The VideoLAN Forums

Hello,

I'm currently using the VideoLAN suite (VLS and VLC) to stream video signals captured from analogue capture cards. For this project, the aim is to capture multiple sources using a single server and to stream these "live" through a specially designed network. Note that this set-up with the single server is only for prototyping purposes - it is intended to possibly form the basis for a larger system.

To achieve the "live" functionality it is desired to have a latency of less than or equal to 100ms. After some tinkering to compile VLS and VLC and attempting to optimise the streaming process, the signal is delay by around 1 second - a value that is unacceptable for the requirements of the project. My question then is; is it possible to stream the raw video signal without encoding? I am guessing that a large amount of time (as well as CPU processor usage) is dedicated to encoding into either mpeg-4 or mpeg-1. For the system, bandwidth is not an issue - this is the cheap component of the system meaning it would be very possible to support raw streaming if such a process were supported by VLS and VLC.

Thus is it possible, or would it be possible, to stream in this way, without encoding? I would attempt to have a look at such a solution in the code myself, however I am not a strong programmer, having minimal experience in C++ and Java only. Any thoughts would be greatly appreciated and feedback as to whether this is a good idea for further developement.

Thanks

Matthew Pritchard

I just wanted to add that I am also considering using VideoLAN (VLC specifically) to implement a video/audio connection between two systems that requires minimal latency. Frankly even 100ms would be a stretch. Anything that would minimize latency from the video feed to the display would be helpful.

In my case the network link would be an 802.11b or g wireless link. There would be only the two systems in the net.

Just my $.02

Les

54Mbits is not near enough to handle RAW YUV or uncompressed RGB streaming. A raw YUV frame could be say 15Mb. If my math serves correct that leaves you with a bitrate @30fps of 3.6Gbit/s, at a conservative estimate.

Encoding introduces latency, nothing you can do about it...

Yes, 54Mbit/s would not be enough, however the equipment being used for my project has a large bandwidth - using a gigabit network between the server and a switch and then 100Mbit lines to the clients.

If a frame were 15Mb, for 30 frames wouldn't that be a bit rate of 450Mbit/s? If this is correct this would, whilst being a huge waste of bandwidth, still be able to be (theoretically) handled by the used hardware.

I guess that the issue is that I believe that the VideoLAN suite is great software and am very interested in using it - there is a strong backbone there for the networking that I desire. However through use of the programs so far, with both Mpeg-1 and Mpeg-4 encoding there has been a delay of around 1 second which is totally undesirable and 'kills' the objectives of the project.

In my tests so far with both forms of encoding the bit rates received at the client machines floats between 700K and 1.8M generally. I have never seen it rise above 2M. This means that for the hardware being used there is a large, unused bandwidth available. For this project I am therefore not concerned with optimising the bandwidth usuage - it is of a much lower priority, possibly the lowest. If the signal must be 50M to the client I am prepared to accept that to have minimal latency. The latency is the key issue.

I understand also that encoding will input latency into the system, the analogue capture is inputting around 33ms of latency according to the manufacture. My question then would be is a way, or an encoding scheme, that does not take as much time to encode as either of the currently used schemes that are part of VLS and VLC - one that would take a limited time (below 100ms)?.

Regards

Matthew Pritchard

VideoLAN is unable to stream raw video... In fact, I don't think this would be feasible easily...

If a frame were 15Mb, for 30 frames wouldn't that be a bit rate of 450Mbit/s? If this is correct this would, whilst being a huge waste of bandwidth, still be able to be (theoretically) handled by the used hardware.

I guess that the issue is that I believe that the VideoLAN suite is great software and am very interested in using it - there is a strong backbone there for the networking that I desire. However through use of the programs so far, with both Mpeg-1 and Mpeg-4 encoding there has been a delay of around 1 second which is totally undesirable and 'kills' the objectives of the project.

That would be 450 megabytes / sec ~ 3.6Gbits. (Sorry should have said MB)

MPEG4 or any other high compression codec will introduce a lot of latency, true. Have you tried MPEG2 with IFrames only, or a low compression high speed codec such as HUFFYUV?

Don't even think about having latencies <= 100ms with VLC. It just never was designed for this.

Only the player by itself will add about 300ms of delay due to the way the data is processed inside, and the server will likely add about as much if not more depending on the output method and compression.

Of course this latency could be reduced and work is being done towards this goal but 100ms is just not feasible with the current design.

You'd better have a look at videoconferencing software which are designed for low latency streaming.

Hi

I'm very interested on what is the outcome. Can someone share your experience on this? Thank you so much.
I'm also looking at streaming at low latency < 1 Second, bandwidth is also not an issue.

dimX

Less than one second is feasible. However raw video is not really given the humonguous bandwidth involved.

Hi,

Is < 1 sec feasible with default Windows binary distribution?
What is the recommended setup for minimum delay (on high-bandwidth network)?

I'm having trouble using some of the encoders. e.g: "Video MPEG - 2 + MPGA (TS)" results:
Streaming / Transcoding failed:
VLC could not open the encoder.

Should I install something in addition?

Any tips would be welcome.

Just set your buffers really small

Also is it possible to stream "raw" video with RTP?

There is a standard for raw video over RTP but VLC does not currently implement it.

Can you please give advice on the settings to use for video streaming with latency ~1 second (for a LAN)?

I am currently running this command on my "server" (Pandaboard ES running Ubuntu 11.10):

cvlc v4l2:///dev/video0 :v4l2-width=80 :v4l2-height=60 --sout '#transcode{vcodec=mpeg4,acodec=none,vb=200}:standard{access=http,dst=192.168.1.80:8080/stream.mpeg}'

I connect to this stream in from a client computer Google Chrome or Firefox by visiting: http://192.168.1.80:8080/stream.mpeg

The stream works well, however I have a latency of 2.5-3 seconds. Can you please give advice on how to reduce to the ~1sec latency you mentioned?

Thank you