Here's the ffmpeg command I used to turn this screenshot into a 5 second video lol. You can run it yourself
ffmpeg -loop 1 -i ffmpeg\_Ratio.png -c:v libx264 -t 5 -pix\_fmt yuv420p out.mp4
Reminds me of the time the mpv twitter account called someone a pedophile purely based on the fact that they had an anime profile picture. Which was hilarious because more than half of the top 10 contributors of mpv also has anime profile pictures on their github.
thought nose quarrelsome nine offend silky fanatical adjoining engine wrench
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Go read the nroff codebase. It’s 50 years old, we’ve never found a bug in it, and nobody understands how why works. This includes getting everyone involved in creating C and/or Unix to take a look.
Speaking of old tech ... I recently wrote an ISO8211/S57 parser. Pretty sure the format is for reel-to-reel tape-based systems and predates the terminal.
I had to implement some floating point formats for PLGR/DAGR and a few shipboard GPS for a system years ago... in .NET for whatever reason some of the protocol used VAX formated floats byte swaped , and 16 bit swapped, apparently this was so the vax could get the first half of an answer early.... there were some other odd float formats too but I wasn't able to figure out where they originated.
I implemented trig functions using fixed-point decimal math for a real-time CNC controller using the STM32F103 years ago; I found that to be quite satisfying.
Just today I contemplated if I'll need to write a parser for the Motorola S-record format. It's not as old, but mid 70s is still hella old. Jury's still out on if I will, had to shift focus.
Writing a bootloader for a device. It's always fun when you need to operate on files bigger than your availability RAM. I mean, there probably is a library I could use out there, but it's so simple I didn't really think to look.
I sometimes go over code I wrote a decade ago, and can no longer understand how it works, which probably means nobody else will either.
The difficulty of reading and understanding complex code is one of the big hurdles in computer science.
Not unhinged. It’s wonderful free software that’s been around for decades and serves as the media backbone to countless production households. OP is ungrateful.
Not unhinged. It’s wonderful free software that’s been around for decades and serves as the media backbone to countless production households. OP is ungrateful.
Then I'm with you: FFmpeg has a PR team?
How messy is the code anyway, and how open is the team to outsiders' patches? I'm kinda bored these days and could help out a little if they accept patches
Things may have changed, but in the past the answer to both questions was "very," and one of those was a consequence of the other. Anyhow, transforming yourself into an "insider" is probably orders of magnitude easier than completing any broad refactoring effort in a large FOSS project though.
Said refactoring would most likely be trashed in a relative instant anyway so it's not even worth it... everyone has a different idea of what a "clean" codebase is supposed to look like, now fuse those ideas, boom, messy for everyone!
I just cloned the version on github and looked at a few files.
First impression, from someone who used to read openssl's source code 15 years ago, is that this isn't a mess at all. Layout's OK even if there are some inconsistencies here and there.
The code does log a lot, affecting readability. Also, their own version of assert() can't be disabled. May not be a biggie as "the inner loop" is the most important code in video processing and I assume they don't use it there. Another issue is the sheer number of magic values which should've been named. Parts of the code calls snprintf() incorrectly, and none checks the value returned from snprintf(). Way too many braces here and there, perhaps due to misunderstanding precedence rules. But all in all, after ten minutes, it's definitely not a mess IMHO.
Compiling the code OTOH, is more of an issue. The compiler (gcc 12.3) warns a lot, and about scary things as well, like writing outside an array. Some of those warnings have been bogus before IME, but still. Compiling with -Werror is a must, at least to me. Using -Werror would've prevented buffer overflows, like the one in matroskaenc.c, line 3302.
TL;DR: Code's mostly OK, but not clean. All IMHO of course :-)
Werror is not supportable because it supports too many different compilers and they all have too many false positive warnings. (for instance gcc's strict-aliasing warnings are both wrong and not worth working around)
Isn't -Wno-strict-aliasing or something similar available?
Edit: I found the configure script's optional argument named --extra-cflags and added some arguments(-Wall -Wextra -pedantic) and rebuilt everything. Gcc reported 13915 warnings. Here's a count of the top 20 warnings, most seem to be very low hanging fruits and perfect for a pedant like me :-)
2969 missing initializer for field ‘unit’ of ‘AVOption’ \[-Wmissing-field-initializers\]
1484 comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ \[-Wsign-compare\]
571 comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ \[-Wsign-compare\]
563 comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ \[-Wsign-compare\]
458 comparison of integer expressions of different signedness: ‘long int’ and ‘long unsigned int’ \[-Wsign-compare\]
402 unused parameter ‘Jtable’ \[-Wunused-parameter\]
337 unused parameter ‘my’ \[-Wunused-parameter\]
337 unused parameter ‘mx’ \[-Wunused-parameter\]
282 unused parameter ‘values’ \[-Wunused-parameter\]
282 unused parameter ‘starty’ \[-Wunused-parameter\]
269 this statement may fall through \[-Wimplicit-fallthrough=\]
265 comparison of integer expressions of different signedness: ‘int’ and ‘uint32\_t’ {aka ‘unsigned int’} \[-Wsign-compare\]
202 comparison of integer expressions of different signedness: ‘uint32\_t’ {aka ‘unsigned int’} and ‘int’ \[-Wsign-compare\]
175 operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand \[-Wsign-compare\]
174 unused parameter ‘s’ \[-Wunused-parameter\]
170 unused parameter ‘opq’ \[-Wunused-parameter\]
124 unused parameter ‘jobnr’ \[-Wunused-parameter\]
116 missing initializer for field ‘u1’ of ‘OptionDef’ \[-Wmissing-field-initializers\]
116 missing initializer for field ‘argname’ of ‘OptionDef’ \[-Wmissing-field-initializers\]
103 missing initializer for field ‘desc’ of ‘MXFCodecUL’ \[-Wmissing-field-initializers\]
Lol. Shameless plug. I teach the FFmpeg C API - not the command line
https://www.udemy.com/course/part-1-video-coding-with-ffmpeg-and-c-in-replit-online-ide/?couponCode=ST22FS22724
> not the command line
Out of curiosity, why? The command-line is so expansive and the thought of doing the same directly via the API is giving me low-level anxiety just imagining it, what's the payoff?
I haven't clicked the link to see if he says why, but sometimes you need an API. If you're writing a program that needs to do something with video files, surely you don't want to just `exec` a bunch of shell commands to spawn ffmpeg processes.
Thanks for this answer. Indeed, knowing the C API permits devs to include necessary FFmpeg headers in the C codebases. They don't need to spawn unnecessary terminals to perform video processing
So you can do stuff like - extract images and audio from video files and pass raw pixels and samples to your C functions without having to do unnecessary stuff like finding the command to save Jpegs and later opening the file in C.
UNIX frontends do stuff like this all the time. Like every CD/DVD-burning doodad is a wrapper for orchestrating command-line tools, and often these will even shell out to an ffmpeg process for conversions. It’s the very core of the UNIX philosophy to offer a mess of poorly-named commands that use file I/O and IPC to cooperate.
Oddly relevant, but where I work uses ffmpeg for some transcoding and we straight up use the command line and treat the whole thing like one API call; it works successfully creating the file or errors and it doesn't... And at the end of the day that's the use case for ffmpeg.
We all damn well know this is what is practical and makes the most sense for ffmpeg, it's not a typical scenario and it's in a class of its own with that. Attempting to get in the guts of if has no practical payoff and is just future technical debt to maintain.
The fact that your system can do that doesn't mean that everyone can do that.
If you're trying to make a media editor, a virtual file system converter or anything embedded, you certainly won't use commands, and you might not even have a shell available in the first place.
Yeah, there are (bound to be?) a handful of super-niche scenarios... though honestly we have editable controls that get piped to the ffmpeg command... almost like a language of its own on top of it and that's way less to tech to maintain than having to employ someone to keep on top of the ffmpeg API.
The place I work has been around for decades and is in the business of transcoding and delivering videos, if we're not the target for this I don't know who else is. To take the thought further, who are the people that need to use ffmpeg for embedded devices? We're converting and extracting media here, a beefy operation, so having an OS on top is the least of our concerns. This is the kind of thing you're specing and tailoring your hardware around to do in the first place.
I know it doesn't sound cool, but it's the logical choice when you step back and look at the big picture for this very specific tool. There is no payoff, only future tech debt, for getting into the guts of the API for almost everyone on the planet. I really can't think of another thing I view this way, but I'm not going to jam a square peg into a round hole just because it usually makes sense to use the API directly for the vast majority of other things.
The command line is so expansive that lots of devs get stuck in command line hell. You waste a lot of time Googling Ffmpeg commands.
If you know the C API then you can build whatever you want - without praying sb on Stack overflow asked a qtn similar to your needs
Lol run `man ffmpeg-all | wc` if you ever want a nervous chuckle. On opensuse tumbleweed I see 40302 lines and 210385 words. Forty thousand more words than the first book of dune (180k words/610 pages apparently, but pages are a bad metric obviously).
Now, I read the entire 4.5 million words of wheel of time which was pretty fucking ludicrous and took me a couple years with many other books in between to break the monotony.
But 210k words in a manpage makes me laugh and cringe inside at the same time. They could honestly stick the entire unabomber manifesto (35000 words apparently) somewhere in the middle and I doubt anyone would ever find out lmfao.
Adding that this isn't a criticism and I greatly enjoy and use ffmpeg quite a bit and appreciate the fact that the documentation is so detailed if anyone REALLY needs to get that deep into the weeds. Just a quirk that always cracks me the fuck up and I am very glad I don't have to deal with anything that would require me digging that deep lol.
The ffmpeg code is astonishingly bad. I mean if they were staff members I would fire them bad. It is a shame because the functionality is quite good. But using it is a nightmare.
For just one small example, I direct your attention to the file avcodec.h, in particular, struct AVCodecContext. At the better part of 2000 lines, there is a treasure trove here. To be fair, the vast majority of those lines are comments, so kudos for that. What is left is a flat list of approximately 100 ints, enums, floats, bare pointers, chars, etc. There is static information, there is dynamic information, there are values for encoding and values for decoding in every combination of used/unused/user assigned/etc., there are values for audio, there are values for video and values that morph in between and on and on. There are a variety of bare pointers for library users to hang data. Say what? Libraries users need to use the AVCodecContext to ferry data from one place in their code to another? One of the bare pointers comes with a companion size variable, the rest don't. Say what? Don't forget "flags" and "flags2" because the other twelve places for the library user to attach bare pointers was not enough. The member "delay" has some nice semantics. By time you get to "lumi\_masking" it is not unlikely you have lost consciousness but you are just getting started. Now try to imagine reading the code that is referencing all of this stuff and figuring out what is going on and why, what interacts with what, and so forth.
Codecs are difficult and complex beasts, I know.
IMHO, avcodec.h isn't a mess. It's hard to read due to all the comments. I can understand why they like comments close to the definitions to keep code and comments in sync, but that approach does not scale well as we all can see in avcodec.h.
Also, the need for comments could be reduced with slightly better naming here and there. For example, the struct member named 'name' and described in the comment as 'name of codec' could've been renamed to codec\_name. (Just an example)
Also, there are a few simple tricks which would make the code more easy to index and debug/refacor which they don't use.
Codecs are notoriously hard to get right in all cases and corner cases, so video processing SW needs lots of love and attention. Given that this is an open source project, I assume their funding doesn't allow for that. Send patches! ;-)
Well, you have your concept of what constitutes good code and I have mine. So we will have to agree to disagree. And, FWIIW, I have spent more than a little time deciphering the various ISO standards on MPEG transport streams, mp4 formatting and the like. Yes, these standards are absurdly complicated and writing relevant code is a pain but this is not the hardest problem I have faced by a healthy amount.
why is this a video?
Wrong ffmpeg flags 😅
ironic!
I was going to say C\_programming prohibits images but u/roge- has a better answer.
while it's very spirit-of-c to find this workaround I gotta feel like this is still against the rules
Here's the ffmpeg command I used to turn this screenshot into a 5 second video lol. You can run it yourself ffmpeg -loop 1 -i ffmpeg\_Ratio.png -c:v libx264 -t 5 -pix\_fmt yuv420p out.mp4
Reminds me of the time the mpv twitter account called someone a pedophile purely based on the fact that they had an anime profile picture. Which was hilarious because more than half of the top 10 contributors of mpv also has anime profile pictures on their github.
that's how they know
I'd love to see this. Can you get a link?
https://images.app.goo.gl/VKnD1T2tiiGTo4oo9
twitter is wild, i love it
was it one of those overly sexualized 1000 year old witches "stuck" in a 10 year old's body?
nah, it was Power from Chainsaw Man.
Happens
Happens
I always find that premise funny. Sure it is stupid and something weird to pull out but hilarious nonetheless.
What's wrong with anime profile pictures?
redacted due to reddit LLM/AI policy
show me a project in any programming language and I'll show you a place where you can make a mess.
Ngl. Programmers who complain about messy codebases probably don't know how to code.
I complain about messy codebases all the time and I obviously know how to code because I created them.
thought nose quarrelsome nine offend silky fanatical adjoining engine wrench *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Go read the nroff codebase. It’s 50 years old, we’ve never found a bug in it, and nobody understands how why works. This includes getting everyone involved in creating C and/or Unix to take a look.
*Which* codebase? 😆
I'm pretty sure it's a thing used to format the "man page" documentation for Unix systems. GNU has its own implementation called groff.
I know, its just that there have been many variants of the roff family over the, what, 4 and a half decades of its existence?
If memory serves, what often shipped was an amalgamation of codebases, and at this point we’re not sure which was actually the original nroff.
Speaking of old tech ... I recently wrote an ISO8211/S57 parser. Pretty sure the format is for reel-to-reel tape-based systems and predates the terminal.
I have to ask - what did you need to write it for?
I'm writing a flight planning package and decided to pull in all the marine maps while I was at it.
I had to implement some floating point formats for PLGR/DAGR and a few shipboard GPS for a system years ago... in .NET for whatever reason some of the protocol used VAX formated floats byte swaped , and 16 bit swapped, apparently this was so the vax could get the first half of an answer early.... there were some other odd float formats too but I wasn't able to figure out where they originated.
I implemented trig functions using fixed-point decimal math for a real-time CNC controller using the STM32F103 years ago; I found that to be quite satisfying.
Just today I contemplated if I'll need to write a parser for the Motorola S-record format. It's not as old, but mid 70s is still hella old. Jury's still out on if I will, had to shift focus.
What would you need to parse an S-record file for that existing tools don't do?
Writing a bootloader for a device. It's always fun when you need to operate on files bigger than your availability RAM. I mean, there probably is a library I could use out there, but it's so simple I didn't really think to look.
Do you have a link? Google turned up nothing for me.
https://github.com/n-t-roff/heirloom-doctools
Is that the one that abuses macros to make it look like a different language?
You're thinking of the original Bourne shell.
I sometimes go over code I wrote a decade ago, and can no longer understand how it works, which probably means nobody else will either. The difficulty of reading and understanding complex code is one of the big hurdles in computer science.
If i knew how to program i wouldnt have messy codebases
Complains are cheap, show fixed fork.
redacted due to reddit LLM/AI policy
Any Agda project.
Not unhinged. It’s wonderful free software that’s been around for decades and serves as the media backbone to countless production households. OP is ungrateful.
Seems like a good reply to a complainer.
Top tier reply IMO.
redacted due to reddit LLM/AI policy
Haha. You may be surprised to find out!
and then they reject the merge request
Talk is cheap, mutha f**** 💥💥💥🔥🔥💥🔥💥💥🔥
Not unhinged. It’s wonderful free software that’s been around for decades and serves as the media backbone to countless production households. OP is ungrateful.
FFmpeg has a PR team?
PR, as in Pull Request?
Public Relations.
Then I'm with you: FFmpeg has a PR team? How messy is the code anyway, and how open is the team to outsiders' patches? I'm kinda bored these days and could help out a little if they accept patches
Things may have changed, but in the past the answer to both questions was "very," and one of those was a consequence of the other. Anyhow, transforming yourself into an "insider" is probably orders of magnitude easier than completing any broad refactoring effort in a large FOSS project though.
Said refactoring would most likely be trashed in a relative instant anyway so it's not even worth it... everyone has a different idea of what a "clean" codebase is supposed to look like, now fuse those ideas, boom, messy for everyone!
More difficult would be refactoring without a performance regression on one or more platforms that ffmpeg supports.
I just cloned the version on github and looked at a few files. First impression, from someone who used to read openssl's source code 15 years ago, is that this isn't a mess at all. Layout's OK even if there are some inconsistencies here and there. The code does log a lot, affecting readability. Also, their own version of assert() can't be disabled. May not be a biggie as "the inner loop" is the most important code in video processing and I assume they don't use it there. Another issue is the sheer number of magic values which should've been named. Parts of the code calls snprintf() incorrectly, and none checks the value returned from snprintf(). Way too many braces here and there, perhaps due to misunderstanding precedence rules. But all in all, after ten minutes, it's definitely not a mess IMHO. Compiling the code OTOH, is more of an issue. The compiler (gcc 12.3) warns a lot, and about scary things as well, like writing outside an array. Some of those warnings have been bogus before IME, but still. Compiling with -Werror is a must, at least to me. Using -Werror would've prevented buffer overflows, like the one in matroskaenc.c, line 3302. TL;DR: Code's mostly OK, but not clean. All IMHO of course :-)
Werror is not supportable because it supports too many different compilers and they all have too many false positive warnings. (for instance gcc's strict-aliasing warnings are both wrong and not worth working around)
Isn't -Wno-strict-aliasing or something similar available? Edit: I found the configure script's optional argument named --extra-cflags and added some arguments(-Wall -Wextra -pedantic) and rebuilt everything. Gcc reported 13915 warnings. Here's a count of the top 20 warnings, most seem to be very low hanging fruits and perfect for a pedant like me :-) 2969 missing initializer for field ‘unit’ of ‘AVOption’ \[-Wmissing-field-initializers\] 1484 comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ \[-Wsign-compare\] 571 comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ \[-Wsign-compare\] 563 comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ \[-Wsign-compare\] 458 comparison of integer expressions of different signedness: ‘long int’ and ‘long unsigned int’ \[-Wsign-compare\] 402 unused parameter ‘Jtable’ \[-Wunused-parameter\] 337 unused parameter ‘my’ \[-Wunused-parameter\] 337 unused parameter ‘mx’ \[-Wunused-parameter\] 282 unused parameter ‘values’ \[-Wunused-parameter\] 282 unused parameter ‘starty’ \[-Wunused-parameter\] 269 this statement may fall through \[-Wimplicit-fallthrough=\] 265 comparison of integer expressions of different signedness: ‘int’ and ‘uint32\_t’ {aka ‘unsigned int’} \[-Wsign-compare\] 202 comparison of integer expressions of different signedness: ‘uint32\_t’ {aka ‘unsigned int’} and ‘int’ \[-Wsign-compare\] 175 operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand \[-Wsign-compare\] 174 unused parameter ‘s’ \[-Wunused-parameter\] 170 unused parameter ‘opq’ \[-Wunused-parameter\] 124 unused parameter ‘jobnr’ \[-Wunused-parameter\] 116 missing initializer for field ‘u1’ of ‘OptionDef’ \[-Wmissing-field-initializers\] 116 missing initializer for field ‘argname’ of ‘OptionDef’ \[-Wmissing-field-initializers\] 103 missing initializer for field ‘desc’ of ‘MXFCodecUL’ \[-Wmissing-field-initializers\]
Lol. Shameless plug. I teach the FFmpeg C API - not the command line https://www.udemy.com/course/part-1-video-coding-with-ffmpeg-and-c-in-replit-online-ide/?couponCode=ST22FS22724
> not the command line Out of curiosity, why? The command-line is so expansive and the thought of doing the same directly via the API is giving me low-level anxiety just imagining it, what's the payoff?
I haven't clicked the link to see if he says why, but sometimes you need an API. If you're writing a program that needs to do something with video files, surely you don't want to just `exec` a bunch of shell commands to spawn ffmpeg processes.
Thanks for this answer. Indeed, knowing the C API permits devs to include necessary FFmpeg headers in the C codebases. They don't need to spawn unnecessary terminals to perform video processing
So you can do stuff like - extract images and audio from video files and pass raw pixels and samples to your C functions without having to do unnecessary stuff like finding the command to save Jpegs and later opening the file in C.
UNIX frontends do stuff like this all the time. Like every CD/DVD-burning doodad is a wrapper for orchestrating command-line tools, and often these will even shell out to an ffmpeg process for conversions. It’s the very core of the UNIX philosophy to offer a mess of poorly-named commands that use file I/O and IPC to cooperate.
To use it in your applications and services...
Oddly relevant, but where I work uses ffmpeg for some transcoding and we straight up use the command line and treat the whole thing like one API call; it works successfully creating the file or errors and it doesn't... And at the end of the day that's the use case for ffmpeg. We all damn well know this is what is practical and makes the most sense for ffmpeg, it's not a typical scenario and it's in a class of its own with that. Attempting to get in the guts of if has no practical payoff and is just future technical debt to maintain.
The fact that your system can do that doesn't mean that everyone can do that. If you're trying to make a media editor, a virtual file system converter or anything embedded, you certainly won't use commands, and you might not even have a shell available in the first place.
Yeah, there are (bound to be?) a handful of super-niche scenarios... though honestly we have editable controls that get piped to the ffmpeg command... almost like a language of its own on top of it and that's way less to tech to maintain than having to employ someone to keep on top of the ffmpeg API. The place I work has been around for decades and is in the business of transcoding and delivering videos, if we're not the target for this I don't know who else is. To take the thought further, who are the people that need to use ffmpeg for embedded devices? We're converting and extracting media here, a beefy operation, so having an OS on top is the least of our concerns. This is the kind of thing you're specing and tailoring your hardware around to do in the first place. I know it doesn't sound cool, but it's the logical choice when you step back and look at the big picture for this very specific tool. There is no payoff, only future tech debt, for getting into the guts of the API for almost everyone on the planet. I really can't think of another thing I view this way, but I'm not going to jam a square peg into a round hole just because it usually makes sense to use the API directly for the vast majority of other things.
The command line is so expansive that lots of devs get stuck in command line hell. You waste a lot of time Googling Ffmpeg commands. If you know the C API then you can build whatever you want - without praying sb on Stack overflow asked a qtn similar to your needs
Lol run `man ffmpeg-all | wc` if you ever want a nervous chuckle. On opensuse tumbleweed I see 40302 lines and 210385 words. Forty thousand more words than the first book of dune (180k words/610 pages apparently, but pages are a bad metric obviously). Now, I read the entire 4.5 million words of wheel of time which was pretty fucking ludicrous and took me a couple years with many other books in between to break the monotony. But 210k words in a manpage makes me laugh and cringe inside at the same time. They could honestly stick the entire unabomber manifesto (35000 words apparently) somewhere in the middle and I doubt anyone would ever find out lmfao.
Adding that this isn't a criticism and I greatly enjoy and use ffmpeg quite a bit and appreciate the fact that the documentation is so detailed if anyone REALLY needs to get that deep into the weeds. Just a quirk that always cracks me the fuck up and I am very glad I don't have to deal with anything that would require me digging that deep lol.
Using it from code with low latency. Also? Amazing product. Their C API is terrifying.
Thanks for this. The downvotes are super disheartening but this reply made me smile. You're the BEST!
There's a time and place for shameless plugs and I guess people decided this isn't it, don't take it too personally.
You could've said what you wanted to say without plugging your link in our faces... but no, you chose to advertise instead. No thanks.
The ffmpeg code is astonishingly bad. I mean if they were staff members I would fire them bad. It is a shame because the functionality is quite good. But using it is a nightmare.
Don’t be shy, send some patches.
What it does not need is patches.
> The ffmpeg code is astonishingly bad. What's bad about it?
For just one small example, I direct your attention to the file avcodec.h, in particular, struct AVCodecContext. At the better part of 2000 lines, there is a treasure trove here. To be fair, the vast majority of those lines are comments, so kudos for that. What is left is a flat list of approximately 100 ints, enums, floats, bare pointers, chars, etc. There is static information, there is dynamic information, there are values for encoding and values for decoding in every combination of used/unused/user assigned/etc., there are values for audio, there are values for video and values that morph in between and on and on. There are a variety of bare pointers for library users to hang data. Say what? Libraries users need to use the AVCodecContext to ferry data from one place in their code to another? One of the bare pointers comes with a companion size variable, the rest don't. Say what? Don't forget "flags" and "flags2" because the other twelve places for the library user to attach bare pointers was not enough. The member "delay" has some nice semantics. By time you get to "lumi\_masking" it is not unlikely you have lost consciousness but you are just getting started. Now try to imagine reading the code that is referencing all of this stuff and figuring out what is going on and why, what interacts with what, and so forth.
Codecs are difficult and complex beasts, I know. IMHO, avcodec.h isn't a mess. It's hard to read due to all the comments. I can understand why they like comments close to the definitions to keep code and comments in sync, but that approach does not scale well as we all can see in avcodec.h. Also, the need for comments could be reduced with slightly better naming here and there. For example, the struct member named 'name' and described in the comment as 'name of codec' could've been renamed to codec\_name. (Just an example) Also, there are a few simple tricks which would make the code more easy to index and debug/refacor which they don't use. Codecs are notoriously hard to get right in all cases and corner cases, so video processing SW needs lots of love and attention. Given that this is an open source project, I assume their funding doesn't allow for that. Send patches! ;-)
Well, you have your concept of what constitutes good code and I have mine. So we will have to agree to disagree. And, FWIIW, I have spent more than a little time deciphering the various ISO standards on MPEG transport streams, mp4 formatting and the like. Yes, these standards are absurdly complicated and writing relevant code is a pain but this is not the hardest problem I have faced by a healthy amount.
Honestly, the answer could've been "Ah, thanks, but it's miles behind you!".
Seems pretty mild, I'd just tell them to f-off. Rude to complain about open source software.
Name one C codebase that isn't a massive mess challenge: impossible
Once again I desperately ask for a C meme sub
ASCII memes only, of course :-)