[Webkit-unassigned] [Bug 194775] HTMLMediaElement readyState unexpectedly changes to HAVE_FUTURE_DATA

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=194775

Yacine Bandou <bandou.yacine at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bandou.yacine at gmail.com,
                   |                            |olivier.blin at softathome.com

--- Comment #3 from Yacine Bandou <bandou.yacine at gmail.com> ---
(In reply to Serban Ungureanu from comment #2)
> (In reply to Jer Noble from comment #1)
> > From your description, I don't understand what underlying problem you're
> > interested in solving. Is Hulu stalling during playback waiting for the
> > readyState to transition to HAVE_ENOUGH?
> > 
> > Frankly, the entire point of MSE is to allow pages to make sophisticated
> > scheduling, routing, and caching decisions. The UA literally does not have
> > enough information to correctly determine whether playback will be able to
> > continue uninterrupted, as networking decisions are not made by the UA. Hulu
> > (and other sophisticated MSE clients) likely do not even use
> > readyState==HAVE_ENOUGH in their loading decision graph.
> 
> During testing, it appeared that Hulu won't allow seeking or pausing(UI
> would become unresponsive) when HTMLMediaElement.readyState <
> HAVE_ENOUGH_DATA. 
> 
> The observed behavior is that the app appends one 5s segment(two actually,
> one audio and one video) every 5 seconds, but the UA keeps switching the
> readyState between HAVE_ENOUGH and HAVE_FUTURE, which, correct me if I am
> wrong, I believe shouldn't happen.

Could you test this patch ? it should fixes your issue.
https://bug-197834-attachments.webkit.org/attachment.cgi?id=369955

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190523/a604b5ae/attachment-0001.html>