- User Since
- May 7 2014, 10:07 AM (280 w, 1 d)
Jul 13 2019
System info added.
Oct 20 2015
Timecodes seem to somehow depend on proxies; one can't exist without the other. Somehow building actual proxies with Record Run seemed, at least for now, to fix the problem. I'm attaching a fifth test case to illustrate this.
Oct 10 2015
I do not get that output file when using Record Run. Maybe you confused which video files you were using. I am attaching a new file which includes the original video clips and the original blendfile using "Record Run" on all of the clips.
The only difference between the original and testscene3 is the video clips themselves, not the blendfile. I observe a huge difference in behavior. When you "render it out" (which is when Blender creates a video file from the contents of the timeline), the timing is correct and the speed of movement is constant. In the blendfile with image sequences, the sequence was (ignorantly) edited to match the intended timing as closely as possible before I realized that simply outputting an image sequence from the video file is incorrect in this case, because in this case the video files have a variable framerate, which is not something Blender has ever been equipped to handle. I have suggested how this problem might be solved, and to illustrate what could be I had to take the unorthodox step of changing the video files, not the blendfile, to reflect how Blender should treat the original clips, as the new clips have their longer frames repeated so that there are exactly 25 frames per second rather than a variable number, which is what a variable framerate is. I really don't have a better way of explaining this.
Mark this as "confirmed".
Oct 8 2015
I tried doing it with Record Run No Gaps and it did not solve the problem. What did solve the problem was transcoding the clips using the ffmpeg video filter -vf "fps=25". Since it's a video filter I'm sure it would be a simple matter of having Blender apply it during playback and rendering to enforce the reported framerate of the file. The nature of these things is such that it wouldn't affect how Blender handles clip timing with project framerates. I'm attaching a zip containing these transcoded files so you can see the effect.
Thank you, Sergey. That did not fix the problem. Behavior is the same after applying timecodes. Did you try it yourself in this specific case? When it renders out we've got those damn glitches again.
Does Sergey even exist, or is he just some black hole you assign unsolvable problems?
With ffmpeg you typically have to do a lot of stuff manually to get it right. For instance those video clips included in the first test case were re-encoded with ffmpeg from the camera source files, with ffmpeg maintaining the original frame pattern exactly as it was. In order to get 25 actual frames per second to match the reported framerate when transcoding, something else would have to be typed into the command line. I'm not exactly sure how this particular thing applies to Blender and how they dance though.
Oct 7 2015
I made a test case with frame sequences. Based on the results, here is what I think is happening: Video coming off of this particular low-end camera is recorded in a variable-framerate optimized stills format, which is commonly used in cases where subsequent frames in an intra-only format are identical, for example when "auto slow shutter" kicks in and the format is MJPEG. turning the AVIs into frame sequences resulted in a strip that speeds up and slows down according to available light, an interesting phenomenon that is consistent through subsequent playbacks and rendering. So yes, it appears that effect strips somehow exacerbate the problem, but (depending on who you want to blame) the problem is that Blender is incorrectly or inconsistently handling variable-framerate videos, at least in the VSE.
Actually Campbell, all of the clips are indeed MJPEG.
With no sync playback seems to match rendering but the middle clip is still glitched out. It's too fast. That was not how I cut it.
I have not confirmed the problem going away by doing that. I don't see a No-Sync option in 2.76-rc3 though I disabled AV-Sync. I'm still seeing the middle clip playing too fast, which I guess differs from the gremlin manifestation of before. Video also renders out the same incorrect way as it did before.
May 9 2014
Well, shit. I can't reproduce this bug in 2.70a. I don't know what that means.
May 8 2014
I can't seem to reproduce it this morning either. Not one crash. It's really frustrating because I don't know what other variables are involved. I'm attaching a blend file that is supposed to represent the steps I described, but it's solid as a rock. I've tried several different blend files and no crashes. :( I also can't seem to attach a file in IE9, so I've uploaded it to another site.