[FFmpeg-devel] [PATCH] FLAC parser

[Michael Niedermayer]

On Sat, Mar 28, 2009 at 06:41:02PM -0400, Justin Ruggles wrote:
> 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.

You can do better without decoding twice
first find all valid headers (sync + header crc + a few bits in the header)
that would give you something like:
H          H      H                      H       H                    H

then calculate the frame crc between each 2 headers
H          H      H                      H       H                    H
--CRC!=0-->
---------CRC==0-->
          -CRC!=0->
          ----------------------CRC==0-->
                  --------------CRC!=0-->
                  ----------------------CRC!=0-->
                                         -CRC==0->
                                         ------------CRC==0---------->
                                                  ------CRC==0------->

Then find the longest connected chain of valid CRCs, if there is another
non overlapping chain of valid crcs before it pick it instead.
Return the first frame from the chain.

also you should favor chains which dont change samplerate or other such
things.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20090329/b622308b/attachment.pgp>