Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/845—Structuring of content, e.g. decomposing content into time segments
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/845—Structuring of content, e.g. decomposing content into time segments
  • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N5/00—Details of television systems
  • H04N5/222—Studio circuitry; Studio devices; Studio equipment
  • H04N5/262—Studio circuits, e.g. for mixing, switching-over, change of character of image, other special effects ; Cameras specially adapted for the electronic generation of special effects
  • H04N5/278—Subtitling
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N5/00—Details of television systems
  • H04N5/76—Television signal recording
  • H04N5/91—Television signal processing therefor
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
  • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
  • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
  • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
  • G11B27/036—Insert-editing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
  • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/47—End-user applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/47—End-user applications
  • H04N21/485—End-user interface for client configuration
  • H04N21/4856—End-user interface for client configuration for language selection, e.g. for the menu or subtitles
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N5/00—Details of television systems
  • H04N5/222—Studio circuitry; Studio devices; Studio equipment
  • H04N5/262—Studio circuits, e.g. for mixing, switching-over, change of character of image, other special effects ; Cameras specially adapted for the electronic generation of special effects
  • H04N5/265—Mixing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N5/00—Details of television systems
  • H04N5/76—Television signal recording
  • H04N5/84—Television signal recording using optical recording
  • H04N5/85—Television signal recording using optical recording on discs or drums
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N5/00—Details of television systems
  • H04N5/76—Television signal recording
  • H04N5/91—Television signal processing therefor
  • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N9/00—Details of colour television systems
  • H04N9/79—Processing of colour television signals in connection with recording
  • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
  • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
  • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
  • H04N9/8047—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction using transform coding
• • G—PHYSICS
  • G11—INFORMATION STORAGE
  • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
  • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
  • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
  • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
  • G11B20/00739—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction is associated with a specific geographical region

Definitions

• the present invention relates, in general, to data storage and archiving and, more specifically, to file formats for storing multiple tracks or streams of data.
• digital versatile disc or digital video disc provides a format used to store movies, music, or software programs.
• a DVD movie often has multiple audio tracks for multilingual presentation of the movie and/or multiple video tracks for including special features such as interviews with the movie producer, movie trailers, etc.
• a DVD has a memory capacity of approximately six gigabytes (GB).
• GB gigabytes
• a single sided DVD generally can store approximately two to three hours of video.
• a file format for storing digital data with a high compression rate. It would be desirable for the file format to be capable of storing data in multiple streams or tracks. It would also be desirable for the file format to be able to encode and archive video, audio, and text data on easily accessible streams or tracks. It would be of further advantage for the file format to be able to provide copyright protection for the digitized content.
• digitized data e.g., digital video, audio, and/or text data
• a multimedia file following a format that is compatible with a standard data coding and compression algorithm.
• the file is readable and/or executable by a processor, e.g., a specific or generic signal processor, a digital signal processor (DSP), a signal processor on an Application Specific Integrated Circuit (ASIC), an Advanced RISC Machine (ARM) microprocessor, etc.
• a processor e.g., a specific or generic signal processor, a digital signal processor (DSP), a signal processor on an Application Specific Integrated Circuit (ASIC), an Advanced RISC Machine (ARM) microprocessor, etc.
• DSP digital signal processor
• ASIC Application Specific Integrated Circuit
• ARM Advanced RISC Machine
• the file format is based on the audio video interleave (AVI) multimedia format.
• AVI file format is a Resource Interchange File Format (RIFF) file specification used with applications that capture, edit, and play back audio-video sequences.
• RIFF Resource Interchange File Format
• RIFF introduced in 1991 by Microsoft Corporation and IBM Corporation, is a format for storing tagged data structures.
• the structure and coding of RIFF can be found at the Microsoft Developer Network (http://msdn.microsoft.com/). The related information on the Microsoft Developer Network is incorporated herein by reference.
• a RIFF file includes a RIFF header followed by zero or more lists and chunks.
• the RIFF header has the following form:
• a chunk has the form:
• a list is an ordered collection of other chunks, for example a collection of movie frames.
• a list has the form:
• An AVI file is identified by a FOURCC ‘AVI’ in the RIFF header. All AVI files include two mandatory LIST chunks: the stream format and the stream data. An AVI file may also include an index chunk, which gives the location of the data chunks within the file. An AVI file with these components has the form:
• the ‘hdr1’ list defines the format of the data and is the first required LIST chunk.
• the ‘movi’ list contains the data for the AVI sequence and is the second required LIST chunk.
• the ‘idx1’ list contains the index, which is optional. AVI files keep these three components in the proper sequence.
• the character set (CSET) chunk is typically used to define a character set and language information for a RIFF file, a LIST, or a stream.
• the CSET chunk is defined as follows:
• wCodePage specifies the code page used for file elements.
• wCountryCode specifies the country code used for file elements. If the CSET chunk is not present or if this field has value zero, USA (country code 001) is assumed in accordance with an embodiment of the present invention. By way of example, the country codes used in the wCountryCode field of CSET chunk are listed in Table 1.
• wLanguage and wDialect specify the language and dialect used for file elements. If the CSET chunk is not present or if these fields have value zero, US English (language code 9, dialect code 1) is assumed in accordance with an embodiment of the present invention.
• US English language code 9, dialect code 1
• Table 2 the language and dialect codes used in the wLanguage and wDialect fields of CSET chunk are listed in Table 2.
• the information ‘INFO’ list is a registered global form type that can store information, e.g., copyright information and comments, that helps identify the contents of the chunk. This information, although useful, does not affect the way a program interprets the file.
• An ‘INFO’ list is a ‘LIST’ chunk with list type ‘INFO’.
• an ‘INFO’ list may contains the chunks listed in Table 3. Additional chunks may be defined. Preferably, an application ignores any chunk it doesn't understand. Each chunk contains a null-terminated Unicode text string. The character set used in the string is specified by the global CSET chunk.
• the AVI file header (‘hdr1’) list includes a main AVI header in an ‘avih’ chunk.
• One or more stream descriptor lists follow the main AVI header. Each stream descriptor is contained in an ‘str1’ list.
• the main AVI header contains global information for the entire AVI file, such as the number of streams within the file and the width and height of the AVI sequence.
• the main header chunk includes an AVIMAINHEADER structure, whose syntax is defined as:
• the members in the AVIMAINHEADER structure have the following variables:
• the flags in the member dwFlags include the following bitwise combinations:
• IARL Archival Location indicating where the subject of the file is archived.
• IART Artist listing the artist of the original subject of the file.
• ICMS Commissioned listing the name of the person or organization that commissioned the subject of the file.
• ICMT Comments providing general comments about the file or the subject of the file, if multiple sentences in length, each sentence ending with a period, no new line characters.
• ICOP Copyright recording the copyright information for the file, multiple copyrights separated by a semicolon followed by a space.
• ICRD Creation date specifying the date the subject of the file was created, listing dates in year-month-day format, padding one-digit months and days with a zero on the left.
• IDIM Dimensions specifying the size of the original subject of the file, e.g., 8.5 inches in height, 11 inches in width.
• IDPI Dots Per Inch specifying dots per inch setting of the digitizer used to produce the file, such as 300.
• IENG Engineer specifying the name of the engineer who worked on the file. If there are multiple engineers, the names are separated by a semicolon and a blank, e.g., Smith, John; Adams, Joe. IGNR Genre, describing the original work, such as, landscape, portrait, still life, etc.
• IKEY Keywords providing a list of keywords that refer to the file or subject of the file, with multiple keywords separated with a semicolon and a blank, e.g., “Seattle; aerial view; scenery”.
• ILGT Lightness describing the changes in lightness settings on the digitizer required to produce the file, its format depending on hardware used.
• IMED Medium describing the original subject of the file, e.g., computer image, drawing, lithograph.
• INAM Name storing the title of the subject of the file, such as, “Seattle From Above”.
• IPLT Palette Setting specifying the number of colors requested when digitizing an image.
• IPRD Product specifying the name of the product, for which the file was originally intended, e.g., “Encyclopedia of Pacific Northwest Geography”.
• ISBJ Subject describing the contents of the file, e.g., “Aerial view of Seattle”.
• ISFT Software identifying the name of the software package used to create the file, e.g., “Microsoft WaveEdit”.
• ISHP Sharpness identifying the changes in sharpness for the digitizer required to produce the file, its format depending on the hardware used.
• ISRC Source identifying the person or organization that supplied the original subject of the file.
• ISRF Source Form identifying the original form of the material that was digitized, e.g., slide, paper, map, which may be different from IMED. ITCH Technician, identifying the technician who digitized the subject file.
• One or more steam descriptor (‘str1’) lists follow the main header ‘hdr1’.
• Each ‘str1’ list corresponds to a data stream and includes information about the data stream in the file.
• a ‘str1’ list contains a stream header chunk (‘strh’) and a stream format chunk (‘strf’).
• a ‘str1’ list may contain a stream header data chunk (‘strd’) and a stream name chunk (‘strn’).
• the stream descriptors in the ‘hdr1’ list are associated with the stream data in the ‘movi’ list according to the order of the ‘str1’ lists. The first ‘str1’ list applies to stream 0, the second applies to stream 1, and so forth.
• the stream header chunk (‘strh’) in the ‘str1’ list includes an AVISTREAMHEADER structure containing information about a stream in the AVI file.
• the AVISTREAMHEADER structure has the syntax:
• typedef struct_avistreamheader ⁇ FOURCC fcc; DWORD cb; FOURCC fccType; FOURCC fccHandler; DWORD dwFlags; WORD wPriority; WORD wLanguage; DWORD dwInitialFrames; DWORD dwScale; DWORD dwRate; DWORD dwStart; DWORD dwLength; DWORD dwSuggestedBufferSize; DWORD dwQuality; DWORD dwSampleSize; struct ⁇ WORD left; WORD top; WORD right; WORD bottom; ⁇ rcFrame; ⁇ AVISTREAMHEADER
• the members in the AVISTREAMHEADER structure have following variables:
• a stream format (‘strf’) chunk follows the stream header (‘str1’) chunk.
• the stream format chunk describes the format of the data in the stream. The data contained in this chunk depends on the stream type.
• the information is a BITMAPINFOHEADER structure, including palette information if appropriate.
• the structure of BITMAPINFOHEADER is defined as:
• typedef struct BITMAPINFOHEADER ⁇ DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; ⁇ BITMAPINFOHEADER
• the members in the BITMAPINFOHEADER structure have following variables:
• the information is a WAVEFORMATEX structure.
• the information has a TEXTINFO structure:
• typedef_textinfo ⁇ WORD wCodePage; WORD wCountryCode; WORD wLanguageCode; WORD wDialect ⁇ TEXTINFO where the meaning of all the fields (wCodePage, wCountryCode, wLanguageCode, and wDialect) is the same as those defined above with reference to CSET chunk.
• Different languages can be set for each of the text streams in a file having multiple text streams.
• the optional stream header data (‘strd’) chunk is present in an AVI file, it follows the stream format chunk.
• the format and content of the ‘strd’ chunk are defined by the codec driver. Typically, drivers use this information for configuration. Applications that read and write AVI files do not need to interpret this information, they simple transfer it to and from the driver as a memory block.
• the information block for achieving the digital rights management (DRM) protection in the AVI file is presented in the ‘strd’ chunk associated with the main video stream.
• the format of the DRM information data for the video stream in the ‘strd’ should be as following:
• DRMINFO WORD wVersion
• STR sDRMInfo DRMINFO
• the optional stream name ‘strn’ chunk includes a null terminated text string describing the stream.
• the string is “Video [—Description]” for a video stream, where optional [—Description] part is any string that describes the video stream, e.g., it can be “Video—Main”.
• the string can be “Audio [—Description]”, where the optional [—Description] part is any string that describes the audio stream, e.g., it can be “Audio—English”, “Audio—French”, “Audio—Main”, or “Audio—Auxiliary”, etc.
• the string can be “Chapter [—Description]”, where the optional [—Description] part is any string that describes the chapter stream.
• the string can be “Subtitle [—Description]”, where the optional [—Description] part is any string that describes the subtitle stream, e.g., it can be “Subtitle—English”, or “Subtitle—Chinese”.
• AVI stream data ‘movi’ list follows the header information in the AVI RIFF file format.
• the ‘movi’ list contains the actual data in the streams, e.g., the video frames and audio samples.
• the data chunks can reside directly in the ‘movi’ list, or be grouped together as subchunks within ‘rec’ lists.
• the ‘rec’ grouping implies that the grouped subchunks should be read from disk all at once, and is intended for files that are interleaved to play from CD-ROM.
• Each data chunk in the ‘movi’ list is identified by a FOURCC that includes a two-digit stream number followed by a two-character code that defines the type of information in the chunk.
• the two-character codes for defining the data type are:
• Video data chunks can also define new palette entries to update the palette during an AVI sequence.
• Each palette-change chunk (‘xxpc’) contains an AVIPALCHANGE structure. If a stream contains palette changes, the AVISF_VIDEO_PALCHANGES flag in the dwFlags member of the AVISTREAMHEADER structure for that stream is set accordingly.
• the optional index list follows the ‘movi’ list in the AVI RIFF file format.
• the index contains a list of the data chunks and their location in the file. If the AVI file contains an index, the dwFlags member of the AVIMAINHEADER structure is set to AVIF_HASINDEX.
• the index (‘idx1’) list includes an AVIOLDINDEX structure with entries for each data chunk, including ‘rec’ chunks.
• the AVIOLDINDEX structure has the syntax:
• fcc specifies a FOURCC code, with the value ‘idx1’.
• cb specifies the size of the structure, not including the initial 8 bytes.
• DwChunkId specifies a FOURCC that identifies a stream in the AVI file, having the form ‘nnyy’ where nn is the stream number and yy is a two-character code that identifies the contents of the stream: db uncompressed video frame dc compressed video frame pc palette change wb audio data dwFlags specifies a bitwise combination of zero or more of the following flags: AVIIF_LIST 0x00000001L // The data chunk is a ‘rec’ list.
• AVIIF_KEYFRAME 0x00000010L // The data chunk is a key frame.
• AVIIF_NO_TIME 0x00000100L // The data chunk does not affect the timing of the stream, e.g., for palette changes.
• AVIIF_NO_COMPUS 0x0FFF0000L // The data are for compressor use.
• DwOffset specifies the location of the data chunk in the file. In one embodiment, the value is specified as an offset, in bytes, from the start of the ‘movi’ list. In another embodiment, the value is the offset from the start of the file.
• DwSize specifies the size of the data chunk, in bytes.
• the AVIOLDINDEX structure includes the initial RIFF chunk (the fcc and cb members) followed by one index entry for each data chunk in the ‘movi’ list.
• the AVIOLDINDEX structure describes an AVI 1.0 index (‘idx1’ format).
• New AVI files should use an AVI 2.0 index (‘indx’ format).
• Additional data can be aligned in an AVI file by inserting ‘JUNK’ chunks as needed. Applications will ignore the contents of a ‘JUNK’ chunk.
• the video tracks of one or more movies are stored in an AVI file as AVI video streams or tracks.
• a single AVI file may include multiple video tracks.
• the first of the multiple video tracks is the main video track.
• the stream descriptor (‘str1’) list for a video stream should include a stream header (‘strh’) chunk, a stream format (‘strf’), a stream header data (‘strd’) chunk if the stream is DRM protected, and a stream name (‘strn’) chunk.
• the member fccType in the structure AVISTREAMHEADER the stream header (‘strh’) chunk for a video stream has the value ‘vids’.
• the stream header data (‘strd’) chunk of a video stream should exist only for DRM protected video.
• the stream name data (‘strn’) chunk for a video stream includes a string of the form “Video [—Descriptions]”.
• the stream data (‘movi’) list of a video stream in includes an ‘nndb’ chunk for an uncompressed video data chunk or an ‘nndc’ for a compressed video data chunk, where ‘nn’ is a two digit data chunk index. If a video data chunk is DRM protected, the ‘movi’ list also includes a ‘nndd’ chunk preceding the corresponding ‘nndb’ or ‘nndc’ chunk of the protected video data chunk.
• the member dwFlags in the structure AVIOLDINDEX of the index entry for the ‘nndd’ chunk is set to AVIF_NO_TIME.
• each video data chunk includes one video frame in variable bit rate coding.
• a B frame is preferably placed in a chunk with the following P frame.
• an uncoded dummy P frame (N in the following illustration) is preferably inserted by the codec to keep the timing.
• a sequence of image frames (I frames), B frames, and P frames I m B m+1 P m+2 P m+3 P m+4 . . . is preferably arranged into the following video stream chunk sequence:
• the audio tracks of one or more movies are stored in an AVI file as AVI audio streams or tracks.
• a single AVI file may include multiple audio tracks.
• the first of the multiple audio tracks is the main audio track.
• the stream descriptor (‘str1’) list for an audio stream should include a stream header (‘strh’) chunk, a stream format (‘strf’), and a stream name (‘strn’) chunk.
• the ‘str1’ list for an audio stream does not include the stream header data (‘strd’) chunk.
• the application should ignore any data chunk with the ‘strd’ code in the steam descriptor (‘str1’) list of the AVI file.
• the member fccType in the structure AVISTREAMHEADER the stream header (‘strh’) chunk for a video stream has the value ‘auds’.
• the stream name data (‘strn’) chunk for a video stream includes a string of the form “Audio [—Descriptions]”.
• the stream data (‘movi’) list of an audio stream in includes an ‘nnwb’ chunk for identifying an audio data chunk, where ‘nn’ is a two digit data chunk index.
• each audio data chunk includes one audio frame in variable bit rate coding.
• each audio data chunk includes one or more audio frames in constant bit rate coding.
• the chapter tracks are stored in an AVI file as AVI text streams or tracks.
• a single AVI file may include multiple chapter tracks.
• the stream descriptor (‘str1’) list for a chapter stream should include a stream header (‘strh’) chunk, a stream format (‘strf’), and a stream name (‘strn’) chunk.
• the ‘str1’ list for a chapter stream does not include the stream header data (‘strd’) chunk.
• the application should ignore any data chunk with the ‘strd’ code in the steam descriptor (‘str1’) list of the AVI file.
• the member fccType in the structure AVISTREANHEADER the stream header (‘strh’) chunk for a video stream has the value ‘txts’.
• the stream format (‘strf’) chunk for a chapter stream has the TEXTINFO structure.
• the stream name data (‘strn’) chunk for a video stream includes a string of the form “Chapter [—Descriptions]”.
• the stream data (‘movi’) list of a chapter stream in includes an ‘nnch’ chunk for identifying a chapter data chunk, where ‘nn’ is a two digit data chunk index.
• each chapter data chunk has a CHAPTERCHUNK structure:
• typedef struct_chapterchunk ⁇ FOURCC fcc; DWORD cb; STR time; STR description ⁇ CHAPTERCHUNK
• the chapter stream is not a regular interval stream.
• the member dwFlags in the structure AVIOLDINDEX of the index entry for the ‘nnch’ chunk is set to AVIF_NO_TIME.
• the subtitle tracks are stored in an AVI file as AVI text streams or tracks.
• the subtitle tracks are stored in an AVI file as AVI bitmap streams or tracks.
• a single AVI file may include multiple subtitle tracks.
• the stream descriptor (‘str1’) list for a subtitle stream should include a stream header (‘strh’) chunk, a stream format (‘strf’), and a stream name (‘strn’) chunk.
• the ‘str1’ list for a subtitle stream does not include the stream header data (‘strd’) chunk.
• the application should ignore any data chunk with the ‘strd’ code in the steam descriptor (‘str1’) list of the AVI file.
• the member fccType in the structure AVISTREAMHEADER the stream header (‘strh’) chunk for a video stream has the value ‘txts’ for text form subtitles or ‘vids’ for bitmap form subtitles.
• the stream format (‘strf’) chunk for a subtitle stream has the TEXTINFO structure for text form subtitles and the BITMAPINFOHEADER structure for bitmap form subtitles.
• the stream name data (‘strn’) chunk for a video stream includes a string of the form “Subtitle [—Descriptions]”.
• the stream data (‘movi’) list of a subtitle stream includes an ‘nnst’ chunk for identifying a text form subtitle data chunk and/or an ‘nnsb’ chunk for identifying a bitmap form subtitle data chunk, where ‘nn’ is a two digit data chunk index.
• each subtitle data chunk has a SUBTITLECHUNK structure:
• the subtitle stream is not a regular interval stream.
• the member dwFlags in the structure AVIOLDINDEX of the index entry for the subtitle chunk is set to AVIF_NO_TIME.
• a compressed subtitle bitmap will have the following fields:
• the “width” and “height” fields specify the dimension of the subtitle bitmap.
• the members “left”, “top”, “right”, and “bottom” fields specify the display rectangle of the subtitle bitmap relative to the main video rectangle.
• the BITMAP includes compressed bitmap data.
• the subtitle bitmaps are four-level bitmaps with the following definition.
• Compression of the subtitle bitmap uses a simple run-length coding according the rules in Table 4.
• the size of the run-length coded data within one line is 1440 bits or less.
• the streams in AVI files are interleaved.
• Audio stream chunks are interleaved ahead of corresponding video stream chunks in time.
• the amount of the audio stream that is interleaved ahead of corresponding points in the video stream should not exceed an predetermined upper limit, e.g., 2 seconds, 5 seconds, 10 seconds, 15 seconds, etc.
• the subtitle chunks are interleaved in the file ahead of the corresponding video chunk in time, with the amount of subtitle interleaved ahead of corresponding points in the video stream not exceeding a upper limit, e.g., 5 seconds, 10 seconds, 15 seconds, 20 seconds, etc.
• the interleaving of the chapter stream is not restricted. It could be all written in the beginning of the “movi” list, or interleaved with the other streams.
• the 4 bits are considered to be one unit. 4 to 15 pixels with Specify ‘0’ in the first 2 bits, and enter the the same value number of pixels in the following 4 bits and follows. the pixel data in the next 2 bits.
• the 8 bits are considered to be one unit. 16 to 63 pixels with Specify ‘0’ in the first 4 bits, and enter the the same value number of pixels in the following 6 bits and follows. the pixel data in the next 2 bits.
• the 12 bits are considered to be one unit.
• the 16 bits are considered to be one unit.
• the same pixels Specify ‘0’ in the first 14 bits, and describe follow to the end of the pixel data in the following 2 bits.
• the 16 a line. bits are considered to be one unit.
• the byte alignment is Insert dummy data of 4 bits ‘0000b’ not accomplished when for adjustment. the description for pixels on one line is completed.
• An AVI file typically does not contain a time stamp of the streams.
• Each stream has its frame rate specified in the stream descriptor (‘str1’) list in the AVI header.
• each chunk contains one and only one frame. Accessing the data of the variable bit rate stream at any given point is feasible with the known frame rate and the data chunk index.
• For constant bit rate streams e.g., constant bit rate audio streams, each chunk may contain one or more frames. Because each frame has a known fixed size, locating data at any given point can be achieved by calculating the size of the stream data. Therefore, seeking an arbitrary location in an AVI file in accordance with the present invention can be achieved for either constant bit rate or variable bit rate streams by parsing and recording the index table for each frame.
• the version of the video codec used in AVI files is signaled by the FourCC code in the fccHandler field or member of the AVISTREAMHEADER of the corresponding stream header ‘strh’ chunks, and the FourCC code bicompression field or member in the BITMAPINFOHEADER of the corresponding ‘strf’ chunks.
• the FourCC codes fccHandler in the stream header (‘strh’) of the AVISTREAMHEADER is set to “divx” or “DIVX”.
• the FourCC (DWORD) code biCompression in the BITMAPINFOHEADER of the corresponding ‘strf’ chunks is set to signify the detailed codec version.
• ‘div3’ or ‘div4’ is used in AVISTREAMHEADER, and ‘div3’ or ‘div4’ is used in BITMAPINFOHEADER;
• ‘divx’ is used in AVISTREAMHEADER, and ‘divx’ is used in BITMAPINFOHEADER;
• ‘divx’ is used in AVISTREAMHEADER, and ‘dx50’ is used in BITMAPINFOHEADER.
• a file format in accordance with the present invention is compatible with high level data compressing algorithms, such as MPEG-4. Its data compression ratio is about six to ten times higher than a standard DVD format.
• the file format is capable of storing data in multiple streams or tracks.
• the file format is also able to encode and archive video, audio, and text data on easily accessible streams or tracks.
• the file format is able to provide protection of the copyright of the digitized content.

Abstract

Description

Claims (96)

Priority Applications (1)

Applications Claiming Priority (2)

Related Parent Applications (1)

Publications (1)

Family

ID=34634434

Family Applications (12)

Family Applications Before (2)

Family Applications After (9)

Country Status (9)

Cited By (22)

Families Citing this family (144)

Citations (125)

Family Cites Families (527)