This may or may not be applicable, but I noticed similar behaviour with Real
Player. SMIL uses an HTTP transport whereas movies by themselves (can) use
something else. The problem in my case was that the corporate firewall
required a password for HTTP traffic but not for the other protocols.
So the issue is probably with the transport protocol and how it is treated
by proxies, rather than anything inherent in the SMIL or the transport
itself. The solution would be to get the sysadmin to change the rules in the
proxy server, then your users would not need to make individual
configuration changes.
Jeff
> -----Original Message-----
> From: email@hidden
> [mailto:email@hidden]On Behalf Of Neil Finlay
> Sent: 25 November 2003 16:14
> To: quicktime-talk
> Subject: SMIL and SOCKS server
>
>
> Hi
>
> As part of a project I produced a synchronised multimedia
> presentation using SMIL in QT.
>
> On testing I discovered that many of my target users could not
> see my presentations even though they had
> installed the latest QT. Through trial and error I discovered
> that the problem was the use of proxy servers
> behind corporate firewalls was blocking the SMIL.
>
> The video on its own had no problem but as soon as it was part of
> a SMIL presentation, no chance.
>
> The situation could be worked around by turning off the use of
> the SOCKS server in QT for Windows. This is
> not a practical solution for most of my users and I am therefore
> having to look at alternatives SMIL and QT.
>
> Has anybody else encountered this problem? Even better has
> anybody found a practical solution.
>
> The SMIL is being served from an Apache web server from an XSLT
> stylesheet in MySQL using
> application/smil content type.
>
> Thanks
> Neil
_______________________________________________
quicktime-talk mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/quicktime-talk
Do not post admin requests to the list. They will be ignored.
