Quote:
|
Originally Posted by adicoto Quote: |
Originally Posted by kimiraikkonen Indeed, yes a sudden action on playback such as seeking(an hitting a hole in your sample) may cause temporary instability, but is it acceptable?
Thanks. | For me it's acceptable. Things work like this.
Let's see a little how the video compresion works. At a basic level. MPEG compression uses a frame as a base. It calculates the next frame only by the difference from the last played frame. And so on...until the difference hits a level. Then, a new frame (a key frame) it's memorated and it's used to calculate the next ones. When you skip to a position into the file or FF into it, there are some calculations to be done. Seeking the nearest keyframe before the point where the file was FF and after that, decoding frames, one by one, until the exact point you decided the movie to be skipped. Those things require CPU and the playback of the file it's accelerated to get to that point.
Remember, you can't jump from a keyframe to the next 167th frame without decoding the other 166 before. Hope this help understanding.
And yes, you can uninstall COreAVC and install FFDshow, as J7N suggested and see if there is a difference.  |
Thanks for the explanation, but is the explanation that you mentioned only applied for MPEGs or others like MP4, WMV, MPEG-4 etc?
Plus, CoreAVC even is not stable when you seek(video freezes, sound goes on till you re-play video) which is mentioned many times before though having more updated version (1.5.0).
Note: I use Bsplayer's Internal Renderer Overlay(default)