[FFmpeg-devel] AC3 Format Detection unreliable.
Justin Ruggles
justinruggles
Sun Aug 5 05:32:21 CEST 2007
Michael Niedermayer wrote:
> Hi
>
> On Sat, Aug 04, 2007 at 08:33:03PM -0400, Justin Ruggles wrote:
>> Justin Ruggles wrote:
>>> Dan Sully wrote:
>>>> * Dan Sully shaped the electrons to say...
>>>>
>>>>>> Yes, please make the stream(s) available.
>>>> Also, I am on an amd64 system.
>>> Doesn't look like that's an issue. I'm getting the same thing on my
>>> system. The file is valid. The issue seems to be the frame size.
>>> 640kbps 48kHz is the largest AC3 frame size, and I think it's not
>>> fitting enough frames into the probe buffer to give a positive
>>> detection. I'll look into it.
>> The problem with this sample is two-fold. The first issue is that the
>> probe buffer in this case is only 2048 bytes. The frame size for this
>> sample (and any others which are 640kbps & 48kHz) is 2560. Therefore,
>> only 1 frame is detected. I changed the threshold for a score of 50
>> down to 2 frames, but this doesn't help here. After I changed to 1
>> frame (at the start of the stream) it now gets a score of 50, but then a
>> 2nd issue occurs.
>
> so you havent fixed the issue but you sucessfully broke the whole probe
> system in lavf, great
>
> the ff_ac3_parse_header function checks only something like 18bits
> a single match at the start IS NOT enough for a score of 50%
> mpeg-ps checks for somthing like 60bits and does misdetect it so
> how many misdetections do you think you added by decreasing the
> bits for ac3 to 18 at the start or 36 at a random pos?
>
> also keep in mind that if no detection happens in 2048 bytes lavf will
> increase the buffer size until a reasonable detection is achived!
>
> so to summarize do NOT "fix" bugs if you do NOT FULLY understand why
> it doesnt work and how the code works, this comment is not intended
> to you but rather to alot of people here
> when i think of pts/dts issues old ogg-vorbis, flv, swf, ... patches
> which where applied these all added fantastically broken, huge, stupid and
> unneeded code to workaround bugs in some other part of the code
You're right, I apologize. I should have tested it more with other
formats before relaxing the detection criteria. I'll change it back and
try to find another way.
2048 bytes is enough for the 1st 5/8 of any AC3 frame, so the 1st CRC
code could be used to detect a single frame with pretty close to 100%
certainty. Then you have the issue of AC3 inside a container. But
would it be okay to give a 50% score if the frame is at the start of the
probe buffer and is a CRC match?
-Justin
More information about the ffmpeg-devel
mailing list