1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 00:02:13 +00:00
Commit Graph

515 Commits

Author SHA1 Message Date
wm4
5a07ce758e demux: fix a comment
Don't refer to fields that were removed.
2014-10-12 20:22:47 +02:00
wm4
26bc6b4831 Add some missing "const"s
The one in msg.c was mistakenly removed with commit e99a37f6.

I didn't actually test the change in ao_sndio.c (but obviously "ap"
shouldn't be static).
2014-10-10 13:44:08 +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
7759c182cb demux_disc: bluray: fix stream language (2)
Commit 50e131b43e 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
2014-09-30 23:38:01 +02:00
wm4
50e131b43e demux_disc: export BD/DVD audio language
This was "forgotten".
2014-09-29 18:06:45 +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
fdf40743bc demux_mkv: don't use default_duration for parsed packets
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.
2014-09-26 01:25:48 +02:00
wm4
debbff76f9 Remove mpbswap.h
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.
2014-09-25 21:32:55 +02:00
wm4
09b7956ca5 stream_cdda, demux_raw: always use s16le
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.
2014-09-25 21:32:06 +02:00
wm4
7aa933cc9e demux_mkv: get rid of MS structs
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.
2014-09-25 02:22:50 +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
fd7dde404d video: remove BITMAPINFOHEADER from internal demuxer API
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.
2014-09-25 00:59:15 +02:00
wm4
e977624d87 audio: confine demux_mkv audio PCM hack
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.
2014-09-24 23:33:21 +02:00
wm4
9ac86d9e99 audio: decouple demux and audio decoder/filter sample formats
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.)
2014-09-24 22:55:50 +02:00
wm4
81bf9a1963 audio: cleanup spdif format definitions
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).
2014-09-23 23:11:54 +02:00
wm4
b745c2d005 audio: drop swapped-endian audio formats
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.
2014-09-23 23:09:25 +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
c15957b43a ebml: warn if there are too many subelements
Seems like a good idea.
2014-09-04 19:21:19 +02:00
wm4
d9aaf78530 demux_mkv: allow up to 256 MB of extradata to make broken files work
What the flying fuck?

Unfortunately, these are already in the wild.

CC: @mpv-player/stable
2014-09-04 19:20:47 +02:00
wm4
9e512c5a98 demux: allow increasing filepos only
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.
2014-09-03 02:00:18 +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
2f537bafa5 demux: get rid of old wrapper
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.
2014-09-01 22:12:39 +02:00
wm4
8599c959fe video: initial Matroska 3D support
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.
2014-08-30 23:24:46 +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
shdown
e2ecf3d03d demux_mkv: eliminate redundant branch
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.)
2014-08-30 15:15:37 +02:00
shdown
f49099b94d demux: eliminate redundant check
pkt can't be NULL since it's initialized from ds->head, which is checked
at the beginning.
2014-08-30 15:15:37 +02:00
shdown
5bc3b7c368 demux_disc: handle new_sh_stream() fail correctly
Break the cycle on fail. Old code was checking if sh is NULL after
accessing it's fields.
2014-08-30 15:15:37 +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
cb642e7c84 player: slightly better cache underrun detection
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.
2014-08-27 23:12:49 +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
1c44db2992 demux: reset idle state on seeks 2014-08-27 23:12:49 +02:00
wm4
c7208319d3 player: better cache status on status line
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.
2014-08-27 23:12:47 +02:00
wm4
dad90f616d player: fix basic playback
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.
2014-08-27 10:59:22 +02:00
wm4
0b428e4482 player: redo how stream caching and pausing on low cache works
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.
2014-08-27 03:39:04 +02:00
wm4
a8513f8b37 demux: reduce wakeups if no cache is active
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.
2014-08-27 00:20:38 +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
c31a91230d demux: avoid unnecessary wakeups
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.
2014-08-24 13:21:32 +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
925c431ff7 demux: enable thread by default
And change the defaults for the other queue options to reduce latency.
2014-08-16 17:15:51 +02:00
wm4
b822faa6cf demux: add option to control the readahead buffer by a duration value
--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.
2014-08-16 17:10:08 +02:00
wm4
e6e3bc7cd9 demux: remove unused function 2014-08-16 17:10:08 +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
9dd160ea97 demux: reduce log spam if threading is disabled 2014-08-11 15:55:12 +02:00
wm4
1483fd443a demux: fix playback abort if --demuxer-thread is not used
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.
2014-08-07 00:34:14 +02:00
wm4
64e1132d39 demux: make track switching asynchronous
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.)
2014-08-06 20:30:47 +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