[Home]History of Aviindex


Revision 5 . . December 13, 2004 1:01 am by gateway
Revision 4 . . December 13, 2004 12:13 am by 64.125.108.5.available.above.net
Revision 3 . . December 12, 2004 2:56 am by gateway
Revision 2 . . December 11, 2004 11:57 pm by 64.125.108.5.available.above.net
Revision 1 . . October 24, 2004 7:01 am by gateway
  

Difference (from prior major revision) (no other diffs)

Changed: 17c17,176
An AVI file can have an optional chunk called
An AVI file can have an optional chunk called "idx1" which
contains information about keyframes (syncpoints) and
locations of video frames resp. audio chunks. Movie play-
ers use this index to seek in files.

aviindex reads the AVI file ifile and writes the index
into ofile. This can either happen in "dumb" mode where
aviindex looks for an existing index (and trusts this
index!) in the file and dumps this index into a human
readable form. The "dumb" mode is used, when -n is NOT
specified or when the filesize of the input file is
smaller than 2 GB.

In "smart" mode, aviindex scans through the complete AVI
file and searches for chunks (may that video or audio) and
reconstructs the index based on the information found. If
an index chunk is found accidently, aviindex will use the
information in this index to recover the keyframe informa-
tion, which is important. aviindex will use smart mode, if
given the -n option OR if the AVI file is larger than 2
GB. If the file is large, the index chunk cannot be found
the usual way so one must use -n but it is possible that
there is an index chunk in this file. Cross fingers.

Also in smart mode, aviindex analyzes the content of the
video frame and tries to detect keyframes by looking at
the data depending on the video codec.

The generated index file serves different purposes.

* The library which handles AVI files in
transcode(1) can read such index files and
use this file to rebuild the index instead
of scanning through the whole AVI file over
and over again. Reading the index from the
index file is much faster than scanning
through the AVI.

* It can be used as a seeking file. When given
to transcode via the --nav_seek switch,
transcode will use the file to seek directly
to the position you specified via -c. This
also works for multiple -c ranges.

* Its nice to have for debugging.

OPTIONS
-o ofile
Specify the name of the output file.

-i ifile
Specify the name of the input file.

-n force generating the index.

-v show version.

-h show help text.

MPLAYER
aviindex can convert from and to mplayer-generated index
files. Since mplayer-1.0pre3 mplayer has the ability to
save the index via -saveidx FILE and load it again through
-loadidx FILE. aviindex is able to convert an mplayer
index file to a transcode index file and vice visa. It is
not able to directly write an mplayer file, though. Exam-
ple of a toolchain
mplayer -frames 0 -saveidx mpidx broken.avi
aviindex -i mpidx -o tcindex
avimerge -x tcindex -i broken.avi -o fixed.avi
Or the other way round
aviindex -i broken.avi -n -o broken.idx
aviindex -i broken.idx -o mpidx
mplayer -loadidx mpidx broken.avi
The major differences between the two index file formats
is that the mplayer one is a binary format which is an
exact copy of an index in the AVI file. aviindex 's for-
mat is text based. See FORMAT for details.

EXAMPLES
The command

aviindex -i 3GBfile.avi -o 3GB.index

generates and index of the large file 3GBfile.avi. You can
use the file 3GB.index to tell transcode to read the index
from this file and not from the avi. This leads to much
faster startup time.

Suppose 3GBfile.avi has DivX video and PCM sound and you
want to encode several ranges.

transcode -V -i 3GBfile.avi --nav_seek 3GB.index \
-x xvid,avi \
-c 5000-6000,0:20:00-0:21:00,100000-100001 \
-y xvid --lame_preset standard -o out.avi

FORMAT
The format of the index file. The first 7 bytes in this
file are "AVIIDX1" for easy detection and a comment of who
created the file. The second line is a comment and
describes the fields. Do not delete it. Each line (except
the first 2) consists of exactly 8 fields all seperated by
one space and describing one particular chunk of the AVI
file.
Here is an example of an AVI file with two audio tracks.

AVIIDX1 # Generated by aviindex (transcode-0.6.8)
TAG TYPE CHUNK CHUNK/TYPE POS LEN KEY MS
00db 1 0 0 2048 8335 1 0.00
01wb 2 1 0 10392 847 1 0.00
01wb 2 2 1 11248 847 1 0.00
02wb 3 3 0 12104 847 1 0.00
02wb 3 4 1 12960 847 1 0.00
00db 1 5 1 13816 5263 0 0.00
00db 1 6 2 19088 3435 0 0.00
01wb 2 7 2 22532 834 1 0.00

The field TAG is the chunk descriptor. Its "00d*" for the
video, "01wb" for the first audio track, "02wb" for the
second audio track and so on.

The field TYPE is the type of the chunk. This is redundant
because the type is also embedded into the TAG field but
its a convenient thing to have. Its 1 for video, 2 for
first audio track and 3 for second audio track.

The field CHUNK is the absolute chunk number in the AVI
file. If you read the CHUNK field in the last line of the
index file, you know how many chunks this AVI file has.

The field CHUNK/TYPE holds information about how many
chunks of this type were previously found in the AVI file.

The field POS is the absolute byte position in the AVI
file where this chunk can be found. Note this field can
hold really large numbers if you are dealing with large
AVIs.

The field LEN is the length of this chunk.

The field KEY holds information if this chunk is a
keyframe. In the example above, all audio chunks are key-
chunks, but only the first video frame is a key frame.
This field is either 0 or 1.

The field MS holds information about how many milliseconds
have passed. This field may be 0.00 if unknown.

AUTHORS
aviindex was written by Tilmann Bitterberg <transcode at
tibit.org>
and is part of transcode.

SEE ALSO
avifix(1), avisync(1), avimerge(1), avisplit(1), tccat(1),
tcdecode(1), tcdemux(1), tcextract(1), tcprobe(1),
tcscan(1), transcode(1), mplayer(1)



Transcode Wiki | Recent Changes | Preferences
Search: