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

[Anton Khirnov]

Quoting Kieran Kunhya (2020-08-03 18:36:16)
> 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.

Both of those use AudioFrameQueue that does pts adjustment. Just did a
test encode with libmp3lame, the first packet's timestamp is negative.

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

That depends on the semantics of the container. E.g. in matroska you are
AFAIU supposed to store the "unadjusted" timestamp (i.e. not taking into
account encoder padding). So if the encoder did adjust the timestamp,
the muxer must adjust it back.
Except the relevant code in our matroska muxer is commented out for no
clear reason.

-- 
Anton Khirnov