Is anyone aware of ways to control #ffplay programmatically in any form, without having to focus the window and having to emulate keyboard/mouse bindings in it?
ffplay is amazing, light, fast, and it’s a player that comes with any #ffmpeg installation.
#Platypush supports media players such as VLC, mpv, mplayer, omxplayer and gstreamer, but they all come with their bags of issues - the VLC libraries seem to break too often on Wayland, mpv has too many API breaking changes across versions and controlling it only works if the version of the library and the player are carefully aligned, mplayer is an unmaintained dumpster fire with a messy control API, working with gstreamer in Python requires the user to install the whole fat GLib luggage and MBs of plugins, and omxplayer is basically dead.
ffplay would be my favourite pick for a portable and lightweight default media player. But the fact that it apparently can’t be controlled in non-interactive ways really puzzles me.
It is absolutely mind bending how many options ffmpeg has. I've been trying to convince it to use the old Radeon 2600 Pro graphics hardware acceleration. No luck finding the magic command yet! :)
Introducing Friction 0.9.6 Beta 1. This release includes several changes to the user interface and some additional new features. We are now in feature freeze, please report any regressions etc.
"ARM64 NEON optimizations:- Several time-consuming C functions have been optimized for the targeted platform - aarch64. The overall performance increased by around 20%. SVE/SVE2 optimizations"
Thanks, y'all! I love it when codebases start coding to ARM64 NEON! #FFMPEG#FFMPEG7
To all those #FFMPEG v7 programmers/users out there: I am getting "[hevc @ 0x11ce08420] Unsupported film grain parameters. Ignoring film grain." on several of my 4k BluRay UHD rips.
I found the error in the FFMPEG code, but cannot tell if it is just telling me it THINKS there should be film grain in the stream, but it can't decode which it is or if there truly is a metadata error in my rip...
The code is in the reply as my server is limited to 400 chars.
This is driving me batty. It wasn't in #FFMPEG v6...and I know the log file for x265 v3.6 says: "Film-Grain characteristics as a SEI message to support Film Grain Synthesis(FGS)" but surely if the BluRay didn't have the SEI msg this shouldn't be warning me...and if it did, and the FGS wasn't recognized, this is a bug in FFMPEG, right?
Is it just me or is #FFMPEG v7 way faster (on #ARM64 at least) when doing multiple things at once? (ie: #nlmeans noise reduction, #crop, then #x265)
I mean these used to take hours and hours on several of my Agatha Christie files (which need noise reduction, crop and encoding). These fly through now at about 30% time reduction per file. Not to mention about 15% smaller size (thanks x265 3.6.x update!)
#FFmpeg 7.0 "Dijkstra" is out. One of the most useful frameworks that's still chugging along today. If you decode video in any format, you know probably know the name.
It has a native VVC decoder, IAMF support and multi-threaded CLI tool alongside hundreds of other improvements and new codecs, features, APIs and bugfixes.
Some people have an odd definition of professionalism. That it's "professional" for a $3 trillion corp to ask people for free labor, but unprofessional for people to ask them to fund them for the work they do.