Reply to topic

yuv444 h264 input, matching output, color loss (pics)

getoperational
Registered Member
Posts
3
Karma
0
I am attempting to record a screencast (h264 yuv444 lossless), edit the video in kdenlive, and then render the output (h264 yuv444 lossless).
Somewhere along the way I seem to lose color information.

(the line I use for recording screencasts)
avconv -f x11grab -s 1920x1080 -r 60 -i :0.0 -vcodec libx264 -preset ultrafast -qp 0 -pix_fmt yuv444p ~/Desktop/screencast/screencast.mkv
The resulting video looks great. Color accuracy looks much closer to the original image than a yuv420 screencast would be.

I then import this video into kdenlive, hit "render" and select lossless, then modify the lossless variables to make the colorspace output match the colorspace input. I am not using any filters or even editing the video yet, just import and render as a test.
(default kdenlive lossless settings)
f=matroska acodec=pcm_s16le ac=2 pix_fmt=yuv420p vcodec=libx264 qp=0 preset=ultrafast aspect=%dar
(my modified lossless settings)
f=matroska acodec=pcm_s16le ac=2 pix_fmt=yuv444p vcodec=libx264 qp=0 preset=ultrafast aspect=%dar

The resulting video appears to be h264 yuv444 according to VLC media player, however color information seems to have been lost along the way.
(original)
Image

(kdenlive output)
Image

(original)
Image

(kdenlive output)
Image

This also seems to happen if I try to use the other lossless codecs such as huffy or ffv1.
Does anyone know why this might be happening? If I just re-encode the video using those same settings with avconv/ffmpeg the color is preserved.
Is there some part of the kdenlive rendering process (such as mlt framework) that forces color to be reduced to something like yuv420 before the final output?
khsien
Registered Member
Posts
20
Karma
0
OS
I'm not sure, but you said you used h264 codec for this movie render. I thought that h264 is a codec with lossy compression, maybe that's why?
getoperational
Registered Member
Posts
3
Karma
0
khsien wrote:I'm not sure, but you said you used h264 codec for this movie render. I thought that h264 is a codec with lossy compression, maybe that's why?


h264 has a lossless mode which I invoke with the "-qp 0" option, and the "-pix_fmt yuv444p" option is requesting a particular colorspace output, which matches the input.
I have run videos through ffmpeg/libav over and over with these settings and the resulting video would look the same as the original h264 yuv444. However when it touches kdenlive I get chroma bleeding as shown in the zoomed icon image.

I am guessing some part of the rendering pipeline has a default setting that is reducing the color. The rendered output I get from kdenlive claims to be h264 yuv444 just like the original file and just like I requested with the render options, however color damage happens somewhere along the way.
getoperational
Registered Member
Posts
3
Karma
0
I can confirm this is not an h264 problem, it happens with other video types as well.
If I create a huffyuv file that is perfect quality rgb, import into kdenlive, then export with the huffyuv "lossless" template built into kdenlive the resulting file says it is now yuv444 and the colors are degraded in the same way as the above examples.

This is with kdenlive 0.9.6 on Mint16 (Ubuntu 13.10).
ddennedy
Registered Member
Posts
1314
Karma
0
The MLT render thread defaults to MLT image format "mlt_image_yuv422". You can override this by adding to a Kdenlive render profile as "mlt_image_format=rgb24" or "mlt_image_format=rgb24a". You will still need to specify "pix_fmt" as that is needed by libavcodec.



 
Reply to topic

Bookmarks



Who is online

Registered users: andreas_k, Baidu [Spider], Bing [Bot], cloose, cloudslayer, cylverbak, davidemme, Exabot [Bot], Google [Bot], google01103, Hans, joaob, koriun, Majestic-12 [Bot], MSNbot Media, nbelavic, paulus3005, pedrorodriguez, simonv, sinclair, wolfi323, Xiceph, Yahoo [Bot]