when HEVC has three B frames, the audio and video will be out of sync

[chbtime]

When making UHD, when HEVC has three B frames, the audio and video will be out of sync. The frame rate of the original video is 23.976, but the frame rate after production becomes 19.3, and the playback time will be longer, 23.976 / 19.3 = 1.242, assuming the original 300 seconds of video, now becomes 372 seconds

[chbtime]

Here is log

tsMuxeR version git-8474c6b. github.com/justdan96/tsMuxer HEVC stream doesn't contain fps field. Muxing fps=23.976 B-pyramid level 1 detected. Shift DTS to 2 frames Decoding AC3 stream (track 2): Bitrate: 192Kbps Sample Rate: 48KHz Channels: 2 Processed 7193 video frames Flushing write buffer Creating Blu-ray stream info and seek index Creating Blu-ray playlist Mux successful complete Muxing time: 12 sec

[jcdr428]

@chbtime can we please have a sample of the hevc stream provoking the bug.

[chbtime]

@jcdr428 Here is the sample

https://1drv.ms/v/s!AvgB20EtWxpYi02BYcp5u-btEhyl?e=hWOrkg

[jcdr428]

@chbtime I don't think it is related to the number of B-frames. tsMuxer increments the DTS (Decoding TimeStamp) according to the hevc 'slice_pic_order_cnt_lsb' read in each frame.

This hevc stream has the following 'slice_pic_order_cnt_lsb' sequence (example for the first GOP): 0, 5, 3, 1, 4, 10, 8, 6, 9, 15, 13, 11, 14, 20, 18, 16, 19, 25, 23, 21, 24...
So basically for every five frames there is one pic order count missing.

There seems to be nothing in the hevc standard imposing the pic order counts to be continuous, however it is common practice. Changing tsMuxer to reflect this rare case would be a lengthy exercise, I would rather close this issue as a 'wontfix'.

Edit: actually the standard states '_slice_pic_order_cntlsb specifies the picture order count modulo MaxPicOrderCntLsb for the current picture', so it would tend to mean that the picture order count must be continuous.

[chbtime]

@jcdr428 This is generated by apple silicon m1 encoding. The encoding of INTEL UHD 630 graphics card does not have this problem. Can it be processed with the timestamp of the original video? The original video playback is fine.

[jcdr428]

@chbtime you could run a script to change the timestamps within the m2ts file, but the hevc pic order counts would still be incorrect. Better to avoid the m1 encoding, or find parameters that don't create the same bug.