[FFmpeg-devel] [PATCH] avcodec: Add bits_per_raw_sample to AVCodecParameters

[Hendrik Leppkes]

On Mon, Apr 11, 2016 at 1:17 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Mon, 11 Apr 2016 12:52:51 +0200
> Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
>> On Mon, Apr 11, 2016 at 11:29 AM, wm4 <nfxjfg at googlemail.com> wrote:
>> > On Mon, 11 Apr 2016 03:12:20 +0200
>> > Michael Niedermayer <michael at niedermayer.cc> wrote:
>> >
>> >> On Sun, Apr 10, 2016 at 11:39:57PM +0000, Kieran Kunhya wrote:
>> >> > On Mon, 11 Apr 2016 at 00:33 Michael Niedermayer <michael at niedermayer.cc>
>> >> > wrote:
>> >> >
>> >> > > The bits_per_raw_sample represents the number of bits of precission per
>> >> > > sample.
>> >> > >
>> >> > > The field is added at the logical place, not at the end as the code was
>> >> > > just
>> >> > > recently added
>> >> > >
>> >> > > This fixes the regression about loosing the audio sample precission
>> >> > > information
>> >> > >
>> >> > > The change in the fate test checksum un-does the change from the merge
>> >> > >
>> >> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>> >> > > ---
>> >> > >  libavcodec/avcodec.h |   17 +++++++++++++++++
>> >> > >  libavcodec/utils.c   |    2 ++
>> >> > >  tests/ref/lavf/ffm   |    2 +-
>> >> > >  3 files changed, 20 insertions(+), 1 deletion(-)
>> >> > >
>> >> > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> >> > > index b3655c5..87739d7 100644
>> >> > > --- a/libavcodec/avcodec.h
>> >> > > +++ b/libavcodec/avcodec.h
>> >> > > @@ -3832,9 +3832,26 @@ typedef struct AVCodecParameters {
>> >> > >       */
>> >> > >      int64_t bit_rate;
>> >> > >
>> >> > > +    /**
>> >> > > +     * The number of bits per sample in the codedwords.
>> >> > > +     *
>> >> > > +     * This is basically the bitrate per sample
>> >> > > +     *
>> >> > > +     * This could be for example 4 for ADPCM
>> >> > > +     * For PCM formats this matches bits_per_raw_sample
>> >> > > +     * Can be 0
>> >> > > +     */
>> >> > >      int bits_per_coded_sample;
>> >> > >
>> >> > >      /**
>> >> > > +     * The number of bits of precission in the samples.
>> >> > > +     *
>> >> > > +     * For ADPCM this might be 12 or 16 or similar
>> >> > > +     * Can be 0
>> >> > > +     */
>> >> > > +    int bits_per_raw_sample;
>> >> > >
>> >> > >
>> >> > Precision spelt wrong. Also needs more clarification as to the difference
>> >> > between the two
>> >>
>> >> on one side of a bitstream format there is raw pcm data (raw samples)
>> >> and on the other a compressed bitstream (aka coded samples)
>> >> these 2 where intended to specify the number of bits per sample in
>> >> these 2 representations
>> >>
>> >> i really dont know how to word this so that its clear and everyone
>> >> understands it
>> >>
>> >>
>> >> > - I have no idea what the difference is or why one would
>> >> > use bits_per_coded_sample for anything.
>> >>
>> >> bits_per_coded_sample is used by several codecs (huffyuv, ima adpcm,
>> >> ...) in avi as a single byte extradata. so it must be transported from
>> >> the demuxer (avi headers) to the decoder and encoder to muxer
>> >> to make this worse, in some of these codecs it matches the
>> >> bits_per_raw_sample, in some it does not
>> >
>> > I still don't understand. bits_per_coded_sample is part of the
>> > AVCodecParameters struct. So what's the difference between per_coded
>> > and per_raw?
>> >
>>
>> As I understand it, coded is mandatory for a bunch of formats to
>> actually decode it, ie. the number of bits for one sample in the
>> actual coded bitstream.
>> And raw is just the bits in a decoded (raw) sample. Sometimes those
>> two can be the same, especially if the codec in question doesnt have a
>> concept of coded bits per sample.
>
> Then I don't understand why the field can't be reused.
>
> One thing that would have to be done though is copying the field to the
> AVCodecContext.bits_per_raw_sample field in decoder init or so.

How can it be reused if you practically have two values? One for
coded, and one for raw? One is mandatory for decoding, and one is good
to know so you can interpret S32 sample format properly.

 - Hendrik