Download video from: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/794782

What log are you getting in chrome://media-internals?

Logs added at: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/794782

        "time": 8205.79700000002,
        "key": "error",
        "value": "Failed to send audio packet for decoding: timestamp=72024975 duration=25980 size=443 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0)"
      },
      {
        "time": 8206.002000000037,
        "key": "error",
        "value": "audio decode error"
      },
      {
        "time": 8206.08600000001,
        "key": "error",
        "value": "audio error during playing, status: PIPELINE_ERROR_DECODE"
      },

It's an audio decode error. I can take a look on Friday.

FFmpeg thinks this file is invalid; I've filed https://trac.ffmpeg.org/ticket/6917

Remuxing the file with a ToT version of ffmpeg works fine. You can find the remuxed version at http://xorax.sea/xvid_sample2.avi

 Issue 806601  has been merged into this issue.

Updating description so other bugs can be merged into this. As a workaround you can use "mp3val -f" to fix standalone mp3 files or in the case of AVI, remux using a newer ffmpeg as noted in c#5.

Upstream took my patch to fix the issue with APE tags, http://git.videolan.org/?p=ffmpeg.git;a=commit;h=42323c3e3a600288e4bf1cefe952486ffc29d280

Once xhwang@ completes the ffmpeg roll, I'll cherry-pick that patch to M66. This does not fix the issue with the avi file or other mp3 files that have garbage in them.

Ah great! Thanks a bunch for the swift reply and fix :)
I have worked around the issue for our use case now (we rely on onended() being called at the end of a track playing but this would never be called since onerror would be called first and simply drop out from there).

Dalecur said:
> I'll cherry-pick that patch to M66

Are you saying this won't get fixed until M66??? 
Shouldn't this be fixed ASAP in a patch version?

See: https://stackoverflow.com/questions/48584075/audio-playback-halts-on-chrome-64

nino.skopac: Your mp3 file is damaged, see the comment at https://bugs.chromium.org/p/chromium/issues/detail?id=806601#c10

$ ffmpeg -i 5a745d88483d86.76121223.mp3 -err_detect explode out.wav
ffmpeg version N-89925-gd4967c04e0 Copyright (c) 2000-2018 the FFmpeg developers
Input #0, mp3, from '5a745d88483d86.76121223.mp3':
  Metadata:
    encoder         : Lavf57.71.100
  Duration: 00:13:47.41, start: 0.000000, bitrate: 48 kb/s
    Stream #0:0: Audio: mp3, 22050 Hz, mono, s16p, 48 kb/s

<snip>

[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] overread, skip -6 enddists: -3 -3
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing bitrate= 348.6kbits/s speed= 914x    
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
[mp3 @ 0x24b9a40] overread, skip -5 enddists: -3 -3
[mp3 @ 0x24b9a40] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
size=   35618kB time=00:13:47.32 bitrate= 352.7kbits/s speed= 966x    
video:0kB audio:35618kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000214%

$ mp3val -f 5a745d88483d86.76121223.mp3 
Analyzing file "5a745d88483d86.76121223.mp3"...
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x77c80): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0xdd806): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x13d98c): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x1af4b4): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x215349): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x289ecf): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x2ef126): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x3514f5): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x3b5ce3): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x424673): MPEG stream error, resynchronized successfully
WARNING: "5a745d88483d86.76121223.mp3" (offset 0x47f1a5): MPEG stream error, resynchronized successfully
INFO: "5a745d88483d86.76121223.mp3": 31671 MPEG frames (MPEG 2 Layer III), +ID3v2, CBR
Rebuilding file "5a745d88483d86.76121223.mp3"...
FIXED: "5a745d88483d86.76121223.mp3": File was rebuilt
Done!

$ ffmpeg -i 5a745d88483d86.76121223.mp3 -err_detect explode out.wav
ffmpeg version N-89925-gd4967c04e0 Copyright (c) 2000-2018 the FFmpeg developers
  built with clang version 6.0.0 (trunk 321529)
  configuration: --enable-shared --enable-nonfree --enable-gpl --cc=clang --ld=clang
  libavutil      56.  7.100 / 56.  7.100
  libavcodec     58.  9.100 / 58.  9.100
  libavformat    58.  7.100 / 58.  7.100
  libavdevice    58.  0.101 / 58.  0.101
  libavfilter     7. 11.101 /  7. 11.101
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
[mp3 @ 0xc49580] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '5a745d88483d86.76121223.mp3':
  Metadata:
    encoder         : Lavf57.71.100
  Duration: 00:13:47.04, start: 0.000000, bitrate: 48 kb/s
    Stream #0:0: Audio: mp3, 22050 Hz, mono, s16p, 48 kb/s

<snip>

size=   35618kB time=00:13:47.03 bitrate= 352.8kbits/s speed= 992x    
video:0kB audio:35618kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000214%

Thanks for the info Dalecur, that gives me enough info on how to fix existing MP3's (run them thru mp3val and upload new versions on S3) and what to change in the future (right now I simply concatenate mp3 binaries, but I'll switch to a library)

 Issue 808928  has been merged into this issue.

Updating title since we're seeing some AAC content with junk packets as well; per the ffmpeg team, the demuxer just shovels whatever it can extract from the stream into the decoder.

These parse failures are unfortunate for clips with 1-2 errors that didn't cause significant drift. Aggregate error rates have risen due to this change, but only by 0.1%-0.2%. The rise is primarily in audio only content. Mixed audio/video content appears to be steady; possibly because we've always failed on such errors for video.

It may be worth exploring an allowance of an error or two per clip. The risk here is we continue down the path of accumulating bad content and hiding stream errors; which is overall bad for the ecosystem and ultimately lead to  issue 806064  and the issue in c#11 with APE tags.

how about fixing the files on-the-fly with ffmpeg itself? or mp3val (mp3val
-f file.mp3)

Can we expect a fix in playback for AAC content with junk packets anytime soon?
I have explained the issue with our file in this comment:  https://bugs.chromium.org/p/chromium/issues/detail?id=808064#c34

 Issue 814430  has been merged into this issue.

 Issue 810004  has been merged into this issue.

We haven't made a decision on the AAC packets since they're part of a well-formed bitstream, but otherwise truncated for some unknown reason. For MP3 files with trailing garbage, on closer inspection of the ffmpeg mp3 parser I think they're doing something incorrect in this case. I've submitted a patch upstream to ffmpeg to fix this:

http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225703.html

I'll pull that into M65 along with the APE tag fix if possible. This should resolve Icecast streams, Nino's mp3 files, and the sample file from  issue 814430 .

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/eac51b1c76474daab2815b95a3514a1176fa5e52

commit eac51b1c76474daab2815b95a3514a1176fa5e52
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Feb 23 19:08:07 2018

Skip trailing junk data when flushing parser.

The parser should only return valid mpeg audio packets; it generally
does so, but in the case of flush, it returns whatever happens to
be in the buffer instead of ensuring its first a valid mpeg packet.

The fix is to check whether a valid frame size has been parsed and
if not discard the packet when flushing.

This should fix all sorts of mp3 files with trailing garbage.

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Bug:  794782 
Change-Id: I4ed8e5e31573f3dc6a3ff3872f4ae8fb9f294091
Reviewed-on: https://chromium-review.googlesource.com/935081
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>

[modify] https://crrev.com/eac51b1c76474daab2815b95a3514a1176fa5e52/libavcodec/mpegaudio_parser.c
[modify] https://crrev.com/eac51b1c76474daab2815b95a3514a1176fa5e52/chromium/patches/README

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d1d61b73d82e3940a775d52de0291b06c5254fc5

commit d1d61b73d82e3940a775d52de0291b06c5254fc5
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Sat Feb 24 04:10:46 2018

Roll /hdd2/chrome/src/third_party/ffmpeg/ 9ed334093..9ca66eafa (7 commits)

https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+log/9ed334093692..9ca66eafaf6f

$ git log 9ed334093..9ca66eafa --date=short --no-merges --format='%ad %ae %s'
2018-02-23 xhwang ffmpeg: Fix memset size on ctts_data in mov_read_trun() (round 2)
2018-02-23 xhwang Revert "ffmpeg: Fix memset size on ctts_data in mov_read_trun()"
2018-02-23 dalecurtis Don't invoke trailing garbage discard for every flush.
2018-02-23 dalecurtis Skip trailing junk data when flushing parser.
2018-01-29 dalecurtis avcodec/mpegaudio_parser: Skip APE tags when parsing mp3 packets.
2018-02-15 dalecurtis Parse and drop gain control data, so that SSR packets decode.
2018-02-15 xhwang ffmpeg: Fix memset size on ctts_data in mov_read_trun()

Created with:
  roll-dep /hdd2/chrome/src/third_party/ffmpeg

BUG= 812567 , 794782 

Change-Id: If6e6ce0fea7773d2a431d8ba390b122e094162b3
Reviewed-on: https://chromium-review.googlesource.com/935967
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538983}
[modify] https://crrev.com/d1d61b73d82e3940a775d52de0291b06c5254fc5/DEPS

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cda1b8dd98a3f31783c42be2908f680571e5dc2d

commit cda1b8dd98a3f31783c42be2908f680571e5dc2d
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Feb 26 20:51:20 2018

Add unit test to ensure mp3 with trailing garbage decodes okay.

The mp3 bitstream is not well-formed, it's essentially just an
aggergation of raw mp3 packets. Common practice (including our
own MP3 demuxer in MSE) is to scan the input bitstream for things
that look like mp3 packets and decode only those while discarding
the rest.

ffmpeg had a bug where they did not properly discard junk from
the end of the file (despite discarding it everywhere else), this
adds a test to ensure it does not regress.

BUG= 794782 
TEST=new unittest

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I322e22fef3ebfa585369edb9d2c5d2ae2bb3afb4
Reviewed-on: https://chromium-review.googlesource.com/935143
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539263}
[modify] https://crrev.com/cda1b8dd98a3f31783c42be2908f680571e5dc2d/media/filters/audio_decoder_unittest.cc
[add] https://crrev.com/cda1b8dd98a3f31783c42be2908f680571e5dc2d/media/test/data/trailing-garbage.mp3

MP3 failures show a large improvement and AAC failures a small improvement after the above patches:
https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+log/2aa88d7..261398f

It's a bit late, but +merge-request-65 to see if we can sneak this in:

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=f6b2ea6e4c0fbd2ce4d93d167f8d42ec

This bug requires manual review: We are only 4 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls apply appropriate OSs label. Thank you.

Rejecting merge to M65 per offline chat with dalecurtis@.

Looks like there is a case where AAC in a raw ADTS is too strictly parsed as well. I'll try to put a patch together for that as well for M66.

 Issue 819488  has been merged into this issue.

Dale, this patch isn't yet fully in upstream ffmpeg; it's still correctly tracked by our downstream patches README as of M67 roll  bug 803898 .

 Issue 822341  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c7916b3e214429239af483abb78efe45e925c08b

commit c7916b3e214429239af483abb78efe45e925c08b
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Mar 19 22:08:04 2018

Ignore invalid MP3 packets from ffmpeg.

Per upstream, this is totally normal to happen and they won't accept
changes to fix this without undertaking a large refactoring of the
AVParser infrastructure:

http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225800.html

This behavior may also occur with ADTS streams, but is rarer in practice
because ffmpeg's ADTS demuxer does more validation on the packets, so
when invalid data is received, av_read_frame() fails and playback ends.
Since we haven't had a rash of complaints about too-short ADTS streams,
don't bother doing this for ADTS streams at this time.

BUG= 822341 , 794782 
TEST=existing tests all still pass.

Cq-Include-Trybots: luci.chromium.try:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Iabcad145bb75f742e4ba7658ab95c377b811efa1
Reviewed-on: https://chromium-review.googlesource.com/965121
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544181}
[modify] https://crrev.com/c7916b3e214429239af483abb78efe45e925c08b/media/filters/audio_decoder_unittest.cc
[modify] https://crrev.com/c7916b3e214429239af483abb78efe45e925c08b/media/filters/ffmpeg_demuxer.cc
[modify] https://crrev.com/c7916b3e214429239af483abb78efe45e925c08b/media/filters/ffmpeg_demuxer.h
[modify] https://crrev.com/c7916b3e214429239af483abb78efe45e925c08b/media/formats/mpeg/mpeg1_audio_stream_parser.cc
[modify] https://crrev.com/c7916b3e214429239af483abb78efe45e925c08b/media/test/pipeline_integration_test.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d4c3823079fe41cd1cbef1ffe2e8b24a173f5559

commit d4c3823079fe41cd1cbef1ffe2e8b24a173f5559
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Tue Mar 20 07:27:24 2018

Fix accidental media_log to nullptr.

BUG= 823597 , 822341 , 794782 
TBR=wolenetz

Cq-Include-Trybots: luci.chromium.try:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I7000336c8c34dbb310bc40faa33d3e51c4e1efa3
Reviewed-on: https://chromium-review.googlesource.com/969984
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544304}
[modify] https://crrev.com/d4c3823079fe41cd1cbef1ffe2e8b24a173f5559/media/filters/ffmpeg_demuxer.cc

 Issue 820024  has been merged into this issue.

 Issue 823596  has been merged into this issue.

I'm seeing this on MP3s that, as far as I can tell, are entirely valid (and don't have APE tags). They're doing what's mentioned in OPs post (stopping slightly short, ended event never fires, media-internal shows PIPELINE_ERROR_DECODE, etc).


Here's exiftool's output:
====================================================
ExifTool Version Number         : 10.55
File Name                       : e6e098a2dfef289f2d64f2deaed0c5a1.mp3
Directory                       : .
File Size                       : 1792 kB
File Modification Date/Time     : 2017:10:13 13:26:38+01:00
File Access Date/Time           : 2017:10:13 12:11:45+01:00
File Inode Change Date/Time     : 2018:01:31 00:47:31+00:00
File Permissions                : rw-r--r--
File Type                       : MP3
File Type Extension             : mp3
MIME Type                       : audio/mpeg
MPEG Audio Version              : 1
Audio Layer                     : 3
Sample Rate                     : 44100
Channel Mode                    : Joint Stereo
MS Stereo                       : Off
Intensity Stereo                : Off
Copyright Flag                  : False
Original Media                  : True
Emphasis                        : None
VBR Frames                      : 2863
VBR Bytes                       : 1833912
VBR Scale                       : 80
Encoder                         : LAME3.99r
Lame VBR Quality                : 2
Lame Quality                    : 0
Lame Method                     : VBR (new/mtrh)
Lame Low Pass Filter            : 18.5 kHz
Lame Bitrate                    : 32 kbps
Lame Stereo Mode                : Joint Stereo
Mp 3gain Minmax                 : 138,212
Mp 3gain Undo                   : -002,-002,N
Replaygain Track Gain           : -3.220000 dB
Replaygain Track Peak           : 0.960152
ID3 Size                        : 1018
Title                           : Ingame 3
Artist                          : Jonathan Dunn
Album                           : The Addams Family
Comment                         : RetroTracks
Year                            :
Genre                           : None
Audio Bitrate                   : 196 kbps
Duration                        : 0:01:14 (approx)
====================================================


MP3val:
====================================================
Analyzing file "e6e098a2dfef289f2d64f2deaed0c5a1.mp3"...
INFO: "(path)/e6e098a2dfef289f2d64f2deaed0c5a1.mp3": 2864 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2+APEv2, Xing header
Done!
====================================================



Yet it still results in broken playback.
The media-internals output:
====================================================
audio_buffering_state	BUFFERING_HAVE_ENOUGH
audio_channels_count	2
audio_codec_name	mp3
audio_dds	false
audio_decoder	FFmpegAudioDecoder
audio_sample_format	Signed 16-bit planar
audio_samples_per_second	44100
bitrate	196301
debug	FFmpegDemuxer: av_read_frame(): End of file
duration	75.025502
error	audio error during playing, status: PIPELINE_ERROR_DECODE
event	PAUSE
found_audio_stream	true
found_video_stream	false
frame_title	RetroTracks - The Addams Family - Ingame 3
frame_url	https://retro.sx/music/348
info	Effective playback rate changed from 0 to 1
max_duration	74.788571
origin_url	https://retro.sx/
passed_cors_access_check	false
pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
pipeline_error	PIPELINE_ERROR_DECODE
pipeline_state	kStopped
player_id	24
range_header_supported	true
render_id	14
seek_target	67
single_origin	true
start_time	0
streaming	false
total_bytes	1835136
url	https://retro.sx/bank/e6/e6e098a2dfef289f2d64f2deaed0c5a1.mp3
====================================================


Is this the same issue? If yes, why?

@enverex, can you check Chrome 66 or 67 and see if this is still an issue?

 Issue 830263  has been merged into this issue.

66 beta seems to work fine. Thanks!

I was just informed by an Ampache user: https://github.com/ampache/ampache/issues/1675


"66 worked for some time, but then exhibits the same problem. Certainly an improvement, but still quite worse than 63."

Chrome 66 still has the same issue.

66 contains a partial fix, bad end of stream packets, 67 just straight up drops bad mp3 packets which was too aggressive to consider merging back.

 Issue 842811  has been merged into this issue.

67 is now stable, so closing this as fixed since mp3 should no longer see issues and AAC error rates are within expectations. Please let me know if you have any media which you think shouldn't throw an error but does in 67+.

Issue(Error) still seen on 10895.16.0, 69.0.3497.29 on all devices.
Use video in comment #1 to repo issue.
Feedback report: 85588319346

@avkodipelli you'll need to provide a link to content that's not playing.

Video uploaded here:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/794782

Ah, see c#5 for that video, you need to update your test clip to conformant file.

new video from #5 is working. Thanks!
Closing this issue.