On Mon, Jul 24, 2017 at 3:42 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
wrote:
> 2017-07-21 20:16 GMT+02:00 Reimar Döffinger <reimar.doeffin...@gmx.de>:
> > On 21.07.2017, at 16:26, Paras Chadha <paraschadh...@gmail.com> wrote:
> >
> >> On Fri, Jul 21, 2017 at 3:27 AM, Carl Eugen Hoyos <ceffm...@gmail.com>
> >> wrote:
> >>
> >>> 2017-07-20 21:46 GMT+02:00 Paras Chadha <paraschadh...@gmail.com>:
> >>>
> >>>> + case AV_PIX_FMT_RGB24:
> >>>> + case AV_PIX_FMT_RGBA:
> >>>> + for (k = 0; k < naxis3; k++) {
> >>>> + for (i = 0; i < avctx->height; i++) {
> >>>> + ptr = p->data[0] + (avctx->height - i - 1) *
> >>> p->linesize[0] + k;
> >>>> + for (j = 0; j < avctx->width; j++) {
> >>>> + bytestream_put_byte(&bytestream,
> ptr[0]);
> >>>> + ptr += naxis3;
> >>>
> >>> (Sorry if this is nonsense:)
> >>> Shouldn't you be using PIX_FMT_GBRP and PIX_FMT_GBRAP?
> >>>
> >>
> >> No, the current pixel formats are working fine. I have tested using GIMP
> >> too. It is showing all the RGB images (and others too) correctly.
> >
> > I think that's not what he meant.
> > You are explicitly requesting a packed format that has the data in
> > RGBRGBRGB... order, and you then need these loops to split it into
> > RRRR... GGGG... BBBB...
> > He's suggesting you should simply request the format storing the data
> like that
>
> Yes, this makes above code both simpler and (on typical hardware)
> always faster (it will never be slower, no matter the hardware).
>
Yes, done. It has made the code a lot simple, thanks.
>
> > then all you need to do is the unsigned -> signed conversion
>
> Which is not necessary for the above case.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
