[FFmpeg-devel] Experimental MSVC port

Michael Niedermayer michaelni
Wed Mar 26 22:31:59 CET 2008


On Wed, Mar 26, 2008 at 09:13:50PM +0000, Ramiro Polla wrote:
> Hello,
> 
> Ole Andr? Vadla Ravn?s <oleavr <at> gmail.com> writes:
> > FWIW, for those of you interested in building a somewhat semi-recent ffmpeg,
> > r11247 (the revision currently suggested by GStreamer's gst-ffmpeg) with
> > MSVC15, I've ported and included it in OABuild:
> 
> Great, you've ruined what I had been planning to do for SOC this summer =)

agree, i was already scared that one of our few highly qualified students
would waste his time with such idiocy.
Clean patches surely are welcome and iam sure you could have done this but
you can do more usefull things then getting ffmpeg to compile under a
propriatary compiler.


> 
> Here is what I had written up this morning:
> Porting FFmpeg to MSVC is not *that* hard. But making a maintainable port is.
> The intention on this project is to clearly define what changes are needed
> to make FFmpeg work and pass regression tests with MSVC, and stop all
> the FUD around MSVC. Well, not all FUD, but most.
> The 2008 Express edition has been released and it still
> contains the most well-known problems:
> - Does not understand named initializers;
> - Does not understand variable-length arrays;
> - Does not understand the inline keyword (understands _inline though);
> - Does not allow explicit divisions by 0.0;
> - Does not understand compound litterals;
> - Does not understand AT&T style asm;
> - Probably others. I gathered this info from libavutil and some other
>   problems I remembered.
> Some of these changes shouldn't have any effect on gcc optimized code, like:
> instead of
> init_multbl2(dec_multbl[0], (int[4]){0xe, 0x9, 0xd, 0xb}, log8, alog8, 
> inv_sbox);
> something like
> const int someconst[4] = {0xe, 0x9, 0xd, 0xb};
> init_multbl2(dec_multbl[0], someconst, log8, alog8, inv_sbox);
>  
> Changes that either slow down C99 code or make the binary bigger are
> obviously not welcome. The same goes for changes that bloat the source code.
> (what people consider bloat varies wildly, but I hope we can reach a 
> consensus).
>  

> For asm, rewrite the inline into Intel-syntax under #ifdef.

Uhm, this will not work out ...
People will not change both sides of it, not add the msvc when writing gcc asm
and people wont be able to test both sides ...


[...]
> As for a mentor, we don't have one yet, but I suggest someone who has already
> done a complete port, like Steve Lhomme, the folks at ffdshow, etc. Whoever has
> already done this, please speak up.

You are too late, their alzheimer has progressed to the point were they cant
speak anymore.

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20080326/39c6b3d0/attachment.pgp>



More information about the ffmpeg-devel mailing list