Problem with multi-edition MKV creation

[hubblec4]

Hi Rocky

I wanted to work on the feature and found that the "-extras" switch no longer works.

When demuxing the audio tracks, they are only as long as the playing time of the mpls. But the playing time should be longer because there is still extra audio data from the additional m2ts files.

With version 1.0.0.72 everything works.

[Rocky]

Is the video OK? I'll start investigating.

[hubblec4]

That was a good question because I never demux the video.
cE shows 103%(output from DGDemux) while demuxing, that means the extra m2ts files are used.

But also the Video duration is too short.

[Rocky]

Are you still using A_NEW_HOPE with the extras as we discussed in the thread? If so, I will test with that.

Also, can you try giving -ignorepl?

[hubblec4]

Yes it is the same disc with the same settings we discussed before.

I will test it.

EDIT:
With -ignorepl it works.

[Rocky]

I was seeing some corruptions in the demuxed video for the extras at the end, even with -ignorepl. Did you see that? If it's corrupting the video it may also be corrupting the audio. Anyway, I will fix things.

[hubblec4]

For the Audio you are also right there is a glitch at the end of the file.

[Rocky]

There are no corruptions with 1.0.0.72 for the extras. In 1.0.0.73, it's supposed to behave the same as 1.0.0.72 when the -ignorepl option is given. So there is a foobar in there I will have to find. I also have to fix it to work correctly without -ignorepl. Use 1.0.0.72 until this is sorted out.

I've been working for 10 hours straight on the change to make DGSource() use Vapoursynth API4, so I'll start working on this tomorrow.

[hubblec4]

I've been working for 10 hours straight on the change to make DGSource() use Vapoursynth API4, so I'll start working on this tomorrow.

You need definitive a break. Have a good night.

[Sherman]

Ha ha, I snuck up on Rocky!

[Rocky]

Great night's sleep...other than Sherman waking me up.

Both problems were caused by me not populating the clips[] data for the extras. Here is a test version with both fixed.

https://rationalqm.us/misc/DGDemux_extras.zip

When you give your blessing, hubblec4, I'll make a release and Sherman will port it to the linux version.

[hubblec4]

Looks good now. Thanks Rocky.

[Rocky]

Great, thank you!

[hubblec4]

Thank you Rocky and Sherman for the updated version.

[hydra3333]

I've been working for 10 hours straight on the change to make DGSource() use Vapoursynth API4

My goodness !
Bestest Regards from down under.

[Rocky]

Yeah, and it was only to make Myrsloik happy. I don't see any real gain.

[hubblec4]

A lot of time has passed but I finally had a few minutes to finish the new cE version.
There is now a way to examine and adjust the "jumps".
https://forum.doom9.org/showthread.php? ... ost2002390

[Rocky]

Thank you for the update.

[hubblec4]

Since mkvmerge has a "terrible" append bug, muxing seamless-branching Blu-ray does not work correctly and it was always assumed that (madshi's)eac3to removes duplicate audio frames. Unfortunately, this is not true, because there are no duplicate audio frames.
cE is now able to create a perfect multi-edition MKV without any demuxing.
Here a test version.
https://forum.videohelp.com/attachments ... 6458/cE.7z

[Rocky]

cE is now able to create a perfect multi-edition MKV without any demuxing.

Hello hubblec4. Can you elaborate on the new process and how it differs from the old one? Thank you.

[hubblec4]

Hi Rocky

I was already thinking about asking you if you were interested in how this works.
Because you could also offer this as an option in DGDemux.
Unfortunately I haven't had much time in the last few days and didn't want to start the topic without being there when questions come up.

First of all, I looked very closely at the Blu-ray specs to see how the whole seamless branching is supposed to be processed (thanks to you and the DG team, I now understand more about it).

It now became clear how the whole thing is structured.

Because every m2ts always starts with a keyframe for video and audio and always at "0" (if you look at each m2ts individually). This means that all tracks in every m2ts are synchronized.

The last audio frame then has a little longer playing time than the video. This is simply due to the different frame lengths.

If the audio is now demuxed, it is logical that the audio offset would build up with each m2ts, and here DGDemux and eac3to remove an audio frame every now and then so that everything stays synchronized.

Here is the bug report for MTX
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3728
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3730

If MTX is supposed to append video and audio tracks, the full length of the track with the highest time stamp is always used. The reason for this is that no data should overlap.

However, this creates a video gap.

The other user, who uses the New Hope Blu-ray, then started to code a workaround in which all the time stamps of the tracks are triggered (with ffmpeg) and then these were "calculated and processed" so that MTX accepts them as a time stamp file.

The crucial thing is that the audio time stamp for each first audio frame of an m2ts file receives exactly the time stamp that the first video frame of the attached m2ts receives.

This does create an audio overlap with the last audio frame of the previous m2ts.
But that is perfectly fine. According to the Blu-ray specs, this is required and Matroska can do it 1:1.

At the moment, MTX even compensates for this overlap by writing the last audio frame into a BlockGroup element and reducing its playback time.

What could DGDemux do now?
DGDemux could generate such an MTX timestamp file instead of demuxing the audio.

Thanks to Sherman, I now had the opportunity to access the PTSs myself because I definitely don't want to use ffmpeg.

I then noticed something that meant I could only create the time stamp file for an audio track using the mpls file. However, I am aware that this may not always be 100% accurate. This is because cE now relies on there always being a last audio frame that plays a little longer than the video, and no new audio frame starts after the last video frame. Just as the Blu-ray specs prescribe.

But it can happen that the audio and video are 100% exactly the same length, or that the last audio frame is no longer than the video. But the probability of this is less than 0.001%.

[Rocky]

Thank you for your explanation.

Because every m2ts always starts with a keyframe for video and audio and always at "0"

Not following you. M2TS streams do not have to start at 0. Are you talking about something different from IN_time? Be aware that there can be video/audio content before IN_time that is to be ignored. In fact, as you know, DGDemux was modified to support that because problematic disks in this regard were seen in the wild.

Here is the bug report for MTX
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3728
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3730

I consider all this as a matter for MTX and not for DGDemux.

What could DGDemux do now?
DGDemux could generate such an MTX timestamp file instead of demuxing the audio.

Well, DGDemux is a demuxer. And anyway you said you no longer need to do any demuxing, so you're asking me to write a utility to support MTX processing? The other guy has already created such a utility/process?

[hubblec4]

Because every m2ts always starts with a keyframe for video and audio and always at "0"

Not following you. M2TS streams do not have to start at 0. Are you talking about something different from IN_time?

I'm sure I didn't express myself very clearly here.
If you look at each m2ts individually and ignore the IN and OUT times in the mpls.
According to Blu-ray specs, the first video and audio frame must have the same time stamp for all appended m2ts files.
If this m2ts is muxed into an mkv, then the first video and audio frame has the time stamp 00:00:00.000.

Be aware that there can be video/audio content before IN_time that is to be ignored. In fact, as you know, DGDemux was modified to support that because problematic disks in this regard were seen in the wild.

Yes, that's true. But as far as I understand, this only affects the first m2ts. So far, I haven't seen this behavior with seamless-branching material. Does the DG team perhaps have a Blu-ray where this is the case?

I consider all this as a matter for MTX and not for DGDemux.

Yes, the problem here lies with MTX. That's why nowadays a demuxer has to be used for the audio tracks so that the audio tracks remain synchronized with the video.
If there is a video track and separate audio tracks, then MTX is doing everything right.

Well, DGDemux is a demuxer. And anyway you said you no longer need to do any demuxing, so you're asking me to write a utility to support MTX processing?

This is all purely hypothetical and please don't feel obligated to anything.
It was just a thought on my part.
Now that I know how to help MTX so that nothing needs to be demuxed, that's all well and good. And the fact that cE can do that now too, but I'm realistic and I don't think cE is a tool that many people use. I think the download numbers for DGDemux are higher.

So I thought it might be good if DGDemux could do that too, and thus it would be expanded to include the option of preserving the audio tracks 1:1 by not applying gap correction (no audio frames are lost), but instead creating a time stamp file.

Because at this point it is no longer an MTX problem, but just a question of the correct time stamps that MTX then has to use when muxing the audio track.

The other guy has already created such a utility/process?

I don't know exactly what was coded and how. But he described the process to me.
In any case, there are dependencies on other tools.
In addition, timestamp files are created for each m2ts for all tracks, which then have to be "laboriously" assembled.

I didn't understand right from the start what the user was trying to do, and to demonstrate everything, he coded a bit. The plan was that his tool could be connected to cE.
But after I understood everything, I came up with a solution myself.

[Rocky]

Yes, that's true. But as far as I understand, this only affects the first m2ts. So far, I haven't seen this behavior with seamless-branching material. Does the DG team perhaps have a Blu-ray where this is the case?

Haha, you gave me one. Please recall COLUMBO from this thread:

viewtopic.php?f=16&t=1308

The same M2TS was repeated with a different start time for each, in order to assemble a montage. Also, making assumptions about something allowed by spec sounds dangerous, and you should at least prepare/allow for it in your design, even if you do not immediately implement it. IMHO. Finally, we also have cases where it affects the last M2TS.

Now that I know how to help MTX so that nothing needs to be demuxed, that's all well and good. And the fact that cE can do that now too, but I'm realistic and I don't think cE is a tool that many people use. I think the download numbers for DGDemux are higher.

So I thought it might be good if DGDemux could do that too, and thus it would be expanded to include the option of preserving the audio tracks 1:1 by not applying gap correction (no audio frames are lost), but instead creating a time stamp file.

That sounds reasonable. If I did that is it something you would use, or would you be using your own stuff? I ask because you are the only person I know that is a potential user of this in a processing path or application.

[Sherman]

Guys, it seems to me that Mr hubblec4's advance is all about correctly transcoding (or more precisely remuxing) from seamless branched bluray to MKV. The conventional approach is to demux with gaps correction and then remux to MKV. Mr hubblec4's new approach avoids all that. Of course, it is a wonderful thing, but as Rocky said DGDemux is a demuxer. Certainly we could create a whole new remuxing utility that implements the idea. But hasn't Mr hubblec4 already done that, and wouldn't we therefore be doing redundant development were we to make such a utility? We would never want to steal Mr hubblec4's thunder!