Ross Finlayson <finlayson@...> writes: > No! You MUST NOT include 'start codes' (i.e., 0x00 0x00 0x00 0x01) > in the NAL units that you feed to a "H264VideoStreamDiscreteFramer". > I don't know how much clearer I (and the LIVE555 code) can be about > this!
Sorry let me be more precise, I meant AVC nal lengths, which I was (incorrectly) referring too as start codes of the AVC format. I definitely get that annex-b start codes should not be sent to the Framer, it can be clearly seen in the code, but i am not sure if the framer requires the AVC NAL lengths which precede the Nal data for each NAL Unit. > all is well in delivery except when the NAL's look like MPEG NALS > 00 00 xx xx. (warning nal type:0) Happening when I include the AVC NAL Lengths. > The *receiver* end - i.e., the client - receives NAL units that have > been packed into RTP packets. Once again, according to the > IETF-defined standard payload format for H.264, these NAL units > DO NOT include start codes. Instead, the receiving client receives > - from the RTP demultiplexor - a sequence of discrete NAL units, > each with their size defined. (I.e., the receiving client doesn't need > (and doesn't get) start codes, because instead it knows the size > of each NAL unit.) Ill try to *decipher* the RTP IETF Docs. Thanks for your help. _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
