mbox series

[FFmpeg-devel,0/5] Properly handle CEA-708 caption data when transcoding

Message ID 20230327164704.12962-1-dheitmueller@ltnglobal.com
Headers show
Series Properly handle CEA-708 caption data when transcoding | expand

Message

Devin Heitmueller March 27, 2023, 4:46 p.m. UTC 
This patch series is intended to address long-standing known issues where
CEA-708 caption data is either duplicated or corrupted (i.e. 50% of the data
is lost).  We employ an intermediate queue, which is available to filters that
change the frame rate of the video, which stashes the 608/708 data and
reconstructs properly formed 708 tuples on the output side (injecting
appropriate padding as needed).

The common functions are implemented in libavutil, but I am open to
suggestions.  While all the users in this patch series are within
libavfilter, there are use cases where this functionality would
be useful within libavformat (which is why libavutil was chosen).

This version of the patch series, compared to the RFC, has a couple
of fixes to catch missed code paths for yadif and tinterlace.

Comments/feedback are welcomed.

Thanks,

Devin

Devin Heitmueller (5):
  ccfifo: Properly handle CEA-708 captions through framerate conversion
  vf_fps: properly preserve CEA-708 captions
  yadif: Properly preserve CEA-708 closed captions
  tinterlace: Properly preserve CEA-708 closed captions
  vf_ccrepack: Add new filter to repack CEA-708 side data

 doc/filters.texi            |  10 ++
 libavfilter/Makefile        |   1 +
 libavfilter/allfilters.c    |   1 +
 libavfilter/tinterlace.h    |   2 +
 libavfilter/vf_bwdif.c      |   7 ++
 libavfilter/vf_ccrepack.c   |  95 ++++++++++++++++++
 libavfilter/vf_fps.c        |   9 +-
 libavfilter/vf_tinterlace.c |   8 ++
 libavfilter/vf_yadif.c      |   6 ++
 libavfilter/vf_yadif_cuda.c |   8 ++
 libavfilter/yadif.h         |   2 +
 libavfilter/yadif_common.c  |   5 +
 libavutil/Makefile          |   2 +
 libavutil/ccfifo.c          | 191 ++++++++++++++++++++++++++++++++++++
 libavutil/ccfifo.h          |  85 ++++++++++++++++
 15 files changed, 431 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_ccrepack.c
 create mode 100644 libavutil/ccfifo.c
 create mode 100644 libavutil/ccfifo.h

Comments

Andreas Rheinhardt March 30, 2023, 12:46 a.m. UTC | #1 
Devin Heitmueller:
> This patch series is intended to address long-standing known issues where
> CEA-708 caption data is either duplicated or corrupted (i.e. 50% of the data
> is lost).  We employ an intermediate queue, which is available to filters that
> change the frame rate of the video, which stashes the 608/708 data and
> reconstructs properly formed 708 tuples on the output side (injecting
> appropriate padding as needed).
> 
> The common functions are implemented in libavutil, but I am open to
> suggestions.  While all the users in this patch series are within
> libavfilter, there are use cases where this functionality would
> be useful within libavformat (which is why libavutil was chosen).
> 

If it is not used now outside of lavfi, it should be in lavfi to allow
to change it when it turns out that changes are needed.

- Andreas
Devin Heitmueller March 30, 2023, 1:14 p.m. UTC | #2 
On Wed, Mar 29, 2023 at 8:46 PM Andreas Rheinhardt
<andreas.rheinhardt@outlook.com> wrote:
>
> Devin Heitmueller:
> > This patch series is intended to address long-standing known issues where
> > CEA-708 caption data is either duplicated or corrupted (i.e. 50% of the data
> > is lost).  We employ an intermediate queue, which is available to filters that
> > change the frame rate of the video, which stashes the 608/708 data and
> > reconstructs properly formed 708 tuples on the output side (injecting
> > appropriate padding as needed).
> >
> > The common functions are implemented in libavutil, but I am open to
> > suggestions.  While all the users in this patch series are within
> > libavfilter, there are use cases where this functionality would
> > be useful within libavformat (which is why libavutil was chosen).
> >
>
> If it is not used now outside of lavfi, it should be in lavfi to allow
> to change it when it turns out that changes are needed.

So I was thinking along the same lines.  This would allow the API to
mature and change as needed without worrying about ABI breakage, which
would be useful since the API is relatively new and might need
tweaking.

Thanks for the suggestion.  I'll move it into libavfilter in the next
patches I submit (pending any other feedback/comments).

Devin