481213 - Support Frame Accurate Seeking and Display

Status: VERIFIED WORKSFORME

(Core :: Audio/Video, defect)

Description

[michael dale]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090227 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090227 Minefield/3.2a1pre

The video tag should support frame accurate seeking and update the video display accordingly. This is critical for interactive video applications. 

Reproducible: Always

Steps to Reproduce:
1.Load a video in the video tag where the video is paused. 
2.Attempt to seek by setting the currentTime to +33ms or: 
$('v1').currentTime += .033
Actual Results:  
On first 33ms increment request the video seeks to 1 second in (on the tested video). Subsequently either the currentTime is not affected by the +.033 request or it seeks anywhere from 160ms to 1000ms forward in the stream.

Expected Results:  
The video should only seek 33ms forward in time and serve the next frame. (If 33ms forward results in a new frame) 

To fix this we first need to fix bug 463358 because even if it was advancing time properly the video rendered on a non-keyframe seek is very ugly.

I imagine since bug 463358 necessitates lead in key frame decode we should keep the frame accurate seeking bug in mind. That the key frame lead-in decode can work without throwing away that computation info and subsequent sequential frame serve requests work quickly.

Comment 1

[michael dale]

Attachment: frame advance html test with 33ms buttons

frame advance html test with 33ms buttons (the same html test file used in other bugs such as bug 463358 .. just added 33ms seek buttons

Comment 2

[michael dale]

also see j^'s http://people.xiph.org/~wiking/framegrabber.html

Comment 3

[diaa.abdelmoneim]

Seeking back in time doesn't work at all for me. It continues loading without working. I don't know if I should post this elsewhere but if this seeking feature is implemented it would make life easier.

Comment 4

[michael dale]

Looking at the frame advance html sample html. What we really need is currentTime +=33ms to not result in an ugly frame.  

Perhaps a simple fix /workaround/ could be added that if the delta of currentTime is less than say 100ms we just advance the playhead to that time without issuing a seek and avoid destroying the frame output with ugly lack of key-frame lead in decode?

Comment 5

[Christopher Blizzard (:blizzard)]

I would actually prefer that we have support for actual nextFrame/prevFrame - gets rid of the nasty time hacks.  (We might support something other than the current fps as well?)

Comment 6

[michael dale]

nextFrame/prevFrame could be supported as well but I think that is later down the road. 

For our video sequencer purposes we would still have to read out the "currentTime" for the next frame and sync everything together. With accurate currentTime sets we avoid client side frame rate interpolation complexity since we just grab the video frame at a given time. If we where doing nextFrame grabs we would need an api to expose the framerate of the video make sure it matches up with other source videos in the sequence know which frame to throw out or double up on when recombining etc. 

We should target supporting frame accurate time seeking with the html5 video tag specification complaint way of doing it for now. 

NextFrame and prevFrame would be cool to have for more complicated applications in the future.

Comment 7

[Matthew Gregan [:kinetik]]

The testcase works fine for me now.  We've implemented all of various bits that allow this to work quite a while ago, but I think this bug was forgotten.  Any objection to marking as WFM?