4k HDR Capable HDMI Splitter (supposedly)

Zitat von RaymondMouthaan

@rasp, So I assume you modified the cpp as above and recompiled to make it faster, but its not the final solution adopted into HyperionNG?

Yes, I changed it in /libsrc/grabber/v4l2/V4L2Grabber.cpp only for myself because lower resolutions generated nasty images and higher resolutions caused unacceptable lag. Dont want to commit it to the project because of the issue of decimacion==1 and the live feed. Maybe it should be made in another way but it works stable and fast for me for my configuration.

Sounds acceptable for personal usage, hopefully a more permanent solution will come to HyperionNG soon, meanwhile I can adopt your solution and recompile from src. But first more importantly I need to solve my other issue, do you have any ideas about that?

Zitat von RaymondMouthaan

Sounds acceptable for personal usage, hopefully a more permanent solution will come to HyperionNG soon, meanwhile I can adopt your solution and recompile from src. But first more importantly I need to solve my other issue, do you have any ideas about that?

Didn't meet that behavior. MPC HC & MadVr changes resolution almost for every movie to fit resolution & FPS and it works. But most of my sources are 1080 HDR and sometimes some old 480 SDR TV series and there is only one PC connected to ezcap / LG C9.

Playing around for many hours and a lot of frustration, unfortunately no succes on the issue regarding Apple TV 4K and the ezcap269. As soon as the ezcap269 is powered on (by connecting the usb cable to the raspberry pi) the Apple TV "detects" the ezcap269 as being a "1080p" device and switches back to 1080p. At this moment the blue led on the ezcap269 turns on indicating the device is capturing the video signal.

What I don't understand is why the Apple TV "sees" the ezcap269 as a 1080p device, instead of a 4K device. I mean the HDMI input of the ezcap269 supports 4K, so it should be seen as a 4K device right? :whistle:.

I am thinking about sending back the ezcap269 because of above reason and because of the issue regarding the lag. Moving over to the expensive HDFury Diva, but more questions rise up before ordering it...

• Is it possible to use the Diva in combination with HyperionNG and my current setup?
• Will the "AppleTV switch back to 1080p" issue been solved using a Diva?
• Is it possible to use my current Arduino Nano + ws2815 ledstrip (which is already perfectly attached to the Sony Bravia) with the Diva?
• How would my setup look like when a Diva is taken into account, do I need other boxes as well?

Apologies for all these questions! I just want have a nicely working diy ambilight setup, without spending more money on devices which are disappointing and frustrating.

Perhaps guys like @frodo and @Claudio Branco can help me out

Help, tips and advise is more than appreciated!

Zitat von rasp

Unfortunately I know only this 4k HDR Capable HDMI Splitter (supposedly)

Ahh, though you mentioned it cuz the update did allow for that tuning commands, oh well.
I see ezcap is still lying about its hdr support, but the software tune is quite good, if it could be even further saturated it would be almost the same.

Further saturation is only possible by algorithm in hyperion NG and it requires YUV format (fast and simple) or more complicated matrix operation for RGB. Current release converts MJPEG directly into RGB and there is no CPU resource left even for that with higher resolution on Rpi3.

I noticed that sometimes v4l2-ctl --set-ctrl looses it's settings. For ex. it display that saturation is 255 but it isn't (captured screen tells different) and it need to be reapplied. I've attached that script to the cron.

Hyperion doesn't use full resolution image and they state its low cpu load, i'm not an expert but i think it would be somehow possible, maybe with ffmpeg, just need to find the right method, i know its there, maybe use LUT..,a simple result of color dodge in ps is, so it can be done

@TPmodding well i'm, but its not the issue of hyperion here, the ezcap device is just not outputting right colors and nothing can fix that, we can only try to change something with the wrong color on image but thats it, its impossible to revert the broken HDR to SDR conversion, if they at least would output a 1080p but with HDR color, then something could be done with this, everything else is just a workaround.
I contacted ezcap again, will see if they answer something else now.

Some things to clarify about ezcap and HDR.

1) even if top command says that overall CPU usage with v4l2 hyperion capturing video format 640x480 decimation 1 is about 120% (out of 400%) it simply says that single main threat of the Hyperion is running out of resource. Press 1 to see core usage. Stats are for Rpi3. With my path CPU usage is 80% and it's acceptable for me: no more lags TV vs LEDS. But there is no more space left for additional filters.

2) we can chose FPS...but for ezcap 269 minimum FPS is 30 - this is the driver/hardware minimum limit. You can set lower FPS but it will be override. So you can't save some resources using that settings.

3) there are some programs that try to fix incorrect color space. I saw some proof of concept in fastled project but I don't now if it works and I think it's only for few hundred points (whole image it's few hundred thousands pixels at least).

4) and most important: you can't fix SDR into HDR again - some information are lost. Simply we don't have meta-data that are transmitted via HDMI to the TV. It's a job for the hardware grabber or matrix to analyze them and currently only few devices from HDFury can do it. In that metadata there are some important information about current frame (for ex. chroma/saturation range is dynamic and can be set in that metadata). We can better or worse try to guess current color gradient by analyzing whole frame and then correct it. It's totally unrealistic in realtime on Rpi. Kodi uses regular graphic card shaders to try to correct them. Color correction that we can apply to ezcap is one of best on the market and fastest and least resource hungry for sure.

Well i know all of this, but hyperion is working good even on rpi zero, it all depend only on algorithm and u can make it work good but depends also on what you want to do, decimation can be controlled, even half of this is enough, as of fastled, you mean 3d lut, well it is probably only one way HDR => SDR tone mapping.

Only the expensive devices seems to work with proper HDR to SDR output, thats a shame, i'm more and more towards using a camera, it will work with anything and is immune to technical changes, soon there will be new consoles, so 4K 120fps will be more popular and any current grabber that does not have at least 4k 120 fps input support will not work, and there are more, vrr, freesync, gsync, i just want something that will always work without any hassle.

The camera is a tempting option but it's prone to interference/changes. Before ezcap 269 I considered it. For gaming and higher / exotic FPS I think camera it's still better solution. Even Diva is limited to only 60fsp. The side effect of copy protection on hardware level and difficult access to restricted documentation made that hell even for Chinese engineers. It's almost unbelievably that after so many years only HDFury acquired that technology for "budget" level devices.

But for my movie player that grabber became almost perfect solution. I had some trouble with win10/madvr configuration that would work with SDR and HDR on one side and ezcap & hyperion on the other. Maybe I describe my final configuration in the other thread in future.

Or find a grabber that is at least downscaling to 1080p with HDR data, that way it would be possible to access the HDR data and do the tone map on rpi, i have seen some grabbers that supposedly does this, but not sure what is the 1080p format then and how to grab that hdr data, or maybe, just maybe, ezcap is doing the same, but we are unable to read that hdr data in stream as we dont have any docs.

I did a raw ffmpeg screenshot dump from real 1080p HDR video to png and it has about 10mb in size and is 48 bits, so, its something there, but i cant view it properly, HDR + WCG viewer app can view it better but still not that good as madVR live vid, trying to figure out what format hdr screenshot should have and where are those hdr data in there, that way it would be possible to test as it would be a frame from a grabber, cuz probably that hdr metadata do not sit with the pixels, its separate.

I have managed to apply 3D LUT filter for HDR content from other project and it looks really nice. Good news is that it can be done in real time.
More to come soon (with sources for Hyperion-NG) in separated thread because is rather not related to 4k grabbers/splitters.

SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center

Zitat von TPmodding

https://www.mydealz.de/deals/h…-2-in-1-konverter-1630056

edit: not sure if it is a switch or splitter

It's only a switcher not splitter: one of two outputs -> 1 monitor or 1 output -> one of two monitors

@Awawa I also have an ezcap269 and I'm having some issues... Most probably related to the same HDR problems discussed here. Mainly, the LEDs are too bright compared to the image shown on the TV.
So, I have 2 noob questions:
1. Could you share your Image Processing and Capturing Hardware configurations?
2. How to apply the workaround that you mentioned here:

Zitat von Awawa

PassThrough works with ezcap 269, no problems with TV 4k60 & HDR or any other resolution/FPS (I had some problems before with VSP01201 and UTV007)
For capture: HDR colors are degraded but can be somehow fixed on startup with:

Code

/usr/bin/v4l2-ctl --set-ctrl contrast=220
/usr/bin/v4l2-ctl --set-ctrl saturation=255
/usr/bin/v4l2-ctl --set-ctrl brightness=128
/usr/bin/v4l2-ctl --set-ctrl hue=16

I'm happy with it.
BTW there is update for ezcap 269 that finally can be flashed but there is no changelog or whatever ...this is so chinese.

`/usr/bin/v4l2-ctl` doesn't exist on my system. I'm running hyperion on a debian with the .deb hyperion package installed.

I'm already looking forward for your patch to be released and enhance the HDR -> SDR processing.

1 v4l2-ctl is a part of v4l-utils package that you can install on your system
2 too bright LEDs could be caused by LED configuration in Hyperion (or by the LED hardware themself) and could be not related to the grabber
3 check & verify the live view capture from Hyperion (for ex link )

Zitat von Awawa

1 v4l2-ctl is a part of v4l-utils package that you can install on your system
2 too bright LEDs could be caused by LED configuration in Hyperion (or by the LED hardware themself) and could be not related to the grabber
3 check & verify the live view capture from Hyperion (for ex link )

Thanks for the answer!
I assumed that it's the grabber since when I use any effect or fixed color within Hyperion, the colors are correct set on the LEDs.
Original Image:

Preview in Hyperion: