Win32 binaries

[Timothy Vermeiren]

Hi,

I feel terrible for asking this, but I give up and am asking if it
would be possible to put win32 binaries in the download section. For
the last 4 days I have been trying to build it myself from the source
in VS2010. Every time I manage to fix a problem, however, tons of
others appear.

This is in no way your fault; this is purely due to my inexperience in
the field of compiling, coding, dependencies and everything. But I
really give up now, so this is why I'm asking if it's possible to put
the compiled win32 binaries somewhere... I realize I will not be able
to make them myself.

In case it would be relevant, anyway, here is the paste of the build
output I'm "achieving" (if you can call it that...) now: http://pastebin.com/xTcJxzxM

Cheers

[Manuel Raña]

Hi, don't know if is the best solution but you can get rid of most errors editing this file:

sources/thelib/src/protocols/liveflv/innetliveflvstream.cpp

And replace line 111 with:

info["audio"]["droppedPacketsCount"] = (uint64_t)0;

And line 114 with:

info["video"]["droppedPacketsCount"] = (uint64_t)0;

Try that and compile again

Hope it helps

2012/1/23 Timothy Vermeiren <tim...@gmail.com>

You received this message because you are subscribed to "C++ RTMP Server" mailing list.
To post to this group, send email to c-rtmp...@googlegroups.com
To unsubscribe from this group, send email to
c-rtmp-serve...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/c-rtmp-server?hl=en

[Giusanny]

it should work with 717 version

The only version I compiled fine without code editing is the 690 :) in my winxp 32 bit virtual machine...I saw you were trying to compile the 717

it was the first time with c++ and vs2010, i'm not better than you :)

[Giusanny]

with 729 (last form repository) i have 2 errors after the Manuel code editing...

defaultprotocolfactory.obj : error LNK2019: riferimento al simbolo esterno "public: __thiscall NATTraversalProtocol::NATTraversalProtocol(void)" (??0NATTraversalProtocol@@QAE@XZ) non risolto nella funzione "public: virtual class BaseProtocol * __thiscall DefaultProtocolFactory::SpawnProtocol(unsigned __int64,class Variant &)" (?SpawnProtocol@DefaultProtocolFactory@@UAEPAVBaseProtocol@@_KAAVVariant@@@Z)

outboundconnectivity.obj : error LNK2019: riferimento al simbolo esterno "public: void __thiscall NATTraversalProtocol::SetOutboundAddress(struct sockaddr_in *)" (?SetOutboundAddress@NATTraversalProtocol@@QAEXPAUsockaddr_in@@@Z) non risolto nella funzione "public: bool __thiscall OutboundConnectivity::RegisterUDPVideoClient(unsigned long,struct sockaddr_in &,struct sockaddr_in &)" (?RegisterUDPVideoClient@OutboundConnectivity@@QAE_NKAAUsockaddr_in@@0@Z)

[Manuel Raña]

Hi, Giusanny, i think you can fix this by including

this header:

sources/thelib/include/protocols/rtp/nattraversalprotocol.h 

and this source:

sources/thelib/src/protocols/rtp/nattraversalprotocol.cpp 

In your proyect

[C++ RTMP Server]

Hey guys,

As far as I see, you are walking towards completion very fast and reliable. As far as I see, is not that hard to bring win build up to floating line :)
So, after you finish the changes, you may want to give me the patch so I can commit the changes into the repo so everybody can benefit

Best regards,
Andrei

[Manuel Raña]

Yes, i'll do a fresh update this evening and try to make a diff for you to patch

If everything goes as expected

[Manuel Raña]

Hi Andrei, the patch is ready for you to review

Where do you want me to send you the patch?

contact evostream?

2012/1/24 Manuel Raña <in...@vengava.com>

[Manuel Raña]

Sent to evostream's contact email

[Giusanny]

Great it works! 729 version compiled

[Giusanny]

on winxp 32bit I have "The procedure entry point WSASendMsg could not be located in the dynamic link library WS2_32.dll" i didn't have this problem with version 690

[Giusanny]

I read in the group that is a windows problem, i just need it to work in windows just for testing.

Wich OS do you use to develop crtmp? and wich IDE? So i can take windows and throw it away :D

[Andriy]

only one rule... Not windows :)

[Vadim Kosarev]

Hi all!

I have made a patch for win32 network issues:

http://vad.pp.ru/rtmpd/patches/win32_network.diff

Here log message of this patch

(1) Add dumb WSASendMsg implementation to use it in WinXP/2k3;

(2) Skip Win32 error message boxes - simply exit server;

(3) Do not fail on set keep alive option to UDP socket;

(4) Set socket send/receive buffers of 128kb;

[Giuseppe Sannicandro]

great Vladim i have to test it..i use windows just for coding environment!

2012/1/25 Vadim Kosarev <vadim.a...@gmail.com>

You received this message because you are subscribed to "C++ RTMP Server" mailing list.

[C++ RTMP Server]

Great job! I will take a look at it and commit it ASAP!
However, I have one observation about WSASendMsg. I didn't look at the patch yet, but here it goes:

WSASendMsg is ***critical*** for the good functioning of the RTSP. WSASendMsg is used to send sparse buffers much like unix sendmsg().
A sparse buffer is actually a collection of memory regions each having a length. For example:

address 0x12340 - 56 bytes
address 0x88880 - 2 bytes
address 0x10000 - 30 bytes

That is an example of a sparse buffer. We need to send all of those buffer in the SAME UDP packet. Calling sendto() 3 times is NOT going to work because the RTP over UDP is packet aligned. Imagine that the UDP buffer I have to send is comprised of those 3 buffers all together. If you use sendto() 3 times, the player will see the packet of 56 bytes and it will consider the A/V packet as being complete. Needless to say, nothing will work :(

Also, you CAN'T send more than MTU bytes over a UDP packet. Theoretically, a UDP packet can not hold more than 65536-N bytes, where N are the bytes used by the ARP and IP layers from the stack (few tens). Another real world bottleneck is that the MTU. Even if you try to send 64000 bytes, that is not going to work either. Behind your back, the first router will chop the packet into multiple MTU size UDP packets, rendering your information useless for protocols like RTSP.

Fortunately, I already take care of the MTU problem and I'm never sending more than 1500 bytes per packet which is the standard MTU over LAN-connected internet connections. For ADSL based connections, that is even smaller (500-600 bytes)

Now you know why I dislike windows so much. sendmsg() was there for AGES in unix world, while the smart people at MSFT considered it useless for the past decade and only added WSASendMsg in later versions of windows (win vista I think...). That's embarrassing for them...

Also, there is yet another problem with UDP sockets. Believe it or not, I get a CONNRESET error on a UDP socket and that socket can't be used anymore. And, again, believe it or not, that is there from the win2k times. Here is a link with, again embarrassing for them, workaround (which doesn't work either, I still get that error!!!)

http://support.microsoft.com/kb/263823

That is absolutely hilarious...

Best regards,
Andrei

[Vadim Kosarev]

Hello Andrei!

1) In my implementation of WSASendMsg all input buffers are concatenated in one temporary buffer which sendto() socket. Is there any performance loss against real WSASendMsg? Maybe network driver anyway concatenates multiple buffers in-memory before sending packet?

In the patch real WSASendMsg procedure is used when possible (there is a startup-time detection of WSASendMsg in WinSock dll).

2) About MTU. Here is my experience: MTU of ethernet is 1472 bytes in payload of UDP packets (i.e. 1480 in payload of IP packets, 1500 in payload of ethernet frames, 1514 total bytes of network packet). You should not send()/sendto() more than 1472 bytes as payload of one UDP packet (otherwise the packet will be fragmented by IP-level protocol driver). These numbers was proved in practice by running ping and wireshark on windows.

3) About CONNRESET on Win32. I just ignore WSAECONNRESET errors in my UDP applications. I simply mark in my tables the client reported by this recvfrom() as unreachable (to prevent further sendto()-s to him till client reconnects himself) then continue main send/recv loop. UDP socket still alive and fully operable with clients other than caused the CONNRESET. Small note: my UDP socket is not connect()-ed, just bind(), setsockopt(...) then select(), sendto(), recvfrom() in main loop.

Workaround from http://support.microsoft.com/kb/263823 is not used. Anyway - this workaround does not remove CONNRESET errors - instead it is returns old behavior of select() on socket with such error. Error CONNRESET after recv()/recvfrom() means one of previous send()/sendto() emits a packet to closed port/unavailable IP/unavailable network. Other ports/IPs/networks still can be reached from this socket.

By the way: WIN32-code in sources/common/src/utils/buffering/iobuffer.cpp uses unknown SOCKERROR_RECV_CONN_RESET symbol.

My fix: http://vad.pp.ru/rtmpd/patches/fix-of-udp-connreset-win32.patch. Some additional UDP recv errors also ignored in the fix.

[Giusanny]

i wanted to to let you kow it works in win32 xp! great!

[Vadim Kosarev]

Hello!

I know.

I'm working in WinXP and I have tested this patch.

Thanks for your feedback!