<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Date: Tue, 29 Nov 2011 20:30:36 +0000<br>
From: Jeff Shanab <<a href="mailto:jshanab@smartwire.com">jshanab@smartwire.com</a>><br>
To: LIVE555 Streaming Media - development & use<br>
<<a href="mailto:live-devel@ns.live555.com">live-devel@ns.live555.com</a>><br>
Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode<br>
Message-ID:<br>
<<a href="mailto:615FD77639372542BF647F5EBAA2DBC20B18E72A@IL-BOL-EXCH01.smartwire.com">615FD77639372542BF647F5EBAA2DBC20B18E72A@IL-BOL-EXCH01.smartwire.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I have a filter that recievecs nal units and spits out frames.<br>
It is a simple state machine on nal type.<br></blockquote><div>I merely use MarkerBit of RTP and Nal unit type 6 (payload type 10) which for my econder configuration is working pretty nice so far. However, I have not tested it against heavy losses or with other encoders.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br></blockquote><div>I should investigate that. My enconder configuration produces those at the start of stream, but I have not thought about losing them yet.</div>
<div><br></div><div>Thank you for your help.</div><div>Best Regards</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
From: <a href="mailto:live-devel-bounces@ns.live555.com">live-devel-bounces@ns.live555.com</a> [mailto:<a href="mailto:live-devel-bounces@ns.live555.com">live-devel-bounces@ns.live555.com</a>] On Behalf Of Ross Finlayson<br>
Sent: Tuesday, November 29, 2011 12:09 PM<br>
To: LIVE555 Streaming Media - development & use<br>
Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode<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>
<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>
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>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.live555.com/pipermail/live-devel/attachments/20111129/692908f0/attachment.html" target="_blank">http://lists.live555.com/pipermail/live-devel/attachments/20111129/692908f0/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br>
<br>
End of live-devel Digest, Vol 97, Issue 39<br>
******************************************<br>
</blockquote></div><br>