[Live-devel] Buffering an H264 Video Stream

[Mark Bondurant]

Sorry for the absence, but I have about a dozen hats to wear.

From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeff Shanab
Sent: Monday, November 03, 2014 4:46 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Buffering an H264 Video Stream

Security cameras keep it simple. They will not usually have bidirectionally predictive frames as that generally takes a two pass encoder and adds latency. Either way that is not the concern at the streaming level although i think live555 will reorder frames if need be.
Remember that this is an RTSP stream, probably unlike the MJPEG  you are use to.
Wikipedia has a good explanation of the basic RTSP conversation. Live555 implements this protocol (both as server and as client)
Read that (the sound of the breeze blowing by over my head), bought a book and read it too. Not helpful in regards to live555 though, which is more a matter of implementation details. Did read the faqs, although apparently it did me no good.
Look at the RTSPCLient.cpp and PlayCommon.cpp to understand the client.
After the necessary steps to start up the conversation with the response from each step responsable for sending the next one.
OPTIONS
DESCRIBE
SETUP
PLAY
 You will call GetNextFrame and live555 will listen the on the socket, collect the data into frames, handle all the lower level protocol assemble into and pass only only complete nal units to your afterGettingFunction, Complete with presentation timestamps.
So you're saying that, because of the brain dead nature of security of security cameras, I can gather NAL packets into a clip starting at any point in the stream and expect that clip to play? I don't have to worry about boundaries beyond that?
At that point you need to collect the frames into your buffer for decoding and display. And call GetNextFrame to keep everything moving.
Oversimplified...
class GOP
{
public:
     uint8* m_keyFrame
     uint8* [] m_diffFrames
     int framecount
     ~GOP(){ // delete all allocated buffers}

}

So lets say you have a simple producer consumer ring buffer holding pointers to GOP instances.
A 10 second linked list perhap, dropping the end, adding to the beginning?
You maintain a statemachine watching the transitions of nal unit types and fill in the GOP's with the bytes for each frame.
Each GOP now represents 1 second of video.
Ah, so there is a boundary in the NAL's that I need to watch for, that initial frame that the following packets are moding. You mentioned this earlier:
[7][8][5][1][1][1][1][1][1][1][1]....

When the current GOP is full you
   1 put a pointer to it into the ring buffer
   2 get the pointer to the next space in the buffer and reallocate and fill it in.
and so on. You always have 10 seconds worth of video avail. You just copy them out or write them out etc.
nal
7 - 8 start frame push 7 into keyframe buffer
8 - 5 push 8 into keyframe buffer
5 - 5 push 5 into keyframe buffer
5 - 1 push 5 into keyframe buffer
1 -1 push 1 into diff frame buffer and increment counter
1 - 7 or 1-5 push 1 into last diff frame, set counter to final value and put GOP into ring buffer. Start new GOP
repeat.
Get it?

7, 8,5,1, are these actual identifiers, like a NAL packet type?







On Mon, Nov 3, 2014 at 6:52 PM, Mark Bondurant <markb at virtualguard.com<mailto:markb at virtualguard.com>> wrote:
As you surly must know, I'm a noob thrust unwillingly by circumstances into this.

This is helpful. I don't need frames, just ten seconds of stream. But, doesn't H264 have a definite beginning with the following NAL packets updating the initial packet? That's what all that predictive slices and three dimensional compression and such does? I don't think I can just jump into the middle of the stream and start grabbing packets and still have a usable stream, which is why I was thinking about converting it to mpeg or something.


From: live-devel [mailto:live-devel-bounces at ns.live555.com<mailto:live-devel-bounces at ns.live555.com>] On Behalf Of Ross Finlayson
Sent: Monday, November 03, 2014 3:35 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Buffering an H264 Video Stream

Also, part of the problem here, I think, is that you seem to be confused by what the class “H264VideoStreamFramer” does.  This class takes as input an unstructured H.264 byte stream, and parses it into discrete H.264 NAL units.  It *does not* combine multiple H.264 NAL units into a single ‘access unit’ (i.e., picture).  If you want to do this (or any other processing on the incoming H.264 NAL units), then you’ll need to do this yourself.  The LIVE555 libraries do not contain any video ‘codec’ (i.e., decoding or encoding) functionality.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com<mailto:live-devel at lists.live555.com>
http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20141104/1a0e1cb4/attachment.html>