[FFmpeg-user] Video Glossary (was: bwdif filter question)

[Mark Filipak (ffmpeg)]

On 09/16/2020 09:58 AM, Mark Himsley wrote:
> 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.
> The bwdif filter will interpret a single raster and is designed to
> output two rasters, each containing one or the other of the fields
> that were contained in the input raster.

Thank you Mark. I note how you've employed the word "raster". I think that's a useful step.

I've spent a month documenting the various macroblock formats (aka syntax) and creating various 
diagrams showing what I've learned along the way. The physical structure of frame data may be coming 
into focus, at least in my head and in my diagrams.

It appears that the pictures people hold in their heads changes depending on context:
1, Encoded frames (slices, macroblocks, etc.) as found on-disc or in a stream,
2, Picture frames output by an input decoder, and
3, Picture structures v. half-picture structures (i.e. frames v. fields, what you are calling 
"rasters") within filter chains.

Each is unique. Each has unique structure and usage. However, undifferentiated names (e.g. "frames", 
"fields", "interlace", "deinterlace") are being applied. People are relying on context to fill in 
the gaps. But when context goes unsaid, confusion reigns leaving us trapped in a video Tower of Babel.

The confusion is not limited to this mailing list. The folks who wrote and revise the H.222 and 
H.242 specifications clearly also relied on context. The result is that H.222 & H.242 seem ambiguous 
and confusing.

Appropriate contextual names based on physical data structures should be created to end the 
confusion. That is what I'm attempting. I invite interested people to join me in a glossary project.

Regards,
Mark.