I am getting this error when trying to cross from one server to another. I have tried both domains and IP’s. issues reside. Systems are within the same subnet. Also, I have tried it on the public-facing development side.
Webserver:
http://10.1.95.36
https://10.1.95.36
Media Server:
http://10.10.1.19:1935
https://10.10.1.19
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://10.10.1.19:1935/vod/mp4:sample.mp4/manifest.mpd. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://10.10.1.19/vod/smil:sample.smil/manifest.mpd (Reason: CORS request did not succeed).
Logs
HTTPStreamerMPEGDashIndex.indexFile[vod/definst/mp4:sample.mp4]: there are no segments available
MediaReaderFactory.getInstance : java.lang.ClassCastException: com.wowza.wms.mediareader.smil.MediaListReaderSMIL cannot be cast to com.wowza.wms.stream.IMediaReader|at com.wowza.wms.stream.MediaReaderFactory.getInstance(MediaReaderFactory.java:19)|at com.wowza.wms.stream.file.PlaylistPlayer.a(PlaylistPlayer.java:574)|at com.wowza.wms.stream.file.PlaylistPlayer.b(PlaylistPlayer.java:568)|at com.wowza.wms.stream.file.PlaylistPlayer.play(PlaylistPlayer.java:773)|at com.wowza.wms.stream.file.MediaStreamFilePlay.play(MediaStreamFilePlay.java:111)|at com.wowza.wms.response.ResponseStreams.output(ResponseStreams.java:51)|at com.wowza.wms.request.RTMPRequestAdapter.service(RTMPRequestAdapter.java:671)|at com.wowza.wms.server.ServerHandler.a(ServerHandler.java:725)|at com.wowza.wms.server.ServerHandler.a(ServerHandler.java:448)|at com.wowza.wms.server.ServerHandler.sessionIdle(ServerHandler.java:602)|at com.wowza.wms.server.ServerHandlerThreadedSession.run(ServerHandlerThreadedSession.java:112)|at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)|at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)|at java.base/java.lang.Thread.run(Unknown Source)|
if I use this:
/vod/mp4:sample.mp4/playlist.m3u8
it works across origins
but if I use:
vod/mp4:sample.mp4/manifest.mpd
It has an issue
Is this going to be fixed?
One thing you can check that has solved this for people who get this error and maybe manually configured this in the xml is to go into [install-dir]/conf/live/Application.xml
and make sure the name has an “s” on the end for cupertinoUserHTTPHeaders. Some support tickets we’ve gotten for this error only have it as "header"without the “s” and they get that specific error. If that looks good, please send the ticket, the engineers would like to take a closer look for you.
<Property>
<Name>cupertinoUserHTTPHeaders</Name>
<Value>Access-Control-Allow-Origin: *</Value>
</Property>
ps aux | sort -rnk 4 | head -1
root 1041 10.0 985.75 985758360 460036 ? Sl 16:53 1:12 /usr/local/WowzaStreamingEngine/java/bin/java -cp :/usr/local/WowzaStreamingEngine/manager/lib/lib-jaxb/FastInfoset-1.2.13.jar:/usr/local/WowzaStreamingEngine/manager/lib/lib-jaxb/istack-commons-runtime-3.0.5.jar:
Tech support also wants to know what version of Engine you’re using here. Is it 4.8.5?
It is the JRE eating it up. I can look at the processes and memory consumption using
ps aux | sort -rnk 4 | head -3.
4.8.5 (build 20200616153358)
Thank you, I will give this a shot. On our Lambda servers, we have 96 cores with 1tb of ram, 10 kingpin video cards, 40tb of PCIe direct storage for video, and 512gb of SSD for the OS. Our virtual servers run on dell r740’s with 96 cores but no graphics cards with nimble storage for the OS then direct attach 6gbps SSD’s for the media.
I will keep you posted
I have applied the patch, rebooted, and now we’re down to normal memory consumption. I will let it run for a couple of days and keep you informed.
Also, I have already looked at that file. Again, it works with HLS but it has an issue with DASH. Sometime’s it will work, then all of a sudden it will stop working. And, if you use cross-platform it works in HLS not DASH
We have noticed that the JRE will consume all 1tb of free RAM on our server. We are running CentOS Linux release 7.8.2003 (Core)
Wow @Robert Sexton! The engineers said to check the heap in the Engine UI. if the Wowza heap in the manager shows low compared to memory - it is not Wowza eating that up.
They’re also on the lookout for a ticket from you so they can test this and find out what’s happening here. I didn’t see one from your name or email address just yet in our ticket system.
ffmpeg -i video.mp4 -crf 18 -c:a libfdk_aac -b:a 192k -s 3840X2160 -b:v 2M -maxrate 2M -bufsize 1M -r 30 -tune film -preset veryslow -movflags +faststart video-2160.mp4
-crf 18 -c:a libfdk_aac -b:a 192k -s 2560x1440 -b:v 1M -maxrate 1M -bufsize 512K -r 30 -tune film -preset veryslow -movflags +faststart video-1440.mp4 \
even on our development server that has 8gb of ram, it’s sucking it up too. same OS.
root 1041 5.8 7.7 7761442 463044 ? Sl 16:53 1:17 /usr/local/WowzaStreamingEngine/java/bin/java -cp :/usr/local/WowzaStreamingEngine/manager/lib/lib-jaxb/FastInfoset-1.2.13.jar:/usr/local/WowzaStreamingEngine/manager/lib/lib-jaxb/istack-commons-runtime-3.0.5.jar
Both Java heap settings are:
VM Dev - 4096 <— Built in Dell r740 intel video
HD Dev - 32768 <— 10 nVidia Kingpin 8gb video cards
I cannot give access to our servers yet. I can provide logs but I will have to remove the files. There are files on these that we not allowed to let people access that we have been testing. We are also encoding with Adobe and FFmpeg
-crf 18 -c:a libfdk_aac -b:a 192k -s 1920x1080 -b:v 512K -maxrate 512K -bufsize 256K -r 30 -tune film -preset veryslow -movflags +faststart video-1080.mp4
-crf 18 -c:a libfdk_aac -b:a 160k -s 1280x720 -b:v 256K -maxrate 256K -bufsize 128K -r 30 -tune film -preset veryslow -movflags +faststart video-720.mp4 \
-crf 18 -c:a libfdk_aac -b:a 128k -s 854x480 -b:v 192K -maxrate 192K -bufsize 96K -r 30 -tune film -preset veryslow -movflags +faststart video-480.mp4
-crf 18 -c:a libfdk_aac -b:a 112k -s 640x360 -b:v 128K -maxrate 128K -bufsize 64K -r 30 -tune film -preset veryslow -movflags +faststart video-360.mp4
-crf 18 -c:a libfdk_aac -b:a 112k -s 426x240 -b:v 96K -maxrate 96K -bufsize 48K -r 30 -tune film -preset veryslow -movflags +faststart video-240.mp4
[root@stream bin]# ./java -version
openjdk version “9.0.4”
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
Does this have to be the version of JRE running? Why not 11? It has better heap management.