rtmpt slow?

[Daniel Ly]

Hello Andrei and others

I just started working with crtmpserver today (I have some Red5 experience). I tested both the trunk version 666 and the stable version 575. I compiled them on an Ubuntu Natty machine in a 32-bit VirtualBox on an old Mac Mini. I tested the avatar.flv from the Red5 project and the JWP-Player with the wizard, both from OS X and Windows. rtmp works fine, but rtmpt seems to be a bit slow. There are short pauses with the spinning wheel every few seconds.

On the server network activity has spikes just before the end of the pauses. CPU load is lower than 0.1. On the host Mac Mini the Virtual Box process is at 15% CPU.

I wonder if there are known issues with rtmpt?

Could you give hints? This would be much appreciated.

[C++ RTMP Server]

Hi,

If you search the mailing list, you will see that RTMPT doesn't support VOD for now. And to be perfectly honest with you, I don't think it will ever do.
The main reason is that RTMP becomes absolutely useless inside this particular protocol stack (TCP-HTTP-RTMP) when you deal with files.
If you can do HTTP on files, why bother inserting RTMP? Just download the file and play it, right? RTMPT makes perfect sense for live streaming when parties are behind firewalls.

Cheers,
Andrei

> 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

[Daniel Ly]

Thanks Andrei, you are right, rtmpt does not make sense here.

I am evaluating crtmpserver for an use-case for sign-language users. Secure video streaming is needed (with secure I mean through an encrypted channel and only available after a login), because the messages are confidential. Also secure video recording is needed.

So, I would try to split the task in two parts:

- https pseudostreaming (for example with mod_flvx on Apache)

- rtmps video recording (with crtmpserver)

Does this make sense?

Daniel

[C++ RTMP Server]

Yes, that makes perfect sense. RTMPS is supported by crtmpserver. There is one major thing you should be aware of: it won't work as expected if you don't have valid certificate.

1. Invalid certificate: RTMPS == TCP-SSL-HTTP-RTMP
2. Valid certificate: RTMPS == TCP-SSL-RTMP

You MUST make use of 2nd scenario. For this, you need valid certificate signed by a signing authority and you MUST connect to the CN inside the certificate. Example: certificate issued for www.example.com (CN)

If you connect using: rtmps://10.11.12.13/live it won't work even if www.example.com is 10.11.12.13. It doesn't even work with rtmps://example.com/live. It MUST be the _exact_ CN: rtmps://www.example.com/live

Cheers,
Andrei
>
> Daniel

[Daniel Ly]

Thanks. SSL Certificates are a bit finnicky, of course, I understand.

[Daniel Ly]

On Tuesday, 4 October 2011 22:24:51 UTC+2, Eugen-Andrei Gavriloaie wrote:

1. Invalid certificate: RTMPS == TCP-SSL-HTTP-RTMP
2. Valid certificate: RTMPS == TCP-SSL-RTMP

I would like to disallow the first scenario. I overrode RegisterProtocol in the application's rtmpappprotocolhander.cpp:

void RTMPAppProtocolHandler::RegisterProtocol(BaseProtocol *pProtocol) {

BaseProtocol *p = pProtocol->GetFarEndpoint();

while (p != NULL) {

  if (p->GetType() == PT_INBOUND_HTTP) {

    FATAL("HTTP not allowed");

    return;

  }

  p = p->GetNearProtocol();

}

// All is well, register protocol.

BaseRTMPAppProtocolHandler::RegisterProtocol(pProtocol);

}

i.e. just don't register protocol if HTTP is somewhere in the stack. Good idea?

Behavior: Incrrect invoke id in basertmpapprotocolhander.cpp:617, then the client tries to reconnect: Unable to bind protocol in inboundhttp4rtmp.cpp, then the client tries to reconnect again: Invalid command: close in inboundhttp4rtmp.cpp.

Daniel

[C++ RTMP Server]

On Oct 11, 2011, at 4:45 PM, Daniel Ly wrote:

> On Tuesday, 4 October 2011 22:24:51 UTC+2, Eugen-Andrei Gavriloaie wrote:
>
> 1. Invalid certificate: RTMPS == TCP-SSL-HTTP-RTMP
> 2. Valid certificate: RTMPS == TCP-SSL-RTMP
>
> I would like to disallow the first scenario. I overrode RegisterProtocol in the application's rtmpappprotocolhander.cpp:
>
> void RTMPAppProtocolHandler::RegisterProtocol(BaseProtocol *pProtocol) {
> BaseProtocol *p = pProtocol->GetFarEndpoint();
> while (p != NULL) {
> if (p->GetType() == PT_INBOUND_HTTP) {
> FATAL("HTTP not allowed");
> return;
> }
> p = p->GetNearProtocol();
> }
> // All is well, register protocol.
> BaseRTMPAppProtocolHandler::RegisterProtocol(pProtocol);
> }
>
> i.e. just don't register protocol if HTTP is somewhere in the stack. Good idea?

Bad idea. Basically, the flash player expects HTTP traffic while the code delivers RTMP traffic

>
> Behavior: Incrrect invoke id in basertmpapprotocolhander.cpp:617, then the client tries to reconnect: Unable to bind protocol in inboundhttp4rtmp.cpp, then the client tries to reconnect again: Invalid command: close in inboundhttp4rtmp.cpp.
>
> Daniel
>

[Daniel Ly]

> i.e. just don't register protocol if HTTP is somewhere in the stack. Good idea?
Bad idea. Basically, the flash player expects HTTP traffic while the code delivers RTMP traffic

I understand.

protocol->GracefullyEnqueueForDelete(true);

Simply disconnect gracefully and the client gets NetConnection.Connect.Close. Better idea?