What is a transcoder on Livepeer?

Video transcoding is the process of converting video from one format to another. For background on why video transcoding is necessary see this link from DaCast. On Livepeer, transcoders run the Livepeer Media Server software in order to provide video transcoding, but they also have special responsibilities to the network in terms of generating new Livepeer Token (LPT), and helping to settle payments from broadcasters across all network participants.

In the medium term, Transcoders will run significant scaled hardware and have significant bandwidth to handle many parallel streams of video. Their setups may be akin to cryptocurrency mining operations. But in the short term, while Livepeer is in alpha and the network is rolling out, the primary responsibilities of a transcoder are:

Pay attention to the network economics and respond to your incentives accordingly. This could be fixing bugs, adjusting your prices, or sharing feedback and bug reports to the community.

Secure your node so that no one can access your Ethereum private key.

You can see that being a transcoder at this stage is just as much about understanding and interacting with the Livepeer protocol running on the Ethereum blockchain, as it is about actually transcoding video. A great transcoder may be 1/4th DevOps professional, 1/4th economics and protocol enthusiast, 1/4th developer, and 1/4th community builder.

Keep your node running 24/7

The Livepeer node is a command line process that runs on OS X or Linux. It’s started in transcode mode quite simply by passing the --transcoder flag.

At this point, if Livepeer was perfect software, it would run 24/7 indefinitely. However Livepeer is very much in alpha. The process may crash. Or even worse, the process may continue running but get into a state where it’s lost connectivity with its peers on the network, or won’t continue taking all the protocol actions.

Your job is to keep this process running, observe and test that it’s doing what it’s supposed to be doing, and potentially even improve the software as you find bugs that is causing it to act incorrectly.

Conduct all required protocol interactions

Note that, again, the node should do all of this for you, if it is running correctly. But if it is not running, or you discover a bug, the effects will be on lost opportunity for you as a transcoder, so best to be aware of what is expected of you.

Initialize the round. (only one transcoder has to do this once per day, so you may not have to).

Call reward() once per round. This is how you get your LPT token rewards.

For transcode jobs that you get assigned and perform, claimWork(), verify(), and distributeFees(). This is all handled for you by the software and would be difficult to compose manually. See details in the Spec.

Pay attention to network economics

To get work you have to set your prices accordingly and attract delegators. The best way to do this is to pay close attention to the network parameters in the livepeer_cli and at https://explorer.livepeer.org.

In your campaign to be elected as a transcoder, and in your ongoing communications to the community, you can promote your pricing, your fee shares and reward cuts, and your history of reliability in calling reward() and distributing fees.

Secure your node

A transcoder node must be online 24/7 constantly signing (and paying gas for) Ethereum transactions. This means that the private key for a funded account is likely sitting on the node in an unlocked state.

This is a risky situation in any circumstance.

The Livepeer software is in alpha and certainly may contain bugs or opportunities for exploits.

It is up to you to run your node responsibly using solid security practices, to manage any associated ETH or LPT responsibly, and to be on the lookout for and fix bugs before they cause any harm to your node.

Setting your reward cut, fee share, and price/segment

These are the levers that you have as a transcoder to compete for delegated stake and work on the network against other transcoders.

Each round Livepeer mints new LPT, and distributes them to everyone in proportion to how much they stake. Reward Cut is the % of your delegators LPT that you will keep for yourself. Delegators -> paying you because you’re doing great work for the network and routing fees and rewards towards them.

As a transcoder you charge fees to transcode video. Fee share is the % of these fees you will share back to your delegators. You -> rewarding your delegators for providing great QA to the network and routing work towards you.

Price/segment is what you charge per 4 second segment of video that you transcode. (Note that this will be adjusted in the future to take into account what type of transcoding you performed). If you’d like to charge $0.50/hr/output stream, then at $500/ETH you would set your price/segment to 1,111,111,111,111 wei.

What are the most important things you can do as a transcoder today?

Call reward() every round. This is how you get your earned LPT and keep your delegators happy.

any estimate date when we can start setting up the service uri?
Hopefully in the next couple weeks! The smart contract changes are ready to go, the protocol just needs to be upgraded along with the Livepeer node.
However, you can start configuring your transcoder to be publicly accessible right now, if it isn’t already. There will be transition period where the Service URI is a “soft” requirement, and we’ll be sure to give everybody plenty of time to set up.

Yep, bond amount means “bond to yourself.” The reason it is 8000000000000 in the image is arbitrary…but the reason it is a big number is because Livepeer Token (LPT) is divisible by 10^18, just like Ethereum is. So

1 LPT actually equals 1000000000000000000 base unit LPT. So that’s why you see big numbers being passed around for transcoder price and bond amounts…because you need a lot of zeroes to actually represent a single ETH or LPT.

As far as broadcasting and transcoding at the same time…I believe yes, that is possible. Though keep in mind that as network usage scales, actual transcoding work would quickly overwhelm a single machine so trying to also broadcast to the same machine may lead to degraded performance.