RTMP TO RTMFP PUBLISHER

765 views
Skip to first unread message

Gerd Hilgemann

unread,
Oct 8, 2013, 9:06:28 AM10/8/13
to openrtmf...@googlegroups.com
as far as i understand, this VOD RTMP to RTMFP adobe example is currently not possible in culumus:

so, i´m asking if some other users need the RTMP to RTMFP feature as well and maybe we can collect some money to pay culumus-dev to include this feature?

i´m able to start with some donating. i know that it is untypical to talk about development cost in forum, what you think?

maybe i can bring a little life back to this project..

KR
gary



Alexander Polozhevets

unread,
Oct 9, 2013, 3:55:12 PM10/9/13
to openrtmf...@googlegroups.com
+1 and +my money

Gerd Hilgemann

unread,
Oct 10, 2013, 8:45:36 AM10/10/13
to openrtmf...@googlegroups.com
hi,

the question is how expensive it will be.

as far as i have study the culumus code its a nice piece of work, really.

I think is realistic to implement a RTMP Protocol handler in 2 weeks. 1 week, eight hours per day for hacking, another week (with a lot of beta-tester) for bug fixing.

C / C++ developers are working on a rate between 30-70 USD per hour. Means 2 weeks, 14 days * 30-70USD is a range of 3000 USD - 8000 USD for the RTMP protocol implementation.

Please note, that GPL-Software doenst mean free development :)

The second thing that you have to know is that a developer must have time to develope it :)

I have to problem to donate this feature with 500 USD, what are you willing to donate?

I dont know if culumus-dev is reading this, but i will try to send him an email to this thread.

What do you think?

Gary




Gerd Hilgemann

unread,
Oct 10, 2013, 8:49:51 AM10/10/13
to openrtmf...@googlegroups.com
One thing is the cost, another the technical implementation.

How is the RTMP publisher working?

Lets say you send an RTMP from an RTMP Encoder to the culumus incoming RTMP channel, and then act the server as a p2p publisher/Client to share the video,audio,data packets to the nearest peer, to a group of peers, and from that groups to the next->to-next->..and so on...

or is the server sending the RTMP packets over RTMFP to all connected peers in the right channel?

Maybe the second point makes not that much sense, cause you can do this also with RTMP, One to many over a RTMP Server.

Gary


Mathieu Poux

unread,
Oct 15, 2013, 10:56:48 AM10/15/13
to openrtmf...@googlegroups.com
Hi,

Yes, maybe this public forum is not the good place to speak about financial resource of GPL projects :-)
But nevermind, I take this opportunity to summarize the situation:

Currently I am working intensively (freely) for many months on MonaServer project like a complete replacement for Cumulus:

We have a first beta date for the end of november, with the following features
  • No more Poco dependencies (just OpenSSL and luajit)
  • Fully coded with C++11 and the new std revision to get a code really friendly to maintain.
  • Rewriting complete of socket code to work in a full async mode (programmation by events), preliminary tests versus Cumulus gives a 4-fold increase in performance.
  • Support of protocols RTMP, RTMPE, RTMFP, WebSocket (with JSON serialization), HTTP, and ICE (for WebRTC).
  • An exclusive RTMFP TURN mode :-) (when P2P fails, without using something else than RTMFP... it was already possible in coding it on client side (flash) and server side (LUA) but the code was often verbose to get a simple fallback server mode when P2P failed. With this feature it becomes fully automatic (when required).
  • Always as simple in the usage than Cumulus (no "protocol" reflexion on the server side, all is transparent for the LUA user, just you can check the protocol with the new parameter "protocol" of the client object:
function onConnection(client,...)
NOTE("Protocol of this client is "..client.protocol)
end
  • Allow to make speaking many clients between them without protocol reflexion. If client1 is RTMP and client2 is WebSocket, they can speak together (transparent bridge between protocols):
-- client1 (RTMP) push data to client2 (WebSocket)
client2.writer:writeMessage("hi client 2, I am client 1")

VOD was not expected for this first beta version, but we can speak about it. I hope also to add quickly WebRTC complete support in Mona.

Now, I have to admit that it's very difficult to progress in GPL world without financial resource (my alone live resourcing :-(). I firmly believe that open source development is the best choice to get excelent user/developper experience.

So a quick call to investors who could help us to release our professional and open source developement of Mona

Thanks for your interests.

pablo platt

unread,
Feb 4, 2014, 6:44:27 AM2/4/14
to openrtmf...@googlegroups.com
Any news about MonaServer?
This project sounds exciting.


--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes OpenRTMFP Cumulus.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse openrtmfp-cumu...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .

Mathieu Poux

unread,
Feb 4, 2014, 8:07:43 AM2/4/14
to openrtmfp-cumulus
Hi, we have brounght the project much further than expected, it's so exciting and should give a new awesome server solution in the exciting panel.
but it has delayed a little the project (and few health problem have not help... but recuperation is complete).
We work hard on currently, again patience (we are testing it deeper on posix system, and the more difficult will be to document what we have done ;-)).


2014-02-04 pablo platt <pablo...@gmail.com>:

pablo platt

unread,
Feb 4, 2014, 8:45:21 AM2/4/14
to openrtmf...@googlegroups.com
Can you share what is currently possible?
Does the server support RTMP, RTMFP and WebRTC?
Is there audio mixing support or do you use a separate stream per user?
Is there transcoding support between speex and opus for example?
Is there video support?
Is there a mailing list?

Is it stable enough to start experimenting with?

Thanks
Reply all
Reply to author
Forward
0 new messages