[Home]Aviindex

Showing revision 3
Difference (from revision 3 to revision 3) (minor diff, author diff)
(The revisions are identical or unavailable.)
NAME
       aviindex	 - Write and read text files describing the index
       of an AVI file

SYNOPSIS

       aviindex [ -o ofile -i ifile -n -v -h ]

COPYRIGHT

       aviindex is Copyright (C) 2003,2004 by Tilmann Bitterberg

DESCRIPTION

       aviindex writes a text file describing the index of an AVI
       file. It analyses the content or index if available of the
       AVI file and prints this information in a  human	 readable
       form.

       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
Password required to edit | View other revisions | View current revision
Edited December 12, 2004 2:56 am by gateway (diff)
Search: