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>
Just that actually changing it at runtime won't do anything.
This deals with a nasty initialization order issue with encoding.
Encoding is initialized after options have initialized, but before
--load-scripts is checked and executed. Encoding initialization accesses
FFmpeg API, thus it has to run after FFmpeg is initialized (which also
implies it's initialized after options/logging init). On the other hand,
it sets the encoding builtin profile, which possibly sets --load-scripts
to "no". That failed at this point because --load-scripts was marked as
fixed.
Just marking it as not fixed gets rid of the headache, even if it's not
perfectly orthodox.
--reset-on-next-file=all triggers m_config_backup_all_opts(), which
backups all options (even deprecated ones). Later, when the option
values are reset with m_config_restore_backups(), mp_on_set_option() is
called, which in turn calls mp_property_do_silent(), which in turn will
call mp_property_generic_option() and m_config_get_co(), which triggers
the deprecation message.
Unfortunately there's no good way to determine whether an option has
actually changed (there's no option value compare operation), so the
deprecated options have to be set no matter what. On the other hand, we
can't pass through additional flags through the property layer. So we
add a dumb global flag to silence the deprecation warnings in these
cases.
Fortunately m_config_get_co_raw() works to silence the warnings.
m_config_get_co() also resolves aliases (deprecated and non-deprecated),
but aliased options are handled differently by the option-property
bridge, so we don't need to do that here, so the only purpose of it is
to trigger a warning for deprecated (non-alias) options.
The tv-freq options and properties use different types, thus must be
treated as incompatible. Fixes an assertion with reset-on-next-file=all,
which tries to set the option.
Fixes#3708.
It turns out the glFlush() call really helps in some cases, though only
in audio timing mode (where we render, then wait for a while, then
display the frame). Add a --opengl-early-flush=auto mode, which does
exactly that.
It's unclear whether this is fine on OSX (strange things going on
there), but it should be.
See #3670.
Don't leave the buffering state while the demuxer is still marked as
having underflowed. It's unclear why this hasn't been done before - with
the logic being complicated as it is, maybe there was a reason for this.
This is actually still not very reliable, but should be better than what
was before: on stream switching decoders can read packets all while the
demuxer is executing a refresh seek, which creates the underrun
situation - but nothing really totally guarantees that the underrun
state remains stable when the demuxer is back at the current demuxer
position. Anyway, it's an improvement.
The rest of the touched condition is not changed, just moved around for
cosmetic reasons.
in very rare circumstances, doing a relative seek like +1s will end up
doing an absolute seek to 00:01. this guards against that possibility.
so far i've only ever seen this issue when using --ad=lavc:ac3_at and
doing several relative seeks in quick succession. this is likely either
a bug in the audiotoolbox decoder in ffmpeg, or simply due to inherent
latency in that hardware decoder which causes brief periods of time
where the current audio pts is unknown.
i've seen several mpegts samples where pts jumps backwards and repeats
itself. this usually happens on live tv streams from cable providers,
particularly when the stream switches from one advertisement to another.
when there is a huge delay between audio/video sync, it can take a
really long time to converge back. this speeds up the resync time by
increasing the max_change allowed per iteration.
Signed-off-by: wm4 <wm4@nowhere>
Thread-local storage in GCC is platform-specific, and some platforms that
are otherwise perfectly capable of running mpv may lack TLS support in GCC.
This change adds a test for GCC variant of TLS and relies on its result
instead of assumption.
Provided that LLVM's `__thread` support is similar to GCC, the test is
called "GCC/LLVM TLS".
Signed-off-by: wm4 <wm4@nowhere>
At this point, all other hwaccels provide -copy modes, and vdpau is the
exception with not having one. Although there is vf_vdpaurb, it's less
convenient in certain situations, and exposes some issues with the
filter chain code as well.
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.)
Had only tested with luajit which supports the \xHH syntax added
in Lua 5.2.
The arrow is troublesome to use since the ideal way to use it, as
the OSD code uses it, needs \alpha&H00<arrow>\r to work, which
does not in OSC's way of showing messages.
Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until
now, decoders always returned the pts via the pkt_pts field, while the
pts field was used for encoding and libavfilter only. Recently, pkt_pts
was deprecated, and pts was switched to always carry the pts.
This means we have to be careful not to accidentally use the wrong
field, depending on the libavcodec version. We have to explicitly check
the version numbers. Of course the version numbers are completely
idiotic, because idiotically the pkg-config and library names are the
same for FFmpeg and Libav, so we have to deal with this explicitly as
well.
Change a few other defaults accordingly:
- seekbarstyle=bar looks better with bottombar.
- Bigger scalewindowed and scalefullscreen make bottom/topbar more readable.
POSIX leaves poll() behavior on directories unspecified. While on
Linux, it seems to behave the same way as regular files (always
return immediately), this is not guaranteed. At least with OSX
10.12, it seems to wait, which essentially means that opening
directories will "hang".
Fixes#3530 and #3649.
