Sorry for the absence, but I have about a dozen hats to wear.
From: live-devel [mailto:[email protected]] 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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
[email protected]<mailto:[email protected]>
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
