rtspsrc: long and regular pauses when streaming from wifi action cams

[philippe renon]

I found the cause of the freezes. Had nothing to do with gstreamer itself.
Problem stems from Qt itself : [QTBUG-40332] High ping when QNetworkAccessManager is instantiated - Qt Bug Tracker
  
|  
|   
|   
|   |    |

   |

  |
|  
|   |  
[QTBUG-40332] High ping when QNetworkAccessManager is instantiated - Qt Bug...
   |   |

  |

  |

 
 

    Le Samedi 3 décembre 2016 0h14, philippe renon <philippe_renon at yahoo.fr> a écrit :
 
 

 I am back on this issue. As a refresher, I am seeing long pauses every 10 seconds when playing a rtsp stream from a wifi camera.
The receiver pipeline is:
gst-launch-1.0.exe -v -m rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 ! decodebin ! timeoverlay ! autovideosink
It was mentioned that the server might be sending data as fast as it can and not in real time.Would that be possible when the server is a live camera ?
It was also suggested to try a non slave buffer-mode. I tried all buffer modes:- "none" : video turns into a slide show and the video sink emits warnings about "a lot of buffers are being dropped"- "synced" and "buffer" : both have the pause issue.

I have used wireshark to capture the RTP traffic for a period of 20 seconds (so it includes at least one pause).

What I noticed is that the pipeline sends a Receiver Report every 10 seconds. Around the Receiver Report it seems that the RTP stream is stalling/pausing for a few secs.Here is a typical sequence around the Reveiver Report message:
No.    Time        Source        Destination   Protocol  Length  Info
61777  609.874675  192.168.42.1  192.168.42.3  RTP       68      PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53358, Time=860883236
61778  609.874676  192.168.42.1  192.168.42.3  RTP       240     PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53359, Time=860883236, Mark
61779  609.907745  192.168.42.1  192.168.42.3  RTP       68      PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53360, Time=860886239
61780  609.907746  192.168.42.1  192.168.42.3  RTP       300     PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53361, Time=860886239, Mark
61781  611.344276  192.168.42.3  192.168.42.1  RTCP      126     Receiver Report   Source description   
61782  612.994309  192.168.42.1  192.168.42.3  RTP       68      PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53362, Time=860889242
61783  612.994311  192.168.42.1  192.168.42.3  RTP       435     PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53363, Time=860889242, Mark
61784  612.994311  192.168.42.1  192.168.42.3  RTP       68      PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53364, Time=860892245
61785  612.994312  192.168.42.1  192.168.42.3  RTP       386     PT=DynamicRTP-Type-96, SSRC=0xF8512ADB, Seq=53365, Time=860892245, Mark

Not sure it means anything...
 

    Le Samedi 12 novembre 2016 10h11, Sebastian Dröge <sebastian at centricular.com> a écrit :
 
 

 On Wed, 2016-11-09 at 22:14 +0000, philippe renon wrote:

> element autovideosink1-actual-sink-d3dvideo sent qos event: live: 1;
> running time: 30719164049; stream time: 26558070697; timestamp:
> 30719164049; duration: 33366666 jitter: 3029708354; proportion:
> 0.15581; quality: 1000000; format: ; processed: 609; dropped: 2;
> 
> The rtpjitterbuffer skew is initially around 8 as expected but then
> starts to increase to reach values in the 200.

This suggests that the server is sending data not in real-time but as
fast as it can. Something definitely seems to be odd with the stream
here, but we should also be able to handle that better.

> I am attaching a dot file of the pipeline at the time a qos event was
> sent.
> 
> Is it possible to disable the rtpjitterbuffer used in the rtspsrc
> bin. If if not, is it possible to create a rtspsrc from its
> individual elements with gst-launch ?

No, rtspsrc is more than the combination of the elements it is
containing. Disabling the rtpjitterbuffer is not possible, but you can
specify a different buffer-mode on it. The non-slave ones probably work
better in your case, but come with other problems.

> Would a wireshark log help ?

If someone has time to look into it and come up with a way to handle
the stream, sure.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

 
   

 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170117/be2da61a/attachment.html>