[FFmpeg-user] bwdif filter question

[Mark Filipak (ffmpeg)]

On 09/20/2020 05:44 PM, Carl Eugen Hoyos wrote:
> Am So., 20. Sept. 2020 um 06:59 Uhr schrieb Mark Filipak (ffmpeg) <markfilipak at bog.us>:
>> On 09/18/2020 03:01 PM, Carl Eugen Hoyos wrote:
>>>> Am 16.09.2020 um 15:58 schrieb Mark Himsley <mark.himsley at gmail.com>:
>>>>> On Mon, 14 Sep 2020 at 15:42, Mark Filipak (ffmpeg) <markfilipak at bog.us> wrote:
>>>>> Is the input to the bwdif filter fields or frames?
>>>> The input to every filter in a filter chain is a raster of pixels.
>>>> That raster may contain one frame or two fields.
>>> That may not be wrong (apart from Paul’s comment) but I wonder how useful it is:
>>> No matter if the raster contains one field, two interlaced fields or a progressive
>>> frame, the filter will always see an input frame.
>> "...if the raster contains *one field*...the filter will always see an input *frame*."
>> How is that possible? How can a frame contain just one field?
> 
> The following makes little sense, it is just meant as an example:
> $ ffmpeg -f lavfi -i testsrc2,field -vf bwdif -f null -
> 
> Here, the input to the bwdif consists of frames that contain one field
> (of the original input).

Thanks, Carl Eugen. Kindly forgive my ignorance -- I can't read 'C' code and probably couldn't find 
the relevant code section if my life depended on it.

If bwdif is the *only* filter, then, from previous discussions, I understand that its input (i.e. 
the decoder's output) is raw frames (e.g. 720x576)? If raw frames, then I can understand the above 
to mean that the filter is 'fed' only one field (e.g. 720x288). Logically, to me, that would be a 
frame (i.e. a 720x288 frame), but no matter (let's forget that). However, even then, the filter is 
receiving only one field. How can it 'deinterlace' a single field? I'm mystified. Does it line 
double in such a circumstance? Or does it deinterlace the current single field with the next single 
field one frame later?

>>> The fact that there is metadata that may signal the content is also not necessarily
>>> helpful as this metadata is typically wrong (often signalling fields when a frame is provided).
>>
>> Can you provide an example (or a link to an example)? I've examined a
>> great number of DSM mpeg presentation streams ('VOB's & 'm2ts's) and
>> I've not seen a single case. What metadata are you looking at?
>> sequence_extension: 'progressive_sequence'?
>> picture_coding_extension: 'picture_structure'?
>> picture_coding_extension: 'top_field_first'?
>> picture_coding_extension: 'repeat_first_field'?
> 
> I would expect that most commercial encodings you have uses
> one of the above, independently of the content...

Based on my experience, and to the best of my knowledge, every MPEG PS & TS have all 5 metadata 
values. Certainly, every MPEG stream *I've* parsed have all 5.

>> picture_coding_extension: 'progressive_frame'?
> 
> ... while this is unusual, even for movies in PAL streams.

For what it's worth, I have only one PAL movie, "The Man Who Would Be King", from Australia. It has 
all 5 metadata values and appears to be a regular MPEG PS.

Regarding 'progressive_frame', ffmpeg has 'interlaced_frame' in lieu of 'progressive_frame'. I think 
that 'interlaced_frame' = !'progressive_frame' but I'm not sure. Confirming it as a fact is a side 
project that I work on only occasionally. H.242 defines "interlace" as solely the condition of PAL & 
NTSC scan-fields (i.e. field period == (1/2)(1/FPS)), but I don't want to pursue that further 
because I don't want to be perceived as a troll. :-)

- Mark.