* 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
Implementation of cache for general movie-related areas
such as sequencer and clip editor (in the future)
Some changes in limiter were necessary:
- Limiter counted mapped memory twice when was checking how many memory is used.
- It was using "global" memory usage not memory usage by cached elements.
It will cause big problems when there's large mesh or plenty of undo steps are
in memory nothing would be cached in sequencer.
- To solve this problem introduced "callback" to measure cached element size.
It could be not very accurate in general, but it works well for image buffers.
And if this callback isn't set old-school memory usage check would be used.
- The whole cache used to get freed when memory limit exceeded, now it'll drop only
as much elements as necessary to reduce memory usage.
Seqcache is switched to use this new cache code.
It helped to make things works better for some movies but it
didn't help proxies to work properly. Correct fix seems a bit larger
and better not be made atm, so to keep behavior of proxies and
original movie consistent keep resolution behaves like it was before
recent changes,
- Display running job template in all sequencer modes
It was displayed only for sequencer mode without preview.
- Fixed proxy rebuild progress indicator
It was alsways zero because of incorrect rounding.
- Fixed timecode saving on windows (and probably some other platforms)
It was caused by incorrect opening file for writting -- it should
be opened in binary format "wb". This error caused incorrect
movie duration detection on windows.
- Fixed movie resolution detection for some movies.
In file attached to report, Blender detected resolution 1920x1088
instead of 1920x1080. Not sure if this fix is correct or it's
issue in FFmpeg, but it's something what mplayer using: store
width/height before running avcodec_open().
- Fixed frame number calculation when building timecodes.
It was rounding error caused some frames be positioned incorrect
in several cases (that each 6th frame rendered as next frame
from report).
