[gstreamer-bugs] [Bug 324186] New: Smarter (deterministic!) typefind decisions

[GStreamer (bugzilla.gnome.org) <bug...@bu...>]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D324186
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: Smarter (deterministic!) typefind decisions
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gst...@li...
        ReportedBy: th...@ma...
         QAContact: gst...@li...
                CC: all...@bu...


I have just encountered a case with a file (from
http://bugzilla.gnome.org/show_bug.cgi?id=3D324123) that highlights a pro=
blem with
current typefinding.

The file in question contains an ID3v2 tag at the start, and an ID3v1 tag=
 at the
end. Inside that is a WAV file, containing MP3 data. Normally (ignoring t=
he
problem in #324123), this works ok, because the file is detected as ID3, =
runs
through id3demux then wavparse then the mp3 decoder.

HOWEVER, when I remove the ID3v2 tag from the start, we now have what loo=
ks like
 a WAV file with ID3v1 at the end. Typefinding functions return MAXIMUM f=
or both
WAV and ID3v1, but sometimes one function runs first and sometimes the ot=
her
does (registry reasons?) which means sometimes the ID3 is found and somet=
imes
the WAV is found.

This SUCKS!

The solution is that somehow, ID3 has to take precedence over WAV in this=
 case.

The best suggestion for how to do that so far is to ensure that the ID3 t=
ypefind
function has higher rank than anything that might be contained in ID3, an=
d that
typefind functions are sorted by rank when they are used.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.