Multithreaded fast-forward possible?

[Peter Rennert]

Dear all,

I want to increase the playback of a video quite drastically. At the 
moment I am playing a test video sequence with

gst-launch-0.10 filesrc location=/path/to/my.mp4 ! qtdemux ! h264parse ! 
ffdec_h264 name=dec ! ffmpegcolorspace ! deinterlace ! xvimagesink

and at some point the video speed cannot get increased further, because 
it uses only one CPU core to decode the video. Gstreamer starts 
complaining of getting behind the timestamps of the stream and crashes.

I could think of two solutions:
     - Is there a "native" way of making use of more than just a single 
core to decode the video frames? I tried to set "max-threads" of 
ffdec_h264 to 4, but it still only uses a single core.

or,
     - Is there a way of skipping frames? As I need only a "effective" 
framerate on the screen of about 25fps I could just decode the frames I 
need and skip the other frames. Then I would not need more CPU power 
than for realtime playback.

or.
     - Is there a way to split the stream after the qtdemux and use 
several decoders in a kind of decoder pool (distribute the frames 
between them) and unify the stream after?

My videos are in H264 format. I am not sure if the non-keyframes are 
encoded with respect to the previous frame or with respect to the last 
key-frame. In that case I could try to filter the key-frames and send 
them to every decoder in the pool and decode the any frame with that as 
reference until the next key-frame. With some management I could try to 
merge the output of the pool decoder with a input-selector. But that 
sounds bulky :\ So if one knows how to get to one of the first two 
solutions, I would be very happy...


Cheers,

Peter

PS I am happy to provide an example video. Maybe something is wrong with 
the encoding there that prevents ffdec_h264 to use multiple cores