GNOME Bugzilla – Bug 749253
h263parse: fix picture format parsing
Last modified: 2015-05-13 10:56:07 UTC
Created attachment 303243 [details] mkv stream with h263 video When we played a encoded H.263 video clip (see attached file) and failed to play and h263parse reported "corrupted CPFMT" and failed to parse the header. We checked this issue, and it turns out there is no CPFMT area in this h263 video (also attached the h263 raw video), and it is wrongly read this area. 1. In H263 spec, for CPFMT, it said: A fixed length codeword of 23 bits that is present only if the use of a custom picture format is signalled in PLUSPTYPE and UFEP is '001'. So, only when source format is custom picture format (format==6), then CPFMT can be read. 2. When checking the CPFMT reading, we also found that the width and height calculation is not correct. According to spec, The 9 bits width info and 9 bits height info should be used as: Picture Width Indication: Range [0, ... , 511]; Number of pixels per line = (PWI + 1) * 4 Picture Height Indication: Range [1, ... , 288]; Number of lines = PHI * 4. */ The prevoius calculate method is not correctly. params->width = (((cpfmt >> 10) & 0x1f) + 1) * 4; params->height = ((cpfmt & 0x1f) + 1) * 4; should be: params->width = (((cpfmt >> 10) & 0x1ff) + 1) * 4; params->height = (cpfmt & 0x1ff) * 4; Please see attached patch for the fix Thanks Lyon
Created attachment 303244 [details] h263 raw video
Created attachment 303245 [details] [review] patch to fix CPFMT reading error issue
Thanks, pushed: commit 6adf3c2499f81e9254e160e04ce3c821bd47938d Author: Lyon Wang <lyon.wang@freescale.com> Date: Tue May 12 15:47:33 2015 +0800 h263parse: fix custom picture format (CPFMT) parsing In the H263 spec, CPFMT is present only if the use of a custom picture format is signalled in PLUSEPTYPE and UFEP is "001", so we need to check params->format and only if the value is 6 (custom source format) the CPFMT should be read, otherwise it's not present and wrong data will be parsed. When reading the CPFMT, the width and height were not calculated correctly (wrong bitmask). https://bugzilla.gnome.org//show_bug.cgi?id=749253