[gst-devel] decodebin, typefinding and seeking

Ronald S. Bultje rbultje at ronald.bitfreak.net
Wed May 11 00:52:14 CEST 2005


Hi Mark,

On Wed, 2005-05-11 at 00:19, Dezelon, Mark wrote:
> I've noticed a couple issues, however.  First the typefinding occurs
> after every 4K read from "myfile".  In another words, according to the
> (extremely lengthy) debug output, 4096 bytes are read and stored in a
> decodebin buffer, a typefinding cycle is run, the next 4096 bytes are
> read and appended, another typefinding cycle is run, and so forth until
> EOF is reached.
> 
> It's the second issue that puzzles me most:  After reading 106496 bytes
> from "myfile", the typefinder sends a seek event (GST_SEEK_METHOD_SET)
> to the end of the file.  Afterwards it sends another seek event to the
> middle of the file.  Then the above process of "read 4K, run a typefind
> cycle" continues until the end of the file.
> 
> The problem is that the bytes in "myfile" must be sent through the
> decoder continuously as every byte is dependent upon the byte before it.

I don't see a problem, I think you read too many logfiles. :). This
behaviour is completely normal, and relates to mp3 typefinding. Here's
what it looks like, and why:

* first, look at the start of the file. For 100kB, try to parse mpeg
audio frames. If 3 subsequent frames (i.e. header + len, and a new
header at header_offset + len) were found, return that we're probably
MPEG. This is because the MPEG audio header isn't all that good a
recognition point, because it's only a few bits. Any /dev/random output
has those bits somewhere.
* If not, then go to halfway the file and do this again. This is because
there's mp3 files out there that start with up to a MB of junk (no, no
a  id3 header; I really mean junk)...

After typefinding, it seeks back to the beginning and handles the whole
file. From here on, it starts forwarding data to the decoder found by
decodebin.

If this doesn't work for you, then you've probably found a bug in
typefind, which isn't all impossible. Please file a bug etc.

Ronald

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





More information about the gstreamer-devel mailing list