[haiku-development] Re: Streaming Fixes for the Plugin Manager

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 4 Mar 2016 13:51:12 +0100

On Thu, Mar 3, 2016 at 11:59 AM, Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:

This is what I would have thought without having thought it through:
Preconditions:
1) We should avoid refetching data whenever possible (for example, while
sniffing)
2) Many streams are actually positionable to allow for seeking (HTTP is
usually positionable).
3) Therefore, we need to differentiate between streams that are truly
non seekable, and those that
are.

There are a few more caveats:
a) Currently our API for seekable streams (BPositionIO) assume they have a
(fixed) size. This is not the case if you listen to a web radio, for
example, which is an endless stream of data.
b) In the case of ffmpeg, in some cases it will try to seek to the end of
a file to sniff data there and detect the format. This is not possible on
such infinite streams, of course.
c) Adding a seekable overlay onto a mostly streamed media is easy: you can
just download it all and let it sit in memory (or in a seekable file). The
real problem is knowing when data is not needed anymore and can be dropped.

For c) at a minimum we need to know if we are in the sniffing state (data
can be read multiple times, possibly by different plugins), or in "runtime"
(ffmpeg has started decoding the stream, now there should be mostly no
seeks). Once in runtime we can decide to allow only pause and fast-forward
for really streamed data, or we can decide to keep some megabytes behind
the current play time buffered to allow some seeking a few minutes back.


I think to correctly solve some behaviors there's need to allow the
interface behave in slight different ways. For example streaming from a
live youtube channel will not allow seeking forward unless the streaming is
paused, but when the user press play next time he have the possibility to
watch the buffered streaming in a delayed way or press a button to jump
forward to the live streaming. In this case there's not way to go backward
and forward but in that special case I mentioned we are allowed to seek
forward but obviously with the limit of how many frames we buffered in the
meantime. This is an example for why I've been thinking that adding a
BPositionIO-derivd BStreamingIO with the mentioned methods and possibly
more to check the status of buffered data could be actually a complete
solution and will give way to eventual subclasses to add more smar ways to
solve the problems.

-- 
Best Regards,
Dario

Other related posts: