[FFmpeg-devel] Captions SCC

[FFmpeg-devel] Captions SCC

[Devlist Archive]

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 be
extraction and embed functions but they do seem to have bugs for my files
at 1080p2997.  Are there any developers willing to take on a paid project
to fix whatever is the issue?  Here are the commands I am working with.

Embed:
"C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -i
"C:\Users\Captions\AIM-2301_premiereDF.mp4" -i
"C:\Captions\AIM-2301_premiereDF.mp4.scc" -map 0:v -map 0:a -map 1 -c:v
copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng
"C:\Captions\AIM-2301_premiereDFcopy.mp4"

Extract:
"C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -f lavfi -i
"movie=\'C:\\Captions\\AIM-2301_premiereDF_ffmpegEmbedscc.mp4\'"[out+subcc]
-map 0:1 -c:s copy "C:\Captions\AIM-2301_premiereDF_ffmpegEmbedscc.scc"


https://drive.google.com/drive/folders/13NXvUgE1EIyLR4WBw30l4NVtS5w33EM7?usp=sharing

The file outputs are included in that drive folder.  Please don't
distribute the files online, but you can use them for testing.  The folder
will go away when the job is complete.  I have requested sample files for
distribution from the content provider, but haven't received those yet.

The objective is to fix the character duplication and data spill out that
is happening during extraction and embedding of scc files for these
resolutions.  I will try to get some 1080i samples also, but don't have
those available in source file form at the moment.  There will be other
captions related projects available once this one is complete.

Thanks,

Zach Swena
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Jack Lau]

> 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
> extraction and embed functions but they do seem to have bugs for my files
> at 1080p2997.  Are there any developers willing to take on a paid project
> to fix whatever is the issue?  Here are the commands I am working with.
> 
> Embed:
> "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -i
> "C:\Users\Captions\AIM-2301_premiereDF.mp4" -i
> "C:\Captions\AIM-2301_premiereDF.mp4.scc" -map 0:v -map 0:a -map 1 -c:v
> copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng
> "C:\Captions\AIM-2301_premiereDFcopy.mp4"
> 
> Extract:
> "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -f lavfi -i
> "movie=\'C:\\Captions\\AIM-2301_premiereDF_ffmpegEmbedscc.mp4\'"[out+subcc]
> -map 0:1 -c:s copy "C:\Captions\AIM-2301_premiereDF_ffmpegEmbedscc.scc”
> 


Hi,

I’ve reviewed the issue with embedding and extracting 608 SCC captions at 1080p2997 resolution and identified a few areas that might help resolve the character duplication and data spill. Here's a summary of my findings:

The current command uses -c:s mov_text, but SCC files may work better with -c:s scc to preserve the format correctly.
The current command uses a filtergraph that might not map correctly for SCC extraction. Instead, try simplifying the extraction command: -map 0:s:0 -c:s copy
Frame Rate Issues: Ensure the video frame rate and the SCC file frame rate match. You might want to force a specific frame rate (e.g., -r 29.97).

Let me know if you have further questions.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

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 should be implemented.  All of my media files I am working with
now are the same frame rate, but forcing a frame rate prior to embedding is
probably a good idea.  I had assumed there were still bugs in the code for
this, but it would be nice if extraction/embedding could work without
having to  change more.

Zach

On Thu, Feb 6, 2025 at 4:57 AM Jack Lau <jacklau1222gm@gmail.com> wrote:

>
>
> > 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
> > extraction and embed functions but they do seem to have bugs for my files
> > at 1080p2997.  Are there any developers willing to take on a paid project
> > to fix whatever is the issue?  Here are the commands I am working with.
> >
> > Embed:
> > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -i
> > "C:\Users\Captions\AIM-2301_premiereDF.mp4" -i
> > "C:\Captions\AIM-2301_premiereDF.mp4.scc" -map 0:v -map 0:a -map 1 -c:v
> > copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng
> > "C:\Captions\AIM-2301_premiereDFcopy.mp4"
> >
> > Extract:
> > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -f lavfi -i
> >
> "movie=\'C:\\Captions\\AIM-2301_premiereDF_ffmpegEmbedscc.mp4\'"[out+subcc]
> > -map 0:1 -c:s copy "C:\Captions\AIM-2301_premiereDF_ffmpegEmbedscc.scc”
> >
>
>
> Hi,
>
> I’ve reviewed the issue with embedding and extracting 608 SCC captions at
> 1080p2997 resolution and identified a few areas that might help resolve the
> character duplication and data spill. Here's a summary of my findings:
>
> The current command uses -c:s mov_text, but SCC files may work better with
> -c:s scc to preserve the format correctly.
> The current command uses a filtergraph that might not map correctly for
> SCC extraction. Instead, try simplifying the extraction command: -map 0:s:0
> -c:s copy
> Frame Rate Issues: Ensure the video frame rate and the SCC file frame rate
> match. You might want to force a specific frame rate (e.g., -r 29.97).
>
> Let me know if you have further questions.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 6:13 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> On Thu, Feb 6, 2025 at 4:57 AM Jack Lau <jacklau1222gm@gmail.com>
> wrote:
> 
> >
> >
> > > 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
> > > extraction and embed functions but they do seem to have bugs for
> my files
> > > at 1080p2997.  Are there any developers willing to take on a paid
> project
> > > to fix whatever is the issue?  Here are the commands I am working
> with.
> > >
> > > Embed:
> > > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -i
> > > "C:\Users\Captions\AIM-2301_premiereDF.mp4" -i
> > > "C:\Captions\AIM-2301_premiereDF.mp4.scc" -map 0:v -map 0:a -map
> 1 -c:v
> > > copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng
> > > "C:\Captions\AIM-2301_premiereDFcopy.mp4"
> > >
> > > Extract:
> > > "C:\FFmpeg\ffmpeg7.1_2024-12-14\ffmpeg.exe" -f lavfi -i
> > >
> > "movie=\'C:\\Captions\\AIM-
> 2301_premiereDF_ffmpegEmbedscc.mp4\'"[out+subcc]
> > > -map 0:1 -c:s copy "C:\Captions\AIM-
> 2301_premiereDF_ffmpegEmbedscc.scc”
> > >
> >
> >
> > Hi,
> >
> > I’ve reviewed the issue with embedding and extracting 608 SCC
> captions at
> > 1080p2997 resolution and identified a few areas that might help
> resolve the
> > character duplication and data spill. Here's a summary of my
> findings:
> >
> > The current command uses -c:s mov_text, but SCC files may work
> better with
> > -c:s scc to preserve the format correctly.
> > The current command uses a filtergraph that might not map correctly
> for
> > SCC extraction. Instead, try simplifying the extraction command: -
> map 0:s:0
> > -c:s copy
> > Frame Rate Issues: Ensure the video frame rate and the SCC file
> frame rate
> > match. You might want to force a specific frame rate (e.g., -r
> 29.97).
> >
> > Let me know if you have further questions.
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

> 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 should be implemented.  All of my media files I am working
> with
> now are the same frame rate, but forcing a frame rate prior to
> embedding is
> probably a good idea.  I had assumed there were still bugs in the
> code for
> this, but it would be nice if extraction/embedding could work without
> having to  change more.
> 
> Zach


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 frames - so that it exists as input to the video encoder.
For the same reason, it is also not possible to add CCs at the muxer level. It always requires video encoding because the data needs to get into the video stream itself, so there's no way to get data from an SCC file into a video stream currently.

The only way in the ffmpeg architecture to get CC data encoded would be at the filtering level. The Subtitle Filtering patchset that I have submitted a while ago has a "splitcc" filter which has video as input and a video plus a subtitle pin/pad at the output side.
What would be needed is a reverse pendant like a "mergecc" filter with video and subtitles input - plus a CEA-608/708 encoder.

softworkz



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Jack Lau]

> 
> 
> 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 frames - so that it exists as input to the video encoder.
> For the same reason, it is also not possible to add CCs at the muxer level. It always requires video encoding because the data needs to get into the video stream itself, so there's no way to get data from an SCC file into a video stream currently.
> 
> The only way in the ffmpeg architecture to get CC data encoded would be at the filtering level. The Subtitle Filtering patchset that I have submitted a while ago has a "splitcc" filter which has video as input and a video plus a subtitle pin/pad at the output side.
> What would be needed is a reverse pendant like a "mergecc" filter with video and subtitles input - plus a CEA-608/708 encoder.
> 
> softworkz
> 


Hi softworkz,

Sorry about that, The response is indeed from AI. I thought this question was enough for AI to answer, I will pay attention to it next time.

Thank you for pointing it out.

Jack
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Jack Lau
> Sent: Friday, February 7, 2025 8:58 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> >
> >
> > 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 frames - so that it exists as input to the
> video encoder.
> > For the same reason, it is also not possible to add CCs at the
> muxer level. It always requires video encoding because the data needs
> to get into the video stream itself, so there's no way to get data
> from an SCC file into a video stream currently.
> >
> > The only way in the ffmpeg architecture to get CC data encoded
> would be at the filtering level. The Subtitle Filtering patchset that
> I have submitted a while ago has a "splitcc" filter which has video
> as input and a video plus a subtitle pin/pad at the output side.
> > What would be needed is a reverse pendant like a "mergecc" filter
> with video and subtitles input - plus a CEA-608/708 encoder.
> >
> > softworkz
> >
> 
> 
> Hi softworkz,
> 
> Sorry about that, The response is indeed from AI. I thought this
> question was enough for AI to answer, I will pay attention to it next
> time.
> 
> Thank you for pointing it out.
> 
> 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 no human would do.
That's why we tend to fall so easily into taking their trash for granted.

sw


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Jack Lau]

> 
> 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 no human would do.
> That's why we tend to fall so easily into taking their trash for granted.
> 
> sw
> 
> 

Hi softworkz,

Thanks for your reply and reminder, I’ll ensure there won't be a next time.

Jack

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Jack Lau
> Sent: Friday, February 7, 2025 9:26 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> 
> >
> > 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 no human would do.
> > That's why we tend to fall so easily into taking their trash for
> granted.
> >
> > sw
> >
> >
> 
> Hi softworkz,
> 
> Thanks for your reply and reminder, I’ll ensure there won't be a next
> time.
> 
> Jack


Hi Jack,

thanks for your reply and understanding. I wanted to note that it's not about wrong answers in general. 
An answer from yourself that starts with "I think" or similar is very welcome, even when it might be wrong. :-)

sw




_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Jack Lau]

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 ago, I submitted a patch titled "[PATCH] examples/transcoding: Fix time_base handling," but it seems that no one has reviewed it yet. I understand everyone is busy, but I was wondering if there has been any feedback or if there are any concerns regarding the patch.

Jack

> 
> Hi Jack,
> 
> thanks for your reply and understanding. I wanted to note that it's not about wrong answers in general. 
> An answer from yourself that starts with "I think" or similar is very welcome, even when it might be wrong. :-)
> 
> sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Marth64]

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 conversation there.

Jack Lau:
I know you mean well and are trying to help. LLM are useful tools, I
would however recommend giving a heads up that the content was being
generated so it does not spook people.
Regarding your own patch, you may send a "Ping" note on your email if
within a reasonable amount of time nobody has reviewed it (sometimes
it takes several days, so 5-7 days is a reasonable time to ping).

That said, I think this is thread off topic for the development list's
core purpose.
I suggest the above steps forward to get this through the right channels.

Thank you!
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

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
subtitles from the video rather than preserving all the captions data like
I thought they were intended to do.  I will take the discussion on the bug
like stuff over to TRAC, but I am still looking for a developer that thinks
they have the skills to implement functions that will preserve display
information in addition to the text.  Correct me if I'm wrong, but my
understanding is that those other lists are for help with user space
commands and bug issues (which is what this thread became) and not
development and trying to communicate with developers about specific
projects and patches.

So to pivot this thread back to its intended purpose, is there anyone in
addition to Soft Works that has an interest in captions filtering topics
and would like to be involved in discussing the specifics of a solution for
608/708 filtering, extraction, and embedding off list so that the required
code can be generated and submitted?

Zach

On Fri, Feb 7, 2025 at 7:39 AM Marth64 <marth64@proxyid.net> wrote:

> 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 conversation there.
>
> Jack Lau:
> I know you mean well and are trying to help. LLM are useful tools, I
> would however recommend giving a heads up that the content was being
> generated so it does not spook people.
> Regarding your own patch, you may send a "Ping" note on your email if
> within a reasonable amount of time nobody has reviewed it (sometimes
> it takes several days, so 5-7 days is a reasonable time to ping).
>
> That said, I think this is thread off topic for the development list's
> core purpose.
> I suggest the above steps forward to get this through the right channels.
>
> Thank you!
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Marth64]

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 RCWT format is ccextractor's native format
for archival and is publically documented.

You can do something like,
ffmpeg -f lavfi -i "movie=MyMovie.mkv[out+subcc]" -map 0:s -c:s copy
-f rcwt MyMoviePreservedCC.bin

Then postprocess with either ccextractor or FFmpeg, eg
ffmpeg -i MyMoviePreservedCC.bin output.ass
or
ccextractor -trim MyMoviePreservedCC.bin

FFmpeg's EIA608 decoder does an OK job of preserving some formatting
when converting to ASS.
RCWT gives you archival and post processing flexibility.


Does this help?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Marth64]

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/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

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
edit workflow and playout.

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 .ssc file output from Premiere and put it back in the .mp4 container.
Embedding seems to be present for some forms of subtitles, but not for a
proper captions file generated by MacCaption or Captionmaker which is
software I am trying to avoid having to buy as I would much rather those
funds go towards development.  One solution I guess would be to just
require sidecar files for playout which I would prefer not to require.  I
can look into those solutions off list.  MCC files or other formats that
support 708 are the ideal, but 608 is all that is required.

If anyone else has ideas or interest in developing a more integrated
process for ffmpeg, I may still be interested in funding that after I
investigate the above solutions off list.

Zach


On Fri, Feb 7, 2025 at 8:37 AM Marth64 <marth64@proxyid.net> wrote:

> 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/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Rémi Denis-Courmont]

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
> their trash for granted.

I am not alone in thinking that your anger here is completely justified.

But still, please watch your language, especially whilst confusing things
(LLM and LLVM).

-- 
Rémi Denis-Courmont
Tapio's place new town, former Finnish Republic of Uusimaa



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Rémi Denis-Courmont]

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 common sense that when you quote something, you are responsible 
for verifying the content and, especially if you cannot vouch 100% for it, you 
have to make it explicit that it is a quote. Otherwise, you are endorsing what 
you send.

Not being a native speaker of the target language may excuse some level of 
misspeaking in one's own prose. Most people (including myself) here are also 
not native English speakers. It does not in any way excuse posting misleading 
nonsense from an LLM (or from elsewhere on the Internet).

The CC has received a complaint already. If *anyone* does this again, the CC 
may very well take action.

-- 
Rémi Denis-Courmont
Villeneuve de Tapiola, ex-République finlandaise d´Uusimaa



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Rémi Denis-Courmont
> Sent: Friday, February 7, 2025 6:31 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> 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
> > their trash for granted.
> 
> I am not alone in thinking that your anger here is completely
> justified.
> 
> But still, please watch your language, especially whilst confusing
> things
> (LLM and LLVM).
> 
> --
> Rémi Denis-Courmont
> Tapio's place new town, former Finnish Republic of Uusimaa

Hi Rémi,

right you are. I'm wondering whether this is a matter of getting older: I notice that it increasingly happens that my head is thinking one thing and my fingers are typing something else (but similar).
I'm a bit worried, tbh 😊

Best,
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Fri, Feb 7, 2025 at 11:42 AM Devlist Archive <devlist@rlb.org> 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 .ssc file output from Premiere and put it back in the .mp4 container.
> Embedding seems to be present for some forms of subtitles, but not for a
> proper captions file generated by MacCaption or Captionmaker which is
> software I am trying to avoid having to buy as I would much rather those
> funds go towards development.  One solution I guess would be to just
> require sidecar files for playout which I would prefer not to require.  I
> can look into those solutions off list.  MCC files or other formats that
> support 708 are the ideal, but 608 is all that is required.

For what it's worth, ffmpeg does have an MCC demuxer, but not a muxer.
Writing one though would be pretty easy (it's a relatively simple
format).  Probably the bigger issue is that internally ffmpeg tends to
strip out all the 708 when using the "subcc" mechanism, only
preserving the 608 tuples.

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 framerate conversion in the first part of the
command before sending the CC data to before handing off the data to
the subcc output.  That said, I've never tried it and would probably
have to play around with it to get the syntax right.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

> 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 framerate conversion in the first part of the
> command before sending the CC data to before handing off the data to
> the subcc output.  That said, I've never tried it and would probably
> have to play around with it to get the syntax right.

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 SD.  Typically files come in with both 608 and 708
streams, but sometimes there will only be a 608 stream.  Regulations only
require 608, but 708 support is ideal.

I noticed that either the RCWT or ccextractor scc process is also messing
with the display duration of the captions, so that is not a currently
functional workflow for me.  Probably has something to do with the
processing subcc is doing.  At least that workflow makes a more accurate
scc file than what is produced when using ffmpeg's ability to write the
.scc file directly.

The functions on my wish list are full 708/608 support for extraction and
embedding to/from mcc and preserving 708/608 during frame rate conversion
and transcoding with ffmpeg.  I have been pleased to see that transcoding
now works with standard commands, but frame rate conversion using normal
commands does not automatically invoke the cc_fifo mechanism or cc_repack.
It would seem that captions should be handled correctly automatically and
not need special filter commands to preserve them.  The captions I work
with are basically user data captions but in an mp4 file according to SCTE
128 / DTVCC Transport.

Zach



On Fri, Feb 7, 2025 at 10:05 AM Devin Heitmueller <
devin.heitmueller@ltnglobal.com> wrote:

> On Fri, Feb 7, 2025 at 11:42 AM Devlist Archive <devlist@rlb.org> 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 .ssc file output from Premiere and put it back in the .mp4 container.
> > Embedding seems to be present for some forms of subtitles, but not for a
> > proper captions file generated by MacCaption or Captionmaker which is
> > software I am trying to avoid having to buy as I would much rather those
> > funds go towards development.  One solution I guess would be to just
> > require sidecar files for playout which I would prefer not to require.  I
> > can look into those solutions off list.  MCC files or other formats that
> > support 708 are the ideal, but 608 is all that is required.
>
> For what it's worth, ffmpeg does have an MCC demuxer, but not a muxer.
> Writing one though would be pretty easy (it's a relatively simple
> format).  Probably the bigger issue is that internally ffmpeg tends to
> strip out all the 708 when using the "subcc" mechanism, only
> preserving the 608 tuples.
>
> 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 framerate conversion in the first part of the
> command before sending the CC data to before handing off the data to
> the subcc output.  That said, I've never tried it and would probably
> have to play around with it to get the syntax right.
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Tom Vaughan]

Soft Works said... "the CC data needs to get into the video frames - so that it exists as input to the video encoder.
For the same reason, it is also not possible to add CCs at the muxer level. It always requires video encoding because the data needs to get into the video stream itself, so there's no way to get data from an SCC file into a video stream currently."

You're confusing subtitles with closed captions. Subtitles are text that is composited into the video. CEA-708 closed captions are carried as metadata in SEI NAL units, muxed into the elementary video stream.

Tom

On 2/6/25, 11:48 PM, "ffmpeg-devel on behalf of Soft Works" <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org> on behalf of softworkz-at-hotmail.com@ffmpeg.org <mailto:softworkz-at-hotmail.com@ffmpeg.org>> wrote:


> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org>> On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 6:13 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org <mailto:devel@ffmpeg.org>>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
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 frames - so that it exists as input to the video encoder.
For the same reason, it is also not possible to add CCs at the muxer level. It always requires video encoding because the data needs to get into the video stream itself, so there's no way to get data from an SCC file into a video stream currently.

The only way in the ffmpeg architecture to get CC data encoded would be at the filtering level. The Subtitle Filtering patchset that I have submitted a while ago has a "splitcc" filter which has video as input and a video plus a subtitle pin/pad at the output side.
What would be needed is a reverse pendant like a "mergecc" filter with video and subtitles input - plus a CEA-608/708 encoder.

softworkz

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Tom
> Vaughan
> Sent: Friday, February 7, 2025 7:36 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Soft Works said... "the CC data needs to get into the video frames -
> so that it exists as input to the video encoder.
> For the same reason, it is also not possible to add CCs at the muxer
> level. It always requires video encoding because the data needs to
> get into the video stream itself, so there's no way to get data from
> an SCC file into a video stream currently."

Hi Tom,

> You're confusing subtitles with closed captions. 

No.

> Subtitles are text that is composited into the video.

No.

> CEA-708 closed captions are
> carried as metadata in SEI NAL units, muxed into the elementary video
> stream.

I wouldn't call this "muxing" but that's not worth a debate.
(you might want to spend a thought on why it's called "elementary stream")


I said "it is also not possible to add CCs at the muxer level".

By that I mean "muxing" in ffmpeg terminology which is unambiguous.

sw


> 
> On 2/6/25, 11:48 PM, "ffmpeg-devel on behalf of Soft Works" <ffmpeg-
> devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org> on
> behalf of softworkz-at-hotmail.com@ffmpeg.org <mailto:softworkz-at-
> hotmail.com@ffmpeg.org>> wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-
> devel-bounces@ffmpeg.org>> On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 6:13 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org <mailto:devel@ffmpeg.org>>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> 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 frames - so that it exists as input to the
> video encoder.
> For the same reason, it is also not possible to add CCs at the muxer
> level. It always requires video encoding because the data needs to
> get into the video stream itself, so there's no way to get data from
> an SCC file into a video stream currently.
> 
> The only way in the ffmpeg architecture to get CC data encoded would
> be at the filtering level. The Subtitle Filtering patchset that I
> have submitted a while ago has a "splitcc" filter which has video as
> input and a video plus a subtitle pin/pad at the output side.
> What would be needed is a reverse pendant like a "mergecc" filter
> with video and subtitles input - plus a CEA-608/708 encoder.
> 
> softworkz
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Fri, Feb 7, 2025 at 1:32 PM Devlist Archive <devlist@rlb.org> 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 SD.  Typically files come in with both 608 and 708
> streams, but sometimes there will only be a 608 stream.  Regulations only
> require 608, but 708 support is ideal.

Yeah, almost everybody ignores the 708 data, and in fact in most cases
the content is authored in 608 and then upconverted to 708 (i.e. so
you don't get any of the benefits of 708).  It's unfortunate how that
turned out, but it's largely related to economics for the content
providers.

I considered adding a c708 AVPacket format which preserves the 708
data, but never got around to it.  Even the MCC demuxer in ffmpeg
right now only uses the 608 tuples and throws away the 708 data.  It's
kind of a mess.

> I noticed that either the RCWT or ccextractor scc process is also messing
> with the display duration of the captions, so that is not a currently
> functional workflow for me.  Probably has something to do with the
> processing subcc is doing.  At least that workflow makes a more accurate
> scc file than what is produced when using ffmpeg's ability to write the
> .scc file directly.
>
> The functions on my wish list are full 708/608 support for extraction and
> embedding to/from mcc and preserving 708/608 during frame rate conversion
> and transcoding with ffmpeg.  I have been pleased to see that transcoding
> now works with standard commands, but frame rate conversion using normal
> commands does not automatically invoke the cc_fifo mechanism or cc_repack.
> It would seem that captions should be handled correctly automatically and
> not need special filter commands to preserve them.  The captions I work
> with are basically user data captions but in an mp4 file according to SCTE
> 128 / DTVCC Transport.

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 relate to cases such as the captions crossing
back/forth between SEI and dedicated caption tracks (e.g. MP4 with a
caption track, the subcc output, etc).

The cc_repack filter itself should almost never be actually used.
It's there mainly to deal with certain broken streams to regenerate
the padding in a conformant manner (e.g. deals with cases where an
incorrect amount of padding is in the source stream, the 608 tuples
violate the interleaving rules, etc).

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> 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 relate to cases such as the captions crossing
> back/forth between SEI and dedicated caption tracks (e.g. MP4 with a
> caption track, the subcc output, etc).
>

Ok, based on this information I am going to make a bug report ticket for
the particular type of mp4 files I am using because while some caption data
is passed, it is garbled and the transcoding process is producing errors.
I was not aware that some work had been done to try to solve the frame rate
conversion issue already as the behaviour of ffmpeg implies that it doesn't
try to compensate for those changes for the file types I am working with.
There are also bugs in the subcc function that seem to be affecting display
time and other metadata.

I assume that it would be more efficient and better to fix the existing 608
only data path before trying to expand things to include 708?

Zach

On Fri, Feb 7, 2025 at 11:03 AM Devin Heitmueller <
devin.heitmueller@ltnglobal.com> wrote:

> On Fri, Feb 7, 2025 at 1:32 PM Devlist Archive <devlist@rlb.org> 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 SD.  Typically files come in with both 608 and 708
> > streams, but sometimes there will only be a 608 stream.  Regulations only
> > require 608, but 708 support is ideal.
>
> Yeah, almost everybody ignores the 708 data, and in fact in most cases
> the content is authored in 608 and then upconverted to 708 (i.e. so
> you don't get any of the benefits of 708).  It's unfortunate how that
> turned out, but it's largely related to economics for the content
> providers.
>
> I considered adding a c708 AVPacket format which preserves the 708
> data, but never got around to it.  Even the MCC demuxer in ffmpeg
> right now only uses the 608 tuples and throws away the 708 data.  It's
> kind of a mess.
>
> > I noticed that either the RCWT or ccextractor scc process is also messing
> > with the display duration of the captions, so that is not a currently
> > functional workflow for me.  Probably has something to do with the
> > processing subcc is doing.  At least that workflow makes a more accurate
> > scc file than what is produced when using ffmpeg's ability to write the
> > .scc file directly.
> >
> > The functions on my wish list are full 708/608 support for extraction and
> > embedding to/from mcc and preserving 708/608 during frame rate conversion
> > and transcoding with ffmpeg.  I have been pleased to see that transcoding
> > now works with standard commands, but frame rate conversion using normal
> > commands does not automatically invoke the cc_fifo mechanism or
> cc_repack.
> > It would seem that captions should be handled correctly automatically and
> > not need special filter commands to preserve them.  The captions I work
> > with are basically user data captions but in an mp4 file according to
> SCTE
> > 128 / DTVCC Transport.
>
> 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 relate to cases such as the captions crossing
> back/forth between SEI and dedicated caption tracks (e.g. MP4 with a
> caption track, the subcc output, etc).
>
> The cc_repack filter itself should almost never be actually used.
> It's there mainly to deal with certain broken streams to regenerate
> the padding in a conformant manner (e.g. deals with cases where an
> incorrect amount of padding is in the source stream, the 608 tuples
> violate the interleaving rules, etc).
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 8:31 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> >
> > 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 relate to cases such as the captions crossing
> > back/forth between SEI and dedicated caption tracks (e.g. MP4 with
> a
> > caption track, the subcc output, etc).
> >
> 
> Ok, based on this information I am going to make a bug report ticket
> for
> the particular type of mp4 files I am using because while some
> caption data
> is passed, it is garbled and the transcoding process is producing
> errors.
> I was not aware that some work had been done to try to solve the
> frame rate
> conversion issue already as the behaviour of ffmpeg implies that it
> doesn't
> try to compensate for those changes for the file types I am working
> with.
> There are also bugs in the subcc function that seem to be affecting
> display
> time and other metadata.
> 
> I assume that it would be more efficient and better to fix the
> existing 608
> only data path before trying to expand things to include 708?
> 
> Zach
 

Unfortunately, there's no bug which could be "fixed". 
For a proper solution, a CEA-608 ENcoder is required. 
And more - like already said.

sw

 
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> 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
possible to just redistribute the packets of the 608 stream in a manner
that does not involve loss or reordering of data?  Part of the problem is
that each of the encoders need to not reorder captions packets or properly
handle things when frame reordering happens during the encode.  The
behaviour of ffmpeg is to include captions tracks that contain corruption,
so I would say that there is a bug even if the solution requires a CEA-608
encoder because the functionality is presented in a broken manner.

On Fri, Feb 7, 2025 at 11:44 AM Soft Works <
softworkz-at-hotmail.com@ffmpeg.org> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 8:31 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > >
> > > 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 relate to cases such as the captions crossing
> > > back/forth between SEI and dedicated caption tracks (e.g. MP4 with
> > a
> > > caption track, the subcc output, etc).
> > >
> >
> > Ok, based on this information I am going to make a bug report ticket
> > for
> > the particular type of mp4 files I am using because while some
> > caption data
> > is passed, it is garbled and the transcoding process is producing
> > errors.
> > I was not aware that some work had been done to try to solve the
> > frame rate
> > conversion issue already as the behaviour of ffmpeg implies that it
> > doesn't
> > try to compensate for those changes for the file types I am working
> > with.
> > There are also bugs in the subcc function that seem to be affecting
> > display
> > time and other metadata.
> >
> > I assume that it would be more efficient and better to fix the
> > existing 608
> > only data path before trying to expand things to include 708?
> >
> > Zach
>
>
> Unfortunately, there's no bug which could be "fixed".
> For a proper solution, a CEA-608 ENcoder is required.
> And more - like already said.
>
> sw
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Fri, Feb 7, 2025 at 2:31 PM Devlist Archive <devlist@rlb.org> 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 cases though that don't properly handle
> > it, and those mainly relate to cases such as the captions crossing
> > back/forth between SEI and dedicated caption tracks (e.g. MP4 with a
> > caption track, the subcc output, etc).
> >
>
> Ok, based on this information I am going to make a bug report ticket for
> the particular type of mp4 files I am using because while some caption data
> is passed, it is garbled and the transcoding process is producing errors.
> I was not aware that some work had been done to try to solve the frame rate
> conversion issue already as the behaviour of ffmpeg implies that it doesn't
> try to compensate for those changes for the file types I am working with.
> There are also bugs in the subcc function that seem to be affecting display
> time and other metadata.
>
> I assume that it would be more efficient and better to fix the existing 608
> only data path before trying to expand things to include 708?
>
> Zach

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 with the exact same files.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> 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 with the exact same files.


Sorry, I updated it with some other examples, I am uploading the
original ones again now.

On Fri, Feb 7, 2025 at 11:52 AM Devin Heitmueller <
devin.heitmueller@ltnglobal.com> wrote:

> On Fri, Feb 7, 2025 at 2:31 PM Devlist Archive <devlist@rlb.org> 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 cases though that don't properly handle
> > > it, and those mainly relate to cases such as the captions crossing
> > > back/forth between SEI and dedicated caption tracks (e.g. MP4 with a
> > > caption track, the subcc output, etc).
> > >
> >
> > Ok, based on this information I am going to make a bug report ticket for
> > the particular type of mp4 files I am using because while some caption
> data
> > is passed, it is garbled and the transcoding process is producing errors.
> > I was not aware that some work had been done to try to solve the frame
> rate
> > conversion issue already as the behaviour of ffmpeg implies that it
> doesn't
> > try to compensate for those changes for the file types I am working with.
> > There are also bugs in the subcc function that seem to be affecting
> display
> > time and other metadata.
> >
> > I assume that it would be more efficient and better to fix the existing
> 608
> > only data path before trying to expand things to include 708?
> >
> > Zach
>
> 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 with the exact same files.
>
> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Fri, Feb 7, 2025 at 2:52 PM Devlist Archive <devlist@rlb.org> 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
> possible to just redistribute the packets of the 608 stream in a manner
> that does not involve loss or reordering of data?  Part of the problem is
> that each of the encoders need to not reorder captions packets or properly
> handle things when frame reordering happens during the encode.  The
> behaviour of ffmpeg is to include captions tracks that contain corruption,
> so I would say that there is a bug even if the solution requires a CEA-608
> encoder because the functionality is presented in a broken manner.

And encoder itself should be required.  The ccfifo/ccrepack stuff in
principle does what is needed, but it's implemented as a video filter,
embedded into various modules in the raw domain that work on AVFrames,
and it's in the decklink output.  We would need to have a BSF which
operates on subtitle AVPackets, and it's likely the video framerate
would have to be explicitly specified (unless we're able to determine
it in the MP4 muxer and automatically instantiate the BSF with the
correct parameters).

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devin Heitmueller]

On Fri, Feb 7, 2025 at 2:55 PM Devin Heitmueller
<devin.heitmueller@ltnglobal.com> 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.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Devlist Archive
> Sent: Friday, February 7, 2025 8:52 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> >
> > 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
> possible to just redistribute the packets of the 608 stream in a
> manner
> that does not involve loss or reordering of data?  

As far as I understand, this is about professional public 
television broadcast, which needs to meet the regulations
and work on any TV set out there.
So even when you fiddle something together that works on some
software players - you're still not done (and you would
have nothing achieved at all).

sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Tom Vaughan]

I know what an elementary video stream is. I founded and led development of x265, which produces elementary video streams. Elementary video streams can contain SEI messages.
It's common to refer to the integration of closed captions into an elementary video stream as multiplexing. For example, see https://doc.haivision.com/MakitoX4Enc/1.7/closed-captioning

It is common for people in the industry to refer to burned-in (or open) captions as subtitles. Those are the only type of captions that would require a video encoder. 

Closed captions are pure metadata, encapsulated in Network Access Layer Units (NALUs). They are embedded by being muxed into the elementary video stream. See https://www.closedcaptioncreator.com/blog/articles/how-to-embed-608-708-closed-captioning.html

Even though embedded captions may appear as a separate data track in a media container, they are embedded in the elementary video bitstream.

Tom

On 2/7/25, 10:55 AM, "ffmpeg-devel on behalf of Soft Works" <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org> on behalf of softworkz-at-hotmail.com@ffmpeg.org <mailto:softworkz-at-hotmail.com@ffmpeg.org>> wrote:

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org>> On Behalf Of Tom
> Vaughan
> Sent: Friday, February 7, 2025 7:36 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org <mailto:devel@ffmpeg.org>>
> Subject: Re: [FFmpeg-devel] Captions SCC
>
> Soft Works said... "the CC data needs to get into the video frames -
> so that it exists as input to the video encoder.
> For the same reason, it is also not possible to add CCs at the muxer
> level. It always requires video encoding because the data needs to
> get into the video stream itself, so there's no way to get data from
> an SCC file into a video stream currently."


Hi Tom,
> You're confusing subtitles with closed captions. 
No.

> Subtitles are text that is composited into the video.
No.
> CEA-708 closed captions are
> carried as metadata in SEI NAL units, muxed into the elementary video
> stream.
I wouldn't call this "muxing" but that's not worth a debate.
(you might want to spend a thought on why it's called "elementary stream")

I said "it is also not possible to add CCs at the muxer level".

By that I mean "muxing" in ffmpeg terminology which is unambiguous.
sw




> 
> On 2/6/25, 11:48 PM, "ffmpeg-devel on behalf of Soft Works" <ffmpeg-
> devel-bounces@ffmpeg.org <mailto:devel-bounces@ffmpeg.org> <mailto:ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org>> on
> behalf of softworkz-at-hotmail.com@ffmpeg.org <mailto:softworkz-at-hotmail.com@ffmpeg.org> <mailto:softworkz-at-
> hotmail.com@ffmpeg.org <mailto:hotmail.com@ffmpeg.org>>> wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org <mailto:ffmpeg-devel-bounces@ffmpeg.org> <mailto:ffmpeg-
> devel-bounces@ffmpeg.org <mailto:devel-bounces@ffmpeg.org>>> On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 6:13 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org <mailto:devel@ffmpeg.org> <mailto:devel@ffmpeg.org <mailto:devel@ffmpeg.org>>>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> 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 frames - so that it exists as input to the
> video encoder.
> For the same reason, it is also not possible to add CCs at the muxer
> level. It always requires video encoding because the data needs to
> get into the video stream itself, so there's no way to get data from
> an SCC file into a video stream currently.
> 
> The only way in the ffmpeg architecture to get CC data encoded would
> be at the filtering level. The Subtitle Filtering patchset that I
> have submitted a while ago has a "splitcc" filter which has video as
> input and a video plus a subtitle pin/pad at the output side.
> What would be needed is a reverse pendant like a "mergecc" filter
> with video and subtitles input - plus a CEA-608/708 encoder.
> 
> softworkz
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>


To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> with subject "unsubscribe".



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> 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 with the exact same files.


The legal requirements are to pass the captions received, not generate
captions at least for the small entities like us.  As such all the encoding
should be done by the content producer as long as the data isn't corrupted.


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 with the exact same files.


Here are some updated commands for the files that are there now and cleaned
up from the extra anothergui and windows path junk.  The commands are in
the text file also.  (one file still uploading)

Embed:
ffmpeg -i AIM-2301_premiereExport.mp4 -i AIM-2301_premiereExport.scc -map
0:v -map 0:a -map 1 -c:v copy -c:a copy -c:s mov_text -metadata:s:s:0
language=eng AIM-2301_ffmpegEmbed.mp4

Extract:
ffmpeg.exe -f lavfi -i "movie=AIM-2301.mp4"[out+subcc] -map 0:1 -c:s copy
AIM-2301_ffmpeg_extracted.scc

On Fri, Feb 7, 2025 at 11:57 AM Soft Works <
softworkz-at-hotmail.com@ffmpeg.org> wrote:

> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 8:52 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > >
> > > 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
> > possible to just redistribute the packets of the 608 stream in a
> > manner
> > that does not involve loss or reordering of data?
>
> As far as I understand, this is about professional public
> television broadcast, which needs to meet the regulations
> and work on any TV set out there.
> So even when you fiddle something together that works on some
> software players - you're still not done (and you would
> have nothing achieved at all).
>
> sw
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".