The video fifo can be removed, since we have a ring buffer in it's
place. This removes unneeded copy operations and as a positive side
improves overall decoding speed.
Makes 8k60p SW and 4k60p HW decoding possible on my system.
For now the ring buffer is 32 images deep. This limitation will
be removed, once audio and video decoder have their own
packet handling.
Using a ordered ring buffer and a thread pool, the color space
conversion is not multi-threaded based on frames. I tried
to implement slice based threading, but libswscale did produced
highly distorted pictures without obvious reason.
This approach introduces some more "lag" when decoding and skipping,
but shouldn't be affect the user negatively, since movie
watching is not lag sensitive, as long as the A/V is synchronized.
Change default to software decoding.
SW decoding is the most robust and fasted method of decoding right now.
Users should enable hw based decoding if their system requires it
and it's actually beneficial for them.
Fix deadlocks when seeking and decrease RAM usage.
Decrease memory allocation by reusing AVFrames.
This change will activate multi-threading for software based
decoder. Color conversion is still single threaded and also not
being performed by OpenGL.
Since the way ffmpeg inits the HW decoding, we can't 100% valdiate
if a hw decoder will play a file or not. Since we need to know
before calling avcodec_open2() if we want to either multi-thread via
software or HW decode, we will only run single-threaded in case of a
late fallback.
This happens for example in off cases when my AMD vega based graphic
card reports that it could HW decode VP9 video but in reality can't
(which is catched in callback get_format() and after avcodec_open2(().
There is currently no good solution in sight, since we can't
reconfigure the decoding context at that point of time.
Libass is optional again. This build will also compile with
ffmpeg 3.4 again, but HW acceleration is not guaranteed to work,
since it hasn't been tested well enough.
The ffmpeg core not support the usage of HW based video decoders.
Core options to configure the HW decoder to use is provided.
Proper fallback to the SW based decoder is implemented.
Currently the decoder loop in single threaded and is limited by
the color conversion that is done in software.
The frame based threading provided by ffmpeg also currently doesn't
seem to provide any benefits in configuring it.
cores/libretro-imageviewer/image_core.c:75:59: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
static const char* IMAGE_CORE_PREFIX(valid_extensions) = 1+ /* to remove the first |, the alternative is 25 extra lines of ifdef/etc */
~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cores/libretro-imageviewer/image_core.c:75:59: note: use array indexing to silence this warning
1 warning generated.
This fixes a few subtle problems with passing CFLAGS and CXXFLAGS as
environment variables for configure.
First it will now only add these variables to config.mk when they are
actually set. If they are unset then the default optimizations in the
Makefile are set. This avoids passing more than one conflicting
optimization level to the compiler.
Next all CFLAGS are added to CXXFLAGS to avoid issues with forgetting to
set both CFLAGS and CXXFLAGS. This results in the cxx compiler getting
passed several redundant optimization levels when both the CFLAGS and
CXXFLAGS environment variabls are used. Now these uses of CFLAGS in
Makefile.common are set to DEF_FLAGS. This allows adding $(DEF_FLAGS)
to the CXXFLAGS variable without adding redundant flags from CFLAGS.
v2: Update other build files.
Supports multiple capture and output modes with deinterlacing
New dummy mode for testing the core even without a capture device
Ability to display frametimes
alternate_hack mode allows capture cards without alternate capture mode
to capture progressive or interlaced inputs at 16ms rather than 33ms
Nils Hasenbanck