[ffmpeg-qsv]Segmentation fault when uploading a 1080p rawvideo.

[a]

environment:

FFMPEG-QSV	CFL	OS: ubuntu 17.04	kernel: 4.15.0
	KBL	OS: ubuntu 16.04	kernel: 4.14.0-rc1
	SKL	OS: ubuntu 16.04	kernel: 4.15.0
			
libva	b6c50dad4d7d14c507108d9f468662e2d7ae1c4d	 https://github.com/01org/libva.git  ( master )
iHD Driver	ed04556a6676fd77ff845508bc54bfc60915450c	 https://github.com/intel/media-driver
libva-utils	9a10ad663349732decd668a426cfc349b0010d1d	 https://github.com/01org/libva-utils.git
Mediasdk	7ea683585f0f84f1bea035a405855312c92c46c0	 https://github.com/Intel-Media-SDK/MediaSDK
FFMPEG	56f68a099cc607658118e00cad30569103ae3751	 https://git.ffmpeg.org/ffmpeg.git

How to reproduce:

1.build env as above lists
2.ffmpeg -hwaccel qsv -init_hw_device qsv=hw -filter_hw_device hw -v verbose -f rawvideo -video_size 1920x1080 -pix_fmt nv12 -i ./123_217frame_1920x1080_blue_sky.yuv -an -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -g 30 -bf 3 -refs 3 -vframes 100 -vsync 0 -y ./H264e_multi_process_1920x1080P_3.h264
3.error message:
Segmentation fault (core dumped)

yuv file to large to upload

[Carl Eugen Hoyos]

Please provide backtrace, disassembly and register dump as explained on https://ffmpeg.org/bugreports.html to make this crash report a valid ticket.

[jkqxz]

That option combination doesn't obviously fail for me, though I don't have that specific input file. Backtrace / more information is needed, though it seems likely this is something inside libmfx.

[Zhong,Li]

Are you sure the input rawvideo is nv12 format? I guess it is yuv420p.
Please double-confirm it and try it again with -pix_fmt yuv420p:

ffmpeg -hwaccel qsv -init_hw_device qsv=hw -filter_hw_device hw -v verbose -f rawvideo -video_size 1920x1080 -pix_fmt yuv420p -i ./123_217frame_1920x1080_blue_sky.yuv -an -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -g 30 -bf 3 -refs 3 -vframes 100 -vsync 0 -y ./H264e_multi_process_1920x1080P_3.h264

[a]

I confirm this file is nv12.
And i tried with "-pix_fmt yuv420p" , it runs successfully.

[Carl Eugen Hoyos]

Both valgrind and backtrace Point to an issue outside of FFmpeg: Why did you set the issue to „reproduced“?
Only use „analysed“ if you add the information here into the ticket.

[Zhong,Li]

Replying to cehoyos:

Both valgrind and backtrace Point to an issue outside of FFmpeg: Why did you set the issue to „reproduced“?
Only use „analysed“ if you add the information here into the ticket.

Hi Carl: I have provided some info in the patch ​https://patchwork.ffmpeg.org/patch/10518/. Please be free to let me know if something wrong when you review the patch.

[Carl Eugen Hoyos]

Could you point me to the mfx documentation where this height alignment is required?

[Zhong,Li]

Alignment requirement is described in mediasdk-man.pdf (​https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.pdf) in a description of mfxFrameInfo structure: "Width and height of the video frame in pixels; Width must be a multiple of 16. Height must be a multiple of
16 for progressive frame sequence and a multiple of 32 otherwise."

[Carl Eugen Hoyos]

(I still wonder why jkqxz couldn't reproduce and why users didn't report this issue earlier - when was mfx support added?)

Why are you only checking height in your patch?

[Zhong,Li]

Replying to cehoyos:

(I still wonder why jkqxz couldn't reproduce and why users didn't report this issue earlier - when was mfx support added?)

It depends on resolution, not sure Mark(jkqxz) tried the specified resolution (1920x1080) or not.
About reasons why users didn't report this issues earlier, I guess should be:

1. Encoding from a raw nv12 video is not a very common case. Transcoding is more common case. Or encoding from a yuv420 rawvideo.
2. If someone want to encode from a nv12 raw video, the may use a system memory pipeline without hwuploading, just like ​https://trac.ffmpeg.org/ticket/5708.

Why are you only checking height in your patch?

src->linesize[0] is also checked.

[Zhong,Li]

Commid_id 681aa7d14f97fd98181ca6d61e11be48fe65692d has fixed this issue, though Mark suggested more checking with copy, not only this 1080p failed case.