Tyler, I see now. That makes sense. Thanks a lot! Vijay
On Thu, Apr 10, 2008 at 8:33 PM, Tyler Nielsen <[EMAIL PROTECTED]> wrote: > > 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
