[FFmpeg-devel] [FFmpeg-cvslog] ffplay: only use hardware accelerated SDL texture formats

[Michael Niedermayer]

On Tue, Apr 17, 2018 at 09:50:15PM +0200, Marton Balint wrote:
> 
> 
> On Tue, 17 Apr 2018, Michael Niedermayer 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 <cus at 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
> 
> Old code negotiated RGB24 format for render which silently dropped the alpha
> channel. This seems to be because of a bug in pick_format:
> 
> libavfilter/avfiltergraph.c, pick_format():
> int has_alpha= av_pix_fmt_desc_get(ref->format)->nb_components % 2 == 0;
> 
> libavutil/pixdesc.c:
> #define pixdesc_has_alpha(pixdesc) \
>     ((pixdesc)->nb_components == 2 || (pixdesc)->nb_components == 4 || (pixdesc)->flags & AV_PIX_FMT_FLAG_PAL)
> 
> 
> >
> >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);
> >                }
> >            }
> >
> 
> Obviously this fixes it. Why do we think that the first value is alpha?
> Parsing it was added in 0d59ae32c23 but according to the QuickTime specs the
> first int16 should be simply 0, not alpha:

the question here is probably are there files which use this for alpha ?
If theres no flag or othe to detect this then we could check for the
spec variant of all being 0 and treat this as all 0xFF alpha

I dont know or remember why this was using it as alpha

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180418/1b2915d0/attachment.sig>