Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

phoronix.com

Post reply on HN
Print view View original

61–70 of 186 posts

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#61

Post by keehun »

seeknotfind wrote: post #59
kevincox wrote: post #46

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…

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.

The parent comment referred to "keyframes" instead of just "frames". Keyframes—unlike normal frames—encode the full image. That is done in case the "delta" you mentioned could be dropped in a stream ending up with strange artifacts in the resulting video output. Keyframes are where the codec gets to press "reset".

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#63

Post by ThrowawayTestr »

m3kw9 wrote: post #17
dylan604 wrote: post #15

Earlier quoted context omitted.

FFMPEG does so much more than just video encoding. I use ffmpeg all day every day, and only a fraction of the time do I actually make a video.

Like what do you do?

I use ffmpeg everytime I download a YouTube video.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#65

Post by kevincox »

Hello71 wrote: post #56
kevincox wrote: post #46

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…

your idea also doesn't work with live streaming, and may also not work with inter-frame filters (depending on implementation). nonetheless, this exists already with those limitations: av1an and I believe vapoursynth work more or less the way you describe, except you don't actually need to load every chunk into memory, only the current frames. as I understand, this isn't a major priority for mainstream encoding pipeli…

It can work with live streaming, you just need to add N keyframes of latency. With low-latency livestreaming keyframes are often close together anyways so adding say 4s of latency to get 4x encoding speed may be a good tradeoff.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#66

Post by tetris11 »

naikrovek wrote: post #57
brucethemoose2 wrote: post #8

Meanwhile, I've been enjoying threaded filter processing in VapourSynth for nearly a decade. Not that this isn't great. Its fantastic. But TBH its not really going to change my workflow of VapourSynth preprocessing + av1an encoding for "quality" video encodes.

I don't understand why you would want to piggyback on this story to say this. are people just itching for reasons to dive into show & tell or to wax poetic about how they have solved the problem for years ? I really don't understand people at all, because I don't understand why people do this. and I'm sure I've done it, too.

There is hype for FEAT. People who have achieved similar FEAT perk up their heads but say nothing.

Hype for FEAT is beyond sensibility. People with similar FEAT are bristled by this and wish that their projects received even a fraction of FEAT's hype.

I think it's normal.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#67

Post by bagels »

kevincox wrote: post #65
Hello71 wrote: post #56

Earlier quoted context omitted.

your idea also doesn't work with live streaming, and may also not work with inter-frame filters (depending on implementation). nonetheless, this exists already with those limitations: av1an and I believe vapoursynth work more or less the way you describe, except you don't actually need to load every chunk into memory, only the current frames. as I understand, this isn't a major priority for mainstream encoding pipeli…

It can work with live streaming, you just need to add N keyframes of latency. With low-latency livestreaming keyframes are often close together anyways so adding say 4s of latency to get 4x encoding speed may be a good tradeoff.

4s of latency is not acceptable for applications like live chat

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#68

Post by seeknotfind »

keehun wrote: post #61
seeknotfind wrote: post #59

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.

The parent comment referred to "keyframes" instead of just "frames". Keyframes—unlike normal frames—encode the full image. That is done in case the "delta" you mentioned could be dropped in a stream ending up with strange artifacts in the resulting video output. Keyframes are where the codec gets to press "reset".

Oh right. For non realtime, if you're not IO bound, this is better. Though I'd wonder how portable the codec code itself would be.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#69

Post by rokweom »

kevincox wrote: post #46

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…

There's already software that does this: https://github.com/master-of-zen/Av1an Encoding this way should indeed improve quality slightly. Whether that is actually noticeable/measurable... I'm not sure.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#70

Post by kevincox »

bagels wrote: post #67
kevincox wrote: post #65

Earlier quoted context omitted.

It can work with live streaming, you just need to add N keyframes of latency. With low-latency livestreaming keyframes are often close together anyways so adding say 4s of latency to get 4x encoding speed may be a good tradeoff.

4s of latency is not acceptable for applications like live chat

As I said, "may be". "Live" varies hugely with different use cases. Sporting events are often broadcast live with 10s of seconds of latency. But yes, if you are talking to a chat in real-time a few seconds can make a huge difference.
Post reply on HN