Beiträge von Awawa

I wonder why to chose cheapest HDMI grabber now... these one based on MS2109 could have some issues with Hyperion.NG also and it's wholesale price is around 3-5USD. You get what you pay. Not great problem if it will stopped working at some point but the worst case scenario is potentially damage to the TV or other equipment as HDMI input is weakest point for their electronic these days. I have used some equipment that based on utv007 but there were no other choice in that time.But I was lucky because it was original utv007 not the counterfeit. Next one with direct HDMI to USB broke in few weeks due to not sufficient cooling and it consumed energy from HDMI all the time and didn't have any power saving feature at all. Guess I was lucky again...

It's done by Madvr. Setup described on the first page, precisely this option: https://postimg.cc/hQWBrY90 Confirmed on the TV extended display properties.

Check the live feed from the grabber (upper right corner). Try to setup resolution and refresh rate manually. After grabber is disconnected it's necessarily to reboot system to work again.

Could be resolution/color format (rgb/yuv et)/refresh rate via HDMI that is not supported by the HDMI - AV converter. Did you change anything?

@HyperLEDs as you have MJPG device maybe you can my fork as it's intended to improve performance for that type of encoding (MJPG):
https://github.com/awawa-dev/hyperion.ng/releases

It contains patches released after Alpha7, Raspbian Buster is recommended. Or you can compile current version of Hyperion to test: beside performance (and one related bug in live preview) I haven't meet any issues.
But beware there's one problem in Hyperion.NG that can affect you: https://github.com/hyperion-project/hyperion.ng/issues/908 (I dont have that dual type of yuyv/mjpg grabber to check it)

@HyperLEDs it's seems it's rather software problem from old Hyperion (operation not permited for that device) because linux drivers is perfectly OK. Trouble with MJPG device was the main and only reason I've migrated to Hyperion.NG. But the store is still pending as I improve it's performance.

For the old hyperion and that device causes you VIDIOC_S_INPUT ERROR 22 could try add --pixel-format YUYV to command line

@jiby The grabber is compatible. That's my old one.
And the HDMI AV converter is...? Seems some PAL/NTSC issue. Analog sucks.

Well, the first registered device is MJPG, it doesnt work with old Hyperion and the new version has some performance isssue but it should work somehow. Try second instance of video device ...it's seems it's yuyv.

@HyperLEDs dmesg looks good and v4l2 capture device is active ...and what are symptoms that the grabbers doesn't work? Hyperion.NG doesn't detect it and there is no info on the www usb grabber configuration page? or the black screen from the grabber or something else maybe?

@HyperLEDs Paste full dmesg & v4l2-ctl --list-formats. This grabber should work.

@MartijnGP I can confirm some strange isuues with yuv 420 (I lost sound) but switching to full RGB resolved it without quality lost.
4k60, HDR, RGB definitely works while ezcap is working as on picture.

As an experiment I've run it on Pi zero.
In fact I'm quite surprised how it performs.
As you can see you can easily go below 80ms lag delay.
That better's timing than I had on Alpha 7 on Rpi3:
Rpi3 Alpha7 800x600 size decimation 1 => lag 140ms
Pi Zero from fork 800x600 size decimation 1 => lag 80ms
I write some optimization mainly for HT but there is one, critical for me issue with video buffer copy procedure for MJPEG that affects single thread also so I've changed it too.

Frame can be resized inside the Hyperion when cropping or sizedecimation is set (and maybe black border detection, didnt check that). It's additional cost, but smaller result frame can compensate it with.

But that's not the case. Without changes there isn't enough power on certain setup to process raw frame that size can be set on the grabber and it's job to resize it.
Frame size is small and quality is poor at least for 640x480, for 800x600 is better but it's minimum quality that I can accept.

-------------------------------------------------------------------------------------

EDIT:
As there were some reports about conflicts between some systems and installers that were native built, now installers are build using standard Hyperion Docker images + libturbojpeg0 package. Also few new changes and code optimization.
For now I'm think I'm done, maybe if some bugs to fix in my fork appear I'll back to that subject. I'm happy from the new features and I use then with every movie (HDR or SDR forced to bt2020 by codec) from some time.

https://github.com/awawa-dev/HyperHDR/releases

FPS are side-effect. For Rpi3 20-30% of frames are broken/incomplete and we need more but more import is latency:
- before 140ms and that must be computed on single core, almost everything else must wait for resources.
- after 30ms and can be computed on different core: both timing depends on jpeg frame size/content
And single core usage that causes Hyperion to pause processing data => then visible lag between TV and LEDS. We cant always blame the grabber or too slow CPU. Especially in case when sizedecimation (that causes frame reduction) improves situations for users as it's often reported and it's possible to improve code performance.

640x480 in my opinion is useless for MJPEG. The jpg artifacts are too noticeable and have effect for the LEDS. We can process JPG better frame by frame but again: this also would increase load. And you could not get even 30FPS on 640x480 before: that the lower limit of that FullHD grabber. The raw jpg frame from the grabber for 800x600 if I remember correctly has only 14kb (depends on scene): that's how much details you loose with lower resolution.

Manipulation with saturation can make some picture HDR beatiful, but average result is a lot worse. I started from that solution. The main problem is messed up gamma and that LUT HDR patch fixes it.

I haven't met a test screen (true HDR "in SDR") that can be broken with the LUT correction and I can provide you a lot of samples that increased saturation causes totally messed up & unrealistic results. Skin tone is best example: you must like orange, a lot of orange everywhere. Then if you start playing with hue to reduce reddish then the yellow starts look greenish, it really leads to nowhere. The input scale to fix is not linear.

Anyway first test release for LUT-HDR to play with: https://github.com/awawa-dev/HyperHDR/releases

Added support for multi-threading for MJPEG encoding (used by ezcap 269 among others).
Before on Rpi 3+ I got 7-8FPS, big delay around 140ms and process using only one core reaching almost 100%.
That causes some unpleasant feeling watching some action movie when LED's stayed behind action on TV.

Using MT I've reached almost 50FPS & average delay around 30ms for 800x600 applying LUT without any decimation.
The load is balanced on all 4 cores if needed.

Patch for HDR/LUT correction is also already included.

Won't go for the mainstream this time, because that multitreading is tested well only on Rpi3+ (and some on x86) and it brings too much revolution for current Hyperion Alpha stage.
And there are some really stability and performance issues with video frame decoding in the current Hyperion version that LUT operation would make things only worse. I fixed things that I found in my fork for testing.

Download sources & binaries from:
https://github.com/awawa-dev/hyperion.ng

Zitat von Andrew_xXx

So i think we need to research this better and not rush this, but there is a light in the tunnel for sure.

Yes, and so we are waiting from 2017 at least for some solution for HDR bleak & wash out colors.
And yes, there is a light at the end: expiring Philips' patents for ambilight... if any new and better transformation shows up can be used with current LUT feature.
It's only a matter of creating generator for a new table. The table isn't build in - can be change by user at any time.

First of all screenshots you have attached before show typical images for that grabber (I have the same one). So Hyperion is receiving what you see on the live stream. The problem lies somewhere further and that causes that the LEDS are too bright. Or this is individual perception but the calibration should be done somewhere else, not in the grabber configuration because it's fine.

Not calibrated TV can also be suspected.

Incoming LUT correction doesn't have the problems you have mention, got some limitation for ex. dynamic luminescence missing but as it's static for all the content in HDR10 it can't change much even between different movies. But it wont work with that dark settings because too much details will be lost.

BTW with this setting you have caused de-saturation (default=128), HDR-in-SDR requires something opposite:

v4l2-ctl --set-ctrl saturation=80

HDR test preview: http://abracadabra.coolpage.biz/lut_generator.html

git clone --recursive https://github.com/awawa-dev/hyperion.ng.git hdr

After you installed the package v4l2-ctl still doesn't work? could you attach your v4l2-ctl --all result?

Otherwise if v4l2-ctl changes brigtness/contrast/saturation on the Hyperion Live preview that means the problem is somewhere else for ex. image processing, LED calibration or maybe hardware.

1% is way to low, something is not rigth and HDR patch as option will increase luminescence slightly. Calibrate your system on the SDR video first and try to adjust also other settings (gamma reb/blue/green play important role).