summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mplayer: reshuffle on every loop if --loop and --shuffle are usedwm42013-08-194-23/+7
| | | | | | | | | | See github issue #194. Unfortunately, this breaks the property that going back in the playlist always works as expected. This changes, because the playlist_prev command will work on the reshuffled playlist, instead of loading the previously played files in order. If this ever becomes an issue, I might revert this commit.
* vaapi: use highest available profile, instead of mapping it exactlywm42013-08-191-41/+38
| | | | | | | Now the code does the same as the original MPlayer VAAPI patch, instead of trying to map the profiles exactly. See previous commit for justification and discussion.
* vdpau: don't try to match codec profileswm42013-08-191-27/+11
| | | | | | | | | | | | | | | | Instead, do what MPlayer did all these years. It worked for them, so there's probably no reason to change this. Apparently fixes playback with some files, where the VDPAU decoder does not formally support a profile, but decoding works with a more powerful profile anyway. Though note that MPlayer did this because it couldn't do it in a better way (no decoder reported profiles available when creating the VDPAU decoder), so it's not entirely clear whether this is a good idea. An alterbative implementation might try to map the profiles exactly, and do some fall backs if the exact profile is not available. But this hack-solution works too.
* changes: add some things for completenesswm42013-08-191-3/+31
|
* vo_vdpau: add RGB supportwm42013-08-182-14/+158
| | | | | | | | | | | | | | | | | | | | | Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
* vo_vdpau: fix screenshots if panscan is usedwm42013-08-181-4/+5
| | | | | | | When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
* vo_vdpau: remove unused variablewm42013-08-181-2/+0
| | | | | It was used to manage video surface in the software decoding path, but now surface management shares the code with hardware decoding.
* mplayer: don't make restored options from quit_watch_later per-file localwm42013-08-171-6/+8
| | | | | | | | | | | | | | | Consider: mpv file1.mkv file2.mkv and file1.mkv is restored from an earlier session when quit_watch_later was used. Then all restored options were reset when file2.mkv is played, even if the user changed them during playback. This affects for example the fullscreen setting. Make it so that after finishing a resumed file, the previously restored settings are not reset again. (Which means only resuming will forcefully overwrite the settings.)
* command: more intuitive chapter seek behaviorPhilip Sequeira2013-08-175-2/+36
| | | | | | | | | If close to chapter start, skipping back goes to previous chapter (no change). If more than <threshold> seconds in, skipping back will now go to the beginning of the current chapter instead. The threshold is set by the new option --chapter-seek-threshold and defaults to 5 seconds. A negative value disables the new functionality.
* command: allow seek to "chapter -1"Philip Sequeira2013-08-172-3/+8
| | | | | This will seek to the start of the file regardless of whether the first real chapter starts there or not.
* vo_vdpau: use color close to black as default colorkey (instead of green)wm42013-08-172-4/+7
| | | | | | | | | | | | | | | | | | The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
* vo_vdpau: allow setting colorkeywm42013-08-173-0/+23
| | | | | | | Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
* m_option: add missing copy callback for some option typeswm42013-08-171-0/+5
| | | | | One reaosn for this is that this broke proper handling of .defval, since m_option_copy did nothing for these option types.
* m_option: make defval constwm42013-08-171-1/+1
| | | | There's really no reason why it shouldn't.
* sd_lavc_conv: don't check AV_CODEC_PROP_TEXT_SUB flagwm42013-08-152-18/+3
| | | | | | | | Not actually useful. This would break whenever a new text subtitle format would be added, which requires a binary->text transformation. (mov_text is one such format; disable it.) In general, we would have to know which packet formats are binary, which we don't, so the only reasonable way to handle this is a white list.
* sub: don't print detected charset if it's UTF-8wm42013-08-153-5/+10
| | | | | Too noisy. This also fixes that iconv() was called if "utf8" was used as codepage.
* vdpau_old: add forgotten probe callbackwm42013-08-151-0/+1
| | | | Could make it crash if the VO didn't support vdpau decoding.
* manpage: fix incorrect ao_alsa example, extend changes.rstwm42013-08-152-2/+7
| | | | | | | One example in ao.rst used the old syntax with mangled device names. Fix it. Mention some shell related caveats. Explicitly mention the change of device name syntax in changes.rst, because it seems to be a common issue.
* sub: make --subcp=enca the default.wm42013-08-152-5/+19
|
* sub: allow specifying a fallback codepage if input is not UTF-8wm42013-08-152-4/+18
| | | | | | | | | | | | | | | Normally, --subcp always forces conversion. This really always forces conversion, even if the UTF-8 check on the input succeeds. Extend the --subcp to allow codepages as fallback if UTF-8 doesn't work. So, for example --subcp=utf8:cp1250 will use UTF-8 if the input looks like UTF-8, and will fall back to use cp1250 if the UTF-8 check fails. I think this should actually be the default, but on the other hand, this changes the semantics of the option, and a user would actually expect --subcp to force conversion, rather than silently using UTF-8 if that happens to work.
* bstr: make UTF-8 check stricterwm42013-08-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Don't accept overlong sequences. Don't accept codepoints past the maximum unicode codepoint. Don't accept the UTF-16 surrogate codepoints. I'm not sure if there are more codepoints that are defined to be invalid, but we just want to make libavcodec happy, so this is enough. (libavcodec's subtitle converter checks for valid UTF-8 and throws up and dies if it's not - now we want to use bstr_sanitize_utf8_latin1() to force valid UTF-8, so the strictness of our UTF-8 parser has to match at least that of the libavcodec's check.) I'm not sure whether the min test is actually 100% correct. Note that libavcodec also treats BOM codepoints as invalid. This is definitely a bug: the BOM is really just "zero-width non-breaking space" redefined by Microsoft, but it is perfectly valid to appear in the middle of a string. Official Unicode has merely deprecated the old usage of the BOM codepoint, and didn't make it illegal. Besides, the string could be from the start of a file, so even this check doesn't make sense even with libavcodec's insane logic. We don't copy this bug.
* sub: if charset detection fails, treat it as broken UTF-8wm42013-08-153-8/+18
| | | | | | | | | | | Broken UTF-8 in this context means we treat it as UTF-8, but we also interpret broken UTF-8 sequences as Latin1. Also, run our own UTF-8 check function before the charset detectors. This prevents from ENCA's UTF-8 check possibly messing up (like detecting 7-bit clean UTF-8 as ASCII, or other things). It also takes care of UTF-8 detection if no charset detector (ENCA, libguess) is compiled in, and it lets us deal better with cut-off UTF-8 sequences.
* bstr: add UTF-8 validation and sanitation functionswm42013-08-152-1/+81
|
* vdpau: fix compilation on Libavwm42013-08-151-0/+1
| | | | | | Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without forward-declaring them and without including the headers declaring them. FFmpeg's header for this is fine.
* video/decode: change fix_image callbackwm42013-08-153-5/+7
| | | | | This might make it slightly easier when trying to implement surface read-back for hardware decoding.
* vd_lavc: fix comment, document hwdec video frame size trickinesswm42013-08-151-1/+4
| | | | | | | | | About this issue, it would be better if the surfaces could be allocated with the real size, and the vdpau video mixer could be created with that size as well. That would be a bit hard, because the real surface size had to be communicated to vdpau. So I'm going with this solution. vaapi seems to be fine with either surface size, so there's hopefully no problem.
* video/decode: pass parameters directly to hwdec allocate_image callbackwm42013-08-155-20/+14
| | | | | | Instead of passing AVFrame. This also moves the mysterious logic about the size of the allocated image to common code, instead of duplicating it everywhere.
* vo_corevideo: add uyvy422 pixel format supportStefano Pigozzi2013-08-151-0/+5
| | | | | Looks like the vda_h264_dec in ffmpeg likes to output this format and it inserted swscale to do pixfmt conversion to yuyv422.
* input: fix build if HAVE_PTHREADS is undefinedGiuliano Schneider2013-08-151-1/+1
|
* sub: fix accidental subtitle overlapswm42013-08-141-1/+6
| | | | | | | | | | | | | | | | | | The fix_overlaps_and_gaps() function in dec_sub.c fixes small gaps or overlaps between subtitle events. However, sometimes it could happen that the corrected subtitle events could overlap by 1ms due to bad rounding, making libass shift subtitles to reduce collisions. (The second subtitle will be shown above the previous one, even if both subtitles are visible only for 1ms.) sd_ass.c rounds the timestamps when converting to integers for unknown reasons. I think it would work fine without that rounding, but since I have no clue why it rounds, and since it could be needed to ensure correct timestamps with ASS subtitles demuxed from Matroska, I'd rather not touch it. So the solution is to use already rounded timestamps to calculate the new subtitle duration in fix_overlaps_and_gaps(). See github issue #182.
* x11: fix --ontopwm42013-08-141-3/+3
| | | | Apply it after mapping.
* vaapi: fix typowm42013-08-141-2/+2
|
* changes.rst: document some OSX and windows changesStefano Pigozzi2013-08-131-0/+5
|
* input.conf: bind AXIS_(LEFT|RIGHT) to seek 5Stefano Pigozzi2013-08-131-2/+2
| | | | Binding them to volume was a bad default, so change it.
* cocoa_common: add precise scrolling supportStefano Pigozzi2013-08-131-16/+11
| | | | | | This adds precise scrolling support. I ran some tests and it seems a little bit smoother and well.. precise. The defaults are rebindable using: AXIS_UP, AXIS_DOWN, AXIS_LEFT and AXIS_RIGHT.
* macosx: remove platform specific input queueStefano Pigozzi2013-08-135-68/+3
| | | | | Since last commit the input queue in the core is thread safe, so there is no need for all this platform specific stuff anymore.
* input: make input queue thread safeStefano Pigozzi2013-08-131-6/+35
| | | | | | | If pthreads are enabled the input queue accesses are regulated by acquiring a mutex. This is useful for platforms like OS X, where the events are created in the cocoa thread and added to the queue to then be dequeued in the playloop thread.
* mpvcore/options: Update default user agent stringMartin Herkt2013-08-131-1/+2
| | | | Uh… about time, I guess?
* demux: move demux_mf before demux_subreaderwm42013-08-121-3/+3
| | | | | demux_subreader is quite aggressive, and sometimes detects random strings in EXIF as subtitle text.
* demux_subreader: report what subtitle format has been foundwm42013-08-121-0/+2
|
* stream_bluray: fix bd:// url segfault introduced by commit bc1d61Noble Huang2013-08-121-6/+2
|
* Revert "sub: support straight alpha additionally to premultiplied alpha"wm42013-08-125-93/+18
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 689a25003fc8098e5fdfbb2faefc0e18365d3acb, with some adjustments to code that was added after that commit. I just messed up big time. We don't need this, and in fact the commit confused straight and premultiplied alpha at one point (just a simple inverted condition due to an oversight), which is why it looked like it was working. In commit 2827295 I wrote: Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures [...] That was just me messing up and being severely confused by my own bugs. VA API uses premultiplied alpha, which by the way is nice and thoughtful of the VA API devs. Well, this was stupid. But in the end, I'm glad that I could actually reduce codesize by a good amount again.
* manpage: actually document --hwdec=autowm42013-08-121-0/+7
|
* configure: fix typowm42013-08-121-1/+1
|
* vo: fix build with #ifdef -> #ifwm42013-08-121-1/+1
| | | | | Whoever had the idea of introducing mixed conventions for these preprocessor symbols should be shot.
* video: add vaapi decode and output supportwm42013-08-1216-5/+1635
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* img_convert: add function to scale RGBA OSD imageswm42013-08-124-1/+50
|
* sub: support straight alpha additionally to premultiplied alphawm42013-08-124-16/+91
| | | | | | | | | This is for VAAPI support. VAAPI does not support premultiplied alpha for OSD. (Normally, we prefer premultiplied, because it has better behavior on scaling.) I'm not sure whether blending in the ASS->RGBA part is correct and I didn't test it extensively.
* video: redo hw decoding initialization, add --hwdec=autowm42013-08-116-100/+204
| | | | | | | | | | | | | | | | Change how the HW decoding stuff is organized, the way it's initialized in particular. Instead of duplicating the list of supported codecs for hwaccel decoders, add a probe function which allows each decoder to report whether it supports a given codec. Add an "auto" choice to the --hwdec option, which automatically enables hardware decoding if libavcodec and/or the VO supports it. What mpv prints on the terminal changes a bit. Now it will just print a single line whether hw decoding is used or not (and nothing at all if no hw decoding at all was requested). The pretty violent fallback from hw decoding to software decoding is still quite verbose and evil-looking though.
* x11_common: get hack for Motif Window Manager out of the waywm42013-08-111-1/+11
| | | | | | | | Disable the hack by default, because it's interfering with some more modern WMs. MWM (Motif Window Manager) is probably pretty dead, but we still allow enabling the old hack with "--fstype=mwm_hack". See github issue #179.
* vo: unref waiting image before destroying VO driverwm42013-08-111-1/+1
| | | | | | | | This is in theory more correct with respect to hardware decoding. With hardware decoding, the VOs play the role of the video surface allocator, and nothing is allowed to reference surfaces past the VO lifetime. But in theory waiting_mpi could be a reference to a HW video surface, so it should be relased before the VO is uninitialized.
* core: make sure hw decoding works when playing multiple fileswm42013-08-111-5/+5
| | | | | The hw decoding context was set only for the first file (when the VO was initialized), instead of every file.
* version.sh: add --print option, which prints version to stdoutwm42013-08-091-2/+23
| | | | Might be helpful when creating a tarball.
* version.sh: integrate the release tag in outputwm42013-08-091-2/+2
| | | | | | | | | | | | This is basically reconstructed from 46b218c. Since we now have proper release tags, we want this again. Add --tags to the git describe call, because the github release system creates light-weight tags only, and we're too lazy to create annitated tags (or is that bad practice?). Add --long, so that the git commit hash is part of the output even if the tag matches.
* demux_lavf: blacklist "tty" libavformat demuxerv0.1.0wm42013-08-071-1/+16
| | | | | | | | | | This is completely useless, and in this particular case, it broke the fallback for MLP2 subtitles (stored as .txt files) to demux_subreader. (Yes, libavformat should be fixed to handle this, but for now this will _always_ break playback of subtitle files stored in .txt.) You can still force this demuxer, but by default we will just pretend that the "tty" demuxer does not exist.
* changes.rst: add precise scrolling supportAlexander Preisinger2013-08-071-0/+2
|
* input.conf: better documentation and sane defaultsAlexander Preisinger2013-08-071-2/+4
| | | | | Uses the same defaults as BTN3/4/5/6 which are hardcoded by most backends for the mouse wheel.
* wayland: add support for precise scrollingAlexander Preisinger2013-08-071-2/+14
| | | | | | | | The default value for a standard mouse is 10.0. Because we don't want to multiply the value in the input config file we scale it down to 1.0. Hopefully this should work for more precise mousewheels or touchpad, but I don't have access to such hardware.
* input: add support for precise scroll axesAlexander Preisinger2013-08-075-3/+39
| | | | | | | | | | | | | | | Support horizontal and vertical axes of input devices. If the input device support precise scrolling with an input value then it should first be scaled to a standard multiplier, where 1.0 is the default. The multiplier will then applied to the following commands if possible: * MP_CMD_SEEK * MP_CMD_SPEED_MULT * MP_CMD_ADD All other commands will triggered on every axis event, without change the values specified in the config file.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-06211-517/+517
| | | | Followup commit. Fixes all the files references.
* core: move contents to mpvcore (1/2)Stefano Pigozzi2013-08-0667-0/+0
| | | | |</