17

Here is what I'm trying:

gst-launch -v udpsrc port=1234 ! fakesink dump=1

I test with:

gst-launch -v audiotestsrc ! udpsink host=127.0.0.1 port=1234

And everything works fine, I can see the packages arriving from the audiotestsrc

Now lets test with the webcam source:

gst-launch -v v4l2src device=/dev/video0 ! queue ! videoscale method=1 ! "video/x-raw-yuv,width=320,height=240" ! queue ! videorate ! "video/x-raw-yuv,framerate=(fraction)15/1" ! queue ! udpsink host=127.0.0.1 port=1234

And nothing happens, no package appears in the dump.

Here is a logdump of what verbose shows in the server.

Does anyone have a clue on this?

Improve this question
1
  • 1
    Forgot to mention: replacing udpsink with autovideosink for example I can see the webcam just fine
    – David Benko
    Oct 6, 2011 at 0:33

3 Answers 3

Reset to default
21

Try these (You may have to install gstreamer-ugly plugins for this one)

UDP streaming from Webcam (stream over the network)

gst-launch v4l2src device=/dev/video0 ! 'video/x-raw-yuv,width=640,height=480' !  x264enc pass=qual quantizer=20 tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 port=1234

UDP Streaming received from webcam (receive over the network)

gst-launch udpsrc port=1234 ! "application/x-rtp, payload=127" ! rtph264depay ! ffdec_h264 ! xvimagesink sync=false

Update

To determine the payload at the streaming end simply use verbose option with gst-launch -v ...

Improve this answer
4
  • 3
    It is a good idea to include a queue between encoding and streaming. Allows for better timing and less jittery playback.
    – Atilla Filiz
    Jan 22, 2013 at 12:52
  • @AtillaFiliz I tend to use 'queue' when working with 'tee' although your point may be valid in this case.
    – enthusiasticgeek
    Jan 22, 2013 at 18:07
  • I did some experiments of my own. I used some specialized hardware on the encoder side, and adding a queue did not make any difference. However, playback quality improved a lot when I added a queue between rtpdepay and ffdec.
    – Atilla Filiz
    Jan 24, 2013 at 11:58
  • 3
    A queue element decouples the flow by sending on data in another thread. See gstreamer.freedesktop.org/data/doc/gstreamer/head/… and gstreamer.freedesktop.org/wiki/…
    – enthusiasticgeek
    Jan 24, 2013 at 16:26
4

Maybe packets are too large for udp? They are limited to 64K. Try resizing frames to really small size to check if this is the reason. If so, you may be interested in some compression and payloaders/depayloaders (gst-inspect | grep pay).

Improve this answer
-1

gstreamer1-1.16.0-1.fc30

gst-launch-1.0 -v filesrc location=/.../.../.../sample-mp4-file.mp4 ! qtdemux ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink port=8888 host=127.0.0.1

https://en.wikipedia.org/wiki/RTP_audio_video_profile

Improve this answer
1
  • 1
    Can you explain your answer a bit?
    – John
    Nov 28, 2020 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.