Problem with sup files?

[renols]

Hi.

Its me Again

I am trying to demux a bluray choosing the mpls file. eac3to shows that there are no less than 21 m2ts files in the mpls file.

dgindex demuxes all just fine, and when comparing the size of the sup file with the one created by eac3to, the size is exactly the same.

However the files are not equal. When I open the sup file created by dgindex in subtitle edit, I can see that it looks like the time code is reset to 00:00 each time a new m2ts file starts. The one I am testing with, the first m2ts file lasts just around 10 minutes. And right at that point when the next m2ts file takes over, the timecode in the sup file goes from 00:09:41:412 to 00:00:00:584. The file created by eac3to doesn't show this behaviour. It looks like dgindex treats each m2ts file as a seperate section, rather then being a part of a complete playlist.

I guess this only shows when having a bluray that has many, or at least more than one, m2ts file in the playlist. Am still trying to completely eliminate my use of eac3to, and am slowly getting there

Tested with a bluray with 15 m2ts files in the playlist. It also happens on that one. No idea if it will happen if there is just 2 m2ts files in the playlist.

Do you have any use of the two sup files, or do you have a bluray yourself, with several m2ts files in the playlist, that you can test with?

Am using the latest 176.

renols

[admin]

Duplicated. Investigating...

[renols]

Sounds good.

Just a small note.

Looks like seamless branching can be a problem for eac3to as well. A subtrack can be 1 second or more out of sync by the end of the movie in some situations. All I can think of, is that it must be the seamless branching that causes maybe some rounding errors or something, which means that all the small time errors adds up at the end of the movie.

Just a note, so you don't make dgindex behave 100% like eac3to when it comes to extracting sup files

Audio looks to be right on the Money. Even when seamless branching is used.

renols

[admin]

Thank you for the additional information and analysis, renols.

There are two ways to go: heuristics or full bluray spec compliance. Full spec compliance is a fairly large development effort. I am exploring heuristic options. I wonder if EAC3TO also uses heuristics, explaining the phenomenon you mentioned.

[admin]

To get the times right we need to know the playing time of each M2TS file. If you open a bluray this information is available in the playlist file and things would be pretty simple. But if you just open a set of M2TS files by themselves (no bluray structure) then the times must be determined by tracking the timestamps and subtracting the first from the last for each M2TS file. (That is a heuristic because theoretically the PTS may not be continuous throughout the file.) I see that EAC3TO can demux that way (eac3to file1.m2ts+file2.m2ts... -demux) so it must be using a heuristic method. So that is what I will implement.

[admin]

Maybe there is a real simple way. I'm already counting display frames during Save Project, so maybe all I have to do is, when I am writing the start time for a subtitle, simply get the global time by dividing the number of display frames to that point by the frame rate. This way, file partitioning is totally irrelevant. Let's see how well it works.

A lot of thinking should precede action.

[renols]

Hi.

Really appreciate you spending the time on this. Unfortunately I can't be helpful when it comes to all the technical things.

One thing I have tested is to create a mkv file by opening the mpls file in mkvtoolnix, and saving it as a mkv file. Using this process, and demuxing the mkv file with dgindex, will give the same result. The subs get progressively out of sync towards the end of the movie. Maybe mkvtoolnix just puts all the m2ts files in a row in the mkv container, so when demuxing the result will be just like doing 1.m2ts+2.m2ts+3.m2ts and so on. When playing back the mkv file, the subs are in sync as they should be. It only seems to happen when a sup file is demuxed and then later muxed in again.

If you somehow can use the frame number, to determine when a sub should be shown, that would solve it I guess.

Hope that you find a good solution, that will not end up with the same result as eac3to.

renols

[admin]

Thank you for your additional information and analysis, renols. It is acute and to the point.

As long as the PCR and PTS timestamps (part of m2ts syntax) are present everything is good. When you demux from m2ts you lose the timestamps (strictly, you can retain the PTS by copying it over and offset it by the length of the previous m2ts files etc., but you definitely lose the PCR, which is the absolute time base). And you can have mismatches of video/audio/subs length at the end of an m2ts due to the different granularities of the elementary units. If the timestamps are available to guide playback then that is irrelevant, but if not then small differences can accumulate. That's the executive summary.

I have tested the frame counting method and it works very well. Everything is spot on all the way to end of the stream (no accumulated desync; we expect no desync with frame counting). The only downside is that in an entire movie (Alien 1 1979) there are two subs that are shorter than they should be but not egregiously so. I may try to mitigate that by enforcing a minimum length of (say) 1 second. But even without that the result is very satisfying. I'll play with that and then give you a test version.

It might be interesting to also implement the full bluray compliant method and compare that to the frame counting heuristic.

Wheee!

[admin]

I released the frame counting method in slipstream 177. Please advise how it performs. This may not be the final fix pending your feedback. It's definitely much better than resetting the time to 0 at each subsequent M2TS file.

[renols]

Hi.

I just tested with the source on which I had the initial problem where the time of subs were reset at start og each m2ts file.

On this particular source eac3to ended up with the subs at the end of the movie being around 1 1/2 seconds out of sync.

With this build of dgindexnv as far as I can tell it is similar to playing back the actual disk. So far it looks pretty good. I will see if I have
other disks that I can maybe test with.

Thank you very much.

renols