[FFmpeg-devel] [PATCH]lavf/webpenc: Do not set alpha flag for yuv420p
Paul B Mahol
onemda at gmail.com
Mon May 2 13:55:27 CEST 2016
On 5/2/16, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> 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
>> 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
> first output frame afaict.
> I was able to test my original patch and it "fixes" reading the output file
> 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
I will comment only this time and if I don't get positive result I
will simply block
every your patch.
Your patch is not valid.
More information about the ffmpeg-devel