[FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding

[Ivan Kalvachev]

On 7/2/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google.com at ffmpeg.org> wrote:
>
>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
>> >> vigneshv-at-google.com at ffmpeg.org> wrote:
>> >>
>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer <jamrial at gmail.com>
>> wrote:
>> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
>> >>> jzern-at-google.com at ffmpeg.org>
>> >>> >> wrote:
>> >>> >>
>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
>> cehoyos at ag.or.at>
>> >>> >>> wrote:
>> >>> >>>>> Do we have decoder support (for either vp8 or vp9) for these
>> files?
>> >>> >>>>
>> >>> >>>> No, only encoding and muxing.
>> >>> >>>
>> >>> >>> Seems like a feature request, but no reason to block this one if
>> the
>> >>> >>> vp8 one is here.
>> >>> >>
>> >>> >>
>> >>> >> I'm not sure I have an opinion on this... But it feels strange to
>> allow
>> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we
>> recommend
>> >>> >> people handle the files created with this feature, if not by using
>> >>> ffmpeg
>> >>> >> itself?
>> >>>
>> >>> One plausible reason is that Chrome can decode this. So it will be
>> >>> useful for people who already have ffmpeg in their pipelines and want
>> >>> to create such files. And like James Almer mentioned, this isn't a
>> >>> first. VP8 Alpha has been this way too.
>> >>
>> >>
>> >> The fact that something is the way it is, does not prove that it is
>> >> therefore right, or that we should therefore continue doing it that way
>> in
>> >> other cases.
>> >>
>> >> So you're suggesting that it is perfectly fine for people to use Chrome
>> as
>> >> decoder if FFmpeg is the encoder. What if people don't have Chrome
>> >> installed? Or what if they want a way of UI-less batch-processing such
>> >> files, e.g. what if a service like Youtube/Vimeo wants to allow upload
>> of
>> >> vp8a/vp9a files without invoking Chrome for decoding?
>> >>
>> >
>> > Additional evidence in [1], [2].
>> >
>> > There absolutely seems to be interest in support for vp8a/vp9a decoding
>> > outside Chrome. I'm not saying you should implement it in all multimedia
>> > frameworks ever created in human history, but doing it in one of them
>> (e.g.
>> > ffmpeg, since it already supports encoding) certainly sounds helpful?
>> >
>>
>> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg.
>> I'm just saying that it shouldn't be a reason to block this patch. :)
>> Sorry if i wasn't clear before.
>
>
> I totally understand that you would think that, since it means you don't
> have to do anything :).
>
> But there's an issue with this thinking. We're essentially already the
> dumping ground for anything multimedia-related nowadays. After all, we
> maintain it and keep it working (assuming basic tests), things couldn't get
> much easier than that, right? But is it actually useful to anyone? I mean
> not just useful for you, but useful to a wider set of people, at least in
> theory.
>
> If there's no decoder, I would claim that the wider utility of this thing
> is essentially zero. And that's somewhat of a concern.
>
> So, how do we get a decoder? vp8a suggests that just waiting for one to
> spontaneously combust out of thin air just doesn't work. So I'm suggesting
> you provide us with one. It's ok if it uses libvpx instead of ffvp8/9.
> Since vp8a encoding is already in, I won't ask for a vp8a decoder either.
> I'm just asking for a vp9a decoder. It might even be OK if it's implemented
> on top of ffmpeg instead of inside libavcodec (I'm not sure how others feel
> about this), i.e. just something that invokes libavformat to parse a webm
> file, create two decoders to get the yuv and a planes, and then merge them
> together into a yuva420p picture. I'm just asking for something _small_ and
> _simple_ (i.e. not "Chrome") that we can point users to when they ask "how
> do I decode vp9a files".
>
> I asked on IRC (#ffmpeg-devel) and several people concurred:
>
> <BBB> jamrial: so … I’m looking for a second opinion here, like, an
> independent one… am I being too hard on these guys for saying “an encoder
> needs a decoder”?
> <JEEB> BBB: I do tend to agree that in general it goes dec->enc, or both at
> the same time. be it a fully lavc decoder or just utilizing a decoder
> library
> <jamrial> BBB: no, you're not being hard
>
> So it seems I'm not entirely alone in this opinion within the ffmpeg
> developer community.
>
> Ronald


Roland, aren't you one of the main developers of ffvp9?
I remember you have spent a lot of time making it faster.
You know that codec well, don't you?

Thus my question is:
Why are you wasting your time
blocking things that people want,
instead of implementing the alpha plane support yourself?

That's how you improve FFmpeg and move the project forward.
By making stuff work.
Not by blocking and obstructing others.