On 5/2/16, Carl Eugen Hoyos <ceho...@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 > 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
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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
