AW: Re: AW: the humble videotestsrc element is magical !!!

[BGraaf]

Why so complicated? If you have only video source, why not source ! queue ! tcpserversink.

The rest could be done on client side.

Von meinem Samsung Galaxy Smartphone gesendet.

-------- Ursprüngliche Nachricht --------

Von: Andres Gonzalez <[hidden email]>

Datum: 04.08.16 20:24 (GMT+01:00)

An: [hidden email]

Betreff: Re: AW: the humble videotestsrc element is magical !!!

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



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/the-humble-videotestsrc-element-is-magical-tp4678965p4678969.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]

That is a very good point, and GStreamer is amazing at facilitating simplicity over complexity.

But when I cannot get a pipeline to work as expected, I always assume that I am not setting the appropriate element properties correctly, or the design of the pipeline is not optimal. So I proceed to explicitly set more properties or add more elements to the pipeline as I get the pipeline working like I want, and all of this then adds complexity to the pipeline.

For me, the only way to learn GStreamer is to play with complex pipelines not the simple ones. GStreamer does so much under-the-covers that it is difficult to understand what is really going on if I use only simple pipelines.

But your point is well taken, I should always go for the simple and otherwise avoid unneeded complexity.

Thanks,

-Andres