http://samples.mplayerhq.hu/V-codecs/CVID/bad_cinepak_frame_size.mov This fix works around another work around which handles a different type of odd Cinepak data. Thanks to Matthew Hoops (clone2727 - gmail.com) for the sample and fix.
Unified · Split
| @@ -330,12 +330,13 @@ static int cinepak_decode (CinepakContext *s) · 329 unmodified lines | ||
| 330 | 330 | |
| 331 | 331 | /* if this is the first frame, check for deviant Sega FILM data */ |
| 332 | 332 | if (s->sega_film_skip_bytes == -1) { |
| 333 | − if (encoded_buf_size != s->size) { | |
| 333 | + if (encoded_buf_size != s->size && (s->size % encoded_buf_size) != 0) { | |
| 334 | 334 | /* If the encoded frame size differs from the frame size as indicated |
| 335 | 335 | * by the container file, this data likely comes from a Sega FILM/CPK file. |
| 336 | 336 | * If the frame header is followed by the bytes FE 00 00 06 00 00 then |
| 337 | 337 | * this is probably one of the two known files that have 6 extra bytes |
| 338 | − * after the frame header. Else, assume 2 extra bytes. */ | |
| 338 | + * after the frame header. Else, assume 2 extra bytes. The container | |
| 339 | + * size also cannot be a multiple of the encoded size. */ | |
| 339 | 340 | if (s->size >= 16 && |
| 340 | 341 | (s->data[10] == 0xFE) && |
| 341 | 342 | (s->data[11] == 0x00) && |