aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/decode
Commit message (Collapse)AuthorAge
* vd_lavc: minor simplification for get_format fallbackGravatar wm42018-05-25
| | | | | | | | | | | 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.
* vd_lavc: enable dr by defaultGravatar wm42018-04-29
| | | | | I had this enabled for quite a while and experienced no issues. I'm not aware of other issues either.
* vd_lavc: slightly better logging about why hwdec is not usedGravatar wm42018-03-08
| | | | | The old message was outdated and also not very precise. Make it all a bit more elaborate.
* vd_lavc: fix inverted conditionGravatar wm42018-03-03
|
* Fix recent FFmpeg deprecationsGravatar wm42018-02-13
| | | | | | | | | 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.
* vd_lavc: fix stall with some uses of --hwdec=copyGravatar wm42018-02-05
| | | | | | | | | | | 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.
* vd_lavc: fix recently broken hardware decode fallbackGravatar wm42018-02-04
| | | | | | | | | 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.
* video: make decoder wrapper a filterGravatar wm42018-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* video: minor simplificationGravatar wm42018-01-25
| | | | | The check is redundant - if removed, it will write the same value, so it's a NOP.
* video: warn user against FFmpeg's liesGravatar wm42018-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* video: change some remaining vo_opengl mentions to vo_gpuGravatar Akemi2018-01-20
|
* video: avoid some unnecessary vf.h includesGravatar wm42018-01-18
|
* video: change some mp_image_pool semanticsGravatar wm42018-01-13
| | | | | | | | | | 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.
* video, audio: don't actively wait for demuxer inputGravatar wm42018-01-09
| | | | | | | | | | | | 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.
* video, audio: always read all frames before getting next packetGravatar wm42018-01-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux_mkv: add hack to pass along x264 version to decoderGravatar wm42017-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* vd_lavc: add an option to explicitly workaround x264 4:4:4 bugGravatar wm42017-12-28
| | | | | | 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.
* vd_lavc: fix crash with RPI hwdecGravatar wm42017-12-28
| | | | | | If you use vo_rpi, this could crash, because hwdec_devs is NULL. Untested. Fixes #5301.
* options: drop some previously deprecated optionsGravatar wm42017-12-25
| | | | | | | | 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.
* Restore Libav supportGravatar wm42017-12-21
| | | | | | | | | | | 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.
* msg: reinterpret a bunch of message levelsGravatar Niklas Haas2017-12-15
| | | | | | | | | | | | | | | | | | | | | | 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.
* vd_lavc: rename --hwdec=rpi to --hwdec=mmalGravatar wm42017-12-15
| | | | | | 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.
* vd_lavc: use libavcodec metadata for hardware decoder wrappersGravatar wm42017-12-15
| | | | | This removes the need to keep an explicit list and to attempt to parse codec names. Needs latest FFmpeg git.
* vd_lavc: always load VO interops with non-copy hw decodersGravatar wm42017-12-11
| | | | | | | | 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.
* vd_lavc: add rkmpp to the hwdec_wrappers array.Gravatar LongChair2017-12-10
| | | | Allows to get the hwdec picked up properly by mpv on rockchip devices
* vd_lavc: don't request native pixfmt with -copy and METHOD_INTERNALGravatar wm42017-12-02
| | | | | | | | | 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.
* vd_lavc, vdpau, vaapi: restore emulated API avoidanceGravatar wm42017-12-02
| | | | | | 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.
* vd_lavc: simpler way to check for opque hw frameGravatar wm42017-12-02
| | | | The ->fmt shit is something I'd like to phase out.
* vd_lavc: sort -copy hwdec modes to end of listGravatar wm42017-12-02
| | | | | | | | | | | | | | | 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).
* vd_lavc: allow forcing single implementations with --hwdecGravatar wm42017-12-02
|
* vd_lavc: slightly simplifyGravatar wm42017-12-02
| | | | | | 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.
* vd_lavc: coding styleGravatar wm42017-12-02
|
* vd_lavc: fix dumb nonsenseGravatar wm42017-12-01
|
* vd_lavc, mp_image: remove weird mpv specific palette constantGravatar wm42017-12-01
| | | | | Was for times when we were trying to be less dependent on libav* I guess.
* vd_lavc: merge redundant headerGravatar wm42017-12-01
| | | | This is not needed anymore.
* vd_lavc: rewrite how --hwdec is handledGravatar wm42017-12-01
| | | | | | | | | | | | | | | | 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).
* vd_lavc: drop mediacodec direct rendering support temporarilyGravatar wm42017-12-01
| | | | | | | | | | | | 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.
* video: move d3d.c out of decode sub directoryGravatar wm42017-12-01
| | | | | | 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.
* vd_lavc: delete hw_d3d11va.c/hw_dxva2.c and merge leftoversGravatar wm42017-12-01
| | | | | | 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).
* hw_dxva2: move dxva2 code to d3d.cGravatar wm42017-12-01
| | | | This source file will disappear, so just collect the leftovers in d3d.c.
* video: refactor hw device creation for hwdec copy modesGravatar wm42017-12-01
| | | | | | | | | | 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.
* vd_lavc: move entrypoint for hwframes_refineGravatar wm42017-12-01
| | | | | | | 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.
* vd_lavc: remove process_image callbackGravatar wm42017-12-01
| | | | Now unused.
* d3d11: move code for d3d11eglrgb hackGravatar wm42017-12-01
|
* vo_gpu: make it possible to load multiple hwdec interop driversGravatar wm42017-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vd_lavc: prefer nvdec over vdpau with --hwdec=autoGravatar wm42017-11-30
| | | | | | | | | | | | | | | | 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).
* vd_lavc: restore --hwdec-image-format and d3d11 opaque modeGravatar wm42017-11-02
| | | | | When the ifdeffery for the frame_params API was added, the new code accidentally didn't include this.
* vd_lavc: clean out more hwdec legacy codeGravatar wm42017-10-31
| | | | | | | | 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.)
* vd_lavc: remove more dead legacy codeGravatar wm42017-10-31
| | | | | | | | | | | | | | 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.
* videotoolbox: use generic code for dummy hwdevice initGravatar wm42017-10-31
| | | | | And move the remaining code (just 2 struct constant definitions) to vd_lavc.c.