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 651161 - Rtsp seek video gets stuck
Rtsp seek video gets stuck
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.29
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-26 15:15 UTC by Nuno Mota
Modified: 2014-11-25 17:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nuno Mota 2011-05-26 15:15:04 UTC
While playing an Rtsp stream with a Transport stream file, Gstreamer is able to play/pause. However when seeking, the command is sent, the server starts streaming from the desired range, but the client's video gets stuck for some reason. Only a few minutes later it starts to work!
Comment 1 Sebastian Dröge (slomo) 2011-05-27 06:37:34 UTC
Sounds like a problem with segment and timestamp handling on the client side.

Could you provide a server and client side testcase for this? Or a debug log of the client with GST_DEBUG=5?
Comment 2 Nuno Mota 2011-05-29 14:01:45 UTC
I tried to make a debug log, but got over 100mb per file. It's quite confusing the output and i'm not that familiar with the low level implementation of Gstreamer. I also hosted a couple of files to test. Here: http://paginas.fe.up.pt/~ee05154/samples/ . I would suggest using Live555 Media Server, the server i'm currently using, with the onDemandRTSPServer.

Maybe you can help me decoding this log file. I'm not able to get the big picture. I think gstreamer can't sync audio and video so it doesn't display even if it is receiving RTP packets.

I'm guessing the problem starts here:
0:00:09.823286760  3815 0x7f2d00304290 WARN                basesink gstbasesink.c:3626:gst_base_sink_chain_unlocked:<audio-sink-actual-sink-pulse> warning: Received buffer without a new-segment. Assuming timestamps start from 0.

The log link follows:
http://feupload.fe.up.pt/get/JIQ1gLJnpPACdqH
Comment 3 Nuno Mota 2011-06-11 17:22:28 UTC
Any updates on this matter? As anyone been able to figure out anything through those logs? 

Regards,
Nuno
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-06-13 10:55:11 UTC
(In reply to comment #2)
> I tried to make a debug log, but got over 100mb per file. It's quite confusing
> the output and i'm not that familiar with the low level implementation of
> Gstreamer. I also hosted a couple of files to test. Here:
> http://paginas.fe.up.pt/~ee05154/samples/ . I would suggest using Live555 Media
> Server, the server i'm currently using, with the onDemandRTSPServer.
> 
> Maybe you can help me decoding this log file. I'm not able to get the big
> picture. I think gstreamer can't sync audio and video so it doesn't display
> even if it is receiving RTP packets.

gst-debug-viewer from cgit.freedesktop.org i helpful to read the log (use GST_DEBUG_NO_COLOR=1 for the logs). Also logs can be uploaded after bzip'ping them.

> 
> I'm guessing the problem starts here:
> 0:00:09.823286760  3815 0x7f2d00304290 WARN                basesink
> gstbasesink.c:3626:gst_base_sink_chain_unlocked:<audio-sink-actual-sink-pulse>
> warning: Received buffer without a new-segment. Assuming timestamps start from
> 0.

That confirms what sebastian was guessing.

> 
> The log link follows:
> http://feupload.fe.up.pt/get/JIQ1gLJnpPACdqH
Comment 5 Sebastian Dröge (slomo) 2013-08-21 18:50:24 UTC
Is this still a problem with latest GIT master? There were many time related changes to the MPEG TS demuxer.
Comment 6 Tim-Philipp Müller 2014-11-25 17:58:05 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!