[FFmpeg-devel] FFmpeg 2.8
nfxjfg at googlemail.com
Mon Aug 31 11:14:42 CEST 2015
On Mon, 31 Aug 2015 09:04:46 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Hendrik Leppkes <h.leppkes <at> gmail.com> writes:
> > Seconds. The way seeking works in my app is that when
> > user wants to seek to positon X, then the reference
> > clock is set to X, and if the demuxer seeks to a
> > wrong position, then it either has to read and decode
> > a lot of frames until X is reached (which on a modern
> > PC usually doesn't take *that* long), or even worse,
> > if it seeks to a point after the requested position,
> > it has to wait until the reference clock has advanced
> > in real-time to the position which it demuxes from -
> > which then can literally take seconds, and annoys
> > users to no end.
> So if I understand correctly, the issue is that the
> old demuxer sometimes (often / always) seeks to a
> position later than the requested position and the
> difference is bigger than with the optional
> demuxer that also seeks to a later position but
> less later?
> Was this the reason for implementing the new demuxer?
> Are you really sure that fixing the new demuxer isn't
> a magnitude more work than fixing the seeking issue
> in the old one?
> (Did you actually ever report this issue? I wasn't
> aware of it and I even wasn't aware of your usecase...)
It's been said multiple times: the old code is terrible, while the new
demuxer's code is actually maintainable.
But we all know you hate the new demuxer because Libav wrote it.
More information about the ffmpeg-devel