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

[Matias N. Goldberg]

> this extensively. However, this often goes bad against code
> that are not
> aware of such functionality (e.g. UNIX code).

Such as wxWidgets (just to name the first big one coming to my mind)?

By the way, DirectShow filter is only available on Windows platforms.

Needs may be different, and XviD's reach is very very very broad, so users should be able to select whether they want to compile with.

Still, making the xvidcore both utf-16 utf-8 and ansi compatible is a good thing.

IMPORTANT:
The information contained in this email may be commercially sensitive and/or legally privileged.
It is intended solely for the person(s) to whom it is addressed. If the reader of this message is not the intended recipient, you are on notice of its status and hereby notified that your access is unauthorized, and any review,
dissemination, distribution, disclose or copying of this message including any attachments is strictly prohibited.
Please notify the sender immediately by reply e-mail and then delete this message from your system.


--- El lun 13-jun-11, Jerker Bäck <jerker.back at gmail.com> escribió:

> De: Jerker Bäck <jerker.back at gmail.com>
> Asunto: Re: [Xvid-devel] Patch for XVID MPEG-4 DirectShow/MediaFoundation filter
> Para: xvid-devel at xvid.org
> Fecha: lunes, 13 de junio de 2011, 12:58
> Hi Michael,
> 
> Very well, of course one could use the _T() or TEXT() macro
> for every string
> to enable the UNICODE define functionality. Hardcore
> ATL/WTL/MFC'ers use
> this extensively. However, this often goes bad against code
> that are not
> aware of such functionality (e.g. UNIX code). In the Xvid
> code there is
> actually an example of the need to explicit use ASCII
> characters (config.c
> 145). All COM code needs wide strings. There is little
> point in using ANSI
> strings in Shell/COM source since they must all be
> translated and eventually
> use the wide functions anyway. 
> 
> So if you prefer to use a mix of ASCII, wide and
> UNICODE-aware strings, then
> my patch will not do. I just think it would be clearer,
> more safe and more
> consistent to decide the type at code level and not let
> the
> compiler/pre-processor decide.
> 
> Cheers
> Jerker
> 
> 
> _______________________________________________
> Xvid-devel mailing list
> Xvid-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>