[FFmpeg-devel] QTRLE encode performance

Malcolm Bechard malcolm.bechard at gmail.com
Fri Feb 8 23:10:09 CET 2013

On Fri, Feb 8, 2013 at 3:51 PM, Alexis Ballier <alexis.ballier at gmail.com>wrote:

> 2013/2/8 Alex Beregszaszi <alex at rtfs.hu>:
> >> I don't know the quicktime encoder, but you should probably check the
> >> filesize for the same color depth: ffmpeg's qtrle encoder is optimal
> >> (in terms of output size), so it's likely a non-optimal heuristic is
> >> much faster.
> >
> > If it is technically possible it would be nice to change qtlreenc to use
> > ff_rle_encode and optimise/multithread the latter to benefit other
> encoders
> > using RLE.
> It's not exactly rle as in the ff_rle_encode sense: you can repeat n
> times a pixel or have n raw pixels (which is what ff_rle_encode does
> afaik) but also skip n pixels, meaning the pixels will be the same as
> those from the previous frame.
> Also, it's probably way much harder to parallelize the rle encoder
> than cutting each frame into # of theads parts of (# of lines / # of
> threads) lines and encode them in parallel.
> Alexis.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Great info for all, thanks.
I think it does make sense to just parallelize the for loop that calls
qtrle_encode_line() to get started. Any suggestion for the best file to use
as a template for how encoding threading is done in ffmpeg?

More information about the ffmpeg-devel mailing list