1334508 - Video doesn't play, makes Firefox take a lot of CPU in autoplay

Status: VERIFIED FIXED

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

Description

[Julien Wajsberg [:julienw]]

STR:
1. Open http://codingschool.fr

This video is playing in background: http://codingschool.fr//front/media/videos/home_background.webm

It is in autoplay and loop, but the video bugs in Firefox. As a result it seems Firefox loops over and over and takes 100% of my CPU.

The video plays fine in Chrome, mplayer.

Same thing happens in Release 51, Aurora 52, Nightly latest. On Linux.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: testcase

Comment 2

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> Created attachment 8832975 [details]
> testcase

It also takes 100% CPU when you play home_background.webm only.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

[MediaPlayback #2]: D/MediaDecoder Decoder=7f6190be7400 state=COMPLETED Changed state to SEEKING (to 0)
[MediaPlayback #2]: D/MediaDecoder Decoder=7f6190be7400 state=COMPLETED change state to: SEEKING
[MediaPlayback #2]: D/MediaDecoder Decoder=7f6190be7400 StopPlayback()
[MediaPlayback #2]: D/MediaDecoder Decoder=7f6190be7400 Changed mNextFrameStatus to NEXT_FRAME_UNAVAILABLE_SEEKING
[MediaPlayback #2]: D/MediaDecoder Decoder=7f6190be7400 MediaDecoderStateMachine::Reset
[MediaPlayback #3]: D/MediaDecoder Decoder=7f6190be7400 state=SEEKING Seek completed, mCurrentPosition=0
[MediaPlayback #3]: D/MediaDecoder Decoder=7f6190be7400 state=SEEKING change state to: DECODING
[MediaPlayback #3]: D/MediaDecoder Decoder=7f6190be7400 state=DECODING change state to: COMPLETED
[MediaPlayback #3]: D/MediaDecoder Decoder=7f6190be7400 Changed mNextFrameStatus to NEXT_FRAME_AVAILABLE
[MediaPlayback #3]: D/MediaDecoder Decoder=7f6190be7400 MaybeStartPlayback() starting playback

I see lots of seeking logs. There should be something wrong to the webm decoder.

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

More logs:

[MediaPlayback #2]: D/MediaSample Decoder=7fbe57ae3400 OnAudioNotDecoded aError=2154692616
[MediaPlayback #2]: D/MediaSample Decoder=7fbe57ae3400 OnVideoNotDecoded aError=2154692616

2154692616=NS_ERROR_DOM_MEDIA_END_OF_STREAM

EOS is returned when decoding first audio/video samples. It looks like the webm decoder concludes there are no audio/video samples at all.

Comment 5

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #4)
> More logs:
> 
> [MediaPlayback #2]: D/MediaSample Decoder=7fbe57ae3400 OnAudioNotDecoded
> aError=2154692616
> [MediaPlayback #2]: D/MediaSample Decoder=7fbe57ae3400 OnVideoNotDecoded
> aError=2154692616
> 
> 2154692616=NS_ERROR_DOM_MEDIA_END_OF_STREAM
> 
> EOS is returned when decoding first audio/video samples. It looks like the
> webm decoder concludes there are no audio/video samples at all.

why would the decoder continue to attempt to demux it then?
if you get EOS, the MediaDecoder/MediaDecoderStateMachine should stop attempt to decode

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Jean-Yves Avenard [:jya] from comment #5)
> why would the decoder continue to attempt to demux it then?
> if you get EOS, the MediaDecoder/MediaDecoderStateMachine should stop
> attempt to decode

Because |<video src="home_background.webm" autoplay loop></video>|.
The "loop" attribute keeps seeking to 0 over and over again.

Comment 7

[Julien Wajsberg [:julienw]]

I think there are 2 questions here:

1. Why the video is not working here, while it's working in Chrome and other players.
2. Why is it looping again and again while it's obvious it's either broken or empty. Is the behavior the same with an empty valid webm file?

Comment 8

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #2)
> (In reply to Julien Wajsberg [:julienw] from comment #1)
> > Created attachment 8832975 [details]
> > testcase
> 
> It also takes 100% CPU when you play home_background.webm only.

I can't reproduce this however, when playing just the webm file, there's no CPU increase, it settle fairly quickly

Comment 9

[Jean-Yves Avenard [:jya]]

The first sample has a negative timestamp, this is specifically forbidden in the mkv/webm standard.
Timecode is an unsigned integer https://www.matroska.org/technical/specs/index.html#Cluster

:kinetic, this is not the first time this issue has come around... We refuse to play those files as they aren't per spec.

Should we relax the rules.

Comment 10

[Julien Wajsberg [:julienw]]

(In reply to Jean-Yves Avenard [:jya] from comment #8)
> (In reply to JW Wang [:jwwang] [:jw_wang] from comment #2)
> > (In reply to Julien Wajsberg [:julienw] from comment #1)
> > > Created attachment 8832975 [details]
> > > testcase
> > 
> > It also takes 100% CPU when you play home_background.webm only.
> 
> I can't reproduce this however, when playing just the webm file, there's no
> CPU increase, it settle fairly quickly

I think he meant that in my testcase there are 2 videos (the fualty webm and a working mp4) and he tried the same one with only the faulty webm.

Comment 11

[Jean-Yves Avenard [:jya]]

i think the core issue we have here, is that the WebM demuxer makes no difference between a genuine EOS and encountering an error....

i guess it should

Comment 12

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1334508: Treat demuxing errors differently than EOS.

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

Comment 13

[Matthew Gregan [:kinetik]]

Comment on attachment 8838979 [details]
Bug 1334508: Treat demuxing errors differently than EOS.

https://reviewboard.mozilla.org/r/113738/#review115296

Comment 14

[Matthew Gregan [:kinetik]]

(In reply to Jean-Yves Avenard [:jya] from comment #9)
> The first sample has a negative timestamp, this is specifically forbidden in
> the mkv/webm standard.
> Timecode is an unsigned integer
> https://www.matroska.org/technical/specs/index.html#Cluster
> 
> :kinetic, this is not the first time this issue has come around... We refuse
> to play those files as they aren't per spec.

That's bug 868797.

> Should we relax the rules.

No idea.  But if we do, it'd be best if that error recovery behaviour was specified somewhere, maybe in the spec via CELLAR (https://datatracker.ietf.org/wg/cellar/charter/).

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/13ce99c3c8af
Treat demuxing errors differently than EOS. r=kinetik

Comment 16

[Julien Wajsberg [:julienw]]

May I suggest to output something in the Web Console in case we detect an error while demuxing or playing the file ?

Comment 17

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/13ce99c3c8af

Comment 18

[Emil Ghitta, QA [:emilghitta]]

I’ve reproduced the issue described in comment 0 using Firefox 52.0 (Build Id:20170302120751) and verified that the issue is not reproducible anymore using Firefox 54.0b2 (Build Id:  20170424145525) on Windows 10 64bit, macOs 10.11.6 and Ubuntu 14.04 64bit.