WebM video won't play in Firefox

[John Pompeii]

Hi,

I'm trying to solve an issue with the libvpx (or libvpx-vp9) codec and was looking for some guidance.  I'm writing a web application that can play customer-uploaded videos, of various formats, in a "preview" fashion.  We're using ffmpeg to do this and for chrome and firefox, we're converting the video source to webm so that we can use the html5 video tag to play the video.  I have a particular issue when the source is a flash video (flv), the converted video will play in chrome but firefox reports that the video stream is corrupt.  Using the same command arguments in avconv, the video plays fine in FF, however the performance is not good enough to make the switch to avconv.  The problem is that I have no idea what FF is finding wrong with the video.  I've used ffprobe, ffmpeg, and avconv to read the file in debug mode (and addding strict options, etc) to see if there is any warnings about the file, but nothing is reported.  Oddly, even if I convert the file first to mp4 and then to webm, FF still reports the file as corrupt so there must be something about the encoding from a flash source that is troubling it. 

Can anyone recommend a tool or technique I can use to figure out what is wrong with the video file (or what FF is complaining about).  Outside of trying to compile FF myself and debug the browser itself, I'm out of ideas.

Any recommendations would be most appreciated!

thanks,

--john

for reference, here's the command line:

ffmpeg -y -loglevel info -i TearsHeaven.flv -c:v libvpx -c:a libopus -deadline good -cpu-used 5 -f webm output2.webm

I'm running the latest (12/2015) build of ffmpeg on 64 bit windows

[Ralph Giles]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/12/15 02:34 PM, John Pompeii wrote:

> Can anyone recommend a tool or technique I can use to figure out
> what is wrong with the video file (or what FF is complaining
> about). Outside of trying to compile FF myself and debug the
> browser itself, I'm out of ideas.

If you run firefox from the commandline, it may print useful warnings
to the console.

Otherwise, can you share a link to a video which demonstrates the proble
m?

-r

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWha4HAAoJEEcAD3uxRB3vLckIAJAoFl+yYFXpggBZXp1mUBq5
uErLPxIM+UzqBixGVUT8FU8OJ4oKYcxEPnbN2JMZ464YacXI1SX+5GX56H1dSm9M
vg5P8AdW2DMk3Zk8/iOvBpO27bWKrX81Fgg4fJ2e2AWXMEtX0OiELmtF+t3TdUhd
GXLHgNrRAaaq2xkNFZk/HusVQXW6gliBgGvY0tXfNcBLcucvDVJbdqgb0kqWCtTC
o9DBYsMljBTOxlbxl5W72iWCTV0x3oCK92DD6jbuQGAY9d8F472SNoSVGwbiQqeA
/8HYX3QYhQUW/dmuaieAlmfZX7NWaTOJVs8qtJE+DD/pNn9Av9kpzSigoLExes4=
=FV8B
-----END PGP SIGNATURE-----

[John Pompeii]

Thanks for the reply Ralph,

I tried the command line quickly and didn't see anything, but i'll to see if there are some debug command line options I can set.  Thanks for the suggestion

Here is a link to the source flash video: https://drive.google.com/file/d/0B3A47kEO8U-tT0szQjNLWnkxcWc/view?usp=sharing

And here is a link to the output: https://drive.google.com/file/d/0B3A47kEO8U-tekRacGthWkxBR1E/view?usp=sharing

They are about 10M each.

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To post to this group, send email to webm-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webm-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Ralph Giles]

On 2015-12-31 3:14 PM, John Pompeii wrote:

> And here is a link to the
> output:https://drive.google.com/file/d/0B3A47kEO8U-tekRacGthWkxBR1E/view?usp=sharing

Loading this in a debug build of Firefox I get:

[Child 688] WARNING: Invalid Opus header: CodecDelay and pre-skip do not
match!: file
/Users/giles/firefox/dom/media/platforms/agnostic/OpusDecoder.cpp, line 76
[Child 688] WARNING: Setting start time on reader failed: file
/Users/giles/firefox/dom/media/MediaDecoderStateMachine.cpp, line 1938

So looks like this is an ffmpeg bug (and a Chrome bug for accepting the
invalid header).

The failing check is currently at
https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/agnostic/OpusDecoder.cpp#74

Adding some debug logging I see that codecDelay here is 6500 µs, while
preskip is 156 frames, or 3250 µs at 48 kHz. That's off by a factor of
two. The Opus header also says the original input was 24 kHz audio,
which is likely where the incorrect factor of two is coming from. The
WebM codecDelay element should be in nanoseconds, and pre-skip should be
in samples at 48 kHz. If the file works after resampling the audio in
the input flv to 48 kHz that's the problem.

-r

[John Pompeii]

Thanks a bunch Ralph.  I'll work with that and see if that takes care of it.   BTW,  I take it that you are working with a version FF that you built yourself and added debugging code to?

Thanks again for going to all that trouble.  That would have taken me a couple of days easily to do on my own.

Cheers,

--john

[Ralph Giles]

On 2015-12-31 4:41 PM, John Pompeii wrote:

> I take it that you are working with a version FF that you
> built yourself and added debugging code to?

That's right. Firefox has a logging mechanism, with particular streams
enabled through the NSPR_LOG_MODULES=LogDomain:level[,...] environment
variable.

So I added the logging call in the attached patch, and then did:

./mach build
NSPR_LOG_MODULES=PlatformDecoderModule:5,MediaDecoder:5 ./mach run
~/Downloads/TearsHeaven.webm

on the terminal command line inside my normal firefox checkout from
https://github.com/mozilla/gecko-dev

The logging works on any debug build. You can download snapshots from
the mozilla-central-*-debug directories at
https://archive.mozilla.org/pub/firefox/tinderbox-builds/ ...which is
easier than building firefox yourself if you don't want to work on the code.

Glad the analysis was helpful, and Happy New Year!

-r

[John Pompeii]

Thanks Ralph for the details and Happy New Year to you too.  Those details are extremely helpful as I'm sure this wont be the last time I have to track something like this down.

As you suspected, after resampling the audio to 44.1K, the file converted fine to webm/opus.  I also did the conversion using the vorbis audio codec instead of opus and that worked fine as well.  Since the bug shows up in ffmpeg but not in avconv, its possible that its been fixed or is specific to ffmpeg, but I'll get it reported to the ffmpeg and opus projects.

thanks again for all your help.  Especially on a holiday!

Cheers,

--john

 -r

[Brendan Bolles]

On Friday, January 1, 2016 at 7:09:23 PM UTC-8, John Pompeii wrote:

As you suspected, after resampling the audio to 44.1K, the file converted fine to webm/opus.  I also did the conversion using the vorbis audio codec instead of opus and that worked fine as well.

Opus in WebM (Matroska) should always be 48 kHz.

https://wiki.xiph.org/MatroskaOpus

Vorbis can be any sampling rate.