gyroflow
gyroflow copied to clipboard
gyroflow
[Bug]: Color space compression
Gyroflow version
v1.0.0-rc1
What operating system are you using?
Windows 10
What GPU are you using?
NVIDIA Geforce GTX1080
What happened?
Hi,
There is some color space compression going on when running GF over h265 GoPro Hero 8 footage. Here is a comparison:
Here you should notice that the shadows in the source are much darker... in fact the GF output doesn't have any pure black at all.
I've run into that same issue with my own video processing attempts before. In my case this was caused by a YUVJ <-> YUV format missmatch
Regards Maik
Relevant log output
No response
So the comparison above was made with GPU encoder. But I've done some further tests and it doesn't matter what encoder I use or what ouput format I choose, it's already "wrong" (in quotes because see text below) after decoding. I've also made another short test clip you can download here: https://drive.google.com/file/d/1SNyF8a0-NJ4KHJj48JCc6WPlEbMWyvmp/view?usp=sharing
Once loaded into GF you can already see the color difference compared to VLC in the Preview window:
The funny part about this is, when you export it and use VLC, the colors are back to normal. I've also tested other players: Media player classic: both clips are dark Windows Movie&TV: both clips are bright Window Media Player: both clips are dark
However if I load both files into Davinci Resolve, the original is dark and the GF export is bright.
TBH: I'm a bit confused now.
Yeah there a lot of color space parameters passed to the encoder, I tried to set them exactly the same as i got from decoder but that already caused problems because some encoders didn't support some parameters. So there are a few workarounds and there's something wrong there probably. Take a look at src/rendering/ffmpeg_video.rs:init_encoder
A nice test with colors was done in #62 however if input file is not 4:2:2 10 bit then swscale is used without setting the color range like you posted in your code, so it's probably the reason in the ProRes case.
However with x264 and x265, swscale is not used in the rendering pipeline so that leaves us only with encoder parameters where things can go wrong.
It'll be also useful to test ProRes 4:2:2 10 bit as input, then swscale won't be used for ProRes.
I'll try to investigate but your tests are also extremely helpful.
@AdrianEddy i think it's related to colorspace. Checkout this excellent article on that topic: https://medium.com/invideo-io/talking-about-colorspaces-and-ffmpeg-f6d0b037cc2f ffmpeg defaults to BT.601, while in our case BT.709 or BT.2020 is more "correct"
TBH: right about now I'm not sure if this is actually a GF issue. It might be just Davinci Resolve treating the files differently as it's the only programm I tested that yields different colors for original/GF-export.
Update: Realsteady does exactly the same thing.
Reelsteady uses RGB24 for processing and discards any color parameters so it's not worth comparing it. If comparing, we can try raw ffmpeg transcode.
Also don't compare preview in the UI as it's also RGB
What does mediainfo say for both the input and output as far as colorspace and range metadata?
It could be that the file is merely mistagged with inappropriate metadata about colorspace or luma range, and the image data itself is not altered color-wise.
Please test with this version: https://github.com/gyroflow/gyroflow/suites/5296956914/artifacts/164310984
That's a Linux+Mac version, I'm on Windows. I've tested it with a build straight from master, but the color issue is still there. As mentioned earlier, it might just be an issue with Davinci Resolve.
Ok so the last issue here I believe is that Davinci Resolve (but not Premiere, After Effects or MPC-HC) detect the original GoPro file as Limited range, where stabilized one as Full range. Right clicking on media -> Clip attributes -> Data levels -> Full makes it look the same.
Davinci Resolve is the industry standard when it comes to colors, so I would expect both files to be detected the same way
While this is not exactly a Gyroflow issue, ideally I would want for Gyroflow to produce files that behave exactly the same as original. I have examined both original mp4 and stabilized mp4 using MP4 Inspector and YUVView but I wasn't able to figure out how Resolve determines which color range to use, both files metadata look exactly the same to me, and I even tried to copy hvcC box and some NAL metadata, but that wasn't it
If someone is able to figure out which metadata Resolve uses to autodetect that range, and how we can set it in output file, this will be ideal.
I'm not sure if this issue should stay open, thoughts?
That's interesting that Resolve is detecting it as Limited range when everything else treats it as full.
Range handling is the bane of my existence... At least it's not kdenlive, which handles any full-range source very poorly. (It's literally why I spent the money on Resolve...)
I wonder if Resolve is doing some sort of special "GoPro Hero 8 mistags their files, override the metadata" thing.
It appears that my latest GPU driver update has made Resolve unhappy, so poking at Resolve's autodetection may be difficult here.
But at least so far, what I see is that in Resolve between glitches: Luma range Auto = very dark but visible video Luma range Video = black crush, nothing visible Luma range Full = very dark but visible.
I'm getting different results than you are here - what I'm seeing is that Resolve is correctly detecting darkness.mp4 as full range. 17.4.3 on Linux (Ubuntu 21.10 using makeresolvedeb). Forcing it to be interpreted as video does exactly what I'd expect - crush/clip the blacks.
Note that while Resolve is the gold standard, its developers understand that video with improper metadata exists and thus its autodetector can't be trusted, which is why they make it so easy to override the autodetection. That ease of override is why it's the gold standard.
Everything I see indicates that the input file is full range and properly tagged as such - especially the "black crush" that occurs if forcing it to be interpreted as full. If it were limited range misinterpreted as full, I'd expect it to be noticeably washed out.
Gyroflow is treating this identically to resolve and to VLC on my machine.
Link for Adrian.
Having same issue. Colours getting compressed. I don't think its the editor interpretation because I've tried all my files in various video players and editors and still same issue. I changed the data levels from video to full in DaVinci Resolve and the highlights are still blown out and shadows crushed.
It happens with every video I run through Gyroflow. From GoPro Hero 10 and GoPro Hero 7 Black.
Here's a link to one of the original GoPro 10 video files shot with flat colour profile:
https://drive.google.com/file/d/1il642pzeItt-eZ-4_yQhDCcfcKlwF5tI/view?usp=sharing
FYI, there are definitely other people having issues with Resolve and GoPro range metadata: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=158370#p843729
I'm closing this as I haven't seen any reports about it in a long time, except Intel macOS with GPU decoding, which I now disabled by default on these systems, so should be all good