111–120 of 186 posts
Earlier quoted context omitted.
...in this case, multi-threading. In other cases; AI workflows that others commercialize, a new type system in a language that already exists in another, a new sampling algorithm that has already existed by another name for decades, a permaculture innovation that farmers have been using for aeons, the list goes on...
just say "feature". language is for communicating. don't impede that communication by using unnecessary terms.
Earlier quoted context omitted.
Like what do you do?
One can use it instead of cat to display text files. Easy syntax to remember. ffmpeg -v quiet -f data -i file.txt -map 0:0 -c text -f data -
dd if=./file.txt
I don't know anything about ffmpeg codebase, but I just wonder... how would I go about doing this _slowly_ without completely doing a giant commit that changes everything? The presentation says it's 700 commits. Was that a separate branch? Or was it slowly merged back to the project? Well I can look at github I guess
It seems ffmpeg uses the mailing list patch way of doing "PRs", which is... well it is what it is. It doesn't help me understand the process unless I just go through all the mailing list archives, I guess.
I've always wondered if better multi-core performance can come from processing different keyframe segments separately. IIUC all current encoders that support parallelism work by multiple threads working on the same frame at the same time. Often times the frame is split into regions and each thread focuses on a specific region of the frame. This approach can have a (usually small) quality/efficiency cost and requires…
IIUC - International Islamic University Chittagong?
I've always wondered if better multi-core performance can come from processing different keyframe segments separately. IIUC all current encoders that support parallelism work by multiple threads working on the same frame at the same time. Often times the frame is split into regions and each thread focuses on a specific region of the frame. This approach can have a (usually small) quality/efficiency cost and requires…
IIUC - International Islamic University Chittagong?
Earlier quoted context omitted.
Latency is still valuable. For example YouTube (which IIRC uses ffmpeg) often takes hours to do transcodes. This is likely somewhat due to scheduling but assuming that they can get the same result doing 4x threads for 1/4 of the time they would prefer that as each job finishes faster. The only real question is at what efficiency cost the latency benefit stops being worth it.
YouTube does not use ffmpeg, at the scale at which they operate it would be too slow / expensive. They use custom hardware just for encoding. fyi they have to transcode over 500h of videos per minute. So multiple that by all the formats they support. They operate at an insane scale, Netflix looks like a garage project for comparison.
If I'm operating a cloud service like Netflix, then I'm already running thousands of ffmpeg processes on each machine. In other words, it's already a multi-core job.
Earlier quoted context omitted.
They'll be doing VBR encodes to DASH, HLS & (I guess still) MSS which covers the resolutions & formats... DRM will be what prevents high res content from working on some "less-trusted" platforms so the same encodes should work. (Plus a couple more "legacy" encodes with PIFF instead of CENC for ancient devices, probably.) New tech advances, sure, they probably do re-encode everything sometimes - even knocking a few MB…
Why bring up assumptions/suppositions about Netflix's encoding process? Their tech blog and tech presentations discuss many of the requirements and steps involved for encoding source media to stream to all the devices that Netflix supports. The Netflix tech blog: https://netflixtechblog.com/ or https://netflixtechblog.medium.com/ Netflix seems to use AWS CPU+GPU for encoding, whereas YouTube has gone to the expense o…
This is overrated - of course that's how you do it, what else would you do?
> Mean-squared-error (MSE), typically used for encoder decisions, is a number that doesn’t always correlate very nicely with human perception.
Academics, the reference MPEG encoder, and old proprietary encoder vendors like On2 VP9 did make decisions this way because their customers didn't know what they wanted. But people who care about quality, i.e. anime and movie pirate college students with a lot of free time, didn't.
It looks like they've run x264 in an unnatural mode to get an improvement here, because the default "constant ratefactor" and "psy-rd" always behaved like this.
Earlier quoted context omitted.
YouTube does not use ffmpeg, at the scale at which they operate it would be too slow / expensive. They use custom hardware just for encoding. fyi they have to transcode over 500h of videos per minute. So multiple that by all the formats they support. They operate at an insane scale, Netflix looks like a garage project for comparison.
There's still decoding. If a service claims to support all kinds of weird formats (like a MOV or AVI from the 90s) that means ffmpeg is running.
For encoding, recently, they've built their own ASIC to deal with H264 and VP9 encoding (for 7-33x faster encoding compared to CPU-only): https://arstechnica.com/gadgets/2021/04/youtube-is-now-build...
Earlier quoted context omitted.
Video codecs often encode the delta from the previous frame, and because this delta is often small, it's efficient to do it this way. If each thread needed to process the frame separately, you would need to make significant changes to the codec, and I hypothesize it would cause the video stream to be bigger in size.
Isn't that delta partially based on the last keyframe? I guess it would be codec dependent, but my understanding is that keyframes are like a synchronization mechanism where the decoder catches up to where it should be in time.
I'd assume if each thread is working on its own key frame, it would be difficult to make b-frames work? Live content also probably makes it hard.