- each class is now responsible to free whatever it allocates
- all tests passed on my machine with ffmpeg 3.2
- Clip is now more careful about freeing a reader if it allocated it as well
* Limit max size of preview to the timeline size (this renders very small profiles correctly)
* Fixing CRF quality setting to allow "low" quality without breaking
* Integration of libresvg SVG library (optional during build)
* Major refactor of max_width and max_height for preview optimization
* Fixed many bugs related to preview resizing, with regards to cached frames
* Updating gitlab CI to find RESVGDIR correctly for windows, and adding svgz support
* Updating cmake findresvg module to search for windows locations first, to prevent an issue on our windows builders and updating some CMake output.
* Removing folder path from resvg header, since it could be installed in different named folders. This is an attempt to fix Windows include issues.
* Making call to AV_FREE_FRAME conditional for non windows systems (because it crashes on Windows for seemingly no reason). Needs more investigation.
* FFmpeg4 support. Compile warnings fixes. Credit goes to many people, including ferdnyc, peterM, and other awesome folks!
* Adding environment checking to enable/disable omp taskwait after each video/audio frame is processed. This is experimental for some users with crashes.
* Moving `omp taskwait` to after the ProcessVideoPacket() method, since that is the only place it is useful.
* Fixing crashes on missing Clip source file, and changing FFmpeg scaling algorthm from SWS_BILINEAR to SWS_LANCZOS (for higher quality scaling)
* Update FindFFmpeg.cmake module, and updating build script. Also enabling debug builds.
* Updating experimental travis build script
* Fixed unit test for newer version of FFmpeg (audio resampling)
* Experimental travis multiple jobs
* Adding OMP schedule hint (thanks PeterM), which prevents crashes in some circumstances.
a scheduler it thinks is best which can be dynamic or guided. Both
sometimes let other threads continue before the block is finished.
That will crash the program with high thread counts and a cache
that is not large enough to hold old enough frames, which leads
to a crash when in some cases like transitions two different
frames are used although one is no longer in the cache.
The static scheduler always waits until the block is finished
before enabling other threads.
