This fix makes sure that we don't de-allocate the video buffer before
while the decoding thread is still working. We also don't throw
an misleading error when the decoding threads flushed the buffers
on seeking.
The logic for when to consider to decode a buffered packet did
had used a "magic number" when considering when the current packet
should be decoded when compared to the reference packet.
This change uses the media fps so that we never "overshoot" our target
and don't need to rely on a "magic number".
Simply use two packet_buffers that are double-linked lists of
AVPacket structs. This way we can control which packets to feed
to the decoders at the right time.
This solves the playback problem with the MP4 files.
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.
