Sorry for the bad subject!<br clear="all"><div class="gmail_quote"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Date: Tue, 29 Nov 2011 10:08:32 -0800<br>
From: Ross Finlayson <<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>><br>
To: LIVE555 Streaming Media - development & use<br>
        <<a href="mailto:live-devel@ns.live555.com" target="_blank">live-devel@ns.live555.com</a>><br>
Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode<br>
Message-ID: <<a href="mailto:6634FB8C-1025-47C9-8F10-E0D66B300EAD@live555.com" target="_blank">6634FB8C-1025-47C9-8F10-E0D66B300EAD@live555.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
> I am working on parsing H264 too. A RTP H264 stream<br>
> I found that it is a common approach of decoders (hard and soft) to request an entire AU (or frame).<br>
> However, the code in live is parsing the streams at NAL-by-NAL basis.<br>
<br>
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.)<br>



<br>
<br>
> 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).<br>



<br>
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".<br>
<br>
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).<br>



<br></blockquote><br></div><div>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)</div><div class="im"><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br></blockquote></div><div>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. </div><div><br>

</div>
<div>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. </div>


<div>żIs this correct?</div><div><br></div><div>Thank you very much.</div><div><br></div></div>
</div><br>