Problems with DNxHD quality (fine vertical lines)

I am working with 1080p AVCHD footage from my Canon 7D. I want to transcode the footage to Avid DNxHD, as it's easier and quicker to edit with. However, I've noticed a quality issue with DNxHD in Kdenlive, there are fine vertical lines in the footage. These lines can be very distracting and obvious in certain scenes. This is rather disappointing, since DNxHD is supposed to be a near lossless format. I'm using Kdenlive, MELT 0.7.6 & ffmpeg 0.10.1 (I upgraded to the latest ffmpeg hoping to fix the issue).

I viewed DNxHD footage in VLC player but there are no vertical lines at all, it looks great as it should. I also used 5DtoRGB to transcode footage to DNxHD but the lines remain. The problem only occurs in Kdenlive, it somehow introduces vertical lines when it decodes DNxHD.

Has anyone seen this problem? Any solutions?

Here's a comparison between DNxDH and high bit-rate Mpeg4 exported from Kdenlive:

And the Original images: &


I've done a quick test transcoding a couple of T2i/550D clips via kdenlive and added both the original canon file and the dnxhd 25P 185 clips to the kdenlive timeline, then simply extracted frame 1 from both clips from the project monitor in kdenlive for comparison. I trust this process for quick comparisons between frames but as no vertical lines appeared I haven't bothered to look at the dnxhd file in more detail so could you post a link to a native canon file which exhibits this problem.

You say only kdenlive gives this issue but you also mention 5DToRGB giving same vertical lines, was that a typo or is that correct? As 5DToRGB also uses FFmpeg as the codec suite.

A few other comments:

There are quite a number of things going on that really are messing with the original canon file in the transcode to any codec even lossless ones that make the process of converting to a 'near lossless / lossless' codec anything but a lossless process with regard to Canon & Nikon DSLR h264.

You'll notice in kdenlives clip properties that the original canon file is 4:2:0 and the DNxHD is 4:2:2 so some chroma interpolation has gone on, usually a good thing, but there are possible issues with regard to correct chroma placement that may contribute to the problem.

Canon h264 files are given a pixel format of yuvj420p (ie: JPEG/RGB levels) rather than yuv420p. FFmpeg will complain about encoding yuvj420p to yuv420p or yuv422p by mentioning incompatible pixel formats and as a result scale the luma in our Canon and Nikon h264 files into 16 - 235. So you will see a contrast change comparing native source with DNxHD, that's not lossless. The reason I explain here:

You'll also notice in kdenlives clip properties that as well as chroma differences there is also a color matrix difference, native Canon files use a BT601 color matrix, the DNxHD have been assigned a BT709 color matrix, in any conversion to RGB including playback will show a clear shift in certain color ranges such as pink appearing more orange. That's not lossless.

So although your vertical lines 'difference' image is quite substantial in the amount of difference shown, a lot, disregrding the vertical lines is because of the two points above, change of contrast and color matrix.

Really need to use a canon source file from yourself that manifests the vertical lines.

My immediate conclusion, for what it's worth is that this could be a FFmpeg specific bug with DNxHD decoding/encoding, or a kdenlive render profile bug, or possibly camera, camera settings or exposure related, although I understand from your description the vertical lines are not present in all playback.

Kdenlive offers some control over how the clips are interpreted via the clip properties box to resolve some of the problems.

The problems I mention above are not limited to kdenlive, in fact kdenlive offers more control than many commercial transcoding tools and NLE's regarding clip interpretation and handling. You'll see same contrast change and wrong color matrix from any QT based decoding / encoding like Mpegstreamclip, Grinder et al.

Other comments:

Kdenlive has a neat proxy workflow.

ProRes encoding / decoding at various profiles is available from git builds of kdenlive via the build script.

I've uploaded a short piece of DNxHD185 footage I exported it from Kdenlive using the Render button using this script...

f=mov acodec=pcm_s16le ac=2 vcodec=dnxhd vb=185000k aspect=%dar-s

There are visible vertical lines in the footage when viewed inside Kdenlive & using SMplayer, VLC Player & Totem player.

However, when I used the Transcode function, it creates DNxHD185 that is without any lines when viewed outside Kdenlive. But it shows lines in Kdenlive. Here's the scrip for transcoding...

-s 1920x1080 -r 25 -vb 185000k -threads 2 -vcodec dnxhd -acodec copy

I also used 5DtoRGB to transcode to DNxHD185, this produced no lines outside Kdenlive, but has lines in Kdenlive (the file is too big for Dropbox).

So it seems to be restricted to Kdenlive's Display and the Render function. For some reason,Transcoding produces footage that has no lines (outside kdenlive). Hope that helps.

Here's a possibly related bug (lines and dots in DNxHD) traced back to libswscale 0.6.2 (my version). I'm running Ubuntu 10.10.

Do you have a sample of native Canon h264 that you have problems with? Is it all your files or just odds ones?

2nd / 3rd generation rendered output, that does this in one player and not this in another I'm not really interested in looking at, native source files and work through the problem to duplicate it or not as the case may be.


Ok, I ran a Canon T2i/550D h264 through kdenlive and exported to DNxHD using your render profile:

f=mov acodec=pcm_s16le ac=2 vcodec=dnxhd vb=185000k aspect=%dar-s

I then loaded the file back into kdenlive and checked a full screen Project Monitor window and extracted a frame and can see no vertical lines like the samples you provide.

I transcoded using your transcode profile:

-s 1920x1080 -r 25 -vb 185000k -threads 2 -vcodec dnxhd -acodec copy

And imported into kdenlive timeline but see no vertical lines in kdenlives Project Monitor window or extracted frame.

So unless there is something specific about 7D video and I've seen reports on various forums about both vertical and fine horizontal lines then what else could it be?

Need a 7D sample file.

Sorry about that. Here's some original Canon 7D footage, there's no banding at all in the original footage.

Also, I downloaded DNxHD185 sample footage I found on the web (in this case 1080i from a HD camcorder(?)). The lines are faintly visible in Kdenlive and they become much more obvious when Rendered back to DNxHD185, the lines are visible outside Kdenlive. I then brought it back into Kdenlive and the banding got worse, it's accumulative. The problem is not specific to my camera. Sorry if I seem a bit picky, but the banding can get very obvious is certain scenes.

An extracted a frame:


Here's an export from Kdenlive, DVCPRO50 sample converted to DNxHD185 using Render. The vertical lines are broader and easy to see. But when I Transcode the DVCPRO footage, there are no lines.

Ok, I've imported the 7D clip, rendered as dnxhd to your render profile, I've looked at the frames in the Project Monitor and extracted frames, I've rerendered the kdenlive derived dnxhd and once again viewed in the Project Monitor & extracted frames and I see absolutely no vertical lines that appear in your images. However the image you provide is letterboxed, whether that additonal step has done anything or not who knows.

The swans clip I did as per your 7D clip, rendered to dnxhd, rerendered to dnxhd, extracted etc etc. No signs of vertical lines to be seen. However I notice from your extracted frame which shows the vertical lines, no signs of interlacing which I see in my extracted frames using a 1080i project, I also see interlacing in the interlaced dnxhd I rendered out to reimport to see the cumilative vertical lines, but see no vertical lines at all. So it appears your extracted frame is from a deinterlaced source or source assumed progressive incorrectly. Mediainfo clearly states the original clip and my rerenders are all interlaced.

The final I see no lines in kdenlive or in any frames extracted from it?

Although your perfectly right to be picky, I'd certainly be annoyed at the vertical lines, I think the problem lies with perhaps a mismatch of ffmpeg libraries or MLT versions or something specific to your machine. Possibly it relates to your playback settings in kdenlive? Don't know. But I'd suggest it's not a specific problem with DNxHD decoding or encoding in ffmpeg or the way kdenlive handles it.

I tested using sunabs unstable git build and 8.2.x, my system ffmpeg version is:

ffmpeg version 0.7.3-4:0.7.3-0ubuntu0.11.10.1, Copyright (c) 2000-2011 the Libav developers
built on Jan 4 2012 16:08:51 with gcc 4.6.1
configuration: --extra-version='4:0.7.3-0ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static
WARNING: library configuration mismatch
avutil configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
avcodec configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
avformat configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
avdevice configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
avfilter configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
swscale configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
postproc configuration: --extra-version='4:0.7.3ubuntu0.11.10.1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-libopenjpeg --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --enable-shared --disable-static
libavutil 51. 7. 0 / 51. 7. 0
libavcodec 53. 6. 0 / 53. 6. 0
libavformat 53. 3. 0 / 53. 3. 0
libavdevice 53. 0. 0 / 53. 0. 0
libavfilter 2. 4. 0 / 2. 4. 0
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 52. 0. 0 / 52. 0. 0

MLT version 0.7.9

Hope something in this mess helps. :-)

I just spent the last couple of days installing & setting up Ubuntu 11.10 (support stopped on the 10th April).

The lines have finally gone, still don't understand what the cause was; my Kdenlive, MTL and ffmpeg versions are all identical. Everything seems to be fine except for one minor bug, kdenlive thinks (erroneously) that ffmpeg can't encode pcm_s16le (this is a known bug).