Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 >  So if we can run Landstat Satellites and entire Universities
 > (vienna), I humbly submit that it's time to realize "you did it" when
 > it comes to data management...and to put media delivery at the
 > forefront of the agenda not at the end of the agenda.
 >
 > The current generation is all about audio and video. "expect... all
 > at once...." Many of us have been asking for audio/video improvements
 > for well over the past ten years. So it's not as if we are coming out
 > of the blue....

We still don't have point-and-click data binding with a built-in MVC 
framework.

But in all fairness those are things the community can do in script, 
whereas multimedia playback is very much an engine concern.

I bring up MVC only to suggest that your priorities may not be mine, and 
mine may not be others'.

As a Linux user I haven't been able to even just play a video at all in 
several years, while it's possible (with some codec/format limitations) 
on Windows and Mac users enjoy support for the latest OS media APIs.

Since most of my current work is in data-intensive productivity apps 
this hasn't held me back; I share the story only to point out that 
priorities are as broad and varied as this community.


 > "difficult port" ?? there are any number of media player frameworks
 > built on JS... Perhaps I'm very dense, but JS is use for media
 > deliver *everywhere*... It's not about a player exactly.. but just to
 > be able to stream audio and video.
 >
 > So back to my question: is there another way to play media using
 > other means beside a player?

Yes: let the browser do it.

But to do that, you'd need to let the browser do it all.

There are two very different worlds here:  the desktop, run with OS APIs 
on binary structures and machine code; and the web, run with browser 
specs on textual data and JavaScript.

These worlds do not collide.  They are fundamentally different, designed 
for very different tasks.

Before LC's HTML initiative, the two worlds were for the most part quite 
separate.  No one expects to use XCode to write C++ apps in Cocoa and 
somehow run them in a browser.

What LC is attempting here is a significant departure from a long 
history in which the two worlds, desktop and web, are very separate from 
one another.

Given that the only execution engine commonly available in browsers is 
JavaScript, to migrate applications made in LiveCode into the confines 
of a web browser requires either of two approaches:

a) Translate LC-native objects to browser-native HTML/CSS, and LC-native 
scripts to JavaScript.

b) Translate the LC engine to JavaScript so LC-native objects and 
scripts need no translation.

Either is a difficult task.

Option a) makes it relatively easy to get appearances, but for 
functionality requires translating every line of LiveCode script into 
JavaScript.

The appearance part isn't that hard:  with a few hours it's possible to 
translate native LC objects into their HTML/CSS equivalents rather 
satisfyingly, with the result being lean browser-native layouts.

But the functionality is not so easy. LiveCode and JavaScript are so 
very different in their syntax, logic, event and object models, that 
translation from one to the other is a mind-bendingly difficult task.

Option b) is where we're headed instead, moving the entire LC engine 
into the browser by translating roughly three quarters of a million 
lines of C++ into JavaScript.

This allows LiveCode scripts and objects to be handled more or less how 
they're handled in the desktop engine, without needing to translate 
LiveCode scripts.

But given that the desktop and the web are such fundamentally different 
platforms, neither approach can be expected to be a seamless move. 
These are very different worlds; there is no magic pony.

Option a) would allow us to export LC player controls as HTML5 player 
objects, but would require you to write any scripts you need in JavaScript.

Option b) lets all your LC objects scripts go along for the ride since 
the LC engine they depend on is now a JavaScript object, but it means 
you don't have access to browser-native objects like HTML5 media support.

If one were inclined to pursue option a), it could be possible to take 
the approach Toolbook and others have, in which functionality targeted 
for web deployment is limited to calls in LC libraries for which 
matching JavaScript libraries are provided.  I first suggested this as a 
solution here in 2003, but no one was interested enough to help see it 
through.  Could still be done, though, just not by myself.  And while 
the functionality such libraries provide would be limited, the 
intersection of things we need to do on both desktop and web is somewhat 
limited by nature anyway, so for some apps it may not be a bad option.

With option b), the one being pursued at the moment, there is the 
possibility that the LC engine code that handles media playback could be 
replaced post-translation with browser-native handling.  Given the 
complexity of the output Emscripten produces this would not be trivial, 
and with the differences in the object model it may not be practical, 
but it might be possible.

I don't know if any of this rambling post is helpful, but my aim here is 
just to point out the very difficult task being undertaken here.  And 
while we can expect Peter's excellent work to continue to make big 
strides, I think it may be helpful to keep expectations in check, since 
we're attempting to bridge two very different worlds. Not all life forms 
that thrive on one planet can survive at all on another.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com