Re: [xine-devel] Frequent (and unnecessary?) alloc/free

[Thibaut Mattern <thibaut.mattern@xxxxxxxxx>]

Hi Miguel,

On 9/24/05, Miguel Freitas <mfreitas@xxxxxxxxx> wrote:
> On 7/29/05, Jason Tackaberry <tack@xxxxxxxxx> wrote:
> > On Fri, 2005-07-29 at 13:22 -0300, Miguel Freitas wrote:
> > > > every frame disposes and reallocates/attaches an X shmem buffer.  Now,
> > > > malloc()/free() is very fast, but I think the overhead for all the shmem
> > > > and Xlib calls is probably less trivial.
> > >
> > > right. it would be very interesting to benchmark this.
> > > i mean, it seems like a good optimization to me. we should not
> > > maintain 2 different fifos in video_out (we don't know how many
> > > different formats are being used by decoders and post plugins) but
> > > rather priorizing frames with the same format when trying to allocate
> > > a new frame from the fifo.
> >
> > I guess in that case it's not a fifo anymore, strictly speaking. :)  But
> > yes, that kind of optimization doesn't sound complicated, and done at
> > that level, all video outs would benefit from it, plus it won't increase
> > memory usage either.
>
> what you would say if i tell you this optimization reduced cpu usage
> here in 20-25% while using deinterlacing plugin in film mode? it did!
> ;-)

excellent ;-)

While you're working on the get_frame function, another thing that
would be cool to fix (or start to think about) is the deadlock problem
when the video pipe needs more than 15 reference frames. iirc we
already have the problem with h264.
It's not easy to fix, i think there is at least three  issues with
this problem; the first one is to detect when we need to create a new
frame, the second one is how to create this frame, and the third one
how to display it if it has not been created by the video plugin.
I've thought a bit about the first issue. If we use 2 lock/ref
counters per frame, one ref counter for the video pipe, and a second
for the output queue, then it's easy to count how many frames are
referenced by the video pipe. If all frames are referenced by the
video pipe, these frames will not return to the free list after
displaying, so we have a deadlock for sure.
The impact of the proposed modification should be very small, only one
file needs to be touched (video_out.c) :
  - add a referenced frames counter to the vos_t struct
  - add a display_lock to the frame_t struct
  - add 2 inc/dec_lock functions to manage the display lock. the
dec_lock function must check the other lock value before adding the
frame to the free list.
  - modify to the vo_frame_inc_lock to increment the referenced frame
counter if the lock was 0
  - modify to the vo_frame_dec_lock function to decrement the
referenced frame counter if the lock was 1, and check the display lock
value.

Then you should be able to detect a deadlock from the get_frame function.
What to do next ? If the video driver can allocate an other frame the
problem is solved, but otherwise we have to create an indirect video
frame, and a real video frame will be needed to display it...

Maybe a new frame flag could be used (VO_INDIRECT_FLAG) to indicate
that a copy to a direct video frame is needed before displaying.
A direct video frame could be reserved for displaying indirect frames
once an indirect frame is created.

just some ideas...
Thibaut


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
xine-devel mailing list
xine-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xine-devel