"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2011/6/6 Måns Rullgård <[email protected]>: >> "Ronald S. Bultje" <[email protected]> writes: > [..] >>>>>>> - if (avctx->codec->priv_class) >>>>>>> + if (avctx->codec && avctx->codec->priv_class) >>>>>>> av_opt_free(avctx->priv_data); > [..] >>> Logic-wise, because what else would it be? >> >> Not null of course? Are you saying the avctx variable has a totally >> different meaning here when threads are used? > > Yes. Look at the code. What we're doing here is free the codec private > options. > > For threading, the AVCodecContext that interacts with the application > _has no codec-specific context in private data_. > > This data is in the worker threads, not in the application-facing > thread. The application facing AVCodecContext has some frame threading > private data there that is used in pthread.c, but calling > AVCodec-specific functions or option-freeing functions there would > crash. > >>> The application-level AVCtx has nothing in it, it's a placeholder that >>> is there to synchronize the individual per-thread AVCtxs that run in >>> each worker thread. It has no private context other than the one that >>> syncs between threads. It has no private_data with codec information >>> in it. Therefore, AVCodec == NULL. >> >> So where is whatever is there in the non-threaded case? > > In the non-threaded case, everything is in AVCodecContext, the one > facing the application. > > In the threaded case, it is not. That's why AVCodec is set to NULL > before freeing stuff. Otherwise you'd free stuff that isn't there -> > crash.
So how do codec-private options work here? I don't see them being freed anywhere. If valgrind didn't report leaks, that's because none of the tests set any private options. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
