While trying to optimise my recordings I noticed that my videos were too dark for some reason. I traced it down and it seems to be some sort of an issue present in mlt, but not in ffmpeg. Here's a sample file:
http://www.mediafire.com/download/6cwqy ... sample.mkv
Make sure to download it and view it in ffplay or mkv, VLC won't do. For reference, this is the brightness it should be in (the decor on the columns is visible):

When rendered with kdenlive/melt, this is what I get instead (the side of the column is completely black):

I've found no way to render this where it would preserve the colour information. I assume that this has something to do with the pixel format, because their support varies greatly from player to player. However, both the input and the output are yuvj420p. Maybe mlt does some sort of an internal format conversion step that causes this?

Also, looks like ffmpeg had a related issue: https://trac.ffmpeg.org/ticket/225

So it's possible it's system-specific. Could someone try and reproduce this?

I'm using kdenlive 0.9.10 on openSUSE 13.2.

Hello,
I remember similar color space problems (Rec 609 vs Rec 701 ?) already discussed on MLT list (or maybe ours with MLT devs). Maybe you could look for archives. I don't remember if there was an easy solution...
Please let us know so that we can keep track in this forum and maybe the manual!

Looking at this on ffplay and it looks absolutely fine.

A lot of players and youtube will not render the darkest and brightest levels of full-range video like the sample.

Are you sure you don't want to render a more compatible yuv420p?

CorrosiveTruths wrote:Looking at this on ffplay and it looks absolutely fine.

A lot of players and youtube will not render the darkest and brightest levels of full-range video like the sample.

Are you sure you don't want to render a more compatible yuv420p?

That's not true. I have a full-length video comparison between the clip processed by FFmpeg -c:v copy and MLT, and the difference is (quite literally) night and day:
https://www.youtube.com/watch?v=CazE84qpvd0
https://www.youtube.com/watch?v=MDI6haod2hI

And yuvj420p is what I get when using the specific recording software that I'm using. I can't change that.

GreatEmerald wrote:

CorrosiveTruths wrote:Looking at this on ffplay and it looks absolutely fine.

A lot of players and youtube will not render the darkest and brightest levels of full-range video like the sample.

Are you sure you don't want to render a more compatible yuv420p?

That's not true. I have a full-length video comparison between the clip processed by FFmpeg -c:v copy and MLT, and the difference is (quite literally) night and day:
https://www.youtube.com/watch?v=CazE84qpvd0
https://www.youtube.com/watch?v=MDI6haod2hI

And yuvj420p is what I get when using the specific recording software that I'm using. I can't change that.

I was referring to the sample specifically, since you said it was a problem, I've also seen youtube occasionally get it right, (like when I tried your sample, oddly enough).

Of course you can change yuvj420p video, you can specify the conversion with -pix_fmt yuv420p in ffmpeg, or add pix_fmt=yuv420p in mlt / kdenlive.

Or you risk youtube not recognising your full range file and doing the conversion poorly, or not at all. As you can see in your crushed white / black video upload.

The final video is going to be yuv420p on youtube anyway, no matter what you do, so might as well let mlt do it.

Does the video look dark in kdenlive itself? Because that's a different issue (one that you fix by ticking full luma in advanced for your clip)

Huh, that's true, ticking full luma indeed results in kdenlive rendering the video with proper colours. So why isn't it default?..

GreatEmerald wrote:Huh, that's true, ticking full luma indeed results in kdenlive rendering the video with proper colours. So why isn't it default?..

Usually, mlt would auto-detect the correct luma range. Are you on an older version by any chance?

It's using MLT 0.9.2 at the moment.

GreatEmerald wrote:It's using MLT 0.9.2 at the moment.

I remember having issues with 0.9.0, and I'm on 0.9.6 now, so maybe try updating it, but hey, if ticking that option works, you needn't bother if you're happy with the results, right?

Updated, and you're right, now it's fixed. The checkbox isn't selected, but it works correctly (I guess the checkbox just means "force").