[FFmpeg-devel] [PATCH] libavformat/mov.c: Add parsing for DDTS atom for DTS audio

Shawn Singh shawnsingh at google.com
Wed Sep 30 17:02:43 CEST 2015


On Wed, Sep 30, 2015 at 5:53 AM, Michael Niedermayer <michaelni at gmx.at>
wrote:

> On Wed, Sep 30, 2015 at 02:17:02PM +0900, Yusuke Nakamura wrote:
> > 2015-09-30 6:44 GMT+09:00 Shawn Singh <shawnsingh at google.com>:
> >
> > > The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E.
> > > This is useful for DTS-HD formats, some of which cannot be
> > > decoded by dcadec.c or libdcadec.
> > >
> >
> > How useful?
> > DTS audio has scalability, and 'ddts' box indicates only one of
> properties
> > of the stream.
> >
> >
> > >
> > > Signed-off-by: Shawn Singh <shawnsingh at google.com>
> > > ---
> > >  libavformat/mov.c | 56
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 56 insertions(+)
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index c57aaeb..da170a6 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -744,6 +744,61 @@ static int mov_read_dec3(MOVContext *c,
> AVIOContext
> > > *pb, MOVAtom atom)
> > >      return 0;
> > >  }
> > >
> > > +static int mov_read_ddts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > > +{
> > > +    const uint32_t ddts_size = 20;
> > > +    AVStream *st = NULL;
> > > +    uint8_t *buf = NULL;
> > > +    uint32_t frame_duration_code = 0;
> > > +    uint32_t channel_layout_code = 0;
> > > +    GetBitContext gb;
> > > +
> > > +    buf = av_malloc(ddts_size + FF_INPUT_BUFFER_PADDING_SIZE);
> > > +    if (!buf) {
> > > +        return AVERROR(ENOMEM);
> > > +    }
> > > +    if (avio_read(pb, buf, ddts_size) < ddts_size) {
> > > +        av_free(buf);
> > > +        return AVERROR_INVALIDDATA;
> > > +    }
> > > +
> > > +    init_get_bits(&gb, buf, 8*ddts_size);
> > > +
> > > +    if (c->fc->nb_streams < 1) {
> > > +        return 0;
> > > +    }
> > > +    st = c->fc->streams[c->fc->nb_streams-1];
> > > +
> > > +    st->codec->sample_rate = get_bits_long(&gb, 32);
> > > +    skip_bits_long(&gb, 32); /* max bitrate */
> > > +    st->codec->bit_rate = get_bits_long(&gb, 32);
> > > +    st->codec->bits_per_coded_sample = get_bits(&gb, 8);
> > >
> >
> > This field is set to 0 as a reserved field if the file is compatible with
> > Ultra Violet's Common File Format (CFF).
> > I prefer that the reference about this is here.
> >
> >
> > > +    frame_duration_code = get_bits(&gb, 2);
> > > +    skip_bits(&gb, 30); /* various fields */
> > > +    channel_layout_code = get_bits(&gb, 16);
> > > +
> > > +    st->codec->frame_size =
> > > +            (frame_duration_code == 0) ? 512 :
> > > +            (frame_duration_code == 1) ? 1024 :
> > > +            (frame_duration_code == 2) ? 2048 :
> > > +            (frame_duration_code == 3) ? 4096 : 0;
> > >
> >
> > Wrong if LBRDurationMod is set to 1.
>
> if you think its better to revert this patch, just say so and ill
> revert
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Michael and Yusuke, thanks for the feedback.

If you do revert, that's no problem.  Otherwise, I can submit a
fix for the LBRDurationMod and for the CFF reserved field as Yusuke
suggested.

Also, unfortunately we do not have any samples that can be shared.
I will try to remux one of the existing fate tests, but we have
limited remuxing capability so it probably will not work.

Yusuke has a good point that the DDTS atom can reflect only one
configuration (e.g. core-substream only, or core + extension). The dcadec
or libdcadec decoders will override any AVStream fields that are set
here.  Our use case was to facilitate probing DTS-HD files with
avformat_find_stream_info without requiring to decode.  Doing so also
required disabling CODEC_CAP_CHANNEL_CONF capability in the decoder,
but obviously that is not appropriate to contribute back to ffmpeg. We
thought the atom parsing would be nice to contribute.

Best Regards,
~Shawn


More information about the ffmpeg-devel mailing list