I'm using interlaced video because: in 50 fps picture move became more smooth and there is no motion blur in kdelive which may help to improve 25 fps video.

When I'll try change size of my video from 1920x1080 to 1280x720 - output picture became awful (and it have no interlace after all). I think that it is not very hard to make correct resize technique which will save interlacing on resize (and save 50i fps)

Algorithm (as I think) should make something like this:
1. We are want to resize 1080i to 720i
2. 1080i frame separated in 2 half-height progressive frames 1920x540
3. Each frame resized to 1280x360
4. Merge two 1280x360 frames into one 720i frame

Second needful thing it is deinterlacing and interlacing features. I mean sometimes maybe better deinterlace 1080i into 1080p(50 fps) and than resize it to 420p 50fps, or edit project with multiple videos in 1080p(50 fps) mode. And sometimes after editing video in 1080p 50fps mode you will need to produce finally 1080i output.

Here's one further argument emphasizing the need for a deinterlace video effect:

I used to work with interlaced PAL footage exclusively in the past.
But nowadays with movie recording capabilities in a lot of devices like
digicams, phones, ... I'm frequently combining a lot of varying footage.
Most of the time I'm dealing with interlaced PAL @ 25 fps (camcorder) and
progressive video @ 15 or 30 fps at the same time.
My current workflow involves a bunch of cumbersome transcoding actions, which
require a lot of time, disk space, and degrade quality as soon as I'm utilizing
some sort of common compression to save disk space. (Going with lossless codecs
is limited on compression rate and preformance issues on the decoding side might
show up, too)

Therefore, here's my vote for a deinterlacing effect in kdenlive - preferably yadif.

Toby

There is already automatic deinterlace, but it uses a poor quality linear blend algorithm. It is automatic based on your project setting, Scanning setting in the Render dialog, and if you change the vertical resolution. By "change the vertical resolution" I mean any time a clip's vertical res does not match the project setting or if some effect causes it to resize. I am planning to add yadif in MLT by the end of the year - it is quite high priority on my todo list.

Hi Dan,

deinterlacing is required before footage goes into any effect processing.
Just think of deinterlacing a composite of two interlaced tracks, where the "pixel distance"
in y direction is an odd number. Since we're mixing bottom and top fields, deinterlacing cannot work anymore! Therefore, deinterlacing after final rendering doesn't help.

Or does the rendering option enable a kind of general "source deinterlacing" ?
Then, this option has to go into the project setting dialog.

Toby

Deinterlacing *is* done prior to the other effect processing. The Manage Project Profile dialog under the Settings dialog has a Progressive checkbox. Based on that, the signaling in the source clip, other output overrides, and other effects signaling the need for it (e.g. vertical scaling); deinterlace is activated on the source.

That's good to know. I didn't expect the project profile to determines it and
was probably irritatet by the scanning option of the output dialog. Anyway ...

How does kdenlive decide which source clip to deinterlace ?
I couldn't find any option or reporting in the clip properties dialog.
Is there some sort of autodetection ? Does it rely on header information , which might be
incorrect or missing in some of the input formats ?
Does "progressive" enforce deinterlacing of all source clips, even the progressive ones ?
No ....

Toby

But I'm not exactly talking about deinterlacing technique. I mean correct resizing with saving interlacing image type (because interlacing image is actually 50 fps) or deinterlacing variant from 25i to 50p format.

> How does kdenlive decide which source clip to deinterlace ?

MLT decides it, not Kdenlive. It deinterlaces if the source is not progressive and "downstream" says to deinterlace for the reasons I described above.

> Is there some sort of autodetection ? Does it rely on header information ,

It uses a field from the FFmpeg API, which I believe is set by the decoder as opposed to demuxer.

> which might be incorrect or missing in some of the input formats ?
> I couldn't find any option or reporting in the clip properties dialog.

Yes, it is possible to be incorrect. MLT has a property you can set on the source clip: force_progressive=0 for interlaced or =1 for progressive. However, this is not yet exposed in Kdenlive's Advanced Clip Properties as it ought to be.

> Does "progressive" enforce deinterlacing of all source clips, even the progressive ones ?

no

BTW, yes, I understand the original post is about field-aware scaling.