summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* audio: decouple demux and audio decoder/filter sample formatswm42014-09-247-85/+66
| | | | | | | | | | | | | | | | | | | | For a while, we used this to transfer PCM from demuxer to the filter chain. We had a special "codec" that mapped what MPlayer used to do (MPlayer passes the AF sample format over an extra field to ad_pcm, which specially interprets it). Do this by providing a mp_set_pcm_codec() function, which describes a sample format in a generic way, and sets the appropriate demuxer header fields so that libavcodec interprets it correctly. We use the fact that libavcodec has separate PCM decoders for each format. These are systematically named, so we can easily map them. This has the advantage that we can change the audio filter chain as we like, without losing features from the "rawaudio" demuxer. In fact, this commit also gets rid of the audio filter chain formats completely. Instead have an explicit list of PCM formats. (We could even just have the user pass libavcodec PCM decoder names directly, but that would be annoying in other ways.)
* ao_sndio: fix U24 bit widthwm42014-09-241-1/+1
| | | | This was wrong since the initial commit.
* TOOLS/umpv: drop unnecessary checkwm42014-09-241-2/+0
| | | | | This was supposed to make sure that argv[1:] does not fail, but Python actually allows mismatching bounds for slicing.
* TOOLS/umpv: use python octal notationshdown2014-09-241-1/+1
|
* TOOLS/mpv_identify.sh: remove pointless escapeshdown2014-09-241-1/+1
|
* TOOLS/idet.sh: add descriptionshdown2014-09-241-0/+3
| | | | | | Just a copy of c0cd58e3f5b1daff58ad5ca48b964a2b1fb86d6d commit message (with a small fix: ildetect.sh+ildetect.so, not ildetect.sh+ildetect.sh).
* TOOLS/idet.sh: remove unused and duplicated assignmentsshdown2014-09-241-2/+0
|
* player: change --keep-open semanticswm42014-09-242-2/+11
| | | | By popular request.
* player: show correct playback time with --keep-open --no-videowm42014-09-241-1/+2
| | | | Whatever.
* player: --loop-file takes precedence before --keep-openwm42014-09-241-2/+2
|
* ao_oss: improve format negotiation, and hopefully fix pass-throughwm42014-09-241-45/+45
| | | | | | | Digital pass-through was probably broken. Possibly fix it (no way to test). This also should make the logic slightly saner. Fortunately, it's unlikely that anyone who uses OSS has a spdif setup.
* ao_coreaudio: fix build failurewm42014-09-241-1/+1
| | | | | | | Commit 5b5a3d0c broke this. The really funny thing is that this code was actually always under "#if BYTE_ORDER == BIG_ENDIAN". The breaking commit just edited this code slightly, but it must have failed to compile on big endian long before (since over 1 year ago, commit d3fb58).
* ao_oss: unbreakwm42014-09-231-2/+2
| | | | Oops.
* ao_pulse: digital pass-throughwm42014-09-231-20/+46
| | | | | | | | Should be able to pass-through AC3, DTS, and others. It seems PulseAudio wants players to fallback to PCM on certain events signaled by the server, but we don't implement that. There's not much documentation available anyway.
* ao_pulse: correctly wait for stream statewm42014-09-231-1/+8
| | | | | This works similar to condition variables; for some reason this apparently worked fine until now, but it breaks with passthrough mode.
* ao_pulse: use pa_stream_new_extended()wm42014-09-231-3/+8
| | | | Needed for compressed audio pass-through later.
* audio: cleanup spdif format definitionswm42014-09-2314-94/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* ao_wasapi: fix fragile format-mapping codewm42014-09-231-28/+19
| | | | | | | | | | | | | This code tried to play with the format bits, and potentially could create invalid formats, or reinterpret obscure formats in unexpected ways. Also there was an abort() call if the winapi or mpv used a format with unexpected bit-width. This could probably easily happen; for example, mpv supports at least one 64 bit format. And what would happen on 8 bit formats anyway? Untested.
* audio: drop swapped-endian audio formatswm42014-09-2325-370/+258
| | | | | | | | | | | | | | | | | | | | Until now, the audio chain could handle both little endian and big endian formats. This actually doesn't make much sense, since the audio API and the HW will most likely prefer native formats. Or at the very least, it should be trivial for audio drivers to do the byte swapping themselves. From now on, the audio chain contains native-endian formats only. All AOs and some filters are adjusted. af_convertsignendian.c is now wrongly named, but the filter name is adjusted. In some cases, the audio infrastructure was reused on the demuxer side, but that is relatively easy to rectify. This is a quite intrusive and radical change. It's possible that it will break some things (especially if they're obscure or not Linux), so watch out for regressions. It's probably still better to do it the bulldozer way, since slow transition and researching foreign platforms would take a lot of time and effort.
* audio: remove swapped-endian spdif formatswm42014-09-237-37/+29
| | | | | | | | | | | | | | | | | | | | | | IEC 61937 frames should always be little endian (little endian 16 bit words). I don't see any apparent need why the audio chain should handle swapped-endian formats. It could be that some audio outputs might want them (especially on big endian architectures). On the other hand, it's not clear how that works on these architectures, and it's not even known whether the current code works on big endian at all. If something should break, and it should turn out that swapped-endian spdif is needed on any platform/AO, swapping still could be done in-place within the affected AO, and there's no need for the additional complexity in the rest of the player. Note that af_lavcac3enc outputs big endian spdif frames for unknown reasons. Normally, the resulting data is just pulled through an auto- inserted conversion filter and turned into little endian. Maybe this was done as a trick so that the code didn't have to byte-swap the actual audio frame. In any case, just make it output little endian frames. All of this is untested, because I have no receiver hardware.
* vf_vapoursynth: make it possible to get filter output incrementallywm42014-09-231-27/+77
| | | | | | | | | | | | | | | | | Until now, we always required the playback core to decode a new frame to get more output from the filter. That seems to be completely unnecessary, because filtered results may arrive before that. Add a filter_out callback, and restructure the code such that it can return any filtered frames, or block if it hasn't read at least one frame. In the worst case, it still can happen that bursts of input requests and output requests happen. (This commit tries to reduce burst-like behavior, but it's not entirely possible due to the indeterministic nature of VS threading.) This is a similar change as with 95bb0bb6.
* player: allow passing number of loops to --loop-filewm42014-09-223-6/+14
| | | | | | | | | | E.g. --loop-file=2 will play the file 3 times (one time normally, and 2 repeats). Minor syntax issue: "--loop-file 5" won't work, you have to use "--loop-file=5". This is because "--loop-file" still has to work for compatibility, so the "old" syntax with a space between option name and value can't work.
* audio: prefer libavcodec over libmpg123wm42014-09-221-1/+1
| | | | | | | | | | | | | | | | | libavcodec/libavformat now handles gapless audio better. In theory, this could be implemented with ad_mpg123 too, but since libavformat strips metadata from mp3 files and passes pure mp3 packets to the decoders only, this can't work by itself. Instead, the player must pass this metadata separately. libav* do this relatively transparently over packet "side data" (attached to AVPacket). It might also be possible to let libmpg123 handles all this by implementing it as demuxer that outputs PCM, but that would have other problems, and I think it's better to make libavformat work correctly. libmpg123 can still be used with '--ad=mpg123:mp3'. Also see issue #1101.
* command: no space before "%" in volume default OSD messagewm42014-09-221-1/+1
| | | | | | More consistent with other output, such as the terminal status line. Also see issue #1103.
* video: filter new frames at a better time (2)wm42014-09-221-7/+9
| | | | | | | | | | | | | | | | | We generally want 2 things: 1. minimal wakeups for decoding each frame 2. minimal number of frames decoded on continuous seeking Commit 35810cb8 changed this a bit, and fixed 1. But it broke 2., and now it decodes 2 frames instead of 1 when you keep seeking (arrow key held down or such). This made seeking appear slower. Fix this by making the logic more explicit. In particular, call the filters only if we actually try to get a new frame. When playing with --no-audio and all other distractions disabled (like OSC), it still wakes up 2 times per frame - but the second time is merely because the VO didn't accept the new frame yet.
* osd: fix --term-osd=nowm42014-09-221-1/+1
| | | | | | | It didn't actually disable it. I'm actually not sure what this option is useful for, but fixing it can't harm.
* command: improve "osd" commandwm42014-09-222-10/+9
| | | | | | | Be less annoying, print the actual OSD level instead of something meaningless, but still clear the OSD if OSD level 0 (no OSD) is set. Remove the special handling for terminal OSD, that was just dumb.
* command: use show_property_osd() sub_stepwm42014-09-221-2/+1
| | | | Simpler and more consistent.
* command: when changing a property, always show it on OSDwm42014-09-211-1/+4
| | | | | | | | | | | | | This means that if a property not listed in property_osd_display[] is changed, it will be shown on the OSD as "name: ${name}". Properties that are listed in property_osd_display[] and have osd_name not set stay invisible by default. This is used for "pause" and "fullscreen", which (like before this commit) are not shown by default, because it would be annoying. The defaults still can be changed with command prefixes (osd-msg, no-osd, others).
* command: simplify OSD property display codewm42014-09-213-54/+42
| | | | | | | | | | | | | | | | Probably not many user-visible changes. One notable change is that the terminal OSD code for OSD bar fallback handling is removed with no replacement. Instead, terminal OSD gets the same text message as normal OSD. For volume, this is ok, because the text message is reasonable. Other properties will look worse, but could be adjusted, and there are in fact no other such properties that would be useful in audio-only mode. The fallback message for seeking falls away as well, but that message was useless anyway - the terminal status line provides all information anyway. I believe the show_property_osd() code is now much easier to follow.
* command: allow changing some OSD-related options even with no VOwm42014-09-211-2/+0
| | | | | | | If no VO was open, these options couldn't be changed or even queried. Although these properties are nearly useless if no VO exists, there's actually no good reason to forbid querying or setting them. Also, even if the VO is created, it doesn't mean the VO window was created.
* command: remove unneeded ifdefswm42014-09-211-4/+4
| | | | | | | | Why bother? Also, since now some properties could be mapped to non-existing options, but mp_property_generic_option() is used, deal with this case and return a not-found error code.
* command: always show OSD message when changing volume etc.wm42014-09-211-15/+3
| | | | | | | | | | | | | | If there's a command that uses the OSD by default, then always print the associated message (or a fallback made of name + value), even if the command has an associated OSD bar. This means volume, gamma, panscan, etc. all show both a message and a OSD bar. Also, add a '%' to the volume message. The extra_msg thing is not needed anymore. See issue #1103.
* options: remove --volstepwm42014-09-216-20/+14
| | | | | | | It's just confusing; users are encouraged to edit input.conf instead (changing the argument to the "add" command). Update input.conf to keep the old behavior.
* TOOLS: idet: remove extra '$' in $(()) expansionBen Boeckel2014-09-211-4/+4
|
* manpage: clarify vf_pp docswm42014-09-211-8/+14
| | | | | Make the note about quoting more prominent. Add a warning that this filter is useless for new files.
* video: fix redrawing when pausing after framedropwm42014-09-211-1/+1
| | | | | | | When pausing after a frame was just dropped, we're logically at the dropped frame, and thus should redraw the dropped frame. This was implemented, but didn't work after unpausing for the second time, because of a minor logic bug.
* video: fix some vo_direct3d crashes due to FFmpeg nonsensewm42014-09-211-1/+2
| | | | | | | | | | | | For incomprehensible reasons, AV_PIX_FMT_GRAY8 (and some others) have a palette. This literally makes no sense and this issue has bitten us before, but it is how it is. This also caused a crash with vo_direct3d: this mapped a texture as IMGFMT_Y8 (i.e. AV_PIX_FMT_GRAY8), and when copying this, it tried to copy the non-existent palette. Fixes #1113.
* TOOLS/umpv: make URL detection consistent with mpv methodshdown2014-09-201-6/+4
| | | | See mp_is_url in options/path.c.
* TOOLS/umpv: print error message to stderrshdown2014-09-201-1/+2
|
* TOOLS/umpv: use MPV environment variable, not UMPV_OPTIONSshdown2014-09-201-10/+8
| | | | Just like the rest of TOOLS/*.sh scripts.
* vo_vdpau: better integration with the generic framedrop codewm42014-09-205-19/+31
| | | | | | | | | | | | | | | | | | | | vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
* vo_vdpau: fix confusion around vsync_intervalwm42014-09-201-10/+9
| | | | | | | vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
* input: explain why we use semaphoreswm42014-09-201-3/+6
| | | | Also switch function names for better self-documentation.
* osdep: hack to fix build with low quality pthreads-w32 headerswm42014-09-201-0/+1
| | | | | | | | | | | | | | | | When compiling semaphore_osx.c on win32, the following error happened: /usr/i686-w64-mingw32/include/semaphore.h:160:6: error: unknown type name 'mode_t' This is because this system header references symbols that are not not defined anywhere. This is clearly a bug in pthreads-w32, but has been known and unfixed since 2012, so add a hack to fix it. We build semaphore_osx.c this way because it saves us an extra configure check. On win32, Linux, etc. it's empty and contains "#include <semaphore.h>" only. Should fix #1108.
* mixer: always restore volume (even with pulse), don't unmutewm42014-09-201-6/+8
| | | | | | | | | | | | | | | | | | Be less clever, and restore the volume state even with AOs like pulse, which have per-application audio. Before this commit we didn't do this, because the volume is global (even if per-application), so the volume will persist between invocations. But to me it looks like always restoring is less tricky and makes for easier to understand semantics. Also, don't always unmute on exit. Unmuting was done even with ao_pulse, and interfered with user expectations (see #1107). This might annoy some users, because mpv will change the volume all the time. We will see. Fixes #1107.
* manpage: document terminal status line componentswm42014-09-201-0/+45
| | | | | (The classic MPlayer documentation had this in separate files, but we deleted them ages ago.)
* player: rename "Late:" field to "SD:"wm42014-09-201-1/+1
| | | | | | | | | Follow up to previous commit. This is probably confusing from a user point of view, since this field shouldn't show up normally anymore. (Before this commit, it could show up sporadically when a slow operation was performed during playback, such as switching fullscreen.)
* video: actually count decoder-dropped frameswm42014-09-201-4/+7
| | | | | | | | | Normally, feeding a packet to the decoder should always return a frame _if_ we received a frame before. So while we can't know exactly whether a frame was dropped, at least the normal case is easily detectable. This means we display something closer to the actual framedrop count, instead of a bad guess.
* video: improve decoder-based framedropping modewm42014-09-201-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the "old" framedropping mode (derived from MPlayer). At least in the mplayer2/mpv source base, it stopped working properly years ago (or maybe it never worked properly). For one, it depends on the video framerate, which assume constant framerate. Another problem was that it could lead to freezing video display: video could get so much behind that it couldn't recover from framedrop. Make some small changes to improve this. Don't use the current audio position to check how much we are behind. Instead, use the last known A/V difference. last_av_difference is updated only when a video frame is scheduled for display. This means we can keep stop dropping once we're done catching up, even if video is technically still behind. What helps us here that this forces a video frame to be displayed after a while. Likewise, we reset the dropped_frames count only when scheduling a new frame for display as well. Some inspiration was taken from earlier work by xnor (see issue #620), although the implementation turned out quite different. This still uses the demuxer-reported (possibly broken) FPS value. It also doesn't account for filters changing FPS. We can't do much about this, because without decoding _and_ filtering, we just can't know how long a frame is. In theory, you could derive that from the raw packet timestamps and the filter chain contents, but actually doing this is too involved. Fortunately, the main thing the FPS affects is actually the displayed framedrop count.
* player: make code more obviouswm42014-09-201-2/+2
| | | | Or at least I think so.
* player: use backwards flag for seeking external trackswm42014-09-201-1/+1
| | | | | Otherwise, the external track could end up at a position that's too late.
* player: reset last_av_difference if not applicablewm42014-09-202-0/+2
| | | | | | Don't let stale values linger around. Also fix a slightly related case in audio.c.
* af_hrtf: initialize coefficient arrayswm42014-09-191-0/+25
| | | | | | | | | | | | | | | Sometimes, --af=hrtf produces heavy artifacts or silence. It's possible that this commit fixes these issues. My theory is that usually, the uninitialized coefficients quickly converge to sane values as more audio is filtered, which would explain why there are often artifacts on init, with normal playback after that. It's also possible that sometimes, the uninitialized values were NaN or inf, so that the artifacts (or silence) would never go away. Fix this by initializing the coefficients to 0. I'm not sure if this is correct, but certainly better than before. See issue #1104.
* input: add locking for repeat infoAlexander Preisinger2014-09-191-0/+3
|
* build: update minimum wayland versionAlexander Preisinger2014-09-192-3/+3
| | | | Uh oh.
* wayland: use reported rete and delayAlexander Preisinger2014-09-191-2/+27
| | | | | If native-keyrepeat is true then we set the rate and delay reported by the compositor.
* input: add function for setting repeat infoAlexander Preisinger