On Wed, 2 Sep 2015 14:06:43 -0700 Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Wed, Sep 2, 2015 at 1:57 PM, wm4 <nfx...@googlemail.com> wrote: > > 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.). > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
