piping 10bit 444le to x264 => artifacts in output

[Selur]

Problem reported over at:
piping 10bit 444le to x265|x264 => artifacts in output (https://forum.doom9.org/showthread.php?t=174314)
also exists in x264 0.148.2762 90a61ec

Jamaika liked to patched sources over at:
https://forum.doom9.org/showthread.php?p=1797210#post1797210

=> Would be nice these changes could also be added to the main branch.

Cu Selur

Ps.: For users which also struggle with this, there's also a link to a google drive with fixed builds over at https://github.com/Freecom/x264

[nevcairiel]

I don't see any fixes relating to 444 10-bit input in that x264 repository you linked. All possible fixes discussed in the original thread have been in other software, not x264.

[Selur]

I don't see any fixes relating to 444 10-bit input in that x264 repository you linked
commits:
https://github.com/Freecom/x264/commit/8157d27b9ead28926fd684c15b132a41dfbb3abc
and
https://github.com/Freecom/x264/commit/0b01811bde3b5a35a681905f4bc8d666557901f2
are the two commits Jamaika mentioned.

All possible fixes discussed in the original thread have been in other software, not x264.
Since Jamaika quickly posted a fix for x264 which I then used and assumed that it would make it's way into the x264 main branch during the following month,...

[nevcairiel]

commits:
https://github.com/Freecom/x264/commit/8157d27b9ead28926fd684c15b132a41dfbb3abc
and
https://github.com/Freecom/x264/commit/0b01811bde3b5a35a681905f4bc8d666557901f2
are the two commits Jamaika mentioned.


One is a feature for 4:2:2 and one is a documentation change, so they do nothing for your use-case.

[Selur]

Strange, fact is that with current normal builds the artifacts are still present, but with the build from Jamaika, the artifacts are not there anymore.
So he must have changed something.

Cu Selur

Ps.: send him a PM

PPs.: "One is a feature for 4:2:2 " <- I thought the additional constrains part of 'We can utilize the existing plane_copy_deinterleave() functions with some
additional minor constraints (we cannot assume any particular alignment or overread the input buffer).' included the fix for the issue I found.

[MasterNobody]

Better ask ffmpeg/libav developers to fix it in there project (overflows in colorspace conversion) in first hand.

[Selur]

In my option that is not enough since lots of folks use old ffmpeg versions and new x264 versions since compiling ffmpeg is a pain (thanks to all the dependencies you normally want to have in it) and x264 isn't.

Also it would be nice if a user who can better express what really the issue is can post a bug report, since I don't know how to express this properly so that the ffmpeg devs will understand it. :)

[Jamaika]

Sorry Selur.
My old computer doesn't work correctly with codecs ffmpeg, x264 and decoder lavvideo. Player MPC-HC shows nonsense. Let others have denounced with the newer hardware (monitor, graphics card 10bit, etc.).
http://i63.tinypic.com/14c4okk.png