mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-04 05:44:53 +00:00
Options -o1 and -o2 broken #146
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lelegard on GitHub (May 27, 2016).
Options -o1 and -o2 are still documented ("ccextractor -h") but are now broken.
$ ccextractor closed-caption-eia.ts -o1 o1.srt
Error: Error: Parameter -o1 not understood.
$ ccextractor closed-caption-eia.ts -o1 o1.srt -o2 o2.srt
Error: Error: Parameter -o1 not understood.
$ ccextractor closed-caption-eia.ts -o o1.srt -o2 o2.srt
Error: Error: Parameter -o2 not understood.
They used to work at least until version 0.69 and maybe later. I found them broken in 0.79. Also broken in 0.81 (from git repo).
I use ccextractor from a front-end application that I develop (named QtlMovie) and the generated command uses -o1 and -o2 to test the presence of 2 CC streams. I still bundle version 0.69 of ccextractor with QtlMovie but I would like to integrate new versions and be confident that it will remain compatible with future versions.
Could you please restore the support for -o1 and -o2?
Or, alternatively, could you please provide a safe method to detect multiple CC streams that will be supported in all future versions?
Thanks
Thierry
@cfsmp3 commented on GitHub (May 27, 2016):
Those parameters were renamed to -1 and -2 respectively. The change came because CCExtractor no longer opens 1 or 2 files, now it can potentially open a lot since we can have more than 2 languages in digital subtitles.
I've removed the -o1 and -o2 line from the documentation, thanks!
We're working full blast on CCExtractor now (Summer of Code just started) so I strongly recommend you use the newest version and report everything, because these days are the best ones to have issues solved quickly, plus we're always happy to work with fellow developers.
@canihavesomecoffee commented on GitHub (May 27, 2016):
A small justification:
They were not renamed to
-1&-2, but dropped in total.-1,-12and-2have been around for much longer, indicating what CC channel to extract exactly.Before last summer this was accompanied by the
-o1and-o2parameters respectively that would allow you to save the results in totally different named files.As we introduced (better) support for the CEA-708 last summer, which can hold many more CC channels that can be extracted at the same time, we decided to drop those two parameters and create the output files based on the name provided in the
-o(or the input file name if-ois omitted).So in your case, if both would be extracted and you don't pass in the
-ooption, two files would be generated:input.srtandinput_2.srt(assuming an input file namesinput.tsor similar)In the case of a sample with CEA708 for example, expected output would be
input.p1.svc01.srtEdit: for reference purposes, the support was removed last year in commit
0541a2fb62@lelegard commented on GitHub (May 27, 2016):
Hi,
Thanks for the clarification. This makes sense.
In fact, my concern is a little bit different and maybe you can help.
In my tool, QtlMovie, I analyze all components of a file and later let the user select which one to transcode and which subtiltle to burn. For all audio, video and most subtitles, ffmpeg does the job. For Teletext, I handle it directly. I use CCextractor to detect and later extract EIA-608 and CEA-708 only.
Concerning CC extraction, I do not need -o1 and -o2 since I extract only stream and I know which one.
But my first need is to detect which EIA-608 and CEA-708 are present. Previously, I used -o1 and -o2 on the beginning of a file. A non-empty output file indicated the presence of a stream. So, can CCextractor simply report the presence of all streams, without extraction?
If this is currently not possible, it would be a great feature to add. Something like what ffprobe is to ffmpeg, in a machine-friendly format if possible, but most importantly in a format which does not change with versions.
As you say, this is time for requests and reports, so here is one ;)
Thanks
Thierry
@canihavesomecoffee commented on GitHub (May 27, 2016):
If you are in need of detecting which streams are present and don't mind using another library, I'd recommend taking a look at the MediaInfo library. It has options to return XML, and it's also possible to directly integrate it as well.
Apart from that there's a --report option available which does a similar thing.
@lelegard commented on GitHub (May 27, 2016):
Thanks, ccextractor -out=report does what I want.
It did not exist in 0.69. Many things seem to have changed since then. May I count on you to keep always the same output layout in future versions so that an application can parse it reliably?
Small problem, after producing the output, it always ends up with a segmentation fault. I downloaded the version 0.80 windows binaries on a 64-bit Windows 10 machine. Moreover, it needs some DLL's. I will try to compile it statically to remove dependencies and get a standalone ccextractor.exe.
Thanks
Thierry
@canihavesomecoffee commented on GitHub (May 27, 2016):
The report functionality should remain static, and I don't think anyone has plans to change it in the near future.
Anyhow, if it would change at any point it should be mentioned in the version log (docs/CHANGES.TXT), so checking that when upgrading between versions should be sufficient to see if any changes occurred there.
Could you open up a new issue for the segmentation fault? That way we can keep the issues sorted better 👍
Regarding the DLL's: this depends on if you want support for OCR (needed for DVB decoding) or not. If I'm not mistaken it's possible to build from the Visual Studio solution without the OCR enabled, and then you'd get a standalone executable (provided the necessary Microsoft libaries for C support are installed on the system). If this continues to be a problem, please do open another ticket.