flac dev - Sep 2004 - Problem in FLAC__stream_decoder_process_metadata

Hi,

I have a problem when I try to open a file, which is not a FLAC file. When I
open a non-flac file with the stream decoder API, one of the first things called
is FLAC__stream_decoder_process_metadata, which itself calls
stream_decoder_find_metadata_. Unfortunately the non-flac file contains some
content, which leads to the state set to FLAC__STREAM_DECODER_READ_FRAME.

However in FLAC__stream_decoder_process_metadata there isn't a case label
for
FLAC__STREAM_DECODER_READ_FRAME and so the assert is called.

I can't workaroud this, because DirectShow sometimes tries all source
filters
available on the system and so, when opening an AVI or MPEG files with my
DirectShow filter this happens. I also don't have access to the file
information, because I get the data as an anonymous stream, which can also be
some sort of streaming data or such, so I can't check for the file extension
to
be ".flac" or similar. So I fixed this for now by adding another case
label in
FLAC__stream_decoder_process_metadata.

case FLAC__STREAM_DECODER_READ_FRAME:
 decoder->protected_->state=FLAC__STREAM_DECODER_UNPARSEABLE_STREAM;
 return false;

Perhaps this or something similar can be added to the CVS, if this behaviour is
a bug and not a feature.

Regards,

Ingo

--- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote:
> I have a problem when I try to open a file, which is not a FLAC file.
> When I
> open a non-flac file with the stream decoder API, one of the first
> things called
> is FLAC__stream_decoder_process_metadata, which itself calls
> stream_decoder_find_metadata_. Unfortunately the non-flac file
> contains some
> content, which leads to the state set to
> FLAC__STREAM_DECODER_READ_FRAME.
> 
> However in FLAC__stream_decoder_process_metadata there isn't a case
> label for
> FLAC__STREAM_DECODER_READ_FRAME and so the assert is called.
> 
> I can't workaroud this, because DirectShow sometimes tries all source
> filters
> available on the system and so, when opening an AVI or MPEG files
> with my
> DirectShow filter this happens. I also don't have access to the file
> information, because I get the data as an anonymous stream, which can
> also be
> some sort of streaming data or such, so I can't check for the file
> extension to
> be ".flac" or similar. So I fixed this for now by adding another
case
> label in
> FLAC__stream_decoder_process_metadata.
> 
> case FLAC__STREAM_DECODER_READ_FRAME:
>  decoder->protected_->state=FLAC__STREAM_DECODER_UNPARSEABLE_STREAM;
>  return false;
> 
> Perhaps this or something similar can be added to the CVS, if this
> behaviour is
> a bug and not a feature.
it is a bug, but the fix looks more like this:

 case FLAC__STREAM_DECODER_READ_FRAME:
  return true;

this is because at the stream level the metadata is
optional.  I realize this is not clear from the format
document and it's something I need to update.

the stream decoder has do be able to continue decoding
in the absence of the metadata.  almost by definition,
if you are using the stream decoder, you have already
determined that the content is FLAC.

this doesn't help you though!  what to do... well,
can you check the first 4 bytes coming in for the
'fLaC' signature?  even if you can't rewind your
input stream, you should be able to buffer 4 bytes
in a 'lookahead' buffer, and change your read callback
to consume that first.  but I admit I don't know
anything about direct show filters.

the other clean thing you can do is this: given the
patch I described above, you can just check to see
if you returned from ...process_metadata() without
getting a metadata callback.  if you did not get a
metadata callback, that means the input didn't even
contain the 'fLaC' marker.  if you did get a metadata
callback, you know it's FLAC and are ready to
...process_remaining_frames()

Josh


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Hi Josh,
> this is because at the stream level the metadata is
> optional.  I realize this is not clear from the format
> document and it's something I need to update.
you are right, this isn't clear.
> the stream decoder has do be able to continue decoding
> in the absence of the metadata.  almost by definition,
> if you are using the stream decoder, you have already
> determined that the content is FLAC.
Not really. With DirectShow you register file types either by the extension,
which is what I do, or with magic values, similar to the mime-magic
functionality found on UNIX systems. However there seem to be problems with
that, so the graph builder, in some cases, simply tries all source filters. So,
when the MediaPlayer opens an AVI it loads all filters registered, e.g. my FLAC
filter, which in turn sets up the stream decoder and reads in the metadata.

What I do now is to provide a flag, which indicates that the file is opened,
then I call ..process_metadata. When the read callback is called it checkes,
whether the file is currently opening and if so, all read requests beyond a
certain byte position (e.g. the first 64 kB or so) are rejected. This should
prevent the ..._process_metadata from scanning through the whole file.

Second, I'll do this:
> the other clean thing you can do is this: given the
> patch I described above, you can just check to see
> if you returned from ...process_metadata() without
> getting a metadata callback.  if you did not get a
> metadata callback, that means the input didn't even
> contain the 'fLaC' marker.  if you did get a metadata
> callback, you know it's FLAC and are ready to
> ...process_remaining_frames()
This is the best solution I think. Thanks for your help.

Regards,

Ingo