It's always a bad idea too fast to reply to Richard's mails ! After reading it twice...
but the same file wrapped in a SMIL document triggers a streaming behavior from QT, such that the media starts playing as soon as even a small amount of it has been buffered.
Nothing tested from the below draft, at this point...
We can expect that the SMIL tags are acting, in HTTP (GET) mode, exactly as the QTSS indications in RTSP (POST) mode... So, a very height potential input , Friend ! Thanks to point our attention on this ;D
1.- If the QT player plays each amount of the movie sequence as soon as the next SMIL tag is downloaded, it could be, for us, a way to serve the clients in a "streaming-alike QOS" mode but without using any QTSS nor Helix server (nor their fat indicators to serve, along the movie datas), as soon as we use the right way to replace the Apple's QT player by a Rev's one...
2.- In replacing the Apple's QT player by a Rev app, there are, probably, ways for us to setup, on a P2P basis, a movies playback networked solution, where each connected Rev's QT player will, mainly, act as a server for the next one, and where, in a "one to many alike" mode, for each different movie to be served, only the first request will be outputed from the provider's main HTTP movies host.
3.- In using the Rev's players callbacks features along the movies are playing on each client, it will be a way to let them send, as POSTs, declarative messages to the main HTTP movies host : the IP addresses of the clients able to relay the served movies, with, for each, the local currentTime value of the cached movie, so the mainserver can relay/forward each new client "time lined"request in the most adaptative way to one of the next connected Rev's P2P QT playback app...
Lost to test before having this kind of set-up available in production mode but, for sure, an interesting project, because your starting point mail, because Rev and because we enjoy that all so much ;)
Thanks again so much, Richard.
Kind Regards, Pierre
Le 9 mai 04, à 21:03, Richard Gaskin a écrit :
Pierre Sahores wrote:BTW : just a little off topic... Do you have any web docs entry points to share about streaming QT/MP4 contents in a "one to many" sheme, runnable in IPV4, without having to send a different stream to each conected user, something like binding the IPV6 broadcast address witch could work in IPV4 mode ?... IPV6 is so great, as dream ;)
It's a rare day when I can lend a hand to Pierre on Internet stuff, but maybe this will help:
This help lots, yet, after reading your input more carefully !
In some limited testing here I've had surprisingly good results playing SMIL documents in player objects. What impresses me most is that you can use media stored on any normal Web server: when playing a media file from a Web server directly QT insists on downloading the file before running it, but the same file wrapped in a SMIL document triggers a streaming behavior from QT, such that the media starts playing as soon as even a small amount of it has been buffered. QT's handling of media referenced within SMIL documents appears to be much more efficient than even using the quick-start option.
So conceivably, if the goal is to send different media to different clients, one could write a Perl or Rev CGI to generate the SMIL on the fly, referencing different media as needed.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________ Rev tools and more: http://www.fourthworld.com/rev _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
-- Bien cordialement, Pierre Sahores
100, rue de Paris F - 77140 Nemours
[EMAIL PROTECTED]
GSM: +33 6 03 95 77 70 Pro: +33 1 41 60 52 68 Dom: +33 1 64 45 05 33 Fax: +33 1 64 45 05 33
Inspection académique de Seine-Saint-Denis Applications et SGBD ACID SQL (WEB et PGI) Penser et produire "delta de productivité"
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
