- User Since
- Sep 29 2016, 6:09 PM (111 w, 1 d)
Mon, Nov 5
Any change in behaviour is in FFMPEG, not in the VSE code itself (which just takes the frames and the playback rate data from ffmpeg as it has always done).
Wed, Oct 31
@Tobiasz Karoń (unfa) VLC is pretty clever, and if the file contains information about a dropped frame or an altered presentation time, you can bet that VLC is capable of interpreting that correctly and adjusting the timing to stay in sync. Blender just takes the average frame rate, and the index of the frame you're on, and calls it a day.
Apr 17 2018
I just downloaded your sample... it only contains 1391 video frames (checked by transcoding it with ffmpeg and looking at the frame count at the end).
Since the audio length in your reports is the same between 2.76b and later versions, and it's the video that has changed length, I would argue that 2.76b was getting the video length wrong somehow. It may even be a difference in ffmpeg / libavcodec rather than in blender itself, since the library versions also change between blender releases.
Mar 25 2018
Mar 9 2018
Hi folks, you might find this interesting. It's from a while ago so probably doesn't compile with current blender source...
Aug 3 2017
Have you tried specifying an absolute path for the font?
I have this patch in my local builds (Fedora) and it works fine. Admittedly my source isn't really up to date, I think it's hovering somewhere close to 2.78c. It's been a while.
May 17 2017
Apr 19 2017
@Sergey Sharybin (sergey) on the topic of git logs, does the system pull an email address from this account? If so I should change it to my blender-specific one (trying to keep spam vectors to a minimum).
Removed name from comment.
Apr 18 2017
Updated to use more efficient conversion when color spaces are identical as per @Sergey Sharybin (sergey)
@Sergey Sharybin (sergey) sorry for the diff spam, uploaded it as you were typing. Sounds much better to use the simple conversion!
Okay, probably best to ignore pretty much everything I said above. I think I had my git in a mess (this seems to happen to me quite often now I come to think of it...) resulting in my jumping back to 2.78c still having the issue.
Whoops, sorry - I mis-spoke before. I had added a text strip, forgetting that those default to "alpha over". Seems it doesn't matter where they are in the layer stack, if you have any other strips that are supposed to combine with the scene render (Add, Subtract, Multiply, Alpha over / under, Over Drop blend modes) then you either get nothing, or the 3D scene render, as your output (which thus doesn't match the OpenGL preview).
Ah okay, thanks for the extra info. If you add another sequence strip (anything will do, color strip maybe?) on top of the scene strip, what ends up being displayed?
@Aaron Carlisle (Blendify) ffmpeg gets the length right because the duration (in frames) has doubled as well as the tbr. If you let Blender change the scene rate to whatever ffmpeg tells it, the length in elapsed time is correct.
There's something pretty odd going on here. Firstly, I wound my source back to the commit that was tagged as 2.78c, and it still exhibits the problem. Secondly, the problem is nothing to do with the operation of "alpha over", but instead to do with the render result display.
Apr 11 2017
Also N.B. the output of ffprobe for the "bad" clip is different from that quoted in the original report:
I am full of questions.
Apr 10 2017
I can't replicate I'm afraid... I get the same result in 2.78a (same hash as you mention) as 2.78c - the clip is seen as 59.94 fps and if it's the first clip imported, the scene framerate is set to match. It could be that all of them are wrong, but they are at least consistent.
Apr 3 2017
Can't reproduce here (admittedly different platform)... can you upload a set of files (including blend) that produces this result? Thanks.
Apr 1 2017
Right. The only build that I can make crash is my own, with a bunch of patches, based on master as of 2017-03-26. A build of the same master, unmodified, does not do it, so my reports are almost certainly a red herring.
Mar 31 2017
Hokay, it did it again while running in the debugger. It's late at night and I was about to stop editing so I'm just going to paste as much as I can here and tidy it up / investigate properly later, with apologies to anyone who gets this mess in their inbox.
Not going to reopen this yet, but I did have a crash today just as a proxy finished rebuilding. However, restarting blender (in the debugger this time) and rebuilding the proxy for the same strip did not make it crash again, so there's some random factor at work here. Crash file attached, it's fallen over in a different place to OP's though.
Mar 29 2017
Hmm, that's a strange one... can you provide a set of files to reproduce? I think proxies generally work for most users, so I guess we should find out what's different in your case.
Mar 27 2017
Sorry it's taken me so long to chip in... this seems to work fine, both on the example provided and on my ones from T49658. It also looks to be a little more CPU-efficient than my attempt and it certainly touches less files.
Mar 13 2017
@Alberto Mardegan (mardy) I don't think it works for multiple instances of the sub-scene.
@Germano Cavalcante (mano-wii) sorry for the delay in replying, have been AFK on holiday. I agree that the recursive search every frame is not efficient. I ended up doing it this way in order to avoid changing any structs / file data, to make sure it was compatible with as much as possible. It would be much better to record the parent / child's pointers into the scene / strip struct at the point of adding the scene, and save this into the file somehow, rather than working it out from scratch every time.
Mar 4 2017
Huh, well this is quite odd. I started a fresh blend from scratch using your audio, and everything pitch-wise was going fine UNTIL I moved the clip (with g). Then, all hell breaks loose and there is no way that I've found to get everything back in step.
Mar 3 2017
Of course, but that would be a feature request so we cannot create a task on here. Perhaps on rightclickselect.com ? I could make a thread on there but won't have time to do it soon.
Yes, sorry about the coding style stuff... force of habit from the style used at work and in all my home projects! I just can't stop my fingers from doing C++ style comments. If people are generally happy with the functionality I'll reformat it (and make sure the patch still works against an up-to-date master).
Hmm... can't confirm with released 2.78b, and I use the pitch control fairly often and thought I was familiar with its various foibles.
Mar 1 2017
No crash here, Linux x64 hash d2f4900 (somewhere in between 2.78b and 2.78c)
I use proxies quite a bit and don't recall any random crashes. What format are your source videos in? If you can create a sample that crashes every time and upload it that would be great.
Feb 23 2017
Pretty sure that's not a bug... if you want to freeze-frame at your cut point, use hard cut (shift K). Soft cut followed by a cross is used to cross with moving pictures.
Feb 14 2017
In fact, in the description of the command (hover over it), it does say "independent of selection or locked state of strips" so I guess this is intentional.
Confirmed with master hash d2f4900. Also positioning cursor over clip 2 and removing gaps also moves clip 3 - basically locking has no effect on the remove gaps command.
Feb 9 2017
Because I felt like it, I have made D2506 which introduces Ken Burns Mode to Transform strips. If you find it helps then use it, if you don't then don't! :o)
Feb 8 2017
Patch made, just have to twist the arm of one of the devs to commit it :o)
Jan 27 2017
I downloaded your phone video, and I think that it does not have a consistent framerate - as algorith noted its average framerate is 26.57fps, but even with blender set to that rate it doesn't map correctly.
I use mixed framerates a lot, so I made blender cope with it better than it does... it's not quite production ready yet as I do notice bugs when I'm using it, but I no longer rely on the "speed control" strip.
Dec 5 2016
Dec 1 2016
Huh. Confirmed using your command - I was using -f to render one frame rather than start and end frames.
I've tried a few variations, but always get the same size image as the one generated in interactive rendering.
Nov 25 2016
TBH I didn't see anything specific to text strips in the debugger - it fails trying to load proxies on the following sequences:
Found a crash while looking at a slightly dodgy file, updated the diff to fix it.
I found a crash in the form of an infinite recursion loop in calculate_evaluation_frame_offset_recursive while looking at a (somewhat dodgy) file in T50112. Fixed by making sure that we don't recurse if the scene referenced by the current sequence in the loop is the parent scene.
FWIW I've made a diff for the patch that stops it crashing.
Crash confirmed on Linux x64, it's falling over in intern/readfile.c - direct_link_scene() where it tries to set seq->strip->proxy->anim to NULL but proxy itself is NULL so it segfaults. Perhaps this file expects proxy data (do you have proxy data on disk OP, or is this someone else's file?) and this function cannot cope if it is not found?
Nov 23 2016
This appears to be a duplicate of (fixed) issue T49975
Nov 16 2016
I just tried it on the released 2.78 (not 2.78a) and the somewhat-newer build I have been hacking on, both work the same - drawing by pressing D and clicking creates strokes, and if I let go of D before LMB then I can keep drawing new strokes with the mouse.
Nov 9 2016
The frozen-end-frames behaviour is definitely related to this - the strip has its "endstill" value set as if the source was still the old length.
Oct 30 2016
Cool. I've just spotted a bug in my patch and fixed it in the diff, doesn't affect you but thought I'd mention it here in case anyone else has tried building with it.
I realised there was a bug in my linked-list traversing that meant it would never look at the last one in the list. Now fixed.
Oct 29 2016
Righto. I made a quick demo vid of how it behaves now:
Oct 28 2016
I'm not sure if this is intentional or not, but it certainly bugs me. I have fixed it in the referenced diff by searching for any matching scene strips and updating their details.
Oct 27 2016
Oct 23 2016
Heh, sneaky. Animated volume will be late by the audio buffer length, but I doubt anyone will notice unless they're using very long buffers. Might get a click at the very start of the render if the first animated value is supposed to be 0, as it'll fade down from 1.0 to 0 over the first buffer.
Oct 21 2016
Bit more info... having clicked the same button in my patched build, it now no longer crackles in preview playback.
FWIW, there is no clipping happening in the attached test file. I noticed the volume > 1.0 thing too, but the wind sample is quiet enough that the multiplied output never reaches 0dBFS. In my rendered example the sine still reaches 2.0.
Oct 19 2016
Certainly, here you go:
Proof of concept done... I had to touch more stuff than I thought, as it turns out the animation of volume isn't done where I thought it was (anyone know why there are two layers of volume animation? The m_volume.read in AUD_SequenceReader.cpp line 186 does nothing, always gives volume of 1.0!).
Oct 18 2016
f-curves / keyframes / modifiers / all the same evaluation system, at the video frame rate.
Have just tried your sample. What you are hearing is the audio level being changed with each blender frame - it does not evaluate f-curves at the audio sample rate, only at the video frame rate, so if you are changing levels that quickly you will definitely hear zipper noise.
Okay, I've undone all that nonsense I pasted last week and have come up with a solution that seems sensible. However I am happy to be told that I've done everything wrong because to be fair I have no idea what I'm doing.
Am I right in thinking that this is only a problem in preview playback? I've noticed it recently due to cranking the buffer size while CPU was high, but rendered output was fine.
Oct 14 2016
Okay, I'm very sorry for what I've just done to your source code. It's Friday afternoon, I'm about to go home and was hoping to have some kind of proof-of-concept, and this is what I ended up with:
That fix did sort out a lot of the odd stuff that was going on with scene strips, but F-Curves appear to be evaluated completely independently of that system.
Err... I don't know how to create a diff on here, sorry!