summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | This was "forgotten".
* demux_lavf: bluray: don't skip stream data when flushingwm42014-09-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This code meant to flush demuxer internal buffers by doing a byte seek to the current position. In theory this shouldn't drop any stream data. However, if the stream positions mismatch, then avio_seek() (called by av_seek_frame()) stops being a no-op, and might for example read some data to skip to the seek target. (This can happen if the distance is less than SHORT_SEEK_THRESHOLD.) The positions get out of sync because we drop data at one point (which is what we _want_ to do). Strictly speaking, the AVIOContext flushing is done incorrectly, becuase pb->pos points to the start of the buffer, not the current position. So we have to increment pb->pos by the buffered amount. Since there are other weird reasons why the positions might go out of sync (such as stream_dvd.c dropping buffers itself), and they don't necessarily need to be in sync in the first place unless AVIOContext has nothing buffered internally, just use the sledgehammer approach and correct the position manually. Also run av_seek_frame() after this. Currently, it shouldn't read anything, but who knows how that might change with future libavformat development. This whole change didn't have any observable effect for me, but I'm hoping it fixes a reported problem.
* demux_disc: bluray: potentially fix some aspects of seekingwm42014-09-292-1/+7
| | | | | | | | | | | | | When flushing the AVIOContext, make sure it can't seek back to discarded data. buf_ptr is just the current read position, while buf_end - buffer is the actual buffer size. Since mpegts.c is littered with seek calls, it might be that the ability to seek could read Mark the stream (which the demuxer uses) as not seekable. The cache can enable seeking again (this behavior is sometimes useful for other things). I think this should have had no bad influence in theory, since seeking BD/DVD first does the "real" seek, then flushes libavformat and reads new packets.
* demux_mkv: don't use default_duration for parsed packetswm42014-09-261-4/+6
| | | | | | | | | Makes it behave slightly better for VP9. This is also the behavior libavformat has. Also while we're at it, don't set duration except for the first packet. Normally we don't use the duration except for subtitles (which are never parsed or "laced"), so this should make no observable difference.
* Remove mpbswap.hwm42014-09-251-1/+0
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* stream_cdda, demux_raw: always use s16lewm42014-09-251-1/+1
| | | | | | | | | | | | | stream_cdda's output format is linked to demux_raw's default audio format, and at least we don't care enough to provide a separate mechanism to let stream_cdda explicitly set the format, so they must match. Judging from the existing code, it looks like CDDA always outputs little endian. stream_cdda.c changed this back to native endian (what demux_raw expects). Just make them both little endian. This requires less code, and also having a raw demuxer's behavior depend on the endianness of the machine isn't very sane anyway.
* demux_mkv: get rid of MS structswm42014-09-253-119/+39
| | | | | | | See previous commits. This finally replaces directly reading the file data into a struct with reading them manually. In theory this is more portable (no alignment issues and other things). For the most part, it's nice seeing this gone.
* audio: remove WAVEFORMATEX from internal demuxer APIwm42014-09-254-79/+83
| | | | | Same as with the previous commit. A bit more involved due to how the code is written.
* video: remove BITMAPINFOHEADER from internal demuxer APIwm42014-09-252-11/+11
| | | | | | | | | | MPlayer traditionally did this because it made sense: the most important formats (avi, asf/wmv) used Microsoft formats, and many important decoders (win32 binary codecs) also did. But the world has changed, and I've always wanted to get rid of this thing from the codebase. demux_mkv.c internally still uses it, because, guess what, Matroska has a VfW muxing mode, which uses these data structures natively.
* audio: confine demux_mkv audio PCM hackwm42014-09-241-6/+28
| | | | | | | | Let codec_tags.c do the messy mapping. In theory we could simplify further by makign demux_mkv.c directly use codec names instead of the MPlayer-inherited "internal FourCC" business, but I'd rather not touch this - it would just break things.
* audio: decouple demux and audio decoder/filter sample formatswm42014-09-245-51/+62
| | | | | | | | | | | | | | | | | | | | For a while, we used this to transfer PCM from demuxer to the filter chain. We had a special "codec" that mapped what MPlayer used to do (MPlayer passes the AF sample format over an extra field to ad_pcm, which specially interprets it). Do this by providing a mp_set_pcm_codec() function, which describes a sample format in a generic way, and sets the appropriate demuxer header fields so that libavcodec interprets it correctly. We use the fact that libavcodec has separate PCM decoders for each format. These are systematically named, so we can easily map them. This has the advantage that we can change the audio filter chain as we like, without losing features from the "rawaudio" demuxer. In fact, this commit also gets rid of the audio filter chain formats completely. Instead have an explicit list of PCM formats. (We could even just have the user pass libavcodec PCM decoder names directly, but that would be annoying in other ways.)
* audio: cleanup spdif format definitionswm42014-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* audio: drop swapped-endian audio formatswm42014-09-233-7/+17
| | | | | | | | | | | | | | | | | | | | Until now, the audio chain could handle both little endian and big endian formats. This actually doesn't make much sense, since the audio API and the HW will most likely prefer native formats. Or at the very least, it should be trivial for audio drivers to do the byte swapping themselves. From now on, the audio chain contains native-endian formats only. All AOs and some filters are adjusted. af_convertsignendian.c is now wrongly named, but the filter name is adjusted. In some cases, the audio infrastructure was reused on the demuxer side, but that is relatively easy to rectify. This is a quite intrusive and radical change. It's possible that it will break some things (especially if they're obscure or not Linux), so watch out for regressions. It's probably still better to do it the bulldozer way, since slow transition and researching foreign platforms would take a lot of time and effort.
* demux: gracefully handle packet allocation failureswm42014-09-166-25/+54
| | | | Now the packet allocation functions can fail.
* ebml: warn if there are too many subelementswm42014-09-041-3/+7
| | | | Seems like a good idea.
* demux_mkv: allow up to 256 MB of extradata to make broken files workwm42014-09-041-1/+1
| | | | | | | | What the flying fuck? Unfortunately, these are already in the wild. CC: @mpv-player/stable
* 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.
* player: show HLS bitrate as fallback for track titleswm42014-09-011-0/+2
| | | | | | HLS streams as demuxed by libavformat have no track title metadata. So show the HLS bitrate if no title is set. Could be useless or annoying, so it's a bit controversial, I guess.
* player: simplistic HLS bitrate selectionwm42014-09-012-7/+18
| | | | | | --hls-bitrate=min/max lets you select the min or max bitrate. That's it. Something more sophisticated might be possible, but is probably not even worth the effort.
* demux: get rid of old wrapperwm42014-09-012-7/+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.
* video: initial Matroska 3D supportwm42014-08-302-0/+13
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* demux_lavf: print a warning if av_read_frame() returns an errorwm42014-08-301-1/+6
| | | | Because why not.
* demux_mkv: eliminate redundant branchshdown2014-08-301-5/+1
| | | | | | In the else branch pict_type is always 3, so pict_type != 3 is always false. (Note that I have no idea of what it was supposed to do and it is just an equivalent of the old behaviour.)
* 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.
* demux_disc: handle new_sh_stream() fail correctlyshdown2014-08-301-2/+4
| | | | | Break the cycle on fail. Old code was checking if sh is NULL after accessing it's fields.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-297-8/+7
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* 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_lavf: don't reject av:// if cache is enabledwm42014-08-271-1/+1
| | | | | Enabling the cache doesn't make much in this situation, but there's also no reason not to reject it.
* demux: reset idle state on seekswm42014-08-271-2/+2
|
* player: better cache status on status linewm42014-08-272-0/+4
| | | | | | | | | | | | | | 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-272-1/+33
| | | | | | | | | | | | | | | | | | | Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
* demux: reduce wakeups if no cache is activewm42014-08-271-1/+5
| | | | | | | | | | | | The purpose of the unconditional pthread_cond_signal() when reading cached DEMUXER_CTRLs and STREAM_CTRLs was apparently to update the stream cache state. Otherwise, the cached fields would never be updated when the stream is e.g. paused. The same could be said about other CTRLs, but these aren't as important, since they are normally updated while reading packet data. In order to reduce wakeups, make this logic explicit.
* demux: always use AVPacketwm42014-08-253-65/+39
| | | | | | | | | | | | | | | | | | | | | This is a simplification, because it lets us use the AVPacket functions, instead of handling the details manually. It also allows the libavcodec rawvideo decoder to use reference counting, so it doesn't have to memcpy() the full image data. The change in av_common.c enables this. This change is somewhat risky, because we rely on the following AVPacket implementation details and assumptions: - av_packet_ref() doesn't access the input padding, and just copies the data. By the API, AVPacket is always padded, and we violate this. The lavc implementation would have to go out of its way to make this a real problem, though. - We hope that the way we make the AVPacket refcountable in av_common.c is actually supported API-usage. It's hard to tell whether it is. Of course we still use our own "old" demux_packet struct, just so that libav* API usage is somewhat isolated.
* demux: avoid unnecessary wakeupswm42014-08-241-1/+1
| | | | | | | | | If a packet is appended to a stream, and there were already packets queued, nothing about the state changed, as far as the user (i.e. the player) is concerned. Thus no wakeup is needed. The pthread_cond_signal() call following this is not interesting - it will simply be a NOP if there are actually no waiters.
* demux_lavf: fix crash with unknown streamswm42014-08-231-1/+1
| | | | Could happen with DVD .vob files.
* demux: enable thread by defaultwm42014-08-161-5/+0
| | | | And change the defaults for the other queue options to reduce latency.
* demux: add option to control the readahead buffer by a duration valuewm42014-08-161-1/+19
| | | | | | | | | | | | | --demuxer-readahead-secs now controls how much the demuxer should readahead by an amount of seconds. This is based on the raw packet timestamps. It's not always very exact. For example, h264 in Matroska does not store any linear timestamps (only PTS values which are going to be reordered by the decoder), so this heuristic is usually off by several hundred milliseconds. The decision whether to readahead is basically OR-ed with the other --demuxer-readahead-packets options. Change the manpage descriptions to subtly convey these semantics.
* demux: remove unused functionwm42014-08-162-13/+0
|
* demux_lavf: support new metadata update APIwm42014-08-141-3/+23
| | | | | This Libav-invented API is of course completely different from the FFmpeg-one. (The fun part is that I approved of both.)
* demux: reduce log spam if threading is disabledwm42014-08-111-3/+11
|
* demux: fix playback abort if --demuxer-thread is not usedwm42014-08-071-9/+9
| | | | | | | | | | | | Switching tracks caused cached_demux_control() to catch the command to switch tracks, even if no thread was running. Thus, the tracks were never really switched, and EOF happened immediately on playback start. Fix it by not using the cache at all if the demuxer thread is disabled. The cache code still has to be called somewhere, though, because it handles stream metadata update. Regression from today.
* demux: make track switching asynchronouswm42014-08-061-0/+21
| | | | | | | | | | | | | Because why not. This can lead to reordering of operations between seeking and track switching (happens when the demuxer wakes up after seek and track switching operations were queued). Do the track switching strictly before seeks if there is a chance of reordering, which guarantees that the seek position will always start with key frames. The reverse (seeking, then switching) does not really have any advantages. (Not sure if the player relies on this behavior.)
* Improve setting AVOptionswm42014-08-021-14/+5
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* demux_lavf: don't consider EAGAIN as EOF conditionwm42014-07-301-2/+3
| | | | | | | | | | This happens apparently randomly with rtmp:// and after seeks. This eventually leads to audio decoding returning an EOF status, which basically disables audio sync. This will lead to audio desync, even if audio decoding later "recovers" when the demuxer actually returns audio packets. Hack-fix this by special-casing EAGAIN.
* stream: hack-fix rtmp-level seekingwm42014-07-301-4/+7
| | | | | | | | | | | | | This didn't work, because the timebase was wrong. According to the ffmpeg doxygen, if the stream index is -1 (which is what we used), the timebase is AV_TIME_BASE. But this didn't work, and it really expected the stream's timebase. Quite "surprising", since this feature (avio_seek_time) is used by rtmp only. Fixing this properly is too hard, so hack-fix our way around it. STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new STREAM_CTRL_AVSEEK is added. We simply pass-through the request verbatim.
* demux_mf: allow seeking past the endwm42014-07-301-1/+1
| | | | How's this for a corner case.
* demux: fix timestamp type for seek callswm42014-07-217-8/+8
| | | | | mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used float.
* demux: asynchronous seekingwm42014-07-211-9/+43
| | | | | | | | | | | | | | | | | This tells the demuxer thread that it should seek, instead of waiting until the demuxer thread is ready. Care has to be taken about the state between seek request and actual seeking: newly demuxed packets have to be discarded. We can't just flush when doing the actual seek, because the user thread could read these packets. I'm wondering if this could lead to issues due to relaxed ordering of operations. But it should be fine, since seeking influences packet reading only, and seeking is always strictly done before that. Currently, this will have no advantages; unless audio is disabled. Then seeking as well as normal playback can be non-blocking.
* demux: don't start reading if no packets were requested yetwm42014-07-201-1/+1
| | | | |