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 637297 - mpeg2enc: fails to encode exotic video sizes
mpeg2enc: fails to encode exotic video sizes
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-15 11:40 UTC by Julien Isorce
Modified: 2018-11-03 13:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Julien Isorce 2010-12-15 11:40:48 UTC
Steps to reproduce:

gst-launch-0.10 videotestsrc num_buffers=100 ! "video/x-raw-yuv, width=570, height=322" ! mpeg2enc ! mplex ! filesink location=res.mpg

Then play it with totem, vlc or mplayer. The video is not correct. It seems to be a stride or colorspace conversion problem.


Other infos:

It's ok with 320*240, 640*480 ...
Comment 1 Vincent Penquerc'h 2011-01-24 17:29:41 UTC
As much as a copout it is, I'm tempted to say "not gstreamer".
Using mjpegtools' mpeg2enc (which is what gstreamer's mpeg2enc element uses) also doesn't get it right, and it triggers lots of valgrind reports (somewhat less of them when using a nice size like 256x256, which lends credence to the theory that it doesn't like weird sizes).
Also, luma seems correct, it's only chroma that's using a bad stride. I've tried various hardcoded strides to see if anyone of them actually worked, and none does. So the issue is more complicated that just bad stride calculation, though it seems closely related.
Comment 2 Fabrizio Milo 2011-02-01 18:11:04 UTC
According to the Mpeg2 standard there is limited number of supported video sizes.
See: http://en.wikipedia.org/wiki/MPEG-2 - Allowed Resolutions .

ie. ATSC:

1920 × 1080 pixel (16:9, square pixels), at 30p, 29.97p, 24p, 23.976p, 60i, 59.94i.
1280 × 720 pixel (16:9, square pixels), at 60p, 59.94p, 30p, 29.97p, 24p, or 23.976p
704 × 480 pixel (4:3 or 16:9, non-square pixels), at 60p, 59.94p, 30p, 29.97p, 24p, 23.976p, 60i, or 59.94i
640 × 480 pixel (4:3, square pixels), at 60p, 59.94p, 30p, 29.97p, 24p, 23.976p, 60i, or 59.94i

I think a message from the encoder saying: video size not supported or invalid should be emitted in this case.
Comment 3 David Schleef 2011-02-02 00:18:25 UTC
(In reply to comment #2)
> According to the Mpeg2 standard there is limited number of supported video
> sizes.
> See: http://en.wikipedia.org/wiki/MPEG-2 - Allowed Resolutions .

This is not correct.  mpeg2enc doesn't encode all sizes because it is buggy.

The correct behavior for the element is to call GST_ELEMENT_ERROR() when an unhandled size is requested.
Comment 4 GStreamer system administrator 2018-11-03 13:07:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/30.