Streaming video is slow and choppy thru Wingate

[saubrey]

Streaming video (asf) file is slow and choppy when played thru Wingate. What can I do about this? I have WG 6.04 running on a Win2k server. The client computer is also Win2k. I reset my video card to 256 bit color on the client and still streaming video is choppy and slow.

Playing the exact same streaming video on the WG server is fast and smooth. I've done it four or five times on the WG server and it is always fast. Always on the client it is slow and choppy.

There is no excessive CPU utilization on the WG server or client computer. The one thing I did notice is that when played on the client, Gatekeeper on the WG server shows an HTTP connection for the asf file. However, when played on the WG server there is no HTTP connection for the asf file...somehow it is bypassing the WG server eventhough all other IE traffic that originates on the WG server does use the WG HTTP proxy. (I've configured IE on the WG server to use Localhost:80 for a proxy and WG's http proxy is configured for port 80). For some reason the asf bypasses WG which is why I think that somehow WG is slowing the stream.

Can you help with this? Thanks, Steve

[MattP]

Hi Steve,

Are you running KAV? If so is drip feed large files turned on? It could be that KAV is trying to scan the stream which is causing it to come through slowly.

[saubrey]

I turned off drip feed on the http proxy services and the streaming video doesn't play at all. It seems like the entire streaming video file must be downloaded by WG before it sends it to the browser, but the browser times out while waiting. Even if it didn't time out, I don't think it is acceptable to wait 15, 20, or 50 seconds for the video to begin playing. Do you have another suggestion?

Do you know why when I run IE on my WG server the streaming video request is not served by WG's http proxy? All other IE HTTP requests are served by WG, but the asf file isn't. This seems to be ideal. The streaming video plays fast and smooth becuase WG isn't involved and all other http requests go thru WG and get Antivirus scanning. I don't know why/how this happening on the WG server, but it is. How can I make this happen on my client computers? Or how can I configure WG to not stream asf files thru the HTTP proxy? Or can I configure WG not to AV scan asf files? It seems like there should be a way to configure WG, but I can't find it. Thanks for your help. Steve

[ImmediateAction]

can ya give an example link?

[saubrey]

www.msn.com. There is a section in the middle panel titled "Video Highlights". All the video seems to be asf files.

[saubrey]

I disabled the AV plug-in for the HTTP proxy service and then the client computer plays fast and smooth streaming video. But with the AV plug-in enabled for the HTTP proxy, the client plays slow and choppy video. So it seems that the HTTP proxy AV plug-in is causing the choppiness. Is there a workaround or fix for this behavior? The CPU utilization on the WG server is 10%. Thanks, Steve

[jamesc]

Just as an idea which I cannot claim I have tried... if your clients are using Windows Media Player to watch the streams, there is an option in there to send request to alternative proxies. Maybe you can create a new www proxy service, turn off the AV, and put the new proxy address into WMPlayers options?

[saubrey]

Your suggestion of creating a new www proxy service and setting Windows Media Player to that proxy works well. It seems that when a video plays in an embedded window within IE it is using the Windows Media Player (at least in my example) and honors the Media Player's proxy, and because I've configured this www proxy to not use the WG AV plug-in the streaming video plays fast and smooth. However, configuring separate proxy services withou AV scanning is not an ideal solution. While streaming video plays smoothly, *any* request made by Windows Media Player is serviced by this proxy. This includes requests for html pages, etc. So these requests will not have AV scaning performed on them. So while the separate proxy solution does work well for streaming video, it introduces another, more serious problem.
Qbik, do you have another suggest/workaround?

[jamesc]

I will have to do a bit more playin round with this, but I would appreciate any feedback (Please notice the Default Rights set to ignored).




Also, there may be a better policy for this, I will have to check with some of my support colleagues when they are available.

And to finish it off, I will just give you a quick backgrounder on why I used seperate "Filters" for the criterions.

The image shown says " If Filter 1 has .asf in the address, let it through. "OR" if Filter 2 has .wmv let it through
If I was to have both criterions in one filter, it would be .. " If the request is for a url that contains .asf "AND" .wmv, let it through.... So if you had it that way, you would require a Windows media file named for example .. test.asf.wmv ... and thats probably like winning the lottery ...

P.S I could take a .wmv file and change the extension to .asf; it would still work. Those are the two main file extensions for Windows Media player files. I presume MSN use the .asf format to be backwards compatiable with earlier version of Windows Media Player (depending which codec was used to encode it.)

[saubrey]

I understand that you are suggesting that I can configure the www proxy indended only for streaming video to reject all requests that are not for .asf or .wmv files. This closes the loophole of Windows Media Player requesting HTML files and not having them AV scanned. But it also means that Windows Media Player will not be able to make any requests for non-asf/wmv files. This restriction severly limits the usefullness of the stand alone Windows Media Player. Or maybe I am misunderstanding your suggestion.

So far, the best idea, although I still don't know how to do it, is to have only one www proxy, used by all clients and programs, with AV scanning on, but with AV scanning for ASF files off. So I'm suggesting a way to filter for AV scanning. An even better solution would be to determine why AV scanning is causing choppiness and fix it, but maybe it is not easily fixable?

Am I the only person who has run into this choppy play back of streaming video issue if AV scanning is On? I do have a slow WG server. It is a 366 MHz with 256 MB RAM (Win2k Adv Server). But cpu utilization on the WG server is only 10% during streaming video playback, so eventhough it is slow it is not CPU bound. Maybe the WG server is I/O bound during video streaming? I'll check for this tonight.

[saubrey]

My WG server is not disk I/O bound, so that is not causing the choppiness. What I did notice is that with AV scanning On, the network throughput on the WG server's external NIC is low when playing streaming video. It is about 150 Kbps. But with AV scanning off, throughput is about 700 Kbps. There is no difference in the WG configuration other than AV scanning on = 150 Kbps, AV scanning off = 700 Kbps. No wonder streaming video is choppy and slow.

So what would cause WG to have low throughput on the external NIC with AV scanning On?

[jamesc]

Will pass on these details to the Development/QA team tomorrow, and see what feedback they have.

[saubrey]

James: Do you have an update on this?

[jamesc]

I have been informed that the next version of KAV will have the ability to exclude specific file types from being scanned within the proxy.

After a considerable amount of tests on a slow computer, the best solution found for your scenario is to use the one I mentioned previously; have a second proxy allowing common multimedia formats.


Windows Media is set with the following file types.

Windows Media file
.asf
.asx
.wpl
.wm
.wmx
.wmd
.wmz

Windows Media Audio
.wma
.wax

Windows Video file
.avi

Windows Audio file
.wav

Movie file
.mpeg
.mpg
.mpe
.m1v
.mp2
.mpv2
.mpa

MP3 Audio file
.mp3
.m3u

Midi file
.mid
.midi
.rmi

AIFF file
.aif
.aifc
.aiff

AU audio file
.au
.snd

Micorsoft Recorded TV Show (dvr-ms)
.dvr-ms

*I have put all these into a policy for "Everyone" using the --> HTTP Resource "Contains" syntax

This has been exported to the test lab tonight, and worked fine. I will have to ask the developers tomorrow morning if they can verify my procedure is correct and compatible for others... I will place a link here tomorrow (I hope) so other users can set up in a few clicks.

[jamesc]

Created this service in Windows XP SP2 / Wingate 6.0.4
Have exported into Windows 2000 / WinGate 6.0.4. Worked as expected.


Before you continue, Please backup your WinGate Registry and Create a system restore point.

The link below will create a new service called WMP Proxy Service on port 8081.
Please make sure you do not have a service with the same name, or a port that has already claimed 8081

Available from here
unzip the file
double click the WMPFull.reg file
Yes
Stop the WinGate Service
Start the WinGate service
Navigate to your services tab (bottom left)
Confirm WMP Proxy is there.

To use the Windows Media Guide, have a look in your history and add those policies in. I noticed localised data from New Zealand when I was using it.

[saubrey]

OK, I will do what you suggest. However, the standalone Windows Player also makes GET requests for HTML and they will be blocked, so the standalone Windows Player will be crippled.

I realize that I have a slow server, however the cpu utilization on it while streaming video is below 10%. I'm not sure I understand what is causing the slow, choppy video on my slow server.

Thanks for all your help on this.

-- Steve

[jamesc]

Do you mean what I said with the Windows Media Guide??

To use the Windows Media Guide, have a look in your history and add those policies in. I noticed localised data from New Zealand when I was using it.

(e.g add in policies for HTTP URL contains wndowsmedia.com)

Edit:

"Click" I see what you mean. And it is a concern for automatic codec downloads too. I will have to think about this. I could of also recommended using the RTSP proxy, but when I was testing on a low spec machine, the WMP Player proxy was performing better, and hence the recommendation.

[saubrey]

I'm now having the same choppy streaming audio thru AOL's audio player due to the KAV plug-in thru the WWW proxy. (The AOL player is accessible off www.aol.com under the section "AOL Radio") If I turn off the KAV plug-in then the AOL player streams very smoothly. The URL that the AOL player uses for streaming video looks like: http://64.236.34.101:5190/stream/7248. The AOL audio player doesn't have its own proxy setting like the WMP has, so I can't force it use the WWW proxy that I configured with KAV turned off. The Aol player just uses the browser's proxy settings. I'm not sure what a solution is for this...do you have suggestions? Thanks, Steve

[jamesc]

Hi Steve,

I have got the AOL Radio web interface going, and can listen to music. When I go to the player setup, I am unable to view the Connection Settings Tab, and the help button just shows me a blank page.

But after looking through my C:\, registry and Program files... I "believe" I have found the solution. Navigate to C:\Program Files\Common Files\Nullsoft\ActiveX\2.6 and use the ProxyConfig.exe tool. (I was using WinXP Pro SP2 and WG 6.0.4)

Let us know how you get on.

[saubrey]

I found the ProxyConfig.exe tool and set the proxy, but radio doesn't use it. HTTP requests are still going to the default proxy.
The "Player Setup" button doesn't allow much control. All it allows is to set the radio pre-sets and to choose between dial-up and broadband.

[saubrey]

Any update on this? Is there a Wingate solution or enhancement in a future release that can fix this problem? Thanks, Steve

[jamesc]

Hi Steve,

I get a differnet result. And I am using NAT as well, but that should not interfere with the radio "not playing" as described below.

Set the ProxyConfig tool to a proxy server that does not exist.
Everything will load, but will never play the radio. When I do a netstat I see "Syn_Sent" to the non existent proxy.

Set the ProxyConfig tool to a proxy that does exist, everything loads and starts playing the radio.

Can you please confirm this is the case? Because if it is, you just need to create a new proxy in WinGate, and point the proxyconfig to it.

[jamesc]

Also Steve, when you said

HTTP requests are still going to the default proxy

I "believe" that is the webpage traffic, not the ActiveX control.

[saubrey]

When I set the proxy, using the Proxy Config tool, to my WG proxy that has the AV plug-in turned off (proxy 2), the radio did not use that proxy. Instead the radio used the default WG proxy (proxy 1) that has the AV plug-in turned on. The radio played, although the audio was choppy. I know that the radio did not use proxy 2 as I turned on logging for proxy 2 and nothing was logged. I know that the radio used proxy 1 because I turned on logging for proxy 1 and it contained a log entry for the radio's HTTP request. So I have to conclude that the Proxy Config tool that I used doesn't control the radio that I used. I don't know why it doesn't, but it doesn't.

OK, so maybe I can root around and find another Proxy Config tool that does control the radio that I'm using and have smooth streaming audio using the radio, but that is not a good long term solution. I can't go to every client computer and pre-determine what radios might be used and attempt to pre-configure a proxy for them that doesn't use the AV plug-in.

Instead I'd like to find a solution on WG's side that will fix this problem for all clients and all radios and video streams. I have to ask why is streaming audio & video choppy if the AV plug-in is on? CPU utilzation on the WG server never goes above 5% so CPU isn't the problem. I checked other WG resources like available RAM, sockets, network utilization, etc., but can find no resource that is in short supply that could be responsible for choppy audio/video.

Is there a WG solution for this problem? Am I the only person experiencing this problem?

Thanks for your help, Steve

[adrien]

hi Steve

It's fairly common for media player applications (i.e. Windows Media Player, RealPlayer etc) to support multiple transports. Normally they try a protocol like RTSP first, which uses UDP packets for the streaming media.

If that fails to connect, quite often they will try a TCP connection, or HTTP. Most clients will look at the proxy settings on the machine they are on.

So, most likely when you run media player on the wingate machine, it is making a "native" RTSP connection, so isn't using HTTP at all.

Whereas the client is having trouble making an RTSP connection and fails over to HTTP.

HTTP is a much worse protocol for streaming media for several reasons - firstly because it is TCP-based. Streaming media protocols are normally designed for a certain allowable level of packet loss. there is no re-transmission normally. However with TCP (which HTTP uses), any packets dropped are timed out, acked etc etc, which has various timeouts.

this makes for choppy video.

Having said all that, there is an RTSP proxy in WinGate - have you tried getting media player on the client to use that?

Adrien

[saubrey]

I understand what you say, but if I turn off the AV plug-in in WG, then the streaming audio/video is not choppy, and the stream is still using HTTP. So the usage of the AV plug-in in WG is causing the choppiness.

I don't think this particular AOL radio player ever tries to use RSTP. I also have WG configured with an RSTP proxy (with logging on), and the AOL radio doesn't attempt RSTP. It starts off using HTTP. Maybe there is a configuration tool for the AOL radio where I can configure usage of a specific protocol like RSTP, but I have not found it.

-- Steve

[adrien]

Hi Steve

If you have the KAV plugin scanning the media stream, it will want to receive it all before it scans it.

At any stage, it only passes on 75% of whatever it receives to the client if dripfeeding is enabled (else it passes on nothing until it has received and scanned the whole file).

With drip-feeding enabled then, you will get 75% of the data piped through as it comes in - the rest will accumulate in WinGate (could end up with some real big temp files if you are listening to streaming radio which never ends).

Short answer, you really don't want to be scanning media.

Can you put in an exception to stop KAV from scanning the URL you are using for the radio station?

Adrien

[saubrey]

I agree that it is not good having streaming audio/video AV scanned, and I would like to find an easy way to configure WG's www proxy to auto detect streaming audio/video and automatically turn off AV scanning for only those streams.

I have sort of done what you suggest for the Windows Media Player. For it I have configured a 2nd www proxy with AV scanning off, and I've configured Windows Media Player to use the 2nd proxy. It works...although there is one security hole with this approach. The Windows media player, besides receiving video/audio streams also can receive and display normal HTML type web pages. The HTLM pages that it receives will not be AV scanned.

Regarding your specific suggestion of configuring KAV from scanning a specific URL...OK, I can do that if the URL has a set pattern, and maybe in my specific case with the AOL radio I can. But this is not a good long term solution. There are more and more web pages that have embedded audio/video players in them (e.g. CNN, NYTimes, AOL, MSN, etc.) I can't possibly predict which streaming players all my client computers will use and pre-configure KAV for them.

A better long term solution is to only have one www proxy that has KAV on, and then to enhance KAV to automatically detect audio/video streams and auto turn off KAV for those streams. Doesn't the audio/video stream set its content type to an audio/video MIME type? Could KAV key off the MIME type and disable AV scanning for them? Maybe keying off MIME type is too simplistic...do audio/video streams have some signature header at the beginning of the data stream? Maybe the KAV could read and attempt to interpret the first 1K of the stream looking for the signature.

[adrien]

yep

we could key on the mime type... however you then need to trust the server you are connected to to send you the correct mime-type... i.e would hate to see browser hijacking through servers that advertise a mime-type that they expect won't be scanned, although probably most browsers wouldn't display it or deal with it as HTML anyway...

So it's most likely a good option for this.

Adrien