After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749253 - h263parse: fix picture format parsing
h263parse: fix picture format parsing
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-05-12 08:22 UTC by Lyon
Modified: 2015-05-13 10:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

mkv stream with h263 video (316.17 KB, application/x-matroska)
2015-05-12 08:22 UTC, Lyon
h263 raw video (312.70 KB, application/octet-stream)
2015-05-12 08:22 UTC, Lyon
patch to fix CPFMT reading error issue (3.76 KB, patch)
2015-05-12 08:24 UTC, Lyon
committed Details | Review

Description Lyon 2015-05-12 08:22: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

Comment 1 Lyon 2015-05-12 08:22:53 UTC
Created attachment 303244 [details]
h263 raw video
Comment 2 Lyon 2015-05-12 08:24:20 UTC
Created attachment 303245 [details] [review]
patch to fix CPFMT reading error issue
Comment 3 Tim-Philipp Müller 2015-05-13 10:55:48 UTC
Thanks, pushed:

commit 6adf3c2499f81e9254e160e04ce3c821bd47938d
Author: Lyon Wang <>
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).