[gstreamer-bugs] [Bug 421110] New x264enc plugin

[GStreamer (bugzilla.gnome.org)]

Do NOT reply to this via email (we are currently unable to handle email
responses and they WILL be discarded).

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=421110.
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

  GStreamer | gst-plugins-bad | Ver: HEAD CVS





------- Comment #9 from Tim-Philipp Müller  2007-03-25 20:16 UTC -------
> x264 library handles widths/heights non-divisible by 16 correctly by
> setting appropriate cropping. This is more effective than cropping the
> image explicitly before passing to encoder

That may be so, but as far as I can tell you're still feeding it data with the
wrong strides in those cases, since you need to consider the actual input
stride of the input data. Also, our video caps system currently doesn't have a
standardised way to pass cropping configuration with picture data, so even if
libx264 can do that you can't really do this with GStreamer yet.

This doesn't look right, for example (although the decoder might be broken in
this respect as well of course):

$ gst-launch-0.10 videotestsrc !
video/x-raw-yuv,format=\(fourcc\)I420,width=718,height=574 ! x264enc !
ffdec_h264 ! ffmpegcolorspace ! xvimagesink