[Live-devel] H264VideoStreamFramer

[Ross Finlayson]

>            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()".


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120912/364b165b/attachment.html>