[Libav-user] sws_scale has weird behavior when not resizing

[Alexandre Millette]

 > I also have encountered this "right band" issue when converting from
 > YUV to RGB. However, I noticed that issue doesn't appear when your
 > frame width is a multiple of 8. I assumed you mentioned HeightxWidth,
 > not widthxheight and, thus frame width is 240, which is a multiple of
 > 8. In that  case this issue should not appear to my knowledge. I have
 > post on this in the same mailing list.

Thank you for pointing me to your previous post ( 
http://ffmpeg.org/pipermail/libav-user/2012-June/002166.html ): my issue 
seems quite similar.

But I am using the WidthxHeight standard, which means that my frame 
width is 190 pixels.
I have tried a few things since my last post:
I added a padding to the video using ffmpeg, making it 192x240 (so a 
multiple of 8) and then the video was shown without the green band, 
proving that there is an alignment problem.
I tried to trick the converter into thinking that the image was wider 
with this line :
 > int w = mpCodecCtx->width+2;
That way the converter assumes a width of 192 pixels. Yet it does 
absolutely no difference.
However, if I were to use :
 > int w = mpCodecCtx->width+3;
Making the width 193 pixels, the right band disappears and the frame is 
shown correctly. I can also use any integer greater than 2, as long as 
the resulting width doesn't bust the line size.
I am not surprised to see that using larger width solves the alignment 
issue, but I really don't get why stipulating a width of 192 does not 
work. After all, 192 is a multiple of 8 and a video that is already 
192x240 shows no issue...

Also I am not sure what would be the proper way to handle this 
situation. Sure I can round the width of the frame to the nearest 
greater multiple of 8 and add one to it, but I'm afraid that in some 
situation it may bust the line size and cause an exception. Plus it 
doesn't seem right to use such magic numbers...

Alex M