Opened 6 years ago
Last modified 6 years ago
#6917 new defect
Seeking in AVI file with mp3 audio throws errors during decoding.
| Reported by: | Dale Curtis | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | undetermined |
| Version: | git-master | Keywords: | avi mp3 |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Originally reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=794782
On ToT ffmpeg, ffplay will show "[mp3 @ 0x7fcd8400b900] Header missing" errors when seeking in the following sample: http://storage.googleapis.com/dalecurtis/xvid_sample.avi (not attached due to size).
The file continues to play because ffplay ignores avcodec_send_packet() failures, but presumably the file should not be throwing errors (certainly it does not in Windows Media Player).
Remuxing the file with the same ToT version of ffmpeg resolves the problem, but since the file plays in WMP without issue I'm not sure there's anything wrong with the original file.
Change History (13)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Replying to dalecurtis:
On ToT ffmpeg, ffplay will show "[mp3 @ 0x7fcd8400b900] Header missing" errors when seeking in the following sample: http://storage.googleapis.com/dalecurtis/xvid_sample.avi (not attached due to size).
This sounds as if the issue is not reproducible with ffmpeg, please remember not to report issues against ffplay if they are reproducible with ffmpeg.
The file continues to play because ffplay ignores avcodec_send_packet() failures
Do you mean it is expected behaviour for Chromium to fail for OTA-files that produce decoding errors because of reception issues?
comment:3 by , 6 years ago
| Keywords: | avi mp3 added |
|---|---|
| Version: | unspecified → git-master |
follow-up: 9 comment:4 by , 6 years ago
Well both ffmpeg and ffplay spout that error when processing the file, so it does happen in both -- it's just not a fatal error in either like it is in Chrome.
I reported this as a bug because I'm not sure if it should be printing an error at all, since WMP (which is generally fairly strict) plays it without issue.
I'm hoping to hear that either this file is corrupt or this is a bug in parsing/seeking (just a low pri one since ffmpeg/ffplay don't care about such errors).
Thanks in advance!
comment:5 by , 6 years ago
Assuming the file has an issue: Wouldn't if be better if Chromium played the file?
follow-up: 8 comment:6 by , 6 years ago
Generally no because we can't differentiate between what is a fatal error where proceeding may have security consequences and what may be equivalent to a "please retry" type error.
We'd also like to act as a forcing function for correctly encoded media on the web and beyond by not silently omitting errors in content.
Unfortunately this means sometimes we won't be able to play everything, but there are no shortage of alternative players if the content is important enough to cause the user to persevere.
comment:7 by , 6 years ago
Parsers in FFmpeg are generally designed to never throw data away. So if a partial packet is received without its header (because of bad packeting in the source file, for example), the parser will not discard it, but just forward it to the decoder - which will then error due to the missing header.
Demuxers generally do not perform validity checks of the packet data due to sheer volume of possible codecs in any given container format (some exceptions apply).
This sounds like the expected behavior in the design of the interaction between demuxers, parsers and decoders to me. One of the components would have to indicate an error of some sort when it discards data, and in this case it happens to be the decoder.
One option is that seeking should hit a better point, but as mentioned above demuxers generally cannot analyze packet content but have to rely on container metadata, and if the AVI has index entries in inopportune positions....
On that note, decoding errors should generally be considered "try again with the next input packet" kind of errors. If one really wanted, you could stop after a long series of on-going errors, but single frames being broken/undecodable (especially at the beginning of badly cut files, or after a seek) is not entirely uncommon.
comment:8 by , 6 years ago
Replying to dalecurtis:
Generally no because we can't differentiate between what is a fatal error where proceeding may have security consequences
Am I correct that you are reporting every single such instance?
Is it really likely that actual such errors (that do lead to security consequences) always show an error before something bad happens?
and what may be equivalent to a "please retry" type error.
We'd also like to act as a forcing function for correctly encoded media on the web and beyond by not silently omitting errors in content.
Do I understand correctly that Chrome does not support transport streams at all? Because afaict, they were defined with the intention to allow unreliable transport, and every transport stream I record here does have reception errors that lead to decoding errors with FFmpeg.
comment:9 by , 6 years ago
Replying to dalecurtis:
I reported this as a bug because I'm not sure if it should be printing an error at all, since WMP (which is generally fairly strict) plays it without issue.
I forgot to comment:
Last time I tested, WMP was better decoding heavily damaged transport streams than FFmpeg, in addition it allows for wrong PAT/PMT which even FFmpeg refuses sometimes, see tickets #1798 and #4864.
comment:10 by , 6 years ago
To get back on topic, we are getting reports of more mp3 files failing in send packet. At least one of those appears to be a valid MP3 file, which makes me think there is actually a bug with the mp3 demuxer.
The linked (too big to attach) file will end with a "header missing" error; and passes mp3val:
https://bugs.chromium.org/p/chromium/issues/detail?id=806601#c12
Analyzing file "ES_To Be Still.mp3"...
INFO: "/usr/local/google/home/dalecurtis/Downloads/ES_To Be Still.mp3": 8719 MPEG frames (MPEG 1 Layer III), +ID3v2+APEv2, CBR
Done!
comment:11 by , 6 years ago
FFmpeg seems to balk at the APEv2 tag:
"[mp3 @ 0x21fa4c0] Audio packet of size 206 (starting with 41504554...) is invalid, writing it anyway."
00379f20 aa aa aa 41 50 45 54 41 47 45 58 d0 07 00 00 ae |...APETAGEX.....|
00379f30 00 00 00 04 00 00 00 00 00 00 a0 00 00 00 00 00 |................|
00379f40 00 00 00 07 00 00 00 00 00 00 00 4d 50 33 47 41 |...........MP3GA|
00379f50 49 4e 5f 4d 49 4e 4d 41 58 00 31 32 30 2c 32 30 |IN_MINMAX.120,20|
00379f60 38 0b 00 00 00 00 00 00 00 4d 50 33 47 41 49 4e |8........MP3GAIN|
00379f70 5f 55 4e 44 4f 00 2b 30 30 32 2c 2b 30 30 32 2c |_UNDO.+002,+002,|
00379f80 4e 0c 00 00 00 00 00 00 00 52 45 50 4c 41 59 47 |N........REPLAYG|
00379f90 41 49 4e 5f 54 52 41 43 4b 5f 47 41 49 4e 00 2d |AIN_TRACK_GAIN.-|
00379fa0 32 2e 30 31 30 30 30 30 20 64 42 08 00 00 00 00 |2.010000 dB.....|
00379fb0 00 00 00 52 45 50 4c 41 59 47 41 49 4e 5f 54 52 |...REPLAYGAIN_TR|
00379fc0 41 43 4b 5f 50 45 41 4b 00 30 2e 36 36 30 32 36 |ACK_PEAK.0.66026|
00379fd0 36 41 50 45 54 41 47 45 58 d0 07 00 00 ae 00 00 |6APETAGEX.......|
It seems to have trouble with that APE tag, https://en.wikipedia.org/wiki/APE_tag
So this may be a separate issue after all.
follow-up: 13 comment:12 by , 6 years ago
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224673.html should fix the issues with APE tags. So we can disregard that for this bug.
To answer some of the above questions:
- We report almost every error, we do allow decoding errors to continue for audio.
- No we don't support transport streams.
It seems we may need to allow skipping send packet failures for audio as well given the above notes.
comment:13 by , 6 years ago
Replying to dalecurtis:
- No we don't support transport streams.
I had not realized this, thank you for the information!
For posterity here's the version information and command line:
$ ffplay /var/www/xvid_sample.avi
ffplay version N-89504-g5450972be4 Copyright (c) 2003-2017 the FFmpeg developers
Input #0, avi, from '/var/www/xvid_sample.avi':KB sq= 0B f=0/0
[mp3 @ 0x7f546400b980] Header missing