summaryrefslogtreecommitdiffstats
path: root/video/decode/vd_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* vd_lavc: let hardware decoder request delaying frames explicitlywm42016-04-071-4/+1
| | | | | | | | | | 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.
* vd_lavc: fix codec vs. decoder confusionwm42016-04-071-13/+14
| | | | | | | | | | 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).
* demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API changewm42016-03-311-2/+1
| | | | | | | | | 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.
* vd_lavc: add d3d11va hwdecKevin Mitchell2016-03-301-0/+4
| | | | | | 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.
* Add a mediacodec decoder hwdec wrapperJan Ekström2016-03-251-0/+4
| | | | | Does the same thing as the rpi one - makes fallback possible by pretending that h264_mediacodec is a hwdec.
* vd_lavc: mediacodec also needs special timebase loveJan Ekström2016-03-251-1/+1
|
* ad_lavc, vd_lavc: support new Libav decoding APIwm42016-03-241-3/+18
| | | | For now only found in Libav.
* vd_lavc: slightly improve codec_timebase hackwm42016-03-241-4/+3
| | | | | | 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.
* vd_lavc: don't get into an endless loop if decoding failswm42016-03-181-0/+2
| | | | Regression since commit 6640b22a.
* av_common: explicitly exclude _vdpau deccoders from enumerationwm42016-03-021-11/+0
| | | | | | | | | | 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.
* vd_lavc: simplify hwdec pixfmt checkwm42016-02-201-1/+1
| | | | | Instead of checking whether the format is a hwaccel format, check whether it's the exact format we've requested for hardware decoding.
* video: allow the decoder to consume packets partiallywm42016-02-191-0/+5
| | | | | | | | | | | | | | | | | | | | 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.)
* dxva2: add interop (non-copyback) hwdec_typeKevin Mitchell2016-02-171-0/+2
| | | | | This always falls back to software decoding right now. VO support will be added in future commits.
* audio/video: expose codec info as separate fieldwm42016-02-151-4/+3
| | | | | Preparation for the timeline rewrite. The codec will be able to change, the stream header not.
* video: approximate AVI timestamps via DTS handlingwm42016-02-111-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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".
* vd_lavc: fix use after free in some hwdecsKevin Mitchell2016-02-061-8/+3
| | | | | | | | | | | | | | fd339e3f53996efd2dae9525990da433d1e1bf89 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>
* vd_lavc: avoid calling flush on an unopened AVCodecContextwm42016-02-051-6/+9
| | | | | | | 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.
* vd_lavc: remove redundant best_csp fieldwm42016-02-031-14/+3
| | | | And some other simplifications.
* vd_lavc: force microsecond timestamps on RPIwm42016-02-031-3/+8
| | | | | | | | | | 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).
* vd_lavc: release surfaces before destroying decoderwm42016-01-301-4/+3
| | | | | | | | | | 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).
* vd_lavc: allow switching between hw/sw decoding any timewm42016-01-291-21/+33
| | | | | | | 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.
* vd_lavc: simplify an aspect of hwdec fallbackwm42016-01-291-9/+4
| | | | | | 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.
* vd_lavc: delay images before reading them backwm42016-01-251-7/+42
| | | | Facilitates hardware pipelining in particular with nvidia/dxva.
* video: cleanup pts/dts passing between decoder componentswm42016-01-251-7/+10
| | | | | Instead of using semi-public codec_pts/codec_dts fields in struct dec_video, pass them via mp_image fields.
* vd_lavc: feed A53_CC side data packets into the demuxer for eia_608 decodingAman Gupta2016-01-181-0/+11
|
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-12/+13
| | | | | | | | | | 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.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* Fix build on older libavcodec versionswm42016-01-081-0/+2
| | | | avcodec_profile_name() was added only a week ago or so.
* vd_lavc: log codec profile when attempting hardware decodingwm42016-01-081-0/+4
| | | | Should be useful.
* video: switch from using display aspect to sample aspectwm42015-12-191-6/+2
| | | | | | | | | | | | | | | | 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).
* vd_lavc: fix avctx NULL checkswm42015-12-051-1/+4
| | | | | | 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.
* video: readd codec delay estimationwm42015-12-021-0/+13
| | | | | | | | | | | | | | | | | 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).
* vd_lavc: be more careful with flushing the decoderwm42015-11-101-5/+21
| | | | | | | | | | | | | | | | | 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.
* rpi: add support for codecs other than h264wm42015-11-051-1/+1
| | | | FFmpeg now supports h264 and mpeg2. At least vc-1 will probably follow.
* vd_lavc: make hwdec fallback more tolerantwm42015-11-031-6/+13
| | | | | | | | | | | | 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.)
* vdpau: fix uninit when init failswm42015-11-011-0/+1
| | | | | | | | | | 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.
* vd_lavc: fix declarationswm42015-10-301-6/+6
| | | | | | | 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.
* vd_lavc: make software decoding fallback an optionRodger Combs2015-10-251-1/+5
|
* vd_lavc: attempt to fallback from hwdec before anything is decodedwm42015-10-191-4/+4
| | | | | | | | | | 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.
* vd_lavc: continue decoding properly after decoding failurewm42015-10-191-3/+7
| | | | | | | | | | 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.
* vd_lavc: work around libavcodec nonsense causing hwdec init failurewm42015-10-121-0/+3
| | | | | | | | | | | | | | | | 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.
* vd_lavc: refuse to initialize vaapi with unknown profileswm42015-10-111-3/+1
| | | | | | Bad idea, although I'm not sure how harmful it actually was. Although this is common code, only the vaapi hwaccel still uses it.
* video: remove codec delay estimationwm42015-10-031-7/+0
| | | | | | | | | | 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.
* Revert "vd_lavc: do not abort hardware decoding on errors"wm42015-09-281-0/+1
| | | | | | | | | | 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.
* video: remove VDA supportwm42015-09-281-4/+0
| | | | | | | | | 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.
* vd_lavc: remove some ancient cargo-cultingwm42015-09-281-1/+0
| | | | | | | | 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.)
* vd_lavc: Fix recovery from vdpau preemptionPhilip Langdale2015-09-251-3/+3
| | | | | Flushing buffers, and thereby triggering decoder reinitialisation needs to happen before attempting, and failing, to decode.
* vd_lavc: do not abort hardware decoding on errorswm42015-09-231-8/+7
| | | | | | | | | | 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.
* vd_lavc: minor cleanup to hwdec fallback codewm42015-09-231-15/+8
| | | | | | | | | 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.
* vd_lavc: better hwdec log outputwm42015-09-021-4/+16
| | | | | | | | | | | | 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.
* vd_lavc: factor all hwdec fallbacks into the same functionwm42015-09-021-24/+19
| | | | | | | | 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).
* video: make container vs. bitstream aspect ratio configurablewm42015-08-301-5/+5
| | | | | | Utterly idiotic bullshit. Fixes #2259.
* vd_lavc: bump number of allocated surfaces for hwdec with HEVCwm42015-08-241-1/+4
|
* vd_lavc: remove unneeded hwdec parameterswm42015-08-191-8/+5
| | | | | | | All hwdec backends now use a single pixel format, and the format is always checked. Also, the init_decoder callback is now mandatory.
* hwdec: add VideoToolbox supportSebastien Zwickert2015-08-051-0/+4
| | | | | | | | 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>
* video: don't restrict --vd-lavc-threads to a maximum of 16wm42015-07-231-1/+1
| | | | | | Only do it when the number of threads is autodetected, as more than 16 threads are still considered not recommended. (libavcodec prints a warning.)
* video: replace our own refcounting with libavutil'swm42015-07-051-8/+5
| | | | | | | | | | | | | | | | | | | | | | mpv had refcounted frames before libav*, so we were not using libavutil's facilities. Change this and drop our own code. Since AVFrames are not actually refcounted, and only the image data they reference, the semantics change a bit. This affects mainly mp_image_pool, which was operating on whole images instead of buffers. While we could work on AVBufferRefs instead (and use AVBufferPool), this doesn't work for use with hardware decoding, which doesn't map cleanly to FFmpeg's reference counting. But it worked out. One weird consequence is that we still need our custom image data allocation function (for normal image data), because AVFrame's uses multiple buffers. There also seems to be a timing-dependent problem with vaapi (the pool appears to be "leaking" surfaces). I don't know if this is a new problem, or whe