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

121–130 of 186 posts

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

#121

Post by bmurphy1976 »

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…

This definitely happens. This is how videos uploaded to Facebook or YouTube become available so quickly. The video is split into chunks based on key frame, the chunks are farmed out to a cluster of servers and encoded in parallel, and the outputs are then re-assembled into the final file.

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

#122

Post by Rebelgecko »

whalesalad wrote: post #41
nerpderp82 wrote: post #34

Earlier quoted context omitted.

https://www.youtube.com/watch?v=9kaIXkImCAM

I'm glad we've reached a point where there is quality parody content online for our industry.

Check out Krazam. I quote their Microservices video on a regular basis (https://youtu.be/y8OnoxKotPQ)

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

#123

Post by jasomill »

andoma wrote: post #26
m3kw9 wrote: post #17

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 -

That doesn't work[1], but

  ffmpeg -v quiet -f data -i file.txt -map 0:0 -c copy -f data -
does.

[1] “Encoder 'text' specified, but only '-codec copy' supported for data streams”

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

#124

Post by slhck »

astrange wrote: post #118
canucker2016 wrote: post #78

Earlier quoted context omitted.

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…

> Their dynamic optimization encoding framework - allocating more bits for complex scenes and fewer bits for simpler, quieter scenes: https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v ... and https://netflixtechblog.com/optimized-shot-based-encodes-now ... 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 numbe…

> This is overrated - of course that's how you do it, what else would you do?

That's not what has been done previously for adaptive streaming. I guess you are referring to what encoding modes like CRF do for an individual, entire file? Or where else has this kind of approach been shown before?

In the early days of streaming you would've done constant bitrate for MPEG-TS, even adding zero bytes to pad "easy" scenes. Later you'd have selected 2-pass ABR with some VBV bitrate constraints to not mess up the decoding buffer. At the time, YouTube did something where they tried to predict the CRF they'd need to achieve a certain (average) bitrate target (can't find the reference anymore). With per-title encoding (which was also popularized by Netflix) you could change the target bitrates for an entire title based on a previous complexity analysis. It took quite some time for other players in the field to also hop on the per-title encoding train.

Going to a per-scene/per-shot level is the novely here, and exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE.

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

#125

Post by jamal-kumar »

rokweom wrote: post #69
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.

I've messed around with av1an. Keep in mind the software used for scene chunking, L-SMASH, is only documented in Japanese [1], but it does the trick pretty well as long as you're not messing with huge dimensions like HD VR where you have video dimensions that do stuff like crash quicktime on a mac

[1] http://l-smash.github.io/l-smash/

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

#126

Post by jasomill »

fransje26 wrote: post #112
andoma wrote: post #26

Earlier quoted context omitted.

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 -

I use dd for that. dd if=./file.txt Can you also format your drive with ffmpeg? I'm looking for a more versatile dd replacement..

It can't create partition tables or filesystems, so no, but

  ffmpeg -f data -i /dev/zero -map 0:0 -c copy -f data - > /dev/sda
is roughly equivalent to to

  dd status=progress if=/dev/zero of=/dev/sda

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

#127

Post by astrange »

slhck wrote: post #124
astrange wrote: post #118

Earlier quoted context omitted.

> Their dynamic optimization encoding framework - allocating more bits for complex scenes and fewer bits for simpler, quieter scenes: https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v ... and https://netflixtechblog.com/optimized-shot-based-encodes-now ... 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 numbe…

> This is overrated - of course that's how you do it, what else would you do? That's not what has been done previously for adaptive streaming. I guess you are referring to what encoding modes like CRF do for an individual, entire file? Or where else has this kind of approach been shown before? In the early days of streaming you would've done constant bitrate for MPEG-TS, even adding zero bytes to pad "easy" scenes. L…

> exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE.

This is unnecessary if the encoder is well-written. It's like how some people used to run multipass encoders 3 or 4 times just in case the result got better. You only need one analysis pass to find the optimal quality at a bitrate.

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

#128

Post by slhck »

astrange wrote: post #127
slhck wrote: post #124

Earlier quoted context omitted.

> This is overrated - of course that's how you do it, what else would you do? That's not what has been done previously for adaptive streaming. I guess you are referring to what encoding modes like CRF do for an individual, entire file? Or where else has this kind of approach been shown before? In the early days of streaming you would've done constant bitrate for MPEG-TS, even adding zero bytes to pad "easy" scenes. L…

> exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE. This is unnecessary if the encoder is well-written. It's like how some people used to run multipass encoders 3 or 4 times just in case the result got better. You only need one analysis pass to find the optimal quality at a bitrate.

Sure, the whole point of CRF is to set a quality target and forget about it, or, with ABR, to be as good as you can with an average bitrate target (under constraints). But you can't do that across resolutions, e.g. do you pick the higher bitrate 360p version, or the lower bitrate 480p one, considering both coding artifacts and upscaling degradation?

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

#129

Post by jasomill »

yoz wrote: post #50
andoma wrote: post #26

Earlier quoted context omitted.

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 -

can I use ffmpeg to embed a gif in a Hacker News comment, because I want that so much right now

No, but you can use ffmpeg to create a GIF from ASCII art embedded in a Hacker News comment:

  $ ffmpeg -v quiet -codecs | egrep -i 'gif|ascii'
   D.V.L. ansi                 ASCII/ANSI art
   DEV..S gif                  CompuServe GIF (Graphics Interchange Format)
(“D” and “E” in the first field indicate support for decoding and encoding)
Post reply on HN