Bug#533546: No zoran support in mplayer

Reinhard Tartler siretart at tauware.de
Fri Jun 19 05:28:30 UTC 2009


Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> On Thu, Jun 18, 2009 at 07:57:35PM +0200, Reinhard Tartler wrote:
>> TBH, I'm pretty puzzled why the configure script does that check this
>> way.
>
> Simple: vf_zrmjpeg.c uses libavcodec internals which means:
> normally installed programs lack a needed header (mjpegenc.h,
> maybe others), it defines HAVE_AV_CONFIG_H which means MPlayer's
> config.h is used by the FFmpeg headers (which _might_ cause issues
> if it differs in the wrong way, though I can't think of an actual
> case where it would be a problem) and lastly it is a feature that
> might break with any kind of change in FFmpeg, even when there
> was no version bump.

Oh, I see. Thank you very much for this (excellent) explanation.

> Simply forcing it via --enable-zr might work, but I recommend that

Not straight away, the configure script has an explicit check to fail if
libavcodec_a is not built. I need to disable that check, similar to how
Nikolay did in his latest followup.

> you avoid giving the impression that you will certainly support it
> for future versions, too - given how rare the hardware is and how
> hackish the current support is I think that would be more than
> you can promise.

That sounds very reasonable. With that explanation, I'm pretty confident
that we can enable that encoder ATM, because the system libavcodec and
mplayer's copy are (currently) in sync: Both ship ffmpeg 0.5, exactly
for reasons like this.

I will add an appropriate note to the patch for configure that
--enable-zoran must to be reconsidered as soon as the system libavcodec
version no longer matches with mplayer's internal copy.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4





More information about the pkg-multimedia-maintainers mailing list