Answers.Body: <p>FFmpeg is tripping up at this statement in <code>Imgutils.c</code> in function <code>av_image_check_size()</code></p>
  
  <pre><code>if ((int)w&gt;0 &amp;&amp; (int)h&gt;0 &amp;&amp; (w+128)*(uint64_t)(h+128) &lt; INT_MAX/8) return;  [ else error() ]
  </code></pre>
  
  <p>where <code>INT_MAX</code> is defined in <code>limits.h</code> as at least <code>32767</code> (<code>2^15-1</code>), or greater depending upon your compiler.</p>
  
  <p>Compiling with a 64-bit compiler will permit larger images.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-25T16:25:54.933Z
Answers.Text: It's tripping up at `(int)w<=0 || (int)h<=0 || stride >= INT_MAX || stride*(uint64_t)(h+128) >= INT_MAX`  And INT_MAX is fixed to 2^31-1. Which compiler limits.h are you referring to? Mine is GCC 6.3.0.  I've 64-bit ffmpeg compiled using a 64-bit toolchain and I also get the same error for the OP's size.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-25T16:32:09.720Z
Answers.Text: Actually, the statement you quoted isn't present in the current code. The one I quoted is, and was added there in Dec 2016.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-25T17:30:24.180Z
Answers.Text: @Mulvya - https://en.m.wikibooks.org/wiki/C_Programming/C_Reference/limits.h - The Standard says a larger value is permitted. That INT_MAX is a minimum value under the Standard (No compliant C Compiler can have a lower value. Further Googling shows that some OS's size is 64 Bit.  I'll accept the newer Source. Plug in his values. Would half the size fit? If he's going to use Python I don't imagine it will accept arbitrarily large values either but it might take 64 Bit values. The size he wants to playback at implies he has an 8K Screen (or is Archiving for the future).
Answers.UserDisplayName: Rob
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-27T09:50:48.323Z
Answers.Text: I would surprised if this was a 64bit limit because I'm using a 64bit version of ffmpeg, specifically `ffmpeg-20170321-db7a05d-win64-static`
Answers.UserDisplayName: Mikhail
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-02T12:36:31.477Z
Answers.Text: Just a comment: why the heck does FFMPEG use (signed) ints for H and W?  If they were unsigned int, then all would be fine and dandy up to 65535 (inclusive).
Answers.UserDisplayName: Michael Tiemann
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2017-03-25T15:42:22.313Z
Answers.LastActivityDate: 2018-12-16T17:03:00.260Z
Answers.LastEditDate: 2018-12-16T17:03:00.260Z
Answers.UserDisplayName: Rob
Body: <p>I got a bunch of really large 16 bit videos, approaching 65535×65535 pixels in size. These are essentially high quality timelapse panoramas. I want to convert them to a 7680×4320 movie (8K UHD, 8 bit). I'm not too concerned about the format, but I want some kind of compression. </p>
  
  <p>I think I can resize the images using Python to get them down to HEVC (8192×4320)...</p>
  
  <p>Is there anything that will playback (with VLC?) that can do a larger number of pixels than 8192×4320? What are my options? </p>
  
  <p>When I try to use FFmpeg I get errors like:</p>
  
  <pre><code>[mjpeg @ 000000000062eae0] [IMGUTILS @ 000000000023ed40] Picture size 20000x19824 is invalidN/A
  Error while decoding stream #0:0: Invalid data found when processing input
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-25T05:24:27.630Z
Comments.Text: Any player based on ffmpeg/libav will likely fail if ffmpeg does. You'll have to downsize the video and then convert. Since your input is MJPEG, you can try to losslessly extract the frames as an image sequence. Downsize with another app (imagemagick?) and then encode that result. `ffmpeg -i in.mov -c copy frames%d.jpg`
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-27T01:13:09.010Z
Comments.Text: I'd imagine there might be hardware limitations on playing back those files, whatever the software.
Comments.UserDisplayName: stib
Tags: <ffmpeg><encoding><software-recommendation><compression>
Title: Largest input image size when encoding a video?
UserDisplayName: Mikhail
ThreadText: # Largest input image size when encoding a video?
  
  (Asked by: username_0 on 2017-03-24)
  
  I got a bunch of really large 16 bit videos, approaching 65535×65535 pixels in size. These are essentially high quality timelapse panoramas. I want to convert them to a 7680×4320 movie (8K UHD, 8 bit). I'm not too concerned about the format, but I want some kind of compression.
  
  I think I can resize the images using Python to get them down to HEVC (8192×4320)...
  
  Is there anything that will playback (with VLC?) that can do a larger number of pixels than 8192×4320? What are my options?
  
  When I try to use FFmpeg I get errors like:
  
  ```
  [mjpeg @ 000000000062eae0] [IMGUTILS @ 000000000023ed40] Picture size 20000x19824 is invalidN/A
  Error while decoding stream #0:0: Invalid data found when processing input
  
  ```
  
  **Tags:** ffmpeg, encoding, software-recommendation, compression
  
  > **Comments:**
  > **username_1**: Any player based on ffmpeg/libav will likely fail if ffmpeg does. You'll have to downsize the video and then convert. Since your input is MJPEG, you can try to losslessly extract the frames as an image sequence. Downsize with another app (imagemagick?) and then encode that result. `ffmpeg -i in.mov -c copy frames%d.jpg`  
  > **username_2**: I'd imagine there might be hardware limitations on playing back those files, whatever the software.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2017-03-25. Score: 0
  
  FFmpeg is tripping up at this statement in `Imgutils.c` in function `av_image_check_size()`
  
  ```
  if ((int)w>0 && (int)h>0 && (w+128)*(uint64_t)(h+128) < INT_MAX/8) return;  [ else error() ]
  
  ```
  
  where `INT_MAX` is defined in `limits.h` as at least `32767` (`2^15-1`), or greater depending upon your compiler.
  
  Compiling with a 64-bit compiler will permit larger images.
  
  > **Comments:**
  > **username_1**: It's tripping up at `(int)w<=0 || (int)h<=0 || stride >= INT_MAX || stride*(uint64_t)(h+128) >= INT_MAX`  And INT_MAX is fixed to 2^31-1. Which compiler limits.h are you referring to? Mine is GCC 6.3.0.  I've 64-bit ffmpeg compiled using a 64-bit toolchain and I also get the same error for the OP's size.  
  > **username_1**: Actually, the statement you quoted isn't present in the current code. The one I quoted is, and was added there in Dec 2016.  
  > **username_3**: @Mulvya - https://en.m.wikibooks.org/wiki/C_Programming/C_Reference/limits.h - The Standard says a larger value is permitted. That INT_MAX is a minimum value under the Standard (No compliant C Compiler can have a lower value. Further Googling shows that some OS's size is 64 Bit.  I'll accept the newer Source. Plug in his values. Would half the size fit? If he's going to use Python I don't imagine it will accept arbitrarily large values either but it might take 64 Bit values. The size he wants to playback at implies he has an 8K Screen (or is Archiving for the future).  
  > **username_0**: I would surprised if this was a 64bit limit because I'm using a 64bit version of ffmpeg, specifically `ffmpeg-20170321-db7a05d-win64-static`  
  > **username_4**: Just a comment: why the heck does FFMPEG use (signed) ints for H and W?  If they were unsigned int, then all would be fine and dandy up to 65535 (inclusive).  
  
  ---
  
  