> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Kieran Kunhya via ffmpeg-devel > Sent: Sunday, January 26, 2025 11:05 AM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Cc: Kieran Kunhya <kieran...@googlemail.com> > Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename > 0x0502 CC format > > On Sun, 26 Jan 2025, 00:31 Soft Works, <softworkz-at- > hotmail....@ffmpeg.org> > wrote: > > > > -----Original Message----- > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > > Marth64 > > > Sent: Sunday, January 26, 2025 1:14 AM > > > To: FFmpeg development discussions and patches <ffmpeg- > > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: > rename > > > 0x0502 CC format > > > > > > > they are broadcasting using a variation of DVB-S (there is no > US > > > standard for sat tv), so the current naming is actually valid. > > > > > > This is my understanding also, but I do believe there was 1 other > > > network that used the same variation. > > > Hence why I suggested a generic name. The counter argument from > > > Kieran > > > was that it's not a DVB standard either so DVB 0502 not a great > name. > > > > It's "user data", so there doesn't necessarily need to be a > standard. It's > > inconsistent anyway: > > > > SCTE-20 (5.7) defines a single byte: > > > > "user_data_type_code—An eight-bit code for picture user data, 0x03" > > > > while ATSC/A53-Part 4 (6.2.3) mandates a > > > > "user_data_identifier – This is a 32 bit code" > > > > Which is supposed to be registered with SMPTE: > > > > > > https://web.archive.org/web/20150324170029/http://www.smpte- > ra.org/mpegreg/mpegreg.html > > > > Then followed by 03 as type code. > > > > (this aligns with the implementation) > > > > > > I haven't found the corresponding in the DVB specs, it must have a > > different name there. > > > > DVB (TS 101 154) mandates a particular way of transporting captions > (that > the Dish method predates). There are other operators that do their > own > thing too.
Yea, you're right. This "particular way" actually copies the ATSC definition from A/53 Part 4 with a user data identifier of "GA94" followed by 0x03, calling it "North American-style closed captions" and has been added in V1.8.1 (2007). The timeline also explains the inconsistency of specs. IMO - It doesn't matter whether the stream is ATSC or DVB flavor because there is no directly related descriptor (which could be different depending on the stream flavor) to indicate the presence of CC data (of any type). The only (indirect) indication I'm aware of is via the "ATSC Caption Service" descriptor in the EPG tables, so it's not much relevant whether there's 'DVB' in the name. - I would call it CC_FORMAT_DISH (no strong opinion though) - The option should be named accordingly, like "dvb_0502", "pick DVB 0502 CC substream" => "dish", "pick Dish CC substream" Or is there any reason to not call it what it is (Dish)? There are Sega or Nintendo audio decoders and other examples and a cryptic description like "DVB 0502" renders it useless for almost everybody. 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-requ...@ffmpeg.org with subject "unsubscribe".
