[x264-devel] x264 encoding corruption bug w/ AltiVec enabled

[Luca Barbato]

On 31/01/2019 00:23, Timothy Pearson wrote:
> On 01/30/2019 04:52 PM, Timothy Pearson wrote:
>> On 01/30/2019 04:18 PM, Timothy Pearson wrote:
>>> On 01/30/2019 03:17 PM, Timothy Pearson wrote:
>>>> On 01/30/2019 03:08 PM, Timothy Pearson wrote:
>>>>> On 01/30/2019 07:08 AM, Luca Barbato wrote:
>>>>>> On 30/01/2019 12:10, Timothy Pearson wrote:
>>>>>>> When attempting to use the latest libx264 with the latest ffmpeg sources
>>>>>>> on Talos II (ppc64le), a color / blocking artifact is introduced in the
>>>>>>> source video.  These artifacts disappear entirely when libx264 is
>>>>>>> rebuilt with asm support (AltiVec) disabled, but the machine is then no
>>>>>>> longer able to maintain 60fps framerate on the sample live stream.
>>>>>>
>>>>>> Please test with the x264 cli and, if possible, provide me the sample
>>>>>> triggering it.
>>>>>>
>>>>>> All the altivec code is tested on checkasm so sounds quite strange there
>>>>>> is a problem there.
>>>>>>
>>>>>> lu
>>>>>
>>>>> After a bit of work I was able to put together a direct x264 command
>>>>> that produces corrupted videos, based on the video output settings used
>>>>> for ffmpeg.  I should note that for various technical reasons related to
>>>>> downstream consumer devices, a few of the settings (FPS, bitrate,
>>>>> keyint) are mandatory for a proper experience, and that they work
>>>>> without AltiVec enabled.
>>>>>
>>>>> Pull the Big Buck Bunny 23 second file from here:
>>>>>
>>>>> https://commons.wikimedia.org/wiki/File:Big_Buck_Bunny_first_23_seconds_1080p.ogv
>>>>>
>>>>> Encode with:
>>>>>
>>>>> x264 --threads 31 --fps 30 --keyint 30 --min-keyint 30 --scenecut 0
>>>>> --preset ultrafast --tune grain --bitrate 25600000 -o
>>>>> Big_Buck_Bunny_encoding_failure.ogv
>>>>> Big_Buck_Bunny_first_23_seconds_1080p.ogv
>>>>>
>>>>> I'm noticing with some interest that the resulting file is unplayable
>>>>> (black screen) in VLC while mplayer shows intermittent artifacts like
>>>>> the one I attached.  mplayer also complains about numerous errors, which
>>>>> would probably explain why each video seems to have different artifacts:
>>>>
>>>> <snip>
>>>>
>>>> Digging a bit further the artifacting is also present when rebuilt with
>>>> --disable-asm.  It seems disable-asm might have made the bug shift
>>>> somewhere else under ffmpeg but not disappear when using the direct x264
>>>> application.  Also, the bug is readily apparent when using "-threads 16"
>>>> instead of "threads 31", so it doesn't appear related to the threading
>>>> support.
>>>>
>>>
>>> After fixing the bitrate (was off by a factor of 1000 due to differences
>>> between ffmpeg and x264 command line parameters) I'm unable to replicate
>>> the issue with the standalone x264 application.  This ffmpeg command
>>> line replicates the issue perfectly however:
>>>
>>> ffmpeg -r 30 -i Big_Buck_Bunny_first_23_seconds_1080p.ogv -r 30 -pix_fmt
>>> yuv422p -vcodec libx264 -preset ultrafast -x264opts
>>> keyint=30:min-keyint=30:scenecut=0 -b:v 25600k -bufsize 25600k -tune
>>> grain -threads 16 Big_Buck_Bunny_encoding_failure.mp4
>>>
>>> I'm assuming something might be off in the interface between libx264 and
>>> ffmpeg?  --disable-vsx did not help, --disable-asm completely resolved
>>> the problems.
>>>
>>> Screenshot of a corrupted frame:
>>> http://imgbin.ca/image.uploads/30-01-2019/original-206092b96120b5f748e06bd9e58e6df5.png
>>>
>>
>> I've tracked this down to the following two AltiVec functions:
>> x264_add8x8_idct_dc_altivec;
>> x264_add16x16_idct_dc_altivec;
>>
>> Disabling both of them, while leaving all other AltiVec functions
>> active, resolves the corruption.
>>
> 
> Trying to speed up encode I found that disabling trellis corrupted the
> output beyond recognition.  I also found that setting that flag in the
> native x264 application reproduced one of my original encoding problems
> seen under ffmpeg:
> 
> x264 --threads 16 --fps 30 --keyint 30 --min-keyint 30 --scenecut 0
> --preset ultrafast --tune grain --bitrate 25600 --trellis 0 -o
> Big_Buck_Bunny_encoding_failure.ogv
> Big_Buck_Bunny_first_23_seconds_1080p.ogv
> 
> Note that this test was run with the two problematic AltiVec functions
> above disabled.  Disabling all asm with --disable-asm fixes the problems
> with trellis=0.
> 
> Screenshot:
> http://imgbin.ca/image.uploads/30-01-2019/original-57d9eb4308cbdcbd46bc56b38bbae722.png
> 
> Hopefully this will be somewhat easier to debug now that ffmpeg is out
> of the picture!
> 

To be 100% sure it is out of the picture could you please convert the 
input to y4m and disable libavcodec and libavformat from your x264 build?

lu