Issue metadata
Sign in to add a comment
|
some mp4 files no longer play
Reported by
matt.hea...@trumedianetworks.com,
May 11 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: Certain mp4 videos that worked in the prior version no longer work. Here is a fiddle with a reduced case: https://jsfiddle.net/4w0a20ae/4/ What is the expected behavior? Video should play What went wrong? Video no longer plays with version 58 stable. Did this work before? Yes 57 Does this work in other browsers? Yes Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.11.6 Flash Version:
,
May 12 2017
Able to reproduce the issue on Windows 10, mac 10.12.4 and Ubuntu 14.04 using chrome reported version #58.0.3029.110 and latest canary #60.0.3095.5. Bisect Information: ===================== Good build: 58.0.3014.0 Revision(450840) Bad Build : 58.0.3015.0 Revision(451180) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/1dd4ccf354c3286647e35ed6e02c36de695901fc..25d15671d9766d5f3cb87b7f5ff810cca5b130e9 From the above change log suspecting below change Review url: https://codereview.chromium.org/2699563002 dalecurtis@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Thanks...!!
,
May 12 2017
No more planned M58 releases, please have a fix for M59.
,
May 15 2017
Dupe of issue 715398 then, please remux the container to avoid negative timestamps; see command line recommendations on the linked bug. These are not valid in an mp4 container.
,
May 15 2017
#4 - but if other browsers accept them, perhaps Chrome should, too.
,
May 15 2017
We tend to take a strict approach to this since out of spec issues like this can lead to security problems. We also don't want to be in the habit of maintaining workarounds for the long term. Also workarounds may have unintended consequences, i.e. in this case working around the negative timestamps has av/sync implications. Are we supposed to rebase timestamps to zero; but what if audio is already starting from time zero? Are we just supposed to drop the negative ts video packets?
,
May 16 2017
#6 - in that case, can you talk to other vendors in order to see whether they are planning on taking your stricter approach about this specific issue? Interoperability makes the platform predictable, which is more important than not maintaining workarounds (I understand the security factor here, but the other vendors probably understand that as well). A small explainer/specification on GitHub would be nice to have to document this behavior and differences (and other vendors can document the answers to your questions in that repository, which makes it easier for you to implement those workarounds, if needed). |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, May 11 2017Labels: -Pri-2 Needs-Bisect Needs-Triage-M58 Pri-1