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! :)
Join @donwatkins on a journey to preserve priceless family recordings with Linux! 📼 Explore the power of FFmpeg for media conversion and learn how open-source solutions empower users to overcome technical challenges.
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!)