summaryrefslogtreecommitdiffstats
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* common: fix version variable declarationswm42014-11-022-2/+3
| | | | This was stupid.
* common: fix \x-style escapingshdown2014-10-161-1/+1
| | | | This was rejecting correct escapes and accepting incorrect ones.
* Add some missing "const"swm42014-10-102-2/+2
| | | | | | | The one in msg.c was mistakenly removed with commit e99a37f6. I didn't actually test the change in ao_sndio.c (but obviously "ap" shouldn't be static).
* fix -Wduplicate-decl-specifier warnings with clangStefano Pigozzi2014-10-092-4/+4
|
* msg: fix unwanted blank lineswm42014-10-081-1/+3
| | | | Was broken in a commit earlier this day.
* client API: introduce numeric log levelswm42014-10-082-0/+15
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
* msg, client API: buffer partial lineswm42014-10-081-61/+73
| | | | | | | | | | | | | | | The API could return partial lines, meaning the message could stop in the middle of a line, and the next message would have the rest of it (or just the next part of it). This was a pain for the user, so do the nasty task of buffering the lines ourselves. Now only complete lines are sent. To make things even easier for the API user, don't put multiple lines into a single event, but split them. The terminal output code needed something similar (inserting a prefix header on start of each line). To avoid code duplication, this commit refactors the terminal output so that lines are split in a single place.
* msg, client API: never send the status line as log messagewm42014-10-081-1/+1
| | | | | | | | | | | | | The status line is a bit special; for example it uses special control codes by design and is not terminated with a newline character in order to update it on the terminal without scrolling. It's not helpful for client API users either, and would require special-casing them (emulating aspects of a terminal?). Also, the status line code is explicitly disabled on osd.c unless the --terminal option is enabled, so there was no good way to even enable the status line for the API. Just pretend that the status line does not exist as far as the client API is concerned. It won't be sent as MPV_EVENT_LOG_MESSAGE.
* msg: set an explicit overflow messagewm42014-10-081-1/+1
| | | | | | | | So client API users don't have to worry about this specifically. Also document the overflow case. (Not sure if we really need to do this; maybe it'd be better not to, since this just adds more noise to the docs.)
* stream: redo playback abort handlingwm42014-09-131-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
* player: deal with some corner cases with playlist navigationwm42014-09-092-1/+16
| | | | | | | | | | | | | | | The purpose is making accessing the current playlist entry saner when commands are executed during initialization, termination, or after playlist navigation commands. For example, the "playlist_remove current" command will invalidate playlist->current - but some things still access the playlist entry even on uninit. Until now, checking stop_play implicitly took care of it, so it worked, but it was still messy. Introduce the mpctx->playing field, which points to the current playlist entry, even if the entry was removed and/or the playlist's current entry was moved (e.g. due to playlist navigation).
* player: normalize playlist entries on addwm42014-09-091-1/+2
| | | | This is not necessarily more correct, but it's less trouble.
* player: don't allow remote playlists to load local fileswm42014-09-011-3/+6
| | | | | | | | Because that might be a bad idea. Note that remote playlists still can use any protocol marked with is_safe and is_network, because the case of http-hosted playlists containing URLs using other streaming protocols is not unusual.
* playlist: don't add the base path twicewm42014-09-011-3/+0
| | | | | | | | | | | | Loading a playlist with --playlist from a sub-directory added the playlist's base path twice: one time in the playlist demuxer, and then again in playlist_parse_file(). The latter function is used only for --playlist, so it worked when loading the playlist directly. (This is probably a mess-up when the MPlayer playlist parsers were replaced with newer code.) CC: @mpv-player/stable
* player: always load playlistswm42014-08-311-0/+3
| | | | | | | | | Until now, you had to use --load-unsafe-playlists or --playlist to get playlists loaded. Change this and always load playlists by default. This still attempts to reject unsafe URLs. For example, trying to invoke libavdevice pseudo-demuxer is explicitly prevented. Local paths and any http links (and some more) are always allowed.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-298-9/+9
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* posix: use STD*_FILENO constantsBen Boeckel2014-08-281-2/+2
| | | | | Rather than "magic" numbers, use meaningful constant names provided by unistd.h.
* msg: allow duplicating a mp_logwm42014-08-251-15/+20
| | | | Trivial; this is mostly just reindenting the normal codepath.
* demux: always use AVPacketwm42014-08-251-0/+2
| | | | | | | | | | | | | | | | | | | | | This is a simplification, because it lets us use the AVPacket functions, instead of handling the details manually. It also allows the libavcodec rawvideo decoder to use reference counting, so it doesn't have to memcpy() the full image data. The change in av_common.c enables this. This change is somewhat risky, because we rely on the following AVPacket implementation details and assumptions: - av_packet_ref() doesn't access the input padding, and just copies the data. By the API, AVPacket is always padded, and we violate this. The lavc implementation would have to go out of its way to make this a real problem, though. - We hope that the way we make the AVPacket refcountable in av_common.c is actually supported API-usage. It's hard to tell whether it is. Of course we still use our own "old" demux_packet struct, just so that libav* API usage is somewhat isolated.
* win32: emulate some ANSI terminal escape codeswm42014-08-211-12/+16
| | | | | | | | | | | | | | We already redirect all terminal output through our own wrappers (for the sake of UTF-8), so we might as well use it to handle ANSI escape codes. This also changes behavior on UNIX: we don't retrieve some escape codes per terminfo anymore, and just hardcode them. Every terminal should understand them. The advantage is that we can pretend to have a real terminal in the normal player code, and Windows atrocities are locked away in glue code.
* Improve setting AVOptionswm42014-08-024-85/+39
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* Remove the last remains of slave modewm42014-08-011-1/+1
| | | | | | | | | | | Almost nothing was left of it. The only thing this commit actually removes is support for reading input commands from stdin. But you can emulate this via: --input-file=/dev/stdin --input-terminal=no However, this won't work on Windows. Just use a named pipe.
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-302-0/+11
| | | | | This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
* command: append entries to the end of the playlist with loadlist appendAlessandro Ghedini2014-07-252-0/+10
| | | | | | Currently entries are added after the current playlist element. This is kinda confusing, more so given that "loadfile append" appends at the end of the playlist.
* encode: deal with codec->time_base deprecationwm42014-07-221-5/+4
| | | | This seems to work with both Libav 10 and FFmpeg d3e51b41.
* tags: add copy functionwm42014-07-162-0/+14
|
* build: allow compilation without any atomicswm42014-07-051-0/+4
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* demux, stream: change metadata notificationwm42014-07-052-0/+7
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* av_common: remove unneeded fieldwm42014-06-291-1/+0
| | | | This is actually needed for encoding only, and not decoding. Drop it.
* Revert "encode: make the central lock recursive"Rudolf Polzer2014-06-121-2/+1
| | | | This reverts commit 231c6672140f019257edd26db20fbcfc2554258f.
* encode: make the central lock recursivewm42014-06-121-1/+2
| | | | | | | | Unfortunately, there's a recursive function call in ao_lavc.c (play function), leading to a deadlock. The locking is getting a bit messy, so just make the lock recursive. This fixes #844.
* encode: make option struct localwm42014-06-113-6/+58
| | | | Similar to previous commits.
* Add more constwm42014-06-113-4/+4
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* client API: call wakeup callback if there are new messageswm42014-06-062-2/+12
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* playlist: fix playlist_move on itselfwm42014-05-251-1/+4
| | | | | | | A playlist_move command that moves an entry onto itself (both arguments have the same index) should do nothing, but it did something broken. The underlying reason is that it checks the prev pointer of the entry which is temporarily removed for moving.
* atomics: switch to C11 stdatomic.hwm42014-05-211-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* encoding: No error when the output format doesn't support a stream type at all.Rudolf Polzer2014-05-161-8/+20
| | | | | | | | When writing a video to foo.mp3, the user's intention is clearly to drop the video stream, and similarly, when writing to foo-%d.png, the intention is clearly to drop the audio stream. Now, explicit specification of --no-audio or --no-video is no longer necessary in these cases.
* common: change MP_NOPTS_VALUE definitionwm42014-05-101-2/+2
| | | | | | | | | Use the exact floating point value, instead of a broken integer constant. The expression calculating the constant probably relied on undefined behavior, because it left-shifts a negative value. This also changes the type of the constant to double, which is perfectly fine, and maybe better than an integer constant.
* common: change mp_snprintf_append semanticswm42014-05-052-5/+12
| | | | | | | | Make it more suitable for chaining. This means a function formatting a value to a string using a static buffer can work exactly like mp_snprintf_append itself. Also rename it to mp_snprintf_cat, because that's shorter.
* options: remove deprecated --identifyMartin Herkt2014-05-042-11/+4
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* common: add mp_snprintf_append() utility functionwm42014-04-292-0/+23
|
* stream: remove interrupt callback global variableswm42014-04-251-0/+3
| | | | | | | | | | | | This used global variables for the asynchronous interrupt callback. Pick the simple and dumb solution and stuff the callback into mpv_global. Do this because interrupt checking should also work in the connect phase, and currently stream creation equates connecting. Ideally, this would be passed to the stream on creation instead, or connecting would be separated from creation. But since I don't know yet which is better, and since moving stream/demuxer into their own thread is something that will happen later, go with the mpv_global solution.
* terminal: fix printing of prefixwm42014-04-231-2/+3
| | | | This was subtly change in 5cfb18. Revert the change.
* Remove CPU detection and inline asm handlingwm42014-04-192-83/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* player: add a --dump-stats optionwm42014-04-173-2/+48
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* msg: correct ringbuffer log level comparisonFRAU KOUJIRO2014-04-171-1/+1
|
* New option --no-ometadata to opt out of including metadata when encoding.Rudolf Polzer2014-04-141-1/+2
| | | | | | | This re-allows the previous behaviour of being able to reencode with metadata removed, which is useful when encoding "inconsistently" tagged data for a device/player that shows file names when tags are not present.
* mp_tags: move generic mp_tags stuff into its own .c/.h files in common/Kevin Mitchell2014-04-132-0/+91
| | | | | | rename add_metadata to the more genera/descriptive mp_tags_copy_items_from_av_dictionary Signed-off-by: wm4 <wm4@nowhere>
* player: remove ASX, SMIL and NSC playlist parserswm42014-04-136-1178/+44
| | | | | | | | | | | | | | | | | | | These playlist parsers are all what's left from the old mplayer playlist parsing code. All of it is old code that does little error checking; the type of C string parsing code that gives you nightmare. Some playlist parsers have been rewritten and are located in demux_playlist.c. The removed formats were not reimplemented. ASX and SMIL use XML, and since we don't want to depend on a full blown XML parser, this is not so easy. Possibly these formats could be supported by writing a very primitive XML-like lexer, which would lead to success with most real world files, but I haven't attempted that. As for NSC, I couldn't find any URL that worked with MPlayer, and in general this formats seems to be more than dead. Move playlist_parse_file() to playlist.c. It's pretty small now, and basically just opens a stream and a demuxer. No use keeping playlist_parser.c just for this.
* terminal: pretty print modules for --msgmoduleEvan Purkhiser2014-04-121-2/+26
|
* encode_lavc: copy metadata to output fileAlessandro Ghedini2014-03-303-1/+20
| | | | | | | | Closes #684 Signed-off-by: wm4 <wm4@nowhere> Includes some minor cosmetic changes additional to the original PR.
* encode: add lockingwm42014-03-092-4/+43
| | | | | | | | | | Since the AO will run in a thread, and there's lots of shared state with encoding, we have to add locking. One case this doesn't handle correctly are the encode_lavc_available() calls in ao_lavc.c and vo_lavc.c. They don't do much (and usually only to protect against doing --ao=lavc with normal playback), and changing it would be a bit messy. So just leave them.
* encode: don't access ao->ptswm42014-03-073-0/+12
| | | | | | | | | | This field will be moved out of the ao struct. The encoding code was basically using an invalid way of accessing this field. Since the AO will be moved into its own thread too and will do its own buffering, the AO and the playback core might not even agree which sample a PTS timestamp belongs to. Add some extrapolation code to handle this case.
* common: add some helper macroswm42014-03-071-0/+3
|
* msg: add --msgtime option to add timestamps to each output messagewm42014-02-281-2/+9