summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: fix segfault issue playing back VC1 in a mkvBin Jin2013-04-271-1/+1
| | | | This bug was introduced in commit 06eee1b.
* vd_lavc: fix decoder init failure pathwm42013-04-271-14/+18
| | | | | | | | | libavcodec decoder initialization failure caused a segfault, because it wasn't properly reported back in init(). Also remove the return value from init_avctx(), which actually makes things simpler. Instead, ctx->avctx can be checked to see whether initialization was ok.
* compat: remove an unused symbolwm42013-04-261-4/+0
| | | | | The compatibility issue actually didn#t get solved, it's just handled differently in mpv now.
* subassconvert: do not escape likely ASS override tagswm42013-04-261-1/+19
| | | | | | | | | | | | | | | | | | | | | | | Usually SubRip files are not expected to contain ASS override tags, but unfortunately these files seem to become more common. Example from a real file: 1 00:00:00,800 --> 00:00:15,000 {\an8}本字幕由 {\c&H26F4FF&}ShinY {\c&HFFAE1A&}深影字幕组{\c&HFFFFFF&} 原创翻译制作 subassconvert.c escaped '{', so that libass displayed the above line literally. Try to apply a simple heuristic to detect whether '{' is likely to start an ASS tag: if the string starts with '{\', and there is a closing '}', assume it's an ASS tag, otherwise escape the '{' properly. If it's a likely ASS tag, it's passed through to libass. The end result is that the above script is displayed in color, while at the same time legitimate uses of '{' and '}' should work fine. We assume that nobody uses {...} for commenting text in SubRip files. (This kind of comment is popular and legal in ASS files, though.)
* manpage: fix references to --slavewm42013-04-261-2/+2
|
* options: allow using [ ] for quoting in sub-optionswm42013-04-262-7/+21
| | | | | | This is an attempt to make quoting of sub-option values less awkward, even if it works only with some shells. This is needed mainly for vf_lavfi. Also update the vf_lavfi manpage section.
* vf_lavfi: move compat crap to the start of the filewm42013-04-261-18/+18
|
* vf_lavfi: silence stupid deprecation warningwm42013-04-261-2/+12
| | | | | | | | | | | | | | | | | | | libavfilter changed the way a format list is passed to vf_format. Now you have to separate formats with "|" instead of ":". If you use "|", it prints an annoying message on every reinit: [format @ 0x8bbaaa0]This syntax is deprecated. Use '|' to separate the list items. ...and it will probably stop working without warning at some point in the future. We need some very annoying ifdeffery to detect this case, because libavfilter version numbers are just plain incompatible between Libav and ffmpeg. There is no other way to detect this. (Sometimes I wonder whether ffmpeg and especially Libav actually like causing unnecessary pain for their users, and intentionally break stuff in the most annoying way possible. Sigh...)
* core: simplify handling of --pausewm42013-04-255-31/+21
| | | | | | | | | | | | | Rename the struct MPOpts "start_pause" field to "pause". Store the user- pause state in that field, so that both runtime pause toggling and the --pause switch change the same variable. Simplify the initialization of pause so that using --pause and changing the file while paused is exactly the same case (changing the file while paused doesn't unpause, this has been always this way). Also make it a bit more consistent. Before, starting with --pause would reset the pause state for every file, instead of following the usual semantics for option switches (compare with behavior of --fs).
* core: don't let cache pause handling and user pausing conflictwm42013-04-253-10/+25
| | | | | | | | | | | | The core pauses and unpauses automatically to wait for the network cache (also known as buffering). This conflicted with user pause control, and was perceived as if the player was unresponsive and/or the cache just overturned the user's decisions. Change it so that the actual pause state and the pause state as intended by the user never conflict. If the user toggles pause, the pause state will be in the expected state as soon as the cache is loaded.
* vf_lavfi: recreate filter graph on seekwm42013-04-251-14/+41
| | | | | | | | | | | | | | Resetting the filter graph helps dealing with filters which save state between frames. This is important especially if they modify frame timing or emit additional frames. Unfortunately the libavfilter API doesn't have a way to do this directly, so we have to use a dirty trick: we recreate the whole graph, including format negotiation down and filter string parsing. ffplay does this too. If libavfilter somehow decides to change output format or size from what the first run in config() returned, mpv will explode. The same applies to vf_next_query_format() return values (although this could be mitigated, should it really happen).
* core: fix bogus condition that broke backstepping with last commitwm42013-04-251-1/+1
| | | | | This broke all cases where indexing was required, and the current frame wasn't the first frame in a segment.
* core: fix backstepping with ordered chapterswm42013-04-251-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | There were two problems. First, frames past the end of the current segment were added to the index, which messed up backstepping. Check for the endpts before added a frame to the index. Second, it wasn't possible to step over segments which change the file. Changing a file causes decoder reinitialization, which (rightfully) is treated as discontinuity (and vo_pts_history_seek_ts was changed). Add some extra code to pretend that a segment-switching seek/reinit does not introduce discontinuities. There's still a weird corner case: sometimes, you can frame step forward on the last frame of a segment without reaching the next segment immediately. This is because the playloop switches into audio-only mode. The segment is switched when both audio and video have ended, so the frame stepping will play random sized chunks of audio until the segment will be switched. This gives the impression that backstepping doesn't work perfectly, even though it's the other way around and frame stepping behaves weird. This is a consequence of wanting to make frame stepping work with audio, and is not really a bug.
* manpage: remove broken examplewm42013-04-241-3/+0
| | | | Weird video size presets have been removed.
* manpage: document --native-keyrepeatwm42013-04-241-0/+6
| | | | Forgotten in commit d853aba.
* demux_mkv: cosmeticswm42013-04-241-4/+3
|
* core: add backstep supportwm42013-04-247-8/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allows stepping back one frame via the frame_back_step inout command, bound to "," by default. This uses the precise seeking facility, and a perfect frame index built on the fly. The index is built during playback and precise seeking, and contains (as of this commit) the last 100 displayed or skipped frames. This index is used to find the PTS of the previous frame, which is then used as target for a precise seek. If no PTS is found, the core attempts to do a seek before the current frame, and skip decoded frames until the current frame is reached; this will create a sufficient index and the normal backstep algorithm can be applied. This can be rather slow. The worst case for backstepping is about the same as the worst case for precise seeking if the previous frame can be deduced from the index. If not, the worst case will be twice as slow. There's also some minor danger that the index is incorrect in case framedropping is involved. For framedropping due to --framedrop, this problem is ignored (use of --framedrop is discouraged anyway). For framedropping during precise seeking (done to make it faster), we try to not add frames to the index that are produced when this can happen. I'm not sure how well that works (or if the logic is sane), and it's sure to break with some video filters. In the worst case, backstepping might silently skip frames if you backstep after a user-initiated precise seek. (Precise seeks to do indexing are not affected.) Likewise, video filters that somehow change timing of frames and do not do this in a deterministic way (i.e. if you seek to a position, frames with different timings are produced than when the position is reached during normal playback) will make backstepping silently jump to the wrong frame. Enabling/disabling filters during playback (like for example deinterlacing) will have similar bad effects.
* mplayer: apply hrseek framedrop only when doing hrseekwm42013-04-241-2/+2
| | | | | | | | | | It's not sure if there's anything that could trigger this accidentally. Normally this can't happen, because hrseek ends always if the PTS is large enough, the same condition which disables framedrop. Seeking resets hrseek framedrop anyway. On the other hand, this change makes the code easier to understand, and might be more robust against weird corner cases.
* x11: use mpv internal key auto-repeat handling if possiblewm42013-04-245-3/+27
| | | | | | | | | | | | | | | | | Block X11's native key repeat, and use mpv's key repeat handling in input.c instead. No configure check for XKB. Even though it's an extension, it has been part of most (all?) xlibs since 1996. If XKB appears to be missing, just refuse enabling x11. This is a potentially controversial change. mpv will use its own key repeat rate, instead of X11's. This should be better, because seeking will have a standardized "speed" (seek events per seconds when keeping a seek key held down). It will also allow disabling key repears for certain commands, though this is not done anywhere yet. The new behavior can be disabled with the --native-keyrepeat option.
* input: don't reset time on each key repeatwm42013-04-241-2/+4
| | | | | | Key repeats were skipped when playloop iterations took too long. Fix this by using the total times for key repeat calculation, instead of the time difference to the last key repeat event.
* input: adjust wait time for key-repeatwm42013-04-241-0/+4
| | | | | Basically, these are additional timers that can expire without making the central select() exit.
* input: change default auto-repeat settingswm42013-04-241-2/+2
| | | | Rather arbitrary, but reasonable.
* input: don't let multi-key bindings block simple key bindingswm42013-04-241-4/+16
| | | | | | | | | | | | | Key bindings can include mutiple keys at once (additional to key modifiers like ctrl etc.). This becomes annoying when quickly switching between two bound keys, e.g. when seeking back and forth, you might end up hitting the "left" and "right" keys at once. The user doesn't expect to invoke the key binding "left-right", but would prefer a key stroke to invoke the binding it was supposed to invoke. So if there's no binding for a multi-key combination, try to find a binding for the key last held down. This preserves the ability to define multi-key combinations, while the common case works as expected.
* input: reduce amount of tracked keys per bindingwm42013-04-241-1/+1
| | | | | There's no need for key bindings that consist of 32 keys held down. It's ridiculous and wastes memory.
* input: fix handling of MP_KEY_STATE_DOWNwm42013-04-242-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | VOs can use the MP_KEY_STATE_DOWN modifier to pass key up/down events to input.c, instead of just simple key presses. This allows doing key auto- repeat handling in input.c, if the VO doesn't want to do that. One issue is that so far, this code has been used only for mouse events, even though the code was originally written with keyboard keys in mind. One difference between mouse keys and keyboard keys is that the initial key down should not generate an input command with mouse buttons (input.c did that), while keyboard events should (input.c didn't do that). Likewise, releasing a key should generate input commands for mouse buttons releases, but not for the keyboard. Change the code so mouse buttons (recognized via the MP_NO_REPEAT_KEY flag) follow the old hehavior, while other keys generate input commands on key down, but not on key release. Note that a key release event is posted either using MP_INPUT_RELEASE_ALL, or a normal key press event after having sent a an event with MP_KEY_STATE_DOWN. This is probably a bit confusing, and a MP_KEY_STATE_RELEASE should be added. Fix shift-handling with MP_KEY_STATE_DOWN as well.
* demux_mkv: fix out of range comparisonwm42013-04-241-1/+1
| | | | | | | | | | | This check was always false: if (num == EBML_UINT_INVALID) Fix it by using the proper type for the num variable. This case actually doesn't really matter, and this is just for hiding the warning and for being 100% correct.
* m_option: fix positional sub-option skippingwm42013-04-231-2/+2
| | | | | | Empty sub-option parameters mean the sub-option should be skipped, e.g. -vf gradfun=:10 sets the second option (by position) to 10. This was broken in commit 04f1e2d.
* vo_opengl_old: remove nomanyfmts warningwm42013-04-231-3/+0
| | | | | | The VO warns by default that the nomanyfmts option should be used if video display fails. This is almost completely useless, but people keep asking what it means.
* manpage: remove references to --no-sliceswm42013-04-231-7/+1
| | | | | | Background: slice support has been completely removed, because it doesn't work with multithreading, and provides a rather bad complexity to performance tradeoff otherwise.
* configure: enable libavdevice by defaultwm42013-04-231-2/+3
| | | | | | | | | Used to be disabled by default, because libavdevice depends on libavfilter, and earlier versions of libavfilter exports symbols that clash with mpv's due to its MPlayer filter wrapper. Our configure script explicitly detects these symbols now, and we can use that to safely auto-detect libavdevice too. If we detect that libavfilter can't be safely used, libavdevice is disabled as well.
* m_option: allow quoted positional parameters for -vfwm42013-04-232-37/+55
| | | | | | | | | This allows things like: '--vf=lavfi="gradfun=20:30"' Adjust the documentation for vf_lavfi to make the example less verbose. As an unrelated change, add a general description to vf_lavfi.
* vf_lavfi: add libavfilter bridgewm42013-04-216-5/+399
| | | | | | | | | | | | | | | | | Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
* mp_image: provide function to convert mp_image to AVFramewm42013-04-212-0/+53
| | | | | | Note that this does not pass through QP information (qscale field). The only filter for which this matters is vf_pp, and we have this natively.
* m_option: redo code for parsing -vf to accept quoteswm42013-04-211-130/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parsing sub-configs (like --rawvideo=subopts or the suboptions for --vo=opengl:subopts) was completely different from the -vf parsing code for a variety of reasons. This change at least makes -vf use the same splitter code as sub-config options. The main improvement is that -vf now accepts quotes, so you can write things like: -vf 'lavfi=graph="gradfun=10:20"' (The '' quotes are for shell escaping.) This is a rather big and intrusive change. Trying some -vf lines from etc/encoding-example-profiles.conf seems to confirm it still works. This also attempts to unify one subtle difference in handling of positional arguments. One consequence is that a minor detail changes. Sub-configs don't know positional arguments, and something like "-- opt=sub1=val1:sub2" means that sub2 has to be a flag option. In -vf parsing, sub2 would be a positional option value. To remove this conflict and to facilitate actual unification of the parsers in the future, the sub2 will be considered a flag option if and only if such a flag option exists. Otherwise, it's considered a value for a positional option. E.g. if there's a filter "foo" with a string option "sopt" and a flag option "fopt", the behavior of the following changes: -vf foo=fopt Before this commit, this would set "sopt=fopt" in the filter. Now, it enables the fopt flag, and the sopt option remains unset. This is not an actual problem to my knowledge.
* m_option: add function to check whether parameters are requiredwm42013-04-213-4/+11
| | | | To avoid that it will be duplicated with m_option.c and m_config.c.
* options: untangle track range parsing for stream_cddawm42013-04-213-89/+15
| | | | | | | | | Remove the "object settings" based track range parsing (needed by stream_cdda only), and make stream_cdda use CONF_TYPE_INT_PAIR. This makes the -vf parsing code completely independent from other options. A bit of that code was used by the mechanism removed with this commit.
* m_option: split out sub-config parsingwm42013-04-211-37/+54
|
* bstr: add bstrto0()wm42013-04-211-0/+6
|
* bstr: add bstrspn()wm42013-04-212-0/+10
|
* x11_common: minor simplificationwm42013-04-211-13/+6
|
* demux_lavf: fix subtitle seeking before start of the filewm42013-04-211-2/+7
| | | | | | | | | | | | | | | | | | When trying to seek before the start of the file, which usually happens when using the arrow keys to seek to the start of the file, external libavformat demuxed subtitles will be invisible. This is because seeking in the external subtitle file fails, so the subtitle demuxer is left in a random state. This is actually similar to the normal seeking path, which has some fallback code to handle this situation. Add such code to the subtitle seeking path too. (Normally, all demuxer support av_seek_frame(), except subtitles, which support avformat_seek_file() only. The latter was meant to be the "new" seeking API, but this never really took off, and using it normally seems to cause worse seeking behavior. Or maybe we just use it incorrectly, nobody really knows.)
* mplayer: prefer -sub/-subfile subs over auto-loaded subswm42013-04-202-2/+9
| | | | | | | | | Before this commit, it was more or less random which subtitle was preferred if there was both an auto-loaded external subtitle, and a subtitle loaded via -sub or -subfile. -sub subtitles happened to be preferred over auto-loaded subs, while -subfile didn't. Fix the -subfile case, and make the behavior consistent by making the selection behavior explicit.
* demux_mkv: always set track->codec_id to a stringwm42013-04-201-1/+3
| | | | | Otherwise audio/video/sub track handling code would dereference the NULL pointer.
* subassconvert: add more web colorswm42013-04-201-24/+153
| | | | | | | | Now includes the complete list from [1] at this time. Switch from BGR to RGB to match with that list. [1] http://www.w3.org/TR/css3-color/#svg-color
* core: display subtitle codec in track listingwm42013-04-203-4/+13
| | | | | Also switch the subrip and subviewer names, which obviously have been confused.
* demux_mkv: always add subtitle trackswm42013-04-201-26/+26
| | | | Even if the codec is unknown.
* demux: remove some unused sh_video_t fieldswm42013-04-204-15/+1
| | | | Completely mysterious, and its values were never actually used.
* demux: get rid of sh_common_twm42013-04-202-21/+14
| | | | | | The only reason this existed was the parsing code. Even though it could have been used for video, it's audio-only, so just move this to sh_audio_t.
* sub, demux: identify subtitle types with the codec namewm42013-04-2012-92/+91
| | | | | | | | | Get rid of the 1-char subtitle type field. Use sh_stream->codec instead just like audio and video do. Use codec names as defined by libavcodec for simplicity, even if they're somewhat verbose and annoying. Note that ffmpeg might switch to "ass" as codec name for ASS, so we don't bother with the current silly "ssa" name.
* av_common: allow calling mp_codec_to_av_codec_id() with NULLwm42013-04-201-7/+9
| | | | Helps reducing special cases.
* demux: remove useless vid/aid/sid fieldswm42013-04-203-7/+1
| | | | | Only demux_ts.c used sid in one case, replace that by reading the same value from another location.
* demux: fix clearing of input paddingwm42013-04-201-2/+2
| | | | | | MP_INPUT_BUFFER_PADDING_SIZE and FF_INPUT_BUFFER_PADDING_SIZE are both 16. The doxygen for FF_INPUT_BUFFER_PADDING_SIZE says only the first 23 bits must to be 0, but this is probably a lie.
* demux_mkv: introduce new_demux_packet_from() and use itwm42013-04-203-10/+15
|
* demux: remove some unused thingswm42013-04-203-47/+4
|
* command: try to switch subs too for program propertywm42013-04-201-2/+4
| | | | Untested, but why not.
* demux_lavf: simplifywm42013-04-201-147/+74
| | | | | | | | | | | | | | This removes the stream handling mess by using a single list for all stream types. One consequence is that new streams are always set to AVDISCARD_ALL, which could be an issue if packets are read before initializing other streams. However, this doesn't seem to an issue for various reasons, so we don't do anything about it. The new code strictly assumes that libavformat never removes or reorders streams once added to AVFormatContext->streams. Undefined behavior will result if it does.
* demux_mkv: simplify use of demuxer APIwm42013-04-201-106/+62
| | | | | | | mkv_track_t now references sh_stream directly, instead of using an ID. Also remove all accesses to demux_stream (demuxer->video etc.). Remove some slave-mode things on the way, like "ID_SI