[FFmpeg-devel] Parallelizing MPEG encoding with MPI

[Michael Niedermayer]

On Sat, Dec 06, 2008 at 11:30:55PM -0500, Alexander Strange wrote:
> 
> On Dec 6, 2008, at 11:00 PM, Jason Garrett-Glaser wrote:
> 
> > On Sat, Dec 6, 2008 at 12:20 PM, Andreas Simbuerger <simi at osaft.eu>  
> > wrote:
> >> Greetings everybody!
> >>
> >> I'm currently working on a programming exercise for my diploma at the
> >> University of Passau. We try to enhance MPEG encoding by introducing
> >> parallelism on GOP encoding with the MPI libraries.
> >
> > Isn't MPI rather unnecessary for video encoding parallelism?  It is
> > rather easy to develop a model (see
> > http://akuvian.org/src/x264/sliceless_threads.txt) which does not
> > require communication between threads except to signal the maximum
> > motion vector search range, which can be done using an atomic write to
> > a struct variable.
> >
> > Dark Shikari
> 
> GOP multithreading for encoding is much easier to add in, though.
> It's bad for ratecontrol efficiency, but a lot less work than adapting  
> ratecontrol to handle frame-threading.
> 
> But we're talking about MPEG-2 here, so slice threading should already  
> work fine.

and >=1 slice per row being mandatory for mpeg2, so there also are enough
slices to work with and with no bitrate loss due to no extra slice headers.
But then of course this is just for multiprocessor systems ... distributing
slice encoding across a network likely would be tricky ...

Besides this, i think GOP based multithreading support is a good idea,
also because it requires very few if any changes per encoder, i mean
many codecs could just independantly encode a GOP and the results could be
concatenated. Minor changes to some headers should be trivial, RC though
might be non trivial but efficiency with multipass encoding shouldnt be
that bad IMHO

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

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081207/3a3f5863/attachment.pgp>

>From =?UTF-8?B?zqDOsc69zrHOs865z47PhM63z4IgzprOsc+Ez4POsc67zr/Pjc67?=  Sun Dec  7 13:20:23 2008
From: =?UTF-8?B?zqDOsc69zrHOs865z47PhM63z4IgzprOsc+Ez4POsc67zr/Pjc67?= (=?UTF-8?B?zqDOsc69zrHOs865z47PhM63z4IgzprOsc+Ez4POsc67zr/Pjc67?=)
Date: Sun, 7 Dec 2008 14:20:23 +0200
Subject: [FFmpeg-devel] In Leopard library is broken if compiled with Tiger
	compatibility
Message-ID: <AB08EDC6-8DEE-456A-8E3B-2A3B78D03254 at panayotis.com>

In Mac OS X 10.5, in order to produce binary compatible code with  
version 10.4, there is a need to manually add the command line argument
-mmacosx-version-min=10.4
or else the produced code will not be binary compatible with previous  
version.

This works with ffmpeg, e.g. by using the "--extra-cflags"  
configuration option, but unfortunately, this is not enough. The  
produced code is still not compatible (there are some *$UNIX2003  
symbols presented).

I did some exploration and managed to spot the source of the problem,  
in case you are willing to address it.

* 1 *

In libavcodec/utils.c line 29
There is a #define which forces specific features for mkstemp
This define breaks "strtod" function in line 1501

Thus, I propose something like

#ifndef __APPLE__
#define _XOPEN_SOURCE 600
#endif

instead of
#define _XOPEN_SOURCE 600

(or even better enable this flag ONLY in systems where are really  
needed.


* 2 *

In configure script, line 1130

There is a line saying
add_cflags -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112

Unfortunately the flag _POSIX_C_SOURCE breaks compatibility, and I'd  
suggest again to be added only when is really needed.


Thank you for listening to me.