5

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
Improve this question
2
  • 5
    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
    – Gyan
    Mar 25, 2017 at 5:24
  • I'd imagine there might be hardware limitations on playing back those files, whatever the software.
    – stib
    Mar 27, 2017 at 1:13

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 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.
    – Gyan
    Mar 25, 2017 at 16:25
  • 3
    Actually, the statement you quoted isn't present in the current code. The one I quoted is, and was added there in Dec 2016.
    – Gyan
    Mar 25, 2017 at 16:32
  • @Mulvya - 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).
    – Rob
    Mar 25, 2017 at 17:30
  • I would surprised if this was a 64bit limit because I'm using a 64bit version of ffmpeg, specifically ffmpeg-20170321-db7a05d-win64-static
    – Mikhail
    Mar 27, 2017 at 9:50
  • 3
    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).
    – Michael Tiemann
    Sep 2, 2019 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.