We don't need to know it's a pointer and can save 2 characters.
No functional changes. This is simply renaming "dec->p_fmt_in",
"decoder->p_fmt_in", "dec.p_fmt_in" and "packetizer->p_fmt_in"
There were two purposes to this as a better alternative to XVideo:
- video surfaces pass-through in GPU in case of hardware decoding,
- scaled SPU blending in both software and hardware decoding cases.
Both functions are now supported with higher priority by the OpenGL
video output. Also the software case no longer works at all anyway.
If the va module succeed to open but is identified as unusable before the end of
FFmpeg getFormat callback, the module may have to do some cleanups in the
AVCodecContext.
the close callback will be called with a NULL AVCodecContext outside the
getFormat callback as the AVCodecContext ownership is transferred to FFmpeg
vd->fmt is the format the display is requesting to receive. On open it's set to
the same as vd->source for convenience. But it might as well not set be at all
before Open has finished.
So far the video can only be fit within the window. This adds other
modes for fitting to the larger dimension, only to the width or only to
the height. These new modes in effect compute the scale/zoom
differently, potentially causing the video to be cropped.
This puts all the video size and placement properties back together as
vout_display_cfg_t originally was before other parameters were added.
No functional changes.
If the input format is not some type of VDPAU YUV, then the output
format should not be VDPAU RGB, so this situation should never happen.
Nowadays the OpenGL or Vulkan display can handle YUV pictures nicely,
so there is anyway not much point left in using the VDPAU mixer without
the VDPAU decoder.
All interop modules reused the util function opengl_interop_init()
(written for the software interop) to initialize the textures properties
from the chroma.
However, the actual texture format may not always be deduced from the
chroma: only the interop implementations have the full knowledge of the
texture details.
Therefore, initialize texture properties directly from each interop
implementation.
Fixes#26735Fixes#26769
Once the sequence is fully parsed we can tell the profile. The return value of
HandleVideoSequence() is how many pictures the decoder should use internally.
p_format->min_num_decode_surfaces contains the minimum for that value.
Steve Lhomme
Tristan Matthews
Maxim Romanov
Rémi Denis-Courmont
Pierre Lamot
Francois Cartegnie
Romain Vimont