aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* audio/out: fail init on unknown audio bufferGravatar wm42014-09-26
| | | | A 0 audio buffer makes push.c go haywire. Shouldn't normally happen.
* ao_sndio: print a warning when draining audioGravatar wm42014-09-26
| | | | | | | | | | | libsndio has absolutely no mechanism to discard already written audio (other than SIGKILLing the sound server). sio_stop() will always block until all audio is played. This is a legitimate design bug. In theory, we could just not stop it at all, so if the player is e.g. paused, the remaining audio would be played. When resuming, we would have to do something to ensure get_delay() returns the right value. But I couldn't get it to work in all cases.
* ao_sndio: update buffer status on get_delayGravatar wm42014-09-26
| | | | | | get_delay needs to report the current audio buffer status. It's important for A/V sync that this information is current, but functions which update it were called on play() or get_space() calls only.
* ao_sndio: change p->delay to samplesGravatar wm42014-09-26
| | | | | | | This was in bytes, but it's more convenient to use samples (or frames; in any case the smallest unit of audio that includes all channels). Remove the ao->bps line too; it will be set after init() returns.
* ao_sndio: set non-blocking flagGravatar wm42014-09-26
| | | | | | Otherwise the feed thread and the playloop will get randomly blocked. This seems to fix most A/V sync issues.
* ao_sndio: fix some incorrect commentsGravatar wm42014-09-26
| | | | The AO API always uses sample counts.
* old-configure: minor improvementsGravatar wm42014-09-26
| | | | | Use a trap to remove the temp dir on exit. Write config.log to old_build instead of the top-level dir.
* build: add -Wno-format-zero-lengthGravatar wm42014-09-26
| | | | | | This warning makes absolutely no sense. Passing an empty string to printf-like functions is perfectly fine. In the OSD case, it just sets an empty message, practically clearing the OSD.
* demux_mkv: don't use default_duration for parsed packetsGravatar wm42014-09-26
| | | | | | | | | Makes it behave slightly better for VP9. This is also the behavior libavformat has. Also while we're at it, don't set duration except for the first packet. Normally we don't use the duration except for subtitles (which are never parsed or "laced"), so this should make no observable difference.
* stream_bluray: allow opening BDMV directories directlyGravatar wm42014-09-26
| | | | | | | | Similar as the previous commits. Most of the code is actually copied from the stream_dvdnav.c code, but I'd rather prefer to duplicate it, than to entangle them. The latter would probably result in terrible things in a few years.
* stream_dvdnav: allow opening DVD directories directlyGravatar wm42014-09-26
| | | | | | | | Same hack as with stream_dvd.c. VIDEO_TS.IFO files are now opened via stream_dvdnav.c. Directories containing a VIDEO_TS.IFO or VIDEO_TS/VIDEO_TS.IFO file are also opened with it.
* stream_dvd: better .ifo probingGravatar wm42014-09-25
| | | | | | | | | | | | | | | stream_dvd.c includes a pseudo-protocol that recognizes .IFO files, and plays them using libdvdread. This was relatively lazy, and could perhaps easily trigger with files that just had the .ifo extension. Make the checks stricter, and even probe the file header. Apparently the first bytes in an .ifo file are always "DVDVIDEO-VTS", so check for this. Refuse to load the main "video_ts.ifo". The plan is to use stream_dvdnav for it. This also removes at least 1 memory leak.
* player: do not wrongly clear OSD bar stops, reindentGravatar wm42014-09-25
| | | | | | | | | | set_osd_bar_chapters() always cleared the OSD bar stops, even if the current bar was not the seek bar. Obviously it should leave the state of the bar alone in this case. Also change the function control flow so that we can drop one indentation level, and do the equivalent change for the other OSD bar functions.
* player: simplify OSD message handling codeGravatar wm42014-09-25
| | | | | | | | | | | Eliminate the remains of the OSD message stack. Another simplification comes from the fact that we do not need to care about time going backwards (we always use a monotonic time source, and wrapping time values are practically impossible). What this code was pretty trivial, and by now unnecessarily roundabout. Merge get_osd_msg() into update_osd_msg(), and add_osd_msg() into set_osd_msg_va().
* player: move code to make playloop smallerGravatar wm42014-09-25
| | | | | This is basically a cosmetic change, although it weirdly also affects the percent position in encoding mode.
* player: rate-limit OSD text updateGravatar wm42014-09-25
| | | | | | | | | | | | | | | There's no need to update OSD messages and the terminal status if nobody is going to see it. Since the player doesn't block on video display anymore, this update happens to often and probably burns slightly more CPU than necessary. (OSD redrawing is handled separately, so it's just mostly useless text processing and such.) Change it so that it's updated only on every video frame or all 50ms (whatever comes first). For VO OSD, we could in theory try to lock to the OSD redraw heuristic or the display refresh rate, but that's more complicated and doesn't work for the terminal status.
* player: fix OSD redraw heuristic with audio-only modeGravatar wm42014-09-25
| | | | | | When using --force-window (and no video or cover art), this heuristic prevents any redrawing during seeking. It should be applied only if there is any form of video.
* sub: approximate subtitle display in no-video modeGravatar wm42014-09-25
| | | | | | | | | | | | | | | | | | | | | | This makes subtitle display somewhat work if no video is displayed, but a VO window exists (--force-window or cover art display). The main problem with normal subtitle display is that it's locked to video: it uses the video PTS as reference, and the subtitles advance only if a new video frame is displayed. In audio-only mode on the other hand, no video frame is ever displayed (or only 1 in the cover art case). You would need a workaround to adjust the subtitle PTS, and you would have to decide with what frequency to update the display. In general, there is no "right" display FPS for subtitles. Some formats (ASS) have animations parameterized by time, and any refresh rate could be used. Sidestep these problems by enabling the text OSD-based subtitle mechanism. This is similar to --no-sub-ass, and updates and renders subtitles with plain OSD. It has some caveats: no bitmap subs, somewhat incorrect timing, no formatting. Timing in particular is a bit strange and depends how often the audio output asks for new data, or other events that happen to wakeup the playloop.
* Remove mpbswap.hGravatar wm42014-09-25
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* stream_cdda, demux_raw: always use s16leGravatar wm42014-09-25
| | | | | | | | | | | | | stream_cdda's output format is linked to demux_raw's default audio format, and at least we don't care enough to provide a separate mechanism to let stream_cdda explicitly set the format, so they must match. Judging from the existing code, it looks like CDDA always outputs little endian. stream_cdda.c changed this back to native endian (what demux_raw expects). Just make them both little endian. This requires less code, and also having a raw demuxer's behavior depend on the endianness of the machine isn't very sane anyway.
* osc: update cache displayGravatar ChrisK22014-09-25
| | | | now similar to what the status line displays
* demux_mkv: get rid of MS structsGravatar wm42014-09-25
| | | | | | | See previous commits. This finally replaces directly reading the file data into a struct with reading them manually. In theory this is more portable (no alignment issues and other things). For the most part, it's nice seeing this gone.
* audio: remove WAVEFORMATEX from internal demuxer APIGravatar wm42014-09-25
| | | | | Same as with the previous commit. A bit more involved due to how the code is written.
* video: remove BITMAPINFOHEADER from internal demuxer APIGravatar wm42014-09-25
| | | | | | | | | | MPlayer traditionally did this because it made sense: the most important formats (avi, asf/wmv) used Microsoft formats, and many important decoders (win32 binary codecs) also did. But the world has changed, and I've always wanted to get rid of this thing from the codebase. demux_mkv.c internally still uses it, because, guess what, Matroska has a VfW muxing mode, which uses these data structures natively.
* audio: confine demux_mkv audio PCM hackGravatar wm42014-09-24
| | | | | | | | Let codec_tags.c do the messy mapping. In theory we could simplify further by makign demux_mkv.c directly use codec names instead of the MPlayer-inherited "internal FourCC" business, but I'd rather not touch this - it would just break things.
* audio: decouple demux and audio decoder/filter sample formatsGravatar wm42014-09-24
| | | | | | | | | | | | | | | | | | | | 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 widthGravatar wm42014-09-24
| | | | This was wrong since the initial commit.
* TOOLS/umpv: drop unnecessary checkGravatar wm42014-09-24
| | | | | 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 notationGravatar shdown2014-09-24
|
* TOOLS/mpv_identify.sh: remove pointless escapeGravatar shdown2014-09-24
|
* TOOLS/idet.sh: add descriptionGravatar shdown2014-09-24
| | | | | | 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 assignmentsGravatar shdown2014-09-24
|
* player: change --keep-open semanticsGravatar wm42014-09-24
| | | | By popular request.
* player: show correct playback time with --keep-open --no-videoGravatar wm42014-09-24
| | | | Whatever.
* player: --loop-file takes precedence before --keep-openGravatar wm42014-09-24
|
* ao_oss: improve format negotiation, and hopefully fix pass-throughGravatar wm42014-09-24
| | | | | | | 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 failureGravatar wm42014-09-24
| | | | | | | 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: unbreakGravatar wm42014-09-23
| | | | Oops.
* ao_pulse: digital pass-throughGravatar wm42014-09-23
| | | | | | | | 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 stateGravatar wm42014-09-23
| | | | | 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()Gravatar wm42014-09-23
| | | | Needed for compressed audio pass-through later.
* audio: cleanup spdif format definitionsGravatar wm42014-09-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 codeGravatar wm42014-09-23
| | | | | | | | | | | | | 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 formatsGravatar wm42014-09-23
| | | | | | | | | | | | | | | | | | | | 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 formatsGravatar wm42014-09-23
| | | | | | | | | | | | | | | | | | | | | | 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 incrementallyGravatar wm42014-09-23
| | | | | | | | | | | | | | | | | 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-fileGravatar wm42014-09-22
| | | | | | | | | | 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 libmpg123Gravatar wm42014-09-22
| | | | | | | | | | | | | | | | | 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 messageGravatar wm42014-09-22
| | | | | | More consistent with other output, such as the terminal status line. Also see issue #1103.
* video: filter new frames at a better time (2)Gravatar wm42014-09-22
| | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-26 17:51:37 +0000