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

[Alberto Alvarez]

>
>
> Date: Tue, 29 Nov 2011 20:30:36 +0000
> From: Jeff Shanab <jshanab at smartwire.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:
>        <
> 615FD77639372542BF647F5EBAA2DBC20B18E72A at 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: live-devel-bounces at ns.live555.com [mailto:
> live-devel-bounces at ns.live555.com] 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
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
> End of live-devel Digest, Vol 97, Issue 39
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111129/84dd0d0a/attachment-0001.html>