development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > On Sun, Feb 9, 2025 at 2:14 PM Soft Works
> > wrote:
> > > Numpad alignment 7, LeftMargin=x VertMargin=y
> >
> > Yeah, that could work. I forg
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Sunday, February 9, 2025 9:23 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> On Sun, Feb 9, 2025 at 2:14 PM Soft
On Sun, Feb 9, 2025 at 2:14 PM Soft Works
wrote:
> Numpad alignment 7, LeftMargin=x VertMargin=y
Yeah, that could work. I forgot about margins. I'll play around with it.
Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/m
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Sunday, February 9, 2025 8:38 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Partial reply:
> FFmpeg's C
Partial reply:
FFmpeg's CC decoder is actually pretty decent for pop-on CC
but produces non-compliant ASS that needs postprocessing.
ASS can cover and render the pop-ons quite well, but the fundamental
limitation with representing EIA608 with ASS is that ASS does not
allow arbitrary positioning AN
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devlist Archive
> Sent: Sunday, February 9, 2025 6:42 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> >
> > Not to start
I suspect WebVTT became the modern CC format because...
- It is natively supported by the HLS and DASH specifications
-
https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
-
https://reference.dashif.org/dash.js/latest/samples
>
> Not to start an argument, but WebVTT is kind of a terrible format.
> It's a lowest common denominator and loses most formatting information
> available even in 608 (which is now more than 40 years old). Stuff
> like rollup captions for live programming, color (to distinguish
> speakers) and ca
On Sat, Feb 8, 2025 at 10:39 PM Tom Vaughan wrote:
>
> I'm excited to see this discussion. There are many leading video distributors
> (streaming services, etc.) that would love to see solid support in FFMPEG for
> closed captions. No promises, but my sense is that additional money can be
> rai
I'm excited to see this discussion. There are many leading video distributors
(streaming services, etc.) that would love to see solid support in FFMPEG for
closed captions. No promises, but my sense is that additional money can be
raised to sponsor this development.
WebVTT as a sidecar captions
On Fri, Feb 7, 2025 at 6:59 PM Marth64 wrote:
>
> Hi Devin & Softworks,
>
> I have been working on a slide deck in my spare time with suggestions
> and a roadmap to improve general digital Closed Captions support.
> I hope to share this with you and the community for feedback in the
> next 2 week
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Saturday, February 8, 2025 12:59 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Hi Devin & Softworks,
>
>
Hi Devin & Softworks,
I have been working on a slide deck in my spare time with suggestions
and a roadmap to improve general digital Closed Captions support.
I hope to share this with you and the community for feedback in the
next 2 weeks. I meant to wrap it up sooner but had some IRL stuff come
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marth64
> Sent: Friday, February 7, 2025 11:18 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> (libavcodec’s definition of AV_CODEC_
On Fri, Feb 7, 2025 at 5:18 PM Marth64 wrote:
> (libavcodec’s definition of AV_CODEC_ID_EIA_608 is a fallacy, it is
> actually A/53 Part 4 coding that is passed around with this codec ID,
> which can contain multiple sub-streams including EIA-608 and CEA-708)
I probably wouldn't call it a "fallac
(libavcodec’s definition of AV_CODEC_ID_EIA_608 is a fallacy, it is
actually A/53 Part 4 coding that is passed around with this codec ID,
which can contain multiple sub-streams including EIA-608 and CEA-708)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
Hi, agreed to move on from this thread.
One parting thought, for future readers -- the RCWT muxer in FFmpeg
preserves the A/53 Part 4 coding intact from decoders which provide it
as side data.
So, it would include EIA608 and CEA708 (DTVCC) pairs since the A/53
Part 4 frames from the SEI messages (
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 9:50 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> At some point we will need to
On Fri, Feb 7, 2025 at 3:58 PM Soft Works
wrote:
> You have never successfully "embedded" an scc file as CEA-608.
> I had told you that twice already. Marth64 has told you the same.
>
> That's not possible right now. Your commands are adding the scc
> captions as mov_text (TTXT) subtitle stream, n
; -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 9:50 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> &g
g.org>> On Behalf Of Tom
> > Vaughan
> > Sent: Friday, February 7, 2025 7:36 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org <mailto:de...@ffmpeg.org>>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > Soft Works said...
sage-
> From: ffmpeg-devel <mailto:ffmpeg-devel-boun...@ffmpeg.org>> On Behalf Of Tom
> Vaughan
> Sent: Friday, February 7, 2025 7:36 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org <mailto:de...@ffmpeg.org>>
> Subject: Re: [FFmpeg-devel] Cap
ftworkz-at-hotmail@ffmpeg.org> wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 8:52 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject:
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 8:52 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> >
> > Unfortunately,
On Fri, Feb 7, 2025 at 2:55 PM Devin Heitmueller
wrote:
> And encoder itself should be required.
Correction: I meant to say "An encoder itself should *not* be required".
Devin
--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.co
On Fri, Feb 7, 2025 at 2:52 PM Devlist Archive wrote:
>
> >
> > Unfortunately, there's no bug which could be "fixed".
> > For a proper solution, a CEA-608 ENcoder is required.
> > And more - like already said.
>
>
> Is a CEA-608 encoder actually required for a frame rate change, or is it
> possibl
>
> One thing worth noting is that the filenames in that Google drive
> don't match up with the example commands you've provided. I would
> recommend if you decide to open a ticket to either rename the files or
> change the commands so whoever tries to reproduce the issue knows they
> are working
On Fri, Feb 7, 2025 at 2:31 PM Devlist Archive wrote:
>
> >
> > The cc_fifo mechanism is actually implemented within the various
> > filters which change the framerate (deinterlacing, framerate
> > conversion, interlacing), so no extra command line arguments are
> > required. There are some edge
age-
> > From: ffmpeg-devel On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 8:31 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > >
> > >
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 8:31 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> >
> > The cc_fi
>
> The cc_fifo mechanism is actually implemented within the various
> filters which change the framerate (deinterlacing, framerate
> conversion, interlacing), so no extra command line arguments are
> required. There are some edge cases though that don't properly handle
> it, and those mainly rela
On Fri, Feb 7, 2025 at 1:32 PM Devlist Archive wrote:
> That is good to hear, FYI any time 708 captions present in a DTVCC video
> stream there also must be 608 captions wrapped in that stream for legal
> compliance and backwards compatibility with older downstream equipment
> that downscales to S
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tom
> Vaughan
> Sent: Friday, February 7, 2025 7:36 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Soft Works said... "the CC
el <mailto:ffmpeg-devel-boun...@ffmpeg.org>> On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 6:13 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org <mailto:de...@ffmpeg.org>>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
Hi Zack,
that m
> I've actually got code in the tree to handle framerate changes for
> captions (the cc_fifo mechanism). It works for CC within video
> streams (e.g. user_data or SEI), but isn't implemented in the case
> where you have C608 packets. It might be possible to insert the
> "cc_repack" filter and fra
On Fri, Feb 7, 2025 at 11:42 AM Devlist Archive wrote:
> As such, I may be able to work out an edit workflow by using RCWT to make a
> .bin file, using ccextractor to make an mcc file and importing into an edit
> suite for transcode. The part I will still be missing is something to take
> the .ss
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Rémi Denis-Courmont
> Sent: Friday, February 7, 2025 6:31 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Le perjantaina 7. helmikuut
Le perjantaina 7. helmikuuta 2025, 11.44.36 UTC+2 Jack Lau a écrit :
> Hi softworkz,
>
> Thank you very much for your patient reply and kind suggestions. I am new to
> the FFmpeg devel mailing list, and English is not my native language, so
> there is still a lot for me to learn.
It should be com
Le perjantaina 7. helmikuuta 2025, 10.16.51 UTC+2 Soft Works a écrit :
> The big evil with LLVMs is not the fact they are making mistakes but the
> extreme level of confidence at which they are presenting these mistakes -
> like no human would do. That's why we tend to fall so easily into taking
>
My application is actually to generate a playout library for over the air
TV, then implement a captions data path into a sub project that relies on
ffmpeg for decode/encode. So I need to not just do archival, but build a
library in a usable format. This requires an ingest process for both an
edi
Added bit: RCWT will preserve more than what the SCC muxer does
You can also convert the RCWT back to SCC with a single EIA608 field
array, again with either tool
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
Hey Zach,
Thanks for the additional context.
Embedding in the traditional sense is not available now.
If archival is also a primary goal, have you checked out the RCWT muxer?
This muxer can collect the original EIA608/CEA708 bytes with all
fields, in A53 Part 4 format,
to a preservable file. The
My intent with starting this thread was to recruit at least one developer
to help make sure a solution is found. It kind of got sent off topic to
the user space by some of the replies. My current understanding is that
the tools used in the ffmpeg commands I was using are actually extracting
subti
Hi folks
Zach (Devlist Archive):
Thanks for sharing your experience and I hope a resolution comes out
of it. I encourage you to write this email instead to the ffmpeg-user
list (or possibly TRAC, our bug trucker), which is better suited for
discussing issues like yours.
Let us pivot this conversat
Hi softworkz,
Thank you very much for your patient reply and kind suggestions. I am new to
the FFmpeg devel mailing list, and English is not my native language, so there
is still a lot for me to learn.
May I ask a question? How long does it usually take for a patch to be reviewed?
A few days a
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Jack Lau
> Sent: Friday, February 7, 2025 9:26 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
>
> >
> > Hi Jack,
> &
>
> Hi Jack,
>
> "paying attention next time"? That's not the right answer.
>
> Please make sure that there won't be a next time.
>
> The big evil with LLVMs is not the fact they are making mistakes but the
> extreme level of confidence at which they are presenting these mistakes -
> like n
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Jack Lau
> Sent: Friday, February 7, 2025 8:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> >
> >
> > Hi
>
>
> Hi Zack,
>
> that message from "Jack" had confused me for a moment, but on re-reading it
> appears to be an AI response.
> The content is total nonsense. There is no "SCC" encoder in ffmpeg, and if
> there was one, it wouldn't help much because the CC data needs to get into
> the video
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 6:13 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> On Thu, Feb 6, 2025 a
Hi Jack,
Thanks for the suggestions. Could you please tell me where I can get a
build of ffmpeg that will work with the -c:s scc command? That encoder
doesn't seem to be in the release version I am working with.
It is slightly unclear to me how your suggestion for the extract command
suggestion
> I have been absent from the list for a few years, so I would appreciate it
> if someone could catch me up a bit. I am needing to extract and embed scc
> files with 608 captions. I am pleased to see that transcoding without
> frame rate changes now preserves 608 intact, and there appear to be
Greetings,
I have been absent from the list for a few years, so I would appreciate it
if someone could catch me up a bit. I am needing to extract and embed scc
files with 608 captions. I am pleased to see that transcoding without
frame rate changes now preserves 608 intact, and there appear to b
53 matches
Mail list logo
