[FFmpeg-devel] [PATCH] h264 parallelized, (was: Parallelized h264 proof-of-concept)

Andreas Öman andreas
Mon Jun 18 13:16:05 CEST 2007


Hello,

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Jun 16, 2007 at 11:03:22PM +0200, Andreas ?man wrote:
>> Hi
>>
>> How about just letting MPV_common_init use ctx->codec->priv_data_size
>> for malloc'ing the contexts? Or is that too inflexible, in that case
>> I tend to favor adding "priv_data_size" to MpegEncContext
> 
> it still would be allocating H264Contexts into a MpegEncContext pointer
> somehow this doesnt feel correct
> 

I have given this some thought, how about this?

Add 'struct H264Context *thread_context[MAX_THREADS]' to H264Context
and use it instead of s->thread_context[] and let h264.c care about
this only.

In order to avoid MPV_common_init() duplicating MpegEncContext (when
avctx->thread_count > 0), i'd like to move out the thread_context
initializing and deinitializing to two new separate functions
MPV_common_init_threads() and MPV_common_end_threads()
(or somthing, name suggestions welcome) and have the current users
of MPV_common_init & end call these explicitly. I'd also like to
move out the 'too many threads' check from MPV_common_init to
MPV_common_init_threads().

This will also IMHO enable a greater degree of freedom for how
multi-threading is implemented for codecs that also use
MPV_common_ -stuff.

comments?






More information about the ffmpeg-devel mailing list