Request key frame in vpuenc (Freescale)
Chuck Crisler
ccrisler at mutualink.net
Wed Oct 2 09:11:39 PDT 2013
It has been a while since I worked with the VPU/Freescale and the memory is
a bit rusty. The SPS/PPS are quite small. Yes, it is wasteful so you
typically count something (seconds, IFrames, whatever) and then send them.
I worked on a robotic application over WIFI, so we always had to be
concerned about sending the SPS/PPS when out of range. There were also
concerns about driving the robot when the driver couldn't see where it was
going. :-) (running into people, driving down stairs, others) Also, dropped
packets always happen, even under the best conditions, which WIFI isn't.
On Wed, Oct 2, 2013 at 11:26 AM, Carlos Rafael Giani
<dv at pseudoterminal.org>wrote:
> On 2013-10-02 16:42, Chuck Crisler wrote:
>
>> I don't think that you need to run the parser after the encoder. The
>> encoder produces a valid H264 buffer so the parser can't do anything
>> worthwhile. Yes, you need to store the SPS/PPS and transmit them in the
>> bitstream with each IFrame. The only other thing to look into is whether or
>> not the encoder inserts start codes in the H264 buffer at MB boundaries
>> based on the MTU size and verify that the payloader is breaking the buffer
>> at those boundaries. And make sure that you are setting the MTU properly.
>>
>>
> You need the parser in case downstream expects a different format. The VPU
> produces h264 data in Annex.B (byte-stream) format. There are container
> formats which do not need Annex.B, so they do not accept it. h264parse can
> then be used to strip it away.
>
> An alternative would be to add code to the encoder element to handle both
> AnnexB and non-Annexb, and access units yes/no. But that seems like code
> duplication to me if h264parse can do it already.
>
> Also, isn't putting the SPS/PPS headers with each IFrame wasteful?
> ______________________________**_________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131002/d5260c8e/attachment.html>
More information about the gstreamer-devel
mailing list