[BUG] DVB subtitles timing issue #504

@NilsIrl commented on GitHub (Dec 22, 2019):

None of the arguments are relevant to the problem.

@NilsIrl commented on GitHub (Dec 22, 2019): None of the arguments are relevant to the problem.

claunia commented

@NilsIrl commented on GitHub (Dec 22, 2019):

~~mpv gives the same output as ccextractor. (There aren't any pause between the subtitles)~~

~~I couldn't test on VLC as it doesn't want to open the file~~

@NilsIrl commented on GitHub (Dec 22, 2019): ~~mpv gives the same output as ccextractor. (There aren't any pause between the subtitles)~~ ~~I couldn't test on VLC as it doesn't want to open the file~~

claunia commented

@NilsIrl commented on GitHub (Dec 22, 2019):

~~There are 2 subtitle stream in the file. Stream 2 seems to correspond with the output given by CCExtractor and has no pauses between the subtitles.~~

@NilsIrl commented on GitHub (Dec 22, 2019): ~~There are 2 subtitle stream in the file. Stream 2 seems to correspond with the output given by CCExtractor and has no pauses between the subtitles.~~

claunia commented

2026-01-29 16:45:33 +00:00

@NilsIrl commented on GitHub (Dec 22, 2019):

~~To me, there is no bug here~~

@NilsIrl commented on GitHub (Dec 22, 2019): ~~To me, there is no bug here~~

claunia commented

@NilsIrl commented on GitHub (Dec 22, 2019):

If the timestamps are supposed to be in sync with the video, the timestamps aren't in sync with the ones given by mpv.

The problem is not only that there are gaps between the timestamps but that the timestamps are wrong

@NilsIrl commented on GitHub (Dec 22, 2019): If the timestamps are supposed to be in sync with the video, the timestamps aren't in sync with the ones given by mpv. The problem is not only that there are gaps between the timestamps but that the timestamps are wrong

claunia commented

2026-01-29 16:45:33 +00:00

@NilsIrl commented on GitHub (Dec 22, 2019):

This line seems to be the origin of the problem:

c1c0627dab/src/lib_ccx/dvb_subtitle_decoder.c (L1689)

@NilsIrl commented on GitHub (Dec 22, 2019): This line seems to be the origin of the problem: https://github.com/CCExtractor/ccextractor/blob/c1c0627dab772c3626b913ac9113f7a16c2e0773/src/lib_ccx/dvb_subtitle_decoder.c#L1689

claunia commented

2026-01-29 16:45:34 +00:00

@NilsIrl commented on GitHub (Dec 23, 2019):

@cfsmp3 @jakubvojacek is there any possibility this could be a regression?

@NilsIrl commented on GitHub (Dec 23, 2019): @cfsmp3 @jakubvojacek is there any possibility this could be a regression?

claunia commented

2026-01-29 16:45:34 +00:00

@NilsIrl commented on GitHub (Dec 23, 2019):

May or may not be the function that collects the timings

c1c0627dab/src/lib_ccx/ts_functions.c (L741)

@NilsIrl commented on GitHub (Dec 23, 2019): May or may not be the function that collects the timings https://github.com/CCExtractor/ccextractor/blob/c1c0627dab772c3626b913ac9113f7a16c2e0773/src/lib_ccx/ts_functions.c#L741

claunia commented

2026-01-29 16:45:34 +00:00

@jakubvojacek commented on GitHub (Dec 23, 2019):

Hello @NilsIrl , thank you for looking into this.

I tested the file on VLC again, selected the first track (DVB Subtitles - [Portuguese]) and it was showing pauses in between subtitles, unlike the generated srt file by ccextractor. I can provide a recorded video of the VLC player if necessary.

Please let me know if you need any further clarification/

Once again, thank you
Jakub

@jakubvojacek commented on GitHub (Dec 23, 2019): Hello @NilsIrl , thank you for looking into this. I tested the file on VLC again, selected the first track (`DVB Subtitles - [Portuguese]`) and it was showing pauses in between subtitles, unlike the generated srt file by ccextractor. I can provide a recorded video of the VLC player if necessary. Please let me know if you need any further clarification/ Once again, thank you Jakub

claunia commented

2026-01-29 16:45:35 +00:00

@NilsIrl commented on GitHub (Dec 23, 2019):

No, don't worry, as you can see, I have striked-through my comments, I accidentally used ccextractor's output as subtitles for mpv which is why I was confused.

@NilsIrl commented on GitHub (Dec 23, 2019): No, don't worry, as you can see, I have striked-through my comments, I accidentally used ccextractor's output as subtitles for mpv which is why I was confused.

claunia commented

2026-01-29 16:45:35 +00:00

@cfsmp3 commented on GitHub (Dec 27, 2019):

@cfsmp3 @jakubvojacek is there any possibility this could be a regression?

Very likely.

@cfsmp3 commented on GitHub (Dec 27, 2019): > @cfsmp3 @jakubvojacek is there any possibility this could be a regression? Very likely.

claunia commented

2026-01-29 16:45:36 +00:00

@NilsIrl commented on GitHub (Jan 10, 2020):

After bisecting I found the commit that made timing look sensible for the first time:

016674b0eb

It's not perfect though (first timestamp is at 0):

<subpictures>
<stream>
<!-- ../build/files/telecine.ts -->
<spu start="0.000" end="0.001" image="../build/files/telecine.d/sub0000.png" xoffset="88" yoffset="46">
</spu>
<spu start="4.929" end="5.936" image="../build/files/telecine.d/sub0001.png" xoffset="88" yoffset="46">
</spu>
<spu start="7.644" end="7.902" image="../build/files/telecine.d/sub0002.png" xoffset="88" yoffset="46">
</spu>
</stream>
</subpictures>

This is what it looked like before:

<subpictures>
<stream>
<!-- ../build/files/telecine.ts -->
<spu start="0.001" end="0.003" image="../build/files/telecine.d/sub0000.png" xoffset="88" yoffset="46">
</spu>
<spu start="0.001" end="0.005" image="../build/files/telecine.d/sub0001.png" xoffset="88" yoffset="46">
</spu>
<spu start="0.001" end="0.003" image="../build/files/telecine.d/sub0002.png" xoffset="88" yoffset="46">
</spu>
</stream>
</subpictures>

@NilsIrl commented on GitHub (Jan 10, 2020): After bisecting I found the commit that made timing *look* sensible for the first time: 016674b0eb4ef09466f9f70575805567fd406bac It's not perfect though (first timestamp is at 0): ```xml <subpictures> <stream>  <spu start="0.000" end="0.001" image="../build/files/telecine.d/sub0000.png" xoffset="88" yoffset="46"> </spu> <spu start="4.929" end="5.936" image="../build/files/telecine.d/sub0001.png" xoffset="88" yoffset="46"> </spu> <spu start="7.644" end="7.902" image="../build/files/telecine.d/sub0002.png" xoffset="88" yoffset="46"> </spu> </stream> </subpictures> ``` This is what it looked like before: ```xml <subpictures> <stream>  <spu start="0.001" end="0.003" image="../build/files/telecine.d/sub0000.png" xoffset="88" yoffset="46"> </spu> <spu start="0.001" end="0.005" image="../build/files/telecine.d/sub0001.png" xoffset="88" yoffset="46"> </spu> <spu start="0.001" end="0.003" image="../build/files/telecine.d/sub0002.png" xoffset="88" yoffset="46"> </spu> </stream> </subpictures> ```

claunia commented

2026-01-29 16:45:36 +00:00

@NilsIrl commented on GitHub (Jan 11, 2020):

a5dcf9242d is the commit that made all subtitles one next to the other.

@NilsIrl commented on GitHub (Jan 11, 2020): a5dcf9242d59b30ae78118a96e914d2adbab04a7 is the commit that made all subtitles one next to the other.

claunia commented

2026-01-29 16:45:36 +00:00

@cfsmp3 commented on GitHub (Jan 11, 2020):

I think that was Anshul's original work on DVB, but that specific issue (as
well was many related to times) were fixed in 2017.
So there must be another commit that reintroduced the problem.

On Fri, Jan 10, 2020 at 4:13 PM Nils ANDRÉ-CHANG notifications@github.com
wrote:

a5dcf92
https://github.com/CCExtractor/ccextractor/commit/a5dcf9242d59b30ae78118a96e914d2adbab04a7
is the commit that made all subtitles one next to the other.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWIHKGPQTNPTTXUWM2DQ5EFJJA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIVSVHI#issuecomment-573254301,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNMTWJIJB3MIMA6WHWEZLLQ5EFJJANCNFSM4ITDPF5A
.

@cfsmp3 commented on GitHub (Jan 11, 2020): I think that was Anshul's original work on DVB, but that specific issue (as well was many related to times) were fixed in 2017. So there must be another commit that reintroduced the problem. On Fri, Jan 10, 2020 at 4:13 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > a5dcf92 > <https://github.com/CCExtractor/ccextractor/commit/a5dcf9242d59b30ae78118a96e914d2adbab04a7> > is the commit that made all subtitles one next to the other. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWIHKGPQTNPTTXUWM2DQ5EFJJA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIVSVHI#issuecomment-573254301>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABNMTWJIJB3MIMA6WHWEZLLQ5EFJJANCNFSM4ITDPF5A> > . >

claunia commented

@NilsIrl commented on GitHub (Jan 11, 2020):

So it's a double regression?

@NilsIrl commented on GitHub (Jan 11, 2020): So it's a double regression?

claunia commented

@cfsmp3 commented on GitHub (Jan 11, 2020):

I'd call it a regression :-) The first implementation did DVB but
timing was broken (completely).
Then it was fixed, by a GCI winner by the way I think in 2016, and
clearly seems to be broken again.
I haven't looked at the code at all but if you're looking into this
some background:

In DVB subtitles are replaced by subtitles- they don't have a
duration, and there isn't a clear screen command. This means that if
you write something it stays there until something else replaces
it(*). However, that "something else" can be "nothing" (as in empty).
My guess is that we are now filtering that and when there's an empty
string we're not passing it to the encoder. So this is a case of being
to clever optimizing stuff.

(*) Actually the specs mention a timeout of I think 30 seconds, but
let's ignore that case for now.

On Fri, Jan 10, 2020 at 4:18 PM Nils ANDRÉ-CHANG
notifications@github.com wrote:

So it's a double regression?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@cfsmp3 commented on GitHub (Jan 11, 2020): I'd call it a regression :-) The first implementation did DVB but timing was broken (completely). Then it was fixed, by a GCI winner by the way I think in 2016, and clearly seems to be broken again. I haven't looked at the code at all but if you're looking into this some background: In DVB subtitles are replaced by subtitles- they don't have a duration, and there isn't a clear screen command. This means that if you write something it stays there until something else replaces it(*). However, that "something else" can be "nothing" (as in empty). My guess is that we are now filtering that and when there's an empty string we're not passing it to the encoder. So this is a case of being to clever optimizing stuff. (*) Actually the specs mention a timeout of I think 30 seconds, but let's ignore that case for now. On Fri, Jan 10, 2020 at 4:18 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > > So it's a double regression? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.

claunia commented

@NilsIrl commented on GitHub (Jan 11, 2020):

Please keep in mind that it isn't the only problem. The other one is that all the subtitles are at the wrong "offset".

For the given input file (telecine.ts), it is exactly (at least what my eyes would qualify as such), 6600 millisecond early.

@NilsIrl commented on GitHub (Jan 11, 2020): Please keep in mind that it isn't the only problem. The other one is that **all** the subtitles are at the wrong "offset". For the given input file (telecine.ts), it is exactly (at least what my eyes would qualify as such), 6600 millisecond early.

claunia commented

@cfsmp3 commented on GitHub (Jan 12, 2020):

@NilsIrl compare it with

0.85 (2017-01-23)
Fix: DVB timing is finally good.

Let's use 0.85 as the "known good version" for DVB timing reference.

How are the results on that one?

@cfsmp3 commented on GitHub (Jan 12, 2020): @NilsIrl compare it with 0.85 (2017-01-23) Fix: DVB timing is finally good. Let's use 0.85 as the "known good version" for DVB timing reference. How are the results on that one?

claunia commented

2026-01-29 16:45:38 +00:00

@NilsIrl commented on GitHub (Jan 12, 2020):

0.85 doesn't compile on my computer 😄

@NilsIrl commented on GitHub (Jan 12, 2020): 0.85 doesn't compile on my computer :smile:

claunia commented

@NilsIrl commented on GitHub (Jan 12, 2020):

It doesn't work with cmake or the linux build script

@NilsIrl commented on GitHub (Jan 12, 2020): It doesn't work with cmake or the linux build script

claunia commented

2026-01-29 16:45:38 +00:00

@NilsIrl commented on GitHub (Jan 12, 2020):

0.85 doesn't look good to me. It gives the same result as master.

@NilsIrl commented on GitHub (Jan 12, 2020): 0.85 doesn't look good to me. It gives the same result as master.

claunia commented

2026-01-29 16:45:38 +00:00

@cfsmp3 commented on GitHub (Jan 12, 2020):

Try a different input file. Maybe that telecine.ts is not great.

https://drive.google.com/drive/folders/0B_61ywKPmI0TUUk5LXJPeG1feFE

I remember I used EastEnders to test and the sync for absolutely perfect.

Remember that you need to compare with the output of the subtitles as
displayed for example with VLC, not the audio. The DVB subtitles
might be off-sync with the audio and that's not our problem.

On Sun, Jan 12, 2020 at 12:47 PM Nils ANDRÉ-CHANG
notifications@github.com wrote:

0.85 doesn't look good to me

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@cfsmp3 commented on GitHub (Jan 12, 2020): Try a different input file. Maybe that telecine.ts is not great. https://drive.google.com/drive/folders/0B_61ywKPmI0TUUk5LXJPeG1feFE I remember I used EastEnders to test and the sync for absolutely perfect. Remember that you need to compare with the output of the subtitles as displayed for example with VLC, *not* the audio. The DVB subtitles might be off-sync with the audio and that's not our problem. On Sun, Jan 12, 2020 at 12:47 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > > 0.85 doesn't look good to me > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.

claunia commented

2026-01-29 16:45:39 +00:00

@NilsIrl commented on GitHub (Jan 12, 2020):

The results with EastEnders are perfect on master.

So the problem is specific to telecine.ts

@NilsIrl commented on GitHub (Jan 12, 2020): The results with EastEnders are **perfect** on master. So the problem is specific to telecine.ts

claunia commented

2026-01-29 16:45:39 +00:00

@cfsmp3 commented on GitHub (Jan 12, 2020):

Play telecine.is in VLC as well, and enable DVB subtitles. Do they look as
bad as in CCExtractor, or are they in sync? If VLC and CCExtractor do the
same thing I'd say it's safe to say the problem is with that file.

If VLC plays it correctly and we don't, then we have a job to do :-)

On Sun, Jan 12, 2020 at 1:11 PM Nils ANDRÉ-CHANG notifications@github.com
wrote:

The results with EastEnders are perfect on master.

So the problem is specific to telecine.ts

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWPOSYHP2B6MTWQDWEDQ5OBPZA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXEJRI#issuecomment-573457605,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNMTWOY5E56C3UO7RWJNB3Q5OBPZANCNFSM4ITDPF5A
.

@cfsmp3 commented on GitHub (Jan 12, 2020): Play telecine.is in VLC as well, and enable DVB subtitles. Do they look as bad as in CCExtractor, or are they in sync? If VLC and CCExtractor do the same thing I'd say it's safe to say the problem is with that file. If VLC plays it correctly and we don't, then we have a job to do :-) On Sun, Jan 12, 2020 at 1:11 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > The results with EastEnders are *perfect* on master. > > So the problem is specific to telecine.ts > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWPOSYHP2B6MTWQDWEDQ5OBPZA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXEJRI#issuecomment-573457605>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABNMTWOY5E56C3UO7RWJNB3Q5OBPZANCNFSM4ITDPF5A> > . >

claunia commented

2026-01-29 16:45:39 +00:00

@NilsIrl commented on GitHub (Jan 12, 2020):

What I do to debug is:

generate subtitles with ccextractor
Play 1 mpv instance with the subtitles from ccextractor and 1 instance with the subtitles directly from the file.
I have a command that makes sure the 2 instances are in sync.

End result:

The results with east enders on master are in sync.
The results with telecine.ts are too early and stay up until the next subtitle compaired with the other instance.

@NilsIrl commented on GitHub (Jan 12, 2020): What I do to debug is: 1. generate subtitles with ccextractor 2. Play 1 mpv instance with the subtitles from ccextractor and 1 instance with the subtitles directly from the file. 3. I have a command that makes sure the 2 instances are in sync. End result: * The results with east enders on master are in sync. * The results with telecine.ts are too early and stay up until the next subtitle compaired with the other instance.

claunia commented

2026-01-29 16:45:40 +00:00

@cfsmp3 commented on GitHub (Jan 12, 2020):

OK but what about the output of mpv relative to audio? Is it in sync, or a
disaster?

If there isn't any player that can play that file correctly, we can forget
about that file, even if the output is different to CCExtractor's (because
we don't know which one is correct). However if mpv plays it correctly
(subtitles and audio are in sync) then we have a problem.

On Sun, Jan 12, 2020 at 1:33 PM Nils ANDRÉ-CHANG notifications@github.com
wrote:

What I do to debug is:

generate subtitles with ccextractor

Play 1 mpv instance with the subtitles from ccextractor and 1
instance with the subtitles directly from the file.

I have a command that makes sure the 2 instances are in sync.

End result:

The results with east enders on master are in sync.

The results with telecine.ts are too early and stay up until the
next subtitle compaired with the other instance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWNNKNAIO22DG6AMCWTQ5OEBVA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXEZXA#issuecomment-573459676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNMTWMF4YEVBYP4A4YORGLQ5OEBVANCNFSM4ITDPF5A
.

@cfsmp3 commented on GitHub (Jan 12, 2020): OK but what about the output of mpv relative to audio? Is it in sync, or a disaster? If there isn't any player that can play that file correctly, we can forget about that file, even if the output is different to CCExtractor's (because we don't know which one is correct). However if mpv plays it correctly (subtitles and audio are in sync) then we have a problem. On Sun, Jan 12, 2020 at 1:33 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > What I do to debug is: > > 1. generate subtitles with ccextractor > 2. Play 1 mpv instance with the subtitles from ccextractor and 1 > instance with the subtitles directly from the file. > 3. I have a command that makes sure the 2 instances are in sync. > > End result: > > - The results with east enders on master are in sync. > - The results with telecine.ts are too early and stay up until the > next subtitle compaired with the other instance. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/CCExtractor/ccextractor/issues/1104?email_source=notifications&email_token=ABNMTWNNKNAIO22DG6AMCWTQ5OEBVA5CNFSM4ITDPF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXEZXA#issuecomment-573459676>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABNMTWMF4YEVBYP4A4YORGLQ5OEBVANCNFSM4ITDPF5A> > . >

claunia commented

2026-01-29 16:45:40 +00:00

@NilsIrl commented on GitHub (Jan 12, 2020):

Yeah MPV (like VLC I assume) gives subtitles that are in sync with the audio (for east enders + telecine).

So the problem is with ccextractor in this specific case.

@NilsIrl commented on GitHub (Jan 12, 2020): Yeah MPV (like VLC I assume) gives subtitles that are in sync with the audio (for east enders + telecine). So the problem is with ccextractor in this specific case.

claunia commented

@cfsmp3 commented on GitHub (Jan 12, 2020):

Can you fix it? :-)

On Sun, Jan 12, 2020 at 1:45 PM Nils ANDRÉ-CHANG
notifications@github.com wrote:

Yeah MPV (like VLC I assume) gives subtitles that are in sync with the audio (for east enders + telecine).

So the problem is with ccextractor in this specific case.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@cfsmp3 commented on GitHub (Jan 12, 2020): Can you fix it? :-) On Sun, Jan 12, 2020 at 1:45 PM Nils ANDRÉ-CHANG <notifications@github.com> wrote: > > Yeah MPV (like VLC I assume) gives subtitles that are in sync with the audio (for east enders + telecine). > > So the problem is with ccextractor in this specific case. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.

claunia commented

@NilsIrl commented on GitHub (Jan 13, 2020):

Can you fix it? :-)

I wish. It doesn't look straightforward at all.

@NilsIrl commented on GitHub (Jan 13, 2020): > Can you fix it? :-) I wish. It doesn't look straightforward at all.

claunia commented

@NilsIrl commented on GitHub (Jan 18, 2020):

Is there a tool I can use so that I can visualise the difference in program flow between two runs (in this case, compare eastenders and telecine)?

@NilsIrl commented on GitHub (Jan 18, 2020): Is there a tool I can use so that I can visualise the difference in program flow between two runs (in this case, compare eastenders and telecine)?

claunia commented

@NilsIrl commented on GitHub (Jan 19, 2020):

For those who want to analyze the flow here is the callgrind output for the command:

TESSDATA_PREFIX=/nix/store/wipcqqi4chy9armmgl9749934sfqzas8-tesseract-4.1.0/share/ valgrind --tool=callgrind ./ccextractor files/01-BBC1.EastEnders.ts

and

TESSDATA_PREFIX=/nix/store/wipcqqi4chy9armmgl9749934sfqzas8-tesseract-4.1.0/share/ valgrind --tool=callgrind ./ccextractor files/telecine.ts

the only difference is the input file. (one works eastenders, and the other has wrong timestamps telecine)

callgrind.zip

I'm posting this here becaues it takes 1+ hour for the commands to run

@NilsIrl commented on GitHub (Jan 19, 2020): For those who want to analyze the flow here is the callgrind output for the command: ```bash TESSDATA_PREFIX=/nix/store/wipcqqi4chy9armmgl9749934sfqzas8-tesseract-4.1.0/share/ valgrind --tool=callgrind ./ccextractor files/01-BBC1.EastEnders.ts ``` and ```bash TESSDATA_PREFIX=/nix/store/wipcqqi4chy9armmgl9749934sfqzas8-tesseract-4.1.0/share/ valgrind --tool=callgrind ./ccextractor files/telecine.ts ``` the only difference is the input file. (one works eastenders, and the other has wrong timestamps telecine) [callgrind.zip](https://github.com/CCExtractor/ccextractor/files/4083669/callgrind.zip) I'm posting this here becaues it takes 1+ hour for the commands to run

claunia commented

@wojtekw commented on GitHub (Feb 3, 2020):

I have similiar problem with ts file.Trying output to spupng but always start of the subtitles is:
<spu start="0.000" end="4.239"

The very weird for me is that ccx shows in output:
Min PTS: 00:00:38:220
Max PTS: 01:53:39:940

So why the first subtitle is 00:00:00 not 00:00:38 ?

Can anyone help? Lost few days for this issue :(

@wojtekw commented on GitHub (Feb 3, 2020): I have similiar problem with ts file.Trying output to spupng but always start of the subtitles is: <spu start="0.000" end="4.239" The very weird for me is that ccx shows in output: Min PTS: 00:00:38:220 Max PTS: 01:53:39:940 So why the first subtitle is 00:00:00 not 00:00:38 ? Can anyone help? Lost few days for this issue :(

claunia commented

@NilsIrl commented on GitHub (Feb 3, 2020):

I have similiar problem with ts file.Trying output to spupng but always start of the subtitles is:
<spu start="0.000" end="4.239"

The very weird for me is that ccx shows in output:
Min PTS: 00:00:38:220
Max PTS: 01:53:39:940

So why the first subtitle is 00:00:00 not 00:00:38 ?

Can anyone help? Lost few days for this issue :(

Could you make the .ts file accessible? That would help a lot.

@NilsIrl commented on GitHub (Feb 3, 2020): > I have similiar problem with ts file.Trying output to spupng but always start of the subtitles is: > <spu start="0.000" end="4.239" > > The very weird for me is that ccx shows in output: > Min PTS: 00:00:38:220 > Max PTS: 01:53:39:940 > > So why the first subtitle is 00:00:00 not 00:00:38 ? > > Can anyone help? Lost few days for this issue :( Could you make the `.ts` file accessible? That would help a lot.

claunia commented

@wojtekw commented on GitHub (Feb 3, 2020):

Unfortunately can't upload this file anywhere. It's movie from one of the majors.

This what I checked that all times are differented of this Min PTS. If I add to every time this Min PTS all would be correct

@wojtekw commented on GitHub (Feb 3, 2020): Unfortunately can't upload this file anywhere. It's movie from one of the majors. This what I checked that all times are differented of this Min PTS. If I add to every time this Min PTS all would be correct

claunia commented