summaryrefslogtreecommitdiffstats
path: root/stream
Commit message (Collapse)AuthorAgeFilesLines
* Silence some Coverity warningswm42014-11-211-0/+1
| | | | None of this really matters.
* Remove some unneeded NULL checkswm42014-11-211-3/+2
| | | | Found by Coverity; also see commit 85fb2af3.
* stream: fix endian swappingwm42014-11-211-2/+2
| | | | | | | | | | In addition to the messed-up expression, the endianness was also inverted. The code reads big endian by default. It "worked" by coincidence, but for little endian, codepoints outside of latin1 were broken. The broken expression was found by Coverity.
* stream: reduce ifdeffery for win32 somewhatwm42014-11-182-16/+8
| | | | Remove the ones which are not strictly needed.
* stream: signal a Windows event object on cancelJames Ross-Gowan2014-11-182-0/+35
| | | | | This will be used in the following commit to cancel subprocesses started by Lua.
* cache: don't relay STREAM_CTRL_AVSEEK if it's unsupportedwm42014-11-011-0/+4
| | | | | | | | Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK is implemented at all, and we can avoid a blocking wait on the cache if demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this can't currently happen, but why hope if we can explicitly prevent it. It'll make us more robust against future changes in libavformat.
* demux_lavf, stream_lavf: drop local buffers on time-seekswm42014-10-301-1/+3
| | | | | There was chance that some data was left in various local buffers after time-seeks. Probably doesn't actually matter.
* demux_lavf: mark as seekable if protocol supports seeking by timewm42014-10-303-0/+9
| | | | | | | | | | | | Basically, this will mark the demuxer as seekable with rtmp* and mmsh protocols. These protocols have network-level time seeking, and whether you can seek on the byte level does not matter. Until now, seeking was typically only enabled because of the cache, and a (nonsensical) warning was shown accordingly. It still could happen that the server doesn't actually support thse requests (or simply rejects them), so this is somewhat imperfect.
* Drop libquvi supportwm42014-10-253-334/+0
| | | | | | | | | | | No development activity (or even any sign of life) for almost a year. A replacement based on youtube-dl will probably be provided before the next mpv release. Ask on the IRC channel if you want to test. Simplify the Lua check too: libquvi linking against a different Lua version than mpv was a frequent issue, but with libquvi gone, no direct dependency uses Lua, and such a clash is rather unlikely.
* tv: remove some differences between immediate/normal modewm42014-10-251-38/+23
| | | | | | | | | | | The immediate mode (which is the default) uses a tiny ringbuffer and doesn't grab timestamps. This leads to quite bad behavior due to the fact that there's an additional buffer between playloop and TV code (the demuxer thread, which doesn't exist in MPlayer). Always grab the timestamps and use a decently-sized buffer. I still have no clue what I'm doing, and hacked it until it appeared to work. Report regressions if you experience any.
* tv: reduce waiting loop from 10ms to 1mswm42014-10-251-2/+2
| | | | | | | | | | | | I can't believe how shitty this (MPlayer-derived) code is. Maybe it should be fixed or be replaced with using libavdevice, but that doesn't seem worth the effort. Anyway, for now reduce the time it's blocking to wait for new frames from 10ms to 1ms, because 10ms might be a bit too tight: it could deliver the frame up to 10ms late - now it's only up to 1ms. (And yes, it does that instead of using condition variables. It also abuses volatile variables as atomics. It's hilarious.)
* stream: fix --stream-dump dropping the file headerwm42014-10-251-10/+12
| | | | | | | | | | | | | | | | | | stream_rar.c peeks the first few bytes when trying to open, which means that opening any stream reads at least 2KB of data (internal buffer size) on opening. This broke --stream-dump, which saved only the data following this initial buffer. Hack it around by writing the current buffer to the capture file too, and move stream_capture_write() above stream_set_capture_file() for this purpose. Cleaner solutions might include: handling the terrible rar thing differently, or using the "proper" stream API for dumping. (The latter is not done, because --stream-dump shares code with the --stream-capture misfeature.) Fixes #1215.
* stream: remove duplicate messagewm42014-10-251-1/+1
|
* tv: remove duplicated crapwm42014-10-251-124/+76
| | | | | The logging functions already add a prefix. Original MPlayer devs must have liked code duplication a lot.
* tv: unqueue buffers correctly (maybe, maybe not)wm42014-10-251-5/+7
| | | | | I clue no idea what I'm doing, but at least it doesn't hang anymore when closing a tv:// stream using a v4l2 loopback device.
* stream: stupid compilation workaround for win32wm42014-10-191-1/+1
| | | | | | | | On win32, open() is a function-like macro. The line of code changed with this commit accidentally expanded the macro. Prevent this macro expansion. Not sure why that happened now. Since as far as I remember system functions can be defined as macros, this affects in theory not only win32.
* Set thread name for debuggingwm42014-10-191-0/+1
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* lua: add an utility function for starting processeswm42014-10-192-7/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately, since Unix is also terrible, this turned out more complicated than I hoped. As a consequence and to avoid that this code has to be maintained forever, add a disclaimer that any function in Lua's utils module can disappear any time. The complexity seems a bit ridiculous, especially for a feature so far removed from actual video playback, so if it turns out that we don't really need this function, it will be dropped again. The motivation for this commit is the same as with 8e4fa5fc. Note that there is an "#ifndef __GLIBC__". The GNU people are very special people and thought it'd be convenient to actually declare "environ", even though the POSIX people, which are also very special people, state that no header declares this and that the user has to declare this manually. Since the GNU people overtook the Unix world with their very clever "embrace, extend, extinguish" strategy, but not 100%, and trying to build without _GNU_SOURCE is hopeless; but since there might be Unix environments which support _GNU_SOURCE features partially, this means that in practice "environ" will be randomly declared or not declared by system headers. Also, gcc was written by very clever people too, and prints a warning if an external variable is declared twice (I didn't check, but I suppose redeclaring is legal C, and not even the gcc people are clever enough to only warn against a definitely not legal C construct, although sometimes they do this), ...and since we at mpv hate compiler warnings, we seek to silence them all. Adding a configure test just for a warning seems too radical, so we special-case this against __GLIBC__, which is hopefully not defined on other libcs, especially not libcs which don't implement all aspects of _GNU_SOURCE, and redefine "environ" on systems even if the headers define it already (because they support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote software THAT portable that other libcs just gave up and implemented parts of _GNU_SOURCE, although probably not all), which means that compiling mpv will print a warning about "environ" being redefined, but at least this won't happen on my system, so all is fine. However, should someone complain about this warning, I will force whoever complained about this warning to read this ENTIRE commit message, and if possible, will also force them to eat a printed-out copy of the GNU Manifesto, and if that is not enough, maybe this person could even be forced to convince the very clever POSIX people of not doing crap like this: having the user to manually declare somewhat central symbols - but I doubt it's possible, because the POSIX people are too far gone and only care about maintaining compatibility with old versions of AIX and HP-UX. Oh, also, this code contains some subtle and obvious issues, but writing about this is not fun.
* stream: better error message for unmatched protocolwm42014-10-171-1/+3
| | | | See #1187.
* demux_lavf: set stream network options if applicablewm42014-10-142-29/+47
| | | | | | | | | | | Normally, we pass libavformat demuxers a wrapped mpv stream. But in some cases, such as HLS and RTSP, we let libavformat open the stream itself. In these cases, set typical network properties like useragent according to the mpv options. (We still don't set it for the cases where libavformat opens other streams on its own, e.g. when opening the companion .sub file for .idx files - not sure if we maybe should always set these options.)
* stream_lavf: expose concat://wm42014-10-141-0/+1
| | | | | | | Apparently there's an use for this; see #1178. I won't redocument obscure FFmpeg features, so add a hint to the manpage that some protocols are documented in FFmpeg instead.
* stream: change internal instead of external pos when dropping bufferswm42014-10-081-0/+1
| | | | | | | | | | | | | | | | | | | stream provides a read buffer (so even something like stream_read_char() is very fast). This means the stream reads ahead by a few KBs, and implies that the internal position (s->pos, which would match e.g. the file position in stream_file.c), and the external position (stream_tell()) can be different. stream_tell() shows how these are related. When dropping buffers, which happens on byte-level discontinuities with a bunch of streams (including DVB), we should not change the position as seen by the demuxer. On the other hand, the internal position is not really meaningful, since these streams aren't seekable anyway. So just change the code such that stream_drop_buffers() doesn't change the demuxer visible position. I'm hoping that this will fix a few problems with DVB. (Also see previous commit.)
* stream_dvb: use stream_drop_buffers()wm42014-10-081-2/+1
|
* stream: don't drop buffers on failed seekswm42014-09-291-6/+2
| | | | | | | | | | | Might matter when libavformat tries to do tiny seekbacks in an unseekable stream, and the seekback buffer isn't large enough. In this case, seeking would fail, and would drop the current buffer. The seekback would end up dropping future data. This change probably doesn't have any observable effects. libavformat normally has its own stream buffer, and demux_mkv.c tries carefully never to seek back.
* cache_file: refuse to cache unseekable streamswm42014-09-291-0/+5
| | | | | | | | | This makes no sense to use with DVD/BD/DVB and some others, and these streams happen to be unseekable. Also, other kinds of unseekable streams (like reading from pipe) should work, but will exhibit sketchy behavior if they need to seek. So just disable it, and leave these problems to the memory cache (cache.c).
* stream_bluray: autodetect AVCHD directorieswm42014-09-271-3/+4
| | | | Fixes #1127.
* stream: change malloc+memset to callocBruno George Moraes2014-09-273-8/+2
| | | | | | | Also removed some memset that were left on some calloc that was already in the code. Signed-off-by: wm4 <wm4@nowhere>
* stream_bluray: allow opening BDMV directories directlywm42014-09-262-0/+88
| | | | | | | | 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 directlywm42014-09-262-0/+54
| | | | | | | | 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 probingwm42014-09-255-21/+66
| | | | | | | | | | | | | | | 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.
* Remove mpbswap.hwm42014-09-251-2/+1
| | | | | | 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 s16lewm42014-09-251-8/+0
| | | | | | | | | | | | | 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.
* audio: drop swapped-endian audio formatswm42014-09-234-6/+6
| | | | | | | | | | | | | | | | | | | | 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.
* stream: fix build with emulated atomicswm42014-09-131-3/+3
| | | | | This code was legal with C11 atomics, but it fails with our compatibility wrapper.
* stream: redo playback abort handlingwm42014-09-137-26/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stream: change cache return valueswm42014-09-072-7/+7
| | | | | Basically a cosmetic change, because currently the player just continues even if the cache fails initializing.
* stream_lavf: assume icy title data is terminated with ';'wm42014-09-061-1/+1
| | | | Should fix #1071.
* player: don't allow remote playlists to load local fileswm42014-09-013-4/+11
| | | | | | | | 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.
* player: always load playlistswm42014-08-314-3/+37
| | | | | | | | | 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.
* cache_file: add a mode that creates a temporary filewm42014-08-301-1/+2
| | | | | | | Since we have to be portable, our options for creating temporary files are somewhat limited. tmpfile() happens to be available everywhere, so use that. This function doesn't allow having a "visible" filename or location, so we use the magic string "TMP" for this.
* stream: correctly propagate uncached stream typewm42014-08-301-1/+1
| | | | | This makes the ordered chapter code not think that a stream from the local filesystem is not a local file (it checks uncached_type).
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-294-5/+5
| | | | | | | | | 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.
* stream: tweaks to network reconnection codewm42014-08-293-3/+6
| | | | | | | | | | | | | | Don't reconnect to the cache (since the cached stream already handles reconnection). This is necessary, because since commit 0b428e44 the "streaming" field (which also controls whether attempting to reconnect makes sense at all) is inherited to the cache stream wrapper. Also, let the stream reset its own position on reconnect. This removes some assumptions and messy handling from the reconnect function. Make sure the cache is dropped on reconnect. This takes care of readjusting the stream position if necessary. (Also drop the cache on DVB channel switching commands.)
* tv: initialize frequencies to 0Ben Boeckel2014-08-281-2/+2
|
* player: redo how stream caching and pausing on low cache workswm42014-08-271-0/+1
| | | | | | | | | | | | | | | | | | | Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
* stream_dvb: restore --dvbin-file optionwm42014-08-062-7/+15
| | | | | | | Got lost some time ago. Although I'm not sure if it actually does anything on MPlayer (it exists there, but might broken, not sure). Fixes #988 (untested).
* stream_dvb: fix channels.conf preference orderwm42014-08-061-3/+4
| | | | | | | | channels.conf was never used (even though its config path was resolved). Also remove the non-sense with the access() call. Fixes #987 (untested).
* Improve setting AVOptionswm42014-08-021-5/+1
| | | | | | | | 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).
* stream: hack-fix rtmp-level seekingwm42014-07-303-7/+15
| | | | | | | | | | | | | This didn't work, because the timebase was wrong. According to the ffmpeg doxygen, if the stream index is -1 (which is what we used), the timebase is AV_TIME_BASE. But this didn't work, and it really expected the stream's timebase. Quite "surprising", since this feature (avio_seek_time) is used by rtmp only. Fixing this properly is too hard, so hack-fix our way around it. STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new STREAM_CTRL_AVSEEK is added. We simply pass-through the request verbatim.
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-301-0/+17
| | | | | 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.
* demux: add a demuxer threadwm42014-07-161-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* Revert "Remove DVD and Bluray support"wm42014-07-156-0/+2608
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
*