summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: support for vda hardware decodingStefano Pigozzi2013-12-021-0/+3
| | | | | | | | | | | The harder work was done in the previous commits. After that this feature comes out almost for free. The only problem is I can't get the textures created with CGLTexImageIOSurface2D to download properly, thus the code performs download using some CoreVideo APIs. If someone knows why download of textures created with CGLTexImageIOSurface2D doesn't work please contact me :)
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-292-9/+9
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* vdpau: always let decoder output IMGFMT_VDPAUwm42013-11-291-0/+1
| | | | | | | | | | The old ffmpeg vdpau support code uses separate vdpau pixel formats for each decoder (pretty much because mplayer's architecture sucked), which just gets into the way. Force the old decoder's output to IMGFMT_VDPAU, and remove IMGFMT_IS_VDPAU() where we can remove it. This should completely remove the differences betwene the old and new vdpau decoder outside of the decoder.
* vaapi: remove unused hw image formats, simplifywm42013-11-291-2/+2
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
* build: make pthreads mandatorywm42013-11-281-7/+1
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-281-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* video: warn against non-monotonic PTS instead of decreasing PTSwm42013-11-281-2/+2
| | | | And by non-monotonic, we mean "strictly non-monotonic".
* video: add heuristic to prevent framedrop during hrseek if pts brokenwm42013-11-282-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Using --start with files that use DTS only, or which simply have broken PTS timestamps, would incorrectly drop frames and possibly not execute the seek correctly. Add yet another heuristic to detect this. The intent is that --start and hr-seeks in general should work correctly, but in order to keep things fast, we still want to allow frame dropping during hr-seek if there are no problems doing so. Do this by disabling frame dropping by default, but re-enabling it if there are no problems found for a while. As a consequence, --start might be somewhat slower, but normal user interaction should remain as fast as before. Note that there's something subtle about the added code: the has_broken_packet_pts field is checked even before the first packet is fed to dec_video.c, so the field must not be set to 0 right on start. It's not initially set to 0 anyway, because the heuristic requires decoding some images before enabling frame drop anyway. Note 2: it's not clear whether frame dropping during hr-seek really helps; I didn't benchmark it.
* video: replace d_video->pts field, change PTS jump checkswm42013-11-272-5/+6
| | | | | | | | | | | | | The d_video->pts field was a bit strange. The code overwrote it multiple times (on decoding, on filtering, then once again...), and it wasn't really clear what purpose this field had exactly. Replace it with the mpctx->video_next_pts field, which is relatively unambiguous. Move the decreasing PTS check to dec_video.c. This means it acts on decoder output, not on filter output. (Just like in the previous commit, assume the filter chain is sane.) Drop the jitter vs. reset semantics; the dec_video.c determined PTS never goes backwards, and demuxer timestamps don't "jitter".
* video: if PTS is missing, make something up using the frameratewm42013-11-271-3/+7
| | | | | | Also get rid of the PTS check _after_ filters. This means if there's a video filter which unsets PTS, no warning will be printed. But we assume that all filters are well-behaved enough by now.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-273-70/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the PTS handling code to make it cleaner, and to separate the bits that use PTS sorting. Add a heuristic to fall back to DTS if the PTS us non-monotonic. This code is based on what FFmpeg/Libav use for ffplay/avplay and also best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non- monotonic, but DTS is sorted. The code is pretty much the same as in Libav [1]. I'm not sure if all of it is really needed, or if it does more than what the paragraph above mentions. But maybe it's fine to cargo-cult this. This heuristic fixes playback of mpeg4 in ogm, which returns packets with PTS==DTS, even though the PTS timestamps should follow codec reordering. This is probably a libavformat demuxer bug, but good luck trying to fix it. The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit inelegant, but maybe better than trying to mess the PTS back into the decoder callback again. [1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
* Move some code from player to audio/video reset functionswm42013-11-271-0/+7
|
* cosmetics: rename video/audio reset functionswm42013-11-274-10/+10
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* video: remove commented codewm42013-11-271-13/+2
|
* video: use dts as fallback when determining pts by sortingwm42013-11-271-11/+10
| | | | | This makes the new code equivalent with the old one, which often passed dts as pts. Also rename some variables to clear up things.
* video: unbreak --no-correct-pts with demuxers that use DTSwm42013-11-262-4/+6
|
* video: move timestamp determination code to dec_videowm42013-11-252-0/+44
| | | | | | | | | | This means the code that tries to figure out the timestamp from demuxer and decoder output is now all in dec_video.c. We set the final timestamp on the returned image (mp_image.pts), as well as the d_video->pts field. The way the player uses d_video->pts field is still a bit messy. Maybe this could be cleaned up later.
* video: disable PTS sorting fallback by defaultwm42013-11-251-2/+3
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux: export dts from demux_lavf, use it for aviwm42013-11-251-4/+1
| | | | | | | | | Having the DTS directly can be useful for restoring PTS values. The avi file format doesn't actually store PTS values, just DTS. An older hack explicitly exported the DTS as PTS (ignoring the [I assume] genpts generated non-sense PTS), which is not necessary anymore due to this change.
* player: merge no-correct-pts with correct-pts codewm42013-11-252-0/+4
| | | | | | Now the --no-correct-pts mode is like the normal mode, just with different timestamp calculations. The semantics should be about the same as before this commit.
* player: change semantics of --no-correct-ptswm42013-11-251-1/+0
| | | | | | | | | | | | | Before this commit, this mode estimated the frame time by subtracting successive packet PTS values. This is complete non-sense for video codecs which use reordering. The code compensated frame times for these non-sense using the FPS value, but confused the rest of the player with non-sense jumping around timestamps. So, all in all this mode is not very useful. Repurpose this mode for fixed frame rate playback. This gives almost the same behavior as the old mode with forced framerate (--fps option). The result is simpler and often more robust.
* dec_video: fix function signaturewm42013-11-252-4/+6
| | | | Just why...? And why did this take 7 years?
* video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFramewm42013-11-254-17/+22
| | | | | | | | | | | | | | | Instead of passing the PTS as separate field, pass it as part of the usual data structures. Basically, this removes strange artifacts from the API. (It's not finished, though: the final decoded PTS goes through strange paths, and filter_video() finally overwrites the decoded mp_image's pts field with it.) We also stop using libavcodec's reordered_opaque fields, and use AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because these pts fields are not "really" opaque anymore, yet we treat them as such. But the end result should be the same, and reordered_opaque is marked as partially deprecated (it's not clear whether it's really deprecated).
* vd_lavc: improve a commentwm42013-11-241-1/+2
|
* vd_lavc: when falling back to software, revert filter error statuswm42013-11-231-0/+2
| | | | | | | | | | | | | | | | | | | When mpv is started with some video filters set (--vf is used), and hardware decoding is requested, and hardware decoding would be possible, but is prevented due to video filters that accept software formats only, the fallback didn't work properly sometimes. This fallback works rather violently: it tries to initialize the filter chain, and if it fails it throws away the frame decoded using the hardware, and retries with software. The case that didn't work was when decoding the current packet didn't immediately lead to a new frame. Then the filter chain wouldn't be reinitialized, and the playloop would stop playback as soon as it encounters the error flag. Fix this by resetting the filter error flag (back to "uninitialized"), which is a rather violent, but somewhat working solution. The fallback in general should perhaps be cleaned up later.
* Attempt to fix build on older libavcodec versionswm42013-11-232-0/+2
|
* video: don't overwrite demuxer FPS valuewm42013-11-231-1/+1
| | | | | | | | | | | | | | | | If the --fps option was given (MPOpts->force_fps), the demuxer FPS value was overwritten with the forced value. This was fine, since the demuxer value wasn't needed anymore. But with the recent changes not to write to the demuxer stream headers, we don't want to do this anymore. So maintain the (forced/updated) FPS value in dec_video->fps. The removed code in loadfile.c is probably redundant, and an artifact from past refactorings. Note that sub.c will now always use the demuxer FPS value, instead of the user override value. I think this is fine, because it used the demuxer's video size values too. (And it's rare that these values are used at all.)
* video: move handling of container vs. stream AR out of vd_lavc.cwm42013-11-234-39/+34
| | | | | | | Now the actual decoder doesn't need to care about this anymore, and it's handled in generic code instead. This simplifies vd_lavc.c, and in particular we don't need to detect format changes in the old way anymore.
* dec_video: make vf_input and hwdec_info statically allocatedwm42013-11-233-7/+5
| | | | | | | | | | | The only reason why these structs were dynamically allocated was to avoid recursive includes in stheader.h, which is (or was) a very central file included by almost all other files. (If a struct is referenced via a pointer type only, it can be forward referenced, and the definition of the struct is not needed.) Now that they're out of stheader.h, this difference doesn't matter anymore, and the code can be simplified. Also sneak in some sanity checks.
* dec_video: remove "initialized" fieldwm42013-11-232-13/+8
| | | | It's redundant.
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-231-3/+3
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* video: move decoder context from sh_video into new structwm42013-11-236-187/+216
| | | | | | | | | | This is similar to the sh_audio commit. This is mostly cosmetic in nature, except that it also adds automatical freeing of the decoder driver's state struct (which was in sh_video->context, now in dec_video->priv). Also remove all the stheader.h fields that are not needed anymore.
* video: remove vf_pp auto-insertionwm42013-11-232-20/+0
| | | | | | | | | | This drops the --pp option, which was probably broken for a while. The option automatically inserted the "pp" filter. The value passed to it was ignored (which is probably broken, it always selected maximal quality). Inserting this filter can be done simply with --vf=pp, so this is not needed anymore.
* video: merge vd.c into dec_video.cwm42013-11-232-175/+138
| | | | | I don't feel like the separation ever made sense, and it was hard to tell which file a function you were looking for was in.
* video: move struct mp_hwdec_info into its own header filewm42013-11-235-17/+4
| | | | | | | | This means most code accessing this struct must now include hwdec.h instead of dec_video.h. I just put it into dec_video.h at first because I thought a separate file would be a waste, but it's more proper to do it this way, as there are too many files which include dec_video.h only to get the mp_hwdec_info definition.
* vf_vavpp: make it work with vo_opengl and software decodingwm42013-11-222-2/+2
| | | | | | | | | | vo_opengl always loads the hwdec backend lazily, so hwdec_request_api() has to be called to possibly load it. This makes vf_vavpp work with software decoding. (Hardware decoding loads the backend before the filter is initialized, so this case is different.) Also, the VFCTRL_GET_HWDEC_INFO call doesn't need to be checked. If it fails, the info will be left blank.
* vdpau_old: enable OpenGL interopwm42013-11-191-0/+1
| | | | | OpenGL interop was essentially disabled, because the decoder didn't request vdpau device creation from vo_opengl.
* demux: rename demux_packet.h to packet.hwm42013-11-182-2/+2
| | | | This always bothered me.
* vd_lavc: select correct hw decoder profile for constrained baseline h264wm42013-11-141-2/+4
| | | | | | | | | | | | | | | | | | | | The existing code tried to remove the "extra" profile flags for h264. FF_PROFILE_H264_INTRA doesn't matter for us at all, because it's set only for profiles the vdpau/vaapi APIs don't support. The FF_PROFILE_H264_CONSTRAINED flag on the other hand is added to H264_BASELINE, except that it makes the file a real subset of H264_MAIN and H264_HIGH. Removing that flag would select the BASELINE profile, which appears to be rarely supported by hardware decoders. This means we accidentally rejected perfectly hardware decodable files. Use MAIN for it instead. (vaapi has explicit support for CONSTRAINED_BASELINE, but it seems to be a new thing, and is not reported as supported where I tried. So don't bother to check it, and do the same as on vdpau.) See github issue #204.
* vdpau: unbreakwm42013-11-091-0/+1
| | | | Obviously I didn't test commit 1b8cd01, and it just crashed. Oops.
* vdpau: drop dummy render functionwm42013-11-071-14/+2
| | | | | | | | | This was supposed to handle preemption better. I still think the current state isn't very nice, since the decoder can "accidentally" call the previous render function after preemption (instead of calling the reloaded function), so there might be issues. But all in all, this dummy_render function is a bit confusing, and still not entirely correct, so it's not worth it.
* vd_lavc: remove explicit crystalhd supportwm42013-11-061-14/+0
| | | | | | | | | | | | | | | | This removes "--hwdec=crystalhd". I doubt anyone even tried to use this. But even if someone wants to use it, the decoders can still be explicitly invoked with e.g.: --vd=lavc:h264_crystalhd The only advantage our special code provided was fallback to software decoding. (But I'm not sure how the ffmpeg crystalhd pseudo-decoder actually behaves.) Removing this will allow some simplifications as soon as we don't need vdpau_old.c anymore.
* vo_opengl: support for vdpau hardware decodingwm42013-11-051-0/+1
| | | | | | | | | | | | This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
* vdpau: drop required/deprecated access to a libavcodec struct fieldwm42013-11-041-3/+0
| | | | | | | | | | | Before the bitstream_buffers field was deprecated, you had to free it, otherwise you would leak memory. (Although vdpau.c uses a new API, they managed to introduce a new deprecation this quickly. This is a complaint.) This introduces a memory leak of 12 bytes per file on every file on some _older_ libavcodec versions. This is minor enough that I don't care.
* Merge branch 'master' into have_configurewm42013-11-044-0/+15
|\ | | | | | | | | Conflicts: configure
| * vo_opengl: add support for VA-API OpenGL interopwm42013-11-041-0/+1
| | | | | | | | | | | | | | | | VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.
| * vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-043-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
* | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-6/+5
|/ | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* demux: rename Windows symbolswm42013-11-021-10/+10
| | | | | | | | | | | | | | | | | | | | There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
* video: check profiles with hardware decodingwm420