On Thu, Nov 07, 2019 at 10:37:05PM +0100, Hendrik Leppkes wrote:
> On Thu, Nov 7, 2019 at 10:34 PM Michael Niedermayer
> <mich...@niedermayer.cc> wrote:
> >
> > From: Limin Wang <lance.lmw...@gmail.com>
> >
> > Fixes misdetection of zYLx.wav
> >
> > Co-Author: Michael Niedermayer <mich...@niedermayer.cc>
> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > ---
> > libavformat/mp3dec.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 6848415657..eb40362548 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
> > int frames, ret;
> > int framesizes, max_framesizes;
> > uint32_t header;
> > - const uint8_t *buf, *buf0, *buf2, *end;
> > + const uint8_t *buf, *buf0, *buf2, *buf3, *end;
> >
> > buf0 = p->buf;
> > end = p->buf + p->buf_size - sizeof(uint32_t);
> > @@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
> > buf2 = buf;
> > for(framesizes = frames = 0; buf2 < end; frames++) {
> > MPADecodeHeader h;
> > + int header_emu = 0;
> >
> > header = AV_RB32(buf2);
> > ret = avpriv_mpegaudio_decode_header(&h, header);
> > if (ret != 0 || end - buf2 < h.frame_size)
> > break;
> > +
> > + for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
> > + uint32_t next_sync = AV_RB32(buf3);
> > + header_emu += (next_sync & MP3_MASK) == (header &
> > MP3_MASK);
> > + }
> > + if (header_emu > 2)
> > + break;
> > buf2 += h.frame_size;
> > framesizes += h.frame_size;
> > }
>
> I still have the same question - how possible is it that the actual
> audio data actually has these same bits? Is it actually impossible? Or
> are we just trading detection flaws here?
By the iso 11172-3 and 13818-3 specs, every mp3 audio frame has a header, below
is the header bitstream
syntax:
header()
{
syncword 12bits bslsf
id 1bit bslsf
layer 2bit bslsf
protection_bit 1bit bslsf
bitrate_index 4bits bslsf
sampling_frequency 2bits bslsf
padding_bit 1bit bslsf
private_bit 1bit bslsf
mode 2bits bslsf
mode_extension 2bits bslsf
copyright 1bit bslsf
original/home 1bit bslsf
emphasis 2bits bslsf
}
so if the header is masking with MP3_MASK(0xFFFE0CCF), it'll zero out these
field:
protection_bit set to 0
bitrate_index set to 0
sampling_freqency set to 0
mode set to 0
So the header should be keep same pattern if the audio frame is encode with
same id and layer. If not, it's
error or something else.
>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
