aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* demux_edl: move implementationGravatar wm42015-02-17
| | | | Same deal as with demux_cue, and a separate commit for the same reasons.
* demux_cue: make independent from MPContextGravatar wm42015-02-17
| | | | Also see previous commit(s).
* demux_cue: move implementationGravatar wm42015-02-17
| | | | | | | | Move the implementation, of which most was in tl_cue.c, to demux_cue.c. Currently, this is illogical, because tl_cue.c still accesses MPContext. This is going to change, and then it will be better if everything is in demux_cue.c. This is only a separate commit to distinguish code movement and actual work; the next commit will do the actual work.
* demux: copy priv pointer tooGravatar wm42015-02-17
| | | | | Weird, but helps with the case a demuxer gets handed its own instance from outside.
* matroska: move timeline code to demux/Gravatar wm42015-02-17
| | | | | Separate from previous commit, because git is bad at tracking file renames when the file contents are also changed.
* matroska: make timeline code independent of MPContextGravatar wm42015-02-17
|
* player: use a separate context for timeline loader stuffGravatar wm42015-02-17
| | | | | | | | | | | | | | | | | | | | | | | | Instead of accessing MPContext in player/timeline/*, create a separate context struct, which the timeline loaders fill out. It turns out that there's not much in the way too big MPContext that these need to access. One major PITA is managing (and closing) the set of open demuxers. The problem is that we need a list of all demuxers to make sure no unneeded streams are enabled. This adds a callback to the demuxer_desc struct, with the intention of leaving to to the demuxer to call the right loader, instead of explicitly checking the demuxer type and dispatching manually in common code. I also considered making the timeline part of the demuxer state, but decided against: it's too much of a mess wrt. memory management and threading, and also doesn't make it clear who owns the child demuxers. With the struct timeline decoupled from the demuxer state, it's at least somewhat clear that the child demuxers are independent from the "main" demuxer. The actual changes to player/timeline/* are separated in the following commits, because they're quite verbose. Some artifacts will be removed later as soon as there's only 1 timeline loading mechanism.
* demux: chapters without metadata are allowedGravatar wm42015-02-17
| | | | Makes some of the following commits slightly simpler. Also fix a typo.
* player: use a macro to remove an element from an arrayGravatar wm42015-02-17
| | | | Should be equivalent.
* player: actually close files when using sub_removeGravatar wm42015-02-17
| | | | | | | | | Also effects some other cases. The real reason for this is for keeping track of which demuxers can be closed (see following commit). Since I don't want to use reference counting for this, some sort of simplistic mark-and-sweep is done to determine whether a demuxer is still needed.
* DOCS/client-api-changes: mark 0.8.0 releaseGravatar wm42015-02-17
| | | | | (There was a missing version bump for the msg-level change; just move it under 1.14.)
* demux_lavf: hack against hls showing "100%" positionGravatar wm42015-02-17
| | | | | | | | | | | | | The HLs protocol consists of a "playlist" main file, which mpv downloads and passes to the HLS demuxer. The HLS demuxer actually requests segment files containing media data on its own. The packets read from the demuxer have a source file position set, but it's not from the main file. This leads to a strange effect: as a last fallback, the player will calculate the approximate playback position from the file position/size ratio, and since the main file is tiny, this will always show 100%. Fix this by resetting the packet file position. This doesn't affect the case when HLS actually reports a duration.
* command: add rescan_external_filesGravatar wm42015-02-16
| | | | | | | | | Requested. Hopefully will be useful for things that download and add external subtitles on demand. Or something. Closes #1586.
* command: nicer OSD message when setting audio-deviceGravatar wm42015-02-16
| | | | Requested.
* etc/input.conf: remove a leftoverGravatar wm42015-02-16
| | | | This is already mapped by default.
* vo_opengl: glsl: remove trailing \Gravatar wm42015-02-16
| | | | | This should be no problem... but it _might_ help with #1536, so it's worth a try.
* vf_vapoursynth: replace a hack with a newer VS API functionGravatar wm42015-02-16
| | | | | The new function does exactly what we need. Replaces the old hack, which created the vscore by running an empty script.
* m_config: log options set by the client API tooGravatar wm42015-02-16
|
* sub: mess with styling defaults, change --ass-use-margins behaviorGravatar wm42015-02-16
| | | | | | | | | | | | | | | | | | | Now --ass-use-margins doesn't apply to normal subtitles anymore. This is probably the inverse from the mpv behavior users expected so far, and thus a breaking change, so rename the option, that the user at least has a chance to lookup the option and decide whether the new behavior is wanted or not. The basic idea here is: - plain text subtitles should have a certain useful defalt behavior, like actually using margins - ASS subtitles should never be broken by default - ASS subtitles should look and behave like plaintext subtitles if the --ass-style-override=force option is used This also subtly changes --sub-scale-with-window and adds the --ass- scale-with-window option. Since this one isn't so important, don't bother with compatibility.
* options: mark some more options as runtime-settableGravatar wm42015-02-16
| | | | | Most of these are in the category of options which can be changed without issues, but which will not take effect immediately.
* osd: customizable subtitle and OSD positionGravatar wm42015-02-16
| | | | | | You can set in which "corner" the OSD and subtitles are shown. I'd prefer it a bit more general (so you could set the alignment using a factor), but the libass API does not provide this.
* osd: make it possible to have different subtitle vs. OSD defaultsGravatar wm42015-02-16
| | | | | | | | Until now, they used exactly the same defaults for the styling options. The defaults were shared, so it was impossible to have different defaults. Change this. This requires duplicating the full default struct, even for settings that are the same. The list of options is still shared, though.
* mpv.desktop: Add zh-TW and zh-CN translationsGravatar Skyrainfit2015-02-16
|
* osxbundle: config file special case isn't needed anymoreGravatar wm42015-02-15
| | | | | | The previous commit effectively fixes the mess caused by 'config' vs. 'mpv.conf', and the hack introduced by commit e01a6dac and extended by commit db167cd4 isn't needed anymore.
* player: undeprecate 'config' filesGravatar wm42015-02-15
| | | | | | | Actually, it's pretty simple to look for multiple filenames at once, since mp_find_all_config_files() is already a bit "special" anyway. See #1569. Reverts most of commit db167cd4 (keeps osx-bundle.conf).
* vd_lavc: uninit the hwdec backend after closing the decoderGravatar wm42015-02-14
| | | | | | | | | | | | | | | | | A recent behavior change in libavcodec's h264 decoder keeps at least 1 surface even after avcodec_flush_buffers() has been called. We used to flush the decoder in order to make sure all surfaces are free'd, so that the hw decoder can be safely uninitialized. This doesn't work anymore. Fix it by closing the AVCodecContext before the hw decoder is uninitialized. This is actually simpler and more robust. It seems to be well-supported too. Fixes invalid read accesses with vaapi-copy and dxva2-copy. These destroyed the hwdec API fully on uninit, and could not deal with surfaces surviving the decoder. Probably fixes #1587.
* x11: fix uninitialized variable readsGravatar wm42015-02-14
| | | | This line of code ended up in the wrong block in commit cd6dfcbe.
* ao: fix null dereferenceGravatar Stefano Pigozzi2015-02-14
|
* player: fix audio-device-list updatesGravatar wm42015-02-14
| | | | | | | The way the AO wakes up the playloop has nothing to do with events; instead we must query the events on the AO once the playloop was woken up. Querying the events in every playloop iteration is thus the correct way to do this.
* client API: clarify filename string encodingGravatar wm42015-02-14
| | | | | | | Admittedly, the behavior on Windows is not quite straightforward. The behavior on the other platforms is equivalent to fopen(). Fixes #1585.
* demux: fix dropped subtitle packets with the new stream switchingGravatar wm42015-02-14
| | | | | | | | | | | | | | If the previous subtitle packet is too far back, and the refresh seek won't pick it up, and the packet never comes again. As a consequence, the refresh mode was never stopped on the subtitle stream, which caused all packets to be discarded. Fix by assuming the file position is monotonically increasing; then it will resume even if a packet _after_ the intended resume point is returned. This introduces a new requirement on how the demuxer behaves. (I'm not sure if mp4 actually satisfies this requirement in all cases.) Fixes a regression introduced by commit f9f2e1cc.
* cocoa: remove unused functionGravatar Stefano Pigozzi2015-02-14
|
* ao_coreaudio: add support for hotplug notificationsGravatar Stefano Pigozzi2015-02-14
| | | | | | | | | | This commit adds notifications for hot plugging of devices. It also extends the old behaviour of the `audio-out-detected-device` property which is now backed by the hotplugging code. This allows clients to be notified when the actual audio output device changes. Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's device selection code is a bit fragile.
* x11: add XK_Cancel to the list of special keysGravatar Martin Herkt2015-02-14
| | | | | Some IR receivers emit this key by default for remote control buttons. Make it mappable.
* Fix build on OSX broken by previous commitGravatar wm42015-02-13
| | | | Hopefully.
* vf_vapoursynth: add display refresh rate propertyGravatar Julian2015-02-13
| | | | | This value is not necessarily trustworthy (it might change) and can be 0.
* x11: return a framerate even if no window is mappedGravatar wm42015-02-13
| | | | | Falls back to the first display in the list returned by xrandr. Not entirely correct, but makes some people happy (see #1575).
* player: deprecate 'config' files (use mpv.conf), warn against clashesGravatar wm42015-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently there's at least one distro which ships a /etc/mpv/mpv.conf file (mpv doesn't install such a file). This breaks config files named 'config' located in the user's mpv config directory, because mpv first loads files named 'config' and then 'mpv.conf'. There is no mechanism for putting files with different names into the same config path order. (Even worse, that mpv.conf file only set an option to the default value. Why do distros always do very stupid things?) Print a warning on collisions. Although using 'config' was well-supported, supporting both names is starting to become messy, so deprecate 'config' and print a warning if one is found. At least we will be able to remove the whole mess once 'config' files are ignored... This also affects the osx-bundle, which intentionally used these not-so- optimal semantics. Solve it in a different way. (Unfortunately with an ifdef - it's not required, but having to explain everyone why mpv tries to load a osx-bundle.mpv file on Linux and Windows would consume energy.) Closes #1569.
* command: mark get_property as deprecatedGravatar wm42015-02-13
| | | | | Using it just makes no sense. But we're really being nice about this and don't remove it immediately.
* x11: make all XF86 special keys mappableGravatar wm42015-02-13
| | | | | | | | Makes all keys documented in XF86keysym.h mappable. This requires the user to deal with numeric keycodes; no names are queried or exported. This is an easy way to avoid adding all the hundreds of XF86 keys to our X11 lookup table and mpv's keycode/name list.
* ipc: put playback core to sleep while dequeuing commandsGravatar wm42015-02-13
| | | | | | | Happens to fix #1581 due to an unfortunate interaction with the way the VO does not react to commands for a while if a video frame is queued. Slightly improves other situations as well, if the client spams mpv with commands during playback.
* demux: hack for instant stream switchingGravatar wm42015-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the delay when switching audio tracks in mkv or mp4 files. Other formats are not enabled, because it's not clear whether the demuxers fulfill the requirements listed in demux.h. (Many formats definitely do not with libavformat.) Background: The demuxer packet cache buffers a certain amount of packets. This includes only packets from selected streams. We discard packets from other streams for various reasons. This introduces a problem: switching to a different audio track introduces a delay. The delay is as big as the demuxer packet cache buffer, because while the file was read ahead to fill the packet buffer, the process of reading packets also discarded all packets from the previously not selected audio stream. Once the remaining packet buffer has been played, new audio packets are available and you hear audio again. We could probably just not discard packets from unselected streams. But this would require additional memory and CPU resources, and also it's hard to tell when packets from unused streams should be discarded (we don't want to keep them forever; it'd be a memory leak). We could also issue a player hr-seek to the current playback position, which would solve the problem in 1 line of code or so. But this can be rather slow. So what we do in this commit instead is: we just seek back to the position where our current packet buffer starts, and start demuxing from this position again. This way we can get the "past" packets for the newly selected stream. For streams which were already selected the packets are simply discarded until the previous position is reached again. That latter part is the hard part. We really want to skip packets exactly until the position where we left off previously, or we will skip packets or feed packets to the decoder twice. If we assume that the demuxer is deterministic (returns exactly the same packets after a seek to a previous position), then we can try to check whether it's the same packet as the one at the end of the packet buffer. If it is, we know that the packet after it is where we left off last time. Unfortunately, this is not very robust, and maybe it can't be made robust. Currently we use the demux_packet.pos field as unique packet ID - which works fine in some scenarios, but will break in arbitrary ways if the basic requirement to the demuxer (as listed in the demux.h additions) are broken. Thus, this is enabled only for the internal mkv demuxer and the libavformat mp4 demuxer. (libavformat mkv does not work, because the packet positions are not unique. Probably could be fixed upstream, but it's not clear whether it's a bug or a feature.)
* demux_mkv: return unique file positions for all packetsGravatar wm42015-02-13
| | | | | | | | | | | | | Until now, some packets could return the same file position if they were split off from a Matroska-level packet. This was perfectly fine, because the file position isn't used for anything overly important (it uses it to estimate playback position if no other information is available). The following commit will use the demux_packet.pos field as unique ID (as a simplification), so make the demuxer export more finegrained information. Also, the last_filepos field didn't have to be global, at least not anymore.
* vo_opengl: fix smoothmotion coefficient calculationGravatar Stefano Pigozzi2015-02-13
| | | | | Using prev_pts as the start of the scale was plain wrong. Change it to prev_vsync.
* cocoa: fix exiting the command line playerGravatar wm42015-02-13
| | | | | | | | Commit e920a00eb assumed that terminate_cocoa_application() actually would exit. But apparently that is not always the case; e.g. mpv --help will just hang. The old code had a dummy exit(0), which was apparently actually called. Fix by explicitly exiting if mpv_main() returns and terminate_cocoa_application() does nothing.
* encoding: fixed-vo option was removedGravatar wm42015-02-13
|
* player: add a --loop=force modeGravatar wm42015-02-12
| | | | | | | Requested. See manpage additions. This also makes the magical loop_times constants slightly saner, but shouldn't change the semantics of any existing --loop option values.
* osx: move code to unset input context to the right placeGravatar wm42015-02-12
| | | | | | | Setting the input context is always called, both in cplayer and libmpv, and under HAVE_COCOA. Unsetting the input context was done only the cplayer uninit call. Also it was under HAVE_COCOA_APPLICATION, so it was not unset in libmpv (dangling pointer).
* osx: move cocoa specific call out of common codeGravatar wm42015-02-12
| | | | This is almost equivalent, and gets rid of the ifdef.
* player: drop explicit exit() callsGravatar wm42015-02-12
| | | | | | | | | The code in main.c calls exit() explicitly, but the code is actually easier to follow by simply exiting from main() instead. The exit() call in av_log.c happens only on severely broken builds, so replace it with abort(). (Shuts up rpmlint warnings.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 07:01:34 +0000