[FFmpeg-devel] [PATCH]lavf/webpenc: Do not set alpha flag for yuv420p

Carl Eugen Hoyos cehoyos at ag.or.at
Mon May 2 11:49:36 CEST 2016


On Wednesday 13 April 2016 10:27:03 am you wrote:
> On Tue, 12 Apr 2016 19:53:13 +0000 (UTC)
>
> Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > wm4 <nfxjfg <at> googlemail.com> writes:
> > > > -                flags |= 2 + 16;
> > > > +                flags |= 2;
> > > > +                if (st->codecpar->format != AV_PIX_FMT_YUV420P)
> > > > +                    flags |= 16; // stream may contain transparency
> > > > information
> > >
> > > The pixel format shouldn't be required to be set in this muxer.
> >
> > I am sorry, I don't understand the word "should" in this
> > sentence: Do you mean the webp specification is bad or
> > that the muxer should use a different information to
> > find out if the frames may contain transparency?
> > Or that the ticket is invalid or that I misunderstand it?
>
> No, I'm just saying that using the pixel format here (or how it's used)
> is not overly robust.
>
> Maybe there is not better way to signal alpha content to the muxer, but
> even then it sounds wrong to assume alpha if the format is not set.

Generally, I don't think assuming alpha for yuva420p and bgra is wrong.

> Maybe it should just check whether the pixel format is alpha, instead
> of whether it's not yuv420p. (Just a suggestion.)

Isn't that exactly equivalent to what my patch is doing?
Or do I just misunderstand?

I just thought that "if (pix_fmt != AV_PIX_FMT_YUV420P)" is shorter than 
"if (pix_fmt == AV_PIX_FMT_RGB32 || pix_fmt == AV_PIX_FMT_YUVA420P)". Do you 
disagree?

> But ideally maybe it could be parsed from the image data? (I'm not sure
> if that's feasible.)

I don't think this makes sense, especially since the header is written for the 
first output frame afaict.

I was able to test my original patch and it "fixes" reading the output file of 
the following command with current webpmux:
$ ffmpeg -f lavfi -i color=d=1 out.webp

The general "bug" cannot be fixed afaict, but fixing many standard use-cases 
makes sense imo.

Please comment, Carl Eugen


More information about the ffmpeg-devel mailing list