[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 4)
Thu Feb 19 19:13:45 CET 2009
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
> > 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel