summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: remove the realmedia fieldwm42015-02-051-25/+21
| | | | | | Granted, this doesn't help much with anything, other than the hate- driven desire to remove or at least reduce anything that has to do with RealMedia.
* demux_mkv: reindent, cosmeticswm42015-02-051-97/+79
| | | | | | | | | | Reindent the whole handle_realaudio() function, and make the surrouding if block return early instead. Also contains some cosmetics to the sipr swapping, which hopefully does not change the semantics, but is untested (the kind of cosmetic changes everyone loves so much). May the person responsible for sipr rot in hell. (It was probably done to obfuscate the codec?)
* demux_mkv: simplify realaudio handlingwm42015-02-051-30/+17
| | | | | | | Staring at the code, it doesn't look like the extra code for "normal" audio is needed. Most of it looks like artifacts from the previous code structure (much of it was added in the initial commit). I couldn't find a sample that uses this code path to fully confirm this, though.
* demux_mkv: remove realvideo-specific aspect ratio handlingwm42015-02-051-17/+5
| | | | | | | | I suppose it could lead to subtle changes in behavior in presence of realvideo files that change aspect radio. With the only sample I had available, the behavior actually improved (azumi.mkv from the MPlayer samples FTP; when starting playback in the middle it used the wrong aspect ratio).
* demux_mkv: use libavcodec parser for realvideowm42015-02-051-68/+4
| | | | | | Appears to work, so we can drop some code. For some really odd reason, the descrambling done on the timestamp requires millisecond units (due to the "algorithm", not the libavcodec API).
* demux_mkv: retrieve timestamps from libavcodec parserwm42015-02-051-3/+16
| | | | | | | | | Fixes vp9 missing timestamps. This requires a brand new libavcodec (the patch for this was just applied to FFmpeg git master). The timestamp mangling is applied to VP9 only. It'd probably work with other codecs, but it's not needed. It could break in various ways, so it has to be explicitly checked for every enabled codec.
* demux_mkv: refactor packet parsingwm42015-02-053-86/+115
| | | | | | | | Makes it somewhat more uniform, and breaks up the awfully deep nesting. This implicitly changes multiple small details, rather than only moving code around. In particular, this computes the packet fields first and parses them afterwards, which is needed for the next commit.
* demux_raw: output smaller audio packetswm42015-02-041-1/+1
| | | | | | | | | | | Currently, audio packets are always filtered as a whole. Since demux_raw output a 1 second long packet, this could lead to large delays when applying softvol volume. It could be fixed by splitting the frames the decoder outputs before filtering them (like the old filter code used to), but since this didn't cause any other problems yet, I'm going with the simpler fix. Fixes #1558.
* demux_disc: fix CDDA seekabilitywm42015-02-031-6/+13
| | | | | | | | The only reason why cdda:// goes through this wrapper-demuxer is so that we add chapters to it. Most things related to seeking apply only to DVD/BD, and in fact broke CDDA sekkability. Fixes #1555.
* demux_mkv: use unique IDs for cover art pseudo-trackswm42015-02-011-0/+1
| | | | | | | Might fix behavior with mkv files that use ordered chapters and have cover art tags. In my opinion, this should actually have worked (because cover art pseudo-tracks are strictly appended), but I don't have a sample file to test at hand.
* player: demote matroska ordered chapter scanning messages to VerboseDiogo Franco (Kovensky)2015-01-281-1/+1
| | | | | Causes a lot of terminal spam on large folders and is not actually useful except maybe for debugging.
* command: export more details about file seekabilitywm42015-01-262-1/+4
| | | | | | | | | | If a file is unseekable (consider e.g. a http server without resume functionality), but the stream cache is active, the player will enable seeking anyway. Until know, client API user couldn't know that this happens, and it has implications on how well seeking will work. So add a property which exports whether this situation applies. Fixes #1522.
* command: export file format as propertywm42015-01-232-5/+3
| | | | | | | | | | | | Repurpose demuxer->filetype for this. It used to be used to print a human readable format description; change it to a symbolic format name and export it as property. Unfortunately, libavformat has its own weird conventions, which are reflected through the new property, e.g. the .mp4 case mentioned in the manpage. Fixes #1504.
* demux_disc: pass seek flags to stream layerwm42015-01-193-6/+15
| | | | | | | | | | | | | | | | Pass through the seek flags to the stream layer. The STREAM_CTRL semantics become a bit awkward, but that's still the least awkward part about optical disc media. Make demux_disc.c request relative seeks. Now the player will use relative seeks if the user sends relative seek commands, and the demuxer announces it wants these by setting rel_seeks to true. This change probably changes seek behavior for dvd, dvdnav, bluray, cdda, and possibly makes seeking useless if the demuxer-cache is set to a high value. Will be used in the next commit. (Split to make reverting the next commit easier.)
* demux: return EOF when reading from unselected streamwm42015-01-161-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: fix EBML parsing checkswm42015-01-121-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-121-15/+19
| | | | | | | | | | 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-121-1/+1
| | | | Fixes #1457.
* demux_mkv: improve robustness against broken libavcodec parserswm42015-01-091-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.
* csputils: replace float[3][4] with a structwm42015-01-061-3/+3
| | | | | Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
* demux_mkv: avoid PTS warning with image attachmentswm42015-01-051-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: enable codec parsing for vfw-muxed files toowm42014-12-311-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.
* demux_playlist: unquote entries in pls playlistswm42014-12-301-0/+3
| | | | I guess these parsers still have a way to go...
* demux_mkv: reduce log noisewm42014-12-292-3/+2
| | | | | | | This message can happen a lot for mkv files which index clusters in the seekhead (which is also broken non-sense, but that's a different story). Also remove a duplicate define from matroska.h.
* demux_mf: move mf.c contents to demux_mf.cwm42014-12-294-187/+122
| | | | | | | | | There's no reason why parts of this demuxer would be in a separate source file. The existence of this code is already somewhat questionable anyway, so it may as well be dumped into a single file. Even stranger that demux.c included mf.h for no reason (it was an artifact from 2002 when the architecture was uncleaner).
* demux_mkv: use attachment filename as coverart titlewm42014-12-231-0/+1
|
* demux_mf: add probing by mime typewm42014-12-221-1/+5
| | | | Reuses the mime type table introduced in the previous commit.
* demux_mkv: support embedded coverartwm42014-12-223-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.
* Check some mallocswm42014-12-121-0/+4
| | | | Fixes #1337.
* command: add properties for current bitratewm42014-12-122-1/+33
| | | | Fixes #1192.
* demux: don't always make --cache-secs override --demuxer-readahead-secswm42014-12-121-2/+4
| | | | It's confusing. Whether the new behavior is less confusing... whatever.
* emux_mkv: fix possible uninitialized reads with short fileswm42014-12-101-1/+3
| | | | | | | | | | These actually are harmless. Even if the data the reader is working on is essentially random, it's treated like untrusted input data, so there should be no harm. But it upsets tools like valgrind. Probably fixes #1329.
* demux_mkv: support svq3wm42014-12-081-14/+24
| | | | | | | | | | The most awesome codec, not. The actual code for svq3 is actually just the part that checks for MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is minor refactoring, that actually improves the code in general. This is just enough to support the 2 svq3-in-mkv sample files I have.
* demux_mkv: reject 0 TimecodeScalewm42014-12-061-0/+4
| | | | | | | Also reject anything over INT_MAX; no particular reason for this upper bound. Fixes #1317.
* demux_playlist: fix negated conditionwm42014-12-061-1/+1
| | | | Fuck.
* demux: silence unseekable messagewm42014-12-051-2/+2
| | | | | | | This message was added in commit a0acb6ea. But it showed up in all sorts of inappropriate contexts, such as when opening m3u from an unseekable http URL, or playing DVDs. So I guess this didn't work out. Disabling it again.
* demux_playlist: detect headerless m3u files by extensionwm42014-12-051-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: explicitly wake up playback thread on metadata change etc.wm42014-12-041-0/+2
| | | | Probably doesn't matter much in practice.
* demux: don't print message if replaygain tags were not foundwm42014-12-041-3/+1
| | | | Even thouhg it was printed in verbose mode only, it was annoying.
* dvd, bd: don't unnecessarily block on demuxer/stream all the timewm42014-12-043-0/+21
| | | | | | | | | | | | | | | | | | This was completely breaking any low-level caching. Change it so that at least demuxer caching will work. Do this by using the metadata cache mechanism to funnel through the menu commands. For some incomprehensible reason, I had to reorder the events (which affects their delivery priority), or they would be ignored. Probably some crap about the event state being cleared before it could be delivered. I don't give a shit. All this code sucks. It would probably be better to let discnav.c access the menu event "queue" directly, and to synchronize access with a mutex, instead of going through all the caching layers, making things complicated and slow.
* demux_playlist: don't ignore last line in m3uwm42014-11-301-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: remove ancient codec mapping leftoverswm42014-11-283-335/+52
| | | | | | | | | | | | | | | | | | | All of this is basically due to how MPlayer's codecs.conf worked. It had a demuxer-interface based an AVI, using FourCCs and data structures found in AVI. FourCCs were used to map streams to decoders. For codecs not supported by AVI, "MPlayer internal" FourCCs were made up. codec_tags.c is there to bridge demuxers written against the old API to the mpv one. By now, only demux_mkv.c needs this (because demux_mkv is the only serious demuxer left - preferably, we should use libavformat for mkv too, but I can't see this happening any time soon, because libavformat _still_ doesn't support segment linking). But the codec tables are full of weird stuff automatically extracted from the old codecs.conf tables. Most of it isn't needed for mkv. Remove all custom tags, readd those used by demux_mkv.c internally (see vinfo and mkv_audio_tag tables). The rest is handled by the tables provided by libavformat, which includes AVI and QT tags.
* demux_mkv: simplify extradata handlingwm42014-11-271-37/+12
| | | | | | | | | It was more complicated than necessary. The behavior changes slightly. Now it might pass through extradata when it didn't before (hopefully harmless), and doesn't fail with an error if extradata is not available, even though it's needed (harmless, will fail either way).
* demux_mkv: cosmeticswm42014-11-271-24/+13
|
* demux_mkv: fix a possible out of bounds accesswm42014-11-271-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 pa