#8114 closed defect (duplicate)
Make minterpolate process higher resolution videos
Reported by: | Ivan | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
We are re-encoding virtual reality videos and these are of higher resolution than 4096x4095 maximum supported by FFMPEG. Our current resolution is 6200x6200px and could potentially hit up to 10K in the future.
Is it possible to remove resolution limits completely from minterpolate filter?
Issue replication:
% ./ffmpeg [input] -vf minterpolate [output]
ffmpeg version N-45194-g40102a213-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
...
Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv), 6400x6400, 53472 kb/s, 30 fps, 30 tbr, 90k tbn, 29.97 tbc (default)
...
[Parsed_minterpolate_0 @ 0x74d3640] Failed to configure input pad on Parsed_minterpolate_0d=N/A
Error reinitializing filters!
Failed to inject frame into filter network: Cannot allocate memory
Error while processing the decoded data for stream #0:1
Conversion failed!
Change History (6)
comment:1 by , 5 years ago
Analyzed by developer: | unset |
---|---|
Component: | avfilter → undetermined |
Keywords: | minterpolate removed |
Reproduced by developer: | unset |
Resolution: | → duplicate |
Status: | new → closed |
Type: | sponsoring request → defect |
Version: | git-master → unspecified |
comment:2 by , 5 years ago
Component: | undetermined → avfilter |
---|---|
Resolution: | duplicate |
Status: | closed → reopened |
Type: | defect → sponsoring request |
Version: | unspecified → git-master |
Better wording used to describe the issue. Please let it go
comment:3 by , 5 years ago
Component: | avfilter → undetermined |
---|---|
Resolution: | → duplicate |
Status: | reopened → closed |
Type: | sponsoring request → defect |
Version: | git-master → unspecified |
follow-up: 5 comment:4 by , 5 years ago
The ffmpeg memory allocation functions will not allocate more than INT_MAX bytes (231-1).
Two of the data structures in minterpolate hit that limit at around 4096x4095. It is unlikely that the limit will be raised. So, the other possible way is to refactor those data structures into separate arrays, say, one per N rows, and allocate each separately. And then adapt the filter to work with this new arrangement.
One possible workaround with the current filter is to divide each frame into partitions. Crop to each partition, with some padding added as per the search radius. Perform minterpolate, crop to remove padding. And then stack the results together. This could get very slow, so do it one partition per command, save to lossless or HQ codec and then stitch those.
follow-up: 6 comment:5 by , 5 years ago
Replying to Gyan:
The ffmpeg memory allocation functions will not allocate more than INT_MAX bytes (231-1).
Two of the data structures in minterpolate hit that limit at around 4096x4095. It is unlikely that the limit will be raised.
I thought it would make sense to raise the limit under some conditions ...
So, the other possible way is to refactor those data structures into separate arrays, say, one per N rows, and allocate each separately. And then adapt the filter to work with this new arrangement.
One possible workaround with the current filter is to divide each frame into partitions. Crop to each partition, with some padding added as per the search radius. Perform minterpolate, crop to remove padding. And then stack the results together. This could get very slow, so do it one partition per command, save to lossless or HQ codec and then stitch those.
... especially since afaict, all this would not help on 32bit systems (where above limit cannot be raised significantly).
comment:6 by , 5 years ago
Replying to cehoyos:
... especially since afaict, all this would not help on 32bit systems (where above limit cannot be raised significantly).
Why can't the workaround be made to work on 32-bit systems?
Duplicate of ticket #7140.