Downstream Margin:
Upstream Margin:
Downstream Line Attenuation:
Upstream Line Attenuation:

This is my testing to show what happens. I have checked on this many times over many days and the results are reproduceable.

Last test I did was today around 3.30pm.
Step #1
Two files are uploaded to a local web server.
First file is v10.zip.
Second file is v10.flv.
Both are 10MB in size. .
v10.zip is NOT a real zip file.
v10.flv is NOT a real video file.
Both are the exact same text file with different filenames.
Running MD5 check on each file produces the same checksum string indicating the contents  of both files are exactly the same.

Note #1
Using a local server eliminates any international connection or congestion issues.
Using the same text file eliminates any filtering based on actual file contents such as zip or video file header identifiers.
Step #2
Using IE7 browser, each file is downloaded using http method (direct download).
Each file is downloaded one at a time.
No other downloads are running at the same time.
No download managers etc are running at the same time.
No proxy server is being used.
A 1Mbps Streamyx connection is used.
A 1Mbps Jaring  connection is used for comparison.

Note #2
Using direct download eliminates any other factors that may influence the results.
Using a Jaring connection as comparison eliminates any problem with the local webserver.

Results
v10.zip download rate is approx 100KB/s using Streamyx.
v10.flv download rate is approx 25KB/s using Streamyx.
v10.zip download rate is approx 105KB/s using Jaring.
v10.flv download rate is approx 105KB/s using Jaring.

So its only with the Streamyx connection where there is a difference in the file download speeds. The downloading can be repeated again but the results are the same.
Step #3
v10.zip and v10.flv are downloaded using a FTP program using streamyx.

Note #3
Using FTP and getting normal speeds eliminates any connection or congestion problems with either ISP networks or the webserver hosting the files.

Result:
All FTP downloads are at approx 105-110KB/s irrespective of file extension.
Comparison testing:

Step #4
Video files (.flv) hosted on a local server are streamed using HTTP progressive download method using a embedded flash player. These video also do not play smoothly using the Streamyx connection due to the constant play/stop/buffering  cycle. However, the videos play smootly using the Jaring connection.

Note #4
This eliminates  that it is only YouTube video being throttled. The same slow down also affects other video streaming.
Conclusion:
Nothing to do with YouTube network or servers.
Nothing to do with Streamyx users side.
Nothing to do with local network connection or congestion.
Nothing to do with international network connection or congestion.
Nothing to do with DNS or routing etc.

So, TM is throttling  http download and video streaming speeds for .flv file extension?
Remarks:

1. There are times where the v10.flv can be downloaded at full speed of approx 100KB/s like the v10.zip file. It is dificult to determine exactly when and under what conditions this can happen. At that time, YouTube  video seems to stream smoothly as wel.
Perhaps at those times the throttling is removed or there is some sort of random throttling going on.

2. An additional quick test similar to listed above using a v10.swf file also downloads at approx 25KB/s.  So .swf are also being throttled.

3. Using a proxy, the videos stream smootly, again pointing to throttling on TM side for direct Streamyx connections.

4. The low rate at which the throttling is set to is not acceptable as you can hardly watch videos with constant pauses for buffering every few seconds. At the very least, the rate of throttling has to be increased to maybe 40-50KB/s (not sure exactly) for smooth playback.