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

Ganesh Ajjanagadde gajjanag at mit.edu
Wed Sep 2 23:06:43 CEST 2015


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?

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list