We recently tried to increase the number of video extensions that we could stream natively in WSE without transcoding per some of the documentation we found (.mp4, .f4v, .mov, .m4a, .m4v, .mp4a, .mp4v, .3gp, .3g2 - https://www.wowza.com/docs/understanding-protocols-and-formats-supported-by-wowza-streaming-engine). However, we quickly noticed we dont get sound. Which, leads us to believe that while WSE can stream the content without transcoding, the audio codec is probably not supported? Is there a way around this, or is transcoding the content into like H.264/.mp4 the only solution? Thanks in advance.
It depends on what audio codec you’re using. The video extensions that you mention are so-called “containers” and they only work with different codec types. You must check which codecs are supported by the chosen container and check if packetizing for the selected combination of container, video codec and audio codec is supported. As an example, you can stream H.264 with Opus, but the HLS packetizer doesn’t support it, so that’ll result in an HLS stream without audio.
Thanks @Karel_Boek! We understand the concepts surrounding container types and supported codecs (but definitely not experts!). From our perspective, we are looking to minimize the transcoding of incoming VOD content as much as possible. Is there an easy programmatic check that we can implement to identify the supported audio codecs when these container types are encountered? Or is it not that simple? And, is there any other way around this with WSE packetization, or is the only solution to encode the content to H.264? Thanks!
Since Wowza doesn’t support VOD transcoding; you should probably have a step in between. When someone uploads a video clip, you could check the video and audio codec, container, etc. (e.g. via a quick ffprobe call) and if it doesn’t match something that is playable by Wowza, then send it off for transcoding (there are several cloud-based transcoding solutions that you can choose from)
For the sake of client compatibility I’d go with H.264 and AAC, unless you have full control over the client-side and prefer different for quality or compatibility reasons.
Thanks @Karel_Boek. We already have an intermediary check like you described in-place. And to your suggestion, we just need to know what audio codecs specifically are acceptable to be natively streamed via WSE? For content that we do transcode, we definitely encode to H.264 and AAC. Can you point us to documentation that lists the compatible audio codecs?