Re: [xine-devel] divx4 decoder plugin patch

[Harm v. d. H. <ha...@et...>]

On Sun, Oct 07, 2001 at 08:10:34PM +0200, Guenter Bartsch wrote:
 
> sorry, took some time until I checked this one out (and there are more
> patches still pending in my inbox 8-)) but I've commited it to cvs now.

Great!

> 
> A few remarks:
> 
> - once again I had to change c++ style comments to c-style comments ;>

Didn't think of that. BTW, there are still 3 left, in lines 175-195.
(also, can you answer my "// Can I do this?" question on line 195?)

> - decore((unsigned long)this, DEC_OPT_RELEASE, 0, 0);
>   segfaults on my machine so I commented it out, probably leading to a
>   memory leak

Actually, I had noticed that avifile's divx4 plugin has it commented
out as well. It worked for me, so I left it on. Since the avifile author
is also a major contributor to the divx4 codec, we can assume it's 
a known problem.

> - the plugin priority is configurable so people can "disable" the plugin
>   in their .xinerc, it's enabled by default

In an off-list discussion with Miguel Freitas, we came to the conclusion
that it might be preferable to use dlopen to get the divxdecore library
instead of linking against it at compile time. Possible GPL issues aside,
this would make life a lot easier for binary packagers as it will allow
them to include the plugin within the main xine-lib package without
dependency problems. 

I don't completely know how xine works, but I imagine that in the absence
of the binary divx4 library, the init_video_decoder_plugin function
can return a "Don't use me!" code, or failing that, divx4_can_handle
can return no capabilities, allowing for a graceful fall-back to the ffmpeg 
plugin. With a printf statement we can inform people what's happening,
and where to get a binary divx4 package for their platform.

I'm willing to create a patch for that, but please tell me if there's
some configure stuff I need to be aware of. (should I use HAVE_DLOPEN
or something? Is there another place in xine where something like this
is done?).

Finally, there's some excess stuff in the divx4 autoconf macro in
m4/_xine.m4; on lines 8-9, the DIVX4_LIBS stuff is not needed (hastily
copied from avifile's configure.in), so I guess neither are the ac_save_LIBS
around it. 

> 
> thanks for your work!

Just had an itch to scratch ;-)

Harm