Faster Video Seeking

Lasse Laursen gazoo at 42.dk
Wed Mar 26 05:28:10 PDT 2014


Hey Tim,

Here's the relevant video seeking code:

http://pastebin.com/fMe1DKVM

As you can tell, I do use the 'GST_SEEK_FLAG_ACCURATE' flag. I have no 
issues with having a slightly less accurate search at first, but then 
how would I nicely switch to the 'GST_SEEK_FLAG_KEY_UNIT'. Perhaps when 
no other frames are waiting to get fetched?

The video is originally from YouTube, so I while I can dodge most of the 
lawyers by keeping its use internal, I'm more weary of sharing it online.

I've tried seeking in VLC which seems to be more responsive.

Thanks,
Lasse

On 26-03-2014 20:58, Tim Müller wrote:
> On Wed, 2014-03-26 at 20:22 +0900, Lasse Laursen wrote:
>
> Hi Lasse,
>
>> I am a little surprised that I've not been able to find any discussions
>> or thoughts on improving the seek-times of Gstreamer. Perhaps it's
>> because I'm in kind of a unique usage scenario? I'm using video
>> scrubbing as a means to test an interaction method, so I've created a
>> simple app where the user can drag a slider widget to scrub through a video.
>>
>> 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.
>>
>> Potential Solutions:
>>
>> 1) The easiest solution is undoubtedly to reduce the resolution. Not
>> great, but a last resort, if needed.
>>
>> 2) Load the entire video file into memory. Is this even possible via
>> gStreamer? The file is only about 1 minute long and fills 15 megs
>> encoded as a webm file. This would be my preferable solution - but
>> again, I worry if it's possible? Could only find 'uri' paths that point
>> to files or online locations.
>>
>> 3) Optimizing the gStreamer pipeline while still keeping the rest of my
>> code intact. Is using uridecodebin a bad thing? Is there a better/faster
>> way for me to display single frames in my app?
>>
>> I hope someone can hint me towards the most viable approach.
> It would be useful to see both your test file and your code. Are you
> doing a KEY_UNIT seek? Are you doing an ACCURATE seek? etc. How slow or
> fast seeking is depends a lot on the file in question, whether there's
> an index, what the keyframe spacing is, if you do a key unit seek, etc.
> Have you tried seeking in Totem (just keep the button pressed and move
> the slider handle)?
>   
>   Cheers
>    -Tim
>



More information about the gstreamer-devel mailing list