David Highley Reporter
	Description • 11 years ago

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.

	Loic
	Comment 1 • 11 years ago

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

	David Highley Reporter
	Comment 2 • 11 years ago

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.

	Loic
	Comment 3 • 11 years ago

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

	David Highley Reporter
	Comment 4 • 11 years ago

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.

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 5 • 11 years ago

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

	Matthew Gregan [:kinetik]
	Comment 6 • 11 years ago

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.

	David Highley Reporter
	Comment 7 • 11 years ago

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

	Matthew Gregan [:kinetik]
	Comment 8 • 11 years ago

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."

	David Highley Reporter
	Comment 9 • 11 years ago

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.

	David Highley Reporter
	Comment 10 • 11 years ago

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>

	Matthew Gregan [:kinetik]
	Comment 12 • 11 years ago

There's related discussion in bug 873775.

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

	Nicholas Iannone
	Comment 13 • 11 years ago

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.

	Matthew Gregan [:kinetik]
	Comment 16 • 10 years ago

(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.

	Jim Mathies [:jimm]
	Comment 17 • 9 years ago

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.

	Matthew Gregan [:kinetik]
	Comment 18 • 9 years ago

(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.

	Jim Mathies [:jimm]
	Comment 19 • 9 years ago

Should this bug be marked resolved WONTFIX then?

	:glob ✱
	Comment 27 • 7 years ago

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?

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 28 • 7 years ago

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

	:glob ✱
	Comment 29 • 7 years ago

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

	Matthew Gregan [:kinetik]
	Comment 30 • 7 years ago

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.

	Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail Assignee
	Comment 32 • 6 years ago

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.

	:glob ✱
	Comment 34 • 6 years ago

sorry i got distracted - thanks bryce!

	Matthew Gregan [:kinetik]
	Comment 35 • 6 years ago
mozreview-review

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

	Pulsebot
	Comment 36 • 6 years ago

Pushed by bvandyk@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dd94760baaf5
Update libnestegg to be more tolerant of blocks with negative timecodes. r=kinetik

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 37 • 6 years ago
bugherder

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