191–200 of 226 posts
Earlier quoted context omitted.
I don't know much, but isn't Audacity a thing?
Audacity is a great GUI for working with audio files. I would think it has a way to export a graph of the wave that it shows you when you open up an audio file. You can install an FFMPEG plugin for Audacity if you need broader support of audio formats (either import or export).
As a little side project, I've been trying to automate creation of those "1 second everyday" style videos [1], and used FFmpeg to achieve this. For things like trimming and concatenating videos, one thing that surprised me was that it was slower than using a tool like ScreenFlow. Note, we're talking about hundreds of gigabytes worth of 4K videos. slower = When I say slower, I mean, if I manually performed the same op…
In case you didn't know, you can use FFmpeg to convert Audible aax files to DRM-free MP3/AAC/whatever [0] (scroll down for FFmpeg instructions). This is useful if for some reason you want to archive them or play them in an app that doesn't constantly change its UI and bombard you with ads. [0]: https://www.kylepiira.com/2019/05/12/how-to-break-audible-dr...
If you're converting .aax files you should consider using .m4b as the output, since it preserves chapters and remembers your last listened timestamp [0]: > Audiobook and podcast files, which also contain metadata including chapter markers, images, and hyperlinks, can use the extension .m4a, but more commonly use the .m4b extension. An .m4a audio file cannot "bookmark" (remember the last listening spot), whereas .m4b…
This claim seems to originate from the fact that the old iPods only remembered the last played position on M4B files. But that's entirely a player convention, not a file format convention.
Earlier quoted context omitted.
- You don't trust so much complex logic, taking untrusted input, written in C and want to rewrite it in Rust. - You want to code it all again using an API that doesn't expect to get its input from a blocking read() function. - ... I think the main reason there isn't any alternative is that it supports soooo many formats that the task seems impossible to anybody thinking about it.
> - You want to code it all again using an API that doesn't expect to get its input from a blocking read() function. In which real world situation/scenario is this a problem? It is hard to think of one, but I am probably missing something? In any case, if that was a real show-stopper, it would probably be much wiser to go with a fork that would modify that one thing, instead of re-writing the whole project.
a) you're probably going to want to control the number of simultaneous streams to a low enough number that you could just fork
b) the responsible thing to do when decoding streams with ffmpeg is to disable all formats except your whitelisted format, but still sandbox the heck out of it, because there's been a lot of CVEs where a crafted input allows remote code execution
Sandboxing is going to be much more complete if the ffmpeg process is only dealing with one input fd, one output fd (maybe an error reportint fd), and no network or filesystem access --- you don't want a decoder error to influence media you're encoding/decoding for another user.
Earlier quoted context omitted.
If you look at it as more of a "composable" interface (as the sibling poster suggested), it makes a lot more sense. No one is going to type out this one-liner from scratch, or have an easy time understanding what it means by reading it, but as it's made up of a series of smaller, more easily understood commands, in a shell or Python script it could be vastly more legible and, dare I say it, usable. This is also the r…
The problem with calling ffmpeg multiple times in a script is you often waste compute time. If you can manage to cobble together a single command (as illegible as that may be), you might be able to do what you're looking to do in far less time
In the process I was reminded of how important Intellectual Property is in our field.
I dowloaded a video from youtube [0] and learned that the video is in a WEBM container for certain types of video compression formats (VP8/9 + another one) as well as vorbis/opus audio. It turns out that to get the best quality on the Apple TV, I should encode to HEVC (H265) video and I guess aac audio.
There’s some sort of history behind this divide. A pain in the neck for people who want to toy around with video, but huge decisions for these companies in choosing the formats they use to move these bits around.
So I can use ffmpeg to re-encode into the new format, and I can play it on my apple devices if the file is local, but I can’t shoot it via UDP to the TV. When VLC (app on apple tv) is listening on a port for UDP I only get choppy audio:
Doing this on the sending side doesn’t seem to work:
ffmpeg \
-re -i video_stream_ready.mp4 \
-c:v copy -c:a copy \
-f mpegts udp:$APPLETVIP:2300
Being stuck at home makes me want to make something artsy that could be fun to look at through the day.
I've been working on a web-based video editor for app features: https://glitter.now.sh/ and i've had tons of fun tweaking FFmpeg.
My only wish would be that the documentation would include video samples for the example commands (I'd love to help with this).
Earlier quoted context omitted.
I actually made my own CLI frontend just because I didn't want to try and memorize ffmpeg options to do the simple things that I want to do most of the time. Now I can just do `--h264 -s X -e Y` to do a h.264 encode from X timecode to Y timecode.
Is -s X -e Y really much easier than -ss X -t $((Y-X)) ? Every couple of years worth of not using an option I need to look it up again. But it's usually not too hard.
Compare:
frontend -s 05:28:38.667 -e 05:28:58.767 input.ts
ffmpeg -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 1
ffmpeg -y -ss 05:28:28.667 -i input.ts -ss 10 -t 20.100 -pass 2Earlier quoted context omitted.
I feel the same about imagemagick. Oh the things you can do with just curl, bash, imagemagick... And gnuplot if you're rich.
Why do you need to be rich for gnuplot? Aren't gnu things generally GPL?
On many systems I work with and have to debug, gnuplot won't be already installed (and won't be installable on a system not connected to the Internet) so 'rich' would be 'flush in packages with a full system available'.
Sometimes, even imagemagick isn't there, but rsvg-convert is, you can still do amazing things with just bash+curl+svg...