This works better for scrubbing the playhead no doubt, but this is affected *everything*. Moving curve points outside the view in the Graph Editor, for example doesn't work like before - you can't continue outside of the Y bounds.
Fixed mistake for macOS version.
@George Vogiatzis (Gvgeo) Here building fails with this patch. Does it apply to master?
would be awesome if it would also include in text form on what frame the clip ends now.
Sun, May 19
Thank you for your answer ! :)
I like this idea, but this task is more complex than you may think it is.
Sat, May 18
There is a function where selecting: "Strip > Set Render Size" automatically populates the correct resolution. It would sure be great to have "Set Render Size" also automatically select the "correct" preset too so that the aspect ratio is made accurate to the source.
Fri, May 17
DAR is the final displayed aspect ratio, FAR is the frame aspect ratio, and PAR is the pixel aspect ratio.
DAR = FAR * PAR
DAR = 720:576 * 16:15 DAR = 720 / 576 * 16 / 15 DAR = 1.33...
Trouble is that DVD material both needs a PAR and a DAR correction to look correct on a computer:
This doesn't make sense. They are practically the same. If you have DAR, you know how to display the video. PAR is used to find DAR.
https://en.m.wikipedia.org/wiki/Pixel_aspect_ratio Here says exactly that the video's DAR = SAR × PAR.
SAR is from video's resolution. DAR is in the metadata.
Trouble is that DVD material both needs a PAR and a DAR correction to look correct om a computer:
Thu, May 16
yes, that’s basically it. But I would advise you wait a bit here, going modal raised some annoying issue (T64660 and T64693 are actually same fundamental problem), that needs to be addressed before generalizing that approach.
I think that's correct - @Bastien Montagne (mont29) coded this so should be able to confirm.
Added changes for other systems.
Used bool to disable Y axis.
Added X wrap for headers.
You should be able to check the Node editor which I think does it.
@William Reynish (billreynish)
Haven't got too far with this today, but I have noticed, that when you have effects applied on top of a strip, move operator will select whole chain.
This makes it hard to actually select a strip in such case.
Wed, May 15
This code only includes the changes for Windows, it will break on macOS and Linux.
As for the cache, I guess it really should not be discarded if the clip was never actually moved?
- This breaks continuous grab in all directions here, not just Y
- This breaks continuous grab for moving keyframes, not just scrubbing
is it OK to change sequence move operator to LMB + tweak?
I guess "relying on the playback process to recognize and stretch it" is kind of expected, like as Blender (mostly) sets the the correct framerate on the first video that gets added.
Not exactly sure how much should change.
For example there are 3 more calls to WM_cursor_grab_enable with wrap bool instead of int now.
Ofc it is possible to set Y bounds -/+ 10000 instead of making all of these changes.
@George Vogiatzis (Gvgeo) thanks for samples, I couldn't find anything to experiment with.
Tue, May 14
I am also able to get the same result when using viewport rendering.
I was about to create this task.
Mon, May 13
Sun, May 12
Sat, May 11
Seems like eevee issue. That's outside of my powers.
Please don't open 4 year old reports like this, but create a new one.
Good, This error is still in blender 2.79 as in blender 2.8.
I have been using masks in blender for a long time and this problem always existed.
At first I thought it was a problem with the mp4. But this happens in sequences of png and exr images as well.
Is there any hope of having the video auto-packing removed again so it behaves like 2.79? Or will this only be made into a warning popup? I really miss being able to actually use the auto-pack feature...