[MPlayer-dev-eng] ASS/SSA discussions

[Ivan Kalvachev]

On 9/24/08, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Sep 21, 2008 at 01:06:00AM +0300, Ivan Kalvachev wrote:
>>
[..]
> It seems you missed my past comments ...
> What ffmpeg is heading toward is
> * the demuxers return subtitle packets like any other packet

Here is THE huge problem.
What does mkv.ass demuxer should return as packet?

No really, this is how the discussion started.

Aurel idea is that the mkv demuxer should take the subtitle packet,
convert it into file.ass line. This is done so whatever the next stage
is, it should handle only the already existing file.ass format.

The previous situation was that the packet was returned in the way it
was stored.

Should I understand the above text as an indication that you are in favor of
reverting Aurel changes from the lavformat mkv demuxer?

> * the subtite decoder decodes these packets to a common subtitle structure
>   (AVSubtitle) containing utf-8 text, timestamps/durations, positions,
>   effects, bitmaps, font references, ...

Sounds reasonable.

> * A common subtitle renderer renders these so they can be displayed or
>   a subtitle encoder encodes them to a possibly diferent format again.

I prefer the term decoder ;)

> 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
> duration or timestamps but also the actual text (unless the format uses
> bitmaps). Also nothing in it is duplicated so there is no problem with
> any possibly ambiguities, as there cannot be any.
>
> You wouldnt want to apply video filters to packets prior to the video
> decoder, so why do you base your arguments on changing things prior to
> subtitle decoder?

(in ffmpeg style)
-acodec copy -vcodec copy -scodec copy -ss 10:0

I remember in the days of ogg bashing, that it's biggest downside was that
you cannot process streams in uniform way because each packet in the stream
is codec dependent.


>> 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.

I'm perfectly fine with the notion that demuxer shouldn't modify the payload.
But at the moment mkv demuxer violates that notion.