summaryrefslogtreecommitdiffstats
path: root/demux/demux.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: handle Matroska-style replaygain tags as wellwm42015-07-121-0/+8
| | | | | | | Matroska doesn't follow the usual ReplayGain conventions, and doesn't distinguish between track/album values. Fixes #2128.
* demux: refactor replaygain tag handlingwm42015-07-121-17/+19
| | | | | For the following commit. Also print the replaygain values in verbose mode.
* player: disable seeking even if the cache is enabledwm42015-07-081-3/+2
| | | | | | | | | | | | | | Until now, if a stream wasn't seekable, but the stream cache was enabled (--cache), we've enabled seeking anyway. The idea was that at least short seeks would typically fall within the cache. And if not, the user was out of luck and terrible things happened. In other words, it was unreliable. Be stricter about it and remove this behavior. Effectively, this will for example disable seeking in piped data. Instead of trying to be clever, add an --force-seekable option, which will always enable seeking if the user really wants it.
* demux: get rid of some bstr thingswm42015-06-241-12/+10
| | | | | Change the demuxer_add_attachment() and demuxer_add_chapter() signatures to take char* instead of bstr, and everything which depends on it.
* player: add some debug output for seekingwm42015-06-181-0/+7
|
* demux: don't get stuck on some cases of timestamp resetswm42015-05-261-1/+2
| | | | | In this case, streaming ogg via mpd over icecast made it buffer infinitely on new tracks.
* demux: read cue sheets embedded in tagswm42015-05-191-2/+17
| | | | | | | | | This reads the "CUESHEET" tag, and attempts to parse it as .cue data. If any is found, the cue tracks are added as chapters. This reuses the parser written for demux_cue.c. Fixes #1957.
* demux_mkv: move global options to the demuxerwm42015-04-231-1/+1
| | | | | | | The options don't change, but they're now declared and used privately by demux_mkv.c. This also brings with it a minor refactor of the subpreroll seek handling - merge the code from playloop.c into demux_mkv.c. The change in demux.c is pretty much equivalent as well.
* demux: report correct cache state close to EOFwm42015-04-201-5/+4
| | | | | | | | | | | | | | | | | | | | | On EOF, this stopped reporting the actual cache duration, and just signalled unknown duration. Fix this and keep reporting whatever is left in the packet queue. This reverts commit 5438a8b3. The commit doesn't give a good explanation as to why it is needed, but I guess it was because the reporting was imperfect (it switched between unknown or 0, and the correct duration). This also removes a line added in commit 848546f2. The line is ds->active = false; The "active" flag basically says that data from this stream is actively needed, and it's used to calculate the minimum data that can actually be played (approximately). If this were ignored, a sparse subtitle stream would set the cache duration to 0s. The commit message adding the line says "actually does nothing, but in theory it's cleaner". Well, screw it.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* demux: fix rar support for files containing DTS audio trackswm42015-03-241-0/+2
| | | | | | | | | | | | | | | | | With a recent cleanup, rar support was stuffed into demux_playlist.c (because "opening" rar files pretty much just lists archive contents and adds them to a playlist using a special rar:// protocol, which will actually access the rar file contents). Since demux_playlist.c is probed _after_ demux_lavf.c (and should/must be), libavformat was given the chance to detect DTS streams embedded within the rar file. This is not really what we want, and a regression what happened before rar listing was moved to demux_playlist.c. Fix it by moving the rar listing into its own pseudo-demuxer, and let ir probe before demux_lavf.c. (Yes, this feature still has users.)
* demux_mkv: check for playback abortswm42015-03-091-0/+5
| | | | | | | | | Check async abort notification. libavformat already do something equivalent. Before this commit, the demuxer could enter resync mode (and print silly warning messages) when the stream stopped returning data because of an abort.
* stream: remove stream filter conceptwm42015-02-271-1/+1
| | | | Unused since the previous commit. (Apparently it was a stupid idea.)
* demux: add a demux_open_url() functionwm42015-02-201-0/+20
| | | | | Often stream and a demuxer are opened at the same time. Provide a function for this and replace most of its uses.
* demux: change demux_open() signaturewm42015-02-201-4/+4
| | | | Fold the relatively obscure force_format parameter into demuxer_params.
* demux: add free_demuxer_and_stream() functionwm42015-02-201-0/+9
| | | | | Although their lifetimes are conceptually different, it happens often that a demuxer is destroyed together with its stream.
* player: enable cache and demuxer thread for subtitles toowm42015-02-181-0/+1
| | | | | | | | | 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, matroska: remove demuxer type fieldwm42015-02-171-1/+0
| | | | | | | | | | | | | 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-171-1/+0
| | | | | | | 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: copy priv pointer toowm42015-02-171-0/+1
| | | | | Weird, but helps with the case a demuxer gets handed its own instance from outside.
* demux: chapters without metadata are allowedwm42015-02-171-2/+3
| | | | Makes some of the following commits slightly simpler. Also fix a typo.
* demux: fix dropped subtitle packets with the new stream switchingwm42015-02-141-2/+2
| | | | | | | | | | | | | | 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-131-4/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* command: export more details about file seekabilitywm42015-01-261-0/+2
| | | | | | | | | | 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.
* demux_disc: pass seek flags to stream layerwm42015-01-191-0/+1
| | | | | | | | | | | | | | | | 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_mf: move mf.c contents to demux_mf.cwm42014-12-291-1/+0
| | | | | | | | | 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).
* command: add properties for current bitratewm42014-12-121-1/+32
| | | | 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.
* 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: 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-041-0/+17
| | | | | | | | | | | | | | | | | | 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: 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: 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: 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.
* player: always use demux_chapterwm42014-11-021-5/+15
| | | | | | | | | 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: fix demux_seek signaturewm42014-10-291-1/+1
| | | | Probably doesn't matter much.
* demux: move some seek flag sanitation to generic codewm42014-10-291-0/+13
| | | | No reason why only demux_mkv.c should do this.
* 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-211-0/+1
| | | | | | | | | 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: allow increasing filepos onlywm42014-09-031-1/+2
| | | | | | | | | | | The last demuxed file position (demuxer->filepos) is used to estimate the total playback percentage in files with possible timestamp resets (like MPEG-PS). Until know, reading from any stream set this position freely. This makes the position jump around. Fix this by allowing icnreasing file position only. Reset it on seeking. With crazy formats, this still could go wrong, but there's only so much you can do.
* demux: get rid of old wrapperwm42014-09-011-5/+0
| | | | | demux_info_get() used to be central, but was turned into a wrapper, and now there was only one caller left. Get rid of it.
* demux: eliminate redundant checkshdown2014-08-301-1/+1
| | | | | pkt can't be NULL since it's initialized from ds->head, which is checked at the beginning.
* player: slightly better cache underrun detectionwm42014-08-271-0/+1
| | | | | | | | | | | | | | | | | | Use the "native" underrun detection, instead of guessing by a low cache duration. The new underrun detection (which was added with the original commit) might have the problem that it's easy for the playloop to miss the underrun event. The underrun is actually not stored as state, so if the demuxer thread adds a new packet before the playloop happens to see the state, it's as if it never happened. On the other hand, this means that network was fast enough, so it should be just fine. Also, should it happen that we don't know the cached range (the ts_duration < 0 case), just wait until the demuxer goes idle (i.e. read_packet() decides to stop). This pretty much should affect broken or unusual files only, and there might be various things that could go wrong. But it's more robust in the normal case: this situation also happens when no packets have been read yet, and we don't want to consider this as reason to resume playback.
* demux: reset idle state on seekswm42014-08-271-2/+2
|
* player: better cache status on status linewm42014-08-271-0/+3
| | | | | | | | | | | | | | The cache percentage was useless. It showed how much of the total stream cache was in use, but since the cache size is something huge and unrelated to the bitrate or network speed, the information content of the percentage was rather low. Replace this with printing the duration of the demuxer-cached data, and the size of the stream cache in KB. I'm not completely sure about the formatting; suggestions are welcome. Note that it's not easy to know how much playback time the stream cache covers, so it's always in bytes.
* player: fix basic playbackwm42014-08-271-1/+1
| | | | | | | | | | | | | The "buffering" logic was active even if the stream cache was disabled. This is contrary to what the manpage says. It also breaks playback because of another bug: the demuxer cache is smaller than 2 seconds, and thus the resume condition never becomes true. Explicitly run this code only if the stream cache is enabled. Also, fix the underlying problem of the breakage, and resume when the demuxer thread stops reading in any case, not just on EOF. Broken by previous commit. Unbreaks playback of local files.
* player: redo how stream caching and pausing on low cache workswm42014-08-271-1/+27
| | <