[Mplayer-users] bugs?

[Arpi]

Hi,

> Doesn't sound too bad. However, I still have a problem with the file: It 
> plays for 3 or 4 minutes (after -idx skipping there is possible), then stops 
> with message  "file doesn't contain the selected audio or video stream" 
> 
> I know the file is broken, but: Is this repairable?
yes, everything is repairable. even a broken HDD driver with ntfs partition
containing very important data -> but should be done manually -> lots' of
money :)

if you send me teh file & money, i'll hack it with hex editor and get it
work :)

ok. stop joking:)
i don't know any program or method for automatically fix broken avi files.
avi is the worst file format i've ever seen. it has zero error tolerance.

for example, asf and mpeg-ts files are from constant-length blocks, so
if a block is broken, you can skip it and read next (you know where is it).
for mpeg, there are sync codes (0x0 0x0 0x1), so it's easy to resync.
same for mpeg audio, but sync code is something like f3ffxxxx, i duno now,
but you can check in mp3lib/sr1.c resync method.

for avi, you have nothing.
it has variable sized chunks, each chunks contains its length.
if a chunk is broken, you don't know where is the next and you don't know
is it broken or not...)

i can imagine a brute-force method (but should be impemenetd in a standalone
util prog, not in mplayer):
if teh parser thinks that chunk is broken (too large chunksize, or invalid
chunk id), it can recursive call itself (parser), and try to find next
chunk probing each byte position after the buggy chunk. if it's ok, try to
check next chunk if still ok, then we can skip broken chunk.
it isn't 100% perfect, and can fail for good chunks and pass broken chunks,
but may help in most cases (or not, didn't try).

i personally hate the avi file format, and really hope thay people will
change to something more usefull (mpeg/asf/quicktime).

and i forget to saym but you already noticed: A-V sync in avi files is
terrible.. there is only one standard way (in avi file format specification)
but nobody uses it (i have only oen file using this, it's about 5 years old,
using CRAM codec...). it specifies that audio-video chunk pairs should be
defined in a LIST item.

currently there are 3 formats, none of them is standard.
1. interleaved streams: same as standard, but they left out LIST chunks,
   only list A and V and A and V etc after eachother.
2. bps method: audio and video streams are totally independent (usually
   -ni streams), but audio timestamp can be calculated by dividing audio
   byte position by a 'average bytes per second' value specified in audio
   stream format header. it can't handle VBR audio.
3. combination of 1. and 2. i just got such file, it's Lola Rennt german
   dvdrip version (thanx Atmos :)).
   it plays with mplayer using method 1., but you can't seek (lost A-V
   sync if seeking). i'ev found that avifile handle this file, because it
   uses combination of 1. and 2. methods (at least fersh avifile 9.6 cvs).
   i'll implement this and try, mayeb help for some special streams.
   btw there are some streams (about 5% of all) which works with mpalyer's
   method 1., but fails with avifile's mixed method 3.
   windows media player uses something between 1. and 3., couldn't find
   yet how it works. old avifile and mplayer -bps uses method 2.

i really don't know, what are standards made for?
but i'm sure, m$ doesn't know too.

sorry for being offtopic, this should go to mplayer-dev-eng.

> "Epsilon < 0" - chl 
is it standard? =)


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu

_______________________________________________
Mplayer-users mailing list
Mplayer-users at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-users