PDA

View Full Version : Decoding problem: jump and wait...


LigH
28th January 2004, 21:02
Dear XviD developers,

I recently encoded a movie with the new RC1 and tried to play it using MPC 6.4.7.6, either with included or windows-internal AVI splitter, but always with the XviD DS filter. The problem: At specific positions, the video playback jumps (probably) one GOP forward and waits there until the timestamp is reached, then the playback continues.

I hope that you can reproduce this effect:

http://www.ligh.de/tmp/jump-n-wait.avi - ~3.4 MB

olnima
28th January 2004, 21:10
with xvid encoder and avi splitter in mpc DISabled no jump no wait everything's o.k.
same mpc like yours.

Greetz
Olnima

LigH
28th January 2004, 21:19
Sorry, don't understand: How do you disable the XviD encoder in MPC? I'd guess you used an other DS filter for decoding XviD than the XviD filter?

I just tried the same, and used ffdshow to decode this video: Yes, with ffdshow it ran fine.

Koepi
28th January 2004, 21:43
That file plays absolutely flawless here (tried latest mpc and wmp6.4). Sorry, I can't reproduce the problem. Do you have post processing enabled and it takes up too much time? Take a look at the task manager when you watch the sample please.

Also, what graphic card and driver are you using? Maybe cloning to tv output triggers this behaviour? (that disables the overlay for some programs in my setup here - maybe that could cause this as well.)

Only some suggestions where to search.

Regards
Koepi

PS: My setup (just for comparing possible bottlenecks)
- AthlonXP 2k+ (palomino)
- GF 4 MX 440 SE with 53.03 WHQ drivers
- 1GB PC-266 (o/c'ed CAS 2.0)
- SBLive! Value 1024 with beta kX drivers 3536
- sample played from light fragmented 5.400rpm operating system HDD, playing some music through cool player next to watching the sample %)

LigH
28th January 2004, 22:08
Indeed, the effect must be CPU load related: it goes up to 100%. The video only jumps ahead when I use all the 3 effect levels. ffdshow's PP was set to "automatic" and therefore obviously went a few steps backwards, forcing all PP levels and noising made the video get stuck as well.

Hardware: Duron 800, ELSA Gladiac GeForce2 GTS (ELSA-Detonator 4x), no TV-Out.

MPC output was set to VMR9-2D; I'll try hardware overlay, too...

Gaia
28th January 2004, 23:31
You get a lot better performance if you don't use VMR9. I had old Geforce2 card and VMR9 was very slow compared to overlay mixer.

Leak
29th January 2004, 01:36
Originally posted by LigH
Hardware: Duron 800, ELSA Gladiac GeForce2 GTS (ELSA-Detonator 4x), no TV-Out.

Well, sysKin (IIRC) said that full postprocessing really wants a 1GHz+ CPU, so I guess your video skipping in MPC with this CPU doesn't really come as a surprise... :)

np: Themselves - John Brown's Vaporizer (Them)

LigH
29th January 2004, 08:03
I just found out that "System default" is even able to "drop frames if behind", so the output may be choppy, but more stable overall.

I seldom used such "big" video dimensions, I usually kept "half native resolution" (e.g. 512x288 for 16:9).

Also I wonder if also some quality optimizing attributes may slow down the decoding process; I used A.Q., max. 3 B (closed, packed), Trellis, ColOpt. But I doubt that any of these options may affect the decoding remarkably...

Selur
30th January 2004, 10:52
at least adaptive quantizer should slowdown playback a bit
(trellis an colopt shouldn't)

Cu Selur

Erik_Osterholm
30th January 2004, 11:04
I've discovered the same problem. It only occurs when I use ffdshow (using the XVid codec, it works fine). CPU is an Athlon 2800 (Barton Core). Right now it's clocked at 1250mhz until my new fan arrives, as it was running a little hot, however the CPU isn't anywhere near saturated when I have the problem (around 22%). Memory (512 megs) usage is also fine.

With ffdshow, I turned off all processing and still the playback is choppy. When I go to the Info section of ffdshow's configuration applet, I see that Decoder FPS jumps from 0 to up to 66 frames per second and fluctuates quite a lot.

The problem only occurs in video encoded with RC1. I have XVid videos that I encoded before RC1 was released, and these play fine through ffdshow.

For grins, I tried using the XVid codec to decode this older video, and there were ... problems. Image streaking and general discoloration (from incorrect motion vectors? is that the correct term?)

And for completeness sake, I tried the original poster's clip, and had the same results as my own encode. Choppy playback when using ffdshow, smooth with XVid.

Koepi
30th January 2004, 11:19
Erik:

the problem you're describing most likely is caused by packed bitstream - ffdshow can't handle that with more than 1 consecutive bframe.

Koepi

Erik_Osterholm
30th January 2004, 11:28
Koepi:
Oh excellent! A little more searching on my part might have turned that up, but now things play flawlessly (when reencoded without packed bitstream).

So what does a packed bitstream change, anyway?

olnima
30th January 2004, 17:44
Originally posted by LigH
Sorry, don't understand: How do you disable the XviD encoder in MPC? I'd guess you used an other DS filter for decoding XviD than the XviD filter?

I just tried the same, and used ffdshow to decode this video: Yes, with ffdshow it ran fine.


Sorry, I mean DEcoder

Olnima

LigH
1st February 2004, 19:59
Just for your information: I did not yet see any problems with the ffdshow build 2004-01-13 decoding XviD with packed bitstream and up to 3 B frames; either it is quite rare, or indeed fixed...

:confused: :rolleyes:

My mirror: http://www.ligh.de/software/mirrors.phtml