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 496127 - [deinterlace/scale/postproc] support for non-I420 colorspaces
[deinterlace/scale/postproc] support for non-I420 colorspaces
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: Normal enhancement
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-12 11:55 UTC by Gabriel Bouvigne
Modified: 2008-05-06 14:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Overly simple patch (693 bytes, patch)
2007-12-11 12:57 UTC, Gabriel Bouvigne
committed Details | Review

Description Gabriel Bouvigne 2007-11-12 11:55:10 UTC
Right now, both ffdeinterlace and postproc_ffmpegdeint only handle 4:2:0 input.

If input is 4:2:2, the only option is to convert colorspace before. However, there is no interlacing information carried within the current Gstreamer, so the 4:2:2->4:2:0 convertion would be done on interlaced content, without being aware of this. This is likely to produce serious chroma artifacts.

Considering that the avpicture_deinterlace ffmpeg function is supporting 4:2:2 (and higher) as input, extending the caps abilities of the ffdeinterlace  and postproc_ffmpegdeint would allow to correctly deinterlace 4:2:2 content, which is not possible right now.
Comment 1 Edward Hervey 2007-11-12 12:00:59 UTC
The only limitations seem to be that the pad template caps are hardcoded to I420.

Modifiying title accordingly.
Comment 2 Gabriel Bouvigne 2007-12-10 16:51:48 UTC
After further looking, in indeed appears that the ffmpeg pixel format is retrieved using gst_ffmpeg_caps_to_pixfmt, which translates Gstreamer caps into ffmpeg pixfmt.
As gst_ffmpeg_caps_to_pixfmt already knows about 4:2:2, it also seems to me that the limitation is only coming form the fact that pad templates of ffdeinterlace and postproc_ffmpegdeint are hardcoded to I420.
Comment 3 Gabriel Bouvigne 2007-12-11 12:57:52 UTC
Created attachment 100760 [details] [review]
Overly simple patch

Considering that ffmpeg is supporting 422P and 411P (http://lxr-itec.uni-klu.ac.at/ffmpeg/source/libavcodec/imgconvert.c#L2129), and considering that Gstreamer caps to ffmpeg formats conversion (gst_ffmpeg_caps_to_pixfmt within gstffmpegcodecmap.c) is able to convert Y42B and Y41B to those formats, wondering is something as simple as this patch could just work.
Comment 4 Wim Taymans 2007-12-11 17:04:28 UTC
did someone try it?
Comment 5 Gabriel Bouvigne 2008-01-14 13:43:26 UTC
I finally tryed it with this pipeline:

gst-launch -v filesrc location=source.mpg ! mpegdemux ! mpeg2dec ! ffmpegcolorspace ! video/x-raw-yuv, format=\(fourcc\)Y42B ! postproc_ffmpegdeint ! ffmpegcolorspace  ! videoscale ! autovideosink 

It works, and connects fine. It deinterlaces, but this pipeline still produces a few color artifacts. I think that it's likely because I'm using ffmpegcolorspace to convert 4:2:0 interlaced video into 4:2:2, while ffmpegcolorspace is not interlacing-aware.
Comment 6 Gabriel Bouvigne 2008-01-14 13:47:47 UTC
I just tryed with a 4:2:2 mpeg source, and indeed it appears to work properly.
Comment 7 Edward Hervey 2008-05-06 14:31:48 UTC
2008-05-06  Edward Hervey  <edward.hervey@collabora.co.uk>

	Patch by: Gabriel Bouvigne  <bouvigne at mp3-tech dot org>
	* ext/libpostproc/gstpostproc.c:
	Support for non-I420 colorspaces in postproc
	Fixes #496127