[Ffmpeg-devel] FFMPEG RTSP for Windows

[Michael A. Kohn]

Rich Felker wrote:

> This code does not give me much confidence in your knowledge of the C
> language. The above can be done without useless temp vars:

> WSADATA dummy;
> if (WSAStartup(MAKEWORD(1,1), &dummy)) return 1;

> and I assume MAKEWORD(1,1) is just 0x0101..

Thank you for insulting me... I actually got that code from the MSDN
documentation... (other than the Win32isStupid part.. I find having to
initialize the winsock library every time it's used annoying so I use
that variable name).. and yes they use MAKEWORD.. if I had to guess why,
it probably has to do with endianess (at one time they had PPC and MIPS
versions of Windows NT).. anyway if you have a problem  with that please
take it up with them...

> This is wrong. It will break cygwin.

> +#ifndef CONFIG_WIN32

I didn't know.. this is my first time working on ffmpeg code I assumed
it's better to use #ifdefs for WIN32 instead of MINGW incase someone was
using microsoft's or intel's compiler...

>          sleep(1);
> +#else
> +        Sleep(1000);

> This is wrong. I doubt win32 is missing sleep, but if it is, you need
> to make an emulation of sleep() using Sleep in a separate
> win32-dependent file.

This is not wrong... try compiling this in Visual C++:

main() { sleep(1); }

it doesn't have sleep.. when I compiled libavformat as it was it gave a
warning on sleep(1); .. and broke other places so I assumed mingw was
missing sleep() also and changed it to Win32 style:

VOID Sleep(DWORD dwMilliseconds);   as MSDN writes it.

I changed it back to sleep(1); in libavformat and even tho it does
give the warning, it does compile.. BUT.. it does NOT work the same...

compile this code on mingw and on linux:

main() { sleep(500); }

on Windows this will return in 500ms.. on Linux this will turn in
500 seconds...

> +#undef rand
> +#define random rand
> random is not allowed in libav*. If it's used this is a bug and must
> be corrected.

notice above these lines i wrote:

> +/* I'm sure the next two lines are evil in some way, but I'm not sure
> +   how else to do that right now */

the way it is right now does not compile.  i was hoping someone could have
been nice enough to explain why instead of you coming around and insulting
me...  i'm sorry if what i did is so horrible, but that was the only way
that was going to compile..

> +#ifdef CONFIG_WIN32
> +        getsockopt (fd, SOL_SOCKET, SO_ERROR, (char FAR *)&ret, (int
FAR
> *)&optlen);

> The use of the FAR pointer qualifier is ABSOLUTELY WRONG!
> This is win16 code!!

According to MSDN Libaray that came with the Visual Studio I use when I
have to do VC++ things:

int getsockopt(
  SOCKET s,
  int level,
  int optname,
  char FAR *optval,
  int FAR *optlen
);

and at the bottom of the page it says to link with Ws2_32.lib.  I'm
assuming this is a 32 bit libarary since it has 32 at the end of it.  I
got a compile warning there when I didn't write the code as I did so I
wrote it exactly the way it is in the MSDN stuff.  Compile warning went
away so I left it.  Once again, complain to Microsoft if you don't like
that (altho by doing a web search it looks like they changed their docs
now anyway).

> -#ifdef __BEOS__
> +#if defined(__BEOS__) || defined(CONFIG_WIN32)
>              len = recv(s->fd, buf, size, 0);
>  #else
>              len = read(s->fd, buf, size);

> IMO it's safe to use recv always.

that's fine..  however the code as it was originally written was using
recv() only for BEOS and read() otherwise.  I did not choose to use read()
on Unix so don't blame me for that.  And same for send.

> Using shutdown() instead of close() or closesocket() should be safe on
> both unix and windows.

once again... the original code was written close() so I chose to stick
with the way the code was originally written...  since close() (just like
read()/write()) doesn't work on Winsock since socket handles are different
than file handles on Windows, so I use the equivlant Windows function
which is closesocket().  If you have a problem with it, please contact the
original author of those functions instead of blaming me.