Controlling how artefacting is rendered

[armelvil]

Hello all,

Is it possible to control how glitches are rendered on the decoder end?

If there's a muxing error, or data loss, typically the decoders respond by rendering blank grey blocks which chase across the screen with FEC enabled, or they simply blink full grey.

I would like to know if it's possible for them to instead hold on the previous frame data until new data are received. For my purposes, the grey blocking is causing issues.

Of course I'd like to get to a place where no data errors appear in the stream, but I don't appear to be there yet (libx265 appears to be the worst offender?)

For reference, I'm using the following sender settings;

libavcodec:encoder=libx265:preset=ultrafast:crf=34:gop=6:bitrate=7M

And receiver;

--tool uv -d gl:fs

GL seems to be more fault-tolerant than vulkan_sdl2 from what I can tell.

Oddly enough with these settings, streaming was fine until a largely blank static image was on the screen, and then grey flickering became very distracting.

I'm using such a ridiculously low GOP value because it seems to minimuze the loss when I do get drops, so they are over in a split second instead of losing 1s> of stream.

[alatteri]

Well I think really we should concentrate on getting effective FEC when using compressed formats, or accept the additional latency and wrap the output of UG in SRT.

[MartinPulec]

Is it possible to control how glitches are rendered on the decoder end?

Currently not but it depends.

The problem is that to ensure that the corruption doesn't occur is to skip all data until next I-frame, as it has been for VP8. But for H.265 also intra-refresh period needs to be turned off, otherwise there are no I-frames, just P.

Would it be usable for you under this circumstances? I mean disabling intra-refresh and waiting until next I-frame?

[armelvil]

Apologies for the late reply & if I was initally unclear -

Martin has the general idea - I noted that my tests with VP9 basically held the corrupted frame on screen, which was less jarring than otherwise. So far oddly the most stable HEVC codec has been libsvt_hevc for some reason.

For the time being, the hacky solution of reducing the MTU to 512 bytes has actually eliminated ALL artefacting entirely!

Once I have managed to scrape my lab back together (taking a break this weekend but should be able to resume testing next) I can run further tests with libx265, which seemed to be the worst offender & disabling intra-refresh.

.. Also, as an unrelated aside - does anyone here know if you can run a Decklink card without the linux DKMS module? My base build runs off fedora CoreOS (think stripped down rpm-ostree SilverBlue) and I'm rather keen on not having to fold in a container-overlay approach to having to build the kernel mods in. It seems other low-latency PCIe solutions also require kernel mods (AJA, Avermedia etc.)

[alatteri]

So far oddly the most stable HEVC codec has been libsvt_hevc for some reason.

If I recall in my tests, libsvt_hevc was more latent than libx265. Also it works in YUV space instead of RGB if color accuracy is important.

For the time being, the hacky solution of reducing the MTU to 512 bytes has actually eliminated ALL artefacting entirely!

are you using FEC too?

.. Also, as an unrelated aside - does anyone here know if you can run a Decklink card without the linux DKMS module? My base build runs off fedora CoreOS (think stripped down rpm-ostree SilverBlue) and I'm rather keen on not having to fold in a container-overlay approach to having to build the kernel mods in. It seems other low-latency PCIe solutions also require kernel mods (AJA, Avermedia etc.)

I use Ubuntu Server as base OS. I think UG is kind of oriented that as a linux distro. It is quite minimal and stable. Works great with DKMS/Decklink.

[armelvil]

Yes, libsvt_hevc was about 2-3x more latent.

I am using RS FEC with the values;
-f V:rs:200:240

The caveat here is that the clients are wireless (yep!) so I'm somewhat out on a limb, there.