> > > Date: Tue, 29 Nov 2011 20:30:36 +0000 > From: Jeff Shanab <[email protected]> > To: LIVE555 Streaming Media - development & use > <[email protected]> > Subject: Re: [Live-devel] Passing H.264 RTP stream to hardware decode > Message-ID: > < > 615fd77639372542bf647f5ebaa2dbc20b18e...@il-bol-exch01.smartwire.com> > Content-Type: text/plain; charset="us-ascii" > > I have a filter that recievecs nal units and spits out frames. > It is a simple state machine on nal type. > 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.
> > 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. > I should investigate that. My enconder configuration produces those at the start of stream, but I have not thought about losing them yet. Thank you for your help. Best Regards > > 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/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20111129/692908f0/attachment.html > > > > ------------------------------ > > _______________________________________________ > live-devel mailing list > [email protected] > http://lists.live555.com/mailman/listinfo/live-devel > > > End of live-devel Digest, Vol 97, Issue 39 > ****************************************** >
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
