[FFmpeg-devel] [RFC PATCH] avformat/utils: always seek back after avformat_find_stream_info()

[Aman Gupta]

On Wed, Apr 10, 2019 at 1:00 AM Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> On Wed, Apr 10, 2019 at 9:55 AM Aman Gupta <ffmpeg at tmm1.net> wrote:
> >
> > On Tue, Apr 9, 2019 at 9:49 PM Hendrik Leppkes <h.leppkes at gmail.com>
> wrote:
> >
> > > On Wed, Apr 10, 2019 at 2:21 AM Aman Gupta <ffmpeg at tmm1.net> wrote:
> > > >
> > > > From: Aman Gupta <aman at tmm1.net>
> > > >
> > > > Previously, the initial seek position was recorded into
> > > > old_offset at the beginning of avformat_find_stream_info(),
> > > > and passed into estimate_timings(). In the case of mpegts
> > > > with a known filesize, it was further passed into
> > > > estimate_timings_from_pts() which called avio_seek(SEEK_SET)
> > > > after doing its timing related seeks. (Interestingly, this
> > > > seeked all the way back to the initial position before
> > > > the probe, rather than only back before the timing
> > > > related seeks to the end of the file).
> > > >
> > > > With this commit, we pull the avio_seek() out of the mpegts
> > > > specific code-path and unconditionally seek all streams back
> > > > to their original position after probing is complete.
> > > >
> > > > This effectively prevents data that is consumed during
> > > > avformat_find_stream_info() from being discarded, so packets
> > > > contained at the beginning of a file are still passed back
> > > > to the user for playback.
> > > >
> > >
> > > I don't think I ever had a case where data was apparently lost from
> > > the beginning of the stream. Can you give examples of what this fixes?
> >
> >
> > Perhaps I'm missing something.
> >
> > If I see the debug log message "After avformat_find_stream_info() pos:
> > 1000000 bytes  seeks:0", are the packets from the first megabyte of the
> > file still returned from API? Maybe they are being cached somewhere and I
> > did not notice.
> >
>
> As far as I know, the packets read during stream info probing are
> being cached in a buffer and returned to the caller on av_read_frame.


Okay that seems to be the missing piece. If someone can point me to where
this buffer is in the code, that would be helpful.

In that case, it makes sense the only seek happens in the mpegts
estimate_by_pts case since that seeks all the way to the end. I'm still not
sure why it seeks back to the beginning (before probe start) position
though, and why that wouldn't cause packets to get doubled up.

Aman


>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".