[gst-devel] stuff needing to be fixed for Rhythmbox

[Ronald Bultje]

Hi Colin,

On Fri, 2003-09-12 at 19:25, Colin Walters wrote:
[snip]
> 2) Typefinding still needs to be more reliable.  The buffer size
> increase helps, but people still have large data like pictures in their
> mp3s.  I think probably what we need is some sort of hinting system. 
> Like if filesrc/gnomevfssrc notices the location ends in .mp3, GStreamer
> should try *really hard* to use it as an mp3 before giving up.

Yeah, we recognized that. We'll likely change typefinding somewhat.
Here's my current idea: provide a typefind function with a GstPad
instead of a GstBuffer, and let it "figure it out" itself. Constraint
for the typefind function: at the end of typefinding, the stream has to
be in the same state as in the beginning. For local files, this is easy:
simply seek back to zero after going through the typefind function.
However, that doesn't work for non-seekable streams, so we'd need to
work around that in some way.

A second idea is to provide it with a GstBytestream instead of a GstPad,
and use gst_bytestream_peek_bytes(). This caches the data inside the
bytestream, so we lose nothing. After typefinding, the autoplugger (or
whatever) fetches the bytestream data and loops it through the pipeline
as normal.

The good thing of both approaches is that we get "full access" to the
pipeline during typefinding, including the possibility to do seeks and
so on, which we definately need for mp3s with images in the id3v2 tag.

Comments? I'm willing to work on this. Oh, and this won't be ported back
to 0.6.x since it's ABI/API breakage.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>