- User Since
- Sep 29 2016, 6:09 PM (196 w, 5 d)
Mar 18 2019
I've been using sequence strips in 2.8, and haven't noticed a difference in framerate between the sequence strip and the scene it came from. I do have a chunky processor though, and some patches applied.
Mar 4 2019
Feb 25 2019
Updated patch to the one supplied by @Richard Antalik (ISS)
Feb 21 2019
Really, KBE / Push & Pan is the thing you do with it, not the effect of ticking this box. It should probably be called "hi-res scaling transform" or something.
Feb 20 2019
Updated to build against 2.8 / current master.
Updated to build against 2.8 / current master.
Updated diff to build against 2.8 / current master
Dec 17 2018
Latest adjustments to suit. If this approach on the UI isn't acceptable I'll try something more complicated, but I thought if the simpler, less-code option is okay I would go with it.
Added SEQ_ prefix to the enums that lacked it; made some defines into enums; changed override rate threshold to use fabsf(); set add movie strip left-hand UI to use vertical alignment so that there is room for the label on the option box for mismatch behaviour.
Dec 16 2018
Oh, it doesn't change the length of the strip - it changes the length of the source scene that is contained within that strip (which is a copy, and currently it only inherits at the point the strip is created). It will never bump the scene strip onto a different channel. This is perhaps poorly worded in my description.
btw @Alberto Mardegan (mardy) I wasn't having a go at you for adding the option, apologies if that was rude. Preserving behaviour of existing files makes sense in a lot of cases, but not here in my opinion :)
Could someone provide a worked example of where this would be a problem, but where that problem would not be experienced when adding the scene a second time? I think it's important that old and new strips of the same scene behave consistently - and if you don't want them to change, all you need to do is simply leave your scene start and end where they are.
Dec 15 2018
Would someone care to review this one also? Thanks!
Moved logic out of rna_scene and into one generic function in sequencer.c
Addressed all review comments from @Brecht Van Lommel (brecht) apart from the one about custom UI layout, for which I would appreciate guidance.
Dec 13 2018
New patch in D4072.
I don't seem to be able to update this diff directly (I suppose that's reasonable) so here's the latest diff. I've taken the liberty of changing the wording a little bit, and had a go at improving the behaviour when you check / uncheck the box in terms of forcing a redraw, but I still can't make it refresh the preview window for the frame that is currently displayed.
Dec 12 2018
@Alberto Mardegan (mardy) Hi, sorry for the big pause! 3 things:
Updated patch since it didn't apply against current master any more.
I think partial frames can wait, I would expect 99% of users of rate control wouldn't need such exact timing control. If someone is happy to merge it, fire away!
Ah, yes that would be impossible with this patch as-is. If all the start / end offsets etc. were made into floats then it would behave as you want with 0.5 in it.
Dec 11 2018
Nov 5 2018
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).
Oct 31 2018
@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.