Wowza Logo Wowza Icon
Wowza Video Sign Out
Talk to an Expert Free Trial
Wowza Video Sign Out

Wowza Community

Push Publishing AddOn package to push stream to CDNs and service providers

Wowza Developer Dojo
#121

Thanks Deckard,

I finally get it working last night by removing the username and password in HW and in the streamname sent to HW. I did try everything on the page you reference but could get it to work.

My next question is, my source streams are mpeg ts and don’t publish themselves, so I use the StartStream.xml to start them and send them to HW. The issue is my streams are not always present, only about 40% of the time. Is there any issues in WMS (memory or other) with the StartStream.xml requesting (trying to publish) the streams every 10 to 15 seconds? Is there a alternative way to sense when an mpeg ts is present at the WMS?

Thanks

Austin

#122

I’m using rtsp announcement with PushPublish and things are working well when the encoder stops streaming thus disconnects from WMS and the PushPublish stream is closed.

I would like to lower the timeout for the RTPStream from the 90 second default but I cannot find where I can change this value. This is for when the network is dropped or the encoder doesn’t disconnect the rtsp session.

From logs:

WARN server comment - RTPStream.idle[464733206:liverepeater/definst:RTSP_22005.sdp]: Close RTSP/RTP session. Session timeout: 90000

Any help would be great

Thanks

Austin

#123

Thanks Charlie, That was the one, works great!

#124

Hello All,

I’m trying to push publish to Edgecast to a given folder

I have FMLE push working with the following settings:

FMS URL: rtmp://fso.dca.xxxx.edgecastcdn.net:1935/20xxxx/liveStream1 //xxxx is my account number

Stream: mystream?3efgt543w

I can play the above fine

In the pushPublisher I was able to get is working without specifying the path with the following:

publisher.setHostname(“fso.dca.xxxx.edgecastcdn.net”);

publisher.setDstApplicationName(“20xxxx”);

publisher.setDstStreamName(“mystream?3efgt543w”);

I can play the above fine

But when I add in the path as in below it doesn’t work, I can’t play the stream and there are not any error on the wowza side.

publisher.setHostname(“fso.dca.xxxx.edgecastcdn.net”);

publisher.setDstApplicationName(“20xxxx/liveStream1”);

publisher.setDstStreamName(“mystream?3efgt543w”);

I tried moving the path to the stream name and that did not work either.

Has anyone used push publishing to Edgecast to a specified folder?

Thanks

Austin

#125

Hello,

I’m having an issue with Metadata being passed through Edgecast to the Flash Player (FlowPlayer).

If I have the FlowPlayer requesting a stream from EC that is NOT present into wowza (encoder is stopped) and than I start the encoder the FlowPlayer sees the Metadata. But every other FlowPlayer client which connects to EC and decodes the stream doesn’t get the Metadata. Has anyone else seen this with Edgecast or other cdns? Shouldn’t the Metadata be made available for every client?

Thanks

Austin

#126

Thanks Richard but no luck, same results.

There are my setting before I push to EC:

publisher.setSendFCPublish(true);

publisher.setSendReleaseStream(true);

publisher.setSendOnMetadata(true);

publisher.setSendOriginalTimecodes(false);

#127

I’m working with Edgecast and I don’t have a stream setup 24/7 with the new values above. I’ll work on it.

On another note, I do have the pushing of custom data working. I have a timer module (based on https://www.wowza.com/docs/how-to-log-client-count-and-metadata-for-a-stream-every-10-seconds-modulelogviewercounts) in wowza which sends custom data through the EC by adding the following:

AMFDataMixedArray myData = new AMFDataMixedArray();
myData.put("delay", 4000);//ms
myData.put("timecodeAbs", new Date().getTime());
myData.put("timecodeDataRel", stream.getDataTC());
stream.sendDirect("onMyData", myData);

And I can recover it with the Flash Player. [Complete with some insight from cricel472, Thanks]

#128

Hey guys,

I’m the guy at BitGravity leading the live streaming engineering team, so I thought I’d clarify what’s going on.

We have done some limited in-house testing with the PushPublish module, and have 3 customers currently testing with it, two of whom are on this thread. :slight_smile:

As with all other methods of ingest we do testing on production equipment but on isolated (“preview”) boxes to help ensure that testing doesn’t destabilize the production gateways. For this testing it’s only the ingest server that’s isolated; the stream traffic goes through the rest of our production infrastructure exactly as if it came from a production ingest server.

Not a big surprise, but with new, untested encoders and a new ingest method there have been some issues which took down one of the the Paris preview ingest servers a few times. This is what affected Alejandro. We were not blocking his streams.

Testing has been going much better this week, and I expect to move at least some of these customers to production gateways in the next few weeks. The one area that I am still concerned about is the retry mechanism. In the case that took down Alejandro the customer’s custom encoder / PushPublish retry mechanism got out of control and basically DOS-attacked the machine. I personally haven’t gotten far enough into the setup to understand where the retries were coming from, but I’m sure we’ll have this all sorted out in the next few days. To be fair, it seems like every encoder we bring on has issues with retries, even many of the $20k rackmount appliances.

I’m very excited to have this module become available to the community. It offers a new, rich set of options to our customers to allow them to ingest different stream types and have tighter control over their stream publishing, while still being able to take advantage of our worldwide, high capacity system. Big kudos to Charlie for once again getting functionality out into the ecosystem which gives folks the flexible tools that allow them to innovate in unexpected ways.

#129

Denis,

Charlie shot me an email later. Looks like there’s enough API there to do the

exponential backoff. Please get in touch with me off-thread and cc: msmith so we can help you get this going.

I don’t have any more info on the startup-all-at-once issue. The main issue right now on our side is that the authentication requests come in all at once. I’m already caching completed auth requests from our back end, but the code doesn’t yet queue on pending results. I’ll be adding that soon, and that that point I believe we should be able to start a lot more at once, maybe 100.

At a certain point, though, something else will fall down from hundreds of simultaneous starts, so IMO we need to throttle the starts regardless of my change.

#130

s/later/earlier/ Sorry for any confusion!

#131

I got a communication out of band which brings me to clarify something here.

We have a lot of customers who broadcast many streams 24/7, so we are very sensitive to encoder reliability. As I stated in passing earlier in this thread, almost all commercial RTMP/RTSP encoders have trouble handling network errors and/or restarts of the RTMP server (“origin” in most systems, “gateway” in ours).

Sometimes the problem is that they fail to retry. Often this is inconsistent: an encoder may lull you into a false sense of security by retrying successfully a number of times in the face of intermittent network outages over a period of several days, and then an outage comes along that just stops the encoder dead, with no explanation.

Sometimes the problem is that they retry too aggressively, essentially DOS-attacking the RTMP server. We had one very expensive encoder send 10 reconnects per second indefinitely if the user’s authentication credentials were wrong. Not so good either. :wink:

In the case of the Push Publish module there are some semi-unique needs, since (unlike commercial RTMP encoders) you can push 500 streams at once, and they can all fail and attempt to reconnect at once.

We will work with our customers who are using the Push Publish module to help them put together as reliable a retry mechanism as possible, and one that won’t attack the target server. As usual, Charlie has thought through the problem enough, and made the API flexible enough, that we have what we need to get the job done.

#132

The Push Publishing API does requires more advanced Java programming skills.

Charlie ,what do you mean by that ? So , the package is not really ready for use , is it basic code ?

#133

Try this:

AMFDataMixedArray data = new AMFDataMixedArray();
data.put("caption", new AMFDataItem(capton);
stream.sendDirect("setCaption", data);

Flash client-side

// set up netstream for the callback on the live stream
nsPlayClientObj:Object = new Object();
nsPlayClientObj.setCaption = function(caption:String):void
{
trace(caption);
}
nsPlay.client = nsPlayClientObj;

Richard

We are pushing a stream from wowza server A to wowza server B using the PushPublisher package, and in addition to the stream being pushed we want to be able to send a message from server A to server B as well. If using IMediaStream.sendDirect() is the right way to do it, can you provide example code for what should be put on server B? The above example only shows how to send a message from sever A to a Flash client.

Thanks for your help in advance.

#134

Just curious,

Is there a reason you’re using PushPublisher between two wowza servers? I believe Live Stream Repeater is recommended between two wowza based CDNs. PushPublish is more for wowza to FMS/CDN. In any case I believe you need to send the info along the netstream metadata.

Cheers,

Pete

I believe the live stream repeater uses a pull mechanism to pull streams from the edge (Server B in my example) from the origin (Server A). What I am trying to do is proactively pushing a stream from Server A to server B on demand.

#135

We are pushing a stream from wowza server A to wowza server B using the PushPublisher package, and in addition to the stream being pushed we want to be able to send a message from server A to server B as well. If using IMediaStream.sendDirect() is the right way to do it, can you provide example code for what should be put on server B? The above example only shows how to send a message from sever A to a Flash client.

Thanks for your help in advance.

Can someone help? Thanks.

#136

I’ve noticed that metadata is not being passed through from source to destination? I’m not sure if this is localized or if it’s something everyone is experiencing.

#137

How are you using the package? Is it RTMP all the way through?

Richard

Yes, it is rtmp all the way through.

#138

Any updates on this? Anything that I could do in terms of testing to help or is this all plugin side?

#139

I do have an update now: We don’t push the onMetaData event. We may change this in the future but there is no short term plan to do so.

Richard

The issue is that with no metadata is when the stream is played from the CDN the player can’t properly resize because of the lack of metadata. This is apparent in full screen. I would definitely classify this as a bug. I’m not sure why the addon doesn’t pass metadata if it has to do with architecture or other issues. This is an immediate issue for us.

#140

Does anyone know where the IMediaStream object reside in the publisher? I’m trying to get access to the outgoing stream.

© 2007–2024 Wowza Media Systems™, LLC. All rights reserved.   Security & Privacy PolicyLegalSystem Status