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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
