[FFmpeg-devel] [PATCH 4/4] lavf/mp3dec: read encoder delay/padding from Info tag

[Jon Toohill]

A similar concern was raised in a previous related patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194690.html
I think the resolution at the time was to go ahead with using both, since
both are used widely and serve slightly different purposes, although I do
agree that it's confusing.

I think I could use AV_PKT_DATA_SKIP_SAMPLES here, and change mp3enc to use
that to fill out the Info tag. But that only seems worthwhile to me if
there is a general consensus to move to just AV_PKT_DATA_SKIP_SAMPLES (and
deprecate/remove initial_padding and trailing_padding). If there's a
concrete case where knowing trailing_padding at the start of a stream is
necessary, then that's not possible, but I'm pretty new to this and don't
know of one. Thoughts?


Jon Toohill |  Google Play Music |  jtoohill at google.com |  (650) 215-0770

On Mon, Sep 26, 2016 at 11:30 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 26 Sep 2016 10:13:39 -0700
> Jon Toohill <jtoohill-at-google.com at ffmpeg.org> wrote:
>
> > ---
> >  libavformat/mp3dec.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 56c7f8c..9cc85a3 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -239,6 +239,8 @@ static void mp3_parse_info_tag(AVFormatContext *s,
> AVStream *st,
> >
> >          mp3->start_pad = v>>12;
> >          mp3->  end_pad = v&4095;
> > +        st->codecpar->initial_padding = mp3->start_pad + 528 + 1;
> > +        st->codecpar->trailing_padding = mp3->end_pad;
> >          st->start_skip_samples = mp3->start_pad + 528 + 1;
> >          if (mp3->frames) {
> >              st->first_discard_sample = -mp3->end_pad + 528 + 1 +
> mp3->frames * (int64_t)spf;
>
> I'm somewhat suspicious about this, because mp3dec.c uses
> AV_PKT_DATA_SKIP_SAMPLES to communicate delay/padding
> (libavformat/utils.c turns the start_skip_samples field into side
> data). So I'm not quite convinced is this mess of FFmpeg and Libav API
> mixture is healthy. Opinions welcome.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>