873775 - Firefox won't start playing webm videos until the complete video is downloaded/cached

Status: RESOLVED DUPLICATE of bug 868797

(Core :: Audio/Video, defect)

Description

[robin]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20100101 Firefox/10.0.12 Iceweasel/10.0.12 (Beta/Release)
Build ID: 20130108232239

Steps to reproduce:

Open webm video from http://lac.linuxaudio.org/2013/video.php?id=78
or any webm at http://lac.linuxaudio.org/2013/recordings/

with 
* Nighly 24.0a1 (2013-05-17) Linux 32bit
* Firefox 21.0 Linux 32bit
* Iceweasel (10.0.12 from debian/jessie)


Actual results:

Video does not start playing until the complete video is downloaded or cached.


Expected results:

The video playback should start immediatley.

It does so with other browsers (e.g. chromium, epiphany khtml, safari,...).

Additional info:
It might be similar to https://bugzilla.mozilla.org/show_bug.cgi?id=502894#c1

The server side (apache 2.2.22) seems OK:
Content-Type is OK (video/webm), apache answers FF's Range: bytes 0- request with a 206,...
However firefox simply continues to wait for the download to complete rather start playing.

HTML5 video element syntax also looks OK -- but it seems irrelevant: The issue is also present if the video file is played directly without HTML.
The videos were encoded with ffmpeg and they play just fine (also when HTTP streamed) with other browsers, VLC, ffplay as well as mplayer. It all points towards some HTTP connection/buffering issue with Firefox.

Comment 1

[Matthew Gregan [:kinetik]]

This looks like a variant of bug 868797:

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

Note that the first two blocks have negative timestamps, which is prohibited by the spec.  See bug 868797 comment 8.

Do you know which tool was used to produce the WebM files?

Comment 2

[robin]

Thanks!

I think the files were encoded with ffmpeg (actually avconv from debian) -- but I'll ask the stream-team.

I was able to fix things with 
  ffmpeg -i <input_file> -codec copy -avoid_negative_ts 1 <output_file>
(using ffmpeg 1.2) just now.

I suppose this resolves this issue.
Though it might be prudent if firefox could handle these issues gracefully.

Comment 3

[robin]

The files were created with gstreamer/fluendo (from debian, not the ffbmc-fork).

Anyway, I'll leave it to you guys to decide what Firefox should do in case it encounters negative timestamps -- but that's a different issue.

I'll close this bug since it's not a firefox bug after all.
Thanks again.

Comment 4

[Matthew Gregan [:kinetik]]

Thanks!

I'll mark it as a dupe of bug 868797, and make that about negative timestamp handling.