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

[Jimmy Christensen]

On 2009-07-02 08:24, Reimar D?ffinger wrote:
> 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.

I will probably move away from using the table at all, so if it's read 
as 32-bit or 64-bit should not matter that much anymore. Personally I 
would rather do it according to the documentation.