SUMMARY Exporting an interlaced source clip (1080i25) to AV1 produces a corrupted video file, unless the AV1 render preset is modified to set the scanning as interlaced and top field first (i.e. matching the source clip). This works fine with h264 in any combination. The codec being used is svt-av1, by editing the preset to change the ffmpeg codec. STEPS TO REPRODUCE 1. Create a new project, either 1080i25 or 1080p50. 2. Load a 1080i25 video clip, like this one (5 seconds, 16MB, direct from camera): https://1drv.ms/v/c/4b232a568ba3cb04/ERc5p230VcVFm65zV0NN8KYBd9rU5Ek0acIDlILk8r9Liw?e=gEKH0U 3. Render using an AV1 preset with the scanning not set, or set to progressive. whether the project is set to 1080i25 or 1080p50, unless the AV1 render preset is modified to set the scanning as interlaced and top field first (i.e. matching the source clip). It then doesn't matter whether the project is set to 1080i25 or 1080p50, both render correctly (except that I wanted progressive video!). 2. 3. OBSERVED RESULT Video is heavily corrupted, e.g. this still: https://1drv.ms/i/c/4b232a568ba3cb04/EYSIc7dvPthKoRnmJVa4xcgB5xGg-Ol2OG4Kabp6eRXvTA?e=vmo8pc EXPECTED RESULT Video render looks like the timeline playback. SOFTWARE/OS VERSIONS Linux, reproduces natively in Gentoo or by running the 25.04.03 Flatpack. Linux/KDE Plasma: KDE Plasma Version: kde-plasma/libplasma-6.3.5 KDE Frameworks Version: kde-frameworks/frameworkintegration-6.13.0/ Qt Version: dev-qt/qtbase-6.9.1-r2 media-video/ffmpeg-7.1.1-r2 media-libs/mlt-7.32.0 media-libs/libaom-3.10.0 media-libs/svt-av1-3.0.2 ADDITIONAL INFORMATION Test files to reproduce this, and examples of rendered files, can be found here: https://1drv.ms/f/c/4b232a568ba3cb04/EmkyObMXIgNBpTn4C6VMjRUBEb-4-fmqegVXRicmWgPRMw?e=HOVxUw
Update that this doesn't reproduce with mlt built from their git repo (396621e), where the render works OK. It would be nice to double up the frame rate in the deinterlace, but that is a different mlt feature request. From this I conclude two things: 1. This is an mlt bug, rather than a kdenlive one. I didn't understand how the render infrastructure worked when I filed this (I know realise all the render options just get pushed into a custom consumer in the .xml file sent to mlt). 2. It is fixed upstream in mlt (although not released yet). I think this bug should probably be closed now?
Thanks Richard! What happened in the forum? I went to look for where you'd pasted the link to (this?) bug today, to look into it, and saw someone had 'flagged' that post - then by the time the moderators reported fixing that, all your posts were gone? I don't know what happened while I wasn't looking, but thanks again for your interest and encouragement to get AV1 better supported.