URLstatus for Players set to remote URLs

Sivakatirswami katir at hindu.org
Thu Aug 16 16:38:37 EDT 2007


I know most everyone is forcing users to download entire movies
before starting players set to http refs... but I would like things to be
  a bit more dynamic.

Can players be hooked to libURL such that

set the filename of player "remoteMovie" to
"http://www.domain.org/movies/greatestShowOnEarth.mov"

would "emulate" a load cmd so that we have access to the URLstatus for
that player's download?

Goal:  One would like to present a progress bar to  users, that could
poll URLstatus for the
player's call to a remote URL... after all it would seem that setting
the player's
filename to an http ref is the same "animal" as a load url call.

I'm finding pretty consistently that any movie that has been exported
with "Fast Start Header"
but *not" compressed hearders and no hinting (we aren't using QT
streaming on one server) will,
even in a non-streaming environment, begin to display frames as soon as
enough data has been buffered.

but, it varies, for reasons I cannot fathom, from one movie to the
next..as to the time that passes before the
movie begins, I suspect differences in bandwidth and data rates. We need
something like

"Please be patient... downloading movie...."  numbers and real time
frames if known would be
even better "Your movie will start in 1 minute 32 seconds".

  And a call back would
be marvelous because you could let the user go do something else and
then "ring" them:
"You movie has begun" and then present them the player again, with the
moving just started.
even if it has not been all downloaded yet, but enough data has arrived
to start the movie.
There would need to be some feedback in the API between Rev and
Quicktime... possibly
as simple as polling the current time, which will be "stuck" at 0, even
if you have
started the player... until enough data has arrived and it begins...
hmmm. maybe that
itself is a half-baked solution....I'll test it..

I discovered a simple trick which cured my previous problems: you can
let a movie dynamically
be changed and set another movie on the same card. The problems related to

a) leaving players with a file name set... *always* set the filename to
empty on closing the card...
(otherwise when you go back to the card the player initiates a download
of the previous filename
it was set to and save with .."duh"

b) for rapid switching, instead of stop the player and resetting it:
just delete it and create a new one
this is a) simple and b) so far proving quite robust... set a field with
URLs to different media types, lock it and
bangaway on the lines as fast as you can, with this in the field script:

on mouseup
   set the alwaysBuffer of the templatePlayer to false
   set the showcontroller of the templatePlayer to true
   put value (the clickline) into tUrl
   set the defaultstack to  "Check Media" # just a separate window for
movie display
   lock screen
   open stack "Check Media"
   delete player "mediaCheck"
   create player "MediaCheck"
   set the filename of player "MediaCheck"  to  tUrl
   set the top of player "MediaCheck" to 10
   unlock screen
   start player "MediaCheck"
end mouseup

It works pretty well...



I note that iTunes has moved away from sending people to a browser page
to watch a movie.
It is doing some wierd thing where it calls the browser and then
redirects you back to the iTunes
interface... I don't know what that's all about...why they need to
invoke your browser at all..
doesn't make sense...

But it is more and more trying to be the robust remote desktop client
app that Rev is already good at.
But Apple's implementation is, surprisingly, pretty "wonky"  if I click
on a HD 1080 version
of a trailer, sure, it takes up the width of my screen, but just stops
and hangs, while waiting
for more data... leaving the user in that anxious state of unknowing  if
his system is hung, or what...
I would think if we can hook players to libURL we can offer a sweeter
user interface...

btw: Adobe's interactive PDF's are even worse... you *can* set a movie frame
to a remote URL and it might or it might not work, and Acrobat
officially does not support
such  http feeds to movie frames, you must either embed (ridiculous for
a PDF that's
trying to show, say a 50 megabyte 20 movie) or call the movie from the
local harddrive.










More information about the use-livecode mailing list