Didée
6th September 2006, 09:17
The file is hosted here:
http://rapidshare.de/files/32120026/CrashingXviD.rar.html
(26MB, Huffyuv (ffdshow/YV12), 200 frames)
It's a preprocessed sample of a DVB-S capture. The sample is error-free, and other encoders than XviD encode it fine. There's not any error message when XviD crashes. Window's hourglass will come up for half a second, then the host application silently vanishes.
From the source's side, it seems related to the "special effect" that is used here: motion in every 4th frame only, with 3 almost-dups inbetween.
(My problem is that this effect is used quite frequently in the series' episodes, so there are many many places where XviD is likely to crash... :( )
On the encoder side, the error seems related to VHQ-search for Bframes ++ (guesswork->) block skip detection. Here's what I figured so far:
Needed settings to crash XviD are: use Qpel and use Bframes and VHQ for Bframes. (No crashing if these settings are not met.) With these settings, the behavior is:
- with "turbo" on, XviD will *always* crash.
- with "turbo" off, VHQ1 will crash, VHQ4 will get through without error.
When adding more and more noise (addgrain(1), addgrain(2), etc.), it is possible to get lower VHQ levels to encode without error. That's why I think it's somehow related to skip detection.
Interesting: VHQ=0 + VHQ for Bframes (funny combination) still will crash.
The error seems not related to optimizations. When deactivating all optimizations, XviD still crashes. (edit: Seems to be in MMX optimizations.)
The source vertically is only MOD8, but tests with MOD16 showed the same behaviour.
I've tested XviD vfw only. Two builds, an 1.2.0dev build from Dec 2005, and celtic's latest MTK build, behaved exactly the same.
http://rapidshare.de/files/32120026/CrashingXviD.rar.html
(26MB, Huffyuv (ffdshow/YV12), 200 frames)
It's a preprocessed sample of a DVB-S capture. The sample is error-free, and other encoders than XviD encode it fine. There's not any error message when XviD crashes. Window's hourglass will come up for half a second, then the host application silently vanishes.
From the source's side, it seems related to the "special effect" that is used here: motion in every 4th frame only, with 3 almost-dups inbetween.
(My problem is that this effect is used quite frequently in the series' episodes, so there are many many places where XviD is likely to crash... :( )
On the encoder side, the error seems related to VHQ-search for Bframes ++ (guesswork->) block skip detection. Here's what I figured so far:
Needed settings to crash XviD are: use Qpel and use Bframes and VHQ for Bframes. (No crashing if these settings are not met.) With these settings, the behavior is:
- with "turbo" on, XviD will *always* crash.
- with "turbo" off, VHQ1 will crash, VHQ4 will get through without error.
When adding more and more noise (addgrain(1), addgrain(2), etc.), it is possible to get lower VHQ levels to encode without error. That's why I think it's somehow related to skip detection.
Interesting: VHQ=0 + VHQ for Bframes (funny combination) still will crash.
The error seems not related to optimizations. When deactivating all optimizations, XviD still crashes. (edit: Seems to be in MMX optimizations.)
The source vertically is only MOD8, but tests with MOD16 showed the same behaviour.
I've tested XviD vfw only. Two builds, an 1.2.0dev build from Dec 2005, and celtic's latest MTK build, behaved exactly the same.