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

VERIFIED FIXED in Firefox 54

Status

()

VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: julienw, Assigned: jya)

Tracking

Trunk
mozilla54
Points:
---

Firefox Tracking Flags

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

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
Flags: needinfo?(jyavenard)
(Reporter)

Comment 1

2 years ago
testcase
Created attachment 8832975 [details]
testcase
(Reporter)

Updated

2 years ago
status-firefox51: --- → ?
status-firefox52: --- → ?
status-firefox53: --- → ?
(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.
(Assignee)

Comment 5

2 years ago
(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.
(Reporter)

Comment 7

2 years ago
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?
(Assignee)

Comment 8

2 years ago
(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
(Assignee)

Comment 9

2 years ago
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)
(Reporter)

Comment 10

2 years ago
(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.
(Assignee)

Comment 11

2 years ago
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 hidden (mozreview-request)

Comment 13

2 years ago
mozreview-review
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)

Comment 15

2 years ago
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/13ce99c3c8af
Treat demuxing errors differently than EOS. r=kinetik
(Reporter)

Comment 16

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

Comment 17

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/13ce99c3c8af
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox54: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
(Assignee)

Updated

2 years ago
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
status-firefox54: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.