[haiku-development] Re: Alternatives to plug-in sniffing

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 18 Aug 2010 12:25:19 +0200

Am 18.08.2010 03:16, schrieb Christopher Humphries:
Hi all,

I had some problems with the sniffing functions in the media plug-ins.

I realise that for streaming to work properly the plug-ins need to be
adapted to make do with a BDataIO when the data isn’t seekable, but it’s
still a problem when only a small chunk of data is available.

Asking each plug-in to sniff the data works on files, where seeking is a
simple matter, but for live streams, seeking is tricky. If the file is
small, seeking in the saved data can work, but bulkier content, e.g., HD
video and DVD data, takes up several gigabytes.

In my opinion, it would be much easier to optionally be able to directly
ask for a certain plug-in, using the device API (libdvdnav can return
accurate format data) or the media MIME type, and avoid the format sniffing.

Asking for a specific plugin is already possible with the API, IIRC you have to use the BMediaFile constructor which takes "const media_file_format*" as parameter.

For sniffing the format, it's indeed not healthy to rely on reading from the source and seeking back to the previous location in the stream for each plugin. On the other hand, it's not necessary to read large amounts of data to be able to sniff. libavformat uses a default sniff buffer of 2K or something in that range, IIRC, and it's able to detect pretty much anything. The way things are setup in libavformat, the initial sniffing buffer is not discarded when actual demuxing/decoding begins, since it's simply left in the I/O caching buffer. We could use a similar approach, for example by wrapping the non-seekable BDataIO source in a buffering BDataIO source class, which we can still "reset" from within the sniffing code that iterates the plugins. It would be a trival change and buffering the reads is not a bad idea anyway (we do that already, but IIRC elsewhere).

Best regards,
-Stephan


Other related posts: