Summary: | [Mac, iOS] Some media content never reaches full 'loaded' state | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> | ||||
Component: | Media | Assignee: | Brent Fulgham <bfulgham> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | bfulgham, jer.noble, jonlee, ossy, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Brent Fulgham
2014-08-11 14:21:34 PDT
This bug is difficult to reproduce, because it is highly reliant on the media being served. The bug happens because the duration returned by the AVFoundation media engine is getting truncated while being relayed from AVFoundation up to the HTMLMediaElement. This causes the value to be slightly different from the "end point" timestamp registered by AVFoundation for the media in question. When the rounding conditions are just right, the truncated value is rounded down and we never reach 100% loaded. This seems to have been introduced in <http://trac.webkit.org/changeset/169568> The correct solution to this problem is already available in <https://bugs.webkit.org/show_bug.cgi?id=133579>, but is on hold for the time being. To work around the issue, we will do the following: 1. Check if the last played time range value, when cast to a float, matches the duration. 2. If it does, return the duration as this value instead of the slightly-different rounded version. Once completed, instead of this failure case: > v=$0 < <video controls autoplay name="media" style="max-width: 100%; max-height: 100%;">…</video> > v.duration < 25.066667556762695 > v.buffered.end(0) < 25.066666666666666 ... we should see > v.duration < 25.066667556762695 > v.buffered.end(0) < 25.066667556762695 It turns out it's a little easier. We simply have some truncation happening in the MediaPlayerPrivate layer for AVFoundation. Things were already ready to hook up to the double version of these methods, so we can simply start using them and avoid this problem. Created attachment 236419 [details]
Patch
Comment on attachment 236419 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=236419&action=review Looks good! r=me. It's good to see all those narrowPrecisionToFloat() calls gone. > LayoutTests/platform/mac/media/video-seek-past-end-paused-expected.txt:15 > -EXPECTED (mediaElement.currentTime == 'mediaElement.duration'), OBSERVED '6.026666641235352' FAIL > +EXPECTED (mediaElement.currentTime == 'mediaElement.duration'), OBSERVED '6.026666666666666' FAIL Ahh, this is how you know it's working. ;) Committed r172425: <http://trac.webkit.org/changeset/172425> Should we revert this change once the patch for 113579 goes in? (In reply to comment #9) > Should we revert this change once the patch for 113579 goes in? No. I think the changes in that bug cover a lot of the same code, using MediaTime instead of float or double. Once we switch to that version, these changes will be removed as part of that merge. (In reply to comment #8) > Committed r172425: <http://trac.webkit.org/changeset/172425> It broke the Apple Windows build: 1>WebCore.lib(MediaPlayerPrivateAVFoundationCF.obj) : error LNK2001: unresolved external symbol "private: virtual float __thiscall WebCore::MediaPlayerPrivateAVFoundationCF::currentTime(void)const " (?currentTime@MediaPlayerPrivateAVFoundationCF@WebCore@@EBEMXZ) 1>C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\bin32\WebKit.dll : fatal error LNK1120: 1 unresolved externals 1>Done Building Project "C:\cygwin\home\buildbot\slave\win-release\build\Source\WebKit\WebKit.vcxproj\WebKit\WebKit.vcxproj" (Build target(s)) -- FAILED. |