From: Michael R. <mr...@us...> - 2005-10-03 13:23:44
|
Hi, > 1. i don't think it does that, as i understand it, the problem is > that there are keyframes and data in between, it doesn't "render" > every frame, it just has to pass all that data to get any sort of > acurate image, This is exactly right. With modern codecs, it is not possible to skip decoding of an arbitrary frame. > 1c. it may be a good idea to let libxine detect keyframe positions > and if you have to pass more than a few keyframes at that speed, it > may be preferable to just display only the keyframes, even if it > may not be so accurate... at very high speeds, this might give a > good speedup, (especially if it could skip lotsa data and not read > everything...) This is called "trickmode" (at least for MPEG-2) and it allows fast forward and even rewind at higher speeds, but it's not implemented yet and there are currently no plans to do that in the near future. But the technique is there and we know the problem. > 1d. is seeking actually optimized to seek until the keyframe, and > from there on the next data? Currently, it starts playback at the first keyframe before the given position. > 2. there's 2 types of seeking: seeking based on (i forgot how it's > called; but it's something like frames) It's percentage seeking (i.e. seek to 50% of the stream, meaning 50% of the bytes in the raw data). > and timeseeking. (I believe the time seeking is/was broken) The ability to time-seek accurately largely depends on the demuxer's capabilities and the cooperation with the input plugin. > 3. isn't there a mute param somewhere? Yes, the standard way frontends use to mute audio during playback should do. > 4. there's also something as post plugins, (the stretch post plugin > comes to mind...) But as with the fast forward by seek-jumps, this is not designed to do fast forward either. There is currently no Right Way (TM) to do fast forward. Sorry. Michael |