Network 版 (精华区)

发信人: zzn (爱你到内伤), 信区: Network
标  题: mms协议英文资料(26)
发信站: 哈工大紫丁香 (2003年08月23日10:56:33 星期六), 站内信件

Time Codes, media packets and ASF headers for Live broadcasts
Relative and Real Time
We need to talk here about asf time codes. While a stream is being sent to a 
viewer, each media packet contains certain time codes stated in milliseconds. 
These time codes are embedded in each packet of the media and in turn, 
increment in time to the next time code.
If the stream is a pre-recorded media held on a streaming server, the first 
received time code will always be zero. The time codes will then increment as 
the media progresses. This is referred to as Relative time, i.e. t = 0 at the 
start of the file and restarting the file again will reset its t value to 0.
If the stream is a Live stream like a TV broadcast however, the first time 
code received could be any value, depending on where in the stream time we 
came in. This is referred to as Real time. I.e. t = 0 only at the start of 
the broadcast and not necessarily where we came in, it is time as it actually 
happens.
To convert Real to Relative time, we use a simple offset as below:
New relative time = the currently read media time - first packet’s media 
time.
Media packet time conversion on the fly
While downloading a pre-recorded file is a straight forward process of 
copying the media packet (and so its pre recorded time codes within) to local 
disk, for live situations its not so simple.
In the case of a live broadcast, we must convert the packet’s Real time 
codes to Relative time before we can save the modified packet to file. We 
must do this because Windows media player software needs these times to be 
saved correctly. Otherwise the player gets confused, and even though we may 
only have say 10 minutes worth of recording to disk, the player may see it as 
a 1 hour file or whatever, depending on where we came in and not what we 
actually downloaded. Consequently, the file would not play even though we may 
have downloaded actual media data, their time related information would be 
incorrect.
A conversion to Relative time is needed to correct this effect, and in our 
software, we do this on the fly while actually downloading.
To explain exactly which bytes need to be addressed in the packet for time 
modification is a rather complicated process and requires knowledge of the 
actual ASF media packet format. We can follow the rules of the ASF format and 
from that locate the send time and object times within the packet. Typically, 
there may be something like 3 to 5 object segments in each ASF packet that 
need to have their time codes modified to relative time. To further 
understand the rules of ASF media and their time codes, I suggest reading the 
ASF 1.0 document available on the net. I will not go into that specification 
here. There is also a diagram showing approximate time code locations later 
in this document. 
--
    既然选择了远方，就让我们风雨兼程吧
    人生最快乐的事　莫过于
        有了目标，并为之奋斗!

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.243.49]