4 ms·

Same demo video as mpeg1, 243kb, decoded in JavaScript: http://phoboslab.org/files/jsmpeg/cat/ http://phoboslab.org/files/jsmpeg/cat/ Longer demo: http://phobo

Same demo video as mpeg1, 243kb, decoded in JavaScript: http://phoboslab.org/files/jsmpeg/cat/ http://phoboslab.org/files/jsmpeg/cat/ Longer demo: http://phoboslab.org/files/jsmpeg/ http://phoboslab.org/files/jsmpeg/

acgourley 11y ago
What are the trade offs in terms of size and processing required?
- phoboslab 11y ago
  Decoding an MPEG1 video is of course much more taxing on the CPU than scrolling through a large image, but low-res videos shouldn't be a problem even on older mobile devices. jsmpeg uses WebGL to speed up the decoding process a bit. On an iPhone5S, it can decode 720p video in realtime[1]. jsmpeg only unpacks the current frame into memory instead of decoding the whole video at once, so it's memory footprint should be much lower. MPEG1 files are also much smaller than storing individual JPEG frames. [1] http://phoboslab.org/files/jsmpeg/benchmark-720p.html http://phoboslab.org/files/jsmpeg/benchmark-720p.html
  - acgourley 11y ago
    What about for a short loop? Can it cache some frames so that could be fast?
  - coldtea 11y ago
    >On an iPhone5S, it can decode 720p video in realtime[1]. While killing the battery while doing it... Why we don't just expose lower level decoding apis to JS instead, I don't know...
    - ZenPsycho 11y ago
      because of how easy it would be for the already bloated ad laden mobile web to abuse those powers, and how seriously obnoxious, bandwidth eating, and battery killing the results would be.
      - coldtea 11y ago
        To ...abuse the powers of having access to an API for decoding video streams? As we've already established, this can already be done, badly, with native javascript. So adding that access would add nothing new to "abuse" or "eat bandwidth" than what we already have, and will induce even LESS bloat than the current situation. As for merely playing movies, ads etc (without direct access to low level decoding APIs), obviously javascript can already do that with the HTML5 media api + native encoders. So nothing new here either. So I can't tell what disastrous "results" you're referring to stemming from what I propose. Giving JS access to low level movie decoding/encoding would just be something to use to make creating JS-based video editors and such easier and more performant.
        ZenPsycho 11y ago
        You can do it, but as you can see, it's not very efficient and eats battery. nobody would actually put this "decode video in javascript" stuff in an ad, as it stands. Making this stuff work well is hard. make it efficient and easy, and you change the economics of the situation to encourage abuse.
        coldtea 11y ago
        >You can do it, but as you can see, it's not very efficient and eats battery. nobody would actually put this "decode video in javascript" stuff in an ad, as it stands No, but they can already show any arbitrary video they want by using Javascript to add any number of videos playing on the website -- that's just plain vanilla HTML5. Adding hooks to low level decoding doesn't add anything new that they can't already do when it comes to showing ads. For ads they only care for high level decoding. It only adds something new when it comes to creating video mangling apps in JS.
        ZenPsycho 11y ago
        that is on desktop. It is currently not possible to autoplay video on an iphone, and that is in fact the topic of this thread, and (partially) the purpose of this library. Beyond autoplaying, I can't imagine what you mean about adding "hooks" to low level decoding. What does that actually gain you over the current situation?

acgourley 11y ago

What are the trade offs in terms of size and processing required?

phoboslab 11y ago
Decoding an MPEG1 video is of course much more taxing on the CPU than scrolling through a large image, but low-res videos shouldn't be a problem even on older mobile devices. jsmpeg uses WebGL to speed up the decoding process a bit. On an iPhone5S, it can decode 720p video in realtime[1]. jsmpeg only unpacks the current frame into memory instead of decoding the whole video at once, so it's memory footprint should be much lower. MPEG1 files are also much smaller than storing individual JPEG frames. [1] http://phoboslab.org/files/jsmpeg/benchmark-720p.html http://phoboslab.org/files/jsmpeg/benchmark-720p.html
- acgourley 11y ago
  What about for a short loop? Can it cache some frames so that could be fast?
- coldtea 11y ago
  >On an iPhone5S, it can decode 720p video in realtime[1]. While killing the battery while doing it... Why we don't just expose lower level decoding apis to JS instead, I don't know...
  - ZenPsycho 11y ago
    because of how easy it would be for the already bloated ad laden mobile web to abuse those powers, and how seriously obnoxious, bandwidth eating, and battery killing the results would be.
    - coldtea 11y ago
      To ...abuse the powers of having access to an API for decoding video streams? As we've already established, this can already be done, badly, with native javascript. So adding that access would add nothing new to "abuse" or "eat bandwidth" than what we already have, and will induce even LESS bloat than the current situation. As for merely playing movies, ads etc (without direct access to low level decoding APIs), obviously javascript can already do that with the HTML5 media api + native encoders. So nothing new here either. So I can't tell what disastrous "results" you're referring to stemming from what I propose. Giving JS access to low level movie decoding/encoding would just be something to use to make creating JS-based video editors and such easier and more performant.
      - ZenPsycho 11y ago
        You can do it, but as you can see, it's not very efficient and eats battery. nobody would actually put this "decode video in javascript" stuff in an ad, as it stands. Making this stuff work well is hard. make it efficient and easy, and you change the economics of the situation to encourage abuse.
        coldtea 11y ago
        >You can do it, but as you can see, it's not very efficient and eats battery. nobody would actually put this "decode video in javascript" stuff in an ad, as it stands No, but they can already show any arbitrary video they want by using Javascript to add any number of videos playing on the website -- that's just plain vanilla HTML5. Adding hooks to low level decoding doesn't add anything new that they can't already do when it comes to showing ads. For ads they only care for high level decoding. It only adds something new when it comes to creating video mangling apps in JS.
        ZenPsycho 11y ago
        that is on desktop. It is currently not possible to autoplay video on an iphone, and that is in fact the topic of this thread, and (partially) the purpose of this library. Beyond autoplaying, I can't imagine what you mean about adding "hooks" to low level decoding. What does that actually gain you over the current situation?