Multithreaded fast-forward possible?
p.rennert at cs.ucl.ac.uk
Wed Dec 12 17:02:08 PST 2012
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.
- 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.
- 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...
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
More information about the gstreamer-devel