On Mon, Aug 31, 2015 at 10:41 AM, Carl Eugen Hoyos <ceho...@ag.or.at> wrote: > Hendrik Leppkes <h.leppkes <at> gmail.com> writes: > >> Here is sample that seeks quite badly with the old >> demuxer, in playback it takes several seconds for the >> seek to catch up properly, > > (Seconds or milliseconds? I can reproduce the issue > with time but not visually...)
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. > >> because it seeks to an absolutely wrong position, >> while the new one ends up much much closer to the >> desired position, giving near instant seeking response >> >> http://files.1f0.de/samples/lav_wmv_slow_seek.wmv > > Seeking works faster for this sample with the new > demuxer. > > Thank you for the sample, Carl Eugen > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
