RTMP Client Library
Chris Hansen
I have used FluorineFx as a client library in an application that I am
writing but I want to deploy my code on other platforms, and as
FluorineFx is managed .NET code, this is not the easiest thing
(Doesn't work on any recent version of mono). Looking at the source
code for crtmpd I noticed the OutBoundRTMPProtocol class in
particular. Could I use this or any of the rest of the rtmp folder in
the source as a lightweight RTMP library?
If so, could any one give me some advice on which classes to use and
how? I'm not looking for someone to write the code for me. I only want
my client to make and receive some RTMP invocations, I am essentially
writing a native interface to a Flash chatroom.
I know Flash is the best client, but the idea is to open the chatroom
to other more limited platforms :)
Thanks,
Chris
cs
Im probably not the best source of info on this subject, as Im new to rtmpd
& am barely trying to understand what's going on with the source.
However, since the (lack of) documentation sucks really badly & there's very
little/hardly *any* active participation in the group/mailing list, &
finding assistance from someone that can decipher the source can be a real
pain IMHO, I figured I'd chime in and try to give some feedback (perhaps it
might be of some help).
I'd say 'take a look at librtmp' that comes packaged with rtmpdump;
http://rtmpdump.mplayerhq.hu/librtmp.3.html
it seems to be more complete (includes functions for swf verification), and
seems to be a lot more lightweight than what's been implemented in rtmpd.
It may or may not suit your needs, but it might be worth looking into.
Hope this helps...
cs
Hi,
Thanks,
Chris
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
Chris Hansen
Thanks for your response! Unfortunately I have already had a look at
said librtmp - the documentation there is even worse and it does not
implement what I need - it focuses solely on obtaining RTMP stream
data, but what I need is to receive and send RTMP invoke commands.
Basically I am only using a subset of the protocol.
But thanks anyway :D at least I know someone reads these messages!
Chris
Eugen-Andrei Gavriloaie
Hi,
crtmpserver was not generally designed to rip parts of it. Theoretically, is possible to achieve what you want. Practically, quite hard.
Another feeling that I get is that people think that the server "superserver" using "libsuper" is heavy. That is not valid (at least for crtmpserver).
The "lightness" of a piece of software for me is the complexity of the most exercised code path at run time. The rest are one timers or unused features (bits on disk)
Crtmpserver can be very easy staged inside a separate thread to achieve integration. However we, at crtmpserver, prefer multi process. Much much better performance an 100% portable. Not to mention the simplicity of doing coding itself.
I don't think rtmpdump is more complete than crtmpserver's rtmp module. It has some additional features, i give you that but saying is more complete than crtmpserver i think is a little bit far streched. Lighter? It is lighter and easyer to integrate. More performance? I doubt! But prove me wrong.
Innactivity on the mailing list is because i'm pretty much the only one doing real coding. Is the reason why we have a mailing list in the first place. Nevertheless, you are 101% right: my implication in answering tech questions should be stronger, but i will start neglecting the code. On the other hand, there are countless requests for win build. Come on! Is that hard to add few missing files to the project and fix minor inconsistences? I don't own a win machine. When i catch one i always bring crtmpserver up to date.
Scarce docs? Besides few very nice exceptions, how many of you at least contributed back your findings? I simply can't do all.
In the end, this mail has a non-negative connotation and is definitely NOT addressed solely to the author of the initial email. He was just the trigger. It is for all of you guys out there who are using it in total silence or ditching it instantly because reasons which remain unknown to the rest of us.
Best regards,
Andrei
cs
I apologize if my response was taken negatively, Ive just been getting somewhat frustrated with the lack of documentation; its difficult to find one’s way around the source at times, and it really does take some effort to understand what’s going on with the program flow & logic.
As far as librtmp is concerned, I was just trying to help by mentioning, and I wasn’t trying to ‘put down’ rtmpd; I honestly don’t have much experience with it, so I cant speak to whether it performs better or worse than rtmpd, but I am also willing to bet that rtmpd has far superior performance. Librtmp was designed with a different, more simplistic purpose in mind; rtmpd is a full-blown client-server arch.
When I said ‘lightweight&complete’ I was simply referring mostly to the fact that it’s got all of the rtmp connectivity/functionality ‘out of the box’ & ready to go in a simple, compact module (again, this is what it was designed for, in contrast to rtmpd’s rtmp library, which was meant to be more integrated into the entire program’s OOP structure).
I personally think rtmpd is an awesome platform, and the coding work Eugen-Andrei has done is amazing. The way he’s abstracted everything & created this extremely well thought out OOP program structure is quite impressive IMHO. That being said, it does feel at times like ‘rtmpd is sooo complex that only its creator can fully understand it’. I really do think it needs better documentation, even if its just a readme document that explains how each of the core concepts work (like what a ‘messagefactory’ or ‘protocol handler’ is for), and how each class/object is meant to interact with the program’s flow. I know there’s a basic ‘api’ doc in the /docs folder, but it honestly doesn’t cover very much at all, it briefly explains what a protocol chain is and nothing more.
Since I myself am still trying to study the source & understand how everything works, Im getting to the point where Im feeling compelled to start documenting everything on my own (both as a personal user guide and perhaps as something that can be published to others). So I agree, I think that users should speak up (myself included) and start trying to contribute, whether it be via documentation or user assistance on the group mailing list.
Anyway, again, sorry if I upset you Andrei, it wasn’t my intention…
Thanks for doing such a great job with rtmpd & keep up the great work
(all that I ask is that you please just try to help us users on the list out every once in a while; some of us still desperately need your guidance)
cs
C++ RTMP Server
I just wanted to express my uneasiness regarding the direction/flow of information which is usually from me and other few exceptions towards the mailing list. The other way around is almost absent.
Bluntly put, a handful of people are trying to handle all the request from all the rest of the people.
Also, since the time is quite limited for us, our priority is to fix bugs NOT to do custom development and just serve it on the plate. In the end, let's say it by name: we ALL have to eat/drink/pay rent. Custom work definitely falls under commercial support :) (look on the home page of www.rtmpd.com)
So, again, CS, I didn't feel in any way touched or offended by your remarks. There is nothing you have to apologies for. You just pointed out the obvious. Hiding it under the carpet or getting upset about it is not the way to go. That's why I just put my thoughts inline and used your email as a trigger :)
Best regards,
Andrei
Josh Allmann
> Hi,
> Im probably not the best source of info on this subject, as Im new to rtmpd
> & am barely trying to understand what's going on with the source.
> However, since the (lack of) documentation sucks really badly & there's very
> little/hardly *any* active participation in the group/mailing list, &
> finding assistance from someone that can decipher the source can be a real
> pain
Andrei addressed many of your points eloquently, but I want to add a
pragmatic note.
RTMPD is not for novices. You need to be comfortable with C++, and you
need to have a good understanding of the RT*P protocols to get the
most mileage out of the source code. That's really the canonical
source of documentation. Proper docs take a lot of time to write, and
may grow stale quickly at the rate Andrei is adding features.
The majority of issues posted on this list could be addressed just by
reading through sample applications and modifying them.
Josh
cs
program functionality should be fair.
Even someone who's comfortable with c++/the rt* protocols still has to dig
through all of the source, jumping back&forth between files, in order to try
to piece together an understanding of how it all fits together. There's no
way around this, for novices & guru's alike.
cs
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Josh Allmann
Sent: Tuesday, September 27, 2011 8:26 PM
To: c-rtmp...@googlegroups.com
Josh
You received this message because you are subscribed to "C++ RTMP Server"
Chris Hansen
to an almost political level crtmpd debate.
I am going to assume that no one has any advice other than 'RMPTD is
not for novices' and that its 'Practically, quite hard'.
/my_involvement_in_this_thread
On Sep 28, 6:37 am, "cs" <changos...@gmail.com> wrote:
> Ok, agreed, but having a decent set of docs that cover the base classes &
> program functionality should be fair.
> Even someone who's comfortable with c++/the rt* protocols still has to dig
> through all of the source, jumping back&forth between files, in order to try
> to piece together an understanding of how it all fits together. There's no
> way around this, for novices & guru's alike.
> cs
>
> -----Original Message-----
> From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
>
> On Behalf Of Josh Allmann
> Sent: Tuesday, September 27, 2011 8:26 PM
> To: c-rtmp...@googlegroups.com
> Subject: Re: [rtmpd:4020] RTMP Client Library
>
cs
thread needed to be said, and your message simply unleashed it.
I think Andrei said it right, either people aren’t speaking up & offering
assistance or people are simply ditching rtmpd (probably upon finding out
how much of a time/energy investment its going to take to get up to speed on
it due to the lack of good documentation & support). Either way, it’s a
vicious cycle that leads to less user involvement & less community growth of
the project. IMHO, rtmpd seems to be going less in the direction of an
opensource community-driven project, and more in the direction of 'a
commercial product that lets you play with a more limited version of the
base source code.' If that’s the case, then there's really not that much
incentive to invest time&energy into helping users or providing free
documentation & support; the goal is mainly just to entice you to buy the
commercial support. I have no issues with this at all; we all need to make a
living somehow, so I completely understand...Still, it does make it that
much harder to work with rtmpd.
As for your question, you'd probably have to implement everything in pretty
much the exact same way as rtmpd does, starting with the base protocol
classes (in the protocols folder), and even extending out to some other
classes (netio, streaming, etc.), just take a look at all of the headers
that are being included. Then, youd either have to code it in the exact same
way as rtmpd (protocol instantiation, message handling, etc.), or start
hacking at stuff in order to force it to do what you want, how you want. I
doubt this would be an easy or worthwhile task, youd be better off just
basically starting from scratch, using rtmpd or librtmp's source as a
template...hence the recommendations to 'just find something else...'; rtmpd
wasn’t designed with the purpose of providing an externally-useable rtmp
protocol library. Anyway, Good luck if you decide to try it.
cs
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Chris Hansen
Sent: Friday, September 30, 2011 4:06 AM
To: C++ RTMP Server
Josh Allmann
managed .NET, you'll need to recreate most of rtmpd's event loop and
the scaffolding around it. Check out the androidapplestreaming sample.
Another option is to write a rtmpd application to do IPC with another
.NET process. This is much simpler if you just need to handle a few
invokes.
Josh
C++ RTMP Server
On Sep 30, 2011, at 8:04 PM, cs wrote:
> Apologies on my end, but I think some of the stuff that came out on the
> thread needed to be said, and your message simply unleashed it.
> I think Andrei said it right, either people aren’t speaking up & offering
> assistance or people are simply ditching rtmpd (probably upon finding out
> how much of a time/energy investment its going to take to get up to speed on
> it due to the lack of good documentation & support). Either way, it’s a
> vicious cycle that leads to less user involvement & less community growth of
> the project. IMHO, rtmpd seems to be going less in the direction of an
> opensource community-driven project, and more in the direction of 'a
> commercial product that lets you play with a more limited version of the
> base source code.' If that’s the case, then there's really not that much
> incentive to invest time&energy into helping users or providing free
> documentation & support; the goal is mainly just to entice you to buy the
> commercial support. I have no issues with this at all; we all need to make a
> living somehow, so I completely understand...Still, it does make it that
> much harder to work with rtmpd.
My opinions:
- crtmpserver was, is and will be an open source _server_. Is not and will not be a server with ready made applications. Is like saying you want a HTTP server and also want the wonder application who does it all on top of it. You can see it much like the vanilla distribution of apache who just shows "It works!" after installation inside the browser.
- I made few sample applications to exemplify how to use the platform and I will make more if my time allows.
- The RTMP part is covering a large use case scenarios. Same goes for RTSP, MPEGTS, etc. Want more functionality? Get your hands dirty with the code :)
- Everyone is more than welcome to create applications and I will definitely offer support based on my free time. Needless to say, people should also help each other if possible.
- Yes, we have commercial support, but no, there are no "hidden" features in the commercial product. We only do commercial applications on top of crtmpserver and make them run smooth _with_ more complex ready-made functionalities. There are no hidden custom made protocols for example. Bottom line, the commercial product is crtmpserver with better tested glue code for applications, 24/7 support, custom programming for peculiar needs, etc
- The docs are scarce. What do you prefer? Docs? Or samples? I have the feeling that if I would have started with docs and without samples at all, people will end up with nothing running. Having them both? Well... as I mentioned before, I can't simply do all. Something gotta give...
- you were talking about community-driven project. Do you have an application to share with us? Any piece of documentation? Something? Please share, that's community-driven. Me and the other few exceptions (I don't want to give names because I don't want to miss someone) I think we make a community. Join us!
I insist on the first opinion, just to be clear
I really hope I made myself understood.
Max Lapshin
> - you were talking about community-driven project. Do you have an application to share with us? Any piece of documentation? Something? Please share, that's community-driven. Me and the other few exceptions (I don't want to give names because I don't want to miss someone) I think we make a community. Join us!
>
Ha-ha! It is very common: "I haven't found any docs".
In fact there are no docs requried for configuring RTMP server and
there are no docs, which can help to make plugin for configuring RTMP
server (only sources)
And: there are NO rtmp servers, which can be developed in community driven mode.
cs
My 'docs' comments referred primarily toward the lack of documentation for
the source code & 'inner workings' of rtmpd, and not so much toward its
usage.
Source code documentation is a good thing, essential to collaborative
development, so I don’t understand why this seems to be frowned upon and
looked at as being of such low priority.
As far as usage docs go, they're also helpful.
Yes, examples are great&nice, but can sometimes be too specific & limited in
scope;
sure, they'll get you up&running quickly, but wont really show you much
else.
As for contributing myself...Id be glad too.
If&when I manage to organize all of my mental notes & finalize my
understanding of the program flow, Id be more than willing to publish
something onto the wiki.
cs
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Max Lapshin
Sent: Sunday, October 02, 2011 12:31 AM
To: c-rtmp...@googlegroups.com
You received this message because you are subscribed to "C++ RTMP Server"
C++ RTMP Server
On Oct 2, 2011, at 10:43 AM, cs wrote:
> Didn’t really understand the last reply, but...
I just trying to correct you when you say:
IMHO, rtmpd seems to be going less in the direction of an
opensource community-driven project, and more in the direction of 'a
commercial product that lets you play with a more limited version of the
base source code
Again, this is an open source project and is NOT limited/impaired in any way compared with the commercial version. I just use the building blocks from open source to build the commercial one. I don't use "secret" building blocks.
I'm sure you will do the same if you decide to use it and I'm sure other people are doing that as well. That's how open source project are driven, not by donations. Trust me when I say that, I have good reasons :)
Cheers,
Andrei
Max Lapshin
>
> As for contributing myself...Id be glad too.
> If&when I manage to organize all of my mental notes & finalize my
> understanding of the program flow, Id be more than willing to publish
> something onto the wiki.
> cs
Look: videostreaming server is a software built about primitive, but
extremely sophisticated logic.
Such code should be documented with links to PDF with standards,
formats and protocols. Maybe there may be some notices about
hacks and other tweaks, but no more.
No one will take care about creating documentation about data flow in
media server, because:
1) those, who can't understand it without documentation aren't ready to read it
2) those, who are ready to read code, don't need documentation.
So we get a horrible and unpleasant trooth: it is good, when _the_
author of videostreaming server can get help from one commiter. It is
really great, when there are
_two_ commiters. But in fact, videostreaming servers aren't community
driven projects because they have to deal with such complexity, that
must be handled in one head.
cs
Understanding the protocol & having a general concept of 'how a streaming
media server works' isn't at all a substitute for being able to read a basic
set of documentation that explains how the server itself (rtmpd) works.
Reading through code & jumping back&forth through source files is time
consuming & can be confusing; it becomes counter-productive. Even more so
when working with an OO-structured program like rtmpd's; if it was
procedural, you'd have a better chance at 'reading through code' and quickly
getting an idea of how the server is structured internally, but it doesn't
help much when you've got all of these abstract objects/classes all over the
place, that you have to tie together mentally in order to visualize how each
of the building blocks interact with one another.
Documentation is key for quickly & effectively grasping how an application
flows, although it seems as though its 'taboo' to mention it with regards to
rtmpd.
Cs
-----Original Message-----
From: c-rtmp...@googlegroups.com [mailto:c-rtmp...@googlegroups.com]
On Behalf Of Max Lapshin
Sent: Sunday, October 02, 2011 3:03 PM
To: c-rtmp...@googlegroups.com
You received this message because you are subscribed to "C++ RTMP Server"
Max Lapshin
> Ok, but, sorry, I still disagree.
> Understanding the protocol & having a general concept of 'how a streaming
> media server works' isn't at all a substitute for being able to read a basic
> set of documentation that explains how the server itself (rtmpd) works.
> Reading through code & jumping back&forth through source files is time
> consuming & can be confusing; it becomes counter-productive. Even more so
> when working with an OO-structured program like rtmpd's; if it was
> procedural, you'd have a better chance at 'reading through code' and quickly
It is a myth. Take a look at ffmpeg. It is also about video and in
fact it has classes inside with
constructor, virtual methods and destructors.
> getting an idea of how the server is structured internally, but it doesn't
> help much when you've got all of these abstract objects/classes all over the
> place, that you have to tie together mentally in order to visualize how each
> of the building blocks interact with one another.
> Documentation is key for quickly & effectively grasping how an application
> flows, although it seems as though its 'taboo' to mention it with regards to
> rtmpd.
You think, that it will help you, because you haven't ever tried to
create documentation for such a project.
Believe me: it is very hard to make documentation of such server,
because you have
very, very complicated logic of communication of different clients in realtime.
And it is hard.