[FFmpeg-user] Yes or No? About the processing pipeline.

[Rob Hallam]

On Thu, 19 Jun 2025 at 19:33, Mark Filipak
<markfilipak.imdb-at-gmail.com at ffmpeg.org> wrote:
>
> On 19/06/2025 13.42, Rob Hallam wrote:
> > On Thu, 19 Jun 2025 at 17:04, Mark Filipak
> > <markfilipak.imdb-at-gmail.com at ffmpeg.org> wrote:
> >> I apologize, Rob. I was going by the bodies, not the headers. The intervening time was actually a
> >> little less than 2 hours. I apologize for the error.
> >
> > I appreciate you taking the time to correct the mistake, thanks.
>
> You're very welcome.
>
> >> 2 hours... Hmmm... Your comment is still shameful.
> >
> > Yeah nah. We all had time to gab about how FOSS and proprietary
> > software sucks over the course of six replies before someone said
> > 'nice one' ? Pretty poor showing from the ML.
>
> Well, Rob, I can't read 'C' code, so I'm unqualified to know whether Paul's patch is any good. We
> will all see that when it's published and compiled and linked and distributed, eh?

It is published.  You can compile and distribute it to your heart's
content- that's one of the great things about Free software.

The work asked for has been acknowledged now though at least.

> I have a story. I'm corresponding with a fellow who wrote a popular subtitling program. He wrote it
> in 2000, rewrote it in 2013, and is currently rewriting it, again. He seems to have little idea
> regarding what what makes a good user interface, good. He doesn't think user-interface thoughts. He
> thinks coding thoughts. To me, user interface is design, not coding. Like all good design, good UI
> design takes experience and lots of time and lots of thinking (and compassion).

Hard agree.

> Do you write code, Rob? I've written a lot of code in my time, but always as part of my hardware
> projects -- of my 29 projects, I think maybe 2 or 3 included microprocessors and assembly. The rest
> had zero code, though I did have to write drivers and tests.

> (part snipped that I will return to)
> When I design hardware, I spend 75% to 80% of my time planning.
> During my planning, I document every decision I make: why did I do 'this' and why didn't 'that'
> work. When the project is done, I have complete (or nearly complete) documentation already done. I
> think that works better than putting off documentation to the end. I know that, for me, I don't have
> the patience to write documentation at the end of a project, and I forget what I wanted to document
> if I leave it to be done at the end.

Agreed on just about everything here.

> I know that, when the code is done and I'm looking at it, it's too easy to say, "Well, 'this' and
> 'that' are obvious, so I don't need to mention 'this' and 'that'."

Yup. I'd go a step further and say that once you're done writing
something you can end up *too* familiar with parts of it and not even
consciously think "I don't need to mention this"- eyes skip over it.

> All my friends were codesmiths, usually 'C' codesmiths. They would spend maybe 5% or 10% of their
> time planning and the rest coding.

There's a huge number of people writing code. Millions. They're a
spectrum from meticulous planners with assiduous attention to
documentation to 'vibe coders' who let ChatGPT generate code and go
"hmm, looks about right". It sounds like you had experience with
people who were "code first, think later"; I'd like to think most
prefer the reverse, I know I do.

Cheers,
Rob