[FFmpeg-devel] [RFC PATCH] avformat/utils: always seek back after avformat_find_stream_info()
ffmpeg at tmm1.net
Wed Apr 10 10:30:27 EEST 2019
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.
This patch was based mostly on a reading of the code. I will run some more
detailed tests and provide an example/test of the new expected behavior.
> - Hendrik
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel