[done] rtsp stream support

[tashes]

As some ipcams do not support other access methos then rtsp streaming, could you please add rtsp to vidblaster.
Thank you

[Prophet][]

I would also like to see this as I wish to stream video from another computer and while I am now able to use the IP Camera feature having support for rtsp or even mms:// or udp:// would make things much easier and allow for audio to also be transmitted in the same stream. For the codec itself anything that is standard like H.264, MPEG-4 or WMV would also be good.

[Johan Lundberg]

I would also really like to see this added to the software.
Since alot of the network based cameras we are using are broadcasting through rtsp, for me (still in trial) this actually is the one thing that would settle the deal. H264 over RTSP is definitely the way to go since more and more cameras will support it in the future.

I really hope this can happen anytime soon.

Regards,
Johan

Edit: If it helps I have no problem setting up a demo camera for testing.

[Mike]

I'd like to run some tests and could use some of your feeds if anyone's still interested.

[Johan Lundberg]

Great Mike,
I don't have any cameras permanently set up, but I can rig one for tests when I get back home again tomorrow.
I will get back to you with details.

Regards,
Johan

[Johan Lundberg]

I have not forgot you Mike, just had alot of work lately. A camera for testing will be up shortly!

/Johan

[Mike]

Thanks Johan. Unfortunately I cannot use this camera for testing as it only offers MJPEG (which works fine btw) and RTSP/H264. I have some code for testing RTSP, but I cannot accept H264 withour further work (which I can't justify right now).

[Johan Lundberg]

Mike, too bad about the support for H264. This is something that I think should be a priority on the list since more and more cameras are using it and of course simply because it's great both quality and bandwidth wise! Anyway, I will see if I can help you out with the RTSP anyway, I will see if I can get something else up and running for you to test on.

Regards,
Johan

[Johan Lundberg]

Mike,

You could just setup vlc player to make a RTSP-stream for you.
Just make it loop-play any file and choose to stream it as RTSP and you should have something to test on.

Regards,
Johan

[Johan Lundberg]

I have some code for testing RTSP, but I cannot accept H264 withour further work (which I can't justify right now).


Any progress on this?
Let me know if I can help in any way.

Thanks,
Johan

[Johan Lundberg]

I know this is an old thread but just wanted to bump this and note that I'm still interesting in support for h264 for RTSP-streamed sources.
Most of the new IP-cameras today uses H264 over RTSP for high quality output and of course we like best available quality!

Thanks.

Johan

[huppe]

Hi,

I'm very interested in RTSP stream, since it allow audio and video. I've got a few IP cams (AXIS 243SA) I've got the http (mjpeg) stream running, but it doesn't have sound. Maybe I just have the sintax wrong... my settings is as follows:
"http://IPARDESS/axis-cgi/mjpg/video.cgi?resolution=704x576", and this is working.

Axis camers RTSP works as follows:

• Unicast via RTP: axrtpu://<ip>/mpeg4/media.amp
• Unicast via RTSP: axrtsp://<ip>/mpeg4/media.amp
• Unicast via RTSP, tunneled via HTTP: axrtsphttp://<ip>/mpeg4/media.amp
• Unicast via RTSP, tunneled via HTTPS: axrtsphttps://<ip>/mpeg4/media.amp
• Multicast: axrtpm://<ip>/mpeg4/media.amp

tested, and worked in SA

Albert

[Johan Lundberg]

This request together with direct decklink output and resizeable source monitors is what I'm really missing in Vidblaster right now and something that would make it alot more useful for us.

Mike, if this is something that will be worked on and added any time soon, I will go on and upgrade to broadcast license.

Thanks.

[Sinc747]

+1 for H.264 support for IP cameras. I understand that the H.264 video is much nicer than the MJPEG video and may also be less overhead.

- Tom

[Johan Lundberg]

We are currently planning an upcoming job where we really would like to use Vidblaster (would btw be a really cool case study as well). The only thing is that this would demand support for IP-cameras with h.264 over rtsp.

Mike, is this something you are considering working on, or should I just drop the idea and go for another solution? We got a couple of months until the job is due.

[damn2good4u]

+1 for H.264 video...

Mike, good work with Vidblaster, but can you be a bit more flexible by adding H.264 to the App? maybe you will need to create a module for user/broadcaster to have a choose btw H.264 and VP6 codecs....

[Johan Lundberg]

Note that this request only is about h.264 and rtsp support as INPUT in the camera module. H.264 support for the streamer module is a separate request.

[Mike]

I want to have a brief look at this to estimate the amount of work involved. Does anyone know a link for testing, or can anyone hookup a camera I can use? Thanks.

[Johan Lundberg]

Give me a few and I will have one (or two) up for you.
Got all the gear right here so it shouldn't take long!

/Johan

[Johan Lundberg]

Okey Mike, you got a PM!

[Mike]

Johan, did you happen to add that second camera?

[Johan Lundberg]

I only have the Axis camera up at the moment (Axis M1054).
Would you like to try the Arecont camera or another Axis camera?
I'm not sure I have any more of the newer Axis cameras at home at the moment. I know I have Axis 207 (slightly older, old kind of streaming URL) and Arecont AV1305 at home.

Can't get anything more up until tonight I'm afraid.

[Johan Lundberg]

Also, today the Axis cameras seems to be the brand prefered by most people I've spoken to, both for surveillance and high end media use of IP cameras.

[jak]

Maybe it's to early regarding the new protocol, but for the mjpeg ones - do you have any feel for the resource/cpu usage with IP cams compared to other connection methods like USB, Firewire or the high-end capture cards?

[Mike]

@Jan: A feature request is not the best place to ask that.

@Johan: Planned to run some tests but no luck. And Axis support is not helping. I'll let you know when I hear more. Agree I will concentrate on Axis only for now.

[Jakob]

+1 for h.264 support for IP Cams. I recently tested a high end Axis HD cam (P5534) Extremely good picture, and very low latency. I could only use in in conjunction with VB in MJPEG mode. When testing it with h.264 (outside VB), you get perfect picture and 100% lipsync when audio is introduced through the camera. Could be VERY usefull, and this is my #1 wish for upcomming feature.

[Mike]

How badly do you wish it?

[Jakob]

I want it pretty bad :-)

[weconverse]

Wrong Answer Jakob, means Mike will make it a Broadcast feature ;)
Note, I am just kidding. This would be a very nice and useful feature.

[Johan Lundberg]

Just want to let you guys know that Mike is putting ALOT of effort in getting this working. I know there are quite alot of obstacles in the way though, but I am sure this will come true sooner or later. Kudos to Mike for all the hard work!

[Mike]

This module will support both RTP flavours RTSP and RTMP so it'll be more than just an IP camera module. any suggestions what to call it? RTP Input?

[Johan Lundberg]

Will this same module also have support for mjpeg over HTTP and replace the current IP-camera choice in the Camera (I) module?

[Mike]

Good question. I guess it depends if there any other purposes for this module than receiving video streams from IP cameras. If not, I guess I could add MJPEG and call it IP Camera. However I think some want to import RTMP streams (http://forum.vidblaster.com/showthread.php?t=1980) that have nothing to do with IP cameras?

[Johan Lundberg]

If we collect all kinds of IP-based video streams in this module we could maybe simply call it IP-stream or Network stream?

[Johan Lundberg]

For reference, in VLC it's named "Open Network Stream".

[Mike]

That's rather generic. RTP Network Stream Input could work, but I find it a little long :) Since RTP is a network protocol, we could omit that, and as it can only be a stream, we can omit that too. Which brings us back to RTP Input? I'd really like to hear what the RTMP guys want to do with it.

[Johan Lundberg]

I think RTP input is alot more confusing than Network stream (or IP stream). If this very same module will also replace the old IP-camera it's not only RTP.
The question is, will there be any other modules supporting some kinds of network/ip streams? If not I think Network stream (or maybe IP stream) is spot on.

The only possible risk of confusion I see is if someone mix it up with the Streamer module and think it is for output purpose.

[Johan Lundberg]

"IP Source"?

[QuinnQuality]

@Mike, have you ever had the change testing a Teradek Cube which sends out RMTP and HTML? If you would, i am willing to lent you one during my Holidays from april 23 to may 8 so you can test one. If Yes, i will contact you on your e.mail address for further details.
It is for our broadcast plans very important to be able to integrate these signals into VidBlaster since i am planning to buy 4 more peaces during my Holidays in the US. Let me know what you think Mike.

[QuinnQuality]

Mike, i would really like to know within 3 weeks or so, if the streaming input to VB request will be a future function, because i am about to make an order for more Teradek Cube's. The fact is now, can i buy only the transmitters or do i now also have to start buying (expensive) receivers to be able to input the remote camera signals into VB

[Mike]

Johan, that does sound nice but this module does RTP, there are a lot IP protocols it does not do so I find that name does not describe the module properly.

Have to say I'm a little disappointed only one person has been willing to reply to this. It is a lot of work to change the naming afterwards so I wanted to make sure I'd use the best name. I'll use RTP Input so I can continue my work.

[Mike]

Would it be possible that an RTP stream is interlaced and so needs deinterlacing?

[jak]

Ok, I'll add my thoughts.

Today we have "Camera I", "Camera II" and "Player" for feeding video into VB.

Player is specifically aimed at prerecorded files, while "Camera I" and "Camera II" handles different types of video input, not limited to actual cameras but also covering other forms of capture devices.

We now get a fourth video source, that not only covers cameras but potentially also other devices that uses the same protocol.

So the main difference between the modules is the types of protocol they handle, not what type of device is at the other end of the connection.

So based on this, "RTP input" makes sense, but then "Camera II" does not...

[Mike]

Also, would you like to see the URL (or the last part of it anyway) or have a field where you can enter a text of your choosing? Obviously the video devices and operator controls (if you compare this module to the camera module) are superfluous. I can also leave them out both and make the module smaller.

[Mike]

Does anyone know an RTMP stream I can use for testing?

[QuinnQuality]

Unfortunately, the Teradek Cube is RTP only and interlaced by standard setting. If the source entered is 720p, the cube can follow. My offer still stand for lending my cube for a 2 week period during my holiday at the end of april.

[Mike]

Thanks John, but I have no time for that available. If however you set up a test stream I will give it a try.

[Mike]

@Jan: Thanks. I hear you and have often wondered if I should change the word camera. However, it feels so normal to be switching "cameras". In that light, maybe this module should also simply be called Camera (type III)? A discussion by itself and worth its own topic.

[Johan Lundberg]

Also, would you like to see the URL (or the last part of it anyway) or have a field where you can enter a text of your choosing? Obviously the video devices and operator controls (if you compare this module to the camera module) are superfluous. I can also leave them out both and make the module smaller.

A text field (the same way as in Camera modules) would be very very useful. The URL, which I then think should be the IP-adress/hostname (or end of it), and not the end of the full URL would also be useful information. Not sure if we need to have it visible at all times though. For our use the IP-adresses will only be used for setup and to track down sources. For the live production custom names (text field) will be much more useful. There we can name the sources real "human friendly" names.

[Johan Lundberg]

Would it be possible that an RTP stream is interlaced and so needs deinterlacing?

For our use I personally don't see the need for this, although for some it might be useful. I see a clear logic though in having this option in all source modules.
After all, in TV distribution interlaced is still very common.

[Mike]

A text field (the same way as in Camera modules) would be very very useful. The URL, which I then think should be the IP-adress/hostname (or end of it), and not the end of the full URL would also be useful information. Not sure if we need to have it visible at all times though. For our use the IP-adresses will only be used for setup and to track down sources. For the live production custom names (text field) will be much more useful. There we can name the sources real "human friendly" names.
I'll only add the text field then. Of course this means the module will be lower than most others (http://forum.vidblaster.com/showthread.php?p=12984).

[Mike]

Work in progress.. (http://twitter.com/#%21/MikeVersteeg/status/55215671331655680)

[Johan Lundberg]

Link is broken, should be: http://twitter.com/MikeVersteeg/status/55215671331655680

Very nice Mike!
Is the solution for audio output the same as in the Player module?

[Mike]

Link is correct and works fine here?

Not yet, still working on that. Currently it uses the default device.

[Mike]

I just found out I made an error in assuming RTSP and RTMP were subsets of RTP (that would have been too logical I guess), so the name I have chosen is wrong and should technically be RTSP/RTMP Input.

[Mike]

A beta version of the new RTSP/RTMP Input module will be available in the next release of VidBlaster Broadcast.

[weconverse]

Whow!
Will this module have API functionality? That is, providing the URL via API. This is useful when resolving stream addresses not known when the profile is set up. For example, somehting coming live from a server after VidBlaster starts airing (or rather neting).

[Mike]

There is still a UI for things like this?

I've only had one RTMP stream to test and that did not work, so this may end up as an RTSP module yet.

[Mike]

Good news, I just received another RTMP address for testing and that worked fine.

A word for those who will be testing this new module: it is not yet recognized by the video switcher, so you will have to route it through a video effect module. If no effects are needed, just use source overlay without a source as this will hardly use any resources (especially with the new effect module).

[Mike]

rtsp/rtmp input <m>
> cut
> operator
> trans
> url

[Johan Lundberg]

Excellent Mike! :)

[Johan Lundberg]

One more question that hit me.
Will this new module be resizable just like the Camera (II) module?
Will be of great value for us. Thanks!

[Mike]

Yes.

http://forum.vidblaster.com/attachment.php?attachmentid=248&stc=1&d=1302259380
RTMP stream with Display Size set to 50%

[QuinnQuality]

@Mike, great news and congratulations on the new release. I have tested 2 Teradek Cube's today and both streams were entered without any problem. The next step towards wireless switching is made. I do hope you will make the RTMP module also recognized in the switcher, for me that would be the best. VidBlaster rocks (You know you could make a pile of money if there would be a Mac OS version)