Opened 7 years ago
Last modified 4 years 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)
Change History (8)
by , 7 years ago
Attachment: | FF_massfowl.wav added |
---|
by , 7 years ago
Attachment: | ffplay-20170628-183744.log added |
---|
FFplay log generated with the -report commandline switch
comment:2 by , 7 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 , 7 years ago
Component: | undetermined → avformat |
---|---|
Keywords: | h263 mp3 regression added |
Priority: | minor → important |
Version: | unspecified → git-master |
Regression since fc145e576a443bfc89efdf35b91fd3c9ca0d8388
comment:4 by , 7 years ago
Keywords: | probe added |
---|
comment:5 by , 4 years 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:
- Improve the h263 parser so that it's more robust against sequence of bytes which might, by chance, result in a false positive detection.
- 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.
- 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.
- 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 , 4 years ago
1 and 2 are infinitely more welcome, they may not be completely trivial though.
The file that fails to playback