I’ve been testing 4.0.4 for the past 2 weeks with transcoder on live streams from FMS. I’ve noticed that from time to time, the different bitrates in the abr (160p and 360p) sometimes develop slight discrepancies in segment durations.
For example, here’s a diff of the output m3u8 |grep EXTINF for 2 transcodings of the same stream running for 20 hrs:
[stg-cache-01 wowza]$ diff /tmp/live_160p.m3u8.extinf /tmp/live_360p.m3u8.extinf
5205c5205
< #EXTINF:3.913,
#EXTINF:3.999,
The target duration in this case was reported as 6 but the segments appear to be a bit under 4. So this means the difference occurred after approx 5.7 hrs.
I’ve been running 24 hr tests. I’ve never seen a difference totally more than 90ms overall in ~10 x 24 hr runs… but similarly, the majority of the time, I don’t see a 0ms difference, which would be what I would expect – with all key frames starting each segment aligned exactly. 40-80 ms is typical and it’s always been only 1 segment that differs. Sometimes it’s even the first segment (which seems to suggest it isn’t always long running streams).
-Ray
Hi,
The cause may be that one or more of the renditions has b frames which may cause the timestamps to be different to the other renditions. Each packet has two timestamp values, PTS (Presentation Time Stamp) and DTS (Decode Time Stamp), and these may vary if b frames are used.
You may need to tell the Wowza server to packetized based on the DTS value by adding the following property to your application and setting it to false.
[th]Path[/th]
[th]Name[/th]
[th]Value[/th]
[th]Type[/th]
Root/Application/LiveStreamPacketizer
cupertinoChunkBreakOnPTS
false
Boolean
The other cause may be if the encoder is not sending streams with synchronized timestamps or the video and audio packets are out of sequence for one or more of the streams.
How to debug encoder multi-bitrate key frame alignment
How to fix unaligned video and audio with a server-side sort buffer
Roger.
Hi,
If the encoding profile is main or higher then there could be B frames in one or more of the streams that could affect the PTS values. It there are no B frames then the PTS and DTS values for each frame should be identical.
The main thing to look at is to see if encoder is sending matching timecodes at the same time for each rendition. If each rendition has completely different timecodes then you will have problems with switching. If they have identical timecodes but one or more renditions is behind the others then you may have problems if it gets too far behind. This would show up in the chunklist requests where each rendition would return chunklists with different segment numbers.
Roger.
Thanks. I will give the PTS/DTS a try first and will report back after a few days of testing.
I am a bit curious as to why/when one should prefer DTS or PTS.
I would’ve assumed each .ts was independent of the next, i.e. no P frames depending on the previous segment and no B frames depending on the next segment, but these details are definitely not in my areas of expertise!
-Ray
So after a few days of experimentation – PTS vs DTS both seem to have the inconsistency. Given that it’s a small one over a reasonably long test window, I am going to cross fingers and overlook it. I could not find a perceptible artifact when viewing the hls generated.