The present invention relates to a method and system for configuring the creation of video files based on specific criteria. The specific criteria may be standard or provided by the ultimate recipient or user of the video file, such as a media network or distributor.
The art of media technology today is characterized by a number of incompatible digital file types. Previously, when video tape was used, there were only a few tape formats (e.g., in the range of 10-15 tape formats), and the tapes of a given format were compatible with each other. For example, if a Sony high-definition video digital recording videocassette (HDCAM) deck was used, all Sony HDCAM tapes would work on the HDCAM deck regardless of who created the tape.
Today, there are hundreds of thousands of digital video file variations. As a result, file compatibility is an enormous problem for media technology companies seeking to move away from standard video tape. There is a need, therefore, for a method and system that enables the makers of video files to create such files to a given specification, in order to ensure that all files used by a given user are created to the user's specification and are of the same, or at least of a compatible type.
There is a further need in the art to define physical media (e.g., video or audio inputs), file parameters, and metadata requirements of a multimedia file as a plurality of precise parameters, tags and values necessary to describe the physical media in a format that may be read and used directly by content editing, compounding and bundling systems contemplated on various computing platforms.
In light of the above-described problems and shortcomings, aspects of the present invention relate to methods and systems that enable the makers of video files to create such files to a given specification, in order to ensure that all files used by a given user are created to the user's specification and are of the same, or at least of a compatible type.
Further, aspects of the present invention are directed to methods and systems for defining physical media (e.g., video or audio inputs), file parameters, and metadata requirements of a multimedia file as a plurality of precise parameters, tags and values necessary to describe the physical media in a format that may be read and used directly by content editing, compounding and bundling systems contemplated on various computing platforms.
Yet further aspects of the present invention are directed to methods, systems and computer program products, relating to configuring a plurality of parameters of a shim file to define a format of at least one media content input, creating a file based program master based on the shim file, and providing the created file based program master to a user for creating and delivering the at least one media content input.
Additional advantages and novel features of these aspects of the invention will be set forth in part in the description that follows, and in part will become more apparent to those skilled in the art upon examination of the following or upon learning by practice of the invention.
Various exemplary aspects of the systems and methods will be described in detail, with reference to the following figures, wherein:
These and other features and advantages of this invention are described in, or are apparent from, the following detailed description of various example aspects.
The present invention, in accordance with an aspect, is directed to determining a plurality of parameters of a shim file to define a format of at least one media content input, creating a file based program master based on the shim file, and providing the created file based program master to a user for creating and delivering the at least one media content input. In accordance with one aspect, the present invention is directed to methods and systems for defining physical media (e.g., video or audio inputs), file parameters, and metadata requirements of a multimedia file as a plurality of precise parameters, tags and values necessary to describe the physical media in a format that may be read and used directly by content editing, compounding and bundling systems contemplated on various computing platforms.
In accordance with an aspect of the present invention, the following terminology may be used to describe various different parts of a file based program master. For example, “Essence” may refer to an actual video or audio content contained within a file. A “Volume” may be a logical drive created on the physical media by a file system. In some instances, volumes may be given names and drive letters. The “Root” of a volume may be the topmost layer of organization, and “Folders” may be following layers of organization within a volume. In addition, a folder may be created within the root of a volume or nested within another folder. Further, a file “Wrapper” may refer to a digital container that holds the video and audio essence along with at least a portion of the file metadata. Wrapper formats are often associated with certain file extensions. The .MOV extension, for example, indicates that the file may use a Quicktime wrapper.
In some aspects, in defining physical media (e.g., video or audio inputs), file parameters, and metadata requirements for file based program masters, one or more shim files may be created to contain a plurality of precise parameters, tags and values that may be necessary to describe the physical media in a format that may be read and used directly by content editing, compounding and bundling systems contemplated on various computing platforms. For example, as a high-level structure requirement and for easy machine-readability, shim files may be constructed as Extensible Markup Language (XML) documents. More specifically, a top-level element in an XML document may include identifiers and useful annotations. Within the top level, the body of a shim file may be presented in the following nested levels:
In some aspects, there may be no more than a single possible Group within a Section, or a single possible Track within a Group. For simplicity of implementation and to allow for future growth, as shown in
Referring to
In some aspects, a shim identifier (shim_id) may be defined to identify a shim file (interchangeably referred to herein as a “shim”) and the identifier is intended to signal a version of the shim that is in use when a bundle of associated media files and information are to be created or modified. Annotation text defining the attributes may be provided.
Further, as described above, each Section may describe a major division of the content, such as Main, Audio, Graphics, Metadata. A general form of a Section may be:
<Section name=“{name}”>
</Section>
Where {name} is a section name, written in UpperCamelCase, unique throughout the entire shim namespace; and {content} is a sequence of one or more Groups (see below).
Each Group may describe a part of a Section. For example, within Graphics there may be Groups for Open, Credits, Lower Thirds Graphic, for example, and a general form of a Group may be:
<Group name=“{name}”>
</Group>
Where {name} is the group name, written in UpperCamelCase, unique throughout the entire shim namespace; and {content} is a sequence of one or more Wrappers (see below).
Each Wrapper may describe a file wrapper which contains a collection of Tracks. For example, within the Program there may be a Wrapper whose type (e.g., described by Paramaters) is a MOV file written by QuickTime. A general form of a Wrapper may be:
<Wrapper name=“{name}”>
{content}
</Wrapper>
Where {name} is the Wrapper name, written in UpperCamelCase, unique throughout the entire shim namespace; and {content} is a sequence of one or more Tracks (see below).
Each Track may describe, e.g., a particular usage of Essence within a Group. For example, within the Audio Section may be a Narration Group with an ENG Track and a SPA Track. Tracks may be single-channel (for example, Picture), or multi-channel (for example, Stereo or Surround). A general form of a Track may be:
<Track kind=“{kind}” name=“{name}” index=“{index}”>
</Track>
Where
{kind} is the Track kind, which may be one of Picture, Sound, Data, Text.
{name} is the Track name, written in UpperCamelCase, unique throughout the entire shim namespace.
{index} is the index of a specific Track when several Tracks are permitted.
{content} is a sequence of one or more Parameters (see below).
This form may permit a description of multiple tracks, for example:
<Track kind=“Audio” name=“AI” index=“1”>
</Track>
<Track kind=“Audio” name=“A2” index=“2”>
</Track>
Each Parameter may describe a named aspect of a Track (or perhaps a Group or Section) and may specify a required value. For example, an Audio/Narration/ENG Track may have a parameter name “Wrapper” and a value “BWAV” (an abbreviation for Broadcast Wave File Format). The general form of a Parameter may be:
<Parameter name=“{name}” index=“{index}” type=“{type}”>{value}</Parameter>
Where
Each SubParameter may describe a named aspect of a Parameter and specify a required value. SubParameters may be provided to help organize the namespaces for Parameter and SubParameter names and avoid issues with non-unique names. The general form of a SubParameter may be:
<Subparameter name=“{name}” index=“{index}” type=“{type}”>{value}</Subparameter>
Where
Limits may be optional, for example. In cases where there is a single allowed value for a Parameter, that value may be provided as simple content of the Parameter element. When a range of values, or one or more of an enumeration of values is required, the value may be specified using one or more <Limit/>elements in place of the simple content.
Each Limit may be expressed as a predicate including a relation and one or more values. For example:
<Parameter name=“VideoBitRate”>
</Parameter>
Or
<Parameter name=“VideoCodec”>
</Parameter>
Or
<Parameter name=“Language”>
</Parameter>
It should be understood that other Limits may also be defined.
Each ParameterSet may describe a collection of Parameters, SubParameters or Limits, for example, and their corresponding values that may be applied to a Track (or perhaps a Group or Section) and may specify a required value. For example, a ParameterSet “PCM_48_20” may define parameters for 48 kHz 20 bit PCM audio that can be used by many Tracks. The general form of a ParameterSet may be:
<ParameterSet name=“{name}”>{value}</ParameterSet>
Where
In some aspects, in addition to the foregoing generic shim syntax, the following shim elements may be configured. For example, Sections may comprise Main, SupplementalAudio, Metadata, and Graphics. Groups within a given Section may comprise: Main Groups; Groups within a Supplemental Audio Section; Groups within a Metadata Section; and Groups within a Graphics Section. In one aspect, there may be only a single Group in the main section for a program.
For Wrappers within given Groups, in some aspects, there may be only a single Wrapper in the main Group in a main Section. Additionally, for Tracks within a Main Wrapper and within a Main Group, shims may comprise Timecode, Video and Audio Tracks.
Referring to
With respect to Limits, in some aspects, shims may specify the permitted Version of the Video Codec with a “greater_equal” limit.
Furthermore, ParameterSets may be configured to define Audio ParameterSets. In one aspect, as most, if not all, Audio Tracks use the same Parameters and SubParameters, to avoid unnecessary repetition, a ParameterSet named “PCM_mono_48_20” may gather and define the common Parameters and SubParameters such as AudioCodec:Coding, AudioSampling:Channels, AudioSampling:BitsPerSample, and AudioCoding:SamplingRate.
Referring to
Referring to
Referring to
Referring to
Referring to
Computer system 3200 includes one or more processors, such as processor 3204. The processor 3204 is connected to a communication infrastructure 3206 (e.g., a communications bus, cross-over bar, or network). Various software aspects are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
Computer system 3200 can include a display interface 3202 that forwards graphics, text, and other data from the communication infrastructure 3206 (or from a frame buffer not shown) for display on a display unit 3230. Computer system 3200 also includes a main memory 3208, preferably random access memory (RAM), and may also include a secondary memory 3210. The secondary memory 3210 may include, for example, a hard disk drive 3212 and/or a removable storage drive 3214, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 3214 reads from and/or writes to a removable storage unit 3218 in a well-known manner. Removable storage unit 3218, represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to removable storage drive 3214. As will be appreciated, the removable storage unit 3218 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative aspects, secondary memory 3210 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 3200. Such devices may include, for example, a removable storage unit 3222 and an interface 3220. 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 erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 3222 and interfaces 3220, which allow software and data to be transferred from the removable storage unit 3222 to computer system 3200.
Computer system 3200 may also include a communications interface 3224. Communications interface 3224 allows software and data to be transferred between computer system 3200 and external devices. Examples of communications interface 3224 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 3224 are in the form of signals 3228, which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 3224. These signals 3228 are provided to communications interface 3224 via a communications path (e.g., channel) 3226. This path 3226 carries signals 3228 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and/or other communications channels. In this document, the terms “computer program medium” and “computer usable medium” are used to refer generally to media such as a removable storage drive 3280, a hard disk installed in hard disk drive 3270, and signals 3228. These computer program products provide software to the computer system 3200. The invention is directed to such computer program products.
Computer programs (also referred to as computer control logic) are stored in main memory 3208 and/or secondary memory 3210. Computer programs may also be received via communications interface 3224. Such computer programs, when executed, enable the computer system 3200 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 3210 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 3200.
In an aspect where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 3200 using removable storage drive 3214, hard drive 3212, or communications interface 3220. The control logic (software), when executed by the processor 3204, causes the processor 3204 to perform the functions of the invention as described herein. In another aspect, the invention is implemented primarily in hardware using, for example, hardware components, such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
In yet another aspect, the invention is implemented using a combination of both hardware and software.
While this invention has been described in conjunction with the exemplary aspects outlined above, various alternatives, modifications, variations, improvements, and/or substantial equivalents, whether known or that are or may be presently unforeseen, may become apparent to those having at least ordinary skill in the art. Accordingly, the exemplary aspects of the invention, as set forth above, are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the invention. Therefore, the invention is intended to embrace all known or later-developed alternatives, modifications, variations, improvements, and/or substantial equivalents.
This application claims the benefit of U.S. Provisional Application No. 61/731,402 entitled “METHOD AND SYSTEM FOR FILE BASED DELIVERY OF CONTENT” filed on Nov. 29, 2012, the entirety of which is incorporated by reference herein.
Number | Name | Date | Kind |
---|---|---|---|
7389474 | Rettig | Jun 2008 | B2 |
20060143191 | Cho | Jun 2006 | A1 |
20100149091 | Kota | Jun 2010 | A1 |
20120042050 | Chen | Feb 2012 | A1 |
20120084345 | Silbey | Apr 2012 | A1 |
20130111028 | Kondrad | May 2013 | A1 |
20130272394 | Brockmann | Oct 2013 | A1 |
Entry |
---|
Nested Relationships in XML, Visual Studio .Net 2003, http://msdn.microsoft.com/en-us/library/yk41a37k(v=vs.71).aspx, Archive Nov. 1, 2012, 1 page. |
Number | Date | Country | |
---|---|---|---|
61731402 | Nov 2012 | US |