Sorry for the bad subject! > > Date: Tue, 29 Nov 2011 10:08:32 -0800 > From: Ross Finlayson <finlay...@live555.com> > To: LIVE555 Streaming Media - development & use > <live-de...@ns.live555.com> > Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode > Message-ID: <6634fb8c-1025-47c9-8f10-e0d66b300...@live555.com> > Content-Type: text/plain; charset="iso-8859-1" > > > 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). > > I already use MarkerBit, along with NAL type to identify the end of AU. (still need to prove it to be secure detection with losses)
> 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. > > VLC, AFAIK does not implement SVC decoding, which I pursue. Mplayer does, but the parsing is again Nal-by-Nal and their code is a bit heavy for my taste. I do like your code more. I am trying to insert the startcodes once I detect a packet that begins a new NAL (not always true). Then continue doing so up to I detect a New AU and there, mark the fcurrPacketCompletesFrame so the afterGetting is executed. ¿Is this correct? Thank you very much.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
