[FFmpeg-trac] #6500(avformat:open): Fails to playback a certain .WAV audio file

FFmpeg trac at avcodec.org
Sun Sep 6 19:05:44 EEST 2020


#6500: Fails to playback a certain .WAV audio file
-------------------------------------+-------------------------------------
             Reporter:  megpoid      |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  important    |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  h263 mp3     |               Blocked By:
  probe regression                   |
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by ddirect):

 This is a "BMU" file, apparently used in some games. It's basically an MP3
 with the "BMU V1.0" 8 byte string as header (and possibly a footer).
 Removing the 8 bytes header results in score 51 for the mp3 format, so the
 file is detected and decoded correctly. But with the header, the score is
 25 for mp3 and other probers are attempted. The h263 probing partially
 succeeds with a score of 25 as well. The file is then assumed as h263 and
 decoding consequently fails.
 I see 4 possible solutions to this:
 1. Improve the h263 parser so that it's more robust against sequence of
 bytes which might, by chance, result in a false positive detection.
 2. Improve the mp3 parser so that it gives higher score even in presence
 of some random data before the first mp3 frame, when the rest of the data
 really appears to contain valid mp3 frames.
 3. Improve the heuristic used to choose a format instead of another when
 probing results in the same score; for example, between mp3 and h263 I
 might want ffmpeg to choose mp3 since it's arguably a more common file
 format.
 4. Leave everything as it is (this is not a common way to encode an mp3
 anyway), but improve the output, e.g. by notifying the user that the
 probing stage resulted in multiple candidates and possibly suggesting to
 add an appropriate "-f" parameter to the command line. The current default
 output (without a more verbose logging level) doesn't give the user
 information about what is actually going on.
 I'm a developer with some spare time, let me know if working on one of
 these solutions would be helpful. I'm on the ffmpeg-devel mailing list,
 not sure if this discussion actually belongs there.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6500#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list