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

VERIFIED FIXED in Firefox 54

Status

()

defect
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: julienw, Assigned: jya)

Tracking

Trunk
mozilla54
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51 ?, firefox52 ?, firefox53 ?, firefox54 verified)

Details

Attachments

(2 attachments)

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.
Flags: needinfo?(jyavenard)
Posted file testcase
(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.
[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.
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.
(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
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
(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.
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?
(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
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.
Flags: needinfo?(kinetik)
(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.
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 on attachment 8838979 [details]
Bug 1334508: Treat demuxing errors differently than EOS.

https://reviewboard.mozilla.org/r/113738/#review115296
Attachment #8838979 - Flags: review?(kinetik) → review+
(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/).
Flags: needinfo?(kinetik)
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/13ce99c3c8af
Treat demuxing errors differently than EOS. r=kinetik
May I suggest to output something in the Web Console in case we detect an error while demuxing or playing the file ?
https://hg.mozilla.org/mozilla-central/rev/13ce99c3c8af
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Depends on: 1347538
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.