FFmpeg is wonderful software. Growing up as a Windows user in the early 2000s, devices were far more picky than they are today about which video codecs they'd support. It was a non-trivial task as an 11yo trying to convert DivX .avis into an MP4 my old iPod Video could understand. Discovering ffmpeg and finding that someone was offering for free what I otherwise could only find under mountains of crappy shareware was a real watershed moment.<p>20 years later it's still a goto. Great tool.
The greatest addition to FFmpeg in the recent past was the addition of large language models translating my "ffmpeg command to mix audio file onto video file" into actually executable FFmpeg commands.<p>Being cheeky of course here. FFmpeg is great. An AI assistant was what I needed to execute my ~12 FFmpeg commands per year though, with ease and speed.
There's a low-hanging fruit that I think would make ffmpeg more helpful for regular people.<p>There's a million terrible websites that offer file conversion services. They're ad-ridden, with god-knows-what privacy/security postures. There's little reason for users to need to upload their files to a third-party when they can do it locally. But getting them to download fiddly technical software is tough - and they're right to mistrust it.<p>So, there's a WASM version of ffmpeg, already working and hosted at Netlify [1]. It downloads the WASM bundle to your browser and you can run conversions/transformations as you wish, in your browser. Sandboxed and pretty performant too!<p>If this tool a) was updated regularly b) had a nicer, non-CLI UI for everyday users and c) was available at an easily-Googlable domain name - it would solve all the problems I mentioned above.<p>[1]: <a href="https://ffmpegwasm.netlify.app/" rel="nofollow">https://ffmpegwasm.netlify.app/</a>
So I'm trying to build ffmpeg via vcpkg today, and it turned out multiple of its dependencies are transitively depending on liblzma, but the downloading of liblzma source has been disabled by GitHub in light of the recent xz backdoor.
rust-ffmpeg already seems to have support for 7.0: <a href="https://github.com/zmwangx/rust-ffmpeg/pull/178">https://github.com/zmwangx/rust-ffmpeg/pull/178</a>
I have been using the xstack filter for several years now.<p>What I do is take several diverse short video segments, like 100, concatenate them into 4 segments (example 23+24+26+27 since they have diverse lengths) and then xstack them into a 2-by-2 mosaic video.<p>Before, I was doing it in a single stage, but now, after some advice, I do it in 5 stages: 4 concatenate stages and 1 xstack stage.<p>I have not profiled/timed it so see which is faster, but it works pretty well, although I often have a lot of different weird warnings.
Meanwhile, the default ffmpeg is at version 4.4.4 [1] on MacPorts. There's ffmpeg6, which is at version 6.1.1. [2]<p>[1]: <a href="https://ports.macports.org/port/ffmpeg/" rel="nofollow">https://ports.macports.org/port/ffmpeg/</a><p>[2]: <a href="https://ports.macports.org/port/ffmpeg6/" rel="nofollow">https://ports.macports.org/port/ffmpeg6/</a>
ffmpeg is such a joy to use, once you make it over the very steep learning curve.<p>I'm making some youtube videos where I play through Demon's Souls flipping a coin to decide to equip items or not, and I wanted to have an onscreen coin flip animation and sound effect. With some effort, I created a transparent set of frames for the animation. Then with ffmpeg's filter_complex I was able to add the image sequence as a video stream, overlay it over the original video, and add a sound effect. That's on top of the existing subtitles, audio channel merging, and video resizing/compression. All in a single (long!) ffmpeg cli command.<p>ffmpeg is one of the true wonders of FOSS.
Surprised even MPEG-5 EVC made it. Unfortunately the VVC Decoder didn't quite make it ( Edit : Officially ) . I guess we will have to wait until version 7.1. Still waiting for x266.
IAMF/ambisonics looks so cool, but it's so unclear how is plebes would play around with it & explore it's use.<p>Crazy how much DirectX (DXVA) support got added.
Changelog:<p>- DXV DXT1 encoder<p>- LEAD MCMP decoder<p>- EVC decoding using external library libxevd<p>- EVC encoding using external library libxeve<p>- QOA decoder and demuxer<p>- aap filter<p>- demuxing, decoding, filtering, encoding, and muxing in the<p>- ffmpeg CLI now all run in parallel<p>- enable gdigrab device to grab a window using the hwnd=HANDLER syntax<p>- IAMF raw demuxer and muxer<p>- D3D12VA hardware accelerated H264, HEVC, VP9, AV1, MPEG-2 and VC1 decoding<p>- tiltandshift filter<p>- qrencode filter and qrencodesrc source<p>- quirc filter<p>- lavu/eval: introduce randomi() function in expressions<p>- VVC decoder (experimental)<p>- fsync filter<p>- Raw Captions with Time (RCWT) closed caption muxer<p>- ffmpeg CLI -bsf option may now be used for input as well as output<p>- ffmpeg CLI options may now be used as -/opt <path>, which is equivalent<p>- to -opt <contents of file <path>><p>- showinfo bitstream filter<p>- a C11-compliant compiler is now required; note that this requirement<p>- will be bumped to C17 in the near future, so consider updating your<p>- build environment if it lacks C17 support<p>- Change the default bitrate control method from VBR to CQP for QSV encoders.<p>- removed deprecated ffmpeg CLI options -psnr and -map_channel<p>- DVD-Video demuxer, powered by libdvdnav and libdvdread<p>- ffprobe -show_stream_groups option<p>- ffprobe (with -export_side_data film_grain) now prints film grain metadata<p>- AEA muxer<p>- ffmpeg CLI loopback decoders<p>- Support PacketTypeMetadata of PacketType in enhanced flv format<p>- ffplay with hwaccel decoding support (depends on vulkan renderer via libplacebo)<p>- dnn filter libtorch backend<p>- Android content URIs protocol<p>- AOMedia Film Grain Synthesis 1 (AFGS1)<p>- RISC-V optimizations for AAC, FLAC, JPEG-2000, LPC, RV4.0, SVQ, VC1, VP8, and more<p>- Loongarch optimizations for HEVC decoding<p>- Important AArch64 optimizations for HEVC<p>- IAMF support inside MP4/ISOBMFF<p>- Support for HEIF/AVIF still images and tiled still images<p>- Dolby Vision profile 10 support in AV1<p>- Support for Ambient Viewing Environment metadata in MP4/ISOBMFF<p>- HDR10 metadata passthrough when encoding with libx264, libx265, and libsvtav1
Moving to c11 is bad, really bad. This is a dangerous road to follow, don't trust ISO on that matter which is literaly doing planned obsolescence on 5-10 years cycle with computer language feature creeps. C has to be simplified then going towards eternal stability, not the other way around. I suspect some toxic/scammy people got in (or brain washed).<p>I think I did updated my code with the new channel layout API. But it was a year ago at least. There is another API which is supposed to change, the seeking API but I wonder if it is now stable enough to be used.