As in, 'seeding' barren planets with life.

Just a fun little diversion. The animation is only about five seconds long. See
my post at...

http://news.povray.org/povray.binaries.images/thread/%3Cweb.49fe82c8fc186ae5f50167bc0%40news.povray.org%3E/

For some strange reason, when I view this on my Windows XP machine--using
Windows Media Player--I see a single, consistent 'stutter' at about 0.9 seconds
into it. This little glitch isn't there in the original image frames, nor is it
visible when previewing the animation in monkeyjam (the app I used to assemble
the images into an MPEG.) I'm wondering if anyone else sees this glitch?

KW

Post a reply to this message

Attachments:
Download 'animated_alien_sphere.avi.dat' (3001 KB)

"Kenneth" <kdw### [at] earthlinknet> wrote:
> As in, 'seeding' barren planets with life.
>
> Just a fun little diversion. The animation is only about five seconds long. See
> my post at...

Hi Kenneth, I really like your animation. I can't wait until you're able to
share with us your methods!


> For some strange reason, when I view this on my Windows XP machine--using
> Windows Media Player--I see a single, consistent 'stutter' at about 0.9 seconds
> into it.

Sadly, this is also the case on my computer. I am running Windows XP too, so to
prove to myself that I wasn't going crazy I also looked at it under my fresh
dual-boot install of Windows 7, and I get the same result.

I loaded the video file into VirtualDub and indeed you have a duplicate frame at
frames 16 and 17 (0-based), which are identical. Removing frame 17 leaves a
smooth animation.


> This little glitch isn't there in the original image frames, nor is it
> visible when previewing the animation in monkeyjam (the app I used to assemble
> the images into an MPEG.) I'm wondering if anyone else sees this glitch?

I don't know what to tell you, other than that I do see the glitch, and there
*is* an extra frame in there. Perhaps monkeyjam does see it too and removes the
duplicate frame automatically for you?

Post a reply to this message

"sooperFoX" <bon### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:

> > For some strange reason, when I view this on my Windows XP machine--using
> > Windows Media Player--I see a single, consistent 'stutter' at about 0.9
> > seconds into it.
>
> Sadly, this is also the case on my computer. I am running Windows XP too, so to
> prove to myself that I wasn't going crazy I also looked at it under my fresh
> dual-boot install of Windows 7, and I get the same result.
>
> I loaded the video file into VirtualDub and indeed you have a duplicate frame at
> frames 16 and 17 (0-based), which are identical. Removing frame 17 leaves a
> smooth animation.
>

Thanks indeed for this info.  I'll take a closer look at my original frames,
although I'm 99% sure that the original un-blurred animation itself doesn't
include duplicate frames. (The scene's animation code--and my 'post'-blurring
code, averaging each 15 frame batch--are both 'clean' AFAIK, and wouldn't have
produced a duplicate frame, anywhere in the chain.)  It's definitely a strange
situation.

Before posting my animation file, I actually went through two complete attempts
at encoding the 'blurred' animation in monkeyjam (using the xvid MPEG codec,
BTW), and both times, the same little stutter showed up when I viewed it in
W.M.P. I haven't seen such a glitch before, in my other similarly-made
animations.

Time to do some detective work!

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> Time to do some detective work!

OK, I've discovered some strange things.

I went back and re-rendered a large block of original animation frames
surrounding this glitch. No duplicate frames anywhere--I checked. Then I
'post'-blurred them as before (again, no duplicate frame among the final
blurred animation frames), and again used monkeyjam and the xvid codec to make
the .avi MPEG movie. And, as I expected, there is a glitch again--a duplicated
frame--but now it isn't in the same place!

So I did some tests, using different video compression codecs in monkeyjam:
INDEO, CINEPAK, and MJPEG.  And, much to my surprise, none of those three
resulting animations show any duplicate frames! It only happens when monkeyjam
uses the xvid codec. So I went into xvid and fiddled with some settings
there--which didn't help.

Using VirtualDub (thanks for the hint, BTW), I took this 'new' glitchy animation
and removed the offending duplicate frame; then re-encoded it there using xvid
again (just as a test), and the final animation plays in W.M.P. with no glitch.
(So it wasn't a Windows Media Player problem, as I had originally thought; nor
specifically an xvid problem.)

So the only conclusion I can come to is that monkeyjam and the xvid codec have
some kind of problem working together. Which means I need to go back through
*all* the xvid-encoded animations I've made, to see if *they* contain any
duplicate frames that I never noticed.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> So the only conclusion I can come to is that monkeyjam and the xvid codec have
> some kind of problem working together. Which means I need to go back through
> *all* the xvid-encoded animations I've made, to see if *they* contain any
> duplicate frames that I never noticed.
>

Sadly, I *do* see duplicate frames in many of my other monkeyjam/xvid
animations-- usually at the very beginning of the animation (which is probably
why they escaped my notice before) and *sometimes* an additional frame
somewhere within the animation. But I also discovered that monkeyjam has
sporadic problems with *other* MPEG compression codecs as well; not duplicated
frames per se, but other errors which look like 'interleaved video.' Not all of
the time, though, which is rather maddening.

Given these monkeyjam/codec errors, I think that from here on out, I'll use
monkeyjam only to *assemble* the animation, save it as a temporary,
UNCOMPRESSED video (which results in a large file, of course), then import that
into VirtualDub and do the xvid compression there. Experiments so far show me
that this is an error-free approach.

KW

Post a reply to this message