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

[filnet]

This pipeline will pause for ~3s every 10s when streaming from a wifi cam (tested with 2 different cam brands).

rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 ! decodebin ! timeoverlay ! autovideosink

This issue is *not* reproducible with gst-launch or the mobile applications dedicated to the particular cams.

I am using an msys2 build of gstreamer 1.10.0 and the pipeline is run within a Qt 5.6.1 app.

I tried decodebin3 and fakesink : same pauses...

One of the cam streams h265, the other one jpeg.

In the Qt application, I tried to mimic what is done in gst-launch to the notable exceptions that:

1/ I use the video overlay API
2/ All bus events are handled synchronously (!)
This includes latency events, overlay events, etc...

Log level 3 yields this repeating pattern of rendering, then a freeze until skew warnings followed by decreasing timestamp warnings:
Note that the pause/freeze happens exactly every 10 seconds.

0:00:06.696025748  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.506932347
0:00:06.729396586  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.540299043
0:00:06.762759977  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.573665740
0:00:06.796128643  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.607032436
0:00:06.829490482  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.640399131
0:00:06.863000955  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.673765827
0:00:06.896212610  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.707132523
0:00:06.929581586  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.740499218
0:00:06.963065994  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:06.773865913
0:00:10.009519675  5096   17982b00 WARN         rtpjitterbuffer rtpjitterbuffer.c:570:calculate_skew: delta - skew: 0:00:03.076607262 too big, reset skew
0:00:10.068884294  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.256601394 < 0:00:10.323816277)
0:00:10.128340451  5096   17982b00 WARN         rtpjitterbuffer rtpjitterbuffer.c:570:calculate_skew: delta - skew: 0:00:01.922682282 too big, reset skew
0:00:10.258822277  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.233469552 < 0:00:10.891049599)
0:00:10.275259457  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.265360892 < 0:00:10.891049599)
0:00:10.306632898  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.296691913 < 0:00:10.891049599)
0:00:10.340349720  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.327394202 < 0:00:10.891049599)
0:00:10.378309886  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.357797606 < 0:00:10.891049599)
0:00:10.415688241  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.387509904 < 0:00:10.891049599)
0:00:10.441272737  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.416511180 < 0:00:10.891049599)
0:00:10.471885323  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.445257516 < 0:00:10.891049599)
0:00:10.520637703  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.473325486 < 0:00:10.891049599)
0:00:10.539163818  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.500763046 < 0:00:10.891049599)
0:00:10.577593467  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.528117597 < 0:00:10.891049599)
0:00:10.605983069  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.554982983 < 0:00:10.891049599)
0:00:10.642451626  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.581471561 < 0:00:10.891049599)
0:00:10.677846857  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.608154940 < 0:00:10.891049599)
0:00:10.715108540  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.634675952 < 0:00:10.891049599)
0:00:10.738431263  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.661180636 < 0:00:10.891049599)
0:00:10.786688404  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.688138936 < 0:00:10.891049599)
0:00:10.807724842  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.715290786 < 0:00:10.891049599)
0:00:10.843468229  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.742765600 < 0:00:10.891049599)
0:00:10.875957506  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.770932558 < 0:00:10.891049599)
0:00:10.906384224  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.799541281 < 0:00:10.891049599)
0:00:10.948233062  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.828660596 < 0:00:10.891049599)
0:00:10.977393758  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.858487781 < 0:00:10.891049599)
0:00:11.015278211  5096   17982a70 WARN            videodecoder gstvideodecoder.c:2767:gst_video_decoder_prepare_finish_frame:<avdec_h264-0> decreasing timestamp (0:00:10.888815991 < 0:00:10.891049599)
0:00:13.069642666  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:12.880490649
0:00:13.103571422  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:12.913857316
0:00:13.136318869  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:12.947223982
0:00:13.169681329  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:12.980590649
0:00:13.203539647  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:13.013957316
0:00:13.236428280  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:13.047323982
0:00:13.269793843  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:13.080690649
0:00:13.303543867  5096   17982a70 INFO            d3dvideosink d3dhelpers.c:1905:d3d_render_buffer:<autovideosink0-actual-sink-d3dvideo> Render 0:00:13.114057316

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2016-11-03 at 22:28 +0000, philippe renon wrote:
> This pipeline will pause for ~3s every 10s when streaming from a wifi
> cam (tested with 2 different cam brands).
>
> rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 !
> decodebin ! timeoverlay ! autovideosink
>
> This issue is *not* reproducible with gst-launch or the mobile
> applications dedicated to the particular cams.

If it's not reproducible with gst-launch, how can it be reproduced and
what is the difference in your application?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

Yes, it is only reproducible in the Qt app. Makes it difficult to track it down.

I tried to spot differences between gst-launch and the app. Not successful yet...

I think that the fact that the pause is every 10s sharp tells us something.

Cheers,

Philippe.

Le Vendredi 4 novembre 2016 17h01, Sebastian Dröge <[hidden email]> a écrit :

On Thu, 2016-11-03 at 22:28 +0000, philippe renon wrote:

> This pipeline will pause for ~3s every 10s when streaming from a wifi
> cam (tested with 2 different cam brands).
>
> rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 !
> decodebin ! timeoverlay ! autovideosink
>
> This issue is *not* reproducible with gst-launch or the mobile
> applications dedicated to the particular cams.

If it's not reproducible with gst-launch, how can it be reproduced and
what is the difference in your application?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

To speed up my testing, I am trying to setup a small rtsp server using gstreamer.

But the following pipeline fails:

$ gst-launch-1.0.exe --gst-debug=3 videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96
Setting pipeline to PAUSED ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
0:00:00.043439433 11828    3205320 FIXME                default gstutils.c:3825:gst_pad_create_stream_id_internal:<videotestsrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
New clock: GstSystemClock
Redistribute latency...
0:00:00.078413588 11828    3205320 WARN                 basesrc gstbasesrc.c:2950:gst_base_src_loop:<videotestsrc0> error: Internal data stream error.
0:00:00.078460444 11828    3205320 WARN                 basesrc gstbasesrc.c:2950:gst_base_src_loop:<videotestsrc0> error: streaming stopped, reason not-linked (-1)
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../../../../gstreamer-1.10.0/libs/gst/base/gstbasesrc.c(2950): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason not-linked (-1)
Execution ended after 0:00:00.035130546
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

I can provide level 4 debug output but not beyond that as the pipeline freezes if level > 4.

Again, please note that I am using a *msys2* build of gstreamer 1.10.

Msys2 comes with gcc 6.2.0, glib2 2.50.1 and glib-networking 2.50.0.

Philippe.

Le Vendredi 4 novembre 2016 19h08, philippe renon <[hidden email]> a écrit :

Yes, it is only reproducible in the Qt app. Makes it difficult to track it down.

I tried to spot differences between gst-launch and the app. Not successful yet...

I think that the fact that the pause is every 10s sharp tells us something.

Cheers,

Philippe.

Le Vendredi 4 novembre 2016 17h01, Sebastian Dröge <[hidden email]> a écrit :

On Thu, 2016-11-03 at 22:28 +0000, philippe renon wrote:

> This pipeline will pause for ~3s every 10s when streaming from a wifi
> cam (tested with 2 different cam brands).
>
> rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 !
> decodebin ! timeoverlay ! autovideosink
>
> This issue is *not* reproducible with gst-launch or the mobile
> applications dedicated to the particular cams.

If it's not reproducible with gst-launch, how can it be reproduced and
what is the difference in your application?

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Sun, 2016-11-06 at 11:51 +0000, philippe renon wrote:
>
> To speed up my testing, I am trying to setup a small rtsp server using gstreamer.
>
> But the following pipeline fails:
>
> $ gst-launch-1.0.exe --gst-debug=3 videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96
> [...]

This does not set up an RTSP server but is just an incomplete pipeline
without a sink.

Try using the test-launch example from gst-rtsp-server/examples, e.g.
  ./test-launch "( videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )"

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

I did try test-launch but was missing the parentheses and thus getting assertions that the video source element was not a bin and other such assertions.

Will try with parentheses...

And thanks for the quick and to the point answers.

Le Lundi 7 novembre 2016 10h26, Sebastian Dröge <[hidden email]> a écrit :

On Sun, 2016-11-06 at 11:51 +0000, philippe renon wrote:
>
> To speed up my testing, I am trying to setup a small rtsp server using gstreamer.
>
> But the following pipeline fails:
>
> $ gst-launch-1.0.exe --gst-debug=3 videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96
> [...]

This does not set up an RTSP server but is just an incomplete pipeline
without a sink.

Try using the test-launch example from gst-rtsp-server/examples, e.g.
  ./test-launch "( videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )"

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

Thanks to your help Sebastian, I was able to test with a local gstreamer rtspsrc server and the Qt client works like a charm.

The setup was:

server:  ./test-launch.exe "( videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )"
client:  gst-launch-1.0.exe -v -m rtspsrc location=rtsp://127.0.0.1:8554/test latency=30 ! decodebin ! timeoverlay ! autovideosink

I also tested with success a simple rtp scenario:

server : gst-launch-1.0.exe -v -m videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=5000
client : gst-launch-1.0.exe -v -m udpsrc port=5000 ! application/x-rtp,payload=96,clock-rate=90000 ! rtpjitterbuffer ! rtph264depay ! decodebin ! videoconvert ! timeoverlay ! autovideosink

But playing a rtsp stream from a wifi "action" camera still has those longish pauses every 10s.

And contrary to what I wrote earlier, I can reproduce it with gst-launch 1.10 with both the msys2 build and the official distribution.

client : gst-launch-1.0.exe -v -m rtspsrc location=rtsp://192.x.x.x/AmbaStreamTest latency=30 ! decodebin ! timeoverlay ! autovideosink

Some findings:

Each time the pipeline "pauses", the video sink emits a qos event and drops one frame:

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.

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 ?

Would a wireshark log help ?

Le Lundi 7 novembre 2016 11h37, philippe renon <[hidden email]> a écrit :

I did try test-launch but was missing the parentheses and thus getting assertions that the video source element was not a bin and other such assertions.

Will try with parentheses...

And thanks for the quick and to the point answers.

Le Lundi 7 novembre 2016 10h26, Sebastian Dröge <[hidden email]> a écrit :

On Sun, 2016-11-06 at 11:51 +0000, philippe renon wrote:
>
> To speed up my testing, I am trying to setup a small rtsp server using gstreamer.
>
> But the following pipeline fails:
>
> $ gst-launch-1.0.exe --gst-debug=3 videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96
> [...]

This does not set up an RTSP server but is just an incomplete pipeline
without a sink.

Try using the test-launch example from gst-rtsp-server/examples, e.g.
  ./test-launch "( videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )"

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

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 <[hidden email]> 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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[filnet]

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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel