868797 - nestegg rejects WebM blocks with negative timestamps

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[David Highley]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130401133302

Steps to reproduce:

Constructed an HTML5 web page with a video tag. When I try to play the video it jumps to the end of the video. If you slide the progress tab back you see the video. If you take it all the way to the beginning it jumps to the end. If you stop short of the beginning and then click play it plays the video. Using Firefox 20.0 on Fedora 18 x86_64 platform.
http://www.highley-recommended.com/Atlantis/index.html



Expected results:

This page works correctly with the Chrome browser. Have run the page through the W3C validator and checked several other sites for a miss implemented page issue. Constructed the video using the Openshot video editor and used it's presets for webm.

Could be the reported 777648 issue but the symptoms do not seem to match.

Comment 1

[Loic]

Could you fix the page/server, the video doesn't start.

Comment 2

[David Highley]

Did you press the play button? The page has a script that disables auto play. Just to make sure it was not the issue I have tested with it commented out.

Comment 3

[Loic]

Yes, I clicked the play button but the network is really slow.

Comment 4

[David Highley]

It is business Comcast 11Mb up 54Mb down have streamed to cellphones, but tricky and the built in players codec support sucks. The pictures on the page do slow the page load time.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

The network is too slow for me to play the video.

David: Do you see the same behaviour on other pages? For example this one:
http://people.mozilla.com/~cpearce/buffered-demo.html

Comment 6

[Matthew Gregan [:kinetik]]

mkvinfo reports the first two blocks have negative timestamps:

|+ Cluster
| + Cluster timecode: 0.000s
| + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = -00:00:00.003)
|  + Frame with size 1
| + SimpleBlock (key, track number 2, 1 frame(s), timecode 18446744027.136s = -00:00:00.002)
|  + Frame with size 1
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000)

We should report a decoder error in this situation instead of silently treating this as an end of media condition.

Comment 7

[David Highley]

I see that now that you gave a reference to this tool set and ran ebml_validator against the file and it never complains.

Comment 8

[Matthew Gregan [:kinetik]]

Nor does mkvalidator, but the spec notes seem clear that negative absolute/raw timecodes are invalid:

Under "Block Timecodes" here: http://matroska.org/technical/specs/notes.html

"The quick eye will notice that if a Cluster's Timecode is set to zero, it is possible to have Blocks with a negative Raw Timecode. Blocks with a negative Raw Timecode are not valid."

Comment 9

[David Highley]

I see references around Oct 2012 for patching ffmpeg in reference to Firefox. But when I search their bug reports I'm not finding a reference so I'm not able to tell if it has been fixed. I have to assume not with the results created.

Comment 10

[David Highley]

Found a fairly painless fix for this issue. The following command will fix the negative time code issue without going through a demux remux transcode process so it is quick.

ffmpeg -i <input_file> -codec copy -avoid_negative_ts 1 <output_file>

Comment 12

[Matthew Gregan [:kinetik]]

There's related discussion in bug 873775.

I'll morph this bug into discussion about Firefox's handling of negative timestamps.

Comment 13

[Nicholas Iannone]

Confirming reproduction on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0, Build ID: 20130618035212

Also, the FFmpeg fix mentioned above (https://bugzilla.mozilla.org/show_bug.cgi?id=868797#c10) worked for me, as well. My team is now setting up a batch script to automate cleanup of affected files from our vast collection of WebM video files. I recommend all others afflicted with this issue do the same.

Comment 16

[Matthew Gregan [:kinetik]]

(In reply to David Highley from comment #9)
> I see references around Oct 2012 for patching ffmpeg in reference to
> Firefox. But when I search their bug reports I'm not finding a reference so
> I'm not able to tell if it has been fixed. I have to assume not with the
> results created.

The change you're talking about is: http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=b08273c9ca8b91d03133f9fbef100bbd3cd8e271 which corresponds to FFmpeg 1.1 aka libavformat 54.59.106.

Comment 17

[Jim Mathies [:jimm]]

This is still an issue with video produced by the latest version of Miro. Are we not going to compensate for this? Note Chrome has no issue with these videos. This bug has been around for almost two years now.

Comment 18

[Matthew Gregan [:kinetik]]

(In reply to Jim Mathies [:jimm] from comment #17)
> This is still an issue with video produced by the latest version of Miro.
> Are we not going to compensate for this? Note Chrome has no issue with these
> videos. 

File a bug against Miro if there isn't one already.  What are they using to produce the media, ffmpeg?  It should be as simple as upgrading to the fixed version if so.

> This bug has been around for almost two years now.

It has *always* been this way in Firefox.  We never supported this because it's invalid, per the Matroska/WebM specs.

Comment 19

[Jim Mathies [:jimm]]

Should this bug be marked resolved WONTFIX then?

Comment 27

[:glob ✱]

given how many duplicates this bug has, and that most other players will play negatively timestamped webms without issue (chrome, mpv, mpc, vlc, etc), is it worth considering a more relaxed approach to playback when negative timestamps are encountered?

Comment 28

[Chris Pearce [:cpearce (Not reading bugmail)]]

Given that Chrome have given up enforcing Google's constraints, we may as well to.

Comment 29

[:glob ✱]

kinetik, with https://github.com/kinetiknz/nestegg/pull/51 merged what's the next step to get this into firefox?

Comment 30

[Matthew Gregan [:kinetik]]

With an up-to-date checkout of Gecko and nestegg (use master, you also need to pick up https://github.com/kinetiknz/nestegg/commit/4acb171d4838924ae7b6ba824e69d4f7cd9eb578), cd into gecko/media/libnestegg and run |update.sh /path/to/nestegg|, then follow the usual steps to post a patch for review on this bug.

Comment 32

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Mind if I grab this, :glob? I've run into another dupe of this, and have done the nestegg dance before, so I think I should be able to get this over the line.

Comment 33

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 868797 - Update libnestegg to be more tolerant of blocks with negative timecodes.

Bump nestegg to commit 89ed0daf2edccb25f744e5faff88b8b4684adceb. This brings
across tolerance of blocks with negative timecodes. Instead of rejecting these
the timecodes are now set to 0.

Also brings across a change to appease clang in ne_read_block_additions by
adding an explicit assignment to data_size.

Review commit: https://reviewboard.mozilla.org/r/224116/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/224116/

Comment 34

[:glob ✱]

sorry i got distracted - thanks bryce!

Comment 35

[Matthew Gregan [:kinetik]]

Comment on attachment 8954942 [details]
Bug 868797 - Update libnestegg to be more tolerant of blocks with negative timecodes.

https://reviewboard.mozilla.org/r/224116/#review231072

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dd94760baaf5
Update libnestegg to be more tolerant of blocks with negative timecodes. r=kinetik

Comment 37

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/dd94760baaf5