nDVR with MBR and SmoothStreaming with sync problems

Wowza Streaming Engine
1

Hello,

I have a system receiving MPEG-TS streams synchronized (i’ve checked dts an pts @logs). The streams are recorded with nDVR Addon

I group them in one smil and use SmoothStreaming to playback.

After some time they loose synchronization between profiles and AV Sync issues start to show in player. Mostly on profile changes.

Since in Smooth Streaming, audio track is one of the audio of the first profile in smil, only one profile is AV synchronized.

I observed the Manifest indexes by DVR time. Since sometimes the streams don’t arrive perfectly aligned, it happens that chunk 50 (for instance) for profile A has the same dts of chunk 49 of profile B. Even with sort buffer this things can happen. Or when one profile has some drops.

Why the SmoothStreaming Manifest doesn’t index by Packet Time, meaning the DTS, resulting in chunks aligned between profiles?

Why is by default DVR Time? Can we change to Packet Time without a module with Request API? Can your Request Delegate be changed to Packet Time?

The same streams without DVR, with SmoothStreaming Packetizer, work perfectly. If you observe the Manifest it’s indexed by Packet Time (DTS)…

Using 4.6.0 with DVR Addon

2

In release 4.0.5

https://www.wowza.com/docs/wowza-streaming-engine-4-0-5-release-notes

Fixed nDVR Smooth Streaming chunk request where rounding to nearest available time in an MBR request would not result in a valid chunk. Fixes “Playlist alignment null store” log warning

WARN server comment 2017-02-24 09:18:34 - - - - - 167104.84 - - - - - - - - DvrPlayerAdapterSmoothStreaming.timeToPlaylistIndex: Playlist alignment null store. t=171982020 stream=

I’m getting this warning in this scenario several times. Is the issue “back”?

I’ve checked and the chunks are with minimal difference between MBR profiles… less than 10ms

3

Solved with 4.6.0.04 with dvrChunksinReserve property.

Wowza should improve nDVR. The way the files are managed kill’s the IO on the server. Too many files.