[FFmpeg-devel] [PATCH] avfilter: add panorama filter

[Paul B Mahol]

On 3/9/18, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 9 Mar 2018 11:05:53 +0100
> Paul B Mahol <onemda at gmail.com> wrote:
>
>> On 3/9/18, Paul B Mahol <onemda at gmail.com> wrote:
>> > On 3/9/18, wm4 <nfxjfg at googlemail.com> wrote:
>> >> On Fri, 9 Mar 2018 09:15:13 +0100
>> >> Paul B Mahol <onemda at gmail.com> wrote:
>> >>
>> >>> On 3/9/18, wm4 <nfxjfg at googlemail.com> wrote:
>> >>> > On Thu, 8 Mar 2018 21:53:48 -0300
>> >>> > James Almer <jamrial at gmail.com> wrote:
>> >>> >
>> >>> >> On 3/8/2018 9:50 PM, Hazem Ashmawy wrote:
>> >>> >> > [PATCH] avfilter: add panorama filter
>> >>> >> >
>> >>> >> > Sorry about that! I removed them now.
>> >>> >> > For the future, any recommendation for a tool for linting /
>> >>> >> > checking
>> >>> >> > formating
>> >>> >> > rules?
>> >>> >>
>> >>> >> There's tools/patcheck. Feed it a git format-patch style of patch
>> >>> >> to
>> >>> >> find common issues, but keep in mind it can generate a lot of false
>> >>> >> positives.
>> >>> >>
>> >>> >> I don't know if we have documentation about actual formatting rules
>> >>> >> anywhere.
>> >>> >
>> >>> > Also:
>> >>> >
>> >>> > <_jamrial> shouldn't that panorama filter sent to the ml use the
>> >>> > spherical
>> >>> > frame side data?
>> >>> >
>> >>> > I think so.
>> >>>
>> >>> Are there actual files that have such data?
>> >>
>> >> Is that a trick question? I only know the non-standard, Google specific
>> >> metadata in mkv and mp4 that lavf can read (was any of this
>> >> standardized yet?).
>> >>
>> >> But that doesn't change that we can tag AVFrames with this info, and
>> >> for files which don't have the metadata, it makes sense to me to set it
>> >> with a new vf_format argument or some sort of vf_setinfo (if we don't
>> >> have anything like this yet).
>> >>
>> >> The part that is annoying is that vf_panorama still seems to require
>> >> setting an output projection, which would make the whole thing more
>> >> annoying instead of less, but even then I'd argue it should default to
>> >> taking the AVFrame configuration (AV_FRAME_DATA_SPHERICAL) as input by
>> >> default, even if the filter arguments can override it.
>> >
>> > That frame side data is very specific and thus considered barely useful
>> > here.
>> >
>> > Is it at all updated to the latest improvements, like new equi-angular
>> > cubemap projection?
>> >
>>
>> I guess not at all, I get this:
>>
>> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x21c1740] Unknown projection type
>
> Well, then add support for it, duh. I don't see how this is an argument
> for not using the video's projection by default. The existing
> infrastructure may be incomplete, but it's very much extensible.

No, its very experimental and fragile.