Issue metadata
Sign in to add a comment
|
Video will not play when hardware acceleration is enabled
Reported by
janus.z...@gmail.com,
Mar 10 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Example URL: See attachment Steps to reproduce the problem: 1. Download the attachment 2. Open the file in Chrome on OS X with Hardware acceleration enabled 3. Play What is the expected behavior? The video should play. What went wrong? There are two cases: 1) There is a video error being thrown. Checking chrome://media-internals shows 00:00:00 04 video_decoder GpuVideoDecoder 00:00:00 04 pipeline_state kPlaying 00:00:00 05 error video decode error 00:00:00 05 pipeline_error pipeline: decode error 2) The video does not play, but no error is thrown. The current player state is playing: 00:00:00 28 video_decoder GpuVideoDecoder 00:00:00 28 pipeline_state kPlaying Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 48.0.2564.116 Channel: stable OS Version: OS X 10.11.1 Flash Version: Shockwave Flash 21.0 r0 To reproduce, simply drag the attached file in a Chrome tab. Also tested in other browsers cross platform: Windows: Chrome, Chrome Canary, Firefox, Edge, IE, Opera, Vivaldi play the file without issue. OS X: Chrome, Chrome Canary show the behaviour described in this report, Firefox, Safari, Opera and Vivaldi do not show this issue. Android: Chrome plays the file without issue. I also checked with other video players such as VLC and Quicktime, but they do not seem to have any issues. FFMPEG does provide a warning in the console: No pixel format specified, yuvj420p for H.264 encoding chosen.
,
Mar 10 2016
I can track this bug back to chrome 43 build. This is not a recent regression. It only repro on H/W decoding on Mac. It not repro on windows H/W decoding. Dan, can you take a look?
,
Mar 11 2016
Able to reproduce the issue on Mac 10.11.3 using chrome version 49.0.2623.87 and canary 51.0.2673.0.This is regression issue broken in M42. Please find the bisect information as below Narrow Bisect:: Good:: 42.0.2276.0 -- (official build 311451) Bad:: 42.0.2278.0 -- (official build 311861) Unable to provide the tool bisect as the video file not playing on invoked chromium.Hence providing manual CL from omahaproxy Change Log:: https://chromium.googlesource.com/chromium/src/+log/42.0.2277.0..42.0.2278.0?pretty=fuller&n=10000 Possible suspect from the above CL https://codereview.chromium.org/857433002 Removing the bisect label,please feel free to add if required.
,
Mar 11 2016
Based on comment#3 removing "Needs-Bisect"
,
Mar 11 2016
Based on my offline Chat with sandersd@ this is duplicate of issue#585452 , hence marking the bug accordingly.
,
Mar 14 2016
Not a duplicate unfortunately. Please review the attached file. This file has all trailing zeros removed behind the AUD, SPS, PPS and SEI-nals. The same behaviour as the original bug report is still in effect.
,
Mar 14 2016
Still looks like a dup to me, the updated mp4 still has zeros in the avcC atom, which is what triggers the behavior. (The entries in the avcC atom are turned into NALUs by the Annex B converter in Chromium.)
,
Mar 15 2016
Awesome, I can confirm removing the trailing zeros from the PPS and SPS in the avcC atom stops Chrome from crashing. Thank you for spotting this last issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Mar 10 2016