Is this video edited or remuxed?

It has negative video timestamps which are invalid. We've stopped silently correcting this recently since it leads to a/v sync issues.

I didn't edited it or touch it. It is straight from the camera. I'm not sure how video timestamp becomes negative. How can I check it? 

chrome://media-internals shows an error "unfixable negative timestamp" when that video is played. If you're familiar with ffmpeg tools, you can see this using "ffprobe -show_packets <video> | less" or a similar command.

That's concerning that it's straight off of a camera, we may have to support this workaround even at the cost of a/v sync then. I wonder if the camera wrote an edit list into the clip which is shifting the time negative or if it's an ffmpeg bug.

I used a Synology application for uploading photos and videos and this application generate thumbnails and low resolution videos with PC power and upload them directly to Synology NAS. Maybe this application made some changes to the video files. I will try to make a short video and check with the command from ffmpeg tools you suggested, but it will take some time as I haven't used it. Or if it helps I can share some video via google drive which comes straight from the camera. Thanks.

I am having the same problem. On Chrome 58 the videos directly from the camera no longer play. After the user uploads them we run them through ffmpeg, and everything works fine. 

Our software lets users preview the file locally before uploading it. This functionality is completely broken with this update. We have had to email all of our customers telling them we no longer support Chrome. 

Below is a link to a video file that was taken directly from a Canon Vixia Video Camera and will not play in the Chrome 58 Browser.
https://videocdn.blob.core.windows.net/videos/nonFormattedMetaData.mp4

Thanks will take a look, it seems like we'll have to silently fixup these videos given the number of reports. This likely means there will be av sync issues. I will take a look and see what we can do here.

I analyzed the metadata of these files, and they are different from  issue 715398  where it was clear that the metadata was wrong.

In these three cases (7001A.mp4, MVI_5623.mp4, and nonFormattedMetaData.mp4), the first frame in presentation order is not the first frame in decode order. The metadata (and edit list in particular) correctly record this. However, FFmpeg is reporting that the first frame in decode order is at time 0 (therefore the first frame in presentation order has a negative timestamp).

Example (MVI_5623.mp4):
  Edit list: start time is 40 ms
  # PTS PTS (after edit) FFmpeg reported PTS
  - --- ---------------- -------------------
  1 120  80                0
  2  40   0              -80
  3  80  40              -40
  4 240 200              120
  5 160 120               40
  6 200 160               80
  7 360 320              240
  8 280 240              160

It seems that there is an actual bug here.

Tracked in ffmpeg by https://trac.ffmpeg.org/ticket/6421

Thanks for looking into this! 

I have tested this with many mp4 files coming directly from different video cameras(all were Canon video cameras), none of these files were playable on Chrome until I re-encoded them using ffmpeg.

Any suggestions for a temporary work around? I have an application with paying clients, that allow users to take a video file directly from the camera, preview them, and upload them. With this bug the application is unusable on Chrome. 

We have sent out communication telling the users to use Firefox, or IE for the time being. However, I am strongly hoping to get this taken care of ASAP. Before this bug we urged all of our users to use Chrome because Chrome has the best file upload performance of all the major browsers. 

Thanks!

The only workaround I am aware of here would be to play back using MSE. It's a simple change if the files are small enough to load into memory on the client size, otherwise it's probably easier to transcode.

(I'm not certain that these files meet the requirements of the MSE spec though, so I can't guarantee reliable results there either.)

Dear Chrome team, Good that you found the bug, but while all the affected parties are fixing the format issue. It would be nice if you can still support the viewing, during the transition period.

We are also experiencing the similar problem with latest Chrome v58 and v59 (beta) for files straight from the camera. As of now, we have requested our customer to refrain from Chrome upgrade.

We would really appreciate if you can please share your plan to release the fix for this issue?

I've pinged the ffmpeg ticket for updates. If I don't hear back today we'll likely proceed with a workaround until a fix is available. Keep in mind any workaround will likely cause av sync issues.

 Issue 728787  has been merged into this issue.

FWIW, disabling edit lists in ffmpeg allows all of these files to play; so it's definitely some error in how the edit lists are being applied causing the problems. I wonder if we should just disable edit lists (first enabled on ~Sep 2016, M57 I think.) 

Any news on an ETA for fix in Chrome?  I see ffmpeg bug tracker posted a fix a few days ago.

Unfortunately the version of ffmpeg we have in Chrome right now doesn't have the capabilities described in the bug. I also don't think we'll be able to merge a fix back to M59 in time for stable, but we'll definitely land a fix for M61/M60 shortly though.

OK, what about disabling edit lists in M59 as an interim workaround?  Based on release history I guess that 60/61 are several weeks away from stable channel, right? 

We can't disable edit lists entirely and Chrome 59 does not have the ability to just disable advanced edit lists; only 60+ will have that code.

So we have to see how big of a patch we need to cherry-pick back to 59 which just went stable and is a bit problematic for a bug like this which doesn't have a lot of affected clients. We're still investigating the options though and will update here as we know more.

 Issue 730243  has been merged into this issue.

Is there any way we can detect when this issue is occurring with Javascript? It would be nice to tell the user what is going on, vs showing a broken video player.

The playback will through an error event when this occurs; so if you add an event listener for that you'll receive the event. You could also check the MediaError message: https://www.chromestatus.com/feature/4996058069336064

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

commit 916a8290de5e9e41873282f01e11ffa7606c1531
Author: John Rummell <jrummell@chromium.org>
Date: Thu Jun 08 04:35:03 2017

Workaround for negative PTS values in video files.

In some videos uploaded from cameras, the first frame in presentation order
is not the first frame in decode order. The metadata correctly records this.
However, FFmpeg is adjusting timestamps so that the first frame in decode
order is at time 0. As a result, the first frame in presentation order has
a negative timestamp, which produces an error.

The workaround is to pass "advanced_editlist=0" in the demuxer options.
This avoids the problem until FFmpeg fixes it properly.

BUG= 723537 
TEST=tested locally with example from comment #6 in the bug

Change-Id: I2b515dff06da2930339592ff4e84ec69da635c91
Reviewed-on: https://chromium-review.googlesource.com/526752
Commit-Queue: John Rummell <jrummell@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477887}
[modify] https://crrev.com/916a8290de5e9e41873282f01e11ffa7606c1531/media/filters/ffmpeg_glue.cc

I applied the above workaround on top of Chromium 59.0.3071.86. The example video in this bug report plays fine now, but I'm still seeing playback errors on IMDb. [1]

chrome://media-internals shows the same "unfixable negative timestamp" error. It seems weird that one video works and another doesn't.

If I build Chromium 59.0.3071.86 with its bundled FFmpeg then the IMDb video works; the issue only occurs when using the system FFmpeg (version 3.3.1).

[1] http://www.imdb.com/title/tt5158522/videoplayer/vi327071257

Your system ffmpeg probably isn't new enough to have the option in c#24, that commit came in March 2017:

http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ef71dc7948322254d1f0fa41218b91f2da0279d9

It's not that; we have FFmpeg 3.3.1 in Arch Linux which includes that commit.

Thing is, applying the workaround in Chromium 59 fixes playback for the two example videos in this bug; however, it doesn't fix the IMDb video. I expected that it would, since it shows the same error (and the issue first appeared with Chromium 58).

Are you unable to repro with the example IMDb trailer I linked in my previous comment?

Hmm, that video doesn't trigger a negative timestamp issue in Chrome 58, so it seems like it's failing for some other reason than the root cause of this issue.

We do have a few patches in our mov demuxer that upstream has not taken or fixed:
https://cs.chromium.org/chromium/src/third_party/ffmpeg/chromium/patches/README?l=64

We don't provide support for use_system_ffmpeg, so YMMV with that option unfortunately. The best I can do is to suggest looking over those patches to figure out what the difference is. You might also try building with use_system_ffmpeg and then running media_unittests to track down a more specific failure case.

Fair enough. Just to clarify:

- Chromium 58/59 won't play that IMDb video when using system FFmpeg 3.3+ (haven't tested earlier FFmpeg versions)
- Chromium 58/59 using the bundled FFmpeg has no issue playing the same IMDb video

I will stop commenting now since I understand this issue is about Chrome and the added workaround does fix the test videos on Chromium as well. I guess the IMDb issue I'm seeing is different, even though it results in the same error message.

One more note; the difference seems to be the start time estimates Chrome calculates using internal FFmpeg structures. Problem is, we have to disable that block of code for compiling against the system's FFmpeg. [1]

I have filed  https://crbug.com/731766  if anyone cares to follow up on that.

[1] https://chromium.googlesource.com/chromium/src.git/+/44fbc4d877cf871eb8d736b4c53a05bb11588931%5E%21/

Tested the issue on windows 7, Ubuntu 14.04 and Mac 10.12.6 using chrome version 61.0.3128.0 with the below steps

1. Opened URL https://home.hdhome.sk/photo/?t=Albums/album_32303137/album_323031372f30352e30312044726f7a64696b/video_323031372f30352e30312044726f7a64696b_4d56495f353632332e6d7034#Albums/album_32303137/album_323031372f30352e30312044726f7a64696b/video_323031372f30352e30312044726f7a64696b_4d56495f353632332e6d7034
2.Switched video quality to original
3. Video played fine, not observed any error.

Please find the attached screen cast for the same.
Adding TE-Verified labels.

Thanks, 

Deleted: 723537.mp4 7.9 MB

	723537.mp4 7.9 MB View Download

 Issue 734570  has been merged into this issue.

Requesting merge for 

"Workaround" commit in comment 24
https://chromium.googlesource.com/chromium/src/+/916a8290de5e9e41873282f01e11ffa7606c1531

Which depends on also cherry-picking this ffmpeg change
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=ef71dc7948322254d1f0fa41218b91f2da0279d9;hp=58b867a7cfea914aa6cad858a4da9b7dfeff9546

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

approving merge to M60. 

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

commit 5d4a0ad7502907e15f207a487a4a1e563e5e01b5
Author: Chris Cunningham <chcunningham@chromium.org>
Date: Fri Jun 23 21:28:45 2017

lavf/mov.c: Add -advanced_editlist option for mov format.

Adding an MOV format option to turn on/off the editlist supporting code, introduced in https://github.com/FFmpeg/FFmpeg/commit/ca6cae73db207f17a0d5507609de12842d8f0ca3

Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ef71dc7948322254d1f0fa41218b91f2da0279d9)
Bug:  723537 
Change-Id: I2723eee5714ab7bc8d956b5f7bbc15ec85cfd496
TBR=dalecurtis@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/547039
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>

[modify] https://crrev.com/5d4a0ad7502907e15f207a487a4a1e563e5e01b5/libavformat/isom.h
[modify] https://crrev.com/5d4a0ad7502907e15f207a487a4a1e563e5e01b5/libavformat/mov.c

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/c25e370edd01771ad2815381231c1a3ae564ecc2

commit c25e370edd01771ad2815381231c1a3ae564ecc2
Author: Chris Cunningham <chcunningham@chromium.org>
Date: Fri Jun 23 22:18:38 2017

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

commit 0b47983aa200f52f152b3bb7b751ef78833e2bc9
Author: Chris Cunningham <chcunningham@chromium.org>
Date: Fri Jun 23 22:26:14 2017

Workaround for negative PTS values in video files.

In some videos uploaded from cameras, the first frame in presentation order
is not the first frame in decode order. The metadata correctly records this.
However, FFmpeg is adjusting timestamps so that the first frame in decode
order is at time 0. As a result, the first frame in presentation order has
a negative timestamp, which produces an error.

The workaround is to pass "advanced_editlist=0" in the demuxer options.
This avoids the problem until FFmpeg fixes it properly.

BUG= 723537 
TEST=tested locally with example from comment #6 in the bug

(cherry picked from commit 916a8290de5e9e41873282f01e11ffa7606c1531)
TBR=jrummell@chromium.org

Change-Id: I2b515dff06da2930339592ff4e84ec69da635c91
Reviewed-on: https://chromium-review.googlesource.com/526752
Commit-Queue: John Rummell <jrummell@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#477887}
Reviewed-on: https://chromium-review.googlesource.com/546916
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#457}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/0b47983aa200f52f152b3bb7b751ef78833e2bc9/media/filters/ffmpeg_glue.cc

Workaround merged to m60.

Tested the issue on windows 7, Ubuntu 14.04 and Mac 10.12.6 using chrome version 60.0.3112.50 video played fine without any error.

Please find the attached screen cast for the same.
Adding TE-Verified labels.

Thanks, 

Deleted: 723537.mp4 3.4 MB

	723537.mp4 3.4 MB View Download

Just updated to Chrome 60 and everything is back to normal! Thank you for fixing this! We are glad to be able to support Chrome again.