>Sounds good.
>So, I volunteer for maintining the legacy code (the current src/*
>stuff).
Then I guess I'm tapped for the new code, huh? (: Well, I'll see how
my work schedule looks, but I should be able to contribute something,
at least. Plus it looks like fun to try. (:
>One of the constraint that I've set is to require minimal or, much
>better, no changes into modules -at all-.
>I thought this project initially as side-project, hosted on a separate
>tree (tcforge), so the total compatibility at module level was
>absolutely required.
Well, that's certainly good to start with (changing too many things at
once will just lead to problems), but we probably ought to consider
changes once the basic framework is solidified, just so we don't have
too many round-peg-to-square-hole converters thrown into the code.
>Quite franly, I still not found a convincing (read: efficient) way of
>handling nodes with threads, every design that I thought so far has
>drawbacks.
>
>The point I'm blocked on is how to blend together real parallelism and
>efficient frame passing. If we apply the strategy I exposed verbatim in
>a multi-{cpu,core} environment, I'm afraid just one node will
>effectively run at any given time, while all the others are blocked in
>pulling. Of course this is no good.
I agree it's not easy (I gave it a little thought myself and eventually
decided it wasn't worth worrying about in an initial implementation),
but I still think we should keep the one-thread-per-node concept. After
all, it's much harder to add multithreading later to a single-threaded
design than it is to design in from the beginning.
>If we come out with a clean solution about handling multithreading and
>(so-called) pull model dealing with multi-I/O shouldn't be a big deal:
>The biggest problem I see is to avoid being forced to effectivly wait
>for _all_ frames to come sequentially (so expending _the sum_ of the
>waiting times sleeping) instead of doing that in parallel (so being
>sleepy only for _the longest_ waiting time).
Agreed, and in the multithreaded model as I envision it, this will
already happen even without worrying about buffers:
(thread_1:mux) --+--> (thread_2:encode_video) --> ...
|
+--> (thread_3:encode_audio) --> ...
i.e. thread 1 pulls from thread 2 and thread 3 at the same time, so it
only has to wait for max(wait_2,wait_3), not (wait_2 + wait_3).
Admittedly I'm not sure how well this will work in practice, since the
demux stage will be single-threaded and not (yet) have any buffering,
but at the least we should be able to get the video and audio streams
running in parallel.
--Andrew Church
achu...@achurch.org
http://achurch.org/
