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

[Timothy Pearson]

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.

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com