[FFmpeg-devel] [RFC] av_get_bits_per_sample() questions
michaelni at gmx.at
Sun Jun 5 23:46:26 CEST 2011
On Sun, Jun 05, 2011 at 11:00:12PM +0200, Stefano Sabatini wrote:
> On date Sunday 2011-06-05 22:28:22 +0200, Stefano Sabatini encoded:
> > On date Sunday 2011-03-13 17:27:24 -0400, Justin Ruggles wrote:
> > > On 03/13/2011 05:24 PM, Alex Converse wrote:
> > >
> > > > On Sun, Mar 13, 2011 at 2:20 PM, Justin Ruggles
> > > > <justin.ruggles at gmail.com> wrote:
> > > >> On 03/13/2011 04:59 PM, Stefano Sabatini wrote:
> > [...]
> > > >>> The second one, av_get_bits_per_sample_fmt(), is misnamed (should be
> > > >>> av_get_bits_per_sample()), so we may change the name to
> > > >>> av_get_bits_per_sample2() for avoiding the conflict with the name
> > > >>> already taken.
> > > >>
> > > >>
> > > >> I agree. But as long as we're reworking it, why not
> > > >> av_get_bytes_per_sample() so it doesn't have to be divided by 8 everywhere?
> > > >>
> > > >
> > > > Don't some ADPCM codecs have less than 8 bits per sample.
> > First variant attached, if we have no reasons to in the future we
> > won't add some sample format with a non integer number of bytes then
> > I'll post the av_get_bytes_per_sample() variant.
> In case the sense of the text above was not clear, I meant: do you
> have some reason to suppose that we may add a sample format with a non
> integer number of bytes?
> If this is not the case, I suppose it is safe to just use
i think its safer to stay with bits
switching to a more limited representation because "we cant nail down
a case now ATM that needs it" seems not an ideal choice
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel