I am working on a project involving video files with very large frames (5760x2176). I needed to compress the raw avi file for transmission over the internet to its intended audience, and I turned to HandBrakeCLI and x265 to handle the job. I did this because the h.264 standard does not actually support frame sizes that large, but h.265 does.
When I went to encode my video I got errors about "ffmpeg_read: pkt too big".
Digging into the HandBrake source I discovered in \libhb\stream.c line 5723 code that checks for absurd sizes from ffmpeg and declines to enlarge the buffer if they occur. The check performed is
Code: Select all
// sometimes we get absurd sizes from ffmpeg
if ( stream->ffmpeg_pkt->size >= (1 << 25) )
This is fine for video that fits the constraints of the h.264 standard, but not for h.265's extreme limits. A single packet of my source file exceeds 2^25 bytes and is not in error. To encode my project I increased the limit to 2^28 bytes and recompiled from source, which allowed my encode to proceed as expected.
Code: Select all
// sometimes we get absurd sizes from ffmpeg, but we still need to work with the very large resolutions supported by x265
if ( stream->ffmpeg_pkt->size >= (1 << 28) )
I am suggesting that the size of this absurdity check needs to be re-evaluated in light of the new frame size options exposed by the x265 encoder. 2^28 worked for my project, but my test case is a far cry from h.265's theoretical max of 8192×4320