Development list for x264, a free library for encoding H264/AVC video streams.

Mauricio Alvarez | 1 May 2006 11:09

Re: Compilation problem with x264 on Dual Opteron setup (SSE3)

Loren Merritt wrote:
> No, despite what intel would have you believe, SSE3 provides nothing at
> all for video codecs. We tried it, at there was no measurable speed
> difference.

And , what about the LDDQU (load quad word unaligned) instruction?

Can be this instruction useful in the motion estimation routines in
which there are access to macroblocks/sub-macroblock with misaligned
addresses?

Mauricio Alvarez

> 
> --Loren Merritt
>

headers

Guillaume POIRIER | 1 May 2006 11:48

Re: Compilation problem with x264 on Dual Opteron setup (SSE3)

Hi,

On 5/1/06, Mauricio Alvarez <alvarez <at> ac.upc.edu> wrote:
> Loren Merritt wrote:
> > No, despite what intel would have you believe, SSE3 provides nothing at
> > all for video codecs. We tried it, at there was no measurable speed
> > difference.
>
> And , what about the LDDQU (load quad word unaligned) instruction?
>
> Can be this instruction useful in the motion estimation routines in
> which there are access to macroblocks/sub-macroblock with misaligned
> addresses?

I made a patch that made use of this instruction, but since I don't
have any machine that supports SSE3, I wasn't able to test it.

It's available here, if you want:
http://tuxrip.free.fr/transperl/MPlayer/SSE3_lddqu.2.diff

I don't know if it still applies cleanly though.

The main problem of that patch is that it unconditionally replaces all
movdqu with lddqu, which isn't very smart. Intel optimization guide
does state quite clearly that it's not how it should be done.
What should be done is: instrument the code in a way that can tell you
what are the loads that are always badly unaligned, and use lddqu only
in these cases (loads that are sometimes aligned, sometimes not do not
benefit from using lddqu).

(Continue reading)

headers

Loren Merritt | 1 May 2006 23:15

Re: Compilation problem with x264 on Dual Opteron setup (SSE3)

On Mon, 1 May 2006, Guillaume POIRIER wrote:
> The main problem of that patch is that it unconditionally replaces all
> movdqu with lddqu, which isn't very smart. Intel optimization guide
> does state quite clearly that it's not how it should be done.
> What should be done is: instrument the code in a way that can tell you
> what are the loads that are always badly unaligned, and use lddqu only
> in these cases (loads that are sometimes aligned, sometimes not do not
> benefit from using lddqu).

All the variants of SAD are unaligned, SATD and SSD are usually aligned.

--Loren Merritt

headers

Pedro Tumusok | 2 May 2006 16:29

Re: Compilation problem with x264 on Dual Opteron setup

On 4/29/06, Pedro Tumusok <pedro.tumusok <at> gmail.com> wrote:

Hi,

We are getting the following error msgs when trying to compile x264 on a machine with dual opteron 280 cpu's.

/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a( dct-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(cpu-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(pixel-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(mc-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(mc-a2.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(predict-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(pixel-sse2.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(quant-a.o)' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `libx264.a(deblock-a.o)' is incompatible with i386 output

Seems the problem was that we where running Debian Sarge which is 32bit and compiled x264 as 64 bit.
Did a reinstall of the server from the testing/etch and then the msg above went away.
But now we get the following msgs from VLC, I know its not just x264, but if anybody got any pointers, it would be appreciated.

cannot load module `/usr/local/lib/vlc/codec/libx264_plugin.so' (libx264.so.46: cannot open shared object file: No such file or directory)

jpt <at> farnsworth:/usr/local/lib/vlc/codec$ ls -l
total 588
-rwxr-xr-x 1 root staff 14722 2006-05-02 18:08 liba52_plugin.so
-rwxr-xr-x 1 root staff 21850 2006-05-02 18:08 libadpcm_plugin.so
-rwxr-xr-x 1 root staff 26261 2006-05-02 18:08 libaraw_plugin.so
-rwxr-xr-x 1 root staff 15232 2006-05-02 18:08 libcinepak_plugin.so
-rwxr-xr-x 1 root staff 44484 2006-05-02 18:08 libcmml_plugin.so
-rwxr-xr-x 1 root staff 15329 2006-05-02 18:08 libcvdsub_plugin.so
-rwxr-xr-x 1 root staff 15985 2006-05-02 18:08 libdts_plugin.so
-rwxr-xr-x 1 root staff 123271 2006-05-02 18:08 libdvbsub_plugin.so
-rwxr-xr-x 1 root staff 13446 2006-05-02 18:08 libfake_plugin.so
-rwxr-xr-x 1 root staff 87327 2006-05-02 18:08 libffmpeg_plugin.so
-rwxr-xr-x 1 root staff 17579 2006-05-02 18:08 libflacdec_plugin.so
-rwxr-xr-x 1 root staff 15502 2006-05-02 18:08 liblibmpeg2_plugin.so
-rwxr-xr-x 1 root staff 11736 2006-05-02 18:08 liblpcm_plugin.so
-rwxr-xr-x 1 root staff 15380 2006-05-02 18:08 libmpeg_audio_plugin.so
-rwxr-xr-x 1 root staff 11772 2006-05-02 18:08 librawvideo_plugin.so
-rwxr-xr-x 1 root staff 16444 2006-05-02 18:08 libspudec_plugin.so
-rwxr-xr-x 1 root staff 24365 2006-05-02 18:08 libsubsdec_plugin.so
-rwxr-xr-x 1 root staff 15457 2006-05-02 18:08 libsvcdsub_plugin.so
-rwxr-xr-x 1 root staff 23110 2006-05-02 18:08 libvorbis_plugin.so
-rwxr-xr-x 1 root staff 29031 2006-05-02 18:08 libx264_plugin.so

--
Best regards / Mvh
Jan Pedro Tumusok

Another fella told me, he had a sister who looked just fine.
Instead of bein' my deliv'rance, she had a strange resemblance
To a cat named Frankenstein

headers

Guillaume POIRIER | 2 May 2006 22:15

Re: Compilation problem with x264 on Dual Opteron setup (SSE3)

Hi,

On 5/1/06, Loren Merritt <lorenm <at> u.washington.edu> wrote:
> On Mon, 1 May 2006, Guillaume POIRIER wrote:
> > The main problem of that patch is that it unconditionally replaces all
> > movdqu with lddqu, which isn't very smart. Intel optimization guide
> > does state quite clearly that it's not how it should be done.
> > What should be done is: instrument the code in a way that can tell you
> > what are the loads that are always badly unaligned, and use lddqu only
> > in these cases (loads that are sometimes aligned, sometimes not do not
> > benefit from using lddqu).
>
> All the variants of SAD are unaligned, SATD and SSD are usually aligned.

Okay, here's an updated version of the patch that only uses lddqu in
sad routines: http://tuxrip.free.fr/transperl/MPlayer/SSE3_lddqu.3.diff

Please test and report if it helps a bit (I doubt it).

Guillaume
--
I am disillusioned enough to know that no man's opinion on any subject
is worth a damn unless backed up with enough genuine information to
make him really know what he's talking about.

-- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists)
http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html

headers

Pedro Tumusok | 3 May 2006 01:20

Re: Compilation problem with x264 on Dual Opteron setup

On 5/2/06, Pedro Tumusok <pedro.tumusok <at> gmail.com> wrote:

Seems the problem was that we where running Debian Sarge which is 32bit and compiled x264 as 64 bit.
Did a reinstall of the server from the testing/etch and then the msg above went away.
But now we get the following msgs from VLC, I know its not just x264, but if anybody got any pointers, it would be appreciated.

cannot load module `/usr/local/lib/vlc/codec/libx264_plugin.so' (libx264.so.46: cannot open shared object file: No such file or directory)

Okay the solution was to add /usr/local/lib to the /etc/ld.so.conf file and run ldconfig. Then a re-compile of x264 and VLC and it worked.

--
Best regards / Mvh
Jan Pedro Tumusok

Another fella told me, he had a sister who looked just fine.
Instead of bein' my deliv'rance, she had a strange resemblance
To a cat named Frankenstein

headers

Pedro Tumusok | 3 May 2006 11:49

Another CPU related question

Hi,

Since my innocent SSE3 questions spurned some replies, I tought I should ask another questions.

The Cell cpu from IBM/Sony el, the PPU is some sort of PPC and according to what I read, PPC software should be recompilable and able to run on the Cell. Albeit without using the SPU's, and according to different presentations and concept proofs etc, the Cell with SPU is a streaming device ie it can use the SPU's to offload bits of work.

There has been some articles about it being able to decode 48 mpeg2 streams at once or something like that, so then to my question, do you belive it would be able to show similar kind of performance in encoding?

--
Best regards / Mvh
Jan Pedro Tumusok

Another fella told me, he had a sister who looked just fine.
Instead of bein' my deliv'rance, she had a strange resemblance
To a cat named Frankenstein

headers

Steven Tondeur | 3 May 2006 16:25

Bug in expanding borders to mod16?

Hi all,

I think I found a small bug in x264_frame_expand_border_mod16    (frame.c).
At line 257, the loop for expanding vertically is immediately followed 
by a semicolon :

for( y = i_height; y < i_height + i_pady; y++ );
    memcpy(....)

Shouldn't it be removed?

Regards,
Steven

headers

Andrea Barbieri | 3 May 2006 16:57

Re: Bug in expanding borders to mod16?

Hello,

looking back at the commits history, x264_frame_expand_border_mod16 was
introduced in Revision 327 and never changed since then.

looks like a typo to me...

andrea

ST:=Steven Tondeur

ST> Hi all,
ST> 
ST> I think I found a small bug in x264_frame_expand_border_mod16    (frame.c).
ST> At line 257, the loop for expanding vertically is immediately followed by a
ST> semicolon :
ST> 
ST> for( y = i_height; y < i_height + i_pady; y++ );
ST>    memcpy(....)
ST> 
ST> Shouldn't it be removed?
ST> 
ST> Regards,
ST> Steven
ST> 
ST> 

--

-- 
Andrea Barbieri
KeyID=0x034DFD5A
KeyFingerprint=C1 68 EA 9A 71 89 53 8D  21 4F 12 81 A7 52 9F 32  03 4D FD 5A
Moving Image Research, The Workshop, Hampton Lane, Bristol, BS6 6LE, UK
Tel +44 117 9732200, FAX +44 117 9732210
http://www.movingimageresearch.com/

headers

Loren Merritt | 3 May 2006 19:30

Re: Another CPU related question

On Wed, 3 May 2006, Pedro Tumusok wrote:

> Hi,
>
> Since my innocent SSE3 questions spurned some replies, I tought I should ask
> another questions.
>
> The Cell cpu from IBM/Sony el, the PPU is some sort of PPC and according to
> what I read, PPC software should be recompilable and able to run on the
> Cell. Albeit without using the SPU's, and according to different
> presentations and concept proofs etc, the Cell with SPU is a streaming
> device ie it can use the SPU's to offload bits of work.
>
> There has been some articles about it being able to decode 48 mpeg2 streams
> at once or something like that, so then to my question, do you belive it
> would be able to show similar kind of performance in encoding?

48 mpeg2 streams? You don't need a Cell for that, unless they're 1080p or 
something. A dvd takes 2% cpu on my Athlon64 3400, so the only thing 
preventing me from displaying 48 of them is bandwidth to the harddrive 
and video card.

--Loren Merritt

13	May 2013
98	April 2013
45	March 2013
72	February 2013
62	January 2013
44	December 2012
64	November 2012
67	October 2012
41	September 2012
74	August 2012
77	July 2012
17	June 2012
45	May 2012
40	April 2012
96	March 2012
117	February 2012
120	January 2012
42	December 2011
19	November 2011
53	October 2011
55	September 2011
96	August 2011
83	July 2011
80	June 2011
72	May 2011
76	April 2011
62	March 2011
103	February 2011
112	January 2011
82	December 2010
135	November 2010
60	October 2010
107	September 2010
80	August 2010
140	July 2010
163	June 2010
128	May 2010
104	April 2010
96	March 2010
172	February 2010
159	January 2010
62	December 2009
93	November 2009
102	October 2009
154	September 2009
137	August 2009
122	July 2009
48	June 2009
79	May 2009
80	April 2009
98	March 2009
110	February 2009
225	January 2009
111	December 2008
110	November 2008
109	October 2008
132	September 2008
80	August 2008
111	July 2008
109	June 2008
86	May 2008
154	April 2008
242	March 2008
45	February 2008
123	January 2008
59	December 2007
148	November 2007
96	October 2007
37	September 2007
71	August 2007
100	July 2007
103	June 2007
105	May 2007
113	April 2007
145	March 2007
77	February 2007
169	January 2007
101	December 2006
109	November 2006
84	October 2006
94	September 2006
125	August 2006
79	July 2006
66	June 2006
107	May 2006
102	April 2006
136	March 2006
108	February 2006
60	January 2006
65	December 2005
76	November 2005
141	October 2005
76	September 2005
77	August 2005
115	July 2005
73	June 2005
140	May 2005
131	April 2005
83	March 2005
19	February 2005

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31