| Age | Commit message (Collapse) | Author |
|---|
|
The MovieSequence and MovieClip classes now have a metadata() function
that exposes the `IDProperty *` holding the video metadata.
Part of: https://developer.blender.org/D2273
Reviewed by: @campbellbarton
|
|
|
|
rBb6ba3c682dd6615e760905572a5bcd69bb46371f since they broke the build.
|
|
|
|
This is an issue with which value to trust: fps vs. tbr. They both cam be
somewhat broken. Currently the idea is:
- If file was saved with FFmpeg AND we are decoding with FFmpeg we trust tbr.
- If we are decoding with Libav we use fps (there does not seem to be tbr in
Libav, unless i'm missing something).
- All other cases we use fps.
Seems to work all good for files from T53857, T54148 and T51153. Ideally we
would need to collect some amount of regression files to make further tweaks
more scientific.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D3083
|
|
Forgot to add that in previous commit, also related to T53003.
|
|
FFMPEG uses int for the numerator, while Blender uses a short. So in
cases people gave weird exotic framerate values and we cannot reduce
enough the numerator, we'd get totally weird values (even negative frame
rates sometimes!)
Now we add checks for short overflow and approximate as best as possible
in that case (error should not matter unless you have shots of at least
several hundreds of hours ;) ).
|
|
It has been deprecated since at least macOS 10.9 and fully removed in 10.12.
I am unsure if we should remove it only in 2.8. But you cannot build blender with it supported when using a modern xcode version anyway so I would tend towards just removing it also for 2.79 if that ever happens.
Reviewers: mont29, dfelinto, juicyfruit, brecht
Reviewed By: mont29, brecht
Subscribers: Blendify, brecht
Maniphest Tasks: T52807
Differential Revision: https://developer.blender.org/D2333
|
|
Affects both "normal" open as a video file and thumbnail generation.
|
|
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
|
|
Seems to be rounding error. Hopefully new code handles the error fixed back in
SVN revision 28901 and still have proper frame number for Hjalti.
What could possibly go wrong here..
|
|
Something weird, seems some buffers _might_ be shared between codec context
and frame, which is quite weird. Could be a bug in FFmpeg or could be wrong
API usage somewhere else..
|
|
Th intention is to make sure we don't free buffers which were not allocated
by FFmpeg.
This is a possible fix for T47806.
|
|
|
|
In fact, some areas in FFmpeg might require alignment up to 32, so now we
make temporary conversion in an aligned frame. We only do this if width is
not aligned to 32.
|
|
Revert "Fix T47724: VSE crops video if horizontal resolution isn't divisible by 8"
This reverts commit 606f6b79eabca236b933dd76e5425162e26ba105.
|
|
This is a bit annoying, but FFmpeg can't deal with unaligned arrays in some
cases. There seems to be an easy workaround with using SWS_ACCURATE_RND flag
which should be harmless since we don't really scaling frames, but only
using sws_scale to change color space.
Additionally, this is what VLC is also using.
|
|
The idea now is to have FFmpeg/OIIO headers listed after
the system ones. This is because FFmpeg/OIIO might define
some constants with the same name as the ones from math.h.
FFmpeg/OIIO has ifdef around defines, but math.h doesn't
check whether constants were already defined or not, which
causes some noisy warnings.
|
|
While it's not something we'll be using for the official release,
it's nice to support new libraries at least on "it compiles" level,
so it's not that many frustrated developers around.
Nexyon, please have a look into Audaspace changes :)
|
|
D1751, remove this library since its quite a specific - only supports an older version of this codec.
Also ffmpeg has added support for recent versions of the codec.
|
|
The idea is to use known number of frames in the stream when possible
instead of trying to deduct it from a stream duration and time base,
which could potentially give some rounding errors.
This, i.e., solves quicktime encoded files from animators to open
just fine in sequencer.
Another report done by the main Nieve guy (aka venomgfx)
|
|
no functional changes
|
|
|
|
We _never_ want this, so better not fail silently.
|
|
|
|
* Allows sound playback for movies
* Allow play-pause with space button
* Allow displaying a position indicator with the I button
|
|
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
|
|
is requested.
|
|
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
Was a regression since avg_frame_rate changes.
Didn't find reliable way to get stream duration which will
work with both FFmpeg and Libav so added some freaking black
magic to distinguish one from another.
|
|
av_close_input_file()
|
|
r_frame_rate is a guessed number defined as "the least common multiple of
all framerates in the stream". It has been deprecated and removed in new
Libav releases.
Use avg_frame_rate instead, which is the average framerate of the
stream.
|
|
|
|
|
|
done/invalid.
|
|
The latest ffmpeg versions include a workaround to deal with a certain
pecularity in Canon DSLR footage: instead of decoding pictures with the
proper resolution of 1920x1080 they decode it with 1920x1088 and add a
black bar at the bottom.
Needless to say, that this screws up things in a lot of areas within blender
(proxy indices, mask animations etc.)
Since all blender versions besides Linux x86 32bit seem still to include
older ffmpeg versions which still contain this bug, this patch adds
a workaround for older versions until we have all versions on all platforms
up to date.
See also: http://git.libav.org/?p=libav.git;a=commit;h=30f515091c323da59c0f1b533703dedca2f4b95d
|
|
Suggestion by Bjeorn Sonnenschein from report #34755.
|
|
- remove unused defines.
- quiet some shadow warnings.
- bevel, ifdef out some asserts that are too common.
- style
|
|
not to confuse things.
|
|
bli_testextensie.patch - from Lawrence D'Oliveiro (ldo)
|
|
Patch makes it possible to compile blender with recent ffmpeg
and libav libraries, mainly by getting rid of deprecated API.
Original patch by Campbell Barton with own modifications to
support compilation with older ffmpeg versions.
This patch could break compatibility of FFV1 videos playing
back in older players, mainly because of alpha support changes.
Preserving compatibility with such players became a headache
and think it's high time to get rid of workarounds here.
|
|
This was a regression in svn rev52718 caused by the fact that we can not
free packet fun until we've finished all manipulation with decoded frame
since frame and packet could share same pointers.
For now restored old behavior of next_packet which seems to be well
tested and better not do bigger refactoring here so close to release.
Memory leak fixed by that revision was fixed by calling av_free_packet
just before avcodec_decode_video2 in cases we're at the end of file.
Tested with valgrind and could not see any memory leaks in ffmpeg
area.
|
|
This fixes a memory leak caused by the last packet on stream EOF not freed.
(Memory leak occurs on ffmpeg heap managed by av_malloc / av_free, so it is
invisible to Blender)
Also: clean up the code a little bit (anim->next_packet was never really used,
so could be moved into a local variable)
|
|
|
|
|
|
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
|
|
This fixes [#32399] VSE doesn't show last 3 frames of Quicktime movie.
Some decoders store frames internally until EOF.
So one has to feed the decoding engine with empty packets after EOF
until all frames could be extracted properly.
|
