[FFmpeg-user] Compiling FFMPEG 2.8.7 fails testing

[MacFH - C E Macfarlane]

Sorry for the delay in replying and thanking you ... been rather busy.  Please see detailed response below ...

> -----Original Message-----
> From: ffmpeg-user [mailto:ffmpeg-user-bounces at ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: 25 August 2016 16:56
> To: FFmpeg user questions
> Subject: Re: [FFmpeg-user] Compiling FFMPEG 2.8.7 fails testing
> 
> Hi!
> 
> 2016-08-25 13:26 GMT+02:00 MacFH - C E Macfarlane
> <c.e.macfarlane at macfh.co.uk>:
> > I know that this group only applies to latest gits, but I'm not ready
> > to use FFMPEG v3, and so am using the last version of 2, and searching
> > for this error didn't find anything useful, so I hope you can help ...
> 
> There are three possibilities:
> 
> There is a bug in 2.8 that was fixed meanwhile.
> If you test current git head, you will immediately find out and be able to fix
> your issue.
> (No effort for me.)
> 
> The bug you found still exists.
> In this case, I will try to reproduce, meaning I have to find an arm system, find
> out which of your compilation option triggers the issue, etc, (A major effort
> for me.)
> 
> There is a compiler bug.
> This situation is more difficult;-(
> Please make sure you are neither using an old, nor a compiler with a low
> micro version number.

I have no choice but use:
	~ # gcc --version
	gcc (GCC) 4.2.3

I've tried to use that version to build on the NAS itself more recent versions of GCC, but the problem is that I do not have the OEM header files, only some others for a similar device, and every time the build has failed.  Perhaps I'll be able to make it work eventually, each time I try I seem to get a little further, but it's all incredibly time consuming and frustrating.

> What I am trying to say is: Of course it is easier for me if you do not test
> current git head, but for FFmpeg users in general (and you), it may make
> more sense if you'd test it.

As you suggested above, I've downloaded the latest version FFMPEG 3.1.3 and tried building that, but the results are far, far worse.  Configure and make each complete without error, but ...
	make -k SAMPLES=fate-suite fate
... results in so many errors that I've had to log them all and put them in a zip:
	www.macfh.co.uk/Temp/FFMPEG_3-1-3_Make_Fate_Errors.zip

Er, happy bedtime reading :-)

> [...]
> 
> > ./configure --prefix=/opt/share  --enable-libx264 --enable-small
> > --enable-gpl --enable-shared --disable-debug
> > --disable-runtime-cpudetect --disable-doc --disable-armv6
> > --disable-armv6t2 --disable-neon --disable-vfp
> > --disable-vfpv3
> 
> I suspect --disable-runtime-cpudetect is never useful.
> Are you really using FFmpeg on arm hardware without neon support?

I've never got any version of FFMPEG to compile without disabling neon support.  Given that this is an OEM device, I suppose it's quite possible that there isn't actually an FPU unit installed?

> > 4)      make check
> 
> This is not the suggested method to test FFmpeg (I sincerely hope it is not
> mentioned somewhere in the documentation), "make fate" is.
> 
> To continue tests after a failure, use "make -k fate" (not FFmpeg-related).

Now done with the original build.  It was several days ago now, but AFAICR there was only one or two other check/fate errors in functionality that I'm unlikely to need, so it may be that I can install and use that build satisfactorily.  I have to go out now, but I'll check it out this evening.

Thanks and regards.
Charles.