[FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples

[wm4]

On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Tue, 8 Mar 2016, Hendrik Leppkes wrote:
> 
> > On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint <cus at passwd.hu> wrote:  
> >>
> >> On Tue, 8 Mar 2016, wm4 wrote:
> >>  
> >>> On Tue,  8 Mar 2016 21:29:52 +0100
> >>> Marton Balint <cus at passwd.hu> wrote:
> >>>  
> >>>> Signed-off-by: Marton Balint <cus at passwd.hu>
> >>>> ---
> >>>>  libavformat/utils.c               | 10 ++++--
> >>>>  tests/ref/fate/gapless2-ipod-aac1 | 72
> >>>> +++++++++++++++++++--------------------
> >>>>  tests/ref/fate/gapless2-ipod-aac2 | 72
> >>>> +++++++++++++++++++--------------------
> >>>>  3 files changed, 80 insertions(+), 74 deletions(-)
> >>>>  
> >>  
> >>> I'm a probably bit late here, but what's the rationale of increasing the
> >>> start time?
> >>>  
> >>
> >> According to docs, start time is supposed to be the pts of the first
> >> decoded frame, therefore skipped samples must be taken into account, when
> >> the start time is determined based on the first packet pts.
> >>  
> >
> > But the skipping is performed by avcodec, not avformat, isn't it?  
> 
> Yes.
> 
> > start_time should be the PTS of the first avpacket coming out of
> > avformat, never mind what a decoder might do to that later.  
> 
> Not according to the docs:
> 
> "AVStream->start_time: decoding: pts of the first frame of the stream in 
> presentation order, in stream time base. Only set this if you are 
> absolutely 100% sure that the value you set it to really is the pts of 
> the first frame."
> 
> If here frame refers to a packet, why the docs is talking about 
> presentation order?
> 
> Also check the libavformat/mp3dec.c, it does the same kind of start_time 
> adjustment based on the skipped samples.

True, with mp3, the first PTS is always 0, and after skipping it will
be some positive value, and start_time is set to the skip duration. Is
this the same here?

Also, what the mp3 demuxer does is not necessarily correct. And
also, what works for audio-only formats isn't necessarily right for if
there are video tracks involved. What I'm really worried about is what
utils.c will determine as total stream start time?

From your added tests it looks like mov.c does now what I'd expect,
though. I just want to be sure this mess doesn't become worse.

Last but not least, why do we have about 3 mechanisms to signal
pre-skip? (Skip side data, skip_samples field, and delay field.)