This should render vdpau safe to enable with profiles not supported
by the hardware (such as high depth or high chroma). Software fallback
will be used automatically.
Handle better cases when we don't have input frame size
same as encoder input frame size. Also gather input samples
untill we get full frame fillet and not just next block.
Set length based on used samples and not frame_size
Also try to make memory calculations cleaner so they don't
overshoot and write stuff all over.
Refs #8265
This is mostly useful if the hw accelerator cannot handle the stream.
The software decoder fallback will then use frame multithreading if it
supports it.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Use parenthesis around the expression returned in LIBAVUTIL_VERSION_CHECK,
to avoid problems that can arise in future with some ways macro may be used.
Same as what has been done in LIBAVCODEC_VERSION_CHECK.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Make fails when using FFmpeg libavcodec version newer than checked by
LIBAVCODEC_VERSION_CHECK, because of redeclaration of many enumerators,
that are unnecessary with newer version of libavcodec library.
It is due to missing parenthesis in macro definition that are making
it wrong.
Probably same with libav libavcodec library, too.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Subtitle is the adjective describing what kind of text. So "subtitle text" is an adjective phrase describing what kind of encoding.
For example, we don't listen to "audios tracks", program "videos codecs", or open "playlists files". Therefore, use the correct form of the word subtitle for the context.
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>
Don't use the display size, which has taken the pixel aspect
ratio into account.
This still doesn't handle actually displaying anything with
non-square pixels correctly, though.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes cases where the OMX decoder previously errored out,
when decoding videos with odd resolutions.
Signed-off-by: Martin Storsjö <martin@martin.st>
On the raspberry pi, the stride is filled in with the right value,
while the slice height is left untouched (and needs to be rounded
up to a multiple of 16).
This fixes rendering of more uncommon resolutions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes decoding of higher resolution content on the raspberry
pi, where the decoder defaults to 80 KB input buffers and doesn't
react if trying to enlarge them in
ImplementationSpecificWorkarounds().
Signed-off-by: Martin Storsjö <martin@martin.st>
This changes how some structs are laid out.
Most of OMX API implementation on the raspberry pi runs on the
VideoCore processor and not on the normal ARM thar runs the
userland. Some OMX structs are passed over to this processor as
whole blocks, so the OMX ABI used in the userland is tied to be the
same as the one used by the VideoCore firmware.
Signed-off-by: Martin Storsjö <martin@martin.st>
The broadcom OMX IL core requires this in order to respond to
requests.
In principle, this shouldn't probably break other OMX implementations,
unless they are picky about it in the same way, requiring version
1.1.1, but still keeping it behind ifdefs just in case.
Signed-off-by: Martin Storsjö <martin@martin.st>
The host library is intentionally not unloaded, since it starts
background threads when initialized, and the deinit function does
not stop the threads. Therefore, this library cannot be unloaded
once loaded and initialized.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is kept under modules/codes/omxil due to sharing much code
with the omxil codec.
This is only tested with the OMX.broadcom.video_render component
on the Raspberry Pi so far, which in itself doesn't advertise any
roles at all, so this could possibly use the "iv_renderer.yuv.overlay"
role instead of plan "iv_renderer".
But it should be possible to generalize this further and adapt it to
any OMX IL video renderer component.
Signed-off-by: Martin Storsjö <martin@martin.st>
The point of the omx core management is to try to load and init the
OMX core once, even if there's multiple e.g. decoder instances. The
reason for this is that there are OMX cores where the deinit function
will deinitialize the whole core on the first deinit call, even if
init has been called twice.
If this file is to be built as part of multiple separate shared
plugins, each of the plugins will initialize the OMX core separately,
which could cause issues with such OMX cores.
Since the second plugin that uses the OMX core, an OMX vout plugin,
isn't used automatically, and the only OMX implementation it currently
is tested to actually work with (the Broadcom OMX core on Raspberry
Pi) doesn't have issues with being uninitialized multiple times,
there's no need to jump through hoops to fix this theoretical issue
right now though.
For reference, if we really want to make sure the omx core is loaded
and initialized only once, the plugins need to be loaded with
RTLD_GLOBAL and all the variables in omxil_core.c need to be marked
with __attribute__ ((visibility ("default"))). But that's generally
not an option, and shouldn't be necessary right now at least.
Signed-off-by: Martin Storsjö <martin@martin.st>
Christoph Miebach
Rafaël Carré
Rémi Denis-Courmont
Felix Paul Kühne
Ilkka Ollakka
Jean-Baptiste Kempf
Janne Grunau
Zoran Turalija
Edward Wang
Martin Storsjö