Uncompressed Option i.e. no-encoding

[beanpaisly]

Hi

I would like to revisit request to add support for no-encoding or uncompressed frame forwarding at least on Windows.

Uncompressed 1920×1080 at 60Hz has achievable bandwidth requirements when on a 10GbE network.

It’s been 2 years since the last mention as per NoMachine Forums – Raw encoding (no encoding)

Wondering if there are any updates or plans to add this option in the near future 2 years down the track?

[Britgirl]

As the other topic mentioned. It was something we had planned to add.

This is a typical case where having a feature request for uncompressed output can be misleading and doesn’t point out what the problem actually is. It makes no sense to make an uncompressed session just to improve the quality. The job of NoMachine is to improve the quality, so much so to give seamless and 1:1 rendering, but still compressed. How are we going to do that? With lossless refinement. There are two ways to do that: refinement with video encoding such as h264, x264,vp8, etc , which will never be 100% lossless, and progressive refinement that means you get to the stage where the last refinement is 1:1, 100% lossless.

When will this be available in production code? It’s work in progress 🙂 We work on refining the output everyday, day by day. Any new improvements we produce during development go into the production code at every release. When will this work be finished? Never. There is no code that you cannot improve in one way or the other 😉

[beanpaisly]

Hi Britgirl,

Apologies for not pointing out what the problem actually is – the problem is Latency i.e. not chasing quality improvement.

I would agree with you that it doesn’t make sense to use an uncompressed session just to improve quality.

It does, however, make perfect sense to have an uncompressed session to improve latency.

Compression adds at least 5ms-10ms of latency and occupies video encoder on the host. What if I want to edit videos remotely and require this video encoder? Not to confuse you, this query is not related to hogging video encoders but concerns latency.

Scenario of uncompressed session makes sense when host and client are in close proximity under the same roof with requirements of minimal latency.

And by minimal latency I mean under 10ms in total. Ideally under 5ms.

Would you please be kind enough to add an uncompressed session option for the sake of latency?

[Britgirl]

It does, however, make perfect sense to have an uncompressed session to improve latency.

 

In practice it’s not like that. Fra81, one of our lead video core developers will explain why 🙂

[beanpaisly]

No worries, Britgirl

Could Fra81 please include recommendation on the following:

– How to achieve sub 10ms latency on an inter-lan setup i.e. within a few meters away?

– Should a USB Bridge cable be used? i.e. one of the 5GbE cables like the Streaming Cable for LattePanda.

– Assuming that uncompressed RGBA framebuffer feed will generate sufficient CPU activity to cause latency issues, is there a good option that is not TCP or UDP? i.e. a different Layer 2 option that would work wonders when going directly PC to PC on consumer network cards(not RDMA)??

Any insights much appreciated.

[fra81]

Hi 🙂

Let’s do some math considering a 1Gbps Ethernet connection and a screen resolution of 1280*960, which, you will agree, is pretty low for today’s standards.

For a start, we can calculate how many MBs can be transferred on the network per second:

(1000000000 / 10) / 1024 = 97656.25

1Gbps = 97.656MBs

The size of a single 1280×960 frame is given by:

(1280 * 960 * 4) / 1024 = 4800.00

Size of 1 frame = 4.8MB

Now we can calculate how many frames can be transferred on the network per second:

97656.25 / 4800.00 = 20.34

It is possible to transfer 20.34 frames per second, which is very far from the 60 fps that would be considered a good frame rate.

We can also calculate how much time is needed to transfer a single frame, that will directly affect the latency:

1000 / 20.34 = 49.16

So it takes 49.16 ms to transfer a single frame through the Ethernet. This considering a direct gigabit Ethernet link between only the two computers. Any other computer on the same network could add more latency. And we can easily imagine what could happen with a FullHD (1920×1080) or a 4K resolution.

This explains why what you say makes perfectly sense in theory but not really in practice. It is far better making the CPU and GPU do the work to reduce the transferred size, as they will always be faster than any network.

[beanpaisly]

Hi fra81,

While I do appreciate the response, calculations provided make sense only for 1GbE connections.

My question, however, referred to 10GbE links.

Please consider the following:

10GbE Transfer Rate per second in MB = 10000000000/10/1024/1024 = 953.67MBps

Size of a single 1920×1080 frame = 1920 * 1080 *4/1024/1024 = 7.91MB

Number of 1920×1080 frames possible to transfer over 10GbE per second = 953.67/7.91 = 120.56fps

Latency per frame = 1000/120.56 = 8.29ms

Rate required to transfer 1920×1080 frames at 60fps = 1920*1080*4*60*8 = 3.98 Gigabit/s

4Gbps is very much achievable on a 10GbE link.

4Gbps may even be achievable over a 5GbE link using UTP.

It looks to me as though total end to end latency in the vicinity of 10ms  is a possibility over 5GbE/10GbE connections if uncompressed option is provided. Would you agree??

[fra81]

In theory yes, in practice unfortunately not. It’s true that 49 ms needed to transfer the same frame, on a 1 Gbps network, would become 4.9 ms, on a 10 Gbps network, but this is only in theory. In practice moving the data from the network layer to the video RAM is much, much more expensive. We did our experimentation, of course, and the real frame-rate that we were able to achieve, with uncompressed data, on a 10 Gbps network, with a dedicated switch, with only the client and server on the physical layer, were close to 20 frames-per-second. And this only at times, with a sustained rate much lower than that. And this with the code that is inside the production NoMachine software, code that is optimized to be zero-copy (except the copy from the network layer to the video RAM, of course). The fact is that data-tranfers are expensive. Operating systems can use DMA, but doing that in user-level code is basically impossible and, even if it was possible, it would only be at conditions that would greatly reduce the number of systems where the “feature” can be leveraged and users make real use of it. The point, in the end, is that even if we did such “uncompressed encoding”, and even if it worked, it would be of so little use for almost the totality of our users that it would just be a quirk, something to mess about with. Different is the approach we have taken, the continued work on algorithmically improving the “end quality” of the output, so much to appear visually lossless.

[beanpaisly]

It does look like Windows in its current form may not be well suited for low latency high rate uncompressed streams over commodity ethernet adapters. Linux with Wayland is another story. Although there are a couple of Windows options that have not been explored, namely:

– a Custom zero copy Soft-RoCE driver on both ends that pins Video RAM.

Do Linux/MacOS versions of NoMachine support standard non-VRAM Soft-RoCE ?

– Thunderbolt to Thunderbolt zero copy or a variation on RDMA i.e. not Thunderbolt Networking

Number of laptops and desktop motherboards supporting Thunderbolt will grow exponentially within a year, hence, it does make sense to look at zero copy over Thunderbolt.

Would NoMachine be willing to explore these options??

[fra81]

As we said, we believe using uncompressed streams over any network, in a software like NoMachine makes no sense, but we will surely explore both of these, as soon as they become more widespread, as we always do with any new advancements and any new technologies ;-).

[Author]

Posts