[ANNOUNCE] We have a functional RTP/RTSP implementation
C++ RTMP Server
I'm proud to announce you that we have a functional version of RTSP/RTP streaming. It is in alpha stage and the code is at least ugly!!! Not to mention that you can crash the server via RTSP/RTP in 10001 ways :). But doesn't matter at all. Because all difficulties were solved and I have the complete know-how. Next, there will be a series of commits on RTSP/RTP part of the project which will make it truly usable.
What does it do in this very moment:
1. Capable of streaming RTMP streams over RTSP
For example, you publish a stream from FMLE and call it myStream. Now you can access it like this:
-- rtmp://ip/app/myStream (RTMP way, nothing special about it)
-- rtsp://ip/app/myStream (RTSP way, this is special :) )
Notice that the only difference is rtmp -- rtsp. Isn't that cool ?
Works on quicktime, android, VLC and ffmpeg
2. Capable of streaming RTSP streams over RTMP. The server is capable of ingesting RTSP/RTP and spit out RTMP
Again, a lot of hacks are involved here, so don't expect to be easy to test it right out of the box. But the hard part was done: fully understanding RTSP/RTP. The code will now be refactorized.
Happy coding
Cheers,
Andrei
------
Eugen-Andrei Gavriloaie
Web: http://www.rtmpd.com
Max Lapshin
header, neither RTCP packets? Mention about such monsters.
Friday Nick
>
C++ RTMP Server
On Jun 1, 2010, at 8:16 PM, Max Lapshin wrote:
> Have you already met with cameras, that doesn't send neither Rtp-Info
> header, neither RTCP packets? Mention about such monsters.
Yep, I did :) The RTP features needed for this to work are minimal (standard RFC)
>
> 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
Max Lapshin
>
> On Jun 1, 2010, at 8:16 PM, Max Lapshin wrote:
>
>> Have you already met with cameras, that doesn't send neither Rtp-Info
>> header, neither RTCP packets? Mention about such monsters.
> Yep, I did :) The RTP features needed for this to work are minimal (standard RFC)
>
And how do you synchronize audio and video?
C++ RTMP Server
Didn't went on that road yet. But in a few days, I will. I was working mainly on management routines (spawning protocols, managing streams, etc) and the proof-of-concept for the RTMP to RTP transcoder routines.
But, my wild guess, is that you can't do much about it without RTCP. And, as in RTMP case, it will highly depend on the quality of the source.
I can say that I had bad experiences consuming VLC produced RTP streams. They were having backwards timestamps which definitely complicates things. Is perfectly "legal", but forces you to do re-ordering. For that, you need buffering on server side because not all clients are thrilled when getting such packets. Opposite, the IP cameras that I tested on, worked perfectly.
Cheers,
Andrei
Max Lapshin
>
> But, my wild guess, is that you can't do much about it without RTCP. And, as in RTMP case, it will highly depend on the quality of the source.
> I can say that I had bad experiences consuming VLC produced RTP streams. They were having backwards timestamps which definitely complicates things. Is perfectly "legal", but forces you to do re-ordering. For that, you need buffering on server side because not all clients are thrilled when getting such packets. Opposite, the IP cameras that I tested on, worked perfectly.
I've tested Axis and Beward cameras. Though Beward's live555 makes
rather unconvenient MPEG-TS to unpack, it is playable.
However, I've met camera (sorry, forgot vendor name) without Rtp-Info
header and rtcp.
I think that best way is to wait for 10 seconds and then synchronize
them by wall clock.
P.S. VLC also likes to create MPEG-TS without timestamps =)
C++ RTMP Server
On Jun 1, 2010, at 10:47 PM, Max Lapshin wrote:
>> Didn't went on that road yet. But in a few days, I will. I was working mainly on management routines (spawning protocols, managing streams, etc) and the proof-of-concept for the RTMP to RTP transcoder routines.
>>
>> But, my wild guess, is that you can't do much about it without RTCP. And, as in RTMP case, it will highly depend on the quality of the source.
>> I can say that I had bad experiences consuming VLC produced RTP streams. They were having backwards timestamps which definitely complicates things. Is perfectly "legal", but forces you to do re-ordering. For that, you need buffering on server side because not all clients are thrilled when getting such packets. Opposite, the IP cameras that I tested on, worked perfectly.
>
> I've tested Axis and Beward cameras. Though Beward's live555 makes
> rather unconvenient MPEG-TS to unpack, it is playable.
mpeg-ts is fully covered. Actually, in rtmpd is just a matter of properly chain few protocols. I'd be glad if I encounter many "mpeg-ts over RTP" cameras :)
> However, I've met camera (sorry, forgot vendor name) without Rtp-Info
> header and rtcp.
Wait a sec... What do you mean by RTP-Info? We might not be on the same page. I only use the standard RTP for now, because I implemented only RFC 3984 (RTP Payload Format for H.264 Video)
>
> I think that best way is to wait for 10 seconds and then synchronize
> them by wall clock.
>
> P.S. VLC also likes to create MPEG-TS without timestamps =)
That is pretty bad.
I don't think is safe to relay on RTP timestamps when it is carrying mpeg-ts content. Best way is to look at PTS inside mpeg-ts payload. If that is not present (that being a serious bug on source side), look at PCR/OPCR. If those are absent as well, than finally fall back on RTP timestamps. But IMHO, if you don't have PTS, the chances of having a smooth and correct playback drops below 10%.
C++ RTMP Server
On Jun 1, 2010, at 8:23 PM, Friday Nick wrote:
>> 2. Capable of streaming RTSP streams over RTMP. The server is capable of ingesting RTSP/RTP and spit out RTMP
>>
> Could you explain how to point the server to ingest RTSP stream? Thanks
I could try but, as I said, is rather complicated and requires you to make use of wireshark, copy some output from there, paste it in the code, etc. Ugly! Ugly! Ugly! And simply doesn't worth the effort, since it will be usable out of the box in the next few days. You just have to have patience :)
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
------
Max Lapshin
>> I've tested Axis and Beward cameras. Though Beward's live555 makes
>> rather unconvenient MPEG-TS to unpack, it is playable.
> mpeg-ts is fully covered. Actually, in rtmpd is just a matter of properly chain few protocols. I'd be glad if I encounter many "mpeg-ts over RTP" cameras :)
>
I meant Rtp, of course, not mpeg-ts.
>> However, I've met camera (sorry, forgot vendor name) without Rtp-Info
>> header and rtcp.
> Wait a sec... What do you mean by RTP-Info? We might not be on the same page. I only use the standard RTP for now, because I implemented only RFC 3984 (RTP Payload Format for H.264 Video)
>
Some devices give you Rtp-Info: header after PLAY command in RTSP
session, so that you can start your server synchronized with wall
clock. It is like first RTCP packet already received.
Eugen-Andrei Gavriloaie
On Wed, Jun 2, 2010 at 12:21 AM, C++ RTMP Server <crtmp...@gmail.com> wrote:
>> I've tested Axis and Beward cameras. Though Beward's live555 makes
>> rather unconvenient MPEG-TS to unpack, it is playable.
> mpeg-ts is fully covered. Actually, in rtmpd is just a matter of properly chain few protocols. I'd be glad if I encounter many "mpeg-ts over RTP" cameras :)
>
>> However, I've met camera (sorry, forgot vendor name) without Rtp-Info
>> header and rtcp.
> Wait a sec... What do you mean by RTP-Info? We might not be on the same page. I only use the standard RTP for now, because I implemented only RFC 3984 (RTP Payload Format for H.264 Video)
>
Some devices give you Rtp-Info: header after PLAY command in RTSP
session, so that you can start your server synchronized with wall
clock. It is like first RTCP packet already received.
I think RTP should be self sufficient. But I will see that in practice. Anyway, I'm going to support RTCP as well and try to sync the A/V in all possible ways.
But as I said, the quality of the source stream (in terms of timestamps) will be the deciding factor and count the most.
Cheers,
Andrei
P.S.
I've added you to my list of contacts. We should go over gtalk and exchange some know-how about streaming.
Max Lapshin
Waster
Can you please exaplain me how can I send RTSP stream to <inboundRtsp>
port in flvplayback application via VLC for example?
andrewaggb
I just found out about your project today and I'd like to try it out
with some ip cameras and nvr software. I currently use Wowza's RTP-
>rtmp to stream to a few customers who wanted flash support. It works
but Wowza is far too expensive for what I'm trying to do and it
requires java which is something I don't want to deal with.
I was able to build your trunk code on fedora 12 (but it failed in vs
2010)
(Error 16 error C1083: Cannot open source file: '..\..\..\sources
\applications\admin\src\variantappprotocolhandler.cpp': No such file
or directory X:\Projects\rtmpd\builders\VS2010\admin\c1xx admin)
Anyways what I'm not clear on is how to input multiple rtp or rtsp
h264 feeds into the server and what path they would be available over
via rtmp. I'm sure it's just configuration file stuff but I couldn't
find doc's/examples. It sounds like a couple people here have already
done it so I'd like to try it out. So basically, if I have an ip
camera at rtsp://192.168.1.16:554/live.sdp how would I configure the
server to publish it via rtmp?
I wrote an rtsp client and rtsp server a couple years ago and have
built various projects using ffmpeg dll's, x264, etc so I'm fairly
familiar with the protocols and video formats/containers involved. I
was considering finishing a small rtmp server I had started many
months ago (single purpose, publish h264 live streams via rtmp) but it
seems like a waste if you're this far along already.
Andrew
C++ RTMP Server
On Jun 8, 2010, at 11:44 PM, andrewaggb wrote:
> Hi,
>
> I just found out about your project today and I'd like to try it out
> with some ip cameras and nvr software.
Well, if you wait a little bit longer, you will be able to install the whole thing directly on the camera (search this mailing list for the last announce :) )
> I currently use Wowza's RTP-
>> rtmp to stream to a few customers who wanted flash support. It works
> but Wowza is far too expensive for what I'm trying to do and it
> requires java which is something I don't want to deal with.
The RTSP/RTP support is still under development: outputting RTSP streams is beta while consuming RTSP streams is proof-of-concept. Both works great when they do :) I need to polish them to bring them to production state.
>
> I was able to build your trunk code on fedora 12 (but it failed in vs
> 2010)
> (Error 16 error C1083: Cannot open source file: '..\..\..\sources
> \applications\admin\src\variantappprotocolhandler.cpp': No such file
> or directory X:\Projects\rtmpd\builders\VS2010\admin\c1xx admin)
>
> Anyways what I'm not clear on is how to input multiple rtp or rtsp
> h264 feeds into the server and what path they would be available over
> via rtmp. I'm sure it's just configuration file stuff but I couldn't
> find doc's/examples. It sounds like a couple people here have already
> done it so I'd like to try it out.
Basically, you have to create a UDP RTP acceptor in the config file and open the RTSP session manually via telnet. That is why I told you is proof-of-concept. But it will be finished soon. I guarantee you that. In the mean time, you can play around with outbound rtsp streams. That is, publishing from FMLE and consuming via RTSP (if it makes any sense to your needs)
> So basically, if I have an ip
> camera at rtsp://192.168.1.16:554/live.sdp how would I configure the
> server to publish it via rtmp?
>
> I wrote an rtsp client and rtsp server a couple years ago and have
> built various projects using ffmpeg dll's, x264, etc so I'm fairly
> familiar with the protocols and video formats/containers involved. I
> was considering finishing a small rtmp server I had started many
> months ago (single purpose, publish h264 live streams via rtmp) but it
> seems like a waste if you're this far along already.
>
> Andrew
>