[FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing

[Limin Wang]

On Thu, Nov 07, 2019 at 10:37:05PM +0100, Hendrik Leppkes wrote:
> On Thu, Nov 7, 2019 at 10:34 PM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> >
> > From: Limin Wang <lance.lmwang at gmail.com>
> >
> > Fixes misdetection of zYLx.wav
> >
> > Co-Author: Michael Niedermayer <michael at niedermayer.cc>
> > Signed-off-by: Michael Niedermayer <michael at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".