[haiku-development] Re: A true streaming equivalent of BDataIO
- From: Christopher Humphries <redeye4@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Aug 2010 15:13:33 +0200
>
> > However many plug-ins insist on seekable content by accepting only a
> > BPositionIO.
>
> Which is unfortunate, but it might be fixable for some add-ons, too.
>
Agreed, if only for ffmpeg. And with the HTML5 version, it might be all
that's needed for the browser anyway.
> > The closest solution to the streaming data construct is the
> > BBufferIO, which allows the buffering of data, but AFAIK it's missing
> > the
> > crucial freeing part: freeing already read data, and avoiding using
> > too much
> > memory in the process.
>
> You obviously misunderstand this class. It has a fixed buffer, and will
> only use that one; therefore it can only seek if the underlying class
> can seek, and it will not use much memory (only as much as you tell it
> to use).
>
Sorry about that, I read through the source again and I understand now how
it's more like a useful static buffer.
>
> > I tried writing my own subclass, where the readat function would
> > return an
> > equivalent number of blocks from the disk, but I think the producer
> > should
> > really be independent from the consumer in this kind of data
> > interface.
>
> I don't understand what you mean here.
>
It's not really important, we were just trying to link a BDataIO directly to
the libdvdnav block reads.
> > Now, I think that a class inheriting BPositionIO that directly
> > implements
> > the standard iostream class, with the general read and write
> > function, but
> > with little or no actual seeking capacity, should do the job. However
> > I
> > could be wrong...
>
> The only way to make it work this way would be to have more than one
> connection unless you want to waste lots of memory. And seeking would
> be dead slow, too, as you would need to "ignore" the whole data stream.
> Assume you are streaming a 4 GB HD video over the network. Now, the
> reader checks some chunk at the end of the file -- do you really intend
> to stream the whole 4 GB over the network to allow this? And do you,
> beyond that, also intend to temporarily store the 4 GB on your local
> disk in order to provide seeking capability?
>
> Well, it cannot work this way generally, only for small files it would
> be acceptable.
>
That's entirely my point. When data is streamed, the reader can only depend
on the blocks given to it, in a sequential order generally, and shouldn't be
able to seek at all.
Storing a 4 GB file isn't an option because you can't realistically have a 4
GB buffer. However if you had a streamed data construct, acting like FIFO
storage, you could just write blocks in from the source, the reader can then
read blocks out, and neither of them have to worry about positions or
offsets.
> The only way to make it work reliable is to fix the readers. They should
> as much as possible try to use a BDataIO only, and do additional checks
> only if there is a BPositionIO.
> In the end, there is not much point in trying to stream a format that
> is not made for streaming at all, so why should we support this?
>
Most network streaming uses appropriate optimal formats, e.g., flash video,
webm, mpeg4... but in practice we're running into more classical file
formats, e.g., mp3, ogg, even quicktime and avi.
I'm not saying that all formats should be streamed, just that quite a few
are.
--
Cheers,
Christopher
Other related posts:
