summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux: add free_demuxer_and_stream() functionwm42015-02-204-9/+14
| | | | | Although their lifetimes are conceptually different, it happens often that a demuxer is destroyed together with its stream.
* demux_lavf: apply hacks even if format is forcedwm42015-02-201-27/+28
| | | | | | | | | | | | | Some of the hacks were not applied if the file format was forced. Commit 37a0c914 moved them to a table, which is checked with normal probing only. Fixes #1612 (DVD forces mpeg, which in turn has to export native stream IDs specifically). Do some code restructuring on the way. For example, the probescore can simply be set to the correct initial value, instead of checking whether it was set at all.
* demux_lavf: blacklist bintext fileswm42015-02-181-0/+3
| | | | | | Whatever the hell that is. FFmpeg tries to open any files with .bin file extension with this demuxer (unless it finds a better demuxer), and then reads the whole damn file, along with spamming dumb crap.
* player: enable cache and demuxer thread for subtitles toowm42015-02-188-0/+19
| | | | | | | | | Includes some logic for not starting the demuxer thread for fully read subtitles. (Well, the cache will still waste _lots_ of resources, and the cache always has to be created, because we don't know whether it'll be needed _before_ opening the file.) See #1597.
* demux_lavf: reorganize hackswm42015-02-181-67/+70
| | | | | | | | | | | An attempt to make format-specifics more declarative. (In my opinion, all of this should be either provided by libavformat, or should not be needed.) I'm still leaving many checks with matches_avinputformat_name(), because they're so specific. Also useful for the following commit.
* demux_lavf: set interrupt_callbackwm42015-02-181-0/+11
| | | | | | Helps with terminating the stream if e.g. HLS streams are stuck. (For other demuxers, the stream's interrupt callback already takes care of this.)
* demux, matroska: remove demuxer type fieldwm42015-02-174-39/+29
| | | | | | | | | | | | | The Matroska timeline code was the only thing which still used the demuxer.type field. This field explicitly identifies a demuxer implementation. The purpose of the Matroska timeline code was to reject files that are not Matroska. But it already forces the Matroska format, meaning loading will explicitly only use the Matroska demuxer. If the demuxer can't open the file, no other demuxer will be tried, and thus checking the field is redundant. The change in demux_mkv_timeline.c removes the if condition, and unindents the if body.
* demux: remove file_contents fieldwm42015-02-174-11/+25
| | | | | | | Only demux_cue and demux_edl used it. It's a weird field and doesn't help with anything anymore - by now, it only saves a priv context in the mentioned demuxers. Reducing the number of confusing things the demuxer struct has is more important than minimizing the code.
* demux_edl: make independent from MPContextwm42015-02-172-42/+36
|
* demux_edl: move implementationwm42015-02-171-2/+280
| | | | Same deal as with demux_cue, and a separate commit for the same reasons.
* demux_cue: make independent from MPContextwm42015-02-172-35/+36
| | | | Also see previous commit(s).
* demux_cue: move implementationwm42015-02-171-4/+388
| | | | | | | | Move the implementation, of which most was in tl_cue.c, to demux_cue.c. Currently, this is illogical, because tl_cue.c still accesses MPContext. This is going to change, and then it will be better if everything is in demux_cue.c. This is only a separate commit to distinguish code movement and actual work; the next commit will do the actual work.
* demux: copy priv pointer toowm42015-02-171-0/+1
| | | | | Weird, but helps with the case a demuxer gets handed its own instance from outside.
* matroska: move timeline code to demux/wm42015-02-171-0/+654
| | | | | Separate from previous commit, because git is bad at tracking file renames when the file contents are also changed.
* matroska: make timeline code independent of MPContextwm42015-02-172-1/+5
|
* player: use a separate context for timeline loader stuffwm42015-02-173-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | Instead of accessing MPContext in player/timeline/*, create a separate context struct, which the timeline loaders fill out. It turns out that there's not much in the way too big MPContext that these need to access. One major PITA is managing (and closing) the set of open demuxers. The problem is that we need a list of all demuxers to make sure no unneeded streams are enabled. This adds a callback to the demuxer_desc struct, with the intention of leaving to to the demuxer to call the right loader, instead of explicitly checking the demuxer type and dispatching manually in common code. I also considered making the timeline part of the demuxer state, but decided against: it's too much of a mess wrt. memory management and threading, and also doesn't make it clear who owns the child demuxers. With the struct timeline decoupled from the demuxer state, it's at least somewhat clear that the child demuxers are independent from the "main" demuxer. The actual changes to player/timeline/* are separated in the following commits, because they're quite verbose. Some artifacts will be removed later as soon as there's only 1 timeline loading mechanism.
* demux: chapters without metadata are allowedwm42015-02-171-2/+3
| | | | Makes some of the following commits slightly simpler. Also fix a typo.
* demux_lavf: hack against hls showing "100%" positionwm42015-02-171-0/+6
| | | | | | | | | | | | | The HLs protocol consists of a "playlist" main file, which mpv downloads and passes to the HLS demuxer. The HLS demuxer actually requests segment files containing media data on its own. The packets read from the demuxer have a source file position set, but it's not from the main file. This leads to a strange effect: as a last fallback, the player will calculate the approximate playback position from the file position/size ratio, and since the main file is tiny, this will always show 100%. Fix this by resetting the packet file position. This doesn't affect the case when HLS actually reports a duration.
* demux: fix dropped subtitle packets with the new stream switchingwm42015-02-142-3/+4
| | | | | | | | | | | | | | If the previous subtitle packet is too far back, and the refresh seek won't pick it up, and the packet never comes again. As a consequence, the refresh mode was never stopped on the subtitle stream, which caused all packets to be discarded. Fix by assuming the file position is monotonically increasing; then it will resume even if a packet _after_ the intended resume point is returned. This introduces a new requirement on how the demuxer behaves. (I'm not sure if mp4 actually satisfies this requirement in all cases.) Fixes a regression introduced by commit f9f2e1cc.
* demux: hack for instant stream switchingwm42015-02-134-4/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the delay when switching audio tracks in mkv or mp4 files. Other formats are not enabled, because it's not clear whether the demuxers fulfill the requirements listed in demux.h. (Many formats definitely do not with libavformat.) Background: The demuxer packet cache buffers a certain amount of packets. This includes only packets from selected streams. We discard packets from other streams for various reasons. This introduces a problem: switching to a different audio track introduces a delay. The delay is as big as the demuxer packet cache buffer, because while the file was read ahead to fill the packet buffer, the process of reading packets also discarded all packets from the previously not selected audio stream. Once the remaining packet buffer has been played, new audio packets are available and you hear audio again. We could probably just not discard packets from unselected streams. But this would require additional memory and CPU resources, and also it's hard to tell when packets from unused streams should be discarded (we don't want to keep them forever; it'd be a memory leak). We could also issue a player hr-seek to the current playback position, which would solve the problem in 1 line of code or so. But this can be rather slow. So what we do in this commit instead is: we just seek back to the position where our current packet buffer starts, and start demuxing from this position again. This way we can get the "past" packets for the newly selected stream. For streams which were already selected the packets are simply discarded until the previous position is reached again. That latter part is the hard part. We really want to skip packets exactly until the position where we left off previously, or we will skip packets or feed packets to the decoder twice. If we assume that the demuxer is deterministic (returns exactly the same packets after a seek to a previous position), then we can try to check whether it's the same packet as the one at the end of the packet buffer. If it is, we know that the packet after it is where we left off last time. Unfortunately, this is not very robust, and maybe it can't be made robust. Currently we use the demux_packet.pos field as unique packet ID - which works fine in some scenarios, but will break in arbitrary ways if the basic requirement to the demuxer (as listed in the demux.h additions) are broken. Thus, this is enabled only for the internal mkv demuxer and the libavformat mp4 demuxer. (libavformat mkv does not work, because the packet positions are not unique. Probably could be fixed upstream, but it's not clear whether it's a bug or a feature.)
* demux_mkv: return unique file positions for all packetswm42015-02-131-4/+5
| | | | | | | | | | | | | Until now, some packets could return the same file position if they were split off from a Matroska-level packet. This was perfectly fine, because the file position isn't used for anything overly important (it uses it to estimate playback position if no other information is available). The following commit will use the demux_packet.pos field as unique ID (as a simplification), so make the demuxer export more finegrained information. Also, the last_filepos field didn't have to be global, at least not anymore.
* 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
| | | | | | |