|
What is the thread reaper? - The Old New Thing[^]
I was looking at this article and it made me wonder if that wasn't the reason that in FreeRTOS a thread had to either destroy itself with a system call, or be destroyed by another thread. If it ran to completion it would crash.
Maybe that RTOS has the same problem, but no thread reaper.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
That makes sense that a thread can't clean up after itself. I hadn't ever thought about it!
I like his writing style.
I don't think before I open my mouth, I like to be as surprised a everyone else.
PartsBin an Electronics Part Organizer - Release Version 1.3.0 JaxCoder.com
Latest Article: SimpleWizardUpdate
|
|
|
|
|
It looks like he posts a new message every day! That must be difficult.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'm thinking it's among his responsibilities at MS. I could be wrong.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Time now for a Friday Morning Smile Moment...
[[This is a marketing photo for a Microphone]]
Those who know and understand microphones will most probably enjoy a few extra seconds zooming in on the inset pic at the lower right
Notice what the humans are actually using
|
|
|
|
|
Coincidence? My shirt today has a picture of a similar microphone! The shirt is from Sweetwater in Ft. Wayne, Indiana. I was there a few months ago and got to tour their facility.  I'm sure most musicians here will know who they are...if you don't, you should look them up.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
|
I used ffmpeg years ago to rip my Hero3 underwater movies into a stream of still photos. I can get just the best shots. Back then I marveled at ffmpeg's command line options. Fast forward a decade or so and I want to go change the ripper script. I am again presented with ffmpeg's massive number of command line options.
ffmpeg -h full lists over ten thousand lines of complex, precise, and densely packed switches. One may specify audio and video codecs, formats, sampling strategies, quantization schemes, transformations, distortion, compression, and on and on. How many career-lifetimes are embodied in this piece of software?
Is there another piece of software that has this many command line options?
-Chug
In one respect ffmpeg reminds me of git: I'm not qualified to judge if the way it behaves is a bug or not.
Over the top we go.
|
|
|
|
|
10 thousand? how do you even comprehend that?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
.Net framework classes ... You start with a likely namespace. e.g. Windows.Devices.Bluetooth. Then you "go deeper; much deeper."
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
death by "--"
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I've seen GUIs built on top of ffmpeg, but I'm sure they all oversimplify what's available.
I can only imagine what a UI supporting every option would look like.
[Edit]
You weren't kidding. I just ran:
ffmpeg -h full > z.txt
Notepad shows the resulting file has 11,689 lines. And I'm sure my version of ffmpeg.exe is way out of date.
That's crazy.
|
|
|
|
|
Maybe an older version of ffmeg? ffmpeg on Ubuntu 22.04 is 4.4.2, and produces 14,159 lines of text
Keep Calm and Carry On
|
|
|
|
|
dandy72 wrote: I can only imagine what a UI supporting every option would look like.
I agree that it is crazy - but not quite as crazy as it first appears. The ffmepeg version installed with the current version of yt-dlp certainly give you 15421 lines if you ask for -h full, but these are certainly not 15421 distinct options. Lots of the lines are alternate parameters to a single option, e.g. each colorspace alternative has its own line. Quite a few of the options take 10-15 lines to list the argument values. Some options are repeated in different contexts, e.g. under each encoder option (the allowed argument values may vary among encoders, though).
So, 17 repetitions of the same option for 17 different encoders, with 15 alternative values, would pack more than 250 lines from the help file into a single pulldown list in the GUI.
Also, the file has >1000 blanklines, and following line is heads a group of options. So there goes another 2000+ lines. A sizable number of options duplicate information, e.g. all the 'show xxx' options: The options would be available in the pulldown selectors; you do not need another way to show them. Lots of options are boolean: You can fit quite a lot of checkboxes in a dialog or tab card. Replace the checkbox with an integer value entry field - a lot of those will go into a single tabcard, too.
There would still be a huge number of pulldown lists - far too many. Far too many check boxes and numeric values. But not as bad as I thought before checking the output closer: There are not 15421 distinct options, as my first impression was. But a few hundred distinct ones is certainly bad enough.
I strongly suspect that half of these options / argument values are never used by anyone but the ffmpeg developers 
|
|
|
|
|
Sure, even eliminating everything you mentioned should simplify things...but still, if someone wanted to build a UI equivalent to all options supported via the command line...and have the smarts to group things together, separating items through tabs, adjust things based on combinations/mutually exclusive options, etc...it would still be a mess of a UI, I'd have to think.
And then, trying to make it user-friendly - reserve an area on the screen to show some text (not just a few words), that dynamically changes based on the control that is currently selected (to explain what it does)...and it would still overwhelm the vast majority of users.
trønderen wrote: I strongly suspect that half of these options / argument values are never used by anyone but the ffmpeg developers
That's a given...when you present too many options, people will do the minimum they need to get things working, then pretty much leave it at that and stick with what they know and never experiment beyond that. So the extra effort those devs put in, really ends up working against them.
|
|
|
|
|
Maybe someone should create a ffmpegSimple wrapper, which accepts only the top 20 or 30 most useful switches. This would be useful to a noob, who can then explore the other switches upon gaining familiarity.
|
|
|
|
|
"ffmpeg wrapper"
In github there are 232 public repositories matching this topic.
|
|
|
|
|
MrChug wrote: Is there another piece of software that has this many command line options?
Time for Guinness World Records?
|
|
|
|
|
Time for a Guinness, period. ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
See: 5 Free GUI For FFmpeg[^]
A tool like inshellisense might be handy too, it can be used from the command-line, powershell, bash etc, but I don't think it offers FFmpeg support yet.
|
|
|
|
|
I think the point is that any one user only has a small number of commands that they use regularly, pertaining to:
- type of file: mov, ts, mp4, jpg, avi, etc...
- operation: crop, adjust color, brightness, contrast, convert, denoise, etc...
- stream assignment, etc...
You learn the commands that you need, and thankfully there is loads of help available on the Interweb, and (most important of all) the documentation is pretty good. I have a list of all the commands that I have ever used and just copy paste new commands as I need to do new things.
My interest BTW, is splitting movies to pngs, and reassembling movies with audio, adjusting frame rates, trimming and editing movies. I also use it with Blender where the preferred output is png files.
It's brilliant!
|
|
|
|
|
Somebody needs to learn YAGNI.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
Fair enough, but in my career I have been into quite a few discussions / arguments where I have held up an architecture, data structure or whatever, as far better suited for future extensions than another one. Then I have been voted down; "We can't worry about future extensions now!", even though the future proof alternative was no more costly to implement. In several cases, there was the "Not invented by me" syndrome: The first implementation was done the way the most senior developer suggested (or the most aggressive new-and-upcoming-star youngsters).
In one case, the project management realized only three months later that the project had a "technical debt" - a major rewrite of core modules were required to handle the extensions for the next release. Usually it takes at least six months
Far too many "agile"!
|
|
|
|
|
Fair enough, but in my career I have been into quite a few discussions / arguments where I have held up an architecture, data structure or whatever, as far better suited for future extensions than another one. Then I have been voted down; "We can't worry about future extensions now!", even though the future proof alternative was no more costly to implement. In several cases, there was the "Not invented by me" syndrome: The first implementation was done the way the most senior developer suggested (or the most aggressive new-and-upcoming-star youngsters).
In one case, the project management realized only three months later that the project had a "technical debt" - a major rewrite of core modules were required to handle the extensions for the next release. Usually it takes at least six months
Far too many "agile" proponents consider it a mortal sin to understand the real problem to be solved before writing 'int main(...' Knowing and understanding the problem domain in advance is against the principles of agile programming.
Not that books on agile development says so. Yet, far too many developers (and project managers) says so (at least indirectly).
|
|
|
|
|
Image Magik probably comes a close second for sheer number of options
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![[[This is a marketing photo for a Microphone]]](https://i.ebayimg.com/images/g/m1MAAOSwgBtksR7f/s-l1600.jpg){kind=link}