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;
params->width = (((cpfmt >> 10) & 0x1ff) + 1) * 4;
params->height = (cpfmt & 0x1ff) * 4;
Please see attached patch for the fix
Created attachment 303244 [details]
h263 raw video
Created attachment 303245 [details] [review]
patch to fix CPFMT reading error issue
Author: Lyon Wang <firstname.lastname@example.org>
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).