[FFmpeg-devel] [PATCH] FLAC parser
Justin Ruggles
justin.ruggles
Wed Jul 21 03:11:02 CEST 2010
Justin Ruggles wrote:
> Hi,
>
> Michael Chinen wrote:
>
>> Hi,
>>
>> This FLAC parser takes the suggestions from a thread from another FLAC
>> parser patch submitted by Jason Ruggles in March 2009[1].
>> Currently it stores 20 headers (8 bit crc verified) and finds all
>> possible (16 bit footer) crc-verified sequences within a neighbor
>> distance of 4.
>> It penalizes sequences that have changes in sample rate, bit depth,
>> and channel arrangement.
>> The settings probably need some twiddling.
>>
>> Seeking seems to work with it (with my av_build_index version in soc
>> svn as well).
>>
>> I used the modifications to flacdec.c (to remove the bytestream and
>> make a function extern) from Jason's patch, but flac_parser.c is new.
>>
>> The second patch is just to make ffplay keep calling av_read_frame
>> after the ByteIOContext has reach EOF.
>>
>> Michael
>>
>> [1] http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/066533.html
>
>> From 6134833f75c83beb306936b62e789c62a85ac2a2 Mon Sep 17 00:00:00 2001
>> From: Michael Chinen <mchinen at gmail.com>
>> Date: Wed, 14 Jul 2010 02:58:53 +0200
>> Subject: [PATCH 1/4] Add FLAC parser
>> Based on mailing list discussion from march 09.
>> flac_parser.c verifies all possible chains within a certain header radius and scores them based on changes in sample rate, bit depth, channels.
>> flacdec.c uses Jason Ruggles' changes from a patch in the same discussion.
>
> My name is Justin Ruggles. :)
>
>> ---
>> libavcodec/Makefile | 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/flac.h | 12 ++
>> libavcodec/flac_parser.c | 362 ++++++++++++++++++++++++++++++++++++++++++++++
>> libavcodec/flacdec.c | 110 +++-----------
>> 5 files changed, 398 insertions(+), 88 deletions(-)
>> create mode 100644 libavcodec/flac_parser.c
>
>
> Some general comments:
>
> 1) I haven't gone too far into why this happens, but it doesn't seem to
> work reliably. Using 20 headers there should be no reason why any
> frames are not detected properly, but in 2 random single-song samples I
> tested I got instances of multiple frames being joined together (i.e.
> skipping a valid header). The decoder can handle this, but it should
> not be occuring.
I think the issue is that search_start in find_new_headers() is
calculated incorrectly.
I changed:
fpc->buffer_size - (buf_size + (MAX_FRAME_HEADER_SIZE-1) )
to
fpc->buffer_size - (buf_size + (MAX_FRAME_HEADER_SIZE+1) )
After that I got no skipped headers and everything worked as expected
for all samples I tested.
-Justin
More information about the ffmpeg-devel
mailing list