- User Since
- Oct 18 2011, 11:01 AM (318 w, 3 d)
Sep 17 2017
Just to add:
Sep 12 2017
Sep 11 2017
I'm running Firefox dev branch (56.0b10).
Sep 8 2017
Sep 7 2017
The crux of this seems to be - "it's not a bug because the code works as intended, therefore it's a feature request" vs "the original design specification has a bug".
Sep 6 2017
Some examples drawn in the 2d editor and 3d viewport:
I can't see how this would be considered either a feature or enhancement.
Sep 3 2017
Sep 1 2017
Aug 18 2017
I can confirm this fixes the clamp function in all bevel modes except for 'percent' - in that case the bevel still sometimes stops short.
Jun 15 2017
Jun 6 2017
Jun 4 2017
May 25 2017
May 23 2017
Apr 18 2017
@Sergey Sharybin (sergey) looks like the latest linux builds are fixed.
Apr 17 2017
Confirmed. Removing the line from config.ocio is enough to fix.
Apr 16 2017
"My purpose is to enable a common/ universal audio codec by default e.g. .mp3"
Apr 15 2017
Mar 12 2017
Mar 1 2017
There seems to be two independent clamping events/rules. The 'clamp overlap' option only affects whether new bevel geometry overlaps other new bevel geometry. But even with that disabled, the bevel doesn't normally cross over pre-existing geometry (which seems sensible) - unless you're bevelling a complete edge loop.
Feb 28 2017
Looks like there's no single video format that's compatible with modern browsers...
Nov 29 2016
Is there a plan to fully define all the allowed combinations of containers, video and audio codecs, and their individual parameters? Maybe in some easily editable xml file.
Oct 11 2016
Just to add, I tried the supplied .blend and have got inconsistent results after removing the embedded images. On one attempt, RAM usage didn't decrease for the single channel image. Another attempt seemed to work.
Ah, sorry. Didn't realise the inline image was it.
Can you upload the unpacked png that's causing the problem?
I'm seeing similar behaviour on 2.78 (linux), but only for packed images. Files referenced from disk use less memory as long as they're true single channel. I'm not seeing any memory savings on GPU though - packed or unpacked.
Jun 21 2016
Jun 15 2016
It's now working as expected. Thanks for the fix!
May 7 2016
Apr 22 2016
Apr 2 2016
It's conceivable that Blender could be outputting non-standards compliant video in some way. Might be enough to confuse Windows where VLC and mediainfo interpret the file structure differently.
Mar 27 2016
Mar 26 2016
You haven't mentioned if the rendered video plays fine, but this is looking like a Windows reporting issue. I remember hearing about similar issues with the Windows file manager some time ago.
Mar 25 2016
Does it try and play at 244fps in VLC and other media players?
Mar 24 2016
For what it's worth; I used the supplied .blend, substituted all the media clips with the provided MVI_0023.MP4 and left it to render the full project length. It wasn't enough to reproduce this bug.
Mar 23 2016
Another vote for this being an option with the default set to the long-standing behaviour.
Mar 22 2016
Generating Record Run timecode is enough to fix this.
Mar 21 2016
Sorry, I missed your update while composing mine.
Mar 20 2016
Can you see if it's possible to create a test scene with this clip that triggers the bug first?
Mar 19 2016
You haven't said where the source video came from. Is it from a camcorder, output from another program?
Mar 16 2016
Can you clarify what you mean by working/not working?
Can confirm it's now working. Thanks for the fix :)
Mar 14 2016
It looks like the original video might be missing frames. Converting the MKV directly with ffmpeg (2.8.4) cli gives some useful info - *lots* of PTS/DTS warnings:
After running through some test charts at various sizes, it looks like the horizontal resolution needs to be divisible by 32 to avoid any colour shift.
Mar 11 2016
Unfortunately the patch has introduced some weirdness with the CbCr up-scaling. See T47766
Mar 9 2016
if it helps track down the issue;
Mar 8 2016
Feb 12 2016
Nice work. Much cleaner and easier to scan through.
Nov 6 2015
Sorry, I wasn't sure.
Nov 4 2015
I'm not suggesting just reverting back. It shouldn't be either-or.
Nov 3 2015
Sergey - since the large preview uses neutral light colour, it makes sense for the small previews to reflect this.
This might be related: https://developer.blender.org/T34240
Although it's talking about the large material preview (when set to 'World Sphere' type).
Dec 24 2014
A screenshot of the whole Blender window would help.
Oct 27 2014
aah... and part of the problem is between my chair and keyboard :)
Oct 16 2014
Mar 14 2014
Confirmed here on Linux x86_64. This issue can be tracked back to at least revision b2fdc59 (2013-12-20).