Hi,

I use kdenlive 0.8.2 on kubuntu 11.10 with avchd video format (1080i50). Editing with proxy clips works fine but I have trouble with rendering :
- I can't read any output rendered with FFV1 (i've tried with xine, dragon player, vlc)
- with HuffYUV I have a strange green and red interlaced band at the bottom of the video

Do you have any idea or a better solution for lossless rendering with avchd files ?

Thanks in advance

Thanks for your answer, I learned things.

Unfortunately and I don't know why, when I try lossless h264 settings I only have the audio in the rendered file (no video at all).

Do you think it comes from ffmpeg 0.7.2 ?

What are you playing the h264 back with? Try playing the encoded file with ffplay, you can do this with the command line in a terminal by changing directory in the terminal to where your file exists and the ffplay myfile.avi, to see whether it's a decoding problem with whatever player you're using or whether it really is audio only.

I use the FFV1 codec in a MOV container. FFV1 is a little faster than HUFFYUV and seems to have less issues. I can open the MOV file in ffmpeg, Handbrake, and DeVeDe after rendering without issue.

Here is my render dialog:

Hi,

with the h264 rendering presets (I-frame, slow and fast) the rendered file size is very low (3 Mo for a avchd file near 100 Mo) that's why I think there is only the audio on it. But I can play the rendered file with the arthursucks preset.

@yellow : thank you for this information ! I have a last question if you don't mind : what is the best workflow for lossless editing with interlaced avchd files ?

nicoduv, 'best' is a funny word and something really for you to decide and depends on what you want your 'lossless' files for.

There is x264 lossless options under HQ in render panel. Be aware that although codecs like HuffyUV and now UTCodec are lossless compression the process of encoding to them is not necessarily lossless and that includes the way decoders handle them.

For example Canon 550D video files use 8bit levels greater than 16 - 235 for luma, so does my Canon HV30. But encoding to YCC UTcodec or HuffyUV with ffmpeg squeezes those levels into 16 - 235 causing errors evident in spiked combed histogram.

But lossless h264 will decode as full range levels.

Its important in kdenlive however to change all clips properties to use full luma to do this, thats if they are full luma which is pretty safe to assume with consumer cameras.

Adding any effects in kdenlive or color processing appears to immediately squeeze files into 16 - 235 whatever however.

Just did a quick test to see if anything has changed with these formats using latest ffmpeg from git and from a 'lossless' point of view if the video source is full range luma, like any Canon or Nikon HDSLR or Canon HV20/30/40 etc neither converting to HuffyUV or FFV1 will be 'lossless' when using ffmpeg on the CLI although the formats do support full levels.

Not lossless reason 1:

Luma levels squeeze using ffmpeg as described earlier, so contrast is increased unnecessarily in the video source, so shadows or 'blacks' get a little crushed, not helpful. This is more prominent in Canon DSLR video than say HV20/30/40 as the mpeg2 codec on that camera seems to crush at 16 anyway although luma goes up to and clips at 255.

Kdenlive at least offers the option to 'force full luma' at import, but seems to squeeze for color processing effects.

Not lossless reason 2:

Loss of color matrix conversion info from header of stream.

For example Canon DSLR video requires a BT601 matrix conversion to RGB and is flagged as such in the header of the video stream, but this is a little unusual for HD sources, when transcoding to FFV1 or HuffyUV that information in the header is lost (according to mediainfo and tests) so in absence of the matrix declaration the default conversion to RGB which is a requirement of any color processing in kdenlive and majority of other NLE's is to use a BT709 matrix for HD sources based on pixel count.

The result of using the wrong matrix is a shift in color from reds to oranges, so skin tones turn a little orange. Canon HV20/30/40's are BT709 so not an issue on that.

So as a result it's not unusual to find a source video has been made more contrasty and color hues shifted before even reaching the NLE.

Luckily again kdenlive allows the forcing of color matrix in the video properties.

However transcoding to lossless h264 maintains full luma levels and maintains the color matrix info in the stream header. There's also a optional flag to set fullrange=1 to 'suggest' to media players how to handle the file. Whether they do or not with any of these settings is a different matter. :-)

So it's useful to establish what your video sources actually contain before assuming transcoding or encoding to so called 'lossless' codecs like FFv1, HuffyUV and utcodec is actually a benefit rather than doing damage.

If this is of any interest to anyone, it's easy to see bad handling, a RGB histogram will appear combed, 'spiky' and strong horizontal lines will show through the waveform monitor rendering in kdenlive. Better to use a tool like Avisynth but that's extra work unless you use it already. ;-)

So after importing a clip have a look at the histogram, are there spikes, looking at the waveform are there thicker horizontal bands at regular intervals up the graticule, either / both suggest incorrect handling.

Force full luma in the clip properties make sure the histogram and waveform update, is the histogram and waveform more smooth and undulating now, if so then the source video has full range luma.

Handling the video source incorrectly and then applying color processing to it will decrease 'quality' and promote artifacts especially at edges of contrast.

Lossless compression yes, lossless process not necessarily. :-)