Variable Frame Rate recordings

[Bryce_Seifert]

Despite sending constant frame rates from our encoder, and zero dropped frames being reported, the Wowza Live stream recordings come back as VFR 100% of the time. Any idea what would cause this? The dips in frame rates are usually very slight as well.
Typical min/max rates:

Encoder settings:

[Bryce_Seifert]

@Rose Power-Wowza Community Manager This is regarding Frame Rate, not bit rate. Even with that selected frame rate remains unaffected.

[Rose_Power-Wowza_Com]

Oh, my sincere apologies for misreading that! Let me look into this for you right away.

[Rose_Power-Wowza_Com]

@Bryce Seifert the engineers would like to know if you’re recording source stream or transcoder output?

[Rose_Power-Wowza_Com]

So, this is very peculiar behavior and the engineers would like to ask you to submit a support ticket in order to take a closer look at this. We have an idea of what may be causing it on our end, but will require the ticket to replicate and test. Thanks so much.

https://www.wowza.com/support/open-ticket

[Bryce_Seifert]

Got it. Submitted under ticket 354939

[Rose_Power-Wowza_Com]

Thanks! I’ll keep an eye on it.

[Bryce_Seifert]

No worries! It is a source stream recording.

[Christian_Siegert]

Hello, Exist a Fix for this issue ? We have the same. Our Encoder send 50FPS (CONSTANT) and the recording is Variable between 45 and 55 Frames.

Frame rate mode                          : Variable
Frame rate                               : 50.000 FPS
Minimum frame rate                       : 45.455 FPS
Maximum frame rate                       : 55.556 FPS

[Christian_Siegert]

Hello,

can you please post the result from this ticket. We have the same issue.

[Bryce_Seifert]

@Christian Siegert

I suspect the problem stems from how we handle the internal timing of frames. Internally we keep track of frames on a millisecond precision timescale and unfortunately most video solutions natively run on a 90KHz time scale which introduces inherent rounding issues when translating to round milliseconds.

If we look at the reported frame rate max and min, you can see how this manifests:
1/29.412 = 0.339 (aka 34ms)
1/30.303 = 0.330 (aka 33ms)

We have to have an occasional 34ms frame, because we can’t have a 33.33333333333333333 ms frame as we would want to.

[Christian_Siegert]

@Bryce_Seifert

I suspect the problem stems from how we handle the internal timing of frames. Internally we keep track of frames on a millisecond precision timescale and unfortunately most video solutions natively run on a 90KHz time scale which introduces inherent rounding issues when translating to round milliseconds.

If we look at the reported frame rate max and min, you can see how this manifests:
1/29.412 = 0.339 (aka 34ms)
1/30.303 = 0.330 (aka 33ms)

We have to have an occasional 34ms frame, because we can’t have a 33.33333333333333333 ms frame as we would want to.

Would I get a fixed framerate if I enter a value other than 50 in the encoder, or could the streaming engine not be fixed (or made configurable), so that this problem no longer exists.