[Live-devel] Buffering an H264 Video Stream

[Jeff Shanab]

Understanding the RTSPClient code is the first requirement! it succinctly
and completely shows the minimum needed.

Strobe is an interesting word but I get what he means, It is a pull
system.  The FAQ has a great explanation of this.
The getNextFrame calls the source to the left(with the provided callback),
which calls the source to the left and so on. The source on the far left
then calls afterGettingFrame() and calls the client callback with the data.
which calls it's guy on the right until it hits the sink on the right. At
that point a getNextFrame() must be called to keep the process going.

On Mon, Nov 3, 2014 at 6:03 PM, Ross Finlayson <finlayson at live555.com>
wrote:

> In the example program you have the ourRTSPClient with a StreamClientState
> object attached. You "strobe" the session object to cause the client to
> pump frames through.
>
>
> I don’t know what you mean here.  I don’t use the word “strobe” anywhere
> in the code or documentation.  Please stop making up your own terminology
> to describe our code!
>
>
> Looking at these two pieces together, I see what I need, but I also see
> two disparate paradigms. The framer wants a FramedSource and RTSPClient
> presents a Media source. RTSPClient understands RTSP, the framer
> understands H264. But they don't fit together in any way I can see. I see a
> Framed paradigm and a Media paradigm.
>
>
> You need to completely discard whatever view (or ‘paradigm’) that you have
> of the code, because it’s at best confusing, and at worst completely wrong!
>
> Instead, start thinking of the code this way (which corresponds to what it
> actually does!):
> ----------
> Your RTSP client application (again, I recommend using “testRTSPClient” as
> a model) would consist of a “MediaSink” object (in the “testRTSPClient”
> code, this is called “DummySink”), which receives data from a
> “FramedSource” object (in the “testRTSPClient” code, this is
> "scs.subsession->readSource()”).  The application starts the flow of data
> by calling “startPlaying()” on the “MediaSink” object.  (This is done just
> once.)
>
> The “MediaSink” object receives one ‘frame’ at a time.  (For H.264 video,
> this ‘frame’ is actually a H.264 NAL unit; not a complete ‘picture’.)  Your
> “MediaSink” subclass would do whatever processing that you want on these
> incoming H.264 NAL units.  Once again, I suggest that you review the code
> for “DummyRTPSink::afterGettingFrame()” ("testRTSPClient.cpp”, lines
> 500-521).  In your own application, you would rewrite this code to do
> whatever you want to the incoming NAL units.
> ----------
>
> (And yes, as Jeff Shanab implied, you could write a “FramedFilter”
> subclass, and insert an object of this subclass in front of the
> ""scs.subsession->readSource()”, and then modify your call to
> “FramedSink::startPlaying()” accordingly.  But before you start playing
> around with “FramedFilter”s, you first need to understand the basic
> “testRTSPClient” application code - and, right now, you seem to be way away
> from this.)
>
> If you don’t want to use the “testRTSPClient” code as a model for your own
> application, then that’s your choice - but then you can’t expect much help
> (at least, not for free) on this mailing list.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> 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/20141103/517824c9/attachment.html>