[FFmpeg-devel] Internal handling of subtitles in ffmpeg

Michael Niedermayer michaelni
Fri Jan 2 16:20:48 CET 2009


On Fri, Jan 02, 2009 at 02:32:18PM +0100, Michael Niedermayer wrote:
> On Fri, Jan 02, 2009 at 09:18:10AM +0100, Reimar D?ffinger wrote:
> > On Fri, Jan 02, 2009 at 02:20:43AM +0100, Michael Niedermayer wrote:
> > > On Fri, Jan 02, 2009 at 12:08:00AM +0100, Reimar D?ffinger wrote:
> > > > On Thu, Jan 01, 2009 at 10:36:36PM +0100, Michael Niedermayer wrote:
[...]
> > 
> > I'd prefer those to be available directly without having 50 more fields
> > in the struct I have to read up on first to know if they are relevant
> > for me and 10 conversion functions I have to call at the right place.
> > 
> > > > Well, you know, I am trying to convince you to say: hell, let's do the
> > > > simple stuff simple and proper and leave the rest to a complicated
> > > > extension.
> > > 
> > > Iam still waiting for you to explain your simple & proper solution. It seems
> > > what you suggest has changed somewhat so iam not entirely sure if you still
> > > argue in favor of replacing decoder->encoder by bitstream filters or what
> > > the intermediate format is supposed to be, originally you suggested ASS but it
> > > seems you dont suggest this anymore?
> > 
> > I am arguing that "the one subtitle representation" should not exist.
> > Unfortunately that is not possible if conversion between all imaginable
> > formats should work.
> 
> > That is why I came up with the "one ASS string blob (possibly in AVSubtitle)"
> > because that at least hides it well (putting it in AVSubtitleRect does
> > not hide it well because that will affect the meaning of x,y - actually
> > already just allowing text in there will though).
> 
> There is a problem with putting a single ASS blob in AVSubtitle. And this is
> the main reason why iam advocating to put it in AVSubtitleRect.
> What if 2 such blobs start at the same time, they would end in the same packet
> and thus the decoder would receive 2 ASS blobs.

> If you volunteer to fix the issues caused by having multiple packets with
> equal timestamps, we surely can put it in AVSubtitle, if the result would
> qualify as simple of course is another question ...

To elaborate on this a little, what would need fixing are muxers for
containers that simply do not allow multiple packets with the same pts,
they would have to collect and merge packets. Similarly on the demuxer side
such packets would have to be split.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090102/77975ec7/attachment.pgp>



More information about the ffmpeg-devel mailing list