[FFmpeg-devel] [PATCH] AAC fatetests

[Michael Niedermayer]

On Sat, Jul 10, 2010 at 10:44:45PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 10, 2010 at 09:39:29PM +0100, M?ns Rullg?rd wrote:
> > Michael Niedermayer <michaelni at gmx.at> writes:
> > 
> > > On Sat, Jul 10, 2010 at 11:49:41AM +0200, Reimar D?ffinger wrote:
> > >> On Sat, Jul 10, 2010 at 10:24:26AM +0100, M?ns Rullg?rd wrote:
> [...]
> > >> This would also allow testing of non-seekable input without needing
> > >> http or piping from stdin...
> > >
> > > one cant seek in bz2 ?
> > > did gnu butcher the _block_ based bw transform that much?
> > 
> > There is likely no way to find the block boundaries other than by
> > decoding the entire thing.
> 
> if so that would be a very lame design, because the basic algorithm doesnt
> use the previous blocks being able to recover in case of damage would
> have been a nice feature

tfm says:
RECOVERING DATA FROM DAMAGED FILES
       bzip2 compresses files in blocks, usually 900kbytes long.   Each  block
       is  handled  independently.   If a media or transmission error causes a
       multi-block .bz2 file to become damaged, it may be possible to  recover
       data from the undamaged blocks in the file.

       The  compressed  representation  of each block is delimited by a 48-bit
       pattern, which makes it possible to find the block boundaries with rea-
       sonable certainty.  Each block also carries its own 32-bit CRC, so dam-
       aged blocks can be distinguished from undamaged ones.

       bzip2recover is a simple program whose purpose is to search for  blocks
       in  .bz2  files,  and write each block out into its own .bz2 file.  You
       can then use bzip2 -t to test the integrity of the resulting files, and
       decompress those which are undamaged.

so my assumtation that one should be able to seek in bz2 is not all that wrong

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100710/e7f85142/attachment.pgp>