[FFmpeg-devel] [PATCH] avformat: remove FF_API_ASS_SSA dead code

[wm4]

On Mon, 22 Sep 2014 21:05:19 +0200
Clément Bœsch <u at pkh.me> wrote:

> On Mon, Sep 22, 2014 at 06:55:54PM +0000, Rainer Hochecker wrote:
> > Clément Bœsch <u <at> pkh.me> writes:
> > 
> > > 
> > > On Mon, Sep 22, 2014 at 03:12:02PM +0000, Rainer Hochecker wrote:
> > > [...]
> > > > Hi,
> > > > 
> > > > Thank you very much for this explanation and sorry for not having read
> > > > release notes properly. subs are not my territory but the maintainer is busy
> > > > with real life so I will try to adapt to those changes.
> > > > 
> > > 
> > > Feel free to ask more direct questions.
> > > 
> > > Basically, the idea is that the matroska demuxer will now output
> > > AVPacket.data that looks like this:
> > > 
> > >     1,,Wolf main,Cher,0000,0000,0000,,Et les enregistrements de ses ondes
> > delta ?
> > > 
> > > instead of:
> > > 
> > >     Dialogue: Marked=0,0:02:42.42,0:02:44.15,Wolf
> > main,autre,0000,0000,0000,,Toujours rien.
> > > 
> > > (to take the matroska specs example)
> > > 
> > > The later had several problems, like including timestamp in a string which
> > > couldn't be altered without insane hacks at format level. It also dropped
> > > the ReadOrder fields which is needed to get proper rendering.
> > > 
> > > [...]
> > > 
> > > Note that we still use the "Dialogue: ..." form for internal decoded form
> > > of the subtitles (what you get into AVSubtitle when calling the decode
> > > subtitles function on the AVPacket), but I'm working on fixing this. I'll
> > > try to document that change even more, and compatibility will last for a
> > > long time again.
> > > 
> > 
> > I only needed to add AV_CODEC_ID_ASS to our handler which already took
> > AV_CODEC_ID_SSA.
> > According to the discussion here:
> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-May/157170.html, is it
> > correct to drop AV_CODEC_ID_SSA?
> > 
> 
> Actually, today someone gave me a AVI file with "ssa" chunks in it
> (basically with the timestamps duplicated into the payload as a normal
> string). I'm unsure yet how we're going to deal with this. It shouldn't
> matter for now whether you drop or keep it, but it might make sense in the
> future.
> 

It never worked before, so we don't really need to care about it. On
the other hand, it was like 2 lines of code to make it work. But
considering that SSA in AVI is so extremely rare, it would be bad if we
would require the user to handle yet another obscure special-case
(old-style SSA codec ID and packets), that it would be better to
rewrite the packet format on the fly... _if_ we want to support
demuxing this.