Ip Restream: Encoder Software Needed or Not?

Wowza Streaming Engine
1

Hi,

We are trying Wowza Server 3 to restream feed from IP cameras. Currently, there is only one camera (GeoVision BX 520D) and all the setup is intranet (for now).

  • ip camera is assigned ip address of 192.168.1.10. It’s stream can be played via VLC Player by going to: rtsp://192.168.1.10:8554/CH001.sdp ( VLC Player gets a login dialog from the ip camera before it can play). VLC Player shows Codec Information as: video: H-264 Mpeg. audio:MPEG AAC

  • Wowza is running on 192.168.1.8

We don’t know how to direct the stream from the ip camera to Wowza. Remember: ip camera has a login dialog (not sure how to get rid of that yet). So…we have a hacked-setup where we are using VLCplayer to play the stream from the camera and using Wirecast to use its ‘Presenter’ functionality to grab the screen from the VLC Player and Broadcasts to Wowza’s ‘live’ stream. Wirecast is unable to find the ip camera (‘Not connected’ error). This setup is working but is not good for ‘production’ quality work.

I have studied the IP restream https://www.wowza.com/docs/how-to-re-stream-video-from-an-ip-camera-rtsp-rtp-re-streaming as well as https://www.wowza.com/docs/how-to-set-up-live-streaming-using-an-rtsp-rtp-based-encoder

but have not found a solution yet.

Question:

  1. Do we really need an encoder like VLC Player or Wirecast to grab the feed from the IP camera?

Or, in general, how would you guys setup if it were you? We may be using an ip camera (the GeoVision one) which is not recognized by Wirecast but it could also help if VLC Player–which DOES see the IP camera stream, broadcasts it to Wowza–thus eliminating the expensive Wirecast from the equation.

Thanks!

2

Check with them for a firmware update that should fix it

Richard

3

Some more info. The ip restream probably doesn’t work because the IP cam expects authentication (which I can enter in VLC Player). So here is the error log file says:

RTPSessionDescriptionDataProviderBasicRTSPWorker.processResponse: Authentication required[401]: Username password not available

WARN server comment 2011-11-18 10:55:17 - - - - - 39255.937 - - -

Where do I enter this info?!

4

I sent a message to GeoVision to see if I can get them to update their firmware with this fix.

Charlie

5

The GeoVision cameras with built-in h.264 video and AAC audio should work with Wowza following that guide, but make sure you have the latest firmware. It might not work out of the box without firmware update.

Cameras with other than h.264 video and AAC or MP3 audio do have to use a transcoder, VLC or the Wowza Transcoder, or other solution.

Richard

6

Oh, I see: Restreaming an authenticated RTSP stream through Wowza Pro

has answer to username/password. At least I don’t see the ‘Stream not found’ error anymore. Still, the live.html for Flash player shows blank now…

7

Richard,

That’s good to know about the IP cam.

But now that I am closer to making the camera work without any 3rd party encoder the camera is acting really flaky: Keep losing its place in the intranet. It ran all last night but now hard to find via its ip address in the network as well as from the GeoVision’s utility program which came with the ip cam. All I did today was to change some video codecs and also reduced the output bandwidth using the browser interface…

Thanks!

Meengla

8

I sent log files as well as other config files to Wowza support: The response is that GeoVision’s IP cams have problems in sending out packets. Here is Wowza’s response. So we are probably going to go for the Axis cams.

Thanks.

PS. Hopefully Wowza will have some recommended ip cams in their Re-Stream IP cam examples–or at least tell us that GeoVision has issues. I have wasted at least 15 hours on trying to get this to work.

There is a known issue with GeoVision cameras. Some of them do not properly send the RTP end of packet bit per the RTP specification. This is needed by Wowza Server.

The specification is here:

http://www.ietf.org/rfc/rfc3984.txt

---- start quote

Marker bit (M): 1 bit

Set for the very last packet of the access unit indicated by the

RTP timestamp, in line with the normal use of the M bit in video

formats, to allow an efficient playout buffer handling. For

aggregation packets (STAP and MTAP), the marker bit in the RTP

header MUST be set to the value that the marker bit of the last

NAL unit of the aggregation packet would have been if it were

transported in its own RTP packet. Decoders MAY use this bit as

an early indication of the last packet of an access unit, but MUST

NOT rely on this property.

Informative note: Only one M bit is associated with an

aggregation packet carrying multiple NAL units. Thus, if a

gateway has re-packetized an aggregation packet into several

packets, it cannot reliably set the M bit of those packets.

---- stop quote

We rely on this marker bit being set properly. It would be best to work with the camera vendor to get this addressed.

Charlie

9

Charlie,

The Wowza ‘patch’ you sent me via email fixed not only for the Flash client but also for the iOS. Both now work for our GeoVision camera.

Thanks for such a prompt support.

Meengla

10

@Webspider,

Are you sure you are in the right topic?