Abstract:
The present invention extends a standard HTML browser to support a new data type, the Uniform Resource Locator Sequence (URLS). The URLS consists of a header and a sequence of URLs. The method of the present invention receives the URLS data then sequentially accesses the data of each URL comprising the URLS, obtains statistics on the response time to the requests for URLs, and times the calls for subsequent URLs in the sequence accordingly so that the arrival of the linked data nearly simulates actual streaming.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to Internet and Intranet Browsers, more specifically, to Browsers equipped with functionality to process a sequence of URL requests automatically. This capability allows the Browser to induce a non-streaming server to simulate a streaming server. 
     2. Discussion of Prior Art 
     Internet Browsers are computer programs that simplify and make convenient viewing and navigating through documents on the World Wide Web (Web), written in the Hypertext Markup Language (HTML). Two of the most popular browsers are the Netscape&#39;s Navigator, home page http://www.netscape.com, and the Microsoft&#39;s Internet Explorer, home page http://www.microsoft.com/ie/default.esp. All Web browsers provide a graphical user interface with standard point-and-click navigation methods and HTML file support. 
     HTML documents linked to other HTML documents on the Internet are called hypertext documents. Hypertext documents with multimedia capabilities are called hypermedia documents. The links, connecting hypertext documents, are called hyperlinks or hot links. Hyperlinks often appear in the hypertext documents behind the highlighted text, a word or a phrase usually describing something of which a user might want further information. The region of the hypertext document where the hyperlink appears as text is called hot object. 
     To activate a hyperlink, the user must point and click on the hot object by using a computer pointing device such as a keyboard or a mouse. The user&#39;s computer screen display is then changed to display the linked hypertext document, which typically contains more information on the highlighted word or phrase of the hot object. Hyperlinks make it easy to follow cross-references between documents. 
     The hypertext documents and other data on the Web are found and retrieved by the means of the Uniform Resource Locator (URL). The URL complies with a draft standard for specifying an object on the Internet. It specifies the object format, the access method, and the location of the object. The object&#39;s formats are specified as Multipurpose Internet Mail Extensions (MIME). The following are a few formats on the Web. 
     .au—the most common audio format, 
     .html—hypertext markup language, 
     .jpg—still images encoded using Joint Picture Experts Group standards, 
     .mid—midi music, 
     .mpg—video images encoded using Motion Picture Experts Group standard, and 
     .ps—post script. 
     Each hot object in hypertext files is linked to a unique URL. Often having a hot object linked to a sequence of URLs is desirable. For example, a presentation may consist of a sequence of HTML files, each of which is linked by a URL. The author may want this presentation of HTMLs to be shown in sequence, each lasting some predetermined amount of time. Another situation arises when a sequence of video segments is located at various URLS, when linked together such sequences comprise one contiguous selection of video. 
     Video is the dominant medium in entertainment and is rapidly becoming common in computing environments. Viewing a sequence of video segments in contiguous fashion is very desirable for a viewer, so as to simulate viewing the entire video being streamed from a server. Providing the user with one hot object that would automatically direct the request to the multitude of URLs in a sequence is therefore desirable, with the request being executed either automatically or manually by the viewer. 
     A conventional non-streaming server is insensitive to isochronous requirements. In general, that type of server is designed for minimal transfer latency. Without explicit mechanisms to ensure isochronism, delivery rates of data to a browser are irregular, resulting in erratic playback quality at client machines. To avoid an erratic playback of video files, the usual approach is to download to the host computer whole video files before starting the video playback. Video data is typically very voluminous. Compressed video formats such as MPEG-1, Indeo, QuickTime-MOV, and Cinepack require about 10 MB to store one minute of video data. When the bandwidth of the channel is too low to support the bit rate of the particular video, this approach of downloading of whole video files before starting the video or some modification of it is inevitable. 
     One such modification is to obtain statistics of the download rate, and together with the bit rate of the video compute a reasonable starting time for playback so that the entire video may be played without glitches. This scheme reduces the latency between the request for the video and the start of the playback. When the bandwidth of the channel is greater than that required for a real-time playback, a non-streaming server may overwhelm the storage of the receiving playback system. 
     Streaming video is primarily intended to address this situation. A streaming server delivers video streams isochronously, so that the video playback is guaranteed to have smooth motion and sound, provided that the channel bandwidth is high enough. The streaming server sends video data at controlled bit rates that match the bit rate of the encoded video. One drawback of streaming video files is that the receiving playback system cannot support random seeks. A user viewing streaming video must always begin viewing from the beginning of the file, or at best from that portion of the file that is cached. When seeking video to the future point in time, for example, the viewer has to wait for the server to stream all the video data prior to the desired seek position. 
     SUMMARY OF THE INVENTION 
     The present invention extends a standard HTML browser to support a new data type, the Uniform Resource Locator Sequence (URLS). The URLS consists of a header containing descriptive information and a sequence of URLs. The URLs may be a sequence of pre-existing files, or a new sequence of URL&#39;s may be created by partitioning a data resource such as video into contiguous time segments, storing each segment in an Internet location and creating a URL for each of these segments. 
     The browser receives the URLS data, sequentially accesses the data of each URL comprising the URLS initiating the requests at times dependent on the bandwidth of the channel and various parameters provided by the data in the header portion of URLS. When the various URLs constitute contiguous segments such as from a video sequence, and the requests are timed appropriately, the effect is that of simulating streaming of video. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 illustrates the structure of the URLS; 
     FIG. 2 illustrates the structure of the URL(j) component of a URLS; 
     FIG. 3 illustrates a computer processing system utilized in the implementation of the preferred embodiment; and 
     FIG. 4 shows a flow chart diagram of the preferred embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Although this invention has been found particularly useful in the environment of video data, this invention can also be applied to various other types of data, such as but not limited to audio data. 
     The preferred embodiment of the present invention extends a standard HTML browser to support a new data type. FIG. 1 shows the structure of this new data type, the Uniform Resource Locator Sequence (URLS). A URLS consists of a Header, containing a header file, and an ordered list URLS(j), where j is an index ranging from 1 to n. 
     The Header file contains information regarding the type of data contained in the various subsequent URLS. Such data type may be text, images, audio, video, and other types of data. The Header also contains information regarding what, if any, computer plug-ins or extras are necessary for processing the data in the subsequent URLs, and whether or not streaming needs to be simulated. A browser simulating streaming is said to be in a streaming mode. 
     The structure of a URLS(j), shown in FIG. 2, contains URL(j), a time duration parameter T(j), and a value B(j) representing the size of the corresponding data. A URL(j) is the URL for the jth entry of the URLS. Typically the time duration parameter T(j) will signify that the browser exhibits the contents of the URL(j) for T(j) period. 
     The present invention may be implemented on any computer processing system including, for example, a personal computer or a workstation. As shown in FIG. 3, a computer processing system which may be utilized by the present invention generally comprises the memory  101 , one or more central processing units (CPU)  103 , and one or more user input devices  107 , such as a keyboard, a mouse, a joystick, a voice recognition system, or a handwriting recognition system. The computer processing system of the present invention includes a nonvolatile memory such as ROM and other nonvolatile storage devices  108  such as a fixed disk drives that store operating systems and application programs that are loaded into the memory  101  for execution by the CPU  103 . In the execution of operating systems and application programs the CPU  103  may use data stored in the nonvolatile storage device  108  and memory  101 . 
     The computer processing system of the present invention further includes a graphics adapter  104  coupled between the CPU  103  and a display device  105  such as a CRT display or a LCD display. The application program and the operating system executed by the CPU  103 , generate graphics commands, for example a command to draw a box (or a window), to display a bit map image, to render a three dimensional model, or to display a video file. Such commands may be handled by the application program or the operating system executed by the CPU  103  or by the hardware that works in conjunction with the application program and the operating system executed by the CPU  103 , wherein the appropriate pixel data is generated and the display device  105  is updated accordingly. 
     In addition, the computer processing system includes a communication link  109 , such as a network adapter or a modem coupled to the CPU  103 , that allows the CPU  103  to communicate with other computer processing systems over the communication link, for example over the Internet. The CPU  103  may receive portions of the operating system, portions of the application programs, or portions of the data used by the CPU  103  in executing the operating system and application programs over the communication link  109 . 
     Application programs and the operating system executed by the CPU  103  may perform the methods of the present invention described below. Alternatively, portions or all of the methods described below may be embodied in hardware that works in conjunction with the application program and the operating system executed by the CPU  103 . In addition, the methods described below may be embodied in a distributed processing system whereby portions of such methods are distributed among two or more processing systems that are linked together via communication link  109 . 
     According to the preferred embodiment of the present invention, described in a flow chart shown on FIG. 4, the user launches a hyperlink by clicking on the hot object appearing on the HTML page displayed by the browser, such hot object having a link to a URLS. Recognizing the URLS data type, the browser responds by executing a sequence of computer instructions. 
     The “Read header” module is called to extract the necessary information from the header portion of the URLS. The header information is passed to the “Initialize” module. Based on the information in the header file, the “Initialize” module causes the browser to launch the appropriate functions necessary to execute one or more desired applications. For example, if the data in the URLs comprise segments from a video stream, the browser will spawn (start up) on the host computer the appropriate video decoders and players. 
     Next, the “Mode?” module reads the part of the header file that specifies whether the data pointed to by URLS is intended for the streaming mode playback, or whether the choice of streaming mode versus manual mode will be left to the user. If the header indicates the streaming mode, the playback mode is set automatically to streaming. Otherwise, the browser will output a query to the computer screen, prompting the user to input which of the two modes the user wishes to execute as a playback. The user then may respond by making the appropriate choice. A default value may be chosen by the browser if the user chooses not to reply to the query. 
     In the streaming mode, the timing of the transitions between the various data of the different URLs is crucial. As an illustration, consider the URLs comprising contiguous segments from a video sequence. Streaming succeeds only if TD(j+1)+A(j+1)&lt;T(j), where TD(j) is the time delay between the time the browser initiates a request for URL(j) and the time the first data packet from URL(j) arrives at the browser. A(j) is the time duration for all data from URL(j) to arrive, that is the time duration from when the first data packet arrives till the last data packet arrives. 
     The “Parameters” module enables the user to choose a minimum time duration for uninterrupted display of the streaming data. The user is prompted to choose a time duration value T, such that in case streaming of the entire program is not possible, at least segments of time duration T will be played continuously. Predefined or default values may be used instead of user input. 
     In the streaming mode, the “Parameters” module then partitions the URLs comprising the URLS into segments 
     segment 1—(URL(A 0 ), . . . , URL(A 1 )), 
     segment 2—(URL(A 1 +1), . . . , URL(A 2 )), 
     segment 3—(URL(A 2 +1), . . . , URL(A 3 )), etc., such that 
     
       
           T ( 1 )+ . . . + T ( A   1 −1)&lt; T  and  T ( 1 )+ . . . + T ( A   1 )&gt; T,    
       
     
     
       
           T ( A   1 +1)+ . . . + T ( A   2 −1)&lt; T  and  T ( A   1 +1)+ . . . + T ( A   2 )&gt; T,  etc.  
       
     
     The display of the last segment cannot be guaranteed to satisfy the requirement. Therefore the buffer size BUFF required to store the segment with the largest amount of data is determined utilizing the B(j) value in the URLS(j). BUFF is equal to the maximum B(A k +1)+B(A k +2)+ . . . +B(A (k+1) ). It then allocates two buffers, BUFF_A and BUFF_B, each of size BUFF. 
     Next, the “Fetch segment” module fetches the first segment and stores it in BUFF_A. This involves making requests for URL( 1 ), URL( 2 ), and so on, until URL(A 1 ). As soon as all the data for the first segment arrives, the “Fetch next segment-and display present-segment” module begins fetching the second segment and storing it in BUFF_B and simultaneously displaying the decoded contents from the first segment stored in BUFF_A. 
     The system continuously watches for the finish of the segment fetch, and the finish of the segment display. This task is performed by the “Wait_auto” module. If the streaming constraints are met, namely TD(j+1)+A(j+1)&lt;T(j), then the fetch will be done before the display. When both fetch and display are done, the “URL&#39;s left?” decision module determines whether segments are remaining to be fetched. If there are, the control is passed back to the “Fetch next segment-and display present-segment” module, which initiates a fetch of a next segment, and stores it in the alternate buffer, BUFF_A for segment three. At the same time it starts displaying the decoded output from the current segment, which is already stored in BUFF_B. 
     This process is continued, with one segment being stored in one buffer and the previous segment being played back from the other, until the “URLs left?” decision module determines that there are no more segments left to fetch, Then, the last segment is displayed by the “Display segment” module and the streaming process terminates with the “End” module. 
     In accordance with the invention, if the streaming criteria are met, then the entire content of all the URLs comprising the URLS will be displayed in proper timing order as prescribed by the content creator. If the contents of the URLs comprise a video sequence, then the video will be displayed from beginning to end in a continuous manner as is typical when using a streaming server and a stream capable player. The player may be programmed so that after playing each video segment, it may be called upon again to continue playing a subsequent segment. This way, the browser does not have to spawn a new player for every incoming segment. 
     In the Manual mode, the “Parameters” module allocates at least two buffers BUFF_A and BUFF_B, each buffer equals in size to the maximum B(j). The “Fetch URL” module fetches the data in URL( 1 ) and stores it in a buffer BUFF_A. As soon as all the data from URL( 1 ) has arrived, the “Fetch next URL and display present URL” module begins fetching the data from URL( 2 ), storing it in a buffer BUFF_B and simultaneously displaying the decoded URL( 1 ) data stored in BUFF_A. 
     The “Wait_man” module continuously monitors the system for a signal from the user to begin fetching data from the next URL. When such signal is detected and all the contents of URL( 2 ) have not arrived, the “Wait_man” module waits until all the contents of URL( 2 ) have arrived. When all the contents of URL( 2 ) have arrived, the “URLs left?” decision module sends the control back to “Fetch next URL and display present URL” module to begin fetching data from the next URL, URL( 3 ) and storing it in the alternate buffer BUFF A, and simultaneously displaying the decoded URL( 2 ) data stored in BUFF_B. 
     This process is continued, with buffers interchanging, ping-ponging, until no more URLs are left to fetch. After the “URLs left?” decision module makes that determination, it sends control to the “Display URL” module which displays the decoded data from the last URL and the process is terminated by the “End” module. 
     The present invention is well suited for viewing video whose compressed data is transmitted from a server, without the need for storing all the data in advance at the local site, and without the need for the server to have streaming capabilities. The video data which will be streamed is partitioned into sequenced segments. A URLS is created, with the URL segment sequence as it&#39;s content. 
     As an illustration, please consider the following. A 60 minute MPEG encoded video stream is partitioned into one minute segments. The data rate of the encoded video is 1.5 Mbps, each one minute segment is therefore encoded with 90 megabits, and the entire video is encoded with 5.4 Gigabits (or 675 MBYTES) of data. The bandwidth from the server to the browser is 3 Mbps. The browser determines that the time delay between its request for data and the beginning of the arrival of the data is less than 20 seconds. The time to deliver a one minute segment of video over the channel is 30 seconds. Thus, the total time from initiating the request for a minute segment till the entire data for that segment arrives is less than 50 seconds, and certainly less than one minute, which is the playing time of one segment. Hence the streaming criteria is satisfied. The browser allocates 2 or more memory buffers, each of 12 megabytes, for temporarily storing the incoming video data, and utilizes them in an alternating fashion.