Movie from Input node skips frames on ANIM?

Support Compositing and Post Processing
1

Can anyone here confirm whether I have encountered a bug or if I’m just doing something wrong?

I am creating a video that will be the composite of live action shot at 29.97fps 1280x720 with animation from Blender 2.49b mixed over the top.

Last night I rendered 6480 frames, but as I was flipping through frame by frame in the output folder I noticed that while the Blender-animated scene moved smoothly, the background video frames have jerky motion because every 2nd or 3rd frame (inconsistently) is a copy of the previous frame instead of the next unique frame it should have been.

In effect, the animation frames go 1, 2, 3, 4, 5, 6, 7, 8, 9 while the video frames go something like 1, 2, 2, 4, 5, 6, 6, 8, 9.

The source video, like I said, is 29,97fps, and if I step through its frames in VirtualDub, each frame is different. Smooth motion, no repeated frames. Blender’s render format is set to 30fps / 1.001 fps base.

In Blender, I am using composite nodes to mix the background video with the 3D scene. With an Image Input node I am bringing in the source .AVI video with Frs = the exact number of frames in the video, SFra = 1, and Offs = 5. Cycle is turned off. If I enable the Refresh button on the node and then step through the frames, I can see every frame of the video properly display with none skipped/repeated. I can render one frame at a time with F12 and it will always be correct. However, when I use the ANIM button to render a bunch of frames (with Do Composite enabled, obviously), that’s when the background video’s frames get messed up.

Is there anything I can do to make sure the Image Input node refreshes for every frame when using ANIM to render multiple frames?

2

What format is your live video? If a compressed format, there may be issues with frame-by-frame consistency. I’ve run into this in the Video Sequencer Editor using .avi files compressed with Xvid using the “AVI codec” option in the VSE – during lap dissolves (“Cross” in the VSE) either the incoming or outgoing strip may, at some random point in the dissolve, back up a frame instead of going forward. Other glitches involving frame count have also occurred.

I haven’t use compressed .avi in the Compositor but it’s possible similar issues may exist. A solution is to render your live video out as either uncompressed (“raw”) .avi, or to an image sequence. I’ve never experienced any glitches using either of these approaches – in both the VSE & the Compositor, they are always frame-to-frame accurate. An image sequence saved as .PNG is probably you’re most economical approach, as raw .avi tends to be a bit bloated.

Virtual Dub can write out your Image sequence, which may be more reliable than Blender’s output of the same file.

3

Exactly, it’s an AVI compressed with Xvid, so I’m probably seeing the same issues you’ve encountered.

I wrote out the video as an image sequence with VirtualDub and that seems to be working. Thanks!

4

I have the same frame skips in dissolves from quiktime files.

5

There is something niggling in the back of my mind about how in certain conditions Blender may choose to re-display a frame … because it’s running out of time and computer-power … oh, heck. What is it that I’m trying to get my :ba:-year-old brain to remember?

6

AV sync for playback, but thats real time on timeline.

7

Ah, yes. That’s it. Unrelated.

8

sundial, you may be thinking of, if you change something in the scene in 3D view, the sequencer scene strip is not marked dirty, and a re-render via vse will get you the old frame.

I think your OP error is dealing with frame encoding sequences. some compression formats store b frames which are backwards derived. see http://en.wikipedia.org/wiki/Video_compression_picture_types and so it seems like your decoder codec is not properly re-constructing the frames for that video before giving it to the VSE.

Try upping your pre-seek to at least 5, so the B can look ahead.

Otherwise, a frame sequence is the way to go, or use a mpeg codec (ffmpeg can convert it really fast, as can the vse).

9

Xvid is an MPEG-4 codec. IIRC the frame-backup glitch only started showing up in 2.49b. I usually use the “AVI codec” option for writing out the glitched files, I’ll try a few using FFMPEG with the Xvid and other codec options, see if it makes a diff.

10

Papasmurf what do you mean by pre-seek? Is that an encoding option or a decode at VSE or a transcode prior to VSE?

11

chip, xvid is an mpeg-4 variant; version 1.2.2 is a bugfix release which may be what OP is seeing (a bug). I was meaning the vanilla mpeg-1 or mpeg-2 inside a recent ffmpeg from within Blender.

3pt: Pre-seek is a decode option needed to properly decode b frames. in the VSE, it is set on strip properties, input panel, MPEG-Preseek. Alas, there is no pre-seek option for the image input node.

First, try upgrading your decoder to 1.2.2. If no difference, then spool it out to an mpeg-2, or frame sequence, and go from there.

12

I can’t claim any great knowledge of codec variants, the whole subject is more than a little confused by the scads of standards and implementations, so I try to stick with a single choice (Xvid’s MPEG-4, variant or not). But in trying out various codec options using FFMPEG, I get a number of error messages from Virtual Dub when trying to play back MPEG-1 and MPEG-2 .avi’s written out of Blender. This isn’t finger-pointing (I wouldn’t know which way to do that :eek: ), just anecdotal comment. VLC will play most of them but VLC (even the newest release) lacks a few features that I need for my production pipeline, and to my eyes doesn’t have the image fidelity VDub brings.

Since all MPEG standards are only that – standards – and codecs are written to implement them in various ways (in other words, they are all variants of one type or another), it’s not unexpected imo that problems arise in their practical use. In terms of fixes, I think we’re stuck with workarounds and make-dos unless everyone in the universe decides to use the same set of a/v codecs without exception – like that’s gonna happen :rolleyes: :wink:

13

+1 to that. Plus, mpeg compression can really hurt image quality. I am animator and compo for a feature film and doing short shots like 1 or 2 seconds of film, if I put out using mpeg from Blender, VLC playback cuts off the last like 10 frames, consistently, and on a 2 second shot, it’s very very annoying because you don’t get that last half-second.

The only rock solid workflow is to spool it out to a png frame sequence and work with that as your input.

14

Agreed. I get that frame-cutoff also (usually 6 frames, though), and other frame-to-frame inconsistency, when using compressed .avi’s in the VSE. I’ve started using them only for rough prelim edits as I build sequences & block the timing. Once the animation’s close to final I start using PNG image sequences even for “playblast” renders, so the VSE transitions will be smooth & predictable. Makes replacing them with beauty renders a lot more accurate, also.

15

Lots of interesting discussion on this, I see!

Like I said, I went with an image sequence and that worked. But I’ll also look into upgrading my Xvid decoder per PapaSmurf’s suggestion and see if that would have made a difference.

Here is the finished product: http://www.youtube.com/watch?v=c-2-8p6kEUI

16

Great playing! I love the wrist-smack chord near the end :smiley:

However, while it starts off with a great grin at the realization of how you’ve played the road markings off against a MIDI track graphic, the whole piece suffers from the lack of differing camera angles and/or camera movement, Yes, I know this would have complicated the CGI by a geometric factor, but it also would make for a far more interesting short imo.

Is that your composition, btw? If so, big kudos!

17

Not my composition. It’s Jon Schmidt’s.

I agree about the static camera hurting the composition, but I only have 2 hands. :wink:

If you’re interested, I have another video where I didn’t line up the 3D with video, so I got to do some Blender camera choreography. Also a Jon Schmidt piece, with more forearm chords. Might be off-topic to discuss here, so go see it in the Finished Projects forum: [post]1650154[/post]

18

Well, then, beg, borrow (prob’ly better not to steal) a couple more cameras & tripods & set 'em up for multiple coverage. Then switch 'em around and play it through again. Actually that can be done with only one camera but it does put a strain in the pianist. As long as he/she stays in accurate tempo, cutting between takes shouldn’t be too difficult. But it is a lot more work.

Unless you’re willing to futz around with camera-matching/tracking software, static cameras would be the only way to go unless you can do a pan & scan to fake it. But even with locked-down cameras, a selection of interesting POVs would do a lot to maintain interest through the end of the piece.

19

Indeed, and that’s a shooting method I’ve used before (but not involving 3D elements). However, the primary goal of this “Road Trip” video was to capture an authentic musical performance for a contest. Adding the piano roll effect in blender is harmless icing on the top, but cutting to different camera angles would be undesirable here for the same reason as it is for an illusionist.

But although I couldn’t use it for this particular project, I still value the ideas and feedback!

20

My bad, I thought this was supposed to be something more than a visual documentation of playing skill. To me , that comes with the listening, not the seeing – I trust the artist enough to believe it’s not “faked” even if I can’t see it being played. But maybe in the digital music world that’s a bit naive – mea culpa! :wink:

I guess I see “performance” as having two different aspects, the aural dimension, where you can just close your eyes and sit back and enjoy, and the visual dimension, where you want to sort of see “everything at once,” like Picasso tried to do with some of his figures. Cutting between POVs is fulfilling the visual part. I recall from the days of live TV seeing performances (from solo piano to full orchestra) in studio with three cams and a director calling the cuts from shot to shot, and never, ever getting the feeling that the performance was in any way anything but in the moment. If the edits are handled well, the continuity of time and performance can be seamless. IMO, of course.

In any case, Bravo! on the playing, very impressive. The piece certainly documents that well :smiley: