This forum has been archived. All content is frozen. Please use KDE Discuss instead.

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

Tags: None
(comma "," separated)
getoperational
Registered Member
Posts
5
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
5
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
5
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
1315
Karma
1
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.


getoperational
Registered Member
Posts
5
Karma
0
ddennedy had the right answer, I was able to do lossless editing in kdenlive by:
converting my source file to huffyuv with ffmpeg
import the huffyuv file into kdenlive and make edits
hit the render button, select the existing render profile "huffyuv (huffyuv+flac)", hit the "create new profile" button
give the new profile a name, change extension to "avi", delete everything in the "parameters" box and paste this in:
f=avi acodec=pcm_s16le vcodec=huffyuv mlt_image_format=rgb24 pix_fmt=rgb24

sidenotes:
I used wav (aka pcm_s16le) for the intermediate editing steps but that can be changed to match your situation.
I used avi for the intermediate steps because when I input 60.000fps source material into kdenlive and then export to mkv the resulting video is 60.119fps, but if I use avi the output framerate matches the input.
After exporting the huffyuv avi from kdenlive I used ffmpeg to re-encode.
User avatar
bartoloni
Moderator
Posts
1510
Karma
4
OS
getoperational wrote: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.

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?


i went crazy for this thing for a lot of time (bad contrast/colors on renderings) finally i found that the issue is the hardware accelleration of VGA card

on ATI card i fixed the issue forcing the Video Output colors (yuv).. when i switched to an old Nvidia card.. the old videos (with a real black and good contrast) becomes bad contrasted.. (same videos.. not new renderings) ... after that i switched again to a more recent Nvidia VGA... .. and all the videos (with different YUV) become good contrasted with a real black. (using a VLC flag for harwdare accelleration for reproduction)

viewtopic.php?f=272&t=142746
https://ffmpeg.zeranoe.com/forum/viewto ... 15&p=12709
Image
vibits
Registered Member
Posts
10
Karma
0
sorry for ressurrecting an ond topic but im here just to inform its not an problem related to videocard or hardware. its an problem in kdenlive and the problem persist untill today. I posted an topic about this issue and im waiting some light on it.

otrher softwares has option to solve it, so its an kdenlive related issue.


Bookmarks



Who is online

Registered users: Bing [Bot], Evergrowing, Google [Bot]