[FFmpeg-user] bwdif filter question

Mark Filipak (ffmpeg) markfilipak at bog.us
Wed Sep 23 19:55:46 EEST 2020


On 09/23/2020 12:19 PM, Greg Oliver wrote:
> On Tue, Sep 22, 2020 at 1:14 PM Mark Filipak (ffmpeg) <markfilipak at bog.us>
> wrote:
-snip-
> 
> He has repeatedly posted to either understand or define better
> the internals of ffmpeg itself...

Thanks for the kind words.

Yaknow, I'm not special or a wizard. I suffer the same assumptions as everyone. As I work on my 
glossary, I'm amazed when I realize something that I had wrong, but had worked on steadily for weeks 
without actually seeing.

Let me give you an example. Last night I realized no matter whether a stream is frame or TFF 
(top_field_first) or BFF (bottom_field_first), that macroblock samples have exactly the same order; 
that it's the order that these samples are read out by the decoder that determines whether the 1st 
sample goes to line 1 or line 2, and whether the 4 luminance blocks are concurrent (aka "progressive").

In other words, TFF and BFF are not formats. They are access methods!!

That realization caused me to dump a raft of seemingly clever, seemingly insightful diagrams that 
had taken weeks of revisions to hone. I realized that those diagrams were crap and just reinforced 
concepts that seem reasonable and are universally accepted but that can't survive close scrutiny.

That kind of insight (which makes me think I'm stupid for not seeing it immediately) will be in the 
glossary. The existing stuff not only implies that fields exist -- fields do not exist (no such 
structure, at least not in streams) and it took me a month of learning how to parse macroblocks to 
discover that -- the existing stuff implies that TFF and BFF are differing formats, but they're not 
formats at all!

I contend that ordinary users can understand the differences between (hard) structure and (soft) 
description, and between a format and a method. I think ordinary users are so hungry to get real 
information that they're willing beg and plead and (nearly) debase themselves.


More information about the ffmpeg-user mailing list