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)
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.
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.
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.
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?
On Mon, Nov 3, 2014 at 6:52 PM, Mark Bondurant <ma...@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-boun...@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@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
