> 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
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
