[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 Devin Heitmueller):

 Replying to [comment:27 Zach]:
 > This would at least be easier to handle a file library than dealing with
 sidecar files, but VLC does not detect that type of muxing in an mov file.
 Since I use VLC for testing file quality and don't really want to move to
 ffplay for that I don't think this solution is a viable option.

 Yeah so I suspect VLC is being tripped up by the lack of 608 NULL packets
 when there aren't captions present, as the SCC file stripped those out and
 there was nothing in the pipeline to re-insert them.  I suspect we would
 need to solve this problem even if inserting the captions into SEI.  My
 first instinct would be to have the SCC demuxer insert the padding, since
 it has the timestamps and would know exactly how much to generate.  But
 there might be a better approach using the cc_fifo (which would likely be
 reusable in other places in the codebase).

 > Why don't we separate the discussion of the uncompressed domain solution
 and the compressed domain.  This ticket should really just about a
 solution that can integrate a seperate captions stream from .scc, .mcc, or
 mxf 436m caption track to an A/53 Part 4 or SCTE-128 DTVCC encoded stream
 within the video elementary stream headed to an mp4 file.

 No objection.  Thanks for clarifying the use case is specifically SEI
 insertion for this ticket.

 > If the solution can also work for mpegts outputs that would be great,
 but mpegts outputs will require a higher degree of standards compliance
 due to multiple decoder targets.

 Any work done in this area will likely work for both MP4 and MPEG-TS.  Any
 interop with creating MPEG-TS files which work across multiple decoders
 would be separate issues.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11462#comment:28>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker