| Summary: | Exporting with pix_fmt=yuv444p does not use 4:4:4 chroma subsampling | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | bugreports.l7dy6 |
| Component: | Rendering & Export | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | bugreports.l7dy6, fritzibaby, lras916 |
| Priority: | NOR | Keywords: | triaged |
| Version First Reported In: | 24.12.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Source image, Kdenlive project file, Kdenlive render script, Kdenlive video, FFmpeg video
A comparison showing that Kdenlive renders a lossy image, even when yuv444p and qp=0 are specified. |
||
Thank you for reporting. Kdenlive works with 8-bit sampling only. Update to 10bit is ongoing. (In reply to emohr from comment #1) > Thank you for reporting. Kdenlive works with 8-bit sampling only. > Update to 10bit is ongoing. Thank you for the fast response. I'm not an expert with video terminology, but I believe that we're talking about two different things. I was referring to chroma subsampling (https://en.wikipedia.org/wiki/Chroma_subsampling) while 8-bit and 10-bit refer to color depth (https://en.wikipedia.org/wiki/Color_depth). I'm only working with 8-bit videos. Do not use H264 encoding due to YUY 4:4:4 encoding limitations. Use x264 encoding with -qp 0 parameter to get a lossless YUY 4:4:4 output file. In detail: YUV 4:4:4 pixel format (yuv444p) can be used for H.264 encoding, but it has limitations. While x264 supports lossless encoding with yuv444p, it requires specific configurations, such as using -qp 0 for lossless output. However, many H.264 encoders primarily support yuv420p due to compatibility issues with various players and devices Additionally, profiles like high444 are not compatible with lossless encoding in x264 Therefore, while technically possible, practical use may be limited depending on the encoder and target playback devices. Therefore, it is not suggested to use h264 for encoding in yuv444. For example NVIDIA's NVENC can encode H.264 video in the YUV 4:4:4 format, as confirmed by user experiences with FFmpeg and the h264_nvenc encoder. However, while encoding is supported, decoding H.264 YUV 4:4:4 is not supported by NVDEC, which only handles YUV 4:2:0 for H.264. Thus, you can encode using NVENC but will need software decoding methods for YUV 4:4:4 content. (In reply to emohr from comment #3) > Do not use H264 encoding due to YUY 4:4:4 encoding limitations. > Use x264 encoding with -qp 0 parameter to get a lossless YUY 4:4:4 output file. H264 is what x264 encodes to. I'm assuming that you're talking about hardware H264 encoders (as opposed to x264 which is a software encoder). I've always used x264 because I know that my hardware encoder can't do 4:4:4. > YUV 4:4:4 pixel format (yuv444p) can be used for H.264 encoding, but it has > limitations. While x264 supports lossless encoding with yuv444p, it requires > specific configurations, such as using -qp 0 for lossless output. According to FFmpeg's wiki (https://trac.ffmpeg.org/wiki/Encode/H.264#a1.ChooseaCRFvalue), using -crf 0 is lossless for 8-bit videos, but I did run another test using -qp 0 to see if anything changed. See the image I attached. Unfortunately, Kdenlive still renders with inaccurate colors, even though I set qp=0 in the render script. The artifacts look similar to an FFmpeg render at yuv422p. Created attachment 177468 [details]
A comparison showing that Kdenlive renders a lossy image, even when yuv444p and qp=0 are specified.
I would like to say that I am also encountering this issue. Even when trying to export lossless video using one of the "lossless/HQ" render options, the output is still squished down to 4:2:2 with the "ffv1" and "utvideo" options. I even tried to create my own render preset with utvideo and specifying "pix_fmt=rgba" as an additional parameter. The rendered video is in "rgba" format, but the image looks like 4:2:2. This makes me think that something somewhere else down the chain converts the images to 4:2:2. A finding I made was that the "Video with Alpha">"FFmpeg with FFV1" actually DOES render losslessly. And I think it's all because of the parameter "mlt_image_format=rgba". I then tried adding this parameter to a modified version of the "Lossless/HQ">"Ut Video" preset and suddenly that renders losslessly as well. I definitely agree that this is a bug that should be fixed, but as a workaround, OP should add "mlt_image_format=rgba" to their list of parameters. (In reply to lras916 from comment #6) > I would like to say that I am also encountering this issue. Even when trying > to export lossless video using one of the "lossless/HQ" render options, the > output is still squished down to 4:2:2 with the "ffv1" and "utvideo" > options. I even tried to create my own render preset with utvideo and > specifying "pix_fmt=rgba" as an additional parameter. The rendered video is > in "rgba" format, but the image looks like 4:2:2. This makes me think that > something somewhere else down the chain converts the images to 4:2:2. > > A finding I made was that the "Video with Alpha">"FFmpeg with FFV1" actually > DOES render losslessly. And I think it's all because of the parameter > "mlt_image_format=rgba". I then tried adding this parameter to a modified > version of the "Lossless/HQ">"Ut Video" preset and suddenly that renders > losslessly as well. > > I definitely agree that this is a bug that should be fixed, but as a > workaround, OP should add "mlt_image_format=rgba" to their list of > parameters. Thank you for checking this out. I can confirm that adding "mlt_image_format=rgba" to my custom preset (with pix_fmt=yuv444p in my case) fixed the issue. I did some more research and found this comment by the creator of MLT regarding their stance on the issue: https://github.com/mltframework/mlt/issues/398#issuecomment-452977479 As the default will not be changed upstream, I think it would be a good idea to make sure all the rendering presets under "Lossless/HQ" contain mlt_image_format=rgba, like all the presets under "Video with Alpha" have. When 10-bit support is added in the future, I think it would be nice to have a GUI drop-down menu next to "Render full color range" called "Pixel format" that lets you choose from "yuv420p" to "yuv444p10le", for example. To implement this, you would need to check the encoder's supported pixel formats. You can use ffmpeg -h encoder=(encoder name, ex. libx264) to check this. The default should be whatever the selected preset specifies. This could also be split into 2 options ("Bit depth" and "Chroma subsampling"), but I prefer "Pixel format" since it ties directly to the corresponding FFmpeg option. |
Created attachment 177114 [details] Source image, Kdenlive project file, Kdenlive render script, Kdenlive video, FFmpeg video SUMMARY I have H.264 videos encoded in the yuv444p pixel format, and I would like to edit them in Kdenlive and export them in yuv444p. I've tried creating a custom render preset with the "pix_fmt=yuv444p" flag added, exporting with crf=0 which is supposed to be lossless, and enabling "Render full color range", but the exported video still shows subsampling artifacts, despite being in the yuv444p format according to VLC and FFmpeg. STEPS TO REPRODUCE 1. Add a PNG image or yuv444p video to the timeline 2. Use a custom render preset that has "pix_fmt=yuv444p" 3. Take a screenshot of the rendered video with VLC or FFmpeg OBSERVED RESULT Video is encoded in yuv444p format, but still shows chroma subsampling artifacts EXPECTED RESULT Video is encoded in yuv444p format and has no chroma subsampling artifacts (and is identical to the original if exported with crf=0) SOFTWARE/OS VERSIONS Arch Linux Kernel Version: 6.12.7-arch1-1 (64-bit) KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION I've attached the project files used to demonstrate this issue, along with an FFmpeg-rendered video that shows the correct behavior (has no chroma subsampling artifacts).