4 ms·

On one hand this is great - offload the processing to the client side. On the other hand, I don't know if I'd trust a client-encoded video when serving video co

by jjcm 6y ago

On one hand this is great - offload the processing to the client side. On the other hand, I don't know if I'd trust a client-encoded video when serving video content to thousands of other users. Curious about the performance though. Would love to see benchmarks vs a standard ffmpeg install.

wahern 6y ago
Unless you're a broadcast studio, aren't most videos client-encoded one way or another? Does YouTube even let users upload raw, uncompressed video? Speaking of which, IME (mostly with audio), exploits more often seem to relate to encapsulation--container format, framing, etc--than to the low-level compressed blocks themselves; and those parts certainly are controlled by the client, at least at ingest. I don't know if that's simply because more people (albeit still small in absolute terms) are capable of understanding and breaking encapsulation implementations as opposed to the math-heavy block (de)compression routines, or because the (de)compression algorithms natural bound the scale of the output--e.g. a compressed 44.1khz AAC frame is not going to expand to more than 44.1k samples, and each sample won't be larger than the parameterized bit size. Either way, anyone distributing multimedia should account for this stuff. Alas, most don't seem to bother; they just pass off files to an ffmpeg binary or wrapper and hope for the best.
- jjcm 6y ago
  I think you've misunderstood. I'm saying that I wouldn't want to directly serve a client-encoded video without doing an encoding pass on the server. Youtube re-encodes all video regardless of the format it's uploaded in.
  - golemiprague 6y ago
    but if it encode it in your webpage with your ffmpeg tool then unless someone interfere with it maliciously in some way it should not be different to encoding it on the server
  - kmeisthax 6y ago
    In the early days of YouTube you could upload FLVs that were served directly to users (this was back when their only playback format was Flash Video). It let you get high-quality video before that was an official option, and some people even had "fun" with malicious FLVs that crashed your browser via Flash.
devwastaken 6y ago
The data formats are standardized with expected outputs, so it should be possible to develop parsers that enforce strict specs. It would be significant faster and cheaper than encoding.
ehsankia 6y ago
I like this for pure client-side apps, if even only for a simple ffmpeg-GUI app that I can link any of my friends who want to quickly convert something without going to amazingmp4tomp3converter.com Basically I'd like to see something like Handbrake on the web, maybe even simpler interface.

by jjcm 6y ago

wahern 6y ago

Unless you're a broadcast studio, aren't most videos client-encoded one way or another? Does YouTube even let users upload raw, uncompressed video? Speaking of which, IME (mostly with audio), exploits more often seem to relate to encapsulation--container format, framing, etc--than to the low-level compressed blocks themselves; and those parts certainly are controlled by the client, at least at ingest. I don't know if that's simply because more people (albeit still small in absolute terms) are capable of understanding and breaking encapsulation implementations as opposed to the math-heavy block (de)compression routines, or because the (de)compression algorithms natural bound the scale of the output--e.g. a compressed 44.1khz AAC frame is not going to expand to more than 44.1k samples, and each sample won't be larger than the parameterized bit size. Either way, anyone distributing multimedia should account for this stuff. Alas, most don't seem to bother; they just pass off files to an ffmpeg binary or wrapper and hope for the best.

jjcm 6y ago
I think you've misunderstood. I'm saying that I wouldn't want to directly serve a client-encoded video without doing an encoding pass on the server. Youtube re-encodes all video regardless of the format it's uploaded in.
- golemiprague 6y ago
  but if it encode it in your webpage with your ffmpeg tool then unless someone interfere with it maliciously in some way it should not be different to encoding it on the server
- kmeisthax 6y ago
  In the early days of YouTube you could upload FLVs that were served directly to users (this was back when their only playback format was Flash Video). It let you get high-quality video before that was an official option, and some people even had "fun" with malicious FLVs that crashed your browser via Flash.

devwastaken 6y ago

The data formats are standardized with expected outputs, so it should be possible to develop parsers that enforce strict specs. It would be significant faster and cheaper than encoding.

ehsankia 6y ago

I like this for pure client-side apps, if even only for a simple ffmpeg-GUI app that I can link any of my friends who want to quickly convert something without going to amazingmp4tomp3converter.com Basically I'd like to see something like Handbrake on the web, maybe even simpler interface.