On Sun, Feb 13, 2011 at 7:12 PM, Ronald S. Bultje <[email protected]> wrote: > Hi, > > On Sun, Feb 13, 2011 at 6:44 PM, Thomas Worth <[email protected]> wrote: >> I am allocating buffers that need to hold the entire contents of >> myAVframe->data[0], including the padding bytes. In the case of >> 1920x1088 video, there are 32 padding bytes so linesize[0] is 1952. I >> need to know this beforehand so I can make room in my buffer. Is there >> any way to know how much this will be prior to actually decoding the >> frame? > > FFALIGN(width, 16)+EDGE_SIZE*16, where FF_ALIGN aligns width to the > next multiple of 16, and EDGE_SIZE itself is also 16, so for 1920, > that'd be ceil(1920/16.0)*16+16*2=1952. > > The same calculation applies to height also. One of the edges is on > top, one at the bottom, one left and one right, so data[0] is > allocated_data+16+(align(width,16)+16*2)*16. > > If you can't provide edges, and you want linesize to be equal to > width, use AVCodecContext->flags &= CODEC_FLAG_EMU_EDGE, this will > slightly slow down decoding, but alleviate the edges on all sides of > the image.
Thanks. In your code above, you multiply 16 by 2, for a total of 32 padding bytes. However, in the case of subsampled formats (h264 decoder, for example) this only applies to the luma channel (data[0]). Cb and Cr channels are only padded with 16 bytes. How should I apply this? Is data[0] always 16*2 and data[>0] always 16*1 with subsampled formats? What should I use to detect this? h264 is a 4:2:0 format where Cb and Cr are 1/4 the resolution of Y, but what about a 4:2:2 format with 1/2 the resolution of Y? _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
