> 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/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
