ccextractor icon indicating copy to clipboard operation
ccextractor copied to clipboard

Correct timing issues

Open Rosehip1248 opened this issue 7 years ago • 6 comments

I played the file through PotPlayer as VLC frame by frame doesn’t display subtitles. Attached are several screenshots where the subtitles were not necessarily needed to be displayed. However, subtitles are displayed before or after they have to be displayed to have a lead-in or lead out time. This ensures that the person watching the program has time to read the closed captions. A typical lead out can be 500ms as this tends to be the default in subbing software, such as Aegisub. Lead-ins tend to be shorter as a character before has just spoken, the default being 125-200ms.

Sometimes, subtitles are timed to a scene as this makes it easier for the user to read them and understand who is speaking. This is achieved by creating keyframes for the video which detect a scene change and are correct to the millisecond. Attached are subtitles which I timed in Aegisub - which are better suited to the scene, while ensuring characters per second are low so a user can still read the subtitles.

Closed captions tend to be snapped one after each other (there is no time gap between the previous line), to ensure flicker does not occur and become annoying for the user to watch. Usually, subtitles have a millisecond gap between them, causing flicker to occur. In the sample material, there was a slight flicker present. However, this wasn’t too noticeable.

Longer sentences tend to be split as they look better this way. This makes it easier for the user to read the subtitles and can identify when there is a pause between people saying something. Within this clip, there was split sentences where a pause occurred, but to a hard of hearing person it would be hard to identify this as the pause was timed to a scene with no comma. While I re-timed the subtitles, I also ensured that flicker didn’t occur along with split sentences making more sense.

Sample material used - https://sampleplatform.ccextractor.org/sample/297a44921a12ca5c69242ba898d0d5047bea25a1633f4a514ecbbc50ba41d638

Re-timed Files.zip screenshot 1336 screenshot 1337 screenshot 1338 screenshot 1339 screenshot 1335

Rosehip1248 avatar Dec 02 '16 06:12 Rosehip1248

GSoC qualification: This issues gives 4 points (don't underestimate this task).

cfsmp3 avatar Jan 20 '17 00:01 cfsmp3

I would like to work on this issue.

jimboH avatar Feb 20 '18 16:02 jimboH

@jimboH go for it :-) good luck!

cfsmp3 avatar Feb 20 '18 17:02 cfsmp3

I am kind of confused. Have you modified the code as mentioned in last line or suggesting such an edit?

sr6033 avatar Mar 15 '18 09:03 sr6033

For clarification,

  • Do the timestamps of the retimed files correspond to the Teletext subtitles in the sample video?

OR

  • Do the timestamps of the retimed files correspond to the points at which a character begins speaking (with lead-in and lead-out) instead of the Teletext subtitles?

I'm really just trying to isolate the issue - are the produced subtitles are late (first question) or should we pursue a more involved solution in which we determine when different characters begin speaking to correct the subtitles originally present in the video (second question)?

dhrumilp15 avatar Jan 19 '20 20:01 dhrumilp15

There was a very important fix in ffmpeg for not standard containers' time_bases (besides 90k that is), https://github.com/FFmpeg/FFmpeg/commit/a27853a7300bb3c2752256b2fc02f2439619f6f8

It fixes this issue: https://trac.ffmpeg.org/ticket/7912

ValZapod avatar Aug 09 '21 07:08 ValZapod