61–70 of 73 posts
> Oh there's a new version of ffmpeg, I'll just quickly build it from source... no I can't wait I'll download the binary https://www.youtube.com/watch?v=9kaIXkImCAM
Earlier quoted context omitted.
It's a lower-level component in so much stuff we're not even aware of.
FFmpeg is a prime single-block-everything-is-built-on xkcd example.
Sometimes I wonder if we can vanish one single project out of existence instantly, which one would cause the most chaos.
Earlier quoted context omitted.
FFmpeg is a prime single-block-everything-is-built-on xkcd example.
> prime single-block-everything-is-built-on xkcd Sometimes I wonder if we can vanish one single project out of existence instantly, which one would cause the most chaos.
https://interoperable-europe.ec.europa.eu/sites/default/file...
https://connollydavid.github.io/pgs-release/
such a fun project!
> Oh there's a new version of ffmpeg, I'll just quickly build it from source... no I can't wait I'll download the binary https://www.youtube.com/watch?v=9kaIXkImCAM
For anyone vaguely familiar with ffmpeg, don't sleep on this video. Quite funny, and everything from `yadif` (which I dealt with today!) to mkvtoolnix to "But then it will explode if you have an apostrophe in your file name. Because it doesn't understand that."
Earlier quoted context omitted.
We use JXS when latency is critical. Most h24/265 decodes will have a 10 frame glass-glass delay, JXS drops that to 3 or 4, at a cost of bandwidth (our UHD jxs streams are 1.5gbit rather than 200mbit for hevc)
That's pretty depressing to read. x264 was handling the encoding side with sub-frame latency 15 years ago, and sub-frame decoding is significantly easier. "with –tune zerolatency, single-frame VBV, and intra refresh, x264 can achieve end-to-end latency (not including transport) of under 10 milliseconds for an 800×600 video stream" But for some reason you can't make use of that and have to burn bandwidth instead.
https://www.obe.tv/how-to-lie-about-latency/
Bandwidth is cheap -- basically free, especially at this bitrate.
Earlier quoted context omitted.
It's a sibling to curl in that way
Big difference for ffmpeg especially (but I imagine for curl too): it's not just one guy in Nebraska. Seems to have a very healthy community of devs involved in it.
Earlier quoted context omitted.
It's a lower-level component in so much stuff we're not even aware of.
Yep. Which is a great architecture IMO. Simple, performant and flexible: choose 3
Copy data to or from a hw surface. At least one of dst/src must have an AVHWFramesContext attached.
int av_hwframe_transfer_data(AVFrame *dst, const AVFrame *src, int flags);
That said, when it works, it's really great
Earlier quoted context omitted.
That's pretty depressing to read. x264 was handling the encoding side with sub-frame latency 15 years ago, and sub-frame decoding is significantly easier. "with –tune zerolatency, single-frame VBV, and intra refresh, x264 can achieve end-to-end latency (not including transport) of under 10 milliseconds for an 800×600 video stream" But for some reason you can't make use of that and have to burn bandwidth instead.
A small part of the end-to-end process https://www.obe.tv/how-to-lie-about-latency/ Bandwidth is cheap -- basically free, especially at this bitrate.
It's not that you should have gotten a magical 10ms latency glass to glass, it's that you should have been able to get 4 frames latency on h.264. But something prevented that, so I'm sad about it.
(And if you say the bandwidth was fine in your situation I won't argue, but using more than a gigabit extra is not usually thought of as free.)