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 331301 - [mpeg2dec] strides issues when cropping
[mpeg2dec] strides issues when cropping
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other Linux
: Normal normal
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-15 17:50 UTC by Tim-Philipp Müller
Modified: 2006-02-17 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
possible fix (6.41 KB, patch)
2006-02-15 17:53 UTC, Tim-Philipp Müller 		none Details | Review

Description Tim-Philipp Müller 2006-02-15 17:50:11 UTC 
mpeg2dec is a bad citizen in Stridesville.

Take the following video:

http://lycos.dropcode.net/xgl/xgl-gentoo-lycos.mpeg

which has dimensions of 764x556 pixels, so it gets cropped + copied before sending it out, albeit the new I420 output buffer is allocated with wrong size, and strides (as implicit by X) are not taken into account when copying.

This is with up-to-date CVS, ie. including the fix from bug #330844 (which is required).
Comment 1 Tim-Philipp Müller 2006-02-15 17:53:48 UTC 
Created attachment 59416 [details] [review]
possible fix
Comment 2 Tim-Philipp Müller 2006-02-15 17:58:16 UTC 
Oh, even with the fix ffmpegcolorspace/basetransform still complains because ffmpegcolorspace assumes a different (too small) unit size due to the same issue.
Comment 3 Jan Schmidt 2006-02-17 13:29:58 UTC 
Fixed in CVS:
        * ext/mpeg2dec/gstmpeg2dec.c: (crop_copy_i420_buffer),
        (crop_copy_i422_buffer), (crop_buffer):
          When we need to crop the output buffer, make sure we
          create a buffer of the right size and respect the implicit
          striding used for I420 elsewhere in GStreamer (#331301).

We should handle the ffmpegcolorspace issue separately.