> I am working on parsing H264 too. A RTP H264 stream > I found that it is a common approach of decoders (hard and soft) to request > an entire AU (or frame). > However, the code in live is parsing the streams at NAL-by-NAL basis.
If you're talking about *receiving* H.264/RTP streams, then the only LIVE555 code that's involved is "H264VideoRTPSource", which doesn't do any 'parsing' at all. It just 'delivers' - in this case NAL units, because that is what the H.264 RTP payload format defines to be the units that are packed into RTP packets. (Note also that, at least in principle, decoders can decode NAL units at a time, not just entire "access units" at a time; that's why it makes sense to deliver NAL units at a time.) > Still, I am fighting to migrate this approach to a AU-by-AU basis. For that, > i think the (H264VideoRTP) source should detect the end of an AU (not an > straightforward matter though) and then instruct the FramedSource to write > the entire AU to the sink (aftergetting). We do that for many other video RTP payload formats. For H.264, however, the units of delivery - as noted above - are NAL units, not "access units". What you can do, however, is - after you've read each NAL unit from your "H264VideoRTPSource" - call "RTPSource::curPacketMarkerBit()" to check whether or not the RTP "M" bit was set on the most recently-received packet. This bit is used to indicate the end of an "access unit" (not just a NAL unit). You might also want to look at the VLC code, because they've done H.264 RTP receiving/decoding using the LIVE555 libraries for several years now. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
