summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* 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 decodingwm42013-11-014-72/+130
| | | | | | | | | | | | | | | We had some code for checking profiles earlier, which was removed in commits 2508f38 and adfb71b. These commits mentioned that (working) hw decoding was sometimes prevented due to profile checking, but I can't find the samples anymore that showed this behavior. Also, I changed my opinion, and I think checking the profiles is something that should be done for better fallback to software decoding behavior. The checks roughly follow VLC's vdpau profile checks, although we do not check codec levels. (VLC's profile checks aren't necessarily completely correct, but they're a welcome help anyway.) Add a --vd-lavc-check-hw-profile option, which skips the profile check.
* vd_lavc: add more ifdeffery and ffmpeg cargo culting for correctnesswm42013-10-311-7/+13
| | | | | | | | | | | | | We mixed the "old" AVFrame management functions (avcodec_alloc_frame, avcodec_free_frame) with reference counting. This doesn't work correctly; you must use av_frame_alloc and av_frame_free. Of course ffmpeg doesn't warn us about the bad usage, but will just mess up things silently. (Thanks a lot...) While the alloc function seems to be 100% compatible, the free function will do bad things, such as freeing memory that might still be referenced by another frame. I didn't experience any actual bugs, but maybe that was pure luck.
* dec_video: remove unused declaration of a former global variablewm42013-10-311-2/+0
|
* vdpau_old: restore hardware decoding with old APIwm42013-10-191-0/+1
| | | | --hwdec=vdpau did nothing with older ffmpeg/libav versions. Oops.
* cosmetics: replace "CTRL" defines by enumswm42013-10-021-4/+6
| | | | Because why not.
* core: add --force-windowwm42013-10-021-1/+0
| | | | | | | | | | | | | | | | | This commit adds the --force-window option, which will cause mpv always to create a window when started. This can be useful when pretending that mpv is a GUI application (which it isn't, but users pretend anyway), and playing audio files would run mpv in the background without giving a window to control it. This doesn't actually create the window immediately: it only does so only after initializing playback and when it is clear that there won't be any actual video. This could be a problem when starting slow or completely stuck network streams (mpv would remain frozen in the background), or if video initialization somehow is stuck forever in an in-between state (like when the decoder doesn't output a video frame, but doesn't return an error either). Well, we can pretend only so much that mpv is a GUI application.
* vaapi: remove non-VLD entrypointswm42013-09-291-6/+2
| | | | | These probably don't work. libavcodec doesn't seem to support them, and neither did the original mplayer-vaapi patch.
* vaapi: fix non-sense conditionwm42013-09-291-1/+1
| | | | Attempting signed comparison on unsigned value.
* vaapi: potentially make reading surfaces back to system RAM fasterwm42013-09-271-1/+4
| | | | | | | | Don't allocate a VAImage and a mp_image every time. VAImage are cached in the surfaces themselves, and for mp_image an explicit pool is created. The retry loop runs only once for each surface now. This also makes use of vaDeriveImage() if possible.
* video: let sh_video->disp_w/h always be container sizewm42013-09-261-4/+1
| | | | | | | Nothing really accesses it. Subtitle initialization actually does in a somewhat meaningful way, but there container size is probably fine, as subtitles were always initialized before the first video frame was decoded.
* video: let sh_video->aspect always be container aspect ratiowm42013-09-262-11/+14
| | | | | | | Now writing -1 to the 'aspect' property resets the video to the auto aspect ratio. Returning the aspect from the property becomes a bit more complicated, because we still try to return the container aspect ratio if no frame has been decoded yet.
* vd: move aspect calculation to a functionwm42013-09-261-24/+9
| | | | | | | | This function would probably be useful in other places too. I'm not sure why vd.c doesn't apply the aspect if it changes size by less than 4 pixels. Maybe it's supposed to avoid ugly results with bad scalers if the difference is too small to be noticed normally.
* vd: remove some dead codewm42013-09-261-14/+4
| | | | | As of now, this function is called only after decoding a full, valid video frame, so the image parameters should be reliable.
* vaapi: allow GPU read-back with --hwdec=vaapi-copywm42013-09-253-3/+108
| | | | | | | | | | | | | | This code is actually quite inefficient: it reuses the (slow, simple) screenshot code. It uses an inefficient method to read the image (vaGetImage() instead of vaDeriveImage()), allocates new memory for each frame that is read, and it tries all image formats again each time. Also, in my tests it always picked NV12 as image format, which is not ideal if you actually want to filter the video, and vo_xv can't handle this format without conversion either. However, a user confirmed that it worked for him, so everything is fine.
* vd_lavc: allow process_image to change image formatwm42013-09-252-18/+21
| | | | | | | | | | | | | | This will allow GPU read-back with process_image. We have to restructure how init_vo() works. Instead of initializing the VO before process_image is called, rename init_vo() to update_image_params(), and let it update the params only. Then we really initialize the VO after process_image. As a consequence of these changes, already decoded hw frames are correctly unreferenced if creation of the filter chain fails. This could trigger assertions on VO uninitialization, because it's not allowed to reference hw frames past VO lifetime.
* vaapi: add vf_vavpp and use it for deinterlacingxylosper2013-09-251-36/+29
| | | | | | | | Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
* vd_lavc: reset last_sample_aspect_ratio in uninit_avctx()xylosper2013-09-131-0/+1
| | | | | | | | In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set, sh->aspect is overwritten. With software decoding fallback behaviour, this makes the aspect ratio from container ignored since last_sample_aspect_ratio is already set in first try with hardware decoding.
* core: add --deinterlace option, restore it with resume functionalitywm42013-09-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --deinterlace option does on playback start what the "deinterlace" property normally does at runtime. You could do this before by using the --vf option or by messing with the vo_vdpau default options, but this new option is supposed to be a "foolproof" way. The main motivation for adding this is so that the deinterlace property can be restored when using the video resume functionality (quit_watch_later command). Implementation-wise, this is a bit messy. The video chain is rebuilt in mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the usual mechanism for enabling deinterlacing can't be used. Further, mpcodecs_reconfig_vo() is called by the video decoder, which doesn't have access to MPContext either. Moving this call to mplayer.c isn't currently possible either (see below). So we just do this before frames are filtered, which potentially means setting the deinterlacing every frame. Fortunately, setting deinterlacing is stable and idempotent, so this is hopefully not a problem. We also add a counter that is incremented on each reconfig to reduce the amount of additional wor