- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
added some missing functions too - which are not used yep but should be there for api completeness.
* CDDM_set_mloop
* CDDM_set_mpoly
* BLI_mempool_count
Split proxy build operator into three parts:
- Prepare context (IMB_anim_index_rebuild_context) which prepares all
needed data and stores it in an anonymous structure used by specific
builder lately.
- Build proxies/timecodes into temporary files (IMB_anim_index_rebuild)
This function will build all selected proxies/timecodes into a temporary
files so old proxies will be still available during building.
- Finish building proxies (IMB_anim_index_rebuild_finish) which copies
temporary files over old proxies filed and releases all resources used
by a context.
Context creation and finishing building happens in a main thread so
it's easy and safe to close all opened handles of proxies files and
refresh cache after rebuilding is finished.
This should finally fix#30315: Temporary proxy files are not erased and old proxys are not updated if the proxy is built more then once (windows)
Two issues are fixed here:
- On windows rename() doesn't actually renames file if destination file is already exist.
Solved by ulinking previously built proxy/timecode.
- IMB_TC_MAX_SLOT was set to incorrect value leading to record run timecode calculating
several times.
which made it using default quality settings which are really bad for camera
tracking (and perhaps for CSE too).
haven't found Jpeg quality setting for FFmpeg which will behave in the same way
as quality setting for image sequence, but seems that mapping image quality
from 1..100 UI range to 31..1 range of qmin/qmax gives expected result.
Issue is caused by scaling for power of 2 dimensions and mipmapping that happens through GLU. It looks like the library cannot handle float colour values above 1.0 correctly. Since we are close to release I will just clamp the srgb result for now even though it will result in a small performance loss for 16 bit textures only.
I tried a few things before that, glGenerateMipmaps + no scaling (supported for 2.0 GL hardware and up), or using our own scaling instead of glu among them which worked very nicely and gave a speedup too. However, since we are close to release and there may be issues with GPU mipmap generation, see:
http://www.gamedev.net/topic/495747-another-glgeneratemipmap-question/
(old discussion but better be sure than sorry)
I went for the most compatible solution. Maybe after release this can be tested if other devs agree.
* Accelerated sRGB <=> linear conversion using lookup table, this can speed up
loading of images in the compositor and simple renders quite a bit.
* Dithering now uses the Floyd-Steinberg algorithm. Previously it would simply
randomize each pixel slightly, adding noise, now that should be reduced.
Patch #29309 by David M.
For premultiplied alpha images, this makes any color space conversion for the image
or render output work on color without alpha multiplied in.
This is typically useful to avoid fringing when the image was or will be composited
over a light background. If the image will be composited over a black background on
the other hand, leaving this option off will give correct results.
In an ideal world, there should never be any color space conversion on images with
alpha, since it's undefined what to do then, but in practice it's useful to have
this option.
Patch by Troy Sobotka, with changes by me.
byte => float, float => float, byte => byte conversions with profile, dither
and predivide. Previously code for this was spread out too much.
There should be no functional changes, this is so the predivide/table/dither
patches can work correctly.
This commit adds new timecode type which counts frames in gapless mode (counting
actually decoded frames instead of using pts to find frame number) which might
resolve issues with files which have got broken or incorrect base time value stored
in the header.
This timecode allows to deal with movies from #29388: Abnormal frame length on MP4 files
- setting the color channels on save as would ignore the channel - BW/RGB/RGBA setting.
now its used when available but still need to hide BW for formats blender can only write as color.
This fixed two issues:
* RAW DV-seeking has to be done using DTS. Sounds silly, but ffmpeg
tracks internal state in RAW DV format decoder and runs mad, if
we seek by byte. Don't know, why I haven't noticed that, when I
added it.
* real fix(tm) for #29295
problem was: we did AVFrame read ahead, and the pattern
read_frame -> decode -> read_frame -> do color conversion of first frame
works everywhere but RAW RGB-files which do some pointer shuffling
within ffmpeg to save a memcpy...
I removed read ahead completely, since it didn't work like originally
intented. Might come back later, but the original purpose (making
resyncing easier if we are completely lost in stream) it never
fullfilled.
Unfortunately, error was caused by own attempt to deal with some kind of broken
videos when was investigating crashes in sequencer. Issue discovered that time
was related on values stored in timecode index and using them as signed data type
later.
Trying to use unsigned value here leads to signed/unsigned check failures.
Prefer just to pre-process that kind of videos i've been trying to deal with
rather than making more global changes during BCON3.
Crash was caused by several conditions:
- Frame which failed to decode tried to be converted to RGB colorspace
and some filters like deinterlacing used to be applied as well
(it's avscale stuff sws_scale where crash happened).
- In some cases it happened reading of freed memory when calling
sws_scale function. Looks like it happened because of freeing
packet on which decoding of frame finished and reading next packet.
Solved this two issues by making YUV->RGB conversion as soon as
frame was decoded in ffmpeg_decode_video_frame (such postprocessing
used to happen in callee of this function ffmpeg_fetchibuf), so now
sws_scale would be called before freeing packet on which decoding of
frame finished and it wouldn't be called in cases when decoding of
frame failed.
If decoding of frame failed, it'll be black ibuf returned to the sequencer.
- Fixed inconsistent data type used for pts number in ffmpeg_fetchibuf
and stored in timecode structure. Not really issue for "correct" movie files,
but probably can help for "broken" one
