[gst-devel] How to submit a new plugin (XVID)

[Gianluca Insolvibile]

Hi,

Ronald Bultje wrote:

 > Simply make a patch against current CVS or just make a tarball of the
 > files that are to be added. Include a list of dependencies (in your
 > case: xvid), s we can change configure.ac and some Makefiles.
The files to be added are gstxviddec.[ch] and the only dependency is
libxvidcore. I'm keeping the current stable version available at the address I
mentioned before (I just uploaded a fixed version).


 > Some questions then:
 > * it seesm to be using I420 as decoding colorspace. Is this because this
 > is the default for decoding or is the XviD package doing a colorspace
 > conversion internally?
As far as I have seen, xvid always performs at least a minimal colorspace
conversion. The internal colorspace is of course some form of YUV, but I am no
colorspace expert, so what I did was to choose I420 since I guessed it is the
one requiring less calculations. I assume sdlvideosink has to do YUV to RGB
conversion then. Am I missing a better way to do it?


 > * why are there width/height get/set properties?
Because the raw video stream contains that information, but the xvid library
does not provide access to it. So, either you get it from an upstream element
(that is the case with avidemux) or you have to provide it externally via
properties (e.g. if you read a raw video stream from disk). I planned to extend
xvid to extract width and height information, but the xvid guys told me they are
going to deal with it in the next release of the library. So those properties
should eventually go away, but at the moment they come very handy for testing.


 > * in your chain function, you seem to use a constant variable for
 > timestamps of the decoded buffers - I also see a queue of buffers... Why
 > don't you simply decode the buffer as it comes in and then use the
 > encoded frame's timestamp for the buffer?
Good point, that's the way I wanted it to be at first. But, again, the xvid
library does not provide access to timestamp information so I have to estimate
it by assuming a fixed interval between frames. Extracting timestamps is another
point I have on my wish list for the new xvid API...

Regarding the queue of buffers: I can't decode each buffer when it comes in,
because the decode function needs to have a whole frame at a time. If I did not
use the queue, it could happen that an incomplete frame (being at the edge
between two successive buffers) would get to the decoder and cause an error. In
other words, I need to prevent the library from getting incomplete frames.


 > Anyway, nice work! I'll do some testing and -if it works- integrate it
 > in gst-plugins.
Thanks. At the moment I tested it with the official DivX5 trailers available on
the net: xXx, Farscape, The Hunt and Kermit swamp years. Video decoding seems to 
be working fine. I also tried it with a native MPEG-4 video stream (produced 
using the ISO MPEG-4 reference software) but it segfaults in the library (seems 
like the video has some unsupported features enabled).

Finally, I have some A-V sync problems when trying to play audio, but I suspect
it has to do with my sloppy K6-II 400 Mhz notebook (and with the fixed frame
interval I am using).

At the moment I have this to-do list:
  - test more MPEG-4 bitstreams to see how XVID deals with them
  - wait for the new API of XVID and, possibly, patch it by adding the 
extraction of some more parameters (i.e. size, timestamps)
  - deal with buffer timestamping and possibly contribute to clock distribution
  in the gst pipeline (I have seen some distributed clock code around in gstreamer)
  - start working on an gst MPEG-4 file format source (it's basically a 
QuickTime demux)

Regards,
	Gianluca