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

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 5 Mar 2016 13:20:45 +0100

Hello,

On Fri, Mar 4, 2016 at 2:09 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:

[...]

3.) Could be solved entirely in the add-on. But then each add-on
would need to solve this.
Also, buffering could be better handled in the BDataIO/BPositionIO
class (especially for sniffing where more than one add-on is involved).
So, the final AIM is to adjust the add-on to be aware about the
different functionalities supplied by BDataIO, BPositionIO, BStreamingIO?


No, IMO the above mentioned class should always be used for the
codec/container add-ons, no matter if the data is streamed or not.

For example, the add-on could set some constraints (ie. how it requires
the data, or what features it requires -- like reading from the end of the
file), and the data IO class would either try its best to accomplish that,
or fail if the underlying stream doesn't allow for that operation.


Ok nice, that's even better and more elegant to implement.

What about adding also BMediaIO::IsCached() and BMediaIO::CacheSize() to
differentiate between cached-seeking and true seeking and
BMediaIO::IsEndless() to allow detect when Position() and GetSize() are
available?

For example a cached BDataIO will specify it's cache size as the buffer
used for sniffing.

At this point it seems we have to make the final API client to be aware of
that, I've considered using some flags too but to me it seems cleaner this
way. I've actually defined BMediaIO as a pure virtual with the intent of it
being an interface between very different ways of providing media.

--
Best Regards,
Dario

Other related posts: