[FFmpeg-trac] #11462(undetermined:new): Cannot embed .scc file into .mp4 using -c:s copy

[FFmpeg]

#11462: Cannot embed .scc file into .mp4 using -c:s copy
-------------------------------------+-------------------------------------
             Reporter:  Zach         |                    Owner:  (none)
                 Type:  enhancement  |                   Status:  new
             Priority:  important    |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Zach):

 Replying to [comment:30 softworkz]:
 > Replying to [comment:29 softworkz]:
 > > This discussion made me wonder about whether it might be feasible to
 have decoders produce AVFrames where the side data is parsed out but the
 video data remains undecoded. This might also help for certain ffprobe
 scenarios (Marth64: you know what I'm up to.. :-)
 >
 > I realize this needs explanation:
 >
 > Currently ffmpeg already has a way for encoding CC data into video
 streams during encoding, and many encoders (even hardware video encoders
 like QSV) support this.
 > This works simply by attaching the CC data as side data in AVFrames.
 That's the mechanism which allows preservation of CC data when transcoding
 video for example, and that's also how it will work with subtitle
 filtering:
 >
 > There will (would/could) be a mergecc filter (a splitcc filter already
 exists) which encodes text subs as CC 608/708 and attaches it as side data
 to the video frames.
 >
 > If it would be possible to work with video frames which have non-decoded
 video data, then the filtering could also be used without re-encoding the
 video.
 >
 > (that's why I don't think it makes sense to separate discussion)

 If there is a possibility of making a solution like a mergecc filter a
 reality that would work with either compressed or uncompressed cases that
 would be the ideal.  I would want to make sure that it could handle an
 input of .mcc or .scc data without re-encoding (but doing proper padding
 insertion) in addition to the subtitle encoding mentioned.  This would
 allow handling content that comes from .srt sources or other subtitle
 formats to be handled also.

 What components would be required to realize a functional processing chain
 with a new mergecc filter supporting either compressed or uncompressed
 source streams?
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11462#comment:31>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker