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 361636 - h263 variant not specified with CODEC_ID_H263
h263 variant not specified with CODEC_ID_H263
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 363118
Reported: 2006-10-12 07:39 UTC by Ville Syrjala
Modified: 2006-12-10 19:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

Specify the h263 variant in the caps. (877 bytes, patch)
2006-10-12 07:43 UTC, Ville Syrjala
none Details | Review
Specify the H.263 variant and version in the caps. (1.72 KB, patch)
2006-11-07 10:21 UTC, Ville Syrjala
committed Details | Review

Description Ville Syrjala 2006-10-12 07:39:56 UTC
I believe the variant field in the ffenc_h263 caps should be set to "h263". Othwerwise it is impossible to diffrentiate plain H.263 and other variants.
Comment 1 Ville Syrjala 2006-10-12 07:43:04 UTC
Created attachment 74543 [details] [review]
Specify the h263 variant in the caps.

Specify the h263 variant in the caps. Only set if when encoding as ffdec_h263 seems to handle all variants.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2006-10-18 11:41:00 UTC
see also discussion in
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2006-11-07 07:24:26 UTC
Ville, can you please make new patches and rename 'variant' to 'h263version' - I'll then apply them.
Comment 4 Ville Syrjala 2006-11-07 10:21:40 UTC
Created attachment 76144 [details] [review]
Specify the H.263 variant and version in the caps.

New patch. Now uses "itu" as the variant and specifies h263version for ffenc_h263 and ffenc_h263p. I wonder if other variants should be added to the caps...

I'm not really sure about the gst_ffmpeg_caps_to_codecid() hunk.

What should be done about video/x-intel-h263? Should it be renamed to video/x-h263?
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2006-11-07 17:05:50 UTC
good point, will need to trace doen, who added the video/x-intel-h263 thing and with what intention. it wasn't even documented before and I don't think we have an encoder for that. So I guess its save to change/fix it.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2006-11-08 12:53:26 UTC
some infos for the "video/x-intel-h263" case:

./gst-plugins-base/gst-libs/gst/riff/riff-media.c:224:      caps = gst_caps_new_simple ("video/x-intel-h263",


./gst-ffmpeg/ext/ffmpeg/gstffmpegcodecmap.c:216:      caps = gst_ff_vid_caps_new (context, "video/x-intel-h263", NULL);
./gst-ffmpeg/ext/ffmpeg/gstffmpegcodecmap.c:1782:  } else if (!strcmp (mimetype, "video/x-intel-h263")) {

just found that commit, where 'variant' had been silently introduced for the 'h263version' :/


Without breaking the API, we can't revert that, neither can we resolve "video/x-intel-h263" into "video/x-h263,variant=intel"
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2006-11-16 07:28:41 UTC
2006-11-16  Stefan Kost  <>

	Patch by: Ville Syrjala <>

	* ext/ffmpeg/gstffmpegcodecmap.c: (gst_ffmpeg_codecid_to_caps),
	  Specify H.263 variant and version in the caps (fixes #361636)