If filters are disabled or reconfigured, attempt to remove and probe the
deinterlace filter again. This fixes behavior if e.g. a software deint
filter was automatically inserted, and then hardware decoding is enabled
during playback. Without this commit, initializing hw decoding would
fail because of the software filter; with this commit, it'll replace it
with the hw deinterlacer instead.
Instead of calling it "future frames" and adding or subtracting 1 from
it, always call it "requested frames". This simplifies it a bit.
MPContext.next_frames had 2 added to it; this was mainly to ensure a
minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2;
together with the other changes, this can be the exact size of the
array.
Handle a relatively recently introduced hack, that allows FLAC audio to
have arbitrary channel layouts, instead of just the predefined fixed
ones. This is actually supported by FFmpeg, but since the demuxer
(instead of the decoder) handles this in FFmpeg, we need to add special-
code to our mkv demuxer.
(The way FFmpeg does this seems a bit backwards, since now every demuxer
for a format that can handle FLAC needs to contain this logic as well.)
The FLAC hack is relatively terrible: we need to parse the FLAC headers,
look for a VorbisComment, parse the VorbisComment, and then retrieve
the magic WAVEFORMATEXTENSIBLE_CHANNEL_MASK entry. But the hack is
officially endorsed, as the official FLAC tools use it. (Although I
couldn't find a trace of it in the format specification. Should I be
surprised?)
This was a minor optimization to potentially avoid resampler
reconfiguration when the filter is reinitialized. But filter
reinitialization is a rare event, and the case when no reconfiguration
is needed is even rarer. As such, this is an unnecessary micro-
optimization and only adds potential for bugs.
This message bloats verbose log output if e.g. audio speed is frequently
readjusted, such as when syncing audio to video. So don't print the
message if only speed is changed. (This case requires reconfiguration,
but can't change the input/output channel maps.)
Also do not print the message if no remixing is done at all.
This was requested by someone.
All code was written by myself; some minor changes by 2 contributors who
agreed to general LGPL relicensing. 1 line of code is by someone unknown
who possibly wasn't asked (setting the "display_fps" variable), and
which can be reasonably ignored as it makes up only 0.1% of the file.
I still have no idea why this is needed, maybe some weird off-by-one
in some shitty driver? Either way, the difference for a working setup
shouldn't be too major, the most noticeable effect would be somewhat worse
performance when resizing the video during playback with interpolation
enabled using the mouse.
That's a specific enough side effect for me to not care as much about it.
Fixes#1814.
Probably makes users happy who want bitmap subtitles to show up in the
screen margins, and stops them from doing idiotic crap with vf_expand.
Fixes#2098.
There are some situations when redrawing is requested, but the current
frame was deleted. This could happen when switching e.g. hw decoding
mid-stream.
Separate uploading/drawing and fix the condition.
Just avoid some code duplication. Also, gl_video_set_options() having a
queue size output parameter is weird at best. While I don't appreciate
that this commit suddenly requires gl_video.c to deal with vo.c directly
in a special case, it's simply the best place to put this function.
The VO will be provided with future frames even if the format changes
mid-stream. This caused a crash if these frames were actually used (i.e.
interpolation mode was enabled).
Fixes a crash when deinterlacing is toggled during playback, and the
deinterlacer changes the stream format (as it can happen e.g. if the
decoder outputs nv12, which in turn happens with hw decoding).
(On a side note, future frames are always non-NULL. Also, the current
frame is of course always in the correct format.)
vaQueryImageFormats() returns a randomly ordered list - so we shouldn't
assume the first format on the list which works is the best. This
effectively switches to nv12 instead of yuv420p on some drivers.
We handle this by reusing va_to_imgfmt[], and ordering it by preference.
We hardcode that GPUs prefer nv12 pver yuv420p. In theory we could do
complicated probing (allocate dummy surface + use vaDeriveImage on it,
then retrieve the FourCC) - but all things which could break assumption
in the future are not supported yet (like 10 bit or 4:4:4), so this is
fine.
Fixes problems with --vo=opengl:interpolation. The issue here is that
vo_opengl retains more surfaces than what was preallocated for the
decoder. Until now, we just explicitly failed to decode frames for which
no additional surfaces are available. Since modern drivers usually are
fine with not "registering" surfaces before the decoder is created, just
allow allocating additional surfaces if needed.
(We also could probably recreate the HW decoder, since the HW decoder
should be stateless. But let's try to avoid raising the overall
complexity of the code.)
The interlaced frame test needs to be aware that the input mpi might be
NULL - this happens at the end of a stream when the input frames have
all been submitted but frames still need to be drained from the
decoder.
ass_set_fonts() is called by mp_ass_configure_fonts(), which was called
every time a subtitle renderer was initialized. I'm not sure why this
was done - I can't find a good reason, and most likely there's none.
However, it did cause problems with an experimental libass branch. It
crashed some time after switching to a second subtitle track. The branch
will hopefully be merged soon, and it seems unlikely that libass wants
to fix its problems with its ridiculous API (rather it should normalize
its API so that the issue doesn't happen in the first place), so just
apply this change. It makes our code simpler too.
Outputting the detected OpenGL features was useless and redundant with
the extension loading output.
Also, remove MPGL_CAP_3D_TEX from OpenGL(ES) 3.0. This block didn't
include the glTexImage3D function, so that was pointless and couldn't
have worked. The OpenGL 2.1 block does it correctly.
VDPAU has explicit support for rotating surfaces, and it is far less
expensive than using the normal rotation filter (which would require
reading video frames back into system memory), it is desirable to
implement the VO rotation capability.
To do this, we need to render the video frames to an output surface,
without rotation, and then render from that surface to the final
output surface to apply the rotation. It is important that the
intermediate surface is the same size as the final one (only not
rotated) so that hqscaling can be applied if requested by the user.
(hqscaling is a mixer capability and so takes effect when the video
surface is rendered to an output surface)
Finally, we must remember to explicitly clear the final output
surface as VDPAU only auto-clears output surfaces when rendering video
surfaces.
Normally, vdpau decoded frames are passed directly to a suitable
vo (vo_vdpau or vo_opengl) without ever touching system memory. This
is efficient for output purposes, but prevents any of the regular
filters from being used with such frames.
This new filter implements a read-back step to pull the frames back
into system memory where they can be acted on by other filters.
Eventually the frames will be sent to the vo as if they were normal
software-decoded frames.
Note that a vdpau compatible vo must still be used to ensure that
the decoder is properly initialised.
Signed-off-by: wm4 <wm4@nowhere>
wm4
Niklas Haas
Philip Sequeira
Stefano Pigozzi
deuiore
Kevin Mitchell
Philip Langdale