On Mon, 11 Apr 2016 13:26:54 +0200 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 1:17 PM, wm4 <nfx...@googlemail.com> wrote: > > On Mon, 11 Apr 2016 12:52:51 +0200 > > Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > > >> On Mon, Apr 11, 2016 at 11:29 AM, wm4 <nfx...@googlemail.com> wrote: > >> > On Mon, 11 Apr 2016 03:12:20 +0200 > >> > Michael Niedermayer <mich...@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 > >> >> > <mich...@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 <mich...@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. It's only a problem if they collide, but maybe it's really better to have them separate to avoid a potential mess. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel