[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 4)

[Michael Niedermayer]

On Thu, Feb 19, 2009 at 07:08:32PM +0100, Reimar D?ffinger wrote:
> On Thu, Feb 19, 2009 at 06:07:41PM +0100, Gwenole Beauchesne wrote:
> > On Thu, 19 Feb 2009, Reimar D?ffinger wrote:
> >
> >> On Thu, Feb 19, 2009 at 05:04:27PM +0100, Gwenole Beauchesne wrote:
> >>> I don't understand this argument. Actually, ::get_format is a pointer to
> >>> function and avcodec_default_get_format() is a function, so IIRC the test
> >>> should work. However, that would obviously have failed if ::get_format 
> >>> was
> >>> a pointer. i.e. sizeof(void *) != sizeof(void (*)(void));
> >>
> >> As I remember it, taking the address of the function in libavcodec will
> >> result a pointer to the actual code, whereas in an external program it
> >> will point to the start of the stub which on first call activates the
> >> dynamic loader.
> >
> > Then, there probably is a tool problem. I mean, if you build a shared lib, 
> > the address of the function in lavc is also the stub. libavcodec is 
> > probably not built correctly on that platform.
> 
> When you build a program against a Windows .dll, the compiler generates
> two things:
> 1) An import table where the linker will fill in the addresses of the dll's
> function after loading the binary
> 2) a stub/wrapper that consists of something this:
>    jmp         dword ptr [a.dll:test]
> 
> Taking the address of the function gives you the address of 2). There is
> of course the obvious question of why, but I don't know the details of
> that, though I suspect it might have something to do with binary
> compatibility.
> 
> > The comparison is valid or could you please tell me the chapter/verse in 
> > the normative reference saying otherwise? I will check tonight but I am 
> > pretty sure this has to work.
> 
> Fact is it does not work. Obviously I forgot to say "on Windows" a few
> times, but no matter how much it is wrong it still does not work on
> Windows (neither will it to my knowledge with -Bsymbolic).
> Yes, we might just ignore that, but in my view such inconsistent
> behaviour is enough to make such checks worse than no checking at all.
> You may of course disagree.

why dont you make default_get_format a macro?
it could in cases where its problematic evaluate to a global function pointer
or a function call returning a function pointer

same for the destruct stuff


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20090219/b795e08e/attachment.pgp>