summaryrefslogtreecommitdiffstats
path: root/demux/demux_lavf.c
Commit message (Collapse)AuthorAgeFilesLines
* 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).
* player: always use demux_chapterwm42014-11-021-5/+1
| | | | | | | | | 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.
* 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.
* 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_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_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-291-1/+1
| | | | | | | | | | | | | 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.
* audio: remove WAVEFORMATEX from internal demuxer APIwm42014-09-251-1/+1
| | | | | Same as with the previous commit. A bit more involved due to how the code is written.
* demux: gracefully handle packet allocation failureswm42014-09-161-3/+9
| | | | Now the packet allocation functions can fail.
* 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-011-7/+17
| | | | | | --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_lavf: print a warning if av_read_frame() returns an errorwm42014-08-301-1/+6
| | | | Because why not.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-2/+1
| | | | | | | | | 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.
* 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: always use AVPacketwm42014-08-251-18/+5
| | | | | | | | | | | | | | | | | | | | | 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_lavf: fix crash with unknown streamswm42014-08-231-1/+1
| | | | Could happen with DVD .vob files.
* 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.)
* 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: fix timestamp type for seek callswm42014-07-211-1/+1
| | | | | mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used float.
* demux_lavf: reverse rotation direction with new APIwm42014-07-171-1/+1
| | | | | | | The old FFmpeg API and the new Libav API disagree about mp4 display rotation direction. Well, whatever, fix it trial-and-error-style. CC: @mpv-player/stable: add
* demux: add a demuxer threadwm42014-07-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* demux_lavf: don't let metadata update mess up ogm playbackwm42014-07-141-1/+4
| | | | | | For OGG audio files, we usually merge the per-stream metadata back to the file-global metadata. Don't do that for OGM, because with OGM most metadata is actually per-stream.
* build: include <strings.h> for strcasecmp()wm42014-07-101-2/+1
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* demux: minor simplificationwm42014-07-061-2/+2
| | | | Oops, should have been part of commit 37085788.
* demux: minor simplification to internal APIwm42014-07-051-1/+1
| | | | Also some other unrelated minor changes.
* dvd: flush buffers properly on seekwm42014-07-051-3/+4
| | | | | | | | | | | Suggested by tholin on github issue #882. This is not entirely clean, but the fields we're accessing might be considered internal to libavformat. On the other hand, existence of the fields is guaranteed by the ABI, and nothing in the libavformat doxygen suggestes they're not allowed to be accessed. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-14/+2
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* demux: make start time a simple fieldwm42014-07-051-5/+7
| | | | Simpler, especially for later changes.
* demux, stream: change metadata notificationwm42014-07-051-0/+1
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* demux: make replaygain per-trackwm42014-07-051-3/+3
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually happen, but this change might help avoid minor corner cases with later changes.
* demux_lavf: for now, ignore the new libavformat image demuxerswm42014-07-051-0/+3
| | | | | | | | | | | | Recently, libavformat added demuxers to open image files like normal demuxers. This is a good thing, but for now they interfere with the operation of demux_mf. Add them to the blacklist until there is a proper solution. (The list doesn't contain _all_ recognized image formats, just those that might interfere with demux_mf.) CC: @mpv-player/stable
* demux_lavf: support OTF fonts in Matroskawm42014-07-051-3/+10
| | | | Apparently it's FFmpeg only.
* demux_lavf: don't dump transport stream programswm42014-07-051-13/+0
| | | | Probably useless.
* demux_lavf: cleanup debug outputwm42014-07-051-19/+10
| | | | Remove unnecessary prefix, remove some messages.
* demux_lavf: fix read_seek return valuewm42014-07-051-3/+1
| | | | | | | This returned a stream error value directly to libavformat, which can't make sense. For example STREAM_ERROR (0) means success in libavformat error codes. (The meaning of the libavformat read_seek return value is underdocumented too.)
* demux_lavf: remove unused symbolwm42014-06-231-2/+0
|
* options: turn --idx, --forceidx into --indexwm42014-06-131-1/+1
| | | | | | | | | | | | Also clarify the semantics. It seems --idx didn't do anything. Possibly it used to change how the now removed legacy demuxers like demux_avi used to behave. Or maybe it was accidental. --forceidx basically becomes --index=force. It's possible that new index modes will be added in the future, so I'm keeping it extensible, instead of e.g. creating --force-index.
* demux_lavf: make option struct localwm42014-06-111-16/+34
| | | | Similar to previous commits.
* Add more constwm42014-06-111-3/+3
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* demux_lavf: support new rotation metadata APIwm42014-06-011-1/+11
|
* command: improve video-bitrate propertyAndrey Morozov2014-06-011-0/+3
| | | | | | Signed-off-by: wm4 <wm4@nowhere> Includes some cosmetic changes over the original PR.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-281-2/+2
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-281-2/+2
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* stream: don't use end_poswm42014-05-241-11/+14
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* stream: kill start_pos, remove --sb optionwm42014-05-241-4/+4
| | | | | | | | | | | | | | | | | | | | stream.start_pos was needed for optical media only, and (apparently) not for very good reasons. Just get rid of it. For stream_dvd, we don't need to do anything. Byte seeking was already removed from it earlier. For stream_cdda and stream_vcd, emulate the start_pos by offsetting the stream pos as seen by the rest of mpv. The bits in discnav.c and loadfile.c were for dealing with the code seeking back to the start in demux.c. Handle this differently by assuming the demuxer is always initialized with the stream at start position, and instead seek back if initializing the demuxer fails. Remove the --sb option, which worked by modifying stream.start_pos. If someone really wants this option, it could be added back by creating a "slice" stream (actually ffmpeg already has such a thing).
* demux_lavf: one more hack for mp3 from networkwm42014-05-041-1/+1
| | | | | | | | | | | | | | mp3 has a hack lowering the probescore for format detection. This is because detecting mp3s is hard due to their nature, and the fact that ID3v2 tags are sometimes several megabytes big. When playing mp3 from network, the mime-type is usually set, and that matches the format hack entry meant for webradios, overriding the normal mp3 entry. This can lead to network mp3s not being detected. Lower the network case to the same probescore as on-disk mp3s. The difference is that for network mp3s, we don't load the full probe-buffer, and we lower the amount of audio the demuxer will read to collect data on opening (0.5 seconds instead of typically 5 seconds).
* demux: export video rotation parameterwm42014-04-211-0/+8
| | | | | Now the rotation hint is propagated everywhere. It just isn't used anywhere yet.
* mp_tags: move generic mp_tags stuff into its own .c/.h files in common/Kevin Mitchell2014-04-131-11/+5
| | | | | | rename add_metadata to the more genera/descriptive mp_tags_copy_items_from_av_dictionary Signed-off-by: wm4 <wm4@nowhere>
* stream_dvd, cache: hack seeking with --cache + dvd:// back into workingwm42014-04-091-0/+2
| | | | | | | | | | | | | | | | | | | This was broken at some unknown point (even before the recent cache changes). There are several problems: - stream_dvd returning a random stream position, confusing the cache layer (cached data and stream data lost their 1:1 corrospondence by position) - this also confused the mechanism added with commit a9671524, which basically triggered random seeking (although this was not the only problem) - demux_lavf requesting seeks in the stream layer, which resulted in seeks in the cache or the real stream Fix this by completely removing byte-based seeking from stream_dvd. This already works fine for stream_dvdnav and stream_bluray. Now all these streams do time-based seeks, and pretend to be infinite streams of data, and the rest of the player simply doesn't care about the stream byte positions.
* demux: add replaygain_data field to demuxer_tAlessandro Ghedini2014-04-041-1/+38
|
* demux_lavf: fix typo in commentwm42014-03-041-1/+1
| | | | Pushed too early...
* sub: use new FFmpeg API to check MicroDVD FPSwm42014-03-041-5/+13
| | | | | | Before this, it wasn't possible to distinguish MicroDVD subtitles without FPS header, and subtitles with FPS header equal to FFmpeg's fallback FPS.
* sub: handle vobsub-in-mp4wm42014-02-131-0/+2
| | | | | | | | | | | The mplayer decoder (spudec.c) actually handled this. There was explicit code for binary palettes (16 32 bit values), and the subtitle resolution was handled by video resolution coincidentally matching the subtitle resolution. Whoever puts vobsub into mp4 should be punished. Fixes the sample gundam_sample.mp4, closes github issue #547.
*