Enhance: Better previews for HDR video (CLOSED, IGNORE)

[invario]

Hello, hopefully I did this correctly this time, thank you.

• Resolves: [Bug]: Previews of HDR videos being generated are washed out (needs tonemap?) #44881

Summary

Previews currently generated for HDR videos result in desaturated/washed out images because of lack of tonemapping. This enhancement detects HDR videos and adds additional switches to the ffmpeg command to generate much improved images.

• ffprobe is required (included with ffmpeg)
• ffmpeg must have been built with libzimg (--enable-libzimg) for the zscale filter to work. This is platform/package dependent. (e.g. FreeBSD 13 does not. Alpine does. Unsure of others.)
• adds configuration option preview_ffmpeg_enable_hdr
• adds [optional] configuration option preview_ffprobe_path

Before

After

TODO

• Perform actual check to see if ffmpeg was built with libzimg. However, this would require another proc_open with command ffmpeg -v quiet -filters and searching its output for 'zscale'. I don't think it's necessary as HDR preview generation would be disabled by default. Any user enabling the option should be aware of the requirement before doing so.
• Update config.php.sample to show new options
• Need additional testing

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[icewind1991]

(disclaimer: my knowledge about ffmpeg/HDR is limited)

Is there a downside to using the hdr options for non-hdr content? It would be better to have hdr previews "just work" without having to do any special config would be better (assuming the ffmpeg has the proper support ofc).

Doing the extra exec to feature-detect seems fine to me, since we can also cache it if we're worried about the overhead. (Though the cost of ffmpeg -v quiet -filters is probably insignificant compared to the actual preview generation)

[invario]

(disclaimer: my knowledge about ffmpeg/HDR is limited)

Is there a downside to using the hdr options for non-hdr content? It would be better to have hdr previews "just work" without having to do any special config would be better (assuming the ffmpeg has the proper support ofc).

Yes. The downside of using the HDR switches on an SDR video is that previews generated are degraded (extremely dark). That's why there is a need to differentiate. Do you need a sample image?

[icewind1991]

I mean always doing the logic that is gated behind preview_ffmpeg_enable_hdr currently (so including the check for "smpte2084" or "arib-std-b67").

[invario]

I mean always doing the logic that is gated behind preview_ffmpeg_enable_hdr currently (so including the check for "smpte2084" or "arib-std-b67").

Ah, sorry, misunderstood. No, there's no downside as long as we confirm somewhere earlier that ffmpeg was built with libzimg and ffprobe is also installed.

[icewind1991]

Ok, I would be in favor then of always enabling the behavior and doing the feature detection

[invario]

Ok, I would be in favor then of always enabling the behavior and doing the feature detection

I can write the routine to detect, and then have the value of preview_ffmpeg_enable_hdr set based on the results (instead of a user config option)?

Not sure where I should insert the routine for least performance impact. What did you mean by 'cache' the results earlier... I admit I don't know how to go about that.

[invario]

Hang on actually, just figured out a more elegant way to do this. ffmpeg/ffprobe already display compile options which is output to stderr by default, unless suppressed by -v quiet.

I can use the same exec I used for ffprobe without the -v quiet and check its stderr for '--enable-libzimg'. No need to do a separate check.

[invario]

There we go. Now checks for the presence of libzimg (zscale filter) when running ffprobe on the video.

[invario]

@st3iny @joshtrichards Hello, I run jnto your names frequently when looking at preview generation related stuff. Would you mind taking a look? TIA!

[invario]

I would love for this to gain some traction or if I can get some guidance on additional steps that I may be missing. Thank you.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[icewind1991]

@invario can you resolve the formatting issues from https://github.com/nextcloud/server/actions/runs/13774792167/job/38566161541?pr=51356

[invario]

@invario can you resolve the formatting issues from https://github.com/nextcloud/server/actions/runs/13774792167/job/38566161541?pr=51356

Sorry, I'm a novice at this... working on it now, thank you.

[invario]

Okay, I think I fixed the formatting. Apologies for the improper commit message, did not realize it would push here. (I'm learning!)

[invario]

Once again, apologies, but I'm making a mess of things. :(

[invario]

I'm going to do a new PR and close this one out.