Define protocol for paying for transcoding

[jellegerbrandy]

Roughly, we need a little "protocol" that we can use immediatly that does the following:

• uploaders pay transcoders for the transocding job with PTI
  • let's set the price the 1 PTI/minute
  • uploader on subscribing gets 15 mins worth of transcoding (like yt), i.e. get 15 PTI on upload
  • uploader visits /upload/ and submits a video
  • money for transcoding the video gets put in escrow (<-- this is the part to define)
  • video is uploaded, sent do the transcoder
  • transcoder finished job and settles the escrow (taking the money for transcoding, giving the remainder back to the user)
  • (we have no trust issues yet for the transcoder, as this is us)

[aeftimia]

Side note: Would the price more closely match the amount of computational work to transcode a video if the user paid in PTI/kB? If so, would it make sense to use this metric instead?

So for this protocol, would it make sense to identify the video by its initial IPFS hash. Perhaps a protocol could be: 1a. Server initiates an escrow with a smart contract with a rate for transcoding videos. The escrow has a time limit, after which the funds will be returned to the sender if they have not been successfully claimed by the transcoder. 1b. Server sends escrow address to client. 1c. Server sends the rate (e.g. PTI/minute) to the client. 2a. Client sends funds to the escrow address and the hash of the video. 2b. Escrow address logs an event, to which the server is subscribed, that details the deposited funds and hash. 3a. Client uploads video to server. 3b. Server checks hash matches that referenced in the escrow and that the funds are sufficient. 3c. If funds are sufficient, move to 4, otherwise, report insufficient funds. 4a. Server transcodes video and uploads each format to IPFS. 4b. Server sends the IPFS hashes of each transcoded segment to the escrow. 4c. Since we can trust the server, there is no challenge step and the funds are released to the transcoder.

[jellegerbrandy]

Hi Alex,

Actually, this protocol was already partly specifed and discussed on gitter soem 10 days ago. I should have linked to the wiki entry here, which already described a protocol, and which i just updated ( (also with staking, @felipegaucho !) https://github.com/Paratii-Video/wiki/wiki/Protocol-Description:-Upload-Video

Just 2 remarks:

• about the pricing - the cost of transcoding is probably based on both the size and the length of the video. Is that right @ya7ya ? Youtube only limits by length (not more than 15 minutes of transcoding by default). In any case, in my proposal, we do not need to negotiate a "price per something", the only thing that counts is the total price. (However, the protcol includes a step where the uploader needs to make an estimate of what a reasonable price is, and for that step, it is useful to ahve at least some idea)

• I think it is cumbersome (and unecessary) to refer to identify the video by the ipfs hash of the raw uploaded file.

[ya7ya]

Hey @jellegerbrandy

the cost of transcoding is probably based on both the size and the length of the video.

It's based on the length and the number of downsamples, for example a 1 minute 1080p video would cost more than 1 minute 480p video.