[MPlayer-dev-eng] Regarding x264 decoding optimizations

[Peter Niemayer]

Vladimir Mosgalin wrote:

> Now thing about how many gops you would like to decode per parallel. You
> weren't satisfied with 2 cores, right? So that means 3 or 4 gops.. Which
> means 2.4 to 3.2 gigs of ram. Ugh.

Don't forget you can reuse any frame buffer that has been displayed.
Threads decoding future GOPs can wait for free buffer from a pool of
buffers that is fed by the thread displaying the current GOP, frame by
frame.

So you'll probably not need more than 2.4G.

You can add 2G to your system for < 75,- EUR, but you might have no
chance to upgrade to any CPU capable of fluent 1080p replay at all.

Also, it's a good thing that the more expensive a GOP is to decode, the
more likely it is to be shorter than 250 frames. This could further lower
the number of frame buffers needed.


> When decoding multiple very different frames at once, you may also run
> into problems with memory performance. 

Of course, that is a risk.


I think that GOP-parallel decoding is an interesting option only
because it's simple, it doesn't need h.264 expert knowledge to implement,
it could just fill the gap before some sophisticated frame/slice/whatever
level parallelism could be exploited.

Regards,

Peter Niemayer