Add public method to MediaTime for doing timeScale conversion.
Created attachment 302718 [details] Patch
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
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
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?
Or maybe PlatformAudioData should own its time as CMTime for Mac
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 "*"
(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.
(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>
Created attachment 302842 [details] Patch for landing
Committed r213068: <http://trac.webkit.org/changeset/213068>