[FFmpeg-user] Yes or No? About the processing pipeline.
Mark Filipak
markfilipak.imdb at gmail.com
Thu Jun 19 20:39:38 EEST 2025
Hi Andrew,
On 19/06/2025 12.13, Andrew Randrianasulu wrote:
> чт, 19 июн. 2025 г., 18:06 Mark Filipak <
> markfilipak.imdb-at-gmail.com at ffmpeg.org>:
>> On 19/06/2025 10.42, BloodMan wrote:
>>>
>>> If someone pays a lot for the system, wants to have a sugary interface of the system and programs,
>>> at the same time assumes that the creator forced it, standardized, designed, polished, smoothed and
>>> pampered (supposedly) and prohibits otherwise and tramples the rights of the owners of the purchased
>>> equipment and system - they go to Apple.
>>>
>>> If someone pays for the system, allows chaos of various interfaces because at the same time the
>>> creator constantly introduces new standards, designs but does not prohibit otherwise, so there is
>>> more freedom - they go to Microsoft.
>>>
>>> If someone likes chaos or assumes that chaos can occur when no one takes money for it, at the same
>>> time has full painful power over the system and programs (sometimes even too painful) but is certain
>>> that the system will run just as efficiently on a supercomputer as on the controller of an old
>>> machine tool - they go to FOSS / Linux.
>>>
>>> I, I suspect like most (I hope), chose Linux not because it is so modest - but because I have and
>>> can have control over almost everything.
>>
>> I understand everything you've written, BloodMan, and I agree with all of it.
>>
>> For example: If Windows ran only if I allowed it to access the Internet, I'd switch to Linux in a
>> heartbeat. That's because Microsoft has earned a reputation for betraying its customers. I use Linux
>> to access the Internet because it has earned a reputation for protecting its users.
>>
>> But I do my work in Windows because my Windows applications are very good. I don't do work in Linux
>> because Linux applications are generally not good. They're not good because there are no consistent
>> standards. That's a failing of Linux because Linux is just a runtime executive, not an operating system.
>
> You mean GUI stuff on top of everything else, right? Something users in
> Windows interact most?
Well, yes, GUI stuff, and no, FFmpeg. As so often happens, my question, which has still not been
answered, has devolved into a controversy about Windows and Linux GUIs. You give a great summary of
the GUI evolution in the X-window system. That applies to UNIX and hence, to Linux. My understanding
is that GUIs are for highly interactive machines -- applications are machines, are they not? -- and
that development of highly interactive machines was brought together by Xerox, at the Palo Alto
Research Center (Xerox PARC). Palo Alto is in Silicon Valley, and I was there at that time, and I
was aware of the development -- I worked for Atari. That was in the early 1980s. Now, you say that X
and GUI toolkits began at MIT in the 1990s. I think it was before that, but whatever. I didn't want
to get into those discussions. I just wanted an answer to a simple question about the structure of
pictures (or fields) in the FFmpeg processing pipeline. I was going to follow that up with a
question regarding why the FFmpeg developers did not define a standard pipeline format so that all
the various filters and processes worked on common structures -- if I were writing such code, that's
the very first thing I would do. As it is, I can't tell exactly what the decoder outputs are and
which filters and processes work on pictures (or fields) and which simply set up encoders to do the
processing -- libx264, for example, accepts arguments that are clearly editorial in nature. I can
guess, and I'm probably right most of the time, but it doesn't hurt to ask, or so I thought. They're
questions developers don't ask because developers know the code.
> I guess compilcated story about X server and GUI toolkits in 1990s plays
> some role in it. X server was MIT and not GLP, partially because it started
> at MIT ? Different proprietary Unix vendors adopted it as standart + Motif
> GUI on top of that. X and co were written in plain C (C89 at that point?).
> It turned out C was not best choice for language to write gui with. C++ and
> obj-c surfaced, but obj-c got little traction in X world (but was big in
> NeXTSTEP/macos X) and libre equivalent of Motif (lesstiff) only surfaced
> lately, when visually cool programs started to use either gtk+ (mostly C,
> originated as widget set for GIMP) or Qt (trolltech ... not sure if they
> were trolling or not with this name!). Qt was strangely licensed at version
> 1.0, they fixed that in 2.x and above, but split already happened, so some
> software continue to use gtk+, some cling to Qt, some tried its own thing
> ... Standarts exist, otherwise even simple copy/paste will not work, but
> default visual styles usually different, and philosophy behind UI in gtk
> and Qt lines also differ.
>
> On your question about money ....
>
> Capitalism is no fun at all, especially when it started to erode very
> foundation for life here on this planet (it turned out you need to start
> doing something about emissions *before* they reached critical levels, not
> after!) but not likely to get away voluntary.
Did Capitalism do that or was it ignorance? Would Socialism -- real Socialism, not phony Socialism
-- have done better? How?
If there was a Socialism that could preserve free choice, I would consider it. But free choice seems
to be one of the first things that socialists take away.
> But I guess your question was mostly about *individual* developers or very
> small teams, who do a lot of "small program market" work on Windows? Yeah,
> I guess it harder to sell text editor for $10 if one already exist for free
> ;) But even in Windows/Mac/Android world most software is meh? And most
> individual developers either bought up and forced to play by company's
> rules, or disappear, often than not with their sources, binaries and
> development history.
Have you worked in industry?
> I agree that Windows/Mac for long time were much more stable/consistent to
> use compared to LInux world where "you always can recompile it" idea was
> pushed a bit too far (IMO).
>
> Speaking about ffmpeg as project, it is not just cli but also software
> library, and widely used as such...
No, I didn't mean libraries. Users don't 'see' libraries.
>... But all this API drop/change in 25 years
> also render some old software unworkable with new versions of libav*
> libraries. Linux distros tend to keep only one version of given library,
> this makes them smaller at cost of keeping compatibility with older FOSS
> programs.
I question the sanity of codesmiths who work for a full day to save 100 bytes.
> Where are developers, one can ask? Well, vacuumed by big companies of
> course! And users pay for instant gratification to big software companies
> not for multiyear road where you write standart first, then write software
> to it. Everyone "want" features fast, no matter how hacky internal
> interface is...
I believe that's a myth. I think the existence of Linux supports my belief.
>... Windows still have much bigger installed base, so many
> developers still cling to it, because dominant platform! And this situation
> partially due to Microsofts not so honest business in 90x, and partially
> due to NDA on how hardware works, so for many years GUI
> performance/stability/featureset was not great, or wifi was not working,
> or specialised pci/e hardware only had drivers for Windows/Mac ...
> Situation better now, but due to constant hw push only some features works
> on some cards with libre drivers and managing giant (they grow in last 20
> years!) collections of routines like qt5/6 or llvm, or rust is become issue
> in itself ...
>
> I wish I was able to say "Slow down!" to all sectors of this damaging
> speed race, but money talks louder than reason ......
Yes, slow down. Stop churning OS GUIs and libraries and foundations so that users must buy new
versions of OSes that are no better (and sometimes worse) than what they already have. That's phony
Capitalism. That's milking the cow.
More information about the ffmpeg-user
mailing list