|author||wm4 <wm4@nowhere>||2017-12-26 05:53:44 +0100|
|committer||Kevin Mitchell <firstname.lastname@example.org>||2017-12-28 00:59:22 -0700|
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.
Diffstat (limited to 'DOCS')
1 files changed, 12 insertions, 0 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index e76f5a115a..baf8f3a6d5 100644
@@ -1159,6 +1159,18 @@ Video
on the machine and use that, up to the maximum of 16. You can set more than
16 threads manually.
+ Assume the video was encoded by an old, buggy x264 version (default: no).
+ Normally, this is autodetected by libavcodec. But if the bitstream contains
+ no x264 version info (or it was somehow skipped), and the stream was in fact
+ encoded by an old x264 version (build 150 or earlier), and if the stream
+ uses ``4:4:4`` chroma, then libavcodec will by default show corrupted video.
+ This option sets the libavcodec ``x264_build`` option to ``150``, which
+ means that if the stream contains no version info, or was not encoded by
+ x264 at all, it assumes it was encoded by the old version. Enabling this
+ option is pretty safe if you want your broken files to work, but in theory
+ this can break on streams not encoded by x264, or if a stream encoded by a
+ newer x264 version contains no version info.