[x264-devel] Disregard last email

[David Munday]

Thanks Sean,
I did something similar and it is now working. 

I appreciate your help,
David

-----Original Message-----
From: Sean McGovern [mailto:gseanmcg at gmail.com] 
Sent: Thursday, February 10, 2011 5:02 AM
To: Munday, David; Mailing List for x264 developers
Subject: Re: Disregard last email

To answer your question, yes that should be allowed to be zero, especially
with the option set you are giving to x264.

The real culprit is the way memalign() is implemented in Solaris. In
x264_macroblock_thread_allocate()[1], if h->param.rc.b_mb_tree is 0 and
threads is neither 'auto' nor 1 this results in scratch_size being 0. For
other operating systems such as MacOS X, this appears to not be a problem as
they will gladly return a valid pointer to a block of memory that is 0 bytes
in length. Solaris memalign() instead returns a NULL pointer which, due to
the test in CHECKED_MALLOC(), causes the error you are seeing.

The fix is to only call CHECKED_MALLOC() if scratch_size is non-zero.

On line 341, add:

if(scratch_size > 0) 

right before the CHECKED_MALLOC(), then rebuild and you should be OK from
there.

[1]
http://git.videolan.org/?p=x264.git;a=blob;f=common/macroblock.c;h=e559ab173
ba5ebe9b9e1bea94bcaf6c794b61a95;hb=HEAD#l314
-----Original Message-----
From: "David Munday" <cromom at soe.ucsc.edu>
Date: Wed, 9 Feb 2011 11:25:36
To: 'Sean McGovern'<gseanmcg at gmail.com>; 'Mailing list for x264
developers'<x264-devel at videolan.org>
Subject: RE: Disregard last email

Hi All,
I've found that my problem comes from the fact that h->param.rc.b_mb_tree is
set to 0.

Should this value be allowed to be 0? 

Thanks,
David

-----Original Message-----
From: Sean McGovern [mailto:gseanmcg at gmail.com]
Sent: Monday, February 07, 2011 11:08 PM
To: David Munday; Mailing list for x264 developers
Subject: Re: Disregard last email

I haven't ever explicitly used the --threads argument. so I have not seen
the issue you are experiencing. I have been able to duplicate it here with
those same arguments and foreman_cif.y4m. It's late here so I won't be able
to look at this any more tonight.

-- Sean

On Tue, Feb 8, 2011 at 1:53 AM, David Munday <cromom at soe.ucsc.edu> wrote:
> Thanks Sean. Are you running  multithreaded x264 on sparcv9 or sparcv8?
>
> If you have a working version on sparcv9, I wonder if you'd be willing 
> to share it with me?
>
> Thanks,
> David
>
>
>
> -----Original Message-----
> From: Sean McGovern [mailto:gseanmcg at gmail.com]
> Sent: Monday, February 07, 2011 9:55 PM
> To: David Munday
> Cc: Mailing List for x264 developers
> Subject: Re: Disregard last email
>
> x264-devel,
>
> Any ideas folks?
>
> On Mon, Feb 7, 2011 at 11:22 PM, David Munday <cromom at soe.ucsc.edu> wrote:
>> I just did a git pull. Ran configure like this: CFLAGS="-m64 -mcpu=v9"
>> LDFLAGS="-m64" ./configure --disable-asm
>>
>>
>>
>> Then built x264, then I ran it using:
>>
>>
>>
>> ./x264 --qp 20 --partitions b8x8,i4x4 --ref 5 --direct auto 
>> --b-pyramid normal --weightb --mixed-refs --no-fast-pskip --me umh 
>> --subme 7 --analyse
>> b8x8,i4x4 --threads 2 -o eledream.264 eledream_640x360_128.y4m
>>
>>
>>
>> And it outpur:
>>
>> y4m [info]: 640x360p 0:0 @ 25/1 fps (cfr)
>>
>> x264 [info]: using cpu capabilities: none!
>>
>> x264 [error]: malloc of size 0 failed
>>
>> x264 [error]: x264_encoder_open failed
>>
>>
>>
>> And then exited immediately.
>>
>>
>>
>> But it runs completely if I specify only one thread. Is multithreaded 
>> execution supported on sparcv9?
>>
>>
>>
>> Thanks,
>> David
>>
>>
>>
>>
>>
>> From: Sean McGovern [mailto:gseanmcg at gmail.com]
>> Sent: Monday, February 07, 2011 4:03 PM
>> To: David Munday
>>
>> Subject: Re: Disregard last email
>>
>>
>>
>> Yes.
>>
>>________________________________
>>
>> From: David Munday <cromom at soe.ucsc.edu>
>>
>> Date: Mon, 7 Feb 2011 15:59:24 -0800
>>
>> To: <gseanmcg at gmail.com>
>>
>> Subject: RE: Disregard last email
>>
>>
>>
>> I used git show-branch in that directory and it tells me "
>> [master] Hotfix for some bugs in VBV emergency "
>>
>> Should I do another pull?
>>
>> Thanks,
>> David
>>
>>________________________________
>>
>> From: Sean McGovern <gseanmcg at gmail.com>
>> Sent: Monday, February 07, 2011 11:27 AM
>> To: David Munday <cromom at soe.ucsc.edu>; Mailing List for x264 
>> developers <x264-devel at videolan.org>
>> Subject: Re: Disregard last email
>>
>> What version did you build? There was a git push last night.
>>
>> -- Sean
>>
>>________________________________
>>
>> From: "David Munday" <cromom at soe.ucsc.edu>
>>
>> Date: Mon, 7 Feb 2011 10:50:10 -0800
>>
>> To: <gseanmcg at gmail.com>
>>
>> Subject: Disregard last email
>>
>>
>>
>> Sorry Sean,
>>
>> I sent that message out prematurely I figured out the problem after I 
>> saw that quiet needed to be removed from the parameter list.
>>
>>
>>
>> I am having a different problem now though. X264 runs fine if I 
>> specify 1 thread. –threads 1, but if I specify 2 or more threads I get:
>>
>> y4m [info]: 640x360p 0:0 @ 25/1 fps (cfr)
>>
>> x264 [info]: using cpu capabilities: none!
>>
>> x264 [error]: malloc of size 0 failed
>>
>> x264 [error]: x264_encoder_open failed
>>
>>
>>
>>
>>
>> David
>>
>>
>>
>> From: Sean McGovern [mailto:gseanmcg at gmail.com]
>> Sent: Friday, February 04, 2011 7:40 PM
>> To: David Munday; Mailing List for x264 developers
>> Subject: Re: x264 for sparcV9
>>
>>
>>
>> Pass --disable-asm to configure, and then re-run gmake.
>>
>> Rebuilding often? Use gmake -j `/usr/sbin/psrinfo -p`
>>
>> Want to follow proper Solaris standards for library placement? Add
>> --libdir=\${exec_prefix}/lib/sparcv9 to configure, and then don't 
>> forget to symlink sparcv9 to '64' in the lib directory.
>>
>> -- Sean
>>
>>________________________________
>>
>> From: "David Munday" <cromom at soe.ucsc.edu>
>>
>> Date: Fri, 4 Feb 2011 19:11:01 -0800
>>
>> To: <gseanmcg at gmail.com>; 'Mailing List for x264 
>> developers'<x264-devel at videolan.org>
>>
>> Subject: RE: x264 for sparcV9
>>
>>
>>
>> Yes, I see your point, I added m64 to LDFLAGS but now I get the
following:
>>
>> gcc -o x264 x264.o input/input.o input/timecode.o input/raw.o 
>> input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o 
>> output/flv.o output/flv_bytestream.o filters/filters.o 
>> filters/video/video.o filters/video/source.o filters/video/internal.o 
>> filters/video/resize.o filters/video/cache.o 
>> filters/video/fix_vfr_pts.o filters/video/select_every.o 
>> filters/video/crop.o filters/video/depth.o input/thread.o 
>> extras/getopt.o libx264.a  -m64 -lm -lpthread -s
>>
>> Undefined                       first referenced
>>
>> symbol                             in file
>>
>> x264_pixel_sad_16x16_vis            libx264.a(pixel.o)
>>
>> x264_pixel_sad_8x8_vis              libx264.a(pixel.o)
>>
>> x264_pixel_sad_8x16_vis             libx264.a(pixel.o)
>>
>> x264_pixel_sad_16x8_vis             libx264.a(pixel.o)
>>
>> ld: fatal: Symbol referencing errors. No output written to x264
>>
>> collect2: ld returned 1 exit status
>>
>>
>>
>> I’m just using configure with the appropriate variables and running 
>> the Makefile as it came from the git repo. Do I need to tell it 
>> something else to not link in pixel.o?
>>
>>
>>
>> Thanks,
>> David
>>
>>
>>
>> From: Sean McGovern [mailto:gseanmcg at gmail.com]
>> Sent: Friday, February 04, 2011 7:01 PM
>> To: David Munday; Mailing List for x264 developers
>> Subject: Re: x264 for sparcV9
>>
>>
>>
>> Also, pixel.o shouldn't be built or linked in as its not 64-bit.
>>
>> -- Sean
>>
>>________________________________
>>
>> From: "David Munday" <cromom at soe.ucsc.edu>
>>
>> Date: Fri, 4 Feb 2011 18:38:31 -0800
>>
>> To: <gseanmcg at gmail.com>; 'Mailing List for x264 
>> developers'<x264-devel at videolan.org>
>>
>> Subject: RE: x264 for sparcV9
>>
>>
>>
>> Hi Sean,
>>
>> Thanks for the reply, I’m using gcc 4.3.2 and I ran configured with
>>
>> #CFLAGS=”-m64 mcpu=v9” ./configure
>>
>>
>>
>> And then ran gmake. Unfortunately, I’m getting a linking error 
>> related to the ELFCLASS of the x264.o object file. I’m thinking this 
>> is something simple that I’m not remembering. Would you mind taking a 
>> look at
> my build?
>>
>>
>>
>> I appreciate your help,
>>
>> David
>>
>>
>>
>>
>>
>> Here’s the last few lines of my build:
>>
>> gcc -Wshadow -O3 -ffast-math -m64 -mcpu=v9 -Wall -I. -std=gnu99 -s 
>> -fomit-frame-pointer -fno-tree-vectorize   -c -o common/threadpool.o 
>> common/threadpool.c
>>
>> as -xarch=v8plusa -DBIT_DEPTH=8 -o common/sparc/pixel.o 
>> common/sparc/pixel.asm
>>
>> ar rc libx264.a common/mc.o common/predict.o common/pixel.o 
>> common/macroblock.o common/frame.o common/dct.o common/cpu.o 
>> common/cabac.o common/common.o common/osdep.o common/re
>>
>> ctangle.o common/set.o common/quant.o common/deblock.o common/vlc.o 
>> common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o 
>> encoder/ratecontrol.o encoder/set.o encode
>>
>> r/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o 
>> encoder/lookahead.o common/threadpool.o common/sparc/pixel.o
>>
>> ranlib libx264.a
>>
>> gcc -o x264 x264.o input/input.o input/timecode.o input/raw.o 
>> input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o 
>> output/flv.o output/flv_bytestream.o filters/fil
>>
>> ters.o filters/video/video.o filters/video/source.o 
>> filters/video/internal.o filters/video/resize.o filters/video/cache.o 
>> filters/video/fix_vfr_pts.o filters/video/select_every.o 
>> filters/video/crop.o filters/video/depth.o input/thread.o 
>> extras/getopt.o libx264.a  -lm -lpthread -s
>>
>> ld: fatal: file x264.o: wrong ELF class: ELFCLASS64
>>
>> ld: fatal: File processing errors. No output written to x264
>>
>> collect2: ld returned 1 exit status
>>
>> gmake: *** [x264] Error 1
>>
>>
>>
>> From: Sean McGovern [mailto:gseanmcg at gmail.com]
>> Sent: Friday, February 04, 2011 4:27 PM
>> To: David Munday; Mailing List for x264 developers
>> Subject: Re: x264 for sparcV9
>>
>>
>>
>> No, it should compile stock provided you are using a recent version 
>> of gcc
>> -- 3.4.3 from Solaris 10 is ever so slightly on the old side. You 
>> might want to get your hands on GCCFSS or Blastwave. I built my own 
>> gcc 4.5.2 against SunFreeware's binutils package.
>>
>> I've been working with the x264 team to keep this building properly 
>> "out of the box" on SPARC.
>>
>> -- Sean
>>
>>________________________________
>>
>> From: "David Munday" <cromom at soe.ucsc.edu>
>>
>> Date: Fri, 4 Feb 2011 16:02:30 -0800
>>
>> To: <sean at seanmcgovern.ca>
>>
>> Subject: x264 for sparcV9
>>
>>
>>
>> Hi Sean,
>>
>> I’m a graduate student doing research with x264 and I need to compile 
>> a 64-bit version for sparcv9. I noticed that you are distributing 
>> solaris packages of exactly what I need, except I need to modify the
> source code.
>>
>>
>>
>> Did you have to do anything special to get x264 to compile for 64-bit 
>> other than pass m64 to the compiler?
>>
>>
>>
>> Thanks for your help,
>> David
>
>