Although it was showing high bitrate, nothing was played. When I connected sender to a DVD player, receiver was working OK but VLC couldn’t play the stream. HDCPĪll this was done with PC output without HDCP encoding. New extender is slightly slower, latency is about 400-500ms. Left monitor shows source (secondary output is fed to HDMI sender), right monitor shows HDMI receiver output and notebook shows stream captured from network. In following videos you can compare the latency of the old and the new HDMI extender. You can stream directly to youtube with audio reencoding with this command:įfmpeg -i udp://239.255.42.42:5004 -vcodec copy -codec:a aac -b:a 128k -f flv rtmp://a./live2/ Latency

Job’s done! Stream qualityīitrate of the stream is quite high, about 15Mbps, but unfortunately, it doesn’t stream in FullHD, but in strange resolution If i lowered the resolution to 1280×720, I’ve got 60fps. I’ve got beautifully clean stream of my other desktop. I started VLC, set input to and the result is here: ffmpeg -i -vcodec copy -f mpegts udp://127.0.0.1:1234Īnd I’ve got significantly better video in VLC then I noticed in pcap, that packet length was 1328B but I knew it should be integer multiply of 188 (typicaly 1316 bytes) if it was mpegts stream.So my next thought was: this must be RTP! So I tried to proxy video thru ffmpeg (latest compiled version). mb_type 535 in P slice too large at 35 2 mb_type 264 in P slice too large at 78 32 mb_type 535 in P slice too large at 18 41

Some choppy video appeared, but it was unusable and following errors were appearing in console: Invalid UE golomb code This was a great news because so heavy multicast traffic means a lot of data (most probably video) and no need to send control packets to start the stream. If you want to know more, just read the blog.

Hack router port 5355