Opened 4 years ago

Last modified 14 months ago

#6500 open defect

Fails to playback a certain .WAV audio file

Reported by: megpoid Owned by:
Priority: important Component: avformat
Version: git-master Keywords: h263 mp3 probe regression
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug:
ffplay fails to playback a certain .WAV audio file. VLC and other non-ffmpeg-based players can play it correctly; I'd assume the audio file is malformed in some way because it seems to be detected as a MP3 file.
How to reproduce:

% ffplay -i FF_massfowl.wav
FF_massfowl.wav: Invalid data found when processing input0B f=0/0

Attachments (2)

FF_massfowl.wav (41.2 KB ) - added by megpoid 4 years ago.
The file that fails to playback
ffplay-20170628-183744.log (1.8 KB ) - added by megpoid 4 years ago.
FFplay log generated with the -report commandline switch

Download all attachments as: .zip

Change History (8)

by megpoid, 4 years ago

Attachment: FF_massfowl.wav added

The file that fails to playback

by megpoid, 4 years ago

Attachment: ffplay-20170628-183744.log added

FFplay log generated with the -report commandline switch

comment:1 by Elon Musk, 4 years ago

Reproduced by developer: set
Status: newopen

File IS mp3.

comment:2 by megpoid, 4 years ago

The issue is that this file fails to playback only on ffmpeg-based players, whereas some other similar MP3 files with incorrect extension playback correctly. And non-ffmpeg-based players will play any such files correctly. I'll attach a similar file that plays correctly in all players.

comment:3 by Carl Eugen Hoyos, 4 years ago

Component: undeterminedavformat
Keywords: h263 mp3 regression added
Priority: minorimportant
Version: unspecifiedgit-master

comment:4 by Carl Eugen Hoyos, 4 years ago

Keywords: probe added

comment:5 by Dario, 14 months ago

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.

comment:6 by Carl Eugen Hoyos, 14 months ago

1 and 2 are infinitely more welcome, they may not be completely trivial though.

Note: See TracTickets for help on using tickets.