possible issue with Dolby Vision Blurays

[mquinn54]

This has also been reported to TSMuxer:
Using tsmuxer from 12/12/20 daily build (git-943a735) - but earlier builds exhibit this also.
Get a dolby video UDH 4K disk (doesn't matter - seems to happen on them all).
If you use makemkv to create an mkv - everything works fine.
Now - use tsmuxer and demux the 2 video streams.
Then - use tsmuxer to remux the 2 streams into a bluray disk.
Now use makemkv to extract an mkv from that disk - You get timecode errors - seems to always be at 47:47.573 where it starts, which is suspicious.

AV synchronization issues were found in file 'V:/Video/test1/title_t00.mkv' (title #1)
AV sync issue in stream 0 at 0:47:47.573 : video frame timecode differs by -0.1ms
AV sync issue in stream 0 at 0:47:47.573 : secondary stream video frame timecode differs by -83.511ms
AV sync issue in stream 0 at 0:47:47.739 : secondary stream video frame timecode differs by -0.1ms
AV sync issue in stream 0 at 0:47:47.739 : secondary stream video frame timecode differs by +41.611ms
AV sync issue in stream 0 at 0:47:47.906 : secondary stream video frame timecode differs by -0.1ms
AV sync issue in stream 0 at 0:47:47.906 : secondary stream video frame timecode differs by +166.733ms
AV sync issue in stream 0 at 0:47:47.906 : secondary stream video frame timecode differs by +83.322ms
AV sync issue in stream 0 at 0:47:48.240 : secondary stream video frame timecode differs by -0.1ms
AV sync issue in stream 0 at 0:47:48.240 : secondary stream video frame timecode differs by +41.611ms
AV sync issue in stream 0 at 0:47:48.407 : secondary stream video frame timecode differs by -0.1ms
AV sync issue in stream 0 at 0:47:48.407 : secondary stream video frame timecode differs by +166.733ms
AV sync issue in stream 0 at 0:47:48.407 : secondary stream video frame timecode differs by +83.322ms
AV sync issue in stream 0 at 0:47:48.740 : secondary stream video frame timecode differs by -0.1ms

All future frames have this "issue".
Unclear if this actually causes a DV problem but it seems really wierd.

if I extract the streams (using tsmuxer) from this re-created bluray - they're exactly the same as the original streams that were used to mux the bluray (as one would expect). So this means there's something slightly different about the muxed bluray that makemkv sees as timecode variances (I'm assuming somehow the timecodes of the 4K and the 1080p streams got out of sync), but how they're "fixed" on re-extraction is a bit bizarre.

[Rumourd]

I'm getting exactly this problem with the same timecode numbers, on a double-layer Dolby Vision remux of Gladiator (Extended version).

Did anyone solve it?

[quietvoid]

I'm able to reproduce the issue and it's probably a MakeMKV bug.
The enhancement layer (second video stream in M2TS) is not being read properly, resulting in a truncated file and the timecode errors.

Not sure what the cause is yet. The m2ts file produced by tsmuxer is fine and extracts to identical bitstreams using ffmpeg.
While using MakeMKV on the tsmuxer BD folder, the first video is slightly different and the second stream is truncated after that 47min timecode.

18,909,787,230 BL_orig.hevc
18,910,513,800 BL_makemkv.hevc
18,909,787,230 BL_tsmuxer.hevc

2,136,462,803 EL_orig.hevc
1,787,196,925 EL_makemkv.hevc
2,136,462,803 EL_tsmuxer.hevc

[ArArdin]

I'm able to reproduce the issue and it's probably a MakeMKV bug.

Having done some testruns I can confirm the issue.

So I just learned there's a "mux BL and EL" option with your newest dovitool, which I wanna give a go.
Can you give any insight/advice on whether to use "--eos-before-el" ?

[EDIT] Never mind. Didn't read your post viewtopic.php?p=121961#p121961 until now.
Cheers.

[quietvoid]

There's a new retail disc with similar errors but at a different timestamp.
Where can I report this bug again? Last time I went through a PM to Mike.

[SamuriHL]

Probably best to email. Same address used to send dumps.

[quietvoid]

Well I've sent a PM already but then I realized that the new issue is an authoring problem.
So I don't think there's a way for MakeMKV to work around it.

The tsMuxer bug is still a thing, though.