1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-21 22:30:22 +00:00
Commit Graph

166 Commits

Author SHA1 Message Date
wm4
79006ef66d demux_lavf: blacklist bintext files
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.
2015-02-18 21:13:11 +01:00
wm4
102946ee03 player: enable cache and demuxer thread for subtitles too
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.
2015-02-18 21:12:57 +01:00
wm4
37a0c9140a demux_lavf: reorganize hacks
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.
2015-02-18 21:12:57 +01:00
wm4
ff992e093b demux_lavf: set interrupt_callback
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.)
2015-02-18 21:12:57 +01:00
wm4
a64b1deaa6 demux_lavf: hack against hls showing "100%" position
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.
2015-02-17 23:42:04 +01:00
wm4
f9f2e1cc4e demux: hack for instant stream switching
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.)
2015-02-13 21:17:17 +01:00
wm4
9681d42a94 command: export file format as property
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.
2015-01-23 15:59:06 +01:00
wm4
2b337d67a4 Check some mallocs
Fixes #1337.
2014-12-12 17:28:22 +01:00
wm4
9479daa13e demux_lavf: set PTS of first packet for formats with no timestamps
Makes time display work for some raw audio formats (*.shn).
2014-11-25 19:08:23 +01:00
wm4
969757baa0 player: always use demux_chapter
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.
2014-11-02 17:29:41 +01:00
wm4
6c469dc9d9 demux_lavf, stream_lavf: drop local buffers on time-seeks
There was chance that some data was left in various local buffers after
time-seeks. Probably doesn't actually matter.
2014-10-30 22:50:44 +01:00
wm4
a77a171b7f demux_lavf: mark as seekable if protocol supports seeking by time
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.
2014-10-30 22:46:36 +01:00
wm4
f0f83ff366 player: add stream selection by ffmpeg index
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.
2014-10-21 13:19:20 +02:00
wm4
9241e1bf10 demux_lavf: set stream network options if applicable
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.)
2014-10-14 21:01:30 +02:00
wm4
ffd3ae1fad demux_lavf: let libavformat open HLS streams directly
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.
2014-10-14 20:43:27 +02:00
wm4
332808bc0d demux_lavf: blacklist jpeg files
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
2014-10-06 21:49:32 +02:00
wm4
b0cb2977ed demux_lavf: bluray: don't skip stream data when flushing
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.
2014-09-29 18:06:44 +02:00
wm4
39451732e9 demux_disc: bluray: potentially fix some aspects of seeking
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.
2014-09-29 18:06:44 +02:00
wm4
9c3c199558 audio: remove WAVEFORMATEX from internal demuxer API
Same as with the previous commit. A bit more involved due to how the
code is written.
2014-09-25 01:56:51 +02:00
wm4
caaeb15318 demux: gracefully handle packet allocation failures
Now the packet allocation functions can fail.
2014-09-16 18:11:00 +02:00
wm4
291d986810 player: show HLS bitrate as fallback for track titles
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.
2014-09-01 23:50:25 +02:00
wm4
5f14543668 player: simplistic HLS bitrate selection
--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.
2014-09-01 23:47:27 +02:00
wm4
98ef68bdfd demux_lavf: print a warning if av_read_frame() returns an error
Because why not.
2014-08-30 15:15:38 +02:00
wm4
68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
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.
2014-08-29 12:31:52 +02:00
wm4
7bb1afb8ea demux_lavf: don't reject av:// if cache is enabled
Enabling the cache doesn't make much in this situation, but there's also
no reason not to reject it.
2014-08-27 23:12:49 +02:00
wm4
758f8f7bd4 demux: always use AVPacket
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.
2014-08-25 00:46:26 +02:00
wm4
b55e093075 demux_lavf: fix crash with unknown streams
Could happen with DVD .vob files.
2014-08-23 04:49:54 +02:00
wm4
061a5af544 demux_lavf: support new metadata update API
This Libav-invented API is of course completely different from the
FFmpeg-one. (The fun part is that I approved of both.)
2014-08-14 01:18:18 +02:00
wm4
d68a759fa4 Improve setting AVOptions
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).
2014-08-02 03:12:33 +02:00
wm4
0dd5228626 demux_lavf: don't consider EAGAIN as EOF condition
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.
2014-07-30 03:32:56 +02:00
wm4
6856d81c68 stream: hack-fix rtmp-level seeking
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.
2014-07-30 02:21:51 +02:00
wm4
d1bb1bf8af demux: fix timestamp type for seek calls
mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used
float.
2014-07-21 19:29:58 +02:00
wm4
30542456c3 demux_lavf: reverse rotation direction with new API
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
2014-07-17 00:30:03 +02:00
wm4
1301a90761 demux: add a demuxer thread
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.
2014-07-16 23:25:56 +02:00
wm4
c129e3f666 demux_lavf: don't let metadata update mess up ogm playback
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.
2014-07-14 14:34:14 +02:00
wm4
f8c2dd1b78 build: include <strings.h> for strcasecmp()
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.
2014-07-10 08:29:32 +02:00
wm4
de28876222 demux: minor simplification
Oops, should have been part of commit 37085788.
2014-07-06 19:02:21 +02:00
wm4
37085788e4 demux: minor simplification to internal API
Also some other unrelated minor changes.
2014-07-05 17:07:15 +02:00
wm4
0cc3594623 dvd: flush buffers properly on seek
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
2014-07-05 17:07:15 +02:00
wm4
338004bcfc dvd, bluray, cdda: add demux_disc containing all related hacks
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.
2014-07-05 17:07:15 +02:00
wm4
8d40b1e8ab demux: make start time a simple field
Simpler, especially for later changes.
2014-07-05 17:07:15 +02:00
wm4
7e209185f1 demux, stream: change metadata notification
(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.
2014-07-05 17:07:14 +02:00
wm4
58880c00ee demux: make replaygain per-track
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.
2014-07-05 17:07:14 +02:00
wm4
18e6d07612 demux_lavf: for now, ignore the new libavformat image demuxers
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
2014-07-05 17:07:14 +02:00
wm4
5eb9039c6b demux_lavf: support OTF fonts in Matroska
Apparently it's FFmpeg only.
2014-07-05 17:07:14 +02:00
wm4
1713dc58f1 demux_lavf: don't dump transport stream programs
Probably useless.
2014-07-05 17:07:14 +02:00
wm4
78f3ba73b9 demux_lavf: cleanup debug output
Remove unnecessary prefix, remove some messages.
2014-07-05 17:07:14 +02:00
wm4
bc29e17bcf demux_lavf: fix read_seek return value
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.)
2014-07-05 17:07:14 +02:00
wm4
a1c220cffd demux_lavf: remove unused symbol 2014-06-23 01:15:58 +02:00
wm4
98a31d5937 options: turn --idx, --forceidx into --index
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.
2014-06-13 02:05:37 +02:00