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

Michael Niedermayer michaelni
Mon Jun 18 22:22:36 CEST 2007


Hi

On Mon, Jun 18, 2007 at 01:16:05PM +0200, Andreas ?man wrote:
> 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.

ok


> 
> 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.

if this is a small change, that is MPV_common_*_threads() being called
from 1-3 places iam ok with it, of it adds 10 calls to it iam not

its not hard to add a codec != H264 check around the init code or even
call MPV_common_*_threads() from MPV_common_*() if codec != H264

(cleanup for mpegvideo stuff is very welcome, bloating it up is not)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070618/21b72bfa/attachment.pgp>



More information about the ffmpeg-devel mailing list