[FFmpeg-devel] [PATCH] OpenEXR decoder rev-3

[Reimar Döffinger]

On Thu, Jul 02, 2009 at 07:54:32AM +0200, Jimmy Christensen wrote:
> On 2009-07-01 23:24, Reimar D?ffinger wrote:
> > On Wed, Jul 01, 2009 at 11:00:14PM +0200, Jimmy Christensen wrote:
> >> It's stated in the documentation for the fileformat :
> >>
> >> The line offset table allows random access to scan line blocks. The
> >> table is a sequence of scan line offsets, with one offset per scan line
> >> block. A scan line offset, of type unsigned long, indicates the
> >> distance, in bytes, between the start of the file and the start of the
> >> scan line block. In the table, scan line offsets are ordered according
> >> to increasing scan line y coordinates.
> >>
> >> I would suspect that the idea perhaps is that on 64-bit systems it can
> >> use the full range, but not on 32-bit systems.
> >
> > unsigned long is also 32 bit on 64 bit Windows systems.
> > Either the documentation does not use the C meaning of that (what else?),
> > the part you quoted lacks context, or the documentation is just braindead.
> > Since you're probably not going to work with asm code, just remember the
> > simple rule: if you are using "long" you are doing something wrong.
> 
> The documentation is here :
> http://www.openexr.com/openexrfilelayout.pdf
> 
> After re-reading it, I found that it does say what it means exactly with 
> "unsigned long", so will change it specifically to that. Didn't know 
> there were such a difference in Windows (not surprised either).

Note that FFmpeg via avcodec_check_dimensions limits the size of a frame
to 256 MPixels, which in case of the float format would be just 1GB.
Thus caring about more than the lowest 32 bit seems pointless for
FFmpeg, particular since such large frames can't be processed with
FFmpeg on 32 bit systems at all, I doubt there is much of a point
in supporting things that can only work on 64 bit systems at all.