[Live-devel] Frame Buffer

[Ross Finlayson]

> So my concern and my question was more about recieving/sending frames than recieving/sending packets, so that I was asking if inside livemedia there is any buffer that stores packets, sorts them and compile them in frames.

Sort of.  First, our RTP reception code automatically ensures that incoming data is delivered in the correct order, even if packets happen to get reordered on the network.  So that's not something that you ever need to worry about.  Our code also deals with the fact that H.264 NAL units may be fragmented over multiple RTP packets.  Our RTP reception code ("H264VideoRTPSource", for H.264 video) always delivers either a complete NAL unit, or (if one of the fragment packets happened to have been lost) no NAL unit at all.  (Note that if a H.264 video 'access unit' has been split into several slices (each one being a NAL unit), then these slices will be delivered - in order, and completely (or not at all) - to the recipient.)

Also, the incoming NAL units will be sorted into 'decode order'  - because that's the order (according to the H.264/RTP payload format standard) in which they were originally transmitted.

Finally, we have a Boolean function "RTPSource::curPacketMarkerBit()" that the receiving code can call to check whether or not the most recently-received NAL unit ends an 'access unit'.

The bottom line is that our code automatically deals with the RTP packetization/depacketization.  All you (as a programmer) need to deal with is 'NAL units'.

You can illustrate this by running the "testRTSPClient" demo application on a H.264 RTSP stream.  See also http://www.live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data

(ps. When responding to an email, please remember to properly trim the text of the quoted message that you're responding to.)


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/20131030/eb686bcd/attachment.html>