--noscte20 RCWT CEA-708 segfault #180

New Issue

claunia · 2026-01-29T16:37:06Z

claunia commented

2026-01-29 16:37:06 +00:00

Originally created by @cactusGit on GitHub (Sep 19, 2016).

Here's sample: http://stream.sunnysubs.com/s06e16_crop.ts
Command lines:

./ccextractor -out=bin -o bin1 s06e16_crop.ts
./ccextractor -out=bin -o bin2 --noscte20 s06e16_crop.ts
./ccextractor -svc 1 -stdout bin1 # no output
./ccextractor -svc 1 -stdout --noscte20 bin1 # no output
./ccextractor -svc 1 -stdout bin2 # segfault
./ccextractor -svc 1 -stdout --noscte20 bin2 # segfault
./ccextractor -svc 1 -stdout s06e16_crop.ts # no output
./ccextractor -svc 1 -stdout --noscte20 s06e16_crop.ts # outputs corrupt 608 and 708

Corrupt 608 is okay, and corrupt 708 subs is issue #426.

Originally created by @cactusGit on GitHub (Sep 19, 2016). Here's sample: http://stream.sunnysubs.com/s06e16_crop.ts Command lines: ``` ./ccextractor -out=bin -o bin1 s06e16_crop.ts ./ccextractor -out=bin -o bin2 --noscte20 s06e16_crop.ts ./ccextractor -svc 1 -stdout bin1 # no output ./ccextractor -svc 1 -stdout --noscte20 bin1 # no output ./ccextractor -svc 1 -stdout bin2 # segfault ./ccextractor -svc 1 -stdout --noscte20 bin2 # segfault ./ccextractor -svc 1 -stdout s06e16_crop.ts # no output ./ccextractor -svc 1 -stdout --noscte20 s06e16_crop.ts # outputs corrupt 608 and 708 ``` Corrupt 608 is okay, and corrupt 708 subs is issue #426.

claunia closed this issue

2026-01-29 16:37:06 +00:00

claunia commented

2026-01-29 16:37:07 +00:00

@cactusGit commented on GitHub (Sep 20, 2016):

Looks like segfault happens here:
https://github.com/CCExtractor/ccextractor/blob/master/src/lib_ccx/ccx_decoders_708_output.c#L404

(gdb) p &(writer->filename)
$1 = (char **) 0x98
(gdb) p &(writer->fd)
$2 = (int *) 0x90
(gdb) bt
#0  0x000000000045111e in ccx_dtvcc_writer_output (writer=0x90, tv=0x9ee960, encoder=0x0) at ../src/lib_ccx/ccx_decoders_708_output.c:404
#1  0x000000000043114b in _dtvcc_screen_print (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120) at ../src/lib_ccx/ccx_decoders_708.c:511
#2  0x0000000000432877 in dtvcc_handle_DLW_DeleteWindows (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, windows_bitmap=0) at ../src/lib_ccx/ccx_decoders_708.c:1029
#3  0x00000000004332aa in _dtvcc_handle_C1 (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, data=0x7ffff7fce84a "\214\001\211\002", data_length=4)
    at ../src/lib_ccx/ccx_decoders_708.c:1319
#4  0x00000000004336bd in ccx_dtvcc_process_service_block (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, data=0x7ffff7fce84a "\214\001\211\002", data_length=4)
    at ../src/lib_ccx/ccx_decoders_708.c:1465
#5  0x0000000000433988 in ccx_dtvcc_process_current_packet (dtvcc=0x7ffff7f55010) at ../src/lib_ccx/ccx_decoders_708.c:1573
#6  0x0000000000416e68 in ccx_dtvcc_process_data (ctx=0x9d6e20, data=0x7fffffffe800 "\001\003C\"", data_length=4) at ../src/lib_ccx/ccx_dtvcc.c:49
#7  0x000000000041c7a9 in do_cb (ctx=0x9d6e20, cc_block=0x9d6a13 "\377C\"\376\214\375\376", sub=0x9d6ea8) at ../src/lib_ccx/ccx_decoders_common.c:194
#8  0x000000000044b576 in rcwt_loop (ctx=0x9d48f0) at ../src/lib_ccx/general_loop.c:1114
#9  0x0000000000406995 in main (argc=4, argv=0x7fffffffea58) at ../src/ccextractor.c:190

@cactusGit commented on GitHub (Sep 20, 2016): Looks like segfault happens here: https://github.com/CCExtractor/ccextractor/blob/master/src/lib_ccx/ccx_decoders_708_output.c#L404 ``` (gdb) p &(writer->filename) $1 = (char **) 0x98 (gdb) p &(writer->fd) $2 = (int *) 0x90 (gdb) bt #0 0x000000000045111e in ccx_dtvcc_writer_output (writer=0x90, tv=0x9ee960, encoder=0x0) at ../src/lib_ccx/ccx_decoders_708_output.c:404 #1 0x000000000043114b in _dtvcc_screen_print (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120) at ../src/lib_ccx/ccx_decoders_708.c:511 #2 0x0000000000432877 in dtvcc_handle_DLW_DeleteWindows (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, windows_bitmap=0) at ../src/lib_ccx/ccx_decoders_708.c:1029 #3 0x00000000004332aa in _dtvcc_handle_C1 (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, data=0x7ffff7fce84a "\214\001\211\002", data_length=4) at ../src/lib_ccx/ccx_decoders_708.c:1319 #4 0x00000000004336bd in ccx_dtvcc_process_service_block (dtvcc=0x7ffff7f55010, decoder=0x7ffff7f55120, data=0x7ffff7fce84a "\214\001\211\002", data_length=4) at ../src/lib_ccx/ccx_decoders_708.c:1465 #5 0x0000000000433988 in ccx_dtvcc_process_current_packet (dtvcc=0x7ffff7f55010) at ../src/lib_ccx/ccx_decoders_708.c:1573 #6 0x0000000000416e68 in ccx_dtvcc_process_data (ctx=0x9d6e20, data=0x7fffffffe800 "\001\003C\"", data_length=4) at ../src/lib_ccx/ccx_dtvcc.c:49 #7 0x000000000041c7a9 in do_cb (ctx=0x9d6e20, cc_block=0x9d6a13 "\377C\"\376\214\375\376", sub=0x9d6ea8) at ../src/lib_ccx/ccx_decoders_common.c:194 #8 0x000000000044b576 in rcwt_loop (ctx=0x9d48f0) at ../src/lib_ccx/general_loop.c:1114 #9 0x0000000000406995 in main (argc=4, argv=0x7fffffffea58) at ../src/ccextractor.c:190 ```

claunia commented

2026-01-29 16:37:07 +00:00

@cfsmp3 commented on GitHub (Sep 21, 2016):

The segfault is fixed. The garbling is not, but that belongs to a separate ticket.

@cfsmp3 commented on GitHub (Sep 21, 2016): The segfault is fixed. The garbling is not, but that belongs to a separate ticket.

claunia referenced this issue

2026-01-29 16:58:51 +00:00

[PR #180] [MERGED] flushing cc buffer every I, P slice for both fields #1063

Sign in to join this conversation.