[MPlayer-dev-eng] ASS/SSA discussions

[Michael Niedermayer]

On Wed, Sep 24, 2008 at 02:03:38AM +0300, Uoti Urpala wrote:
> On Tue, 2008-09-23 at 23:16 +0200, Michael Niedermayer wrote:
> > On Sun, Sep 21, 2008 at 01:06:00AM +0300, Ivan Kalvachev wrote:
> 
> > besides#2, the ass demuxer in libavcodec will not parse, nor set the
> > display_duration. Its the ass AVParser that might, it would be nasty
> > code duplication if demuxers would do it ...
> 
> Do you intend to actually implement a .ass demuxer?

As you ask so nicely, Ill see what i can do. Iam starting to think that
it might take less time to just implement everything related to ASS than
continue this discussion.


> 
> Would the demuxer set _anything_ at all in the packets then?
> display_duration is at the same level as start time information. Would
> you omit both or for some reason parse one but not the other?

I can just repeat that there will be no random code duplication in ffmpeg,
and having avi, nut, asf, ... parse the duration would be code duplication.
Not to mention that i will try to minimize codec specific code in demuxers.


> 
> > It seems you missed my past comments ...
> > What ffmpeg is heading toward is
> > * the demuxers return subtitle packets like any other packet 
> > * the subtite decoder decodes these packets to a common subtitle structure
> >   (AVSubtitle) containing utf-8 text, timestamps/durations, positions,
> >   effects, bitmaps, font references, ...
> > * A common subtitle renderer renders these so they can be displayed or
> >   a subtitle encoder encodes them to a possibly diferent format again.
> 
> What do you mean by "heading toward"? Is someone going to actually
> implement this? Who? I've seen no indication of such work being done.

It will be implemented as subtitle decoders are implemented. You surely
can see that the existing decoders alraedy use AVSubtitle and AVSubtitle
is a vector based container not a sigle bitmap.


> 
> > Now this is not so much different from video and audio
> > the decoder converts a codec specific bitstream into a common and simple
> > representation (a bitmap or a bunch of PCM samples).
> > 
> > Within this framework, subtitles are trivially editable, not only the
> 
> They won't be trivially editable at least if you want to store the
> result in an existing format.
> 
> There is no "simple representation" for all SSA/ASS effects other than
> naming the specific effect. Audio codecs can be decoded to PCM in some
> sample format and most video codecs can be decoded to bitmaps, but
> subtitles are more like vector graphics. There is no simple format that
> could accurately represent every input.

Iam not interrested in what you would prefer cannot be done or did not exist.


[...]
> > > Summary:
> > > Demuxer must remove fields that it have parsed and stored in AVPacket structure.
> > 
> > see above
> > 
> > 
> > > Anything else would lead to increasing of code duplication and special handling.
> > 
> > This is certainly not true, as it is not done currently by any (de)muxer 
> > and doing it would add very significant and complex code to every
> > demuxer. And yes iam speaking about the general case here, not just ass, if you
> > mean just ass, then i honestly do not understand why it should be a special
> > case.
> 
> The reasons why SSA/ASS subtitles are different from a standard video
> codec have already been explained in the thread (a couple of times). But
> I'll try once again:

Ill not try to repeat the same awnser again though, you can look it up in the
thread.


> 
> Some video codecs have their own timestamps. But those are NOT used for
> timing when muxed in a normal container.

Are you the maintainer of mplayers av sync code? If so i would have
suspected that you know how mpeg2 in mpeg-ps works. But this comment
makes it clear that you do not.
The durations in the mpeg2 stream are certainly used when muxed in mpeg-ps.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- Måns Rullgård
-------------- 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/mplayer-dev-eng/attachments/20080926/6cd495b2/attachment.pgp>