[FFmpeg-devel] [PATCH] FLAC parser

[Justin Ruggles]

Michael Niedermayer wrote:
> On Fri, Mar 27, 2009 at 01:05:47AM -0400, Justin Ruggles wrote:
>> Hi,
>>
>> I finally got a working FLAC parser without resorting to buffering
>> max_frame_size bytes like the FLAC decoder does.  It requires a slight
>> change to ff_combine_frame() since the header can be up to 16 bytes long
>> and ff_combine_frame() currently only supports up to 8 bytes of overread
>> data (FF_INPUT_BUFFER_PADDING_SIZE).
>>
>> This works with all samples I've tested, but it would be great to have
>> more tested as well.  There are quite a few corner cases, and while I've
>> tried to think of everything I can, I might have missed something.
> 
> If i understand this correctly,
> this is a probabilistic parser, that is it will fail once in 4tb of
> random data at least, but due to the max crc stuff sooner.
> and as data is not random it could fail more frequently

Yes. The only alternatives I can see would be decoding twice (although
inverse prediction, and interleaving could be skipped in the parser) or
not having a parser, which prevents stream copy to most other containers.

I came up with a different probability of false positive frame detection
for random data, but I might be calculating incorrectly...  For
simplicity, given the smallest size frame header, there are 180 valid
combinations in 48 bits, which is about 1 in 1.56e12.  Then if you take
into account the CRC-16 of the previous frame, that makes it around 1 in
1.02e17.  But given that the sync code is mostly a string of 1's, the
probability is likely higher than that with non-random data.

-Justin