You are viewing a single comment's thread from:

RE: The case for client side encoding

in #viewly7 years ago (edited)

This does sounds brilliant, but would you not require many transcodings for the different browser formats and adaptive streaming, and thus significantly increase bandwidth requirements between the Viewly node and the network when uploading (essentially each video would need to be uploaded several times). If so, from an average end-users perspective, that may go down so well.

Still there has to be some price for freedom, and I'm happy with slightly longer uploads!

Is X264 not under any threat due to H264 patents, would that also need be a consideration for you guys if you were developing an encoder?

Sort:  

You are exactly right. However it turns out that even with transcoding into multiple formats, the total upload size is often smaller than original, due to the efficiency of encoding itself.

x264 is quite common, and we do use it (implicitly). I am really looking forward to royalty free H265 adaptations (VP9 et al).

Oh yes I see, I hadn't thought of that!

So should ffmpeg and x264 compile into WebAssembly too?

I hope to join the discussion on Telegram when I've some more time.

Coin Marketplace

STEEM 0.21
TRX 0.26
JST 0.040
BTC 101296.09
ETH 3673.80
USDT 1.00
SBD 3.15