[FFmpeg-devel] [PATCH v6 0/4] Initial implementation of TTML encoding/muxing

[Jan Ekström]

On Thu, Mar 4, 2021 at 4:52 PM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Thu, Mar 4, 2021, 16:43 Moritz Barsnick <barsnick at gmx.net> wrote:
>>
>> On Thu, Mar 04, 2021 at 15:52:13 +0200, Jan Ekström wrote:
>> > I... just am not so sure in this case splitting the TTML writer and
>> > the TTML encoder from each other makes sense.
>>
>> I agree. In very many cases, muxer and encoder, or demuxer and decoder
>> are only useful together.
>>
>> Yet I have observed that commits to libavformat and libavcodec are
>> usually separated. Check the addition of many other such combinations.
>> (I think usually the codec comes first, because the muxer/demuxer uses
>> the codec definition.
>
>
> Yes, I have looked at things, and I after I go for a walk will specifically check previous subtitle additions. Meanwhile, please take a look at the alternatives that I've raised and please tell me of either of those makes a) sense b) it easier to revert things in case that is wanted.
>
> The codec definition is there already, as demuxing of ttml packets from mxf was already implemented. That - as I did note in my previous message would be why if you really wanted the muxer could be brought in first as well.

I have asked Anton for an opinion on this because my first reaction
might have been a bit "asdf unclear comments from someone after the
patch set has been in review for months and it's something that's been
part of the patch set from the beginning.", and thus might have
required a bit of re-calibration.

And it was a combo of:

1. ENOCARE (as in, either would be acceptable)
2. If I really wanted an opinion on this, split.

Thus I will split it, encoder first, then muxer. Since the muxer
utilizes a helper from the encoder's header and I'm too lazy at this
point to rewrite things into multiple bits. I do not find it required
in this case, but if it gets things forward...

Jan