Decoding/Playback Lags with Nic's DS Decoder and bframes

[jang0]

I encoded a 640*480 25 FPS clip with the following settings (Koepi build 14052003-1):

1pass CBR 900kbps

Motion Search Precision: 6
Quantization Type: H.263
FourCC: Xvid
VHQ mode: 1
Max/Min I-Frame interval: 250/1
lumi masking: OFF
greyscale: OFF
interlacing: OFF
chroma motion: ON
Quarterpel: ON
GMC: OFF
Maximum B-Frames: 2
B-Frame Quantizer Ratio: 150
B-Frame Quantizer Offset: 100
B-Frame Threshold: 50
DX50 B-VOP compatibility: ON
packed bitstream: OFF
Min I-Frame Quantizer: 2
Max I-Frame Quantizer: 31
Min P-Frame Quantizer: 2
Max P-Frame Quantizer: 31
Max Bitrate: 10000
Max overflow improvement: 60
Max overflow degradation: 60
Chroma Optimizer: OFF
trellis R-D Quantization: OFF
Reaction Delay Factor: 16
averaging period: 100
smoother: 100

My Problem/its symptoms:

When playing back the plain avi file (without sound stream) using nic's ds decoder (build 23.02.2003 or 30.03.2003) and windows media player 6.4 the video gets stuck/lags at certain frames (always the same frames) for approximately 2 seconds and then continues playing. it doesn't continue at the same frame but the frames that should have been displayed during the lag are just omitted. during the lag the cpu load drops to nearly 0 % and then goes up again to the usual 60-80 %.

This occurs on the following conditions:

- it seems to happen only with the special clip (see encoding options above)
- output color space is set to RGB32 or No Force (Yuv12 and yuy2 work fine, rgb24 doesn't seem to work at all, probably a video card incompatibility)
- one or more postprocessing options are activated

ffdshow has the same problems when selecting RGB32 and activating postprocessing.

Does anybody know what causes this problem?

System:
CPU: AMD Duron 1300
Motherboard: DFI AK74-EC
RAM: 512 MB SD-RAM PC133
Video: Geforce 2MX-400 64 MB
OS: Win2k Prof. SP3

[Nic]

"ffdshow has the same problems"

Are you saying that ffdshow displays exactly the same problem? What about if ffdshow uses xvid.dll rather than libavcodec?

Is there anyway for you to upload a bit of the clip that demonstrates this? (maybe your CPU cant handle decoding and postprocessing with these particular options ?? )

Id normally just assume CPU, but 1300 is fast enough and you say that the CPU drops to 0%...very strange

Thanks alot for posting all the relevant XviD settings :)

Cheers,
-Nic

[Lobuz]

I observed it too. There is a point where CPU usage goes high and then it's pauses and drops to 0 for a really long time.

At my GeForce2Pro64 (Winfast) the colour space have real quality or speed impact. In NoForce and YV12 there is much more Kernel CPU usage. I think it's NVidia's shitty drivers and there is a little luma, chroma offset ( 2 ), which sometimes looks awfull - faces. I use only yuy2. Wouldn't it be safer to set it at yuy2 for default?

Another unfriendly factor that's working Network app in the background(1-2 to 10% of CPU at jump). It's unfriendly for XviD - setting highest priority helps.

It looks like ffdshow is really much more efficient then nic's standalone decoder (but I'm not sure if the quality is identical). It's faster Especially with qpel and B-frames stuff. With ffdshow and XviD dll it's only a little faster.

At my Athlon 900 I can play XviD(no qpel, no b-fr) 1440x784 with stereo Vorbis ( resized Matrix trailer ) without a single drop of synch with ffdshow(no postproc). But with XviD dec its impossible even in lover resolutions.

Regards
Lobuz

[jang0]

I just checked ffdshow again, it only occurs when using xvid.dll, NOT when using libavcodec.

I'm just preparing a clip that shows the problem. is 12 Megs Ok for you or should i make a smaller part of it?

the strange thing is that the video is decoded at constant 25 FPS except for the lags.

BTW: is there a tool that checks if a video stream is mpeg4 compliant?

regards,

mark

[jang0]

I've made a 2 mb sample that shows the problem (at least at my computer). it can be downloaded here:

decoding_lag.avi (http://320088823240.bei.t-online.de/misc/decoding_lag.avi)

regards,
mark

[Didée]

I bet it's simply a system overload.

- 640*480 are quite a lot of pixels, a lot of macroblocks to decode.
- Bframes increase CPU load.
- Qpel increases CPU load even more.
- You try to output RGB, what forces an additional colorspace conversion. (Perhaps you don't even get an overly surface with RGB, who knows what Nvidea's drivers are doing?)
- And after all of that, you run with postprocessing enabled!

Don't expect miracles from a Duron 1300 ... ;)

Just for testing, repeate the encoding with a res of 512*384, or even 448*336.
I'm almost sure your problem will disappear with lower resolutions.


Oh, and the problem is only with Nic's decoder as well as with xvid.dll, but not with libavcodec?
Since libavcodec is the fastest decoder, that seconds my assumption.



Regards

Didée

[drebel]

Owing a Duron @1GHZ gives me a more precise knowledge of its limitations ,so that one can expect SOME miracles from it ;) I mean ,my limit is about 704,xxx (even with 4:3 AR) with b-fr+qpel
If "frame drop ratio" is untouched in debug tab of the encoder (i dont know if it works bugfree anyway ),then it has to do with unnecessary colorspace conversions from your graphic card.The easy way to find this out is to load graphedit and to take a good look at the filter chain : if a certain "decompressor" is taking place between xvid.ax and video rendener except overlay mixer (or overlaymixer2) then we have the guilty one.
If it's the last case,thing are getting more complicated : i experienced the same problem with Nic's xvid.ax while trying to force some colorspaces out of my Geforce2MX and 43.45 detonators.I think the prob lies in the dshow filter itself and just waits for a fix ;)
I assume you 're using a "light" player for that purpose (try media player classic instead to avoid that hadware acceleration slider) and have already checked for occupied system resources.Try also Reclock filter for video-sound synchronisation (u 'll find it through the search button)

regards,
george

[jang0]

now that's really strange: now the lags also appear when forcing yuy2 or yv12 output. in graphedit, Avi Decompressor is used between the Decoder and the Video Renderer when YUY2 or YV12 is forced, not when RGB32 is forced.
I also tried different Detonator driver versions, same problem.

I also tried Media Player Classic and the Reclock Filter. I shut down all unnecessary services and threads, but still the lags occur. Perhaps it's really a simple performance problem, because without bframes and qpel, the clip plays perfectly smooth.

[cult]

I played your avi with zoomplayer,ffdshow and nic's.Didnt notice a simple lag though with no pp.Activating pp I had a signle lag in frame 180.It is when the screen gets full of light because of the rocket's engine.Otherwise all is ok.Noted that I played the avi and in the background my cpu was busy encoding(vdmod at idle),downloading from internet and being in a irc channel.If I stop all this maybe I ll get a better luck.My cpu celeron overclocked@1ghz,radeon 8500

[drebel]

Avi decompressor ? Not good ,i guess...Shouldn't that be performed internally in Nic's filter instead of forcibly porting another one into the chain?
Well ,where's your prob anyway?Video rendener ALWAYS outputs to RGB ,so why all the trouble ?Simply use Force RGB from Nic's Dshow for now ;)
BTW, is that "vertical yellow line on the right " prob with YV12 close to any solution?
Just a guess ...

regards,
george