[FFmpeg-devel] [PATCH] movtextdec: MPEG4 Part 17 Timed Text Decoder.

Philip Langdale philipl at overt.org
Thu Jul 5 00:13:35 CEST 2012

On Thu, 5 Jul 2012 00:01:01 +0200
Clément Bœsch <ubitux at gmail.com> wrote:
> Doesn't apply on HEAD and your tree looks not up to date.

No, it's not, but I've updated it and the diff updates cleanly.

> > + * 3GPP TS 26.245/MPEG4 Part 17 Timed Text decoder
> All that naming looks quite inconsistent: you use "mov
> text" (sometimes "MPEG4 Timed Text"), but the specs are the MPEG-4
> ones, and are talking about "3GPP Timed Text" (and sometimes called
> "tx3g" right?) so wouldn't it make sense to actually call that
> decoder tx3gdec.c?
> AFAICT all of this is the same thing. Eventually you could add a @file
> doxy to briefly give the good references, but I don't want to block
> this patch.

Yeah, the thing is that its the same thing with a lot of different
names. I only use mov_text because the codec id already exists in the
codebase - I wouldn't have called it that if I had a choice.

* 3GPP TS 26.245 defines the stream content
* MPEG4 Part 17 defines how it gets muxed into mp4 containers
* TX3G is the FOURCC but doesn't reflect any official naming

I obviously can't use all those names in every spot, so I ended up
using MPEG4 Part 17 as the "short" form, just because this hasn't
been tested in any other context - so I don't want to claim it will
work for any other container.
> Don't bother with this, it's often a pain when rebasing or reviewing
> on a more recent HEAD. Just add a "FIXME: bump lavc" or something in
> the commit description, the commiter can fix that.

I have commit rights, so I intend to do it myself - hence adding
including the version bump.
> Thank you very much for this.
> Except the naming confusion, the patch LGTM. (I don't think it
> matters if the samples is still called MovText_*)

I named the sample MovText because of the CODEC_ID.

> Are you working on an encoder so we can mux subtitles in MOV/MP4?

Yes. I have an encoder in my github tree. I've been working on dealing
with the muxer complexities of needing to insert extra samples to define
duration. I have a patch for that which is not terrible, so I'll be able
to put a diff up soon.

There's also the on-going problems with not being able to demux srt from
matroska, which will prevent the most common re-mux scenario. I've
got proposed fixes for that in my tree.



More information about the ffmpeg-devel mailing list