Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes:
>
> On 13.05.2016, at 02:49, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
>
> > Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes:
> >
> >>> - AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_LOSSLESS
> >>> + AV_CODEC_CAP_AUTO_THREADS | (int)AV_CODEC_CAP_LOSSLESS
> >>
> >> That doesn't seem like a good idea, AV_CODEC_CAP_LOSSLESS does
> >> not fit in int,
> >
> > Why does 0x8000 not fit in int?
>
> Isn't it 0x80000000??
You are right but this still is <= 32bit, no?
> Either way, the compiler said it didn't fit...
I believe the compiler said it cannot convert a large positive
(32bit) value into (signed) int.
> >> so we should not try to store it in one, not explicitly cast
> >> to int...
> >
> > What is the correct fix?
>
> Where does the "int" the compiler complains about come from?
I believe it comes from line 3552 of avcodec.h:
int capabilities;
> I guess it should be "unsigned" or a 64 bit type instead.
It was unsigned but the compiler doesn't like the conversion
from unsigned to int and 64 bit are not an option afaict.
Carl Eugen
_______________________________________________
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
