On Thu, Apr 10, 2008 at 7:22 AM, Vijay <[EMAIL PROTECTED]> wrote: > > (2) two sinks but with queues in between some elements: > gst-launch-0.10 -m -v filesrc location=<avi-file> ! tidemux_avi name=t t. > ! queue max-size-buffers=60 ! filesink location=<media-file> t. ! queue > max-size-buffers=180 ! filesink location=<media-file> > > I understand (from gstreamer's user manual) that in the second working > pipeline (in (2), above), the added queues forced the remainder of each end > of the pipeline in a different thread. But, I don't know how this made it > work. Could you explain that? > >
Sure, gstreamer always syncs audio and video output (even when your writing to a filesink). The way it does this, is it waits for all sinks to receive a buffer. It then uses the timestamps on the buffers to know when to 'play' each one. If one sink never receives a buffer, it will remain in preroll forever. The reason one sink didn't receive data in the first case is because of how data is stored in avi files. a simplified view might look like this: V0 V1 V2 V3 A0 A1 A2 A3 Basically 4 video frames followed by 4 audio blocks. So what would happen without the queues is this: 1. Demuxer grabs V0 and sends it as a buffer to the video filesink. 2. Demuxer grabs V1 and tries to send it to the video filesink, because the filesink is paused (audio filesink hasn't got anything yet), it hangs waiting for V0 to be processed. This won't happen until A0 is passed on, and that will never happen because the demuxer is stuck with V1. With the queues this happens: 1. Demuxer grabs V0 and adds it to the video queue. 2. Demuxer grabs V1 and adds it to the video queue. There is no hang here because the video queue can hold many buffers (passed in with max-size-buffers), and so far we've given it two. 3. V2 and V3 get handled the same. 4. Demuxer grabs A0 and adds it to the audio queue. Then A1 A2 and A3. you get the idea. Then in two separate threads (it doesn't really matter in this case that they are separate threads, but as you pointed out, queues make threads) Thread 1: When V0 is added, it is passed to the video filesink. When the filesink is ready for more data, the next buffer in the queue is passed on. Thread 2: The same as above, but for audio. Tyler
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
