After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 424713 - tcpserver/tcpclient with ximagesink, stream start is delayed
tcpserver/tcpclient with ximagesink, stream start is delayed
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: dont know
0.10.12
Other All
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-31 01:02 UTC by Henrik Olsson
Modified: 2007-10-17 16:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Description Henrik Olsson 2007-03-31 01:02:00 UTC 
Please describe the problem:
When using a tcpserversink and a tcpclientsrc outputting to an ximagesink/xvimagesink the output window displays one frame then freezes for a while before playing the stream.

Steps to reproduce:
1. run "gst-launch videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 ! tcpserversink port=1234 protocol=gdp"
2. run "gst-launch tcpclientsrc protocol=gdp port=1234 ! ximagesink"



Actual results:
Window popups with one frame from the videotest, freezing with it for a few seconds

Expected results:
Window popups with the videotest stream being played

Does this happen every time?
Yes, different freeze lengths though.

Other information:
Comment 1 Wim Taymans 2007-10-17 16:39:08 UTC 
This is intended behaviour. What happens is that the buffers (along with timestamps) are reconstructed at the receiver side and then displayed according to the receiver clock, which is totally different from the sender clock or base_time. To get this pipeline working as intended, the app should distribute the same clock to both pipelines (or use GstNetTimeProvider, GstNetClientClock) and set the same base_time on both pipelines.