[Webkit-unassigned] [Bug 52697] New: Frame accurate seeking isn't always accurate

[bugzilla-daemon at webkit.org]

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

           Summary: Frame accurate seeking isn't always accurate
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
               URL: http://www.massive-interactive.nl/html5_video/smpte_te
                    st_universal.html
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Media Elements
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: coenen.rob at gmail.com


Please see this testcase that shows Safari is not always seeking to the correct frame when attempting frame accurate seeking. 
The testcase is in the bug URL. 
Chrome had a similar bug and fixed it:
http://code.google.com/p/chromium/issues/detail?id=69499.  We should fix it too.

Using the single step "|> +1 frame" button, each click should advance by one frame, and the time in the top right of the video frame should match the computed time beside it in the surrounding content.
(Try frame stepping to 00:00:00:13, the calculated timecode is correctly 00:00:00:13 but the burned-in timecode shows that the frame is stuck at 00:00:00:12 2x then on the netx click bth burned in and calculated timecodes jump to 00:00:00:14. Frame 00:00:00:13 gets never shown)

The testcase uses MP4, WebM, and Ogg.  I can reproduce the bug with the H264 file.

When single stepping, we seem to be 1 or 2 frames off the expected time.  One frame of this is caused by bugs in the seeking logic.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.