[Live-devel] Passing H.264 RTP stream to hardware decode

[Alberto Alvarez]

Sorry for the bad subject!

>
> Date: Tue, 29 Nov 2011 10:08:32 -0800
> From: Ross Finlayson <finlayson at live555.com>
> To: LIVE555 Streaming Media - development & use
>        <live-devel at ns.live555.com>
> Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode
> Message-ID: <6634FB8C-1025-47C9-8F10-E0D66B300EAD at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111129/bc436644/attachment.html>