f_auto_filters: don't set interlaced-only for userdeint

[kasper93]

Not wanted apparently: #14822 (comment)

[kasper93]

@hooke007: Does this fixes playback of your file?

[llyyr]

Why do we want to enable deinterlacing for frames not flagged as interlaced?

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-12-intel
• mpv-macos-13-intel
• mpv-macos-14-arm

[hooke007]

Why do we want to enable deinterlacing for frames not flagged as interlaced?

That's what deinterlace=yes designed for. interlaced-only=yes cannot fix for the wrong encoded frames.

[hooke007]

But I agree that now the new value auto was added. interlaced-only=yes should work with auto

[llyyr]

I looked at it more, and it seems that before auto was added, yes worked basically the same way as auto except the check was done in refqueue not in auto filters. https://github.com/mpv-player/mpv/blob/master/video/filter/refqueue.c#L107

Right now both auto and yes are actually the same option, so I agree with removing this to allow forcing deinterlacing for every frame if that's what the user wants.

However, I noticed another issue. With the current implementation of auto, we destroy the subfilter for every frame that's not interlaced then recreate it when we have an interlaced frame again. This is probably not very efficient. I think the auto option should be reworked to just set interlaced-only=yes and with yes we should set interlaced-only=no

bwdif_cuda and bwdif_vulkan have different syntax but they can do this too https://ffmpeg.org/ffmpeg-all.html#bwdif_005fvulkan

I'll whip up a PR for this

[llyyr]

I have something that works but the only problem is that deinterlace-active property can't exist anymore, how much do we care about it?

[Dudemanguy]

It's not that important but why can't it exist anymore? The output chain should be able to access all filters.

[llyyr]

It's not that important but why can't it exist anymore? The output chain should be able to access all filters.

Currently, we just check by seeing if the filter is inserted or not. After #14841, with auto the filter is always inserted and we don't know what it is actually doing with the frames.

[hooke007]

Hmm, if the source file is marked p, auto shouldn't insert the filter.

[llyyr]

auto shouldn't insert the filter.

Whether the filter is inserted or not doesn't matter, if the frames themselves aren't marked as interlaced then the filter won't do anything. Inserting and removing filters is expensive and leads to stutters when it happens, so I think avoiding that should be the priority.

[hooke007]

Inserting and removing filters is expensive

It was caused by mpv's internal design. Of course it's expensive when you check it each frame.
But what I point out it here is that the check should be only once for each video track.

[llyyr]

Patches for a better solution are welcome

check it each frame.

This is necessary because the concept of an "interlaced file" does not exist, interlacing is frame data and only exist as frame data. You can't mark entire file as interlaced, what you're doing is marking each individual frame as interlaced. There exist files that have some interlaced frames but not all

[hooke007]

Have no idea how mediainfo could do.
I will test if performance was affected when filtet was insert even though it doesn't deint.

[llyyr]

Have no idea how mediainfo could do.

mediainfo reports a file is interlaced if at least 1 frame in it is interlaced. Actually it depends on the file format but I'm not interested in reading 20 year old C++ code.