19

I am streaming video and audio from my web cam/microphone over UDP. When I view the stream (even on the same machine) there is a delay of about 4 seconds. I have tried setting the UDP Cache setting to 0, or 1 but it doesn't seem to help. I have tried reducing the video and audio bit-rates, using mono sound and reducing the sample-rate all to no avail.

Does anyone have any ideas how I could reduce the delay, to something better suited to for a video conference, i.e < 1 second?

Is there a setting I can apply to the viewer/streamer that can help?

Thanks,

Marc

Marc
  • 1,541
  • 2
  • 19
  • 29

3 Answers3

9

If you are using rtsp protocol to stream to video/audio, you can adjust the delay at

tools->preferences->all->input/codecs->demuxers->RTP/RTSP->caching value

tools->preferences->all->input/codecs->demuxers->RTP->RTP de-jitter buffer length

ciphor
  • 8,018
  • 11
  • 53
  • 70
  • 8
    Note: `Caching value (ms)` and `RTP de-jitter buffer length (msec)` option are not present in the GUI of the nightly build version VLC 2.1.0-git-20120203-0008. Even the `Input/Codecs->Access modules->UDP` tree item is missing so `UDP caching` option is not available from the GUI. – ecle Feb 13 '12 at 13:27
  • 2
    They call it "network-caching" now, but it doesn't seem to work the same way. I'm unable to get the great latency I got in 1.1.9 (~100-150 ms) in 2.0.4 (far more, becomes unstable for such low values). – Yngve Sneen Lindal Jan 26 '13 at 12:49
  • 1
    @YngveSneenLindal what command line did you use for such good latencies with 1.1.9? – rogerdpack Oct 17 '13 at 21:32
  • 2
    I set --rtsp-caching to anything from 130 to 200. You have to experiment. Remember that this latency can be masked by whatever buffer latency your video source has. I've also had good experiences with 1.1.3 and 1.1.6. They rock in comparison to >= 2.0 – Yngve Sneen Lindal Oct 18 '13 at 09:53
6

Try this.

#!/bin/sh
ETH=eth0

cvlc --miface=$ETH v4l2:///dev/video0 :input-slave=alsa://hw:0,0 :sout=#transcode{vcodec=h264,venc=x264{preset=ultrafast,tune=zerolatency,intra-refresh,lookahead=10,keyint=15},scale=auto,acodec=mpga,ab=128}:rtp{dst=224.10.0.1,port=5004,mux=ts} :sout-keep >/dev/null 2>/dev/null &
vlc1=$!
vlc  --miface=$ETH rtp://224.10.0.1 >/dev/null 2>/dev/null &
vlc2=$!
wait $vlc2
kill -9 $vlc1

I've 2 seconds delay with 720p webcam, it produce about 2.5Mbit/s trafic and load for one core ~30%.

kovserg
  • 86
  • 1
  • 1
4

In my study of VLC streaming with webcam, I got 2-3 seconds delay for UDP multicast stream transcoded with WMV/ASF container + WMV2 codec from Dell's Creative Integrated Webcam with cif video size.

If using MP4/MOV container + H.264 codec, I got twice the delay of the former with the same settings in bitrate, fps and scale.

I disabled audio in both streaming settings since I wasn't interested in it.

I did the study with two VLC versions:

  • VLC 1.1.11 (latest Windows stable release)
  • VLC 2.1.0 (latest nightly build version)

With the first version, I could transcode and stream from the webcam, but it could not playback the stream properly (it just gave a blackened video stream)

With the second version, it worked well for transcoding, streaming and playback.

This study was done on: 

Intel Core 2 Duo T7250
4GB DDR2-667 SDRAM 
SATA 7200 RPM HDD
GeForce 8400M GS 128MB GDDR3 (+ 128MB shared memory = 256MB video memory)
Windows XP Pro SP3
ee.
  • 947
  • 5
  • 5
  • I tried simular settings on my laptop, the processor is an i7, however the graphics card is an integrated Intel one. Do you know if the graphics card processor gets used when streaming video? That could be my problem. – Marc Feb 13 '12 at 11:33
  • 1
    Yes, under Windows, `dshow://` is a DirectShow interface; like any DirectX interfaces, it will use all hardware-accelerated features of a DirectX GPU that can improve performance if they are detected either on the server side or the client side. – ecle Feb 13 '12 at 13:33