[FFmpeg-devel] [PATCH][RFC] avutil/spherical: add a flag to signal tiled/padded projections

[Vittorio Giovara]

On Wed, Mar 29, 2017 at 8:01 PM, James Almer <jamrial at gmail.com> wrote:
> A new field is added to AVSphericalMapping for this purpose,
> and is used by both Equirectangular and Cubemap projections.
> This is a replacement for duplicate projection enums like
> AV_SPHERICAL_EQUIRECTANGULAR_TILE, which are therefore
> removed.
>
> Signed-off-by: James Almer <jamrial at gmail.com>
> ---
> This patch depends on the av_spherical_projection_name() patchset for
> simplicity purposes.
>
> Ok, this is an RFC mainly because of the API/ABI break it represents.
> The AV_SPHERICAL_EQUIRECTANGULAR_TILE projection is a month and a half
> old and not present in any release, plus a major bump is queued as part
> of the merges, so i personally think this change is acceptable as is for
> such an niche and recent feature.
> If not then i can deprecate said projection enum value instead and keep
> the current muxer functionality for it for a while. It will need a lot
> of preprocessor guards, though.
>
> The reason for this change is that eventually, a new projection enum
> for padded cubemap may be suggested with the same arguments as the ones
> used to introduce the one for tiled equirectangular. Then if any new
> real projections are added, we'd could end up with duplicate enums for
> them as well, when setting a single shared flag would be enough.
> Stereo3D avoided a lot of duplicate types with the inverted flag, so i
> figured the same should be done here.
>
> Improved doxy and/or flag name is extremely welcome (Read: needed).

I'm against this idea because of explanations given in other threads.

The stereo3d case is different because it's a property that can be
applied to all types, while the cropped/padded feature applies to
current existing projections, not the future ones. Additionally there
is nothing wrong with having more enum values, since it is likely that
future cubemaps layouts will have a different enum value, and not
another field to check.

Regardless of the outcome of the discussion, please keep the API
aligned for users' sake.
-- 
Vittorio