sendto doesn't seem to be sending #59

New Issue

claunia · 2026-01-29T16:34:11Z

claunia commented

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

Originally created by @slifty on GitHub (Jun 24, 2015).

First: Awesome tool, you guys are awesome.

Second: I'm pulling captions from a UDP stream and I would like to send them to a TCP server.

> ccextractor -s -udp 239.255.251.9:1234 -sendto localhost:9500

In another shell, I've set up a netcat listening to 9500 to test this out:

> nc -l -p 9500

When I run these two commands, the output is as follows:

CCExtractor 0.76, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
--------------------------------------------------------------------------
Input: Network, 239.255.251.9:1234
[Extract: 1] [Stream mode: Autodetect]
[Program : Auto ] [Hauppage mode: No] [Use MythTV code: Auto]

[Timing mode: Auto] [Debug: No] [Buffer input: Yes]
[Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No]
[Target format: .bin] [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: Yes, no timeout] [Clock frequency: 90000]
Teletext page: [Autodetect]
Start credits text: [None]

----------------------------------------------------------------------
Connecting to localhost:9500
connect() error: Connection refused
trying next addres ...

However, it seems to be "connecting" since when I stop the nc early, it shows:

Error: read() error: Connection refused

Note, I'm building something to make it easy to broadcast the captions extracted using ccextractor across a websocket API. I will be sure to update this issue when I figure out what's going on.

Worth noting that when I send the output to stdout with a -stdout flag (and removing sendto) I am seeing captions, so the UDP extraction portion is functioning as expected.

Originally created by @slifty on GitHub (Jun 24, 2015). First: Awesome tool, you guys are awesome. Second: I'm pulling captions from a UDP stream and I would like to send them to a TCP server. ``` shell > ccextractor -s -udp 239.255.251.9:1234 -sendto localhost:9500 ``` In another shell, I've set up a netcat listening to 9500 to test this out: ``` shell > nc -l -p 9500 ``` When I run these two commands, the output is as follows: ``` CCExtractor 0.76, Carlos Fernandez Sanz, Volker Quetschke. Teletext portions taken from Petr Kutalek's telxcc -------------------------------------------------------------------------- Input: Network, 239.255.251.9:1234 [Extract: 1] [Stream mode: Autodetect] [Program : Auto ] [Hauppage mode: No] [Use MythTV code: Auto] [Timing mode: Auto] [Debug: No] [Buffer input: Yes] [Use pic_order_cnt_lsb for H.264: No] [Print CC decoder traces: No] [Target format: .bin] [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: Yes, no timeout] [Clock frequency: 90000] Teletext page: [Autodetect] Start credits text: [None] ---------------------------------------------------------------------- Connecting to localhost:9500 connect() error: Connection refused trying next addres ... ``` However, it seems to be "connecting" since when I stop the nc early, it shows: ``` Error: read() error: Connection refused ``` Note, I'm building something to make it easy to broadcast the captions extracted using ccextractor across a websocket API. I will be sure to update this issue when I figure out what's going on. Worth noting that when I send the output to stdout with a -stdout flag (and removing sendto) I am seeing captions, so the UDP extraction portion is functioning as expected.

claunia closed this issue

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

claunia commented

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

@slifty commented on GitHub (Jun 24, 2015):

All right -- I dug in and it looks like sendto is limited in scope and I misunderstood its purpose.

I'll document my findings here for the next person who has questions:

sendto requires a confirmation byte (1) to be returned after each message.
in the current build (0.67), sendto can only send binary format. You can read more about this format here: https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT

I'm likely going to need to fork ccextractor and modify the sendto functionality to send whatever the -out format is, since I don't want to have to write a binary transcript format parser in nodejs!

I'll leave this issue open for the next day or so in case a core contributor comes around and wants to weigh in. Otherwise I'll be closing this issue since sendto is functioning as coded.

@slifty commented on GitHub (Jun 24, 2015): All right -- I dug in and it looks like sendto is limited in scope and I misunderstood its purpose. I'll document my findings here for the next person who has questions: 1. sendto requires a confirmation byte (1) to be returned after each message. 2. in the current build (0.67), sendto can only send binary format. You can read more about this format here: https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT I'm likely going to need to fork ccextractor and modify the sendto functionality to send whatever the -out format is, since I don't want to have to write a binary transcript format parser in nodejs! I'll leave this issue open for the next day or so in case a core contributor comes around and wants to weigh in. Otherwise I'll be closing this issue since sendto is functioning as coded.

claunia commented

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

@canihavesomecoffee commented on GitHub (Jun 25, 2015):

This was added as part of last years GSoC by @rkuchumov, where the goal was to be able to capture the raw packets on one instance and decode it on another. I'm not sure what his plans are for this summer, but maybe he can help you out :)

On a sidenote, with a bit of luck it might be added in the near future (@kisselef seems to be working on something similar: bd050f6505).

@canihavesomecoffee commented on GitHub (Jun 25, 2015): This was added as part of last years GSoC by @rkuchumov, where the goal was to be able to capture the raw packets on one instance and decode it on another. I'm not sure what his plans are for this summer, but maybe he can help you out :) On a sidenote, with a bit of luck it might be added in the near future (@kisselef seems to be working on something similar: https://github.com/kisselef/ccextractor/commit/bd050f6505e1384bfdd059c78d50814a18d1caca).

claunia commented

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

@slifty commented on GitHub (Jun 25, 2015):

Thanks @wforums for the context! That makes complete sense; @kisselef let me know if there is any help I can provide, I don't want to redouble your effort. One thought on the referenced commit is that I wonder if there is a way to make -sendto do it all, rather than having two somewhat similar flags.

The use case I'm looking to support is to be able to specify a host/port pair to receive whatever output is specified (instead of a file or stdout). Maybe this would be something like -netout (or a modification of -o to take in network paths somehow?)

@slifty commented on GitHub (Jun 25, 2015): Thanks @wforums for the context! That makes complete sense; @kisselef let me know if there is any help I can provide, I don't want to redouble your effort. One thought on the referenced commit is that I wonder if there is a way to make -sendto do it all, rather than having two somewhat similar flags. The use case I'm looking to support is to be able to specify a host/port pair to receive whatever output is specified (instead of a file or stdout). Maybe this would be something like -netout (or a modification of -o to take in network paths somehow?)

claunia commented

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

@rkuchumov commented on GitHub (Jun 25, 2015):

-tcp and -sendto use a protocol which goal is to send captions to the repository. This protocol supports a passwords and some additional information. That's why there are confirmation bytes. In the end, it sends data in BIN format which is decoded at the server side to TTXT, SRT, ...

If I understood you correctly, you want to send extracted cc data (in txt, srt) to a server, don't you? why not just: nc -l -p 2048 and ccextractor file -stdout -quiet -out=txt | nc 127.0.0.1 2048 ?

@rkuchumov commented on GitHub (Jun 25, 2015): -tcp and -sendto use a protocol which goal is to send captions to the repository. This protocol supports a passwords and some additional information. That's why there are confirmation bytes. In the end, it sends data in BIN format which is decoded at the server side to TTXT, SRT, ... If I understood you correctly, you want to send extracted cc data (in txt, srt) to a server, don't you? why not just: `nc -l -p 2048` and `ccextractor file -stdout -quiet -out=txt | nc 127.0.0.1 2048` ?

claunia commented

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

@slifty commented on GitHub (Jun 25, 2015):

@rkuchumov That's exactly what I'll do -- I just got sucked down a rabbit hole and didn't think beyond ccextractor. Thank you!

@slifty commented on GitHub (Jun 25, 2015): @rkuchumov That's exactly what I'll do -- I just got sucked down a rabbit hole and didn't think beyond ccextractor. Thank you!

claunia referenced this issue

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

[PR #59] [MERGED] Support for configuration file #953

claunia referenced this issue

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

[PR #59] Support for configuration file #956

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#59