On 10/01/2020 12:16 PM, Greg Oliver wrote:
On Wed, Sep 30, 2020 at 6:25 PM Mark Filipak (ffmpeg) <markfili...@bog.us>
wrote:
-snip-
Mark,
Normally I would absolutely defend your queries as they are technical and
lower level, but I would almost have to side with Bouke from post
(
bwdif filter question
)
You are trying to get free editing for your book now.
I have no book. I intend to have no book. I'm a retired engineer and don't need book proceeds. I
intend to give everything to the ffmpeg project (and anyone else who finds it useful) for free and
unconditionally. It is all public domain. By simply posting it, I'm making it all public domain.
I do not agree with
that.. There are many good contributors and inquisitors (you included),
but (IMHO) you cannot solicit things like this that are grammatical rather
than technical. I think a lot of the developers are also in the same boat
as you (sometimes) try to re-define things that are common language (even
if not accurate technically).
I'm working on a glossary, not a dictionary. I have no desire to re-define
common language.
eg - your definition if interlaced versus interweaved.. No matter if you
are right or wrong, the concept and understanding of a majority will
prevail - no exceptions.
We shall see, eh? If there's power in (better?) terms, then they will prevail. If not, then they
will die. For what it's worth, I've never written the word "interweaved".
Certainly, to cite just one realm, the current nomenclature is quite confused regarding pre-decoding
streams v. post-decoding processing. The H.xxx folks leave interpretation to "context". But relying
on context relies on understanding, and it is understanding that is lacking. Which would you shoot
first? The chicken or the egg? -- Buy this concept or I shoot the dog.
Please (for me at least) keep your posts here related to ffmpeg and not
trying to change the nomenclature of what exists. We are all using the
same software, so whatever the software uses for terminology (as this list
is exactly related to), please do not interfere with that.
My experience is that the entire video field, not just ffmpeg, is grossly underspecified. That hurts
users and developers -- a lot of time is wasted and a lot of feelings are hurt. Based on my 47 years
of engineering experience, the first things that need to be fixed is to unequivocally and
unambiguously define all the terms & structures. To me, that's the low hanging fruit. Then comes the
processes, but once the terms & structures are nailed down, I think we'll all discover that
documenting the processes will be a snap.
Take that up directly with developers and let them sort it out.
I would/could never stop them from contributing. But it should be acknowledged that the developers
have a developer's perspective. The developer view is like looking out at the world through a pinhole.
On a side note - I have yet seen one of your definitions of a technology
been held up when a developer chimes in - no hard feelings, just that
industry terminology is hard to trump :)
Oh, believe me, you've seen nothing yet. I ponder terminology and anguish over every word choice for
a long, long time. I doggedly seek to manufacture terms that are intuitive and acceptable to all.
The developers have their opinions and have not been shy sharing it. To be honest, I don't see how
this (my glossary) can even be an issue. I'm an ffmpeg user and so long as I'm courteous and focus
on video issues, the developers should welcome me. If not, then I should be removed from the
ffmpeg-user list.
Give this journey the time that it deserves. We all have the same destination in sight, just
differing paths to get there. Perhaps there exists no single path, eh?
--
What if you woke up and found yourself in a police state?
African-Americans wake up in a police state every day.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
