-
Notifications
You must be signed in to change notification settings - Fork 59
UltraGrid FAQ
- Estimating available bandwidth
- Usage
- Recommended test procedure
- Determining max MTU size
- How can I ensure the network works correctly?
- Which is the most suitable option for HD over Gigabit Ethernet links?
- I cannot see any video
- I am experiencing problems with image quality or it seems to I do not receive video at all (although data comes)
- Windows - bind returns WSAEACCES error
- Video is displayed twice, one underneath anoter with both part vertically shrinked
- Video is "tearing" - top part is a frame ahead of the bottom
- Video is not smooth when panning with a camera
Answer to this question heavily depends on target usage - mainly if you intend to use compression and which. Generally, for uncompressed video, you will need 10Ge connectivity and properly set network (buffers, etc.) but the overall system needn't be so powerful. For GPU-based compressions, you will need an appropriate graphic card. However, compression rather reduces HW requirements to other part of computer, because the BW is lower, so for eg. displaying DXT compressed video it will suffice a rather low end machine.
Another parameter that needs to be taken into account is if we need to operate as a sender/receiver only, or in a duplex mode. Moreover, if you want to have videos in both direction compressed you need to keep in mind that you will need a good PCIe bandwidth (each video goes twice through PCIe). Otherwise, you may loose packets, because network adapter has only limited FIFO buffers and it may not be able to access the bus for a while.
For estimation of available network bandwidth you can use tool called iperf. For better results on links capable of gigabits per seconds please use patched version of iperf available here.
Server
./iperf-2.0.4/src/iperf -u -s -l 8500 -i 1 -w 16M
Client
./iperf-2.0.4/src/iperf -u -c <serverIP> -l 8500 -i 1 -w 16M -b 2G -d
-
-u - means UDP
-
-s - server mode
-
-c
- client mode with address of the server -
-l 8500 - use MTU 8500B
-
-i 1 -print stats after 1 seconds
-
-w 16M - UDP buffer size (has to be less than net.core.wmem_max, this value can be increased with cmd 'sysctl -w net.core.rmem_max=33554432')
-
-b 2G - tested bandwidth, here 2 Gbps
-
-d - do bidirectional test
-
-t number of seconds to run the test
- Estimate bandwidth that could go through with negligible losses (less than 0.1%), in the above example 2 Gbps
- if the result of test was without significant loss, increase tested bandwidth
- if there were significant packet loss, use lower bandwidth
- test until you get maximal bandwidth with loss ratio suitable for application
- for UltraGrid, 0.1% packet loss is usually acceptable, for uncompressed video it can be somewhat more
- if you use FEC with UltraGrid, it can be significantly more, eg. up to 10%
You can use following parameter to determine MTU size between sender and receiver:
ping -M do -s 8500
or in Windows
ping -f -l 8500
Checks whether 8500B packets can be transmitted from sender to receiver.
The directions to check your network can be found at this page.
Over 1GE links you usually cannot use uncompressed HD video. Instead, you have these possibilities:
- dual-link - requires 2 edge-wise disjoint paths between a sender and a receiver. Moreover, it will be needed to use Jumbo frames.
- DXT1 compression - it is suitable for 1GE links even with standard Ethernet (1500B) frames.
- DXT5 YCoCg compression offers bandwidth around 500 Mbps for 1080p@30 at higher quality than DXT1 compression but you will need Jumbo frames
First, we need to check if the video keeps comming. You can use slurm tool to monitor incomming/outgoing traffic:
slurm -i eth<n>
You can also check if the dataflow matches with expected - you should see some 125MB/s (slurm uses bytes, not bits) for uncompressed 1080p@30fps 8-bit video on both sender and receiver.
There is also possibility to test video via local loop to check if there are you can see the video on sender. If so, there is probably a network problem or problem with receiver. You can run it like this:
./bin/uv -t decklink:<mode> -d gl -m 9000 localhost
I am experiencing problems with image quality or it seems to I do not receive video at all (although data comes)
-
is processor affinity set for each UltraGrid thread
taskset -pc <proc_n> <pid_n>(Linux) -
you can also check output of
topcommand, if UG doesn't use whole processor (except of compression)
The following is important mostly for uncompressed or any other high-bitrate transfers. Not much relevant for low-bitrate transfers.
-
are large enough receiving buffers available to hold at least a frame? (sysctl net.inet.udp.recvspace (Mac)/net.core.rmem_max(Linux))
-
are jumbos set on the interface
ifconfig eth<n> | fgrep MTU -
Ultragrid uses Jumbo frames (-m 8500) option
-
are jumbos enabled along the whole path? Works for both Linux and macOS:
ping -M do -s 8500 target_ip -
are capture card and network interface card in appropriate PCIe slots?
-
are PCIe lanes assigned appropriately (macOS)?
Port that UltraGrid wants to bind may be occupied by another service - open command prompt and "netstat -anbo". From the output check if the UDP ports 5004-5007 (default UG ports for video and audio) are not used by another service. If so, stop the running service or use different set of ports for UltraGrid.
It is most likely due the fact you interpred interlaced video as progressive. To correct this, check sending mode on sender and if there is set progressive video, change it to the interlaced one wit same properties (width, height, FPS).
Please check this page.
This is most likely due to low number of FPS. When using progressive video or displaying interlaced one as a progressive (eg. to a normal computer display), 25 or 30 FPS isn't sufficient. There are some approaches do deal with it:
- use progressive video at a rate of 50/60 FPS. This needs your camera supporting it and also grabbing card being able to capture - if grabbing through SDI, you will need either dual-link SDI or 3G compatible
camera and grabbing card.
- keep interlaced video and display it as interlaced - this is not possible with SW displays (OpenGL/SDL) but almost always when displaying with an HW card (even eg. Intensity HDMI a common computer display) the
display knows how to deal with interlaced content and the movement is smooth
- when using OpenGL and SDL, there is also a possibility to use a postprocessor which doubles frame-rate of interlaced content in a mean that ordinary TV does (switching both fields every 1/2 of frame time):
uv -p double_framerate -d gl <senderIP>
NB that your graphic system needs to be able to process 50/60 frames per sec, which cannot be always true (mainly with SDL).
The best performance will be achieved if you run UltraGrid on single node because all data will be local for that node, eg. if you have NUMA with 4 processors, each with 12 logical cores, run (Linux specific):
taskset -c 0-11 uv [params]
to keep UltraGrid on a single node.
Similar effect can be achieved also in Windows.
Yes, it is no problem in Linux. But bear in mind that you will need to pass $DISPLAY variable if you need the Xserver. In that case, you also need to be the user logged to Xserver, or the logged user will need to enter
xhost +
On Macs it is bit different - you will also need to be logged to Mac OS X desktop to use run UltraGrid remotelly.
- ... contact the development team: [email protected]
- If you have a problem, please, run our
ultragrid-bugreport-collect.shscript and send us its output (ultragrid-bugreport.txt.gz) in order to allow us detect the problem.
If you have any technical or non-technical question or suggestion please feel free to contact us at