RTSP client play support

[briand123]

I have been using Wowza for 4 years and found your uber awesome SRS. Incredible work in a very short time with a small team. There is one critical feature missing for my use case. Although its not highly common use, it's very critical for TV media. We have television clients who use Flash (flowplayer) to preview our streams, but when they want to ingest into their studio, they connect to Wowza using RTSP, not RTMP nor HLS. The reason is RTSP latency is very low. So for Live ingestion, TV station loves the low-latency as they often talk to live camera shooter on the phone during ingestion. In Wowza, the RTSP client also supports basic authentication, so for example you would use something like this in VLC to access this stream with some basic security:
rtsp://username:[email protected]/stream1
More TV stations are using ingestion mixer boards that use RTSP (i.e. Tricaster for instance) so they can pull from IP camera as well as Wowza server for live video. I hope you can add RTSP player client support in future release. God speed SRS!

[winlinvip]

SRS3(2016) focus on big-data, maybe SRS4(2017) can support it.

[winlinvip]

Do you know RSTP well? I got a question when develop the rtsp stream caster, which allow publish RTSP to SRS: how to support dts and pts in RTSP, because it seems RTSP only one timestamp the pts, how to calculate the dts in RTSP stream? Or, RTSP does not support dts, which is introduced in modern h.264 codec?

[briand123]

Sorry, I don't have deep protocol knowledge of RTSP. I am curious why you are choosing to support RTSP push publish ingestion into SRS before supporting RTSP pull on the player client side. Most all encoder HW I know of is RTMP on the push, unless source is IP camera which requires RTSP pull. I can't think of any IP camera out there that does anything but support RTSP pull for h.264 native.

Anyway, I will be stuck with paying for Wowza licenses until your SRS v4 since I need RTSP pull client player support. I would rather give you the money to put it in SRS now instead of paying Wowza haha

[winlinvip]

Push RTSP to SRS is part of stream caster, and user can push other protocols, for example, HTTP FLV or other protocols.
SRS-SEA push HTTP-FLV to SRS, for android to publish realtime stream in pure java code and hardware encoding, without ffmpeg or other library.
Please read the https://github.com/simple-rtmp-server/srs/tree/2.0release#stream-architecture

[hdezela]

@briand123 I've been using srs with feng to do exactly what you're saying. In my case it works fine since I only have a max of two tv channels ever pulling the live stream. It's also nice because I have a secondary feng running to support older Android and Blackberry phones that don't understand HLS - here in Peru 65% of phones are low-spec and don't get many upgrades.

@winlinvip Maybe you can take a look at the feng code to answer your RTSP questions....it works great and perhaps has what you need to resolve the issues with RTSP.

[winlinvip]

@hdezela Great work! I read the README and feng is design for RTSP similar to live555.
Can u give some detail step for users who want to covert RTMP to RTSP to play? I found no wiki or detail usage of feng.

[winlinvip]

For SRS, to pull RTSP then remux to RTMP/HLS/FLV is the main use scenario, and pulling RTSP is a feature of stream caster.
But deliverying RTSP to client, is huge difference of SRS design goal, seems a old compatible feature, so I think feng/live555/crtmpd and any server which can convert RTMP to RTSP is a better solution.
That is, I think the arch of SRS is design to delivery RTMP stream in cluster or client, it's impossible to change to delivery both RTMP and RTSP by SRS, and it's not the goal of SRS.

However, for the users who want to convert RTMP to RTSP for history problems, @hdezela can u give some detail step by step guide? That's very useful, thanks~

[hdezela]

I've got random text files with snippets of how I did it here and there, when I get back home next week I'll look over them and create a guide that'll hopefully be understandable.

Since RTSP is a dying protocol, documentation for feng was lacking, I was able to piece it together using archive.org and different fora around the web.

[winlinvip]

@hdezela Great!

[briand123]

Wow this is cool. Glad to see what you guys are doing. For now, I have
to use Wowza in production as I must have RTSP pull into wowza for IP
camera ingestion, then my multiple clients tap the output stream from wowza
via authenticated RTSP. I'd love to have alternate solutions than using
Wowza, which is java based and expensive. Hopefully, what you guys are
doing will compete with them.

On Thu, Sep 24, 2015 at 12:17 AM, winlin [email protected] wrote:

@hdezela https://github.com/hdezela Great!

—' translates to '> —' in English.
Reply to this email directly or view it on GitHub
#476 (comment)
.

TRANS_BY_GPT3

[briand123]

Yes. I clearly understand what your are saying winlin. The only part I
would disagree with is the part about RTSP pull from the server 'player'
side being an 'old compatible' feature. For general consumer audience,
maybe. For news rooms switching from satellite to IP video, it's the
preferred way right now. The reason is HLS causes way too much delay.
And Flash plugin is hated more everyday by the security folks. RTP and
RTSP are lowest latency which news studio wants for dialogue. I know
this usage is niche case, but news media is a large and big $$$ business,
and Wowza does have that use case covered. In the future, it may be
WebRTC gives the lowest latency. I know someone is making a Wowza WebRTC
interface layer product.
Best Regards,
Brian

On Wed, Sep 23, 2015 at 9:23 PM, winlin [email protected] wrote:

For SRS, to pull RTSP then remux to RTMP/HLS/FLV is the main use scenario,
and pulling RTSP is a feature of stream caster.
But deliverying RTSP to client, is huge difference of SRS design goal,
seems a old compatible feature, so I think feng/live555/crtmpd and any
server which can convert RTMP to RTSP is a better solution.
That is, I think the arch of SRS is design to delivery RTMP stream in
cluster or client, it's impossible to change to delivery both RTMP and RTSP
by RTSP, and it's not the goal of SRS.

However, for the users who want to convert RTMP to RTSP for history
problems, @hdezela https://github.com/hdezela can u give some detail
step by step guide? That's very useful, thanks~

—' translates to '> —' in English.
Reply to this email directly or view it on GitHub
#476 (comment)
.

TRANS_BY_GPT3

[winlinvip]

Humm, seems the WebRTC will be the one for realtime communication~

[briand123]

Maybe at some point, but not any time soon. If you research the webRTC
efforts, it's influx over codec wars. Many oppose h.264 over licensing
headaches. AAC is out for audio. There is a company that's been making a
webRTC gateway for Wowza.

http://www.wowza.com/forums/showthread.php?36532-WebRTC-support

The focus is more for video calls vs TV broadcast media IP video, but still
could be applied. The good thing is the player is built into the browser.
No flash, no VLC, no quicktime plugins.

On Fri, Sep 25, 2015 at 9:29 AM, winlin [email protected] wrote:

Humm, seems the WebRTC will be the one for realtime communication~

—' translates to '> —' in English.
Reply to this email directly or view it on GitHub
#476 (comment)
.

TRANS_BY_GPT3

[winlinvip]

Dup to #1500 support GB18181

[winlinvip]

Does not support pushing RTSP streams from the camera to SRS, only supports ingesting/FFmpeg pulling RTSP streams from the camera and then forwarding them to SRS, refer to: #2304 (comment)

TRANS_BY_GPT3