[FFmpeg-devel] FFmpeg 2.8

[wm4]

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.