Known issues with Wowza Streaming Engine

Affected versions: WSE 4.8.20

Fixed in: Not yet fixed

Symptoms: If the dimensions (height and width) of an image are an even/odd or odd/even number of pixels, then scaling will fail. WSE Manager shows an error:

sum of image Width and Height must be an even number.

Workaround: Change the dimensions to either an odd or even number of pixels such that the sum of pixels is even. You can do this by cropping the original image.

Affected versions: WSE 4.8.19

Fixed in: Not yet fixed

Symptoms: If you use Digest with Cleartext, you receive a failure to log in message.

Cause: In WSE 4.8.19, SHA-256 compatibility was added to update security standards. Because of the update, Cleartext is not compatible with Digest authentication out of the box.

Workaround: There are two workarounds for this issue:

1. For a more secure method, follow this - If you use Digest with Cleartext and receive a failure to log in message, update your password encoding scheme to use SHA-256 in the [install-dir]/conf/Server.xml file and restart Wowza Streaming Engine to log in. For more information on this method, check this article.
2. You can also configure plaintext password using the below properties in [install-dir/conf/Server.xml]:

   <AuthenticationMethod>basic</AuthenticationMethod>
   <PasswordEncodingScheme>cleartext</PasswordEncodingScheme>

   This method is less secure because the password is in plaintext.

Affected versions: WSE 4.8.18 and later

Fixed in: Not yet fixed

Symptoms: A conflict occurs if you need to import classes from jakarta.xml.bind-api.

Cause: In WSE 4.8.18 and later, the jaxb-core and jaxb-runtime jars were updated to version 3.0.2 from version 2.3.3.

Workaround: If you use these classes, we recommend running WSE 4.8.17 instead. We don’t recommend manually updating the JAR file because it may impact other sections of the workflow.

Third-party issue

Affected versions: WSE 4.8.8.01 and later

Fixed in: Although WSE 4.8.17 upgrades to Apache Log4j 2.16.0 to fix CVE-2021-44228 and CVE-2021-45046, it does not fix CVE-2021-45105, which is fixed in Apache Log4j 2.17.0.

Symptoms: Logging in WSE uses a version of Apache Log4j2 with a security vulnerability (CVE-2021-44228) involving JNDI functionality that is not protected against attacker-controlled LDAP and other JNDI-related endpoints.

In addition, steps to mitigate CVE-2021-44228 in Apache Log4j 2.15.0 and 2.16.0 did not fully address security vulnerabilities. These issues are captured in CVE-2021-45046 and CVE-2021-45105.

Workaround: We recommend WSE customers take action to address the recent Apache Log4j2 vulnerabilities by using our Log4j2 updater to get the latest Log4j2 files: see Update to fix Apache Log4j2 security vulnerabilities to get the updater and for information about running it.

Note: You do not need to update to WSE 4.8.17 to get the latest fixes for Apache Log4j2-related issues.

Addressing recent Apache Log4j2 issues is a dynamic situation that we will continue to respond to based on Apache updates.

Affected versions: WSE 4.7.8

Fixed in: Not yet fixed

Symptoms: There is a problem with the Facebook stream target destination in WSE 4.7.8 that breaks the ability to send streams to Facebook when WSE is running on some versions of CentOS.

Workaround: You may be able to use the generic RTMP stream target destination type to send streams to Facebook. For more information, see Use RTMP to distribute live streams.

Affected versions: WSE 4.7.0

Fixed in: Not yet fixed

Symptoms: If you have configured WSE Manager to use a secure socket layer (SSL) certificate so that you can connect using HTTPS, that configuration is lost during the update.

Cause: Updating to WSE 4.7.0 overwrites the startmgr.bat (Windows) or startmgr.sh (Linux) file.

Workaround: After you have successfully updated to WSE 4.7.0, follow the instructions in How to connect to WSE Manager over HTTPS to reconfigure HTTPS connections.

Affected versions: WSE 4.3.0-4.4.1 (updater versions 4.3.0, 4.3.0.01, 4.3.0.02, 4.3.003, 4.4.0, 4.4.0.01, and 4.4.1)

Fixed in: Not yet fixed

Symptoms: After you uninstall one of these updater versions, you may see a message that indicates your updater uninstall may have failed:

A required action of the update failed. The update did not complete successfully, see the wowzastreamingengine_update.log for details.

Workaround: This message can be misleading. Check for the following message. If it's present, your updater uninstall completed successfully:

Restoration complete

Fixed in: Not yet fixed

Symptoms: When the REST API makes a PUT request to modify the parameter cupertinoChunkDurationTarget, it recognizes the path for live applications, but does not recognize the path for VOD applications.

Workaround: Rename the parameter to CupertinoChunkDurationTargetVOD so that it differentiates between the live and VOD application paths.

Fixed in: Load balancer module build 17278+. The load balancer SSL connection issue has been resolved. It is no longer necessary to roll back to a previous version of WSE. Customers who have experienced this issue will want to ensure they have installed latest load balancer module (build 17278+) for resolution.

Symptoms: The load balancer stops working when configured for SSL.

Fixed in: Not yet fixed

Symptoms: WSE can crash when starting and stopping stream publishing frequently and using Beamr encoding or decoding. Depending on the amount of RAM, this may only occur after starting and stopping the stream frequently for many hours or multiple days.

Cause: Insufficient physical memory (RAM).

Workaround: On Linux, limiting the number of arenas allowed per CPU core can prevent this issue. See Optimize Transcoder Memory Utilization (Linux Only) for more information.

Fixed in: Not yet fixed

Symptoms: If you've enabled secure sockets layer (SSL) security for the WSE REST API, you may see the following warning statement in the logs even though the REST API queries are working properly:

WARNING: An error occurred during the communication with the remote HTTP server.

Workaround: Disregard the erroneous log statements and use the WSE REST API as intended. No workaround is needed.

Third-party issue

Fixed in: Not yet fixed

Symptoms: When running WSE virtual machines on Azure Marketplace, the WSE software may start after some delay. After startup, WSE Manager may display the virtual machine's private IP address, instead of the public IP address, on the Home, Sources (Live), and Test Playback pages.

Cause: These problems are caused by the way in which Azure Marketplace processes variable lookup metadata.

Workaround: Future Azure Marketplace releases may optimize how variable lookup metadata is reported in the Azure platform. To permanently display the public IP address in WSE Manager, do the following:

1. Connect to your virtual machine (Windows connection instructions | Linux connection instructions).
2. Open the [install-dir]/conf/VHost.xml] file in a text editor and replace the <Manager>/<TestPlayer>/<IpAddress> value (${com.wowza.video.platform.PLATFORM_METADATA_EXTERNAL_IP}) with your virtual machine's public IP address:

   <Manager>
   	<TestPlayer>
   		<IpAddress>[wowza-vm-public-ip-address]</IpAddress> <!--changed for default video install. -->
   		<Port>${com.wowza.wms.HostPort.FirstStreamingPort}</Port>
   		<SSLEnable>${com.wowza.wms.HostPort.SSLEnable}</SSLEnable>
   	</TestPlayer>
   	<!-- Properties defined are used by the Manager -->
   	<Properties>
   	</Properties>
   </Manager>

3. If you were signed in to WSE Manager, sign out, and then sign in again.

The Home, Sources (Live), and Test Playback pages in the manager should display the virtual machine's public IP address.

Third-party issue

Affected versions: Ubuntu 15.04

Fixed in: Not yet fixed

Symptoms: WSE services on Ubuntu 15.04 fail as part of the installation and don't start automatically.

Cause: This appears to be related to the recent move by Ubuntu from upstart to systemd (see SystemdForUpstartUsers).

Workaround: Do ONE of the following:

• Start WSE manually by running the following as root:

  # /etc/init.d/WowzaStreamingEngine start
  
  # /etc/init.d/WowzaStreamingEngineManager start

• Reinstall the missing upstart functionality, which should ensure that WSE services are restarted on reboots:

  # apt-get install upstart-sysv

Third-party issue

Fixed in: Not yet fixed

Symptoms: WSE services fail to start--either as legacy init.d scripts or as systemd services--after Linux is updated. We've observed this with Centos 7.2 updates.

Workaround: Create the following service files:

/usr/lib/systemd/system/WowzaStreamingEngine.service

[Unit]
Description=WowzaStreamingEngine
After=syslog.target
After=network.target
After=local-fs.target
After=remote-fs.target

[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/WowzaStreamingEngine/bin/WowzaStreamingEngine start
ExecStop=/usr/local/WowzaStreamingEngine/bin/WowzaStreamingEngine start
RemainAfterExit=yes

# Give a reasonable amount of time for the server to start up/shut down
TimeoutSec=300

[Install]
WantedBy=multi-user.target

/usr/lib/systemd/system/WowzaStreamingEngineManager.service

[Unit]
Description=WowzaStreamingEngineManager
After=syslog.target
After=network.target
After=local-fs.target
After=remote-fs.target

[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/WowzaStreamingEngine/manager/bin/WowzaStreamingEngineManager start
ExecStop=/usr/local/WowzaStreamingEngine/manager/bin/WowzaStreamingEngineManager start
RemainAfterExit=yes

# Give a reasonable amount of time for the server to start up/shut down
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Enable services

systemctl daemon-reload
systemctl enable WowzaStreamingEngine.service
systemctl enable WowzaStreamingEngineManager.service

Start new services

systemctl start WowzaStreamingEngine.service
systemctl start WowzaStreamingEngineManager.service

Fixed in: Not yet fixed

Symptoms: Some antivirus tools report "Found Luhe.Fiha.AN" in Windows Installer (.msi) files for WSE software.

Cause: We believe this to be a false positive. Customers haven't reported any problems.

Third-party issue

Affected versions: Java Runtime Environment (JRE) 8u78 and greater, when you use your own JRE

Fixed in: Not yet fixed

Symptoms: If you use your own Java Runtime Environment (JRE) (8u78 and greater) with WSE, you may not be able to start WSE Manager.

You may also encounter an instability issue related to Java settings and see an error message similar to the following:

500 error is thrown: "Sorry there was an error getting to (server/performance/javasettings/edit.htm):
Internal Server Error:500"

Workaround: If you use your own JRE, you can install an earlier JRE version that doesn't have these issues (see Manually install and troubleshoot Java on WSE) or you can run the latest WSE installer, which has an earlier version of the JRE. We'll monitor the Java updates and update this article with the latest findings.

Fixed in: Not yet fixed

Symptoms: If you use a text editor to add properties to WSE XML configuration files, you can't edit the property in WSE Manager if the property name or value has a leading (or trailing) blank space. For example, if you add the following property that has leading blank space in its name to an XML file:

<Property>
	<Name>  myCustomProperty</Name>
	<Value>12345</Value>
	<Type>String</Type>
</Property>

When WSE Manager starts, it will load the XML file, and then remove the leading blank space from the property name that it displays in its user interface. (It does this because leading and trailing blank spaces are a common source of configuration errors.) For the example property above, the manager will display this as myCustomProperty in its UI.

If you try to edit myCustomProperty in the manager, the property will be saved as a new property to the XML file.

<Property>
	<Name>  myCustomProperty</Name>
	<Value>12345</Value>
	<Type>String</Type>
</Property>
<Property>
	<Name>myCustomProperty</Name>
	<Value>67890</Value>
	<Type>String</Type>
</Property>

Workaround: If your media server configuration requires a property with a leading or trailing blank space in its name or value, you must always edit this property in the configuration XML file using a text editor.

Third-party issue

Fixed in: Not yet fixed

Symptoms: The Matrox Monarch HD encoder sends metadata with encoded streams that goes through WSE but can't be processed when received by an Akamai RTMP CDN endpoint.

Workaround: Add a custom property to the stream target that instructs the target to ignore the problematic metadata.

Note: Creating custom properties for a stream target requires an administrator user with advanced permissions.

1. In WSE Manager, select the live application that uses the Matrox Monarch encoder and the Akamai RTMP stream target.
2. In the contents panel, click Stream Targets.
3. Select the stream target that's sending the stream to Akamai.
4. Click the Custom tab, click Edit, and then click Add Custom Property.
5. In the Add Custom Property dialog box, specify:
   • Name - removeMetadataObjects
   • Type - Boolean
   • Value - true
6. Click Add and then click Save.

Affected versions: WSE 4.12.0 build 20260929182413

Fixed in: WSE 4.12.0 build 20261005183231. Update your WSE instance using the WSE 4.12.1 updater.

Symptoms: WebRTC data channels fail silently.

Cause: The WSE 4.12.0 build 20260929182413 update failed to copy the sctp4j-1.0.7.jar file to the WSE instance.

Workaround: Manually copy the sctp4j-1.0.7.jar file from the updater package to your WSE instance's [install-dir]/lib directory.

Affected versions: WSE 4.9.0 and later

Fixed in: Not yet fixed

Symptoms: Akamai stream targets haven't yet been certified with WSE 4.9.0 and later.

Workaround: If you're using WSE to send live streams to the Akamai HD network for distributed delivery, use WSE 4.8.28 or earlier.

Affected versions: WSE 4.8.25 and earlier

Fixed in: WSE 4.8.26

Symptoms: Stream targets fail to connect to Facebook business pages.

Cause: The onlyMe privacy permission is set by default when the Facebook stream target is created.

Workaround: To avoid this issue on earlier versions of WSE, follow these steps when creating the Facebook stream target:

1. Select MyTimeline from the Video Destination dropdown.
2. Set the privacy to anything other than the onlyMe option.
3. Select Page from the Video Destination dropdown.
4. Save the stream target.

Affected versions: WSE 4.8.22

Fixed in: WSE 4.8.23

Symptoms: You won't be able to use a connection code to send a stream from WSE to Wowza Video. If you try, you'll see the stream target in WSE stays in a Waiting state.

Workaround: Use a custom RTMP stream target instead.

Affected versions: WSE 4.8.19 through 4.8.20

Fixed in: WSE 4.8.21. We recommend upgrading to resolve this issue.

Symptoms: If the Server.xml file is not configured correctly, anyone can log in to WSE Manager GUI with any random username and password.

Affected versions: WSE 4.8.13 and later

Fixed in: WSE 4.8.15 and later

Symptoms: Some live and VOD sources with H.264 video fail upon publishing or playback due to a decoding error. The error is logged with a message similar to the following:

ERROR 500 - H264Utils.decodeAVCC : java.lang.Exception: Expected to parse SPS of length 28 bytes, but 16 bits remained

Affected versions: WSE 4.7.7 and earlier

Fixed in: WSE 4.7.8 and later provides a 64-bit executable installer, making WSE installations compatible with macOS Catalina.

Symptoms: New instances of WSE can't be installed on macOS Catalina.

Cause: The installer is a 32-bit executable. macOS Catalina requires 64-bit executables.

Affected versions: WSE 4.7.3 and 4.7.4

Fixed in: WSE 4.7.5 and later, where the updater checks for Java version 1.7.0 or higher.

Symptoms: When updating WSE software to version 4.7.3 or 4.7.4, it checks for Java version 1.6.0 or later. However, Java version 1.7.0 is the minimum required version.

Note: You still must use Java version 1.7.0 - 1.8.0_77 or use the Java version that is installed with WSE software (Oracle Java 1.8.0_77). Versions newer than 1.8.0_77 aren't supported. For more information, see Download and install Java.

Affected versions: WSE 4.7.4

Fixed in: WSE 4.7.5 and later

Symptoms: The Stream Target functionality that enables you to send streams to Wowza Video for transcoding and delivery to users may not work.

Note: This problem is limited to the Wowza Video target destination when configured for Wowza Video to transcode the stream. All other configurations of the Wowza Video and Wowza CDN stream targets work as expected in Wowza Streaming Engine 4.7.4.

Affected versions: WSE 4.5.0

Fixed in: The latest updater for WSE software. Install the latest updater for Wowza Streaming Engine software, which has a fix for this issue.

Symptoms: WSE 4.5.0 software has an error that prevents the SHOUTcast and Icecast stream targets from working.

Fixed in: WSE 4.8.12 and later

Symptoms: With SRTP-based video sources (WebRTC or RTSP), HLS enabled (cupertinostreamingpacketizer), and large amounts of lost or out-of-order packets, the HLS packetizer can stop creating segments due to SRTP authentication and decryption failures and cause a slow memory leak. WSE logs indicate SRTP failures with the following message:

SRTP authentication failed

Workaround: To sort out-of-order packets for UDP transports, see Turn on an RTP jitter buffer and packet loss logging (RTP and MPEG-TS) or Set up WebRTC streaming.

Third-party issue

Fixed in: WSE 4.8.8.01

Symptoms: Publishing streams to Facebook using the Facebook Live stream target fails.

Cause: A change in the Facebook Graph API to deprecate the save_vod parameter for some requests.

Workaround: You can publish streams to Facebook using the generic RTMP stream target and enabling RTMPS for the stream target by adding "sendSSL":"true" to the generic RTMP stream target entry in the PushPublishMap.txt file. See Use RTMP to distribute live streams for more information.

Affected versions: Some versions of WSE

Fixed in: WSE 4.7.6

Symptoms: When publishing a stream to a multicast group, an IGMP join group message was also sent. The IGMP message results in unnecessary traffic on the network and may result in packet loss issues as well.

Note: If, for some reason, you would like to continue sending IGMP join group messages with Wowza Streaming Engine 4.7.5.01 and later, you can configure the sendIGMPJoinMsgWhenPublishing property To enable the behavior of previous Wowza Streaming Engine releases, do the following:

1. In Wowza Streaming Engine Manager, click the Server tab and select Virtual Host Setup in the contents panel.
2. In the details page, click the Properties tab, and then click Outgoing RTP Datagram in the Quick Links bar.
3. In the Outgoing RTP Datagram section, click Edit.
4. Change the sendIGMPJoinMsgWhenPublishing value to true and then click Save. (The default value is false.)
5. Restart the server when prompted to apply the changes.

Third-party issue

Fixed in: WSE 4.7.0 and later. See How to update your Wowza Streaming Engine installation.

Symptoms: The NSSM service manager can't open a console window when trying to start WSE services. This error may appear after a recent Windows 10 update.

Workaround: If you can't or don't want to update your media server software, do the following:

1. Open an elevated Command Prompt window (press the Windows Logo+X keys, and then click Command Prompt (Admin) on the power user menu).
2. In the Command Prompt window, navigate to a WSE installation bin folder that has an NSSM EXE file installed. There are two possible locations: [install-dir]/bin and [install-dir]/manager/bin.
3. Run the following commands:

   nssm set [wowza-streaming-engine-service-name] AppNoConsole 1
   nssm set [wowza-streaming-engine-manager-service-name] AppNoConsole 1

You must use properly formatted service names in these commands. To get the service names, open the Services control panel (press the Windows Logo+R keys, and then type services.msc in the Run dialog box), right-click the Wowza Streaming Engine and Wowza Streaming Engine Manager services in the list, and then click Properties. The service name to use will be highlighted on the General tab in the Properties dialog box.

Example commands for WSE 4.6.0

nssm set WowzaStreamingEngine460 AppNoConsole 1
nssm set WowzaStreamingEngineManager460 AppNoConsole 1

Fixed in: WSE 4.7.0 and later includes Wowza CPU calculation improvements to address this issue.

Symptoms: If you deploy WSE media server software in the cloud, and then log into the web-based WSE Manager on the cloud-hosted virtual machine, the Usage graph in the manager may display a higher Wowza CPU value than the actual media server CPU usage. Refreshing the manager webpage may boost the Wowza CPU graph so that it's even more out-of-sync from actual CPU consumption.

Workaround: To view Wowza CPU consumption:

• Windows - Look at the running Java.exe processes in Windows Task Manager (be sure to Show processes from all users).
• Linux - Run the following grep command to display running Java processes and filters for Java processes:

  PS - ef  | grep java*

  Then, to see the CPU usage for a particular Java process, run the top command using the Java process identifier (PID).

Affected versions: WSE 4.8.14 (Windows, updated using the updater)

Fixed in: Not yet fixed

Symptoms: If you use the updater to update to WSE 4.8.14 on Windows, when the transcoder starts, Access logs (wowzastreamingengine_access.log) report warnings about missing transcoder library files. These warnings can be ignored as transcoding is not affected and continues normally.

WARN 200 - TranscoderSessionNative.loadLibrary: File is missing: C:/Program Files (x86)/Wowza Media Systems/Wowza Streaming Engine 4.8.13+1/lib-native/win64/mc_bc_dec_avc.dll
WARN 200 - TranscoderSessionNative.loadLibrary: File is missing: C:/Program Files (x86)/Wowza Media Systems/Wowza Streaming Engine 4.8.13+1/lib-native/win64/mc_dec_hevc.dll
WARN 200 - TranscoderSessionNative.loadLibrary: File is missing: C:/Program Files (x86)/Wowza Media Systems/Wowza Streaming Engine 4.8.13+1/lib-native/win64/mc_enc_avc.dll
WARN 200 - TranscoderSessionNative.loadLibrary: File is missing: C:/Program Files (x86)/Wowza Media Systems/Wowza Streaming Engine 4.8.13+1/lib-native/win64/mc_enc_hevc.dll

Workaround: To remove the warning logs, complete the following steps:

1. Navigate to the [install-dir]\lib-native\win64 directory and open transcoder.list in a text editor.
2. Delete the following lines:

   mc_bc_dec_avc.dll
   mc_dec_hevc.dll
   mc_enc_avc.dll
   mc_enc_hevc.dll

3. Save your changes and then restart Wowza Streaming Engine.

Affected versions: WSE 4.7.5 and 4.7.8

Fixed in: Not yet fixed for WSE 4.7.8, which doesn't support CentOS 6. For WSE 4.7.5, the best solution is to update to Wowza Streaming Engine versions 4.7.5.01 - 4.7.7.

Symptoms: Wowza Transcoder doesn't work in some versions of WSE on CentOS 6.

Cause: WSE 4.7.8

WSE 4.7.8 included changes to the minimum supported versions of some of the libraries used by Wowza Transcoder. For example, GNU C Library (glibc) 2.17 is now the minimum supported version.

WSE 4.7.5

WSE 4.7.5 included changes to some of the libraries used by Wowza Transcoder, including updating the GNU C Library (glibc) to version 2.14. However, CentOS 6.9 doesn't support glibc 2.14. This means Wowza Transcoder doesn't work on CentOS 6.9 with WSE 4.7.5.

Workaround: WSE 4.7.8

Update to a version of CentOS that supports glibc version 2.17 or later.

WSE 4.7.5

Alternatively, you can update to CentOS 7, which supports glibc 2.14 and would enable you to use the fixes and new features in WSE 4.7.5.

If you can't update to CentOS 7 and need to use Wowza Transcoder, don't update to WSE version 4.7.5. Earlier versions of WSE media server software use glibc 2.12, which is supported by CentOS 6.9.

• If you're installing WSE for the first time, request a copy of the WSE 4.7.4 installer package.
• If you've already updated to WSE 4.7.5, follow the instructions in Remove an update on Linux to remove the 4.7.5 update and revert to an earlier version of the media server software.

Affected versions: WSE 4.5.0.01 and 4.5.0.02

Fixed in: WSE 4.6.0

Symptoms: If you include graphic overlay images when transcoding streams and you set the overlay opacity value to less than 100 (completely opaque), or you use a file for your overlay image that was originally created with less than 100 percent opacity, a memory leak occurs. Our findings also show that the memory leak is larger for larger overlay image files.

Fixed in: Not yet fixed

Symptoms: If you transcode MPEG-1 Audio Layer II to AAC, you may experience the audio and video drifting out of sync. When transcoding the audio, you may see a log similar to the following:

INFO server comment - JNI:TranscoderSession.audioDecoderCreate[_defaultVHost_:live/_definst_/mpegtsstream.stream]: Create audio decoder: MPEG1 Part 1/2: default INFO transcoder decoder-audio-start mpegtsstream.stream {"codec":"MP3", "objectType":"MPEG1LAYER2", "sampleRate":48000, "channels":2}

Workaround: Add a custom property to the Transcoder template that instructs the transcoder to transcode to HE-AAC instead of AAC.

1. Open the transcoder template XML file that you're using, such as [install-dir]/transcoder/templates/transcode.xml, in a text editor and add the following property to the <Encode>/<Audio>/<Parameters> section.

   <Parameter>
       <Name>mainconcept.he</Name>
       <Value>2</Value>
       <Type>Integer</Type>
   </Parameter>

2. Save the file and restart incoming stream to pick up the Transcoder template changes.

Third-party issue

Fixed in: Not yet fixed

Symptoms: NVIDIA accelerated decoding fails on Windows 10 with Java 8. The failure occurs when you use CUDA or NVCUVID acceleration for decoding. (NVENC acceleration seems to work.)

Workaround: Use Java 7 on Windows 10 to avoid this issue. For information on installing Java, see Manually install and troubleshoot Java. NVIDIA is investigating this issue.

Affected versions: WSE 4.8.24 - 4.8.26

Fixed in: WSE 4.8.27. The Wowza Video Transcoder workflow was replaced in WSE 4.8.27.

Symptoms: Wowza Video Transcoder stream targets using connection codes fail to start stream targets correctly. This can trigger the transcoder to start unnecessarily in Wowza Video and impact billing.

Workaround: For existing configurations, we recommend rolling back to version 4.8.23.

Affected versions: WSE 4.8.14 and later

Fixed in: WSE 4.9.3

Symptoms: With NVIDIA GPU-acclerated transcoding, GPU performance is lower than with previous versions of Wowza Streaming Engine. Logs show repeated SKIP1FRAME and ALLFRAMESOFF messages as a result.

Affected versions: WSE 4.8.14

Fixed in: WSE 4.8.15

Symptoms: When using graphic overlays and the CUDA scaling implementation for NVIDIA GPU-accelerated transcoding on a Windows system, the overlay images can flicker or appear transparent.

Affected versions: WSE 4.8.13 and earlier

Fixed in: WSE 4.8.14, which upgraded CUDA support to CUDA 11 and supports NVIDIA drivers 460.00 and later.

Symptoms: WSE does not work with NVIDIA drivers that support CUDA 11.

Workaround: If you are using an earlier version of WSE, install an NVIDIA driver that supports CUDA 10, such as version 440. See the NVIDIA documentation for installation instructions.

Affected versions: WSE 4.2.0

Fixed in: The latest WSE software update. To get this update, sign in to your Account Management page using your Wowza account and then check the Downloads tab. You must have an active Maintenance and Support contract to receive updates.

Symptoms: An issue in WSE 4.2.0 software prevents NVIDIA hardware from being recognized; therefore, NVIDIA NVENC hardware-accelerated encoding can't be enabled for Transcoder.

Third-party issue

Affected versions: iOS 15 and later

Fixed in: Not yet fixed

Symptoms: We previously noticed an issue related to devices running iOS15+ that caused WebRTC publishing to fail in Wowza Streaming Engine. Reported errors include a WebSocket Connection Failed message.

Cause: Our initial investigation led us to believe this was due to Apple's WebSocket fragmentation. After further exploration, we believe this issue is connected to the NSURLSession WebSocket experimental feature from Apple. For a workaround, check the following solution.

Workaround: To circumvent this problem and publish the WebRTC stream:

1. Go to Safari > Settings > Advanced.
2. Enable Show Develop menu in menu bar.
3. From Develop in the menu bar, go to Experimental Features and disable the NSURLSession WebSocket feature.

Alternatively, see this related resolved playback issue and download our published solution here.

Third-party issue

Affected versions: iOS 7 and iOS 8 native players

Fixed in: Not yet fixed. Bug 19179149 is open in the Apple Radar bug reporting tool. Last tested with iOS 8.3.

Symptoms: A CEA-608 caption that has exactly 32 characters and is sent as part of the video NAL units is displayed incorrectly. This doesn't occur if the caption has 31 or 33 characters.

Fixed in: Not yet fixed

Symptoms: When using the DASH-IF reference player (dash.js) and Google Chrome, DASH streams may play for a while and then start looping on a single media segment.

Workaround: We recommend that you use either the Google Shaka player or the Bitmovin Adaptive Streaming Player to play DASH streams. These players seem to have better compatibility with Wowza Streaming Engine MPEG-DASH streams.

Fixed in: Not yet fixed

Symptoms: WebRTC source streams, including those with H.264 video, that are transcoded for adaptive bitrate streaming with Video Codec set to Passthrough encounter playback issues over MPEG-TS HLS (cupertinostreamingpacketizer).

Workaround: You can transcode the video by setting Video Codec to another codec, rather than Passthrough, to avoid this issue.

Affected versions: Safari on iOS 15

Fixed in: The fix is to download our published example from here.

Symptoms: Publishing or playing a WebRTC stream using Safari on iOS 15 fails. With the Wowza Streaming Engine WebRTC test pages, you get the following error message:

WebSocket connection to ‘wss://[address]:443/webrtc-session.json’ failed. The operation could not be completed. Socket is not connected.

Third-party issue

Affected versions: iOS 8

Fixed in: iOS 12

Symptoms: Live streams with DVR enabled by Wowza nDVR may not start playback on iOS 8 devices.

Workaround: If you encounter this issue on your iOS 8-based player, you can either touch and hold the Rewind button to start playback immediately or wait for about 30 seconds for playback to start.

Note: This problem doesn't occur on iOS 7 (or earlier).

Third-party issue

Affected versions: JW Player 7

Fixed in: JW Player 8

Symptoms: JW Player has confirmed that a problem in their JW Player 7 software may prevent WebVTT closed captions in live streams from being displayed during playback.

Workaround: You can also use JW Player 6 or CEA-608 captions.

Third-party issue

Affected versions: Edge version 20.10240.16384.0 on Windows 10 (build 10240)

Fixed in: The issue doesn't occur with Edge version 25.10586.0.0 on Windows 10 (version 1511 - OS build 10586.3).

Symptoms: In the Microsoft Edge native player, you can play Apple HLS streams, but artifacts appear across the lower part of the video.

Third-party issue

Affected versions: iOS 9

Fixed in: iOS 12-based players. The issue also doesn't occur with iOS 8 and iOS 7 players.

Symptoms: On iOS 9-based players, after a live stream with WebVTT captions runs for over 12 hours, the captions no longer appear in the player.