[MPlayer-dev-eng] [PATCH] vf_ffmpeg, threads and slice callback

[Reimar Döffinger]

On Sat, Sep 11, 2010 at 05:12:25PM -0400, Alexander Strange wrote:
> If it can't handle out of order draw_horiz_band it would probably be best to not set the callback if it set thread_count > 1.

The "problem" with that is that it will disable slices for all codecs,
even those that can not do threading.
If it's enough we can do it like below, it's just not optimal at all...
Index: libmpcodecs/vd_ffmpeg.c
===================================================================
--- libmpcodecs/vd_ffmpeg.c     (revision 32136)
+++ libmpcodecs/vd_ffmpeg.c     (working copy)
@@ -649,7 +649,8 @@
 
     // ok, let's see what did we get:
     if(mpi->flags&MP_IMGFLAG_DRAW_CALLBACK &&
-       !(mpi->flags&MP_IMGFLAG_DIRECT)){
+       !(mpi->flags&MP_IMGFLAG_DIRECT) &&
+       lavc_param_threads == 1){
         // nice, filter/vo likes draw_callback :)
         avctx->draw_horiz_band= draw_slice;
     } else
@@ -819,7 +820,8 @@
         mpi=mpcodecs_get_image(sh, MP_IMGTYPE_EXPORT, MP_IMGFLAG_PRESERVE |
             (ctx->do_slices?MP_IMGFLAG_DRAW_CALLBACK:0),
             sh->disp_w, sh->disp_h);
-        if(mpi && mpi->flags&MP_IMGFLAG_DRAW_CALLBACK){
+        if(mpi && mpi->flags&MP_IMGFLAG_DRAW_CALLBACK &&
+           lavc_param_threads == 1){
             // vd core likes slices!
             avctx->draw_horiz_band=draw_slice;
         }


> > What about the first is hard to avoid?
> > You just keep the main thread waiting fo buffer requests, and all real
> > decoding threads pass the get_buffer through that.
> > Compared to all the other things this needs (e.g. making sure you
> > don't end up with wrong buffer sizes just because some later frame
> > has a different frame size) this should be rather simple, though
> > somewhat annoying to implement.
> 
> Well, I wanted to avoid annoyance.
> 
> The specific difference here (between a mutex on calling get/release_buffer and forwarding requests to the main thread) should only affect clients using thread-local storage, though. That does happen in mplayer (vo_corevideo, just causes a missing autorelease pool warning) but I don't think it's what you meant. What's the specific problem here?

Sounds like there should be none. I don't know at all what the problems
are/might be, but in case -noslices doesn't fix it there must be something
else.