Faster Video Seeking

[Nicolas Dufresne]

Le mercredi 26 mars 2014 à 20:22 +0900, Lasse Laursen a écrit :
> I've built the playback pipeline using 'uridecodebin' and use it to 
> create a raw frame I can display on a texture in my app. I use the 
> 'gst_element_seek_simple' function call to seek through frames in a 
> video. I run it in a separate thread and ignore any additional calls 
> until the original call has returned. The video is in webm format with a 
> resolution of 1280x720. Currently, it's very juttery. Seeking to a new 
> frame takes quite a while. Much longer than I need for properly testing 
> my interaction method. I'm assuming the slow seek times is due to 
> gStreamer accessing the video as stored on the HD? So slow HD access times.

gst_element_seek() and gst_element_seek_simple() are asynchronous call.
They terminate if the command has return an error, or when ASYNC_DONE
message is emitted. Sending seek before that, will cancel previous seek
and will give the impression of seek being slower then it is.

Appropriate scrub implementation should always wait that previous
operation has completed before doing the next one (seek compression).
Though, when scrub terminate, if current seek is not the last one, the
current seek should be canceled in order to reach the final position as
fast as possible.

From that point, you'll be able to really measure the seek speed. Some
optimization is being done all the time, though there is so many
formats, and so many ways it can be slow that your specific use case
might not be covered yet.

cheers,
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140326/23a967a1/attachment.sig>