| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
At least DTV_ENUM_DELSYS is not available in older versions.
It's hard to tell when this identifier was introduced, but it appears it
was probably API version 5.5.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the timing logic is correct, it tends to mess with looping
videos and such in unappreciated ways.
It also has to be admitted that most file formats seem not to properly
define the duration of the last video frame (or libavformat does not
export it in a useful way), so whether or not we should use the demuxer
reported framerate for the last frame is questionable. (Still, why would
you essentially just discard the last frame?)
The timing logic is kept, but disabled for video with "normal" FPS
values. In particular, we want to keep it for displaying images, which
implicitly set the frame duration to 1 second by reporting 1 FPS. It's
also good for slide shows with mf://.
Fixes #2745.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most text subtitles are read completely on loading (libavformat works
this way, and there are good reasons to do it on the higher levels too).
This leads to some messy problems. For example, the subtitle path is the
only one which might read packets during decoder initialization. This is
not neccessary; get rid of it.
This fixes a potential problem of seeking to position 0 for image
subtitles on init, and if the start position is not at the beginning of
the timeline.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't need to be part of the big context, but is strictly part of
shuffling data from the audio filters to audio output, and thus belongs
into ao_chain.
It also turns out that clearing it in clear_audio_output_buffers() is
completely redundant.
(Of course ao_buffer is an abomination in the first place and shouldn't
exist at all.)
|
|
|
|
|
|
|
|
|
|
| |
vo_chain_uninit() isn't supposed to care much about the decoder
(although decoders and outputs still go strictly together, so there is
not much of an actual difference now).
Also unset track.d_video correctly.
Remove a stale declaration from dec_video.h as well.
|
| |
|
|
|
|
|
|
|
|
|
| |
Similar to the video path. dec_audio.c now handles decoding only. It
also looks very similar to dec_video.c, and actually contains some of
the rewritten code from it. (A further goal might be unifying the
decoders, I guess.)
High potential for regressions.
|
|
|
|
| |
This was outdated after a1f949d3b83224306e099c7d670f11eb8f249b84.
|
| |
|
|
|
|
|
| |
May help in future debugging in case of old kernels
with modern / obscure devices.
|
|
|
|
|
|
|
|
|
|
|
| |
Using the new API is a necessity for multiple-delivery-system
devices, since the old API does not offer a way to switch
the delivery system of the card.
This should in principle also be done for DVB-T / ATSC,
especially since most DVB-T devices also support DVB-C,
but I can not test such an implementation due to lack of hardware
(currently) so it seems better to leave the existing, tested code-path
in place for now.
|
|
|
|
|
|
|
|
| |
No need use use all capital letters, and don't warn
if DVB-S2 is supported in addition since we handle that
in DVB-S case already.
Also, print the delivery system number for still unhandled
delivery systems to simplify debugging.
|
|
|
|
|
|
|
|
|
| |
Saves one unnecessary additional ioctl per tuning
by just reusing existing information.
Should also fix the case of multiple supported delivery types
since we now rely on the initial query from the chosen
configuration after channel list parsing
instead of requerying the device.
|
|
|
|
|
|
|
|
|
| |
Most common case would be DVB-C / DVB-T combination cards.
Cards with multiple delivery systems are only supported
starting from DVBv5 API (Kernel 2.6.38).
In this case, we loop over all delivery systems and
just treat them as different cards would be treated:
They all get their own TUNER-type, channel-list parsing etc.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only request the current screen configuration instead of polling for new
screens, too. We're not interested in detecting any new screens as we're
merely enumerating what is currently connected and configured.
On some hardware (like mine) calling XRRGetScreenResources will stall
X11 for about 10 to 20 seconds. This has annoyed me for a few months
now and almost made me switch to VLC ;)
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Just requires glueing it together with Bloat Super Glue (tm).
|
|
|
|
|
| |
This means there will be no loss if profile detection failed for some
reason.
|
|
|
|
|
|
| |
This is probably the 3rd time the user-visible behavior changes. This
time, switch back because not normalizing seems to be the more expected
behavior from users.
|
|
|
|
|
|
|
|
| |
Too many problems. Well, actually it's just Linux audio systems which
cause problems, and exclusive audio access on other platforms.
In any case, it seems you have to do some manual configuration if you
want multichannel audio output.
|
|
|
|
| |
Kind of annoying.
|
| |
|
|
|
|
|
|
| |
They don't define FF_PROFILE_VP9_0.
Fixes #2737.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems useless.
This only helped in one case: one audio stream in the sample
av_find_best_stream_fails.ts had a AC3 packets which couldn't be
decoded, and for which avcodec_decode_audio4() returned 0 forever. In
this specific case, playback will now not start, and you have to
deselect audio manually.
(If someone complains, the old behavior might be restored, but
differently.)
Also remove the stale "bitrate" field.
|
|
|
|
| |
Another bit of preparation.
|
|
|
|
| |
That's where its only use is.
|
|
|
|
|
|
| |
While the situation is not really clear for the other rewritten
coreaudio code, it's very clear for the channel mapping code. It was all
written by us. (MPlayer doesn't even have any channel map handling.)
|
|
|
|
|
|
| |
Make it consistent with filter_kernels.c.
See #2688.
|
|
|
|
|
|
|
|
|
|
|
| |
Do this to make the license situation less confusing.
This change should be of no consequence, since LGPL is compatible with
GPL anyway, and making it LGPL-only does not restrict the use with GPL
code.
Additionally, the wording implies that this is allowed, and that we can
just remove the GPL part.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This difference was unnecessary.
|
|
|
|
|
| |
Calling demux_add_packet() unconditonally frees the packet if the stream
is not selected.
|
|
|
|
|
|
|
| |
Previously used opt_exclusive option to decide which volume control code to run.
The might not always reflect the actual state, for example if passthrough
is used. Admittedly, none of the volume controls will work anyway with
passthrough, but this is the right thing to do.
|
|
|
|
|
| |
Previously this would break all further attempts to init the driver after one
had failed.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #2729.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Meh. Why are there even two code paths.
This adds an additional check; the big function is only moved.
|
|
|
|
| |
Well, not that the unthreaded case is important, or even works properly.
|
|
|
|
| |
Will be used in a following commit.
|
| |
|
|
|
|
|
| |
Make it more conservative. In most cases, mpv should be able to
determine it correctly on all supported platforms.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prevents channels from being dropped, e.g. when going 7.1 -> 7.1(wide)
and similar cases. The reasoning here is that channel layouts over HDMI
don't work anyway, and not dropping a channel and playing it on a
slightly "wrong" (but expected) speaker is preferable to playing silence
on these speakers.
Do this to remove issues with ao_coreaudio. Frankly I'm not sure whether
our mapping (between CA and mpv/FFmpeg speakers) is correct, but on the
other hand due to the reasons stated above it's not all that meaningful.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
next_scanline is usually an unsigned int.
Fixes #2635 (again).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eventually we want the VO be driven by a A->V filter, so a decoder
doesn't even have to exist. Some features definitely require a decoder
though (like reporting the decoder in use, hardware decoding, etc.), so
for each thing which accessed d_video, it has to be redecided if and how
it can access decoder state.
At least the "framedrop" property slightly changes semantics: you can
now always set this property, even if no video is active.
Some untested changes in this commit, but our bio-based distributed
test suite has to take care of this.
|
|
|
|
| |
The same is going to happen to d_video and d_audio later.
|
|
|
|
|
|
|
| |
Not bothering with anything advanced, so we just show "(original)" if
the video-aspect property/option is reset.
Fixes #2722.
|
|
|
|
|
|
|
|
|
|
|
| |
This moves some code related to decoding from video.c to dec_video.c,
and also removes some accesses to dec_video.c from the filtering code.
dec_video.ch is starting to make sense, and simply returns video frames
from a demuxer stream. The API exposed is also somewhat intended to be
easily changeable to move decoding to a separate thread, if we ever want
this (due to libavcodec already being threaded, I don't see much of a
reason, but it might still be helpful).
|
| |
|
|
|
|
|
|
|
| |
Makes the next commit simpler. It's probably a bad idea to add more
fields to the global state, but on the other hand the client API state
is pretty much per-instance anyway. It also will help with things like
the proposed libmpv custom stream API.
|
| |
|
|
|
|
|
| |
In my tests, CGDisplayModeGetRefreshRate returns 24.0 even though the nominal
one is set to 24000/1001. This is obviously not good for video.
|
| |
|
|
|
|
|
|
| |
Well, this probably depends on the exact Windows version.
Fixes #2611.
|
|
|
|
|
|
|
|
|
| |
The aspect ratio calculations are cached (mainly so that aspect ratio
related messages are not logged on every frame). The cache is not clared
anymore when video filters are reconfigured, but changing the
video-aspect-ratio property relied on it. Make it explicit.
Fixes #2714.
|
|
|
|
|
|
|
| |
Since the streams are chosen from the full TS by the player frontend,
one should not expect that the program which is shown matches the chosen
channel which was used for tuning to the frequency.
Also, reformulate slightly to simplify reading.
|
|
|
|
|
| |
If it is defined, which it rarely is (e.g. mpegts streams)
this is the preferred title information.
|
|
|
|
|
|
| |
This is labeled as "name of the service in broadcasting (channel name)"
and exported as a generic tag by avformat-demuxers, notably lavf
when handling mpegts-streams from DVB.
|
|
|
|
|
|
| |
Need to trigger demux_changed() manually since metadata
of tracks and streams is not changed, but demuxer-metadata
is still changed on program switch.
|
|
|
|
|
| |
Very helpful to switch between the different programs
on a transponder in full-transponder-mode for DVB.
|
|
|
|
|
| |
There is now H and K for DVB-channel switching,
and the properties dvb-channel (W) and dvb-channel-name (RW).
|
|
|
|
|
|
|
|
| |
The binding is similar to the tv-binding, just with capital letters.
Switching the dvb-channel-name property compared to dvb-channel
means the channel-name is shown on-screen when switching instead of
"dvb-channel (error)" otherwise,
and switching anyways happens without changing the card.
|
|
|
|
|
|
| |
Channel switching is treated inside the global DVB state
by now. Anyways the last switching direction is not really useful
and of no interest inside the player.
|
|
|
|
|
|
|
|
|
| |
On read, it returns the name of the current DVB program,
on write, it triggers a channel-switch to the program
if it is found in the channel list of the currently active card.
Compared to the dvb-channel property which already exists
and is a pair of integers (card + channel number) this has the limitation
of not switching the card, but is probably of much more common use.
|
|
|
|
| |