summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* sub: add demux_libass wrapper, drop old hackswm42013-06-2514-177/+131
| | | | | | | | | | | | demux_libass.c allows us to make subtitle format detection part of the normal file loading process. libass has no probe function, but trying to load the start of a file (the first 4 KB) is good enough. Hope that libass can even handle random binary input gracefully without printing stupid log messages, and that the libass parser doesn't accept too many non-ASS files as input. This doesn't handle the -subcp option correctly yet. This will be fixed later.
* core: don't set correct-pts mode randomlywm42013-06-252-5/+8
| | | | | | The default correct-pts mode depended on which demuxer was opened last. Often this is the subtitle demuxer. The correct-pts mode should be decided on the demuxer for video instead.
* subreader: turn into actual demuxerwm42013-06-258-202/+229
| | | | | | | | | | | | | | | | subreader.c (before this commit renamed to demux_subreader.c) was special cased to the -sub option. The plan is using the normal demuxer codepath for all subtitle formats (so we can prefer libavformat demuxers for most formats). There are some subtle changes. The probe size is restricted to 32 KB (instead of unlimitted + giving up after 100 lines of input). For formats like MicroDVD, the video FPS isn't used anymore, because it's not available on the subtitle demuxer level. Instead, hardcode it to 23.976 FPS (libavformat seems to do the same). The user can probably still use -sub-fps to fix the timing. Checking the file extension for ".utf"/".utf8"/".utf-8" is simply removed (seems worthless, was in the way, and I've never seen this anywhere).
* demux: add utility functions for preloading demuxerswm42013-06-252-5/+81
| | | | | These will be needed by subtitle demuxers, which read all data on initialization.
* stream: remove stream_unread_buffer()wm42013-06-252-21/+0
| | | | Replaced with stream_peek().
* demux_lavf: use stream_peek() instead of read/unreadwm42013-06-251-6/+4
| | | | | | | Simpler, reduces the amount of copying. We still have to malloc+memcpy the probe buffer though, because padding with FF_INPUT_BUFFER_PADDING_SIZE is required by libavformat.
* stream: add stream_peek functionwm42013-06-252-0/+35
| | | | | Makes probing easier, and this is perhaps a simpler interface than stream_unread_buffer().
* stream: never let read functions return values < 0wm42013-06-251-3/+5
| | | | | | | | | | stream_read_unbuffered() can sometimes return negative values on error. Change that to return 0 - the negative values are nowhere used anyway. If distinguishing errors and EOF is really needed, a flag could be added instead. This also fixes the stream_read_partial() call in cache.c, which assumes the return values is always >= 0.
* stream: readd memory streamswm42013-06-252-5/+21
|
* Move/rename subreader.cwm42013-06-258-6/+3
|
* sd_ass: fix nonsensewm42013-06-251-1/+4
| | | | | | Actually check the newly added text for whitespace, and not the uninitialized buffer after it. Also, if an even is only whitespace, don't add it at all.
* sd_ass: disable special handling of subtitles with duration 0wm42013-06-252-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sd_ass contains some code that treats subtitle events with duration 0 specially, and adjust their duration so that they will disappear with the next event. This is most likely not needed anymore. Some subtitle formats allow omitting the duration so that the event is visible until the next one, but both subreader.c as well as libavformat subtitle demuxers already handle this. Subtitles embedded in mp4 files (movtext) used to trigger this code. But these files appear to export subtitle duration correctly (at least libavcodec's movtext decoder is using this assumption). Since commit 6dbedd2 changed demux_lavf to actually copy the packet duration field, the code removed with this commit isn't needed anymore for correct display of movtext subtitles. (The change in sd_movtext is for dropping empty subtitle events, which would now be "displayed" - libavcodec does the same.) On the other hand, this code incorrectly displayed hidden events in .srt subtitles. See for example the first event in SubRip_capability_tester.srt (part of FFmpeg's FATE). These intentionally have a duration of 0, and should not be displayed. (As of with this commit, they are still displayed in external .srt subs because of subreader.c hacks.) However, we can't be 100% sure that this code is really unneeded, so just comment the code. Hopefully it can be removed if there are no regressions after some weeks or months.
* sd_ass: handle libavformat ASS comment packets as wellwm42013-06-232-18/+14
| | | | | | | | | | | | Currently, we are filtering libavformat style ASS packets by checking whether they are prefixed "Dialogue: ". Unfortunately, comment packets are demuxed too. These start with "Comment: ", so they are not caught. Change the filtering, and use the codec ID instead. libavformat uses "ssa" as codec ID for ASS subtitles, while mpv uses "ass". Also, at least FFmpeg will change the ASS packet format to the same format mpv and Matroska use, and identify these with "ass" as codec ID, so this is works out nicely.
* subreader: remove overlap handling codewm42013-06-231-243/+3
| | | | | | | | | | | Some of this (fixing timing) is now done in dec_sub.c (although it's not active for subreader.c code yet - this will be fixed when subreader.c subs are read through a demuxer wrapper). Another reason to remove this is that this code doesn't do much good anymore. libass does handle overlap, and trying to fold overlapping lines into single subtitle events will prevent libass from handling this properly.
* sub: do some timing postprocessing on preloaded subswm42013-06-233-13/+53
| | | | | | | | | | | | | This fixes the -subfps option (which unfortunately is still useful), and fixes minor annoying timing errors (which unfortunately still happen). Note that none of these affect ASS or image subtitles. ASS is specially handled: libass loads subtitles as ASS_Track. There are no actual packets passed around, and sd_ass just uses the ASS_Track. Disable the --sub-no-text-pp option. It's misleading now and always was completely useless.
* sub: preload external text subtitleswm42013-06-235-2/+109
| | | | | | | | If a subtitle is external, read it completely and add all subtitle events in advance when the subtitle track is selected. This is done for text subtitles only. (Note that subreader.c and subtitles loaded with libass are different and don't have anything to do with this commit.)
* sub: remove redundant conditionwm42013-06-231-2/+2
|
* stream: remove padding parameter from stream_read_complete()wm42013-06-239-25/+24
| | | | | | | | Seems like a completely unnecessary complication. Instead, always add a 1 byte padding (could be extended if a caller needs it), and clear it. Also add some documentation. There was some, but it was outdated and incomplete.
* demux: don't require fill_buffer callbackwm42013-06-233-13/+1
|
* cache: fix build on OSX (again)wm42013-06-161-0/+7
| | | | | | | | | | | | | OSX doesn't support the POSIX API we were using. We check for _POSIX_TIMERS. 0 or -1 means unsupported. See: http://pubs.opengroup.org/onlinepubs/009696699/functions/clock_getres.html http://pubs.opengroup.org/onlinepubs/009696699/basedefs/unistd.h.html The workaround of using gettimeofday() is suggested by Apple: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/pthread_cond_timedwait.3.html Thanks to AStorm for providing help here.
* cache: fix compilation on Libavwm42013-06-161-1/+8
| | | | Appears Libav doesn't have av_clip64(). So implement our own.
* cache: use correct header for clock_gettimewm42013-06-161-0/+1
| | | | Fixes compilation on OSX.
* ao_dsound: fix compilationwm42013-06-161-0/+2
|
* configure: make check for stream cache verbosewm42013-06-162-2/+5
| | | | | Also add a minor comment about the stream cache needing pthreads now to DOCS/crosscompile-mingw.txt.
* Merge branch 'cache_new'wm42013-06-1627-1049/+907
|\
| * stream: don't set sector size on cachewm42013-06-161-3/+1
| | | | | | | | | | | | | | | | | | This is useless on the cache side. The sector is needed only to deal with stream implementations which are not byte addressable, and the cache is always byte addressable. Also set a default read_chunk value. (This value is never used unless you chain multiple caches, but it's cleaner.)
| * cache: attempt to improve slow cache warningwm42013-06-161-26/+35
| | | | | | | | | | Still sucks. The old cache behavior (before removing the fork code) wasn't great either, though.
| * cache: report more precise stream timewm42013-06-161-9/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DVD and bluray packet streams carry (essentially) random timestamps, which don't start at 0, can wrap, etc. libdvdread and libbluray provide a linear timestamp additionally. This timestamp can be retrieved with STREAM_CTRL_GET_CURRENT_TIME. The problem is that this timestamp is bound to the current raw file position, and the stream cache can be ahead of playback by an arbitrary amount. This is a big problem for the user, because the displayed playback time and actual time don't match (depending on cache size), and relative seeking is broken completely. Attempt to fix this by saving the linear timestamp all N bytes (where N = BYTE_META_CHUNK_SIZE = 16 KB). This is a rather crappy hack, but also very effective. A proper solution would probably try to offset the playback time with the packet PTS, but that would require at least knowing how the PTS can wrap (e.g. how many bits is the PTS comprised of, and what are the maximum and reset values). Another solution would be putting the cache between libdvdread and the filesystem/DVD device, but that can't be done currently. (Also isn't that the operating system's responsibility?)
| * stream: don't align stream position if not neededwm42013-06-161-3/+1
| | | | | | | | | | This is pointless, and just increases latency on seeking. For streams that have a sector size set, this is still needed, though.
| * stream: don't adjust stream position if seek succeeds, but read failswm42013-06-161-3/+2
| | | | | | | | | | | | | | This was probably done this way to ensure that after a successful seek, the reported stream position is the same as the requested seek position. But it doesn't make too much sense, since both stream->pos and the stream implementation's internal position will go out of sync.
| * stream: fix some aspects of EOF handlingwm42013-06-162-13/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | The stream EOF flag should only be set when trying to read past the end of the file (relatively similar to unix files). Always clear the EOF flag on seeking. Trying to set it "properly" (depending whether data is available at seek destination or not) might be an ok idea, but would require attention to too many special cases. I suspect before this commit (and in MPlayer etc. too), the EOF flag wasn't handled consistently when the stream position was at the end of the file. Fix one special case in ebml.c and stream_skip(): this function couldn't distinguish between at-EOF and past-EOF either.
| * stream: don't set EOF flag in stream implementationswm42013-06-167-13/+1
| | | | | | | | | | | | | | | | | | | | EOF should be set when reading more data fails. The stream implementations have nothing to say here and should behave correctly when trying to read when EOF was actually read. Even when seeking, a correct EOF flag should be guaranteed. stream_seek() (or actually stream_seek_long()) calls stream_fill_buffer() at least once, which also updates the EOF flag.
| * stream: remove stream_reset()wm42013-06-168-25/+3
| | | | | | | | | | | | | | | | | | This function was called in various places. Most time, it was used before a seek. In other cases, the purpose was apparently resetting the EOF flag. As far as I can see, this makes no sense anymore. At least the stream_reset() calls paired with stream_seek() are completely pointless. A seek will either seek inside the buffer (and reset the EOF flag), or do an actual seek and reset all state.
| * stream: check for interruption when trying to reconnect streamwm42013-06-161-3/+3
| | | | | | | | | | | | | | This happens with something like "mpv https://www.youtube.com/watch". The URL is obviously not valid, but the stream layer tries to reconnect. This commit at least allows to use the terminal to abort gracefully. (Other than killing the process.)
| * stream: cosmeticswm42013-06-162-26/+12
| |
| * stream: reset buffer even on EOF/errorwm42013-06-161-4/+2
| | | | | | | | This probably didn't matter anywhere, but it's more proper.
| * cache: use threads instead of fork()wm42013-06-166-553/+425
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically rewrite all the code supporting the cache (i.e. anything other than the ringbuffer logic). The underlying design is untouched. Note that the old cache2.c (on which this code is based) already had a threading implementation. This was mostly unused on Linux, and had some problems, such as using shared volatile variables for communication and uninterruptible timeouts, instead of using locks for synchronization. This commit does use proper locking, while still retaining the way the old cache worked. It's basically a big refactor. Simplify the code too. Since we don't need to copy stream ctrl args anymore (we're always guaranteed a shared address space now), lots of annoying code just goes away. Likewise, we don't need to care about sector sizes. The cache uses the high-level stream API to read from other streams, and sector sizes are handled transparently.
| * stream: add partial read functionwm42013-06-162-17/+28
| | | | | | | | | | This is a nice way to avoid an additional copy of the data when reading with stream_read().
| * demux_lavf: change probing, use stream_unread_buffer()wm42013-06-161-31/+33
| | | | | | | | | | This fixes a longstanding issue with demux_lavf probing. See previous commit.
| * stream: add stream_unread_buffer()wm42013-06-162-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | demux_lavf probes up to 2 MB of data in the worst case. When the ffmpeg demuxer is actually opened, the stream is seeked back to 0, and the previously read data is thrown away. This wasn't a problem for playback of local files, but it's less than ideal for playing from slow media (like web streams), and breaks completely if the media is not seekable (pipes, some web streams). This new function is intended to allow fixing this. demux_lavf will use it to put the read probe data back into the buffer. The simplest way of implementing this function is by making it transparently extend the normal stream buffer. This makes sure no existing code is broken by new weird special cases. For simplicity and to avoid possible performance loss due to extra dereferencing when accessing the buffer, we just extend the static buffer from 8 KB to 2 MB. Normally, most of these 2 MB will stay uncommitted, so there's no associated waste of memory. If demux_lavf really reads all 2 MB, the memory will be committed and stay unused, though.
| * cache: make the stream cache a proper stream that wraps other streamswm42013-06-168-352/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, the cache was franken-hacked on top of the stream API. You had to use special functions (like cache_stream_fill_buffer() instead of stream_fill_buffer()), which would access the stream in a cached manner. The whole idea about the previous design was that the cache runs in a thread or in a forked process, while the cache awa functions made sure the stream instance looked consistent to the user. If you used the normal functions instead of the special ones while the cache was running, you were out of luck. Make it a bit more reasonable by turning the cache into a stream on its own. This makes it behave exactly like a normal stream. The stream callbacks call into the original (uncached) stream to do work. No special cache functions or redirections are needed. The only different thing about cache streams is that they are created by special functions, instead of being part of the auto_open_streams[] array. To make things simpler, remove the threading implementation, which was messed into the code. The threading code could perhaps be kept, but I don't really want to have to worry about this special case. A proper threaded implementation will be added later. Remove the cache enabling code from stream_radio.c. Since enabling the cache involves replacing the old stream with a new one, the code as-is can't be kept. It would be easily possible to enable the cache by requesting a cache size (which is also much simpler). But nobody uses stream_radio.c and I can't even test this thing, and the cache is probably not really important for it either.
| * stream: remove pointless checkwm42013-06-091-7/+3
| |
| * stream: remove unused functionwm42013-06-091-9/+0
| |
| * stream: move VCD specific stuff to stream_vcdwm42013-06-093-5/+4
| | | | | | | | I don't even know what VCDs are. A prehistoric version of the DVD or so.
| * stream_cdda, stream_vcd: check read buffer sizewm42013-06-092-0/+5
| | | | | | | | | | | | | | | | These assumed that the buffer provided with fill_buffer() was at least sector sized, instead of checking the size parameter. This is just a cleanup, since every caller made sure to align everything on sector sizes, if a stream has the sector size set.
| * stream_dvd: remove some deadly insane codewm42013-06-091-15/+0
| | | | | | | | | | | | Of course all of stream_dvd.c (as well as libdvdread) is completely insane, but at least this hack for ancient broken compilers on really obscure platforms should be safe to remove.
| * stream: misleading statementwm42013-06-091-1/+1
| |
| * core: use STREAM_CTRL instead of accessing stream_dvd internalswm42013-06-094-11/+33
| | | | | | | | | | | | | | | | | | | | | | | | Some code in mplayer.c did stuff like accessing (dvd_priv_t *)st->priv. Do this indirectly by introducing STREAM_CTRL_GET_DVD_INFO. This is extremely specific to DVD, so it's not worth abstracting this further. This is a preparation for turning the cache into an actual stream, which simply wraps the cached stream. There are other streams which are accessed in the way DVD was, at least TV/radio/DVB. We assume these can't be used with the cache. The code doesn't look thread-safe or fork aware.
| * stream: rename cache2.c to cache.cwm42013-06-092-1/+1
| | | | | | | | | | | | | | I never found cache1.c (whatever it was named, if it ever existed). cache2.h will be deleted later, so don't go through the trouble of renaming it.
| * cache2: uncrustifywm42013-06-091-452/+521
| |
* | audio/out: remove ao->outburst/buffersize fieldswm42013-06-1616-82/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core didn't use these fields, and use of them was inconsistent accross AOs. Some didn't use them at all. S