Re: [FFmpeg-devel] Captions SCC

From: Soft Works <softworkz-at-hotmail.com@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Captions SCC
Date: Fri, 7 Feb 2025 23:46:38 +0000
Message-ID: <DM8P223MB0365C1E2F08ACA16C6215F62BAF12@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAAhd_PVYGPjMniTUXUAJ61dj4csQ9J8_eixu4CVLdmDEbLnFOw@mail.gmail.com>

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Marth64
> Sent: Friday, February 7, 2025 11:18 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Captions SCC
> 
> (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)

Hi Marth64,

from my understanding, streams in ffmpeg are receiving their type identity from the id of the codec (decoder in case of input streams) that is getting assigned to them - either by probing or manual setting. When I have an H.264 video stream but configure with "-c:v hevc", the stream becomes an HEVC stream (of course it won't get very far in decoding).
There is no separation between these two things. When doing the former, it's not an H.264 stream with an HEVC decoder - it's an HEVC stream _because_ it has an HEVC decoder assigned.

The only CC decoder we have is for CEA-608, so that's what it gets assigned by which it _becomes_ an CEA-608 stream.
I'm not 100% sure, but I believe there's also a paradigm not to add AV_CODEC_ID_xxxx entries as long as no encoder or decoder exists for it.

From what I've seen, for the Atmos detection (great addition btw, it was on my list as well!), you also didn't add an AV_CODEC_ID_ATMOS but used some FF_PROFILE enums instead.
It's actually a pretty similar case: there's data we can decode by standard means, but there's also some additional data that we can't decode.

At the bottom line, what's perhaps missing is a standardized way for representing streams with multiple layers. On the other hand it doesn't make much sense as long as we don't have codec ids for (still) unsupported media types. 

Does anybody know what the masterplan is for these types of things?

Thanks
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".