Currently we check AV_FRAME_DATA_DISPLAYMATRIX for its rotation factor
but not for its flip factor, which could happen with some input files.
This commit adds and autovflip filter, which is applied before the
autorotate filter to flip vertically before rotating. It also changes
the displaymatrix reading code to output to mp_image->params.vflip so
it can be autoinserted as necessary.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
a3823ce0e0 made this request a special
case because of all the threading considerations. Unfortunately, the
implementation made it so that VDCTRL_GET_HWDEC always would return
CONTROL_UNKNOWN when using mp_decoder_wrapper_control. This didn't
matter because VDCTRL_GET_HWDEC in vd_lavc would always succeed, but in
reality it shouldn't. It takes some time before we actually know what
the hwdec is and if you query during that time, you'll could get some
bogus value (e.g. during hwdec auto probing). So fix that by returning
false in vd_lavc if hwdec_notified isn't there yet and adjust the
wrapper control logic to take this into account.
This adds --video-aspect-method=ignore to replace --video-aspect-override=0.
--video-aspect-override=0 and --video-aspect-override=-1 will no longer be
handled specially. For compatibility, 0 is mapped to always use ignore
and -1 is always mapped to always use container.
"no" is now the replacement for --video-aspect-override=-1, which is
internally remapped to -2 to avoid using a deprecated value.
This is poorly implemented and will break existing scripts which set
the value directly with double without a string value, like
mp.set_property_native, or if the value is set with add/multiply commands.
Revert this until a better solution is found.
This reverts commit cb91de2a34.
Setting this to M_RANGE(-1, 10) meant that you could pass fractional
negative values without it being an error. This is, of course, nonsense.
-1 is the only special negative value with a meaning. Error out if we
get anything else by doing some additional parsing before we send it off
to parse_double which will then restrict the range to 0, 10 with these
changes. Note that this approach requires defval to be there which is
not the most extensible thing in the world. But there's literally only
two OPT_ASPECT type options out of the hundreds we have so not a big
deal. Ideally, this type should be OPT_CHOICE but with underlying
doubles but that's too much effort to implement cleanly.
This update introduces a demux_packet_pool, allowing for the reuse of
previously allocated packets when needed.
sizeof(AVPacket) is not a part of the lavc public ABI, which prevents us
to allocate memory in larger blocks. However, we can substantially
decrease the amount of alloc/free operations during playback by reusing
both mpv's demux_packet and AVPacket.
This adjustment addresses the root cause of issue #12076, which,
although resolved upstream, did not fully tackle the persistent problem
of allocating small blocks of aligned memory. This issue largely stems
from the FFmpeg design of the AVPacket API. After this change memory
will no longer be allocated once cache limits is reached.
The demux_packet_pool is shared as a global pool of packets for a given
MPContext.
This change significantly speeds up the demuxer deinitialization,
benefiting file switching scenarios, especially when a large demuxer
cache is used.
See: #12294
See: #12563
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Uploading all available formats has proven to be problematic because
more unusual ones can crash the driver, even when no upload is
necessary. Check the upload only if needed to avoid issues with broken
drivers.
This also might speedup the init process.
Fixes: #14956Fixes: #15030
There was mixup between upload formats and device formats. Instead of
filtering the device formats with VO constraints, upload formats were
affected. It was working, because most of the time the upload is using
the same formats. But if there is conversion on the fly needed we were
filtering wrong list of formats. Upload formats are those that can be
used to upload to the given hardware frame, conversion during upload are
allowed if possible. The main fix is in select_format() which were using
device formats as input, instead of ouptut formats and upload formats as
output, instead of input.
With the previous change, it is possible that the mp_hwdec_ctx contains
a list of known supported hwuploads. Take this into account when adding
to the p->fmts list. We want to be sure to select only something that is
actually possible to use. If the hwdec does not implement
supported_hwupload_formats, then all are assumed to work.
It is possible for a format to be supported by hardware but not by
av_hwframe_transfer for uploading. This breaks the best upload format
selection. We first select the hardware input format and then choose the
best software format that can be uploaded. In some cases, this may
result in a format that is not uploadable at all, leading to an error.
To solve this, we should avoid adding non-uploadable formats to the fmts
table.
For example, for format d3d11/yuv420p, av_hwframe_transfer_get_formats()
returns empty list of formats.
Now that we have identified the device types associated with each hwdec, we
can take advantage of this to ensure that get the right hwdec is chosen when
decoding frames and there are multiple choices available with different device
types.
This is also plumbed into the filter initialisation logic, although in practice
the decision on the hwdec has already been made at this point - still it's
easier than retaining the ambiguous look up logic and worrying that it might
lead to an inconsistent result.
These were all deprecated in mpv 0.37.0 or earlier and are not
considered common enough options to warrant keeping the deprecated
mapping longer. Since demux_cue had only a single option in it, the
entire option substract is removed. This can be readded later if someone
wants to introduce a specific option to it again.
This adds non-mpv filters to option-info/af/choices and
option-info/vf/choices, which allows completing them with set af/vf
<Tab> in console.lua.
Partial fix of #13017. Getting the filter options would required adding
af-list and vf-list properties.
The pad count serves as a minimum even if the filter has
dynamic inputs/outputs, so we should reject them here.
At least on FFmpeg 6.1 this results in no practical change
in the list accepted filters.
fixes: 8bf3fe7e2a
Abstract out EGL, and allow choosing between EGL and vulkan at runtime.
vf_gpu_egl.c contains GL specific context and creation/destroy code,
vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being
built in systems where EGL is not available and where Vulkan is
available.
Lots of filters have generic internal function names like "process".
On a stack trace, all of the different filters use this name,
which causes confusion of the actual filter being processed.
This renames these internal function names to carry the filter names.
This matches what had already been done for some filters.
These options were deprecated with the addition of the channel layout
API about a couple of years ago*. Unfortunately, we never saw the
deprecation messages so it went unnoticed until they were completely
removed with the recent major version bump. Fix this by setting
in_chlayout and out_chlayout instead if we have AV_CHANNEL_LAYOUT.
Fixes#13662.
*: 8a5896ec1f
refqueue gets the field of the frame from mp_image which almost always(if not
always) assumes bottom field order first. By default this behavior should not
change but specifying the field order should bypass this.
We generally try to avoid that due to the #ifdef mess.
The equivalent format is defined in ffmpeg 4.4 while our interop code
requires a higher version, but that doesn't cause any problems.
When mp_output_chain_update_filters() fails, talloc_free() is called on
each mp_user_filter. But because the structure doesn't have a talloc
destructor, the args aren't freed, resulting in stale references.
Fix this by calling the destructor of the wrapped filter instead.
Deinterlacing required that the user set it on/off themselves, but we
actually have handy flags for detecting if a frame is interlaced. So
it's pretty simple to make an auto option using that. Unfortunately,
life is not quite that simple and there are known cases of false
positives from the ffmpeg flags so we can't make auto the default value.
However, it still may have some utility for some people, and the
detection could potentially be improved upon later. Closes#10358.
