Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanianwrote: > 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 > --- > libavcodec/libvpx.c| 3 +++ > libavcodec/libvpxenc.c | 1 + > 2 files changed, 4 insertions(+) applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Tue, Jul 12, 2016 at 11:49 AM, Vignesh Venkatasubramanianwrote: >>> > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Thu, Jul 7, 2016 at 12:02 PM, Ronald S. Bultjewrote: > Hi Vignesh, > > On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > >> On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian >> wrote: >> > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje >> wrote: >> >> Hi, >> >> >> >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < >> >> vigneshv-at-google@ffmpeg.org> wrote: >> >> >> >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >> >>> wrote: >> >>> > Hi, >> >>> > >> >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje > > >> >>> wrote: >> >>> > >> >>> >> Hi, >> >>> >> >> >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >> >>> >> vigneshv-at-google@ffmpeg.org> wrote: >> >>> >> >> >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >> >>> 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@ffmpeg.org> >> >>> >>> >> wrote: >> >>> >>> >> >> >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >> >>> ceho...@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
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi Vignesh, On Thu, Jul 7, 2016 at 2:44 PM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanian >wrote: > > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje > wrote: > >> Hi, > >> > >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < > >> vigneshv-at-google@ffmpeg.org> wrote: > >> > >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje > >>> wrote: > >>> > Hi, > >>> > > >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje > > >>> wrote: > >>> > > >>> >> Hi, > >>> >> > >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < > >>> >> vigneshv-at-google@ffmpeg.org> wrote: > >>> >> > >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer > >>> 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@ffmpeg.org> > >>> >>> >> wrote: > >>> >>> >> > >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < > >>> ceho...@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: > >> > >> jamrial: so … I’m looking for a second opinion
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Wed, Jul 6, 2016 at 4:50 PM, Vignesh Venkatasubramanianwrote: > On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < >> vigneshv-at-google@ffmpeg.org> wrote: >> >>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >>> wrote: >>> > Hi, >>> > >>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >>> wrote: >>> > >>> >> Hi, >>> >> >>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >>> >> vigneshv-at-google@ffmpeg.org> wrote: >>> >> >>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >>> 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@ffmpeg.org> >>> >>> >> wrote: >>> >>> >> >>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >>> ceho...@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: >> >> 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”? >> 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 >> BBB: no, you're not being hard >> >> So it seems I'm not entirely alone in this opinion within the ffmpeg >> developer
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultjewrote: > Hi, > > On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > >> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >> wrote: >> > Hi, >> > >> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >> wrote: >> > >> >> Hi, >> >> >> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >> >> vigneshv-at-google@ffmpeg.org> wrote: >> >> >> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >> 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@ffmpeg.org> >> >>> >> wrote: >> >>> >> >> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >> ceho...@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: > > 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”? > 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 > 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
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Ivan Kalvachev gmail.com> writes: > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi, On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje> wrote: > > Hi, > > > > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje > wrote: > > > >> Hi, > >> > >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < > >> vigneshv-at-google@ffmpeg.org> wrote: > >> > >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer > 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@ffmpeg.org> > >>> >> wrote: > >>> >> > >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < > ceho...@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: 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”? 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 BBB: no, you're not being hard So it seems I'm not entirely alone in this opinion within the ffmpeg developer community. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultjewrote: > Hi, > > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje wrote: > >> Hi, >> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >> vigneshv-at-google@ffmpeg.org> wrote: >> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer 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@ffmpeg.org> >>> >> wrote: >>> >> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos >>> >>> 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. > 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 > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
James Zern ffmpeg.org> writes: > >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi, On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultjewrote: > Hi, > > On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > >> On Fri, Jul 1, 2016 at 11:06 AM, James Almer 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@ffmpeg.org> >> >> wrote: >> >> >> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos >> >>> 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? 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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi, On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Fri, Jul 1, 2016 at 11:06 AM, James Almerwrote: > > 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@ffmpeg.org> > >> wrote: > >> > >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos > >>> 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? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 11:06 AM, James Almerwrote: > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern >> wrote: >> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos >>> 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. > > 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 > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: > Hi, > > On Fri, Jul 1, 2016 at 1:40 PM, James Zern> wrote: > >> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos >> 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? 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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi, On Fri, Jul 1, 2016 at 1:40 PM, James Zernwrote: > On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos > 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? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 9:23 AM, Vignesh Venkatasubramanianwrote: > On Thu, Jun 30, 2016 at 10:37 PM, James Zern > wrote: >> On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian >> wrote: >>> 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 >>> --- >>> 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyoswrote: >> 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Ronald S. Bultje gmail.com> writes: > Do we have decoder support (for either vp8 or vp9) for these files? No, only encoding and muxing. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Hi, On Fri, Jul 1, 2016 at 12:23 PM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Thu, Jun 30, 2016 at 10:37 PM, James Zern >wrote: > > On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian > > wrote: > >> 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 > >> --- > >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Thu, Jun 30, 2016 at 10:37 PM, James Zernwrote: > On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanian > wrote: >> 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 >> --- >> 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. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On Thu, Jun 30, 2016 at 4:16 PM, Vignesh Venkatasubramanianwrote: > 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 > --- > libavcodec/libvpx.c| 3 +++ > libavcodec/libvpxenc.c | 1 + > 2 files changed, 4 insertions(+) > Wasn't there a vp8+alpha webm in fate? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
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--- 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel