[Webkit-unassigned] [Bug 217713] [GTK][WPE] currentTime reported as NaN shortly after seeking for MSE playback

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Alicia Boya García <aboya at igalia.com> ---
Thank you very much for such a very complete bug report.

(In reply to sycy700 from comment #0)
> There is similar code in Chromium. Not sure if the code below is responsible
> that this issue cannot be reproduced using Chromium, but one difference is
> that when there are no ranges available, then 0.0 is returned instead of
> invalidTime for the 'nearest' function.
> 
> https://github.com/chromium/chromium/blob/
> 2420378bc7c24eee30c48455f0c54aa4c7390aa2/third_party/blink/renderer/core/
> html/media/html_media_element.cc#L2095
> 
> void HTMLMediaElement::Seek(double time) {
> ...
> time = seekable_ranges.Nearest(time, now);

This is not entirely accurate. While Nearest() in Chromium will indeed return 0.0 in this case, that is not actually relevant because the function returns early in the case where there are no seekable ranges:

void HTMLMediaElement::Seek(double time) {
  [...]
  if (seekable_ranges.empty()) {
    seeking_ = false;
    return;
  }
  time = seekable_ranges.Nearest(time, now);

The proposed solution of setting time to zero in the case where there are not seekable ranges is not ideal because it discards the previously requested seek time, and it just happens that it's zero in this case.

I assume the empty seekable ranges is a consequence of not yet knowing the duration of the media (which changes after either setting it manually or when parsing the media). Some things I wonder at the moment are:

I still wonder how come a seek is allowed to happen before there were any seekable ranges.

-- 
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/20201029/697599c5/attachment-0001.htm>