Sounds like the session is timing out. We will have to look at this.
Charlie
We will look into it. Still working on FlashHTTP streaming. Thanks for the feedback. It could be a while before we release an updated version.
Charlie
We tested it with a single mp4 on our own Wowza server (downloaded here: http://www.wowza.com/_h264/bigbuckbunny_450.mp4).
When I test with Wowza test link: http://184.72.239.149/vod/smil:bigbuckbunny.smil/manifest.f4m
The video is not working each time I hit the preview button either. But of course I can’t see it is causing a high java load server side.
On our server the java load gets high with some player requests, and it stays high until we restart Wowza.
I see the problem. Will release a new version later today. Will post back here when it is ready.
Charlie
The new version that fixes the infinite loop problem has been posted. See the UPDATE not in the article. Re-download the package and update the lib/wms-httpstreamer-sanjosestreaming.jar file with the on in the newer package. Please let me know if this fixes your issue.
Charlie
Set the following property in both the LiveStreamPacketizers/Properties and HTTPStreamers/Properties in conf/[application]/Application.xml:
<Property>
<Name>cupertinoRelativePlaylistItems</Name>
<Value>false</Value>
<Type>Boolean</Type>
</Property>
Charlie
Flash HTTP steraming is always relative. It is only cupertino streaming that has the full URLs in the playlist.m3u8 file.
Charlie
Describe in detail your setup (encoders, OS…) so we can try to reproduce.
Charlie
Are you sure you are running 2.2.3. When I look at the version of the origin defined in this Application.xml it is 2.2.0.
Charlie
I did try your Application.xml with 2.2.3 and it works for me.
Charlie
Hmm, maybe you have an old version of the San Jose .jar file. I guess I might try a fresh install of 2.2.3. Maybe there was an issue with an upgrade.
Charlie
We installed 2.1.2 patch5 and FlashHTTP package.
When using the included video player the video plays well (but not showing video every refresh).
But when using the video player located at
We installed 2.1.2 patch5 and FlashHTTP package.
When using the included video player the video plays well (but not showing video every refresh).
But weird things happen when using the video player located at: http://www.osmf.org/configurator/fmp/
Sometimes the video plays after pushing “preview” button. But sometimes the screen is black, and on the server the java process takes 100% cpu and does not go down anymore.
Normal Wowza shutdown does not work when this happens.
I checked the “yes” box, and we did see some video.
But after a few (random) attempts, pushing the “preview” button, we are seeing a black screen, and server side a java process hangs at 100% cpu.
We tested it with a single mp4 on our own Wowza server (downloaded here: http://www.wowza.com/_h264/bigbuckbunny_450.mp4).
When I test with Wowza test link: http://184.72.239.149/vod/smil:bigbuckbunny.smil/manifest.f4m
The video is not working each time I hit the preview button either. But of course I can’t see it is causing a high java load server side.
On our server the java load gets high with some player requests, and it stays high until we restart Wowza.
It does fix java cpu load problem, super!
I understand you are still working on it, don’t know if this is useful :
- both video players only load a test-video (also your testlink) every other attempt. When it fails the console shows this info:
INFO server comment - HTTPStreamerAdapterSanJoseStreaming.canHandle[crossdomain.xml]: false
DEBUG server comment - HTTPStreamerAdapterCupertinoStreaming.canHandle[crossdomain.xml]: false
- protocol is logged as “http (cupertino)”
We are testing SanJose live streaming on 2.2.3.
Seems to work using RTMP broadcasters.
Using a RTP broadcaster, lots of errors appear and CPU load increases to 100%
java.lang.NullPointerException
at com.wowza.wms.httpstreamer.sanjosestreaming.livestreampacketizer.LiveStreamPacketizerSanJose.updatePlaylistABST(Unknown Source)
at com.wowza.wms.httpstreamer.sanjosestreaming.livestreampacketizer.LiveStreamPacketizerSanJose.updatePlaylistStr(Unknown Source)
at com.wowza.wms.httpstreamer.sanjosestreaming.livestreampacketizer.LiveStreamPacketizerSanJose.endChunkTS(Unknown Source)
at com.wowza.wms.httpstreamer.sanjosestreaming.liverepeater.SanJoseStreamerLiveRepeaterReceiver.addVideoData(Unknown Source)
at com.wowza.wms.stream.live.MediaStreamLiveAbstract.addVideoData(Unknown Source)
at com.wowza.wms.netconnection.NetConnectionProcessData.processNextRequest(Unknown Source)
at com.wowza.wms.netconnection.NetConnectionAdapter.service(Unknown Source)
at com.wowza.wms.netconnection.NetConnectionSessionHandler.serviceRequest(Unknown Source)
at com.wowza.wms.netconnection.NetConnectionSessionHandler.handleMessageReceived(Unknown Source)
at com.wowza.wms.netconnection.NetConnectionSessionHandler.messageReceived(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain$2.messageReceived(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain.access$900(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(Unknown Source)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(Unknown Source)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain.access$900(Unknown Source)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(Unknown Source)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(Unknown Source)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Looks like it is related to a specific Application.xml config, not the broadcaster type.
When I switch the StreamType in the config file below, and try with a RTMP broadcasters, same thing happens for the SanJose stream. (while the rtmp stream plays fine)
When using another application (without the sorter stuff) on the same server, SanJose does work.
Server is Linux - Debian Lenny
<Root>
<Application>
<ApplicationTimeout>500</ApplicationTimeout>
<Connections>
<AutoAccept>true</AutoAccept>
<AllowDomains></AllowDomains>
</Connections>
<Streams>
<StreamType>live</StreamType>
<StorageDir>/bla/live/rtmp/</StorageDir>
<LiveStreamPacketizers>cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer, cupertinostreamingrepeater, smoothstreamingrepeater, sanjosestreamingrepeater</LiveStreamPacketizers>
<Properties>
<Property>
<Name>sortPackets</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
<Property>
<Name>sortBufferSize</Name>
<Value>750</Value>
<Type>Integer</Type>
</Property>
</Properties>
</Streams>
<HTTPStreamers>cupertinostreaming,smoothstreaming,sanjosestreaming</HTTPStreamers>
<SharedObjects>
<StorageDir></StorageDir>
</SharedObjects>
<Client>
<IdleFrequency>-1</IdleFrequency>
<Access>
<StreamReadAccess>*</StreamReadAccess>
<StreamWriteAccess>*</StreamWriteAccess>
<StreamAudioSampleAccess></StreamAudioSampleAccess>
<StreamVideoSampleAccess></StreamVideoSampleAccess>
<SharedObjectReadAccess>*</SharedObjectReadAccess>
<SharedObjectWriteAccess>*</SharedObjectWriteAccess>
</Access>
</Client>
<RTP>
<!-- RTP/Authentication/Methods defined in Authentication.xml. Default setup includes; none, basic, digest -->
<Authentication>
<Method>none</Method>
</Authentication>
<!-- RTP/AVSyncMethod. Valid values are: senderreport, systemclock, rtptimecode -->
<AVSyncMethod>systemclock</AVSyncMethod>
<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>
<Properties>
<Property>
<Name>rtpDePacketizerWrapper</Name>
<Value>com.wowza.wms.rtp.depacketizer.RTPDePacketizerWrapperPacketSorter</Value>
</Property>
<Property>
<Name>rtpDePacketizerPacketSorterBufferTime</Name>
<Value>1500</Value>
<Type>Integer</Type>
</Property>
<Property>
<Name>rtpDePacketizerPacketSorterFlushTime</Name>
<Value>30</Value>
<Type>Integer</Type>
</Property>
<Property>
<Name>rtpDePacketizerPacketSorterLogPacketLoss</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
</Properties>
</RTP>
<Repeater>
<OriginURL>rtmp://xxxx.be</OriginURL>
</Repeater>
<Modules>
<Module>
<Name>base</Name>
<Description>Base</Description>
<Class>com.wowza.wms.module.ModuleCore</Class>
</Module>
<Module>
<Name>properties</Name>
<Description>Properties</Description>
<Class>com.wowza.wms.module.ModuleProperties</Class>
</Module>
<Module>
<Name>logging</Name>
<Description>Client Logging</Description>
<Class>com.wowza.wms.module.ModuleClientLogging</Class>
</Module>
<Module>
<Name>flvplayback</Name>
<Description>FLVPlayback</Description>
<Class>com.wowza.wms.module.ModuleFLVPlayback</Class>
</Module>
</Modules>
<Properties>
<!-- Properties defined here will be added to the IApplication.getProperties() and IApplicationInstance.getProperties() collections -->
<!--
<Property>
<Name></Name>
<Value></Value>
</Property>
-->
</Properties>
</Application>
</Root>
Yes positive: Wowza Media Server 2 Subscription 2.2.3 build26454
The origin that was defined in Application.xml is indeed running 2.2.0 but is not used in this testing setup.
If you are using the developer edition of Wowza, there are time limits on live http streaming.
Richard
Same thing here. When I played it in Flash I noticed a hiccup at about the same point, I think it must be related. Is it a shoutcast stream?
Richard
I get a freeze in exactly 30 seconds also in my test. I’ll let you know what I find out.
Richard
