New issue
Advanced search Search tips

Issue 871214 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 9
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

MPEG-DASH / HLS Stream Stops Playing at Specific Time

Reported by dev.adia...@gmail.com, Aug 6

Issue description

Chrome Version       : 67.0.3396.99 (Official Build) (Problem since 64)
Other browsers tested:
     Safari: OK
    Firefox: OK
       Edge: OK

What steps will reproduce the problem?
(1) Try to play video file https://content-s02.adia.tv/chrome-issue.mp4

The problem occurs when trying to play:
MPEG-DASH: https://dv01c5ty3bvah.cloudfront.net/cdn2/_definst_/chrome-issue.mp4/manifest.mpd
HLS: https://dv01c5ty3bvah.cloudfront.net/cdn2/_definst_/chrome-issue.mp4/playlist.m3u8

To test those, we used:
http://reference.dashif.org/dash.js/v2.9.0/samples/dash-if-reference-player/index.html
https://video-dev.github.io/hls.js/demo/

What is the expected result?
Video should play normally

What happens instead?
Video stops playing around 21 second mark


Please provide any additional information below. Attach a screenshot if
possible.

Error with the DASH player is:
MEDIA_ERR_DECODE (PIPELINE_ERROR_DECODE: Failed to send audio packet for decoding: timestamp=22245011 duration=45986 size=612 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0))

Error with the HLS player is:
The video playback was aborted due to a corruption problem or because the video used features your browser did not support - PIPELINE_ERROR_DECODE: Failed to send audio packet for decoding: timestamp=22244671 duration=46439 size=612 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0)

MP4 file is recorded from Wowza server (live RTMP stream pushed from FMLE). Download: https://content-s02.adia.tv/downloads/files/chrome-issue.mp4

Wowza Version: 4.7.5.02
Also tested 4.7.6 -> same behaviour.

 
I should add that I also tested this in Canary 70.0.3514.0 (Official Build) canary (64-bit) (cohort: Clang-64), and the same problem exists.
Labels: Needs-Triage-M67
Components: Internals>Media
Cc: vamshi.kommuri@chromium.org
Labels: Needs-Bisect Triaged-ET
Status: Untriaged (was: Unconfirmed)
Thanks for filing the issue!

Able to reproduce the issue on reported chrome version  67.0.3396.99 using Mac 10.13.1, as the issue isn't seen in M60(60.0.3112.0) considering it as Regression and marking it as Untriaged. 
Note: Will soon update the bisect info.
Labels: -Type-Bug -Pri-3 -Needs-Bisect hasbisect-per-revision Target-68 RegressedIn-64 Target-69 Target-70 M-70 FoundIn-70 FoundIn-68 FoundIn-69 OS-Linux OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: dalecur...@chromium.org
Status: Assigned (was: Untriaged)
++Issue is seen on the latest canary 70.0.3516.0 too, using Windows 10, Ubuntu 14.04

Bisect Information:
-------------------
Good Build: 64.0.3257.0
Bad Build:  64.0.3258.0

You are probably looking for a change made after 513689 (known good), but no later than 513690 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/7642e1c5fc5715dc1894eaf828ef85ae0a5d1fb7..9f57237995f7921b4dcd8855f1f6fe98874218d2
Suspecting: https://chromium.googlesource.com/chromium/src/+/9f57237995f7921b4dcd8855f1f6fe98874218d2
Review URL: https://chromium-review.googlesource.com/738626

@Dale Curtis: Please help in assigning it to the right owner if this is not related to your change.

Thanks!
Labels: -Pri-1 -Target-68 -Target-69 -Target-70 -M-70 -Needs-Triage-M67 Pri-3
This is due to becoming stricter about bad aac content. I'll take a look later today, but 99% of the time this has been due to incorrect aac encoding. See  issue 794782 .
Status: WontFix (was: Assigned)
ffmpeg spits out the following:

[aac @ 0x91d280] env_facs_q 252 is invalid
[aac @ 0x91d280] Input buffer exhausted before END element found
Error while decoding stream #0:1: Invalid data found when processing input

Which seems to come from here:
https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavcodec/aacsbr_template.c?l=853

Which AFAICT is conformant with the spec which states these values are < 2**7 == 128.
The command I used:

$ ffmpeg -i chrome-issue.mp4 -vn -f wav -y /dev/null


$ ffmpeg -version
ffmpeg version N-91560-g476fd6ba3a Copyright (c) 2000-2018 the FFmpeg developers
built with clang version 7.0.0 (trunk 338452)
configuration: --enable-shared --enable-nonfree --enable-gpl --cc=clang --ld=clang --enable-libvpx --enable-libopus --disable-hwaccels
libavutil      56. 18.102 / 56. 18.102
libavcodec     58. 22.100 / 58. 22.100
libavformat    58. 17.101 / 58. 17.101
libavdevice    58.  4.101 / 58.  4.101
libavfilter     7. 26.100 /  7. 26.100
libswscale      5.  2.100 /  5.  2.100
libswresample   3.  2.100 /  3.  2.100
libpostproc    55.  2.100 / 55.  2.100


Sign in to add a comment