MPV

mpv:mruby

Last commit made on 2017-12-30
Get this branch:
git clone -b mruby https://git.launchpad.net/mpv

Branch merges

Branch information

Name:
mruby
Repository:
lp:mpv

Recent commits

2d4add3... by Stefano Pigozzi <email address hidden>

mruby: add a basic ruby implementation of obsevables

200f336... by Stefano Pigozzi <email address hidden>

mruby: automatically quit mpv after test suite

614ff9e... by Stefano Pigozzi <email address hidden>

mruby: annotate that commandv crashes horribly

0150257... by Stefano Pigozzi <email address hidden>

mruby: return api mpv queries as either monads

5a5cc02... by Stefano Pigozzi <email address hidden>

tmp: mruby support

d9ca235... by kevmitch

manpage: put android surface options on one line

This is required by rst2man.

5e50fe3... by wm4 <wm4@nowhere>

demux_mkv: add hack to pass along x264 version to decoder

This fixes when resuming certain broken h264 files encoded by x264. See
FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264
bug itself.

Normally, the unregistered user data SEI (that contains the x264 version
string) is informational only. But libavcodec uses it to workaround a
x264 bug, which was recently fixed in both libavcodec and x264. The fact
that both encoder and decoder were buggy is the reason that it was not
found earlier, and there are apparently a lot of files around created by
the broken decoder. If libavcodec sees the SEI, this bug can be worked
around by using the old behavior.

If you resume a file with mpv (i.e. seeking when the file loads),
libavcodec never sees the first video packet. Consequently it has to
assume the file is not broken, and never applies the workaround,
resulting in garbage being played.

Fix this by always feeding the first video packet to the decoder on
init, and then flushing the codec (to avoid that an unwanted image is
output). Flushing the codec does not remove info such as the x264
version. We also abuse the fact that the first avcodec_send_packet()
always pushes the frame into the decoder (so we don't have to trigger
the decoder by requsting an output frame).

d480b12... by wm4 <wm4@nowhere>

vd_lavc: add an option to explicitly workaround x264 4:4:4 bug

Technically, the user could just use --vd-lavc-o with the same result.
But I find it better to make this an explicit option, so we can document
the ups and downs, and also avoid setting it for non-h264.

f6a582e... by wm4 <wm4@nowhere>

demux_mkv: maintain a small packet read queue

This is less of a mess than the single-item queue in tmp_block, and also
might help us in the future.

5cbadbe... by wm4 <wm4@nowhere>

vd_lavc: fix crash with RPI hwdec

If you use vo_rpi, this could crash, because hwdec_devs is NULL.

Untested. Fixes #5301.