[Live-devel] Design Suggestion for Returning Frames To User

[Ross Finlayson]

>    I am having difficulty understanding the concept for two reasons, first as I said, only the MediaSink class has access to the newest incoming frame.  How do you envision one transferring this new frame to say ... a GUI for display?

Because I don't know anything about the GUI software that you plan to use, I can't answer this.  But there's no reason in principle why you couldn't make your entire application a single-threaded event loop (including handling of GUI events), and just decode and render frames directly from your "MediaSink" subclass, after it's received each frame.

Alternatively, you might find it more convenient to do the rendering (and perhaps the decoding as well) in a separate thread - especially if your stream contains both audio and video substreams (because then they need to be synchronized, based on their presentation times).  In this case, your separate rendering (or decoding+rendering) thread would pass (in a thread-safe way) buffers to and from the LIVE555 thread, for use by its "MediaSink" subclass.  This is basically how VLC works, for example.

But this is up to you to decide (so this will be my last posting on this topic).


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/20120628/9af57577/attachment.html>