Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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 Carl Eugen Hoyos, 5 years ago

Analyzed by developer: unset
Component: avfilterundetermined
Keywords: minterpolate removed
Reproduced by developer: unset
Resolution: duplicate
Status: newclosed
Type: sponsoring requestdefect
Version: git-masterunspecified

Duplicate of ticket #7140.

comment:2 by Ivan, 5 years ago

Component: undeterminedavfilter
Resolution: duplicate
Status: closedreopened
Type: defectsponsoring request
Version: unspecifiedgit-master

Better wording used to describe the issue. Please let it go

comment:3 by Carl Eugen Hoyos, 5 years ago

Component: avfilterundetermined
Resolution: duplicate
Status: reopenedclosed
Type: sponsoring requestdefect
Version: git-masterunspecified

comment:4 by Gyan, 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.

in reply to:  4 ; comment:5 by Carl Eugen Hoyos, 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).

in reply to:  5 comment:6 by Gyan, 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?

Note: See TracTickets for help on using tickets.