Firefox can not play some WebM videos generated by avconv on Trusty

[Mossroy]

Steps to reproduce :
- Download the source H.264 video attached to this bug
- On a Trusty machine, convert this video to WebM with "avconv -i P5270914.MOV P5270914-trusty.webm". It should give the same result as attached
- Open this webm file in Totem or in VLC : it plays correctly
- Open this webm file in Firefox 29. When you click on play, it goes directly to the end and does not show anything
- Open this same webm file in Chromium (tested with version 34) : it plays correctly

If you generate the WebM file on Precise, with the same command-line, it plays correctly in Firefox (see attached P5270914-precise.webm).
So I suppose it comes from a difference in the way avconv does the conversion, that is not correctly supported by Firefox

All tests are made with Precise and Trusty amd64, with all current updates.
Firefox version 29.0 on both
avconv 9.13-0ubuntu0.14.04.1 on Trusty, and 0.8.10-0ubuntu0.12.04.1 on Precise

[Mossroy (mossroy)]

Mkvinfo for the WebM file generated on Trusty :
$ mkvinfo P5270914-trusty.webm
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: webm
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 217051
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 163)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: Lavf54.20.4
| + Writing application: Lavf54.20.4
| + Segment UID: 0x3e 0x93 0xba 0x8b 0xfd 0xdf 0xd6 0xff 0xd9 0x02 0xc0 0xaa 0xbd 0x1a 0x95 0xd2
| + Duration: 4.772s (00:00:04.772)
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Lacing flag: 0
| + Language: eng
| + Codec ID: V_VP8
| + Track type: video
| + Default duration: 0.033ms (30000.300 frames/fields per second for a video track)
| + Video track
| + Pixel width: 1920
| + Pixel height: 1080
| + Display width: 1920
| + Display height: 1080
| + Display unit: 3 (aspect ratio)
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 2
| + Lacing flag: 0
| + Language: eng
| + Codec ID: A_VORBIS
| + Track type: audio
| + Audio track
| + Channels: 2
| + Sampling frequency: 48000
| + Bit depth: 32
| + CodecPrivate, length 3949
|+ Cluster

[Mossroy (mossroy)]

Mkvinfo for the WebM file generated on Precise :
$ mkvinfo P5270914-precise.webm
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: webm
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 222861
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 163)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: Lavf53.21.1
| + Writing application: Lavf53.21.1
| + Segment UID:0xc5 0xb6 0x30 0xdf 0xf7 0x71 0xf0 0xbd 0x47 0xf5 0x85 0x4b 0x4f 0x26 0x45 0xdc
| + Duration: 4.772s (00:00:04.772)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Lacing flag: 0
| + Language: eng
| + Codec ID: V_VP8
| + Track type: video
| + Default duration: 33.367ms (29.970 fps for a video track)
| + Video track
| + Pixel width: 1920
| + Pixel height: 1080
| + Display width: 1920
| + Display height: 1080
| + Display unit: 3
| + A track
| + Track number: 2
| + Track UID: 2
| + Lacing flag: 0
| + Language: eng
| + Codec ID: A_VORBIS
| + Track type: audio
| + Audio track
| + Channels: 2
| + Sampling frequency: 48000
| + Bit depth: 16
| + CodecPrivate, length 3949
|+ Cluster

[Mossroy (mossroy)]

The mkvinfo outputs show a difference in the "Default Duration" field, which seems to be incorrect on Trusty.
I tried to force it, by adding a "-r 29.970" parameter to avconv : the field's value is modified but still different from Precise, and the video does not play better

[Mossroy (mossroy)]

I found this bug report on Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=868797
It might be related, but I don't think it's the same issue : manually sliding the video in the middle does not make it play.
The workaround they propose is for ffmpeg, and does not seem to work on avconv : "unrecognized option 'avoid_negative_ts'"

[Daniel Letzeisen (dtl131)]

Just to be sure I read this right, you're saying that the file generated in Precise plays okay?
If not, make sure you have gstreamer0.10-plugins-bad installed on your Trusty install: http://www.webmproject.org/tools/

[Mossroy (mossroy)]

Yes, you got it right : the file generated in Precise plays ok in Firefox (on Precise, Trusty, Windows, Android etc). You can try by yourself by clicking on the attachment.
But the file generated in Trusty does not play on Firefox (at least on Trusty), even if it does in Totem, VLC, and Chromium. You can also try the attachment.

I forgot to mention that the video codec is VP8, and audio codec is Vorbis

[Mossroy (mossroy)]

The package gstreamer0.10-plugins-bad is installed in version 0.10.23-7.2ubuntu1.
But I thought the webm implementation of Firefox was built in Firefox itself (because it's a free codec), and that gstreamer was used only for h.264 videos (due to patent issues) ?

[Mossroy (mossroy)]

I tested to convert my video with ffmpeg instead of libav.
For that, I installed ffmpeg (version 1.2.6-1~trusty1) from this PPA : ppa:jon-severinsson/ffmpeg , on Trusty

The result is attached, and works correctly with Firefox.

So this gives at least a workaround on Trusty

$ mkvinfo P5270914-trusty-ffmpeg.webm
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: webm
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 271445
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 163)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: Lavf54.63.104
| + Writing application: Lavf54.63.104
| + Segment UID: 0x86 0xd8 0xad 0xa2 0x7d 0x9b 0xb3 0x23 0x7d 0x91 0x40 0x58 0xe7 0x22 0xb6 0x78
| + Duration: 4.775s (00:00:04.775)
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Lacing flag: 0
| + Language: eng
| + Codec ID: V_VP8
| + Track type: video
| + Default duration: 33.367ms (29.970 frames/fields per second for a video track)
| + Video track
| + Pixel width: 1920
| + Pixel height: 1080
| + Display width: 1920
| + Display height: 1080
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 2
| + Lacing flag: 0
| + Language: eng
| + Codec ID: A_VORBIS
| + Track type: audio
| + Audio track
| + Channels: 2
| + Sampling frequency: 48000
| + Bit depth: 32
| + CodecPrivate, length 3951
|+ Cluster

[Erlenmayr (erlenmayr)]

Same here with a lot of videos. Upstream avconv seems to work as well as ffmpeg.

[Mossroy (mossroy)]

I tested the WebM file generated on Trusty with Firefox 27.0.1 and 29.0.1 on Windows 7 : same behavior. It can not be played, whereas the file generated on Precise can be played fine.
Maybe I should report this issue on bugzilla.mozilla.org?

[Mossroy (mossroy)]

Created attachment 8432087
P5270914-trusty.webm

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428193813

Steps to reproduce:

Open the attached WebM video file with Firefox

Actual results:

The video does not play at all : the cursor seems to jump at the end.
Seeking anywhere inside the video does not help.
This same file can be played without issues on Chromium, VLC and Totem (on Ubuntu)

See original bug report on Ubuntu : https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1323822

Expected results:

Either the file is "corrupted" in the sense that it does not comply to the expected format. In this case, I would expect to have an error message somewhere.
Either it is correct, and it should be played by Firefox.

[Mossroy (mossroy)]

Here is the mkvinfo of the attached file :

$ mkvinfo P5270914-trusty.webm
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: webm
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 217051
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 163)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: Lavf54.20.4
| + Writing application: Lavf54.20.4
| + Segment UID: 0x3e 0x93 0xba 0x8b 0xfd 0xdf 0xd6 0xff 0xd9 0x02 0xc0 0xaa 0xbd 0x1a 0x95 0xd2
| + Duration: 4.772s (00:00:04.772)
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Lacing flag: 0
| + Language: eng
| + Codec ID: V_VP8
| + Track type: video
| + Default duration: 0.033ms (30000.300 frames/fields per second for a video track)
| + Video track
| + Pixel width: 1920
| + Pixel height: 1080
| + Display width: 1920
| + Display height: 1080
| + Display unit: 3 (aspect ratio)
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 2
| + Lacing flag: 0
| + Language: eng
| + Codec ID: A_VORBIS
| + Track type: audio
| + Audio track
| + Channels: 2
| + Sampling frequency: 48000
| + Bit depth: 32
| + CodecPrivate, length 3949
|+ Cluster

Please notice that the "default duration" value seems strange to me

[Mossroy (mossroy)]

Please note that this video has been generated with libav 9.13-0ubuntu0.14.04.1 on Ubuntu Trusty, by converting from a H.264 source video. It can be reproduced very easily with other source videos.
When converting with some other versions of libav (at least the one of Ubuntu Precise), or the latest version of ffmpeg, the generated video file can be played by Firefox.
See the details on Launchpad issue.

So it looks like a "misunderstanding" between this libav version and Firefox.
Maybe there is an issue in libav itself.
I created this issue on Buzilla because the video works on several other implementations, and because the issue is the same with Firefox on W7 (not ubuntu-specific)

[Mossroy (mossroy)]

As the issue in the same with Firefox on W7, and this video works well on other implementations, I've created an issue upstream for Firefox, on bugzilla : https://bugzilla.mozilla.org/show_bug.cgi?id=1018579

In any case, it looks like this version of libav generates something Firefox dislikes. So maybe the fix could come from libav itself.
I don't know if the generated file conforms to the vp8/webm specs or not

[Daniel Letzeisen (dtl131)]

Possibly relevant: https://code.google.com/p/chromium/issues/detail?id=130313
Default duration is not used anymore, so newer avconv may not bother setting it to a valid value.
Of course, if FIrefox still expects that value to be valid, it could cause problems..

[Mossroy (mossroy)]

After a few tests, I suspect the issue might come from the audio track.

If I encode without the audio track :
avconv -i P5270914.MOV -an P5270914-trusty-no-audio.webm

It gives me the attached file, and it plays fine on Firefox

When comparing both mkvinfo (the ones generated with libav, on Precise and Trusty), you can notice that the audio track has a different bit depth (32 vs 16).
Maybe the header bit depth could not correspond to the actual bit depth of the track, or something similar?

[Mossroy (mossroy)]

And if I remove the video instead of the audio (-vn option instead of -an), it does not play either and "jumps" to the end of the stram.
I tried to tweak the libvorbis options on bitrate and quality values, but it does not seem to make any difference.

I also tried to manually modify the header properties with mkvpropedit, but it always seems to delete both audio and video tracks in the header, giving a file considered corrupted by Firefox (but still playable on Totem, VLC and Chromium... It looks like these players are less dependent on the mkv header)

[Paul-silaghi (paul-silaghi)]

Reproduced in 32.0a1 (2014-06-01), win 7 x64.
Works in Chrome.

[Mossroy (mossroy)]

For what it's worth, if it might help somebody :

As a temporary workaround before this issue is fixed, I succesfully use Docker (http://packages.ubuntu.com/trusty/docker.io) to convert my videos in an isolated environment.
I prefer not to install ffmpeg or upgrade libav through PPAs on my main system (Some other applications depend on libav and I don't want to break them), and it's a very lightweight solution compared to starting a complete virtual machine.

I used a Trusty image provided by the official repo of Docker (https://index.docker.io/_/ubuntu/) and configured the ffmpeg PPA in it.
After commiting my modified image (called trusty-ffmpeg below), I can run the conversion with a command-line like :
sudo docker run -i -t -v /home/mossroy/Videos:/host trusty-ffmpeg ffmpeg -i /host/P5270914.MOV /host/P5270914-trusty-docker.webm
(note that I use the -v option to map the path of my video to a /host directory inside the docker container)

It gives the same result as https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1323822/+attachment/4121477/+files/P5270914-trusty-ffmpeg.webm , which works properly in Firefox.
It did not notice the docker performance overhead, so it works really well for me

[Kevin Shenk (batonac)]

As this is fixed in libav upstream, it is possible to fix webm files on trusty using a libav update PPA:
https://launchpad.net/~motumedia/+archive/libav10-trusty

After enabling the PPA and updating libav, you can use this command to fix the webm files:
avconv -i input.webm -codec copy output.webm

[Zefling-r (zefling-r)]

I have same problem with my MP4 encoded on Ubuntu 14.04 :
http://ikilote.net/Galeries/Autres/Divers/test_20140627.mp4
http://ikilote.net/Galeries/Autres/Divers/test_20140627.webm

(Webm works in Chrome, but MP4 works without sound, all are unplayable in Firefox)

[Erlenmayr (erlenmayr)]

Dudes this is obviously an avconv bug, not a Firefox bug. New avconv and ffmpeg work. You cannot fix Firefox to play corrupt video files, only because VLC is tolerant. avconv should create clean and valid files, such that we know that they work on all WebM players including mobile devices.

[Erlenmayr (erlenmayr)]

@zefling-r:

Which audo encoder does your avconv select? As far as I know there are several available in Ubuntu repos, including libfdk-aac, libvo-aac and faac.

[Mossroy (mossroy)]

@erlenmayr:
I don't know the WebM/Ogg/VP8 specifications enough to say if the file is "corrupt" or not.
You might be right. And it's true that VLC is more permissive than many other players.
But the file also does play correctly with Totem and Chromium. So which software is buggy did not seem that obvious to me, unless we can say if this file complies to its specs or not.
That's why I opened the bug for both Firefox and avconv.

[Daniel Letzeisen (dtl131)]

If it is fixed in libav, then it would be nice if someone would link to the commit that fixed it.

[Mossroy (mossroy)]

I found 2 bug reports on upstream libav that seem to be related :
https://bugzilla.libav.org/show_bug.cgi?id=597
https://bugzilla.libav.org/show_bug.cgi?id=341
At least the symptom seems to be the same.
Both are fixed in Libav 9.14, by commit https://github.com/libav/libav/commit/9455a023be9f3915ccf5511a0b8fdb5b8897b2b6
This has been commited between versions 9.13 (the one currently packaged for Trusty) and 9.14

So it would be worth trying with libav 9.14.
Unfortunately, this version does not seem to be compiled for Trusty in https://launchpad.net/~motumedia/+archive/ubuntu/libav-daily
Do you know an easy way to make this test? (I mean, without compiling it manually)

[Mossroy (mossroy)]

I did not find any libav 9.14 package for Ubuntu (any version), so I finally compiled it myself on Trusty, from mainstream source.
After converting the source video with the same command-line, it outputs the attached webm file, which works correctly in Firefox.

In order to check that the issue did not come from the patches of Ubuntu (or the compilation options I used), I also compiled version 9.13 from source, and reproduced the issue in Firefox.

So version 9.14 of libav solves the issue.
It's certainly the same issue as in the libav bugtracker mentioned above : a bug in libav that makes it generate corrupt webm files.

Would it be possible to upgrade libav to 9.14 in Trusty?

[Mossroy (mossroy)]

@dtl131 : it looks like the commit 9455a023be9f3915ccf5511a0b8fdb5b8897b2b6 (in libav) is probably the one that fixes the issue

[Mossroy (mossroy)]

It looks like it's related to a libav bug. See https://bugzilla.libav.org/show_bug.cgi?id=597 and https://bugzilla.libav.org/show_bug.cgi?id=341
It has been fixed in libav between versions 9.13 and 9.14.

So it looks like Firefox is less permissive than Gstreamer, Chromium and VLC on WebM files...

In any case, could Firefox output an error message in such cases, instead of silently failing?

[Mossroy (mossroy)]

@erlenmayr: it looks like you were right :-)

[Daniel Letzeisen (dtl131)]

If you feel the update is important enough, you can request SRU: https://wiki.ubuntu.com/StableReleaseUpdates

[Mossroy (mossroy)]

I also compiled version 9.13 patched with commit 9455a023be9f3915ccf5511a0b8fdb5b8897b2b6 : the output video works in Firefox.

So it's now sure that this commit is the one that fixes the issue.
If upgrading to 9.14 is not possible, backporting the patch would also work.

[Mossroy (mossroy)]

I did not have the time to make the SRU : version 9.14 has just been deployed on Ubuntu Trusty, for security reasons : see https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1341216

I checked the webm conversions : problem solved :-)

[Mossroy (mossroy)]

For the record, Trusty now generates a correct webm file (see attached video)

[Erlenmayr (erlenmayr)]

@Mossroy: I posted in May already that upstream avconv fixes the issue.

Thanks for your work, it finally works now. :)

[Mossroy (mossroy)]

I close this bug as invalid.
I still believe Firefox should improve the user feedback in such cases, but it was a bug in libav, not in Firefox