the humble videotestsrc element is magical !!!

[Andres Gonzalez]

Hi,

I am trying to stream using tcpserversink and the various muxers.  For a server example:

gst-launch-1.0 -vv videotestsrc is-live=true ! queue ! videoconvert ! x264enc byte-stream=true ! h264parse config-interval=1 ! queue ! matroskamux ! queue leaky=2 ! tcpserversink port=50010 host=0.0.0.0 recover-policy=keyframe sync-method=latest-keyframe sync=false

For the client on a different local box:

gst-launch-1.0 -vv tcpclientsrc host=192.168.1.80 port=50010 typefind=true do-timestamp=false ! matroskademux ! typefind ! avdec_h264 ! autovideosink

this works perfect. However, if I use any other source element in the server pipeline, source elements that are known to work on the server box, the client errors out with:

ERROR: from element /GstPipeline:pipeline0/GstTCPClientSrc:tcpclientsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstTCPClientSrc:tcpclientsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.

I have looked at the dot files created by the server gst-launch for both cases, that is, the exact same pipeline but using different src elements. In other words, the pipeline is exactly the same from the first queue element to the end of the pipeline.   The only difference I find is that the pipeline using videotestsrc inserts an additional capsfilter element immediately after it. The linking and state transitions on the server also appear to be the same for both cases.

So it appears that these other server sources are doing something different than what the videotestsrc is doing, and that difference is effecting the negotiation on the client.

Any ideas on how I should configure the server sources so the client will negotiate correctly?  

Thanks,

-Andres

[BGraaf]

Hi Andreas,

May you give us the total server and client pipelines for the not working
scenario?

Bernhard

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]]
Im Auftrag von Andres Gonzalez
Gesendet: Donnerstag, 4. August 2016 18:35
An: [hidden email]
Betreff: the humble videotestsrc element is magical !!!

Hi,

I am trying to stream using tcpserversink and the various muxers.  For a
server example:

gst-launch-1.0 -vv videotestsrc is-live=true ! queue ! videoconvert !
x264enc byte-stream=true ! h264parse config-interval=1 ! queue ! matroskamux
! queue leaky=2 ! tcpserversink port=50010 host=0.0.0.0
recover-policy=keyframe sync-method=latest-keyframe sync=false

For the client on a different local box:

gst-launch-1.0 -vv tcpclientsrc host=192.168.1.80 port=50010 typefind=true
do-timestamp=false ! matroskademux ! typefind ! avdec_h264 ! autovideosink

this works perfect. However, if I use *any* other source element in the
server pipeline, source elements that are known to work on the server box,
the *client* errors out with:

ERROR: from element /GstPipeline:pipeline0/GstTCPClientSrc:tcpclientsrc0:
Internal data flow error.
Additional debug info:
gstbasesrc.c(2943): gst_base_src_loop ():
/GstPipeline:pipeline0/GstTCPClientSrc:tcpclientsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.

I have looked at the dot files created by the server gst-launch for both
cases, that is, the exact same pipeline but using different src elements. In
other words, the pipeline is exactly the same from the first queue element
to the end of the pipeline.   The only difference I find is that the
pipeline using videotestsrc inserts an additional capsfilter element
immediately after it. The linking and state transitions on the server also
appear to be the same for both cases.

So it appears that these other server sources are doing something different
than what the videotestsrc is doing, and that difference is effecting the
negotiation on the client.

Any ideas on how I should configure the server sources so the client will
negotiate correctly?  

Thanks,

-Andres



--
View this message in context:
http://gstreamer-devel.966125.n4.nabble.com/the-humble-videotestsrc-element-
is-magical-tp4678965.html
Sent from the GStreamer-devel mailing list archive at Nabble.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

[Andres Gonzalez]

Thank you Bernhard for your response.

This pipeline appears to work correctly on the server but causes the client to exit in error:

gst-launch-1.0 -vv decklinkvideosrc device-number=4 mode=10 ! queue ! videoconvert ! x264enc byte-stream=true ! "video/x-h264,stream-format=byte-stream" ! h264parse config-interval=1 ! queue ! matroskamux streamable=true ! queue leaky=2 ! tcpserversink port=50010 host=0.0.0.0 recover-policy=keyframe sync-method=latest-keyframe sync=false

This pipeline also appears to work correctly on the server but causes the client to exit in error:

gst-launch-1.0 -vv v4l2src device=/dev/video0 typefind=true ! queue ! videoconvert ! x264enc byte-stream=true ! h264parse config-interval=1 ! queue ! matroskamux streamable=true ! queue leaky=2 ! tcpserversink port=50010 host=0.0.0.0 recover-policy=keyframe sync-method=latest-keyframe sync=false

Actually, these are just temporary sources for me.  I am working on a native app that uses the API and not gst-launch. I have several GStreamer RTP/RTCP streams working correctly using appsrc for the sources, and I am currently in the process of adding TCP streaming for these appsrc sources. But I could not get my appsrc-based pipelines to work correctly when I used those same basic appsrc-based pipelines (but modified the sink elements for tcpserversink instead of the RTP/RTCP sinks).  

So I concluded that TCP streaming and tcpserversink was more complicated than I originally thought, or at least I am missing some key concepts.  So I went back to playing with these gst-launch pipelines so I could figure out what I was doing wrong. Debugging GStreamer gst-launch scripts is much easier than debugging GStreamer API routines in my native C++ app.   :-)

Thanks for your help,

-Andres

[Jan Alexander Steffens]

On Thu, Aug 4, 2016 at 7:34 PM Andres Gonzalez <[hidden email]> wrote:

gst-launch-1.0 -vv videotestsrc is-live=true ! queue ! videoconvert !
x264enc byte-stream=true ! h264parse config-interval=1 ! queue ! matroskamux
! queue leaky=2 ! tcpserversink port=50010 host=0.0.0.0
recover-policy=keyframe sync-method=latest-keyframe sync=false

this works perfect. However, if I use *any* other source element in the
server pipeline, source elements that are known to work on the server box,
the *client* errors out

Try removing the leaky queue. I assume whatever source you're using creates much bigger and/or more frequent buffers than videotestsrc's default 320x240@30, and immediately overfills it.

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

[Tim Müller]

On Fri, 2016-08-05 at 17:36 +0000, Jan Alexander Steffens wrote:

> Try removing the leaky queue. I assume whatever source you're using
> creates much bigger and/or more frequent buffers than videotestsrc's
> default 320x240@30, and immediately overfills it.

Yes indeed, matroska is not really designed for lossy transports, so if
you e.g. happen to drop header packets that's not going to work.

tcpserversink will drop things if clients if needed, if clients read
too slowly.

Cheers
 -Tim

--

Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Andres Gonzalez]

Your assumption was indeed correct. When I removed the leaky property the stream works.
Thank you for your help.
-Andres

[Andres Gonzalez]

Tim,
Thank you for that additional information. Now I know "why" the leaky queue caused problems.
-Andres