Re: to be effcient or not to be efficient

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.

> 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).

> 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 :)