[MPlayer-dev-eng] Regarding x264 decoding optimizations

[Gautham Anil]

Hi,

I can give an algorithm which can manage this with
virtually no delays.

Datastructures : T : Thread pool with k threads.
F: x Frame Buffers 
int c; // current frame buffer position
int f; // current frame number
U : non-decoded frames

while not at end of movie {
.....
<Display the frame stored in F_c>
mark F[c] unused;
wait till F[(c + 1) % x] is used.
atomic {
    c = (c + 1) % x; 
    f++;
}
if U[f+x] is a keyframe, add a new job with f+x to the
thread pool queue.
...
}
....
-------------------------
Thread logic:
Let the given job be y. There is a keyframe at y. 
let i = y;

while(!(i > y && (U[i] is a keyframe))) {

wait till F[(i - f) + c] is unused, 
decode U[i] and put it in F[(i - f) + c]. Mark it
used.
i++;
}
return self to thread pool.


--------------------------------------
This algorithm will process multiple GOPs in a
parallel non blocking way. Since someone with 2G
should be able to use around 150 buffers, I think the
video should play perfectly smooth. This algorithm
will keep decoding something while the buffers are not
full. Oh, and the thread decoding the current GOP must
have higher priority than any other thread.

End result is, immediately after seeking, movie will
play as normal. But benefits of buffering will not
show up until the next GOP is encountered (in no more
than 10 seconds). Still if the GOP currently seeked to
has some easy frames, that should give the decoder
some head start. 

Also, while playing movies, I noticed that most of the
time CPU is not full. So, even in the seeked-to GOP,
there will occur some buffering.

--- Peter Niemayer <niemayer at isg.de> wrote:

> RC wrote:
> >>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.
> > 
> > With x264's default keyint=250, and 8 cores,
> you're waiting 80
> > seconds before playback can start.
> 
> It's much more likely that 2 or 3 cores provide
> enough CPU power
> to allow for fluent playing.
> 
> Yes, waiting 20 or 30 seconds before the replay
> starts is annoying,
> but may still be very preferable if the alternative
> is no fluent
> replay at all.
> 
> And don't forget how many people are willing to
> watch annoying
> "FBI-Warnings" and studio intros on DVDs that are
> much longer...
> without any choice to skip that part.
> 
> 
> > Not to mention that multiple
> > reference frames (open GOPs) could complicate
> things much more.
> 
> AFAIK the "keyint" parameter refers to closed GOPs,
> only - otherwise,
> jumping to the start of the GOP would be just as
> complicated.
> 
> Regards,
> 
> Peter Niemayer
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
>
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 

--
Gautham Anil


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ