Choppiness followed by temporary stop...

[Metamorphous]

Having downloaded XviD-1.0-RC1-25012004 (Niltze) I decided to encode 'The Man Who Wasn't There' which is basically a black and white film.

Having set up some zone these were my settings:

Advanced Options
----------------
Motion Search: 6
VHQ: 4
Use chrome motion: Yes.
Maximum I-Frame interval: 500
Quantizations (all defaults)

Profile
-----------------
Profile @ Level: (unrestricted)
Quantization type: MPEG
Quarter Pixel: Yes
B-VOP (all on defaults eg:)
Packed Bitstream: Yes
Closed GOV: Yes


Now the problem I am having is with playback... its very choppy and even stops for like a second perhaps two during different parts of the movie. I have tried various things/ what ever came to my attention on the forum including sysKin updates (last being xvid.ax4.zip ?). Anyway I am using a variety of tools to play this back (BSPlayer, WMP6.4, etc. - no ffdshow or conflicting codecs) nothing seems to make a difference though when I turn off XVID decoder features play back speed is closer to what it should be - otherwise quite slow. Am I doing something wrong ? or can my machine simply not handle it ?
My spec is : Pentium 3 866 / 512 Ram.

I have provided a clip of this movie as well which can be downloaded from:

http://www.philexcables.com/pData/TMWWT_sample.avi

That clip doesn’t show the choppiness in most scenes [ unless if you look for it] however for myself it does demonstrate the pause/ temporary stop which happens at around 1:07 when the actor in white overall turns is back.

Someone please help help help :(
I dont want to have to re-encode this.
Many thanks in advance.

[Leak]

Originally posted by Metamorphous
Now the problem I am having is with playback... its very choppy and even stops for like a second perhaps two during different parts of the movie.

I'd guess that your CPU can't keep up decoding and after getting choppy/grinding to a halt has to wait for an I-frame to restart decoding.

Have a look at the task manager while your video is decoding - does the CPU usage hit 100% at those spots?

(If that's the case, of course turning down the postprocessing helps, since it's quite a CPU hog by itself...)

np: Ricardo Villalobos -Theogenes (Alcachofa)

[mikeX]

Leak is probably right.

My AMD Athlon XP (underclocked @ 1150 MHz with 256 266MHz DDR) isn't enough to decode a 768x432 xvid movie (it presented me with basically the same problems you mentioned) when using YUV deblocking.

I have to say (again) that the xvid decoder (after beta 3, at least that's when i noticed it) is very cpu hungry.

A (hopefully temporary) solution is using ffdshow, i tried it's postprocessing on the same video and it didn't give me any problems (build 05.23.2003) (cpu ~80-90% vs 100% with stuttering), although i see from your setup (packed bitstream) that you'll have other problems with it :( )

-- edit

AFAIK Q-Pel makes decoding more cpu-intensive as well

[Danzel]

Yes, QPel does increase decoding processor usage quite a lot.

And the Deblocking features in the newer xvid decoder have been designed for quality not speed, so they are quite cpu hungry too.

IIRC Chroma Motion can cause some weird effects in B/W Movies too, so you may want to try disable that.

Danzel.

[Didée]

( @ syskin, probably )

XviD decoder currently indeed is using quite some CPU cycles when decoding. It's not only the deblocking features - even the plain decoding is not exactly ultra-fast. (Now imagine that de-ringing gets re-implemented, too - - deringing needs even more computing power.)
That's okay with me, as I understand this is all WIP. But I'd like to ask:

About how much headroom is possibly there to improve XviD's decoder speed?

One quick example, giving the idea:

Source: MKV file: XviD 1280*720 + 2Bframes + qpel (25fps) ++ stereo Vorbis @ 128 kbps
CPU : XP 1800+

Playback w/out any PP:
ffdshow: 25 fps, ~80% CPU
XviD.ax: 12~14 fps, CPU @ MAX and beyond

As one can see, ffdshow effectively reaches double the speed of XviD's DS decoder! (I could even resize the clip by ffdshow additionally to 1024*576, and ffdshow stays in sync, cpu@100%, but not stuttering.)

And this is what bugs me a little these days: I'm sitting on a couple of HiQ clips I made, but I can't play them _really_ HiQ:
ffdshow shows IDCT related artefacts, and XviD is simply too slow.

So I'm curious what might come in store, and what will definetly not.

- Didée

[sysKin]

Originally posted by Didée
About how much headroom is possibly there to improve XviD's decoder speed?There isn't much of a possibility. There are some tricks which can improve b-frames (similar to what I've already done with encoder) but it isn't much.

Generally, XviD is not a good decoder and developers don't think it has to be. It's libavcodec that is a good decoder.

By the way your numbers surprise me. I can decode a 1280x720 hdtv encode (no qpel, no sound, bframes - the one in "hdtv sample" thread) at about 58% cpu load - at athlon xp 2000+. Can't watch with postprocessing.

Remember that you can reduce cpu load using YV12 colorspace - if your hardware supports it well. It's about 44..52% cpu load here if I do that

[Didée]

Well, I did force the output to YV12. That's why the speed climbed up to whopping 14fps ... outputting YUY2, I don't get beyond 12fps.
Qpel at those dimensions has a big impact.

Just to say it once more: _all_ other decoders that I managed to decode XviD with show more or less the same IDCT problems, where only XviD DS gives a (almost) clean picture.
It's really disappointing, to have e.g. a very-slow-panning scene, with forced "better-than-q2" (q2 /w high-bitrate matrix), and to still get *obvious* smearing of foreground objects against the background.

One more aspect, while I'm at it:
I remember that the (temporary) usage of simple IDCT in XviD was abandoned in favour to Walken because of compatibility reasons to other mpeg-4 implementations.
But, obviously, we do not have real compatibility: every other decoder in fact does have slight IDCT problems with XviD streams.
So where is the problem? Are really all other decoders that inaccurate, or lies the answer somewhere between the lines?

All of that is a little like having the holy grail behind a thick crystal wall:
It seems in reach, but is unreachable.

- Didée


P.S.
Will take too much years before I (re-)learned enough programming to fix ffdshow, though. By that time, h.264 will be old'n'dusty stuff ...

[Metamorphous]

The CPU is indeed at 100% for most scenes where its choppy... that is with the postprocessing all off - its a shame I dont have a faster machine to test this with - but I guess with a faster CPU I would not have this problem right ?

Is it likely that these problems with playback will be resolved/ the codec optimised in the near future with the final release ?

Just trying to figure out if I should keep this whole encoding of this movie or not - revert back to old codec and re-encode with that (though I am after quality more than anything else).

Oh and I didnt have Chrome optimsation activated - that was disabled.

Oh oh oh.... and one last thing with 1.0-Beta3 I get a much better play back... the cpu is near enough 100% (for most scenes about 90%) and there is occasional chopiness but much much less.

[mikeX]

i forgot to say that for the figures I mentioned i also had RGB32 colorspase for the xvid decoder and 'ConvertToRGB32()' through avisynth for ffdshow

@ Metamorphous:

As sysKin said, there is (sadly) not much room for optimization. But you don't really have to throw away your encodes since you can still use other decoders (i hear the day when ffdshow will handle 'packed bitstream' for multiple b-frames is not far)

[crusty]

@Metamorphous:
It's quite obvious that your computer is too low specced for what you're trying to do.
With previous builds I've seen stuttering on PIII-500's, and the new decoder is more power-hungry.
Qpel and B-frames both increase required cpu power for decoding, and besides that, it looks like you have several settings that I would set differently anyway.
Your Maximum frame interval is rather high and it is recommended to keep it about 10X the framerate. In fact I usually set it lower than that, to about 200.
Try again without packed bitstream, Qpel and B-frames, with Qpel turned off first. It will probably make a difference.
Also, see if your harddisk is nearly full. When NTFS partitions have less than 15% free space they tend to get rather slow, and if your encoded clip is heavily fragmented this can also cause choppy playback. Check your harddisk for fragmentation.

@all:
It has been known for some time that Qpel is more cpu-intensive.
Reports are somewhere between 30-60% more cpu power.
Also, a resolution like 1280*720 is quite big, and as far as I can remember isn't in any normal MPEG-4 profile. AS Profile only goes to 720x576 as far as I can remember. So I wouldn't consider it to be a big surprise if the file isn't MPEG-4 compliant anyway.
A picture of 720x576 equals about 414720 pixels.
A picture of 1280x720 would be 921600.
That's twice as much stuff to decode, and as mentioned in other threads, the decoder really needs a 1GHz+ cpu to do all the post-processing proper. And that's the estimate for the standard resolutions.
I frankly have no idea why the decoder has suddenly acquired such a hunger for cpu since beta-3, I can only guess that it has something to do with the development in the dev-api-4 branch, since most if not all pre-beta version decoders where from dev-api-3 development.

As for sysKin's xvid.ax, the latest version is 7, but Koepi told me that most if not all of the improvements in there went into the RC2 decoder.

However, if you have a high resolution Xvid there is ONE THING you can try:
The latest 'DivX player' from DivXNetworks uses hardware acceleration if you have an Ati Radeon 9500/9600/9700/9800. All you have to do is set the fourCC to DivX and try to play it in that player. I don't know if it will work, but it MIGHT. Give it a try.

And offcourse, the increase in cpu requirement could just as well be a simple 'oops' in the code overlooked by the devs....just a question of more people looking at the code.