1384590 - Firefox 55 beta 12 doesn't buffer videos fully anymore

Status: RESOLVED WONTFIX

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

Description

[alexander.kern]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170616112219

Steps to reproduce:

(0. Disable mediasource extensions in about:config)
1. View any video and pause it. (or if you didn't disable mediasource extensions show a video that doesn't use mediasource extensions)
2. See how long it buffers.


Actual results:

A bit of the video gets buffered, but not all of it. It's about 3 minutes for me mostly I think.


Expected results:

Whole video should buffer like it did in Firefox version 54.

Comment 1

[alexander.kern]

So what actually changed is that these values changed from:

cache_readahead_limit: 999999
cache_resume_threshold: 999999

to

cache_readahead_limit: 60
cache_resume_threshold: 30

I guess it was intentional, but why? I thought it was super convenient to be able to scroll through a video and to have it buffered out until the end so it didn't matter how good my connection to the server was then.

Please reconsider. Thank you for your work.

Comment 2

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to alexander.kern from comment #1)
> I guess it was intentional, but why? I thought it was super convenient to be
> able to scroll through a video and to have it buffered out until the end so
> it didn't matter how good my connection to the server was then.

We limit the amount of pre-buffering on fast connections in bug 1367950. Are you experiencing this issue on a slow connection?

Comment 3

[alexander.kern]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> (In reply to alexander.kern from comment #1)
> > I guess it was intentional, but why? I thought it was super convenient to be
> > able to scroll through a video and to have it buffered out until the end so
> > it didn't matter how good my connection to the server was then.
> 
> We limit the amount of pre-buffering on fast connections in bug 1367950. Are
> you experiencing this issue on a slow connection?

Thanks for your reply. No, I have a fast (enough) connection, I just liked that every video buffered until the end because I can track anywhere and have the video instantly continue. So I wondered why the change at all. But I did a bit of research and I guess it was this issue that led to this change: https://bugzilla.mozilla.org/show_bug.cgi?id=1347174#c37

I never came upon that issue so I'll keep it at a high limit and threshold. I understand the reasoning behind the low values for general users.

This ticket can be closed as far as I am concerned as there seems to be a good reason for this change (which I didn't know of when I added this ticket). Thanks!

Comment 4

[alexander.kern]

Wait, but if it still buffers the whole video if one has a slow connection, wouldn't that possibly lead to the same problem described in https://bugzilla.mozilla.org/show_bug.cgi?id=1347174#c37 that the changed values of cache_readahead_limit and
cache_resume_threshold were supposed to solve?

Comment 5

[alexander.kern]

(In reply to alexander.kern from comment #4)
> Wait, but if it still buffers the whole video if one has a slow connection,
> wouldn't that possibly lead to the same problem described in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1347174#c37 that the changed
> values of cache_readahead_limit and
> cache_resume_threshold were supposed to solve?

OK, no, because the bug deals with something else. This is the actual ticket with the reason why this change happend: https://bugzilla.mozilla.org/show_bug.cgi?id=1085186

Comment 6

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

The whole idea is:
1. We want to buffer a certain amount of data ahead of the current playback position to make playback smooth and avoid playback stalls in buffering.
2. We want to buffer as less as possible but not less to make playback stall. It is a waste of bandwidth to preload more than user needs.

So the design is:
1. When connection is fast, we buffer only 60s ahead which according to our experiment is enough to prevent buffer underflow.
2. When connection is slow, we err on the side of smoothness by buffering as much as possible until the whole cache is full (slow connection is usually unstable, it is hard to predict how much is enough to prevent underflow).

Comment 7

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

(In reply to alexander.kern from comment #1)
> I guess it was intentional, but why? I thought it was super convenient to be
> able to scroll through a video and to have it buffered out until the end so
> it didn't matter how good my connection to the server was then.
We throttle buffering only when connection is fast. When connection is fast, you should experience only little latency when seeking to any position of the whole timeline.

Comment 8

[alexander.kern]

I understand now. Thanks for the explanations! Closing this