BUG: No captions were found in input. #296

New Issue

claunia · 2026-01-29T16:40:10Z

claunia commented

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

Originally created by @Brentx3 on GitHub (Mar 19, 2017).

I've been successfully using CCExtractor for a few years with my HDHomerunPrime. However recently one channel (Disney) stopped extracting in CCExtractor, but the captions show correctly in VLC media player. I can't figure out why they won't extract.

Link to an example transport stream file:
https://drive.google.com/open?id=0BzchVf99j5mrbUYwSzhQUlJCUDA

CCExtractor Version 0.85

Originally created by @Brentx3 on GitHub (Mar 19, 2017). I've been successfully using CCExtractor for a few years with my HDHomerunPrime. However recently one channel (Disney) stopped extracting in CCExtractor, but the captions show correctly in VLC media player. I can't figure out why they won't extract. Link to an example transport stream file: https://drive.google.com/open?id=0BzchVf99j5mrbUYwSzhQUlJCUDA CCExtractor Version 0.85

claunia closed this issue

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

claunia commented

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

@siddharthjindal1997 commented on GitHub (Mar 21, 2017):

@cfsmp3 this bug also due to premature end of file. here number of bytes received is 0 which is not printed due to
if (result != 188) { if (result > 0) mprint("Premature end of file - Transport Stream packet is incomplete (expected 188 bytes, got %lld).\n", result); return CCX_EOF; }

in file ts_functions.c

it should be result>=0 for printing the error -premature end of file.
can you point me towards solving the premature end of file error.issue- #304

@siddharthjindal1997 commented on GitHub (Mar 21, 2017): @cfsmp3 this bug also due to premature end of file. here number of bytes received is 0 which is not printed due to `if (result != 188) { if (result > 0) mprint("Premature end of file - Transport Stream packet is incomplete (expected 188 bytes, got %lld).\n", result); return CCX_EOF; }` in file ts_functions.c it should be result>=0 for printing the error -premature end of file. can you point me towards solving the premature end of file error.issue- #304

claunia commented

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

@Izaron commented on GitHub (Mar 21, 2017):

@siddharthjindal1997 I guess that result = 0 just means that all packets in the file are correct (not broken), but if we have packet with the size [1..187], that means we have a cropped file or simular error.

@Izaron commented on GitHub (Mar 21, 2017): @siddharthjindal1997 I guess that `result = 0` just means that **all** packets in the file are correct (not broken), but if we have packet with the size [1..187], that means we have a cropped file or simular error.

claunia commented

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

@Brentx3 commented on GitHub (Mar 21, 2017):

I think the 'premature end of file' was my fault, I copied the transport stream while it was recording.

Here is a link to a complete file: https://drive.google.com/open?id=0BzchVf99j5mrYkhmS3dmeXlCclE

Hopefully that is a better example file, that shows the issue better.

@Brentx3 commented on GitHub (Mar 21, 2017): I think the 'premature end of file' was my fault, I copied the transport stream while it was recording. Here is a link to a complete file: https://drive.google.com/open?id=0BzchVf99j5mrYkhmS3dmeXlCclE Hopefully that is a better example file, that shows the issue better.

claunia commented

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

@saurabhshri commented on GitHub (Apr 9, 2017):

The video file doesn't appear to have a separate stream for captions (as tested by tools like mediainfo and ffprobe).

But the output of video stream by ffprobe mentions closed captions :

Stream #0:0[0x7a9]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 704x480 [SAR 10:11 DAR 4:3], Closed Captions, max. 18000 kb/s, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc

This is a direct quote from conversation with @cfsmp3 on slack regarding the same :

It's possible (no idea) that VLC is actually virtual-splitting the video program and that the data is actually in MPEG private data
we also do that ourselves, but maybe now it's stored a bit differently
we'd need to run it in a debugger and see what's going on

It should be helpful for someone working on the issue. :)

@saurabhshri commented on GitHub (Apr 9, 2017): The video file doesn't appear to have a separate stream for captions (as tested by tools like mediainfo and ffprobe). But the output of video stream by ffprobe mentions closed captions : ``` Stream #0:0[0x7a9]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 704x480 [SAR 10:11 DAR 4:3], Closed Captions, max. 18000 kb/s, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc ``` This is a direct quote from conversation with @cfsmp3 on slack regarding the same : >It's possible (no idea) that VLC is actually virtual-splitting the video program and that the data is actually in MPEG private data >we also do that ourselves, but maybe now it's stored a bit differently >we'd need to run it in a debugger and see what's going on It should be helpful for someone working on the issue. :)

claunia commented

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

@cfsmp3 commented on GitHub (Apr 10, 2017):

Fixed in master. Various notes, in case we have to revisit:

VLC source code for PMT parsing: 8924974ac1/modules/demux/mpeg/ts_psi.c

Fixed by doing this in our parse_PMT:
current_next_indicator = buf[5] & 0x01;
// This table is not active, no need to evaluate
if (!current_next_indicator && pinfo->version!=0xFF) // 0xFF means we don't have one yet
return 0;

The current_next_indicator flag is always set to 1 in the sample file (meaning that PMT is not yet active, so we were just skipping it waiting for one with 0, which never happens). Anyway if we don't have a previous PMT at all (pinfo->version is now init'ed to 0xFF) we just use the first we find.

@cfsmp3 commented on GitHub (Apr 10, 2017): Fixed in master. Various notes, in case we have to revisit: - VLC source code for PMT parsing: https://github.com/videolan/vlc/blob/8924974ac13958b2850a9923f07cc11e918279a1/modules/demux/mpeg/ts_psi.c Fixed by doing this in our parse_PMT: current_next_indicator = buf[5] & 0x01; // This table is not active, no need to evaluate if (!current_next_indicator && pinfo->version!=0xFF) // 0xFF means we don't have one yet return 0; The current_next_indicator flag is always set to 1 in the sample file (meaning that PMT is not yet active, so we were just skipping it waiting for one with 0, which never happens). Anyway if we don't have a previous PMT at all (pinfo->version is now init'ed to 0xFF) we just use the first we find.

claunia commented

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

@jaum20 commented on GitHub (May 21, 2022):

I'm facing this error with Disney+ vtt subtitles. For this one, for example. I get:

CCExtractor 0.87, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
--------------------------------------------------------------------------
Input: sub.vtt
[Extract: 1] [Stream mode: Autodetect]
[Program : Auto ] [Hauppage mode: No] [Use MythTV code: Auto]
[Timing mode: Auto] [Debug: No] [Buffer input: No]
[Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No]
[Target format: .srt] [Encoding: UTF-8] [Delay: 0] [Trim lines: No]
[Add font color data: Yes] [Add font typesetting: Yes]
[Convert case: No] [Video-edit join: No]
[Extraction start time: not set (from start)]
[Extraction end time: not set (to end)]
[Live stream: No] [Clock frequency: 90000]
[Teletext page: Autodetect]
[Start credits text: None]
[Quantisation-mode: CCExtractor's internal function]

-----------------------------------------------------------------
Opening file: sub.vtt
File seems to be an elementary stream, enabling ES mode
Analyzing data in general mode
  0%  |  00:00
Number of NAL_type_7: 0
Number of VCL_HRD: 0
Number of NAL HRD: 0
Number of jump-in-frames: 0
Number of num_unexpected_sei_length: 0

Total frames time:	  00:00:00:000  (0 frames at 29.97fps)
Done, processing time = 0 seconds

This file subtitle displays fine in VLC

@jaum20 commented on GitHub (May 21, 2022): I'm facing this error with Disney+ vtt subtitles. For [this one](https://pastebin.com/Git6Zk7R), for example. I get: ``` CCExtractor 0.87, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc -------------------------------------------------------------------------- Input: sub.vtt [Extract: 1] [Stream mode: Autodetect] [Program : Auto ] [Hauppage mode: No] [Use MythTV code: Auto] [Timing mode: Auto] [Debug: No] [Buffer input: No] [Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No] [Target format: .srt] [Encoding: UTF-8] [Delay: 0] [Trim lines: No] [Add font color data: Yes] [Add font typesetting: Yes] [Convert case: No] [Video-edit join: No] [Extraction start time: not set (from start)] [Extraction end time: not set (to end)] [Live stream: No] [Clock frequency: 90000] [Teletext page: Autodetect] [Start credits text: None] [Quantisation-mode: CCExtractor's internal function] ----------------------------------------------------------------- Opening file: sub.vtt File seems to be an elementary stream, enabling ES mode Analyzing data in general mode 0% | 00:00 Number of NAL_type_7: 0 Number of VCL_HRD: 0 Number of NAL HRD: 0 Number of jump-in-frames: 0 Number of num_unexpected_sei_length: 0 Total frames time: 00:00:00:000 (0 frames at 29.97fps) Done, processing time = 0 seconds ``` This file subtitle displays fine in VLC

claunia referenced this issue

2026-01-29 16:59:41 +00:00

[PR #296] Fix CMakeLists.txt #1137

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#296