Opened 5 weeks ago

Last modified 4 days ago

#6917 new defect

Seeking in AVI file with mp3 audio throws errors during decoding.

Reported by: dalecurtis 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 (9)

comment:1 Changed 5 weeks ago by dalecurtis

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

built with clang version 6.0.0 (trunk 318667)
configuration: --enable-libfdk-aac --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libx264 --enable-libx265 --enable-shared --enable-nonfree --enable-gpl --cc=clang --ld=clang
libavutil 56. 5.100 / 56. 5.100
libavcodec 58. 7.100 / 58. 7.100
libavformat 58. 3.100 / 58. 3.100
libavdevice 58. 0.100 / 58. 0.100
libavfilter 7. 7.100 / 7. 7.100
libswscale 5. 0.101 / 5. 0.101
libswresample 3. 0.101 / 3. 0.101
libpostproc 55. 0.100 / 55. 0.100

Input #0, avi, from '/var/www/xvid_sample.avi':KB sq= 0B f=0/0

Duration: 00:02:27.57, start: 0.000000, bitrate: 3337 kb/s

Stream #0:0: Video: mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 3270 kb/s, 30 fps, 30 tbr, 30 tbn, 30.01 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 22050 Hz, stereo, s16p, 55 kb/s

[mp3 @ 0x7f546400b980] Header missing

comment:2 in reply to: ↑ description Changed 4 weeks ago by cehoyos

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 Changed 4 weeks ago by cehoyos

  • Keywords avi mp3 added
  • Version changed from unspecified to git-master

comment:4 follow-up: Changed 4 weeks ago by dalecurtis

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 Changed 4 weeks ago by cehoyos

Assuming the file has an issue: Wouldn't if be better if Chromium played the file?

comment:6 follow-up: Changed 4 days ago by dalecurtis

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 Changed 4 days ago by heleppkes

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.

Last edited 4 days ago by heleppkes (previous) (diff)

comment:8 in reply to: ↑ 6 Changed 4 days ago by cehoyos

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 in reply to: ↑ 4 Changed 4 days ago by cehoyos

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.

Note: See TracTickets for help on using tickets.