Discussion:
[FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Vignesh Venkatasubramanian
2016-06-30 23:16:31 UTC
Permalink
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.

[1] https://codereview.chromium.org/2096813002/

Signed-off-by: Vignesh Venkatasubramanian <***@google.com>
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)

diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
index 55edc7e..1eca97a 100644
--- a/libavcodec/libvpx.c
+++ b/libavcodec/libvpx.c
@@ -29,12 +29,14 @@

static const enum AVPixelFormat vp9_pix_fmts_def[] = {
AV_PIX_FMT_YUV420P,
+ AV_PIX_FMT_YUVA420P,
AV_PIX_FMT_NONE
};

#if CONFIG_LIBVPX_VP9_ENCODER
static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {
AV_PIX_FMT_YUV420P,
+ AV_PIX_FMT_YUVA420P,
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
@@ -46,6 +48,7 @@ static const enum AVPixelFormat vp9_pix_fmts_highcol[] = {

static const enum AVPixelFormat vp9_pix_fmts_highbd[] = {
AV_PIX_FMT_YUV420P,
+ AV_PIX_FMT_YUVA420P,
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUV444P,
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 4ea932d..c5b1b86 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -284,6 +284,7 @@ static int set_pix_fmt(AVCodecContext *avctx, vpx_codec_caps_t codec_caps,
#endif
switch (avctx->pix_fmt) {
case AV_PIX_FMT_YUV420P:
+ case AV_PIX_FMT_YUVA420P:
enccfg->g_profile = 0;
*img_fmt = VPX_IMG_FMT_I420;
return 0;
--
2.8.0.rc3.226.g39d4020
James Zern
2016-07-01 05:37:05 UTC
Permalink
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.
[1] https://codereview.chromium.org/2096813002/
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)
Wasn't there a vp8+alpha webm in fate?
Vignesh Venkatasubramanian
2016-07-01 16:23:07 UTC
Permalink
On Thu, Jun 30, 2016 at 10:37 PM, James Zern
Post by James Zern
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.
[1] https://codereview.chromium.org/2096813002/
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)
Wasn't there a vp8+alpha webm in fate?
yes, there is one under vp8_alpha directory. but the test is very weak
as it just does a -c copy and checks if the output has blockadditional
data. if you want, i can replicate the same for vp9. let me know.
Post by James Zern
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
Ronald S. Bultje
2016-07-01 17:02:46 UTC
Permalink
Hi,

On Fri, Jul 1, 2016 at 12:23 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
On Thu, Jun 30, 2016 at 10:37 PM, James Zern
Post by James Zern
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.
[1] https://codereview.chromium.org/2096813002/
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)
Wasn't there a vp8+alpha webm in fate?
yes, there is one under vp8_alpha directory. but the test is very weak
as it just does a -c copy and checks if the output has blockadditional
data. if you want, i can replicate the same for vp9. let me know.
Do we have decoder support (for either vp8 or vp9) for these files? Using
either libvpx or ffvp8/9? My impression is no.

Ronald
Carl Eugen Hoyos
2016-07-01 17:07:16 UTC
Permalink
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these files?
No, only encoding and muxing.

Carl Eugen
James Zern
2016-07-01 17:40:07 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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.
Ronald S. Bultje
2016-07-01 17:53:55 UTC
Permalink
Hi,
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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?

Ronald
James Almer
2016-07-01 18:06:18 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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?
We already create animated webp files that we can't decode. It wouldn't
be a first :P

PS: We should really add animated webp decoding, for that matter.
Vignesh Venkatasubramanian
2016-07-01 19:12:03 UTC
Permalink
Post by James Almer
Post by Ronald S. Bultje
Hi,
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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.
Post by James Almer
We already create animated webp files that we can't decode. It wouldn't
be a first :P
PS: We should really add animated webp decoding, for that matter.
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
Ronald S. Bultje
2016-07-01 19:29:21 UTC
Permalink
Hi,

On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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?

Ronald
Ronald S. Bultje
2016-07-01 19:48:24 UTC
Permalink
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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?

Ronald

[1] https://bugzilla.gnome.org/show_bug.cgi?id=735450
[2]
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2014-September/023436.html
Vignesh Venkatasubramanian
2016-07-01 21:27:09 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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.
Post by Ronald S. Bultje
Ronald
[1] https://bugzilla.gnome.org/show_bug.cgi?id=735450
[2]
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2014-September/023436.html
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
Ronald S. Bultje
2016-07-01 22:03:13 UTC
Permalink
Hi,

On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one if
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange to
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use Chrome
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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.
Post by Ronald S. Bultje
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
Ivan Kalvachev
2016-07-02 08:13:13 UTC
Permalink
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one if
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange to
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use Chrome
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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.
Post by Ronald S. Bultje
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".
<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.
Vignesh Venkatasubramanian
2016-07-06 23:50:10 UTC
Permalink
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one if
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange to
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use Chrome
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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.
Post by Ronald S. Bultje
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".
<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). 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. :)
Post by Ronald S. Bultje
Ronald
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
Vignesh Venkatasubramanian
2016-07-07 18:44:38 UTC
Permalink
On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one if
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange to
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use Chrome
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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.
Post by Ronald S. Bultje
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".
<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
Post by Vignesh Venkatasubramanian
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. :)
Post by Ronald S. Bultje
Ronald
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
--
Vignesh
Ronald S. Bultje
2016-07-07 19:02:33 UTC
Permalink
Hi Vignesh,

On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one
if
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange
to
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
people handle the files created with this feature, if not by
using
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
in
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use
Chrome
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
files, e.g. what if a service like Youtube/Vimeo wants to allow
upload
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
of
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
outside Chrome. I'm not saying you should implement it in all
multimedia
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
frameworks ever created in human history, but doing it in one of them
(e.g.
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
much easier than that, right? But is it actually useful to anyone? I
mean
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
not just useful for you, but useful to a wider set of people, at least
in
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
theory.
If there's no decoder, I would claim that the wider utility of this
thing
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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.
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
I'm just asking for a vp9a decoder. It might even be OK if it's
implemented
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
on top of ffmpeg instead of inside libavcodec (I'm not sure how others
feel
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
about this), i.e. just something that invokes libavformat to parse a
webm
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
file, create two decoders to get the yuv and a planes, and then merge
them
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
together into a yuva420p picture. I'm just asking for something _small_
and
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
_simple_ (i.e. not "Chrome") that we can point users to when they ask
"how
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
do I decode vp9a files".
<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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
needs a decoder”?
<JEEB> BBB: I do tend to agree that in general it goes dec->enc, or
both at
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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
Thanks, that resolves my concerns.

Ronald
Vignesh Venkatasubramanian
2016-07-12 18:49:49 UTC
Permalink
Post by Ronald S. Bultje
Hi Vignesh,
On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
Do we have decoder support (for either vp8 or vp9) for these
files?
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Carl Eugen Hoyos
No, only encoding and muxing.
Seems like a feature request, but no reason to block this one
if
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
the
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
vp8 one is here.
I'm not sure I have an opinion on this... But it feels strange
to
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
allow
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
encoding of content we cannot decode. Being ffmpeg, how do we
recommend
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
people handle the files created with this feature, if not by
using
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
in
Post by Ronald S. Bultje
Post by Ronald S. Bultje
other cases.
So you're suggesting that it is perfectly fine for people to use
Chrome
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
as
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
files, e.g. what if a service like Youtube/Vimeo wants to allow
upload
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
of
Post by Ronald S. Bultje
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
outside Chrome. I'm not saying you should implement it in all
multimedia
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Ronald S. Bultje
Post by Ronald S. Bultje
frameworks ever created in human history, but doing it in one of them
(e.g.
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
much easier than that, right? But is it actually useful to anyone? I
mean
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
not just useful for you, but useful to a wider set of people, at least
in
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
theory.
If there's no decoder, I would claim that the wider utility of this
thing
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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.
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
I'm just asking for a vp9a decoder. It might even be OK if it's
implemented
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
on top of ffmpeg instead of inside libavcodec (I'm not sure how others
feel
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
about this), i.e. just something that invokes libavformat to parse a
webm
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
file, create two decoders to get the yuv and a planes, and then merge
them
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
together into a yuva420p picture. I'm just asking for something _small_
and
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
_simple_ (i.e. not "Chrome") that we can point users to when they ask
"how
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
do I decode vp9a files".
<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
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
needs a decoder”?
<JEEB> BBB: I do tend to agree that in general it goes dec->enc, or
both at
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
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
Thanks, that resolves my concerns.
Can you please commit this patch? Thanks!
Post by Ronald S. Bultje
Ronald
_______________________________________________
ffmpeg-devel mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Vignesh
James Zern
2016-07-13 06:01:58 UTC
Permalink
On Tue, Jul 12, 2016 at 11:49 AM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Post by Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
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
Thanks, that resolves my concerns.
Can you please commit this patch? Thanks!
I missed Ronald's comment last week. I'll push this soon.
Ivan Kalvachev
2016-07-02 08:04:46 UTC
Permalink
Post by Vignesh Venkatasubramanian
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
Hi,
On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
Post by Vignesh Venkatasubramanian
Hi,
On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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.
The libvpx is used for both encoding and decoding,
so it should be able to decode alpha planes and
provide them to ffmpeg.

Do you have idea how hard is adding decoding support this way?
Can you do it?
Carl Eugen Hoyos
2016-07-02 08:26:49 UTC
Permalink
Post by Ivan Kalvachev
Do you have idea how hard is adding decoding support this way?
It is non-trivial because the format is quite broken.

But I really don't see how any of this is related...

Carl Eugen
Carl Eugen Hoyos
2016-07-01 20:30:13 UTC
Permalink
Post by James Zern
Post by Carl Eugen Hoyos
Post by Ronald S. Bultje
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.
Of course not.

Sorry if I gave that impression, Carl Eugen
James Zern
2016-07-01 17:40:46 UTC
Permalink
On Fri, Jul 1, 2016 at 9:23 AM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
On Thu, Jun 30, 2016 at 10:37 PM, James Zern
Post by James Zern
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.
[1] https://codereview.chromium.org/2096813002/
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)
Wasn't there a vp8+alpha webm in fate?
yes, there is one under vp8_alpha directory. but the test is very weak
as it just does a -c copy and checks if the output has blockadditional
data. if you want, i can replicate the same for vp9. let me know.
I think it would make sense if there was going to be work done on the
decode side.
James Zern
2016-07-13 06:35:37 UTC
Permalink
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian
Post by Vignesh Venkatasubramanian
Chrome canary now supports decoding of VP9 streams with alpha
channel [1]. Add support to ffmpeg for creating such files.
[1] https://codereview.chromium.org/2096813002/
---
libavcodec/libvpx.c | 3 +++
libavcodec/libvpxenc.c | 1 +
2 files changed, 4 insertions(+)
applied

Loading...