Move the code that copies the dylib's to the bundle to a new script
(dylib-unhell.py) which is called by osxbundle.py.
dylib-unhell is about 20x faster than the previous implementation. This is
accomplished by removing superflous shell-out operations which are kept track
of using an in memory tree of all the needed dependencies. Moreover the
shell-outs have been further optimized by not requiring a complete shell for
every operation and just using subprocess.call (which is equivalent to Popen).
The many "boxes" in this entry were causing rst2pdf to fail because it
couldn't figure out where to break the page. Make the boxes smaller by
removing semi-redundant examples. Also try and make surrounding text a
little shorter by rewording.
This is done after filters, so things like framerate-doubling
deinterlacing is accounted for.
Unfortunately, framedropping can cause inaccuracies (especially after
precise seeks), and we can't really know when that happens. Even though
we know that the decoder might drop a frame if we request it to do so,
we don't know when the dropped frame will start or stop affecting the
video filter chain. Video filters can have frames buffered, and we
can't tell at which point the dropped frame would have been output.
It's not even possible to mark a discontinuity after seek, because
again we don't know if the filter chain still has the discontinuity
within its buffers.
So we have to live with the fact that the output of this property can
be completely broken after seek, unless --no-hr-seek-framedrop is used.
This allows disabling of decoder framedrop during hr-seek.
It's basically another useless option, but it will help exploring
whether this framedropping really makes seeking faster, or whether
disabling it helps with precise seeking (especially frame backstepping).
Until recently, the VO was an unavoidable part of the seeking code path.
This was because vdpau deinterlacing could double the framerate, and hr-
seek and framestepping etc. all had to "see" the additional frames. But
we've removed the frame doubling from the vdpau VO and moved it into a
video filter (vf_vdpaupp), and there's no reason left why the VO should
participate in seeking.
Instead of queuing frames to the VO during seek and skipping them
afterwards, drop the frames early.
This actually might make seeking with vo_vdpau and software decoding
faster, although I haven't measured it.
Now we avoid calling update_video() twice on reconfig (once to check
whether there are still new frames, and again to actually do the
reconfig). Instead, we check whether there's still something going on
before calling update_video() at all, and depending on that
update_video() will be allowed to reconfig or not.
This will simplify some things later.
It doesn't look like vo_wayland_config() necessarily sets this flag, so
it seems safer to trigger an explicit resize. This accounts for the case
when playing a new file with different size than the one before.
Currently, vo_reconfig() calculates the requested window size and sets
the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is
implemented by the VO or the windowing backend. The window size can be
different from the display size if e.g. the --geometry option is used.
It will also set the vo->dx/dy fields and read vo->xinerama_x/y.
It turned out that this is very backwards and actually requires the
windowing backends to workaround these things. There's also
MPOpts.screenwidth/screenheight, which used to map to actual options,
but is now used only to communicate the screen size to the vo.c code
calculating the window size and position.
Change this by making the window geometry calculations available as
separate functions. This commit doesn't change any VO code yet, and just
emulates the old way using the new functions. VO code will remove its
usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
Because the http playlist URL I had for testing claimed to be m3u by
file extension and mime type, but didn't have the header.
Note that this actually changes behavior only in the case the format is
detected by mime type. Then p->force will be set before calling the
parser, and the header becomes optional.
Changing --softvol-max and then resuming would change the volume level
on resume to something different than the original volume. This is
because the user volume setting is always between 0-100, and 100
corresponds to --softvol-max gain.
Avoid that changing -softvol-max and resuming an older file could lead
to a too loud volume level by refusing to restore if --softvol-max
changed.
Commit 433161 actually broke vo_opengl (and maybe others), because
config_ok is not necessarily set correctly yet _during_ reconfig. So a
vo_get_src_dst_rects() call during reconfig did nothing.
When the VO was not initialized with vo_reconfig(), or if the last
vo_reconfig() failed, changing panscan would cause a crash due to
vo_get_src_dst_rects() dereferencing vo->params (NULL if not
configured).
Just do nothing if that happens, as there is no video that could be
displayed anyway.
Doesn't really seem to be much of use. Get rid of the remaining uses of
it.
Concerning vo_opengl_old, it seems uninitGl() works fine even if called
before initialization.
Make it more suitable for chaining. This means a function formatting a
value to a string using a static buffer can work exactly like
mp_snprintf_append itself.
Also rename it to mp_snprintf_cat, because that's shorter.
Basically, extract the option table from DOCS/man/en/changes.rst, and
search the table if an option wasn't found. If there's an entry about
it, print it. Hopefully this behavior is slightly more userfriendly.
This is strictly bound to option names. It doesn't work for option
values, nor does it attempt to emulate the old option.
The comment says that it wakes up the main thread if 50% has been
played, but in reality the value was 0.74/2 => 37.5%. Correct this. This
probably changes little, because it's a very fuzzy heuristic in the
first place.
Also move down the min_wait calculation to where it's actually used.
mp3 has a hack lowering the probescore for format detection. This is
because detecting mp3s is hard due to their nature, and the fact that
ID3v2 tags are sometimes several megabytes big.
When playing mp3 from network, the mime-type is usually set, and that
matches the format hack entry meant for webradios, overriding the normal
mp3 entry. This can lead to network mp3s not being detected. Lower the
network case to the same probescore as on-disk mp3s. The difference is
that for network mp3s, we don't load the full probe-buffer, and we lower
the amount of audio the demuxer will read to collect data on opening
(0.5 seconds instead of typically 5 seconds).
