[FFmpeg-user] fieldmatch "marked as interlaced" -- doesn't work

[Mark Filipak (ffmpeg)]

On 2021-03-15 06:43, Paul B Mahol wrote:
> On Sun, Mar 14, 2021 at 11:18 PM Mark Filipak (ffmpeg) wrote:
>> On 2021-03-14 10:47, Mark Filipak (ffmpeg) wrote:
>>> I hoped that "marked as interlaced" [1] meant that
>>>
>> 'select=expr=not(eq(interlace_type\,TOPFIRST)+eq(interlace_type\,BOTTOMFIRST))'
>> [2]
>>
>> Have I made myself understood? Do you see the problem?
>>
>> ...progressive.&.scan-int.here... 'select' ...only.progressive.here...
>>
>> But scan-interlace frames are getting through the 'select'.
>>
>> Either,
>> 1, 'select' is broken, or
>> 2, 'fieldmatch' is broken, or
>> 3, 'fieldmatch' is setting a different flag (not 'interlace_type').
>
> 4, Missing more than half of information to give actual correct conclusion.


I don't know what you mean, Paul, but unless there's features I don't know about, 
'fieldmatch,yadif,decimate' is, by design, kind to telecined segments of video but unkind to 
scan-interlaced segments.

Here are the facts as I know the facts.

'fieldmatch' pulls up 5-frame telecined segments while leaving frame 4 as a duplicate of frame 3.

Since 'decimate=cycle=5' discards frame 4 in formerly telecined segments, 'FRAME_RATE' is reduced 
(to 23.976fps).

Reducing 'FRAME_RATE' in formerly telecined segments also reduces 'FRAME_RATE' in scan-interlaced 
segments unless either,
1, internal streams support VFR, or
2, scan-interlaced frames are 'split' out to a secondary stream prior to 'decimate'.

Apparently, internal streams don't support VFR [1], therefore, 'FRAME_RATE' in scan-interlaced 
segments is reduced unless scan-interlaced frames are 'split' out.

Scan-interlaced frames can't be 'split' out [2], therefore, the 'FRAME_RATE' in scan-interlaced 
segments are reduced.

Since 'FRAME_RATE' reduction in scan-interlaced segments can't be avoided, 1 out of 5 
scan-interlaced frames are dropped [3] and video in those segments are be degraded.

[1] If serial ffmpeg streams supported VFR, then detelecined segments v. scan-interlaced segments 
could be differentiated via 'FRAME_RATE'

[2] Though 'fieldmatch' flags scan-interlaced frames as 'interlaced', the flag is not 'select'able: 
'select=expr=eq(interlace_type\,TOPFIRST)+eq(interlace_type\,BOTTOMFIRST)' always fails.

[3] Though follow-on deinterlacers (e.g. 'yadif') can be inserted between 'fieldmatch' & 'decimate', 
doing so does not prevent 1-in-5 frame drops.

I understand what was intended, but what is happening is not what was intended -- the 
scan-interlaced sections lose 1 frame in every 5 frames and thereby suffer some judder. The easiest 
fix would probably be to make the 'interlaced' flag in note [2] visible to the 'select' filter.

Your comments are welcome.

Regards,
Mark.


>> How do I proceed?
>>
>>> would work. However, the 'select' doesn't work. I'm counting on the
>> 'select' working -- not working
>>> is a complete show stopper.
>>>
>>> Is there some other species of "marked as interlaced" that will make the
>> 'select' work?
>>>
>>> Thanks,
>>> Mark.
>>>
>>> [1] From https://ffmpeg.org/ffmpeg-filters.html#fieldmatch
>>> "The separation of the field matching and the decimation is notably
>>> motivated by the possibility of inserting a de-interlacing filter
>>> fallback between the two. If the source has mixed telecined and real
>>> interlaced content, fieldmatch will not be able to match fields for
>>> the interlaced parts. But these remaining combed frames will be
>>> *marked as interlaced*, and thus can be de-interlaced by a later
>>> filter such as yadif before decimation."
>>>
>>> [2] From https://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect
>>> "interlace_type (video only)
>>> "    The frame interlace type. It can assume one of the following values:
>>> "    PROGRESSIVE
>>> "        The frame is progressive (not interlaced).
>>> "    TOPFIRST
>>> "        The frame is top-field-first.
>>> "    BOTTOMFIRST
>>> "        The frame is bottom-field-first."
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
> 


-- 
In 5 years, robots will have made bitcoin worthless. Why? Bitcoin miners
don't produce anything. They only consume, and consumption has no value.
Now visualize millions of solar powered, self-replicating bitcoin miners.