[Live-devel] H264VideoStreamFramer

[malc]

On Wed, 12 Sep 2012, Ross Finlayson wrote:

> >            framer = H264VideoStreamFramer::createNew
> >                (*env, subsession->readSource (), True/*includeStartCodeInOutput*/);
> > 
> >            MPEG2TransportStreamFromESSource* tsFrames =
> >                MPEG2TransportStreamFromESSource::createNew (*env);
> >            tsFrames->addNewVideoSource(framer, 5/*mpegVersion: H.264*/);
> 
> Your problem here is your use of "H264VideoStreamFramer".  That
> class is intended to be used when reading from a *byte stream* that
> contains a sequence of H.264 NAL units - e.g., from a file.  That's
> why it's used in the "testH264VideoToTransportStream" demo
> application, whose code you used as a model.
> 
> Unfortunately, because you are using a RTSP/RTP client, the input
> source is *not* a byte stream.  Instead, it is a sequence of
> discrete H.264 NAL units - one at a time.  Because of this, the data
> from your RTSP/RTP stream - i.e., "subsession->readSource()" -
> should *not* be fed into a "H264VideoStreamFramer".
> 
> Instead, *in principle*, you could just feed
> "subsession->readSource()" directly into your
> "MPEG2TransportStreamFromESSource" (via the "addNewVideoSource()"
> call).  Unfortunately, however, there's a problem with this: The
> H.264 NAL units that come from the RTP source (i.e., from
> "subsession->readSource()") do not have a 4-byte 'start code' (i.e.,
> 0x00 0x00 0x00 0x01) at the front, but that data that you feed into
> a "MPEG2TransportStreamFromESSource" needs to have these start
> codes.
> 
> Therefore, you will need to write your own subclass of
> "FramedFilter" that adds a 4-byte 'start code' to each input frame,
> and use an instance of this class - instead of
> "H264VideoStreamFramer" - in front of "subsession->readSource()".
> 

That (adding {0,0,0,1}) is basically what avformat based code was
doing, i didn't realize it's needed in this case too. Though in a way
things were easier, the data was just accumulated and then fed to the
avformat, no need to subclass and follow (unknown to me (yet?)) rules
of processing, perhaps there exists an example of something similar in
the source tree already?

Thank you.

-- 
mailto:av1474 at comtv.ru