Opened 10 months ago

Last modified 10 months ago

#6192 new defect

bus error core dump in swscale optimizations on arm

Reported by: peterbennett Owned by:
Priority: normal Component: swscale
Version: 3.2.1 Keywords: crash
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Change History (13)

comment:1 Changed 10 months ago by peterbennett

  • Component changed from undetermined to swscale

comment:2 in reply to: ↑ description ; follow-up: Changed 10 months ago by cehoyos

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.

comment:3 Changed 10 months ago by cehoyos

  • Keywords crash added

comment:4 in reply to: ↑ 2 Changed 10 months ago by peterbennett

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.

comment:5 follow-up: Changed 10 months ago by 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.

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.

comment:6 Changed 10 months ago by cehoyos

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

comment:7 in reply to: ↑ 5 ; follow-up: Changed 10 months ago by cehoyos

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.

comment:8 in reply to: ↑ 7 Changed 10 months ago by peterbennett

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.

comment:9 Changed 10 months ago by peterbennett

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.

comment:10 Changed 10 months ago by peterbennett

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/

comment:11 Changed 10 months ago by cehoyos

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

comment:12 Changed 10 months ago by peterbennett

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

comment:13 Changed 10 months ago by cehoyos

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

Note: See TracTickets for help on using tickets.