Re: to be effcient or not to be efficient

On Thu, Jan 08, 2004 at 11:01:17AM +0100, Steve Lhomme wrote:
> Jerome Bonnet wrote:
> 
> >My opinion about thread (however I am not a video/audio coder -yet-):
> >
> >All processing from one filter/codec/demuxer to another is serialized,
> >meaning that not much can be parallelized (The codec must wait for the
> >demuxer output for the current video frame). Even if some may be
> >buffurized, this will just flatten the different processing time from
> >one frame to another, however this may be archived with a single buffer
> >at the end of the processing (Am I clear ? Is this right ?).
> 
> That's not true for the DJ software I want to make. Many tracks can be 
> used at the same time, in parallel. Not all is serialised. As long as 
> you have filters with multiple input/multiple output (pins) you also 
> have some parallel processing. Think of merging the subtitle track on 
> the video track too.

that's your software specifics and they have to be implemented in your
software. [well, in my also, do i'm mulotithreading as well].

it doesn't mean the codec api have to create any threads. the
possibility of some parts running in separate threads should be
considered of course, but not implemented by the media access library.

> >The real thread benefit is to use one thread for each entire processing
> >pipeline. For instance, pipelines are graphs in DirectShow, and each
> >graphs instance are encapsulated in one thread. This means that two
> >different videos playing in a GUI application will use two different
> >threads for each video (two pipelines, two DShow graph instances) and
> >one thread for the GUI (always a good thing to have a specific thread
> >for the GUI).
> 
> Nop. Each filter in DirectShow has its own thread and is locked most of 
> the time (waiting for incoming data or waiting to output data).

synchronization between the threads just complicates the implementation
of the components although has nothing to do with the functionality they
provide. all the decoder has to do is to decode frames. 

somebody will want to put input/demuxer/decoder in one thread, other
will want to separate them, the codec or demuxer implementor shouldn't
bother. 

if you want DirectShow-like functionality - put it on top of the access
api. 

> >I think (abeit not sure) that VLC is actually using different threads
> >for different filter/codec/demuxer along the rendering pipeline (opposed
> >to mplayer/xine/dshow).
> 
> It would be nice to have some input from them :)

-- 
gr{oe|ee}t{en|ings}
artm