Tangentially, 50% of effort goes into assembling long complex CLI commands, and 50% fighting with escaping for the shell. Adding text to a video adds it’s own escaping hell for the text. Has anyone found a bulletproof recipe for calling ffmpeg with many args (filters) from python? Use r-strings? Heredocs?
FFmpeg 8.0
171–180 of 207 posts
Re: FFmpeg 8.0
#172Has anyone made a good GUI frontend for accessing the various features of FFMPEG? Sometimes you just want to remux a video without doing any transcoding, or join several video and audio streams together (same codecs).
Re: FFmpeg 8.0
#173Earlier quoted context omitted.
> tar -cf archive.tar.gz foo bar This will create an uncompressed .tar with the wrong name. You need a z option to specify gzip.
Apparently this is now automatically determined by the file name, but I still habitually add the flag. 30 years of muscle memory is hard to break!
Re: FFmpeg 8.0
#174Tangentially, 50% of effort goes into assembling long complex CLI commands, and 50% fighting with escaping for the shell. Adding text to a video adds it’s own escaping hell for the text. Has anyone found a bulletproof recipe for calling ffmpeg with many args (filters) from python? Use r-strings? Heredocs?
Re: FFmpeg 8.0
#175Earlier quoted context omitted.
nope, that would be handling tar balls ffmpeg right after
Personally I never understood the problem with tar balls. The only options you ever need are tar -x, tar -c (x for extract and c for create). tar -l if you wanna list, l for list. That's really it, -v for verbose just like every other tool if you wish. Examples: tar -c project | gzip > backup.tar.gz cat backup.tar.gz | gunzip | tar -l cat backup.tar.gz | gunzip | tar -x You never need anything else for the 99% case.
gzip -dc backup.tar.gz | tar -x
You can skip a step in your pipeline.Re: FFmpeg 8.0
#176Some Netflix devs are going to have a busy sprint
> Note that these releases are intended for distributors and system integrators. Users that wish to compile from source themselves are strongly encouraged to consider using the development branch
Re: FFmpeg 8.0
#177Earlier quoted context omitted.
About 10-ish years ago, my then employer was talking to some other company about helping them get their software to release. They had what they believed to be a proprietary compression system that would compress and playback 4k video with no loss in quality. They wouldn't let us look into the actual codecs or compression, they just wanted us to build a front-end for it. I got to digging and realized they were just re…
One more taking part in a time-honoured tradition of taking someone else's thing, adding your own dipping mustard (if even that), and calling it your own. A new chatbot? Another ChatGPT wrapper. A new Linux Distro. Another Arch with a preinstalled desktop environment. A new video downloader? It's yt-dlp with a GUI. If they were just honest from the get-go, it'd be fine, but some people aren't.
If it were just individuals doing it, maybe it would've been somewhat digestible. But it's a pity that sometimes even trillion-dollar companies do it.
Pre-LLM days, the doers were atleast aware of their copy/clone/wrapper, but now it's happening unintentionally when LLMs give out modified versions of someone else's code without binding to its license, because AFAIK LLMs do not automatically add licensing details of libraries used inside their outputted code, or do they?
Re: FFmpeg 8.0
#178Re: FFmpeg 8.0
#179August 23nd