DV-PAL (german) & interlaced field order

just completed two large 1080p projects, everything went fine.
But now, I have, for historical reasons, to process some old SD DV-PAL footage and end up in multiple trouble.
My setup is kdenlive 23.08.04 in Manjaro Linux (XFCE) on i7-9700 / 16GiB, 2xNvme, 1xSSD, 2xHDD.
The Problems:

  • If I start a new project, kdenlive offers for project-settings (profile) DV/DVD PAL, that’s right, BUT in ‘video settings’ shows up ‘Top field first’ - that’s wrong, at least for me.
    So I defined my own profile, showing ‘bottom field first’ - thats my footage according to mediainfo and what the standards tell here.
  • I am able to work as usual, edit etc. but I want to keep the output/export the same as the raw footage. So I defined a new (missing) export-profile for DV-PAL. If I use the defaults in kdenlive for this, I get avi-files ‘top fields first’ again, according to mediainfo…
  • Then I forced the export-profile in my wanted direction: ‘top_field_first=0’ and ‘progressive=0’.
    Mediainfo shows ‘Scan type: Progressive, Original…: Interlaced/Bottom Field First’
  • Then I tried to output a mp4/ac3 and get Interleaved, Top field first.

What the hell is going wrong here?
Can somebody point me to a right direction?
If you need more info, I will do my best.
Thank you in advance!

P.S. -
Did a further test:

  • ignoring all the frame-stuff & exporting a DV-avi without any switches gives a regular output having ‘bottom_field_first’ and playing well. Tested in VLC stepping frame by frame.
    Looks the same like the raw stuff.
    Is there some error in the headers introduced (in kdenlive) only?
    Will try & use that way if it really works…

Edit-2: One should read everything in mediainfo-ouput:
Scan type: Progressive
Original scan type: Interlaced
Original scan order: Bottom Field First
i.e. no useable result, resulting filesize some bigger than raw stuff.

  • if I try to output any mp4 (h264), I get everytime ‘top_field_first’, no matter what switches are on or not.
    Stepping forward (and back) in VLC shows that indeed - something like chameleon-move…

Very confused…

Indeed, very confusing. I check with the Kdenlive team for the correct workflow, working with PAL/NTSC/DV material.

Thank you very much!
I will stay tuned & patient…

BTW: I tried the same thing in shotcut (Linux, latest appimage). Is AFAIK MLT/ffmpeg based too - works ok, produces a clean dv-out.

Hello again, and one more P.S.:
Today I cleaned up some workspace and found some elder avi/dv-testfiles from 2022 (!), having the same problems.
This time I thought, my experience would be insufficient, and I abandoned these tests…
But today I think, is is a long standing bug.
What I found so long is: everywhere is given a default ‘top field first’, sometimes you may override it, but ist gets ignored, sometimes you get no chance to change anything.

Just landed on this thread due to being stopped in my tracks by kdenlive’s apparently broken handling of DV (PAL also in this case). It’s a little surprising, although somehow also not surprising. I suspect development has just rocketed a bit too far into the future and unintentially broken the legacy stuff!

Nevertheless, I’d like to be able to do a very traditional DV edit in kdenlive. That is, maintaining interlaced throughout, including render back to DV tape like it’s 1999.

Now, I’ve come back to edit my post because I actually seem to have managed to resolve all the issues. The only question I have now is wanting explicit confirmation that the deinterlace dropdown option does nothing if the render preset is set to Interlaced.

First I created a new Render profile for AVI and dvvideo codec. Fair enough. I set all the parameters correctly for interlaced, bottom field first, etc, and in this instance 16:9 display aspect ratio (I was editing widescreen content).

I immediately ran into two problems when I went to render.

The first is that there doesn’t seem to be any way to specifically select no deinterlacing. There’s only a drop down to change between various deinterlacers, not set it to None, for example. My tests have shown that… probably… this isn’t having any effect with my render profile set to interlaced, but I’m really not sure. Could someone confirm this setting is ignored?

The second is that by default the pixel format is incorrect for PAL DV. Kdenlive is picking yuv411 which is correct for NTSC DV, but not PAL DV, which is yuv420. I was eventually able to work out how to solve this. I had to add in the additional parameters “properties=dv_pal_wide/DV” (see the right-most dialog in the image at the end of this post).

While this works, it isn’t very user friendly. Why are all the presets that can be found under C:\Program Files\kdenlive\share\mlt\presets\consumer\avformat\ (on Windows) not exposed to the GUI? I have a feeling that they used to be in the past?

The issue persisted with incorrect metadata on the exported file, with the scan type showing as Progressive.

Scan type                      : Progressive
Original scan type             : Interlaced
Original scan order            : Bottom Field First

I was able to solve this by editing the aformentioned DV render preset, AND also editing the project profile, because by default the kdenlive PAL preset incorrectly has Top Field First. See the image at the end of the post.

I edited C:\Program Files\kdenlive\share\mlt\presets\consumer\avformat\dv_pal_wide\DV to be the following:


meta.preset.note=The popular standard definition camcorder digital video format
meta.preset.name=camcorder/DV (SD Widescreen PAL)

Now, this is how the metadata looks like in my rendered AVI:

Scan type                      : Interlaced
Scan order                     : Bottom Field First


Originally, the preset as supplied with kdenlive, had bf=0, which is incorrect. I also added field_order=bb for good measure.

So to conclude, it seems some cleaning up is needed within the kdenlive profiles and presets to fix the broken default field order settings for PAL. A None deinterlace option would be nice for piece of mind also.


1 Like