[FFmpeg-devel] [RFC] Implementation of closed caption support
gisle at snirklasjon.no
Mon Aug 4 21:35:02 CEST 2014
Den 04. aug. 2014 21:11, skrev Reimar Döffinger:
> On Mon, Aug 04, 2014 at 08:04:39PM +0100, Kieran Kunhya wrote:
>>> And as far as I can tell if you want to remux
>>> but with separate subtitle stream that would even mean that you have to
>>> re-encode the video for no good reason.
>> You can just swap out the caption data. It's guaranteed to be CBR anyway.
> Uh, no.
> The point is to get the CC data out you need to decode.
> Now that you have the video decoded, if you want to mux it you have
> to encode it again.
> Though maybe it's possible to somehow use the same input stream twice as
> input in FFmpeg and copy it once (for muxing) and decode it once (to get
> the CC data).
My current work in progress uses a bitstream filter and implements a
partial parser for h.264 and mpeg2 frames. This is not all that much
code, since most of the datastructures can be ignored. It also havce the
advantage that the closed caption stuff can be kept in a separate
module, and not mixed into the decoders. The decoder approch would also
not work for insertion of closed captions (for h.264 that would be x264,
and I can't see that CC has a place there really). I'm uncertain enough
that I would prefere to here the opinion here before submitting a patch.
As far as I can see it now:
- Modular, the CC code can be kept separate.
- Less complex code
Need for features that I can't see is present in the bitstream filters:
- As far as I can see -no support for timestamps (PTS), required for
reordering and timestams in the output file
- No support for arguments to bitstream filters (unlike audio and video
- Parser already present. Easy to insert extraction code on the right spots
- Less modular, CC code mixed with decoding code.
- Does not easily extend to encoders/insertion.
- Parameters (for input files)?
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel