Log in

View Full Version : Divx 6.8.x - Decoder issues


dloneranger
2nd April 2008, 17:06
Has anyone seen/can confirm a problem I'm having with V6.8

PC
Amd 5600X2, 4Gb ram, nvidia gt7800 graphics card

Symptom
Occasional stuttering in playback - audio plays fine, but the video pauses then runs at high speed until it catches up
The same effect (but exaggerated) can be reproduced here by
1)play a video in Mediaplayerclassic
2)set affinity of mpc to 1 cpu
3)audio plays fine, video stutters and plays at low fps
4)reset affinity back to all core
5)video plays at high fps until it catches up to the audio

Both 6.8.1 and the 6.8.2 beta behave in this way

DigitAl56K
3rd April 2008, 03:10
I'll assume you've done the basics in MPC and from the Play menu checked the Filters list to ensure that the only filters related to the video path loaded are "DivX Decoder Filter" and the renderer. It might be interesting to see a screenshot of the filtergraph when you drop a .divx or DivX .avi file into GraphEdit.

Have you tried adjusting the settings in the Decoder Configuration Utility? It's available under "DivX Codec" in the DivX programs group on your Start menu.

I would first check the post-processing settings. If they are set to "Full Deblocking with Sharpening" this has the potential to tax your CPU. You might try "Automatic Deblocking" instead, which within reasonable parameters is self adjusting based on real-time decoding performance. Make sure you have the "Reduce CPU spikes using one frame delay" option checked, and try temporarily disabling the options "De-interlace video" and "Use advanced hardware overaly". If the problem goes away after following these steps then try restoring the original options one at a time to identify what is causing your issue.

Limiting the process to a single CPU when decoding high resolution video files with post-processing at high levels is not something I would recommend, by the way, but I can understand why you might do it for diagnostic purposes.

You might also download Process Explorer and set the CPU chart to show one graph per CPU (or even just use task manager) to see if during decoding any one of your cores is maxed out, which might point to other problems.

Are you by any chance using a USB sound card? I have one of these for my laptop and I've noticed it eats 10-20% of the CPU time in deferred procedure calls, which is CPU time not normally displayed by task manager (although ProcessExplorer will show it). Try using GraphEdit to play the content after deleting the audio decoder and renderer from the graph, and see what happens.

dloneranger
3rd April 2008, 12:20
Hi, thanks for the reply :-)

The decoder is set to automatic deblocking, deinterlace and advanced overlay are off, framedelay has been tested both on&off

Graphedit shows just the basic filters (avi splitter->divx decoder filter->video renderer)

The videos are not hi-def, but the problem is resolution independant - even a 64x64 test video is affected

Rechecking after removing the audio with virtualdub shows no difference (apart from graphedit not splitting/rendering the audio of course) - the sound device is not usb btw

Taskmanager is set to show one core per cpu with kernel times

Typical cpu usage for mpc while playing a video 6%-12%, but when you force the affinity to 1 core it rises to 50%, maxing out the single core until you let it use both again, then mpc runs at about twice normal cpu usage until it catches up - all goes back to normal then

(Changing the affinity was just a way to force it to show the same problem that happens in regular use)

Dixv 6.7 is of course not affected by these issues and the pc can happily play back 4 dvd resolution videos all at the same time

Thanks for the attention and hope some of that info is useful for you

DigitAl56K
3rd April 2008, 21:23
Can you tell me:

Which renderer is MPC set to use (Options->Playback->Output), give me the "DirectShow Video" and "VMR7/9 (renderless) & DirectX 7/9 settings".
Is the problem occurring natively in GraphEdit when you tested it?
Which version of the nVidia drivers are you running? (Start->Run->dxdiag->Display->"Drivers" panel)
What settings did you use when you encoded these DivX videos? If you used the DivX encoder, can you provide me with a copy of the CLI string from the settings button in the encoder GUI?


Thanks!

dloneranger
3rd April 2008, 21:41
In order

Mpc is currently using EVR, but the same happens in vmr7/9 and overlay

Graphedit has the same issue

In DXdiag, the drivers show 7.15.0011.6925 as the version number (the latest non-beta version)

Cli is -bv1q 5 -vbv 4854000,3145728,2359296 -dir C:\ -pq 8610 -b 1 -profile=3 -quantization=2 -thread_delay=1

DigitAl56K
3rd April 2008, 21:49
XP SP2, Vista, Vista SP1?

dloneranger
3rd April 2008, 21:53
All 3 ;-)

Dual boot xp sp2, vista sp1 now, but it was plain sp1 until a few weeks ago

Tbh I wouldn't have thought of mentioning it, but I've seen it on a few pc's now with all sorts off configurations

DigitAl56K
3rd April 2008, 23:00
Okay,

I can definitely reproduce the situation when the affinity is locked to a single CPU! EVR is barely working for me in MPCHC, but that's another issue :)

Our codec dev team are wondering if you see CPU spikes when these slowdowns occur under normal circumstances (i.e. no manual overriding of the affinity), and we're also interested if in ProcessExplorer when you double-click the process to view the process property page and go to the Threads tab whether one or multiple threads in module "divxdec.ax" are showing abnormally high CPU usage? Note that in ProcessExplorer it may be advisable to choose "View->Update speed->0.5 seconds" while performing this investigation. This will increase the CPU use by ProcessExplorer, so remember to revert the setting when you're done.

Thanks so much for your help here, looks like we're on to something!

dloneranger
3rd April 2008, 23:22
Yes there is a spike in normal use, you can't see it in process explorer as it's over too quickly to see, but it is visible as a spike in perfmon (sudden 100% cpu usage)

I don't know if this is relevant but it's always core 0 that spikes, at least on this pc