[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Opendivx digest, Vol 1 #11 - 9 msgs
Send Opendivx mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.projectmayo.com/mailman/listinfo/opendivx
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opendivx digest..."
Today's Topics:
1. Re: Some ideas (Stefan Arentz)
2. Re: Re: [Opendivx] Some ideas (Stefan Arentz)
3. Re: Some ideas (Nick Feamster)
4. Re: Re: [Opendivx] Some ideas (Nick Feamster)
5. Re: global variables (John Funnell)
6. Re: Some ideas (Stefan Arentz)
7. Re: Some ideas (Dan Maas)
8. Re: Some ideas (Nick Feamster)
9. Re: Re: [Opendivx] Some ideas (Stefan Arentz)
--__--__--
Message: 1
Date: Wed, 31 Jan 2001 17:25:28 +0100
From: Stefan Arentz <[email protected]>
To: Nick Feamster <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: Re: [Opendivx] Some ideas
On Wed, Jan 31, 2001 at 11:17:55AM -0500, Nick Feamster wrote:
> That is easily solved by simply writing some different code for windoze
> and using #ifdefs
You seem to miss the point. We were talking about getting rid of
global variables in the code because it is not possible to create
to instances of a decoder or encoder in the same process.
A solution with fork() was suggested, however, this does not work
on all platforms, like BeOS, MacOS and Windows.
Writing some other code for fork() on Win32 is not an option
because the problem is the globals, and not the fork().
IMO the divx core library should be plain C, with NO calls to
any operating system service (fork, malloc, read, write, etc.).
This will make the code 100% portable to any platform.
Stefan
--__--__--
Message: 2
Date: Wed, 31 Jan 2001 17:29:20 +0100
From: Stefan Arentz <[email protected]>
To: Arpi <[email protected]>
Cc: [email protected]
Subject: Re: Re: [Opendivx] Some ideas
On Wed, Jan 31, 2001 at 05:21:49PM -0600, Arpi wrote:
> Hi,
>
> > That is easily solved by simply writing some different code for windoze
> > and using #ifdefs
>
> Why does the codec have to do fork()? Leva it to the application which uses
> it...
> I'm just saying that the codec shouldn't be prepared for threading, because
> there is no need for it, but it causes performance loss.
C'mon, look beyond the basic unix usage of this library.
Say you want to
use it in a simple conferencing app where you have five streams open in
the same window and an encoder running to capture data from your camera.
Making it thread-safe is a *minor* issue compared to the other tasks
on the list.
Stefan
--__--__--
Message: 3
Date: Wed, 31 Jan 2001 11:31:32 -0500 (EST)
From: Nick Feamster <[email protected]>
To: Stefan Arentz <[email protected]>
Cc: <[email protected]>, <[email protected]>,
<[email protected]>
Subject: Re: [Opendivx] Some ideas
> You seem to miss the point. We were talking about getting rid of
> global variables in the code because it is not possible to create
> to instances of a decoder or encoder in the same process.
This is just a bad idea altogether. The idea is that with fork() you
create two separate processes. Sharing data between two threads of a
codec is potentially dangerous, and why would you want to do that anyway?
Why not just create two separate processes?
> A solution with fork() was suggested, however, this does not work
> on all platforms, like BeOS, MacOS and Windows.
this is not a solution to creating multiple threads within one process.
it is a way of forking off a new child process with its own memory space.
Much safer (and a different idea entirely) than using threads.
> IMO the divx core library should be plain C, with NO calls to
> any operating system service (fork, malloc, read, write, etc.).
>
> This will make the code 100% portable to any platform.
However, threading libraries also differ by platform, and thus behavior
varies by OS. So I would recommend against using threads.
--__--__--
Message: 4
Date: Wed, 31 Jan 2001 11:34:52 -0500 (EST)
From: Nick Feamster <[email protected]>
To: Stefan Arentz <[email protected]>
Cc: Arpi <[email protected]>, <[email protected]>
Subject: Re: Re: [Opendivx] Some ideas
In this case, you should simply have the conferencing app fork an encoder
process (or something else in the case of winblows) for each instance of
the encoder.
The idea is not to make the codec unncessarily complex. There is no
reason why core functionality of a video codec should be multithreaded.
This is an application-level issue.
If someone needs an application that's multi-threaded, THEY figure out how
to extend that using fork() or whatever.
The more complex you try to make it, the more difficult it becomes to make
the app cross-platform.
Nick
> C'mon, look beyond the basic unix usage of this library.
>
> Say you want to
> use it in a simple conferencing app where you have five streams open in
> the same window and an encoder running to capture data from your camera.
>
> Making it thread-safe is a *minor* issue compared to the other tasks
> on the list.
>
> Stefan
>
>
> _______________________________________________
> Opendivx mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx
>
--__--__--
Message: 5
From: "John Funnell" <[email protected]>
To: "Arpi" <[email protected]>, <[email protected]>
Subject: Re: [Opendivx] global variables
Date: Wed, 31 Jan 2001 16:37:16 -0000
> Anyway, copying some data to the stack is basicly a good idea.
> Stack pointer is always there so it doesn't mean extra addressing. except
if
> you're using more than one indices to an array[x+y*4] what can be done
> now using registers (array[EAX+4*EBX]) but can't using stack (there is no
> array[ESP+EAX+4*EBX]...)
> I think that arrays are never global (except constants, but they can stay
> global even for threading), they are allocated at runtime so it's
> not a problem.
This is x86 specific, can anyone enlighten us to the addressing modes of the
other architectures that have the potential to decode DivX realtime? I'm
thinking that things like VLIW media processors may have quite rigid
addressing modes.
So, after all, it seems like losing the globals might not be too bad, at
least for x86 CPUs. I'll believe it when I see it though. If we can get
rid of the globals, we can forget all about threads and processes (unless of
course we want to have portable support for SMP :-O )
John
--__--__--
Message: 6
Date: Wed, 31 Jan 2001 17:37:50 +0100
From: Stefan Arentz <[email protected]>
To: Nick Feamster <[email protected]>
Cc: Stefan Arentz <[email protected]>, [email protected],
[email protected], [email protected]
Subject: Re: [Opendivx] Some ideas
On Wed, Jan 31, 2001 at 11:31:32AM -0500, Nick Feamster wrote:
> > You seem to miss the point. We were talking about getting rid of
> > global variables in the code because it is not possible to create
> > to instances of a decoder or encoder in the same process.
>
> This is just a bad idea altogether. The idea is that with fork() you
> create two separate processes. Sharing data between two threads of a
> codec is potentially dangerous, and why would you want to do that anyway?
> Why not just create two separate processes?
Yes it is dangerous. That's why I voted for removing globals, and why?
Because you cannot create two separate processes on all platforms.
This is not just a UNIX thing. It must run on many platforms.
> > A solution with fork() was suggested, however, this does not work
> > on all platforms, like BeOS, MacOS and Windows.
>
> this is not a solution to creating multiple threads within one process.
> it is a way of forking off a new child process with its own memory space.
> Much safer (and a different idea entirely) than using threads.
Does not work on all platforms.
> > IMO the divx core library should be plain C, with NO calls to
> > any operating system service (fork, malloc, read, write, etc.).
> >
> > This will make the code 100% portable to any platform.
>
> However, threading libraries also differ by platform, and thus behavior
> varies by OS. So I would recommend against using threads.
We are not USING threads. Just make sure that one encoder does not
share data with another encoder or decoder. That already makes the
code thread-safe. Big deal :-)
Stefan
--__--__--
Message: 7
From: "Dan Maas" <[email protected]>
To: <[email protected]>
Subject: Re: [Opendivx] Some ideas
Date: Wed, 31 Jan 2001 11:42:23 -0500
> This is a much better solution than doing multiple threads. I like the
> fork() option personally. Using threads can create unnecessary complexity
> (shared variables, race conditions, etc.) in the codec which is much more
> cleanly solved by using separate processes.
> Perhaps we could come to a comprimise by locking the whole decoder/encore
> with a mutex (or other atomic read/write trick). Thus if two
> threads/applications wanted the codec at once, then one would have to
wait.
Both of these solutions entail unnecessary work and place severe
restrictions on the calling code.
Just leave this up to the caller. Provide the guarantee that contexts share
no state (ie no global variables), then the caller can use whatever
concurrency model it wants. (don't go insane like the Gtk folks and just
start throwing mutexes all over the code, then everybody must pay for the
overhead even if they aren't threaded!). e.g. if the caller wants to run two
completely independent encodes/decodes in different threads, it doesn't
incur any locking overhead whatsoever.
(yes, BTW, I personally prefer multi-process designs to multi-threaded
designs, but this way we can make everyone happy, especially the Windows
folk who must suffer without fork() and with very heavy process context
switches =)
> Another solution would be for each instantiation of the codec to create
its
> own copy of code, globals, everything. The memory cost is not too bad.
But
> I'm not sure of the mechanics for doing this. Aparently dll's can be
loaded
> like this.(?)
The compiler should be smart enough to do this automatically. As long as the
globals/context-specific variables aren't declared "volatile," the compiler
is free to optimize access to them by storing them in registers. Anyway, the
only place where the global vs. local access method would make any
detectable performance difference at all is in the very innermost loops,
which can be hand-optimized if necessary.
Dan
--__--__--
Message: 8
Date: Wed, 31 Jan 2001 11:39:07 -0500 (EST)
From: Nick Feamster <[email protected]>
To: Stefan Arentz <[email protected]>
Cc: <[email protected]>, <[email protected]>,
<[email protected]>
Subject: Re: [Opendivx] Some ideas
> We are not USING threads. Just make sure that one encoder does not
> share data with another encoder or decoder. That already makes the
> code thread-safe. Big deal :-)
sure, ok. I can agree with that much. :)
Nick
--__--__--
Message: 9
Date: Wed, 31 Jan 2001 17:39:43 +0100
From: Stefan Arentz <[email protected]>
To: [email protected]
Subject: Re: Re: [Opendivx] Some ideas
On Wed, Jan 31, 2001 at 11:34:52AM -0500, Nick Feamster wrote:
> In this case, you should simply have the conferencing app fork an encoder
> process (or something else in the case of winblows) for each instance of
> the encoder.
>
> The idea is not to make the codec unncessarily complex. There is no
> reason why core functionality of a video codec should be multithreaded.
> This is an application-level issue.
>
> If someone needs an application that's multi-threaded, THEY figure out how
> to extend that using fork() or whatever.
>
> The more complex you try to make it, the more difficult it becomes to make
> the app cross-platform.
It is not complex!
Please, anyone here who does understand this? I'm not going to type
all my arguments again :-)
Stefan
--__--__--
_______________________________________________
Opendivx mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx
End of Opendivx Digest
Reply To Poster
Local References / HOW-TO / FAQs