AV_HWDEVICE_TYPE_NONE was not declared

[cwilling]

I see that recent FFMpegReader.h has:

#if IS_FFMPEG_3_2
		AVPixelFormat hw_de_av_pix_fmt = AV_PIX_FMT_NONE;
		AVHWDeviceType hw_de_av_device_type = AV_HWDEVICE_TYPE_NONE;
#endif

However AV_HWDEVICE_TYPE_NONE is not defined in ffmpeg until version 4 (git tag n4.0), despite the suggestion in doc/ HW-ACCEL.md that:

HW accel is supported from FFmpeg version 3.2 (3.3 for nVidia drivers)

Having searched various ffmpeg git tags, I think that claim is wrong. Maybe some distros have somehow backlported the hardware acceleraton stuff from 4.x to earlier versions (unlikely?).

As a result, libopenshot-0.2.4 cannot build with (for instance) ffmpeg-3.2.4 with error:

/var/tmp/SBo/libopenshot-0.2.4/src/../include/FFmpegReader.h:152:41: error: 'AV_HWDEVICE_TYPE_NONE' was not declared in this scope
   AVHWDeviceType hw_de_av_device_type = AV_HWDEVICE_TYPE_NONE;

[ferdnyc]

@cwilling

You're right that AV_HWDEVICE_TYPE_NONE isn't defined in FFmpeg 3.2, so FFmpegReader shouldn't be using it there. It was actually added in FFmpeg 3.4,so it's valid for any later FFmpeg release.

The hardware-decoding support definitely is present in FFmpeg 3.2, though — it's just that in 3.2, the enum didn't include a _NONE value.

(AFAICT it was only meant to be used in situations where HW decoding is supported, and in other situations wouldn't be referenced at all. Which makes for a weird API that the FFmpeg developers presumably thought better of, hence the addition of _NONE in 3.4.)

Our original FFmpeg 3.2 support initialized hw_de_av_device_type to AV_HWDEVICE_TYPE_VAAPI:

libopenshot/include/FFmpegReader.h

Lines 149 to 153 in 514cb11

	int hw_de_supported = 0; // Is set by FFmpegReader
	#if IS_FFMPEG_3_2
	AVPixelFormat hw_de_av_pix_fmt = AV_PIX_FMT_NONE;
	AVHWDeviceType hw_de_av_device_type = AV_HWDEVICE_TYPE_VAAPI;
	#endif

It looks like for 3.2 that's what we'll have to revert to doing, while 3.4 and higher can use _NONE.

[ferdnyc]

I tracked down an FFmpeg 3.2 PPA for Ubuntu Xenial, and added an additional build to our Travis matrix to test FFmpeg 3.2 specifically. Which revealed that the missing AV_HWDEVICE_TYPE_NONE isn't the only issue building libopenshot with FFmpeg 3.2. I'll have to work out fixes for the rest of the issues, as well.

Thanks for pointing this out! Clearly not having FFmpeg 3.2 in our CI matrix has allowed our support to slip quite a bit.

[ferdnyc]

As the title of #436 says, further investigation has revealed that our HW acceleration code never actually supported FFmpeg 3.2 at all. I've opened #437 to limit hw-accel support to FFmpeg 3.4+ only, building with FFmpeg 3.2 will no longer attempt to use hardware acceleration.

[cwilling]

Thanks! I extracted a patch from #437 and applied to libopenshot-0.2.4 which now builds fine.