[Ffmpeg-devel] [PATCH] MingW RTSP support

Rich Felker dalias
Mon Apr 3 01:31:25 CEST 2006


On Sun, Apr 02, 2006 at 09:58:10AM -0500, Michael A. Kohn wrote:
> Personally, I don't think the change from..
> 
[snip]
> 
> .. is that much more gross, but I see your point.. if you let one thing
> slide, other gross things get in..
> 
> I mean.. i know you guys don't care much for the OS that MingW programs
> run on.. but i think these changes are pretty small in order to expand the
> audience of ffmpeg.. lots of people could benifit from it..
> 
> As far as modifying mingw itself... adding in the missing include files in
> the mingw directory... I would vote against that just because I'd be
> willing to bet most people who would compile ffmpeg on the MingW OS's
> would end up getting compiler errors while trying to build it and probably
> just start putting bug reports on these lists.. I'd bet 99% of them would
> never figure to add the missing include files into MingW..

No one said the files have to go in the mingw system include dir.
Putting them in . is just as good as long as . is in the library path.

> Maybe another alternative would be to just include a patch file in the
> source tree that gets automatically patched in when a user configures
> ffmpeg for MingW?
> 
> btw.. speaking of gross #defines.. these three lines appear at the top of
> tcp.c..
> 
> #if defined(__BEOS__) || defined(__INNOTEK_LIBC__)
> typedef int socklen_t;
> #endif
> 
> Shouldn't these three lines be on os_support.h?  I almost moved them
> there, but I wasn't sure if the BEOS build would break if I did.

Yes. Somehow BeOS lusers get away with this stuff because their OS
isn't considered as "lame" as windows by most developers, but I don't
distinguish. One broken, standards-violating, proprietary OS is as bad
as another..

Rich





More information about the ffmpeg-devel mailing list