I have a filter that recievecs nal units and spits out frames. It is a simple state machine on nal type.
Watchout for the embedded/unembedded SPS amd PPS packets, some sources have them and some don't. If they don't I build them from the SDP and then insert them in so Clients are happy. From: [email protected] [mailto:[email protected]] On Behalf Of Ross Finlayson Sent: Tuesday, November 29, 2011 12:09 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode 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
