Locutus wrote: > Could the fact that the call to avcodec_decode_video is returning a decoded > image in a buffer of dimensions different from the source indicate a > mis-compiled libav library for the target platform (windows)?
A mis-compiled library seems very unlikely to me. I have noticed the same behavior here under Linux. I'm sorry but I don't know the exact revision number I used to build the libraries. At least two codecs seem to produce a picture that is always 32 pixels wider than the source image. I made some experiments with MPEG2 and DIVX, both adding 32 pixels of width. But I didn't find out 1. if the picture is padded to the new size or scaled 2. if the padding is added to the left or on both sides (16 px on each side) 3. if the picture is also padded vertically 4. how to determine the effective decoded picture width, height and padding To answer Luca's question: The size(s) in AVCodecContext always show the "real" size, i.e. the size without the padding. The only hint to the padding is the line stride of the decoded picture (claimed width + 32 px). After finding the answers to the above questions, converting the picture into your format should be quite easy. However I'm not very familiar with the libav* API and I don't know if the av_picture_pad function you mentioned can do the trick alone and how it should be called ... Best regards Siegmar _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
