Hi,

I have some problems during rendering .mp4 files, I have to use MPEG-2 profile which is really perfect for me. There is a small but...

The source video file use yuvj420p (instead of yuv420p by default in kdenlive profiles), so it means if I used yuv420p contrast is smaller and black is less black than with yuvj420p. I did manage with mp4 files as I added to my favorite profile this line 'pix_fmt=yuvj420p' but in MPEG-2 aftr adding this line 'pix_fmt=yuvj420p' after rendering I have got file yuv420p.

It is posibble to have yuvj420p in MPEG-2 profile?

What camera and codec are the source yuvj420p from, h264 from a Canon or Nikon DSLR?

Nikon D5100

Thought so, yuvj420 is the wrong pixel format type for the D5100, it's the full range flag set on in the file which ffmpeg reads as meaning yuvj420, it's really yuv420 and is handled better as yuv420.

If you want the very best out of it, you need to switch the full range flag off. I do with my Canon h264 which is handled the same as yours due to the same flag. Then ffmpeg reads it as yuv420.

The brightness problem you mention is because ffmpeg scales the luma going from yuvj420 to yuv420 but it does it totally unnecessarily.

So what should I do?

When I use yuv420 (h264) I see a difference in comparation with raw file.
Only yuvj420 looks exactly the same.

Well I think you have a few possible options, but i think Option 1 is simplest:

1. Remux the Nikon files using a tool that lets you mainpulate the VUI Options 'fullrange' metadata attached to the MOV's, such as a patched build of GPAC's MP4Box which is what I currently do to switch the 'fullrange' flag off, so FFmpeg treats the files as yuv420p even though they have full range levels, until something simpler is sorted out. This also involves muxing the output h264 and audio stream from a kdenlive project and setting the 'fullrange' flag on in the MOV or mp4 container format output in order to force yuvj420p assignment for playback. All this is additional steps and work arounds.

2. Pursue an FFmpeg solution that stops or force a different pixel format for the Nikon source files compatible with yuv420p codecs like h264, DNxHD etc. Bug report to FFmpeg maybe, maybe there is already a solution.

3. Pursue a custom Kdenlive Encoding Profile that uses yuvj420p pixel format. Not sure this is going to work as FFmpeg is assigning yuvj420p solely because off the VUI Option and not the luma levels in the h264 stream. VUI Options are only applicable to h264 anyway I think.

4. Use a tool like AVISynth to reencode to an intermediate lossless codec that FFmpeg uses a yuv420p pixel format for regardless. Long winded, lots of disk space and time wasted.

I've explained a little what's going on in a blog post today. http://blendervse.wordpress.com/?p=768&preview=true

Hey Yellow, a guy in another thread mentioned FFMBC. I haven't installed and played with it yet, but it occurred to me that it may solve some of these issues. What do you think?

http://code.google.com/p/ffmbc/

It would seem that ffmbc deals with this issue:
http://groups.google.com/group/ffmbc-discuss/browse_thread/thread/2ef275d6bd7202a3#

No don't so they start off talking about YCbCr to RGB wrong levels, but in fact is was a typical conversion 16 - 235 and all that, so moved on to color matrix BT601 to BT709 which is nothing to do with restricted vs full range but more to do with color encoding again it only becomes an issue with YCbCr to RGB conversions, so some one provides a patch to maintain levels between yuvj420p assigned sources and RGB so when writing images from yuvj420p the levels transfer unaffected. This can be seen with ffmpeg based apps like Blender that will output correct levels images from yuvj420p source but stuff up luma encoding to YCbCr because the source is deemed to have full range levels.

The fundemental problem is that many cameras shoot full range including the C300 but as its not h264 the VUI Options are not available anyway. Also many cameras shoot full range h264 but choose not to use the flag and that h264 is assigned yuv420p by ffmpeg. :-) Its just the same levels in the h264 stream.

The VUI Options are to signal to a media player how to playback why on earth NLEs are handling it like that is questionable. :-)

Ahhh, I see. The whole problem is with how NLEs handle the flag.

Just out of curiosity, if VLC is going to crush luma anyway, does it really make a visible difference if I edit and export with those values already crushed? I know that from a purist's standpoint "lossless" should be lossless, but from a practical standpoint don't NLEs handle the files in this way because, in the end, they are WYSIWYG, and this is how people are going to be viewing your file on VLC? Otherwise the image would always look better in the NLE than during playback, and the user would complain about the encoder being broken ...

I'm assuming, of course, that I will always be using something like VLC and not a "full range" player. Does such a thing exist?

Or does VLC also handle the file differently (better image quality) when the flag is turned off or you've used a lossless intermediate codec from AVISynth?

Sorry I'm being a bit thick. This interests me and I'm trying to get my head around it.

No your absolutely correct about media playback will almost certainly be 16 - 235 and DVD, Bluray, Youtube etc expect restricted range luma but with regard to NLEs the question is when we consider that many of us shoot video with the objective of capturing as much info as possible in a 'flat' or LOG appearance in order to grade it all of which will ultimately be done in RGB do we want to do that color processing on RGB data derived from a mangled conversion or by a controlled conversion, do we want control over when where and if we need 16 - 235 output and it is at encoding to delivery that the decision should be made, not all output is for delivery, it maybe going on to a grading app or other post process then maybe we want to maintain full 8bit gradation rather then squeeze at that point.

What we appear to have is a dumb 'this source must be scaled to maintain levels' ie squeeze to 16 - 235 when decompressed into the NLE in order for the NLE to do the typical 16 - 235 back to 0 - 255 RGB. Histograms show effect of that compared to a 'proper' full range conversion to RGB ie: lossless round trip.

With regard to whether there is a visible degrading of quality going straight from squeezed source to me if its evident a process can be improved then why not, but its an individuals choice but could be useful to be aware.

Yeah, I know what you mean. I shoot photos in RAW and retouch the TIFFs in 16bit, only to upload them to some photo sharing site with awful JPEG compression. But I always think, hmm, one day I might need to blow that up for my big gallery opening hehe :)