cubicibo / ScenariStream

Bidirectional conversion tool for Scenarist ES+MUI and Raw streams
MIT License
3 stars 0 forks source link

Converted PES+MUI can't be imported into Scenarist #1

Closed Alllen closed 6 months ago

Alllen commented 6 months ago

Hi cubicibo! I extracted the subtitle file (.SUP) from the Blu-ray Disc stream using tsmuxer and then converted it to PES+MUI format using ScenariStream, and there is an error occurred when I try to drag the resulting PES into Scenarist. I tried using DGDmuxer for demuxing and got the same result. But, the PES+MUI I generated with KITe demuxing can be successfully dragged into Scenarist, I checked them with hash software and found that the hash value of the PES file converted by ScenariStream is exactly the same as that of the PES file generated by KITe, while the MUI file is different. Is the problem with the new MUI file, is it that it doesn't conform to the Scenarist file spec? I've uploaded the test sample to the attach, please check it out.

Result in Scenarist:
1) DGDemux:
    Error : DTS of ICS(or PCS) is less than PTS of previous END.
    Error : PG Decode error. D:\sub\DGDemux\ScenariStream_DGD_744 PID 12a0 eng.pes offset=0x4BBA (first byte of invalid segment).
    Error : Decode failed. File Path:[D:\sub\DGDemux\ScenariStream_DGD_744 PID 12a0 eng.pes]
2) tsMuxer:
    Error : DTS of ICS(or PCS) is less than PTS of previous ICS(or PCS).
    Error : PG Decode error. D:\sub\tsMuxer\ScenariStream_tsM_00803.track_4768_eng.pes offset=0xA4D2 (first byte of invalid segment).
    Error : Decode failed. File Path:[D:\sub\tsMuxer\ScenariStream_tsM_00803.track_4768_eng.pes]
3) KITe:
    Info : D:\sub\KITe demux\00073_h_01.pes  Decoding was completed.

tsMuxer.zip KITe demux.zip DGDemux.zip

cubicibo commented 6 months ago

Hi, Interesting issue, thanks for filing it up. There are two problems:

#.1 SUP files problems

To fix DGDemux or tsMuxer SUPs, you can use this script. You must have SUPer python package installed. It will create a new file "_fixed" in the same folder.
Usage: python3 script.py path_to_file.sup:

from SUPer.render2 import DSNode
from SUPer.pgraphics import PGObjectBuffer
from SUPer import SUPFile

from argparse import ArgumentParser
from pathlib import Path

ap = ArgumentParser()
ap.add_argument('supfile')
fp = Path(ap.parse_args().supfile)

assert fp.exists(), "Input SUP file does not exist."
sup = SUPFile(fp)
output = open(Path.joinpath(fp.parent, fp.stem + "_fixed" + fp.suffix), 'wb')

try:
    for epoch in sup.gen_epochs():
        buffer = PGObjectBuffer()
        for ds in epoch:
            DSNode.apply_pts_dts(ds, DSNode.set_pts_dts_sc(ds, buffer, epoch[0].wds))
            output.write(bytes(ds))
except Exception as e:
    print(f"Critical error while fixing stream: {e}")
output.close()

Both SUP files will be identical once you execute this script. From there, you can use ScenariStream.

I don't think there is anything to fix in ScenariStream. The issue originates from the muxers/demuxers. A conversion utility should not fix the files on the fly. I can only suggest you to use this script to "fix" the files.

#.2 MUI Problem (??) Now, if you convert the "_fixed" file, you will see that MUI is nearly identical everywhere except for a few bytes every few lines. I have absolutely no idea why the KITe file is like this. Here's a test:

  1. Import _fixed PES+MUI in Scenarist
  2. Encode -> Build/Rebuild PES data (please try both operations)
  3. Please do the same for KITe PES+MUI file. Import then Build+Rebuild.

I expect that Scenarist will change the KITe data but not the tsMuxer data. To me, it seems like KITe output is incorrect, or the Blu-ray itself contains this oddity. tsMuxer_fixed.zip

cubicibo commented 6 months ago

FYI tsMuxer should be fixed once this PR is merged: https://github.com/justdan96/tsMuxer/pull/833

Alllen commented 6 months ago

Thank you for your time to help me with another problem! I ran the script you provided to fix the two SUP files extracted by tsMuxer and DGDemux, and after fixing them, their hash is exactly the same, and after it was converted to PES+MUI, both of them can be imported to Scenarist without any problem, and were successfully encoded. In addition, after doing the Build/Rebulid operation in Scenarist on the PES files, and as you would expect, they are all the same file no matter whether you use Build or Rebulid operation, including the MUI file generated by KITe.

hash

Alllen commented 6 months ago

FYI tsMuxer should be fixed once this PR is merged: justdan96/tsMuxer#833

You have a point, DTS should be parsed and generated correctly for writing to the SUP at the time of the demux video file, rather than being added out of thin air when it's being converted again, that's for the best, although it probably adds to the calculations, I'm guessing.

cubicibo commented 6 months ago

Thanks for the comparison and glad I could help! I guessed correctly that the KITe MUI file was incorrect and Scenarist would fix it đŸ‘€ Either a KITe issue or the actual Blu-ray data is wrong.

By the way, if you can generate a PES+MUI file in Scenarist with a >15h duration using a simple BDN XML that shows one subtitle for a few second every hour, I would appreciate a sample.

Alllen commented 6 months ago

By the way, if you can generate a PES+MUI file in Scenarist with a >15h duration using a simple BDN XML that shows one subtitle for a few second every hour, I would appreciate a sample.

Of course! sample.zip

cubicibo commented 6 months ago

Thanks! Finally I can confirm that .SUP with duration longer than 13h export to PES+MUI correctly. .SUP files duration is limited to ~13h while PES+MUI supports up to ~26h, and has offsets. So, extra care is needed in conversion process.

Alllen commented 5 months ago

Hi cubicibo, Sorry to bother you again, recently I found out that after .sup file is converted to .pes+mui by ScenariStream, before mux, it will be forced to be re-encoded by Scenarist, and saved as a (filename)-0.pes temporary file in the "Encode/AdujustedES" folder of Scenarist project, and then mux will be started with using it. And sometimes it will even wrongly generate the file that size up to 2Gb (from the original file size of about 80Mb, scanning the bit rate of the PGS in muxed video raised from about 70kbps to 2000kbps), I use Scenarist pes editor directly open this -0.pes file to view, I do not see what is different between the original pes file structure and the temp pes file structure, including the number of epochs, the PTS, composite object, etc. are all the same as the original, i think it should be that scenarist generates some extra rubbish data to put into the pes. I had to try to convert this sup to bdnxml first before, then import to the Scenarist, and it doesn't get re-encoding before muxing, and no longer has the error about the file size getting bigger. Also, I went to look at past pes generated by SUPer BDN conversion and found that all of them showed signs of being re-encoded (i.e. the presence of -0.pes in "AdujustedES" folder). So the tentative conclusion is that the current version of SUPer(or ScenariStream)-generated .pes dragged into Scenarist, regardless of whether it is done building or rebuilding, will invariably be forced by scenarist to undergo a reencoding the moment the mux start button is pressed, and that scenarist actually uses these -0.pes files to mux. files to mux, and the way to let scenarist generate pes through bdnxml import is no need to re-encode, it may be that scenarist recognises them by some identifier, as to why the size is bigger, it is unknown. Can you please check this example for me? 1

example.part001.zip example.part002.zip example.part003.zip example.part004.zip example.part005.zip example.part006.zip example.part007.zip

cubicibo commented 5 months ago

Hi,

It seems like you have mistakenly enabled "Acquisition Point Interval" option in Scenarist BD. 452-41ee6f66bc

When this option is enabled, Scenarist BD adds anchors (acquisition points). Blu-ray player use these anchors to catch up and display faster a subtitle stream, they do not have to wait for the next event anymore which can be quite a few seconds in the future. On the downside, every anchor contains all of the data to display the subtitles. If they are too frequent, the data size explodes, so does the bitrate. In your -0.pes file, events are refreshed every 2 frames. If you do not use any option like that in Scenarist BD, then your PG/IG does not have to be built to be muxed.

Alllen commented 5 months ago

Hi,

It seems like you have mistakenly enabled "Acquisition Point Interval" option in Scenarist BD. 452-41ee6f66bc

When this option is enabled, Scenarist BD adds anchors (acquisition points). Blu-ray player use these anchors to catch up and display faster a subtitle stream, they do not have to wait for the next event anymore which can be quite a few seconds in the future. On the downside, every anchor contains all of the data to display the subtitles. If they are too frequent, the data size explodes, so does the bitrate. In your -0.pes file, events are refreshed every 2 frames. If you do not use any option like that in Scenarist BD, then your PG/IG does not have to be built to be muxed.

Thank you so much! You really know everything. To be honest, I didn't understand this option at all before, just now following your guide, I tried to re-drop the .pes file into the Scenarist‘s Datatree, and checked that the "Acquisition Point interval" in the Property is really 2 frames. After removing the 2 frames to 0 frame and re-muxing, the PGS bitrate and file size are no longer bigger, and no -0.pes is generated, and everything seems to be back to normal. In fact, I didn't artificially turn on this option, but started muxing directly after dropping the pes. I do not understand how it automatically becomes 2 frames, when other subs extracted from the same raw disc are dropped in and are 0 frame. I wonder if this setting comes from the converted pes file or the demuxed sup? Besides, checked those .pes previously generated with Scenariststream or SUPer and this option is 0 frame, also what happened to those previously with the option 0 frame that had generated *-0.pes (the bitrate is normal)?

cubicibo commented 5 months ago

You are always welcome!

[...] I tried to re-drop the .pes file into the Scenarist‘s Datatree, and checked that the "Acquisition Point interval" in the Property is really 2 frames. [...] In fact, I didn't artificially turn on this option, but started muxing directly after dropping the pes. I do not understand how it automatically becomes 2 frames.

This is an option of Scenarist, it is not in the data stream. I do not know why it would get enabled sometimes, and other times not. Possibly Scenarist BD has some internal logic to enable this setting.

also what happened to those previously with the option 0 frame that had generated *-0.pes (the bitrate is normal)?

I cannot know, I do not have Scenarist BD. You would have to provide me samples so I can analyze them.

Alllen commented 5 months ago

I cannot know, I do not have Scenarist BD. You would have to provide me samples so I can analyze them.

Please analyse these two pes files of the same subtitle and maybe we can get an answer, one in example1 is the source file (from sup converted and fixed by ScenariStream) that was dropped into Scenarist, bring the 2 frames option enable, and will explode.The other is the one that was encoded by Scenarist after I removed the 2 frames and before mux by it at the original filepath (but this muxing didn't generate the 0.pes, no bitrate explosion, no data size explosion), and when I drop it into Scenarist again, it doesn't bring the 2 frame option enable again either! example1.part1.zip example1.part2.zip example1.part3.zip example1.part4.zip

Here's another sup(ScenariStream converted and fixed, too) extracted from the same Blu-ray disc, which from start to finish doesn't bring the 2-frames again at all: example2.zip

cubicibo commented 5 months ago

example 1 PTS is not on Scenarist BD frame grid. Scenarist is not happy and re-encodes all PTS/DTS. Furthermore, it seems that numerous files were joined together to produce this SUP. Testing this file with SUPer returns quite a few errors due to discontinuities. Scenarist BD evidently detects faults on imports and enables by default some re-encoding options, including Acquisition Point Interval for some reason.

example 2 has no such abnormalities.