#13614: MediaPlayer Streaming issues
-------------------------+-------------------------------------------------
Reporter: thaflo | Owner: leavengood
Type: bug | Status: assigned
Priority: high | Milestone: Unscheduled
Component: | Version: R1/Development
Kits/Media Kit |
Resolution: | Keywords: mediaplayer, stream, streaming, url
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------+-------------------------------------------------
Comment (by pulkomandy):
This could be related to the way we handle buffering for these streams.
The HTTP request threads downloads the data and fills in a memory buffer
(a variant of BMallocIO, IIRC).
The data is then read on the other side by the media kit through BMediaIO.
However, it is not clear when we are allowed to forget some previously
downloaded data. For a file with a known size/duration, we can keep it all
in RAM as long as the BMediaFile is in use (or if the file is too large we
could switch to on-disk buffering).
However, for a streaming source, the filesize is essentially infinite.
There are flags in BMediaIO but they only allow to guess at this (the
source is marked non-seekable, IIRC). There are flags to ffmpeg to tell it
about this but I don't know if we properly set them. Only after we have
done this, we can know that the ffmpeg plugin will be keeping its own
internal buffering of the data, allowing us to make BMediaIO behave as
"erase-on-read" in this case: whatever has been read cannot be accessed
anymore.
Then, we can somehow make BMediaIO use a fixed size circular buffer for
storage, locking the http thread when it downloads faster than the media
consumer can use the data, and maybe increase the buffer when this
happens, but keeping some sane maximum limit (maybe max 512K of buffer,
which should be a dozen seconds for a compressed MP3 file or so?)
--
Ticket URL: <https://dev.haiku-os.org/ticket/13614#comment:9>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
