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

[Clément Bœsch]

On Mon, Sep 22, 2014 at 09:13:18PM +0200, wm4 wrote:
> 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.

Supporting that properly is not that much work; there will just be a
somewhat nasty convert from this layout to the internal one (when that
last one will be sane).

Maybe that's rare indeed, but then someone will suddenly find a .nut, or
maybe try to pack these lines exactly the same way in another format.

So yeah, it's nasty, and I'm just unsure about what will be done. I'll
continue my work with that in mind. Until I'm done, I can't really say yet
if SSA will be kept or no. Also, I'll probably have to write that compat
layer anyway for the transition period.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140922/b6d16a73/attachment.asc>