Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
Hi Roger, On Mon, Jun 19, 2023 at 8:50 PM Roger Pack wrote: > > OK updated patches to work with latest git master, made coded id less verbose. > These have been tested against a "real device" and seem to work properly. > I'd like to get feedback on the Closed caption decoder first if that's > possible. > I pinged the decoder "maintainer" about it once and didn't get a > response so seems it's up to us. > > Thank you. > -=roger=- First off, to be clear, I'm generally supportive of your efforts to extend the DirectShow interface to support delivery of 608 captions. That said, I have some concerns about the specific approach you've taken, and in particular the notion of introducing a new codec type. It's been a while since I've looked at the BDA interface for the VBI slicer, but IIRC there are two CC output pins, and the first one delivers the sliced byte pairs for CC1/CC2 and the second pin delivers CC3/CC4. Your patch to the Directshow driver though only operates on the first pin, so any captions on CC3/CC4 would be lost. Further, your new codec provides no way to know whether the packets containing the byte pairs are for CC1/CC2 or CC3/CC4. We need to be able to distinguish between the two, since knowing which service is carrying the captions is important and some data types (e.g. XDS) are only delivered on certain services. The original AV_CODEC_ID_EIA_608 codec allows downstream components processing the packets to know which pair it is based on the prefix byte. My inclination is that adding a new codec type creates additional maintenance headaches, as various components needs to be modified to handle both codecs, and in fact the *only* difference between your codec and the existing one is the presence of the prefix byte (which is actually needed in order to tell which pair it is). So why not simply have the directshow component add the 0xFC byte to the front of the payload for CC1/CC2 and 0xFD for CC3/CC4? Doing this would allow everything else to stay the same and no additional codec would be required? It would also allow you to add support for CC3/CC4 after wiring it up to the other CC output pin on the BDA VBI slicer? In other words, it seems like a 1-line change to the dshow patch would eliminate the need for the first patch completely. On a side-note, it's probably worth noting that using a three-byte payload predates CEA-708. The prefix byte was present in earlier standards such as use in DVD GOPs, although the actual structure of the prefix byte differs in various standards. While the format for the ffmpeg codec does match what's found in CEA-708, that's mostly just for the sake of consistency. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Tue, Jun 20, 2023 at 2:50 AM Roger Pack wrote: > OK updated patches to work with latest git master, made coded id less > verbose. > These have been tested against a "real device" and seem to work properly. > I'd like to get feedback on the Closed caption decoder first if that's > possible. > I pinged the decoder "maintainer" about it once and didn't get a > response so seems it's up to us. > > Please remove '_dec_' part, its really not needed. Thank you. > -=roger=- > > On Thu, May 7, 2020 at 7:06 AM Paul B Mahol wrote: > > > > Is it just me, or the coded id is too much verbose? > > > > On 5/7/20, Anton Khirnov wrote: > > > Quoting Roger Pack (2020-04-28 08:15:19) > > >> From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001 > > >> From: rogerdpack > > >> Date: Tue, 28 Apr 2020 05:15:15 + > > >> Subject: [PATCH 1/3] closed caption decoder: accept and decode a new > codec > > >> type of 'raw 608 byte pairs' > > >> > > >> Signed-off-by: rogerdpack > > >> --- > > >> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h > > >> index e7d6e059db..805e18758b 100644 > > >> --- a/libavcodec/codec_id.h > > >> +++ b/libavcodec/codec_id.h > > >> @@ -513,6 +513,7 @@ enum AVCodecID { > > >> > > >> AV_CODEC_ID_MICRODVD = 0x17800, > > >> AV_CODEC_ID_EIA_608, > > >> +AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS, > > > > > > You can't just add new IDs in the middle of the table, it changes the > > > IDs of all the following codecs which breaks ABI. > > > Add it to the end of the subtitle block. > > > > > > -- > > > Anton Khirnov > > > ___ > > > 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". > > ___ > > 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". > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
OK updated patches to work with latest git master, made coded id less verbose. These have been tested against a "real device" and seem to work properly. I'd like to get feedback on the Closed caption decoder first if that's possible. I pinged the decoder "maintainer" about it once and didn't get a response so seems it's up to us. Thank you. -=roger=- On Thu, May 7, 2020 at 7:06 AM Paul B Mahol wrote: > > Is it just me, or the coded id is too much verbose? > > On 5/7/20, Anton Khirnov wrote: > > Quoting Roger Pack (2020-04-28 08:15:19) > >> From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001 > >> From: rogerdpack > >> Date: Tue, 28 Apr 2020 05:15:15 + > >> Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > >> type of 'raw 608 byte pairs' > >> > >> Signed-off-by: rogerdpack > >> --- > >> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h > >> index e7d6e059db..805e18758b 100644 > >> --- a/libavcodec/codec_id.h > >> +++ b/libavcodec/codec_id.h > >> @@ -513,6 +513,7 @@ enum AVCodecID { > >> > >> AV_CODEC_ID_MICRODVD = 0x17800, > >> AV_CODEC_ID_EIA_608, > >> +AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS, > > > > You can't just add new IDs in the middle of the table, it changes the > > IDs of all the following codecs which breaks ABI. > > Add it to the end of the subtitle block. > > > > -- > > Anton Khirnov > > ___ > > 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". > ___ > 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". 0001-Closed-caption-add-ability-to-read-EIA-608-byte-pair.patch Description: Binary data 0002-dshow-add-ability-to-capture-closed-caption-EIA-608-.patch Description: Binary data ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
Is it just me, or the coded id is too much verbose? On 5/7/20, Anton Khirnov wrote: > Quoting Roger Pack (2020-04-28 08:15:19) >> From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001 >> From: rogerdpack >> Date: Tue, 28 Apr 2020 05:15:15 + >> Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec >> type of 'raw 608 byte pairs' >> >> Signed-off-by: rogerdpack >> --- >> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h >> index e7d6e059db..805e18758b 100644 >> --- a/libavcodec/codec_id.h >> +++ b/libavcodec/codec_id.h >> @@ -513,6 +513,7 @@ enum AVCodecID { >> >> AV_CODEC_ID_MICRODVD = 0x17800, >> AV_CODEC_ID_EIA_608, >> +AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS, > > You can't just add new IDs in the middle of the table, it changes the > IDs of all the following codecs which breaks ABI. > Add it to the end of the subtitle block. > > -- > Anton Khirnov > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
Quoting Roger Pack (2020-04-28 08:15:19) > From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001 > From: rogerdpack > Date: Tue, 28 Apr 2020 05:15:15 + > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > type of 'raw 608 byte pairs' > > Signed-off-by: rogerdpack > --- > diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h > index e7d6e059db..805e18758b 100644 > --- a/libavcodec/codec_id.h > +++ b/libavcodec/codec_id.h > @@ -513,6 +513,7 @@ enum AVCodecID { > > AV_CODEC_ID_MICRODVD = 0x17800, > AV_CODEC_ID_EIA_608, > +AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS, You can't just add new IDs in the middle of the table, it changes the IDs of all the following codecs which breaks ABI. Add it to the end of the subtitle block. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
Bump... On Wed, Apr 29, 2020 at 11:23 PM Roger Pack wrote: > > > > c9153590e5f167e41910d867639eb887164e28d2 > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > > From: rogerdpack > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > > > type of 'raw 608 byte pairs' > > > > breaks fate > > > > TESTsub-cc-realtime > > --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200 > > +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200 > > OK I believe to have fixed that, see the latest attached. Plus a few > more aesthetic cleanups to boot. > > Thanks! ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Fri, May 1, 2020 at 12:22 AM Kieran Kunhya wrote: > > On Fri, 1 May 2020 at 04:59, Roger Pack wrote: > > > On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote: > > > > > > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote: > > > > > > > > > c9153590e5f167e41910d867639eb887164e28d2 > > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 > > 2001 > > > > > > From: rogerdpack > > > > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a > > new > > > > codec > > > > > > type of 'raw 608 byte pairs' > > > > > > > > > > How does this content exist? Are you defining your own file format with > > the > > > byte pairs? > > > > It's transmitted as "raw byte pairs" by analog TV broadcast in the US. > > https://en.wikipedia.org/wiki/EIA-608 has details. > > > > I believe it transmits one closed caption character (or control code) > > per frame (basically a single byte pair on "line 21") so it can do 30 > > closed caption chars/second. Anyway that's where it's originating > > from. Good question :) > > > > Yes, but these byte pairs are usually in a container or exist in an > analogue waveform. It's from analogue waveform, it gets pulled out by the analog TV decoder card into the byte pairs. The container is basically "which frame" the line 21 data happened to come in with. It comes in with two bytes/frame. It comes in with a timestamp given by (I presume) the timestamp of the frame it accompanies as a pin in directshow (in windows). Directshow with the tuner card presents the line 21 data as "VBI packets" (with a header specifying which portion of the VBI it comes from, line 21 "odd" or line 21 "even"), and a timestamp. There is another directshow filter that basically filters out the VBI data and passes on just the "raw byte pairs" for a given CC stream. See attached, but only concentrate on the "VBI Codec" filter box. It presents two "CC" pins, the first of which we accept the byte pairs from (with patch 3/3) [1] So it's an analog standard, which directshow handles this way, and it's converted to byte pairs. > Have you defined your own format of "raw byte pairs"? That doesn't exist in > the wild as far as I know. The "format" is normal EIA 608 https://en.wikipedia.org/wiki/EIA-608 The "characters" section. There was already a codec named "AV_CODEC_ID_EIA_608", but it was really EIA 608 encapsulated within an EIA 708 stream, so I went with a new name. The existing 608 decoder already decoded the "byte pairs" internally I just needed to be able to access it without the encapsulation for this particular input. In the analog stream they "come in" on the line 21 data as EIA byte pairs. No 708 encapsulation, hence me calling it "raw" (AV_CODEC_ID_EIA_608_RAW_BYTE_PAIRS). So it seems standard. Cheers. -roger- [1] If you care about the nitty gritty, here's the media types that the pins present: VBI pin: Media type: MEDIATYPE_VBI {F72A76E1-EB0A-11D0-ACE4-C0CC16BA} Subtype: KSDATAFORMAT_SUBTYPE_RAW8 {CA20D9A0-3E3E-11D1-9BF9-00C04FBBDEBF} Format type: {F72A76E0-EB0A-11D0-ACE4-C0CC16BA} CC pin: Media type: MEDIATYPE_AUXLine21Data {670AEA80-3A82-11D0-B79B-00AA003767A7} Subtype: MEDIASUBTYPE_Line21_BytePair {6E8D4A22-310C-11D0-B79A-00AA003767A7} Format type: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196} ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Fri, 1 May 2020 at 04:59, Roger Pack wrote: > On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote: > > > > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote: > > > > > > > c9153590e5f167e41910d867639eb887164e28d2 > > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 > 2001 > > > > > From: rogerdpack > > > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a > new > > > codec > > > > > type of 'raw 608 byte pairs' > > > > > > > How does this content exist? Are you defining your own file format with > the > > byte pairs? > > It's transmitted as "raw byte pairs" by analog TV broadcast in the US. > https://en.wikipedia.org/wiki/EIA-608 has details. > > I believe it transmits one closed caption character (or control code) > per frame (basically a single byte pair on "line 21") so it can do 30 > closed caption chars/second. Anyway that's where it's originating > from. Good question :) > Yes, but these byte pairs are usually in a container or exist in an analogue waveform. Have you defined your own format of "raw byte pairs"? That doesn't exist in the wild as far as I know. Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote: > > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote: > > > > > c9153590e5f167e41910d867639eb887164e28d2 > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > > > From: rogerdpack > > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new > > codec > > > > type of 'raw 608 byte pairs' > > > > How does this content exist? Are you defining your own file format with the > byte pairs? It's transmitted as "raw byte pairs" by analog TV broadcast in the US. https://en.wikipedia.org/wiki/EIA-608 has details. I believe it transmits one closed caption character (or control code) per frame (basically a single byte pair on "line 21") so it can do 30 closed caption chars/second. Anyway that's where it's originating from. Good question :) Thanks! ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote: > > > c9153590e5f167e41910d867639eb887164e28d2 > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > > From: rogerdpack > > > Date: Tue, 28 Apr 2020 05:15:15 + > > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new > codec > > > type of 'raw 608 byte pairs' > How does this content exist? Are you defining your own file format with the byte pairs? Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
> > c9153590e5f167e41910d867639eb887164e28d2 > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > > From: rogerdpack > > Date: Tue, 28 Apr 2020 05:15:15 + > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > > type of 'raw 608 byte pairs' > > breaks fate > > TESTsub-cc-realtime > --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200 > +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200 OK I believe to have fixed that, see the latest attached. Plus a few more aesthetic cleanups to boot. Thanks! From 5d7c12a3f703e794e1092087355bc9523d5f4d93 Mon Sep 17 00:00:00 2001 From: rogerdpack Date: Tue, 28 Apr 2020 05:15:15 + Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs' Signed-off-by: rogerdpack --- configure | 1 + libavcodec/Makefile | 2 +- libavcodec/allcodecs.c| 1 + libavcodec/ccaption_dec.c | 116 ++ libavcodec/codec_desc.c | 7 +++ libavcodec/codec_id.h | 1 + libavcodec/version.h | 4 +- 7 files changed, 92 insertions(+), 40 deletions(-) diff --git a/configure b/configure index 080d93a129..8a0a6cce7c 100755 --- a/configure +++ b/configure @@ -2681,6 +2681,7 @@ bink_decoder_select="blockdsp hpeldsp" binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs" binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs" cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp" +ccaption_raw_608_decoder_select="ccaption_decoder" clearvideo_decoder_select="idctdsp" cllc_decoder_select="bswapdsp" comfortnoise_encoder_select="lpc" diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 28076c2c83..006eb40107 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -246,6 +246,7 @@ OBJS-$(CONFIG_C93_DECODER) += c93.o OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \ cavsdata.o OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o ass.o +OBJS-$(CONFIG_CCAPTION_RAW_608_DECODER)+= ccaption_dec.o ass.o OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o OBJS-$(CONFIG_CDTOONS_DECODER) += cdtoons.o OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o @@ -463,7 +464,6 @@ OBJS-$(CONFIG_MP3ON4FLOAT_DECODER) += mpegaudiodec_float.o mpeg4audio.o OBJS-$(CONFIG_MPC7_DECODER)+= mpc7.o mpc.o OBJS-$(CONFIG_MPC8_DECODER)+= mpc8.o mpc.o OBJS-$(CONFIG_MPEGVIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o -OBJS-$(CONFIG_MPEG1VIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o OBJS-$(CONFIG_MPEG1VIDEO_ENCODER) += mpeg12enc.o mpeg12.o OBJS-$(CONFIG_MPEG1_CUVID_DECODER) += cuviddec.o OBJS-$(CONFIG_MPEG1_V4L2M2M_DECODER) += v4l2_m2m_dec.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index 54d40ebdbc..b78f58cb4c 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -645,6 +645,7 @@ extern AVCodec ff_ssa_decoder; extern AVCodec ff_ass_encoder; extern AVCodec ff_ass_decoder; extern AVCodec ff_ccaption_decoder; +extern AVCodec ff_ccaption_raw_608_decoder; extern AVCodec ff_dvbsub_encoder; extern AVCodec ff_dvbsub_decoder; extern AVCodec ff_dvdsub_encoder; diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c index bf3563a0bc..a2197cd673 100644 --- a/libavcodec/ccaption_dec.c +++ b/libavcodec/ccaption_dec.c @@ -341,43 +341,51 @@ static void write_char(CCaptionSubContext *ctx, struct Screen *screen, char ch) } /** - * This function after validating parity bit, also remove it from data pair. - * The first byte doesn't pass parity, we replace it with a solid blank - * and process the pair. - * If the second byte doesn't pass parity, it returns INVALIDDATA - * user can ignore the whole pair and pass the other pair. + * This function accepts a byte pair [EIA 608 first byte, EIA 608 second byte] + * checks both for parity and strips parity on success. + * If the first byte doesn't pass parity, replace it with a solid blank + * and process the pair anyway. + * Returns failure for parity failure or "no data" (padding bytes). + */ +static int validate_eia_608_byte_pair(uint8_t *cc_data_pair) { +if (!av_parity(cc_data_pair[1])) { +return AVERROR_INVALIDDATA; +} +if (!av_parity(cc_data_pair[0])) { +cc_data_pair[0]=0x7F; // solid blank +} +if ((cc_data_pair[0] & 0x7F) == 0 && (cc_data_pair[1] & 0x7F) == 0) { +return AVERROR_INVALIDDATA; // padding bytes +} +/* remove parity bit */ +cc_data_pair[0] &= 0x7F; +cc_data_pair[1] &= 0x7F; +return 0; +} + +/** + * This function accepts "cc_data_pair" = [708 header byte, EIA 608 first byte, EIA 608 second byte] + * This function after validating parity bits, also removes parity bits
Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
On Tue, Apr 28, 2020 at 12:15:19AM -0600, Roger Pack wrote: > I needed this in order to be able to parse raw analog TV closed > caption byte pairs (analog line 21 CC's). > configure |1 > libavcodec/Makefile |2 > libavcodec/allcodecs.c|1 > libavcodec/ccaption_dec.c | 117 > +++--- > libavcodec/codec_desc.c |7 ++ > libavcodec/codec_id.h |1 > libavcodec/version.h |4 - > 7 files changed, 93 insertions(+), 40 deletions(-) > c9153590e5f167e41910d867639eb887164e28d2 > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001 > From: rogerdpack > Date: Tue, 28 Apr 2020 05:15:15 + > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec > type of 'raw 608 byte pairs' breaks fate TESTsub-cc-realtime --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200 +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200 @@ -1,42 +0,0 @@ -[Script Info] -; Script generated by FFmpeg/Lavc -ScriptType: v4.00+ -PlayResX: 384 -PlayResY: 288 - -[V4+ Styles] -Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding -Style: Default,Monospace,16,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0 - -[Events] -Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text -Dialogue: 0,0:00:14.14,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}( -Dialogue: 0,0:00:15.47,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} in -Dialogue: 0,0:00:15.92,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inau -Dialogue: 0,0:00:16.36,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudi -Dialogue: 0,0:00:16.81,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudibl -Dialogue: 0,0:00:17.25,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible -Dialogue: 0,0:00:17.70,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible ra -Dialogue: 0,0:00:18.14,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radi -Dialogue: 0,0:00:18.59,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio -Dialogue: 0,0:00:19.03,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio ch -Dialogue: 0,0:00:19.48,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio chat -Dialogue: 0,0:00:19.92,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio chatte -Dialogue: 0,0:00:20.36,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio chatter -Dialogue: 0,0:00:21.70,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,44)}({\i1} inaudible radio chatter{\i0} ) -Dialogue: 0,0:00:42.61,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> -Dialogue: 0,0:00:43.05,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> S -Dialogue: 0,0:00:43.50,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Saf -Dialogue: 0,0:00:43.94,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safet -Dialogue: 0,0:00:44.39,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety -Dialogue: 0,0:00:44.83,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety re -Dialogue: 0,0:00:45.28,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety rema -Dialogue: 0,0:00:45.72,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remain -Dialogue: 0,0:00:46.17,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains -Dialogue: 0,0:00:46.61,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains ou -Dialogue: 0,0:00:47.06,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains our -Dialogue: 0,0:00:47.50,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains our nu -Dialogue: 0,0:00:47.95,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains our numb -Dialogue: 0,0:00:48.39,9:59:59.99,Default,,0,0,0,,{\an7}{\pos(38,28)}({\i1} inaudible radio chatter{\i0} )\N{\an7}{\pos(38,44)}>> Safety remains our number -Dialogue:
[FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'
I needed this in order to be able to parse raw analog TV closed caption byte pairs (analog line 21 CC's). 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch Description: Binary data ___ 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".