Wowza Transcoder CBR Bug, ENG-2346
It is impossible to run the Wowza Streaming Engine Transcoder in CBR mode. The setting exists, but it is not actually applied. This article shares the one-month record of finding the CBR mode bug, working with the technical support team, and getting it registered as an official bug under ENG-2346, along with its status one year later.
The Digging Begins: Why Is There No VBR Mode?
Every article I write on this blog is based on a service that I operated, still operate, or plan to build. I write each article by recreating the testbed step by step. This helps my poor memory, prevents possible errors, and fulfills my small wish to share accurate information with my readers.
When I pushed myself to keep writing about Wowza Streaming Engine, hereafter called Wowza, and started covering its transcoder, I ran into a confusing situation.
Huh? Why is there no VBR option in the transcoding settings?
Come to think of it, I had almost never needed to use VBR (Variable Bit Rate). The only times I used VBR were back when I worked with RealVideo or satellite equipment. Most of the systems I had worked with were based on CBR (Constant Bit Rate). That is how I had used Wowza for so many years without even noticing that there was no VBR setting. (Yes. That is really just an excuse…)
Still, after working with many encoders and transcoders, I could not remember seeing any equipment without a CBR/VBR selection option. I naturally planned to cover this first in my article about the Wowza Transcoder, so this was the moment I became confused.
Right, It Has to Be There
I started searching through related documents, but I could not find anything useful about the CBR and VBR settings. After digging around here and there, I finally found a clue.
Updated transcoder VBR target to peak bitrate range from varying values per-implementation to 110% everywhere
Of course! It is a transcoder. There is no way it would not have a VBR option! With this clue in hand, I contacted Wowza technical support. A reply arrived only a few hours later. They told me to add the following parameter to the transcoder template file.
<Parameter>
<Name>mainconcept.bit_rate_mode</Name>
<Value>2</Value> <!-- 0 = CBR, 1 = CQT, 2 = VBR, 3 = TQM -->
<Type>Long</Type>
</Parameter>Happy that I could continue the article, I applied the setting and tried to capture the decoding bitrate in VLC so that I could show the difference between CBR and VBR. And then, the real digging began.
The Real Digging: Huh? This Is Not Right
What Is Different?
I created two transcoder presets in one live application and fed them a 9 Mbps MPEG-TS stream sent over UDP multicast. I set the same target bitrate for both presets, but added the VBR parameter to only one of them.
- Default transcoding preset with an output video bitrate of 3.65 Mbps
- Default transcoding preset with an output video bitrate of 3.65 Mbps and the VBR parameter added
The bitrate changes in the two output streams passing through different transcoders should naturally have been different. However, the two streams showed the same bitrate changes. I switched the mode to CBR, but the result was still the same. In other words, nothing changed whether I selected CBR or VBR.
I wondered if I had entered the setting incorrectly. I sent Wowza the bitrate data measured with ffprobe and the transrate.xml file that I had used. A few days later, I received this reply.
I’d also suggest testing with a more dynamic source (fast movement, scene changes, etc.) to give the encoder more reason to vary the bitrate.
The moment I read this reply, I had a feeling. This… is going to be hard to get an answer for…
Open Your Eyes and Look Closely!
If they said the content was the problem, the best answer was to show them the result with their own eyes. When people think of dynamic video, they usually think of concerts or sports broadcasts. I agree, but there is another kind of content that is just as dynamic: anime featuring a magical girl transformation.
To protect the copyright of the content used in the test, I processed the audio and video from the captured file that I sent to Wowza. It is mosaicked, but you can still see that the content is dynamic enough. The VLC information window is shown below the video.
There are three values to look at carefully.
- Input media data size
- The total size of the stream received by VLC. Because the two transcoders are running with different profiles, the stream data sizes should not be the same.
- Input bitrate graph
- A record of the bitrate changes in the stream received by VLC. Because CBR and VBR use different encoding methods, the graphs should have different shapes.
- Demuxed data size
- The amount of stream data that VLC used for playback. This value should also be different between the two streams.
And of course, all three values moved in exactly the same way in CBR mode and VBR mode. I summarized the results and sent Wowza another reply with the captured video.
A few more days passed, and the reply I had been waiting for finally arrived. Its contents reminded me once again that I was talking to a foreign company.
…Wowza Streaming Engine’s default behavior already uses VBR encoding. So, unless you’re explicitly changing it to a different mode (like CBR), VBR is the default behavior out-of-the-box….
Fine, Then What Is This?
Technical support from overseas companies is very different from support from Korean companies. (I agree that their approach is more reasonable.) They begin by checking the most basic, common-sense items. Of course, it is right to follow the basics and the proper process. Still, I cannot help feeling stunned at times like this. (I can still clearly remember the voice of a Thomson engineer who asked, “Did you connect the ground?” when I called France at 2 a.m. about an equipment problem.) Switch it to CBR? Of course I had already tried that! Did they really think I had not?
Then it occurred to me that I was missing something. VBR settings on most equipment usually come with additional parameters. At least the following three are normally provided.
- Max Bitrate
- The maximum value that must not be exceeded during variable bitrate operation
- Min Bitrate
- The minimum bitrate that the encoder should not fall below during VBR encoding.
- Q-Factor
- A set of quality factors that affect picture quality and compression ratio. Some encoders let you set separate values for I-frame, B-frame, and P-frame.
Even equipment that does not let users set each parameter separately usually provides presets or modes that change these three values. However, I had never seen any such settings in Wowza.
If I knew the default values of these parameters and how to adjust them, I could dig deeper into the transcoder. So I replied to Wowza. I told them that I had already tried the CBR setting and asked for information about those three values.
A few days later, Wowza sent this reply.
..I could replicate the issue you reported… …we currently do not have any documented…
Only now had the manufacturer managed to reproduce the issue. Now it really begins! (Then what on earth had you been doing until now…?)
The Digging Ends at a Big Rock
Additional Transcoder Parameter Information
The next day, an email arrived from Wowza with information about several options for detailed transcoder settings. It included not only the parameters I had asked about, but also detailed information about several hidden settings.
Thinking that I might finally get something useful this time, I eagerly applied the settings. At last, I managed to find a meaningful difference.
In the End, I Hit a Huge Rock
I had confirmed that the additional parameters changed the characteristics of the output streams. If I knew their default values, I could better understand how the default profile worked and explain it in the article. I asked Wowza again for the default value of each parameter. A few days later, I received the following reply.
there are no internal defaults applied for these parameters they default to 0.
The reply also included this additional information.
I checked with our Product Management team, and they confirmed that this is indeed a bug. I’ve gone ahead and created a bug ticket for it in our internal system
In the end, the reason why the result stayed the same no matter how I changed the CBR and VBR settings, content, or measurement method was not a mistake in my settings or test conditions. It was a product bug that Wowza also acknowledged.
After all that digging, I finally hit a huge rock that I could not dig through with a shovel. Removing that rock was now Wowza’s job.
Conclusion
More than a month passed between my first question and the registration of the bug. There were moments when I felt frustrated, but the Wowza support engineer handled my issue sincerely throughout that long period. (And they are still working on it.) Regardless of this particular issue, I do not think Wowza’s technical support is bad.
Wowza has been used in real production environments for many years. Its features and stability have been proven over that long period, and I have no disagreement about that. Still, I believe that Wowza is basically an origin server. When possible, I prefer to handle encoding and transcoding with dedicated external equipment and let Wowza focus on stream ingest, protocol conversion, and distribution. Separating the roles of each system makes it easier to trace failures and manage output quality.
However, please remember that this does not mean the Wowza Transcoder is useless. Many streams are still being delivered through the Wowza Transcoder, and CBR is used only in limited areas of the OTT world. In fact, if I had not dug into this while writing the article, I would probably have kept using it without knowing about the problem, just as I had before.
Wowza officially acknowledged the behavior I found as a bug and registered it under the bug tracking number ENG-2346. From this point on, analyzing the cause and fixing it are Wowza’s responsibility.
As one Wowza user, I am satisfied that I added one small spoonful to making the software a little better and gained a deeper understanding of how the transcoder works along the way. More importantly, I have left behind an article that may save other readers from wasting their thoughts and time on the same problem. That is enough for me.
And One Year Later
The CBR bug in the Wowza Streaming Engine Transcoder was registered as ENG-2346 on . About a year later, in , I was moving articles from DectENG.com to eqmaker.kr when I suddenly wondered whether the bug had been fixed. I asked Wowza technical support for an update and received the following reply.
I checked the bug ticket: ENG-2346 that was raised for this issue, and I can confirm that it is currently in progress. Our engineering team is actively working on it; however, we do not have an estimated timeline for when the fix will be completed.
I also confirmed that this bug ticket has already been associated with your account. Once the issue is resolved and the fix is available, you will automatically receive a notification.
Unfortunately, the bug has still not been fixed after about a year. Even I do not think this is a critical issue. If it had caused a fatal problem in real-world use, complaints from countless users around the world would already have poured in. The chance to discover it would never have reached me.
In fact, even I, the person who found the bug, had lost interest because I had no reason to use the transcoder. The truth is that if the features I use work well, I pay less attention to the others. I suspect that most other users are not very different.
That does not mean incorrect behavior should be left as it is. Even if a bug is not critical, something that is clearly wrong should be fixed. I hope that one day I will hear from Wowza that ENG-2346 has been fixed.
Update History
- — First published
- — Revision and URL migration
