[MPlayer-dev-eng] Regarding x264 decoding optimizations

[Peter Niemayer]

Guillaume POIRIER wrote:
> The "right" way to do it is frame-level multi threaded decoding (just
> like x264 does for encoding), as Loren has said several times on
> ffmpeg-dev mailing list (Google is your friend if you want the
> details).
> Sadly, implementing this is clearly uneasy, that's why it has never
> been done up to now. :-

If you were willing to sacrifice latency and RAM in favor of being able
to fluently replay on minimal hardware, wouldn't the following
idea be possible (and kind of easy to implement):

Just assign the work of decoding one complete GOP (from one I-frame
to the next) to CPU core 1, the next GOP to CPU core 2 etc. to CPU core N.

Assuming that one CPU core needs "factor X times the amount of time one
GOP would play" to decode the GOP, you would be able to play the video
fluently if you can dedicate at least X+1 CPU cores to the round-robin
decoding.

Of course, that means there's a X GOP delay before the fluent replay can start
(even after fast-forward jumps or alike) and it also means you need to be able
to buffer several seconds of decoded frames in memory.

However, since the method seems simple to implement, and CPU cores and RAM seem
to be getting cheaper in comparison so "single core speed", it may be worth
trying.

Regards,

Peter Niemayer