Re: [FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
Quoting Kieran Kunhya (2020-08-03 18:36:16) > On Mon, 3 Aug 2020 at 08:16, Anton Khirnov wrote: > > > Quoting Kieran Kunhya (2020-07-27 20:15:17) > > > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov 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=initial_padding_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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
On Mon, 3 Aug 2020 at 08:16, Anton Khirnov wrote: > Quoting Kieran Kunhya (2020-07-27 20:15:17) > > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov 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=initial_padding_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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
Quoting Kieran Kunhya (2020-07-27 20:15:17) > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov 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=initial_padding_q=initial_padding Sounds a lot like "find them yourself". Presumably you already did that, so might as well list at least an example. > > 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
On Mon, 27 Jul 2020 at 11:09, Anton Khirnov 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=initial_padding_q=initial_padding > 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. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
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? 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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Inconsistent handling of initial_padding and PTS adjustment
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? Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
