[FFmpeg-devel] [RFC] ffmpeg.c refactoring

[Michael Niedermayer]

On Wed, Jun 11, 2008 at 11:32:45AM +0200, Ralf Terdic wrote:
> On Wednesday 11 June 2008 10:57:05 Luca Abeni wrote:
> > Did you measure this overhead? I did...
> From Java, the overhead is noticeable when comparing Runtime.exec() with the 
> JNI equivalent. We compiled ffmpeg to a JNI shared library before, so I, too, 
> know what I'm talking about.

This leads to the point i said about people not being able to code.
If it can be done in C with low overhead and C->java itself does not add
to much overhead for you (it does add alot but seems you dont mind).
So you can write your JNI shared lib that forks
and execs ffmpeg (or a seperate java free process that does the
forking & exec if you want even more seperation). If its too costy from java.
Also keep in mind some commercial OSs are slow with forks(), some unix variant
is strongly recommanded.


> 
> > If the number of forked processes is too high, wait before serving a new
> > request...
> Why use a hacky solution instead of a clean one based on a thread-safe API?

Because
* Its less work and simpler
* Its not cleaner at all once java isnt involved anymore.

And besides, i like to repeat, cleaning up ffmpeg.c is welcome, there very
well could be things that both of us consider cleanup, moving globals into a
struct though is not.


> 
> > So, you want to decode thousands of videos simultaneously... I repeat: the
> > problem here is not the fork() overhead.
> I know what you mean, but that's no reason to deliberately add even more 
> overhead...

This boils down to a simple
either you do care about performance or you do not.
If you do, using java and ffmpeg.c instead of libav* is the wrong thing.
If you do not, fork() is your least problem assuming you arent trying to
run your server on a MS desktop OS.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20080611/e9a4a8ed/attachment.pgp>