"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
When starting to play back a movie strip, there was a "oh, let's figure out if
this is a video file?" check, immediately followed by "let's initialize the
machinery to decode a video file". The first one is kinda redundant, since if
it will happen to not be a video file, the latter check will nicely fail.
Addressed that by removing (seemingly unused at all?) functionality from
`ImBufAnim`, now it is only used for video file playback. Details:
- It looks like `ImBufAnim` is only ever used to play back "video files", so
remove all the other modes of operation from it ("image sequence").
- Which makes `ImBufAnim::curtype` be not needed, it only needs to store state
of whether it's initialized already.
- Which means there's no need to call `imb_get_anim_type` (which does very
costly `isffmpeg`) when starting to play ImBufAnim.
- Remove some other variables from `ImBufAnim` that were just flat out unused.
In Gold previs playback between 1:41-1:55, on Windows/Ryzen5950X:
- Slowest 3 frames went from 276, 195, 168ms -> 222, 174, 147ms (saves 20+ ms
per frame). All of these frames are camera cuts where multiple new video
clips start playing.
- In the whole playback, total amount of time taken by `imb_get_anim_type`:
234ms -> zero! Since that is no longer used.
- There are still stalls when starting to play a movie clip, and that is
actually initializing ffmpeg things. But now at least right before
"initialize ffmpeg" there's no additional redundant work.
Pull Request: https://projects.blender.org/blender/blender/pulls/118503
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Fix several issues found while investigating missing browser thumbnails.
TIFF, PSD, and PNG now use their old file check code. This is due to
OIIO not having an early-out check within `.open`. Calling `.open`
required a large portion of the file to be available (more than 8192
bytes). The code here can be removed in the future if/when a new API is
available which alleviates this problem.
PSD files often carry along a large blob of ICCProfile metadata.
Attempting to roundtrip this metadata when we cache the thumbnail to
.png was leading to problems. We suppress this metadata now as ICC
profiles are not supported in general and are quite large.
Lastly, even after the mentioned new API is available, OIIO will want to
validate the full header of some file formats. DPX is the largest at a
full 2048 bytes so we must have this as our minimum now too. OS's should
be servicing this read call just as efficiently as when using 64. I
could spot no performance difference here at least.
This was missed during development because Blender will cache thumbnails
into a special .thumbnails directory and the images I was using to test
had already been cached there.
Pull Request: https://projects.blender.org/blender/blender/pulls/107515
