Open Bug 1512611 Opened 2 years ago Updated 22 days ago

HTMLMediaElement's buffered attribute not up to date after finishing fetching media on hypem.com

Categories

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

defect

Tracking

()

Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox69 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix

People

(Reporter: oana.botisan, Unassigned)

Details

(Keywords: parity-chrome, regression)

Attachments

(1 file)

Attached video not buffered.mov
[Affected versions]:
- Nightly 65.0a1
- DevEd 65.0b2
- Firefox 63.0.3

[Affected platforms]:
- Windows 10 x64
- Windows 7 x32
- Ubuntu 18.04
- macOS 10.14

[Steps to reproduce]:
1. Go to: https://hypem.com/artist/filous
2. Play any of the songs.
3. Look at the player that's at the bottom of the page.

[Expected result]:
- The whole song is buffered.

[Actual result]:
- The last portion of the song is not buffered. 

[Regression range]:
- This is a regression. I can't reproduce the issue on Nightly from 2016-01-02. I will try to find a pushlog as soon as possible.

[Additional notes]:
- Please look at the attached video.
- The song still plays in that portion, but if you click on the progress bar nothing happens.
- If the page is refreshed a few times (5-6 times) the problem disappears.
[Regression range]:

- last good build: 2016-08-04 (20160804030441)
- first bad build: 2016-08-05 (20160805030444)
- pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1576e7bc1bec7232e9e4ba78cce62526b1a6380b&tochange=d320ef56876f52db9bc0eb79554c7332d4793769
Component: Video/Audio Controls → Audio/Video: Playback
Product: Toolkit → Core
They are reading this from the `buffered` attribute in the event handler of the "progress" and "suspend" events.

The spec says this:
> Once the entire media resource has been fetched (but potentially before any of it has been decoded)
> 
>     Fire an event named progress at the media element.
> 
>     Set the networkState to NETWORK_IDLE and fire an event named suspend at the media element.


I see this in the log:
> [Child 31511: Main Thread]: D/nsMediaElementEvents 0x103f3c000 Dispatching event progress
> [Child 31511: Main Thread]: D/nsMediaElement 0x103f3c000 Buffered range 0 [0.0,2.0]
> [Child 31511: Main Thread]: D/nsMediaElementEvents 0x103f3c000 Dispatching event suspend
> [Child 31511: Main Thread]: D/nsMediaElement 0x103f3c000 Buffered range 0 [0.0,2.0]

It seems to me that when we're done fetching the data, it should be part of the `buffered` range.

Looking at code it seems that the "progress" and "suspend" events stem from [1], while the `buffered` range is set by [2]. I wonder if the `buffered` range is not updated on the last "progress" because, even though we've finished fetching the resource, we haven't demuxed it yet.
I also wonder whether the intention of the spec is that we should have the guarantee that `buffered` is updated before "progress". I don't see much use of `buffered` if we don't. One would have to resort to polling it then.

jya, do you know what we should expect here?


[1] https://searchfox.org/mozilla-central/rev/adcc169dcf58c2e45ba65c4ed5661d666fc3ac74/dom/media/ChannelMediaResource.cpp#407
[2] https://searchfox.org/mozilla-central/rev/adcc169dcf58c2e45ba65c4ed5661d666fc3ac74/dom/media/MediaFormatReader.cpp#3043
Rank: 15
Flags: needinfo?(jyavenard)
Priority: -- → P2
Summary: On hypem.com the song is partially buffered → HTMLMediaElement's buffered attribute not up to date after finishing fetching media on hypem.com
I don't think the two readyState and networkState are related.

It's even more obvious with MSE, where the buffered range is changed during the coding frame processing algorithm, while the network state is done on the main thread after the appendBuffer call.

The spec also clearly states that the buffered range is "at the time the attribute is evaluated. Users agents must accurately determine the ranges available, even for media streams where this can only be determined by tedious inspection" you can't do that synchronously between fetching the data and parsing it.

Unless we delay the notification and change to networkState only once the MFR has finished parsing the content
Flags: needinfo?(jyavenard)
Perhaps that's what we need to do.

I'm marking this a P3 because the spec is not explicit about this. It does however work in chrome so for webcompat it still makes sense to adapt a bit here.
Keywords: parity-chrome
Rank: 15 → 25
Priority: P2 → P3

I can reproduce this issue using 60.5.2esr on https://www.shutterstock.com/music/genre/Rock.

Reproducible on Mac OS 10.12 in latest Nightly 69.0a1 (2019-06-10)
Build ID 20190610214846
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:69.0) Gecko/20100101 Firefox/69.0

Hi Nils, do you think this can be looked at for 70?

From the pushlog bug 1274626 appears to be the most likely to cause problems in this area.

But I'm not convinced that we really understand the proper the solution here.

jya: is what you described in comment #3 really the solution we should pursue here?
Do we know if this is what Chrome does?

Flags: needinfo?(drno) → needinfo?(jyavenard)

Hi,

I'm able to reproduce this issue using Windows with Firefox version NIghtly 75.0a1 (2020-02-20). Marking that flag as affected.

(In reply to Nils Ohlmeier [:drno] from comment #8)

From the pushlog bug 1274626 appears to be the most likely to cause problems in this area.

But I'm not convinced that we really understand the proper the solution here.

jya: is what you described in comment #3 really the solution we should pursue here?
Do we know if this is what Chrome does?

Clearing my queue.

My earlier comment is a way to change the observable behaviour while still be spec compliant. But we are spec compliant today.

To me it seems to be a site issue, they read the buffered range once, the code could be listening to timechange instead and update the graph as needed.

Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.