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 <jamr...@gmail.com> wrote:
> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
> jzern-at-google....@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?

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to