On Wed, Apr 13, 2011 at 4:13 PM, Ronald S. Bultje <[email protected]> wrote: > 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?
Put it under if (!avctx->is_copy) free(). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
