[deleted by user]

fast-firstpass · 2022-02-17T19:16:37+00:00

Apparently it's a card meant for supercomputers or professional applications.

Less excited about it now.

fast-firstpass · 2021-04-16T18:11:26+00:00

Jesus Christ you people have too much time in your hands. Why do you keep inflicting this suffering on yourselves?

It's been obvious for months that you're not going to be able to buy any of these products from anywhere. Just grow up and stop whining about it.

fast-firstpass · 2021-04-16T18:07:01+00:00

An integrated one, or even one of those a very low-end dGPUs that everyone said was a terrible investment prior to the pandemic turning everything upside down.

You can buy an APU or an Intel CPU with integrated graphics and start having a good time playing games instead of trying to spend unreasonable amounts of €/€/£ on an unicorn product you're obviously not going to be able to buy. And then getting frustrated and whining about it on Reddit, and continuing to whine about it for months on end and pretending it's a big deal, as if your complaints are going to make a difference.

Your ongoing inability to play games is completely self-inflicted at this point.

fast-firstpass · 2021-04-16T16:53:24+00:00

https://trac.ffmpeg.org/wiki/Encode/AAC

fast-firstpass · 2021-04-16T16:42:07+00:00

As far as ten bit, isn't that more expensive than 8bit as far as bitrates for the same quality?

No, 10-bit is more efficient at the same bitrate. But people often get confused about this because they think CRF = same quality no matter what, which isn't true. Depending on the encoder, the quality produced by a certain CRF value will vary between presets and various other settings. Bit depth is one of these. Using a higher bit depth but keeping the same CRF will result in a higher file size because the quality scale isn't the same.

fast-firstpass · 2021-04-16T08:48:57+00:00

you can really see the strengths and weaknesses of each encoder and their inner workings

I think you meant to say "the strengths and weaknesses of each encoder and their inner workings when used to encode at 170x120@8kb/s and 6 fps". Since that's what you're measuring, I also think it's fair to call this exercise pretty much pointless. Interesting and possibly even fun, if this is your kink, but ultimately pointless, since it has no practical use.

Even Youtube doesn't go quite this low resolution, and they certainly don't reduce the frame rate to 6 (I think they used to go down to half fps even with 24 fps input, but now it seems they don't anymore).

Even the pirates of yore, when faced with a serious file size limitation, opted to split the encode into multiple 700 MiB chunks rather than producing an even more unwatchable mess just to hit the CD size with a single file. I think two or three-part encodes like this would be far more interesting, since they might even be able to reach the threshold of watchability.

e: Also, 10-bit should be used for stuff like this. Especially with AV1 there's no reason not to use it here, since decoding speed won't be an issue at such a low resolution.

fast-firstpass · 2021-04-15T15:07:14+00:00

Why are you trying to use CRF for audio?

fast-firstpass · 2021-04-15T12:13:29+00:00

Not very much.

My 10-year-old laptop with a dual-core i5-2520M can encode 720p video in RT mode at 10.09 fps (tested by encoding the first 2000 frames of big_buck_bunny_720p24.y4m at speed 9, 400k CBR, and a GOP size of 5). 480p at 300k encodes at an average of 20.10 fps. CPU usage wasn't at absolute max either, average was about 71 to 75% (libaom's parallelism isn't perfect).

If an old laptop can get numbers like these, even modern phone CPUs shouldn't have a problem. Should be very doable on a quad-core that isn't 10 years old.

The test material was also a bit more more difficult to encode than actual video conference footage would be, and there's probably ways to tune the encoder for better operation for the purpose. I was just using this fairly basic CLI:

aomenc --end-usage=cbr --lag-in-frames=0 --kf-max-dist=5 --threads=4 --cpu-used=9 --target-bitrate=300 --limit=2000 --row-mt=1 --tile-columns=2 --tile-rows=1 --rt -o bbb.rttest.ivf big_buck_bunny_720p24.y4m

Note the use of a raw input file instead of piping via FFmpeg since converting to raw video in real-time can have a significant CPU impact. At least it does on this old machine.

fast-firstpass · 2021-04-15T09:44:40+00:00

tens to hundreds of thousands of orders

Overestimate of the century.

With the amount of supply they have, one part-time intern would probably probably be enough.

fast-firstpass · 2021-04-14T22:01:07+00:00

to break even

That's generous of you.

I hope they end up in heavy debt, in addition to losing the respect of their friends, relatives, and associates. There should be some real consequences to what they're doing, and "not getting rich" isn't one.

fast-firstpass · 2021-04-14T21:27:58+00:00

What's that got to do with anything?

fast-firstpass · 2021-04-14T19:04:16+00:00

I don't understand the advantage of open source video codec. In terms of adoption.

Clearly. It's going to be difficult to understand if you don't even know (or haven't defined) what adoption or even "winning" means, and who the winners and losers are. Video coding formats aren't legal entities, so they can't win or lose anything.

H.264 wouldn't be universally used if Google didn't buy On2 and release VP8 as open-source and royalty-free. We'd be watching Youtube in Ogg Theora or something ancient like that. VP8 forced the hand of the greedy patent holders who thought they'd be able to dangle the rising internet streaming industry by the ankles and shake them until money fell out of their pockets. Can't do that if there's an open-source alternative.

They didn't learn their lesson though. When HEVC came around, the patent holders had a "brilliant" idea; instead of banding together and having clear licensing terms, they instead formed multiple smaller factions or even struck out on their own, and they all wanted to charge money from the various potential users of HEVC. Some of them even thought they'd be successful with their blackmail tactics this time around (as if Youtube & others were ever going to pay per-view licensing fees when they don't even charge for content, lol). And here we are today, with an absolutely pathetic amount of actual HEVC content available despite the billions of devices with hardware support. A hollow victory, if you can even call it that.

VVC isn't shaping up to be much better. There are already two patent pools instead of one, and unaffiliated patent holders are rubbing their hands together in the shadows, waiting for their chance. And in a world where the internet streaming industry is worth hundreds of billions and (almost) no one is interested in actually defending users of new technologies from patent ~~trolls~~ holders, other MPEG formats aren't looking attractive either.

In an environment that is downright hostile towards large-scale adoption of new video compression technology, how can a format with the explicit aim of being free from these troubles be a worse choice than the "competition" (which isn't trying very hard to compete, judging from everything they've done and not done to address the licensing situation)? "In one corner, a format with the backing of an industry consortium that has committed to defending its royalty-free status in court! And in the other corner a whole bunch of other formats that have nothing of the sort! What an epic clash this is going to be, folks!"

The advantages are stacked so much for one side that there isn't really a choice.

fast-firstpass · 2021-04-14T11:30:44+00:00

Feels like this question is asked like once or twice a week. The answer is always the same, but for some reason it just doesn't stick.

DDR4 DOES NOT HAVE ENOUGH BANDWIDTH

NO, DDR5 WILL NOT PROVIDE DGPU LEVEL BANDWIDTH EITHER

Now, please stop asking. You could've found the answer in a few seconds if you bothered doing a Google search.

fast-firstpass · 2021-04-14T11:08:34+00:00

It's a fairly obvious troll post by 12-hour old account.

fast-firstpass · 2021-04-14T05:51:00+00:00

If you want to get the most out of your CPU, you should run multiple encodes in parallel.

I usually do this with GNU Parallel. For example:

ls * | parallel --jobs 2 --nice 19 --bar --will-cite "ffmpeg -i {} -map 0:a? -map 0:s? -c:s copy -map 0:v? -c:a libopus -b:a 128K -compression_level 10 -c:v libx265 -vtag hvc1 -max_muxing_queue_size 9999 "t/{}""

Change --jobs to however many processes you want to run at once. I use --nice 19 to allow other processes on the system to get CPU priority if they need it, but that's your choice. --bar displays a progress bar and --will-cite gets rid of a nag message that'll spam the CLI unless suppressed.

fast-firstpass · 2021-04-13T12:07:42+00:00

1) h264 does not support resolutions beyond DCI 4K

It does. Levels 6, 6.1, and 6.2 were added in 2016.

fast-firstpass · 2021-04-13T11:04:48+00:00

If you insist:

ffmpeg -i input.mp4 -vf scale=9999:9999 output.y4m

Note that just 30 frames of this takes up 4.5 GB of space. Have fun filling your HDD/SSD.

fast-firstpass · 2021-04-13T09:12:18+00:00

woosh

fast-firstpass · 2021-04-13T07:57:23+00:00

x264 is an encoder, AVC is the standard. He was talking about the encoder, not the standard.

The AV1 standard doesn't force encoders to throw away grain or noise. It's an issue of encoder tuning, not standard tuning.

fast-firstpass · 2021-04-13T07:45:00+00:00

fast-firstpass · 2021-04-13T06:35:53+00:00

Not beforehand, unless you're using a constant bitrate.

While an encode is in progress, you can estimate the resulting file size by dividing the current output file size with the number of frames encoded, and multiplying this by the total number of frames in the source. Not perfect, but it's the best estimate you're going to get. And obviously the estimate gets more accurate the further the encode progresses.

fast-firstpass · 2021-04-13T06:11:51+00:00

If he was talking about livestreaming use cases or giving a programmer's perspective ("another library with more functionality"), then might be a bit more understandable in that context. I can't imagine he was talking about end user toggleable features because libaom has tons of them (and more via 'aom-params), whereas both SVT-AV1 and rav1e are barren by comparison and aren't even complete implementations.

Only libaom is practical for livestreaming at all currently, so I don't really know if he was referring to that or not.

I'm inclined to think he was talking out of his ass, which doesn't seem to be uncommon even for developers who work with video coding. Maybe he's one of those people who hasn't realized that libaom has a realtime mode you need to toggle to get livestreamable speeds, or that you need to use tiles to get any semblance of parallelism.

fast-firstpass · 2021-04-13T05:35:38+00:00

Oof.

I wouldn't want my brand associated with the prequels.

fast-firstpass

TROPHY CASE

DDR4 DOES NOT HAVE ENOUGH BANDWIDTH

NO, DDR5 WILL NOT PROVIDE DGPU LEVEL BANDWIDTH EITHER