Bug 135814 – [Mac, iOS] Some media content never reaches full 'loaded' state

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Brent Fulgham]

Some <media> sources, including certain advertisements, cause pages to get stuck loading because they never achieve a full loaded state.

[Brent Fulgham]

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.

[Brent Fulgham]

<rdar://problem/17476923>

[Brent Fulgham]

This seems to have been introduced in <http://trac.webkit.org/changeset/169568>

[Brent Fulgham]

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

[Brent Fulgham]

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.

[Brent Fulgham]

Created attachment 236419 [details]
Patch

[Jer Noble]

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. ;)

[Brent Fulgham]

Committed r172425: <http://trac.webkit.org/changeset/172425>

[Jon Lee]

Should we revert this change once the patch for 113579 goes in?

[Brent Fulgham]

(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.

[Csaba Osztrogonác]

(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.