Difficulty level: |
Information for: |
||||||||||
surfer |
|||||||||||
"John Doe"layman |
expert |
web-master |
|||||||||
[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]
There are only two topics with some additional information which touches exclussively Net Transport. In concrete: a multi-segment RTSP and ASF indexing. You should read definitelly a "Streaming Media" tutorial. This document base on information provided there.
Net Transport is probably the only one application which can download RTSP in more than single segment. It realizes 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.
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.
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 1: 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.
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.
You can translate or link this tutorial under conditions written at this domain's "Legal Stuff" page and followed. If any doubts, please contact me.
Copyrights, trademarks and credits are collected here.
Marián Stach
Prešov, Slovakia Central Europe
2004-05-31
[ Language ] :: [ Main Index ] :: [ Site Navigation ] :: [ Tutorials ] :: [ Downloads ] :: [ Contact ]