Hi, On Fri, Mar 23, 2012 at 6:04 AM, Janne Grunau <[email protected]> wrote: > On 2012-03-22 18:20:00 -0700, Ronald S. Bultje wrote: >> > One comment, Janne if you could incorporate the following change: >> > >> > diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c >> > index 720997f..ef75665 100644 >> > --- a/libavcodec/mpegvideo.c >> > +++ b/libavcodec/mpegvideo.c >> > @@ -606,6 +606,8 @@ int ff_mpeg_update_thread_context(AVCodecContext *dst, >> > } >> > } >> > >> > + s->mb_num_left = s1->mb_num_left; >> > + >> > return 0; >> > } >> > >> > Otherwise the n_threads'th (instead of the next) thread will "unlock" >> > the previously not-completely-decoded image, leading to deadlocks all >> > over the place. >> >> Ignore this, me stupid, but this hang exists and should be resolved, e.g. >> by caching the old self-thread's current_picture_ptr or so... > > I'm still thinking of a way to handle errors and calls with single > slices instead of frames with multithreading. Without much progress. > > Just not supporting such a fringe feature sounds like the best > solution. I'll update the patch for that.
I really don't think that belongs here, yes. For slice-mt, we have slice-mt. This is frame-mt, and the intention is frame-level multithreading, not to abuse it to achieve something similar'ish to slice-mt... If you want to implement slice-mt... ;-). (Kinda pointless unless you know of someone using rv34 for realtime communication purposes, like video conferencing or so.) Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
