I have been trying to figure out how to stream my desktop (over LAN) using VLC and to achieve the lowest latency possible (<100ms).
The goal is to have another computer receive the stream and potentially play games while streaming (i.e playing game from PC1 on the PC beside the TV).
What settings should I use? I have tried multiple approaches but have yet to succeed.
EDIT: I am open to using something other than VLC as well.
I have also tried the same with VLC and couldn't ever get latency bellow 3 seconds. FFmpeg did wonders and finally provided a latency bellow 1 second.
mpeg2video and UPD provided the best results, RTP latency felt a bit worse but very close. Moving to x264 improves quality in exchange for a bit more latency, but that really depends on how much dynamic content is there and how fast the CPU is. I only got x264 working with UDP, but there must be a way to do it with RTP.
I'm not sure it's feasible for playing. The server will be under a heavy workload and latency will be noticeable - at least on Linux, don't know about windows.
On Linux try one of the following commands:
$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec mpeg2video -b:v 8000 -f rtp rtp://192.168.0.10:1234
or
$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec libx264 -preset ultrafast -tune zerolatency -crf 18 -f mpegts udp://192.168.0.10:1234
Adjust for screen resolution (-s <your resolution>), refresh rate (-r <fps>), bandwidth (-b:v <bits/s>), quality (-crf 18 or -qp 18, the lower the better), and target ip:port.
If running Windows use dshow in place of x11grab.
Watch it using ffplay udp://192.168.0.10:1234 or ffplay sdp://192.168.0.10:1234.
Mind you that none of those options will stream sound. I was unable to get such low latencies when streaming audio as well. It might be doable, I just didn't figured out how.
The most responsive client was ffplay, VLC introduced too much latency even with its network cache set to zero - with such cache it actually got worse, since it tried to 'resync' the stream too often.
If you need further details I made a post about my findings. Hope it helps. I appreciate any feedback. ^_^
Related
I am trying to capture the live packets from available interface. My code is developed in go lang and for capturing purpose, I am using google's go packet library.
I am able to capture packets but I am unable to get precise timestamp.
If I run the below command and see the timestamp in wireshark, I am getting accurate difference between timestamps.
tcpdump -i device0 -j adapter_unsynced -w captureOnMachine.pcap
But, If I generate tcp dump using go packet library there is no precision.
I looked over the internet about adapter_unsynced command and saw
PCAP_TSTAMP_ADAPTER_UNSYNCED - adapter_unsynced
Time stamp provided by the network adapter on which the cap-
ture is being done. This is a high-precision time stamp; it
is not synchronized with the host operating system's clock.
Can we get same setting in docker or go packet library.
I want to constantly monitor TCP data coming from a particular source.
I am using this command in a cygwin mintty xterm on a Windows server.
tshark.exe -i 5 -f "tcp port 1234" -T fields -e data | xxd -r -p
This works perfectly as I get a scrolling window of ASCII that is the data being sent to me. When that connection fails (which is what I am trying to debug) then the last data sent is shown in the cygwin window.
However, I notice that the Tshark memory usage is constantly creeping up and after a few hours is quite large.
What can I do about this? I would like to leave this running for several days.
You might want to try modifying your tshark command-line options to include the -b files:N option (and possibly other -b options as well for duration and/or filesize) to start a ring buffer. Doing so will cause tshark to discard its internal state whenever it rolls to the next file in the ringbuffer. Discarding state means freeing all memory associated with that state information, so at least in theory, you can capture forever.
For more information, feel free to read the Wireshark blog article, "To Infinity and Beyond! Capturing Forever with Tshark" by Evan Huus, one of the Wireshark core developers and the person responsible for implementing this feature to discard state information.
Setup and observation
I have a PC equipped with an Intel i350 T2 NIC where I would like to capture on both interfaces simultaneously using tcpdump. Both interfaces are connected to a 100mbit HUB (sic!) which forwards various traffic from an external traffic source to both interfaces at the "same time", so I can measure the difference of the timestamps done by the respective ethernet MACs.
Capturing simultaneously with:
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth2 -w test_eth2.pcap
user#rt:~$ sudo tcpdump -j adapter --time-stamp-precision nano -B 1048576 -i eth3 -w test_eth3.pcap
After that I merge the two files together to compare the timestamps:
user#rt:~$ mergecap -F nseclibpcap -w merged.pcap test_eth2.pcap test_eth3.pcap
Wireshark then shows me, that for a few packets I get a timestamp diff of the duplicate frames of around 20-40nsec (which is nice and sufficient for my application!).
But there are also lots of frames which show a difference of up to tens of microseconds when comparing the respective duplicates.
Environment
user#rt:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
user#rt:~$ uname -r
3.19.0-28-generic
user#rt:~$ lscpu | grep "Model name"
Model name: Intel(R) Core(TM) i7-4790 CPU # 3.60GHz
Questions
How/Who does the syncing of the adapter clock to CLOCK_REALTIME (I presume)
How often does this syncing occur.
Is there some room for tweaking without too much effort?
Is it possible to use e.g. phc2sys to sync all adapter clocks to CLOCK_REALTIME?
Would (4) interfere with the mechanisms done by (1)?
THX for help or pointing out my mistakes!
From a quick glance at igb_ethtool.c your NIC indeed seems to be capable of hardware timestamping. The jitter you observe (20-40ns) is just in the range of the expected PHY jitter from synchronizing to the Ethernet clock. (For 100Mbit the clock is 25MHz or 40ns.)
So far looking great, thanks to Intel. Not many NICs/drivers have this capability.
Now the bad part: I doubt anything is syncing CLOCK_REALTIME to the NIC adapter clock at the moment. The clocks are probably free-running at a slightly different frequencies. Those oscillators are usually specified at 50ppm, typical drifts will be around 5ppm, which means they will drift apart by ~5us every second, varying with room temperature. Keep that in mind when using the nanosecond precision. If your system uses NTP you may even see NTP drift adjustments happening.
But the good news is that you probably don't need to synchronize them, unless you really want absolute timestamps. The main reason why your NIC supports hardware timestamping at all is probably to support IEEE1588 PTP (precision time protocol). If you need absolute time with sub-microsecond precision, you should look look at this protocol and/or buy a GPS receiver.
If you just need relative timestamps, you could try -j adapter_unsynced instead of -j adapter, or maybe you could try to stop NTP from trying to drift-correct your system clock. If all this fails, you could try to start linuxptp, which may have the capbability to properly sync NIC and system time even if you don't have a PTP network.
And finally... you are using a HUB, which means Ethernet is running in half-duplex mode, which means... collisions. Unless your NIC is absolutely quiet. I guess in theory this shouldn't matter because you observe the same collisions in both NICs, and frames aren't delayed or queued differently depending on which path they take. But since half-duplex is so rare these days it may be that NIC timestamping support wasn't implemented with that in mind. Typical bugs in such implementations are e.g. returning the timestamp of the previous frames instead of the current one.
Chapter 7.9 of the Intel i350 Datasheet may help you with your 3rd question. It provides the set of PTP registers you can configure in the igb driver.
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf
I am trying out VOD streaming with latest VLC as described in this wiki:
https://wiki.videolan.org/Documentation:Streaming_HowTo/VLM/ and trying to stream an HD movie file with extension mp4.
i am able to open the stream in VLC running on the same machine, but it takes lot of time to even start playing back. (minutes). The test is run in Fedora 20.
My machine is capable enough to play HD video.
I have tried with and with trans-coding and results are same.
Help is appreciated.
Found the issue and it is strange.
I had the streaming server and client in the same machine. The streaming was always extremely slow. However, disconnecting from the network made it work fast.. It did not matter whether the network connection was wifi or ethernet.
However, if you were to run the client in a different machine, it work properly.
I'm having a problem here. I want to play RSTP streaming on ipad and iphone. but I find out that it will be much more easier if I use Http Live Streaming. I want to convert my RTSP streaming to Http live streaming using lighttpd. but I really have no idea how to do that. Do lighttpd accetp rtsp streaming url as input? Can anyone help? thanks!
you have two choices:
1) Run a server on your network that re-streams rtsp as hls.
a) wowza - popular, expensive
b) live 555 - free, lots of work
d) ffserver - free and as basic as it gets tons of work to make work.
Advantage :
No bandwidth restrictions over cellular or wi-fi
play with native apple players
Disadvantage
High server bandwidth - if your paying for server time you may want to watch this.
high letancy - forget any kind of live video.
2) Run FFmpeg based player on device
advantages :
a) A lot easier than it used to be, we do this all the time
b) deal with lgpl license, clear guidelines at ffmpeg.org and not a huge hassle
c) all on device, no server load issues.
Disadvantages
Limited bandwidth over celluar (about 10 min intervals), unlimited over wifi
lighttpd doesn't accept RTSP as an input. You will need some sort of translator program to read the rtsp stream and output the files to the website storage. I think you could do it with the avconv/ffmpeg program.