1
0
mirror of https://github.com/mpv-player/mpv synced 2025-03-11 08:37:59 +00:00
Commit Graph

540 Commits

Author SHA1 Message Date
wm4
9ca1592f3f d3d: implement screenshots for --hwdec=d3d11va
No method of taking a screenshot was implemented at all. vo_opengl
lacked window screenshotting, because ANGLE doesn't allow reading the
frontbuffer. There was no way to read back from a D3D11 texture either.

Implement reading image data from D3D11 textures. This is a low-quality
effort to get basic screenshots done. Eventually there will be a better
implementation: once we use AVHWFramesContext natively, the readback
implementation will be in libavcodec, and will be able to cache the
staging texture correctly. Hopefully. (For now it doesn't even have a
AVHWFramesContext for D3D11 yet. But the abstraction is more appropriate
for this purpose.)
2016-06-28 20:38:53 +02:00
wm4
17c5738cb4 d3d: merge angle_common.h into d3d.h
OK, this was dumb. The file didn't have much to do with ANGLE, and the
functionality can simply be moved to d3d.c. That file contains helpers
for decoding, but can always be present (on Windows) since it doesn't
access any D3D specific libavcodec APIs. Thus it doesn't need to be
conditionally built like the actual hwaccel wrappers.
2016-06-28 20:07:56 +02:00
stepshal
c5094206ce Fix misspellings 2016-06-26 13:47:21 +02:00
wm4
7be37337f4 vo_opengl: vdpau interop without RGB conversion
Until now, we've always converted vdpau video surfaces to RGB, and then
mapped the resulting RGB texture. Change this so that the surface is
mapped as NV12 plane textures.

The reason this wasn't done until now is because vdpau surfaces are
mapped in an "interlaced" way as separate fields, even for progressive
video. This requires messy reinterleraving. It turns out that even
though it's an extra processing step, the result can be faster than
going through the video mixer for RGB conversion.

Other than some potential speed-gain, doing this has multiple other
advantages. We can apply our own color conversion, which is important in
more complex cases. We can correctly apply debanding and potentially
other processing that requires chroma-specific or in-YUV handling.

If deinterlacing is enabled, this switches back to the old RGB
conversion method. Until we have at least a primitive deinterlacer in
vo_opengl, this will stay this way. The d3d11 and vaapi code paths are
similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 19:58:40 +02:00
wm4
7ecac3ae6f d3d11va: remove unused d3d11va_surface.subindex field
This is now stored within the AVFrame/mp_image.
2016-06-16 18:13:46 +02:00
James Ross-Gowan
88b584656d dxva2: remove dead code in failure case
This was made unnecessary by a02d77b, since the only way the function
could fail was by failing to add a reference to the DirectX DLLs.
2016-06-07 18:53:05 +10:00
wm4
0348cd080f video: remove d3d11 video processor use from OpenGL interop
We now have a video filter that uses the d3d11 video processor, so it
makes no sense to have one in the VO interop code. The VO uses it for
formats not directly supported by ANGLE (so the video data is converted
to a RGB texture, which ANGLE can take in).

Change this so that the video filter is automatically inserted if
needed. Move the code that maps RGB surfaces to its own inteorp backend.
Add a bunch of new image formats, which are used to enforce the new
constraints, and to automatically insert the filter only when needed.

The added vf mechanism to auto-insert the d3d11vpp filter is very dumb
and primitive, and will work only for this specific purpose. The format
negotiation mechanism in the filter chain is generally not very pretty,
and mostly broken as well. (libavfilter has a different mechanism, and
these mechanisms don't match well, so vf_lavfi uses some sort of hack.
It only works because hwaccel and non-hwaccel formats are strictly
separated.)

The RGB interop is now only used with older ANGLE versions. The only
reason I'm keeping it is because it's relatively isolated (uses only
existing mechanisms and adds no new concepts), and because I want to be
able to compare the behavior of the old code with the new one for
testing. It will be removed eventually.

If ANGLE has NV12 interop, P010 is now handled by converting to NV12
with the video processor, instead of converting it to RGB and using the
old mechanism to import that as a texture.
2016-05-29 19:00:55 +02:00
wm4
a02d77ba0d d3d: simplify DLL loading
For some reason, the d3d9/dxva2/d3d11 DLLs are still optional. But we
don't need to try so hard to keep exact references. In fact, there's no
reason to unload them at all.

So load them once in a central place. For simplicity, the d3d9/d3d11
backends both load all DLLs. (They will error out only if the required
DLLs could not be loaded.)

In theory, we could just call LoadLibrary multiple times (without
calling FreeLibrary), but I'm slightly worried that this could be
detected as a "bug", or that the reference count could even have a low
static limit that could be hit soon.
2016-05-17 11:59:54 +02:00
wm4
39b64fb176 video: merge dxva2 source files
video/dxva2.c exported only 2 functions, both used only by
video/decode/dxva2.c.

The same was already done for d3d11.
2016-05-17 11:05:51 +02:00
wm4
32c10956e0 vaapi: avoid forward declaration of variable
Why is everything so horrible.
2016-05-15 18:37:51 +02:00
wm4
70b3561270 video: add --hwdec=auto-copy mode
This uses the normal autoprobing rules like "auto", but rejects anything
that isn't flagged as copying data back to system memory.

The chunk in command.c was dead code, so remove it instead of updating
it.
2016-05-11 16:20:13 +02:00
wm4
fd82e14888 build: merge d3d11va and dxva2 hwaccel checks
We don't have any reason to disable either. Both are loaded dynamically
at runtime anyway. There is also no reason why dxva2 would disappear
from libavcodec any time soon.
2016-05-11 15:40:31 +02:00
wm4
a3d416c3d3 vo_opengl: d3d11egl: native NV12 sampling support
This uses EGL_ANGLE_stream_producer_d3d_texture_nv12 and related
extensions to map the D3D textures coming from the hardware decoder
directly in GL.

In theory this would be trivial to achieve, but unfortunately ANGLE does
not have a mechanism to "import" D3D textures as GL textures. Instead,
an awkward mechanism via EGL_KHR_stream was implemented, which involves
at least 5 extensions and a lot of glue code. (Even worse than VAAPI EGL
interop, and very far from the simplicity you get on OSX.)

The ANGLE mechanism so far supports only the NV12 texture format, which
means 10 bit won't work. It also does not work in ES3 mode yet. For
these reasons, the "old" ID3D11VideoProcessor code is kept and used as a
fallback.
2016-05-10 21:06:34 +02:00
wm4
46fff8d31a video: refactor how VO exports hwdec device handles
The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and
renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or
documented where not), which makes the whole thing saner and cleaner. In
particular, thread-safety rules become less subtle and more obvious.

The new internal API makes it easier to support multiple OpenGL interop
backends. (Although this is not done yet, and it's not clear whether it
ever will.)

This also removes all the API-specific fields from mp_hwdec_ctx and
replaces them with a "ctx" field. For d3d in particular, we drop the
mp_d3d_ctx struct completely, and pass the interfaces directly.

Remove the emulation checks from vaapi.c and vdpau.c; they are
pointless, and the checks that matter are done on the VO layer.

The d3d hardware decoders might slightly change behavior: dxva2-copy
will not use the VO device anymore if the VO supports proper interop.
This pretty much assumes that any in such cases the VO will not use any
form of exclusive mode, which makes using the VO device in copy mode
unnecessary.

This is a big refactor. Some things may be untested and could be broken.
2016-05-09 20:03:22 +02:00
wm4
5be40f035b d3d: DXVA2_ModeMPEG2_VLD supports all profiles
Fixes hardware decoding of most mpeg2 things.
2016-05-03 15:46:16 +02:00
James Ross-Gowan
622bcb0e37 win32: replace libuuid.a usage with initguid.h
Including initguid.h at the top of a file that uses references to GUIDs
causes the GUIDs to be declared globally with __declspec(selectany). The
'selectany' attribute tells the linker to consolidate multiple
definitions of each GUID, which would be great except that, in Cygwin
and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with
the ones declared in libuuid.a.

Since initguid.h obsoletes libuuid.a in modern compilers that support
__declspec(selectany), add initguid.h to all files that use GUIDs and
remove libuuid.a from the build.

Fixes #3097
2016-05-01 21:10:24 +10:00
Kevin Mitchell
8d51f08010 d3d11va: fix invalid deref on decoder init failure
fixes #3092
2016-04-29 23:36:01 -07:00
wm4
64f9e48bf1 d3d11va, dxva2: return the format struct directly
Slight simplification, IMHO.
2016-04-29 23:30:01 +02:00
wm4
016eab2209 d3d11va, dxva2: simplify decoder selection
In particular, this moves the depth test to common code.

Should be functionally equivalent, except that for DXVA2, the
IDirectXVideoDecoderService_GetDecoderRenderTargets API is called
more often potentially.
2016-04-29 23:24:28 +02:00
wm4
bda111018c video: add IMGFMT_P010 alias
Gets rid of some silliness, and might be useful in the future.
2016-04-29 22:38:54 +02:00
wm4
dff33893f2 d3d11va: store texture/subindex in IMGFMT_D3D11VA plane pointers
Basically this gets rid of the need for the accessors in d3d11va.h, and
the code can be cleaned up a little bit.

Note that libavcodec only defines a ID3D11VideoDecoderOutputView pointer
in the last plane pointers, but it tolerates/passes through the other
plane pointers we set.
2016-04-27 14:06:50 +02:00
wm4
9896994688 vd_lavc: adjust D3D11VA autoprobe order
We want to prefer d3d11va over dxva2 anything. But since dxva2 copyback
is more efficient than d3d11va's currently, d3d11va-copy should come
last.
2016-04-27 13:54:20 +02:00
wm4
3706918311 vo_opengl: D3D11VA + ANGLE interop
This uses ID3D11VideoProcessor to convert the video to a RGBA surface,
which is then bound to ANGLE. Currently ANGLE does not provide any way
to bind nv12 surfaces directly, so this will have to do.

ID3D11VideoContext1 would give us slightly more control about the
colorspace conversion, though it's still not good, and not available
in MinGW headers yet.

The video processor is created lazily, because we need to have the coded
frame size, of which AVFrame and mp_image have no concept of. Doing the
creation lazily is less of a pain than somehow hacking the coded frame
size into mp_image.

I'm not really sure how ID3D11VideoProcessorInputView is supposed to
work. We recreate it on every frame, which is simple and hopefully
doesn't affect performance.
2016-04-27 13:49:47 +02:00
wm4
da59726776 vd_lavc: hack against videotoolbox crash on failure
I guess this won't ever be fixed properly in FFmpeg. Too hairy, and the
alternative (using VideoToolbox as "full decoder") is too attractive.
2016-04-26 18:53:58 +02:00
wm4
8ffd2f1dd4 vd_lavc: simplify some unneeded ifdeffery
These were for ancient libavcodec versions.
2016-04-25 19:11:16 +02:00
wm4
6a1814dfb8 vd_lavc: make image_format hwdec field optional
For Mediacodec in particular we don't care about the format. It can just
decode to whatever it wants. The only case we would care about is it not
returning an opaque format if we don't have proper interop, but
libavcodec always returns non-opaque formats by default.
2016-04-25 12:23:38 +02:00
wm4
7e3d8e7134 vd_lavc: simplify RPI and Mediacodec wrappers
Use the recently added lavc_suffix mechanism to select the wrapper
decoder.

With all hwdec callbacks being optional, and RPI/Mediacodec having only
dummy callbacks, all the callbacks can be removed as well.

The result is that the vd_lavc_hwdec struct for both of them is tiny.
It's better to move them to vd_lavc.c directly, because they are so
trivial and small.
2016-04-25 12:23:38 +02:00
wm4
46e49a37be vd_lavc: make all hwdec callbacks optional 2016-04-25 12:23:37 +02:00
wm4
bb17df1f07 vd_lavc: set AVCodecContext.time_base to forced time base
This is a bit sketchy, as there isn't a truly standard way to
communicate the timebase.
2016-04-25 12:23:37 +02:00
wm4
4f5509e1dd vd_lavc: better hwdec wrapper decoder selection
This is intended for cases when --hwdec needs to override the decoder
implementation in use, like for example on the RPI.

It does two things:
1. Allow the hwdec to indicate a decoder suffix. libavcodec by
   convention adds a suffix to all wrapper decoders, and here we start
   relying on it. While not necessarily the best idea, it's the only
   thing we got. libavcodec's hwaccel list is useless, because it only
   has the codec ID, not the associated decoder's name.
2. Make --hwdec=auto work properly. It shouldn't fail anymore, and hwdec
   probing should reliably work, even if a different decoder is selected
   with --vd. The semantics of --hwdec should dictate that it overrides
   the default decoder.
2016-04-25 12:13:12 +02:00
wm4
85416bc36a vd_lavc: allow process_image() to return NULL
In case of errors or whatever.
2016-04-25 11:30:07 +02:00
wm4
b1a8e8dba6 vd_lavc: fix hwdec fallback if hwdec pre-initialization fails
Damn.
2016-04-22 15:52:16 +02:00
Kevin Mitchell
ce153bdb42 d3dva: move Intel_H264_NoFGT_ClearVideo to lower priority
This seems to cause problems, so only use it if H264_E is not available.

fixes #3059
2016-04-18 02:00:50 -07:00
Kevin Mitchell
2f5c7af914 dxva2: fix missing newline in error message 2016-04-18 01:58:18 -07:00
Kevin Mitchell
611594e7e8 d3dva: include selected decoder and format in verbose output 2016-04-17 18:28:14 -07:00
wm4
f5ff2656e0 vaapi: determine surface format in decoder, not in renderer
Until now, we have made the assumption that a driver will use only 1
hardware surface format. the format is dictated by the driver (you
don't create surfaces with a specific format - you just pass a
rt_format and get a surface that will be in a specific driver-chosen
format).

In particular, the renderer created a dummy surface to probe the format,
and hoped the decoder would produce the same format. Due to a driver
bug this required a workaround to actually get the same format as the
driver did.

Change this so that the format is determined in the decoder. The format
is then passed down as hw_subfmt, which allows the renderer to configure
itself with the correct format. If the hardware surface changes its
format midstream, the renderer can be reconfigured using the normal
mechanisms.

This calls va_surface_init_subformat() each time after the decoder
returns a surface. Since libavcodec/AVFrame has no concept of sub-
formats, this is unavoidable. It creates and destroys a derived
VAImage, but this shouldn't have any bad performance effects (at
least I didn't notice any measurable effects).

Note that vaDeriveImage() failures are silently ignored as some
drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL
interop. In addition, we still probe whether we can map an image
in the EGL interop code. This is important as it's the only way
to determine whether EGL interop is supported at all. With respect
to the driver bug mentioned above, it doesn't matter which format
the test surface has.

In vf_vavpp, also remove the rt_format guessing business. I think the
existing logic was a bit meaningless anyway. It's not even a given
that vavpp produces the same rt_format for output.
2016-04-11 22:03:26 +02:00
wm4
813372d6e9 d3d: fix Windows build
Commit f009d16f accidentally broke it.

Thanks to RiCON for noticing and testing.
2016-04-07 21:04:31 +02:00
wm4
f033481551 videotoolbox: change how videotoolbox format is managed
The underlying intention of this code is to make changing
--videotoolbox-format at runtime work. For this reason, the format can't
just be statically setup, but must be read from the option at runtime.

This means the format is not fixed anymore, and we have to make sure the
renderer is property reinitialized if the format changes. There is
currently no way to trigger reinit on this level, which is why the
mp_image_params.hw_subfmt field was introduced.

One sketchy thing remains: normally, the renderer is supposed to be
involved with VO format negotiation, which would ensure that the VO
can take the format at all. Since the hw_subfmt is not part of this
format negotiation, it's implied the get_vt_fmt() callback only
returns formats supported by the renderer. This is not necessarily
clear because vo_opengl checks this with converted_imgfmt separately.
None of this matters in practice though, because we know all formats
are always supported.

(This still requires somehow triggering decoder reinit to make the
change effective.)
2016-04-07 19:54:58 +02:00
wm4
8a67606c20 vd_lavc: let hardware decoder request delaying frames explicitly
Until now, the presence of the process_image() callback was used to set
a delay queue with a hardcoded size. Change this to a vd_lavc_hwdec
field instead, so the decoder can explicitly set this if it's really
needed.

Do this so process_image() can be used in the VideoToolbox glue code for
something entirely unrelated.
2016-04-07 18:47:32 +02:00
wm4
f009d16f36 vd_lavc: fix codec vs. decoder confusion
Some functions which expected a codec name (i.e. the name of the video
format itself) were passed a decoder name. Most "native" libavcodec
decoders have the same name as the codec, so this was never an issue.

This should mean that e.g. using "--vd=lavc:h264_mmal --hwdec=mmal"
should now actually enable native surface mode (instead of doing copy-
back).
2016-04-07 17:48:00 +02:00
wm4
c971220cdd demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API change
AVFormatContext.codec is deprecated now, and you're supposed to use
AVFormatContext.codecpar instead.

Handle this for all of the normal playback code.

Encoding mode isn't touched.
2016-03-31 22:00:45 +02:00
Kevin Mitchell
213c611471 dxva2: rewrite to use shared code with d3d11va
This is basically a full rewrite to make it look more like d3d11va.c
2016-03-30 09:01:33 -07:00
Kevin Mitchell
a7110862c8 vd_lavc: add d3d11va hwdec
This commit adds the d3d11va-copy hwdec mode using the ffmpeg d3d11va
api. Functions in common with dxva2 are handled in a separate decode/d3d.c
file. A future commit will rewrite decode/dxva2.c to share this code.
2016-03-30 09:01:27 -07:00
Jan Ekström
5843392db5 Add a mediacodec decoder hwdec wrapper
Does the same thing as the rpi one - makes fallback possible by
pretending that h264_mediacodec is a hwdec.
2016-03-25 21:35:59 +01:00
Jan Ekström
83b8d3f52c vd_lavc: mediacodec also needs special timebase love 2016-03-25 21:35:57 +01:00
wm4
4300bfd518 ad_lavc, vd_lavc: support new Libav decoding API
For now only found in Libav.
2016-03-24 17:53:30 +01:00
wm4
b34befbab8 vd_lavc: slightly improve codec_timebase hack
The mp_set_av_packet()/mp_pts_from_av() functions check whether the
timebase is set at all (i.e. AVRational.num!=0), so there's no need to
fiddle with pointers.
2016-03-24 16:38:14 +01:00
wm4
042ca849ea vd_lavc: don't get into an endless loop if decoding fails
Regression since commit 6640b22a.
2016-03-18 13:14:13 +01:00
wm4
a993cdc481 dxva2: prevent outputting native surfaces with HWDEC_DXVA2_COPY (again)
Not quite sure when/why exactly this was broken.
2016-03-17 09:47:09 +01:00
wm4
e8355597f3 dec_video: always redisplay cover art after a seek
Instead of displaying it only on playback start (or after switching
tracks), always display it even after a seek.

This helps with --lavfi-complex. You can now overlay e.g. audio
visualizations over cover art, and it won't break after a seek.

The downside is that this might make seeks with huge cover art slower.

There is also a glitch on seeking: since cover art pictures always
have timestamp 0, the playback time will be 0 for a moment after seek,
and then revert to audio PTS (as video is considered EOF). This is also
due to how lavfi's overlay filter behaves. (I'm not sure how to tell
lavfi that it's just a single frame.)
2016-03-11 20:58:13 +01:00
wm4
52d336e4c1 dec_video: reduce scope of variable
Almost only a cosmetic change, although it decreases pointless
referencing/dereferencing of the cover art packet too.
2016-03-11 20:31:41 +01:00
wm4
c53c6bbd38 video: fix coverart decoding
Deselecting cover art and then reselecting it did not work. The second
time the cover art picture is not displayed again. (This seems to break
every other month...)

The reason is commit 6640b22a. It mutates the input packet. And it is
correct that we don't own d_video->header->attached_picture at this
point. Fix it by creating a new packet reference.
2016-03-07 15:00:08 +01:00
wm4
fa8b2be4de av_common: explicitly exclude _vdpau deccoders from enumeration
Completely pointless abominations that FFmpeg refuses to remove. They
are ancient, long deprecated API which we can't use anymore. They
confused users as well.

Pretend that they don't exist. Due to the way --vd works, they can't
even be forced anymore. The older hack which explicitly rejects these
can be dropped as well.
2016-03-02 22:20:15 +01:00
wm4
1f436f65f2 video: fix hr-seek
Hr-seek was often off by one frame due to rounding issues, which have
been traditionally taken care off by adding a "tolerance". Essentially,
frames very close to the seek target PTS are not dropped, even if they
may strictly are before the seek target.

Commit 0af53353 accidentally removed this by always removing frames even
if they're within the "tolerance". Fix this by "unsharing" the logic and
making sure the segment code is inactive for normal seeks.
2016-02-28 20:29:51 +01:00
wm4
d549c4e402 vd_lavc: simplify hwdec pixfmt check
Instead of checking whether the format is a hwaccel format, check
whether it's the exact format we've requested for hardware decoding.
2016-02-20 11:56:31 +01:00
wm4
f04cb7bf48 dxva2: fix autoprobing
Doing --hwdec=auto ends up picking dxva2, creating a decoder, and then
sending D3D frames down the video chain, which immediately fails and
falls back to software.

Consider dxva2 only if the VO provides a context. If this fails,
autoprobing will proceed to try dxva2-copy as usual.

Fixes #2844.
2016-02-19 20:02:09 +01:00
wm4
6640b22a8c video: allow the decoder to consume packets partially
This is in preparation for a hypothetical API change in libavcodec,
which would allow the decoder to return multiple video frames before
accepting a new input packet.

In theory, the body of the if() added to vd_lavc.c could be replaced
with this code:

    packet->buffer += ret;
    packet->len    -= ret;

but currently this is not needed, as libavformat already outputs one
frame per packet. Also, using libavcodec this way could lead to a
"deadlock" if the decoder refuses to consume e.g. garbage padding, so
enabling this now would introduce bugs.

(Adding this now for easier testing, and for symmetry with the audio
code.)
2016-02-19 18:50:14 +01:00
wm4
b3804e71af video: move packet timestamp fudging
There is some strange code which sets the DTS of the packet to PTS (but
only if it's not AVI), which apparently helps with timestamp
determination with some broken files. This code is annoying because it
tries to avoid mutating the packet (which it logically doesn't own).
Move it to where it does and get rid of the packet_copy mess.

Needed for the following commit.
2016-02-19 18:28:46 +01:00
wm4
ee5ba9678a video: move unreliable-packet-PTS check
This tries to determine whether packet PTS values are accurate and can
be used for frame dropping during seeking. Move both checks (PTS is
missing; PTs is non-monotonic) to the earliest place where they can be
done.
2016-02-19 18:16:21 +01:00
Kevin Mitchell
084162d6fe dxva2: add interop (non-copyback) hwdec_type
This always falls back to software decoding right now. VO support will be added
in future commits.
2016-02-17 06:59:02 -08:00
wm4
f371367aac dxva2: avoid using AV_PIX_FMT_P010 directly
The new code is essentially equivalent, but compiles against older
ffmpeg.

Fixes #2832.
2016-02-17 13:54:55 +01:00
Kevin Mitchell
3dfb07854b dxva2: use mp_HESULT_to_str on FAILED(hr) 2016-02-16 12:36:57 -08:00
Kevin Mitchell
88c83f450a dxva2: use mp_image_pool_get_no_alloc for decoder images
This makes it more explicit that the pool doesn't ever actually do any
allocating itself.
2016-02-16 12:36:57 -08:00
Kevin Mitchell
d5348a66dc dxva2: another attempt at using mp_image pool
Apparently, some drivers require you to allocate all of the decoder d3d surfaces
at once. This commit changes the strategy from allocating surfaces as needed via
mp_image_pool_set_allocator, to allocating all the surfaces in one call to
IDirectXVideoDecoderService_CreateSurface and adding them to the pool with
mp_image_pool_add.

fixes #2822
2016-02-16 12:36:56 -08:00
wm4
0af5335383 Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.

The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.

The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)

To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
  concatenating files with completely different codecs for the sake
  of EDL (which also uses the timeline infrastructure). A "lighter"
  approach would try to make use of decoder mechanism to update e.g.
  the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
  normal playback core mechanisms like hr-seek, but now the playback
  core doesn't need to care about these things.

These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)

There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.

Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 21:04:07 +01:00
wm4
f2b039da77 audio/video: expose codec info as separate field
Preparation for the timeline rewrite. The codec will be able to change,
the stream header not.
2016-02-15 20:34:45 +01:00
wm4
f219a48dca video: remove pointless parameter indirection
This is always the same value.
2016-02-15 20:28:36 +01:00
wm4
acf239a45c dxva2: support HEVC Main 10 2016-02-15 12:52:16 +01:00
Kevin Mitchell
06f1e934db dxva2: use mp_image pool for d3d surfaces
This is required so that the individual surfaces can pass beyond the dxva2
decoder and be passed to the vo.

This also adds additional data to mp_image->planes[0] for IMGFMT_DXVA2, which is
required for maintaining and releasing the surface even if the decoder code is
uninited.

The IDirectXVideoDecoder itself is encapsulated together with its surface pool
and configuration in a dxva2_decoder structure whose creation and destruction is
managed by talloc.
2016-02-14 11:01:12 -08:00
Kevin Mitchell
543f6df2a6 dxva2: remove unused structure members 2016-02-14 11:01:12 -08:00
Kevin Mitchell
74a8fd3702 dxva2: streamline number of surface calculation
use hwdec_get_max_refs and put the "4 base work surfaces" into
ADDITIONAL_SURFACES macro.
2016-02-14 11:01:12 -08:00
wm4
d3f32cba32 video: approximate AVI timestamps via DTS handling
Until now (and in mplayer traditionally), avi timestamps were handled
with a timestamp FIFO. AVI timestamps are essentially just strictly
increasing frame numbers and are not reordered like normal timestamps.

Limiting the FIFO is required because frames can be dropped. To make
it worse, frame dropping can't be distinguished from the decoder not
returning output due to increasing the buffering required for B-frames.
("Measuring" the buffering at playback start seems like an interesting
idea, but won't work as the buffering could be increased mid-playback.)
Another problem are skipped frames (packets with data, but which do
not contain a video frame).

Besides dropped and skipped frames, there is the problem that we can't
always know the delay. External decoders like MMAL are not going to
tell us. (And later perhaps others, like direct VideoToolbox usage.)

In general, this works not-well enough that I prefer the solution of
passing through AVI timestamps as DTS. This is slightly incorrect,
because most decoders treat DTS as mpeg-style timestamps, which
already include a b-frame delay, and thus will be shifted by a few
frames. This means there will be a problem with A/V sync in some
situations.

Note that the FFmpeg AVI demuxer shifts timestamps by an additional
amount (which increases after the first seek!?!?), which makes the
situation worse. It works well with VfW-muxed Matroska files, though.

On RPI, the first X timestamps are broken until the MMAL decoder "locks
on".
2016-02-11 16:14:30 +01:00
wm4
7caecc53b0 player: fix crash if no video decoder can be initialized
Caused by the recent refactoring for complex filters.
2016-02-10 00:07:01 +01:00
kwkam
77cb44d759 video/decode/dxva2.c: GUID_NULL conflicts
GUID_NULL is defined in <ks.h>
gcc 6.0 refuses to link the executable because of that

Signed-off-by: wm4 <wm4@nowhere>
2016-02-06 22:55:53 +01:00
Kevin Mitchell
fb5f732798 vd_lavc: fix use after free in some hwdecs
fd339e3f53 introduced a regression that caused
segfault while uniniting dxva2 decoder (and possibly vdpau too). The problem was
that it freed the avctx earlier, before calling the backend-specific uninit
which referenced it.

Revert some of the changes of that commit, and avoid calling flush by
checking whether the codec is open instead.

(Based on a PR by Kevin Mitchell.)

Signed-off-by: wm4 <wm4@nowhere>
2016-02-06 14:24:25 +01:00
wm4
fd339e3f53 vd_lavc: avoid calling flush on an unopened AVCodecContext
It can be "dangerous". In particular, the decoder might have failed to
initialize, and is now in a broken state. avcodec_flush_buffers() is not
expected to be called in this state, and could trigger undefined
behavior.
2016-02-05 17:46:46 +01:00
wm4
6cbd7d6390 video: remove AVI timestamps for dropped frames
Might possible improve A/V sync, although this is at best approximate.
(AVI is just fucked.)
2016-02-04 21:31:15 +01:00
wm4
a38f313bcc vd_lavc: remove redundant best_csp field
And some other simplifications.
2016-02-03 21:31:53 +01:00
wm4
1b6a191ea3 vd_lavc: force microsecond timestamps on RPI
Avoids "problems". In particular, it makes MMAL output a NOPTS timestamp
if the input timestamp was NOPTS.

Don't do it for other decoders. Ideally, we will at some point in the
future switch to integer fractions for timestamps at least up until the
filter layer. But this would be a larger change, and for now I'd prefer
keeping the not-rounded demuxer timestamps (if we have them).
2016-02-03 21:29:56 +01:00
wm4
ab318aeea8 audio/video: merge decoder return values
Will be helpful for the coming filter support. I planned on merging
audio/video decoding, but this will have to wait a bit longer, so only
remove the duplicate status codes.
2016-02-01 22:03:04 +01:00
wm4
e42a08340b vd_lavc: release surfaces before destroying decoder
Commit b53cb8de added a delay queue for decoded frames. This is supposed
to be used with copy-back decoders like dxva2-copy and vaapi-copy.
Surfaces returned by them can't be referenced after uninitializing the
decoders, so they have to be released before destroying the decoder.
Move the flush_all() call above decoder uninit accordingly. Also move
the destruction of the AVFrame used for decoding (just for being
defensive - normally it doesn't hold any reference).
2016-01-30 20:59:25 +01:00
wm4
a8dd0abb6d vd_lavc: allow switching between hw/sw decoding any time
We just need to provide an entrypoint for it, and move the main init
code to a separate function. This gets rid of the messy video chain full
reinit in command.c, which completely destroyed and recreated the video
state for the purpose of mid-stream hw/sw switching.
2016-01-29 22:47:27 +01:00
wm4
942a6729fa vd_lavc: simplify an aspect of hwdec fallback
Don't give the "software_fallback_decoder" field special meaning. Alwass
set it, and rename it to "decoder". Whether hw decoding is used is
determined by the "hwdec" field already.
2016-01-29 22:46:46 +01:00
wm4
d980fd0856 video: fix broken-PTS fallback determination
This codes tries to deal with broken PTS timestamps, but since commit
271cabe6 it didn't always overwrite the previous timestamp as it should
have. This mattered only if there were broken timestamps in the video
stream.

Also remove the pointless prev_codec_pts variables, since the decoder
doesn't overwrite these fields anymore.
2016-01-29 22:43:18 +01:00
wm4
939ad0889b rpi: add VC-1 support
Oops, this was forgotten earlier. Enables automatic use of the VC-1
hardware decoder on RPI.
2016-01-28 11:23:23 +01:00
wm4
c7ec8fdfe7 rpi: add mpeg-4 decoding support 2016-01-27 21:09:44 +01:00
wm4
475d346174 vaapi: lower number of allocated surfaces again
Commit b53cb8de increased this by the number of additionally delayed
surfaces. But since this is only enabled in copy-back mode (which is
what process_image is about), the other additional surfaces accounted
for the direct rendering case can be ignored.
2016-01-26 14:05:54 +01:00
wm4
b53cb8de5e vd_lavc: delay images before reading them back
Facilitates hardware pipelining in particular with nvidia/dxva.
2016-01-25 21:46:40 +01:00
wm4
271cabe6a5 video: cleanup pts/dts passing between decoder components
Instead of using semi-public codec_pts/codec_dts fields in
struct dec_video, pass them via mp_image fields.
2016-01-25 21:46:39 +01:00
wm4
a160405284 vdpau: force driver to report preemption early
Another fix for the crazy and insane nvidia preemption behavior.

This time, the situation is that we are using vo_opengl with vdpau
interop, and that vdpau got preempted in the background while mpv was
sitting idly. This can be e.g. reproduced by using:

   --force-window=immediate --idle --hwdec=vdpau

and switching VTs. Then after switching back, load a video file.

This will not let mp_vdpau_handle_preemption() perform preemption
recovery, simply because it will do so only once vdp_decoder_create()
has been called. There are some other API calls which trigger
preemption, but many don't.

Due to the way the libavcodec API works, vdp_decoder_create() is way too
late. It does so when get_format returns. It notices creating the
decoder fails, and continues calling get_format without the vdpau
format. We could perhaps force it to reinit again (by adding a call to
vdpau.c, that checks for preemption, and sets hwdec_request_reinit), but
this seems too much of a mess.

Solve it by calling API in mp_vdpau_handle_preemption() that empirically
does trigger preemption: output_surface_put_bits_native(). This call is
useless, and in fact should be doing nothing (empty update VdpRect).
There's the slight chance that in theory it will slow down operation,
but in practice it's bound to be harmless. It's the likely cheapest and
simplest API call I've found that can trigger the fallback this way.
(The driver is closed source, so it was up to trial & error.)

Also, when initializing decoding, allow initial preemption recovery,
which is needed to pass the test mention above.
2016-01-25 16:45:18 +01:00
wm4
536efe6faf player: fix some oversights in video refactoring
vo_chain_uninit() isn't supposed to care much about the decoder
(although decoders and outputs still go strictly together, so there is
not much of an actual difference now).

Also unset track.d_video correctly.

Remove a stale declaration from dec_video.h as well.
2016-01-22 00:25:44 +01:00
wm4
f352669157 Change 3 more files to LGPL 2016-01-20 15:43:56 +01:00
wm4
a8abb53a5d vaapi: fix compilation on older FFmpeg/Libav
They don't define FF_PROFILE_VP9_0.

Fixes #2737.
2016-01-20 15:35:15 +01:00
wm4
8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
Aman Gupta
f9cefbfec4 vd_lavc: feed A53_CC side data packets into the demuxer for eia_608 decoding 2016-01-18 12:14:52 -08:00
wm4
056901b2be video: refactor: disentangle decoding/filtering some more
This moves some code related to decoding from video.c to dec_video.c,
and also removes some accesses to dec_video.c from the filtering code.

dec_video.ch is starting to make sense, and simply returns video frames
from a demuxer stream. The API exposed is also somewhat intended to be
easily changeable to move decoding to a separate thread, if we ever want
this (due to libavcodec already being threaded, I don't see much of a
reason, but it might still be helpful).
2016-01-16 22:08:39 +01:00
wm4
c9204fe3a5 video: fix interactively changing aspect ratio
The aspect ratio calculations are cached (mainly so that aspect ratio
related messages are not logged on every frame). The cache is not clared
anymore when video filters are reconfigured, but changing the
video-aspect-ratio property relied on it. Make it explicit.

Fixes #2714.
2016-01-14 09:46:11 +01:00
wm4
9a88b118b4 video: decouple filtering/decoding slightly more
Lots of noise to remove the vfilter/vo fields from dec_video.

From now on, video filtering and output will still be done together,
summarized under struct vo_chain.

There is the question where exactly the vf_chain should go in such a
decoupled architecture. The end goal is being able to place a "complex"
filter between video decoders and output (which will culminate in
natural integration of A->V filters for natural integration of
libavfilter audio visualizations). The vf_chain is still useful for
"final" processing, such as format conversions and deinterlacing. Also,
there's only 1 VO and 1 --vf option. So having 1 vf_chain for a VO seems
ideal, since otherwise there would be no natural way to handle all these
existing options and mechanisms.

There is still some work required to truly decouple decoding.
2016-01-14 00:18:48 +01:00
wm4
5722f93a74 video: refactor: shuffle code around
struct dec_video should have nothing to do with video filters or
outputs, and this huge chunk of code was somehow stuck directly in
dec_video.c.
2016-01-14 00:18:36 +01:00
wm4
bf13bd0d47 video: refactor: handle video format fixups closer to decoder
Instead of handling this on filter chain reinit, do it directly after
the decoder. This makes the code less entangled. In particular, this
gets rid of the really weird "override params" concept in the video
filter code.

The last_format/fixed_formats have some redundance with decoder_output,
but unfortunately the latter has a slightly different use.
2016-01-14 00:18:31 +01:00
wm4
671df54e4d demux: merge sh_video/sh_audio/sh_sub
This is mainly a refactor. I'm hoping it will make some things easier
in the future due to cleanly separating codec metadata and stream
metadata.

Also, declare that the "codec" field can not be NULL anymore. demux.c
will set it to "" if it's NULL when added. This gets rid of a corner
case everything had to handle, but which rarely happened.
2016-01-12 23:48:19 +01:00
Dmitrij D. Czarkoff
ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4
9acea8759b dxva2: log more debug infos
Dump the complete list of decoders and image formats. If it's a decoder
we know, add a stringified name.
2016-01-11 16:24:13 +01:00
wm4
2a80680d95 Fix build on older libavcodec versions
avcodec_profile_name() was added only a week ago or so.
2016-01-08 17:19:04 +01:00
wm4
12b4f177ec vd_lavc: log codec profile when attempting hardware decoding
Should be useful.
2016-01-08 09:22:25 +01:00
BtbN
5790bbba61 vaapi: add VP9 profile entires 2015-12-20 10:40:06 +01:00
wm4
0a0bb9059f video: switch from using display aspect to sample aspect
MPlayer traditionally always used the display aspect ratio, e.g. 16:9,
while FFmpeg uses the sample (aka pixel) aspect ratio.

Both have a bunch of advantages and disadvantages. Actually, it seems
using sample aspect ratio is generally nicer. The main reason for the
change is making mpv closer to how FFmpeg works in order to make life
easier. It's also nice that everything uses integer fractions instead
of floats now (except --video-aspect option/property).

Note that there is at least 1 user-visible change: vf_dsize now does
not set the display size, only the display aspect ratio. This is
because the image_params d_w/d_h fields did not just set the display
aspect, but also the size (except in encoding mode).
2015-12-19 20:45:36 +01:00
wm4
565efeeada vd_lavc: fix avctx NULL checks
If reinit after a fallback from hardware fails, this field can be NULL.
The check in control() was broken due to a typo (found by Coverity), and
decode() lacked the check entirely.
2015-12-05 23:53:55 +01:00
wm4
344d44681e video: readd codec delay estimation
Approximately reverts commit 3ccac74d. This failed with some avi files,
which do pseudo-VFR by sending packets with empty frames (or repeat
frames, depending on point of view). Specifically, these packets are not
0 bytes, so they don't get skipped by libavformat, as with the usual VFR
avi hack. Instead, the packet contains a VOP with vop_coded=0, so
libavcodec will just return no frame. We could probably distinguish such
skipped frames and delayed frames by explicitly measuring the codec
delay by counting how long it takes to get the very first frame (and
then treat skips as explicit drops), but we may as well simply reinstate
the old code.

To appease to at least one semi-broken case, do not enable this logic on
the RPI, as the FFmpeg MMAL wrapper has arbitrary buffering (and MMAL
itself is asynchronous).
2015-12-02 14:38:47 +01:00
wm4
52af1f72e2 dxva2: reject 10 bit HEVC
10 bit HEVC would require DXVA2_ModeHEVC_VLD_Main10, and most a
different surface type (judging by lavfsplitter source code, both
P010 and P016 would work). Since I'm unable to test this stuff,
exclude 10 bit for now.

See #2516.
2015-11-23 12:38:06 +01:00
wm4
0ec35fa111 videotoolbox: make decoder format customizable
Because apparently there's no ideal universally working format.

The weird OpenGL texture format for kCVPixelFormatType_32BGRA is from:

http://stackoverflow.com/questions/22077544/draw-an-iosurface-to-an-opengl-context

(Which apparently got it from the linked Apple example code.)
2015-11-17 21:21:19 +01:00
wm4
9a6ec9de2f vd_lavc: be more careful with flushing the decoder
Until now, we've relied on the following things:

- you can send flush packets to the decoder even if it's fully flushed,
- you can send new packets to a flushed decoder,
- you can send new packers to a partially flushed decoder.

("flushing" refers to sending flush packets to the decoder until the
decoder does not return new pictures, not avcodec_flush_buffers().)

All of these are questionable. The libavcodec API probably doesn't
guarantee that these work well or at all, even though most decoders have
no issue with these. But especially with hardware decoding wrappers
(like MMAL), real problems can be expected. Isolate us from these corner
cases by handling them explicitly.
2015-11-10 16:06:42 +01:00
wm4
b2a3e877c0 video: increase avi pts buffer size
When decoding on RPI/MMAL, the buffering between decoder input and
output can be quite excessive.
2015-11-06 17:06:32 +01:00
wm4
2cf9ee989c rpi: add support for codecs other than h264
FFmpeg now supports h264 and mpeg2. At least vc-1 will probably follow.
2015-11-05 17:24:35 +01:00
wm4
163c6ad862 vd_lavc: make hwdec fallback more tolerant
A hw decoder might fail to decode a frame for multiple reasons, and not
always just because decoding is impossible. We can't generally
distinguish these reasons well. Make it more tolerant by accepting
failures of 3 frames, but not more. The threshold can be adjusted by the
repurposed --vd-lavc-software-fallback option.

(This behavior was suggested much earlier in some PR, but at the time
the "proper" hwdec fallback was indistinguishable from decoding error.
With the current situation, "proper" fallback is still instantious.)
2015-11-03 14:03:02 +01:00
wm4
1d2d649281 vdpau: fix uninit when init fails
The uninit() function was called twice if the uninit() function failed
(once by init(), once by vd_lavc.c code), which caused crashes due to
double-free. (This failure is a corner case, and all other hwdec
backends appear to handle this case gracefully.)

I do not think this code should be able to deal with uninit() being
called other than once. Guarantee that it's called exactly once.
2015-11-01 23:03:02 +01:00
wm4
3dec68ba47 vd_lavc: fix declarations
Fixes linker failure. How did this ever work? Apparently it did most of
the time, but apparently we just got the first case where it didn't.

Fixes #2433.
2015-10-30 09:41:55 +01:00
Rodger Combs
d6e7190836 vd_lavc: make software decoding fallback an option 2015-10-25 15:21:11 +01:00
wm4
50f8548b2f vd_lavc: attempt to fallback from hwdec before anything is decoded
The previous commit moved the av_frame_unref() after the got_picture
check. This accidentally also deferred the software fallback
reinitialization to until a software picture was decoded (instead of the
exact time of the fallback), which is not ideal.

Just rely on the fact that calling av_frame_unref() on a frame is ok
even if nothing was decoded.
2015-10-19 18:19:57 +02:00
wm4
0ab6031d76 vd_lavc: continue decoding properly after decoding failure
Commit 12cd48a8 started setting the hwdec_failed field even if hwdec was
not active, and because it also checked this field even if hwdec was not
active, broke decoding forever.

Fix this, and also avoid a memory leak or API misuse by releasing the
decoded picture. Passing an unreleased frame to the decoder has as far
as I know no defined effects.
2015-10-19 17:49:30 +02:00
wm4
8d004f07a4 vd_lavc: work around libavcodec nonsense causing hwdec init failure
The libavcodec h264 decoder contains some idiotic code with unknown
purpose (no sample or explanation known that necessitates its
existence), that causes the AVCodecContext.get_format callback to be
invoked at a time when hwaccels can't be initialized. By definition, the
get_format callback is supposed to initialize hwaccels (another idiotic
thing now part of the API, but different story). This causes hwdec
initialization sometimes to fail (WolfensteinTwitch.mp4): the first
get_format callback will mark it as failed, so the second get_format
(the "proper" normal one) will not bother restoring the state, and hwdec
init fails.

While this should be fixed in libavcodec (good luck with that), it's
quite easy to workaround.
2015-10-12 21:24:25 +02:00
wm4
9e7069fde2 vd_lavc: refuse to initialize vaapi with unknown profiles
Bad idea, although I'm not sure how harmful it actually was.

Although this is common code, only the vaapi hwaccel still uses it.
2015-10-11 18:48:02 +02:00
wm4
b4804a4b26 video: fix base for --no-correct-pts
Use the first encountered packet PTS/DTS as base, instead of the last
one. This does not add the amount of frames buffered in the codec to the
PTS offset, and thus is better.

Also, don't add the frame time if there was no decoded frame yet. The
first frame should obviously have the timestamp of the first packet
(going by this heuristic).
2015-10-06 18:19:20 +02:00
wm4
5015759334 video: increase maximum number of buffered AVI pts samples
While b-frame reordering limits the maximum required number to around
16, the number of additionally buffered frames can be much higher.

Guess when this actually matters? (For the libavcodec MMAL wrapper.)
2015-10-06 18:19:20 +02:00
wm4
3c292395ca video: don't sort AVI pts samples
It's obviously not needed, and only an artifact of the old PTS
determination code.
2015-10-06 18:19:20 +02:00
wm4
8e654d3f78 video: remove user-controllable PTS sorting (--pts-association-mode)
Useless. Sometimes it might be useful to make some extremely broken
files work, but on the other hand --no-correct-pts is sufficient for
these cases.

While we still need some of the code for AVI, the "auto" mode in
particular inflated the size of the code.
2015-10-06 18:19:20 +02:00
wm4
0e245b3752 video: disable framedrop if avi-style timestamps are used
This can't be handled correctly at all. Other cases when the decoder
might drop a frame (such as completely failing to decode a frame) will
shift timestamps by a frame, and it can't be avoided.

While we could maybe find a better way to handle this with libavcodec's
main decoders, this seems to be much harder if it should work with
certain HW decoders, which don't passthrough the DTS field (such as
MMAL). Another problem are .avi files with b-frames. So just leave it
as it is.
2015-10-06 18:18:57 +02:00
wm4
3ccac74de2 video: remove codec delay estimation
This was used only by the timestamp sorting code, which is a fallback
for avi files (as well as avi-muxed mkv files). This was supposed to
prevent accumulating timestamps in case the decoder consumes more
packets than it outputs frames (i.e. frames are dropped). This didn't
work very well (timestamps could be off by a large amount), the
estimation of the delay was fragile, and the interdependencies with the
decoder were annoying, so kill it.
2015-10-03 22:10:44 +02:00
wm4
ee283843fa video: cosmetics: remove trailing whitespace 2015-10-03 21:21:27 +02:00
wm4
12cd48a8a9 Revert "vd_lavc: do not abort hardware decoding on errors"
This essentially reverts commit 009dfbe3. FFmpeg VideoToolbox support
is being wacky, and can cause major issues, such as not being able
to decode a single frame. (E.g. by playing a .ts file. This should be
fixed in FFmpeg eventually.)

This is not a straight revert of the commit; just a functional one. We
keep the slightly simpler code structure.
2015-09-28 22:31:47 +02:00
wm4
1dd7b7bddc video: remove VDA support
VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no
reason to support VDA anymore. In fact, we had a bug that made VDA not
useable with older FFmpeg versions in some newer mpv releases.

VideoToolbox is supported even on slightly older OSX versions, and if
not, you still can run mpv without hw decoding.
2015-09-28 22:03:14 +02:00
wm4
15ef9f9ee6 vd_lavc: remove some ancient cargo-culting
Definitely not needed anymore, and fixes a crash in some weird corner-
cases.

The extradata freeing is apparently still needed, though. (Because a
codec context can be opened again, which makes no sense, but ok.)
2015-09-28 22:03:14 +02:00
wm4
710872bc22 vaapi: remove dependency on X11
There are at least 2 ways of using VAAPI without X11 (Wayland, DRM).
Remove the X11 requirement from the decoder part and the EGL interop.
This will be used by a following commit, which adds Wayland support.

The worst about this is the decoder part, which includes a bad hack for
using the decoder without any VO interop (also known as "vaapi-copy"
mode). Separate the X11 parts so that they're self-contained. For the
EGL interop code we do something similar (it's kept slightly simpler,
because it essentially only has to translate between our silly
MPGetNativeDisplay abstraction and the vaGetDisplay...() call).
2015-09-27 21:33:15 +02:00
wm4
0ae8aebb89 video: refactor GPU memcpy usage
Make the GPU memcpy from the dxva2 code generally useful to other parts
of the player.

We need to check at configure time whether SSE intrinsics work at all.
(At least in this form, they won't work on clang, for example. It also
won't work on non-x86.)

Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some
awkward stuff to share the existing code used by mp_image_copy(). I'm
hoping that FFmpeg will sooner or later provide a function like this, so
we can remove most of this again. (There is a patch, bit it's stuck in
limbo since forever.)

All this is used by the following commit.
2015-09-25 19:18:16 +02:00
Philip Langdale
361040f9d9 vd_lavc: Fix recovery from vdpau preemption
Flushing buffers, and thereby triggering decoder reinitialisation
needs to happen before attempting, and failing, to decode.
2015-09-25 17:29:44 +02:00
wm4
009dfbe3b6 vd_lavc: do not abort hardware decoding on errors
Usually, libavcodec ignores errors reported by the hardware decoding
API, so it's not like we can actually escape if the hardware is somehow
acting up.

For normal fallback purposes, or if parts of the hw decoding API which
we actually check fails, we do this by setting and checking the
hwdec_failed flag anyway.
2015-09-23 20:37:47 +02:00
wm4
4d6c1be7b6 vd_lavc: minor cleanup to hwdec fallback code
The comment was largely outdated, and described the old situation when
we used a "violent" fallback by making get_buffer2 fail completely.

Also, for the case when the hw decoder initialization succeeded (in
get_format), but get_buffer2 for some reason requests something
unexpected, we also can fallback more gracefully and in the same way.
2015-09-23 14:20:50 +02:00
Kevin Mitchell
269f271b73 video: make --field-dominance set interlaced flag
fixes #2289
2015-09-10 23:46:06 -07:00
wm4
61b902f5a7 vd_lavc: better hwdec log output
Often, we don't know whether hardware decoding will work until we've
tried. (This used to be different, but API changes and improvements in
libavcodec led to this situation.) We will often output that we're going
to use hardware decoding, and then print a fallback warning.

Instead, print the status once we have decoded a frame.

Some of the old messages are turned into verbose messages, which should
be helpful for debugging. Also add some new ones.
2015-09-02 23:33:13 +02:00
wm4
11f44a10f9 vd_lavc: factor all hwdec fallbacks into the same function
The fallback at initialization time was basically duplicated, maybe for
the sake of showing a different error message. This doesn't matter
anymore; not much can fail at initialization anymore. Most meaningful
and common errors happen either at probing or in get_format (when the
actual hw decoder is initialized).
2015-09-02 23:10:39 +02:00
wm4
82f0d373fb video: make container vs. bitstream aspect ratio configurable
Utterly idiotic bullshit.

Fixes #2259.
2015-08-30 23:04:17 +02:00
wm4
1ec1b4186c vd_lavc: bump number of allocated surfaces for hwdec with HEVC 2015-08-24 23:02:40 +02:00
wm4
2172c22ee3 vaapi: add HEVC profile entries
libavcodec does not support HEVC via VAAPI yet, so this won't work.
However, there is ongoing work to add HEVC support to VAAPI, and this
change might help with testing. (Or maybe not - but there is no harm in
this change.)
2015-08-24 23:00:45 +02:00
wm4
bffd78748f vd_lavc: remove unneeded hwdec parameters
All hwdec backends now use a single pixel format, and the format is
always checked.

Also, the init_decoder callback is now mandatory.
2015-08-19 21:33:18 +02:00
wm4
6894858bf2 video: fix VideoToolbox/VDA autodetection
This affects vo_opengl_cb in particular: it'll most likely auto-load
VDA, and then the VideoToolbox decoder won't work. And everything fails.

This is mainly caused by FFmpeg using separate pixfmts for the _same_
thing (CVPixelBuffers), simply because libavcodec's architecture demands
that hwaccel backends are selected by pixfmts. (Which makes no sense,
but now we have the mess.)

So instead of duplicating FFmpeg's misdesign, just change the format to
our own canonical one on the image output by the decoder. Now the GL
interop code is exactly the same for VDA and VT, and we use the VT name
only.
2015-08-17 23:51:31 +02:00
wm4
8d66bd76e2 video: remove old vdpau hwaccel API usage
While the "old" libavcodec vdpau API is not deprecated (only the very-
old API is), it's still relatively complicated code that badly
duplicates the much simpler newer vdpau code. It exists only for the
sake of older FFmpeg releases; get rid of it.
2015-08-10 00:07:35 +02:00
Sebastien Zwickert
31b5a211f4 hwdec: add VideoToolbox support
VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working.
The code needs libavcodec support which was added recently (to FFmpeg git,
libav doesn't support it).

Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
2015-08-05 17:47:30 +02:00
wm4
41101c2996 win32: revert wchar_t changes
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"

Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
2015-08-01 21:09:11 +02:00
wm4
fefac2c941 win32: more wchar_t -> WCHAR replacements
This was essentially missing from commit 0b52ac8a.

Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.

For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
2015-07-30 21:50:11 +02:00
wm4
281c21b7f1 video: don't restrict --vd-lavc-threads to a maximum of 16
Only do it when the number of threads is autodetected, as more than 16
threads are still considered not recommended. (libavcodec prints a
warning.)
2015-07-23 17:17:26 +02:00