Commit Graph

710 Commits

Author SHA1 Message Date
wm4 4ae43a1c40 vd_lavc: fix broken assert()
This assert() sometimes triggered (and still triggers) with lavc API
bugs. It tries to check that at least 1 plane is set to a non-NULL
value. Obviously, a valid frame returned by successful decoding should
never have it.

The problem is that some hwdecs use integer surface IDs cast to a
pointer. Recently, it happened that newer Intel drivers started using
surface ID 0 under certain circumstances (for unknown reasons), which
triggers this assert.

Just get rid of it.

For the sake of #7185, add an assert() specifically for nvdec. That
failure needs to be further analyzed, is probably a FFmpeg bug, and
without this assert() would just crash somewhere further down the video
chain.

Fixes: #7261
2019-12-15 23:40:11 +01:00
wm4 8e08a2ec97 vd_lavc: simplify decode return error checking
This code checked AVFrame.buf[0] instead of the decode return code to
see whether a frame was decoded. This is sort of suspicious; while I
think that the lavc API actually guarantees it, it's not intuitive
anyway. In addition, the code was unnecessarily roundabout.

Replace it with a proper error code check. Remove the other error return
(that was, or should have been, redundant before). The no-frame path is
now cleanly separated. Add an assert on the frame-returned path; if this
fails, lavc violated its own API.
2019-12-15 22:26:39 +01:00
wm4 c26e80d0fd command: shuffle some crap around
This is preparation to get rid of the option-to-property bridge
(mp_on_set_option). This is a pretty insane thing that redirects
accesses to options to properties. It was needed in the ever ongoing
transition from something to... something else.

A good example for the need of this bridge is applying profiles at
runtime. This obviously goes through the config parser, but should also
make all changes effective, for which traditionally the property layer
is used.

There isn't much left that needs this bridge. This commit changes a
bunch of options (which also have a property implementation) to use
option change notifications instead. Many of the properties are still
left, but perform unrelated functions like OSD formatting.

This should be mostly compatible. There may be some subtle behavior
changes. For example, "hwdec" and "record-file" do not check for changes
anymore before applying them, so writing the current value to them
suddenly does something, while it was ignored before.

DVB changes untested, but should work.
2019-11-25 00:26:36 +01:00
wm4 67e17f1104 vd_lavc: don't keep packets for fallbacks if errors are tolerated
The user can raise the number of tolerated hardware decoding errors. On
the other hand, we have a static limit on packets that are "saved" for
fallback handling (and that's a good idea to avoid unbounded memory
usage). In this case, it could happen that the start of a file was fine
after a fallback, but after that buffered amount of data, it would
suddenly skip.

It's more useful to skip buffering entirely if the number of tolerated
decoding errors exceeds the fixed buffer.

(And also, I'm sure nobody gives a shit about this feature.)
2019-11-02 23:00:49 +01:00
wm4 0e1cfe0c42 vd_lavc: fix prepare_decoding() failure modes
prepare_decoding() returned a bool that was supposed to tell whether
decoding could work, or if something was fucked. After recent changes to
the decoder loop, this did not work anymore, and caused an endless loop.
Redo it, so it makes more sense. avctx being NULL (software fallback
initialization failed) now signals EOF. hwdec_failed needs to be handled
on send_packet() only, where it probably never happens anyway.

(Who was the idiot who made libavcodec have two entrypoints for
decoding? Oh right, it was me. PEBKAC.)
2019-11-02 22:44:39 +01:00
wm4 7bf31c51f2 vd_lavc: mention hw decoding if decoding fails in hwdec mode
Just so the user knows. Provides some context.
2019-11-02 22:38:08 +01:00
wm4 1bb726dedc vd_lavc: simplify fallback handling for full stream hw decoder
Shovel the code around to make the data flow slightly simpler (?). At
least there's only one send_packet function now. The old code had the
problem that send_packet() could be called even if there were queued
packets; due to sending the queued packets in the receive_frame
function, this should not happen anymore (the code checking for this
case in send_packet should normally never be called).

Untested with actual full stream hw decoders (none available here); I
created a test case by making hwaccel decoding fail.
2019-11-02 22:37:14 +01:00
wm4 dab588a4a2 vd_lavc: signal packet consumed in drop-all case
This is just a very special code path. This probably got stuck, now that
the previous commit returned the EAGAIN properly. Untested.
2019-11-02 21:38:19 +01:00
wm4 203fc6fe44 vd_lavc: change incorrect bool return type to int
Forgotten in commit 5d5fdb7. This failed to return the error code
properly. In particular, if the decoder rejected the packet, this was
not properly detected. Normally, this mattered only in specific cases.

Fixes: #7115
2019-11-02 21:35:48 +01:00
wm4 edc6075fa3 vd_lavc: fix draining with hwdec copy modes
Commit 5d5fdb77e9 changed details of the decoding control flow, and
called it a "high-risk" change. It turns out that this broke with with
hwdec copy mode, where there is some sort of delay queue (supposedly
increases efficiency, but more likely worthless cargo-cult).

It simply used the wrong (basically inverted) condition for the draining
case.

This was the only case that did not work properly. Other tests,
including video/audio decoding errors, software decoding fallbacks,
etc., seemed to work well. Might still not be exhaustive, as there are
so many corner cases.

Also change two error code returns. This don't/shouldn't really matter,
though the second error code led it to return both a frame and
AVERROR_EOF, which is unexpected, and makes lavc_process() leak a frame.
But also see next commit.

Fixes: 5d5fdb77e9
2019-10-25 21:44:49 +02:00
wm4 5d5fdb77e9 ad_lavc, vd_lavc: return full error codes to shared decoder loop
ad_lavc and vd_lavc use the lavc_process() helper to translate the
FFmpeg push/pull API to the internal filter API (which completely
mismatch, even though I'm responsible for both, just fucking kill me).

This interface was "slightly" too tight. It returned only a bool
indicating "progress", which was not enough to handle some cases (see
following commit).

While we're at it, move all state into a struct. This is only a single
bool, but we get the chance to add more if needed.

This fixes mpv falling asleep if decoding returns an error during
draining. If decoding fails when we already sent EOF, the state machine
stopped making progress. This left mpv just sitting around and doing
nothing.

A test case can be created with: echo $RANDOM >> image.png

This makes libavformat read a proper packet plus a packet of garbage.
libavcodec will decode a frame, and then return an error code. The
lavc_process() wrapper could not deal with this, because there was no
way to differentiate between "retry" and "send new packet". Normally, it
would send a new packet, so decoding would make progress anyway. If
there was "progress", we couldn't just retry, because it'd retry
forever.

This is made worse by the fact that it tries to decode at least two
frames before starting display, meaning it will "sit around and do
nothing" before the picture is displayed.

Change it so that on error return, "receiving" a frame is retried. This
will make it return the EOF, so everything works properly.

This is a high-risk change, because all these funny bullshit exceptions
for hardware decoding are in the way, and I didn't retest them. For
example, if hardware decoding is enabled, it keeps a list of packets,
that are fed into the decoder again if hardware decoding fails, and a
software fallback is performed. Another case of horrifying accidental
complexity.

Fixes: #6618
2019-10-24 18:50:28 +02:00
wm4 e1157cb6e8 video: generally try to align image data on 64 bytes
Generally, using x86 SIMD efficiently (or crash-free) requires aligning
all data on boundaries of 16, 32, or 64 (depending on instruction set
used). 64 bytes is needed or AVX-512, 32 for old AVX, 16 for SSE. Both
FFmpeg and zimg usually require aligned data for this reason.

FFmpeg is very unclear about alignment. Yes, it requires you to align
data pointers and strides. No, it doesn't tell you how much, except
sometimes (libavcodec has a legacy-looking avcodec_align_dimensions2()
API function, that requires a heavy-weight AVCodecContext as argument).

Sometimes, FFmpeg will take a shit on YOUR and ITS OWN alignment. For
example, vf_crop will randomly reduce alignment of data pointers,
depending on the crop parameters. On the other hand, some libavfilter
filters or libavcodec encoders may randomly crash if they get the wrong
alignment. I have no idea how this thing works at all.

FFmpeg usually doesn't seem to signal alignment internal anywhere, and
usually leaves it to av_malloc() etc. to allocate with proper alignment.
libavutil/mem.c currently has a ALIGN define, which is set to 64 if
FFmpeg is built with AVX-512 support, or as low as 16 if built without
any AVX support. The really funny thing is that a normal FFmpeg build
will e.g. align tiny string allocations to 64 bytes, even if the machine
does not support AVX at all.

For zimg use (in a later commit), we also want guaranteed alignment.
Modern x86 should actually not be much slower at unaligned accesses, but
that doesn't help. zimg's dumb intrinsic code apparently randomly
chooses between aligned or unaligned accesses (depending on compiler, I
guess), and on some CPUs these can even cause crashes. So just treat the
requirement to align as a fact of life.

All this means that we should probably make sure our own allocations are
64 bit aligned. This still doesn't guarantee alignment in all cases, but
it's slightly better than before.

This also makes me wonder whether we should always override libavcodec's
buffer pool, just so we have a guaranteed alignment. Currently, we only
do that if --vd-lavc-dr is used (and if that actually works). On the
other hand, it always uses DR on my machine, so who cares.
2019-09-19 20:37:05 +02:00
wm4 a8be8fe4f4 vd_lavc: put vaapi before vdpau in autoprobe order
--hwdec=auto-copy was preferring vdpau over vaapi. In the HEVC 10 bit
case, this also led to hardware decoding not being enabled. (Probably
because the probing can't start over after enabling hw decoding fails at
runtime, or something like that.)

Possible that this subtly breaks on some setups. You can't always win.
2019-09-19 20:37:05 +02:00
wm4 165799157d vd_lavc: add --hwdec-extra-frames option
Surprised this didn't exist before.
2019-09-19 20:37:05 +02:00
Jan Ekström 199aabddcc Merge branch 'master' into pr6360
Manual changes done:
  * Merged the interface-changes under the already master'd changes.
  * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
2019-03-11 01:00:27 +02:00
Akemi 08679f756c vd_lavc: increase the possible length of the hwdec name
this lead to an unexpected videotoolbox-copy hwdec name due to the last
two chars being cut off. since selection is also done by that name one
had to use "videotoolbox-co" to explicitly use the copy mode of
videotoolbox.
2019-01-23 09:30:58 +01:00
wm4 25525cee62 vd_lavc: minor simplification for get_format fallback
The default get_format does exactly do this, so we don't need to
duplicate it.

The only potential problem with this is that the logic doesn't entirely
prevent that the avcodec_default_get_format hw_device_ctx path is
triggered, which would probably work, but has unknown consequences and
interactions. But the way the logic currently works it can't happen,
provided the hwaccel metadata libavcodec provides is correct.
2018-05-25 10:17:06 +02:00
wm4 a770006c6e vd_lavc: move hwdec opts to local config, don't use global MPOpts
The --hwdec* options are a good fit for the vd_lavc local option
struct. This annoyingly requires manual prefixing of most of these
options with --vd-lavc (could be avoided by using more sub-struct
craziness, but let's not).
2018-05-24 19:56:35 +02:00
wm4 c9fcd20959 vd_lavc: minor simplification for get_format fallback
The default get_format does exactly do this, so we don't need to
duplicate it.

The only potential problem with this is that the logic doesn't entirely
prevent that the avcodec_default_get_format hw_device_ctx path is
triggered, which would probably work, but has unknown consequences and
interactions. But the way the logic currently works it can't happen,
provided the hwaccel metadata libavcodec provides is correct.
2018-05-24 19:56:34 +02:00
wm4 d6af6efbf9 vd_lavc: enable dr by default
I had this enabled for quite a while and experienced no issues. I'm not
aware of other issues either.
2018-04-29 02:21:32 +03:00
wm4 075aa21797 vd_lavc: slightly better logging about why hwdec is not used
The old message was outdated and also not very precise. Make it all a
bit more elaborate.
2018-03-08 17:12:32 -08:00
wm4 628805866d vd_lavc: fix inverted condition 2018-03-03 02:38:01 +02:00
wm4 706bb1d0c7 Fix recent FFmpeg deprecations
This includes codec/muxer/demuxer iteration (different iteration
function, registration functions deprecated), and the renaming of
AVFormatContext.filename to url (plus making it a malloced string).

Libav doesn't have the new API yet, so it will break. I hope they will
add the new APIs too.
2018-02-13 17:45:29 -08:00
wm4 9282a34fbf vd_lavc: fix stall with some uses of --hwdec=copy
Also a regression of the filter change. The new code is more picky about
EOF states, and it turns out the weird delay queue (used with some hwdec
copy back modes only) accidentally dropped an EOF event. It reset the
avctx before the delay queue was drained, which meant it never returned
the expected AVERROR_EOF status code.

Also don't signal EOF when copy back fails. It should just try to
continue until fallback is performed.
2018-02-05 23:34:42 -08:00
wm4 beb8d27912 vd_lavc: fix recently broken hardware decode fallback
This is a dataflow issue caused by the filters change. When the fallback
happens, vd_lavc does not return a frame, but also does not accept a new
packet, which confuses lavc_process(). Fix this by immediately retrying
to feed the buffered packet and decode a frame on fallback.

Fixes #5489.
2018-02-04 16:24:17 -08:00
wm4 6d36fad83c video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.

One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().

Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.

Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.

I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-30 03:10:27 -08:00
wm4 04be2b43ec video: minor simplification
The check is redundant - if removed, it will write the same value, so
it's a NOP.
2018-01-25 20:18:32 -08:00
wm4 c88ab96a78
video: warn user against FFmpeg's lies
I found that at least for mjpeg streams, FFmpeg will set packet pts/dts
anyway. The mjpeg raw video demuxer (along with some other raw formats)
has a "framerate" demuxer option which defaults to 25, so all mjpeg
streams will be played at 25 FPS by default.

mpv doesn't like this much. If AVFMT_NOTIMESTAMPS is set, it prints a
warning, that might print a bogus FPS value for the assumed framerate.
The code was originally written with the assumption that FFmpeg would
not set pts/dts for such formats, but since it does, the printed
estimated framerate will never be used. --fps will also not be used by
default in this situation.

To make this hopefully less confusing, explicitly state the situation
when the AVFMT_NOTIMESTAMPS flag is set, and give instructions how to
work it around.

Also, remove the warning in dec_video.c. We don't know what FPS it's
going to assume anyway. If there are really no timestamps in the stream,
it will trigger our normal missing pts workaround. Add the assumed FPS
there.

In theory, we could just clear packet timestamps if AVFMT_NOTIMESTAMPS
is set, and make up our own timestamps. That is non-trivial for advanced
video codecs like h264, so I'm not going there. For seeking and
buffering estimation the situation thus remains half-broken.

This is a mitigation for #5419.
2018-01-22 23:48:27 -08:00
Akemi 828f38e10d video: change some remaining vo_opengl mentions to vo_gpu 2018-01-20 14:43:49 -08:00
wm4 d652d479f1 video: avoid some unnecessary vf.h includes 2018-01-18 00:59:07 -08:00
wm4 83ab873497 video: change some mp_image_pool semantics
Remove the max_count creation parameter, because it's pointless and
rarely ever did anything. Add a talloc parent parameter instead (which
is something completely different, but convenient, and all callers needs
to be changed anyway).

Instead of clearing the pool when the now removed maximum is reached,
clear it on image parameter changes instead.
2018-01-13 03:26:45 -08:00
wm4 0a406f97e0 video, audio: don't actively wait for demuxer input
If feed_packet() ended with DATA_WAIT, the player should have gone to
sleep, until the demuxer wakes it up again when there is new data. But
the call to read_frame() unconditionally overwrote this status code, so
it never waited. The consequence was that the core burned CPU by
effectively polling the demuxer status, which was noticeable especially
when seeking in network streams (since seeking is async, decoders will
start out with having to wait for network).

Regression since commit 33e5755c.
2018-01-09 09:19:56 +01:00
wm4 33e5755c23 video, audio: always read all frames before getting next packet
The old code tried to make sure at all times to try to read a new
packet. Only once that was read, it tried to retrieve new video or audio
frames the decoder might already have decoded.

Change this to strictly read frames from the decoder until it signals
that it wants a new packet, and only then read and feed a new packet.
This is in theory nicer, follows the libavcodec recommended data flow,
and and reduces the minimum latency by 1 frame.

This merely requires switching the order in which those calls are done.
Normally, the decoder will return only 1 frame until a new packet is
required. If we would just feed it 1 packet, return DATA_AGAIN, and wait
until the next frame is decoded, we would run the playloop 1 time too
often for no reason (which is fine but might have some overhead). To
avoid this, try to read a frame again after possibly feeding a packet.
For this reason, move the feed/read code to its own functions each,
instead of merely moving the code.

The audio and video code for this particular thing is basically
duplicated. The idea is to unify them one day, so make the change to
both. (Doing this for video is the real motivation for this change, see
below.)

The video code change is slightly more complicated, because we have to
care about the framedrop counting (which is just a heuristic, but for
now considered better than nothing, and possibly considered required to
warn the user of framedrops happening - maybe).

Apparently this change helps with stalling streams on Android with the
mediacodec wrapper and mpeg2 decoder implementations which deinterlace on
decoding (and return 2 frames per packet).

Based on an idea and observations by tmm1.
2018-01-01 23:17:56 -08:00
wm4 5e50fe3049 demux_mkv: add hack to pass along x264 version to decoder
This fixes when resuming certain broken h264 files encoded by x264. See
FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264
bug itself.

Normally, the unregistered user data SEI (that contains the x264 version
string) is informational only. But libavcodec uses it to workaround a
x264 bug, which was recently fixed in both libavcodec and x264. The fact
that both encoder and decoder were buggy is the reason that it was not
found earlier, and there are apparently a lot of files around created by
the broken decoder. If libavcodec sees the SEI, this bug can be worked
around by using the old behavior.

If you resume a file with mpv (i.e. seeking when the file loads),
libavcodec never sees the first video packet. Consequently it has to
assume the file is not broken, and never applies the workaround,
resulting in garbage being played.

Fix this by always feeding the first video packet to the decoder on
init, and then flushing the codec (to avoid that an unwanted image is
output). Flushing the codec does not remove info such as the x264
version. We also abuse the fact that the first avcodec_send_packet()
always pushes the frame into the decoder (so we don't have to trigger
the decoder by requsting an output frame).
2017-12-28 00:59:22 -07:00
wm4 d480b1261b vd_lavc: add an option to explicitly workaround x264 4:4:4 bug
Technically, the user could just use --vd-lavc-o with the same result.
But I find it better to make this an explicit option, so we can document
the ups and downs, and also avoid setting it for non-h264.
2017-12-28 00:59:22 -07:00
wm4 5cbadbe721 vd_lavc: fix crash with RPI hwdec
If you use vo_rpi, this could crash, because hwdec_devs is NULL.

Untested. Fixes #5301.
2017-12-28 00:17:42 -07:00
wm4 69ae23fdd1 options: drop some previously deprecated options
A release has been made, so drop options deprecated for that release.
Also drop some options which have been deprecated a much longer time
before.

Also fix a typo in client-api-changes.rst.
2017-12-25 04:06:17 -07:00
wm4 3412c1a1aa
Restore Libav support
Libav has been broken due to the hwdec changes. This was always a
temporary situation (depended on pending patches to be merged), although
it took a bit longer. This also restores the travis config.

One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT
for videotoolbox (as opposed to the mpv format identifier), which is not
available in Libav. Add an ifdef; the affected code is for a deprecated
option anyway.
2017-12-21 19:45:32 +01:00
Niklas Haas ba1943ac00 msg: reinterpret a bunch of message levels
I've decided that MP_TRACE means “noisy spam per frame”, whereas
MP_DBG just means “more verbose debugging messages than MSGL_V”.
Basically, MSGL_DBG shouldn't create spam per frame like it currently
does, and MSGL_V should make sense to the end-user and provide mostly
additional informational output.

MP_DBG is basically what I want to make the new default for --log-file,
so the cut-off point for MP_DBG is if we probably want to know if for
debugging purposes but the user most likely doesn't care about on the
terminal.

Also, the debug callbacks for libass and ffmpeg got bumped in their
verbosity levels slightly, because being external components they're a
bit less relevant to mpv debugging, and a bit too over-eager in what
they consider to be relevant information.

I exclusively used the "try it on my machine and remove messages from
MSGL_* until it does what I want it to" approach of refactoring, so
YMMV.
2017-12-15 22:28:47 -08:00
wm4 cedcdc1f3c vd_lavc: rename --hwdec=rpi to --hwdec=mmal
Annoying exception that makes no sense to keep. Normally, users or
client applications will either use --hwdec=auto, or not set the option
at all, which both leads to the expected result.
2017-12-15 12:32:25 +02:00
wm4 9824a30eb1 vd_lavc: use libavcodec metadata for hardware decoder wrappers
This removes the need to keep an explicit list and to attempt to parse
codec names. Needs latest FFmpeg git.
2017-12-15 12:32:25 +02:00
wm4 a4705e8b59 vd_lavc: always load VO interops with non-copy hw decoders
For METHOD_INTERNAL hwdecs (non-copy cases), make sure the VO interops
are always loaded, because those decoders will output hardware pixel
formats, which will need special support in vo_gpu. Otherwise,
initialization will fail, complaining that it can't convert the output
format to something the VO supports.
2017-12-11 20:44:59 +02:00
LongChair b60ac5b5ba vd_lavc: add rkmpp to the hwdec_wrappers array.
Allows to get the hwdec picked up properly by mpv on rockchip devices
2017-12-10 18:24:50 +02:00
wm4 ca29a5aa9b vd_lavc: don't request native pixfmt with -copy and METHOD_INTERNAL
If the codec uses AV_CODEC_HW_CONFIG_METHOD_INTERNAL, and we're using
the -copy method, then don't request the native pix_fmt. It might not
have a AVFrame.hw_frames_ctx set, and we couldn't read back at all. On
top of that, most of those decoders probably don't provide read-back
when using such opaque formats anyway, while providing separate decoding
modes to decode to RAM.
2017-12-02 21:08:38 +01:00
wm4 23a9efd124 vd_lavc, vdpau, vaapi: restore emulated API avoidance
This code is for trying to avoid using an emulation layer when using
auto probing, so that we end up using the actual API the drivers
provide. It was destroyed in the recent refactor.
2017-12-02 04:53:51 +01:00
wm4 8b3dbab19e vd_lavc: simpler way to check for opque hw frame
The ->fmt shit is something I'd like to phase out.
2017-12-02 02:45:49 +01:00
wm4 3c07db0345 vd_lavc: sort -copy hwdec modes to end of list
Otherwise, if e.g. "nvdec" didn't work, but "nvdec-copy" did, it would
never try "vdpau", which is actually the next non-copy mode on the
autprobe list. It's really expected that it selects "vdpau". Fix this by
sorting the -copy modes to the end of the final hwdec list.

But we still don't want preferred -copy modes like "nvdec-copy" to be
sorted after fragile non-preferred modes like "cuda", and --hwdec=auto
should prefer "nvdec-copy" over it, so make sure the copying mode does
not get precedence over preferred vs. non-preferred mode.

Also simplify the existing auto_pos sorting condition, and fix the
fallback sort order (although that doesn't matter too much).
2017-12-02 02:32:41 +01:00
wm4 b279cfb1dd vd_lavc: allow forcing single implementations with --hwdec 2017-12-02 00:57:25 +01:00
wm4 5990f640f4 vd_lavc: slightly simplify
Factor the somewhat-duplicated code into an append function. Also fix
setting the copying flag in one of the cases. This also ensures some
uniformity.
2017-12-02 00:54:42 +01:00
wm4 47f7920006 vd_lavc: coding style 2017-12-02 00:45:03 +01:00
wm4 55c7e96878 vd_lavc: fix dumb nonsense 2017-12-01 22:08:59 +01:00
wm4 9d367cb0f9 vd_lavc, mp_image: remove weird mpv specific palette constant
Was for times when we were trying to be less dependent on libav* I
guess.
2017-12-01 22:03:38 +01:00
wm4 d891239d72 vd_lavc: merge redundant header
This is not needed anymore.
2017-12-01 22:01:54 +01:00
wm4 eb8957cea1 vd_lavc: rewrite how --hwdec is handled
Change it from explicit metadata about every hwaccel method to trying to
get it from libavcodec. As shown by add_all_hwdec_methods(), this is a
quite bumpy road, and a bit worse than expected.

This will probably cause a bunch of regressions. In particular I didn't
check all the strange decoder wrappers, which all cause some sort of
special cases each. You're volunteering for beta testing by using this
commit.

One interesting thing is that we completely get rid of mp_hwdec_ctx in
vd_lavc.c, and that HWDEC_* mostly goes away (some filters still use it,
and the VO hwdec interops still have a lot of code to set it up, so it's
not going away completely for now).
2017-12-01 21:11:43 +01:00
wm4 80359c6615 vd_lavc: drop mediacodec direct rendering support temporarily
The libavcodec mediacodec support does not conform to the new hwaccel
APIs yet. It has been agreed uppon that this glue code can be deleted
for now, and support for it will be restored at a later point.

Readding would require that it supports the AVCodecContext.hw_device_ctx
API. The hw_device_ctx would then contain the surface ID.
vo_mediacodec_embed would actually perform the task of creating
vo.hwdec_devs and adding a mp_hwdec_ctx, whose av_device_ref is a
AVHWDeviceContext containing the android surface.
2017-12-01 18:01:15 +01:00
wm4 9f52a92899 video: move d3d.c out of decode sub directory
It makes more sense to have it in the general video directory (along
with vdpau.c and vaapi.c), since the decoder source files don't even
access it anymore.
2017-12-01 17:58:56 +01:00
wm4 1e44540906 vd_lavc: delete hw_d3d11va.c/hw_dxva2.c and merge leftovers
Like with all hwaccels, there's little that is actually specific to
decoding (which has been moved away anyway), and what is left are
declarations (which will also go away soon).
2017-12-01 17:58:56 +01:00
wm4 b89f5084cc hw_dxva2: move dxva2 code to d3d.c
This source file will disappear, so just collect the leftovers in d3d.c.
2017-12-01 08:10:31 +01:00
wm4 a0d9e15342 video: refactor hw device creation for hwdec copy modes
Lots of shit code for nothing. We probably could just use libavutil's
code for all of this. But for now go with this, since it tends to
prevent stupid terminal messages during probing (libavutil has no
mechanism to selectively suppress errors specifically during probing).

Ignores the "emulated" API flag (for avoiding vaapi/vdpau wrappers), but
it doesn't matter that much for -copy anyway.
2017-12-01 08:05:16 +01:00
wm4 c5fac0c2b0 vd_lavc: move entrypoint for hwframes_refine
The idea is to get rid of vd_lavc_hwdec, so special functionality like
this has to go somewhere else. At this point, hwframes_refine is only
needed for d3d11, and it doesn't do much, so for now the new callback
has no context. In can be made more fancy if really needed.
2017-12-01 08:01:41 +01:00
wm4 643a1fc7de vd_lavc: remove process_image callback
Now unused.
2017-12-01 05:57:41 +01:00
wm4 9345964bad d3d11: move code for d3d11eglrgb hack 2017-12-01 05:57:41 +01:00
wm4 91586c3592 vo_gpu: make it possible to load multiple hwdec interop drivers
Make the VO<->decoder interface capable of supporting multiple hwdec
APIs at once. The main gain is that this simplifies autoprobing a lot.
Before this change, it could happen that the VO loaded the "wrong" hwdec
API, and the decoder was stuck with the choice (breaking hw decoding).
With the change applied, the VO simply loads all available APIs, so
autoprobing trickery is left entirely to the decoder.

In the past, we were quite careful about not accidentally loading the
wrong interop drivers. This was in part to make sure autoprobing works,
but also because libva had this obnoxious bug of dumping garbage to
stderr when using the API. libva was fixed, so this is not a problem
anymore.

The --opengl-hwdec-interop option is changed in various ways (again...),
and renamed to --gpu-hwdec-interop. It does not have much use anymore,
other than debugging. It's notable that the order in the hwdec interop
array ra_hwdec_drivers[] still matters if multiple drivers support the
same image formats, so the option can explicitly force one, if that
should ever be necessary, or more likely, for debugging. One example are
the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both
support d3d11 input.

vo_gpu now always loads the interop lazily by default, but when it does,
it loads them all. vo_opengl_cb now always loads them when the GL
context handle is initialized. I don't expect that this causes any
problems.

It's now possible to do things like changing between vdpau and nvdec
decoding at runtime.

This is also preparation for cleaning up vd_lavc.c hwdec autoprobing.
It's another reason why hwdec_devices_request_all() does not take a
hwdec type anymore.
2017-12-01 05:57:01 +01:00
wm4 c7596d3c8b vd_lavc: prefer nvdec over vdpau with --hwdec=auto
nvdec aka cuvid aka cuda should work much better than vdpau, and support
newer codecs (such as vp9), and more advanced surface formats (like 10
bit).

This requires moving the d3d hwaccels in the autoprobe order, since on
Windows, d3d decoding should be preferred over nvidia proprietary stuff.

Users of older drivers will need to force --hwdec=vdpau, since it could
happen that the vo_gpu cuda hwdec interop loads (so the vdpau interop is
not loaded), but the hwdec itself doesn't work.

I expect this does not break AMD (which still needs vdpau for vo_gpu
interop, until libva is fixed so it can fully support AMD).
2017-11-30 21:54:13 +01:00
wm4 ff17760c00 vd_lavc: restore --hwdec-image-format and d3d11 opaque mode
When the ifdeffery for the frame_params API was added, the new code
accidentally didn't include this.
2017-11-02 15:58:36 +01:00
wm4 95c6a482eb vd_lavc: clean out more hwdec legacy code
All this code used to be required by the old variants of the libavcodec
hw decoding APIs. Almost all of that is gone, although the mediacodec
API unfortunately still pulls in some old stuff (but not all of it).

(mediacodec build/functionality is untested, but should work.)
2017-10-31 17:11:52 +01:00
wm4 f27a9aaa17 vd_lavc: remove more dead legacy code
All of this was dead code and completely unused.

get_buffer2_hwdec() is the biggest chunk. One unfortunate thing about it
is that, while it was active, it could perform a software fallback much
faster, because it didn't have to wait until a full frame is decoded (it
actually decoded a full frame, but the current code has to decode many
more frames due to the codec delay, because the current code waits until
the API returns a decoded frame.) We should probably restore the latter,
although since it's an optional optimization, and the current behavior
doesn't change with the removal of this code, don't actually do anything
about it.
2017-10-31 15:29:13 +01:00
wm4 7fd1359fcf videotoolbox: use generic code for dummy hwdevice init
And move the remaining code (just 2 struct constant definitions) to
vd_lavc.c.
2017-10-31 15:20:09 +01:00
wm4 e0f42bdc5d vd_lavc: remove dead legacy code 2017-10-31 14:18:35 +01:00
wm4 078a3ed996 d3d: remove some legacy code
See #5062.
2017-10-31 14:14:45 +01:00
wm4 ff093e5b78 vd_lavc: makre sure required headers are included early enough
Should fix #5062.
2017-10-31 14:12:11 +01:00
wm4 a18a7cd4f5 vd_lavc: move display mastering data stuff to mp_image
This is where it should be. It only wasn't because of an old libavcodec
bug, that returned the side data only on every IDR. This required some
sort of caching, which is now dropped. (mp_image wouldn't have been able
to do this kind of caching, because this code is stateless.) We don't
support these old libavcodec versions anymore, which is why this is not
needed anymore.

Also move initialization of rotation/stereo stuff to dec_video.c.
2017-10-30 21:07:48 +01:00
wm4 a7f4ecb012 Bump libav* API use
(Not tested on Windows and OSX.)
2017-10-30 20:55:42 +01:00
wm4 58d83a9309 vd_lavc: make --hwdec=nvdec-copy actually work
This simply didn't work. Unlike cuda-copy, this is a true hwaccel, and
obviously we need to provide it a device.

Implement this in a relatively generic way, which can probably reused
directly by videotoolbox (not doing this yet because it would require
testing on OSX).

Like with cuda-copy, --cuda-decode-device is ignored. We might be able
to provide a more general way to select devices at some later point.
2017-10-30 18:34:49 +01:00
wm4 b7ce3ac445 vd_lavc: remove need for duplicated cuda GL interop backend
This is just a dumb consequence of HWDEC_ types somehow being part of
both decoder and VO. Obviously, the VO should only care about supporting
specific hardware surface types or providing specific device types, but
until they are separated, stupid unintuitive mismatches will occur.
2017-10-30 18:31:20 +01:00
wm4 d6ebb2df47 Get rid of deprecated AVFrame accessors
Fist we were required to use them for ABI compat. reasons (and other
BS), now they're deprecated and we're supposed to access them directly
again.
2017-10-30 13:36:44 +01:00
wm4 6b745769b1 vd_lavc: add support for nvdec hwaccel
See manpage additions.

(In ffmpeg-mpv and Libav, this is still called "cuvid". Libav won't work
yet, because it has no frame params support yet, but this could get
fixed soon.)
2017-10-28 19:59:08 +02:00
wm4 f36d152eb7 vd_lavc: use avcodec_fill_hw_frames_parameters() API
This removes the need for codec- and API-specific knowledge in the
libavcodec hardware acceleration API user. For mpv, this removes the
need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we
still keep the "old" parts for the sake of supporting older Libav, and
FFgarbage.)
2017-10-27 18:08:20 +02:00
wm4 22fa498bf9 vd_lavc: more aggressive frame dropping for intra only codecs
Should speed up seeks.

(Unfortunately it's useless for backstepping. Backstepping is like
precise seeking, except we're unable to drop frames, as we can't know
the previous frame if we drop it.)
2017-10-26 19:44:26 +02:00
wm4 a5b51f75dc demux: get rid of demux_packet.new_segment field
The new_segment field was used to track the decoder data flow handler of
timeline boundaries, which are used for ordered chapters etc. (anything
that sets demuxer_desc.load_timeline). This broke seeking with the
demuxer cache enabled. The demuxer is expected to set the new_segment
field after every seek or segment boundary switch, so the cached packets
basically contained incorrect values for this, and the decoders were not
initialized correctly.

Fix this by getting rid of the flag completely. Let the decoders instead
compare the segment information by content, which is hopefully enough.
(In theory, two segments with same information could perhaps appear in
broken-ish corner cases, or in an attempt to simulate looping, and such.
I preferred the simple solution over others, such as generating unique
and stable segment IDs.)

We still add a "segmented" field to make it explicit whether segments
are used, instead of doing something silly like testing arbitrary other
segment fields for validity.

Cached seeking with timeline stuff is still slightly broken even with
this commit: the seek logic is not aware of the overlap that segments
can have, and the timestamp clamping that needs to be performed in
theory to account for the fact that a packet might contain a frame that
is always clipped off by segment handling. This can be fixed later.
2017-10-24 19:35:55 +02:00
Lionel CHAZALLON cfcee4cfe7 Add DRM_PRIME Format Handling and Display for RockChip MPP decoders
This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced
format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor
struct.

That struct holds dmabuf fds and information allowing zerocopy rendering
using KMS / DRM Atomic.

This has been tested on RockChip ROCK64 device.
2017-10-23 21:07:24 +02:00
wm4 1ff6a1c8c7 video: make previously added hwdec params mechanism more generic
The mechanism introduced in b135af6842 assumed AVHWFramesContext would
be enough. Apparently it's not - the intended use with Rockchip (not
Rokchip btw.) requires accessing actual frame data in order to access
the AVDRMFrameDescriptor struct.

Just pass the entire mp_image to the new function. This is more
flexible, although it slightly worries me that it will be less reusable
for things which require setting up mp_image_params before any real
frames are processed (such as filters).
2017-10-16 17:00:38 +02:00
wm4 0a7c5a130e video: properly pass through ICC data
The same should happen with any other side data that matters to mpv,
otherwise filters will drop it.

(No, don't try to argue that mpv should use AVFrame. That won't work.)

ffmpeg_garbage() is copy&paste from frame_new_side_data() in FFmpeg
(roughly feed201849b8f91), because it's not public API. The name
reflects my opinion about FFmpeg's API.

In mp_image_to_av_frame(), change the too-fragile

  *new_ref = (struct mp_image){0};

into explicitly zeroing out the fields that are "transferred" to the
created AVFrame.
2017-10-16 16:36:51 +02:00
wm4 b135af6842 video: add mp_image_params.hw_flags and add an example
It seems this will be useful for Rokchip DRM hwcontext integration.

DRM hwcontexts have additional internal structure which can be different
depending on the decoder, and which is not part of the generic hwcontext
API. Rockchip has 1 layer, which EGL interop happens to translate to a
RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple
layers. Both will use sw_format=nv12, and thus are indistinguishable on
the mp_image_params level. But this is needed to initialize the EGL
mapping and the vo_gpu video renderer correctly.

We hope that the layer count is enough to tell whether EGL will
translate the data to a RGB texture (vs. 2 texture resembling raw nv12
data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE.

This commit adds the flag, infrastructure to set it, and an "example"
for D3D11.

The D3D11 addition is quite useless at this point. But later we want to
get rid of d3d11_update_image_attribs() anyway, while we still need a
way to force d3d11vpp filter insertion, so maybe it has some
justification (who knows). In any case it makes testing this easier.
Obviously it also adds some basic support for triggering the opaque
format for decoding, which will use a driver-specific format, but which
is not supported in shaders. The opaque flag is not used to determine
whether d3d11vpp needs to be inserted, though.
2017-10-16 15:02:12 +02:00
wm4 ac295960b8 video: make it possible to always override hardware decoding format
Mostly an obscure option for testing. But --videotoolbox-format can be
deprecated, as it becomes redundant.

We rely on the libavutil hwcontext implementation to reject invalid
pixfmts, or not to blow up if they are incompatible.
2017-10-16 15:02:12 +02:00
Aman Gupta 61a1612de9 hwdec: add mediacodec hardware decoder for IMGFMT_MEDIACODEC frames 2017-10-09 18:36:54 +02:00
Aman Gupta d08e407c9e hwdec: rename mediacodec to mediacodec-copy 2017-10-09 18:36:54 +02:00
wm4 158b69f04c build: switch preliminary LGPL mode from v3 to v2.1
iive agreed to relicense things that are still in mpv to LGPLv2.1. So
change the licenses of the affected files, and rename the configure
switch for LGPL mode to --enable-preliminary-lgpl2.

(The "preliminary" part will probably be removed from the configure
switch soon as well.)

Also player/main.c hasn't had GPL parts since a few commits ago.
2017-10-05 15:57:30 +02:00
wm4 dc5fcced23 vd_lavc: cuda requires setting hw_device_ctx
This restores cuda/cuvid under Windows.

Cuvid is relatively useless under Windows, but this was requested.
2017-09-26 23:20:20 +02:00
wm4 9b60398f4e video: remove old videotoolbox support
Like as in previous commits, you need a very recent FFmpeg (probably git
master).
2017-09-26 19:13:26 +02:00
wm4 ae7db6503b video: drop old D3D11/DXVA2 support
Now you need FFmpeg git, or something.

This also gets rid of the last real use of gpu_memcpy(). libavutil does
that itself. (vaapi.c still used it, but it was essentially unused,
because the code path isn't really in use anymore. It wasn't even
included due to the d3d-hwaccel dependency in wscript.)
2017-09-26 18:58:45 +02:00
wm4 5d57e9b1be video: drop old cuda/cuvid hwaccel
Just use FFmpeg 3.3 (or whatever it was) to get Cuvid support.
2017-09-26 18:00:46 +02:00
wm4 2b855739d5 vd_lavc: revert accidental vaapi changes revert
Commit bfa9b62858 accidentally reverted these (because my editor did
not reload the file correctly).

Fixes #4904.
2017-09-22 05:19:37 +02:00
wm4 bfa9b62858 build: add preliminary LGPL mode
See "Copyright" file for caveats.

This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
2017-09-21 13:56:27 +02:00
wm4 b881881dbd Revert "vd_lavc: change auto-probe order to prefer cuda over vdpau-copy"
This reverts commit 96462040ec.

I guess the autoprobing is still too primitive to handle this well. What
it really should be trying is initializing the wrapper decoder, and if
that doesn't work, try another method. This is complicated by hwaccels
initializing in a delayed way, so there is no easy solution yet.

Probably fixes #4865.
2017-09-19 18:35:29 +02:00
wm4 96462040ec vd_lavc: change auto-probe order to prefer cuda over vdpau-copy
This aims at making --opengl-hwdec-interop=cuda --hwdec=yes select the
correct decoding mode: cuda instead of vdpau-copy.
2017-08-30 12:08:40 +02:00
wm4 ecef999d19 vd_lavc: work around some more idiotic FFmpeg nonsense
Like in commit bd356333c7, but for the other hwaccels as well.

Fixes #4794.
2017-08-24 11:35:17 +02:00
wm4 60ba7eebd7 vd_lavc: fix mid-stream hwdec fallback
Not resetting hwdec_request_reinit caused it to flush on every packet,
which not only caused it to fail triggering the actual fallback, and let
it never decode a new frame, but also to get stuck on EOF.
2017-08-23 14:02:44 +02:00
wm4 028faacff5 video: add metadata handling for spherical video
This adds handling of spherical video metadata: retrieving it from
demux_lavf and demux_mkv, passing it through filters, and adjusting it
with vf_format. This does not include support for rendering this type of
video.

We don't expect we need/want to support the other projection types like
cube maps, so we don't include that for now. They can be added later as
needed.

Also raise the maximum sizes of stringified image params, since they
can get really long.
2017-08-21 14:56:07 +02:00
wm4 de6d3f8ca1 vd_lavc: fix device leak with copy-mode hwaccels
Apparently this was broken by the "ctx->hwdec" check in the if condition
guarding the destroy call, and "ctx->hwdec = NULL;" was moved up
earlier, making this always dead code.

This should probably be refcounted or so, although that could make it
worse as well. For now, add a flag whether the device should be
destroyed.

Fixes #4735.
2017-08-09 12:00:56 +02:00