Bug 510531 - avfilter.fieldorder auto-loaded in Kdenlive/MLT with interlaced files, causes errors and rendering issues
Summary: avfilter.fieldorder auto-loaded in Kdenlive/MLT with interlaced files, causes...
Status: RESOLVED NOT A BUG
Alias: None
Product: kdenlive
Classification: Applications
Component: Rendering & Export (other bugs)
Version First Reported In: 25.08.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-12 16:23 UTC by Martin Schnitkemper
Modified: 2025-11-09 12:23 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schnitkemper 2025-10-12 16:23:57 UTC
SUMMARY
When opening or working with interlaced video files in Kdenlive, the avfilter.fieldorder filter is automatically added to the timeline, even if it was never manually applied in the project.

STEPS TO REPRODUCE
Always – with:
    • Interlaced video sources
    • New or existing Kdenlive projects
    • MLT 7.32.0 + FFmpeg 8.0

OBSERVED RESULT
    1. Error message in the Effect Stack / Console:
       [filter avfilter.fieldorder] Unexpected return format
    2. The Project Monitor stays blank (white) until the project is switched to a progressive profile
    3. Rendering (e.g. with hevc_vaapi) fails with hardware filter errors, like:
       A hardware device reference is required to upload frames to.
       Failed to setup hwfilter: -22
This behavior also affects older project files, which previously worked fine (e.g. in Kdenlive 23.x or older MLT versions).

EXPECTED RESULT
    • The avfilter.fieldorder filter should not be applied automatically unless the user adds it manually
    • Alternatively, there should be a way to disable or blacklist this filter (per project or globally)
    • There is no documentation about this automatic behavior or any filter blacklisting functionality

SOFTWARE/OS VERSIONS
    • Kdenlive: 25.08.2
    • MLT: 7.32.0
    • FFmpeg: 8.0
    • GPU: Mesa Intel® UHD Graphics 630
    • VAAPI: enabled

    • Operating System: Arch Linux 
    • KDE Plasma Version: 6.4.5
    • KDE Frameworks Version: 6.18.0
    • Qt Version: 6.10.0
    • Kernel Version: 6.17.1-arch1-1 (64-bit)
    • Graphics Platform: X11

ADDITIONAL INFORMATION
What was tested:
    • Switching project profile to "progressive" → temporarily hides the issue, but is not a solution
    • Tried to blacklist the filter using:
        ◦ /etc/mlt-7/avformat/blacklist.txt
        ◦ ~/.local/share/mlt-7/avformat/blacklist.txt
    • These files are not evaluated at all
    • Manually adding fieldorder to /usr/lib/mlt/avfilter//blacklist.txt does work

Suggestions:
    1. Prevent automatic insertion of avfilter.fieldorder, unless explicitly added
    2. Provide a user-controllable blacklist mechanism for AVFilters (e.g. config file)
    3. Improve fallback behavior: don't show a blank Project Monitor if filter fails
Comment 1 Martin Schnitkemper 2025-10-20 11:15:23 UTC
The crash issue when rendering with the hevc_vaapi codec has been identified and resolved by the MLT developers: https://github.com/mltframework/mlt/commit/13d1c0ee242471db6ca3cb55aee48f4d32058573

The problem of the "[filter avfilter.fieldorder] Unexpected return format error" remains, however. After reviewing older project files, I saw that this filter was also used implicitly before when the project settings were set to an "interlaced" profile. This also explains why the display errors (white content) only occur in the Project Monitor. So, it's not new that this filter is being loaded, but what is new is that it no longer works and displays the error message mentioned when used. Therefore, I'm withdrawing my suggestion from the initial bug report to make the filter configurable, as it's clearly necessary for correct processing. Instead, the reason the filter can no longer be loaded needs to be addressed.

I'm currently working around this by explicitly setting the input material to "progressive" and adjusting the project profile, as processing interlaced material is currently not possible.
Comment 2 Martin Schnitkemper 2025-11-09 12:23:11 UTC
Since the last system update, the described errors no longer occur.

The cause was likely mlt, which was delivered in an updated version 7.34.1. To test this, I temporarily downgraded to version 7.32.0, and the problems reappeared. There may have been an incompatibility between mlt-7.32.1 and ffmpeg-8.