the point is, there is no way i would have been able to figure out the command line myself. it still trips up every now and then (at which point im often screwed), but i can atleast finally use the tool.
DO use ChatGPT to help you to write ffmpeg commands, but at least has some basic understanding of how ffmpeg works -- especially the fact that it works like a pipeline so the order of the options absolutely matters.
And ChatGPT often throw lots of unnecessary options (sometimes even do harm), so do actually investigate what each switch is supposed to do (ChatGPT can help with that too) if you're going to use the generated command for something semi-serious.
If possible, try to keep the switches as few as possible and avoid exotic flags. But do pay attention to pixel format and colorspace options to make your video as compatible as possible. It's very easy to mess things up for doing even seemingly simple tasks (like converting static images to slideshow etc.)
Had to try and fix a bug with that script and it took me hours just to get some understanding of it.
Makes me wonder if video processing is just that complicated, or if someone could make some sort of simpler tool for this
But if you're documenting it right then you'll still need a paragraph explaining what every checkbox does...
Does this "Vulkan based encoding" mean we'll be able to get the best of both worlds? A 'pure' software encoder, but with the massive parallelism of a GPU?
If so I'd be extremely excited. Getting to shrink my DVD and Blu Ray rip collection down by moving it all to AV1 at rest would massively reduce my storage cost
Unlikely. This is just a generic API to the same GPU backends; so you will not see more quality than nvenc.
SVT-AV1 is pretty fast these days, Almost every minor release added last year added an additional 10-50% speedup. So if you haven't checked it out for a year or so, you'll be amazed by how much quicker it has gotten. Just saying.
I don't think NVENC supports this workflow, which is a big reason it's not suitable for quality encoding.
I am surprised we got LC-EVC in. Not sure about adoption outside TV but it is a very nice technology that is hyper efficient. ( This is not related to the MPEG 5 EVC )
>you can use LC-EVC with H.264, HEVC or AV1 base layers.
It can be used with VVC as well. That is what the Brazilian TV 3.0 has adopted. On the surface this gives an additional 10-20% BD-Rate. Can't wait t have encoder to test this out.
I pushed quite a lot on that, tbh, because of the Brazil adoption.
Now I can just highlight a file and:
- covert audio to mp3
- convert gif to video
- convert to mp4
- convert video to gif
- convert video to webp
- convert video to hevc mkv
- convert video to mp3
- convert video to mp3 with artwork
- convert video to thumbnail
- trim video beginning
- trim video end
- drop video audio
- speed up video
- speed up video fragment
- resize video
That's impressive, glad to see such an incredibly important project healthy!
>>> Bandwidth Restricted
The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly. Details:
451 Actioning this file would cause "jbkempf.com//blog/2024/ffmpeg-7.1.0/" to exceed the per-day file actions limit of 160000 actions, try again later >>>
I only found an open ffmpeg patchset for cinema DNG, blackmagic raw has no support anywhere outside of the manufacturer's SDK and Apple ProRes RAW has only Apple's SDK and a proprietary reimplementation by a czech developer. The current ffmpeg release supports afaict neither of these formats.
I thought about writing my own decoder for ProRes RAW but as I've never written a codec before, I haven't had much success ^^
And the LTS is maintained at least as long as the next LTS is, and should be at least 3 years.
So, for example, we support 5.1 and 7.1 as LTS. And we support 6.1 and 4.4 as best effort.
In case you're curious, a few more details about this application:
- We're taking videos outdoors, so depth is longer range than usual (0m-80m). Ideally we'd love to store depth maps as single channel fp16 alongside the RGB stream. It's common in other application to store depth as int16 (e.g. as 16-bit greyscale PNGs), but if units are mm, you get overflow at 65 meters.
- In addition to depth maps, it would be interesting if we could store segmentation maps (single-channel int16), stereo footage (maybe MV-HEVC could be useful for this if it lands in ffmpeg one day), and various camera metadata (e.g. per-video epipolar matrices)
- I've briefly looked into single-channel 12-bit h264 for this application, but if the standard provides for something less hacky, that's even better! :)
There's a brief overview of the data we collected on the project page: https://google-research-datasets.github.io/sanpo_dataset/ Check out the animation under "Dataset" for an executive summary of the various video streams.
