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! Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
