On Fri, Oct 14, 2011 at 12:10:30PM +0200, Janne Grunau wrote: > On Fri, Oct 14, 2011 at 10:33:17AM +0200, Diego Biurrun wrote: > > On Thu, Oct 13, 2011 at 03:56:20PM -0700, Ronald S. Bultje wrote: > > > On Thu, Oct 13, 2011 at 3:37 PM, Diego Biurrun <[email protected]> wrote: > > > > > > > > --- a/tests/fate/prores.mak > > > > +++ b/tests/fate/prores.mak > > > > @@ -7,9 +7,9 @@ FATE_PRORES = fate-prores-422 > > > > \ > > > > > > > > -fate-prores-422: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422.mov > > > > -fate-prores-422_hq: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_HQ.mov > > > > -fate-prores-422_lt: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_LT.mov > > > > -fate-prores-422_proxy: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_Proxy.mov > > > > -fate-prores-alpha: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_with_Alpha.mov > > > > +fate-prores-422: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422.mov -pix_fmt yuv422p10le > > > > +fate-prores-422_hq: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_HQ.mov -pix_fmt > > > > yuv422p10le > > > > +fate-prores-422_lt: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_LT.mov -pix_fmt > > > > yuv422p10le > > > > +fate-prores-422_proxy: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_422_Proxy.mov -pix_fmt > > > > yuv422p10le > > > > +fate-prores-alpha: CMD = framecrc -vsync 0 -i > > > > $(SAMPLES)/prores/Sequence_1-Apple_ProRes_with_Alpha.mov -pix_fmt > > > > yuv422p10le > > > > > > I _think_ prores_alpha is actually 444 (should be 4444, but the alpha > > > channel isn't handled correctly now). Can you double check that? > > > > How do I check that? > > Passing "-pix_fmt yuv422p10le" to the alpha sample changes FATE CRCs. > > you mean passing '-pix_fmt yuv444p10le'? the decoder sets pix_fmt to > yuv422p10, the automatic scaling to yuv444p10le will of course change > the CRCs. I'm not sure if Ronald wanted you to check if the pix_fmt > reported by the decoder is correct which it is after a cursory look.
IIRC, decoder always sets pix_fmt to YUV422p10 in init no matter what's its real pix_fmt so the first frame on transcoding has wrong colours. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
