Hi, On Wed, Apr 13, 2011 at 4:08 PM, Alexander Strange <[email protected]> wrote: > On Apr 13, 2011, at 11:35 AM, Ronald Bultje wrote: >> Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6: >> >> time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \ >> ~/Downloads/sintel_trailer_1080p_vp8_vorbis.webm \ >> -f null -vcodec rawvideo -an - >> 1: 0m14.630s (89.9 fps) >> 2: 0m8.056s (163.2 fps) >> 3: 0m5.882s (223.6 fps) >> 4: 0m4.952s (265.6 fps) >> >> time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \ >> ~/Downloads/Elephants_Dream-720p-Stereo.webm \ >> -f null -vcodec rawvideo -an - >> 1: 1m12.962s (215.1 fps) >> 2: 0m44.682s (351.2 fps) >> 3: 0m31.183s (503.2 fps) >> 4: 0m25.284s (620.6 fps) >> >> Ronald > >> --- a/libavcodec/pthread.c >> +++ b/libavcodec/pthread.c >> @@ -646,6 +646,8 @@ static void frame_thread_free(AVCodecContext *avctx, int >> thread_count) >> pthread_mutex_unlock(&p->mutex); >> >> pthread_join(p->thread, NULL); >> + if (i) >> + update_context_from_thread(p->avctx, fctx->threads[i-1].avctx, >> 0); >> >> if (codec->close) >> codec->close(p->avctx); > > I'm not sure other codecs are prepared to have update_context called after > they're closed. Let me think about it.
Oh, that's me being lazy. What happens is that all threads have a copy of the frame struct, and freeing them in the first and then second thread causes a double-free. How does h264/etc solve that? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
