4 ms·

ffmpeg https://github.com/FFmpeg/FFmpeg https://github.com/FFmpeg/FFmpeg

by e9 7y ago

gnulinux 7y ago
Recently had to make a few changes to ffmpeg codebase. It's pretty good.
astrange 7y ago
The build system and assembly system (x86asm) are very underrated. Open source went from autotools, which are awful, to cmake, which also seems to be awful. ffmpeg's configure/make system has the same interface as autotools but is actually good. libavformat is rather difficult to use and difficult to fix bugs in - you'll never find the bugs. Same with the ffmpeg frontend, which makes it easy to ask for something it's near impossible to get right, like copying an mkv file to an avi, it'll just corrupt your data silently. Everything about the video decoders is great, but encoding never worked as well, which is why nobody uses ffmpeg2/4/etc and x264 is a separate project.
- _Gyan_ 7y ago
  libavformat is rather difficult to use and difficult to fix bugs in - you'll never find the bugs. Some examples? encoding never worked as well, which is why nobody uses ffmpeg2/4/etc and x264 is a separate project. Most users use x264 _via_ ffmpeg since they may need to filter the video and/or filter/process/mux audio and other streams.
  - astrange 7y ago
    > Some examples? Just try copying video between different containers (mkv, ts, avi for one) without reencoding. > Most users use x264 _via_ ffmpeg since they may need to filter the video and/or filter/process/mux audio and other streams. They don't have to do that; you can handle each track separately and mux them back afterward. I'm talking about ffmpeg's builtin MPEG2/4/MP3 encoders, which nobody used when they were competitive because it leaves all the options at "go fast" instead of providing tunings. They're also unmaintained and the code is hard to figure out - that's why x264 was a separate project instead of just another part of libavcodec.
    - _Gyan_ 7y ago
      Just try copying video between different containers (mkv, ts, avi for one) without reencoding. I do, all the time. AVI is an old container and it has issues with B-frames and also VFR but those are container limitations, not a libavformat issue. All transmuxing between common modern containers with present-day common codecs work fine. There are always edge cases, but that's what they are, edge cases. you can handle each track separately and mux them back afterward. Why do that? What's the benefit? I'm talking about ffmpeg's builtin MPEG2/4/MP3 encoders You seem to be talking about the state more than a decade back. How's that relevant to 2019? BTW, there is no native MP3 encoder.

ffmpeg https://github.com/FFmpeg/FFmpeg https://github.com/FFmpeg/FFmpeg

by e9 7y ago

ffmpeg https://github.com/FFmpeg/FFmpeg https://github.com/FFmpeg/FFmpeg

gnulinux 7y ago

Recently had to make a few changes to ffmpeg codebase. It's pretty good.

astrange 7y ago

The build system and assembly system (x86asm) are very underrated. Open source went from autotools, which are awful, to cmake, which also seems to be awful. ffmpeg's configure/make system has the same interface as autotools but is actually good. libavformat is rather difficult to use and difficult to fix bugs in - you'll never find the bugs. Same with the ffmpeg frontend, which makes it easy to ask for something it's near impossible to get right, like copying an mkv file to an avi, it'll just corrupt your data silently. Everything about the video decoders is great, but encoding never worked as well, which is why nobody uses ffmpeg2/4/etc and x264 is a separate project.

_Gyan_ 7y ago
libavformat is rather difficult to use and difficult to fix bugs in - you'll never find the bugs. Some examples? encoding never worked as well, which is why nobody uses ffmpeg2/4/etc and x264 is a separate project. Most users use x264 _via_ ffmpeg since they may need to filter the video and/or filter/process/mux audio and other streams.
- astrange 7y ago
  > Some examples? Just try copying video between different containers (mkv, ts, avi for one) without reencoding. > Most users use x264 _via_ ffmpeg since they may need to filter the video and/or filter/process/mux audio and other streams. They don't have to do that; you can handle each track separately and mux them back afterward. I'm talking about ffmpeg's builtin MPEG2/4/MP3 encoders, which nobody used when they were competitive because it leaves all the options at "go fast" instead of providing tunings. They're also unmaintained and the code is hard to figure out - that's why x264 was a separate project instead of just another part of libavcodec.
  - _Gyan_ 7y ago
    Just try copying video between different containers (mkv, ts, avi for one) without reencoding. I do, all the time. AVI is an old container and it has issues with B-frames and also VFR but those are container limitations, not a libavformat issue. All transmuxing between common modern containers with present-day common codecs work fine. There are always edge cases, but that's what they are, edge cases. you can handle each track separately and mux them back afterward. Why do that? What's the benefit? I'm talking about ffmpeg's builtin MPEG2/4/MP3 encoders You seem to be talking about the state more than a decade back. How's that relevant to 2019? BTW, there is no native MP3 encoder.