EP1682980A2 - Systeme, methode et produit de programme informatique pour determiner a distance la configuration d'un utilisateur de contenu multimedia - Google Patents

Systeme, methode et produit de programme informatique pour determiner a distance la configuration d'un utilisateur de contenu multimedia

Info

Publication number
EP1682980A2
EP1682980A2 EP04796800A EP04796800A EP1682980A2 EP 1682980 A2 EP1682980 A2 EP 1682980A2 EP 04796800 A EP04796800 A EP 04796800A EP 04796800 A EP04796800 A EP 04796800A EP 1682980 A2 EP1682980 A2 EP 1682980A2
Authority
EP
European Patent Office
Prior art keywords
information
user
computer
storage devices
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04796800A
Other languages
German (de)
English (en)
Other versions
EP1682980A4 (fr
Inventor
Jody Shapiro
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/700,409 external-priority patent/US7356575B1/en
Application filed by Sony Corp filed Critical Sony Corp
Priority to EP10010727A priority Critical patent/EP2278461A1/fr
Priority to EP08016181A priority patent/EP2026535A1/fr
Publication of EP1682980A2 publication Critical patent/EP1682980A2/fr
Publication of EP1682980A4 publication Critical patent/EP1682980A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • the invention described herein relates to information systems, and more particularly to detection of multimedia content client configuration information.
  • Some users nay have a high speed broadband connection, while others may have a 56K modem connection.
  • a content provider is laced with the problem of how to fonnat the content to be delivered. Incorrect formatting would result in the delivery of content that was incompatible with a user's configuration. This card result in content that is unusable. If the content is usable, the content may be in a format that fails to take advantage of all the features available in the user's configuration, such that the content, as experienced by the user, is not as rich as it could be. h the past, content providers have addressed this problem by choosing some set of common user configurations. The provider, for example, might identify the most common media players and versions thereof.
  • the provider formats the content for each of these players and stores these assorted versions of the content.
  • the provider would then develop a memo to be provided to the user, in effect asking which media player the user has, or, if the user has more than one, which player is preferred by the user.
  • the user then makes a selection, and the content that has been pre-encoded in the selected format is delivered to the user.
  • This solution has limitations. First, it is relatively inflexible. The number of options is limitted. A user's specific configuration may not have been presented as an option in the menu. And if an end user has more than one media player available to him, the users preferred choice may not have been listed as an option. Also, the solution above requires user input each tine. The user might not want to be queried. The user may instead prefer that formatting be resolved for him. In other situations, the user might not know the information requested by the menu. The user may not know what version of a media player he has. This solution also requires that a content provider change their menus and re-encode content whenever new players (or new versions of existing players) become prevalent. The above solution, therefore, is inflexible and burdensome to both the user and the provider.
  • a method for remotely determining the configuration of a computer of a multimedia content user includes sending player detection code to the user's computer.
  • Configuration information is received regarding the user's computer including information regarding OS version, web browser version, hardware platform, user interface language type, encoding format, or compression algorithm, or combinations thereof.
  • the method may include setting a cookie at the user's computer to a domain of a delivery management server, performed before the receiving, and wherein the configuration information is received in the cookie.
  • a method for remotely determining the configuration of a computer of a multimedia content user is further provided including sending player detection code to the user's computer, receiving configuration information regarding the user's computer, and sending a modified information header instruction.
  • the method may also include sending unique client ED.
  • the instructions may be received after the information is sent, and the modified information may include some information that was not included in the sent information and or the modified information may exclude some information that was included in the sent information.
  • the modified information header instruction may also be sent prior to the receiving, and the configuration information received may be prepared according to the modified information header instruction.
  • the received configuration information may include one or more adaptations such as a hardware adaptation and/or a user interface version adaptation.
  • the modified header information instruction may be prepared according to the adaptation information.
  • a method is further provided for remotely determining the configuration of a computer of a multimedia content user. including receiving at a user's computer player detection code from a second computer, sending to the second computer configuration information regarding the user's computer, and receiving a modified information header instruction. An unique client ID may be received.
  • a client ID pointer address may be appended with configuration information for sending to the second computer.
  • Modified header information may be prepared based on the received header instruction.
  • the modified header information with appended client ED may be sent to the second computer.
  • a further configuration information request may be received prior to the sending of the modified header information.
  • the instruction may be received after the configuration information is sent.
  • the modified information may include some information that was not included in the sent information and/or may exclude some information that was included in the sent information.
  • the instruction may also be received before the configuration information is sent.
  • the configuration information sent may be prepared according to the modified information header instruction.
  • the configuration information may include one or more adaptations such as a hardware adaptation and/or a user interface version adaptation, and the modified header information instruction may be prepared according to the adaptation information.
  • a method for determining a connection speed of a computer including determining a size of a timing block based on an estimated bandwidth, marking the time at which ' transfer of the timing block begins, marking the time at which transfer of the timing block ends, and determining the connection speed based on the determined timing block size and the times at which transfer begins and ends.
  • a further method that is provided for determining a connection speed of a computer includes receiving a timing block of data having a known size, receiving a start time at which transfer of the timing block is to begin, beginning the timing block transfer at the start time, marking the time at which transfer of the timing block ends, and determining the connection speed based on ,the timing block size and the times at which transfer begins and ends.
  • the timing block size may be determined by fetching estimated bandwidth information, determining an estimated time to retrieve data for determining connection speed with adequate resolution; and determining the timing block size that will take the determined estimated time to retrieve.
  • the timing block may be received in a markup language comment as part of a preferences page.
  • the method may also include storing the connection speed in a cookie.
  • the method may include sending the cookie to a delivery management server.
  • the timing block may comprise random data;
  • a method for remotely determining the configuration of a computer of a multimedia content user includes sending player detection code to the user's computer, receiving configuration information regarding the user's computer, and determining a type of digital rights management information on the user's computer based on the received configuration information.
  • processor readable storage devices are also provided having processor readable code embodied thereon.
  • the processor readable code is for programming one or more processors to perform a method for remotely determining the configuration of a computer of a multimedia content user and/or for determining a connection speed of a computer, in accordance with any of the above.
  • Figure 1 illustrates the general architecture of an embodiment of the invention.
  • Figure 2 is a block diagram illustrating the computing environment of an embodiment of the invention.
  • Figure 3 A is a flow chart illustrating the overall process of an embodiment of the invention.
  • Figure 3B is a flow chart illustrating server-side request processing in accordance with an embodiment including receiving a delivery manager HTTP request.
  • Figure 3C is a flow chart illustrating server-side request, processing in accordance with an embodiment including receiving a detection URL HTTP request.
  • Figure 3D is a flow chart illustrating further request processing according to an embodiment of the invention.
  • Figure 4A is a flow chart illustrating the process of media player detection, according to an embodiment of the invention.
  • Figure 4B is a flow chart illustrating client-side windows media player (WMP) detection in accordance with an exemplary embodiment of the invention.
  • Figure 4C is a flow chart illustrating client-side RealPlayer (Real) detection in accordance with another exemplary embodiment of the invention.
  • Figure 4D is a flow chart illustrating client-side QuickTime (QT) detection in accordance with an exemplary embodiment of the invention.
  • Figure 5 A is a flow chart illustrating the process of presenting a preferences page to the user, according to an embodiment of the invention.
  • Figure 5B is a flow chart generally illustrating a bandwidth detection -method according to an embodiment of the invention.
  • Figures 6A-6C are a flowchart that describes a routine for accessing media content according to an embodiment of the present invention.
  • Figure 7 depicts an exemplary transcoder that may be used in accordance with embodiments of the present invention.
  • Figure 8 is a table showing exemplary transcoding source types and destination types for various publishing variables according to an embodiment of the present invention.
  • Figure 9 is a table showing exemplary client environment variable types according to an embodiment of the invention.
  • a system, method, and computer program product for determining the configuration of an end user's computer system In particular, the media players and network connection speed of the user are determined.
  • This configuration information is then received by a second computer, preferably a delivery management server.
  • the configuration information is used to format multi-media content for delivery to the user. Because the content is formatted according to the configuration information, the content is compatible with the user's configuration.
  • the configuration determination process involves server contact code placed in the web page of the content provider. When the web page is loaded by the user, the server contact code directs the browser to retrieve code from the delivery management server. When the code is executed by the user, the media player of the user is determined. This information is saved in cookies at the user arid is sent to the delivery management server.
  • the user is presented with a preferences page in which the user can indicate the configuration.
  • the preferences page also contains a mechanism for determining the connection speed of the user.
  • the preferences page can also make specific recommendations to the user, e.g., recommend that the user choose a specific media player.
  • the preferences page contains a block of data having a known size. The time required to transfer the block is measured, and the connection speed is then calculated and provided to the delivery management server.
  • the configuration determination process involves server contact code that is placed in the web.page.of the content provider. When the web page is loaded by the user, the server contact code directs the browser to retrieve scripts from the delivery management server.
  • the media player of the user is determined. This information is saved in cookies at the user and is sent to the delivery management server.
  • the configuration information can then be used by a transcoder that formats the media content according to the configuration information. If the configuration information is indeterminate or incomplete, the user is presented with a preferences page in which the user can indicate the configuration. This configuration, as determined through the preferences page, is also tored in cookies and sent to the delivery management server to allow formatting of content.
  • the preferences page can also make specific recommendations to the user, e.g., recommend that the user choose a specific media player.
  • the preferred embodiments described herein relate to a system, method, and computer program product that allows the remote determination of a user's computer system configuration. This allows multimedia content destined for that computer to be formatted in a manner compatible with the user's configuration. If sufficient configuration information is obtained, the content can be formatted so as to provide the best possible media experience for the user.
  • the concept of a user's computer is defined broadly to include the full range of programmable or programmed - devices.
  • a user's computer can be, but is not limited to, a personal computer or other workstation, a laptop, a palmtop, a personal data assistant, or a cell phone.
  • server contact code is contained in a web page sent by a content provider to the user.
  • the server contact code retrieves one or more scripts from a delivery management server.
  • the scripts enable the determination of configuration information of the user's computer system.
  • the configuration information comprises the identity and version of the user's media player(s).
  • the configuration information is then returned to the delivery management server.
  • the configuration information can then be used to format the multi-media content appropriately.
  • configuration information is also stored locally at the user's computer in the form of cookies. In subsequent' hypertext transfer protocol (HTTP) requests, the cookies can be sent to the delivery management server as a way of conveying the configuration information.
  • HTTP hypertext transfer protocol
  • a preferences page where the user can specify his configuration (e.g., his available or preferred media player type and version, and/or a preferred connection speed)To the delivery management server.
  • the preferences page can also be used to recommend that the user choose a specific media player.
  • a preferences page includes a block of data of known size. This block is transferred into the user's computer as a part of the preferences page. The time required to transfer this block of data is measured in order to determine the connection speed of the user's computer. The connection speed represents an additional piece of configuration information. The connection speed is also stored locally at the user's computer in the form of a cookie.
  • This cookie can also be sent to the delivery management server as a way of conveying the user's connection rate to the delivery management server.
  • the system of the preferred embodiment basically supports detection of two things: server-to-clie ⁇ t connection speed (bandwidth), and media players (including player versions) installed on the client.
  • connection speed detection only server-to-client estimation is desired because the media stream will be sent by the server to the client.
  • Some media player control channel data will be sent from the client back to the server, but the quantity of data is vastly smaller than the actual media data being sent from the server.
  • the ideal is to be able to detect all of the following: media players installed (e.g.
  • QuickTime, Windows Media Player, RealPlayer, etc. versions of installed media players (e.g., QuickTime 5.0.2, Windows Media Player 6.4, RealPlayer 8.0), and individual audio and video codecs installed in each media player (S ⁇ renson v3 for QuickTime, Windows Media Video V8, Sony ATRAC for RealPlayer, etc).
  • Useful information includes operating system version, web browser version, hardware platform, and preferred user interface language. Some of this information is easily obtained (typically as part of an HTTP header that's sent by the client to the server), while other information is either more difficult to obtain or time consuming to obtain and is best done periodically (not for every request). In these cases, it's desirable to save the detected information (as well as any user preferences) in a cookie stored in the client's web browser. When requests are made: to Generic Media servers, the web browser will automatically send affiliated cookie data to the server. ⁇ •
  • An overall architecture in accordance with a preferred embodiment includes server contact code embedded in a web page of a content provider.
  • the server contact code directs the user's browser to a delivery management server, which sends one or more scripts to the user. Execution of the scripts can identify the type and version of the user's media player.
  • This delivery management server receives this information from the user.
  • the configuration information can eventually be used to format multi-media content for delivery to the user.
  • FIG 1. A content provider 105 is shown delivering information to a user 110. Included in web page 115 is server contact code 120. When the browser of user 110 accesses server contact code 120, the browser establishes contact with delivery management server 125 and asks for one or more player detection scripts 140.
  • Server 125 responds by. sending scripts 140 to user 110.
  • the scripts 140 when executed, determine configuration information 135 for user 110..
  • this configuration information is stored with user 110 by a process of setting cookies that contain configuration information 135.
  • the cookies are retained by user 110, and when user 1 10 makes the HTTP request 130 to access the content, configuration information 135, in the form of the cookies, is sent to delivery management server 125.
  • ⁇ transcoder (not shown) formats the multi-media content in a manner specified by configuration Information 135.
  • the resulting formatted content can then be delivered to user 110 through a streaming server (not .shown), If configuration information 135 is not available (or otherwise requires clarification), an additional script, provided to user 110 as one of the scripts 140, opens a new window that loads a preferences web page 150. With this page, user 110 can explicitly identify configuration information 135 (e.g., the player type and version) through a user interface in preferences page 150. As before, the configuration information 135 can be retained at user 110 in the form of cookies and forwarded to delivery management server- 125. In an embodiment f the invention, a recommendation can be made by the delivery management server to the user, through the preferences page 150, as to a particular media player that the user can or should select.
  • configuration information 135 e.g., the player type and version
  • a recommendation can be made by the delivery management server to the user, through the preferences page 150, as to a particular media player that the user can or should select.
  • the recommendation is based on what is known about the user's options.
  • the recommendation can be conveyed through a portion of the page. This portion can be thought of as a server interface, since the server communicates to the user through this interface.
  • the preferences page includes a block of data 155 having a known size. The transfer of the block 155 is timed in order to determine the connection speed of the user 10.
  • block 155 (known hereinafter as the timing block) is incorporated in an HTML comment in the preferences page 150:
  • the delivery management server 125 is one of a set of such servers.
  • the set of delivery management servers services a community of users by means of the invention described herein. Given a user's request for content, the user would be assigned to a specific delivery management server through, a selection mechanism that balances the load created by multiple users.
  • the functionality of delivery management server 125 is embodied in a viewer web server interface to a transcoding engine.
  • the transcoding engine in general, receives content from a content provider and formats ("transcodes") the content in a manner that makes it usable by user 110.
  • the viewer web server interface is a network interface between the transcoding engine and the user 1.10, that allows content to be requested by user 110.
  • the viewer web server interface receives and processes a content request from the user 110, thereby initiating the transcoding and delivery of the requested content to the user 110.
  • the viewer web server interface sends a reply to user 1 10's request, redirecting the user 110 to an appropriate streaming server from which to receive the requested media content.
  • Formatted (“transcoded") content is then streamed to the user 110 by a streaming server and/or proxy server (also a part of the transcoding engine).
  • a streaming server and/or proxy server also a part of the transcoding engine.
  • a transcoding engine is described in greater detail in U.S. patents 6,407,680 and 6,593,860, and incorporated by reference herein in its entirety.
  • the delivery management server 125 and the viewer web server interface can be implemented as separate servers.
  • transcoding and delivery management operations described above can be performed by a delivery management service.
  • This service may be, for example, a separate organization or business entity independent of the content provider 105.
  • web page 115 may be developed by content provider 105 independently of the delivery management service. Web page 115 could then include a logo or other branding images, a ⁇ d/or a "look and feel" specific to content provider 105.
  • preferences page 150 though delivered to user 110 by delivery management server 125, could also be developed by content provider 105 independent of the delivery management service. Independence of the delivery management service and content provider 105 would also allow the delivery management service to make service changes on its own.
  • the delivery management service would be free to upgrade its service by adding or otherwise modifying functionality.
  • Player detection scripts 140 could be improved, for example, so as to make the player detection process faster or more comprehensive, independent of a specific content provider 105.
  • the transcoding process could also be upgraded independent of content provider 105, to accommodate additional media formats of to provide faster transcoding, for example.
  • the delivery management server 125 may be implemented using hardware, software or a combination thereof. In particular, server 125 may be implemented using a computer system or other processing system. An example of such a computer system 200 is shown in Figure 2.
  • the computer system 200 includes one or more processors, such as processor 204.
  • the processor 204 is connected to a communication infrastructure 2,06 (e.g., a bus or network).
  • Computer system 200 also includes a main memory 208, preferably random access memory (RAM), and may also include a secondary memory 210.
  • the secondary memory 21 may include, for example, a hard disk drive 212 and/or a removable storage drive 214, representing a magnetic tape drive, an optical disk drive, etc.
  • the removable storage drive 214 reads from and/or writes to a removable storage unit 218 in a well known manner.
  • Removable storage unit 218 represents a magnetic tape., optical disk, etc.
  • the removable storage unit 218 includes a computer usable storage medium having stored therein computer software and/or data.
  • Secondary memory 210 can also include other similar means for allowing computer programs or input data to be loaded into computer system 200.
  • Such means may include, for example, a removable storage unit 222 and an interface 220. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 222 and interfaces 220 Which allow software and data to be transferred from the removable storage unit 222 to computer system 200.
  • Computer system 200 may also include a communications interface 224. Communications interface 224 allows software and data to.be transferred between computer system 200 and external devices.
  • communications interface 224 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc.
  • Software and data transferred via communications interface 224 are in the form of signals 228 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 224. These signals 228 are provided to communications interface 224 via a communications path (i.e., channel) 226.
  • This channel 226 carries signals 228 into and out of computer, system 200, and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels.
  • signals 228 can convey information required by the delivery management server 125, such as HTTP request 130 and configuration information 135.
  • Signals 228 can also convey information to user 110, such as scripts 140 and preferences page 150.
  • computer program medium and “computer usable medium” are used to generally refer to media such as removable storage drive 214, a hard disk installed in hard disk drive 212, and signals 228.
  • These computer program products are means for providing software to computer system 200. The invention is directed in part to such computer program products.
  • Computer programs also called computer control logic
  • Computer programs are stored in main memory 208 and/or secondary memory 210.
  • Computer programs may also be received via communications interface 224.
  • Such computer programs when executed, enable the computer system 200 to perform the features of the present invention as discussed herein.
  • the computer programs when executed, enable the processor 204 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 200.
  • the configuration information of a user's computer is determined and sent to a delivery management server.
  • the delivery management server then passes the configuration information to a transcoder that formats multimedia content according to the configuration information.
  • the formatted content can then be sent to the user.
  • An overall process in accordance with an embodiment of the invention is illustrated in . Figure 3A-3D.
  • the process begins at step 305.
  • the user begins loading a web page of a content provider.
  • the web page contains server contact code which directs the user's browser to the delivery management server. In an embodiment of the invention, this is accomplished in an HTML header of the content provider's web page.
  • execution of the server contact code is initiated by an action of the user, such as clicking on a control or link in the content provider's web page, or by entering an explicit command.
  • the server contact code is executed automatically after loading the web page.
  • the user's browser fetches player detection code from the delivery management server ("js" in the example above).
  • the media players that can be used by the user are determined.
  • step 330 the identity of the media players is recorded in one or more cookies in the user's computer. This step will also be described in greater detail below.
  • a decision is made at the delivery management server (step 331) as to whether the received configuration information is sufficient to format the requested multi-media content. If cookies are received and verified as having valid settings, a minimal HTTP response is sent back, implying validity. If the received configuration information is sufficient to format the requested multi-media content, processing continues at step 335, described below.
  • An additional decision point can be made between step 320 and 325 in the method described and illustrated with reference to Figure 3A. That is, if sufficient information is . received, player detection can be completely skipped in one embodiment.
  • a decision of what, if any, player detection code to send may be performed after step 320 when the client requests it from the server. If js does not receive valid cookies (i.e., if configuration information at the user is insufficient or nonexistent), the method continues at step 332.
  • a preferences page is displayed for the user. In an embodiment of the invention, this is accomplished by sending the user a segment of javascript that opens a new window which loads the preferences page. The preferences page allows the user to deliberately indicate to the delivery management server the configuration or preferences of the user with respect to the media player, and/or the user's connection speed.
  • the preferences page can also recommend to the user that a specific media player be chosen.
  • the preferences page includes a mechanism through which the connection speed of the user's computer can be determined and relayed to the delivery management server. . l
  • the preferences provided by the user are received by the User's computer.
  • the preferences are stored in cookies.
  • the user requests the multi-media content, made available by the content provider through a web page, by making an HTTP request. Such a request can be made, for example, by clicking on some region of the content provider's web page. As a part of this request, any cookies that contain configuration information are sent to the delivery management server.
  • the cookies could, for example, describe the media player type and version.
  • the cookies could also store the measured connection speed, as well as any preferred connection speed that the user might have.
  • the user may, for example, wish to use only a portion of the available bandwidth for streaming. Here, the user would choose a slower speed than the maximum permitted by the user's configuration.
  • HTTP request is as follows.
  • the user may have a particular preference for one player over another.
  • the preferences page provides a way to resolve these situations, by letting the user convey a player preference to the delivery- management server.
  • the preferences page can convey a recommendation to the user as to which media player might provide the best results.
  • the delivery management server may make one or more inferences based on what is known about the user's configuration.
  • FIG. 3B is a flow chart illustrating server-side request processing in accordance with an embodiment of the invention including receiving a delivery manager HTTP request 371. It is checked at step 372 whether delivery manager cookies have been received. If not, then at step
  • a HTTP response is sent containing code to send client to detection URL. If so, then at step '
  • FIG. 3C is a flow chart illustrating server-side request processing in accordance with a preferred embodiment including receiving a detection URL HTTP request 375.
  • HTTP headers are analyzed to determine configuration information of the client. Among the information determined is operating system, platform and HTTP client or user agent, as illustrated. As understood from further description herein, e.g., with reference to Figures 7-9 and elsewhere, there are many features, characteristics and variances of client computers that may be determined at step 376. In addition, particular items of information that are desired to be received at the server may be indicated to the client as illustrated at Figure 3D and described in more detail below.
  • a TimerStart code may be sent at step 377.
  • a data block or timing block is sent to the client for bandwidth measurement at step 378.
  • a TimerStop code is sent at step 379.
  • the bandwidth is calculated from the amount of the data that is communicated during the time as determined from the difference between the TimerStop time and the TimerStart time, at step 380, and stored in a cookie.
  • the chunk size or timing block size may be fixed and the bandwidth determined based on how much time it takes to . communicate it.
  • the chunk size or timing block size may be selected so that the exercise lasts just above a minimum time needed to make a tolerably accurate bandwidth determination.
  • a client-side media player detection code is sent. DETECTION MECHANISM DETAILS
  • users may be typically connecting from a personal computer or a PDA (Palm, PocketPC).
  • the connection may be generally via HTTP from either a web browser or a media player that can make HTTP requests,
  • client device software may typically not be written to or otherwise controlled, and instead Works within the constraints of existing clients. More specifically, there may be no way to a particular existing web browser (e.g., Internet Explorer, Netscape, Mozilla, etc.) and thus configuration detection algorithms must work within their support of Javascript and work around bugs/quirks of individual browser versions.
  • different media players support varying levels of version and installed-codec queries. In many eases (particularly for older players) there's no way to .
  • media player detection may be typically simplified by the fact that current media player support for PDA's is limited. For example, on PalmOS based PDA's, there may be only a single video player that is available and/or supported. On the PocketPC, as another example, Microsoft's Pocket Windows Media Player was the only available player for a long-time. RealNetworks and PacketVideo have also introduced players for PDA's.
  • the detection logic can often be simplified to 1 :1 mappings between a given PDA and a (default) media player.
  • Bandwidth measurement is also not easy to estimate within the constraints of HTTP and Javascript.
  • Bandwidth measurement tools may typically make their estimations by timing how long it takes a client to receive a known quantity of data. Higher bandwidth estimation accuracy may be obtainable if the time measurement is restricted to just the time spent actually transmitting the data, and if the data-size truly estimates the actual number of bites transmitted. Ideally, multiple measurements are taken to average out anomalies.
  • design requirements/constraints may include: Must be done from within a web page (in a web browser); Code/scripting must only use.
  • Random ASCII data or other random data is preferably used to prevent compression by data-compressing modems, routers, and webservers (which would reduce the actual number of bits received, and thus affect the bandwidth calculation).
  • the bandwidth measurement calculation is preferably only run once, and alternatively multiple times.
  • the size of the data chunk may. be selected to be 20 kilobytes such as may balance the need for expedient measurement for modem users against, the need for accurate measurement for users on LAN connection speeds of around 300 kbps. Again, due to the design constraints more advanced/accurate bandwidth measurement techniques may be undesirable.
  • the measurements may be still vulnerable to calculation corruption. Other applications or browser windows may be sending data, thus slowing the transmission time, for example.
  • intermediate routers may be buffering data and transmitting it in large chunks.
  • data may still get compressed by intermediate routers/modems.
  • the data may burst over the last network link, e.g., from the firewall to the computer, or in the browser, e.g., it may parse/execute Javascript in sections, any or all of which may falsely decrease the transmission time.
  • default detection results may be used. Users could change their preferences at a later date by clicking a link to go to a settings/preferences changing web page. Default detection results may be . advantageously customized for different clients based on information gleaned from the HTTP Request headers (operating system, hardware platform, e.g.).
  • a Macintosh client might have as a default that QuickTime is installed, while a PocketPC client might have this default that Pocket Windows Media Player is installed.
  • the default bandwidth might be 56 kbps.
  • a preferred implementation utilizes "cookies" for storing persistent data between user . sessions.
  • Cookies are name- value pairs stored by an HTTP client which are associated with a . , domain. When the client makes subsequent HTTP Requests, it sends with the request cookies that are affiliated with the HTTP server's domain. Cookies can be further specified to expire (be deleted) after a certain date.
  • Separate cookies may be created/used in an exemplary implementation for storage of things like measured bandwidth, detected media players (and their versions), user bitrate preference, user media player preference for streaming, and/or user media player preference for downloaded content. Each' cookie may have its own expiration date which can be utilized to set the frequency at which portions of detected information could be considered stale and due for re- detection.
  • things which consume a relatively large amount of time to detect may be done Once and then only re-detected periodically (or upon user request).
  • Much of the difficulty and complexity of typical configuration detection implementations is due to only being able to write/control the server-side environment.
  • client-side platforms, browsers, media players, scripting languages, bugs, etc. need not always be worked within and around in accordance with a preferred embodiment, e.g., as being considered unchangeable.
  • upgrading/changing the client's installed software may be now allowed, although may alternatively be specifically not allowed.
  • FIG. 3D is a flow chart illustrating further request processing according to an embodiment of the invention.
  • a modified information header instruction is sent at step 382. That is, a request is sent to the client for different information than the client either already has sent or is prepared to send based on a standard or previous request.
  • a unique client ID is sent at step 383, so that the particular information requested and then received from the client is associated with that client.
  • Client operations 384-386 illustrate an effect on client-side processing due to server operations 382-383.
  • the client acknowledges the instruction received based on step 382 and appends client ID pointer address information to the requested header information based on step 383.
  • the client prepares modified header information at step 385 depending the information requested in the instruction of step 382.
  • the client sends at step 386 modified header information with ID upon further request.
  • the subroutine ends at step 387.
  • the modified information may include information that was not included in information previously received or that the client understood was desired by the server. This advantageously permits the server to get all of the information desired.
  • the modified information may also exclude information that was included before or that the client would otherwise send to the server. This advantageously can reduce the amount of data being sent, particularly when some of the data is not desired for processing at the server or otherwise for transcoding and/or otherwise providing media transcoding services.
  • Adaptations of client hardware, client user interface version or other client configuration features may be included in the configuration information requested by the server and/or sent . , from the client.
  • the modified header information instruction may be prepared according to this adaptation information. These adaptations, e.g., maybe according to specific browser configurations at the client.
  • the design requirements of implementation architectures may be designed to provide more freedom for writing custom client software.
  • a form of persistent storage may be provided so that detected information can be stored from one session to another. This can advantageously reduce the time spent on bandwidth measurement;
  • the bandwidth estimate may be measured and/or updated constantly, periodically or as requested based on timing/timestamps of data being sent from the server to the client.
  • detection information may be kept in memory so that it can be sent by the client with requests to the server.
  • the client may advantageously have a way of quickly/easily knowing what media players are installed on a client.
  • hooks are provided into the operating system (or software installation manager) so that detection software can directly query for what media player software is installed, what version it is, what version of codecs are installed, and/or for other configuration information. If the implementation is done such that only one media player is installed and/or that additional installations aren't available, or that the detection management software is integral to the media player, it might be advantageous to have the media player software directly report this information instead.
  • direct correlations may be .made about a client's actual media player capabilities from the version information reported.
  • version 1 :0.4 of the V XYZ video codec is capable of decoding a video compressed with the XYZ algorithm, but that the decoder requires the video frame/size dimensions to be multiples of 8 pixels.
  • Another example might be that if the client reports it has audio codec A ABC version 1.1 and audio codec A DEF version 3.0 that the server must not send data encoded with any other audio codec, and that the compression algorithm used must be decodable by one of the client's audio codecs. All bandwidth measurement algorithms fundamentally boil down to measuring how long it takes to receive a known-size chunk of data or how much data is communicated in a predetermined period of time.
  • an algorithm is described in more detail below with reference to Figure 5B including sending one or more of multiple chunks of data such that the chunk-size or timing block size may be varied or selected according to a current approximated bandwidth.
  • Detection information may be used on the server side to decide on a transcoded bitrate and media player format/version. It is generally inefficient and resource intensive to provide transcodes in all possible combinations of bandwidths and codec.
  • the codecs used maybe limited, e.g., to the most commonly installed and the bitrates encoded may be limited to ones that supported the most common target audiences, e.g., 20kbps for 28.8 modem, 34kbps for 56k modems, 90kbps for ISDN, 300kbps for DSL, and 500kbps for cable-modern.
  • Step 4A the step of performing player detection, is described in greater detail in Figure 4A.
  • This process begins at step 405.
  • step 410 a determination is made as to what browser the user has.
  • the user's browser will be either a version of NETSCAPE NAVIGATOR, or a version of INTERNET EXPLORER (IE).
  • step 411 a string search for a given media player is performed through the resident mimetype array and plugin array.
  • the mimetype array is a mapping of what application to load upon receiving a response with a given mimetype. Any given media player typically has its own mimetype.
  • the plugin array is a listing of all browser plugins that have been installed; typically, each has registered a corresponding mimetype. As a result, these arrays will typically contain character strings that indicate the media player(s) resident on the user's computer.
  • QUICKTIME is indicated by the string "QuickTime” for example
  • WINDOWS MEDIAPLAYER is indicated by the string "video/x-msvideo”.
  • step 413 If in step 413 the string search is successful, then the player is determined to be present in step 415. Otherwise, processing continues at step 416.
  • step 416 a determination is made as to whether another media player is to be sought. If so, processing returns to step 411 , and a string search is conducted for another media player. In the illustrated embodiment, therefore, multiple string searches will generally be performed, although the invention can be implemented to perform a single search.
  • the process concludes at step 417. Note that different versions of a given player may be registered with the ' browser using slightly different names or properties. Detection of these distinctions by string searches can provide information as to specific versions. In an embodiment of the invention, the string searches are implemented using javascript.
  • step 410 it is determined that the user's browser is INTERNET EXPLORER
  • step 420 the browser is asked to instantiate an object for a given media player and version.
  • this instantiation is done using Vbscript. Creation of a REALPLAYER version 5 object, for example, would be attempted with the statement CreateObject("RealPlayer.RealP ⁇ ayer(tm) ActiveX Control (32-bit)". If, in step 425, this instantiation is permitted, this implies that the media player is in fact present on the user's computer, as shown in step 430. The process then continues at step 440.
  • step 425 If, in step 425, instantiation of the given media player object is not permitted, then it can be assumed that the media player is not resident at the user's computer.
  • step 440 a determination is made as to whether the presence of any other media player should be ascertained. If so, the process returns to step 420 and another attempt will be made, this time to instantiate an object for a different media player. If, in step 440, a determination is made that no other media player will be sought, then the process concludes at step 417. Note that differences between players, -especially differences between versions of a player, can be detected by corresponding differences in how player objects are instantiated in step 420. Also, for player objects that support version queries (e.g., QUICKTIME and REALPLAYER), the player can be asked directly about its version.
  • version queries e.g., QUICKTIME and REALPLAYER
  • FIG. 4B is a flow chart illustrating client-side windows media player (WMP) detection in accordance with an exemplary embodiment of the invention.
  • WMP client-side windows media player
  • step 445 it.is checked whether ClassED for WMP 7 may be created. If so, then WMP version is set to WMP 7 and the process moves to RealPlayer detection. If at step 445, it is determined that ClassED for WMP 7 cannot be created, then at step 447 is it checked whether that for WMP 6.4 may be created, and if so, WMP version is set to 6.4 and if not, then the process moves to step 449.
  • step 452 It is checked at step 452 whether mimetype application/x-ms-wmd is registered by a plugin, If so, then WMP version is set to version 7 ending the WMP detection procedure. If not, then at step 453, is it checked whether mimetype application/x-ms-wmv is registered to a plugin. If so, then WMP version is set to version 6.4 ending the sub-routine.
  • step 454 it is checked whether mimetype application/x- msplayer2 is registered to a plugin. If so, then WMP version is set to yes, and if not, then EMP version is set to no, and either way, the process moves to RealPlayer detection.
  • FIG. 4C is a flow chart illustrating client-side RealPlayer (Real) detection in accordance with an exemplary embodiment of the invention.
  • Step 455 it is checked whether Real is available on this client's OS/platform. If not, then Realversion is set to no ending the sub-routine and moving the process on to QuickTime detection. If so, then at step 456, it is checked whether ActiveX is available on this browser. If yes, then at step 457 it is checked whether a RealPlayer G2 object may be created. If so, then Realversion is set to RealPlayerG2Object.GetVersioninfo() and the process moves to QuickTime detection as illustrated at Figure 4D. If not, then at step 459, it is checked whether a RealPlayer object may be created.
  • Realversion is set to version 5 ending the sub-routine, and if no, then the process moves to step 461 where it is checked whether a RealVideo object can be created. If yes, the Realversion is set to version 4, and if not then Realversion is set to no and either way, the sub-routine is ended. If at step 456, it is determined that ActiveX is not available on this browser, then the subroutine moves to step 464, as illustrated at Figure 4C, where it is checked whether mimetype audio/x-pn-realaudio-plugin is registered by a plugin. At step 465, Realversion is set to yes. Then, at step 466, it is checked whether there is a plugin name containing "RealOne".
  • Realversion is set to One at step 467 ending the sub-routine. If not, then at step 468, it is checked whether there is a plugin name containing "RealPlayerG2", and if so, then Realversion is set to G2 ending the sub-routine. If riot, then at step 470, it is checked whether there is a plugin name containing "RealPlayer”. If so, then Realversion is set to version 5, and if not, then at step 471, it is checked whether there is a plugin name containing "Realvideo”. If so 5 then Realversion is set to version 4, and if not, then Realversion is set to no, and either way, the process moves to Figure 4D and QuickTime detection.
  • FIG. 4D is a flow chart illustrating client-side QuickTime (QT) detection in accordance with an exemplary embodiment of the invention.
  • QT QuickTime
  • step 472 it is checked whether QT is available on this OS/platform. If no, then QTversion is set to no ending the sub-routine. If yes, then at step 473, it is checked whether ActiveX is available on this browser. If yes, then at step 474, it is checked whether a QuickTimeCheck object can be created. If not, then QT version is set to no, and if so, then the sub-routine moves to step 475. There it is checked whether QuickTime is available by using, Call QuickTimeCheckObjectVersion.IsQuickTimeAvailableQ.
  • step 475 If the result of the checking at step 475 is no, then Qtversion is set to no, and if the result of step 475 is yes, then QTversion is set to QuickTimeCheckObject.QuickTimeVersion, and either way, the sub-routine is ended upon saving of the detection results at step 482. If at step 473, it is determined that ActiveX is not available on this browser, then at step 478, it is checked whether mimetype video/quicktime is registered by a plugin. If not, the QTversion is set to no, and if so, then QTversion is set to yes at step 479. Then, at step 480, it is checked whether there is a plugin name containing "QuickTime Plug-i ⁇ ".
  • Step 355 of Figure 3A the step of presenting a preferences page to the user, is illustrated in greater detail in Figure 5A according to an embodiment of the invention.
  • the process begins at step 505.
  • step 510 the preferences page is loaded from the delivery management server.
  • step 515 the transfer of a block of data of known size, stored within the preferences page, begins. The transfer of this block is timed to determine the user's connection speed. This block is denoted hereinafter as a timing block.
  • the timing block is included in the preferences page as an HTML comment. As a result the browser ignores the timing block for processing purposes. At the same time the transfer of the timing block begins, the browser notes the time at which the transferring of the timing block starts. In step 520, the transfer of the timing block concludes, and the time at which the transfer concludes is also noted by the browser. En step 530, a calculation is made as to the connection speed* i.e., data transfer rate, based on the time required to transfer the timing block and on its known size. In step 535, loading of the preferences page concludes and the possible configurations that the user might have are displayed for the user. In step 540, the user's input with regards to the configuration is received. The process concludes at step 545.
  • the connection speed* i.e., data transfer rate
  • the preferences page can also be displayed at times other than what is described above with respect to Fi gure 3 A.
  • the user is. given a link in the content provider's web page through which the user can access the preferences page whenever desired. This allows the user to change the stated preferences at will,
  • the preferences page is displayed to the user at regular intervals, e.g., every six months. This allows the user to make periodic updates of the configuration information.
  • coqkies when a browser makes a request to a server, the browser only sends up cookies that are associated with the server's domain.
  • a cookie can be associated with a new domain in one of two ways: 1) a Set-Cookie: header is received from a server within the new domain, or 2) the cookie is set via javascript by a page that was loaded from a server in the new domain. Since the player detection code is not always being rim from a delivery management server page (e.g., the case where the player detection is loaded as part of the header of a content provider's web page), a way to set the cookies is needed. The goal is a third party cookie, whereby a cookie that would otherwise be set to the original domain (the content provider's domain) is set instead to the delivery management server's domain. In, an embodiment of the invention, this can be done by making a dummy image( ) request from within javascript.
  • the delivery management server can reply by sending back a Set-Cookie: header.
  • a URL may be built at the user's computer directed to a cookie set script at the delivery management server.
  • a dummy image object may be created at the user's computer. This object serves no purpose except to allow a dummy image request to be made, from within javascript, to the domain of the delivery management server.
  • the browser makes an HTTP request, asking that a dummy image be loaded from the domain of the delivery management server; this request incorporates a request for the cookie set script.
  • the delivery management server responds by associating the Cookies with the server (i.e., sending back a Set-Cookie: header). This will allow the cookies to be sent to the delivery management server, even though their presence at the user's computer may have originally been determined by the content provider or some other domain.
  • the configuration information is stored in the cookies.
  • GET/ssp/cookieset?gmPlayerPref ⁇ eal HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- powerpoint, applicatio ⁇ /vnd.ms-excel, application/msword,*/* Accept-Language: en-us Accept-Encoding: gzip, deflate
  • User-Agent Mozilla/4.0 (compatible; MSEE 5.5; Windows NT 5.0)
  • FIG. 5B is a flow chart generally illustrating a bandwidth detection method according • to an embodiment of the invention.
  • a sub-routine is started at step 550 and proceeds at step 552 to fetch estimated bandwidth information, e.g., at determined from a previous bandwidth detection or otherwise.
  • estimated bandwidth information e.g., at determined from a previous bandwidth detection or otherwise.
  • an estimated time to retrieve data is determined for determining a connection speed with adequate resolution, i.e., using the estimated, bandwidth information.
  • the reason for this is that we want the timing block or chunk-size to be selected based on the results of this step, and we want this estimated time to be not shorter than and not much longer than a minimum time within which bandwidth information may be determined within a tolerable resolution.
  • the chunk-size or timing block size that will take the estimated time to communicate is determined at step 556.
  • random data such as random ascii data is used in the timing block or chunk, so that modems will not compress the data and make the communication time drastically shorter than the estimated time and leaving the result outside the resolution tolerance.
  • timing block size or chunk-size is determined that will take approximately the estimated time.
  • a timing block or data chunk of that determined size is communicated to the client at step 558.
  • the actual time it takes to communicate the timing block is measured.
  • the bandwidth is then determined at step 560 based on the size of the. data chunk or timing block sent in step 558, and on the measured retrieval time by the client.
  • the sub-routine illustrated at Figure 5B is ended at step 562.
  • systems and methods in accordance with preferred embodiments perform the transcoding of media content on demand, in response to a viewer's request to access media content. Additionally, preferred embodiments essentially perform the transcoding of media content in "real-time" after the publication of the media content, as part of the media content delivery process.
  • the delay between the submission of a request to view media content to the media transcoding engine (see U.S. patent no. 6,407,680 and U.S. patent application no. 10/644,602, which are incorporated by reference) and the delivery of the media content to a viewer client will be approximately thirty seconds or less.
  • the invention is not limited to a specific delivery time and can. encompass a variety of delivery times greater than or less than thirty seconds.
  • FIGS 6A-6C depict a flowchart 1500 of a method by which media content is accessed by a viewer according to embodiments of the present invention.
  • the invention is not limited to the description provided by the flowchart 1500. Rather, it will be apparent to persons skilled in the art from the teachings herein that other functional flows are within the scope and the spirit of the present invention.
  • the viewer sends a request to access media content via the viewer client to the viewer Web server interface within the media transcoding engine.
  • the request is an HTTP request generated by the viewer client when the viewer clicks on a URL on the content provider's web-site.
  • the URL link which may be provided by the media transcoding engine to the content provider during the media content publishing process, contains address information and source information that points the viewer client to the media transcoding engine and provides information to the media transcoding engine about the source of the requested media content.
  • the viewer Web server interface receives the request, it forwards it to a task manager (again see the 6,407,680 patent and 10/644,602 application, incorporated by reference).
  • the task manager parses the request to determine if the necessary request information is included in order to service the request.
  • the request comprises an HTTP request
  • the task manager parses the header of the HTTP request to determine if the necessary information is included in order to service the request.
  • the necessary information includes at least a source location, a source type, a destination location, and a destination type.
  • the source type and destination type are each defined by at least one publishing variable.
  • publishing variables for media content can include, but are not limited to, the file format, bit rate, communication protocol(s), physical medium, compression algorithm, digital rights management information, or any combination thereof.
  • the information required for servicing the request includes at least a source location, a source format, a source bit-rate, a destination location, a destination format, and a destination bit rate. If the task manager determines that the request information is not complete, the task manager will fetch the necessary information as shown in steps 1506 and 1508.
  • the task manager can consult a database to find the necessary source information.
  • the task manager can perform a network request to fetch the necessary information from the content provider's web-site. For example, the task manager can perform an HTTP request, an RTSP request, or a request using any other standard network application protocol.
  • the task manager can fetch the needed information by querying the viewer client.
  • the optimal destination type for the destination location may be stored as a "cookie" on the viewer client, which may be accessed by the task manager.
  • the task manager determines what tasks need to be executed in order to deliver the requested media content.
  • the tasks include all the steps necessary to deliver the requested media content, and may include fetching the requested media content, transcoding the, requested media content from the source type into the destination type, and streaming the transcoded media content to the viewer client.
  • the task manager Once the task manager has determined what tasks need to be executed, it then interfaces with a resource manager (again see the 6,407,680 patent and 10/644,602 application, incorporated by reference) and instructs the resource manager to execute the required tasks.
  • the resource manager receives the instruction to execute the required tasks from the task manager and, at step 1 12, assigns each task to one or more machines within the machine farm.
  • the resource mana ⁇ ger is programmed to achieve an efficient execution of tasks by the available resources.
  • the allocalioii of resources to a given task by the resource manager is determined based on a variety of factors including, but not limited to, which machines support the necessary utilities for performing the required task, which machines have available resources (for example, available CPU), and which machines can coordinate with each other to carry out the task when coordination is required.for execution.
  • the resource manager can also be programmed to distribute tasks based on a variety of other criteria including the avoidance of network congestion. For example, the resource manager may be programmed to assign decompression and compression tasks to the same machine in order to avoid the network congestion that may result from transmitting uncompressed data from one machine to another within the internal network of the media transcoding engine.
  • the resource manager oversees tasks after they are assigned to make sure that they are properly executed.
  • the resource manager oversees the execution of assigned tasks by maintaining a list of all assigned tasks in the database and periodically communicating with the slave monitor of each machine running a given task in order to determine the status of the task.
  • the resource manager periodically polls the slave monitor of the machine to which the task has been assigned to determine the status of the task.
  • the slave monitor itself sends periodic status messages to the resource manager, informing it of the status of an assigned task.
  • the resource manager stores information that it receives from the slave monitors about the status of each task and each machine in the database in order to assist in its function of assigning and monitoring necessary tasks.
  • the slave monitors only initiate tasks received from the resource manager, and the tasks themselves report directly to the resource manager rather than to the slave monitors.
  • the resource manager monitors each assigned task in accordance with a fault tolerance, routine that permits the resource manager to determine when a task has failed and to execute the necessary steps for correcting the problem and ensuring the delivery of the requested media content. For example, if a machine to which a task has been assigned does not respond to a status query for a predetermined period of time, the resource manager can be programmed to reassign the task to a different machine and re-boot the machine that is not responding.
  • the resource manager can be programmed to shut down all the dependent tasks and re-assign the entire set of tasks in order to ensure the delivery of the requested media content.
  • individual tasks are each assigned a priority.
  • the resource manager monitors new tasks and when the priority of an existing task is lower than that of a new task that needs to be assigned, the resource manager will instruct the existing task to kill itself to accommodate the new higher-priority task. Alternately, the slave monitor can kill the existing task.
  • An example of a low priority task includes the transcoding of media content for a viewer after the viewer has stopped viewing the requested content. . • .
  • the task manager constructs a reply to the initial request to access media content received from the viewer client.
  • the reply serves to redirect the viewer client to a streaming server or proxy server from which the requested media content will ultimately be received by the viewer client.
  • the reply comprises an HTTP reply.
  • a determination is made whether auto source type detection in accordance with a preferred embodiment is turned on.
  • the system may be permanently set to automatic source type detection on or to automatic source type detection off or it may be selectively toggled.
  • the method move to the corresponding step 1534 or 1536.
  • the method illustrated at Figure 6B after the determination is made, then the method move to the next corresponding step. That is, if automatic source type detection is turned on, then at step 1534, source type information is automatically fetched from source server or client. An advantage is that this is quicker and . simpler for the user, Alternatively, if automatic source type detection is turned off* then at step 1536, input is requested through a source user/interface from a user who is demanding the content. An advantage is that a user with multiple source types for the content can choose between them, or if the source has a firewall such that the source type cannot be readily detected with user input.
  • the system may be permanently set to automatic destination type detection on or to automatic destination type detection off or it may be selectively toggled. If the automatic destination type detection is permanently on or off, then the determination is not necessary and the method can move to the corresponding step 1540 or 1542. In the method illustrated at Figure 6B, after the determination is made, then the method move to the next corresponding step. That is, if automatic destination type detection is turned ⁇ ri, then at step 1540, destination type information is automatically fetched from destination server or client. An advantage is that this is quicker and simpler for the user.
  • step.1542 input is requested through a destination user interface from a user who is demanding the Content.
  • An advantage is that a user with multiple destination types for the Content can choose between them, or if the destination has a firewall such that the destination type cannot be readily detected with user input.
  • Further criteria independent of destination type may be detected and applied based upon designated rules, e.g., as set out by the publisher of the media content or otherwise based upon a business rule. For example, bandwidth criteria may be based upon a customer's contract, or a trailer or a clip or both may be inserted with the transcoded media content upon request by a publisher.
  • the machines within the machine farm perform the .
  • the delivery of media content is a pipelined process in which the fetching, transcoding and streaming of different portions of the same media content stream may occur simultaneously.
  • the resource manager arranges for the pipelining of these steps through resource allocation within the media transcoding engine. The pipelining of these steps results in a faster delivery time for requested media by the media transcoding engine.
  • the appropriate destination type e.g., the appropriate destination format and bit-rate or other appropriate publishing variables
  • one or more transmitter servers within the machine farm begins fetching the requested media content as a data stream from the source location as shown at step 1518.
  • the requested media content can initially either reside within a master archive within the media transcoding engine, in an archive external to the media transcoding engine, or be received as a streaming feed directly from the content provider client. Where the requested media content resides within the master archive, one of the transmitter servers fetches the requested media content over the internal network of the media transcoding engine.
  • one of the transmitter servers uses the access information provided during the publishing process to fetch the requested media content.
  • the requested media content may be temporarily cached in the master archive, permitting expedited access to the media content when subsequent requests for the same media content are received by the media transcoding engine.
  • the requested media content is a streaming feed directly from the content provider client
  • one of the transmitter servers fetches the streaming data from the content provider Web server interface. Because embodiments of the present invention do not fetch and transcode the streaming data until it is actually requested by a viewer,. unnecessary transcoding of media content is thereby avoided.
  • step 1520 after the transmitter server begins fetching the requested media content, if the source type is the same as the destination type (e.g., the source format and bit rate is the same as the destination format and bit-rate), then no transcoding is necessary and the media content is transmitted to the streaming servers as soon it is fetched.
  • the streaming servers then stream the content to the viewer client at step 1524, as described below.
  • the source type is not the same as the destination type, then one of the transcoding servers within the machine farm will transcode the media content from the source type to the destination type as shown in step 1522.
  • the resource manager assigns the transcoding task to a transcoder server that runs the necessary transcoder .
  • the transcoding is carried out using one of a variety of well-known methods and for converting media content of one type to another, including conventional codec routines for transcoding media content. Further description of transcoding operation and examples are provided below.
  • a copy of the transcoded media content is temporarily stored in the transcoded cache, permitting expedited delivery of the media content when subsequent requests for the same media content transcoded into the same destination type are received by the media transcoding engine.
  • one of the streaming servers streams the media content in the appropriate destination type to the viewer client as soon as it is received from either a transcoder, a transmitter or the transcoded cache.
  • the transcoded media content is streamed to the viewer client via an optional proxy server.
  • either the streaming server or the optional proxy server keep usage statistics pertaining to the media content being delivered as well as the destination types in which the media content is being delivered that are used by the resource manager for cache management purposes.
  • the protocol used for streaming media to the viewer client and for streaming data between the transmitter servers, transcoder servers and the streaming servers is a standard protocol for streaming media, such as RTSP. Alterriately, a proprietary protocol defined over standard network protocols like TCP/UDP can be used.
  • different protocols may be used to accommodate different network infrastructure needs. For example, protocols may be implemented that dynamically change according to network traffic conditions. However, these examples are illustrative.
  • the viewer client receives the streaming media content from either the streaming server or the proxy server.
  • the viewer client plays the media content in accordance with the destination type associated with the media player resident on the viewer client.
  • the media content may be received and stored as a downloaded file on the viewer client for playing at a later time, or for transfer to an alternate media playing device.
  • a media transcoding engine may include one or more transcoders.
  • Transcoders convert certain types of media content (referred to herein as a source type) to another type of media content (referred to herein as a destination type).
  • Transcoding can involve a number of different conversion operations. The particular conversion operations used depend upon the media content and associated publishing variables being converted. This is why the efficient detection of the configuration information of a client, which maybe a destination, is advantageous.
  • Publishing variables as used herein refer to different characteristics of media content.
  • media content is digital data being published over a network. In this case, publication refers to digital data which has been formatted for delivery over a network and for viewing by a destination media player.
  • Publishing variables for media content can include, but are not limited to, the file format, bit rate, communication protocol(s), physical medium, compression algorithm, and/or digital rights management information.
  • the digital data can be any type of file format including but not limited to container formats, bitmap formats, video formats, audio formats, vector formats, metafile formats, scene formats, animation formats, multimedia formats, hybrid formats, hypertext and hypermedia formats, three-dimensional data (3D) formats, virtual reality rnodeling language (VRML) formats, font formats (bitmap fonts, stroke fonts, spline-based outline fonts), page description language (PDL) formats, and any other type of graphics file format or other file format.
  • container formats bitmap formats, video formats, audio formats, vector formats, metafile formats, scene formats, animation formats, multimedia formats, hybrid formats, hypertext and hypermedia formats, three-dimensional data (3D) formats, virtual reality rnodeling language (VRML) formats, font formats (bitmap fonts, stroke fonts, spline-based outline fonts), page description language (
  • Table 1 lists examples of such file formats that can be used in embodiments of the present invention: TABLE 1 Example File Formats Format Type ADOBE ILLUSTRATOR Metafile ADOBE PHOTOSHOP Bitmap ATARI ST GRAPHICS FORMATS Bitmap and Animation AUTOCAD DXF Vector AUTODESK • 3D STUDIO Scene Description BDF Bitmap BRL-CAD Other BUFR Other CALS RASTER Bi map CGM Metafile CMU FORMATS. Multimedia DKB .Scene Description DORE RASTER FILE FORMAT Bitmap DPX Bitmap DR.
  • Compression algorithm choices can be made based on optimization according to bit-rate choices, or according to the nature of the content. For example, video files in which little motion occurs (“talking heads") and video files in which there is a substantial amount of motion (“high-motion” video) may each be more efficiently compressed using different compression algorithms. Within any one compression algorithm, there can be further variations. For example, files compressed according to the JPEG standard can be either YUV -based or RGB-based. With respect to the digital rights management system of the preferred embodiment, a media player on a client computer detected in accordance with an aspect of the invention determines the DRM information type, or usage rule type, which it can handle.
  • Windows Media Player can interpret and/or handle usage rules, provided by Microsoft Windows Media DRM system, but generally cannot interpret and/or handle those provided by Real's Helix DRM system.
  • RealOne player can interpret and/or handle those provided by Real's Helix DRM system, but cannot interpret and or handle those provided by Microsoft Windows Media DRM system. That is, a media player type generally has a one-to-one correspondence to DRM type that it can interpret.
  • DRM information or usage rule information may be described by XrML, XML or the like including tags and their values. DRM information or usage rule information may also be attached to content. Otherwise, it may be separated physically from content and is associated logically to content through content ID or the like.
  • DRM information or usage rule information may also define how and or when a user can use the associated content.
  • the server system can automatically detect media player type on a client computer, determine a DRM type on the client computer based on media player type, and automatically transcode DRM information or usage rule information to be able to interpret and/or handle it on the client computer.
  • DRM information may be transcoded from source type (e.g., MSFT Windows Media DRM) to destination type (e.g., Real Helix).
  • source type e.g., MSFT Windows Media DRM
  • destination type e.g., Real Helix
  • the advantageous method includes sending player detection code to the user's computer, receiving configuration information regarding the user's computer, and determining a type of digital rights management information on the user's computer based on the received configuration information.
  • publishing variables set forth above there are also publishing variables unique to video data and audio data.
  • Publishing variables for video data include the width and height of the video image in pixels as well as the frame rate of the video. Depending on the bit- rate requirements and the nature of the data, different settings may be necessary in order to ensure the best picture quality. For example, some video may be better viewed at 15 frames per second at 160x120 pixels, while some others may be better viewed at 5 frames per second at 320x240 pixels, even at the same bit-rate.
  • FIG. 7 shows an example transcoder. that transcodes on demand source type media content 610 to destination type media content 650.
  • Source type media content 610 is digital data delivered over a network in one or more packets.
  • the digital data that forms source type media content 610 is defined by one or more publishing variables.
  • the publishing variables as shown in Figure 7 include one or more of the following variables: source file format, source bit rate, source physical medium, source communication protocol, source encoding, or any combination thereof.
  • Destination type media content 650 is digital data delivered over a network in one or more packets to an end user that demands the media content.
  • the digital data that forms destination type media content 650 is also defined by one or more publishing variables.
  • the publishing variables as shown in Figure 7 include one or more of the following variables: destination file format, destination bit rate, destination physical medium, destination communication protocol, destination encoding, or any combination thereof.
  • Figure 8 shows a table of an example implementation where one or more transcoders transcodes on demand from a source type media content 710 to a first destination type 750.
  • Figure 8 also shows an example implementation where one or more transcoders transcodes " on demand from a source type media content 710 to a second destination type 760.
  • the source type media content 710 includes digital data published according to the following source publishing variables: namely, the physical medium is a local disk, the communication protocol includes a file I/O, the file format is MP3 using MP3 encoding at a bit rate of 128 kilobits per second (kbps).
  • the first destination type media content 750 includes digital data transcoded for publication according to the following destination publishing variables: namely, the physical medium is a packet-switched network (the Internet), the communication protocol includes WINDOWS MEDIA STREAMING MMS protocol, the file format is WINDOWS MEDIA FILE, using MP3 encoding at a bit rate of 56 kbps.
  • the second destination type media content 760 includes digital data transcoded for publication according to the following destination publishing variables: namely, the physical medium is a Wireless Network, the communication protocol includes HTTP, the file format is MP.3 including MP3 encoding at a bit rate of 12 kbps.
  • Tables 2-5 Example Transcoder Operations TABLE 2 Publishing Variables
  • Source Type Destination Type physical medium Disk Network communication protocol (s) File I/O RTSP container format MPEG1 QUICK TIME encoding MPEG1 SORENSON (video) QDESIGN (audio) bit rate 1.5 Mbps 300 kbps
  • Wired Network Wired Network communication protocol HTTP RTSP .container format QUICK TIME, .REAL encoding H.263 REAL PROPRIETARY G2 Video/Audio bit rate 56 kbps 56 kbps
  • Figure 9 is a table showing exemplary client environment variable types according to an embodiment of the invention.
  • the system of the preferred embodiment is capable of determining further characteristics of client systems including operation system (OS) versions, ' web browser versions, hardware platforms and user interface languages.
  • OS operation system
  • This capability is an advantageous improvement even over a system that includes the advantageous ability to discern which type of OS, e.g., Windows, Mac or Linux, is being used on the client machine. For example, even " if it is known the system uses Windows, an assumption of aversion more recent than the client actually has could result in complete failure of the media stream and a conservative assumption of a much earlier version can result in inefficiencies.
  • OS operation system
  • a source type 810 i.e., where the media content is coming from and configured for initially, having Window XP as its OS version, Navigator 3.0 as its browser version, a Pentium 4 processing chip installed and using Javascript for Navigator 3.0 as its user interface language.
  • These source types may be provided or determined similar to the determination of the client configuration described in accordance with an embodiment herein.
  • the destination types 850 are illustrated as being Mac OS X operating system, Omniweb 4.1 web browser version, a G3 processor chip, and user interface language XSLT for Omniweb 4.1.
  • Example embodiments of the methods and systems of the present invention have been described herein. As noted elsewhere, these example embodiments have been described for illustrative purposes only, arid are not limiting. Alternate embodiments, differing slightly or substantially from those described herein, will be apparent to persons skilled in the relevant art based on the teachings contained herein. For example, one skilled in the relevant art will appreciate that the transcoding system and method of the present invention is not limited to the transcoding and delivery of media content alone, but also encompasses the transcoding and delivery of information of all types, including, but not limited to compressed files, electronic documents, HTML pages, XML documents, and any other information that can be stored in a plurality of formats and delivered electronically.
  • systems and methods for the on-demand transcoding of media content from a source type to a destination type may be provided, wherein the system includes a plurality of transcoders for transcoding from a plurality of source types to a plurality of destination types, and wherein the system receives a transcoding request for media content, fetches the media content in response to the transcoding request, sends the media content to one of the plurality of transcoders based on the source type and destination type transcodes the media content from the source type to the destination type, thereby generating transcoded media content, and transmits the tf ansGOded media content.
  • the system may fetch, send, and transcode the media content arid transmit the transcoded media content in a pipelined fashion.
  • the system may also provide for the publication of media content as a file or stream of digital data, for the archiving of media content, and the caching of transcoded media content to improve system efficiency.
  • the operations have been described in selected typographical sequences. However, the sequences have been selected and so ordered for typographical convenience and are not intended to imply any particular order for performing the operations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention concerne une méthode pour déterminer à distance la configuration d'un ordinateur d'un utilisateur de contenu multimédia. Cette méthode consiste à envoyer un code de détection de joueur concernant l'ordinateur de l'utilisateur et à recevoir des informations de configuration concernant l'ordinateur de l'utilisateur. L'invention concerne une méthode de détermination d'une vitesse de connexion d'un ordinateur. Cette méthode consiste à déterminer la taille d'un bloc de synchronisation, en fonction d'une largeur de bande estimée et à extraire ce bloc de synchronisation. La vitesse de connexion est déterminée en fonction de la taille du bloc de synchronisation et des périodes de début et de fin de transfert.
EP04796800A 2003-10-31 2004-10-29 Systeme, methode et produit de programme informatique pour determiner a distance la configuration d'un utilisateur de contenu multimedia Ceased EP1682980A4 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10010727A EP2278461A1 (fr) 2003-10-31 2004-10-29 Système, procédé, et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia
EP08016181A EP2026535A1 (fr) 2003-10-31 2004-10-29 Système, procédé et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US51601703P 2003-10-31 2003-10-31
US10/700,409 US7356575B1 (en) 2001-11-09 2003-11-03 System, method, and computer program product for remotely determining the configuration of a multi-media content user
PCT/US2004/036087 WO2005043329A2 (fr) 2003-10-31 2004-10-29 Systeme, methode et produit de programme informatique pour determiner a distance la configuration d'un utilisateur de contenu multimedia

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP08016181A Division EP2026535A1 (fr) 2003-10-31 2004-10-29 Système, procédé et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia

Publications (2)

Publication Number Publication Date
EP1682980A2 true EP1682980A2 (fr) 2006-07-26
EP1682980A4 EP1682980A4 (fr) 2008-03-26

Family

ID=34556076

Family Applications (3)

Application Number Title Priority Date Filing Date
EP10010727A Ceased EP2278461A1 (fr) 2003-10-31 2004-10-29 Système, procédé, et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia
EP04796800A Ceased EP1682980A4 (fr) 2003-10-31 2004-10-29 Systeme, methode et produit de programme informatique pour determiner a distance la configuration d'un utilisateur de contenu multimedia
EP08016181A Ceased EP2026535A1 (fr) 2003-10-31 2004-10-29 Système, procédé et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP10010727A Ceased EP2278461A1 (fr) 2003-10-31 2004-10-29 Système, procédé, et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP08016181A Ceased EP2026535A1 (fr) 2003-10-31 2004-10-29 Système, procédé et produit de programme informatique pour déterminer à distance la configuration d'un utilisateur de contenu multimédia

Country Status (4)

Country Link
EP (3) EP2278461A1 (fr)
JP (2) JP4761158B2 (fr)
KR (1) KR101089934B1 (fr)
WO (1) WO2005043329A2 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7991891B2 (en) 2006-02-02 2011-08-02 Microsoft Corporation Version-specific content searching
CN101443743B (zh) * 2006-05-12 2011-04-20 株式会社爱可信 终端、网络系统以及状态描述信息提供方法
US8139487B2 (en) * 2007-02-28 2012-03-20 Microsoft Corporation Strategies for selecting a format for data transmission based on measured bandwidth
EP2400746B1 (fr) * 2008-06-27 2013-02-20 Kabushiki Kaisha Toshiba Récepteur de télévision, procédé de contrôle du récepteur et dispositif de construction du réseau
CN102387121B (zh) * 2010-08-30 2014-07-23 株式会社日立制作所 管理服务器、影像分发控制系统及影像分发控制方法
CN102571769A (zh) * 2010-12-31 2012-07-11 北京华夏未来信息技术有限公司 一种自适应终端分辨率的方法及系统
CN104380275B (zh) * 2012-04-23 2017-10-13 阿弗梅德网络公司 用于http伪流的基于积分控制器的定步
EP2763376B1 (fr) 2013-01-31 2018-02-21 Samsung Electronics Co., Ltd Procédé et dispositif pour la fourniture d'un service
CN105099602A (zh) * 2014-04-25 2015-11-25 阿里巴巴集团控股有限公司 一种基于网速传输文件的方法及系统
KR101942269B1 (ko) * 2017-01-20 2019-01-25 한화테크윈 주식회사 웹 브라우저에서 미디어를 재생하고 탐색하는 장치 및 방법
US11089349B2 (en) 2017-01-20 2021-08-10 Hanwha Techwin Co., Ltd. Apparatus and method for playing back and seeking media in web browser

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007418A1 (en) * 2000-07-13 2002-01-17 Vendaria, Inc. Method and system for delivering and monitoring an on-demand playlist over a network
US20030093507A1 (en) * 2001-11-09 2003-05-15 Generic Media, Inc. System, method, and computer program product for remotely determining the configuration of a multi-media content user

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3394352A (en) 1965-07-22 1968-07-23 Electronic Image Systems Corp Method of and apparatus for code communication
FR2234708B1 (fr) 1973-06-22 1976-09-17 Thomson Csf
JP3208039B2 (ja) 1995-03-09 2001-09-10 ケイディーディーアイ株式会社 画像符号化データのレート変換装置
US5928330A (en) 1996-09-06 1999-07-27 Motorola, Inc. System, device, and method for streaming a multimedia file
US6317134B1 (en) 1996-09-13 2001-11-13 Silicon Graphics, Inc. System software for use in a graphics computer system having a shared system memory and supporting DM Pbuffers and other constructs aliased as DM buffers
US6070002A (en) 1996-09-13 2000-05-30 Silicon Graphics, Inc. System software for use in a graphics computer system having a shared system memory
US6466939B1 (en) 2000-03-31 2002-10-15 Microsoft Corporation System and method for communicating video data in a digital media device
JP2001333410A (ja) * 2000-05-22 2001-11-30 Sony Corp メディアデータの提供を最適化するためのメタデータ使用方法及びシステム
US6934933B2 (en) 2000-08-14 2005-08-23 Twin Communications Of America, Inc. Portable operating environment for information devices
US20020099770A1 (en) 2000-09-08 2002-07-25 Muse Corporation Hybrid communications and interest management system and method
US6407680B1 (en) 2000-12-22 2002-06-18 Generic Media, Inc. Distributed on-demand media transcoding system and method
US7092987B2 (en) * 2001-02-13 2006-08-15 Educational Testing Service Remote computer capabilities querying and certification
US20020170065A1 (en) * 2001-05-08 2002-11-14 Pinnick Skyler D. Apparatus and method of managing compression of video and delivery of video over the internet
US20020099858A1 (en) 2001-08-06 2002-07-25 Muse Corporation Network communications protocol
JP2003141011A (ja) * 2001-11-08 2003-05-16 Nec Soft Ltd リモートセットアップシステム及びプログラム
EP1326185A1 (fr) * 2002-01-08 2003-07-09 Alcatel Analyse hors ligne du comportement d'utilisateur pour la personalisation en ligne d'un service plus valeur
US7155475B2 (en) 2002-02-15 2006-12-26 Sony Corporation System, method, and computer program product for media publishing request processing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007418A1 (en) * 2000-07-13 2002-01-17 Vendaria, Inc. Method and system for delivering and monitoring an on-demand playlist over a network
US20030093507A1 (en) * 2001-11-09 2003-05-15 Generic Media, Inc. System, method, and computer program product for remotely determining the configuration of a multi-media content user

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LARRY BOUTHILLIER: "Detecting Streaming Media Players and Connection Speed Tutorial" [Online] 18 February 2003 (2003-02-18), , XP002467766 Retrieved from the Internet: URL:http://www.streamingmedia.com/article.asp?id=8396&page=1> [retrieved on 2008-02-05] * the whole document * *
See also references of WO2005043329A2 *

Also Published As

Publication number Publication date
WO2005043329A2 (fr) 2005-05-12
JP4761158B2 (ja) 2011-08-31
EP2278461A1 (fr) 2011-01-26
JP5477655B2 (ja) 2014-04-23
KR20060113678A (ko) 2006-11-02
EP1682980A4 (fr) 2008-03-26
KR101089934B1 (ko) 2011-12-05
JP2011066916A (ja) 2011-03-31
JP2007517276A (ja) 2007-06-28
EP2026535A1 (fr) 2009-02-18
WO2005043329A3 (fr) 2006-10-19

Similar Documents

Publication Publication Date Title
US8843589B2 (en) System, method, and computer program product for remotely determining the configuration of a multi-media content user
US7356575B1 (en) System, method, and computer program product for remotely determining the configuration of a multi-media content user
JP5477655B2 (ja) 情報処理方法および記録媒体
US9276984B2 (en) Distributed on-demand media transcoding system and method
US7242324B2 (en) Distributed on-demand media transcoding system and method
US7647386B2 (en) System, method, and computer program product for remotely determining the configuration of a multi-media content user
US20220109737A1 (en) Method and system for streaming applications using rate pacing and mpd fragmenting
US5838927A (en) Method and apparatus for compressing a continuous, indistinct data stream
CN100458747C (zh) 用于确定计算机的连接速度的方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060524

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 13/00 20060101AFI20061123BHEP

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101ALI20080213BHEP

Ipc: G06F 9/445 20060101AFI20080213BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20080225

17Q First examination report despatched

Effective date: 20080513

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SONY CORPORATION

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150714