Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Marton Balint	c60a824ee8	avformat/qtpalette: parse color table according to the QuickTime file format specs The specs says that the the first color component in the color array is not alpha, but simply 0. Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov Signed-off-by: Marton Balint <cus@passwd.hu>	7 years ago
Andreas Cadhalpun	63c9b30f98	qtpalette: make the color_* variables unsigned again This fixes segmentation faults due to out of bounds writes, when color_start is interpreted as negative number. This regression was introduced in commit 57631f. Reviewed-by: Mats Peterson <matsp888@yahoo.com> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>	9 years ago
Mats Peterson	b6c61b7d43	lavf/qtpalette: Ignore greyscale bit in certain cases The QuickTime File Format Specification states the following: "Depth: A 16-bit integer that indicates the pixel depth of the compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the depth of color images. The value 32 should be used only if the image contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and 8-bit grayscale, respectively, for grayscale images." There is no mention of value 33, i.e. 1-bit video (0x01) with the greyscale bit (0x20) set. I therefore suggest that we ignore the greyscale bit when processing 1-bit video. Another reason to do this is that the first 1-bit sample file below will be displayed properly with blue colors in QuickTime in Windows or Mac in spite of the greyscale bit being set. Also, QuickTime in Windows or Mac ignores the greyscale bit if the video sample description contains a palette, regardless of bit depth. This is undocumented behaviour, but I think we should do the same, and it seems pretty logical after all, since one wouldn't really bother putting a customized palette into a grayscale file anyway. See the second 8-bit sample file below, which has the greyscale bit set, and which contains a palette in the video sample description. In Windows or Mac, it will be displayed with the palette in the sample description, in spite of the greyscale bit being set. Sample file 1 (1-bit QuickTime Animation): https://drive.google.com/open?id=0B3_pEBoLs0faTThSek1EeXQ0ZHM Earth Spin 1-bit qtrle orig.mov Sample file 2 (8-bit QuickTime Animation): https://drive.google.com/open?id=0B3_pEBoLs0fad2s0V1YzUWo5aDA quiz-palette+gs.mov Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	9 years ago
Mats Peterson	bd03ee1184	lavf/qtpalette: Treat 1-bit video as palettized This commit for qtpalette.c and qtpalette.h adds 1-bit video to the "palettized video" category, since if the video sample description contains a palette, the two colors in the palette can be any color, not necessarily black & white. Unfortunately, I've noticed that the qtrle (QuickTime Animation) decoder blindly assumes that 1-bit video is black & white. I don't have enough knowledge about the decoder to fix this, though. Below is a link to a sample 1-bit QuickTime Animation clip of a rotating earth that uses blueish colors, and they will be correctly rendered in QuickTime, but not in FFmpeg (which will use black & white). https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	9 years ago
Michael Niedermayer	ca9e3cb3ce	avformat/qtpalette: Move ff_get_qtpalette() doxy to header Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	9 years ago
Mats Peterson	57631f1851	avformat: factor ff_get_qtpalette() out of mov.c This consists mainly of moving the palette handling from the mov_parse_stsd_video() function to a new ff_get_qtpalette() function in the new file qtpalette.c, which will be shared by both matroskadec.c and mov.c. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	9 years ago