[gst-devel] tcpsink - tcpsrc- gdp problem

[xavier.grasa at iss-profesionalia.com]

Hi again,

After some debugging, it seems that, after the first frame is sent, the
select calls (WSAWaitForMultipleEvents() gstpoll.c line 1185) of both
sides never return. Somehow, the client waits for new data from the
server, and the latter might be waiting for the client to be ready to
accept new data. When the client is stopped, the server side select
returns.

Besides, several mutex issues have been observed at the receiving side:
from time to time the g_mutex_lock (gstpoll.c line 1213) calling
EnterCriticalSection() does never return and enters in a deadlock waiting
for the ownership of the critical section of code.

We are using Glib 2.16.1 and Gstreamer 0.10.19 CVS on WinXP SP2.

> send pipeline:
> gst-launch --gst-debug-no-color -v -m videotestsrc do-timestamp=true
is-live=true ! gdppay ! queue ! tcpserversink port=1234 host=localhost
receive pipeline:
> gst-launch --gst-debug-no-color -v -m tcpclientsrc port=1234
> host=localhost ! gdpdepay !  queue ! ffmpegcolorspace !
> directdrawsink

Any idea on how to get around the mentioned issues? Has anyone tried those
pipelines on WinXp?

Thanks & regards,

--xavier

> Hi,
>
> I have also met a similar situation where a pipeline got frozen locally
in windows.
> I also used the tcpserversink/tcpclientsrc combination. And after a
certain amount of time/frames it froze
> for me aswell.
> Do anyone recognize this?
>
>
> Thanks,
>
> Mattias
>
> xavier.grasa at iss-profesionalia.com wrote:
>> Hello,
>> I'm trying to send-receive raw video on the same pc using gdp and tcp
for
>> test purposes. The following pipelines have been run on a Linux system
as
>> well as on a winxp pc.
>> send pipeline:
>> gst-launch --gst-debug-no-color -v -m videotestsrc do-timestamp=true
is-live=true ! gdppay ! queue ! tcpserversink port=1234 host=localhost
receive pipeline:
>> gst-launch --gst-debug-no-color -v -m tcpclientsrc port=1234
>> host=localhost ! gdpdepay !  queue ! ffmpegcolorspace !
>> (directdrawsink-xvimagesink)
>> They work fine on the Linux machine, but not on the winxp one. The
receive
>> pipeline only gets one frame, it shows it, and then freezes. The
connection is not lost, but it won't try to read more frames from the
socket. I've tried to debug the tcpclientsrc filter with MSVS, but it
loses the thread scope after the first frame is read from the socket.
Similar behaviour is observed when debugging the tcpserversink after
writing the first frame. I wondered if it was a sync problem with
directdrawsink, but tried the same pipeline with testsink and got the same
>> result.
>> ¿Any idea of what's wrong?
>> don't know if it has anything to do with it, but  the tcp packet size
in
>> winxp is 8K, whereas in Linux is 16K.
>> Thanks, any help will be appreciated.
>> BR,
>> --xavier