[FFmpeg-devel] XVMC Deathmatch

Michael Niedermayer michaelni
Sun Feb 15 03:17:41 CET 2009


On Sun, Feb 15, 2009 at 03:44:20AM +0200, Ivan Kalvachev wrote:
> On 2/15/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sun, Feb 15, 2009 at 02:34:59AM +0200, Ivan Kalvachev wrote:
> >> On 2/15/09, Diego Biurrun <diego at biurrun.de> wrote:
> >> > On Sun, Feb 15, 2009 at 01:01:36AM +0100, Diego Biurrun wrote:
> >> >> On Sun, Feb 15, 2009 at 01:56:49AM +0200, Ivan Kalvachev wrote:
> >> >> > On 2/15/09, Diego Biurrun <diego at biurrun.de> wrote:
> >> >> > > On Sun, Feb 15, 2009 at 12:29:18AM +0100, Michael Niedermayer
> >> >> > > wrote:
> >> >> > >> On Sat, Feb 14, 2009 at 11:40:35PM +0100, Diego Biurrun wrote:
> >> >> > >> > On Sat, Feb 14, 2009 at 11:30:02PM +0100, Michael Niedermayer
> >> >> > >> > wrote:
> >> >> > >> > > On Sat, Feb 14, 2009 at 10:38:39PM +0100, Diego Biurrun wrote:
> >> >> > >> > > > On Sat, Feb 14, 2009 at 04:53:01PM +0100, Michael
> >> >> > >> > > > Niedermayer
> >> >> > >> > > > wrote:
> >> >> > >> > > > >
> >> >> > >> > > > > >    //these are not changed by the decoder!
> >> >> > >> > > > > >    int  magic;
> >> >> > >> > > > >
> >> >> > >> > > > > 3 points
> >> >> > >> > > > > find and get rid of or rename fields to "ununsed123" all
> >> >> > >> > > > > unused
> >> >> > >> > > > > fields in this
> >> >> > >> > > > > struct, dont break ABI!
> >> >> > >> > > >
> >> >> > >> > > > All fields are used either in FFmpeg or MPlayer.
> >> >> > >> > > >
> >> >> > >> > > > The following are unused in FFmpeg:
> >> >> > >> > > >
> >> >> > >> > > >   int             mc_type;
> >> >> > >> > > >   int             chroma_format;
> >> >> > >> > > >   unsigned int    display_flags;
> >> >> > >> > > >   int             state;
> >> >> > >> > > >   void*           p_osd_target_surface_render;
> >> >> > >> > > >
> >> >> > >> > > > But they are all used in libvo/vo_xvmc.c in MPlayer as can
> >> >> > >> > > > be
> >> >> > >> > > > seen
> >> >> > >> > > > by
> >> >> > >> > > > trying to compile against an xvmc.h without those fields:
> >> >> > >> > > >
> >> >> > >> > > > libvo/vo_xvmc.c: In function 'xvmc_draw_image':
> >> >> > >> > > > libvo/vo_xvmc.c:378: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'state'
> >> >> > >> > > > libvo/vo_xvmc.c: In function 'config':
> >> >> > >> > > > libvo/vo_xvmc.c:536: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'mc_type'
> >> >> > >> > > > libvo/vo_xvmc.c:538: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'chroma_format'
> >> >> > >> > > > libvo/vo_xvmc.c: In function 'draw_osd':
> >> >> > >> > > > libvo/vo_xvmc.c:899: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'display_flags'
> >> >> > >> > > > libvo/vo_xvmc.c:899: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'display_flags'
> >> >> > >> > > > libvo/vo_xvmc.c:902: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'state'
> >> >> > >> > > > libvo/vo_xvmc.c:903: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'state'
> >> >> > >> > > > libvo/vo_xvmc.c:904: error: 'struct xvmc_render_state' has
> >> >> > >> > > > no
> >> >> > >> > > > member
> >> >> > >> > > > named 'p_osd_target_surface_render'
> >> >> > >> > > > [...]
> >> >> > >> > > >
> >> >> > >> > > > Does research give points? :)
> >> >> > >> > >
> >> >> > >> > > no, you have to remove or rename these fields to unused* to
> >> >> > >> > > get
> >> >> > >> > > the
> >> >> > >> > > points.
> >> >> > >> >
> >> >> > >> > Well, I did do
> >> >> > >> >
> >> >> > >> >    int             mc_type;
> >> >> > >> >
> >> >> > >> > -->
> >> >> > >> >
> >> >> > >> >    int             unused1;
> >> >> > >> >
> >> >> > >> > and FFmpeg compiles fine afterwards, but when I put that xvmc.h
> >> >> > >> > in
> >> >> > >> > my
> >> >> > >> > MPlayer tree, I get the above compilation failure.
> >> >> > >> >
> >> >> > >> > Thus my conclusion is that the field is not, as you claim,
> >> >> > >> > unused.
> >> >> > >> > Am I missing something?
> >> >> > >> >
> >> >> > >> > > am i allowed to give tips on how to solve such things?
> >> >> > >> >
> >> >> > >> > This will likely result in more fixes :)
> >> >> > >>
> >> >> > >> well
> >> >> > >> first as was said the header was not public thus no rename in the
> >> >> > >> header
> >> >> > >> really could break an external APP, removial of a field of course
> >> >> > >> could
> >> >> > >> so renaming these to unused123 and placing them under #if
> >> >> > >> no_major_bump_yet
> >> >> > >> should not break anything (in theory)
> >> >> > >
> >> >> > > I had all the fields I mentioned above under
> >> >> > >
> >> >> > > #if LIBAVCODEC_VERSION_MAJOR < 53
> >> >> > >
> >> >> > >> yes it means mplayer has to be updated before the next major bump
> >> >> > >> and
> >> >> > >> before it could use our installed header instead of its private
> >> >> > >> copy
> >> >> > >>
> >> >> > >> but thats mplayers problem to say it harshly ...
> >> >> > >
> >> >> > > Well...
> >> >> > > Ivan designed this incestuously.  It's kind of hard to tell if this
> >> >> > > is
> >> >> > > a
> >> >> > > public or a private header...
> >> >> >
> >> >> > Well, don't tell me I didn't had reasons to hold your
> >> >> > plans on making it public header.
> >> >>
> >> >> You held that plan back for many years.  Without this deathmatch, you
> >> >> would not have made those changes to MPlayer.
> >> >>
> >> >> > > I suggest that we assume it is becoming a public header just now
> >> >> > > and
> >> >> > > thus
> >> >> > > now that Ivan updated MPlayer to not use them anymore, the
> >> >> > > following
> >> >> > > two
> >> >> > > fields could be safely be removed:
> >> >> > >
> >> >> > >    int mc_type;
> >> >> > >    int chroma_format;
> >> >> > >
> >> >> > > OK to remove them?
> >> >> >
> >> >> > You were the one who insisted on installing it.
> >> >> > Deal with the consequences.
> >> >>
> >> >> I take that as a "I don't care", which I will now interpret to mean I
> >> >> have a free ticket to go ahead.
> >> >
> >> > Note to Michael: I know this breaks ABI and API.  I'm operating under
> >> > the
> >> > assumption that the API is still in flux and the only user is MPlayer,
> >> > which has already been updated.
> >> >
> >> > So don't go subtracting points from me :)
> >>
> >> Michael,
> >> Is breaking ABI OK for you.
> >> I can make some general changes if this is so!
> >
> > i dont give a damn about the lavc XVMC ABI, if it can be improved by
> > breaking
> > ABI ...
> > just think about what you will tell the distro maintainers when their
> > lavc suddenly starts acting up with mplayer and xvmc ... with some versions
> > being combined ... maybe one should tell them so that they can take some
> > precautions
> 
> AFAIK
> you can't use xvmc with shared libavcodecs,
> unless you do really durty tricks.

the mplayer in debian has a dependancy for
libavcodec51 and libxvmc1, iam of course not claiming that it works
but its in the depends and i suspect all the depends are shared libs

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090215/7039a907/attachment.pgp>



More information about the ffmpeg-devel mailing list