3 ms·

> I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." Examples: 2 prores decoders, 2 prores enc

by jbk 11y ago

> I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess." Examples: 2 prores decoders, 2 prores encoders (or 3), 2 different resampling libraries, libstagefright integration that does not work, more global context structures compared to libav, etc... They also refused to remove some very outdated (non-working) code like xvmc. > why doesn't someone (like VLC) take the best features from both projects and create their own library? Because it's a lot of work. An enormous work.

zvrba 11y ago
Having multiple implementations of a feature does not make it a "mess" unless they step on each other's toes.
makomk 11y ago
If I remember correctly, a big part of the reason that ffmpeg ended up with two resampling libraries is that after they'd created theirs, libav wrote their own with a different, totally incompatible API and ffmpeg wanted to support applications that were written for the libav API.
- loup-vaillant 11y ago
  "There is a reason for everything" Scott Meyers, talking of the various… quirks of C++. https://www.youtube.com/watch?v=48kP_Ssg2eY https://www.youtube.com/watch?v=48kP_Ssg2eY
anon4 11y ago
For what it's worth, a lot of production code looks this way. It's not right, it really should be nice and neat and so on. However, I don't see it as a grave sin against the project. Messy code can diverge where needed more easily. Three different copies of the same code? Yeah, ok. That's ok. One day, when you can, merge them together. You can't merge them together? It's ok. Maybe they shouldn't be merged together. Is it a barrier to entry for new developers? I feel that any developer who has worked on messy legacy code won't bat an eye. This sounds more like a problem experienced by a young coder fresh out of university. You definitely can write clean code. Cleanliness can be a priority. There are some surprisingly clean and well-written large codebases out there. However, a lot of people just don't care. They are very smart, capable people who just bang out code that works and don't care to integrate in the proper clean way with the old code. If you want clean code, an old, large, working C/C++ codebase is not what you want. We often can't spend time cleaning up old code, since there's always more features to implement, bugs to fix, etc. Learn to deal pragmatically with code like that. It's not like that out of malice, or some misguided attempt at writing the largest IOCCC winner. You can work with it. It's just a bit trickier.
- subliminalbrad 11y ago
  Writing clean code is not an academic exercise. It means comprehending it takes longer, writing features takes longer, testing it takes longer. It makes every interaction with the codebase harder. That might not be quite as bad in a proprietary codebase since you have somewhat more of a captive audience, but in an open source project where you want a long-tail of contributions from many people, that is a serious problem.
- prewett 11y ago
  I've worked on some of those "old, large, working C/C++ codebases" and the ones that are not clean are the ones where you are terrified of making a small change to fix a bug, especially close to release, because you have absolutely no idea what might break. Two copies of the same code? Great, which one do I fix? Both? How do I test that it worked, I can't even figure out where #2 is activated in the UI?! Is there something a little different about them that I need to watch out for? And test cases for said codebase? Hahahahaha!

by jbk 11y ago

zvrba 11y ago

Having multiple implementations of a feature does not make it a "mess" unless they step on each other's toes.

makomk 11y ago

If I remember correctly, a big part of the reason that ffmpeg ended up with two resampling libraries is that after they'd created theirs, libav wrote their own with a different, totally incompatible API and ffmpeg wanted to support applications that were written for the libav API.

loup-vaillant 11y ago
"There is a reason for everything" Scott Meyers, talking of the various… quirks of C++. https://www.youtube.com/watch?v=48kP_Ssg2eY https://www.youtube.com/watch?v=48kP_Ssg2eY

anon4 11y ago

For what it's worth, a lot of production code looks this way. It's not right, it really should be nice and neat and so on. However, I don't see it as a grave sin against the project. Messy code can diverge where needed more easily. Three different copies of the same code? Yeah, ok. That's ok. One day, when you can, merge them together. You can't merge them together? It's ok. Maybe they shouldn't be merged together. Is it a barrier to entry for new developers? I feel that any developer who has worked on messy legacy code won't bat an eye. This sounds more like a problem experienced by a young coder fresh out of university. You definitely can write clean code. Cleanliness can be a priority. There are some surprisingly clean and well-written large codebases out there. However, a lot of people just don't care. They are very smart, capable people who just bang out code that works and don't care to integrate in the proper clean way with the old code. If you want clean code, an old, large, working C/C++ codebase is not what you want. We often can't spend time cleaning up old code, since there's always more features to implement, bugs to fix, etc. Learn to deal pragmatically with code like that. It's not like that out of malice, or some misguided attempt at writing the largest IOCCC winner. You can work with it. It's just a bit trickier.

subliminalbrad 11y ago
Writing clean code is not an academic exercise. It means comprehending it takes longer, writing features takes longer, testing it takes longer. It makes every interaction with the codebase harder. That might not be quite as bad in a proprietary codebase since you have somewhat more of a captive audience, but in an open source project where you want a long-tail of contributions from many people, that is a serious problem.
prewett 11y ago
I've worked on some of those "old, large, working C/C++ codebases" and the ones that are not clean are the ones where you are terrified of making a small change to fix a bug, especially close to release, because you have absolutely no idea what might break. Two copies of the same code? Great, which one do I fix? Both? How do I test that it worked, I can't even figure out where #2 is activated in the UI?! Is there something a little different about them that I need to watch out for? And test cases for said codebase? Hahahahaha!