[FFmpeg-devel] State of existing infrastructure for subtitle transcoding

[Michael Niedermayer]

On Sat, Apr 28, 2012 at 04:03:01PM -0700, Philip Langdale wrote:
> Hi all,
> 
> I'm currently working on an encoder and decoder for tx3g subtitles
> (aka: MPEG4 Part 17 subtitles). The format is a bit of a departure
> from what we've seen before in that rather than being an embedded
> text document like SRT or ASS, it's defined strictly in terms of
> the containerized stream with the stream packet pts used to indicate
> display time, etc.
> 
> I was able to write a simple decoder (simple because it ignores all
> styling information) that works like srtenc, so that you can take
> an mp4 file with subtitles and, for example, transcode it to an
> mkv file with srt subtitles. So that's great.
> 
> But I'm having nothing but trouble on the encoder side.
> 
> 1) The srt decoder assumes that its input is from a raw text file.
> If you try and feed it a stream from a matroska file, it will fail
> because the timing information is stored in the packet fields and
> not as part of the srt text. I assume this applies for ASS to, so
> the upshot is we don't actually have decoders that will work for
> the kind of transcode scenario I'm aiming for. This one I can fix,
> so I'm not so concerned.
> 

> 2) I can't express subtitle duration in the expected way. From my
> reading of the spec, the packet pts value is the time to start
> showing the subtitle and you encode the end time as a separate
> empty packet with the pts set appropriately. I don't think there's
> a way to output two packets for one input packet. Am I missing
> something?

The same issue exists with dvbsub, I dont think transcoding bewteeen
the 2 packet and 1 packet+duration variants is supported yet.

But there where some discussions about this, you might want to search
the ML archives. maybe someone has a pointer handy ... i couldnt find
it quickyl


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120430/a192a543/attachment.asc>