summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* stream: don't require streams to set s->pos in seek callbackwm42013-08-229-22/+11
| | | | Instead, set s->pos depending on the success of the seek callback.
* stream: move file forward skipping to common stream implementationwm42013-08-223-52/+29
| | | | | | | | | | | stream_file.c contains some code meant for forward seeking with pipes. This simply reads data until the seek position is reached. Move this code to stream.c. This stops stream_file from doing strange things (messing with stream internals), and removes the code duplication too. We also make stream_seek_long() use the new skip code. This is shorter and much easier to follow than the old code, which basically did strange things.
* stream_avdevice: remove redundant dummy callbackwm42013-08-221-6/+0
|
* stream_file: uncrustifywm42013-08-221-132/+140
|
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-2210-113/+591
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec' decoder in FFmpeg. The Good: This new implementation has some advantages over the previous one: - It works with Libav: vda_h264_dec never got into Libav since they prefer client applications to use the hwaccel API. - It is way more efficient: in my tests this implementation yields a reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and ~65-75% compared to h264 software decoding. This is mainly because `vo_corevideo` was adapted to perform direct rendering of the `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework. The Bad: - `vo_corevideo` is required to use VDA decoding acceleration. - only works with versions of ffmpeg/libav new enough (needs reference refcounting). That is FFmpeg 2.0+ and Libav's git master currently. The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture. One one end this makes the code simple since Apple's OpenGL implementation actually supports this out of the box. It would be nice to support other output image formats and choose the best format depending on the input, or at least making it configurable. My tests indicate that CPU usage actually increases with a 420p IMGFMT output which is not what I would have expected. NOTE: There is a small memory leak with old versions of FFmpeg and with Libav since the CVPixelBufferRef is not automatically released when the AVFrame is deallocated. This can cause leaks inside libavcodec for decoded frames that are discarded before mpv wraps them inside a refcounted mp_image (this only happens on seeks). For frames that enter mpv's refcounting facilities, this is not a problem since we rewrap the CVPixelBufferRef in our mp_image that properly forwards CVPixelBufferRetain/CvPixelBufferRelease calls to the underying CVPixelBufferRef. So, for FFmpeg use something more recent than `b3d63995` for Libav the patch was posted to the dev ML in July and in review since, apparently, the proposed fix is rather hacky.
* mp_msg: fix typo in message level for new msg API macrosStefano Pigozzi2013-08-221-2/+2
|
* cocoa_common: fix window positioning with `--geometry`Stefano Pigozzi2013-08-221-10/+5
| | | | | | | | | | | Regression since ff3b98d11c. The window positioning code relied on the visibleFrame's height without taking into account the dock's presence. Also moved the constraining code to the proper method that overrides the original NSWindow behaviour. This avoids having to check for border since the constraining is performed by Cocoa only for titled windows. Fixes #190
* mplayer: replace "D:" in status line with "Late:"wm42013-08-211-1/+1
| | | | | | | | | | Too many people thought "D:" really meant number of dropped frames. But it's actually the number of frames where the playloop thought it'd be a good idea to drop them. Of course this does nothing if frame dropping is disabled, but even with normal frame dropping, this doesn't indicate whether a frame was _really_ dropped. (Looks like libavcodec doesn't even give us this information reliably? The decode function can return no frame in case of codec delay due to threading and such.)
* options: replace --edition=-1 with --edition=autowm42013-08-213-5/+7
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* mplayer: start track IDs from 1 rather than 0wm42013-08-213-3/+3
| | | | | | Completely pointless, but makes ChrisK happy for some reason. Track ID 0 is now rejected by the option parser itself.
* manpage: fix (again) incorrect ao_alsa exampleCheng Sun2013-08-201-1/+1
| | | One example in ao.rst used the old syntax with misspelling of "no-block".
* command: simplify video brightness/gamma/etc. handling a bitwm42013-08-201-44/+17
| | | | | | | | | | | | | We don't need to store the offsets of the options corresponding to the properties, because the option-property bridge knows about this already. The check against 1000 was for the case if e.g. the --brightness option is not used. Always overwrite the option value instead, both when querying and setting the property. (This is needed to make the settings persistent even if vf_eq is used and the video chain is reinitialized.) This commit assumes that VFCTRL_SET_EQUALIZER is always paired with VFCTRL_GET_EQUALIZER (likewise for VOCTRL), which is the case.
* vf_eq: fix behavior when changing parameterswm42013-08-201-4/+14
| | | | | | | | | | | | | | | Using -vf eq and changing brightness, contrast, etc. using key bindings with e.g. "add brightness 1" didn't work well: with step width 1, the property gets easily "stuck". This is a rounding problem: e.g. setting gamma to 3 would actually make it report that gamma is set to 2, so the "add" command will obviously never reach 3 with a step width of 1. Fix this by storing the parameters as integers. This was broken in cac7702. This commit effectively changed these properties to use the value as reported by vf_eq, instead of the previously set value for the "add" command. This was more robust, but not very correct either, so we keep the new behavior and make vf_eq report its parameters more accurately.
* m_option: make "add speed 0.1" command workwm42013-08-191-0/+1
| | | | Was broken since the speed property was switched from float to double.
* mp_core: declare seek_type enum outside of nested structwm42013-08-191-3/+8
| | | | cosmetic change. See previous commit.
* wayland: separate shm and cursor contextAlexander Preisinger2013-08-192-9/+15
| | | | | | The display, window, keyboard and cursor structures are now cleanly and logically separated. Also could prevent a future bug where no shm format is set when the cursor image is loaded (Never happened until now).
* m_option: rename struct member named "new"wm42013-08-192-5/+5
| | | | | | Cosmetic change to allow C++ code to include this header. See github issue #195.
* video: make it possible to scale/pan the video by arbitrary amountswm42013-08-196-5/+62
| | | | | | | | | | | Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
* options: remove --panscanrange optionwm42013-08-194-19/+3
| | | | | | This option allowed you to extend the range of the panscan controls, so that you could essentially use it to scale the video. This will be replaced by a separate option to set the zoom factor directly.
* 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
|