[FFmpeg-devel] AAC decoder corrups memory?

[Pavel Pavlov]

> >> ICL is not a supported compiler for FFmpeg. See:
> >> blab la bla
> >
> > If you don't want to try to run ffplay, then why bother replying at
> > all?
> 
> We've tried those files, and they all play without a glitch for us.
> 
> > Does ffmpeg contain some dirty magic
> 
> Not dirty, but magic for sure.
> 
> > or intel compiler sucks beyond all belief,
> 
> FATE says yes.
> 

Yes to what? That's what fate tells me:
  [Thu Mar 18 00:32:59 2010] 350 / 350 tests passed


Since I'm using cygwin and building with visual studio I had to do some minor fixes to the fate script. At first it would simply hang and did nothing at all. It appeared that sometimes it would block inside select.select call. I changed it to be ifd = select.select([so_fd, se_fd], [], [], 1). (the outer loop calls that select repeatedly anyways).
The other problem is that os.kill was frequently throwing exception, so I had to pass on OSError exception:
            try:
                os.kill(real_pid, signal.SIGTERM)
            except OSError:
                pass # exited?

I resolved the corruption problem and found out what was the source of strange corruptions and missing back trace.
A while ago, there were some changes to rtp code. Since I don't use configure script I always need to add or remove files from visual studio solution. That time some files were added and some were deleted. I got a link error (missing symbols) and tried to search entire src tree for these symbols: ff_ms_rtp_asf_pfv_handler and ff_ms_rtp_asf_pfa_handler. All I was able to find was that they were declared in a header (rtpdec_asf.h), referenced in rtpdec.c but weren't anywhere defined. Since I don't use that rtp code and I keep a copy of unmodified ffmpeg tree I simply had no choice but to include missing declarations from that copy to quickly resolve that link issue (I was thinking that some changes in ffmpeg svn broke the build and didn't worry thinking that it would be fixed soon). So, my build kept on compiling some parts of ffmpeg from another location. As I don't regularly do svn updates the two copies became more and more different which eventually over long time period led to this hidden corruption. WTF would somebody write it like that: Declare variables in an h file and then use some macro to create them. Because these were declared as variables in an h file and because these weren't defined in any *.c file I thought either it was a bug or this code was removed from ffmpeg, but I didn't even have slightest idea that it could possibly be done that way. At least there should have been a comment like: 
  //define ff_ms_rtp_asf_pfv_handler, ff_ms_rtp_asf_pfa_handler trough a macro:
So that at least global search could find these. After I was debugging for a LONG time I decided to build other version and it worked, after comparing the two trees I found out what was the problem.
So, I apologize for making noise, that was my own problem and ffmpeg is all fine with aac :)

thanks


> > so that .c transferred to binaries using anything other gcc become
> > corrupted??
> 
> We support non-gcc compilers provided they don't suck.
> 

FATE says that icl does not suck ;)