Page MenuHome

AVI Warnings and File Size Check
Closed, ArchivedPublicPATCH

Description

This patch contains two different fixes. One is to change local variables from int to int64_t so that they do not cause warnings when used with ftell. There are also some casts from int64_t to int when it is known to be safe.

The second part of this patch is a function 'calculate_final_offset' that determines what the new size of an AVI file will be after a frame is written. This is used by AVI_write_frame to check if its safe to write a frame. I chose to write a separate function because I think it would be easier than cleaning up in the middle of writing a set of streams. However this may have to be done anyway in the future (see end of this description).

In the AVI_write_frame I also did some common sub-expression elimination for index values that were used multiple times.

Also, I gratuitously moved an ftell(... SEEK_END) to make another later call redundant. Added some comments for future maintainers.

I'm not sure how to test this patch, so it has not been tested.

In addition, I noticed that AVI_write_frame never checks to make sure that awrite succeeded, which means even if it does not write a file >2GB it might fail to detect other situations like permission or out-of-disk-space errors. This means that this function may need to be re-factored significantly to handle IO problems and in that case it may be better to just check for overflow along with the other errors and use the same cleanup code. In that case further rewriting of AVI_write_frame is needed and that part of this patch can be ignored.



Event Timeline

There was a bug report within the past year regarding file sizes that exceeded 4 gigs on Windows(Citation needed). It was causing problems with AVI writing larger than 4 gig files. I believe it was Brecht that fixed it. He might have more information.

Interesting because the problem I'm trying to protect against here is the possibility of a offset being more than 2^31 (2GB), since it is a signed value. I want to do that before blindly casting an int64_t to an int. It may be that this problem is solved upstream and the cast would be safe.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Mar 25 2015, 5:13 PM
Sergey Sharybin (sergey) claimed this task.

It' usually a really good idea to test patches before submitting them for the review. Also, i would think it's makes more sense to reduce number of backends and use ffmpeg for movie i/o.