summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux: return EOF when reading from unselected streamwm42015-01-251-1/+1
| | | | | | | | | | | | | | | | | Normally the player doesn't read from unselected streams, so this should be a no-op. But unfortunately, some broken files can severely confuse the player, and assign the same demuxer stream to multiple front-end tracks. Then selecting one of the tracks would deselect the other track, with the end result that the demuxer stream for the selected track is deselected. This could happen with mkv files that use the same track number (which is of course broken). timeline_set_part() sets the tracks using demuxer_stream_by_demuxer_id(), using the broken non-unique IDs. The observable effect was that the player never quit, because demux_read_packet_async() told the caller to wait some longer for new packets. Fix by returning EOF instead. Fixes #1481.
* demux_mkv: avoid PTS warning with image attachmentswm42015-01-251-0/+5
| | | | | | | Removes an annoying "No video PTS! Making something up." warning. Mark it as keyframe, which is needed to prevent strange behavior with PNG. Also, don't leak the picture data.
* demux_mkv: use attachment filename as coverart titlewm42015-01-251-0/+1
|
* demux_mf: add probing by mime typewm42015-01-251-1/+5
| | | | Reuses the mime type table introduced in the previous commit.
* demux_mkv: support embedded coverartwm42015-01-253-1/+34
| | | | | | | | | | | The code could as well be in demux.c, but it's better to avoid accidental clashes with demux_lavf.c. FFmpeg provides no way yet to map a mime type to a codec, so do it manually. (It _can_ map a mime type to an "input format", but not a codec.) Fixes #1374.
* demux_mkv: enable codec parsing for vfw-muxed files toowm42015-01-251-9/+10
| | | | | | | | | | | | | | | For some codecs, we need to invoke a codec parser (because libavcodec will run into trouble otherwise). This was done based on the Matroska codec field. But this ignores handling of vfw-muxed files, which use a pseudo-codec to signal presence of vfw structures, which we must unmangle to get the real codec. Handle this by rearranging the code. This fixes at least mp3-in-mkv for vfw-muxed files; typically old files. Conflicts: demux/demux_mkv.c
* demux_playlist: detect headerless m3u files by extensionwm42015-01-251-1/+24
| | | | | | | | | | | | | | | m3u files are normally just text files with a list of filenames. Nothing actually mandates that there is a header. Until now, we've rejected such files, because there's absolutely no way to detect them. If nothing else claims the file, the extension is ".m3u", and if the contents of the file look like text, then load it as m3u playlist. The text heuristic is pretty cheap, but at least it should prevent trying to load binary data as playlist. (Which would "work", but result in a catastrophic user experience.) Due to the text heuristic, UTF-16/32 files will be rejected (unless they have a header), but I don't care.
* demux_mkv: fix EBML parsing checkswm42015-01-251-16/+15
| | | | | | | | Reading IDs must be checked too. This was basically forgotten in commit f3a978cd. Also set the *length parameter for ebml_parse_length() in some error cases, which _really_ should happen. Fixes #1461.
* demux_mkv: better check for some EBML parsingwm42015-01-251-12/+18
| | | | | | | | | | Apparently, originally this code was meant to be able to read past the buffer somewhat, which is why the buffer allocation was padded by 8 byte. This is unclean and confuses valgrind. This probably could have crashed with certain invalid files too. Also revert the change added with 10a2f69; it should be not needed anymore.
* demux_mkv: avoid endless loop with broken fileswm42015-01-251-1/+1
| | | | Fixes #1457.
* demux_mkv: improve robustness against broken libavcodec parserswm42015-01-251-2/+2
| | | | | | | | | The VP9 codec parser has a bug: it doesn't set the data/size pointers passed to it. As I understand, it must always do this, and in fact, if it doesn't some libavcodec generic code would be in trouble too. This helps with #1448, but is not the full fix for it. The codec parser must be fixed in libavcodec itself.
* demux_playlist: unquote entries in pls playlistswm42015-01-251-0/+3
| | | | I guess these parsers still have a way to go...
* Check some mallocswm42014-12-171-0/+4
| | | | Fixes #1337.
* demux_mkv: reject 0 TimecodeScalewm42014-12-081-0/+4
| | | | | | | Also reject anything over INT_MAX; no particular reason for this upper bound. Fixes #1317.
* demux_playlist: don't ignore last line in m3uwm42014-12-011-2/+2
| | | | | | | | If EOF is reached after reading a line, the EOF flag is set. This was a problem for the m3u code, which checked for EOF _after_ reading a line, which will discard the last line read. Also fix a typo in an unrelated part of the file.
* demux_mkv: fix a possible out of bounds accesswm42014-11-281-6/+8
| | | | | | | | | | | | | The if branch has a weak check to test whether the codec_id is the short ID, and handles the long IDs in the else branch. The long IDs are all longer than 12 bytes long, so hardcoding the string offset to get the trailing part of the name makes sense. But the if condition checks for another thing, which could get the else branch run even if the codec_id is short. Fix the bogus control flow and check if the codec_id is long enough. One of these checks could be considered redundant, but include them both for defensive coding.
* demux_lavf: set PTS of first packet for formats with no timestampswm42014-11-251-0/+9
| | | | Makes time display work for some raw audio formats (*.shn).
* demux_mkv: fix scary sign extension issueswm42014-11-211-8/+8
| | | | | | | Expressions involving uint16_t are promoted to int, which then can overflow if the uint16_t values are large enough. Found by Coverity.
* demux_mkv: fix possible real-audio out of bounds accesseswm42014-11-211-1/+7
| | | | | | | Could index static arrays from arbitrary input data without checking for bounds. Found by Coverity.
* demux_mkv: fix uninitialized variablewm42014-11-211-1/+1
| | | | Found by Coverity.
* demux_mkv: haali hack: add last frame duration to video length toowm42014-11-201-2/+3
| | | | | From what I can see, only the blockduration of the packet needs to be added, never the "default duration".
* demux_mkv: add an option for compatibility with Haaliwm42014-11-181-0/+65
| | | | This was requested on IRC.
* demux_mkv: check file type without actually reading datawm42014-11-161-0/+7
| | | | | | | | Do a minimal check on data read with stream_peek(). This could help with probing from unseekable streams in some situations. (We could check the entire EBML and Matroska headers, but probably not worth the trouble. We could also seek back to the start, which demux.c doesn't do, but which would work usually - also not worth the trouble.)
* demux_cue: use stream_peek()wm42014-11-161-6/+2
| | | | | | This could cause probing failures with unseekable streams. (Although I'm not perfectly sure why; seeking back should work in this particular case.)
* demux_mkv: adjust subtitle preroll again (2)wm42014-11-151-3/+12
| | | | | | | | | | | | | | Make the changes started in commit c827ae5f more eloborate, and provide an option to control the amount of data read before the seek-target. To achieve this, rewrite the loop that finds the lowest still acceptable target cluster. It is now searched by time instead of file position. The behavior (both with and without preroll option) may be different from before this change, although it shouldn't be worse. The change demux_mkv_read_cues() fixes a bug: when seeking after playing normally, the code would erroneously assume that durations are set. This doesn't happen if the first operation after loading was a seek instead of playback.
* demux: update cache state when pausedwm42014-11-121-1/+11
| | | | | | | | | | | | | This was removed in commit 480f82fa. This caused the cache display not to update while paused, because the update_cache() function is never called in the thread (now I remember why the extra call was "needed"). The old implementation intentionally run update_cache() only before waiting on a mutex, with no further checks for the condition variable. In theory, this is strictly not sane, but since it was just for the retrieval of the very fuzzy cache status, it was ok. Now we want to call update_cache() outside of the mutex though - which means that in order to avoid missed wakeups, a proper condition has to be used.
* demux_mkv: adjust subtitle preroll againwm42014-11-111-14/+17
| | | | | | | | | | | | | | | Revert commit 24e52f66; even though the old beheavior doesn't make sense (as the commit message assured), it turns out that this works better: typically, it means preroll will start from the previous video key frame (the video CUE index will contain clusters with video key frames only), which often coincides with subtitle changes. Thus the old behavior is actually better. Change the code that uses CueDuration elements. Instead of merely checking whether preroll should be done, find the first cluster that needs to be read to get all subtitle packets. (The intention is to compensate for the enlarged preroll cluster-range due to reverting commit 24e52f66.)
* demux_mkv: fix undefined shiftswm42014-11-081-4/+4
| | | | | | | Found by clang sanitizer. Casting unsigned integers to signed integers with same size has implementation defined behavior (it's even allowed to crash), but it seems reasonable to expect that reasonable implementations do a complement of 2 "conversion".
* demux_mkv: fix indentationwm42014-11-051-3/+3
| | | | Meh.
* demux_mkv: for subtitle preroll, consider all clusterswm42014-11-051-5/+3
| | | | | | | | | This considered only index entries that were for the same track ID as the track used for seeking. This doesn't make much sense for preroll; it'll just possibly skip clusters, and select an earlier cluster. One possible negative side-effect is that the preroll might be too tight now, and miss subtitle packets more often.
* demux_mkv: apply subtitle preroll only if needed, based on cue indexwm42014-11-051-0/+16
| | | | | | | | | The demuxer has a hack to seek to the cluster before the target cluster in order to "catch" subtitle lines that start before the seek target, but overlap with the video after the seek target. Avoid this hack if the cue index indicates that there are no overlapping subtitle packets that can be caught by seeking to the previous cluster.
* demux_mkv: read CueRelativePosition/CueDuration elementswm42014-11-051-11/+27
| | | | | | | | Nothing is done with them yet. This is preparation for the following commit. CueRelativePosition isn't even saved anywhere, because I don't intend to use it. (Too messy for no gain.)
* demux_mkv: index all packetswm42014-11-051-4/+2
| | | | | | | | | | | | Instead of indexing only 1 packet per cluster (which is enough for working seeking), add every packet to the index. Since on seek, we go through every single index entry, this probably makes seeking slower. On the other hand, this code is used for files without index only (e.g. incomplete files), so it probably doesn't matter much. Preparation for the following commits.
* demux: report 0s readahead time as fallback in some situationswm42014-11-051-1/+5
| | | | | | | | | | If no packets are queued, the readahead time is obviously 0. If the end time is smaller than the start time, the problem is probably that audio and video start at slightly different times - report 0 in this case too. Do this because seeing "???" as readahead time is a bit annoying.
* demux: unbreak build with Libavwm42014-11-031-0/+4
| | | | ....
* demux: don't account known range for streams that are EOFwm42014-11-031-2/+4
| | | | | | | | | This influences the demuxer readahead display. If a stream has reached EOF, we want to ignore it for the purpose of this calculation. Note that if a stream contains no packets, it still should cause the value 0s to be displayed (unless it's EOF), because that's just the actual situation.
* demux: fix PTS comparisonwm42014-11-031-2/+4
| | | | | | | | This was relying on the fact that timestamps will always be numerically larger than MP_NOPTS_VALUE, but the trick didn't actually work for MP_PTS_MIN. Be a bit more sincere, and don't rely on this anymore. This fixes the comparison, and avoids the readahead amount displaying as "???" in some situations (since one of the values was NOPTS).
* demux: don't consider stream EOF an underrunwm42014-11-031-1/+1
| | | | | | | | | | | | In this case, we didn't find any new packets for this stream, even though we've read ahead as much as possible. (If reading ahead in this case, the "Too many packets in the demuxer packet queues" error is normally printed.) If we do consider this an underrun, handle_pause_on_low_cache() will pause and show the "buffering" state, which is not useful. Could also happen on very bad interleaving.
* demux_mkv: remove minor code duplicationwm42014-11-031-12/+6
|
* demux_mkv: implement audio skipping/trimmingwm42014-11-033-2/+41
| | | | | | | | | | | | | This mechanism was introduced for Opus, and allows correct skipping of "preroll" data, as well as discarding trailing audio if the file's length isn't a multiple of the audio frame size. Not sure how to handle seeking. I don't understand the purpose of the SeekPreRoll element. This was tested with correctness_trimming_nobeeps.opus, remuxed to mka with mkvmerge v7.2.0. It seems to be correct, although the reported file duration is incorrect (maybe a mkvmerge issue).
* player: always use demux_chapterwm42014-11-025-15/+23
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* demux_lavf, stream_lavf: drop local buffers on time-seekswm42014-10-301-2/+5
| | | | | 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-301-0/+2
| | | | | | | | | | | | 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.
* demux_playlist: redirect ASF streaming to mmsh://wm42014-10-301-14/+30
| | | | | | | | | | | | I'm not sure if this could be done in libavformat instead. Probably not, because libavformat doesn't seem to have any mechanism for trying one protocol and reverting (or redirecting) to another one if needed. This commit is sort of a hack too, because it redirects the URL by pretending the http:// link is a playlist containing the mmsh:// link. The list of mime types is borrowed from MPlayer (which has completely different code to handle this).
* demux: fix demux_seek signaturewm42014-10-292-2/+2
| | | | Probably doesn't matter much.
* demux: move some seek flag sanitation to generic codewm42014-10-292-10/+15
| | | | No reason why only demux_mkv.c should do this.
* demux_mkv: implement percentage seeking with no indexwm42014-10-291-22/+24
| | | | It was implemented only for the case the index exists (pretty useless).
* demux_mkv: export packet file positionwm42014-10-291-0/+1
| | | | | This gives us approximate fallback playback percentage position if the duration is unknown.
* demux: seek to position 0 when loading, instead of restoring itwm42014-10-281-7/+7
| | | | | | | | | | This was originally done for DVD/BD/DVB, where the start position could be something different from 0, and seeking back to 0 would mess it up completely. Since we're not quite sure that these streams are unseekable, we can simplify this somewhat, and also make sure we also start at 0 for normal files. Helps a little bit with the following edition reloading commit.
* demux: don't access stream while lock is heldwm42014-10-241-22/+30
| | | | | | | | | | Although this is fine when the stream cache is active (which caches these and returns the result immediately), it seems cleaner not to rely on this detail. Remove the update_cache() call from demux_thread(), because it's sort of in the way. I forgot why it exists, and there's probably no good reason for it to exist anyway.
* demux: cache STREAM_CTRL_GET_BASE_FILENAMEwm42014-10-241-0/+18
| | | | | | | | It's needed for some obscure feature in combination with .rar reading. However, it's unconditionally used by the subtitle loader code, so take care of not blocking the main thread unnecessarily. (Untested.)
* player: add stream selection by ffmpeg indexwm42014-10-213-0/+4
| | | | | | | | | Apparently using the stream index is the best way to refer to the same streams across multiple FFmpeg-using programs, even if the stream index itself is rarely meaningful in any way. For Matroska, there are some possible problems, depending how FFmpeg actually adds streams. Normally they seem to match though.
* Set thread name for debuggingwm42014-10-191-0/+2
| | | | | | | | | | 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.
* demux: print a warning if stream is not seekablewm42014-10-171-2/+3
|
* demux_lavf: set stream network options if applicablewm42014-10-141-2/+3
| | | | | | | | | | | 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.)
* demux_lavf: let libavformat open HLS streams directlywm42014-10-141-1/+2
| | | | | | | | Fixes opening some streams. This means the HLS playlist will be opened twice, but that's not much of a problem, considering it's pretty small, and HLS will make many other http accesses anyway.
* demux_mkv: fix undefined behaviorwm42014-10-131-1/+1
| | | | | | | With some files, the extradata variable can remain uninitialized, but will be used for memory access. CC: @mpv-player/stable (with high priority)
* demux: fix a commentwm42014-10-121-2/+1
| | | | Don't refer to fields that were removed.
* Add some missing "const"swm42014-10-101-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).
* demux_lavf: blacklist jpeg fileswm42014-10-061-0/+1
| | | | | | | We handle them under demux_mf.c for stupid reasons; mostly so that an image is shown for a second instead of just flashing it. CC: @mpv-player/stable
* demux_disc: bluray: fix stream language (2)wm42014-09-301-0/+1
| | | | | | | | | Commit 50e131b43ed happened to make it work for DVD (because the higher bits of the ID are masked in the DVD case), but failed for Bluray. This probably fixes it, although I don't have a sample to multiple streams to confirm it really does it right. CC: @mpv-player/stable
* demux_disc: export BD/DVD audio languagewm42014-09-291-0/+1