US20090063693A1

Movatterモバイル変換

Info

Publication number: US20090063693A1
Application number: US11/847,855
Authority: US
Inventors: Robert W. Bond; Stephen E. JAFFE; Michael P. OUTLAW; Matthew A. TERRY; Matthew B. TREVATHAN
Original assignee: International Business Machines Corp
Current assignee: Kyndryl Inc
Priority date: 2007-08-30
Filing date: 2007-08-30
Publication date: 2009-03-05
Also published as: US20170331873A1; US10659510B2; US9807139B2; US20140222970A1

Abstract

A system and method for streaming media and, more particularly, to a system and method for active transcoding of content in a distributed system. The method includes receiving a file having predetermined parameters and sizing the file up to an optimal packet size according to a logarithmic scheme. The optimal packet size is a largest packet size. In further aspects, the method also includes providing a computer infrastructure operable to perform the steps herein. The system includes a media service, rules engine, log based job creator and a stream constructor. A computer infrastructure having computer readable medium to perform the processes described herein is also provided.

Description

FIELD OF THE INVENTION

The invention generally relates to a system and method for streaming media and, more particularly, to a system and method for active transcoding of content in a distributed system.

BACKGROUND OF THE INVENTION

In view of advancing technologies, the delivery of digitized media content over a network to end user computers has become commonplace. The term “media” refers to any information, including audio, video, data, text, or other content. To provide such content, communication protocols define how the digitized media content is exchanged over the network.

Digital representations of media content come in different types. These types are defined according to variables which can include file format, bit rate, compression algorithm, and/or digital rights management information associated with the media content. The type of digitized media content will also depend upon a number of factors, such as, the computing and/or networking technology used in the process of publishing.

Digitized media content types can also be categorized according to the type of physical medium that supports the storage of the media content. Digitized media types may also be categorized by the communication protocol or protocols used to transmit the media content. For example, in packet-switched networks such as the Internet, many layers of protocols are used such as, for example, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Real-Time Transport Protocol (RTP).

Transcoders are used to convert certain types of media content (source type) to another type of media content (destination type). This conversion is known as “transcoding,” which can involve a number of different conversion operations. Users incapable of accommodating the destination type of the transcoded files simply cannot access the content. As a result of the rapid development in media publishing technology, new internet and wireless device manufacturers must invest heavily in the transcoding of media content so that a variety of content can be experienced on new media playing devices as new destination types.

Conventional multi-type transcoding services are limited in that they can only divide media files into evenly split packets for processing, i.e., transcoding. For example, in a ten minute file that is 100 Mb, each minute of the file can only be partitioned into 10 Mb packets. Once the packets are equally divided, they are sent to the transcoder for processing. Such an even distribution, though, does not translate well to near real time. For example, in an on-demand transcoding environment, the system must wait for the first job to complete before informing the user that they can start streaming. In this case, as the transcoder works on a single job, this job must complete before a new job can enter the system. For this reason, it will take time (n) to process each job. Although this is acceptable in many circumstances, there may be circumstances where the results need to be streamed back to the client in a faster manner. This streaming could be a media stream, data stream or results for further/synchronized process.

Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.

SUMMARY OF THE INVENTION

In a first aspect of the invention, a method comprises receiving a file having predetermined parameters and sizing the file up to an optimal packet size according to a logarithmic scheme. The optimal packet size is a largest packet size.

In a second aspect of the invention, the method is provided for actively transcoding a file. The method comprises providing a computer infrastructure operable to: receive a file with predetermined parameters; size the file into different packet sizes up to an optimal packet size based on the predetermined parameters, with the optimal packet size being a largest packet size; and send the different packet sizes for processing, in a priority processing order of smallest to the optimal packet size.

In another aspect of the invention, a system comprises a media service, rules engine, log based job creator and a stream constructor. The media service is configured to receive a file with parameters. The rules engine is configured to store at least one encoding rule associated with the file. The log based job creator is configured to split the file into different packet sizes up to a maximum of an optimal packet size based on the encoding rules. The log based job creator can be overridden by a logarithm scheme provided by the file as one of the parameters. The stream constructor is configured to order a processed stream of data.

In yet another aspect of the invention, a computer infrastructure has a computer readable medium having a computer program executable to: size a file into different packets sizes based on a logarithmic scheme using predetermined parameters of the file, with an optimal size being a largest packet size; and send the different packet sizes for processing, in a priority processing order of smallest to the optimal size.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described in the detailed description which follows, in reference to the noted plurality of drawings by way of non-limiting examples of exemplary embodiments of the present invention.

FIG. 1 shows an illustrative environment for implementing the processes in accordance with the invention;

FIG. 2 shows an illustrative embodiment implementing the processes of the invention;

FIG. 3 shows a representation of different sized packets to be processed, in accordance with the invention;

FIGS. 4 and 5 show graphical implementations of the logarithm scheme in accordance with the present invention; and

FIG. 6 shows a flow diagram implementing processes in accordance with the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The invention generally relates to a system and method for streaming media and, more particularly, to a system and method for active transcoding of content in a distributed system. In embodiments, the system and method is configured for use with an audio, video or audiovisual media file, as well as for text files. By implementing the invention, files to be transcoded can be divided into optimally sized data chunks (packets) using a logarithmic algorithm to enable faster transmission in a data stream. By way of illustrative example, the system and method of the invention is configured to divide an incoming file into smaller packets based on a logarithmic algorithm. As the smaller data packets are processed and streamed back to the user, the logarithmic algorithm continues to divide the data file into larger packets for processing, until an optimal size data packet is reached. In this way, it is possible to allow a user to view smaller packets of data while the larger packets are processing, i.e., stream the entire job faster, compared to conventional systems. In embodiments, the splitting of the file may be linked, for example, to the transcoding needs of the devices. The invention can be used over any distributed network, for example, as discussed in more detail below.

System Environment

FIG. 1 shows anillustrative environment10 for managing the processes in accordance with the invention. Theenvironment10 includes acomputer infrastructure12 that can perform the processes described herein. In particular, thecomputer infrastructure12 includes acomputing device14 that comprises amedia engine30. Themedia engine30 makescomputing device14 operable to allow active transcoding of media (content) in a distributed computing system.

More specifically, themedia engine30 is configured to split content, e.g., audio, visual, audiovisual and text files (hereinafter referred generally as “media”) into different sized packets (jobs), e.g., non-uniformly sized packets, for processing within a distributedgrid transcoding environment34. As should be understood by those of skill in the art, the distributedgrid transcoding environment34 includes one or more grid computers configured to transcode the media. The media engine can also provide the split media file to multiple transcoders in the distributedgrid transcoding environment34 to decrease streaming time.

In one implementation, themedia engine30 determines job loads based on a logarithmic scheme, e.g., Log(x)*n, where “n” represents an optimal packet size and “x” represents time. As should be understood, the optimal packet size can be different sizes depending on the capacity and processing capabilities of the grid computers within the distributedgrid transcoding environment34. As such, the logarithmic scheme implemented by themedia engine30 not only determines and apportions different sized packets, themedia engine30 also provides the optimal media size packet (or packets) for each grid computer of thegrid transcoding environment34. In this way, several media packets of the different packet sizes or the same packet sizes can be sent to one or more grid computers over a period of time, which equal or substantially equal the optimal size. As the smaller packet sizes are processed, larger sized packets can be prepared and processed, until a largest optimal size packet is processed in accordance with the invention. This allows the most efficient use of the grid computers. In another embodiment, the invention is used for text files in which the logarithmic based algorithm will determine a dividing of the file either at the periods or paragraph ends.

As themedia engine30 begins the chunking process, it will send each media packet to agrid scheduler32. As the smaller packets are faster to process, thegrid scheduler32 will schedule the smaller jobs with top priority while the larger jobs can be scheduled later in the process. This increases response time of the streaming of the media by allowing the smaller packets to be viewed while thetranscoding environment34 is still processing the larger packets. In embodiments, the media engine will send a plurality of the different packet size, equal to or substantially equal to the calculated optimal size, over a period of time for processing. Once the packet size reaches optimal size, though, the media engine will then send only one optimal size packet per period of time for processes. However, if there is an interruption in the data stream, themedia engine30 can reduce packet size or number of packets in the data stream to better accommodate the grid computers of thegrid transcoding environment34.

Still referring toFIG. 1, thecomputing device14 includes aprocessor20, amemory22A, an input/output (I/O)interface24, abus26 and auser interface32. Thememory22A can include local memory employed during actual execution of program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Further, thecomputing device14 is in communication with the external I/O device/resource28 and astorage system22B. Thegrid scheduler32 can communicate with thestorage system22B. The I/O device28 can comprise any device, e.g., e keyboards, displays, pointing devices, etc., that enables an individual to interact withcomputing device14 and/or any device that enablescomputing device14 to communicate with one or more other computing devices using any type of communications link.

Theprocessor20 executes computer program code, which is stored inmemory22A and/orstorage system22B. As discussed herein, the computer program code executes the processes of the invention. While executing computer program code, theprocessor20 can read and/or write data to/frommemory22A,storage system22B, and/or I/O interface24. Thebus26 provides a communications link between each of the components incomputing device14. Thus,computing device14 shown inFIG. 1 may be provided on any distributed network.

Thecomputing device14 can comprise any general purpose-computing article of manufacture capable of executing computer program code installed thereon (e.g., a personal computer, server, handheld device, etc.). For the purposes of this description, the article of manufacture can be a computer-usable or computer readable medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-RNV) and DVD.

Thecomputing device14 is only representative of various possible equivalent-computing devices that may perform the processes described herein. To this extent, in embodiments, the functionality provided by thecomputing device14 can be implemented by a computing article of manufacture that includes any combination of general and/or specific purpose hardware and/or computer program code. In each embodiment, the program code and hardware can be created using standard programming and engineering techniques, respectively.

In embodiments, the invention provides a business method that performs the processes of the invention on a subscription, advertising, and/or fee basis. That is, a service provider, such as a Solution Integrator, could offer to perform the processes described herein. In this case, the service provider can create, maintain, deploy, support, etc., a computer infrastructure that performs the process steps of the invention for one or more customers. In return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement and/or the service provider can receive payment from the sale of advertising content to one or more third parties.

Illustrative Embodiments of the Invention

FIG. 2 shows an illustrative embodiment implementing the processes of the invention. In embodiments, themedia engine30 receives a media file to be transcoded. The media file may include the following parameters:

- File Size;
- Current File Format; and
- Export Format.
  In optional embodiments, the media file may include a desired logarithmic scheme and/or a scale. The scale can be represented as a scalar value of a per unit time measurement, as discussed in greater detail below.

Themedia engine30 includes amedia service30a, a log basedjob creator30b, arules engine30cand astream constructor30d. Themedia service30areceives the media file, and searches for the current file size and file format. In further or alternative embodiments, themedia service30amay also check for compression rules and media cache to determine whether the job has already been encoded. If the job has not been encoded, themedia service30acan send the optimal job size, job splitting rule, current format, export format, bit-rate, compression algorithm, and the length of the media to therules engine30cfor further processing.

Once themedia service30adetermines the current file size and file format (e.g., current and export format), themedia service30awill use the export format and current format to look up in therules engine30cthe encoding rule for the media file. Therules engine30c, in embodiments, can also determine the stream rate, scale and resolution of the media file.

Therules engine30c, using the information obtained from the media file, informs the log basedjob creator30bof the optimal job size for encoding of the media file. The log basedjob creator30buses this information to determine the job scheduling (packet sizes) using the logarithmic scheme in accordance with the invention. That is, the log basedjob creator30bwill determine the different packet sizes based on the optimal packet size, taking into account the information of the media file as well as the configuration of the transcoding environment. In alternative embodiments, the media file may include the logarithmic scheme, which overrides the log basedjob creator30b.

Themedia engine30 determines an optimal size of the media file to be sent to the grid computers via the logarithmic scheme. Themedia engine30 will begin to divide the media file into the different sized jobs using the logarithmic scheme. The smaller media job files which, in the aggregate, equal or substantially equal the optimal size can all be sent to thegrid computers34 for simultaneous processing. Thus, as should be understood and as an illustrative example, themedia engine30 determines an optimal size packet, e.g., 1000 k, and then begins to divide the media file into smaller packets, e.g., 10 packets of 100K, 20 packets of 50 k, etc. As the smaller packets equal the optimal size in aggregate, they can be sent to the grid computers for processing. In this case, each packet may be sent to aseparate grid computer34, simultaneously for processing. In an alternative scenario, as different grid computers have different processing capacities, it is contemplated that two or more of the smaller packets can be sent to the same grid computer, depending on its rated processing capacity. As the smaller packets are processed, themedia engine30 continues to divide the media file into larger and larger packets, e.g., 5 packets of 200 k, 2 packets of 500 k, until an optimal packet size, e.g., 1 packet of 1000 k, is reached.

Themedia engine30 will stop the splitting into different sizes once an optimal size is reached for processing. As themedia engine30 divides the media file, the media files (in aggregate equaling or substantially equaling the optimal size) will be sent to thegrid scheduler32, where the smaller sized jobs will be processed prior to the larger sized jobs. This allows longer jobs to complete while smaller jobs are streamed back to the user. In embodiments, the packets of different sizes will be sent to the grid scheduler in such a manner that a plurality of different sized packets equaling the optimal size can be processed over a predetermined time period.

As the jobs are processed in thegrid environment34, the transcoded media will be sent back to themedia engine30 for ordering by thestream constructor30d. As the processed jobs are ordered, they will be sent to the user. As shown inFIG. 2, audio, visual and/or audiovisual media are represented by the “stream” arrow, whereas, text files are represented by the “file” arrow”.

FIG. 3 shows a representation of different sized packets of a single media file to be processed, in accordance with the invention. As shown, the media packets are of various sizes, with size “4” being the optimal size. As discussed above, the smaller sized packets will be processed prior to the larger sized packets (and optimal size) such that the smaller jobs can be streamed back to the user while the larger jobs are being processed., e.g.,size1,size2,size3,size4. It should be understood that each different sized packets can be representative of a plurality of such sized packets such an optimal size is reached in an aggregate or combination of the different sized packets. In one example, a scenario can be envisioned in whichsize1 andsize2 packets, combined, are an optimal size and are processed in the grid environment at the same time.

A code snippet implemented by themedia engine30, in accordance with the invention, can be represented as follows:


	File Size
	Current File Format
	Export Format
	(Optional) Log algorithm
	(Optional) scale
	<File Name =”filename”>
	<Export>
	</Export>
	<Log>
	</log>
	<scale>
	</scale>
	</File>

FIG. 4 shows a graphical implementation of the logarithm scheme in accordance with the present invention. More specifically,FIG. 4 illustrates that over time (x-axis) it is possible to gradually increase the size of the job (y-axis) as jobs are put into the grid environment for processing. Also, in implementation, the graph ofFIG. 4 may be used to determine the media packet sizes. It should be recognized that the graph ofFIG. 4 is one illustrative example showing an implementation of the processes of the invention. Accordingly, it should be understood that the graph ofFIG. 4 should not be considered a limiting feature of the invention and that other examples are contemplated by the invention.

In the graph ofFIG. 4, the y-axis represents a job size in kilobytes and the x-axis represents time. In this example, the optimal job size is about 5 kbytes/sec, as shown by the plateau of the line corresponding to approximately 5 on the y-axis. In the logarithm scheme, this optimal size would be represented as Log(x)*5.

Graphically,FIG. 4 shows that the packet or job size of the media increases as time passes, until the optimal size is reached. As graphically shown, the objective is to start returning the first part of the data (media to be transcoded or data stream) as soon as possible and increase the length of jobs to maximize the streaming. Thus, instead of sending uniform sized jobs to the grid scheduler, the system and method of the invention creates smaller jobs at the start of the processing and larger, more uniform jobs as the processing approaches the end, until an optimal size is obtained.

Also, as can be represented inFIG. 4, a scale can be used for the x-axis to represent, in embodiments, a greater granularity to the system. In embodiments, the scale can be sent in or stored in the rules engine ofFIG. 2. In one illustration, without any scale, each number on the x-axis represents a second. Using a scale, though, each of the numbers on the x-axis may represent a fraction of a second, providing for greater granularity. For example, in a scale of 0.5, ½ steps on the x-axis will represent every second.

Using the graph ofFIG. 4 to determine the media packet sizes, in the example of a scale of 0.5, at one second, i.e., 0.5 on the x-axis, the resultant packet size is approximately 0.5 kbytes/sec. Thus, in the example using an optimal size of Log(x)*5, at one second (represented as 0.5 on the x-axis), the size of the packet is 1/10 of the optimal size of 5 kbytes/sec. (represented as 0.5 on the y-axis). As this is the case, then the packet size to send to the distributed grid at one second is 1/10 of 5 or 0.5 kilobytes. In this case, a total of 10 jobs can be sent in the first second. This same process can be used for the 2^nd, 3^rd, etc. second, until the total job is sent to the distributed grid for transcoding. In this manner, a plurality of the different packet sizes over a period of time can be sent for processing, which is equal the optimal size.

FIG. 5 shows a graphical implementation of the logarithm scheme in accordance with the present invention. In this example,FIG. 5 demonstrates log(x), log(x)*2 . . . log(x)*5. Similar toFIG. 4,FIG. 5 illustrates that over time (x-axis) it is possible to gradually increase the size of the job (y-axis) as jobs are put into the grid environment for processing. The graph ofFIG. 5 can also be used to determine overall job sizing in accordance with the invention.

In the example ofFIG. 5, the optimal job size varies depending on the designated optimal size “n” in log(x)*n. As shown inFIG. 5, if the user has a project of seven seconds,FIG. 5 graphically shows how varying the logarithm allows the user to manually vary the packet size across the system. For example, in a 1 k optimal packet size, the representation of the equation is log(x), in a 5 k optimal packet size representation of the equation is log(x)*5. In the example ofFIG. 5, the packets for the 5 k example can be divided into a first packet of 2 k, a second packet of 3 k, etc. until it reaches the vertical asymptote at 5 k. This similar procedure can be used for the optimal size of 1 k, 2 k, 3 k and 4 k example, using the processes described herein.

ILLUSTRATIVE EXAMPLE

FIG. 6 is an illustrative example implementing processes of the invention, which may be implemented in the environment ofFIG. 1 orFIG. 2. The process ofFIG. 6 may be implemented and executed from either a server, in a client server relationship, or they may run on a user workstation. Additionally, the invention can be implemented in an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In an embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system, as discussed above.

InFIG. 6, atstep200, the media engine receives a media file from the user. The media file may be visual, audio, audiovisual or text. Atstep205, the media engine determines the current and export format of the file and provides this information to the rules engine. Atstep210, the rules engine looks up the encoding rule for the file. Therules engine30c, in embodiments, can also determine the stream rate, scale and resolution of the media file. Atstep215, therules engine30cinforms the log based job creator of the optimal job size for encoding of the media file. Atstep220, the log basedjob creator30buses this information to determine the job scheduling (packet sizes) using the logarithmic scheme in accordance with the invention. That is, the media will be divided according to the logarithmic scheme, and sent to the grid scheduler for processing within the grid environment.

As the smaller packets are processed, they will be sent back to the media engine, and more specifically ordered in the stream constructor, atstep225. Atstep230, as the processed jobs are ordered, they will be sent to the user. The processes continue until all of the media is processed and sent back to the user, from preferably smallest job size to the largest, optimal job size.

While the invention has been described in terms of embodiments, those skilled in the art will recognize that the invention can be practiced with modifications and in the spirit and scope of the appended claims.