Deterministic Transcoding

[dob]

The Livepeer protocol depends upon being able to verify the computations that transcoders do when encoding video. To do this using Truebit as proposed, transcoding needs to be deterministic, producing the same bit-for-bit output.

When using FFMPEG for transcoding, by default, one would not get deterministic output if run on different architectures, or if the number of threads/cores being used is greater than one. This can be potentially overcome by:

• compiling FFMPEG with all compiler optimizations turned off
• running with only one thread
• potentially running in an emulated, well spec'd architecture, like web assembly

However this of course brings its own tradeoffs in terms of efficiency of the encodings relative to centralized options that don't need to be verified, as well as restricting who can run Livepeer, and introducing additional engineering/operational complexity.

This track aims at research solutions for transcoding verification. There are at least two separate approaches.

1. Most efficient and direct setups that produce deterministic output and can run on whatever hardware the transcoder brings to the table.
2. Solutions that don't require bit-for-bit determinism, such as probabilistic checks and majority rules schemes.

[dob]

Some links that have been helpful in understanding why we don't see deterministic output when running the same code:

https://stackoverflow.com/questions/46898384/ffmpeg-libx264-encoder-different-machines-different-output

https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/

[hiddentao]

Off the top of my head, probabilistic checks make more sense to me - e.g. running a mapReduce over all 8x8 or 16x16 blocks. For two reasons:

• It's likely possible to produce a similar quality / identical frame using different hardware + software combinations. By not restricting the combination usable by a transcoder they are free to optimize their machinery to suit the task, thereby encouraging competition and continuous improvement in this area.

• A probabilistic check allows for the variation in output that is naturally expected even from identical setups, plus it allows for varying how stringent the check needs to be according to other factors - for example, if there are relatively few transcoders available then perhaps the match % can be lower, in order to encourage more transcoders to enter the market. Following on from this point, makes sense that the closer my transcoded image matches the expected image the more I should get rewarded. This incentivises transcoders to also compete with each other even in the case where only a few transcoders are available to provide the service.

[ericxtang]

The goal of transcoding is to have the same video at different bitrates. If we can take a random timestamp and measure image similarity between the input and output video(image), we'll have some confidence on whether we got the "right" output.

Check out this link about image similarity. https://stackoverflow.com/questions/843972/image-comparison-fast-algorithm

We can also measure the bitrate for the output video to make sure it's around the desired bitrate.

Judging in this scheme might be tricky - since we don't have an exact comparison, we'll either have to define some confidence interval, or have a economic model that punishes based on the distance between the desired value and actual value.

[iameli]

I absolutely love that this is the first Google result for "Deterministic Transcoding".

For what it's worth — and I'm not saying we should drop everything and do this — but IMO we gave up too soon on the idea of bitexact deterministic transcoding. None of the major video encoders are presently capable of multithreaded determinism. But that's not, like, a law of physics. Just something that wasn't ever a priority for people writing video encoders. Implementing such a thing would presumably trade off some performance for determinism, but even an encoder that's 50% as efficient would be very useful for its properties around verifiability. Something worth keeping in mind for the next 25 years of decentralized transcoding.