[FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
tempn at mi.rr.com
Thu Sep 3 07:05:03 CEST 2015
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.
has the rockbox fixed point decoders, if someone wants to port them
back to ffmpeg libavcodec git master that would be awesome...
More information about the ffmpeg-devel