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

wm4 nfxjfg at googlemail.com
Wed Sep 2 23:29:40 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?

Just no. Show me a meaningful embedded 16 bit platform that can make
meaningful use of libavcodec. Even _if_ a 16 bit embedded thing would
play media, it'd use its own dedicated circuity instead of doing it on
a general purpose CPU.

Another angle: as long as you can't show me an architecture that would
actually benefit from such a relaxation _and_ be worth all the effort
for it, nobody is going to be interested. (And in fact, should not
waste his time on such theoretical things.)


More information about the ffmpeg-devel mailing list