Bug 168860 – Add public method to MediaTime for doing timeScale conversion.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jer Noble]

Add public method to MediaTime for doing timeScale conversion.

[Jer Noble]

Created attachment 302718 [details]
Patch

[Build Bot]

Comment on attachment 302718 [details]
Patch

Attachment 302718 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/3189326

New failing tests:
media/modern-media-controls/macos-fullscreen-media-controls/macos-fullscreen-media-controls-drag.html
media/modern-media-controls/macos-fullscreen-media-controls/macos-fullscreen-media-controls-drag-is-prevented-over-button.html

[Build Bot]

Created attachment 302735 [details]
Archive of layout-test-results from ews115 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-elcapitan  Platform: Mac OS X 10.11.6

[youenn fablet]

Comment on attachment 302718 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=302718&action=review

> Source/WTF/ChangeLog:9
> +        will be used when converting to a new time scale.

This seems fine, although two tests are failing.

The broader question I have is whether MediaTime abstraction is the best approach here.
For the mac platform, we are probably going from CMTime to MediaTime and (I am guessing) back to CMTime.
If so, maybe we would be better using something like a PlatformMediaTime wrapping a CMTime (and maybe a MediaTime for GTK) instead of directly using a MediaTime?

[youenn fablet]

Or maybe PlatformAudioData should own its time as CMTime for Mac

[Eric Carlson]

Comment on attachment 302718 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=302718&action=review

> Source/WTF/wtf/MediaTime.cpp:530
> +        if (static_cast<int64_t>(llabs(remainder))*2 >= static_cast<int64_t>(timeScale)) {

Nit: spaces around the "*"

[Jer Noble]

(In reply to comment #4)
> Comment on attachment 302718 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=302718&action=review
> 
> > Source/WTF/ChangeLog:9
> > +        will be used when converting to a new time scale.
> 
> This seems fine, although two tests are failing.
> 
> The broader question I have is whether MediaTime abstraction is the best
> approach here.
> For the mac platform, we are probably going from CMTime to MediaTime and (I
> am guessing) back to CMTime.
> If so, maybe we would be better using something like a PlatformMediaTime
> wrapping a CMTime (and maybe a MediaTime for GTK) instead of directly using
> a MediaTime?

No. MediaTime is very heavily used in the MSE codebase. Adding an extra indirection + soft link dispatch for every time operation would be unacceptably slow. And then every port would need to re-invent their own rational time class which would look, in the end, exactly the same as MediaTime. There's no practical benefit.

[Jer Noble]

(In reply to comment #7)
> (In reply to comment #4)
> > Comment on attachment 302718 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=302718&action=review
> > 
> > > Source/WTF/ChangeLog:9
> > > +        will be used when converting to a new time scale.
> > 
> > This seems fine, although two tests are failing.

Those tests have been flaky for a while: <https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#tests=media%2Fmodern-media-controls%2Fmacos-fullscreen-media-controls%2Fmacos-fullscreen-media-controls-drag.html>

[Jer Noble]

Created attachment 302842 [details]
Patch for landing

[Jer Noble]

Committed r213068: <http://trac.webkit.org/changeset/213068>