[FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump

[compn]

On Wed, 2 Sep 2015 14:06:43 -0700
Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:

> On Wed, Sep 2, 2015 at 1:57 PM, wm4 <nfxjfg at googlemail.com> wrote:
> > On Wed, 2 Sep 2015 16:49:41 -0400
> > "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde
> >> <gajjanag at mit.edu> wrote:
> >>
> >> > On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer
> >> > <michaelni at gmx.at> wrote:
> >> > > From: Michael Niedermayer <michael at niedermayer.cc>
> >> > >
> >> > > a 32bit bitrate is insufficient for high resolution, high
> >> > > framerate
> >> > material
> >> > > an example would be rawvideo
> >> > >
> >> > > Not all changes are covered by #if as its easier to just push
> >> > > when the bump is done instead of making it coditional and
> >> > > removig the
> >> > conditionallity
> >> > >  again
> >> >
> >> > Not for this patch; but just a thought - I noticed in swresample
> >> > the use of int for sample rate. Note that all the C spec
> >> > guarantees is int
> >> > >= 16 bits, and 2^15 < 33000 which is insufficient for a lot of
> >> > >audio.
> >> > Your comment above seems to reflect the assumption that int >= 32
> >> > bits. Maybe this assumption is made elsewhere in the codebase as
> >> > well, but it is not safe as per the standard. Thus, I feel
> >> > swresample rate should be an int32_t; and there may be more
> >> > opportunities for cleanup elsewhere.
> >>
> >>
> >> FFmpeg assumes int >= 32bit. We don't support platforms where this
> >> assumption doesn't hold.
> >
> > While this is true, it would actually be an advantage if some of
> > ints all over the codebase changed to size_t. For example, FFmpeg
> > can't process images over 16000x16000 in size, which is just
> > ridiculous, because there are many real-world cases which need
> > resolutions this high (consider scans etc.).
> 
> Thanks all for clarifications. I assume environments where int=16 bit
> are quite rare. However, as a long term goal, could there be some
> potential users (e.g embedded guys) who would benefit from relaxing
> the int>=32 bit assumption?

talk to rockbox (or other embedded libavcodec user) devs and ask them
if 16bit precision would help.

there were some embedded device patches for libavcodec that added
int-only codecs. but no one ever looked at them.

http://git.rockbox.org/?p=rockbox.git;a=tree;f=lib/rbcodec/codecs

has the rockbox fixed point decoders, if someone wants to port them
back to ffmpeg libavcodec git master that would be awesome...

-compn