mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-14 05:25:44 +00:00
[BUG] Output Type webvtt prints styling #489
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 @ggnull35 on GitHub (Feb 22, 2019).
Please prefix your issue with one of the following: [BUG], [PROPOSAL], [QUESTION].
CCExtractor version (using the --version parameter preferably) : git master
In raising this issue, I confirm the following (please check boxes, eg [X] - and delete unchecked ones):
My familiarity with the project is as follows (check one, eg [X] - and delete unchecked ones):
Necessary information
-autoprogram**Video links (replace text below with your links) **
Please make the affected input file available for us (no screenshots, those don't help!). Public links to Dropbox, Google Drive, etc, are all fine. If it is not possible to make it available publicly, send us a private invitation (both Dropbox and Google Drive allow that). In this case we will download the file and upload it to the private developer repository.
Do not upload your file to any location that will require us to sign up or endure a wait list, slow downloads, etc. If your upload expires make sure you keep it active somehow (replace links if needed). Keep in mind that while we go over all tickets some may take a few days, and it's important we have the file available when we actually need it.
Additional information
{issue content here, replace this line with your issue content}
PS: Make sure you set an alert in GitHub so you get notifications about your ticket. We may need to ask questions and we do everything inside GitHub's system.
This command prints styling:
ccextractorwinfull.exe -stdout -ff -webvtt -quant 0 -noru -trim -lf -nots -nobom -nofc -quiet c:\Users\ASUS\Desktop\ScreenHD60sec_ENG.ts
Normally webvtt-full should be printing styling, not webvtt. They have both same output.
C:\Tools\ccextractor\windows\Debug-Full>ccextractorwinfull.exe -stdout -ff -webvtt -quant 0 -noru -trim -lf -nots -nobom -nofc -quiet c:\Users\ASUS\Desktop\ScreenHD60sec_ENG.ts
WEBVTT
STYLE
/* default values /
::cue {
line-height: 5.33vh;
font-size: 4.1vh;
font-family: monospace;
font-style: normal;
font-weight: normal;
background-color: black;
color: white;
}
/ special cue parts /
::cue(c.transparent) {
color: transparent;
}
/ need to set this before changing color, otherwise the color is lost /
::cue(c.semi-transparent) {
color: rgba(0, 0, 0, 0.5);
}
/ need to set this before changing color, otherwise the color is lost /
::cue(c.opaque) {
color: rgba(0, 0, 0, 1);
}
::cue(c.blink) {
text-decoration: blink;
}
::cue(c.white) {
color: white;
}
::cue(c.red) {
color: red;
}
::cue(c.green) {
color: lime;
}
::cue(c.blue) {
color: blue;
}
::cue(c.cyan) {
color: cyan;
}
::cue(c.yellow) {
color: yellow;
}
::cue(c.magenta) {
color: magenta;
}
::cue(c.bg_transparent) {
background-color: transparent;
}
/ need to set this before changing color, otherwise the color is lost /
::cue(c.bg_semi-transparent) {
background-color: rgba(0, 0, 0, 0.5);
}
/ need to set this before changing color, otherwise the color is lost /
::cue(c.bg_opaque) {
background-color: rgba(0, 0, 0, 1);
}
::cue(c.bg_white) {
background-color: white;
}
::cue(c.bg_green) {
background-color: lime;
}
::cue(c.bg_blue) {
background-color: blue;
}
::cue(c.bg_cyan) {
background-color: cyan;
}
::cue(c.bg_red) {
background-color: red;
}
::cue(c.bg_yellow) {
background-color: yellow;
}
::cue(c.bg_magenta) {
background-color: magenta;
}
::cue(c.bg_black) {
background-color: black;
}
/ Examples of combined colors */
::cue(c.bg_white.bg_semi-transparent) {
background-color: rgba(255, 255, 255, 0.5);
}
::cue(c.bg_green.bg_semi-transparent) {
background-color: rgba(0, 256, 0, 0.5);
}
::cue(c.bg_blue.bg_semi-transparent) {
background-color: rgba(0, 0, 255, 0.5);
}
::cue(c.bg_cyan.bg_semi-transparent) {
background-color: rgba(0, 255, 255, 0.5);
}
::cue(c.bg_red.bg_semi-transparent) {
background-color: rgba(255, 0, 0, 0.5);
}
::cue(c.bg_yellow.bg_semi-transparent) {
background-color: rgba(255, 255, 0, 0.5);
}
::cue(c.bg_magenta.bg_semi-transparent) {
background-color: rgba(255, 0, 255, 0.5);
}
::cue(c.bg_black.bg_semi-transparent) {
background-color: rgba(0, 0, 0, 0.5);
}
X-TIMESTAMP-MAP=MPEGTS:65442, LOCAL 00:00:00.000
00:00:10.000 --> 00:00:14.479
You are watching high-quality subtitles
from Screen Subtitling Systems.
00:00:14.600 --> 00:00:19.079
Screen products cover everything from
off-line subtitle preparation systems
00:00:19.200 --> 00:00:22.679
to mu|ti-|anguage, multi-channel,
fully automated transmission solutions.
00:00:22.800 --> 00:00:26.279
Our highly innovative product range
evolves constantly,
00:00:26.400 --> 00:00:30.399
giving our clients
the commercial advantage they need
00:00:30.520 --> 00:00:32.999
in today's highly competitive marketplace.
00:00:33.120 --> 00:00:38.599
Screen is committed to providing
the very best customer service -
00:00:38.720 --> 00:00:44.719
all our products are supported by a
dedicated 24-hour customer support team.
@negative0 commented on GitHub (Mar 21, 2019):
How can I replicate this issue?
@MatejMecka commented on GitHub (Mar 22, 2019):
Please Provide a Sample in order to reproduce it.
@MatejMecka commented on GitHub (Jun 2, 2019):
Can the issue be closed due to the Author not providing a sample to test the bug report?
@FossPrime commented on GitHub (Jun 5, 2019):
I was able to reproduce the bug with
ccextractor -out=webvtt full.mp4on 0.88 (9e212f). Should be noted that-o full.vttfixes the issue, but that's not an option when you have multiple sub tracks. My workaround is to use ffmpeg to convert the srt's from ccextractor.http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4616/Full%20Episode.mp4
@cfsmp3 Please reopen.
On a somewhat separate matter, webvtt-full output causes Gnome Editor (gedit) to interpret all webvtt-full subs as GBK? full.vtt.txt
@FossPrime commented on GitHub (Jun 5, 2019):
There appears to be no guard for writing the header
414a57d97e/src/lib_ccx/ccx_encoders_common.c (L445)using
-o out.vttwill output srt.For reference, I attached the ffmpeg conversion of the ccx srt
ffshort.vtt.txt
I compared the sha1sum of
-out=webvtt-fulland-out=webvtt... they are identical. The main reason why this bug is problematic is ffmpeg4.... it does not handle the fancy webvtt ccx outputs, at all.Seems like ffmpeg #0A line feed for line breaks, while ccx uses a null character then a CR LF. Seems like everything would be much happier without the null character.
@FossPrime commented on GitHub (Jun 5, 2019):
Separate bug...
Our x-timestamp-map is way down. this breaks ffmpeg!
@tozawa-xumo commented on GitHub (Nov 21, 2019):
There is a small error in the X-TIMESTAMP-MAP.
X-TIMESTAMP-MAP=MPEGTS:65442, LOCAL 00:00:00.000
should be corrected to
X-TIMESTAMP-MAP=MPEGTS:65442,LOCAL:00:00:00.000
(no space before "LOCAL" and a colon needed between "LOCAL" and "00:00:00.000"
It's a simple fix on line 217 of ccx_encoders_webvtt.c
@aadibajpai commented on GitHub (Nov 21, 2019):
Start a pull request? 😄
@tozawa-xumo commented on GitHub (Nov 21, 2019):
If that makes things easier for you, I would.