On Tue, 17 Apr 2018 14:49:48 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Tue, Apr 17, 2018 at 01:27:48AM +0200, Marton Balint wrote: > > > > > > On Mon, 16 Apr 2018, Michael Niedermayer wrote: > > > > >Hi > > > > > >On Sat, Nov 04, 2017 at 06:28:58PM +0000, Marton Balint wrote: > > >>ffmpeg | branch: master | Marton Balint <c...@passwd.hu> | Sat Oct 28 > > >>22:46:08 2017 +0200| [415038f2bd321a3b41564d4e0c6c17d7a096c397] | > > >>committer: Marton Balint > > >> > > >>ffplay: only use hardware accelerated SDL texture formats > > > > > >This breaks ffplay playing some files like: > > >./ffplay fate-suite//cvid/catfight-cvid-pal8-partial.mov -noframedrop > > > > > >The output is completely black since this commit > > > > Seems like a bug in swscale (pal8 -> bgra conversion), the alpha is 0 > > instead of 255. > > the file seems to store alpha = 0 > SDL seems to treat alpha=0 different between PAL8 and RGBA, or maybe iam > missing something > > try this: > > diff --git a/libavformat/qtpalette.c b/libavformat/qtpalette.c > index 666c6b7351..51a134d30a 100644 > --- a/libavformat/qtpalette.c > +++ b/libavformat/qtpalette.c > @@ -104,6 +104,7 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb, > uint32_t *palette) > avio_r8(pb); > b = avio_r8(pb); > avio_r8(pb); > + a = 0xFF; > palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b); > } > } > > swscale does not introduce the alpha=0 its there before This is totally not a new problem, a bunch of players will actually interpret alpha if it's present as indicated by the pixfmt. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
