Jump to content

Green bar when decoding HEVC with QuickSync and Tone Mapping


PontusN

Recommended Posts

PontusN

Didn't think I would come a stir the pot in this thread again, but here we are. 

Is there a way to increase the saturation of a specific color during tone mapping? 
As you know Im using QSV to achieve this, and current best tone mapping is bt.2390, the results are very good, but it's currently only available in software.

Hable is unfortunately crushing blacks to much to be usable. 

Reinhard and Mobius is performing quite well, but both suffer from desaturation to some degree, but mostly the reds. Is there a way to fix this with a search and replace in ffmpeg or something similar?

Or is it possible to implement Aces algorithm? (Which I believe suffers from over saturation instead, but I think it's preferable.)

Edited by PontusN
Link to comment
Share on other sites

PontusN

Here I am blaming Emby again aswell. The desaturation is only a problem when viewed in a browser (Same problem in Brave, Edge and Firefox) where I also have a problem with a green bar at the bottom for some reason.

HOWEVER, I just noticed, when an OSD module is overlaying, the green bar disappears and the reds are way more saturated again.
I have provided a short recording.

With VAAPI the same effects occur but without the green bar at the bottom.

2022-05-23 17-40-40.mkv

Edited by PontusN
Link to comment
Share on other sites

6 hours ago, PontusN said:

Here I am blaming Emby again aswell. The desaturation is only a problem when viewed in a browser (Same problem in Brave, Edge and Firefox) where I also have a problem with a green bar at the bottom for some reason.

HOWEVER, I just noticed, when an OSD module is overlaying, the green bar disappears and the reds are way more saturated again.
I have provided a short recording.

With VAAPI the same effects occur but without the green bar at the bottom.

2022-05-23 17-40-40.mkv 1.33 MB · 1 download

HI, can you please attach the corresponding ffmpeg log? Thanks.

Link to comment
Share on other sites

7 hours ago, PontusN said:

Here I am blaming Emby again aswell. The desaturation is only a problem when viewed in a browser (Same problem in Brave, Edge and Firefox) where I also have a problem with a green bar at the bottom for some reason.

HOWEVER, I just noticed, when an OSD module is overlaying, the green bar disappears and the reds are way more saturated again.
I have provided a short recording.

With VAAPI the same effects occur but without the green bar at the bottom.

2022-05-23 17-40-40.mkv 1.33 MB · 2 downloads

That's interesting!

Have you tried any other clients with this same media to what kind of results you get?

Link to comment
Share on other sites

PontusN
13 hours ago, cayars said:

That's interesting!

Have you tried any other clients with this same media to what kind of results you get?

When playing in the iOS app the colors appear correct and with no green bar.

Here are both logs @Luke

The browser one is very large because of this line repeating thousands of times.
 

14:07:56.217 [segment @ 0x152eb01483c0] Non-monotonous DTS in output stream 24:1; previous: 1951, current: 1950; changing to 1952. This may result in incorrect timestamps in the output file.

 

ffmpeg-iphone.txt ffmpeg-Browser.txt

Link to comment
Share on other sites

Please disable HLS subtitles via Diagnostic Options. The file has an insane number of subtitle streams.

Next, please try to disable tone mapping and check whether you'll still see the green bar.

PS: I have split this into a new topic

 

Link to comment
Share on other sites

PontusN
1 hour ago, softworkz said:

Please disable HLS subtitles via Diagnostic Options. The file has an insane number of subtitle streams.

Next, please try to disable tone mapping and check whether you'll still see the green bar.

PS: I have split this into a new topic

 

Is 10+ subtitles really a problem?
Do I understand it correctly that disabling this will cause all subtitles to be burned in, no matter if direct play is available?

Will try disabling shortly

Link to comment
Share on other sites

4 minutes ago, PontusN said:

Is 10+ subtitles really a problem?
Do I understand it correctly that disabling this will cause all subtitles to be burned in, no matter if direct play is available?

Yes, it is a problem, because currently, it generates segment files for each subtitle stream simultaneously.

In the future, transcoding will create segments only for two or three streams (and restart when needed).

6 minutes ago, PontusN said:

Do I understand it correctly that disabling this will cause all subtitles to be burned in, no matter if direct play is available?

No. It just does what it says.

Link to comment
Share on other sites

1 minute ago, PontusN said:

Disabling hardware TM removes the green bar.

Forcing software Transcoding AND TM yields good colors and no green bar.

ffmpeg-noHLS-TM-Software.txt 49.67 kB · 0 downloads ffmpeg-noHLS-TM-disabled.txt 58.04 kB · 0 downloads ffmpeg-noHLS-TM-enabledtxt.txt 55.54 kB · 0 downloads

OK, great, so it is probably related to the OpenCL tone mapping. Could you please turn TM back on and try various resolutions (by reducing the quality).

If my suspicion is right, it depends on whether the image height is a multiple of 16 or 32 (which 1080 isnt').

Link to comment
Share on other sites

The ultimate confirmation would be to try with VAAPI but OpenCL tone mapping selected..

Link to comment
Share on other sites

PontusN

@softworkz

The post above the one you quoted is tested with OpenCL.

Indeed only 4K and 1080p has the green bar. All resolutions are desaturated though.

Link to comment
Share on other sites

PontusN
5 minutes ago, softworkz said:

Yes, but it's QuickSync, not VAAPI.

I don't know if we're actually looking at the same post, but here is a log with VAAPI and OpenCL.

The same desaturation and OSD effect occurs, but without the green bar.

ffmpeg-VAAPI-OpenCL.txt

Link to comment
Share on other sites

3 minutes ago, PontusN said:

I don't know if we're actually looking at the same post,

image.png.fc29a930ff2ea5126866b9063319fa24.png

These are all the attachments you had posted. Which one do you think would have been the one with VAAPI + OpenCL?
(except the one you have posted right now)

Link to comment
Share on other sites

pwhodges

BTW, I have seen files sourced from Netflix with over 30 subtitle streams...  Plus a dozen or so audio streams.  I don't have any to test, though, as I remove the excess myself.

Paul

Link to comment
Share on other sites

Just now, pwhodges said:

BTW, I have seen files sourced from Netflix with over 30 subtitle streams...  Plus a dozen or so audio streams.  I don't have any to test, though, as I remove the excess myself.

Paul

It's not that the files would be a problem. It's a problem how Emby handles them currently...

Link to comment
Share on other sites

PontusN
1 minute ago, softworkz said:

image.png.fc29a930ff2ea5126866b9063319fa24.png

These are all the attachments you had posted. Which one do you think would have been the one with VAAPI + OpenCL?
(except the one you have posted right now)

Yea sorry I never posted a log from it, just described in text about VAAPI (The second post in this thread). (Should have added about OpenCL, forgot about native since I never use it.)

  • Thanks 1
Link to comment
Share on other sites

Nevermind.

OK, so when it doesn't happen with VAAPI, then it might be due to the interop with OpenCL.

As a last test, could you please try the following with QuickSync and OpenCL TM:

  • Make it playback with a lower resolution
  • Take note of the scale filter string in the ffmpeg command
  • Use Diagnostic Options >> Text Replace
  • Find: enter the scaled down resolution string ('scale_qsv@...')
  • Replace: same string as above, but change the resolution values to
    • 1920 1088
    • 1920 1080 (just for counter-checking, does nothing, should show the green bar again)

Thanks

Link to comment
Share on other sites

PontusN
40 minutes ago, softworkz said:

Nevermind.

OK, so when it doesn't happen with VAAPI, then it might be due to the interop with OpenCL.

As a last test, could you please try the following with QuickSync and OpenCL TM:

  • Make it playback with a lower resolution
  • Take note of the scale filter string in the ffmpeg command
  • Use Diagnostic Options >> Text Replace
  • Find: enter the scaled down resolution string ('scale_qsv@...')
  • Replace: same string as above, but change the resolution values to
    • 1920 1088
    • 1920 1080 (just for counter-checking, does nothing, should show the green bar again)

Thanks

So this is interesting. When playing a 4K file and scaling down to 1080p the green bar in not there (Without the text replace).

So the green bar is only there when no scaling at all is taking place.

I could also not find 'scale_qsv' but found this instead: 'vpp_qsv@f1=width=1920:height=1080' setting this to 1088 changed nothing, even if it's visible in the logfile (Maybe a 'user sessions' issue not showing 1088 and it actually worked fine.)

ffmpeg-QSV-TM-textreplace1088.txt ffmpeg-QSV-TM-AutoScaleto1080p.txt

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...