4 ms·

Yes! Supported file types can, such as MP4. Other video formats are not currently supported for streaming (can still be uploaded for download) due to browser re

by sweca 2y ago

Yes! Supported file types can, such as MP4. Other video formats are not currently supported for streaming (can still be uploaded for download) due to browser restrictions and compute considerations. For supported video types, Horizon is optimized in the sense that it recognizes videos and allows viewers to stream it in chunks for seamless watching.

ijustlovemath 2y ago
Why not have the user's machine do the encoding into whatever format is cheapest/easiest for you to support? Could even divide user payloads into chunks and p2p it, bittorrent style. No compute needed, beyond a tracking server that can be very cheap to run
- sweca 2y ago
  Transcoding client-side still has considerations: - What if the user's hardware is not performant? - Transcoding is intensive, so their machine will become slow - Even wasm based ffmpeg will not be as efficient and has its own issues - Takes a very long time
  - ijustlovemath 2y ago
    1. Then setup a worker thread with a very high nice value, like 19. Limit your throughput with tick-based compute (sleep if you're using too much compute) 2. Not if you do as proposed 3. Efficiency is not your problem, as you've stated with the previous 2 requirements. Your algorithm doesn't have to be maximally efficient if it takes a while to compute (eg you're using sleep in it) 4. Doesn't matter, most users of this service will only be taking a few photos or videos a day. Offer a paid service upgrade for heavy users who cant handle the upload times.
jmuguy 2y ago
That's awesome. I think I read somewhere that everything is hosted in EU? Because man... its painfully slow uploading a 600 MB video from east coast US, and I have a GB line.
- sweca 2y ago
  Yes it's hosted in the EU. Sorry about your slow upload speeds. I'm in Canada on the east coast and it's still decently fast for me. Although, the uploader can be optimized further (using multiple threads for each file rather than single thread per file), so they may or may not improve after that. In the (possibly near) future, I do plan on scaling to the NA to give us better latency.

by sweca 2y ago

ijustlovemath 2y ago

Why not have the user's machine do the encoding into whatever format is cheapest/easiest for you to support? Could even divide user payloads into chunks and p2p it, bittorrent style. No compute needed, beyond a tracking server that can be very cheap to run

sweca 2y ago
Transcoding client-side still has considerations: - What if the user's hardware is not performant? - Transcoding is intensive, so their machine will become slow - Even wasm based ffmpeg will not be as efficient and has its own issues - Takes a very long time
- ijustlovemath 2y ago
  1. Then setup a worker thread with a very high nice value, like 19. Limit your throughput with tick-based compute (sleep if you're using too much compute) 2. Not if you do as proposed 3. Efficiency is not your problem, as you've stated with the previous 2 requirements. Your algorithm doesn't have to be maximally efficient if it takes a while to compute (eg you're using sleep in it) 4. Doesn't matter, most users of this service will only be taking a few photos or videos a day. Offer a paid service upgrade for heavy users who cant handle the upload times.

jmuguy 2y ago

That's awesome. I think I read somewhere that everything is hosted in EU? Because man... its painfully slow uploading a 600 MB video from east coast US, and I have a GB line.

sweca 2y ago
Yes it's hosted in the EU. Sorry about your slow upload speeds. I'm in Canada on the east coast and it's still decently fast for me. Although, the uploader can be optimized further (using multiple threads for each file rather than single thread per file), so they may or may not improve after that. In the (possibly near) future, I do plan on scaling to the NA to give us better latency.