Frame Drop with CoreAVC after seeking
 

Hi,
Using Bsplayer with CoreAVC 1.5, i have a very light-weight video 320x240 @ 30 fps, if i seek through timeline of Bsplayer, after seeking, when i look at Movie Info by pressing ALT+3, i sometimes see dropped frames in Movie Info of Bsplayer including "jitter" statistic.

Additionaly, i closed my Kaspersky anti-virus for the risk of being responsible of that problem, but it didn't help,

The video costs nearly %10-14 CPU which is contained in MP4 extension and decoded using CoreAVC 1.5, CoreAAC 1.2.0.575, Gabest 1.0.02 Splitter.

Is it a hardware or CoreAVC decoder problem?

Because i belive my system's specs are much capable to play that video(s) smoothly. (Old but must be capable, Pentium 4 2.4GHZ, 768MB DDR-RAM, GeForce4 MX440 64MB-DDR(with latest forceware driver 93.71) etc...)

If i don't seek on the same video during playback, the playback is smooth.

Thanks!

Seeking through the file it's a stressing process. It's normally that decoding can't be smooth and if you have the patience, you wil see that the errors and all othe things will loose the values if the file continue playing. Tested with an 720p MKV file.

For example, if you hit a hole with the car on the highway, at 140 KMph, the car will balance, but will go back to normal.

I agree, but still confusion, should i rely on my hardware or "Movie Info" reported by Bsplayer?

Seeking always has been a problem since first releases of Bsplayer, or is it a nature of media streams? Though i have much free resource, i beleive there shouldn't be any frame drops or jitter in any file format including CoreAVC (AVC/MPEG-4) or others after seeking, because decoding is smooth if you're leaving player and system alone during playback.

FF using arrows and <> gets my CPU at this levels

I have a Core2DUo @2 GHz an 2 GB DDR2@667. I believe that your CPU will be overwhelmed when doing that. It's possible that your hardware isn't realy such close to the needs oh HD.

LE: if you hit the hole even with a Hummer, you'll get some balance.

adicoto,
As i mentioned, the video(s) that cause frame drop or jitter after seeking is all about a tiny 320x240 @ 29.91 fps, not a HD one, and there are other files like that which are played very fine if i don't seek and leave playback alone(no other stuff on computer such as not exploring GUI-requiring apps.). And this file only costs about %8-10 CPU during playback.

Here is media info report if you interest in it as attachment.

BTW, i seek by clicking on a point on timeline and goes to a time and continues to playback directly, not using Fast Forward. (FF)

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.

Only you can test if it is a CoreAVC problem: by temporarily using another decoder with all other components the same.

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. :wink:

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)

MPEG-4 and WMV have much fewer keyframes than MPEG-1 or MPEG-2 and higher complexity, so seeking is harder. The Group of Pictures (interval between keyframes) in MPEG-2 is at most 18 frames, while in next-gen formats, including commercial Blu-rays, the interval is usually between 100 and 250 frames.

Nevertheless the system should be able to resync quickly after seeking. If it does not, then it's not operating properly. It takes 4-8 seconds to jump in Blu-ray streams on my computer, but still playback resumes normally.

I can seek allright with this combination:
- Haali Media Splitter, 2007-06-03
- ffdshow beta4
- AC3Filter v1.01a
- BSPlayer 1.36 (occasionally crashes if there are subtitles)

I've found that the later versions of AC3Filter perform poorly during seeking (sound goes on and repeats a small buffer until video catches up).

Seeking MPEG files are much more slower and harder than DivX or Xvid or MP4, even from harddrive instead of CD-ROM or DVD-ROM. (Seeking a MPEG file excessively stresses an optical drive, a VCD(MPEG1) or a DVD(MPEG2) or a single MPEG file) and i was said by someone that MPEG files have few keyframes which makes seeking longer and harder.

And Yes, if seeking was unstable for some reason resulting with frame drop or jitters, the video tries to re-sync to establish a smooth playback.

And sometimes, without pointing a specific format, if you directly seek a through video, the video can be out of sync just for a few seconds, then smooth playback is re-established if you wait with a little patience in Bsplayer. (I have version 1.41 build 832)

A kind of sudden acceleration of a car to catch another car in front of it.

So, is it a natural thing or unexpected? That's why i decided to ask to worry or not.

Thanks.

MPEG is refered as a compresion method (MPEG1, MPEG2, MPEG4). DvX, XviD, WMV, VP6...and the list can go on. The basics are the same, the ecuations are a little bit different. :wink:
Yes, it's normal, don't need to worry.