[FFmpeg-devel] FFmpeg 2.8

[Carl Eugen Hoyos]

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...)

Carl Eugen