awawa-dev / HyperHDR

Highly optimized open source ambient lighting implementation based on modern digital video and audio stream analysis for Windows, macOS and Linux (x86 and Raspberry Pi / ARM).

Home Page:http://www.hyperhdr.eu/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Captured content of screen is distorted: jagged diagonal stripes, no visible content, when screen is in 4k mode 21:9 3440x1440 in macOS M1 v14

DonaldTrump-2020 opened this issue · comments

Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)

Steps to reproduce

set mornitor to 4k mode 21:9 3440x1440, then captured it by hyperHDR

What is expected?

Screen content captured exactly when screen is in 4k mode 21:9 3440x1440

What is actually happening?

Captured content of screen is distorted: jagged diagonal stripes, no visible content, when screen is in 4k mode 21:9 3440x1440 in macOS M1 v14. In other lower resolution (ex: 2k, full hd,... both 16:9 and 21:9), hyperHDR still works well!

System

macOS v14, 34in mornitor 4K with max resolution 3440x1440

Hi
Just to be sure, do you mean software capture? Not USB grabber?
I dont have Apple Arm like M1 platform currently so cant reproduce it and fix it.
Maybe it's something trivial like aligning video frame lines for certain resolutions, so maybe someone can test and provide a fix if needed?
https://github.com/awawa-dev/HyperHDR/blob/master/sources/grabber/macOS/macOsGrabber.mm

I mean software capture. I think in both intel or m1 have same this issue.

in macOsGrabber.mm, Which parts are likely to this issues and can be fix it, @awawa-dev ?

Which parts are likely to this issues and can be fix it

This is a very good question ;) Probably here:

rawData = (uint8_t*)CFDataGetBytePtr(sysData);

I reduced from 16 to 4 in the code below, do you think it's ok?

int Grabber::getTargetSystemFrameDimension(int& targetSizeX, int& targetSizeY)
{
	int startX = _cropLeft;
	int startY = _cropTop;
	int realSizeX = _actualWidth - startX - _cropRight;
	int realSizeY = _actualHeight - startY - _cropBottom;

	if (realSizeX <= 4 || realSizeY <= 4)
	{
		realSizeX = _actualWidth;
		realSizeY = _actualHeight;
	}

	int checkWidth = realSizeX;
	int divide = 1;

	while (checkWidth > _width)
	{
		divide++;
		checkWidth = realSizeX / divide;
	}

	targetSizeX = realSizeX / divide;
	targetSizeY = realSizeY / divide;

	return divide;
}

Try to increase capturing resolution in the software grabber configuration. The default is 512 I think and maybe it's too low.

set it to 1024

I tried it , but not work

It is likely that the actual line length in bytes is longer than the number of pixels per line * pixel size (4) would suggest. I think this is stored in CGImageRef.bytesPerRow (can be obtain using CGImageGetBytesPerRow on our CGImageRef display)
This can be passed to processSystemFrameBGRA

void Grabber::processSystemFrameBGRA(uint8_t* source, int lineSize, bool useLut)
The second argument allows something like this to be included here:
processSystemFrameBGRA(rawData);
so you would have to check it yourself

size_t bytesPerRow = CGImageGetBytesPerRow(display);
processSystemFrameBGRA(rawData, static_cast<int>(bytesPerRow)); 

I will try it soon, thank you!

size_t bytesPerRow = CGImageGetBytesPerRow(display);
processSystemFrameBGRA(rawData, static_cast<int>(bytesPerRow)); 

it works well bro, thank you so much!

Thanks for the feedback. Can you submit a pull request to fix the code or should I do it?

Thanks for the feedback. Can you submit a pull request to fix the code or should I do it?

Could you please do it for me? You present the issue more professionally and understandably than me LOL