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

[Vignesh Venkatasubramanian]

On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
<vigneshv at google.com> wrote:
> On Fri, Jul 1, 2016 at 3:03 PM, 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.
>>
>
> Alright, i have a working patch for the decoder locally (i will push
> that to the ML shortly).

Here it is: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196403.html

> In the meantime, let's please unblock this.
> It worked this time as it wasn't too complex, but i'm not sure if
> conditioning patches like this is always a good idea. :)
>
>> Ronald
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>
> --
> Vignesh



-- 
Vignesh