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 707433 - xvid: Port plugin to 1.0.
xvid: Port plugin to 1.0.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-04 01:25 UTC by Jonathan Horowitz
Modified: 2018-11-03 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Changes to xvid plugin as of 0.10 API (17.51 KB, patch)
2013-09-04 01:25 UTC, Jonathan Horowitz
needs-work Details | Review
Changes to xvid plugin as of 0.10 API revision 2 (26.73 KB, patch)
2013-09-11 09:05 UTC, Jonathan Horowitz
none Details | Review
Revive xvid plugin (76.98 KB, patch)
2018-05-13 02:25 UTC, Jonathan Horowitz
none Details | Review
Revive xvid plugin revision 2 (77.19 KB, patch)
2018-05-13 02:35 UTC, Jonathan Horowitz
needs-work Details | Review

Description Jonathan Horowitz 2013-09-04 01:25:33 UTC
Created attachment 254028 [details] [review]
Changes to xvid plugin as of 0.10 API

Get the xvid plugin working with the 1.0 API.
Comment 1 Jonathan Horowitz 2013-09-04 01:27:06 UTC
The attachment gets the plugin to compile but I'm not sure if the port was correct, as I only went with some porting documentation I found in git and the two versions' API docs. Can someone take a look and see if it was done correctly?
Comment 2 Sebastian Dröge (slomo) 2013-09-04 09:17:55 UTC
Review of attachment 254028 [details] [review]:

::: ext/xvid/gstxviddec.c
@@ +53,3 @@
             0x0000ff00) "; " RGB_24_32_STATIC_CAPS (32, 0x0000ff00, 0x00ff0000,
             0xff000000) "; " RGB_24_32_STATIC_CAPS (32, 0x000000ff, 0x0000ff00,
             0x00ff0000) "; " RGB_24_32_STATIC_CAPS (24, 0x0000ff, 0x00ff00,

These caps are now RGB, xRGB, ARGB, BGRx, etc. We don't use masks in the caps any longer

@@ +133,3 @@
   dec->sinkpad = gst_pad_new_from_static_template (&sink_template, "sink");
   gst_pad_set_chain_function (dec->sinkpad,
+      (GstPadChainFunction) gst_xviddec_chain);

The signature of the function has changed to contain the parent too, also this element should just be ported to the GstVideoDecoder base class

@@ +136,2 @@
   gst_pad_set_event_function (dec->sinkpad,
+      (GstPadEventFunction) gst_xviddec_handle_sink_event);

Same

@@ +212,2 @@
     default:
+      ret = gst_pad_push_event (dec->srcpad, event);

gst_pad_event_default()

::: ext/xvid/gstxvidenc.c
@@ +45,3 @@
             0x0000ff00) "; " RGB_24_32_STATIC_CAPS (32, 0x0000ff00, 0x00ff0000,
             0xff000000) "; " RGB_24_32_STATIC_CAPS (32, 0x000000ff, 0x0000ff00,
             0x00ff0000) "; " RGB_24_32_STATIC_CAPS (24, 0x0000ff, 0x00ff00,

All comments from the decoder apply to the encoder too
Comment 3 Jonathan Horowitz 2013-09-11 09:05:29 UTC
Created attachment 254654 [details] [review]
Changes to xvid plugin as of 0.10 API revision 2
Comment 4 Edward Hervey 2018-05-12 08:17:25 UTC
upstream xvid is still maintained (came as a surprise).

Jonathan, want to try rebasing this against current Gstreamer ?
Comment 5 Jonathan Horowitz 2018-05-13 02:25:04 UTC
Created attachment 371971 [details] [review]
Revive xvid plugin

Wow, talk about a necro bump :)

Here is a completely untested patch that does what you ask (I think). Perhaps you could take a look and see if anything is obviously wrong with it; I do not have the time to test at the moment :/
Comment 6 Jonathan Horowitz 2018-05-13 02:35:02 UTC
Created attachment 371972 [details] [review]
Revive xvid plugin revision 2

Missed a couple changes there ;)
Comment 7 Edward Hervey 2018-05-16 16:57:33 UTC
Review of attachment 371972 [details] [review]:

Only went through the decoder

::: ext/xvid/gstxviddec.c
@@ +120,3 @@
+
+/* flush xvid encoder buffers caused by bframe usage;
+   disabled for now... */

is this because the xvid library can't support it ?

@@ +202,3 @@
+  }
+
+  /* and pass along all */

you don't need to implement ::parse() if you just pass along everything

@@ +297,3 @@
+      info->width, info->height, dec->input_state);
+
+  /* FIXME : Do we still need to set fps/par now that we pass the reference input stream ? */

no

@@ +410,3 @@
+    /* bframes can cause a delay in frames being returned
+       non keyframe timestamps can permute a bit between
+       encode and display order, but should match for keyframes */

all this ts handling should be needed. Doesn't xvid have a way to provide an identifier of some kind on input and then provide you that identifier on the decoded frame ?

 That would allow you to match the proper data on the output buffer.
Comment 8 GStreamer system administrator 2018-11-03 13:17:41 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/108.