On Mon, 31 Aug 2015 09:04:46 +0000 (UTC) Carl Eugen Hoyos <ceho...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
