[Xvid-devel] Patch for XVID MPEG-4 DirectShow/MediaFoundation filter

[Edouard Gomez]

"Jerker Bäck" <jerker.back at gmail.com> wrote:

>Hi Michael,
>
>> I don't disagree with you that Unicode should be faster than ANSI for
>> Windows NT onwards. But the difference in speed will be completely
>> unnoticeable for Xvid, so this shouldn't be much of a consideration
>> here.
>Agree, for the Xvid dshow source this discussion is entirely academic.
>
>> So could you modify your patch so that the code can be compiled with
>> both MBCS and Unicode char set?
>Sure. As suspected, the new patch require less changes. Using the
>winnt.h
>TEXT macro to avoid dependency of tchar.h. This goes also well in style
>with
>SDK DirectShow source. There are 2 cases where explicit use of A
>variant
>functions are required.
>
>I added a patch for CXvidDecoder::ar_x, ar_y (int => UINT) so that the
>types
>corresponds to VIDEOINFOHEADER2 and Media Foundation. (Compiler warning
>cleanup).
>

>New patch:
>http://pastebin.com/xXPrSuMP


I disapprove part of the second patch.

xvid.h file exposes just an api whose code is implemented in pure c files. It should be no problem for these files to be compiled using other calling conventions. If need be for functions to be marked using an explicit calling convention, these should be the assembly functions, marked as cdecl. This would definitely consolidate xvid source code builds against different calling convention usage.

secondly, your patch is wrong in regard to the use of declspec (dllexport). If one uses the xvid.h file for using the xvid dll, the macro you introduce should be declspec (dllimport). So either your patch is incomplete or you rely on some specific compiler/linker behavior declaring missing symbols at link time as declspec (dllimport) when presented some archive with their import symbol variant.

It also doesn't cope with possible cases such as a static windows lib.

Sometimes it's simpler to just not deal with all the cases because they make header files unnecessary complicated. And in the end, with new platforms appearing, they often aren't more robust but just more difficult to maintain.

I'd concentrate the efforts on making sure xvid sources compile fine whatever the user compiling it might do. mark the assembly code as cdecl and don't bother with the header changes, let the developers deal with that, they should know what they're
 doing if they mess with the calling conventions or use a dll build.


-- 
Edouard Gomez