[FFmpeg-devel] [PATCH] AAC fatetests
Måns Rullgård
mans
Sat Jul 10 22:53:23 CEST 2010
Michael Niedermayer <michaelni at gmx.at> writes:
> 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
Yes, it seems that it should be possible, albeit with some overhead
scanning for startcodes and with only 900k granularity.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list