Talk:Real Time Messaging Protocol
|WikiProject Computing||(Rated Start-class, Low-importance)|
RTMP - what is RTMPT - a RMPT Tunnel I beleive? Any info on this? They have also created RTMPE which is an RTMP + Encryption stream. —Preceding unsigned comment added by 22.214.171.124 (talk • contribs) 13:00, 25 February 2007
Is there a rtmp rip application (enter a rtmp url, get a flv file on your hd)? For OS X? Thanks for any pointers, Peter S. 02:17, 1 September 2007 (UTC)
I've only just begun working with RTMP in ActionScript 3 (Flex 2 SDK), but I'm using FluorineFx (http://www.fluorinefx.com) for the server and it's free / open source rather than the other commercial implementations listed. I don't know that it "fully" implements the protocol, but it seems to do all the things RTMP is for (RPC, Shared Objects, etc.). Neilob 14:45, 26 October 2007 (UTC)
The information on this Link is related to Wiki and its not just a link, Its useful information. Please include this and revert the changes made
Some of the notes on elements missing from the spec appear to be original research (or at least non-cited). A look at the current version of the spec suggests that this information is no longer accurate. As one example, the little-endianness of the stream message IDs are clearly documented in the spec. I'll wait a few days for comments, then reduce it to something like the following:
Adobe has released a specification (cite-link) that documents RTMP (except for the portions relating to copy protection). The specification includes a limited patent grant (which does not apply to 'prohibited uses', such as recording streamed content to disk).
The bit about 'Adobe is liable for initiating a false action under the Act' is likewise non-cited. It is also, as far as I know, untested in the courts. I'm inclined to just remove it (the section already documents the conflict between Adobe and some competing clients).
- I definitely think that there is some original research here. The very notion of 'missing parts' from the specs is research outside the main source and I believe should be referenced extensively. I deleted the part about the fact that the message id is little endian is not mentioned in the spec since it is wrong. It is mentioned on page 8 of the June 2009 release of the spec. I also strongly believe that there author meant Message ID rather than Stream ID as was written since the latter is a 6 bit number that is definitely big endian. It is usually a 0x03 (interpreted normally as 3 dec). I also deleted the omission of aggregate messages since they are referenced in page 21 of the same spec, maybe not very extensively I agree and would back up the claim that the spec is badly written. Mmick66 (talk) 10:01, 25 December 2011 (UTC)
As this discussion hadn't moved in a while, I WP:BOLDed and tried for a clarification in the lead-in, as well as fixing up a couple other issues. If you don't like my wording, feel free to modify it, of course. Jouster (whisper) 18:27, 3 June 2012 (UTC)
I have deleted the unsourced and probable WP:OR criticism. Someone didn't read the cover document carefully, because it says that not all details are made public. Also, it appears someone thought that a full implementation is needed for some (unspecified) "license" to be granted, when no such thing is in the Adobe license agreement. (Of course it would be silly since they don't disclose the whole thing.) JMP EAX (talk) 22:44, 4 August 2014 (UTC)
Re requested clarification
"Other RPC services are made asynchronously with a single client/server request/response model, so real-time communication is not necessary"
request/response happen pretty much in real time, so it would be better to say here, that "maintaining a persistent communication channel is not necessary upon arrival of response".
also, rtmp supports publisher/subscriber model, which is different from video/audio streaming, still requires a persistent connection so messages can be pushed to client. —Preceding unsigned comment added by 126.96.36.199 (talk) 01:33, 15 April 2010 (UTC)