[FFmpeg-user] Yes or No? About the processing pipeline.
Mark Filipak
markfilipak.imdb at gmail.com
Thu Jun 19 21:33:02 EEST 2025
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?
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).
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.
All my friends were codesmiths, usually 'C' codesmiths. They would spend maybe 5% or 10% of their
time planning and the rest coding. 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.
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'."
More information about the ffmpeg-user
mailing list