| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D15376
|
|
|
|
|
|
We didn't properly free allocated ffmpeg data structures.
|
|
Follow naming from T85728.
|
|
|
|
|
|
In ffmpeg 5.0, several variables were made const to try to prevent bad API usage.
Removed some dead code that wasn't used anymore as well.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D14063
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
Function `IMB_indexer_get_seek_pos()` can return non 0 seek position for
frame index 0. This causes seeking to incorrect GOP and scanning ends
with failiure.
Hard-code first frame index seek position to 0.
Differential Revision: https://developer.blender.org/D13974
|
|
|
|
This change applies only for automatic proxy building, when strip
is added to timeline. Manual building process is not affected.
Don't build proxy file if movie is already fast enough to seek.
To determine seek performance, check if whole GOP can be decoded
in 100 milliseconds.
To consider some variation in GOP size, large number of packets are
read, assuming that each packet will produce 1 frame. While this is not
technically correct, it does give quite accurate estimate of maximum GOP
size.
This test will ensure consistent performance on wide array of machines.
Check should be done in order of few milliseconds.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11671
|
|
Movies with variable frame rate can cause mismatch of displayed frame
when proxies are used. Since proxies are not used for rendering, this
means, that output may be different than expected. This problem can be
avoided when timecodes are used.
Set used timecode to Record Run. Timecodes are built with proxies at
the same time, therefore if proxies are built and used this will
resolve possible mismatch of output.
Record run is chosen, because it will show frames based on time they
were encoded by encoder and should match behavior as if movie was
played back at normal speed. This change is done only for new strips
in order to not overwrite user defined settings.
Other minor changes:
- When proxies are enabled, size 25% is no longer set by default. It was mostly annoying anyway.
- Silence warning when timecode file is not present. This was introduced in 4adbe31e2fc98f982aed3d97505513750ec348d4.
Previously use of timecodes was hard-coded in sequencer and this error would spam console if timecodes would be
enabled by default and proxies would be never built.
ref: T95093
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13905
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
The seek pts was not correctly calculated.
In addition to that we were not seeking in the video pts time base.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11921
|
|
This shows the text as part of the assertion message.
|
|
|
|
Because of the added sanity checks in rB14508ef100c9 (D11492), seeking
in proxies would not work correctly any more. This is because it wasn't
working as intended before, but in most cases this wouldn't be
noticeable. However now when the sanity checks are tripped it is very
noticeable that something is wrong
The indexer tried to use dts values for time stamps when we used pts in
our decode functions to get the time positions. This would make it
start in the wrong GOP frames when searching. Now that we enforce no
crossing of GOP frames when decoding after seek, this would lead to
issues.
Now we correctly use pts (or dts if pts is not available) and thus we
don't have any seeking issues because of time stamp format missmatch.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11561
|
|
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D11567
|
|
This change was prompted by D6408 which moves thumbnail extraction into
a shared function that happens use these endian defines but only links
blenlib.
There is no need for these defines to be associated with globals
so move into their own header.
|
|
We need to unref the packet to tell ffmpeg it is ok to free it after
use.
|
|
|
|
Changes in rBce649c73446e, affected established proxy codec preset.
Presets were not working and all presets were similar to `veryfast`.
Tunes are now working too, so `fastdecode` tune can be used. I have
measured little improvement, but I tested this only on 2 machines and
I have been informed that `fastdecode` tune does influence decoding
performance for some users.
Change preset from `slow` to `veryfast` and add tune `fastdecode`
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11454
|
|
The issue was two fold. We didn't properly:
1. Initialize the codec default values which would lead to VLC
complaining because of garbage/wrong codec settings.
2.Calculate the time base for the video. FFmpeg would happily accept
this but VLC seems to assume the time base value is at least somewhat
correct and couldn't properly display the frames as the internal time
base was huge. We are talking about 90k ticks (tbn) for one second of
video!
This patch initializes all codecs to use their default values and fixes
the time base calculation so it follows the guidelines from ffmpeg.
Reviewed By: Sergey, Richard Antalik
Differential Revision: http://developer.blender.org/D11426
|
|
Before the FFmpeg commit: github.com/FFmpeg/FFmpeg/commit/1c0885334dda9ee8652e60c586fa2e3674056586
FFmpeg would use deprecated variables to calculate the video fps.
We don't use these deprecated variables anymore, so ensure that the
duration is correct in ffmpeg versions without this fix.
Reviewed By: Sergey, Richard Antalik
Differential Revision: http://developer.blender.org/D11417
|
|
We didn't initialize the scaled proxy frame properly.
This would lead to issues in ffmpeg 4.4 as they are more strict that the API is properly used.
Now we initialize the size and format of the frame.
|
|
There need to be more cleanup for ffmpeg 4.5 (ffmpeg master branch).
However this now compiles on ffmpeg 4.4 without and deprication
warnings.
Reviewed By: Sergey, Richard Antalik
Differential Revision: http://developer.blender.org/D10338
|
|
GOP size and quality are adjusted for h264 codec.
These new values are based on result of benchmark on 9 random files:
https://docs.google.com/spreadsheets/d/1nOyUGjoVWUyhQ2y2lAd8VtFfyaY1wQNGj1krCCNbk7Y/edit?usp=sharing
Reducing quality to 50 reduces proxy filesize by about 2x on average
and has no significant impact on decoding performance.
Increasing GOP size from 2 to 10 also reduces proxy filesize 2x-3x
while scrubbing is only about 8% slower. It is still around 100FPS
with 1920x1080 media.
This is unfortunately about 50% slower than MJPEG, but this can be
improved with `fastdecode` tune applied to libx264 encoder
Quite surprisingly h264 codec presets had little influence on proxy
building performance as well as proxy filesize. So far it looks that
FFmpeg does initialize encoder in different way then Blender.
This applies mot only for presets but for tune and profile libx264
setting.
Once this issue is resolved, performance of proxies may be optimized
further.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D10897
|
|
Generalize threading settings in proxy building and use them for encoding
and decoding in general. Check codec capabilities, prefer FF_THREAD_FRAME
threading over FF_THREAD_SLICE and automatic thread count over setting it
explicitly.
ffmpeg-codecs man page suggests that threads option is global and used by
codecs, that supports this option. Form some tests I have done, it seems that
`av_dict_set_int(&codec_opts, "threads", BLI_system_thread_count(), 0)`
has same effect as
```
pCodecCtx->thread_count = BLI_system_thread_count();
pCodecCtx->thread_type = FF_THREAD_FRAME;
```
Looking at `ff_frame_thread_encoder_init()` code, these cases are not
equivalent. It is probably safer to leave threading setup on libavcodec than
setting up each codec threading individually.
From what I have read all over the internet, frame multithreading should be
faster than slice multithreading. Slice multithreading is mainly used for low
latency streaming.
When running Blender with --debug-ffmpeg it complains about
`pCodecCtx->thread_count = BLI_system_thread_count()` that using thread count
above 16 is not recommended. Using too many threads can negatively affect image
quality, but I am not sure if this is the case for decoding as well - see
https://streaminglearningcenter.com/blogs/ffmpeg-command-threads-how-it-affects-quality-and-performance.html
This is fine for proxies but may be undesirable for final renders.
Number of threads is limited by image size, because of size of motion vectors,
so if it is possible let libavcodec determine optimal thread count.
Performance difference:
Proxy building: None
Playback speed: 2x better on 1920x1080 sample h264 file
Scrubbing: Hard to quantify, but it's much more responsive
Rendering speed: None on 1920x1080 sample h264 file, there is improvement with codecs that do support FF_THREAD_FRAME for encoding like MPNG
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D10791
|
|
|
|
Proxy coded has been changed to h264. Error code is more generic now.
|
|
Use h264 codec for output. This codec produces smaller files, can be
multithreaded and decodes even faster than MJPEG.
Quality setting 0-100 corresponds to "Lowest Quality" to
"Perceptually Lossless" in Blender's h264 encoding presets.
All available cores are used for decoding.
Same goes for decoding but only for codecs that supports this
(h264, vp9 seems to support this option out of th box as well).
Other decoders can probably be optimized in similar way, but threaded
encoding provides significant boost already.
I have tested variety of codecs, and all were transcoded properly.
Reviewed By: sergey, fsiddi
Differential Revision: https://developer.blender.org/D10731
|
|
|
|
Following code from D8627 this patch corrects multi threaded processing
of proxies, where a 60 sec proxy generation drops to 35 sec.
Differential Revision: https://developer.blender.org/D8659
|
|
Without this, additional items could be added in the future
which wouldn't be included in the check.
Move the check out of the loop since this is such an unlikely
situation that checking every iteration isn't needed.
Also remove redundant casts.
|
|
|
|
Handle return value of `fread()` by printing an error and closing the
file when it cannot be read from. Not only is error handing a good idea,
it also prevents GCC from warning that the return value of `fread()`
should not be ignored:
```
.../blender/source/blender/imbuf/intern/indexer.c: In function ‘IMB_indexer_open’:
.../blender/source/blender/imbuf/intern/indexer.c:201:5: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
201 | fread(&idx->entries[i].frameno, sizeof(int), 1, fp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../blender/source/blender/imbuf/intern/indexer.c:202:5: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
202 | fread(&idx->entries[i].seek_pos, sizeof(unsigned long long), 1, fp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../blender/source/blender/imbuf/intern/indexer.c:203:5: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
203 | fread(&idx->entries[i].seek_pos_dts, sizeof(unsigned long long), 1, fp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../blender/source/blender/imbuf/intern/indexer.c:204:5: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
204 | fread(&idx->entries[i].pts, sizeof(unsigned long long), 1, fp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Differential Revision: https://developer.blender.org/D9916
Reviewed by: campbellbarton
|
|
|
|
Height and width of video proxies was limited to multiples of 8 with
comment "JPEG requires this".
I could not find any resource that would confirm this to be the case
with FFMPEG and MJPEG codec.
I have looked in:
https://ffmpeg.org/ffmpeg-all.html
https://ffmpeg.org/ffmpeg-formats.html
https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html
Reviewed By: ISS, sergey, sybren
Differential Revision: https://developer.blender.org/D6507
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/imbuf` module.
No functional changes.
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
|
|
To prepare for D6811 small changes were needed.
we can no longer undefine near/far since the windows
headers use those extensively.
some of the imbuf files need to include the windows
headers explicitly to make sure it builds.
|
|
Skip building proxy if directory can not be created.
Crash happens, when setting custom dir to location of source file itself.
This results in attempt to create directory with the same name as source file.
Differential Revision: https://developer.blender.org/D6148
Reviewed By: sergey
|
|
This was introduced in FFmpeg lavf 55.1.100 in 2013. For systems that are
still on LibAV or older FFmpeg there is a fallback implementation that
performs the same guess as we did before in `av_get_r_frame_rate_compat()`.
|
|
When the result isn't used, prefer post increment/decrement
(already used nearly everywhere in Blender).
|
|
Automated using clang-tidy.
|
|
|
|
|
