Did anyone use Digital Rapids encoders with Wowza? Any input on how to set things up?
Regards,
Goran Tomas
I have. They work great. I don’t have explicit steps but I know with the latest Stream software you should be able to use the DigitalRapids H.264 and Dicas H.264 encoder using RTSP/RTP without any issue.
Charlie
I did chat with the Digital Rapids folks this morning and this issue is soon to be resolved in the next release of their software. If you contact them directly I believe they have a patch for the current version.
Charlie
I have not had a chance to test. It should resolve the issue.
Charlie
Be sure to contact Digital Rapids and be sure you are running the latest version of their software. They warned us there is an issue with the version that reports this as an issue.
Charlie
I don’t know.
Charlie
Thanks for the info. I do think there some strange AV sync issue with specific versions of the Flash player. It seems to be related to Main profile H.264 video that uses B-frames. Hard to pin down. I tell most folks to switch to Baseline and it goes away.
Charlie
Thanks for the info. I am working on a tutorial here:
http://www.wowza.com/forums/showthread.php?t=9413
It is not complete as of yet but should be soon.
Charlie
The basic instruction for an encoder using SDP files is here.
https://www.wowza.com/docs/how-to-set-up-live-streaming-using-a-native-rtp-encoder-with-sdp-file)
Be sure that the UDP ports specified in the SDP file are open on the server. After the bind statements in the logs you should see firstPacket logs statements indicating you are getting packets from the encoder. Also be sure you have set the StreamType and LiveStreamPacketizer settings properly in conf/live/Application.xml.
Re-reading your post again, if you are going to use SDP files then you don’t need to do ANNOUNCE. I might turn this off for now and focus on getting it to work using SDP files. I have had issues getting RTSP/RTP ANNOUNCE to work properly with DR encoders.
Charlie
Be sure you upgrade to Wowza 2.2.3. It should resolve this issue. It was a timecode resolution issue with RTP incoming streaming.
Charlie
Zip up conf and logs folders, and send to support@wowza.com
Include screen-shot(s) of encoder settings
Include link to this thread
Include the urls you are using to play in different clients.
Richard
Do you know if the same problem occurs with “AVC for web” codec ??
Thanks
Thanks for the reply. I wanted to warn that it’s happening to me with FMS 3.5.1 too (because I also use some kind of relay functions).
Just after the FCPublish it disconnects…
I’m going to upgrade the DR and see what happens
Digital Rapids has recently released a new version of their Stream Software (3.3.0.b22). It says the following:
RTMP Broadcast:
Added “Server with authentication” mode which uses the “generic” FMS authentication.
Allow user to specify number of retries on server connection error. Changed default number of connection attempts to 15. When reconnect count = 0, then retry indefinitely.
Added FCPublish/FCUnpublish calls to FMS streaming.
(Stream SDK: Ability to insert metadata using the web services API.)
Did anyone tested if it solves the issue with Wowza ?
From what I read in the release notes (not in 3.3 changes but in a side note in page 9):
- WARNING: The FCPublish addition means that RTMP publishing to a Wowza server no longer works. Also an RTMP relay-publish may no longer work or may need to be modified in order to get it working. NOTE: This is fixed in Stream 3.3.0.
It should be fixed. If I have the chance of testing it myself I’ll report.
I can confirm that with Digital Rapids software 3.3.0.b22 works again with relays in FMS 3.5 
We are evaluating a Digital Rapids system for encoding and streaming to Wowza. It is equipped with a DRC-1400 card and it is running the latest version of DR Stream Live software (1.3.2.b29) on Windows XP.
We have created a stream using DR AVC/Nero AAC codecs and RTP processor. We could not get the software to push the stream to Wowza through RTMP. We have noticed the following in the Stream Live Readme, p. 2:
RTMP broadcasting:
[…]
Now uses the FCPublish at the start of publishing to a Flash Media Server with the “no username or password” option. This allows the RTMP broadcast to be used with additional CDNs (for example, with Level 3).
WARNING: The FCPublish addition means that RTMP publishing to a Wowza server no longer works. Also an RTMP relay-publish may no longer work or may need to be modified in order to get it working.
What does this mean? Does Wowza implement FCPublish? If not, are there plans to implement it?
Any workarounds? Since Stream Live seems to handle RTMP with/without authentication differently, would it make sense to try the MediaSecurity addon/module?
We have also tried RTSP/RTP publishing, it works, but we have faced an A/V sync issue, so we would rather stick with RTMP at this point, in order to simplify this setup.
We are been trying the latest version of their software: Stream Live 1.3.2.b29 and Stream (FE) 3.2.1.b29. The behavior is the same on both (this is also mentioned in the Stream FE Readme).
The encoder disconnects right after sending the FCPublish command:
2010-05-12 14:59:46 EEST comment server DEBUG 200 - cmd: FCPublish - - - 23.583 - - - - - - - - - - - - - -
2010-05-12 14:59:52 EEST comment server INFO 200 - ServerHandler.exceptionCaught[[any]:1935:digital-rapids]: java.io.IOException: Connection reset by peer - - - 28.73 - - -
DR reports:
Failed to start the processor.
Processor: RTP
Unspecified error
The complete conversation log from Wowza (at debug log level) can be found here:
https://pithos.grnet.gr/pithos/rest/zmousm@grnet-hq.admin.grnet.gr/files/pub/wms_debug_access.log
It seems that DR implies this is a Wowza-specific issue (=they won’t bother fixing it) and that Wowza should support this command. What is your perspective on this?
Please see the second question as well: if we implement authentication for RTMP publishing by adding the MediaSecurity package, would this work as a workaround or would we still stumble upon this issue?
To answer my own question:
Please see the second question as well: if we implement authentication for RTMP publishing by adding the MediaSecurity package, would this work as a workaround or would we still stumble upon this issue?
No, RTMP authentication does not seem to make any difference regarding this issue.
Yes, the problem occurred while using the “Digital Rapids AVC for Web” codec profile, however the RTMP issue is linked to the “Native RTP” processor and not the “Digital Rapids AVC for web” codec profile.
We did ask DR (through the reseller) for the patch that charlie mentioned. We were given a patch and we tried it, but nothing changed.
The readme included in that patch stated the following:
Patch for RTMP broadcast in Stream 3.2.0
========================================
This patch corrects a problem where RTMP broadcasts were not connecting to some CDN servers that required the “FCPublish” call before streaming.
Note: This only affected the “Server with no password” option.
This led me to think this patch is actually the one that caused the problem in the first place, and not the one addressing the incompatibility with Wowza, as charlie mentioned.
When we reported this to DR (always through the reseller), they replied this issue is specific to the particular software version and that we could overcome it by reverting to a previous build…
We completed the evaluation using RTSP/RTP and plain RTP instead. In general it worked OK, but we could not figure out if there was an A/V sync issue after all:
The multicast RTP coming from the DR box was synchronized when playing in VLC, but when served by Wowza audio occasionally seemed to drift ahead of video. The drift was mostly noticed in some flash players but was less noticeable or did not appear at all for RTSP (VLC), Apple HTTP (iPhone) or Microsoft HTTP clients.
Since the problem was not reproducible, we could not draw any definite conclusion about it.
(apologies for the late reply)
