[FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment

[Kieran Kunhya]

On Mon, 3 Aug 2020 at 08:16, Anton Khirnov <anton at khirnov.net> wrote:

> Quoting Kieran Kunhya (2020-07-27 20:15:17)
> > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov <anton at khirnov.net> wrote:
> >
> > > Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > > > Hi,
> > > >
> > > > I notice that some encoders adjust the PTS with initial_padding and
> some
> > > > don't.
> > > > Is this intentional and should we decide that all encoders should do
> > > this?
> > >
> > > Which ones don't?
> > >
> >
> > A few here:
> >
> https://github.com/FFmpeg/FFmpeg/search?p=1&q=initial_padding&unscoped_q=initial_padding
>
> Sounds a lot like "find them yourself". Presumably you already did that,
> so might as well list at least an example.
>

There's nothing to find. It's easy to see from that page which ones do a
pts subtraction and which ones don't.
For example libmp3lame.c and libopusenc.c do not.


> > > I don't think this is a matter of opinion really - if encoder adds
> > > padding and doesn't adjust the timestamps then the output timestamps
> are
> > > just plain wrong.
> > >
> >
> > Well some containers have a flag for it. Right now if you encoded with
> > libopus into mkv or ts you get the PTS offset as well as the syntax
> element
> > written to the bitstream.
>
> Then I'd say if a container has a special field for padding then it
> should also adjust timestamps.
>

This makes no sense. Either the container writes the special padding field
and doesn't adjust timestamps.
Or it assumes the timestamps are already adjusted and writes a zero padding
field.
Writing both is clearly wrong.

Kieran