On Fri, 6 Feb 2015 20:16:50 +0000 (UTC) Carl Eugen Hoyos <ceho...@ag.or.at> wrote:
> wm4 <nfxjfg <at> googlemail.com> writes: > > > The pixfmt docs seems to imply that the extra > > component must be set to 0 if a RGB0 format is > > used. Camtasia puts random stuff. > > The documentation sounds wrong to me: The pix_fmt > was needed because of hardware providing 32bit rgb, > there is no guarantee what the X bits contain and > it makes no sense for FFmpeg to require a specific > content. > It is good behaviour that libswscale writes a > defined value though (as it does iirc). > > (This is unrelated but I don't think "random" is > the right word in above sequence: The fact that > I did not interpret the alpha value as random > was apparently the reason I never changed the > pix_fmt. But you are clearly right that RGB32 is > wrong.) > > > What about AV_PIX_FMT_RGB555? It's documented > > as having 1 alpha bit > > I believe this is a documentation issue, see > rgb15to32_c() in libswscale. > > > though it doesn't have the alpha pixfmt flag set. > > Fix the docs? Or introduce RGB05551? > > Atm, I cannot remember a sample that supports > alpha in RGB555 (I do remember that it is > defined in some specs though). > > > There is no AV_PIX_FMT_RGB064. > > > Is it guaranteed that there is no 64 bit > > format with padding? > > FFmpeg "promises" that RGBA64 contains a valid > alpha channel, just as FFmpeg "promises" bit- > exact H.264 decoding. > > > If one ever exists, is it guaranteed that a 0 > > variant will be added? > > I cannot imagine a screen driver that provides > 64 bit rgb screen grabs but please prove me wrong! > If all these things are guaranteed, then I have no problems with the current solution. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
