Also allows demuxers to buffer, and we explicitly discard stale QPSK events.
Inspiration taken from the szap-s2 implementation.
S2API is only used if available and for DVB-S cards - it might also be useful to have that for DVB-T2 / DVB-C2 tuning later, but I do not have the HW / no DVB-T2 broadcasting station nearby to test functionality.
This should do no functional changes, only usage of the different API. The S2API is more extensible and a requirement for all the HD-deliveries (e.g. DVB-S2) and since 2.6.28 is the successor of the old API.
Tuning to DVB-S2 channels actually already "works" like this if the delivery is hardcoded in - for a fully working implementation, the channels.conf.sat would need an additional field indicating the delivery type (VDR-type channels.conf have that).
This commit also:
- Cleans up some debug output.
- Moves an unneeded usleep(100000) (only needed for diseqc switching for SAT) into the DVB-S-only part of the implementation.
Define a new macro "DVB_USE_S2API" to be used to switch to S2API if available,
also document what is the main difference in the new S2API.
StreamID-handling is only supported since API 5.2, and some macros
were renamed or only added later with 5.8 (somewhere around kernel 3.6),
so some define-fixups are needed to support these intermediate
kernel header versions.
Commit 87c13de6 added a fallback to video resolution if the subtitle
resolution is unknown. Apparently this fixed some broken files with
vobsubs.
This broke some DVB subtitles. Apparently .ts captures with 1920x1080
video resolution and 720x576 subtitles do exist. The sample at hand had
some streams with 720x576 resolution and no sub resolution set, and some
streams with 1920x1080 resolution and sub resolution set (both against
the same 1920x1080 video). My conclusion is that 720x576 is the only
reasonable fallback for DVB (but I can't be sure).
The fallback is removed for PGS too. I don't know about the PGS case; it
seems the sub resolution must always be set, so it shouldn't matter.
Fixes#1425.
This makes vo_opengl_cb respond to controls like "gamma" and
"brightness". The commit includes an awkward refactor for vo_opengl to
make it easier for vo_opengl_cb.
One problem is a logical race condition. The set of supported controls
depends on the pixelformat, which in turn is set by reconfig(). But the
actual reconfig() call (on the renderer) happens asynchronously on the
renderer thread. At the time it happens, the player most likely already
tried to set some controls for command line options (see init_vo() in
video.c). So setting this command line options will fail most of the
time, though it could randomly succeed. This can't be fixed directly,
because the player can't wait on the renderer thread, because the
renderer thread might already wait on the player.
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.
This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
No more equals signs for options that don't take values.
Complete values for options with preset choices.
Complete --no-whatever where applicable.
Fixes#997.
--sub-scale-by-window=no attempts to keep subs always at the same pixel
size.
The implementation is a bit all over the place, because it compensates
already done scaling by an inverse scale factor, but it will probably do
its job.
Fixes#1424. (The semantics and name of --sub-scale-with-window are
kept, and this adds a new option - the name is confusingly similar, but
it's actually analogue to --osd-scale-by-window.)
This adds an "auto" choice to the concurrent-frames suboption, and makes
it the default.
I'm not so sure about making this the default, though. It could lead to
excessive buffering with large CPU counts. But we'll see.
Our own code was introduced when FFmpeg didn't provide this API (or
maybe didn't even have a way to determine the CPU count). But now,
av_cpu_count() is available for all FFmpeg/Libav versions we support,
and there's no reason to have our own code.
libavutil's code seems to be slightly more sophisticated than our's, and
it's possible that the detected CPU count is different on some platforms
after this change.
If there's only 1 chapter, the seeking by chapter (using the chapter
property) will either jump to the chapter point, or quit playback. This
is as designed, but seems like a useless and annoying behavior.
Removes an annoying "No video PTS! Making something up." warning.
Mark it as keyframe, which is needed to prevent strange behavior with
PNG. Also, don't leak the picture data.
Options which take colors accept two variants. The first is "r/g/b/a",
the second is "#AARRGGBB". Since they put alpha at different places,
it's probably better to document the second variant explicitly. (It's a
bit strange that they put alpha in different places, but on the other
hand, it's kind of natural. The second variant should probably be
considered deprecated.)
mpv_opengl_cb_uninit_gl() can be called at any time; but then the
decoder must be destroyed due to complications with hardware decoding.
This is why kill_video() exists. To make things easier, there is the
invariant that while vo_opengl_cb is active, the OpenGL state must
exist. But kill_video() didn't actually destroy the VO; only the video
decoder. This could trigger an assertion (vo_opengl_cb.c:187).
Actually, the video output is always destroyed lazily at a later point
if the decoder is destroyed, but not early enough for out purposes.
Returning the property before the window is mapped could lead to
confusing behavior, and in particular strange differences between
vo_vdpau and vo_opengl. (vo_opengl creates the window right at the
start, while vdpau waits until the first reconfigure event.) It might
even be possible that for vo_opengl random results were returned,
because the hidden window can have different placement than the actual,
final one on initial video reconfig.
Fix this by returning the property only if the window is considered
mapped. command.c handles this case specifically, and makes the property
unavailable, instead of returning an empty list.
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
This is basically a hack; but apparently a needed one, since many
vapoursynth filters insist on having a FPS set.
We need to apply the FPS override before creating the filters. Also
change some terminal output related to the FPS value.
Most of this is explained in the code comments. This change should
improve performance with vapoursynth, especially if concurrent requests
are used.
This should change nothing if vf_vapoursynth is not in the filter chain,
since non-threaded filters obviously can not asynchronously finish
filtering of frames.
Add an explicit "signal" event type, because the implicit one was
confusing.
Don't rescale the Y axis of the second graph, it was nonsense.
Make the legend for the second graph separate (and cleanup the code
creating the graphs).
* bits instead of bytes
* add valid_bits argument
* just pass in the mp_chmap and get the number and wavext channel map from that
* indicate valid bits in waveformat_to_str
* make appropriate accomodations in try_format
