bus error core dump in swscale optimizations on arm

[Peter Bennett]

This happened in MythTV (www.mythtv.org) in arm architecture only. In this instance MythTV uses sws_scale to convert a frame to RGB format without changing its size.

MythTV has a private copy of FFMPEG source (currently 3.2).

If input format is AV_PIX_FMT_YUV420P and output format is AV_PIX_FMT_BGRA, and the input and output sizes are the same, sws_scale fails with a bus error. If I use an output width 1 pixel less than input, it avoids some optimization and then works correctly.

Source code (look for #if ARCH_ARM at line 166).
​https://code.mythtv.org/trac/browser/mythtv/mythtv/libs/libmythtv/mythavutil.cpp

There is more info in this ticket
​https://code.mythtv.org/trac/ticket/12888

[Carl Eugen Hoyos]

Replying to peterbennett:

MythTV has a private copy of FFMPEG source (currently 3.2).

Making this bug report invalid.

Please test current FFmpeg git head (this is required for every bug report) and explain how the issue can be reproduced with ffmpeg (which does use the software scaler) and post all information needed to reproduce here.

[Peter Bennett]

Replying to cehoyos:

Please test current FFmpeg git head (this is required for every bug report) and explain how the issue can be reproduced with ffmpeg (which does use the software scaler) and post all information needed to reproduce here.

Thanks for looking at this. I will get that together in the next few days and update it here.

[Peter Bennett]

I tested this with the ffmpeg executable and I cannot reproduce it that way. I traced through ffmpeg and it does call the sws_scale in a slightly different way. When running the command line through ffmpeg there is the following message

[swscaler @ 0xad1c0] No accelerated colorspace conversion found from yuv420p to bgra.

The command line I used is

ffmpeg -ss 2.0 -i /path/filename -frames 1 -pix_fmt bgra imagefile.bmp

It produces an image file without failure, and seems to be the same thing we are trying to do.
I do not know the cause of our error. We have a workaround and if you see no bug in ffmpeg here, please close the ticket.

[Carl Eugen Hoyos]

Please add at least backtrace, disassembly and register dump for the crash in MythTV as explained on https://ffmpeg.org/bugreports.html

[Carl Eugen Hoyos]

Replying to peterbennett:

I tested this with the ffmpeg executable and I cannot reproduce it that way. I traced through ffmpeg and it does call the sws_scale in a slightly different way. When running the command line through ffmpeg there is the following message

[swscaler @ 0xad1c0] No accelerated colorspace conversion found from yuv420p to bgra.

Why is the line SET_FF_NVX_TO_ALL_RGBX_FUNC(yuv420p, YUV420P, accurate_rnd); that is mentioned on the MythTV bug tracker not called?

The command line I used is

ffmpeg -ss 2.0 -i /path/filename -frames 1 -pix_fmt bgra imagefile.bmp

(The console output may give an indication why the neon-optimized code is not called.)

It produces an image file without failure, and seems to be the same thing we are trying to do.
I do not know the cause of our error.

We have a workaround and if you see no bug in ffmpeg here, please close the ticket.

I suspect the work-around chosen is a very bad idea performance-wise.

[Peter Bennett]

Replying to cehoyos:

Why is the line SET_FF_NVX_TO_ALL_RGBX_FUNC(yuv420p, YUV420P, accurate_rnd); that is mentioned on the MythTV bug tracker not called?

This is FFMPEG code in FFmpeg/libswscale/arm/swscale_unscaled.c. I do not know if or why it is not called when I run ffmpeg executable.

(The console output may give an indication why the neon-optimized code is not called.)

I will rerun it and attach the console output here.

I suspect the work-around chosen is a very bad idea performance-wise.

Normally, I agree that it would not be advisable. However in this specific case the program is being run once to produce a single image for a preview, and it makes little difference if it takes some extra time.

[Peter Bennett]

I commented out my workaround, rebuilt and ran with gdb as requested. The result is here

​https://paste.ubuntu.com/24091281/

There are some quirks with raspberry pi gdb. Sometimes back trace is cut short with a 0x00000000 entry, as in this case.

Let me know if there is anything else I can do to help.

[Peter Bennett]

Here is the log from running ffmpeg to extract an image. I do not see any explanation why it did not use the accelerated colorspace conversion.

​https://paste.ubuntu.com/24091326/

[Carl Eugen Hoyos]

What does grep NEON config.h show in your build directory?

[Peter Bennett]

In FFMPEG build directory

pi@tardis ~/proj/github.com/FFmpeg/FFmpeg $ grep NEON config.h
#define HAVE_NEON 1
#define HAVE_NEON_EXTERNAL 0
#define HAVE_NEON_INLINE 0
#define HAVE_INTRINSICS_NEON 0
#define CONFIG_NEON_CLOBBER_TEST 0

In MythTV build directory where I build the local copy of ffmpeg for MythTV

pi@tardis ~/proj/github.com/bennettpeter/mythtv/mythtv/external/FFmpeg $ grep NEON config.h
#define HAVE_NEON 1
#define HAVE_NEON_EXTERNAL 0
#define HAVE_NEON_INLINE 0
#define HAVE_INTRINSICS_NEON 0
#define CONFIG_NEON_CLOBBER_TEST 0

[Carl Eugen Hoyos]

Then I don't know why you cannot test ff_yuv420p_to_bgra_neon() with ffmpeg.