On Wed, 2 Sep 2015 16:49:41 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > > > On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer <michae...@gmx.at> > > wrote: > > > From: Michael Niedermayer <mich...@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.). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
