You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the client sends a request to transcode a video to the transcoder. They communicate directly via a webrtc channel using the paratii-protocol When the transcoding job is done, the transcoder sends a message to the client over webRTC with the result (ipfsHash), and the client writes the result to the Videos.sol contract.
This is very fragile, because the client may go offline (transcoding takes a long time) and then the result will not be written.
Another reason why this is unsatifsfctory is because iIn the future, this record will represent a claim of the transcoder for payment for the job done (and a client in this way could easily block the message and make it impossible for the transcoder to claim is reward).
We have just one transcoder now, but these could be many in the future.
What we'd need is:
uploader creates a new id for the vdeo, and writes id and ipfsHashOrig to the videos.sol contract, plus it assigns the transcoding job to the transcoder (which is identified by an ethereum address)
After the transcoder finished the job, it sends the ipfsHash and the id to the blockchain
Of course, only the transcoder can claim that the job is done.
The transcoder only can claim the job once (it cannot change the hash later)
There are perhaps two different approaches here:
Adapt the Videos.sol contract with logic so that transcoder jobs can be assigned and claimed.
Create a new contract that handles this logic. (this is probably the preferred option)
The text was updated successfully, but these errors were encountered:
See our uploader here https://portal.paratii.video/upload
What we have now is the following mechanism:
paratii-protocol
When the transcoding job is done, the transcoder sends a message to the client over webRTC with the result (ipfsHash
), and the client writes the result to theVideos.sol
contract.This is very fragile, because the client may go offline (transcoding takes a long time) and then the result will not be written.
Another reason why this is unsatifsfctory is because iIn the future, this record will represent a claim of the transcoder for payment for the job done (and a client in this way could easily block the message and make it impossible for the transcoder to claim is reward).
We have just one transcoder now, but these could be many in the future.
What we'd need is:
id
for the vdeo, and writesid
andipfsHashOrig
to the videos.sol contract, plus it assigns the transcoding job to the transcoder (which is identified by an ethereum address)ipfsHash
and theid
to the blockchainThere are perhaps two different approaches here:
Videos.sol
contract with logic so that transcoder jobs can be assigned and claimed.The text was updated successfully, but these errors were encountered: