Streaming Media
Principles & Cataloguing

This article is appendix to previous one called Hunting for clips‘ URLs. I have got a few mails as reaction meanwhile, most of them kind and polite, with request to extend that article with short description and introduction to streaming protocols. Because, some of downloading tips are written as axioma (true to be believed).

They have true - it is complicate to use some tip, if you have no idea why it should work. I will try to write this using the style „look, how it is easy“. The reason is, that I suppose, that those mails senders can find only marketing information - which says, in fact, nothing - or high-quality technical articles written in style „look, how I am smart“. The fee, I have to pay choosing the popular style is technical precission and necessary simplyfying.

[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]

If you are an professional programmer or web-page designer, you will probably find nothing new here.

I suppose, you have read mentioned article already as well as Net Transport help files and FAQs, so a lot of information I am going to skip. If not, please take a quick look there first, and then return to this article.

The page is designed to 1024 pxl wide true-color screen using Times font face as default.

There is no content, because this article is so short, it can be called info.
It is also supposed to be read from beginning to end.

HTTP & Streaming-protocols

HTTP protocol is suitable to transform all binary data. You can get exact copy of everything you know HTTP URL address ( i.e. beginning with string „http://“) and, of course, you have rights to access. Text and progressive image formats (you can see how they are drawing in your browser) - both need not to be downloaded fully to see content - are treat as abstract binary data, because they are, in fact.

The most important word in previous paragraph is „exact“. Really, only exact copy. In fact, robustness of HTTP transfer is its priority and when to guarantine this requires 1/3 of communication capacity for CRC (error-feed-back), it will get it. So, in those extremally rare cases, when you download a bad file copy, it is almost everytime your fault or there is wrong file on server already. Download manager is programmed to eliminate all of your fault, by the way.

Streaming protocols, such as RTSP or MMS, throw away this „exact“. It can do that because of special file design. If HTTP priority is error-free transfer, the streaming protocols priority is pack all information to not exceed theoretical bandwidth.
For sure, it will not suprise you, that clips inner structure is similar to movies. Better say, it is similar to animators work. There are key-frames which contains full information and can be used as start point. And there are stream-frames which contains only differences to previous frame.

Streaming protocols works through players on streaming media servers. Files located on that servers are mostly pre-recorded session. It is a normal clip with its header, supposed to be view from begining. Beside them, there can be also live-broadcasting sessions. They can be hardly called files, even when you use a wild imagination, because you usually enter somewhere into midle of stream and start watching. The difference is enormous - pre-recorded sessions exist physically (however, you access to your personal copy created by server at your access), live-broadcast packets (bytes) is forgotten with the moment they are sent.

What advantages it has?

At first, you can enter into broadcast in almost every point, and you can leave anytime you want to. No need to wait until all media is downloaded to enjoy it. You can watch it at real-time.

The second advantage is so natural that is usually hard to catch at once. You need not to download exact copy to keep the file playable. So what? Well, you can download only so many bytes, as your internet-connection allows you to transport. In result, you get a file copy at lower quality than the quality of source-file, but you will finish - sometimes much-more - quicker.

Picture 1: Ratio of average file-size for pre-recorded sessions - i.e. how many bytes you will download at "optimal image quality". To give you some preview of real life, please look to the following graph. There are file-sizes of one minute clip prepared to transport through different internet-speed connection. Concrete values are not important, just ratio. As you can see, the ratio is about 3 times between two speeds followed. The biggest jump (56k vs. ISDN128, and 256xDSL vs. 512xDSL) are result of video-size and/or percentage - to be strict even presence - of key-frames. Frames rate, video image and sound quality have no such dramatic effect.

The third advantage is, that it allow to come loose very strict error control, which is one of HTTP pillar. For sure, some disturbances can happend, then player will be confused with upcomming bytes that will make no sense for it, because they has been transmitted wrongly. When this occurs, player will wait for another keyframe. It will not try to download wrongly bytes again. In fact, there could be accessible no more (e.g. at live broadcast).

What the producent can get?

At one word, lower costs, because of:

• less file duplication: instead of 6 different file copies, each optimized for one speed producent can provide only one (in theory) but usually 2 or 3 files (56k, ISDN, 512ADSL is typical combination).
• more users can be connected simultaneously, because CRC checking and re-transmission does not occupied connection capacity
• and not the last: simple programming of preview

The similar tendency can be observed on all present content. Internet becomes to be more commercial every day. Partially it happens because of sufficient file-formats with free conversion tools are available. J2K (Jpeg2000), PDF (Adobe Acrobat document) and Ogg-Vorbis (licence-pay-free audio format) - to mention the famous ones: all of them has the architecture which allows to present full file low-quality preview for free and download the rest of bytes (I repeat, the rest of bytes) to increase the sound quality or dpi or color depth, after appropriate pay.

Resynchronization & Quality

As you guess for sure - everything is driven, or in other words, the file possition is given by clock. When you ask the clip for playback, the player will report to server your bandwidth. Server will create a virtual copy of file and point your player to it. Then both start stop-watches (second-counter). And counting. When bytes not arrived so quick, player will first try to skip them. Player will ask directly for sequence according to its own watches. This is called resynchronization. If even this fail, it will pause playing (caching), consequently, after network time-out, playback will fall.

There is another one possibility, which has been called „optimal image quality“ by NetTransport. There is no frames drop possible. When the bytes do not arrive fast enough, the playback will pause. Until another part of smooth continuos playing will be cached.

To keep file playable - de facto, to retain desired file-size and bandwidth - encoder has a few possibilities. We will start with T1 clip. Its quality can be compared with DivX movies. That ones, which are distributed on one or two CDs. When encoder need to modify this clip for 512ADSL or 256ADSL connection, it only degrades compression quality or simply makes less frame amount as key-frames. So result clip is packed more, consequently smaller. When encoder need to make a clip for ISDN128, degradation of quality, will not be enough in the most of cases. So it have to decrease frames frequency. Instead of normal 25 fps or 29.97 fps, it will use only 15 fps or even 10 fps. You will see the clip as it jerk, but still can we talk about some kind of motion. Other possibility, but rare on this level is reducing the video- size. Until now, we use e.g. 320 pxl x 240 pxl video. Encoder will reduce sides to their half. For 56k modem speed is reducing video-size to 160 pxl x 120 pxl necessary. Frame rate will be reduced even to 5 fps. Image compression will be as high as possible.

Everything at previous paragraph can be done only on server side or during preparing the pre-recorded session. Player can only decrease frame rate. Video-size and its compression quality will stay as was set on server side.

Streaming media servers main differences

One more thing: when you connect to server through HTTP, server is on your service. It is - in true word meaning - your servant to serve you. You decide what server must to do. Not at streaming protocols. User ask for clip and declare his vission about how connection should looks like. This vission can be approved by server, but can be also disagree abd overide with server own conditions. Worse, server can demand on its own conditions. When you, as user, will not buy it, you will see no clip. It touches mainly protocols, ports and „optimal image quality“ flag.

And another one: a few paragraphs up, I wrote, that server will create a virtual copy of file. So streaming protocols do not use a physical file – as HTTP do – but something, which exist only temporary at server memory. This is the reason, why you can not change a protocol on already running download.

(Theoretical) Reality

If you do not understand what is going on until now, I hope this example will be illustrative enough. The most important conclussion from previous topics is that quality is always fixed on the server-side. The difference is only at time which takes to download the full quality clip. Or, in other words, the difference is on quality, we will reach during desired time.

The sketch at pic. 2 should be understable even without accompanied text. In all cases, I suppose there are no limitations on server side, nor disconnections. Reference sites offers two players to view the clip: RealPlayer (RTSP) and Microsoft Windows Media Player (MMS). Additionally, there is a link to download the clip. RTSP suppose degradation through dropping the frames, MMS will pause playback till caching is finished. HTTP has no choice - it must download complete file byte by byte. To make sketch simple, there is only one file on server. In reality, there are two of them: RM for RTSP and WMV for MMS.

The clip located on server is 20 minutes long and it is pre-recorded session (so no live broadcast). It has been designed for ISDN dual-connection (128 kbps). Video size is 320 x 240 pxls and frame rate has been set on 24 fps. Physical file-size is around 16 MBy.

There are three different users with different bandwidth. One with classical dial-up connection through 56kb modem, one with dual ISDN connection, so his total capacity is 128kb, and the last one with 256ADSL connection.

Let‘s first check the users whose choose downloading the clip through HTTP. How they succeed? Well, user connected through modem has probably a good sponsor, because downloading the clip takes nearly one-and-half of hour, which is cca 4 times more than actual clip length. ISDN connection manage download in 20 minutes - say, the same time as clip length. ADSL owner has clip downloaded within 9 minutes. All three got identical file copy - they are the same in every single byte. All three videos has 320 x 240 x 24 fps. One more thing is common for them: all three has had completely blocked access to internet during download. They can just pantienly sit and look on percent rising.

The users whose decide to watch the clip at RealPlayer, spend with watching the same time: 20 minutes, exactly. After minor time of initial caching - cca 10 seconds for modem, 2 seconds for ISDN and hard to remark at ADSL - the clip has started to play and playback continued without pausing till very end. The difference has been on quality of this entertaiment. Modem user watch on panoptikum of static images which changes around every half of second. When he opened the statistics, he saw the naked truth: average speed has been 2,3 fps and more than 3/4 of frames has been dropped - they has not been send from server at all. If he was interested about total bytes transmitted through network he should find out something around 4 MBy. Experience of ISDN users has been different. He watched the full clip at quality it is on server side. It can happened that frame rate has been lower than declared 24 fps, however it is negligible percent, which he did not mention at all. ADSL owner enjoy the same experience as ISDN owner. For sure, no frame must be held on server. But, there is one difference. If ISDN user decide to watch another clip simultaneously, he can. But, frame rate on both clip will drop down to around 10 fps. Not at ADSL: his capacity is big enough to see both ISDN clips simultaneously without degradation of quality. When all three users suddenly decide to check something on internet, they will have no problem with this. True, playback quality can worse meanwhile - at 56k modem the playback will probably pause - but after HTTP request is fullfil, playback return to its original quality level.

We can say the same about ISDN and ADSL users and MMS protocols as we said about their RTSP equivalent. But 56k modem owner has completelly different experience - both quality and quantity - than his equivalent on RTSP. He saw the full clip as he had ISDN connection. But he saw 10 seconds sequence, wait another 40 to caching next part, saw it, another pause and so on. For almost 80 minutes, when he saw the final part. If he was interested, he could check that almost 20 MBy of data has been transmitted. Again, no one from this trio has no problem to check something on the web during playback.

MultiMediaServer types

Watchful reader can mind some anomaly between values on RTSP and MMS parts. Well, loosing error-control can be done - among other assumptions - because it send data in format which for sure not been accidentically destroyed by other than 8-bits communication hardware. The pure text is e.g. transmitted at mode like this. Quicker send, but more bytes must be used.

You can find a few protocols to set at Microsoft Windows Media Player options. We must start with HTTP. HTTP ver 1.1 can handle streaming. (HTTP ver. 1.0 can not.) You still can find a few clips using this - you can observe that downloading speed is almost three times higher than it is usual for binary data. This streaming is not so popular, because it can be directly saved. But, on the other side, it has perfect error-check mechanism, which is necessary during transmission on DRM cryted clips. Other extrem is UDP protocol, sometimes refered as MMSU. There is no error-control, even for used channel. It is much more quicker than HTTP. However, it is not popular. At first, because of quality - when something is missinterpreted, you will not see the rest of clip. At second, transmission through channel which is not controlled can be easily misuse. The same can be say about Multicast. TCP (or MMST) is some kind of compromise - it use simple checking method and key-frames. So we can jump directly to any clip part. It can not be save with standard browser functions and Microsoft Windows Media Player can not be squeeze to do that.

Everything is clear? Try to answer to this question: you are going to view clip prepared for 256ADSL through 56k modem. Clip has typical size, say 352 x 240 pxls, high quality image, so low frame rate - say 10 fps. What the clip will looks like (video-size, fps)?

56k Modem specific

The fair questions can be given by 56k modem users. „How this bandwidth, which I set at Net Transport, is related to my internet-service-provider connection speed?“ Well, we must first repeat this question, and be the more precious this time:

„How this Net Transport bandwidth is related to my ISP connection speed, when I downloading a pre-recorded session?“

Hope, you remember that clip bandwidth, or sometimes is called bit-rate, is the (maximum) data rate for stored media file. It does not mean necessary, that it is a rate of which it can be viewed on-line! So, Net Transport during download does not cooperate with server, because it does not send re-synchonozation command. Consequently, server does not know, that the file is not synchronized and it just – very effectivelly – buffer it before sending stream data. This allow Net Transport to keep stream comming regardless of actual streaming bandwidth (de facto, your ISP connection speed). Poetically said – you can empty a glass of milk even through a thin straw. It will take time, of course, but we are not now at real-time, and the file you get will be broadband quality.

„What about live broadcasting?“

Unfortunatelly, because of nature of real-time streaming, server will send stream regardless of your modem speed and a lot of data would be lost. Live streaming bit-rates can only be as fast as your internet link allow.

„How is Net Transport reported bandwidth related to clip bandwidth?“

As for sure you know from Net Transport help files, RTSP bandwidth value (Tools > Options :: Streaming, or Job > New download :: Other settings :: Streaming) is reported to server. As we said before, server will cache the stream data according to this value. The only thing, server will eventually do – when reported bandwidth is smaller than clip bandwidth – is frames dropping. So, in result, we will get a file with the same video-size, but with less fps than original.

You can do a real magic with this option. When you are an broadband owner and you want to make a video-caps from high-quality clip, setting bandwidth to 56k modem is the quickest way. You will get a copy with 1 fps, or even less, and this „static-images-packet“ you can transform to serie with any freeware capture screen application. You can, of course, capture during playback, but in this way, result will be much more smoother and images will be de-interlanced.

Back to modem.

Suppose you want to download a three high-quality RealMedia clips ...

Pre-recorded with bit-rate 184kb (for 256ADSL), all have cca 25 minutes and their reported size is around 35 MBy. What you should do to save your money and time. Downloading them all at „optimal quality image“ makes no sense – you will download 100 MBy all night, maybe longer.

Setting an ISDN speed? Better, but you will have to download one file at once – which is not so great tragedy – and for sure you will not save so much. Probably, only 3/8 of frames count will be droped, consequently result frame-rate will be around 17 fps and you will have to download 15 Mby. How much time it take? 80 minutes, 100 minutes?

What about set your connection speed to required 256ADSL and start download all 3 clips simultaneously? Server will count the same seconds for all three clips. All three clips will have 2/3 of their frames dropped, because of insufficient bandwidth (not real! That one, we simulate – we are downloading from the same server!) All three clips will has around 29.97/3 = cca 10 fps. Not too much, but it can be viewed. Totally we will download that 35 MBy, which has each clip, and we will finish within 3 hours. Maybe less, maybe more.

So I believe, that now you for sure known the answer for question that has been given before this topic. Unfortunatelly, player will have to drop almost 90% of all frames, because the video-size must retrain. Consequently, you will see panoptikum of high-quality images, because your clip frame rate will be around 1 fps.

Clip Index

And short stay at clip index. We have to start from clip inner structure. During all history of signal transmission, there has never been a main problem at device resolutions. The main problem has always been at data bitrate. Even presently, there is no problem to mount 8 MPxl CCD senzor to camera - I mean motion or television cameras. The problem is how to read-transport-process-and-save 8 [MPxl] x 3 [colours] x 30 [fps] x 2 [intelaced-half-shoot] / 2 = 720 Mbps of data every second! The same problem occurs at videorecorders: how to achieve the tape speed considering magnetic heads at level 25 m/sec? When (cassette-)tape-recorder need only 0.045 m/sec. By the way, Sony used a rotated tilted heads.

At middle of 80's last century, the MPEG Comittee has the same problem. Minimum efficiency of JPEG compression is 20% and two-speed CD mechanic experimentally existed with transfer rate 300 kbps. Not too much when comparing with 720 Mbps x 1024 = 737280 kbps, isn't it? This gives us 20% x 300 kbps = 1.4 Mbps for transport at maximum. And it is just too low for sending every frame as reasonable-quality independed JPEG.

So (probably) Autodesk proposed to use its philosophy of animated flics used at e.g. formats FLC or FLI. Just, instead of saving full picture at every frame, we will save only the first frame and later we are going to save only differences between frames. By the way, it is a fact, that it is much more quicker left the point on monitor than redraw it. MPEG heavily expand this idea. At first, there are much more frames with full picture information. Otherwise, it is not only impossible to rewind a clip freely, but even impossible it to transmit - consument can switch on his TV any time. At second, why not to help a decoder? What do you think, what need a less information: storing preciselly diferences, or storing target frame and let decoder to improvise within some margin (both at time axis and at picture "face").

Picture 4: The basic arcitecture concept of every modern video-stream inner structure.
Number of B-frames can vary, as well as interval between I-frames. It is possible, that exclussively I-frames are used.
[ Full picture ]

So the final concept recognizes three types of frames: interleaved, predicted and bidirectional. Interleaved frames contains (among others) full picture. Predicted frames contains the differences which we demand to preserve. Bidirectional contains a motion path how those differences are achieved. Decoder first read interleaved frame (start point), then predicted frame (target point) and then a few biderectional frames. It display interleaved frame, estimated frames interpolated from interleaved and predicted information by biderectional motion path rules, and finally target frame which is sum of inteleaved frame and deifferencies at predicted frame.

You can enter into transmission - no matter if during fast forward, rewind, cut or simply start watching - only on interleaved frame. More interleaved frames results at bigger file size, but gives you a smoother rewind and you can cut the clip more precisely. I say that interleaved contains among others a full picture. That others is synchronization information between video and audio tracks. Interleaved frames are often called an intra-frames. Traditionally, the intra frames contains only picture with no synchronization - so the clip has only single video-stream.

Clip index is, of course, an index at normal meaning of word. It contains only offsets for every interleaved frame. It is result of another practical problem: hard-disk does not write an information continually. So it is impossible to scan through-out whole file and looking for the frame user choose every time he decide to skip something. Clip index is always at the end, because it is not unnecessary when you watch full clip from beginning.

And now, how it is possible, that there are an application such as ASFTools, DivFix or VirtualDub, which can rebuild index? Exactly, they can "rebuild" index: they can scan through whole file at binary level and look for frames marked as interleaved. They collect offsets of these and finally append it to the end of file.

To make an index, is completelly different task. A specially in the case, that clip has only one interleaved frame - so he has had no index before. You need to decompress whole stream and compress it again to create at first interleaved frames at choosen interval and then you can make their index. It can be done very quick and precisely at formats which are open - such as most of AVI codecs, or MPEG. Even when clip is partially destroyed, you can always try to do something as brute-force: you will just try until it starts to give some sense. Worse, if you depend on patent pending or closed commercial codecs. Because you can not go to binary level, but you are forced to call documented procedures, it is quite possible that you will not be able to recover a part after error.

And this is, by the way, a reason why I use a Microsoft Windows Media, or RealMedia only as the final format for publishing and why I always make them indexed. And I recommend you, to do it also.

Future?

I believe that RTSP protocol will win as default protocol for transport a MPEG-4 based media. It is a simle economic calcultion: you can publish only one clip at 750 kbps quality. All ADSL users - no matter if they have download speed at 384 kbps, 512 kbps or 1 Mbps - can watch it. It is irrelevant, that original clip will have 29.97 fps and 384 kbps will "create" a movie with say 15 fps. It is smooth enough to be watched.

There is another reason. ISO through MPEG Comittee and International Electrotechnical Commission gave as condition for approbation of MPEG-4 compilant technology, an implementation of mechanism which will guarantee that media will be encoded-transported-decoded at real-time for desired quality and bandwidth. To say it clearly: it prohibits the pausing playback.

This can be solve in two ways. One: the frames dropping - as it is done at RTSP. Two: multi-resolution streams. As far as I know, Microsoft Windows Media clips can contain a few "versions" of the same scene at different bandwidth. They do it by a few indexes with different interval between I-frames and B-frames.

But because RealNetworks anounced that it will publish RTSP specification - probably royalty free at least for beginning - and even Apple honored this protocol, I believe that Microsoft will stay at its own philosophy "include and widen" (as it done with e.g. Novell Netscape, or Lotus SmartSuite) and will start to support RTSP rather than involve something new.

Of course, they are a lot of other factors which can shuffle MPEG-4 revolution. MPEG-2, or HDTV, have been succesful because the concurents must cooperate: there is no corporation dominated worldwide which can participate to do it at its own acount. The internet market is completely different segmented - both users and distributers can switch to other technology during 20 minutes: uninstall, download, install and watch. In case, that distributer uses a SMIL to publishing, of course. Almost all companies start to follow Unisys way: want to support or use our format - o.k. pay us. From the last year it happens with MP3 (Franhoffer institute, Enlargen, Germany), causas Cisco vs. Linux, or Sun vs. Microsoft are almost legendary, and even JPEG - Compression Labs let it royalty free, the new owner Forgent Networks start to claim charges. And, as the last one to mention, i is only question of time, when telecoms starts to hate a flat-rate-xDSL: they really loose a lot of money.

So, as you can see, all investors have a few facts to consider before they start to invest: no matter if to producent, or distributor. And when they finally decide, they can suddenly discover, that there are no consuments - because of telecoms. I hope, that at least Eurobird-1 satelite will fullfil its expectations.

Digital Rights Management clips

Digital Rights Management, the term is usually short-cutted to DRM or DMR, is general term for „owner exclussive content copy protection“ technologies. True is, that this technology is „copy prevention“ like. In present, they are applicable to DivX media, Real Media, Microsoft Windows Media. Except of DivX, there are two generation of DRM, refered as version 1 and version 2. As you can guess, all companies use their own variants of the same basic principle. For us, the details are irrelevant for now, so we will talk generally.

DRM allows servers identify concrete player on cocrete computer and provide clip for it. This is a reason, why there are an options which allows player identify uniquelly.

• RealPlayer :: View > Preferences :: Support :: Send RealServer data
• Windows Media Player :: Tools > Options :: Player :: Internet options
• mplayer2 :: View > Options :: Player :: Others

DRM1 is based on flags. These can configure players, to not play clip unless you are physically logged at concrete www-site. Simillar technique is used by fonts and PostScript users for sure know, what am I talking about – because their licence not allows embeding, substitions fonts is used during printing or exporting to PDF.

DRM2 is based on licences, which defines how many times within some time-interval, clip can be played. Players save this licences at special crypted file, or even at clip-file itself (RealMedia, DivX), together with last used date/time stamp (because of turning system clock back). We should back-up them (WMP :: Tools > Backup licences) before re-installing the system, and presently, even updating players and/or any manipulation with hardware.

Clip is crypted and server transmits all necessary hash-codes to decrypt it. If you have valid licence. Therefore there are other „copies“ of player on other computers, clip will not be playable on them. Therefore stream is decrypter at player, it is possible that – when you have „secure path“ hardware – it turns to be impossible to capture video through TV card.

So, the question is not: „May I download DRM files?“ but „Will I be able to play them?“

You will probably download the file – you can find out clip URL and, if the server will want to communicate with anonymous player (i.e. Net Transport) or will grab your player identifier itself, you can also download them. URL protocol will be probably HTTPS, because server send an encrypted data, so it must be error-free transmission.

If clip is protected by DRM1, non-standard players can play them, or there is a good chance that converter will ignore licence flags.

Worse, if clip is at DRM2. This has been broke at Windows Media (it works on WMA as well as WMV) at 2001 and it works perfectly, so it really can free clips from licences. However it is not an easy task, because you have to do a lot of things during very short time, to obtain and save hash-codes. DivX DRM system is – by producent own word – „so cheap, that no one will try to break it.“ They declare already, that they will realease source codes for Linux, so we will see. RealMedia will not be downloaded, because all „recorders“ are confused with crypted data and they suppose, it is not a RealAudio/RealMedia clip. Net Transport can download a raw stream, however it will not be playable, because it is crypted and without hash-codes.

And we will finish on this. All basic and necessary information to understand streaming media principle have been already wrote. I do not suppose user can be interested with futher technical details - most of them is unofficial. If you are interesting about tools, converters and DRM weakness, you will have to find them alone. I am not going to help you with this.

But when you have any other question or constructive comments for rise up this short-info educational value, you are welcomed and thank you in forward. Please use some meaningful subject at your post.

Appendix:
Average file-size and video-quality for particular formats

Picture 1 with ratio of filesize for pre-recorded sessions results with a few requests for concrete values and for comparission of video-formats. I have got also an e-mail, which says "... streamed media are not good. ASF is piece of ...(garbage)..., its quality is incredible. MPEG rulez!" The sender has no idea what is he talking about, and I personally have doubts, if he reads an article, or just look for header.

I can agree with you, that there are a lot of reason why to dislike mentioned ASF, but its theoretical possibilities of quality is not one of them. Prepare an ASF from DVD video using HDTV-2Mbps profile, and I can guarantee you that even osciloscope will not find a difference between it and MPEG! And, of course, you will get an ASF clip which will need 25 MBy for one minute. And reasons why to really dislike it? - active scripting, definitive format, patent pending, disynchronization during real-time (therefor it can not be done quicker, because of Microsoft codec) conversion to e.g. AVI.

So, by my personal opinion is not quite fair to compare particular formats. Following table and graph should be review, with this to remember: bigger picture, more quality and precious detail - so you can view it even on 1600 x 1280 screen - needs more space. I have been looking over internet for streamed files, presented to be viewed on-line. At the following table are average values from a few dozens clips. Picture 3 is its graphical representation.

Picture 3: Graphical representation of average file-size for most common quality of particular video-formats.
Please, attached table for details and read this chapter before judgement.

One tip, before continue: when you find somewhere on internet (or at Peer2Peer networks) MPEG file, you can be almost sure, that it will be TV-captured transmission, consequently that there is somewhere its streaming original, which has 1/10 of MPEG file-size.

Players in use according to Nielsen//NetRatings

		November 2002	April 2002
	Microsoft WM Player	49.8	17.0
	RealPlayer	33.4	15.1
	Apple QT Player	16.8	7.3
	These are absolut numbers of installations in millions. The fact, that one user can use more players simultaneously is ignored! Sorry for updated information. Actual world-wide datas are members only.

Net Transport & Multi-Segment RTSP

Net Transport is probably the only one application which can download RTSP in more than single segment. It realize this by very elegant tricks. However, a few people have been confused when they use this. A specially, at the download end. This short notice is about mechanism behind this. Please look also at Net Transport Help's FAQs.

The basic fact is that RTSP does not use a fixed length of chunks, or packets. "Packet" you can treat as Demokritos treats "atom" - the smallest and futher undivideable element from which is the clip built. Because the length is not fix, Net Transport can not know how big is the clip during download. It can only guess its size. This is reason why the download sometimes continue over 100%.

Variable length of packets has one more logical effect: Net Transport must download every segment into its own physical file. Again, it can not know precisely, where the another segment will start. For safety, it will download a few bytes extra for every segment. In this way, the segments are overlaping, so there is a reason to believe that resulted joined file will be correct. I mean playable.

I think, I mention it somewhere, but to assert: all disk operation has uninterupted priority at Microsoft Windows. Have you ever read a corrupted CD, or diskette? Does the computer "stop respond" during reading? I believe, you have meet this. Similar happens after Net Transport finished with download. All segments are copied byte by byte and joined together into single file. It takes some time - a specially at very big clips or on low-speed hard-disks, as well as need some free-space on disk.

Considering all of these facts, I recommend you, to use from 2 to 5 segments for RTSP at maximum. I personally use 2 segments and only at very rare cases my transport speed is not from its upmost quater. Do not use a compressed NTFS partition - reported free space is only estimated and disk operations takes much more time. Do not let your free space capacity on disk falls below a few GBy! Say, that 4 GBy you should take as absolute minimum.

Net Transport & Make ASF Indexed

The command Make ASF indexed should be used for every Microsoft Windows Media clip you download through MMS protocol. You will get an original clip index - if this index exist, of course - which can be priceless when the clip is not completelly error-free. Using this command for clips downloaded via HTTP / HTTPS / FTP protocols makes no sense, because you will download an exact presumeably error-free copy from server.

Why Net Transport ignores the index? Therefore, it can not know, where the file will finish. Consequently, where to put the index. As we know, the index is always at the end of file. Is it really important to obtain the index? Yes, it is. For two reason: MMS protocols use very simple mechanism for checking transmission errors (or even does not check them at all), and it is quite possible that we will not be able to rebuild index for whole file. More details about MMS servers and clip index are above at this document.

Legal stuff

If anyone wants to translate this, he is welcome. If you need a permission, you have got it in forward: "fair use" for non- profit purposses exclussive with source and credits mentionned. Please, see here for full details.

Copyrights

The brandnames protected by trademarks or registered trademarks appear through all text. I have made a conclussion that I use this names exclussively for informational purpose. Therefore, the appropriate trademark symbols are not accompanied every single reference. They are listed only here. Instead of that, there is always producent named This solution I accepted only for convenient of readers and goods of trademarks and rights legal holder, not even mention of aim to disturbe or break these rights in any way.

DivX™ is trademark of DivX Network, Inc., ©2002

ISO® is registered short-name of International Organization for Standardization.

HTTP as short-name of Hypertext Transfer Protocol, HTTPS as short-name of Secure HTPP, HTML as short-name of Hyper Text Markup Language, are all generic terms and intelectual property of World Wide Web Consortium (W3C®), © 1994 - 2003

Microsoft®, MMS® as official short-name of Microsoft® Multimedia Stream protocol, Windows® Media Player® also refered here as WMP and WM Player, WMV© as short-name of Windows® Media Video are registered trademarks or trademarks or copyrights of Microsoft Corp., ©1985 - 2003

MPEG, MPG, MPE, MJPEG as official short-names of Motion Picture Experts Group video-technology is intelectual property of Motion Picture Experts Group and ISO, © 1983, 1985

Net Transport (including Net Transport logo) is copyrighted by Kevin Wang, ©2003

Nielsen//NetRatings™ is service mark and trademark of Nielsen Media Research and NetRatings Inc.

Pepsi® and Pepsi-Cola® are registered trademark of PepsiCo.

PostScript® and PDF® as official short-name of Portable Document Format are registered trademarks of Adobe Systems Incorporated, ©1987 - 2002

QuickTime® refered here as QT and QuickTime® Player™ are registered trademark or trademarks of Apple® Computer, Inc., © 1997 - 2003

RTSP as official short-name of Real-Time Streaming Protocol, Real® Server, Helix Server®, RealPlayer™ and RealOne™ Player refered here also as RMP are registered trademarks or trademarks copyrighted by Real® Networks™, ©1994 - 2003

 

Updates

2004-05-05
Added part about Net Transport's own features for real-time protocols: what's going on when downloading multi-segment RTSP, and indexing ASF downloaded by MMS.

2003-11-20
Added part about clip index. Added part about transport protocols future. Nielsen//NetRatings moves actual information about digital entertaiment industry into members section, so I can not update info about players in use.

2003-07-09
Picture 1 caption extended. Appendixes are added - average file-size for video formats and connection speed, players in use. One mail quotation and discussed. Two new pictures.

[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]

Marián Stach, Prešov, Slovakia, Central Europe
2003-06-12, 2003-07-09