Some HTML5 video elements of mp4s fail to load
Reported by
tk.fo...@gmail.com,
Aug 31 2017
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce the problem:
1. Load the following static pages, one at a time:
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
<video controls>
<source src="https://d2yqgtswku371j.cloudfront.net/VID2016/04/19/3482930/3482930L/3458A.mp4" type="video/mp4"/>
</video>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
<video controls>
<source src="https://d2yqgtswku371j.cloudfront.net/VID2016/04/19/3482930/3482930L/3459A.mp4" type="video/mp4"/>
</video>
</body>
</html>
What is the expected behavior?
Both videos load properly.
What went wrong?
The second video loads metadata but doesn't load data itself, and so is unplayable. It doesn't signal any errors, either.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 60.0.3112.113 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 26.0 r0
These videos are representative of a larger sample of videos. These two in particular were created in the same manner within seconds of each other and have been handled similarly since creation. Firefox handles both of these videos fine.
,
Aug 31 2017
Confirmed using Chrome 60 on Windows 7 Enterprise. From chrome:media-internals - 00:00:00 73 debug FFmpegDemuxer: unfixable negative timestamp 00:00:00 73 error FFmpegDemuxer: demuxer error: 13 00:00:00 73 pipeline_error DEMUXER_ERROR_COULD_NOT_PARSE
,
Aug 31 2017
Hmm, we fixed a related issue in m60, issue 723537 . I suspect the root cause is the same, but if it's not an edit list I'm not sure how we're ending up with negative timestamps here.
,
Aug 31 2017
These files are invalid: $ MP4Box -info 3458A.mp4 [iso file] Unknown box type alis ICC colour profile not supported [iso file] Unknown box type alis [iso file] Unknown box type wave [iso file] Box "frma" is invalid in container wave [iso file] Read Box "mp4a" failed (Invalid IsoMedia File) - skipping [iso file] Unknown box type urat [iso file] Unknown box type wide $ MP4Box -info 3459A.mp4 [iso file] Unknown box type alis ICC colour profile not supported [iso file] Unknown box type alis [iso file] Unknown box type wave [iso file] Box "frma" is invalid in container wave [iso file] Read Box "mp4a" failed (Invalid IsoMedia File) - skipping [iso file] Unknown box type urat [iso file] Unknown box type wide Definitely negative timestamps are not allowed. If you are clipping these from a stream using ffmpeg, ensure you are setting -avoid_negative_ts make_zero. =>sandersd for confirmation that they're invalid, but the various mp4 validation tools I have won't even open these - so this is likely WontFix.
,
Aug 31 2017
I don't know how they're being clipped (or not), but it wouldn't surprise me if it's done poorly and inconsistently. We couldn't find these particular problems in our investigation though, so thanks so much for investigating as well.
,
Sep 1 2017
#5 - Using BrowserStack, looks like all of the browsers except Chrome can easily handle those invalid files. I do not think Chrome should be the odd one out. If you do think this more strict decoding makes sense, perhaps file issues about it in issue trackers of the other browsers. Those things should be aligned and interoperable.
,
Sep 6 2017
I didn't find anything horribly wrong with the timestamps. The edits are unusual, but not invalid.
3458A.mp4:
- Audio is 20ms longer than the movie.
An edit crops the first 16ms, leaving 4ms also cropped at the end.
- Video consistently uses SAP Type 2 sync samples.
First PTS is 33ms, but the edit crops at 41ms.
The edit duration is 64ms longer than the track.
3459A.mp4:
- The same but with different numbers.
If we're seeing negative timestamps, something is going wrong in FFmpeg.
,
Sep 7 2017
Okay, might be worth retesting with the updated ffmpeg that has isasi@'s fixes in it; though I thought those were only for advanced edit lists.
,
Sep 7 2017
I tested with ffmpeg-git as of today, and the issue is still present. The first few video packets of 3458A.mp4 are reported as: [PACKET] pts=0 pts_time=0.000000 dts=-3003 dts_time=-0.100100 [/PACKET] [PACKET] pts=-2002 pts_time=-0.066733 dts=-2002 dts_time=-0.066733 [/PACKET] [PACKET] pts=-1001 pts_time=-0.033367 dts=-1001 dts_time=-0.033367 [/PACKET] [PACKET] pts=3003 pts_time=0.100100 dts=0 dts_time=0.000000 [/PACKET] This is consistent with shifting the first packet to PTS time 0, but that is incorrect behavior for SAP Type 2 (in this case, the shift should be such that the second packet has PTS time 0). That said, audio has the same problem, but no SAP Type 2: [PACKET] pts=-752 pts_time=-0.015667 dts=-752 dts_time=-0.015667 [/PACKET] [PACKET] pts=272 pts_time=0.005667 dts=272 dts_time=0.005667 [/PACKET] [PACKET] pts=1296 pts_time=0.027000 dts=1296 dts_time=0.027000 [/PACKET] [PACKET] pts=2320 pts_time=0.048333 dts=2320 dts_time=0.048333 [/PACKET]
,
Sep 11 2017
Update: FFmpeg Git now returns the expected timestamps (and discard flags) for these files. There are a few steps to fixing the issue in Chrome, but they are all in-progress: - FFmpeg roll to include the latest edit list handling code. - Re-enable advanced edit list support now that they are correct. (Disabled here: https://bugs.chromium.org/p/chromium/issues/detail?id=723537) - Implement dropping of frames marked for discard.
,
Oct 24 2017
Fixed in 5341599c0b2b5a74f62a7734d592d7faae9983c8. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by nyerramilli@chromium.org
, Aug 31 2017