1511607 - media.suspend-bkgnd-video.enabled breaks HLS

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Audio/Video, defect, P2)

Description

[csheany]

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0

Steps to reproduce:

1. Open https://adultswim.com/streams
2. Play the video
3. Switch to a different tab
4. Return to the original


Actual results:

The video is paused.


Expected results:

To be determined.

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Alastor, would you mind taking a first look at this? Is this unexpected behavior?

Comment 2

[Alastor Wu [:alwu]]

Because of decoding error, the video can't continue playing. I found that this HLS video doesn't allow seeking, we would get error once we're trying to seek (like suspend-video-decoding do).

This issue can be eaily reproduced when you're trying to seek this video (because they block seeking from control interace, I seeked video from web console). However, I am not sure this seeking error is because the resource site provides is non-seekable or we didn't handle HLS seeking well in our HLS demuxer/HLSDecoder.

---

Hi, John, do you have any idea about that?
Thank you!

Comment 3

[John Lin [:jhlin][:jolin]]

Yes, the seek request was rejected because the souce is a live stream, which is considered unseekable. However, in this case it is an internal request to support null video decoder rather than actual seek from user/player. Since the demuxer/exoplayer still fetches data in this state, I will try making HLSDemuxer::IsSeekableOnlyInBufferedRanges() returns true and see if that could fix the problem.

Comment 4

[csheany]

Thank you for looking into it.

Has there been discussion about flipping the default pref value as it is not immmediately user facing?

Is the reason messages along the lines of "video can't be played because the file is corrupt" and "no video with supported format and mime type found" aren't displayed due to the fact it doesn't use the native controls?

Comment 5

[John Lin [:jhlin][:jolin]]

I suppose we could just add an additional check to whether the media is seekable and prevent entering suspend mode when not.

Comment 6

[csheany]

Would that defeat the purpose of the setting?

Comment 7

[John Lin [:jhlin][:jolin]]

(In reply to csheany from comment #6)
> Would that defeat the purpose of the setting?

Not really, IMHO. There are several other cases that affects video suspend mode behavior regardless of the pref. See dependent bugs of 1352007.

Comment 8

[csheany]

Is it easier to shut down the decoding when necessary as opposed to the other way adound?

Comment 9

[John Lin [:jhlin][:jolin]]

Attachment: Bug 1511607 - don't suspend background video decoding for unseekable media. r?jya!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/516feba2e8cd
don't suspend background video decoding for unseekable media. r=jya

Comment 11

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/516feba2e8cd

Comment 12

[csheany]

Would your original suggestion help with performance while the tab is in the foreground?

Comment 13

[John Lin [:jhlin][:jolin]]

(In reply to csheany from comment #12)
> Would your original suggestion help with performance while the tab is in the
> foreground?

I don't think so. It looks like IsSeekableOnlyInBufferedRanges() was added only to support seeking for cue-less WebM files and is not quite suitable for determining whether video decoding can be suspended or not.

Comment 14

[csheany]

What do you think would prevent interruptions from seeking attempts?

Comment 15

[Sorina Florean [:sflorean]]

I was able to reproduce this issue on an affected build of Nightly and I can confirm the fix on latest Nightly build from 01-02-2019 using Huawei Honor 8 (Android 7.0). 

@csheany do you confirm as well? Thanks

Comment 16

[csheany]

It seems to be working for me as well.