4k HDR Capable HDMI Splitter (supposedly)

  • OK, I will check it.
    But it seems there is a bigger, unacceptable problem. It came out during watching movie at nigth. There is very big delay between movie on the TV and captured frame: ~1-1.5s. UTV007 with old hyperion was much, much faster. I don't know why this happens and what fails: hyperion-ng, mjpg processing, that device or USB2.0 speed is insufficient. I didn't found 'frame decimation' option in hyperion-ng that was present in the previous generation . CPU has 30-40% usage for PAL, size decimation = 8 .
    I dont have a plan to upgrade my config to Rpi4 because there are problems with SPI. So it seems it's a dead end.

  • 1)
    I have tested it on Win10. As I suspected HDR capture doesn't work properly but is should be sufficient for ambiligth.


    2)
    I have excluded USB2.0 and the device as a suspect. I have connected ezcap 269 through USB2.0 hub to PC with Win10 and there was almost no delay after I have disabled caching in VLC.

    For me there is something wrong with hyperion-ng that causes that delay for ex. caching, too high framerate or resolution (PAL/NTSC et. are deprecated for new generation HDMI devices) that we can't change or set, low priority capture process or it can't use all four cores for certain tasks. CPU usage is not even at 50%.on Rpi3.

  • OK, I found the problem in the hyperion_ng code.
    I know it's rather a developer problem (move post to other forum section if you like) but it breaks things on modern FullHD USB capture devices that are used with USB2.0 host: the delay between stream and capture is totally unacceptable. You are run off the USB bandwidth (or resources) with ezcap 269 and Rpi3.


    That's how current hyperion_ng finds resolution to work with:

    It chose the highest available resolution:1080/30fps and it's too much for usb2.0 and/or Rpi 3 .
    With the brutal hack I changed std:max to std:min (you must also change 0 as a start base min_width/height values) in v4l2grabber.cpp when grabber is searching resolution:

    I noticed that the framerate is hardcoded to 30fps but didn't change it. Now the grabber works flawless without any lag.


    I recommend to change that algorithm a little and move some settings to the configuration.

  • Ah, so sad :(
    I had hope, but if the vlc preview and everything else is correct then the issue is in the internal grabber itself, but that makes it false advertising, who would need a broken colors recording or for streaming, it just doesn't make sense.
    I did see they have some firmware updates so maybe the can fix it? I will try to contact them and ask exactly what parameters should the 1080p output have and maybe how to fix some things.
    I'm just wondering if the color data can be still used but cant be displayed or the colors are just beyond repair, maybe we would need an additional hdr to sdr mapping, but i would need a direct recording from that device to test things.
    Also thx for confirming that the full res wont work on usb 2.0.

  • To clarify ;) : full res 1080 capture works with usb2.0 (at least in 30fps, I'm not sure if it skips frames) but it's not real time processing that we need for ambilight on Rpi3. For recording or streaming I think it's fine. On the other hand we don't need fullhd for ambilight but working HDR would be nice. It's strange that even with 640x480 and size decimator 1 (I use at least 2) system generates some lag but CPU is stable at only 33%. This indicates that hyperion_ng's grabber is not capable of using multicores to process frames.

  • Well i checked this a while ago and yes, hyperion ng is not using multiple cores, on the other hand it wasn't that needed, either way my goal is 60 fps performance and i will use rpi4, if things wont go my way i will try to make my own ambi with .net core.

  • .net core app would be nice :) I think that Rpi4 is 2xfaster Rpi3 single core at most and there are some unresolved problems with SPI. If grabber's performance will scale 1:1 then the lag will decrease from 1.5sec to 0.7sec at best. And it's for 30FPS only. It's still too high.

  • @rasp
    Hmm, i have found one more possible solution, wanted to test if for some time now, use ffmpeg to do a hdr to sdr tonemap and use it the same way as for cameras, with a virtual one.
    The basic command to test this is ffplay.exe "Real4Colors.mkv" -loop 0 -y 780 -vf zscale=t=linear,tonemap=hable,zscale=t=bt709,format=yuv420p


    But i have limited testing files, the Real4Colors.mkv is a HDR bt2020 file from YT, the command did successfully do a hdr to sdr conversion but it was not ideal.


    The support from ezcap did only say that 1080p output is SDR, but i dont trust them much, so maybe there is a way to force ffmpeg to treat it like hdr and convert those bad colors to good sdr ones.


    It probably wont be that easy and maybe some additional commands would be needed, but i would need a direct 1080p video output recording from that ezcap device when the input is 4k HDR to even somehow test it. Could be the sony hdr demo.

  • My ezcap returned to the case with Rpi3 setup so I cant check it right now. I fight with hyperion_ng's grabber: there's some things to optimize in mjpg decoding even on the single thread but I lost some time due to fact that alfa3 doesn't work at all.
    But I think your solution should work to some extant. I saw similar approach somewhere where they tried to correct bt2020 to bt709 color conversion by the software transformation. There's only one problem: we don't have any information about the base stream before it was captured... was it 4k HDR or simply 1080p SDR or any other format. Without knowing that it's impossible to apply correct filter or don't apply it at all.


    You could try to contact Y&H: it's OEM but the same product and they have better support on the Amazon.

  • Well thats the part to do so experiments as i dont know what will came up, but it is mjpeg frames, so we can even experiment on one frame from the 1080p output but a video would be better. I once have done even some tests with a bleak SDR frame screenshot from a HDR material and even then i was able to correct the colors even if they were clearly not there (visually), its just i dont trust ezcap in the parameters, i would trust only in raw source capture, be it screens or video.


    I just dont know how exactly the hdr/sdr display and conversion work, what data is there, but there are players that do not support HDR and yet they show you the video but it has wrong colors, now how is this possible, it somehow converts those hdr colors, maybe the colors ale always saved as HDR values (10 bits?) but if your player dont understand this it just display wrong colors but the data could still there.


    Anyway im not in a hurry, its just an idea.


    Its clearly that the ezcap device must have some issues, but maybe there is a chance of a workaround. I did answer them when they said 1080p output is sdr that it has wrong colors and when they plan do fix it, but no answer for now :)


    Amazon would be a nice try, but im not sure i can ask them specific if i dont own the device.

  • You could check that topic: https://github.com/hyperion-project/hyperion.ng/issues/497
    Anyway that approach requires some interaction from user to switch on/off the color correction due to fact we don't know anything about the base stream. Well, if that ezcap could somehow forward an information about is hdr stream present...


    I'm pretty sure that pre-buy asking Y&H on Amazon it's perfectly fine: that grabber is advertised as a HDR capable but it's seems it's only half-true.

  • Will check it, but the base streams is just what you get at the 1080p output, at least the base we can get, there is only the topic of what software you use and format to capture and save it.
    In vlc when previewing capture you can take a screenshot or record it and even check the media codec information. Even record in raw format.


    As the amazon way, well there is some angle there, but then i cant use the advantage of owning it and say it is not working to get some more info. But now i see it is no more on amazon, they replaced the offer, its not ezcap 269 any more.

  • No, the base stream is that what is coming into the capture card thru HDMI - we need to know what it's format to apply the correct filter. In my case with sony test file it was 4k HDR10. The output grabber stream is 1080 and always SDR.


    It's ezcap 269 not 286. It's worldwide available on many amazon sites: https://www.amazon.de/dp/B07VS6X6S9

  • There is no point in knowing the base input as we are working only on the output data, besides input can change, only the raw 1080p output data is important, so this is the base material for me, vlc can even save the raw stream, i dont care much about the input as i will experiment with the formats either way and it wont work for sure out of the box, thats what the experiments are for. The SDR output is one way or another bugged so i just dont trust anything but the output data itself.
    As of ezcap version, just a typo, but i posted a link to the ez269 offer on page 10 to amazon and now it is no more pointing to the right version, thats odd, but i will try to ask from your link.
    Also, not sure what setup you have, but if it is rpi with system gui then vlc works there too.

  • I'm sure that if we will treat that output 1080 from 4k HDR with fix for HDR it will cure bleak color in some way but if the input source would be 1080p SDR then it will mess it up. Anyway or other there's no magic fix but to make ezcap to do correct color transformation from bt2020 to bt709 because that's the problem. If your source is always 4k HDR then of course you can hardcode it.

  • Well i know, its a stretch, just trying to find some workaround, if it will work then i can think what's next and how to make it user friendly. In the meantime i will read more about hdr on sdr displays, how it works. I did ask the seller from that amazon link for details, will see if he will answer.
    Well no one can fix the issues on ezcap but the company, there is a firmware, but they need to update it, i also searched for a custom firmware, but found nothing.

  • Ok, that amazon seller answered, his answer is completely useless, based on his answer i think he dont even know English that good and for sure i have no intent to continue a discussion with him, it would be pointless.
    On the topic of correcting colors, read some more, did some initial tests, it is probably impossible to correct the colors in any other way than 3d lut, its no magic and ffmpeg cant be forced to do impossible things, at least on images, still didn't do any video tests.

  • Gentlemen - I am considering the ezcap269 as well. Based on your experience to date, would you recommend this unit as an acceptable choice as a video grabber for Hyperion NG?
    My normal throughput is simply a 4K30 or 4K60 from a set top box. I believe that the HDCP is not affected, so "on paper" it looks like the perfect solution.
    Could you please update your experience with it in relation to Hyperion NG. I'll be using a Raspberry Pi 4. Thank you.

  • Anyone try the new ezcap 301? Supposed to support 4k 60fps and notably states this:


    "Good News : This product is the NEWEST one,it has the functions of both ezcap287 /287P and Ezcap261 /266 [Product Selling Point ] this NEW Ezcap301 HD Video Capture card solved the color difference problem."


    What's odd is they don't mention HDR anywhere in the post, but one can only hope ...


    Update - - -
    Ignore my comment. Went directly to the Easycap website as it seemed too good to be true and sure enough it was. 301 only does 1080p 60fps pass through not 4k, aliexpress sellers and their blatant lies, postings say it supports 4k 60fps pass through in the title, images and description ugh : /

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!