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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel