Commit Graph

1057 Commits

Author SHA1 Message Date
Niklas Haas c335e84230 video: refactor HDR implementation
List of changes:

1. Kill nom_peak, since it's a pointless non-field that stores nothing
   of value and is _always_ derived from ref_white anyway.

2. Kill ref_white/--target-brightness, because the only case it really
   existed for (PQ) actually doesn't need to be this general: According
   to ITU-R BT.2100, PQ *always* assumes a reference monitor with a
   white point of 100 cd/m².

3. Improve documentation and comments surrounding this stuff.
4. Clean up some of the code in general. Move stuff where it belongs.
2017-06-18 20:48:23 +02:00
wm4 b6d0b57e85 Drop/move img_fourcc.h
This file is an leftover from when img_format.h was changed from using
the ancient FourCCs (based on Microsoft multimedia conventions) for
pixel formats to a simple enum. The remaining cases still inherently
used FourCCs for whatever reasons.

Instead of worrying about residual copyrights in this file, just move it
into code we don't want to relicense (the ancient Linux TV code). We
have to fix some other code depending on it. For the most part, we just
replace the MP_FOURCC macro with libavutil's MKTAG (although the macro
definition is exactly the same). In demux_raw, we drop some pre-defined
FourCCs, but it's not like it matters. (Instead of
--demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
2017-06-18 15:13:45 +02:00
wm4 cd019ba602 demux_lavf: change license to LGPL (almost)
Since this demuxer is based on code by michael, this file can become
LGPL only once the mpv core becomes LGPL, and this is preparation for
it.

There were quite a lot of changes for rearranging preferred libavformat
vs. internal MPlayer demuxers, codec mappings, and filename extensions,
but all this got removed, so some of the relevant authors weren't asked.

cehoyos, who disagreed with LGPL, made a few changes in the past (mostly
codec mapping and deinterlacing related things), but all of them were
removed, mostly due to libavformat API cleanups.

adland, who could not be reached, did commit 057916ee65, but it's easy
to essentially revert the change (this is what the source changes in
this commit do), so we don't need to think about it.

Chris Welton, who could not be reached, made a simple change in commit
958c41d9b6. Fortunately, the API changed again, and his changes were
removed, so we don't need to think about this either.

There is an anonymous contribution in commit 085f35f4b4 - since this
did not introduce any original code, and the probe code was heavily
rewritten multiple times, I don't consider it relevant.
2017-06-16 15:50:00 +02:00
wm4 4e663566dd demux_lavf: by default probe info for HLS again
This switches back the --demuxer-lavf-probe-info default for HLS from
"no" to "yes".

Apparently the old default caused problems with the FFmpeg MediaCodec
wrapper. I'm not sure whether it's due to the extradata (which would not
make any sense as MediaCodec takes in Annex B formatted h264 data), or
something else. Reportedly, enabling probing fixes it though, so enable
it again.

Add disparaging comment about Google software/APIs here.
2017-06-12 22:04:44 +02:00
wm4 9f79809930 demux_lavf: disable various other special behavior if hacks disabled
This affects in particular the heuristic that enables byte seeks in some
cases with .ts input. --demuxer-lavf-hacks=no should disable this
behavior now.
2017-06-07 16:48:21 +02:00
wm4 fdd75f90ae demux_mkv: remove incorrect comment
In the previous commit, I claimed that this GUID stuff was a libavformat
extension, but that seems to be completely wrong. (LATM might be an
extension of some kind, though.)

I don't know what Microsoft calls this GUID "suffix" though. It's
generally used to wrap wav format tags and video FourCCs as GUIDs.
I guess you could grep Microsoft headers for it to find its name,
or something.
2017-06-03 23:23:35 +02:00
wm4 eae693fc46 demux_mkv: support FFmpeg A_MS/ACM extensions
Indeed, FFmpeg found a way to maximize the misery around VfW/AVI-style
muxing. It appears it can mux a number of random codecs by using random
format tags. To make this even more stranger, it has a probably custom
GUID for signaling them, although for unknown reasons this is done only
"sometimes" (judging from FFmpeg's riffenc.c).

Whatever, it's not too hard to support it. Also apparently fix the
incorrect interpretation of extended formats - there's absolutely no
reason to assume they're always PCM. Instead, check for the correct
GUIDs. Also while we're at it, move the channel mask handling also to
codec_tag.c, so all WAVEFORMATEXTENSIBLE handling is in one place. (With
the normal wav header handling strangely still in demux_mkv.c.)

The case I was looking at (aac_latm muxing) decodes now. While I'm not
entirely sure about its correctness (libavformat has a weird
special-case for SBR), it certainly doesn't try to play it as PCM,
which is much of an improvement.

The extradata mess in the demux_mkv.c A_MS/ACM code path is unfortunate
and ugly, but has less impact than refactoring all the code to make
this specific case nicer.

Did I mention yet that I hate VfW-style mkv muxing?
2017-06-03 22:49:15 +02:00
wm4 c443aa68d3 demux_mkv: vp9 alpha, second try
The parser is used to split superframes, and the decoder didn't like
when the blockadditional was duplicated on the second split packet.
2017-05-30 22:50:05 +02:00
wm4 3a448ab972 demux_mkv: fix alpha with vp9 + libvpx
The blockadditional side data gets lost because vp9 has to go through
the parser.
2017-05-30 19:26:27 +02:00
wm4 9b5e4e5715 demux_raw: drop "mp-rawvideo" use
This is an old pseudo codec to pass through the pixel format. Setup a
suitable AVCodecParameter directly instead, so the "rawvideo" codec can
be used.
2017-05-20 11:43:57 +02:00
wm4 6fe75c38d8 demux_mkv: read headers at the end of the file sorted by position
Try to read header elements stored at the end of the file in the order
of their position. (It would be nicer if mkv simply told us a range of
elements to parse, but it doesn't do that.)

This can potentially reduce seek elements, although I didn't check if
any real files trigger this. The real contribution by this change is
that it does not defer reading the CUE index if we need to seek to the
end of the file anyway. This can actually avoid 2 seeks when opening a
file and --start is used, and the file has other headers elements at the
end of the file (like tags).
2017-05-15 16:40:57 +02:00
wm4 6aba929a1b demux/stheader: change license to LGPL
All authors of the current code have agreed.

For most of its life, MPlayer used Microsoft structs like WAVEFORMATEX
to describe media content. It appears these were copied from wine in
61c5a99851. Copyright is unclear, but mpv completely removed use of
these structs anyway. (demux_mkv.c still contains code to read these
fields from a byte stream, but the struct is fully gone.)

42f97b2b820: cehoyos (who probably didn't agree with LGPL) applied a
patch by someone who agreed. It's unknown whether cehoyos modified the
patch (and thus his copyright would apply), but the changed code was
removed anyway. (The code was first moved somewhere else, then removed.)

efd53eed614: the patch author was not asked. Although the mkv_sh_sub_t
struct was later moved to stheader.h, the added field was removed
without replacement.

f6878753fbd: nick, who could not be reached, added an include guard, but
the guard was changed several times later, and it's probably not
copyrightable anyway.

afb0fd5ea17: the same nick adds a field that was later replaced and
finally removed again in 8cd6b20571.
2017-05-10 13:18:08 +02:00
wm4 d2af35aeb3 demux/packet: change license to LGPL
All contributors have agreed. In 3a43f13fce, someone who potentially
disagreed reverted a commit by someone else (restoring the original
state). This shouldn't matter for Copyright, and all of the affected
code was rewritten/removed anyway.
2017-04-21 13:34:10 +02:00
wm4 cba4efb083 ebml, matroska.h: change license to LGPL
These are covered by the analysis in commit e7e6aa3d64 too
(although there are no potential problems).
2017-04-21 13:34:10 +02:00
wm4 b78d2e6d09 demux_mkv: mention non-LGPL code 2017-04-21 13:34:10 +02:00
wm4 e7e6aa3d64 demux_mkv: change license to LGPL
Most contributors have agreed. This claims it's based on gstreamer code,
but this was LGPL at the time (and still is). Contributors whose code
was removed were not accounted for. There are still some potentially
problematic cases:

06eee1b67 is potentially the most problematic case. Most of these
changes are gone due to mpv not using BITMAPINFOHEADER anymore. Some
of the other changes are rather trivial. If someone contests this and
claims that copyrightable changes are left, the original change can
simply be reverted.

62bfae140 has only 2 lines left: a "char *name;" struct field, and a
line that prints a message. All other code was removed. The parsing code
in particular was made declarative, which replaced reading this element
explicitly (and  other elements, see 1b22101c77). I'm putting the log
message under HAVE_GPL, but I don't think the declaration is
copyrightable, or the mere concept of reading this element. Redoing the
other 2 lines of code would result in the  same program text.

d41e860ba was applied by someone who (potentially) disagreed. The patch
itself is from someone who did agree, though. It's unknown whether the
applier changed the patch. But it seems unlikely, and the change was
mostly rewritten.

50a86fcc3 all demux_mkv changes were reverted (old stdout slave mode)
3a406e94d same
2e40bfa13 the old MPlayer subtitle code was completely removed
316bb1d44 completely removed in 1cf4802c1d
87f93d9d7 same
11bfc6780 relative seeks were removed in 92ba630796
be54f4813 the corresponding demux_mkv code was removed in 5dabaaf093
efd53eed6 all internal vobsub handling is now in FFmpeg
d7f693a20 removed in f3db4b0b93
e8a1b3713 removed in 522ee6b783
cfb890259 removed, see 6b1374b203 for analysis
c80808b5a same
2017-04-21 12:21:33 +02:00
wm4 e335e33239 codec_tags: minor simplification
At least this doesn't duplicate the libavcodec PCM codec names.
2017-04-18 05:35:50 +02:00
wm4 080b930742 codec_tags: remove some more leftovers
I think these became redundant some time ago, and would only matter if
someone put QT tags into WAVEFORMATEX headers using mkv avi muxing.
2017-04-18 05:34:16 +02:00
wm4 3709ce6718 demux: estimate total packet size, deprecate packet number limits
It's all explained in the DOCS changes. Although this option was always
kind of obscure and pointless. Until it is removed, the only reason for
setting it would be to raise the static default limit, so change its
default to INT_MAX so that it does nothing by default.
2017-04-14 19:19:44 +02:00
wm4 b7b12c36af demux_lavf: disable half-working mp4 edit list support in libavcodec
Instead, enable the "old" code, which uses this for gapless info (audio
padding/trailing) only.
2017-04-07 13:12:10 +02:00
wm4 a1ad64a1c8 demux_cue: include io.h for Windows UTF-8 filesystem functions 2017-04-04 17:45:19 +02:00
wm4 9080e4d468 demux_lavf: get total duration from per-track durations as fallback
Apparently fixes youtube mp4 streams if avformat_find_stream_info() is
not called.

Keeping audio/video track and other track durations separate is for
the sake of embedded subtitle streams, where we want to include the
duration of overlong subtitle streams (I think).
2017-03-01 16:13:27 +01:00
wm4 6f8c953042 demux_lavf: skip avformat_find_stream_info() for some formats
Includes hls, mp4, mkv by default. This also avoids stupid things like
decoding at least 1 video frame per stream in the demuxer.

This also add --demuxer-lavf-probe-info to give finer control over what
happens.
2017-02-23 18:18:22 +01:00
wang-bin e285e22143 Use AV_INPUT_BUFFER_PADDING_SIZE instead of deprecated one
Signed-off-by: wm4 <wm4@nowhere>
2017-02-08 16:55:16 +01:00
wm4 92f9747c2b demux_edl: fix behavior with no init segment provided
Not that we use it...
2017-02-05 15:51:36 +01:00
wm4 8362577f8c demux_timeline: more silencing 2017-02-04 23:10:04 +01:00
wm4 58c9f1a822 demux: try not to read packets when cancelled
Essentially, this will make it abort sooner. Especially with DASH it
might avoid confusing error messages, although exact behavior depends
on timing.
2017-02-04 22:53:04 +01:00
wm4 61202bb364 ytdl_hook, edl: implement pseudo-DASH support
We use the metadata provided by youtube-dl to sort-of implement
fragmented DASH streaming.

This is all a bit hacky, but hopefully a makeshift solution until
libavformat has proper mechanisms. (Although in danger of being one
of those temporary hacks that become permanent.)
2017-02-04 22:34:38 +01:00
wm4 97680bf604 demux_timeline: move code around
Cosmetic preparation for later changes.
2017-02-04 22:19:21 +01:00
wm4 95d4c2d7f6 player: different way to auto-enable the demuxer cache
Instead of enabling it only when a stream-cache is enabled, also try to
enable it independently from that if the demuxer is marked as
is_network.

Also add some code to the EDL code, so EDLs containing network streams
are automatically cached this way.

Extend the OSD info line so that it shows the demuxer cache in this case
(more or less).

I didn't find where or whether options.rst describes how the demuxer
cache is enabled, so no changes there.
2017-02-02 18:38:16 +01:00
wm4 fb9a32977d stream: get rid of streamtype enum
Because it's kind of dumb. (But not sure if it was worth the trouble.)

For stream_file.c, we add new explicit fields. The rest are rather
special uses and can be killed by comparing the stream impl. name.

The changes to DVD/BD/CD/TV are entirely untested.
2017-02-02 18:26:58 +01:00
wm4 e13a62fc34 stream: better method signal caching, rename weird uncached_stream field
"uncached_stream" is a pretty bad name. It could be mistaken for a
boolean, and then its meaning would be inverted. Rename it.

Also add a "caching" field, which signals that the stream is a cache or
reads from a cache. This is easier to understand and more flexible.
2017-02-02 18:03:29 +01:00
wm4 738de7d3fe demux_tv: free the correct field instead of creating dangling pointer
This could potentially have caused fun crashes if the --tv-channels
option was used, and something more advanced than tv:// was used to open
it. (This code is still untested.)
2017-02-02 08:50:18 +01:00
wm4 9c12d54afa demux_mkv: passthrough BlockAdditions for libvpx alpha
Dumb but simple thing. Requires the FFmpeg libvpx decoder wrapper, as
its native decoder doesn't support alpha.
2017-01-31 14:48:10 +01:00
wm4 c178920505 demux_mkv: any reference makes a frame not a keyframe
Fixes seeking with:

https://bugs.chromium.org/p/chromium/issues/detail?id=497889

Haali also ignores the element's contents, and interprets its presence
as the block not being a keyframe. FFmpeg is going to have an equivalent
change.

I don't know yet whether the affected sample is valid - a reference
timestamp of 0 doesn't make too much sense to me.
2017-01-31 12:44:49 +01:00
wm4 63b34143a5 cue: accept lower-case cue commands
Some files appear to use them. In the sample I've seen, one field was
"Performer" instead of "PERFORMER".

This change is slightly risky, because it increases the chance of
misdetecting other formats as cue files.

Fixes #4057.
2017-01-24 08:57:51 +01:00
wm4 b14fac9afa build: replace some FFmpeg API checks with version checks
The FFmpeg versions we support all have the APIs we were checking for.
Only Libav missed them. Simplify this by explicitly checking for FFmpeg
in the code, instead of trying to detect the presence of the API.
2017-01-24 08:11:42 +01:00
wm4 73858bb0cc player: remove --stream-capture option/property
This was excessively useless, and I want my time back that was needed to
explain users why they don't want to use it.

It captured the byte stream only, and even for types of streams it was
designed for (like transport streams), it was rather questionable.

As part of the removal, un-inline demux_run_on_thread() (which has only
1 call-site now), and sort of reimplement --stream-dump to write the
data directly instead of using the removed capture code.

(--stream-dump is also very useless, and I struggled coming up with an
explanation for it in the manpage.)
2017-01-21 17:19:01 +01:00
wm4 880bf54d7e player: actually let cache readahead after opening demuxer for prefetch
Disabling cache readahead by default until at least 1 track is selected
is mainly for external files and such, where you don't want them to use
up resources until they're actually used.

It doesn't make sense to disable the cache for the demuxer opened for
prefetch. Also, it's fine to let it do that for the main file too (doing
or not doing it is of little consequence). That saves us from having to
distinguish them.
2017-01-19 08:00:19 +01:00
wm4 4e25feda0d player: change aspects of cover art handling
Cover art handling is a disgusting hack that causes a mess in all
components. And this will stay this way. This is the Xth time I've
changed cover art handling, and that will probably also continue.

But change the code such that cover art is injected into the demux
packet stream, instead of having an explicit special case it in the
decoder glue code. (This is somewhat more similar to the cover art hack
in libavformat.)

To avoid that the over art picture is decoded again on each seek, we
need some additional "caching" in player/video.c. Decoding it after each
seek would work as well, but since cover art pictures can be pretty
huge, it's probably ok to invest some lines of code into caching it.

One weird thing is that the cover art packet will remain queued after
seeks, but that is probably not an issue.

In exchange, we can drop the dec_video.c code, which is pretty
convenient for one of the following commits. This code duplicates a
bunch of lower-level decode calls and does icky messing with this weird
state stuff, so I'm glad it goes away.
2017-01-10 15:43:02 +01:00
wm4 334cad57c6 demux: rename a function
Also extend the comment on it.
2017-01-10 12:27:37 +01:00
wm4 0e8b9ed228 demux: uninline ds_get_packets()
It has only 1 caller, and is too far appart within the file. I think it
used to have multiple callers, but now it just doesn't make any sense to
keep it separate anymore.
2017-01-10 11:54:34 +01:00
wm4 42a60143c2 demux_mkv: ebml: turn an int shift into int64
This was probably the intention all along. But I honestly have no idea
what this code even does.

Due to what ebml_read_vlen_int() is used for, this is unlikely to have
mattered anyway as it rarely/never reads huge values. Which is probably
why this has worked for over a decade.
2017-01-09 13:37:04 +01:00
wm4 99a4be4127 demux_mkv: trust keyframe flags for TrueHD
TrueHD is a fucked up audio codec with extremely small frame sizes. Some
of these frames start with full headers, which are usually marked as
keyframes, and from which decoding can be started (or at least that's
what you'd expect).

So for such tracks we should probably trust the keyframe flags. Doesn't
really improve seek behavior, though.
2016-12-20 14:28:29 +01:00
wm4 3b5777d86a demux_mkv: fix seeking in some broken files
Some files have audio tracks with packets that do not have a keyframe
flag set at all. I don't think there's any audio codec which actually
needs keyframe flags, so always assume an audio packet is a keyframe
(which, in Matroska terminology, means it can start decoding from that
packet).

The file in question had these set:

| + Multiplexing application: Lavf57.56.100 at 313
| + Writing application: Lavf57.56.100 at 329

Garbage produced by garbage...

There are other such files produced by mkvmerge, though. It's not
perfectly sure whether these have been produced by FFmpeg as well
(mkvmerge often trusts the information in the source file, even if it's
wrong - so other samples could have been remuxed from FFmpeg).

Fixes #3920.
2016-12-19 21:29:46 +01:00
wm4 3eceac2eab Remove compatibility things
Possible with bumped FFmpeg/Libav.

These are just the simple cases.
2016-12-07 19:53:11 +01:00
wm4 ceb2e1026d demux, stream: add option to prevent opening referenced files
Quite irresponsibly hacked together. Sue me.
2016-12-04 23:15:31 +01:00
wm4 47f974a395 demux_lavf: blacklist ffm (ffserver) 2016-12-04 13:18:48 +01:00
wm4 79d99bd264 demux_mkv: distinguish mp2 and mp3
demux_mkv.c has returned mp3 for mp2 since the initial commit. Normally
not a problem.
2016-11-23 15:57:35 +01:00
wm4 b787a4121a demux_timeline: always signal new segment after a seek
This is needed to put the decoders into the correct state. In
particular, decoders will not initialize the current segment without
this flag. The intention of not setting the flag for seeks within the
segments were to avoid costly decoder reinits, but it seems this is
better handled explicitly in the decoder wrappers.
2016-11-09 16:44:06 +01:00
Niklas Haas c676c31815 demux: expose demuxer colorimetry metadata to player
Implementation-wise, the values from the demuxer/codec header are merged
with the values from the decoder such that the former are used only
where the latter are unknown (0/auto).
2016-11-08 19:16:26 +01:00
Niklas Haas 81ceb7b6a5 demux_mkv: parse colorimetry metadata
Matroska actually has lots of colorimetry metadata that video tracks can
use, including mastering metadata (HDR signal peak) etc.

This commit adds the EBML definitions and parses the most basic fields.
Note that nothing uses these fields yet, this commit is just adding the
necessary parsing and infrastructure.
2016-11-08 19:16:24 +01:00
wm4 5838322975 demux: improve buffer estimation in a corner case
This deals with the estimation of buffered packets, which is used mostly
for display, but also things like pausing on low buffer levels.

If a stream is fully EOF (no more packets), we don't want to include it
in the total buffer amount. This also means we should make ds->eof less
flaky and more stable, so don't reset it in ds_get_packets() (this
function reset ds->eof just to retrigger a packet read attempt - we can
have this slightly simpler). This somewhat fixes buffering display when
e.g. issuing a refresh seek after re-enabling audio/video when playing
with subtitles only.
2016-11-01 16:25:40 +01:00
Uoti Urpala 18681a7dd2 demux_mkv: fix ordered chapter sources with ordered editions
Commit f72a900892 (and others) added support for ordered editions that
recursively refer to other ordered editions. However, this recursion
code incorrectly activated if the source files had ordered chapters
even if the main file only wanted to use them as raw video, resulting
in broken timeline info overall.

Ordered chapters can specify a ChapterSegmentEditionUID value if they
want to use a specific edition from a source file. Otherwise the
source is supposed to be used as a raw video file. The code checked
demuxer->matroska_data.num_ordered_chapters for an opened source file
to see whether it was using a recursive ordered edition, but demux_mkv
could enable a default ordered edition for the file using the normal
playback rules even if the main file had not specified any
ChapterSegmentEditionUID. Thus this incorrectly enabled recursion if a
source file had a default edition using ordered chapters. Check
demuxer->matroska_data.uid.edition instead, and ensure it's never set
if a file is opened without ChapterSegmentEditionUID.

Also fix what seems like a memory leak in demux_mkv.c.

Signed-off-by: wm4 <wm4@nowhere>
2016-10-22 18:45:06 +02:00
wm4 3a78eefc88 demux_mkv: don't recursively resolve timeline for opened reference files
Instead, resolve all references and so on in the top-level timeline.
2016-10-22 17:17:04 +02:00
wm4 61a51c57a9 demux: don't try to refresh unselected streams
This could cause nonsensical queue overflow warnings, but was otherwise
probably harmless.
2016-10-21 17:11:26 +02:00
Aman Gupta 7684483052 demux_lavf: set title on hearing and visual impaired tracks 2016-10-20 14:56:00 +02:00
wm4 a2fa0d0b68 demux_lavf: don't accidentally enable edit list crap on Libav
You really don't get a break from all the multiple bullshit.
2016-10-18 19:14:15 +02:00
wm4 b86a2316df demux_lavf: "support" mov edit lists and log errors if used
FFmpeg recently got "support" for mov edit lists. This is a terrible
hack that will fail completely at least with some decoders (in
particular wrappers for hardware decoding might be affected). As such it
makes no point to pretend they are supported, even if we assume that the
"intended" functionality works, that there are no implementation bugs
(good luck with all that messy code added to the already huge mov
demuxer), and that it covers enough of the mov edit list feature to be
of value.

So log an error if the FFmpeg code for mov edit lists appears to be
active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list
segments on non-key frame boundaries.

In the first place, FFmpeg committed this only because Google wanted it
in, and patch review did not even pick up obvious issues. (Just look how
there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.)

We still pass the new packet flag to the decoders (av_common.c change),
which means we "support" FFmpeg's edit list code now. (Until it breaks
due to FFmpeg not caring about all the details.)
2016-10-18 16:57:02 +02:00
wm4 88f10ec84f player: fix instant subtitle refresh on track switches
When switching a subtitle track, the subtitle wasn't necessarily
updated, especially when playback was paused.

Some awfully subtle and complex interactions here.

First off (and not so subtle), the subtitle decoder will read packets
only on explicit update_subtitles() calls, which, if video is active, is
called only when a new video frame is shown. (A simply video frame
redraw doesn't trigger this.) So call it explicitly. But only if
playback is "initialized", i.e. not when it does initial track selection
and decoder init, during which no packets should be read.

The second issue is that the demuxer thread simply will not read new
packets just because a track was switched, especially if playback is
paused. That's fine, but if a refresh seek is to be done, it really
should do this. So if there's either 1. a refresh seek requested, or 2.
a refresh seek ongoing, then read more packets.

Note that it's entirely possible that we overflow the packet queue with
this in unpredicated weird corner cases, but the queue limit will still
be enforced, so this shouldn't make the situation worse.
2016-09-24 19:57:19 +02:00
wm4 04320d26eb stream, demux, config: remove some dead/unneeded option-related code
This has all been made unnecessary recently. The change not to copy the
global option struct in particular can be made because now nothing
accesses the global options anymore in the demux and stream layers.

Some code that was accidentally added/changed in commit 5e30e7a0 is also
removed, because it was simply committed accidentally, and was never
used.
2016-09-09 17:54:57 +02:00
wm4 5324fb731f tv: remove weird option parsing stuff
Mostly untested.
2016-09-09 17:54:35 +02:00
wm4 d4d8b3a4fc demux: do not access global options
Don't access MPOpts directly, and always use the new m_config.h
functions for accessing them in a thread-safe way.

The goal is eventually removing the mpv_global.opts field, and the
demuxer/stream-layer specific hack that copies MPOpts to deal with
thread-safety issues.

This moves around a lot of options. For one, we often change the
physical storage location of options to make them more localized,
but these changes are not user-visible (or should not be). For
shared options on the other hand it's better to do messy direct
access, which is worrying as in that somehow renaming an option
or changing its type would break code reading them manually,
without causing a compilation error.
2016-09-06 20:09:56 +02:00
wm4 9f0e7bb998 input, demux_tv: remove some older option access methods 2016-09-06 20:09:44 +02:00
wm4 e66c098228 demux_mkv: don't crash if --ordered-chapters-files fails
It just crashed.
2016-09-06 20:09:18 +02:00
wm4 bc97d60542 demux: close underlying stream if it's fully read anyway
This is for text subtitles. libavformat currently always reads text
subtitles completely on init. This means the underlying stream is
useless and will consume resources for various reasons (network
connection, file handles, cache memory).

Take care of this by closing the underlying stream if we think the
demuxer has read everything. Since libavformat doesn't export whether it
did (or whether it may access the stream again in the future), we rely
on a whitelist. Also, instead of setting the stream to NULL or so, set
it to an empty dummy stream. This way we don't have to litter the code
with NULL checks.

demux_lavf.c needs extra changes, because it tries to do clever things
for the sake of subtitle charset conversion.

The main reason we keep the demuxer etc. open is because we fell for
libavformat being so generic, and we tried to remove corresponding
special-cases in the higher-level player code. Some of this is forced
due to ass/srt mkv/mp4 demuxing being very similar to external text
files. In the future it might be better to do this in a more
straight-forward way, such as reading text subtitles into libass and
then discarding the demuxer entirely, but for aforementioned reasons
this could be more of a mess than the solution introduced by this
commit.

Probably fixes #3456.
2016-08-26 13:34:52 +02:00
wm4 4121016689 player: don't directly access demuxer->stream
Cleaner and makes it easier to change the underlying stream.

mp_property_stream_capture() still directly accesses it directly via
demux_run_on_thread(). This is evil, but still somewhat sane and is not
getting into the way here.

Not sure if I got all field accesses.
2016-08-26 13:33:38 +02:00
wm4 74d4073771 demux: demote packet queue overflow to a warning
It doesn't necessarily have to mean anything bad.

We're still too lazy to provide any more detailed information (e.g.
whether this happened to likely bad interleaving, excessive amount of
packets like with some ASS subs, or that the readahead user option is
limitted by the packet queue size).
2016-08-22 12:10:55 +02:00
wm4 2fbd1d3610 demux: change fps field to double
Because why not.
2016-08-19 15:00:58 +02:00
wm4 05e4df3f0c video/audio: always provide "proper" timestamps to libavcodec
Instead of passing through double float timestamps opaquely, pass real
timestamps. Do so by always setting a valid timebase on the
AVCodecContext for audio and video decoding.

Specifically try not to round timestamps to a too coarse timebase, which
could round off small adjustments to timestamps (such as for start time
rebasing or demux_timeline). If the timebase is considered too coarse,
make it finer.

This gets rid of the need to do this specifically for some hardware
decoding wrapper. The old method of passing through double timestamps
was also a bit questionable. While libavcodec is not supposed to
interpret timestamps at all if no timebase is provided, it was
needlessly tricky. Also, it actually does compare them with
AV_NOPTS_VALUE. This change will probably also reduce confusion in the
future.
2016-08-19 14:59:30 +02:00
wm4 1e53fc3a15 demux_lavf: don't report start time for ogg
Better with ogg shoutcast streams. These have PTS resets on each
playlist item, so the PTS would usually reset to some negative value.
2016-08-18 21:03:01 +02:00
wm4 12e251c29e demux: fix undefined behavior with ogg metadata update
When an ogg track upodates metadata, we have to perform a complicated
runtime update due to the demux.c architecture. A detail was broken and
an array was allocated with the previous number of streams, which
usually led to invalid memory write accesses at least on the first
update.

See github commit comment on commit b9ba9a89.
2016-08-16 10:48:54 +02:00
wm4 9d2bcd2ef9 demux: minor cleanup to replaygain error handling
If the PEAK tag is invalid, return an error.

Make the error signalling conventions more uniform by strictly returning
a negative value on error, and treating >=0 as success.
2016-08-13 15:09:03 +02:00
wm4 e392d6610d demux: make ALBUM replaygain tags optional
IF they're missing, use the TRACK ones instead. See #3405.
2016-08-13 15:06:45 +02:00
wm4 78d808c5bd audio: log replaygain values in af_volume instead demuxer
The demuxer layer usually doesn't log per-stream information, and even
the replaygain information was logged only if it came from tags.

So log it in af_volume instead.
2016-08-13 15:06:07 +02:00
wm4 b9ba9a898a demux: add per-track metadata
...and ignore it. The main purpose is for retrieving per-track
replaygain tags. Other than that per-track tags are not used or accessed
by the playback core yet.

The demuxer infrastructure is still not really good with that whole
synchronization thing (at least in part due to being inherited from
mplayer's single-threaded architecture). A convoluted mechanism is
needed to transport the tags from demuxer thread to user thread. Two
factors contribute to the complexity: tags can change during playback,
and tracks (i.e. struct sh_stream) are not duplicated per thread.

In particular, we update the way replaygain tags are retrieved. We first
try to use per-track tags (common in Matroska) and global tags
(effectively formats like mp3). This part fixes #3405.
2016-08-12 21:39:32 +02:00
wm4 896a97c2e2 demux: do not add packets between refresh seek requested and done
Could cause strange issues on seeks or track switches, was only visible
as race condition.
2016-08-08 11:13:43 +02:00
wm4 39ae261cc5 demux_timeline: enable refresh seeks in some situations
Play a trick to make the packet pos field monotonically increasing over
segment boundaries if the source demuxers return monotonically
increasing pos values. This allows the demuxer to uniquely identify
packets with the pos field, and can do refresh seeks using that.

Normally, the packet pos field is used as a fallback for determining the
playback position if the demuxer returns no proper duration. But
demux_timeline.c always will, and the packet pos fields usually make no
sense in relation to the returned file size anyway if the timeline
source demuxers originate from separate streams.
2016-08-07 13:53:34 +02:00
wm4 78bcbe289e demux: make refresh seek handling more generic
Remove the explicit whitelisting of formats for refresh seeks. Instead,
check whether the packet position is somewhat reliable during demuxing.
If there are packets without position, or the packet position is not
monotonically increasing, then do not use them for refresh seeks.

This does not make sure of some requirements, such as deterministic
seeks. If that happens, mpv will mess up a bit on stream switching.

Also, add another method that uses DTS to identify packets, and prefer
it to the packet position method. Even if there's a demuxer which
randomizes packet positions, it hardly can do that with DTS. The DTS
method is not always available either, though. Some formats do not have
a DTS, and others are not always strictly monotonic (possibly due to
libavformat codec parsing and timestamp determination issues).
2016-08-06 19:28:41 +02:00
wm4 7fd3dbcd52 demux: fix a minor race condition
If the packet read function returns, and EOF was detected, and a seek
was issued in the meantime, then don't use the EOF result. The seek will
be processed later, and reset the EOF state anyway.

The main effect is probably that we don't return EOF to the decoders
(which the playback core resets before issuing the seek), and that we
won't log an EOF message.

Not important, but slightly more correct.
2016-08-06 17:48:45 +02:00
wm4 d41f0a54b0 player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.

A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.

Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.

One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.

Should mostly fix #3392.
2016-08-06 15:47:04 +02:00
wm4 0b144eac39 audio: use --audio-channels=auto behavior, except on ALSA
This commit adds an --audio-channel=auto-safe mode, and makes it the
default. This mode behaves like "auto" with most AOs, except with
ao_alsa. The intention is to allow multichannel output by default on
sane APIs. ALSA is not sane as in it's so low level that it will e.g.
configure any layout over HDMI, even if the connected A/V receiver does
not support it. The HDMI fuckup is of course not ALSA's fault, but other
audio APIs normally isolate applications from dealing with this and
require the user to globally configure the correct output layout.

This will help with other AOs too. ao_lavc (encoding) is changed to the
new semantics as well, because it used to force stereo (perhaps because
encoding mode is supposed to produce safe files for crap devices?).
Exclusive mode output on Windows might need to be adjusted accordingly,
as it grants the same kind of low level access as ALSA (requires more
research).

In addition to the things mentioned above, the --audio-channels option
is extended to accept a set of channel layouts. This is supposed to be
the correct way to configure mpv ALSA multichannel output. You need to
put a list of channel layouts that your A/V receiver supports.
2016-08-04 20:49:20 +02:00
Eric Toombs 27b59e1940 demux_raw: s16be support was missing due to small typo
Signed-off-by: wm4 <wm4@nowhere>
2016-07-30 00:05:40 +02:00
wm4 d60db967bd demux_lavf: remove subtitle seeking special-case
It used not to work - but now it apparently does. Not sure when that got
fixed in FFmpeg, but there's no longer a reason to keep this hack.

This also gets rid of the check for the read_seek2 field, which is not
part of the public API.
2016-07-24 18:41:55 +02:00
wm4 fb8deb69a6 libarchive: unify entry iteration between stream/demux layers
No really good reason to duplicate this.
2016-07-18 12:44:56 +02:00
wm4 6e45e1de77 demux_timeline: restore mkv edition switching 2016-07-14 18:26:58 +02:00
wm4 a30e727266 demux_mkv: support Matroska webvtt
They're different from the Google/WebM subtitle types, and use a new
codec ID.

Fixes #3247.
2016-06-14 16:43:07 +02:00
wm4 aeb3df0e2c demux_lavf: assume fully read files (subtitles) are always seekable
Since the libavformat API is crap, we have to apply tons of heuristics
to check whether seeking will work. (No, checking it at seek time isn't
going to work either, because if a seek fails, the demuxer will be in an
undefined state. Because the libavformat API is crap.)
2016-06-08 12:02:06 +02:00
wm4 68796fbdf5 demux: fix memory leak when loading of ordered chapter file is aborted 2016-06-07 21:56:09 +02:00
wm4 c06a92e09e demux_edl: adjust warnings and variable names
Don't warn against unknown sourve length if the segment length is
explicitly provided.

Rename "len" to "end_time", because that's what it actually is.
2016-05-23 15:23:27 +02:00
wm4 035297212a demux_mkv: better resync behavior for broken google-created webms
I've got a broken webm that fails to seek correctly with "--start=0".
The problem is that every index entry points to 1 byte before cluster
start (!!!). demux_mkv tries to resync to the next cluster, but since it
already has read 2 bytes with ebml_read_id(), it doesn't get the first
cluster, but the following one. Actually, it can be any amount of bytes
from 1-4, whatever happens to look valid at this essentially random byte
position.

Improve this by resyncing from the original position, instead of the one
after the EBML element ID has been attempted to be read.

The file shows the following headers:

| + Muxing application: google at 177
| + Writing application: google at 186

Indeed, the file was downloaded with youtube-dl. I can only guess that
Google got it completely wrong.
2016-05-21 16:39:44 +02:00
wm4 26b6d74484 demux_playlist: recognize m3u8 as playlist extension
Whatever. As mentioned in #3154.
2016-05-17 18:18:00 +02:00
wm4 2f8b4dd480 demux_lavf: fix a minor memory leak 2016-05-08 13:24:22 +02:00
wm4 503dada42f demux_playlist: read directories recursive
demux_playlist.c recognizes if the source stream points to a directory,
and adds its directory entries. Until now, only 1 level was added.
During playback, further directory entries could be resolved as
directory paths were "played".

While this worked fine, it lead to frequent user confusion, because
playlist resuming and other things didn't work as expected. So just
recursively scan everything.

I'm unsure whether it's a good fix, but at least it gets rid of the
complaints. (And probably will add others.)
2016-04-18 22:08:44 +02:00
wm4 f4142ab9ad demux_mkv: fix seeking with files that miss the first index entry
Now it will always be able to seek back to the start, even if the index
is sparse or misses the first entry.

This can be achieved by reusing the logic for incremental index
generation (for files with no index), and start time probing (for making
sure the first block is always indexed).
2016-04-12 15:41:44 +02:00
wm4 c971220cdd demux_lavf, ad_lavc, ad_spdif, vd_lavc: handle FFmpeg codecpar API change
AVFormatContext.codec is deprecated now, and you're supposed to use
AVFormatContext.codecpar instead.

Handle this for all of the normal playback code.

Encoding mode isn't touched.
2016-03-31 22:00:45 +02:00
wm4 38c813c919 demux_lavf: remove old MicroDVD frame timing guessing
This was changed in 2014, so I suppose users will usually have a FFmpeg
release which includes the corresponding upstream change. If not, well
too bad for those MicroDVD-obsessed users.

Also don't try to retrieve the default framerate as exported by the
demuxer, and instead hardcode it and trust it won't ever change. this
avoids that we have to deal with a larger mess in the codecpar commit.
2016-03-31 21:46:23 +02:00
wm4 0e7bdce907 demux_lavf: remove some old framerate guessing
I don't trust it one bit, and it's a bother with the codecpar change.
If it turns out to be important for some file formats, it could be
added back (or FFmpeg fixed).
2016-03-31 21:39:01 +02:00
wm4 1107a070e4 Revert "demux_mkv: don't trust DefaultDuration for audio"
This reverts commit 503c6f7fd6.

There are situations where some decoders (MF apparently) always require
a timestamp. Also, this makes bitrate estimation more granular than
necessary. It seems it's better to try to detect fiels with broken
default durations explicitly instead. Or maybe something should be
added to smooth audio timestamps after filters.
2016-03-30 11:34:35 +02:00
wm4 57506b27ed cache: use a single STREAM_CTRL for various cache info
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)

Since this includes the cache speed, this should fix #3003.
2016-03-29 11:29:52 +02:00
wm4 dafafc90de demux_timeline: request subtitle prefetching on crossing segments
SEEK_HR is interpreted by demux_mkv.c, and enables subtitle preroll by
prefetching additional subtitle pakcets which might overlap with the
seek destination. This should make the case work when segment boundaries
fall into the middle of subtitle events.

This still usually leaves a flicker of at least 1 frame on start,
because dec_sub.c does not ensure that enough subtitles are read before
rendering after a segment switch. (Probably a WONTFIX.)
2016-03-25 17:27:02 +01:00
wm4 fd57503890 demux_timeline: skip decoder reinit when seeking to same segment
"Normal" seeks, which don't actually switch the segment, do not need to
reinit the decoders.
2016-03-17 21:32:41 +01:00
wm4 d8b27ee4de demux: remove pausing mechanism
This is simpler, because it doesn't have to wait from both threads for
synchronization.

Apart from being simpler/cleaner, this serves vague plans to stop/start
the demuxer thread itself automatically on demand (for the purpose of
reducing unneeded resource usage).
2016-03-10 00:08:04 +01:00
wm4 953ff6b390 demux: replace demux_pause/demux_unpause with demux_run_on_thread
This pause stuff is bothersome and is needed only for a few corner-
cases. This commit removes it from the demuxer public API and replaces
it with a demux_run_on_thread() function and refactors the code which
needed demux_pause(). The next commit will change the implementation.
2016-03-09 23:55:34 +01:00
wm4 5c1fe2a4f3 demux: delay bitrate calculation on packets with unknown timestamps
Commit 503c6f7f essentially removed timestamps from "laces" (Block sub-
divisions), which means many audio packets will have no timestamp.
There's no reason why bitrate calculation can't just delayed to a point
when the next timestamp is known.

Fixes #2903 (no audio bitrate with mkv files).
2016-03-05 13:08:38 +01:00
wm4 fb2f8abaaa demux_null: fix segfault with --cache enabled
stream->info can be NULL if it's the cache wrapper. To be fair,
stream->info is considered private API anyway. So don't access it, but
check the URL instead.
2016-03-05 00:56:55 +01:00
wm4 cda0dc9070 demux_mkv: correctly export unknown packet durations
Instead of just setting the duration to 0.
2016-03-05 00:12:58 +01:00
wm4 9972847265 demux: add null demuxer
It's useless, but can be used for fancy --lavfi-complex nonsense.
2016-03-04 23:51:55 +01:00
wm4 a6f8a6977e demux_timeline: set correct seekable flags
Tricky misleading crap.

Fixes #2898.
2016-03-03 15:31:44 +01:00
wm4 a4e29e67f9 demux_lavf: don't copy cover art picture
Use the AVPacket refcounting mechanism instead.
2016-03-03 11:04:32 +01:00
wm4 a19307d598 Revert "demux_mkv: pretend waveext channel layouts by default"
This reverts commit af66fa8fa5.

The reverted commit caused AVCodecContext.channel_layout to be set,
while requesting stereo downmix will make libavcodec output a stupid
message:

  ac3: Channel layout '5.1' with 6 channels does not match specified number of channels 2: ignoring specified channel layout

The same happens with --demuxer=lavf (without this change too).

I'm not quite sure what acrobatics are required to shut up libavcodec,
but for now revert the commit. It was a rather minor, almost cosmetic
issue, which I consider less important than clean CLI terminal output.
2016-03-02 22:28:32 +01:00
wm4 af66fa8fa5 demux_mkv: pretend waveext channel layouts by default
Not much of an impact, just makes output of the "channels" "track-list"
sub-property nicer.
2016-02-29 21:00:18 +01:00
wm4 92ba630796 demux: remove relative seeking
Ever since a change in mplayer2 or so, relative seeks were translated to
absolute seeks before sending them to the demuxer in most cases. The
only exception in current mpv is DVD seeking.

Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR
is kept, because it's sometimes slightly useful for seeking in things
like transport streams. (And maybe mkv files without duration set?)

DVD seeking is terrible because DVD and libdvdnav are terrible, but
mostly because libdvdnav is terrible. libdvdnav does not expose seeking
with seek tables. (Although I know xbmc/kodi use an undocumented API
that is not declared in the headers by dladdr()ing it - I think the
function is dvdnav_jump_to_sector_by_time().) With the current mpv
policy if not giving a shit about DVD, just revert our half-working seek
hacks and always use dvdnav_time_search(). Relative seeking might get
stuck sometimes; in this case --hr-seek=always is recommended.
2016-02-28 19:28:34 +01:00
wm4 08dbaf1dcc demux_timeline: slightly improve reported file format
Report the underlying demuxer's format. Since there can be many demuxers
participating, pick the "main" segment.
2016-02-25 22:49:50 +01:00
wm4 b654aaea0a demux: avoid lost wakeup on queue overflow
If a stream is marked as EOF (due to no packets found in reach), then we
need to wakeup the decoder. This is important especially if no packets
are found at the start of the file, so the A/V sync logic actually
starts playback, instead of waiting for packets that will never come.
(It would randomly start playback when running the playback loop due to
arbitrary external events like user input.)
2016-02-24 22:04:18 +01:00
wm4 503c6f7fd6 demux_mkv: don't trust DefaultDuration for audio
It's used to interpolate timestamps for sub-packets ("block laces").
It's occasionally broken, and not really needed by us.
2016-02-24 21:48:24 +01:00
wm4 f3549ff76a demux_mkv: fix opus gapless behavior (2)
Commit 943f76e6, which already tried this, was very stupid: it didn't
actually override the samplerate for Opus, but overrode it for all
codecs other than Opus. And even then, it failed to use the overridden
samplerate. (Sigh...)
2016-02-22 20:46:28 +01:00
wm4 0e298bb95a demux_lavf: adjust seeks by maximum codec delay
Fixes relative seeks. Without this, a seek back could skip so much data
that the seek would effectively jump forward. (Or insert silence for
files with video.)

There's the question whether the frontend should do this instead (by
using information from the decoders), but for now this seems more
proper.

demux_mkv.c does this already, sort of.

libavformat doesn't for seeks in .ogg (aka .opus), but might be doing it
for mkv. Seems to be a mess as well.
2016-02-22 20:21:13 +01:00
wm4 943f76e6ce demux_mkv: add hack to fix opus gapless behavior
I think the conclusion is that AV_PKT_DATA_SKIP_SAMPLES is misdesigned
(at least for some formats), and an alternative mechanism using
durations would be better. (Combining it with a proper timebase would
keep sample-accuracy.)
2016-02-21 16:26:23 +01:00
wm4 297fdcc095 demux_timeline: fix nested timelines
You can e.g. reference ordered chapters or other EDL files in EDLs.
There were some bugs left which broke this in some cases.
2016-02-20 16:22:15 +01:00
wm4 ce0b99314b demux_timeline: cosmetics: move a function
Gets rid of a forward declaration.
2016-02-16 21:06:02 +01:00
wm4 3c3cd0c540 demux_timeline: disable cache for inactive segments
This is achieved indirectly by deslecting all streams for the non-
current segment (and if the segment doesn't share the demuxer with the
currently active one).

Restores functionality added with commit 46bcdb70.
2016-02-16 21:05:18 +01:00
wm4 0af5335383 Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.

The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.

The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)

To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
  concatenating files with completely different codecs for the sake
  of EDL (which also uses the timeline infrastructure). A "lighter"
  approach would try to make use of decoder mechanism to update e.g.
  the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
  normal playback core mechanisms like hr-seek, but now the playback
  core doesn't need to care about these things.

These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)

There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.

Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 21:04:07 +01:00
wm4 65f9af1d40 packet: cosmetics: reorder fields 2016-02-15 20:39:17 +01:00
wm4 fa821de8b2 demux_mkv: support channel layout in VfW muxed PCM
Fixes #2820.
2016-02-14 12:42:24 +01:00
wm4 dccda5189d demux: reduce verbosity
Tired of seeing all these useless pseudo-demuxers in the log.
2016-02-11 20:54:44 +01:00
Jan Ekström a75f40e0d7 demux_mf: only use glob() if it is available
The only other place where glob() is used is windows-specific and
for windows mpv includes its own glob wrapper.
2016-02-10 21:29:25 +01:00
wm4 a18aa9e632 demux_mkv: allow negative timestamps
FFmpeg can generate such files. It's unclear whether they're allowed by
Matroska. mkvinfo shows packet timestamps in both forms (one of them
must be a bug), and at last libavformat's demuxer treats timestamps
as signed.
2016-01-27 21:08:53 +01:00
wm4 8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
wm4 6fafdd5142 demux: remove a minor difference between threaded/unthreaded modes
This difference was unnecessary.
2016-01-19 14:21:02 +01:00
wm4 ae4b0f3f7c demux: fix leaking closed captions packets with unselected sub stream
Calling demux_add_packet() unconditonally frees the packet if the stream
is not selected.
2016-01-19 14:19:50 +01:00
Aman Gupta f9cefbfec4 vd_lavc: feed A53_CC side data packets into the demuxer for eia_608 decoding 2016-01-18 12:14:52 -08:00
wm4 46bcdb7039 demux: disable stream cache if no tracks are selected
Slightly helps with timeline stuff, like EDL. There is no need to keep
network (or even just disk I/O) busy for all segments at the same time,
because 1. the data won't be needed any time soon, and 2. will probably
be discarded anyway if the stream is seeked when segment is resumed.

Partially fixes #2692.
2016-01-18 18:43:55 +01:00
wm4 5986861c9c demux: remove unused function 2016-01-18 18:43:55 +01:00
wm4 f15a79d144 demux: fix interleaved subtitle reading in unthreaded mode
Meh. Why are there even two code paths.

This adds an additional check; the big function is only moved.
2016-01-18 18:43:18 +01:00
wm4 488f569d99 demux: unify codepaths for threaded/unthreaded track switching
Well, not that the unthreaded case is important, or even works properly.
2016-01-18 18:40:35 +01:00
wm4 2bbed80135 demux: remove unused flag 2016-01-18 18:40:05 +01:00
wm4 0ed170ec0b sub: fix memory leaks
demux_lavf.c leaked the complete subtitle data if it was put through
iconv.

lavc_conv.c leaked AVCodecContext.subtitle_header (set by libavcodec),
which is fixed by using avcodec_free_context(). It also leaked the
subtitle that was decoded last.
2016-01-18 11:46:28 +01:00
Oliver Freyermuth 0c9b655477 demux_lavf: update metadata with information from AV_PROGRAM on switch.
Need to trigger demux_changed() manually since metadata
of tracks and streams is not changed, but demuxer-metadata
is still changed on program switch.
2016-01-14 00:36:53 +01:00
wm4 a4cdf1a727 demux_lavf: fix charset conversion with UTF-16 subtitles
UTF-16 subtitles are special in that they are usually read by
libavformat directly, even though they are not in UTF-8. This is
explicitly handled convert_charset() and skips conversion to UTF-8.

There was a bug due to not resetting the file position: if conversion
happens, the actual stream is replaced with a memory stream containing
the converted data, but if conversion is skipped, the original stream
with the wrong file position is kept.

Fix by always opening a memory stream. (We _could_ seek back, but there
is a slight possibility of additional failure due to unseekable
streams.)

Also, don't enter conversion if the subtitle is detected as UTF-8
either.

Fixes #2700.
2016-01-12 23:50:01 +01:00
wm4 671df54e4d demux: merge sh_video/sh_audio/sh_sub
This is mainly a refactor. I'm hoping it will make some things easier
in the future due to cleanly separating codec metadata and stream
metadata.

Also, declare that the "codec" field can not be NULL anymore. demux.c
will set it to "" if it's NULL when added. This gets rid of a corner
case everything had to handle, but which rarely happened.
2016-01-12 23:48:19 +01:00
Dmitrij D. Czarkoff ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4 8135838018 player: eliminate demux_get_next_pts()
This slightly changes behavior when seeking with external audio/subtitle
tracks if transport streams and mpeg files are played, as well as
behavior when seeking with such external tracks.

get_main_demux_pts() is evil because it always blocks on the demuxer (if
there isn't already a packet queued). Thus it could lock up the player,
which is a shame because all other possible causes have been removed.

The reduced "precision" when seeking in the ts/mpeg cases (where
SEEK_FACTOR is used, resulting in byte seeks instead of timestamp seeks)
might lead to issues. We should probably drop this heuristic. (It was
introduced because there is no other way to seek in files with PTS
resets with libavformat, but its value is still questionable.)
2016-01-11 20:36:23 +01:00
fwr a655432bbe demux_lavf: re-enable codepage autodetection for .ass
There are a lot of incorrectly encoded subtitles with .ass extension
and non-ass subtitles (srt, ssa) with such extension, so we need to
try codepage detection even for .ass.

Signed-off-by: wm4 <wm4@nowhere>
2016-01-04 19:19:00 +01:00
Kagami Hiiragi 492e3deb95 demux_mkv: skip EBML void elements
EBML_ID_VOID might occur at any level, see:
https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown
This change prevents "Corrupt file detected" errors on completely valid
files.
2015-12-29 20:39:34 +01:00
wm4 b47bf06f97 sub: change how subtitles are read
Slightly change how it is decided when a new packet should be read.
Switch to demux_read_packet_async(), and let the player "wait properly"
until required subtitle packets arrive, instead of blocking everything.
Move distinguishing the cases of passive and active reading into the
demuxer, where it belongs.
2015-12-29 01:35:52 +01:00
wm4 4c1deb680d sub: do charset conversion in demux_lavf.c
Just so I can remove a few lines from dec_sub.c.

This is slightly inelegant, as the whole subtitle file has to be read
into memory, converted at once in memory, and then provided to
libavformat in an awkward way by creating a memory stream instead of
using demuxer->stream. It also won't be possible to force the charset on
subtitles in binary container formats - but this wasn't exposed before,
and we just hope this won't be ever needed. (One motivation was fixing
broken files with non-UTF8 muxed.) It also won't be possible to change
the charset on the fly, but this was not exposed either.
2015-12-28 23:23:30 +01:00
wm4 97d50538cd demux_lavf: prepare for using wrapper stream instance
Preparation for the next commit.
2015-12-28 23:22:58 +01:00
wm4 d9f8b9f7b2 demux_mkv: adjust subtitle preroll defaults
Always preroll by default if the cue (index) information indicates
overlapping subtitles.

Increase the amount of maximum data it will skip to get such subtitles
to 10 seconds. Since the index information can reliably tell whether
reading earlier is needed, the maximum should be rarely actually used,
thus we can set it high. On the other hand, the "old" prerolling
mechanism always has to skip the maximum amount of data; thus the method
using the index gets its own option to control the maximum amount of
data to skip.

(As more and more files With newer mkvtoolnix versions are muxed, and
with this new and hopefully sane default established, these options can
probably be removed in the future.)
2015-12-27 02:13:06 +01:00
wm4 ce8524cb47 sub: cache subtitle state per track instead of per demuxer stream
Since commit 6d9cb893, subtitle state doesn't survive timeline switches
(ordered chapters etc.). So there is no point in caching the state per
sh_stream anymore (which would be required to deal with multiple
segments). Move the cache to struct track.

(Whether it's worth caching the subtitle state just for the situation
when subtitle tracks get reselected is questionable. But for now, it's
nice to have the subtitles immediately show up when reselecting a
subtitle.)
2015-12-26 18:32:27 +01:00
wm4 25497226cf demux_mf: fix previous commit
It was total crap.
2015-12-23 21:58:01 +01:00
wm4 f9ba1a3ddf demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)

Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.

Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).

This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 21:52:16 +01:00
Aman Gupta d5274d9298 demux_lavf: rename to handle_new_stream to clarify intent 2015-12-22 13:00:05 +01:00
Aman Gupta 5360baa49e demux_lavf: make trace output for mp_seek easier to digest
Signed-off-by: wm4 <wm4@nowhere>
2015-12-21 22:29:38 +01:00
wm4 f2187de8bb demux_disc: fix aspect ratio retrieval (again)
Commit 127da161 was not properly tested either - it did nothing, and
just made it use the video bitstream aspect ratio determined by
libavformat (which isn't always the correct one).
2015-12-20 20:50:54 +01:00
wm4 127da1613f demux_disc: fix aspect ratio
Broken by commit 0a0bb905. STREAM_CTRL_GET_ASPECT_RATIO returns a
display aspect ratio, not a pixel aspect ratio.
2015-12-20 09:36:56 +01:00
wm4 0a0bb9059f video: switch from using display aspect to sample aspect
MPlayer traditionally always used the display aspect ratio, e.g. 16:9,
while FFmpeg uses the sample (aka pixel) aspect ratio.

Both have a bunch of advantages and disadvantages. Actually, it seems
using sample aspect ratio is generally nicer. The main reason for the
change is making mpv closer to how FFmpeg works in order to make life
easier. It's also nice that everything uses integer fractions instead
of floats now (except --video-aspect option/property).

Note that there is at least 1 user-visible change: vf_dsize now does
not set the display size, only the display aspect ratio. This is
because the image_params d_w/d_h fields did not just set the display
aspect, but also the size (except in encoding mode).
2015-12-19 20:45:36 +01:00
Kevin Mitchell 7137afeb2c demux: check embedded cuesheet refers to only one file
If someone was "clever" enough to embed a cuesheet
referencing multiple files, mpv would create a bunch
of nonsense chapter markers.
2015-12-17 12:38:57 -08:00
Kevin Mitchell ad80cc4eee demux_cue: remove cue tracks which have a null filename.
This can happen if the file references a track, but does not specify
an INDEX 01 for it. This would cause mpv to just segfault due to
dereferencing the null pointer as a string.

A file causing this was observed in the wild by
ExactAudioCopy v0.99pb4 for a disk that contained a data track at the
end.
2015-12-17 12:38:53 -08:00
wm4 f36c17d715 demux_lavf: minor cleanups 2015-12-17 01:17:26 +01:00
wm4 74c11f0c84 sub: detect charset in demuxer
Slightly simpler, and removes the need to pre-read all subtitle packets.

This still does the subtitle charset conversion on the packet level
(instead converting when parsing the file), so in theory this still
could provide a way to change the charset at runtime. But maybe even
this should be removed, as FFmpeg is somewhat likely to get its own
charset detection and conversion mechanism in the future. (Would have
to keep the subtitle file in memory to allow changing the charset on
the fly, I guess.)
2015-12-17 01:17:23 +01:00
wm4 29226e6a99 sub: remove sd_movtext.c
libavcodec's movtext-to-ass converter does the same and has more
features. On Libav, this commit disables mp4 subtitle display.
2015-12-15 21:05:48 +01:00
wm4 a6521f3941 demux: remove old subtitle parser
All of these are supported by FFmpeg now. It was disabled by default
too (with FFmpeg).

If compiled against Libav, mpv will lose the ability to read some
subtitle formats (but the most important ones, srt and ass, still should
work).
2015-12-10 22:53:37 +01:00
wm4 45ae0716be csputils: rename "yuv2rgb" functions
They're not necessarily restricted to YUV aka YCbCr.

vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-09 00:23:36 +01:00
wm4 c2d0d7818f csputils: remove obscure int_bits matrix scaling
This has no reason to be there. Put the functionality into another
function instead. While we're at it, also adjust for possible accuracy
issues with high bit depth YUV (matters for rendering subtitles into
screenshots only).
2015-12-09 00:08:00 +01:00
wm4 b2e8d5749b demux: fix seeking in .ts
.ts files (and some other raw streams) are the only files that enable
the SEEK_FACTOR code path, which was broken since commit 70df1608.
2015-11-23 16:20:44 +01:00
wm4 8ff2058681 demux_mkv: fix incremental indexing with single-keyframe files
This is another regression of the recently added start time probing. If
a seek is executed after opening the file (but before reading any
packets), the first block is discarded instead of indexed. If there are
no other keyframes in the file, seeking will fail completely.

Fix it by seeking to the cluster start if there aren't any index entries
yet. This will read the skipped packet again.

Fixes #2498.
2015-11-17 21:43:35 +01:00
wm4 70df1608d6 player: handle rebasing start time differently
Most of this is explained in the DOCS additions.

This gives us slightly more sanity, because there is less interaction
between the various parts. The goal is getting rid of the video_offset
entirely.

The simplification extends to the user API. In particular, we don't need
to fix missing parts in the API, such as the lack for a seek command
that seeks relatively to the start time. All these things are now
transparent.

(If someone really wants to know the real timestamps/start time, new
properties would have to be added.)
2015-11-16 22:47:17 +01:00
wm4 384b13c5fd demux_libass: remove this demuxer
This loaded external .ass files via libass. libavformat's .ass reader is
now good enough, so use that instead.

Apparently libavformat still doesn't support fonts embedded into text
.ass files, but support for this has been accidentally broken in mpv for
a while anyway. (And only 1 person complained.)
2015-11-11 21:28:20 +01:00
wm4 977869a804 demux_lavf: mark ASS tracks as always UTF-8
Stops mpv from trying to run a subtitle charset detector on .ass files
loaded by libavformat.
2015-11-11 21:25:08 +01:00
Kevin Mitchell cf5b117553 libarchive: remove redundant log prefix
"libarchive:" is already added by the logging system
2015-11-09 22:41:19 -08:00
wm4 1356755ad4 demux_mkv: remove --demuxer-mkv-fix-timestamps
While it seemed like a pretty good idea at first, it's just a dead end
and works only in the simplest cases. While it may or may not help
slightly with audio sync mode, the display-sync mode already compensates
this in a better way. The main issue is that timestamps at this layer
are not in order, so it can look at single timestamps only.
2015-11-07 17:37:32 +01:00
wm4 945df57357 demux_mkv: dump mixing/writing app fields in verbose log 2015-11-06 12:48:24 +01:00
wm4 3c081dfd93 Replace deprecated av_free_packet() calls
av_free_packet() got finally deprecated. Use av_packet_unref() instead,
which has almost the same semantics, has existed for a while, and is
available in all FFmpeg and Libav versions we support.
2015-10-28 23:48:56 +01:00
wm4 a135c9cffc demux_mkv: fix cluster skip with duration probing
The start time probing essentially broke it.
2015-10-27 20:57:11 +01:00
wm4 555ecbb70e demux_mkv: fix duration probing for files with non-0 start time
When using --demuxer-mkv-probe-video-duration=full and the file did not
start at timestamp 0, the reported duration was still wrong.
2015-10-26 18:21:31 +01:00
wm4 955c6843b6 command: do not return 0 for bitrates if unknown
This makes the bitrate properties unavailable, instead of
returning 0 when:

1. No track is selected, or
2. Not enough packets have been read to have a bitrate estimate yet
2015-10-23 14:53:19 +02:00
wm4 0a1a5707bf demux: cosmetics: remove indirection
Let's not waste precious lines.
2015-10-22 01:26:34 +02:00
wm4 667b968939 demux_lavf: always copy codec headers
If this is not done, libavformat could change the headers while
demuxing, all while the decoder thread reads these fields during
initialization.
2015-10-19 15:27:42 +02:00
wm4 9ca312b4b1 demux: remove demux_add_packet() return value 2015-10-17 14:27:55 +02:00
wm4 76bfd5b4a2 demux_mkv: probe start time
MKV files can very well start with timestamps other than 0. While mpv
has support for such files in general, and demux_lavf enables this
feature, demux_mkv didn't export a start time.

Implement this by simply reading the first cluster timestamp. This in
turn is done by reading 1 block. While we don't need the block for this
prupose at all, it's the easiest way to get the cluster timestamp read
correctly without code duplication. In theory this could be wrong, and
a packet could start at a much later time, but in practice this won't
happen.

This commit also adds an option to disable this feature. It's not
documented because nobody should use it. (But I happen to have a need
for this.)
2015-10-16 17:11:44 +02:00
wm4 14a2993796 demux_mkv: do not return subtitle packets that end before seek target
This affects the subtitle preroll mode during seeking. It could matter
somewhat with insane files with ten-thousands of subtitle events, which
now seem to pop up, and will avoid packet queue overflow.
2015-10-12 21:19:43 +02:00
wm4 252d5b319a demux_subreader: participate in probing only on Libav
FFmpeg supports all formats the old subreader code does, and is better
at it. On the other hand, subreader.c's probing is bad and can lead to
false positives easily.
2015-10-08 19:59:49 +02:00
wm4 288eaacd85 demux: don't attempt to open a demuxer after abort signal was given
demux_open() kept trying to fallback to other demuxers when opening was
cancelled. This was not really a problem, but it was stupid.
2015-10-06 18:19:20 +02:00
wm4 ae7212963e cue: read more metadata
Make handling of metadata slightly more generic, and add reading of the
"PERFORMER" fields. There are some more fields, but for now let's leave
it at this.

TRACK-specific PERFORMER fields have to be read from the per-chapter
metadata (somewhat obscure).

Fixes #2328.
2015-10-01 21:57:35 +02:00
wm4 b4491c00c4 Take care of libavcodec convergence_duration deprecation
This AVPacket field was a hack against the fact that the duration field
was merely an int (too small for things like subtitle durations). Newer
libavcodec drops this field and makes duration 64 bit.
2015-09-29 18:43:28 +02:00
wm4 496d53a2f2 ebml: warn if an EBML has unknown length
While unknown lengths are supported in some important cases like
segments and clusters, they are not for small and complex metadata
elements like the track list. Such elements are simply rejected.

This case was caught by the size sanity check below, but the message is
misleading and wrong.

(There are likely no files in the wild which require support for this.
The sample file I've seen was muxed by libavformat, but in a case where
it aborted when writing the header. Clearly a broken file.)
2015-09-03 13:39:00 +02:00
wm4 ba384fffca demux_mkv: discard broken index
Add a simplistic heuristic for detecting broken indexes. This includes
indexes with very few elements (apparently libavformat sometimes writes
such indexes, or used to), and indexes with broken timestamps.

The latter was apparently produced by very old HandBrake versions:

| + Muxing application: libmkv 0.6.1.2
| + Writing application: HandBrake 0.9.1

These broken files seem to be common enough that libavformat added a
workaround for them in 2008 (and maybe again in 2015). Apparently all
timestamps are multiplied with the file's tc_scale twice, and FFmpeg
attempts to fix them. We should throw away the whole thing.
2015-08-26 22:47:07 +02:00
wm4 dae464a491 demux_mkv: don't read index twice
Actually, this never happened, because there's logic for ignoring
duplicate header elements (which includes the seek index). This is
mostly for robustness and readability.
2015-08-26 22:42:54 +02:00
wm4 a48a8a746e demux_libarchive: don't allow probing to read unlimited data
Instead, allow reading 2KB only. This seems to be sufficient for
libarchive to recognize zip, 7z, rar, tar. Good enough.

This is implemented by creating an in-memory stream with a copy of
the file header. If libarchive succeeds opening this, the actual
stream is opened.

Allowing unlimited reading could break unseekable streams, such as
playing from http servers with no range request support or pipes.

Also, we try not to read too much data in the first probe pass. Some
slow network streams like shoutcast services could make probing much
slower if we allow it to read too much. In the second probing pass,
actually allow 200KB.
2015-08-24 22:26:07 +02:00
wm4 da8a9ff589 demux_libarchive: reject 0-sized files
libarchive does strange things with them.
2015-08-18 00:14:37 +02:00
wm4 cf2fa9d3e5 stream: provide a stream_get_size() convenience function
And use it everywhere, instead of retrieving the size manually. Slight
simplification.
2015-08-18 00:10:54 +02:00
wm4 bf5eac8dd3 demux_libarchive: open flat compressed files
Things like .gz etc., which have no real file header. A mixed bag,
because it e.g. tends to misdetect mp3 files as compressed files or
something (of course it has no mp3 support - I don't know as what it
detects them). But requested by someone (or maybe not, I'm not sure
how to interpret that).
2015-08-17 23:59:55 +02:00
wm4 2b280f4522 stream: libarchive wrapper for reading compressed archives
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.

Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.

This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
2015-08-17 00:55:26 +02:00
wm4 828881816a demux: remove redundant demux_chapter.name field
Instead, force everyone to use the metadata struct and set a "title"
field. This is only a problem for the timeline producers, which set up
chapters manually. (They do this because a timeline is a separate
struct.)

This fixes the behavior of the chapter-metadata property, which never
returned a "title" property for e.g. ordered chapters.
2015-08-12 11:11:23 +02:00
wm4 8f2d9db79f demux_mkv: disable timestamp fixup code again
This doesn't work too well if sections of the file change to a different
framerate. It lowers our chances to guess the correct FPS in the display
sync code.

For normal playback, this (probably) doesn't help that much anyway,
except that the "estimated-vf-fps" property will regress in the simplest
mkv case. This will be fixed with the next commit.

The now disabled code will probably be removed; it's not useful anymore.
2015-08-10 18:38:36 +02:00
wm4 beb4f8316a demux: add options to control maximum queue size
Add --demuxer-max-packets and --demuxer-max-bytes, which control the
maximum size of the packet queue. These can be helpful to avoid
excessive memory usage.

Memory usage is the reason why there's a limit in the first place. If a
file is more or less broken, and audio and video don't line up, the
decoders will fill up the packet queue trying to read more audio or
video, and the maximum sizes are required to avoid unbounded memory
allocation. Being able to override the maximum sizes is useful; either
for restricting memory usage further, or enlarging the sizes when
attempting to play various broken files.
2015-08-05 23:41:29 +02:00
wm4 775d816096 demux: remove options to control minimum packet queue size
Remove --demuxer-readahead-packets and --demuxer-readahead-bytes. These
were a bit useless. They could force a minimum packet queue size, but
controlling the queue size with --demuxer-readahead-secs is much nicer.

It's fairly certain nobody ever used these options.
2015-08-05 23:38:23 +02:00
wm4 0b1c3e8de2 player: warn against using HLS URLs with --playlist
That just makes no sense, but seems to be a somewhat common user error.

The detection is not perfect. It's conceivable that EXT-X-... headers
are used in normal m3u playlists. After all, HLS playlists are by
definition a compatible extension to m3u playlists, as stupid as it
sounds.
2015-08-04 17:51:00 +02:00
wm4 75b1d5043f player: use demux_open_url() to open main files
Instead of opening a stream and then a demuxer, do both at once with
demux_open_url().

This requires some awkward additions to demuxer_params, because there
are some weird features associated with opening the main file. E.g. the
relatively useless --stream-capture features requires enabling capturing
on the stream before the demuxer is opened, but on the other hand
shouldn't be done on secondary files like external subtitles.

Also relatively bad: since demux_open_url() returns just a demuxer
pointer or NULL, additional error reporting is done via demuxer_params.

Still, at least conceptually, it's ok, and simpler than before.
2015-08-04 01:01:09 +02:00