4 ms·
Nice approach. I assume this can be adapted to run in a single process on a multi-core machine to increase parallelism. But... Why no comparison to the curren
by ysleepy 9y ago
Nice approach. I assume this can be adapted to run in a single process on a multi-core machine to increase parallelism.
But...
Why no comparison to the currently established approach of encoding chunks of 5sec/128frames, all in parallel?
The paper mentions this approach, but only compares to single- and multi-threaded vpx. As a reader I'm left wondering if it is because this approach leads to a similar overall encoding time.
The paper also fails to mention that keyframes are also there in regular intervals to help seeking, especially for streaming video.
Also the way of measuring youtube "encoding time" is ridiculous. This probably measures the length of the encode job queue and currently available unused compute in gc2.
- keithwinstein 9y agoThanks! Unfortunately we couldn't run 128-frame independent chunks (which we would call "ExCamera[128,1]") on an AWS Lambda instance because it doesn't have enough storage or RAM to store 128 frames of raw 4K video. We did benchmark ExCamera[24,x] (including the independent case, ExCamera[24,1]), which is the biggest we could fit on a lambda, and include those results in the paper. All of our tested configurations end up with a keyframe at least every 192 frames (the max configuration was ExCamera[12,16]), so we're sort of similar to the status quo in terms of keyframe (i.e. type-1/2 SAP) frequency.
- ysleepy 9y agoThanks for the insight. The vpx runs were done on normal VMs. But I see that approaching a smaller runtimes, VMs are not economical. The theoretical bound of splitting the source material into 5s chunks and encoding them all in parallel is still a useful comparison to make. Especially considering an endless supply of jobs keeping VMs busy.