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?

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

Created attachment 254654 [details] [review]
Changes to xvid plugin as of 0.10 API revision 2

upstream xvid is still maintained (came as a surprise).

Jonathan, want to try rebasing this against current Gstreamer ?

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 :/

Created attachment 371972 [details] [review]
Revive xvid plugin revision 2

Missed a couple changes there ;)

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.

-- 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.