Really rooting for Viewly, and this is a creative way to approach one of its biggest outstanding problems. Long term this will probably be a good way to go, but in the nearish term it feels like a bit of wishful thinking for a few reasons.
- Not all clients can handle the load. It would crush battery life of mobile devices. You'd have to re-encode many times to support all the formats users might want to play. It's just so cumbersome
- It blocks your future proofing as far as any formats you want to support in the future. Sometimes centralized video services do a full pass over all their content to support something new or optimize things. You can't go back in time and ask clients to re-encode everything to something new
Neither of these things are deal breaker size in and of themselves, but together they're just worse than existing platforms. Usually you can't compete against an incumbent unless you're 10x better. This feels like 2x worse.
Luckily, I do think there are ways to solve this with decentralized infrastructure. I think the eventual path for this will really be using a completely different decentralized system that the user is never aware of in order to do this processing, but it would be paid for by a fraction of the steem value given to the content. Whatever agrees to do the processing before the content has views is taking on the liability of the cost up-front though which creates a huge hurdle.
Can't wait to see what you come up with, or if doing this client side will actually just work out for now (would be cool if that's the case).
RE: The case for client side encoding