Rev's P2P QT playback app draft (was: Data Protection)

[Pierre Sahores]

Hello again, Richard,

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
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

-- 
Bien cordialement, Pierre Sahores

100, rue de Paris
F - 77140 Nemours

psahores+ at +easynet.fr

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é"