From alvarez at ac.upc.edu  Mon May  1 11:09:05 2006
From: alvarez at ac.upc.edu (Mauricio Alvarez)
Date: Mon, 01 May 2006 11:09:05 +0200
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron
 setup (SSE3)
In-Reply-To: <Pine.A41.4.64.0604291007100.188796@dante65.u.washington.edu>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>  <Pine.A41.4.64.0604281936001.157936@dante65.u.washington.edu> <aa7a75950604290324y6bfea683t9cd21ca77f486aa4@mail.gmail.com> <Pine.A41.4.64.0604291007100.188796@dante65.u.washington.edu>
Message-ID: <4455D031.5030201@ac.upc.edu>

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
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From poirierg at gmail.com  Mon May  1 11:48:10 2006
From: poirierg at gmail.com (Guillaume POIRIER)
Date: Mon, 1 May 2006 11:48:10 +0200
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron setup (SSE3)
In-Reply-To: <4455D031.5030201@ac.upc.edu>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>
	 <Pine.A41.4.64.0604281936001.157936@dante65.u.washington.edu>
	 <aa7a75950604290324y6bfea683t9cd21ca77f486aa4@mail.gmail.com>
	 <Pine.A41.4.64.0604291007100.188796@dante65.u.washington.edu>
	 <4455D031.5030201@ac.upc.edu>
Message-ID: <4e03026a0605010248k6106f3d0ob9ce159b4f59ed9d@mail.gmail.com>

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).

In any cases, I doubt lddqu can bring any benefit to K8 cores. It's
probably only useful for prescott cores.

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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Mon May  1 23:15:11 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Mon, 1 May 2006 14:15:11 -0700 (PDT)
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron
 setup (SSE3)
In-Reply-To: <4e03026a0605010248k6106f3d0ob9ce159b4f59ed9d@mail.gmail.com>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com> 
 <Pine.A41.4.64.0604281936001.157936@dante65.u.washington.edu> 
 <aa7a75950604290324y6bfea683t9cd21ca77f486aa4@mail.gmail.com> 
 <Pine.A41.4.64.0604291007100.188796@dante65.u.washington.edu> 
 <4455D031.5030201@ac.upc.edu> <4e03026a0605010248k6106f3d0ob9ce159b4f59ed9d@mail.gmail.com>
Message-ID: <Pine.A41.4.64.0605011412170.16726@dante68.u.washington.edu>

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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From pedro.tumusok at gmail.com  Tue May  2 16:29:27 2006
From: pedro.tumusok at gmail.com (Pedro Tumusok)
Date: Tue, 2 May 2006 16:29:27 +0200
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron setup
In-Reply-To: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>
Message-ID: <aa7a75950605020729y3eeb5275q997b3e2131aec3fa@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060502/1fc8002b/attachment.htm 

From poirierg at gmail.com  Tue May  2 22:15:47 2006
From: poirierg at gmail.com (Guillaume POIRIER)
Date: Tue, 2 May 2006 22:15:47 +0200
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron setup (SSE3)
In-Reply-To: <Pine.A41.4.64.0605011412170.16726@dante68.u.washington.edu>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>
	 <Pine.A41.4.64.0604281936001.157936@dante65.u.washington.edu>
	 <aa7a75950604290324y6bfea683t9cd21ca77f486aa4@mail.gmail.com>
	 <Pine.A41.4.64.0604291007100.188796@dante65.u.washington.edu>
	 <4455D031.5030201@ac.upc.edu>
	 <4e03026a0605010248k6106f3d0ob9ce159b4f59ed9d@mail.gmail.com>
	 <Pine.A41.4.64.0605011412170.16726@dante68.u.washington.edu>
Message-ID: <4e03026a0605021315o17bc59dapc5e3534728705203@mail.gmail.com>

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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From pedro.tumusok at gmail.com  Wed May  3 01:20:48 2006
From: pedro.tumusok at gmail.com (Pedro Tumusok)
Date: Wed, 3 May 2006 01:20:48 +0200
Subject: [x264-devel] Re: Compilation problem with x264 on Dual Opteron setup
In-Reply-To: <aa7a75950605020729y3eeb5275q997b3e2131aec3fa@mail.gmail.com>
References: <aa7a75950604281749i3c8b30aet8137e87ca27e0cf9@mail.gmail.com>
	 <aa7a75950605020729y3eeb5275q997b3e2131aec3fa@mail.gmail.com>
Message-ID: <aa7a75950605021620q7175e8e2p711e58f3696f8c6a@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060503/55d4f91a/attachment.htm 

From pedro.tumusok at gmail.com  Wed May  3 11:49:29 2006
From: pedro.tumusok at gmail.com (Pedro Tumusok)
Date: Wed, 3 May 2006 11:49:29 +0200
Subject: [x264-devel] Another CPU related question
Message-ID: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060503/6317e4cf/attachment.htm 

From stondeur at etro.vub.ac.be  Wed May  3 16:25:45 2006
From: stondeur at etro.vub.ac.be (Steven Tondeur)
Date: Wed, 03 May 2006 16:25:45 +0200
Subject: [x264-devel] Bug in expanding borders to mod16?
Message-ID: <4458BD69.4040901@etro.vub.ac.be>

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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From andrea.barbieri at movingimageresearch.com  Wed May  3 16:57:34 2006
From: andrea.barbieri at movingimageresearch.com (Andrea Barbieri)
Date: Wed, 3 May 2006 15:57:34 +0100 (BST)
Subject: [x264-devel] Re: Bug in expanding borders to mod16?
In-Reply-To: <4458BD69.4040901@etro.vub.ac.be>
References: <4458BD69.4040901@etro.vub.ac.be>
Message-ID: <Pine.GSO.4.64.0605031548110.23909@cherenkov>

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/

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Wed May  3 19:30:47 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Wed, 3 May 2006 10:30:47 -0700 (PDT)
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>
Message-ID: <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>

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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Wed May  3 19:59:23 2006
From: svn at videolan.org (Subversion daemon)
Date: Wed,  3 May 2006 19:59:23 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r517 (pengvado)
Message-ID: <20060503175923.67A73113C@ganesh.videolan.org>

r517 | pengvado | 2006-05-03 19:59:23 +0200 (Wed, 03 May 2006) | 3 lines
Changed paths:
   M /trunk/common/frame.c
   M /trunk/encoder/ratecontrol.c

typo in expand_border_mod16


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From jelle-x264-devel at foks.8m.com  Wed May  3 23:20:58 2006
From: jelle-x264-devel at foks.8m.com (Jelle)
Date: Wed, 03 May 2006 17:20:58 -0400
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com> <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>
Message-ID: <44591EBA.3050301@foks.8m.com>

Loren Merritt wrote:
> 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.

That 2% is achieved by offloading a lot of the work to the videocard 
(which does the idct and the mc). Unless you have 48 video cards in your 
system, it will not be able to decode 48 mpeg streams.

Jelle.

> 
> --Loren Merritt
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Wed May  3 23:54:23 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Wed, 3 May 2006 14:54:23 -0700 (PDT)
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <44591EBA.3050301@foks.8m.com>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>
 <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>
 <44591EBA.3050301@foks.8m.com>
Message-ID: <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu>

On Wed, 3 May 2006, Jelle wrote:
> Loren Merritt wrote:
>> On Wed, 3 May 2006, Pedro Tumusok wrote:
>> 
>>> 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.
>
> That 2% is achieved by offloading a lot of the work to the videocard (which 
> does the idct and the mc). Unless you have 48 video cards in your system, it 
> will not be able to decode 48 mpeg streams.

No, I don't know whether my videocard supports xvmc, but I certainly 
haven't enabled it in ffmpeg. This is cpu-time as measured by
`time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From stankovic.marko at gmail.com  Fri May  5 01:44:37 2006
From: stankovic.marko at gmail.com (Marko Stankovic)
Date: Fri, 05 May 2006 01:44:37 +0200
Subject: [x264-devel] Re: Bad x264.pc
In-Reply-To: <4450FF59.6000407@gmail.com>
References: <4450FF59.6000407@gmail.com>
Message-ID: <445A91E5.9070502@gmail.com>

Have someone noted my previous post?
I think adding this (or something similar) in "configure" script (at 
line 393) would help:
--- begin of code ---
if test "$vis" = "yes" ; then
   case $SYS in
     MINGW|CYGWIN|BEOS)
       ;;
     *) pclibs="$pclibs -L/usr/X11R6/lib -lX11"
       ;;
   esac
fi
--- end of code ---

Marko Stankovic wrote:
> Hello, x264-developers!
> I've compiled x264 with pthread and visualize options enabled, but 
> mplayer didn't detected x264. After checking mplayer's config.log I 
> found that problem is in x264.pc file which is not including 
> -L/usr/X11R6/lib -lX11 in "Libs" section.
> Manually including that in x264.pc resolved the problem.
> So I suggest you to include a check if visualize is enabled (in 
> configure script) and in that case add above mentioned string to x264.pc
> 
> Cheers,

-- 
++ Marko Stankovic ++ Registered Linux User #361318 [counter.li.org]
== www.kapiraj.org ==
Emancipate yourselves from mental slavery;
None but ourselves can free our minds.
           Bob Marley, "Redemption Song"

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From jelle-x264-devel at foks.8m.com  Fri May  5 19:45:22 2006
From: jelle-x264-devel at foks.8m.com (Jelle)
Date: Fri, 05 May 2006 13:45:22 -0400
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com> <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu> <44591EBA.3050301@foks.8m.com> <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu>
Message-ID: <445B8F32.8090702@foks.8m.com>

Loren Merritt wrote:
> On Wed, 3 May 2006, Jelle wrote:
> 
>> Loren Merritt wrote:
>>
>>> On Wed, 3 May 2006, Pedro Tumusok wrote:
>>>
>>>> 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.
>>
>>
>> That 2% is achieved by offloading a lot of the work to the videocard 
>> (which does the idct and the mc). Unless you have 48 video cards in 
>> your system, it will not be able to decode 48 mpeg streams.
> 
> 
> No, I don't know whether my videocard supports xvmc, but I certainly 
> haven't enabled it in ffmpeg. This is cpu-time as measured by
> `time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.

Ok, I'll run that too then.

Two different machines. I know for sure that neither machines have 
videocards that support Xvmc.

============ Test 1:

Athlon64 3200+ (2GHz/512kb cache)

MPEG2 video 480x576 at 25fps, 2.5Mbit/s (much less than DVD), 4688 seconds 
long.

BENCHMARKs: VC: 612.046s VO:   0.648s A:   0.000s Sys: 127.753s =  740.447s
BENCHMARK%: VC: 82.6589% VO:  0.0875% A:  0.0000% Sys: 17.2535% = 100.0000%

Exiting... (End of file)

real    12m20.753s
user    9m0.006s
sys     0m10.123s

100 * 12*60+20/4688 =~ 16% CPU.

============ Test 2:

P4/3GHz/1M cache

MPEG2 video 720x480 at 29.97fps, 4.5Mbit/s, 1886 seconds long

BENCHMARKs: VC: 224.833s VO:   0.710s A:   0.000s Sys:  24.075s =  249.618s
BENCHMARK%: VC: 90.0707% VO:  0.2846% A:  0.0000% Sys:  9.6446% = 100.0000%

Exiting... (End of file)

real    4m11.951s
user    3m51.214s
sys     0m9.968s

100 * 4*60+12/1886 =~ 13% CPU.

I don't know where you got 2%, but I can't reproduce anything even close 
to it.

2% of a 2.2GHz CPU, or 44MHz, for DVD video? How can I get that?

mpeg2 decoding takes about the same amount of operations per frame as 
JPEG (mjpeg) encoding. If your 2% number is really valid, you should be 
able to transcode mpeg2 to mjpeg 25 times faster than real-time (ramdisk 
to ramdisk if necessary).

I would like that to be possible, but it doens't look like it is.

Jelle.

> 
> --Loren Merritt
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Sat May  6 19:12:23 2006
From: svn at videolan.org (Subversion daemon)
Date: Sat,  6 May 2006 19:12:23 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r518 (pengvado)
Message-ID: <20060506171223.D6F719D52@ganesh.videolan.org>

r518 | pengvado | 2006-05-06 19:12:23 +0200 (Sat, 06 May 2006) | 3 lines
Changed paths:
   M /trunk/encoder/encoder.c
   M /trunk/x264.c
   M /trunk/x264.h

--sps-id, to allow concatenating streams with different settings.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From shauli.rozen at gmail.com  Mon May  8 14:09:51 2006
From: shauli.rozen at gmail.com (shauli.rozen at gmail.com)
Date: Mon, 8 May 2006 15:09:51 +0300
Subject: [x264-devel] MPEG4 question
Message-ID: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com>

Hi All

this is not a x264 related question , but I thought the vast video knowledge
here will have the answer.
Does old MPEG4 (not part 10) support changing the qscale in MB level (
i.e.-changing it inside the frame).

10x
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060508/5d1fe423/attachment.htm 

From manao at melix.net  Mon May  8 14:18:22 2006
From: manao at melix.net (Mathieu Monnier)
Date: Mon, 08 May 2006 14:18:22 +0200
Subject: [x264-devel] Re: MPEG4 question
In-Reply-To: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com>
References: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com>
Message-ID: <445F370E.7060106@melix.net>

> Hi All

Hi,

> this is not a x264 related question , but I thought the vast video 
> knowledge here will have the answer.

Indeed, it's not. Xvid, ffmpeg, mplayer, mencoder ML would really have 
been better suited. It's imho as bad a habit as using an already 
existing thread to ask a completely unrelated question.

Anyway,

> Does old MPEG4 (not part 10) support changing the qscale in MB level 
> (i.e.-changing it inside the frame).

Yes, but in a (very) restrictive way : the quantizer scale can only vary 
from [-2:+2] of the quantizer scale of the last encoded macroblock. AVC 
is quite less constrained in that regard ( [-26:+26] iirc ), so is mpeg2 
( whatever quantizer scale you want ).

Regards,

Mathieu

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From glargo at email.com  Mon May  8 15:16:49 2006
From: glargo at email.com (GILBERTO SANCHEZ)
Date: Mon, 08 May 2006 08:16:49 -0500
Subject: [x264-devel] MPEG4 AVC Encoder
Message-ID: <20060508131649.390551F50B1@ws1-2.us4.outblaze.com>

Hi all,

I'm new in the video world and i'm start to work with mencoder to encoder any video format to x264 + AAC, i'm using mencoder but i don't know which paremeters use.   I need information about this topic and i appreciate your help

Gilberto

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From robert.swain at gmail.com  Mon May  8 15:38:56 2006
From: robert.swain at gmail.com (Robert Swain)
Date: Mon, 8 May 2006 14:38:56 +0100
Subject: [x264-devel] Re: MPEG4 AVC Encoder
In-Reply-To: <20060508131649.390551F50B1@ws1-2.us4.outblaze.com>
References: <20060508131649.390551F50B1@ws1-2.us4.outblaze.com>
Message-ID: <200605081438.56640.robert.swain@gmail.com>

On Monday 08 May 2006 14:16, GILBERTO SANCHEZ wrote:
> I'm new in the video world and i'm start to work with mencoder to encoder
> any video format to x264 + AAC, i'm using mencoder but i don't know which
> paremeters use.   I need information about this topic and i appreciate your
> help

The mplayer man page is quite detailed with regard to the descriptions of 
options available and often gives suggestions. That would be a good place to 
start.

Rob

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Mon May  8 18:20:59 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Mon, 8 May 2006 09:20:59 -0700 (PDT)
Subject: [x264-devel] Re: MPEG4 question
In-Reply-To: <445F370E.7060106@melix.net>
References: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com>
 <445F370E.7060106@melix.net>
Message-ID: <Pine.A41.4.64.0605080920220.161478@dante65.u.washington.edu>

On Mon, 8 May 2006, Mathieu Monnier wrote:

> Yes, but in a (very) restrictive way : the quantizer scale can only vary from 
> [-2:+2] of the quantizer scale of the last encoded macroblock. AVC is quite 
> less constrained in that regard ( [-26:+26] iirc ), so is mpeg2 ( whatever 
> quantizer scale you want ).

[-26:+25], interpreted modulo 52. So it's really unrestricted.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From tim.greatrex at mac.com  Tue May  9 02:23:30 2006
From: tim.greatrex at mac.com (Tim Greatrex)
Date: Tue, 9 May 2006 01:23:30 +0100
Subject: [x264-devel] build error
In-Reply-To: <Pine.A41.4.64.0605080920220.161478@dante65.u.washington.edu>
References: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com> <445F370E.7060106@melix.net> <Pine.A41.4.64.0605080920220.161478@dante65.u.washington.edu>
Message-ID: <3FE09C5B-21DA-4C3B-8816-225E8F7CC846@mac.com>

Hi guys,

i've been advancing my knowledge by installing (or trying to) packs  
like ffmpeg, gpac (to no success) faad, zlib, sdl etc (works i  
think :S ),

now when i try to configure then make x264 i get:-

...
You can run 'make' or 'make fprofiled' now.
Tims-PowerMac:~/programs/x264 timgreatrex$ make
.depend:95: *** missing separator.  Stop.
Tims-PowerMac:~/programs/x264 timgreatrex$


any ideas? is this due to any recent changes or my mistakes?
tried re-svning all the files but same error.


Tim

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Tue May  9 08:11:43 2006
From: svn at videolan.org (Subversion daemon)
Date: Tue,  9 May 2006 08:11:43 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r519 (pengvado)
Message-ID: <20060509061143.12A3F273F@ganesh.videolan.org>

r519 | pengvado | 2006-05-09 08:11:42 +0200 (Tue, 09 May 2006) | 4 lines
Changed paths:
   M /trunk/common/amd64/pixel-a.asm
   M /trunk/common/amd64/pixel-sse2.asm
   M /trunk/common/i386/pixel-a.asm
   M /trunk/common/i386/pixel.h
   M /trunk/common/i386/predict-c.c
   M /trunk/common/pixel.c
   M /trunk/common/pixel.h
   M /trunk/encoder/analyse.c
   M /trunk/encoder/slicetype_decision.c
   M /trunk/tools/checkasm.c

faster intra search: some prediction modes don't have to compute a full hadamard transform.
x86 and amd64 asm.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From singh at eurecom.fr  Tue May  9 10:07:08 2006
From: singh at eurecom.fr (singh at eurecom.fr)
Date: Tue,  9 May 2006 10:07:08 +0200
Subject: [x264-devel] BMP input
Message-ID: <1147162027.44604dac021d6@webmail.eurecom.fr>

I need to take a BMP sequence as input of my decoder. I don t want to use a tool
(such as Virtualdub).
I tried to modify the source but I don t understand how to replace a
frame by a BMP, and how the frames are represented.
Thanks for help.



-------------------------------------------------
This mail sent through Institut Eurecom Webmail: http://webmail.eurecom.fr

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From singh at eurecom.fr  Tue May  9 10:07:10 2006
From: singh at eurecom.fr (singh at eurecom.fr)
Date: Tue,  9 May 2006 10:07:10 +0200
Subject: [x264-devel] BMP input
Message-ID: <1147162030.44604daea0767@webmail.eurecom.fr>

I need to take a BMP sequence as input of my decoder. I don t want to use a tool
(such as Virtualdub).
I tried to modify the source but I don t understand how to replace a
frame by a BMP, and how the frames are represented.
Thanks for help.



-------------------------------------------------
This mail sent through Institut Eurecom Webmail: http://webmail.eurecom.fr

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From mru at inprovide.com  Tue May  9 10:50:37 2006
From: mru at inprovide.com (=?utf-8?Q?M=C3=A5ns_Rullg=C3=A5rd?=)
Date: Tue, 9 May 2006 09:50:37 +0100 (BST)
Subject: [x264-devel] Re: BMP input
In-Reply-To: <1147162030.44604daea0767@webmail.eurecom.fr>
References: <1147162030.44604daea0767@webmail.eurecom.fr>
Message-ID: <13795.194.202.59.51.1147164637.squirrel@mail.inprovide.com>


singh at eurecom.fr said:
> I need to take a BMP sequence as input of my decoder. I don t want to use a
> tool (such as Virtualdub).
> I tried to modify the source but I don t understand how to replace a
> frame by a BMP, and how the frames are represented.
> Thanks for help.

Please don't post the same message twice.

You can use FFmpeg to read a BMP sequence.

-- 
M?ns Rullg?rd
mru at inprovide.com

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From michaelni at gmx.at  Tue May  9 11:36:01 2006
From: michaelni at gmx.at (Michael Niedermayer)
Date: Tue, 9 May 2006 11:36:01 +0200
Subject: [x264-devel] Re: MPEG4 question
In-Reply-To: <445F370E.7060106@melix.net>
References: <34b75c4f0605080509o37f5e627n3637450fd6f5a62e@mail.gmail.com> <445F370E.7060106@melix.net>
Message-ID: <20060509093601.GQ32606@MichaelsNB>

Hi

On Mon, May 08, 2006 at 02:18:22PM +0200, Mathieu Monnier wrote:
[...]
> >Does old MPEG4 (not part 10) support changing the qscale in MB level 
> >(i.e.-changing it inside the frame).
> 
> Yes, but in a (very) restrictive way : the quantizer scale can only vary 
> from [-2:+2] of the quantizer scale of the last encoded macroblock. AVC 

only for I & P frames, B frames allow only {-2,0,+2} so you have to decide
between even and odd quantizers, furthermore you cannot change the quantizer
in macroblocks which have 4 motion vectors, h263 is similarely limited

h263+ lifts these (idiotic) limits and like mpeg1,mpeg2 and h264 allows the
whole range on every MB

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From shauli.rozen at gmail.com  Tue May  9 17:58:01 2006
From: shauli.rozen at gmail.com (shauli.rozen at gmail.com)
Date: Tue, 9 May 2006 18:58:01 +0300
Subject: [x264-devel] Re: BMP input
In-Reply-To: <13795.194.202.59.51.1147164637.squirrel@mail.inprovide.com>
References: <1147162030.44604daea0767@webmail.eurecom.fr>
	 <13795.194.202.59.51.1147164637.squirrel@mail.inprovide.com>
Message-ID: <34b75c4f0605090858r4a497732i39ac1b89306801cf@mail.gmail.com>

Also , converting a RGB image to YUV is quite simple.

On 5/9/06, M?ns Rullg?rd <mru at inprovide.com> wrote:
>
>
> singh at eurecom.fr said:
> > I need to take a BMP sequence as input of my decoder. I don t want to
> use a
> > tool (such as Virtualdub).
> > I tried to modify the source but I don t understand how to replace a
> > frame by a BMP, and how the frames are represented.
> > Thanks for help.
>
> Please don't post the same message twice.
>
> You can use FFmpeg to read a BMP sequence.
>
> --
> M?ns Rullg?rd
> mru at inprovide.com
>
> --
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060509/095f78a6/attachment.htm 

From stephan.singh at gmail.com  Tue May  9 09:57:39 2006
From: stephan.singh at gmail.com (Stephan Singh)
Date: Tue, 9 May 2006 16:57:39 +0900
Subject: [x264-devel] BMP input
Message-ID: <9e26c2c50605090057w550002bfjf13640298cf60868@mail.gmail.com>

I need to take a BMP sequence as input of my decoder.
I tried to modify the source but I don t understand how to replace a
frame by a BMP.
Thanks for help.

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From mru at inprovide.com  Tue May  9 20:46:39 2006
From: mru at inprovide.com (=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=)
Date: Tue, 09 May 2006 19:46:39 +0100
Subject: [x264-devel] Re: BMP input
In-Reply-To: <9e26c2c50605090057w550002bfjf13640298cf60868@mail.gmail.com> (Stephan Singh's message of "Tue, 9 May 2006 16:57:39 +0900")
References: <9e26c2c50605090057w550002bfjf13640298cf60868@mail.gmail.com>
Message-ID: <yw1xu07z9gts.fsf@agrajag.inprovide.com>

"Stephan Singh" <stephan.singh at gmail.com> writes:

> I need to take a BMP sequence as input of my decoder.
> I tried to modify the source but I don t understand how to replace a
> frame by a BMP.

You already asked this question two times earlier today, and have
received replies.  If those replies did not answer your question, try
rephrasing your question so that we may understand what it is you want
to know.  Simply repeating it (in a new thread no less) will only
serve to annoy people, and you will most likely be ignored.

-- 
M?ns Rullg?rd
mru at inprovide.com

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From singh at eurecom.fr  Wed May 10 07:28:02 2006
From: singh at eurecom.fr (singh at eurecom.fr)
Date: Wed, 10 May 2006 07:28:02 +0200
Subject: [x264-devel] Re: BMP input
Message-ID: <1147238882.446179e29ae5e@webmail.eurecom.fr>

I appologize for last multiple identical posts that was not on purpose!

My problem is not to convert RGB to YUV, that is already done. The problem is
where  (which variable represents the 

current frame) I have to include it.



-------------------------------------------------
This mail sent through Institut Eurecom Webmail: http://webmail.eurecom.fr

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From matje at lanzone.be  Wed May 10 07:46:57 2006
From: matje at lanzone.be (Mathy Vanvoorden)
Date: Wed, 10 May 2006 07:46:57 +0200
Subject: [x264-devel] Re: BMP input
In-Reply-To: <1147238882.446179e29ae5e@webmail.eurecom.fr>
References: <1147238882.446179e29ae5e@webmail.eurecom.fr>
Message-ID: <200605100746.57382.matje@lanzone.be>

On Wednesday 10 May 2006 07:28, singh at eurecom.fr wrote:
> I appologize for last multiple identical posts that was not on purpose!

No problem, don't do it again ;)

> My problem is not to convert RGB to YUV, that is already done. The problem
> is where  (which variable represents the
>
> current frame) I have to include it.

Take a look at the function Encode_frame and where it gets called in x264.c. 
It should contain all the info you need.

-- 
Best regards,

Mathy Vanvoorden

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Wed May 10 08:09:48 2006
From: svn at videolan.org (Subversion daemon)
Date: Wed, 10 May 2006 08:09:48 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r520 (pengvado)
Message-ID: <20060510060948.C6BF6273D@ganesh.videolan.org>

r520 | pengvado | 2006-05-10 08:09:48 +0200 (Wed, 10 May 2006) | 3 lines
Changed paths:
   M /trunk/common/amd64/pixel-sse2.asm
   M /trunk/common/amd64/predict-a.asm
   M /trunk/common/i386/pixel.h
   M /trunk/common/i386/predict-a.asm
   M /trunk/common/i386/predict-c.c
   M /trunk/common/macroblock.h
   M /trunk/common/pixel.h
   M /trunk/common/predict.c
   M /trunk/common/predict.h
   M /trunk/encoder/analyse.c
   M /trunk/encoder/macroblock.c
   M /trunk/tools/checkasm.c

faster intra search: filter i8x8 edges only once, and reuse for multiple predictions.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From andrea.barbieri at movingimageresearch.com  Wed May 10 16:37:35 2006
From: andrea.barbieri at movingimageresearch.com (Andrea Barbieri)
Date: Wed, 10 May 2006 15:37:35 +0100 (BST)
Subject: [x264-devel] Re: x264: svn commit r520 (pengvado)
In-Reply-To: <20060510060948.C6BF6273D@ganesh.videolan.org>
References: <20060510060948.C6BF6273D@ganesh.videolan.org>
Message-ID: <Pine.GSO.4.64.0605101516010.6485@cherenkov>

Hello,

common/macroblock.h makes use C99 designated initializers which are not 
supported at the moment by any Visual C++ compilers...

I've attached a patch that provides support for successful compilation 
in MSVC projects.

best regards,
andrea
-- 
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/
-------------- next part --------------
Index: macroblock.h

===================================================================

--- macroblock.h	(revision 520)

+++ macroblock.h	(working copy)

@@ -38,6 +38,7 @@

 
 static const int x264_pred_i4x4_neighbors[13] =
 {
+#ifndef _MSC_VER
     [I_PRED_4x4_HU]      = MB_LEFT,
     [I_PRED_4x4_H]       = MB_LEFT,
     [I_PRED_4x4_HD]      = MB_LEFT | MB_TOPLEFT | MB_TOP,
@@ -50,6 +51,21 @@

     [I_PRED_4x4_DC_LEFT] = MB_LEFT,
     [I_PRED_4x4_DC_TOP]  = MB_TOP,
     [I_PRED_4x4_DC_128]  = 0
+#else
+    MB_TOP,                         // I_PRED_4x4_V
+    MB_LEFT,                        // I_PRED_4x4_H
+    MB_LEFT | MB_TOP,               // I_PRED_4x4_DC
+    MB_TOP  | MB_TOPRIGHT,          // I_PRED_4x4_DDL
+    MB_LEFT | MB_TOPLEFT | MB_TOP,  // I_PRED_4x4_DDR
+    MB_LEFT | MB_TOPLEFT | MB_TOP,  // I_PRED_4x4_VR
+    MB_LEFT | MB_TOPLEFT | MB_TOP,  // I_PRED_4x4_HD
+    MB_TOP  | MB_TOPRIGHT,          // I_PRED_4x4_VL
+    MB_LEFT,                        // I_PRED_4x4_HU
+    MB_LEFT,                        // I_PRED_4x4_DC_LEFT
+    MB_TOP,                         // I_PRED_4x4_DC_TOP
+    0,                              // I_PRED_4x4_DC_128
+    0
+#endif
 };
 
 

From lll+vlc at m4x.org  Wed May 10 16:58:54 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Wed, 10 May 2006 16:58:54 +0200
Subject: [x264-devel] square sar should be allowed
Message-ID: <20060510145854.GC11853@pavuc.le-loarer.org>

Hi,

I observe that x264 refuses to write a sar of 1:1 and prefer to let the
"unknown" status. I think this is wrong, an unknown aspect ratio is not
the same of a given 1:1 aspect ratio.

Here is a patch which removes the test and allows to put an explicit
square sar.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 520)
+++ encoder/encoder.c	(working copy)
@@ -506,10 +506,6 @@
         {
             x264_log( h, X264_LOG_ERROR, "cannot create valid sample aspect ratio\n" );
         }
-        else if( i_w == i_h )
-        {
-            x264_log( h, X264_LOG_INFO, "no need for a SAR\n" );
-        }
         else
         {
             x264_log( h, X264_LOG_INFO, "using SAR=%d/%d\n", i_w, i_h );
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060510/081efdd4/attachment.pgp 

From lll+vlc at m4x.org  Wed May 10 17:15:56 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Wed, 10 May 2006 17:15:56 +0200
Subject: [x264-devel] NAL order inside access unit is not correct
Message-ID: <20060510151556.GD11853@pavuc.le-loarer.org>

Hi,

According to the H.264 norm, the order of NAL inside an access unit
should be SPS, PPS, SEI, VCL but x264 is outputing the user data SEI
before the SPS and the PPS.

Here is a patch which is correcting this.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 520)
+++ encoder/encoder.c	(working copy)
@@ -673,11 +673,6 @@
     /* Put SPS and PPS */
     if( h->i_frame == 0 )
     {
-        /* identify ourself */
-        x264_nal_start( h, NAL_SEI, NAL_PRIORITY_DISPOSABLE );
-        x264_sei_version_write( h, &h->out.bs );
-        x264_nal_end( h );
-
         /* generate sequence parameters */
         x264_nal_start( h, NAL_SPS, NAL_PRIORITY_HIGHEST );
         x264_sps_write( &h->out.bs, h->sps );
@@ -687,6 +682,11 @@
         x264_nal_start( h, NAL_PPS, NAL_PRIORITY_HIGHEST );
         x264_pps_write( &h->out.bs, h->pps );
         x264_nal_end( h );
+
+        /* identify ourself */
+        x264_nal_start( h, NAL_SEI, NAL_PRIORITY_DISPOSABLE );
+        x264_sei_version_write( h, &h->out.bs );
+        x264_nal_end( h );
     }
     /* now set output*/
     *pi_nal = h->out.i_nal;
@@ -1331,14 +1331,6 @@
     /* Write SPS and PPS */
     if( i_nal_type == NAL_SLICE_IDR && h->param.b_repeat_headers )
     {
-        if( h->fenc->i_frame == 0 )
-        {
-            /* identify ourself */
-            x264_nal_start( h, NAL_SEI, NAL_PRIORITY_DISPOSABLE );
-            x264_sei_version_write( h, &h->out.bs );
-            x264_nal_end( h );
-        }
-
         /* generate sequence parameters */
         x264_nal_start( h, NAL_SPS, NAL_PRIORITY_HIGHEST );
         x264_sps_write( &h->out.bs, h->sps );
@@ -1348,6 +1340,14 @@
         x264_nal_start( h, NAL_PPS, NAL_PRIORITY_HIGHEST );
         x264_pps_write( &h->out.bs, h->pps );
         x264_nal_end( h );
+
+        if( h->fenc->i_frame == 0 )
+        {
+            /* identify ourself */
+            x264_nal_start( h, NAL_SEI, NAL_PRIORITY_DISPOSABLE );
+            x264_sei_version_write( h, &h->out.bs );
+            x264_nal_end( h );
+        }
     }
 
     /* Write frame */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060510/471a3026/attachment.pgp 

From glargo at email.com  Wed May 10 18:26:02 2006
From: glargo at email.com (GILBERTO SANCHEZ)
Date: Wed, 10 May 2006 11:26:02 -0500
Subject: [x264-devel] Video is faster to Audio
Message-ID: <20060510162602.6FDFC1CE305@ws1-6.us4.outblaze.com>

Hi all, 

I use mencoder this:

mencoder kiss.asf -o out.mp4 -of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames -oac faac -faacopts br=256 -ovc x264 -x264encopts qp_min=10:qp_max=51:qp_step=4:ratetol=60:ip_factor=1.4:pb_factor=1.3:qcomp=0.7:scenecut=40:keyint=51:keyint_min=10:
frameref=3:bframes=3:b_bias=0:direct_pred=2:b_adapt:b_pyramid:cabac:weight_b:me=2:subq=5:chroma_me:mixed_refs:brdo:bime:4x4mv:i4x4:i8x8:
8x8mv:b8x8mv:8x8dct

And the result was a file where the video is faster in comparison with audio and the original size file.asf is 18512799 and the size file.mp4 is 23327659 

How i can optimize and resolve that

Thanks

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Wed May 10 18:42:07 2006
From: svn at videolan.org (Subversion daemon)
Date: Wed, 10 May 2006 18:42:07 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r521 (pengvado)
Message-ID: <20060510164207.9AB45273D@ganesh.videolan.org>

r521 | pengvado | 2006-05-10 18:42:07 +0200 (Wed, 10 May 2006) | 4 lines
Changed paths:
   M /trunk/encoder/encoder.c

allow sar=1/1.
patch by Loic Le Loarer.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Wed May 10 18:47:05 2006
From: svn at videolan.org (Subversion daemon)
Date: Wed, 10 May 2006 18:47:05 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r522 (pengvado)
Message-ID: <20060510164705.3EEA68A7@ganesh.videolan.org>

r522 | pengvado | 2006-05-10 18:47:05 +0200 (Wed, 10 May 2006) | 3 lines
Changed paths:
   M /trunk/common/macroblock.h

msvc doesn't like C99 named array initializers


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Wed May 10 18:54:54 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Wed, 10 May 2006 09:54:54 -0700 (PDT)
Subject: [x264-devel] Re: NAL order inside access unit is not correct
In-Reply-To: <20060510151556.GD11853@pavuc.le-loarer.org>
References: <20060510151556.GD11853@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605100951430.153934@dante65.u.washington.edu>

On Wed, 10 May 2006, Lo?c Le Loarer wrote:

> Hi,
>
> According to the H.264 norm, the order of NAL inside an access unit
> should be SPS, PPS, SEI, VCL but x264 is outputing the user data SEI
> before the SPS and the PPS.
>
> Here is a patch which is correcting this.
>
> Best regards.

Where does it say this? I'm looking at
7.4.1.2.3 Order of NAL units and coded pictures and association to access units,
and I fail to see such a constraint.

--Loren Merritt

From lll+vlc at m4x.org  Wed May 10 19:27:32 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Wed, 10 May 2006 19:27:32 +0200
Subject: [x264-devel] Re: NAL order inside access unit is not correct
In-Reply-To: <Pine.A41.4.64.0605100951430.153934@dante65.u.washington.edu>
References: <20060510151556.GD11853@pavuc.le-loarer.org> <Pine.A41.4.64.0605100951430.153934@dante65.u.washington.edu>
Message-ID: <20060510172732.GE11853@pavuc.le-loarer.org>

Le Wednesday 10 May 2006 ? 09:54:54 -0700, Loren Merritt a ?crit:
> On Wed, 10 May 2006, Lo?c Le Loarer wrote:
> 
> >Hi,
> >
> >According to the H.264 norm, the order of NAL inside an access unit
> >should be SPS, PPS, SEI, VCL but x264 is outputing the user data SEI
> >before the SPS and the PPS.
> >
> >Here is a patch which is correcting this.
> >
> >Best regards.
> 
> Where does it say this? I'm looking at
> 7.4.1.2.3 Order of NAL units and coded pictures and association to access 
> units,
> and I fail to see such a constraint.

Well, you are right, I interpreted the badly the list of NAL type
describing the start of an access unit.

There are dependencies between some SEI message types and the SPS, so
they should be ordered correctly in order to allow starting at the
middle of a stream efficiently and I mixed the constraints in my mind.
But it isn't the case for user data, so there should be no problem with
the current order.

Sorry.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060510/30fcb64e/attachment.pgp 

From lorenm at u.washington.edu  Thu May 11 09:11:57 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Thu, 11 May 2006 00:11:57 -0700 (PDT)
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <445B8F32.8090702@foks.8m.com>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>
 <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>
 <44591EBA.3050301@foks.8m.com> <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu>
 <445B8F32.8090702@foks.8m.com>
Message-ID: <Pine.A41.4.64.0605102048320.118926@dante65.u.washington.edu>

On Fri, 5 May 2006, Jelle wrote:
> Loren Merritt wrote:
>> 
>> No, I don't know whether my videocard supports xvmc, but I certainly 
>> haven't enabled it in ffmpeg. This is cpu-time as measured by
>> `time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.
>
> Ok, I'll run that too then.
>
> Two different machines. I know for sure that neither machines have videocards 
> that support Xvmc.
>
> Athlon64 3200+ (2GHz/512kb cache)
> MPEG2 video 480x576 at 25fps, 2.5Mbit/s (much less than DVD), 4688 seconds long.
> 100 * 12*60+20/4688 =~ 16% CPU.
>
> P4/3GHz/1M cache
> MPEG2 video 720x480 at 29.97fps, 4.5Mbit/s, 1886 seconds long
> 100 * 4*60+12/1886 =~ 13% CPU.
>
> I don't know where you got 2%, but I can't reproduce anything even close to 
> it.
>
> 2% of a 2.2GHz CPU, or 44MHz, for DVD video? How can I get that?

Ok, so it wasn't quite 2%.

Athlon64 3400+ (2.2GHz/1024kb cache)
MPlayer dev-CVS-060508-14:21-4.0.4

MPEG2 video 720x480x23.976fps, 4.1 Mbit/s, 5598 seconds
BENCHMARKs: VC: 184.573s VO:  0.124s A:  0.000s Sys:  5.560s = 190.297s
BENCHMARK%: VC: 96.9921% VO: 0.0652% A: 0.0000% Sys: 2.9227% = 100.0000%
real    191.395s
user    185.882s
sys     3.446s

100% * 191.395 / 5598 = 3.4% CPU

MPEG2 video 720x480x23.976fps, 8.4 Mbit/s, 3750 seconds
BENCHMARKs: VC: 232.713s VO:  0.086s A:  0.000s Sys: 10.425s = 243.224s
BENCHMARK%: VC: 95.6782% VO: 0.0354% A: 0.0000% Sys: 4.2863% = 100.0000%
real    244.856s
user    233.706s
sys     5.401s

100% * 244.856 / 3750 = 6.5% CPU

> mpeg2 decoding takes about the same amount of operations per frame as JPEG 
> (mjpeg) encoding. If your 2% number is really valid, you should be able to 
> transcode mpeg2 to mjpeg 25 times faster than real-time (ramdisk to ramdisk 
> if necessary).

Transcoding mpeg2->mjpeg is only 6x realtime here (using the 3.4% dvd).
mjpeg takes more time for bitstream packing because it's higher bitrate, 
and more time for dct/quant because when encoding you need to process all 
pixels/coefs, whereas when decoding you skip the null coefs and null 
blocks. And yes, those factors combined cost more than a little motion 
compensation does.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From pedro.tumusok at gmail.com  Thu May 11 11:06:06 2006
From: pedro.tumusok at gmail.com (Pedro Tumusok)
Date: Thu, 11 May 2006 11:06:06 +0200
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <Pine.A41.4.64.0605102048320.118926@dante65.u.washington.edu>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com>
	 <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu>
	 <44591EBA.3050301@foks.8m.com>
	 <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu>
	 <445B8F32.8090702@foks.8m.com>
	 <Pine.A41.4.64.0605102048320.118926@dante65.u.washington.edu>
Message-ID: <aa7a75950605110206k1050e78cx16edbd49533a83b1@mail.gmail.com>

On 5/11/06, Loren Merritt <lorenm at u.washington.edu> wrote:
>
> On Fri, 5 May 2006, Jelle wrote:
> > Loren Merritt wrote:
> >>
> >> No, I don't know whether my videocard supports xvmc, but I certainly
> >> haven't enabled it in ffmpeg. This is cpu-time as measured by
> >> `time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.
> >
> > Ok, I'll run that too then.
> >
> > Two different machines. I know for sure that neither machines have
> videocards
> > that support Xvmc.
> >
> > Athlon64 3200+ (2GHz/512kb cache)
> > MPEG2 video 480x576 at 25fps, 2.5Mbit/s (much less than DVD), 4688 seconds
> long.
> > 100 * 12*60+20/4688 =~ 16% CPU.
> >
> > P4/3GHz/1M cache
> > MPEG2 video 720x480 at 29.97fps, 4.5Mbit/s, 1886 seconds long
> > 100 * 4*60+12/1886 =~ 13% CPU.
> >
> > I don't know where you got 2%, but I can't reproduce anything even close
> to
> > it.
> >
> > 2% of a 2.2GHz CPU, or 44MHz, for DVD video? How can I get that?
>
> Ok, so it wasn't quite 2%.
>
>
>
> 100% * 244.856 / 3750 = 6.5% CPU
>
>
I guess that my real question was, do you think the Cell is the cpu beast
that IBM/Sony/Toshiba claims it to be? If so a PS3 with Linux and an
optimized x264 code to take care of the SPE's in the Cell might be a very
cheap encoder.

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/05bded1c/attachment.htm 

From alberto.carubelli at gmail.com  Thu May 11 13:18:08 2006
From: alberto.carubelli at gmail.com (Alberto Carubelli)
Date: Thu, 11 May 2006 13:18:08 +0200
Subject: [x264-devel] x264_encoder_reconfig PLEASE HELP ME!!!!!!!!
Message-ID: <cdcc82870605110418q30d10707r6d92a696ddf0216f@mail.gmail.com>

Hi,
I'm trying to use the x264_encoder_reconfig function to update the bitrate
of the x264 encoder while it is running, but I have absolutely no idea of
how the function works or what codes it returns (it keeps returning 0). Is
there a man page, or does anybody know how x264_encoder_reconfig works or
how the hell I'm supposed to change the bitrate of a stream while it's
running?
Thanks,

Alberto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/199e8377/attachment.htm 

From matje at lanzone.be  Thu May 11 13:45:17 2006
From: matje at lanzone.be (Mathy Vanvoorden)
Date: Thu, 11 May 2006 13:45:17 +0200
Subject: [x264-devel] Re: x264_encoder_reconfig PLEASE HELP ME!!!!!!!!
In-Reply-To: <cdcc82870605110418q30d10707r6d92a696ddf0216f@mail.gmail.com>
References: <cdcc82870605110418q30d10707r6d92a696ddf0216f@mail.gmail.com>
Message-ID: <200605111345.17585.matje@lanzone.be>

On Thursday 11 May 2006 13:18, Alberto Carubelli wrote:
> Hi,
> I'm trying to use the x264_encoder_reconfig function to update the bitrate
> of the x264 encoder while it is running, but I have absolutely no idea of
> how the function works or what codes it returns (it keeps returning 0). Is
> there a man page, or does anybody know how x264_encoder_reconfig works or
> how the hell I'm supposed to change the bitrate of a stream while it's
> running?

x264 only permits to change a limited set of parameters (most require you to 
restart the stream). I wrote a patch that allows to change the bitrate when 
in CBR mode. Pengvado took a look at it and corrected some errors, but I 
don't think I've got the corrected version, nor has it been added to x264 
yet. I've attached my patch (created agains r502), which works good enough 
for what I want, but does something wrong with the stats. Have fun with it.

-- 
Best regards,

Mathy Vanvoorden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reconfig_bitrate.diff
Type: text/x-diff
Size: 2855 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/4f2d023d/attachment.diff 

From lll+vlc at m4x.org  Thu May 11 19:14:06 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Thu, 11 May 2006 19:14:06 +0200
Subject: [x264-devel] [PATCH] set constraint_set[01]_flag when possible
Message-ID: <20060511171406.GG1485@pavuc.le-loarer.org>

Hi,

Here is a patch which set the flags constraint_set0_flag and
constraint_set1_flag when possible. This has the advandage of giving
more information on the stream which may help decoders.

I have included the text from the H.264 norm so that in case of
improvement in x264 supported feature, the flags can be corrected
accordingly easily.

Hope this helps adn can be included in x264.

Best regards.

-- 
Lo?c
-------------- next part --------------
Index: encoder/set.c
===================================================================
--- encoder/set.c	(revision 522)
+++ encoder/set.c	(working copy)
@@ -88,8 +88,60 @@
         sps->i_profile_idc  = PROFILE_BASELINE;
     sps->i_level_idc = param->i_level_idc;
 
-    sps->b_constraint_set0  = 0;
-    sps->b_constraint_set1  = 0;
+    sps->b_frame_mbs_only = 1;
+
+    /* Set constraint_set0_flag if the BASELINE constraint are fulfilled even if
+     * the profile is not BASELINE, this allows a BASELINE only decoder to decode
+     * the stream */
+    /* Bitstreams conforming to the Baseline profile shall obey the following constraints: */
+    sps->b_constraint_set0  = 1
+        /* - Only I and P slice types may be present. */
+        && (0 == param->i_bframe)
+        /* - NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive. */
+        && 1
+        /* - Sequence parameter sets shall have frame_mbs_only_flag equal to 1. */
+        && sps->b_frame_mbs_only
+        /* - The syntax elements chroma_format_idc, bit_depth_luma_minus8, bit_depth_chroma_minus8, qpprime_y_zero_transform_bypass_flag, and seq_scaling_matrix_present_flag shall not be present in sequence parameter sets. */
+        && (sps->i_profile_idc < PROFILE_HIGH)
+        /* - Picture parameter sets shall have weighted_pred_flag and weighted_bipred_idc both equal to 0. */
+        && (0 == param->analyse.b_weighted_bipred)
+        /* - Picture parameter sets shall have entropy_coding_mode_flag equal to 0. */
+        && !param->b_cabac
+        /* - Picture parameter sets shall have num_slice_groups_minus1 in the range of 0 to 7, inclusive. */
+        && 1
+        /* - The syntax elements transform_8x8_mode_flag, pic_scaling_matrix_present_flag, and second_chroma_qp_index_offset shall not be present in picture parameter sets. */
+        && 1 /* already checked by PROFILE_HIGH check upper */
+        /* - The syntax element level_prefix shall not be greater than 15. */
+        && 1 /* x264 doesn't support level_prefix > 15 yet */
+        /* - The level constraints specified for the Baseline profile in subclause A.3 shall be fulfilled. */
+        /* Warning: the constraint on MaxSubMbRectSize is not checked */
+        ;
+
+    /* Set constraint_set1_flag if the MAIN constraint are fulfilled even if
+     * the profile isn't MAIN, this allows MAIN only decoder to decode
+     * the stream and allows a BASELINE/MAIN decoder to decode the stream
+     * more efficiently by doing deblocking on the fly */
+    /* Bitstreams conforming to the Main profile shall obey the following constraints: */
+    sps->b_constraint_set1  = 1
+        /* Only I, P, and B slice types may be present. */
+        && 1
+        /* NAL unit streams shall not contain nal_unit_type values in the range of 2 to 4, inclusive. */
+        && 1
+        /* - The syntax elements chroma_format_idc, bit_depth_luma_minus8, bit_depth_chroma_minus8, qpprime_y_zero_transform_bypass_flag, and seq_scaling_matrix_present_flag shall not be present in sequence parameter sets. */
+        && (sps->i_profile_idc < PROFILE_HIGH)
+        /* Arbitrary slice order is not allowed. */
+        && 1
+        /* Picture parameter sets shall have num_slice_groups_minus1 equal to 0 only. */
+        && 1
+        /* Picture parameter sets shall have redundant_pic_cnt_present_flag equal to 0 only. */
+        && 1
+        /* - The syntax elements transform_8x8_mode_flag, pic_scaling_matrix_present_flag, and second_chroma_qp_index_offset shall not be present in picture parameter sets. */
+        && 1 /* already checked by PROFILE_HIGH check upper */
+        /* - The syntax element level_prefix shall not be greater than 15. */
+        && 1 /* x264 doesn't support level_prefix > 15 yet */
+        /* The level constraints specified for the Main profile in subclause A.3 shall be fulfilled. */
+        ;
+    /* Never set constraint_set2, it is not necessary as not used in real world */
     sps->b_constraint_set2  = 0;
 
     sps->i_log2_max_frame_num = 4;  /* at least 4 */
@@ -125,7 +177,6 @@
     sps->b_gaps_in_frame_num_value_allowed = 0;
     sps->i_mb_width = ( param->i_width + 15 ) / 16;
     sps->i_mb_height= ( param->i_height + 15 )/ 16;
-    sps->b_frame_mbs_only = 1;
     sps->b_mb_adaptive_frame_field = 0;
     sps->b_direct8x8_inference = 0;
     if( sps->b_frame_mbs_only == 0 ||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/f9a736eb/attachment.pgp 

From lll+vlc at m4x.org  Thu May 11 19:29:44 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Thu, 11 May 2006 19:29:44 +0200
Subject: [x264-devel] [PATCH] split horizontal and vertical mv range
Message-ID: <20060511172944.GA21736@pavuc.le-loarer.org>

Hi,

Here is a patch which splits the horizontal and vertical motion vector
range and limits the vertical range correctly according to the level.

This has the effect of increasing the horizontal range which is level
independant instead of limiting it to the same value as the vertical
range by default, this may improve the encoding quality in some
situations.

This also prevent to produce invalid streams by setting a too big range.

Hope this helps.

Best regards.

-- 
Lo?c
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 522)
+++ encoder/encoder.c	(working copy)
@@ -423,10 +423,14 @@
             x264_log( h, X264_LOG_ERROR, "invalid level_idc: %d\n", h->param.i_level_idc );
             return -1;
         }
-        if( h->param.analyse.i_mv_range <= 0 )
-            h->param.analyse.i_mv_range = l->mv_range;
+        if( h->param.analyse.i_horizontal_mv_range <= 0 )
+            h->param.analyse.i_horizontal_mv_range = 2048; // This is a level independent limit
         else
-            h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
+            h->param.analyse.i_horizontal_mv_range = x264_clip3(h->param.analyse.i_horizontal_mv_range, 32, 2048);
+        if( h->param.analyse.i_vertical_mv_range <= 0 )
+            h->param.analyse.i_vertical_mv_range = l->mv_range;
+        else
+            h->param.analyse.i_vertical_mv_range = x264_clip3(h->param.analyse.i_vertical_mv_range, 32, l->mv_range);
     }
 
     if( h->param.rc.f_qblur < 0 )
Index: encoder/set.c
===================================================================
--- encoder/set.c	(revision 522)
+++ encoder/set.c	(working copy)
@@ -204,8 +204,8 @@
         sps->vui.b_motion_vectors_over_pic_boundaries = 1;
         sps->vui.i_max_bytes_per_pic_denom = 0;
         sps->vui.i_max_bits_per_mb_denom = 0;
-        sps->vui.i_log2_max_mv_length_horizontal =
-        sps->vui.i_log2_max_mv_length_vertical = (int)(log(param->analyse.i_mv_range*4-1)/log(2)) + 1;
+        sps->vui.i_log2_max_mv_length_horizontal = (int)(log(param->analyse.i_horizontal_mv_range*4-1)/log(2)) + 1;
+        sps->vui.i_log2_max_mv_length_vertical = (int)(log(param->analyse.i_vertical_mv_range*4-1)/log(2)) + 1;
     }
 }
 
@@ -537,7 +537,7 @@
     CHECK( "DPB size", l->dpb, mbs * 384 * h->sps->i_num_ref_frames );
     CHECK( "VBV bitrate", l->bitrate, h->param.rc.i_vbv_max_bitrate );
     CHECK( "VBV buffer", l->cpb, h->param.rc.i_vbv_buffer_size );
-    CHECK( "MV range", l->mv_range, h->param.analyse.i_mv_range );
+    CHECK( "MV range", l->mv_range, h->param.analyse.i_vertical_mv_range );
 
     if( h->param.i_fps_den > 0 )
         CHECK( "MB rate", l->mbps, (int64_t)mbs * h->param.i_fps_num / h->param.i_fps_den );
Index: encoder/analyse.c
===================================================================
--- encoder/analyse.c	(revision 522)
+++ encoder/analyse.c	(working copy)
@@ -218,26 +218,29 @@
     if( h->sh.i_type != SLICE_TYPE_I )
     {
         int i;
-        int i_fmv_range = h->param.analyse.i_mv_range - 16;
+        const int i_h_fmv_range = h->param.analyse.i_horizontal_mv_range - 16;
+        const int i_v_fmv_range = h->param.analyse.i_vertical_mv_range - 16;
 
         /* Calculate max allowed MV range */
-#define CLIP_FMV(mv) x264_clip3( mv, -i_fmv_range, i_fmv_range )
         h->mb.mv_min[0] = 4*( -16*h->mb.i_mb_x - 24 );
         h->mb.mv_max[0] = 4*( 16*( h->sps->i_mb_width - h->mb.i_mb_x - 1 ) + 24 );
-        h->mb.mv_min_fpel[0] = CLIP_FMV( -16*h->mb.i_mb_x - 8 );
-        h->mb.mv_max_fpel[0] = CLIP_FMV( 16*( h->sps->i_mb_width - h->mb.i_mb_x - 1 ) + 8 );
+#define CLIP_H_FMV(mv) x264_clip3( mv, -i_h_fmv_range, i_h_fmv_range )
+        h->mb.mv_min_fpel[0] = CLIP_H_FMV( -16*h->mb.i_mb_x - 8 );
+        h->mb.mv_max_fpel[0] = CLIP_H_FMV( 16*( h->sps->i_mb_width - h->mb.i_mb_x - 1 ) + 8 );
+#undef CLIP_H_FMV
         h->mb.mv_min_spel[0] = 4*( h->mb.mv_min_fpel[0] - 16 );
         h->mb.mv_max_spel[0] = 4*( h->mb.mv_max_fpel[0] + 16 );
         if( h->mb.i_mb_x == 0)
         {
             h->mb.mv_min[1] = 4*( -16*h->mb.i_mb_y - 24 );
             h->mb.mv_max[1] = 4*( 16*( h->sps->i_mb_height - h->mb.i_mb_y - 1 ) + 24 );
-            h->mb.mv_min_fpel[1] = CLIP_FMV( -16*h->mb.i_mb_y - 8 );
-            h->mb.mv_max_fpel[1] = CLIP_FMV( 16*( h->sps->i_mb_height - h->mb.i_mb_y - 1 ) + 8 );
+#define CLIP_V_FMV(mv) x264_clip3( mv, -i_v_fmv_range, i_v_fmv_range )
+            h->mb.mv_min_fpel[1] = CLIP_V_FMV( -16*h->mb.i_mb_y - 8 );
+            h->mb.mv_max_fpel[1] = CLIP_V_FMV( 16*( h->sps->i_mb_height - h->mb.i_mb_y - 1 ) + 8 );
+#undef CLIP_V_FMV
             h->mb.mv_min_spel[1] = 4*( h->mb.mv_min_fpel[1] - 16 );
             h->mb.mv_max_spel[1] = 4*( h->mb.mv_max_fpel[1] + 16 );
         }
-#undef CLIP_FMV
 
         a->l0.me16x16.cost =
         a->l0.i_rd16x16    =
Index: common/common.c
===================================================================
--- common/common.c	(revision 522)
+++ common/common.c	(working copy)
@@ -118,7 +118,8 @@
     param->analyse.i_me_range = 16;
     param->analyse.i_subpel_refine = 5;
     param->analyse.b_chroma_me = 1;
-    param->analyse.i_mv_range = -1; // set from level_idc
+    param->analyse.i_horizontal_mv_range = -1;
+    param->analyse.i_vertical_mv_range = -1; // set from level_idc
     param->analyse.i_chroma_qp_offset = 0;
     param->analyse.b_fast_pskip = 1;
     param->analyse.b_dct_decimate = 1;
Index: x264.h
===================================================================
--- x264.h	(revision 522)
+++ x264.h	(working copy)
@@ -195,7 +195,8 @@
 
         int          i_me_method; /* motion estimation algorithm to use (X264_ME_*) */
         int          i_me_range; /* integer pixel motion estimation search range (from predicted mv) */
-        int          i_mv_range; /* maximum length of a mv (in pixels) */
+        int          i_horizontal_mv_range; /* maximum length of a horizontal mv (in frame pixels) */
+        int          i_vertical_mv_range; /* maximum length of a vertical mv (in frame pixels) */
         int          i_subpel_refine; /* subpixel motion estimation quality */
         int          b_bidir_me; /* jointly optimize both MVs in B-frames */
         int          b_chroma_me; /* chroma ME for subpel and mode decision in P-frames */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/e7a52814/attachment.pgp 

From lll+vlc at m4x.org  Thu May 11 19:44:55 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Thu, 11 May 2006 19:44:55 +0200
Subject: [x264-devel] [PATCH] set a valid value in direct_8x8_inference_flag
Message-ID: <20060511174455.GB21736@pavuc.le-loarer.org>

Hi,

This patch avoid to produce invalid streams by enforcing the level
restrictions on direct_8x8_inference_flag value. It also allows the
application to ask for a given value of direct_8x8_inference_flag.

Is it OK for you ?

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 522)
+++ encoder/encoder.c	(working copy)
@@ -427,6 +427,23 @@
             h->param.analyse.i_mv_range = l->mv_range;
         else
             h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
+        /* Validate direct_8x8_inference_flag: */
+        if( -1 == h->param.i_direct_8x8_inference_flag )
+        {
+            /* The flag isn't forced, set it to 0 if the level doesn't
+             * limit it to 1 and it it possible to generate P macroblocks
+             * with partitions smaller than 8x8 */
+            h->param.i_direct_8x8_inference_flag = l->direct8x8 ? 1 : !(h->param.analyse.inter & X264_ANALYSE_PSUB8x8);
+        }
+        else
+        {
+            /* if the level limits this flag to 1, check it isn't forced to 0 */
+            if (h->param.i_direct_8x8_inference_flag < l->direct8x8)
+            {
+                x264_log( h, X264_LOG_ERROR, "invalid direct_8x8_inference_flag %d for level %d\n", h->param.i_direct_8x8_inference_flag, h->param.i_level_idc );
+                return -1;
+            }
+        }
     }
 
     if( h->param.rc.f_qblur < 0 )
Index: encoder/set.c
===================================================================
--- encoder/set.c	(revision 522)
+++ encoder/set.c	(working copy)
@@ -127,13 +127,7 @@
     sps->i_mb_height= ( param->i_height + 15 )/ 16;
     sps->b_frame_mbs_only = 1;
     sps->b_mb_adaptive_frame_field = 0;
-    sps->b_direct8x8_inference = 0;
-    if( sps->b_frame_mbs_only == 0 ||
-        !(param->analyse.inter & X264_ANALYSE_PSUB8x8) )
-    {
-        sps->b_direct8x8_inference = 1;
-    }
-
+    sps->b_direct8x8_inference = param->i_direct_8x8_inference_flag;
     sps->crop.i_left   = 0;
     sps->crop.i_top    = 0;
     sps->crop.i_right  = (- param->i_width)  & 15;
Index: common/common.c
===================================================================
--- common/common.c	(revision 522)
+++ common/common.c	(working copy)
@@ -72,6 +72,7 @@
     param->b_bframe_adaptive = 1;
     param->i_bframe_bias = 0;
     param->b_bframe_pyramid = 0;
+    param->i_direct_8x8_inference_flag = -1;
 
     param->b_deblocking_filter = 1;
     param->i_deblocking_filter_alphac0 = 0;
@@ -485,10 +486,10 @@
     s += sprintf( s, " bframes=%d", p->i_bframe );
     if( p->i_bframe )
     {
-        s += sprintf( s, " b_pyramid=%d b_adapt=%d b_bias=%d direct=%d wpredb=%d bime=%d",
+        s += sprintf( s, " b_pyramid=%d b_adapt=%d b_bias=%d direct=%d d8x8=%d wpredb=%d bime=%d",
                       p->b_bframe_pyramid, p->b_bframe_adaptive, p->i_bframe_bias,
-                      p->analyse.i_direct_mv_pred, p->analyse.b_weighted_bipred,
-                      p->analyse.b_bidir_me );
+                      p->analyse.i_direct_mv_pred, p->i_direct_8x8_inference_flag,
+                      p->analyse.b_weighted_bipred, p->analyse.b_bidir_me );
     }
 
     s += sprintf( s, " keyint=%d keyint_min=%d scenecut=%d",
Index: x264.h
===================================================================
--- x264.h	(revision 522)
+++ x264.h	(working copy)
@@ -159,6 +159,7 @@
     int         b_bframe_adaptive;
     int         i_bframe_bias;
     int         b_bframe_pyramid;   /* Keep some B-frames as references */
+    int         i_direct_8x8_inference_flag; /* Use direct_8x8_inference_flag in SPS: (-1: 0 if possible according to level and partition mode) */
 
     int         b_deblocking_filter;
     int         i_deblocking_filter_alphac0;    /* [-6, 6] -6 light filter, 6 strong */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060511/55c0ef90/attachment.pgp 

From lorenm at u.washington.edu  Fri May 12 01:24:26 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Thu, 11 May 2006 16:24:26 -0700 (PDT)
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <20060511171406.GG1485@pavuc.le-loarer.org>
References: <20060511171406.GG1485@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu>

On Thu, 11 May 2006, Lo?c Le Loarer wrote:

> Here is a patch which set the flags constraint_set0_flag and
> constraint_set1_flag when possible. This has the advandage of giving
> more information on the stream which may help decoders.
>
> I have included the text from the H.264 norm so that in case of
> improvement in x264 supported feature, the flags can be corrected
> accordingly easily.
>
>+ Set constraint_set0_flag if the BASELINE constraint are fulfilled
>+ even if the profile is not BASELINE, this allows a BASELINE only 
>+ decoder to decode the stream

Why? x264 selects profile based on which features are enabled. It will 
never generate a Baseline-compatible stream that isn't actually marked as 
Baseline.
I suppose you could argue that there is some value in setting 
constraint_set1_flag for Baseline files, because there are decoders that 
support Main but not all of Baseline.
If you still think constraint_set[01]_flag should be set, then I'll set 
them based on the value of sps->i_profile, not duplicate all the 
parameter checks.

--Loren Merritt

From lll+vlc at m4x.org  Fri May 12 08:36:34 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 12 May 2006 08:36:34 +0200
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu>
References: <20060511171406.GG1485@pavuc.le-loarer.org> <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu>
Message-ID: <20060512063634.GA23574@pavuc.le-loarer.org>

Le Thursday 11 May 2006 ? 16:24:26 -0700, Loren Merritt a ?crit:
> On Thu, 11 May 2006, Lo?c Le Loarer wrote:
> 
> >Here is a patch which set the flags constraint_set0_flag and
> >constraint_set1_flag when possible. This has the advandage of giving
> >more information on the stream which may help decoders.
> >
> >I have included the text from the H.264 norm so that in case of
> >improvement in x264 supported feature, the flags can be corrected
> >accordingly easily.
> >
> >+ Set constraint_set0_flag if the BASELINE constraint are fulfilled
> >+ even if the profile is not BASELINE, this allows a BASELINE only 
> >+ decoder to decode the stream
> 
> Why? x264 selects profile based on which features are enabled. It will 
> never generate a Baseline-compatible stream that isn't actually marked as 
> Baseline.

Sure, so it is not necessary to set constraint_set0_flag. I added it for
completeness but it is not important. You can let it to 0 if you prefer.

> I suppose you could argue that there is some value in setting 
> constraint_set1_flag for Baseline files, because there are decoders that 
> support Main but not all of Baseline.

This is what I wanted to add. Because of this and because it is faster
to do deblocking on the fly as it is possible in MAIN.

> If you still think constraint_set[01]_flag should be set, then I'll set 
> them based on the value of sps->i_profile, not duplicate all the 
> parameter checks.

This is the case for constraint_set1_flag as the only test is
(sps->i_profile_idc < PROFILE_HIGH), all the other lines are here to
quote the norm so that it is easy to understand what and why is done,
and to complete the tests when the features supported by x264 are
increased.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060512/035f46a6/attachment.pgp 

From lll+vlc at m4x.org  Fri May 12 08:45:10 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 12 May 2006 08:45:10 +0200
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <20060512063634.GA23574@pavuc.le-loarer.org>
References: <20060511171406.GG1485@pavuc.le-loarer.org> <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu> <20060512063634.GA23574@pavuc.le-loarer.org>
Message-ID: <20060512064510.GB23574@pavuc.le-loarer.org>

The Thursday 11 May 2006 16:24:26 -0700, Loren Merritt wrote:
> If you still think constraint_set[01]_flag should be set, then I'll set 
> them based on the value of sps->i_profile, not duplicate all the 
> parameter checks.

By the way, by checking that parameter checks are really duplicated, I
discover that the profile can be set to BASELINE while to shouldn't:
when weighted_bipred_idc (b_weighted_bipred is x264) is not 0.

I think the attached patch should be applied to correct this.

Thank you

-- 
Lo?c
-------------- next part --------------
Index: encoder/set.c
===================================================================
--- encoder/set.c	(r??vision 522)
+++ encoder/set.c	(copie de travail)
@@ -82,7 +82,7 @@
         sps->i_profile_idc  = PROFILE_HIGH444;
     else if( param->analyse.b_transform_8x8 || param->i_cqm_preset != X264_CQM_FLAT )
         sps->i_profile_idc  = PROFILE_HIGH;
-    else if( param->b_cabac || param->i_bframe > 0 )
+    else if( param->b_cabac || param->i_bframe > 0 || param->analyse.b_weighted_bipred != 0)
         sps->i_profile_idc  = PROFILE_MAIN;
     else
         sps->i_profile_idc  = PROFILE_BASELINE;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060512/31eed38d/attachment.pgp 

From svn at videolan.org  Fri May 12 10:17:54 2006
From: svn at videolan.org (Subversion daemon)
Date: Fri, 12 May 2006 10:17:54 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r523 (pengvado)
Message-ID: <20060512081754.E72DC205D@ganesh.videolan.org>

r523 | pengvado | 2006-05-12 10:17:53 +0200 (Fri, 12 May 2006) | 3 lines
Changed paths:
   M /trunk/encoder/encoder.c
   M /trunk/encoder/set.c

set the SPS constraint_set[01]_flag based on the profile in use, just in case some decoder cares


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Fri May 12 10:18:20 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Fri, 12 May 2006 01:18:20 -0700 (PDT)
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <20060512063634.GA23574@pavuc.le-loarer.org>
References: <20060511171406.GG1485@pavuc.le-loarer.org>
 <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu>
 <20060512063634.GA23574@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605120050420.197570@dante65.u.washington.edu>

On Fri, 12 May 2006, Lo?c Le Loarer wrote:
> Le Thursday 11 May 2006 ? 16:24:26 -0700, Loren Merritt a ?crit:
>
>> I suppose you could argue that there is some value in setting
>> constraint_set1_flag for Baseline files, because there are decoders that
>> support Main but not all of Baseline.
>
> This is what I wanted to add. Because of this and because it is faster
> to do deblocking on the fly as it is possible in MAIN.

I don't buy speed as a reason. If I were implementing a decoder that 
supported both strategies of deblocking, I would select which one to use 
based on whether slicegroups or ASO were used in any given frame, not on 
the profile or constraint_set.

> By the way, by checking that parameter checks are really duplicated, I
> discover that the profile can be set to BASELINE while to shouldn't:
> when weighted_bipred_idc (b_weighted_bipred is x264) is not 0.

weighted_bipred applies only to B-frames. If there are B-frames, it's 
already not Baseline. However, I did fail to forbid weighted_bipred when 
not using B-frames. Fixed that instead.

--Loren Merritt

From lll+vlc at m4x.org  Fri May 12 11:36:11 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 12 May 2006 11:36:11 +0200
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <Pine.A41.4.64.0605120050420.197570@dante65.u.washington.edu>
References: <20060511171406.GG1485@pavuc.le-loarer.org> <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu> <20060512063634.GA23574@pavuc.le-loarer.org> <Pine.A41.4.64.0605120050420.197570@dante65.u.washington.edu>
Message-ID: <20060512093611.GB20545@pavuc.le-loarer.org>

Le Friday 12 May 2006 ? 01:18:20 -0700, Loren Merritt a ?crit:
> On Fri, 12 May 2006, Lo?c Le Loarer wrote:
> >Le Thursday 11 May 2006 ? 16:24:26 -0700, Loren Merritt a ?crit:
> >
> >>I suppose you could argue that there is some value in setting
> >>constraint_set1_flag for Baseline files, because there are decoders that
> >>support Main but not all of Baseline.
> >
> >This is what I wanted to add. Because of this and because it is faster
> >to do deblocking on the fly as it is possible in MAIN.
> 
> I don't buy speed as a reason. If I were implementing a decoder that 
> supported both strategies of deblocking, I would select which one to use 
> based on whether slicegroups or ASO were used in any given frame, not on 
> the profile or constraint_set.

I agree for slicegroups but not for ASO, you cannot know if ASO is used
without parsing all the slice headers of a picture, it is not always
practical and not all decoders will do this.

> >By the way, by checking that parameter checks are really duplicated, I
> >discover that the profile can be set to BASELINE while to shouldn't:
> >when weighted_bipred_idc (b_weighted_bipred is x264) is not 0.
> 
> weighted_bipred applies only to B-frames. If there are B-frames, it's 
> already not Baseline. However, I did fail to forbid weighted_bipred when 
> not using B-frames. Fixed that instead.

You are right, this is better.

On this point, the H.264 norm is a bit other restrictive,
weighted_bipred_idc has no meaning in Baseline, it shouldn't be
restricted like the direct_8x8_inference_flag.

Thank you.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060512/b6f1022d/attachment.pgp 

From teemu.tuominen at imap.tut.fi  Fri May 12 12:38:01 2006
From: teemu.tuominen at imap.tut.fi (Teemu Tuominen)
Date: Fri, 12 May 2006 13:38:01 +0300
Subject: [x264-devel] Explanation request for ME
Message-ID: <44646589.90302@imap.tut.fi>

Hi,

I just quikly looked at the ME implementation in x264. It's quite 
understandable code, i would say. However, it would be very nice if 
someone could explain if there is some tricks beneath or above the 
search pattern code. If we leave subpel search out of the question, can 
fullsearch be comparable with other implementations. I am considering to 
use x264 in small ME testing environment and i would be pleased for any 
support.

Here are some questions that i firstly wondered...
SAD-functions seemed not to use early break feature. Does x264 use some 
pixel desimation method for SAD.  In which phase is the interpolation 
done for subpel search. Is there any upper-level predictors for motion 
field that leaves BMA entirely out for certain blocks. In other words, 
how precisely can x264 cover the error surface if FS comparison is 
implemented. Is the implemented ESA comparable with fullsearch at 
fulpel-level ? And so on..



-TT-

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lll+vlc at m4x.org  Fri May 12 18:19:48 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 12 May 2006 18:19:48 +0200
Subject: [x264-devel] [PATCH] frame_num increment in non-refererence frames
Message-ID: <20060512161948.GC20545@pavuc.le-loarer.org>

Hi,

x264 is current producing invalid streams when B frames are used because
frame_num are not correctly incremented. According to paragraph 7.4.3,
frame_num must not be equal to PrevRefFrameNum (except in special cases
when fields are used), so the frame_num must be incremented after a
reference picture but not after a non reference picture.

If I and P pictures are reference and B pictures are not reference, the
following order should be seen :
I P B B P B P P B P ...
0 1 2 2 2 3 3 4 5 5 ...

while x264 is producing :
I P B B P B P P B P ...
0 1 1 1 2 2 3 4 4 5 ...

I have made a patch which seems to correct this but I'm not enterely
sure it is really correct as I don't know the code well enough. Can you
take a look at this ?

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(revision 523)
+++ encoder/encoder.c	(working copy)
@@ -864,14 +864,14 @@
     /* ------------------------ Create slice header  ----------------------- */
     if( i_nal_type == NAL_SLICE_IDR )
     {
-        x264_slice_header_init( h, &h->sh, h->sps, h->pps, i_slice_type, h->i_idr_pic_id, h->i_frame_num - 1, i_global_qp );
+        x264_slice_header_init( h, &h->sh, h->sps, h->pps, i_slice_type, h->i_idr_pic_id, h->i_frame_num, i_global_qp );
 
         /* increment id */
         h->i_idr_pic_id = ( h->i_idr_pic_id + 1 ) % 65536;
     }
     else
     {
-        x264_slice_header_init( h, &h->sh, h->sps, h->pps, i_slice_type, -1, h->i_frame_num - 1, i_global_qp );
+        x264_slice_header_init( h, &h->sh, h->sps, h->pps, i_slice_type, -1, h->i_frame_num, i_global_qp );
 
         /* always set the real higher num of ref frame used */
         h->sh.b_num_ref_idx_override = 1;
@@ -1292,12 +1292,12 @@
     if( i_slice_type == SLICE_TYPE_B )
         x264_macroblock_bipred_init( h );
 
+    /* ------------------------ Create slice header  ----------------------- */
+    x264_slice_init( h, i_nal_type, i_slice_type, i_global_qp );
+
     if( h->fenc->b_kept_as_ref )
         h->i_frame_num++;
 
-    /* ------------------------ Create slice header  ----------------------- */
-    x264_slice_init( h, i_nal_type, i_slice_type, i_global_qp );
-
     /* ---------------------- Write the bitstream -------------------------- */
     /* Init bitstream context */
     h->out.i_nal = 0;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060512/8bae0e87/attachment.pgp 

From lorenm at u.washington.edu  Fri May 12 20:29:41 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Fri, 12 May 2006 11:29:41 -0700 (PDT)
Subject: [x264-devel] Re: [PATCH] set constraint_set[01]_flag when possible
In-Reply-To: <20060512093611.GB20545@pavuc.le-loarer.org>
References: <20060511171406.GG1485@pavuc.le-loarer.org>
 <Pine.A41.4.64.0605111434020.124672@dante74.u.washington.edu>
 <20060512063634.GA23574@pavuc.le-loarer.org>
 <Pine.A41.4.64.0605120050420.197570@dante65.u.washington.edu>
 <20060512093611.GB20545@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605121127110.10950@dante65.u.washington.edu>

On Fri, 12 May 2006, Lo?c Le Loarer wrote:

> Le Friday 12 May 2006 ? 01:18:20 -0700, Loren Merritt a ?crit:
>> On Fri, 12 May 2006, Lo?c Le Loarer wrote:
>>> Le Thursday 11 May 2006 ? 16:24:26 -0700, Loren Merritt a ?crit:
>>>
>>>> I suppose you could argue that there is some value in setting
>>>> constraint_set1_flag for Baseline files, because there are decoders that
>>>> support Main but not all of Baseline.
>>>
>>> This is what I wanted to add. Because of this and because it is faster
>>> to do deblocking on the fly as it is possible in MAIN.
>>
>> I don't buy speed as a reason. If I were implementing a decoder that
>> supported both strategies of deblocking, I would select which one to use
>> based on whether slicegroups or ASO were used in any given frame, not on
>> the profile or constraint_set.
>
> I agree for slicegroups but not for ASO, you cannot know if ASO is used
> without parsing all the slice headers of a picture, it is not always
> practical and not all decoders will do this.

Start decoding with inline deblocking. When/if you get to a slice that's 
out of order, stop deblocking, and do the rest after decoding.

--Loren Merritt

From lorenm at u.washington.edu  Fri May 12 21:22:51 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Fri, 12 May 2006 12:22:51 -0700 (PDT)
Subject: [x264-devel] Re: Explanation request for ME
In-Reply-To: <44646589.90302@imap.tut.fi>
References: <44646589.90302@imap.tut.fi>
Message-ID: <Pine.A41.4.64.0605121147570.10950@dante65.u.washington.edu>

On Fri, 12 May 2006, Teemu Tuominen wrote:

> I just quikly looked at the ME implementation in x264. It's quite 
> understandable code, i would say. However, it would be very nice if someone 
> could explain if there is some tricks beneath or above the search pattern 
> code. If we leave subpel search out of the question, can fullsearch be 
> comparable with other implementations. I am considering to use x264 in small 
> ME testing environment and i would be pleased for any support.
>
> Here are some questions that i firstly wondered...
> SAD-functions seemed not to use early break feature.

MMX/SSE2 SAD is fast. Putting a branch in the middle makes it slower.

> Does x264 use some pixel desimation method for SAD.

No.

> In which phase is the interpolation done for subpel search.

Immediately after encoding a frame, we perform all the half-pixel 
interpolations and save the results. Subpel search then reads the 
interpolated pixels from there, and may average 2 of them to get a 
quarter-pixel offset.
See common/mc.c:x264_frame_filter() (which also inits ESA).

> Is there any upper-level predictors for motion field that leaves BMA 
> entirely out for certain blocks. In other words, how precisely can 
> x264 cover the error surface if FS comparison is implemented.

Fast P-skip and B-skip will omit BMA (and all other decisions too) if the 
Skip block type has sufficiently low residual. You can disable them in 
x264 (--no-fast-pskip --subme=6 --b-rdo), in which case BMA is performed 
on all blocks.

> Is the implemented ESA comparable with fullsearch at fullpel-level?

"exhaustive search" == "full search".
And successive elimination doesn't change the results at all, it's just 
faster.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From tuukkat at ee.oulu.fi  Mon May 15 10:01:53 2006
From: tuukkat at ee.oulu.fi (Tuukka Toivonen)
Date: Mon, 15 May 2006 11:01:53 +0300 (EEST)
Subject: [x264-devel] Re: Video is faster to Audio
In-Reply-To: <20060510162602.6FDFC1CE305@ws1-6.us4.outblaze.com>
References: <20060510162602.6FDFC1CE305@ws1-6.us4.outblaze.com>
Message-ID: <Pine.GSO.4.61.0605151100210.19789@tk1>

On Wed, 10 May 2006, GILBERTO SANCHEZ wrote:

>mencoder kiss.asf -o out.mp4 -of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames -oac faac -faacopts br=256 -ovc x264 -x264encopts qp_min=10:qp_max=51:qp_step=4:ratetol=60:ip_factor=1.4:pb_factor=1.3:qcomp=0.7:scenecut=40:keyint=51:keyint_min=10:
>frameref=3:bframes=3:b_bias=0:direct_pred=2:b_adapt:b_pyramid:cabac:weight_b:me=2:subq=5:chroma_me:mixed_refs:brdo:bime:4x4mv:i4x4:i8x8:
>8x8mv:b8x8mv:8x8dct

Try to add options

-mc 0 -noskip -skiplimit 0

it might help.

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lll+vlc at m4x.org  Tue May 16 13:06:21 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Tue, 16 May 2006 13:06:21 +0200
Subject: [x264-devel] Interlaced support developpement
Message-ID: <20060516110621.GC20501@pavuc.le-loarer.org>

Hi,

Because H.264 usage is starting to grow in TV field mainly, interlaced
support is essential for an encoder (TV camera often produce interlaced
content and TV display are interlaced often).

So I'd like to start working during my spare time to add interlaced
support to x264 and I'd like to know if anyone is already working on
this and if such a contribution would be welcomed and have a chance to
be intergrated.

I plan to add MBAFF support first because it seems the most efficient
feature of H.264 to encode interlaced content (I see PAFF mode as a
compatibility mode for MPEG2 encoder). I'll submit my patches often, so
that my code can be reviewed and corrected early and can reach consensus
of all other developpers involed in x264.

If I have the time, I'll also try to add support in FFmpeg to decode the
interlaced content produced by x264 with my patches.

Any comments ?

Best regards.

-- 
Lo?c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060516/aa5a3d74/attachment.pgp 

From skal at planet-d.net  Tue May 16 16:17:03 2006
From: skal at planet-d.net (skal)
Date: Tue, 16 May 2006 16:17:03 +0200
Subject: [x264-devel] Re: Interlaced support developpement
In-Reply-To: <20060516110621.GC20501@pavuc.le-loarer.org>
References: <20060516110621.GC20501@pavuc.le-loarer.org>
Message-ID: <1147789024.10816.15.camel@localhost>


   Hi all,

On Tue, 2006-05-16 at 13:06 +0200, Lo?c Le Loarer wrote:
[...]
> Any comments ?

  open( pandora_box );


Skal

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From fseitner at ondemand.co.at  Mon May 15 11:00:43 2006
From: fseitner at ondemand.co.at (Florian Seitner)
Date: Mon, 15 May 2006 11:00:43 +0200
Subject: [x264-devel] Integral projection
Message-ID: <3E031E765F5EFC4D9F4112697539491FC70463@server.silicon.local>


Hi!

  I have a question regarding the integral images used in the x264
project. How are they used exactly? Are they used to compute the SAD or
like integral projections?

  Florian

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From mulder2 at gmx.de  Mon May 15 17:52:57 2006
From: mulder2 at gmx.de (MuldeR)
Date: Mon, 15 May 2006 17:52:57 +0200
Subject: [x264-devel] If you use x264 in another project, let us know !
Message-ID: <4468A3D9.3090304@gmx.de>

If you use x264 in another project, let us know !

Done so:
http://free.pages.at/borschdfresser/public/home/html/projects.html#mencoder264

Greeeeetz
MuldeR

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Tue May 16 22:24:24 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Tue, 16 May 2006 13:24:24 -0700 (PDT)
Subject: [x264-devel] Re: Integral projection
In-Reply-To: <3E031E765F5EFC4D9F4112697539491FC70463@server.silicon.local>
References: <3E031E765F5EFC4D9F4112697539491FC70463@server.silicon.local>
Message-ID: <Pine.A41.4.64.0605161322550.123408@dante65.u.washington.edu>

On Mon, 15 May 2006, Florian Seitner wrote:

>  I have a question regarding the integral images used in the x264
> project. How are they used exactly? Are they used to compute the SAD or
> like integral projections?

It is used the compute SAD during successive elimination motion search.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From nabeeliqbalus at yahoo.com  Wed May 17 10:33:31 2006
From: nabeeliqbalus at yahoo.com (Nabeel Iqbal)
Date: Wed, 17 May 2006 01:33:31 -0700 (PDT)
Subject: [x264-devel] Re: Interlaced support developpement
In-Reply-To: <1147789024.10816.15.camel@localhost>
Message-ID: <20060517083331.28683.qmail@web31810.mail.mud.yahoo.com>

Hi,
   i am interested in implementation of fields in x264 so you can consider me as a resource in this development. can we make it official for x264 project ? waiting for comments from project manager.
   
  Regards
  Nabeel Iqbal

skal <skal at planet-d.net> wrote:
  
Hi all,

On Tue, 2006-05-16 at 13:06 +0200, Lo?c Le Loarer wrote:
[...]
> Any comments ?

open( pandora_box );


Skal

--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060517/7e9fd535/attachment.htm 

From fseitner at ondemand.co.at  Wed May 17 14:30:52 2006
From: fseitner at ondemand.co.at (Florian Seitner)
Date: Wed, 17 May 2006 14:30:52 +0200
Subject: [x264-devel] Re: Integral projection
Message-ID: <3E031E765F5EFC4D9F4112697539491FC70466@server.silicon.local>

Thanks Loren! 

I guessed so. I am currently working on H.264 encoder for an embedded
chip. The available resources (memory/cache sizes/..) are quite limited
and an extra computation of an integral image for each frame quite
costly. 

Maybe integral projections for fast block matching would be a good
feature to add in x264. They are probably quite useable in embedded
solutions since they are updated locally and do not require as much
memory as e.g. a whole integral images. In case that there is enough
memory available to compute the integral images, we could also use them
for computing the integral projections... .

Is there a plan to implement integral projections (someone out there who
is working on this?)?

  Florian




-----Original Message-----
From: Loren Merritt [mailto:lorenm at u.washington.edu] 
Sent: Dienstag, 16. Mai 2006 22:24
To: x264-devel at videolan.org
Subject: [x264-devel] Re: Integral projection

On Mon, 15 May 2006, Florian Seitner wrote:

>  I have a question regarding the integral images used in the x264
> project. How are they used exactly? Are they used to compute the SAD
or
> like integral projections?

It is used the compute SAD during successive elimination motion search.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Thu May 18 22:13:08 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Thu, 18 May 2006 13:13:08 -0700 (PDT)
Subject: [x264-devel] Re: Integral projection
In-Reply-To: <3E031E765F5EFC4D9F4112697539491FC70466@server.silicon.local>
References: <3E031E765F5EFC4D9F4112697539491FC70466@server.silicon.local>
Message-ID: <Pine.A41.4.64.0605181202080.133948@dante72.u.washington.edu>

On Wed, 17 May 2006, Florian Seitner wrote:

> I guessed so. I am currently working on H.264 encoder for an embedded
> chip. The available resources (memory/cache sizes/..) are quite limited
> and an extra computation of an integral image for each frame quite
> costly.
>
> Maybe integral projections for fast block matching would be a good
> feature to add in x264. They are probably quite useable in embedded
> solutions since they are updated locally and do not require as much
> memory as e.g. a whole integral images. In case that there is enough
> memory available to compute the integral images, we could also use them
> for computing the integral projections... .

The integral image was a fun feature that I implemented just because I 
could. It's not useful, and I recommend that you not port it to your 
embedded app even if you could. Even with the integral optimizations, 
exhaustive search is still much slower than any of x264's 3 iterative 
search methods, and rarely produces measurably better motion vectors.

As far as I can tell from a little reading, integral projections are the 
same idea as integral image, applied to PHODS instead of exhaustive 
search. Yes it will be fast, but I have doubts about the quality. PHODS 
didn't work very well in libavcodec.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lll+vlc at m4x.org  Fri May 19 10:27:52 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 19 May 2006 10:27:52 +0200
Subject: [x264-devel] Re: [PATCH] set a valid value in direct_8x8_inference_flag
In-Reply-To: <20060511174455.GB21736@pavuc.le-loarer.org>
References: <20060511174455.GB21736@pavuc.le-loarer.org>
Message-ID: <20060519082752.GN20501@pavuc.le-loarer.org>

Hi,

Le Thursday 11 May 2006 ? 19:44:55 +0200, Lo?c Le Loarer a ?crit:
> This patch avoids to produce invalid streams by enforcing the level
> restrictions on direct_8x8_inference_flag value. It also allows the
> application to ask for a given value of direct_8x8_inference_flag.

I'd like to know what is the status of this patch and other patches I
have sent for which I have no answer yet.

It would be great it the issues I pointed out and try to solve find a
solution in x264 code, the bitstreams produced may be invalid...

Best regards.

-- 
Lo?c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060519/01017475/attachment.pgp 

From lll+vlc at m4x.org  Fri May 19 10:21:07 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Fri, 19 May 2006 10:21:07 +0200
Subject: [x264-devel] [PATCH] test decoded pictures
Message-ID: <20060519082107.GM20501@pavuc.le-loarer.org>

Hi,

Here is a patch which allows to check that the view of decoded pictures
in the encoder is the same as the decoder even when non references
frames are used (and display order is not the same as encoding order).

It also contains a document which explain how to do the comparaison
using the JM reference H264 decoder.

This is very usefull to check that any change in the encoder doesn't
break too much things.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
diff -ruN x264.orig/doc/test_method.txt x264.new/doc/test_method.txt
--- x264.orig/doc/test_method.txt	1970-01-01 01:00:00.000000000 +0100
+++ x264.new/doc/test_method.txt	2006-05-19 10:08:52.000000000 +0200
@@ -0,0 +1,25 @@
+Here is one test method which check that the encoder
+vision of decoded pictures in the same as the decoder
+view, this ensure that there is distortion between what
+the encoder and the decoder.
+
+Install and compile x264 :
+svn co svn://svn.videolan.org/x264/trunk x264
+cd x264
+./configure
+perl -i -pe 's|//(#define DEBUG_DUMP_FRAME)|$1|' encoder/encoder.c # define DEBUG_DUMP_FRAME
+make
+cd ..
+
+Install and compile JM reference decoder :
+wget http://iphome.hhi.de/suehring/tml/download/jm10.2.zip
+unzip jm10.2.zip
+cd JM
+sh unixprep.sh
+cd ldecod
+make
+cd ../..
+
+./x264/x264 input.yuv -o output.h264 # this produce fdec.yuv
+./JM/bin/ldecod.exe -i output.h264 -o ref.yuv
+diff ref.yuv fdec.yuv
diff -ruN x264.orig/encoder/encoder.c x264.new/encoder/encoder.c
--- x264.orig/encoder/encoder.c	2006-05-19 10:05:05.000000000 +0200
+++ x264.new/encoder/encoder.c	2006-05-19 10:13:22.000000000 +0200
@@ -76,12 +76,22 @@
 }
 
 #ifdef DEBUG_DUMP_FRAME
-static void x264_frame_dump( x264_t *h, x264_frame_t *fr, char *name )
-{
-    FILE * f = fopen( name, "a" );
+#include <sys/stat.h> /* for open modes */
+#include <fcntl.h>    /* for open flags */
+static void x264_frame_dump( x264_t *h, x264_frame_t *fr, char *name, int i_frame )
+{
+    /* Open the dump frame in write mode without trunc nor append option,
+     * to allow seeking at the correct place (encoding order is different
+     * than display order).
+     * This is not possible with fopen directly, so use open system call
+     * and then fdopen to add a FILE structure on the created file descriptor.
+     */
+    int fd   = open( name, O_CREAT|O_WRONLY, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH );
+    FILE * f = fdopen( fd, "w" );
     int i, y;
 
-    fseek( f, 0, SEEK_END );
+    /* Write the frame in display order */
+    i = fseek( f, i_frame * h->param.i_height * h->param.i_width * 3 / 2, SEEK_SET );
 
     for( i = 0; i < fr->i_plane; i++ )
     {
@@ -810,10 +820,8 @@
     h->i_ref0 = X264_MIN( h->i_ref0, 16 - h->i_ref1 );
 }
 
-static inline void x264_reference_update( x264_t *h )
+static inline void x264_fdec_deblock( x264_t *h )
 {
-    int i;
-
     /* apply deblocking filter to the current decoded picture */
     if( !h->sh.i_disable_deblocking_filter_idc )
     {
@@ -821,6 +829,13 @@
         x264_frame_deblocking_filter( h, h->sh.i_type );
         TIMER_STOP( i_mtime_filter );
     }
+}
+
+static inline void x264_reference_update( x264_t *h )
+{
+    int i;
+
+    x264_fdec_deblock( h );
     /* expand border */
     x264_frame_expand_border( h->fdec );
 
@@ -1479,6 +1494,10 @@
     /* handle references */
     if( i_nal_ref_idc != NAL_PRIORITY_DISPOSABLE )
         x264_reference_update( h );
+#ifdef DEBUG_DUMP_FRAME
+    else
+        x264_fdec_deblock( h );
+#endif
     x264_frame_put( h->frames.unused, h->fenc );
 
     /* increase frame count */
@@ -1585,7 +1604,7 @@
 
 #ifdef DEBUG_DUMP_FRAME
     /* Dump reconstructed frame */
-    x264_frame_dump( h, frame_psnr, "fdec.yuv" );
+    x264_frame_dump( h, frame_psnr, "fdec.yuv", h->fenc->i_frame );
 #endif
     return 0;
 }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060519/1c697c9c/attachment.pgp 

From jelle-x264-devel at foks.8m.com  Fri May 19 20:24:45 2006
From: jelle-x264-devel at foks.8m.com (Jelle)
Date: Fri, 19 May 2006 14:24:45 -0400
Subject: [x264-devel] Re: Another CPU related question
In-Reply-To: <Pine.A41.4.64.0605102048320.118926@dante65.u.washington.edu>
References: <aa7a75950605030249q89347f1lb84143cc3bc8878e@mail.gmail.com> <Pine.A41.4.64.0605031024570.194924@dante65.u.washington.edu> <44591EBA.3050301@foks.8m.com> <Pine.A41.4.64.0605031439290.123596@dante73.u.washington.edu> <445B8F32.8090702@foks.8m.com> <Pine.A41.4.64.0605102048320.118926@dante65.u.washington.edu>
Message-ID: <446E0D6D.2090706@foks.8m.com>

Loren Merritt wrote:
> On Fri, 5 May 2006, Jelle wrote:
>> Loren Merritt wrote:
>>>
>>> No, I don't know whether my videocard supports xvmc, but I certainly 
>>> haven't enabled it in ffmpeg. This is cpu-time as measured by
>>> `time mplayer -benchmark -vo null -nosound -vc ffmpeg2`.
>>
>> Ok, I'll run that too then.
>>
>> Two different machines. I know for sure that neither machines have 
>> videocards that support Xvmc.
>>
>> Athlon64 3200+ (2GHz/512kb cache)
>> MPEG2 video 480x576 at 25fps, 2.5Mbit/s (much less than DVD), 4688 
>> seconds long.
>> 100 * 12*60+20/4688 =~ 16% CPU.
>>
>> P4/3GHz/1M cache
>> MPEG2 video 720x480 at 29.97fps, 4.5Mbit/s, 1886 seconds long
>> 100 * 4*60+12/1886 =~ 13% CPU.
>>
>> I don't know where you got 2%, but I can't reproduce anything even 
>> close to it.
>>
>> 2% of a 2.2GHz CPU, or 44MHz, for DVD video? How can I get that?
> 
> Ok, so it wasn't quite 2%.

Still a lot better than what I get... If it's not Xvmc, I'd like to know 
what it is. Am I doing something wrong?

The server for the mplayer CVS is down, so I tried the latest release 
mplayer (1.07pre7try2, compile with plain './configure').

I reran the 480x576 2.5Mbit video, and it got to 11.6% on the 3200+. I 
also ran it on a Turion (2.2GHz/1MB cache), and it needed 5.4% there 
(4.9% in x86_64 mode (pure64)), a 2.8GHz/512KB cache Xeon needed 5.6%.

At 480x576, that is quite a lot less macroblocks than a full DVD, but 
still it needs significantly more CPU than your benchmark. The 
difference is much more than you would expect from the CPU speed difference.

Am I doing something wrong? Or is the CVS version of mplayer that much 
faster than the latest release?

(A 4.5Mbit/s 720x480 stream on the P4/3Ghz/1M cache still needed 11.3% 
with mplayer 1.07pre7try2).


Jelle.

> 
> Athlon64 3400+ (2.2GHz/1024kb cache)
> MPlayer dev-CVS-060508-14:21-4.0.4
> 
> MPEG2 video 720x480x23.976fps, 4.1 Mbit/s, 5598 seconds
> BENCHMARKs: VC: 184.573s VO:  0.124s A:  0.000s Sys:  5.560s = 190.297s
> BENCHMARK%: VC: 96.9921% VO: 0.0652% A: 0.0000% Sys: 2.9227% = 100.0000%
> real    191.395s
> user    185.882s
> sys     3.446s
> 
> 100% * 191.395 / 5598 = 3.4% CPU
> 
> MPEG2 video 720x480x23.976fps, 8.4 Mbit/s, 3750 seconds
> BENCHMARKs: VC: 232.713s VO:  0.086s A:  0.000s Sys: 10.425s = 243.224s
> BENCHMARK%: VC: 95.6782% VO: 0.0354% A: 0.0000% Sys: 4.2863% = 100.0000%
> real    244.856s
> user    233.706s
> sys     5.401s
> 
> 100% * 244.856 / 3750 = 6.5% CPU
> 
>> mpeg2 decoding takes about the same amount of operations per frame as 
>> JPEG (mjpeg) encoding. If your 2% number is really valid, you should 
>> be able to transcode mpeg2 to mjpeg 25 times faster than real-time 
>> (ramdisk to ramdisk if necessary).
> 
> Transcoding mpeg2->mjpeg is only 6x realtime here (using the 3.4% dvd).
> mjpeg takes more time for bitstream packing because it's higher bitrate, 
> and more time for dct/quant because when encoding you need to process 
> all pixels/coefs, whereas when decoding you skip the null coefs and null 
> blocks. And yes, those factors combined cost more than a little motion 
> compensation does.
> 
> --Loren Merritt
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Fri May 19 21:14:29 2006
From: svn at videolan.org (Subversion daemon)
Date: Fri, 19 May 2006 21:14:29 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r524 (pengvado)
Message-ID: <20060519191429.92EF4419A@ganesh.videolan.org>

r524 | pengvado | 2006-05-19 21:14:29 +0200 (Fri, 19 May 2006) | 4 lines
Changed paths:
   M /trunk/encoder/encoder.c

non-referenced B-frames should have the same frame_num as the following ref frame, not the previous.
patch by Loic Le Loarer.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Fri May 19 22:10:41 2006
From: svn at videolan.org (Subversion daemon)
Date: Fri, 19 May 2006 22:10:41 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r525 (pengvado)
Message-ID: <20060519201041.78D973161@ganesh.videolan.org>

r525 | pengvado | 2006-05-19 22:10:41 +0200 (Fri, 19 May 2006) | 4 lines
Changed paths:
   A /trunk/doc/regression_test.txt
   M /trunk/encoder/encoder.c

when using DEBUG_DUMP_FRAME, write decoded pictures in display order.
patch by Loic Le Loarer.


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Fri May 19 22:13:29 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Fri, 19 May 2006 13:13:29 -0700 (PDT)
Subject: [x264-devel] Re: [PATCH] set a valid value in direct_8x8_inference_flag
In-Reply-To: <20060519082752.GN20501@pavuc.le-loarer.org>
References: <20060511174455.GB21736@pavuc.le-loarer.org>
 <20060519082752.GN20501@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605191140590.18160@dante65.u.washington.edu>

On Fri, 19 May 2006, Lo?c Le Loarer wrote:
> Le Thursday 11 May 2006 ? 19:44:55 +0200, Lo?c Le Loarer a ?crit:
>> This patch avoids to produce invalid streams by enforcing the level
>> restrictions on direct_8x8_inference_flag value. It also allows the
>> application to ask for a given value of direct_8x8_inference_flag.
>
> I'd like to know what is the status of this patch and other patches I
> have sent for which I have no answer yet.
>
> It would be great it the issues I pointed out and try to solve find a
> solution in x264 code, the bitstreams produced may be invalid...
>
> Best regards.

The option is ok, but the default value needs quality testing. If 8x8 
inference measurably reduces quality, then I will leave it off by 
default, even if that violates levels.

The mv range thing is probably ok, I'll review it sometime.

--Loren Merritt

From lll+vlc at m4x.org  Sat May 20 00:23:02 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Sat, 20 May 2006 00:23:02 +0200
Subject: [x264-devel] Re: x264: svn commit r525 (pengvado)
In-Reply-To: <20060519201041.78D973161@ganesh.videolan.org>
References: <20060519201041.78D973161@ganesh.videolan.org>
Message-ID: <20060519222302.GG23574@pavuc.le-loarer.org>

Le Friday 19 May 2006 ? 22:10:41 +0200, Subversion daemon a ?crit:
> r525 | pengvado | 2006-05-19 22:10:41 +0200 (Fri, 19 May 2006) | 4 lines
> Changed paths:
>    A /trunk/doc/regression_test.txt
>    M /trunk/encoder/encoder.c
> 
> when using DEBUG_DUMP_FRAME, write decoded pictures in display order.
> patch by Loic Le Loarer.

Thank you for applying these patches and correcting my bad english.

-- 
Lo?c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060520/57e81464/attachment.pgp 

From lll+vlc at m4x.org  Sat May 20 00:24:02 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Sat, 20 May 2006 00:24:02 +0200
Subject: [x264-devel] Re: [PATCH] set a valid value in direct_8x8_inference_flag
In-Reply-To: <Pine.A41.4.64.0605191140590.18160@dante65.u.washington.edu>
References: <20060511174455.GB21736@pavuc.le-loarer.org> <20060519082752.GN20501@pavuc.le-loarer.org> <Pine.A41.4.64.0605191140590.18160@dante65.u.washington.edu>
Message-ID: <20060519222402.GH23574@pavuc.le-loarer.org>

Le Friday 19 May 2006 ? 13:13:29 -0700, Loren Merritt a ?crit:
> On Fri, 19 May 2006, Lo?c Le Loarer wrote:
> >Le Thursday 11 May 2006 ? 19:44:55 +0200, Lo?c Le Loarer a ?crit:
> >>This patch avoids to produce invalid streams by enforcing the level
> >>restrictions on direct_8x8_inference_flag value. It also allows the
> >>application to ask for a given value of direct_8x8_inference_flag.

Thank you for taking time to take at look and answer. 
 
> The option is ok, but the default value needs quality testing. If 8x8 
> inference measurably reduces quality, then I will leave it off by 
> default, even if that violates levels.

Ok, I see your point of view, but the respect of the level contraints
are essential in my point of view, because they are used by decoders to
compute worst case senarii in term of memory, bandwidth, computing
ressources... and so be sure that they can decode any stream respecting
a given profile and level in real time. Producing invalid streams breaks
interoperability and should be avoided. I propose that the default
options always produce a valid stream and that some levels constraints
can be ignored only with a special option and a big fat warning.

More precisely, I propose that only the constraints which cannot be
removed by using a higher level _and_ can improve encoding quality, can
be violated (if explicitly asked only, not by default). If I read the
spec correctly, the candidates are: MaxMvsPer2Mb (not checked yet but
not relevant), direct_8x8_inference_flag, frame_mbs_only_flag (not
relevant yet), MinLumaBiPredSize (not relevant yet) and SliceRate (not
checked yet but not really a problem given the usage of slices). So only
direct_8x8_inference_flag needs to be evaluated for the moment and
you are working on it.

All the other constraints (MB rate, MaxFS, DPB size, MaxBR, MaxCPB,
MaxVmvR, MinCR (not yet checked, may be a problem for lossless mode))
should be enforced and the CHECK macro in x264_validate_levels should
return an error in such a condition, asking for a bigger level.

This way:
- someone using the default values (level=5.1) will still be nearly
  unconstrainted and produce a valid bitstream
- someone who cares about interoperability and sets a level (and other
  parameters like direct_8x8_inference_flag) will be confident that x264
  will respect the level contraints and produce a valid bitstream or
  refuse to encode at the given level
- and someone who knows what he does, control the decoder which will be
  used to decode his stream (and so can break interoperability) and
  really want to break the limits to increase quality will be able to 
  do it too.

I will try to give a patch which explain more clearly this.

> The mv range thing is probably ok, I'll review it sometime.
Thank you.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060520/61991780/attachment.pgp 

From lll+vlc at m4x.org  Sat May 20 02:45:58 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Sat, 20 May 2006 02:45:58 +0200
Subject: [x264-devel] Re: [PATCH] set a valid value in direct_8x8_inference_flag
In-Reply-To: <20060519222402.GH23574@pavuc.le-loarer.org>
References: <20060511174455.GB21736@pavuc.le-loarer.org> <20060519082752.GN20501@pavuc.le-loarer.org> <Pine.A41.4.64.0605191140590.18160@dante65.u.washington.edu> <20060519222402.GH23574@pavuc.le-loarer.org>
Message-ID: <20060520004558.GI23574@pavuc.le-loarer.org>

Hi,

Here is patch which implement the following proposal.
I also contains the previous direct_8x8_inference_flag patch I sent.

Best regards.
-- 
Lo?c

Le Saturday 20 May 2006 ? 00:24:02 +0200, Lo?c Le Loarer a ?crit:
> Le Friday 19 May 2006 ? 13:13:29 -0700, Loren Merritt a ?crit:
> > On Fri, 19 May 2006, Lo?c Le Loarer wrote:
> > >Le Thursday 11 May 2006 ? 19:44:55 +0200, Lo?c Le Loarer a ?crit:
> > >>This patch avoids to produce invalid streams by enforcing the level
> > >>restrictions on direct_8x8_inference_flag value. It also allows the
> > >>application to ask for a given value of direct_8x8_inference_flag.
> 
> Thank you for taking time to take at look and answer. 
>  
> > The option is ok, but the default value needs quality testing. If 8x8 
> > inference measurably reduces quality, then I will leave it off by 
> > default, even if that violates levels.
> 
> Ok, I see your point of view, but the respect of the level contraints
> are essential in my point of view, because they are used by decoders to
> compute worst case senarii in term of memory, bandwidth, computing
> ressources... and so be sure that they can decode any stream respecting
> a given profile and level in real time. Producing invalid streams breaks
> interoperability and should be avoided. I propose that the default
> options always produce a valid stream and that some levels constraints
> can be ignored only with a special option and a big fat warning.
> 
> More precisely, I propose that only the constraints which cannot be
> removed by using a higher level _and_ can improve encoding quality, can
> be violated (if explicitly asked only, not by default). If I read the
> spec correctly, the candidates are: MaxMvsPer2Mb (not checked yet but
> not relevant), direct_8x8_inference_flag, frame_mbs_only_flag (not
> relevant yet), MinLumaBiPredSize (not relevant yet) and SliceRate (not
> checked yet but not really a problem given the usage of slices). So only
> direct_8x8_inference_flag needs to be evaluated for the moment and
> you are working on it.
> 
> All the other constraints (MB rate, MaxFS, DPB size, MaxBR, MaxCPB,
> MaxVmvR, MinCR (not yet checked, may be a problem for lossless mode))
> should be enforced and the CHECK macro in x264_validate_levels should
> return an error in such a condition, asking for a bigger level.
> 
> This way:
> - someone using the default values (level=5.1) will still be nearly
>   unconstrainted and produce a valid bitstream
> - someone who cares about interoperability and sets a level (and other
>   parameters like direct_8x8_inference_flag) will be confident that x264
>   will respect the level contraints and produce a valid bitstream or
>   refuse to encode at the given level
> - and someone who knows what he does, control the decoder which will be
>   used to decode his stream (and so can break interoperability) and
>   really want to break the limits to increase quality will be able to 
>   do it too.
> 
> I will try to give a patch which explain more clearly this.
> 
> > The mv range thing is probably ok, I'll review it sometime.
> Thank you.
> 
> Best regards.
> 
> -- 
> Lo?c
> 
> "heaven is not a place, it's a feeling"
-------------- next part --------------
Index: encoder/set.h
===================================================================
--- encoder/set.h	(r??vision 525)
+++ encoder/set.h	(copie de travail)
@@ -29,6 +29,6 @@
 void x264_pps_init( x264_pps_t *pps, int i_id, x264_param_t *param, x264_sps_t *sps );
 void x264_pps_write( bs_t *s, x264_pps_t *pps );
 void x264_sei_version_write( x264_t *h, bs_t *s );
-void x264_validate_levels( x264_t *h );
+int  x264_validate_levels( x264_t *h );
 
 #endif
Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c	(r??vision 525)
+++ encoder/encoder.c	(copie de travail)
@@ -431,6 +431,26 @@
             h->param.analyse.i_mv_range = l->mv_range;
         else
             h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
+        /* Validate direct_8x8_inference_flag: */
+        if( h->param.i_direct_8x8_inference_flag < 0 )
+        {
+            /* The flag isn't forced, set it to 0 if the level doesn't
+             * limit it to 1 and it it possible to generate P macroblocks
+             * with partitions smaller than 8x8 */
+            h->param.i_direct_8x8_inference_flag = l->direct8x8 ? 1 : !(h->param.analyse.inter & X264_ANALYSE_PSUB8x8);
+        }
+        else
+        {
+            h->param.i_direct_8x8_inference_flag = x264_clip3( h->param.i_direct_8x8_inference_flag, 0, 1 );
+            /* if the level limits this flag to 1, check it isn't forced to 0 */
+            if (h->param.i_direct_8x8_inference_flag < l->direct8x8)
+            {
+                x264_log( h, X264_LOG_ERROR, "invalid direct_8x8_inference_flag %d for level %d\n", h->param.i_direct_8x8_inference_flag, h->param.i_level_idc );
+               if (!h->param.b_allow_invalid_bitstreams) {
+                   return -1;
+                }
+            }
+        }
     }
 
     if( h->param.rc.f_qblur < 0 )
@@ -536,7 +556,11 @@
     h->pps = &h->pps_array[0];
     x264_pps_init( h->pps, h->param.i_sps_id, &h->param, h->sps);
 
-    x264_validate_levels( h );
+    if (x264_validate_levels( h ) < 0)
+    {
+        x264_free( h );
+        return NULL;
+    }
 
     x264_cqm_init( h );
     
Index: encoder/set.c
===================================================================
--- encoder/set.c	(r??vision 525)
+++ encoder/set.c	(copie de travail)
@@ -130,13 +130,7 @@
     sps->i_mb_height= ( param->i_height + 15 )/ 16;
     sps->b_frame_mbs_only = 1;
     sps->b_mb_adaptive_frame_field = 0;
-    sps->b_direct8x8_inference = 0;
-    if( sps->b_frame_mbs_only == 0 ||
-        !(param->analyse.inter & X264_ANALYSE_PSUB8x8) )
-    {
-        sps->b_direct8x8_inference = 1;
-    }
-
+    sps->b_direct8x8_inference = param->i_direct_8x8_inference_flag;
     sps->crop.i_left   = 0;
     sps->crop.i_top    = 0;
     sps->crop.i_right  = (- param->i_width)  & 15;
@@ -518,7 +512,7 @@
     { 0 }
 };
 
-void x264_validate_levels( x264_t *h )
+int x264_validate_levels( x264_t *h )
 {
     int mbs;
 
@@ -530,12 +524,20 @@
     if( l->frame_size < mbs
         || l->frame_size*8 < h->sps->i_mb_width * h->sps->i_mb_width
         || l->frame_size*8 < h->sps->i_mb_height * h->sps->i_mb_height )
-        x264_log( h, X264_LOG_WARNING, "frame MB size (%dx%d) > level limit (%d)\n",
+    {
+        x264_log( h, X264_LOG_ERROR, "frame MB size (%dx%d) > level limit (%d)\n",
                   h->sps->i_mb_width, h->sps->i_mb_height, l->frame_size );
+        if (!h->param.b_allow_invalid_bitstreams)
+            return -1;
+    }
 
 #define CHECK( name, limit, val ) \
     if( (val) > (limit) ) \
-        x264_log( h, X264_LOG_WARNING, name " (%d) > level limit (%d)\n", (int)(val), (limit) );
+    { \
+        x264_log( h, X264_LOG_ERROR, name " (%d) > level limit (%d), try increase level\n", (int)(val), (limit) ); \
+        if (!h->param.b_allow_invalid_bitstreams) \
+            return -1; \
+    }
 
     CHECK( "DPB size", l->dpb, mbs * 384 * h->sps->i_num_ref_frames );
     CHECK( "VBV bitrate", l->bitrate, h->param.rc.i_vbv_max_bitrate );
Index: x264.c
===================================================================
--- x264.c	(r??vision 525)
+++ x264.c	(copie de travail)
@@ -202,6 +202,10 @@
              "                                  (p4x4 requires p8x8. i8x8 requires --8x8dct.)\n"
              "      --direct <string>       Direct MV prediction mode [\"%s\"]\n"
              "                                  - none, spatial, temporal, auto\n"
+             "      --direct_8x8 <-1|0|1>   Direct prediction size [%d]\n"
+             "                                  -  0: 4x4\n"
+             "                                  -  1: 8x8\n"
+             "                                  - -1: smallest possible according to level\n"
              "  -w, --weightb               Weighted prediction for B-frames\n"
              "      --me <string>           Integer pixel motion estimation method [\"%s\"]\n"
              "                                  - dia: diamond search, radius 1 (fast)\n"
@@ -314,6 +318,7 @@
             defaults->rc.f_complexity_blur,
             defaults->rc.f_qblur,
             strtable_lookup( x264_direct_pred_names, defaults->analyse.i_direct_mv_pred ),
+            defaults->i_direct_8x8_inference_flag,
             strtable_lookup( x264_motion_est_names, defaults->analyse.i_me_method ),
             defaults->analyse.i_me_range,
             defaults->analyse.i_subpel_refine,
@@ -452,6 +457,7 @@
 #define OPT_THREAD_INPUT 320
 #define OPT_NO_DCT_DECIMATE 321
 #define OPT_SPS_ID 322
+#define OPT_DIRECT_8X8 323
 
         static struct option long_options[] =
         {
@@ -481,6 +487,7 @@
             { "output",  required_argument, NULL, 'o' },
             { "analyse", required_argument, NULL, 'A' },
             { "direct",  required_argument, NULL, OPT_DIRECT },
+            { "direct_8x8",  required_argument, NULL, OPT_DIRECT_8X8 },
             { "weightb", no_argument,       NULL, 'w' },
             { "me",      required_argument, NULL, OPT_ME },
             { "merange", required_argument, NULL, OPT_MERANGE },
@@ -703,6 +710,9 @@
             case OPT_DIRECT:
                 b_error |= parse_enum( optarg, x264_direct_pred_names, &param->analyse.i_direct_mv_pred );
                 break;
+            case OPT_DIRECT_8X8:
+                param->i_direct_8x8_inference_flag = atoi(optarg);
+                break;
             case 'w':
                 param->analyse.b_weighted_bipred = 1;
                 break;
Index: common/common.c
===================================================================
--- common/common.c	(r??vision 525)
+++ common/common.c	(copie de travail)
@@ -72,6 +72,7 @@
     param->b_bframe_adaptive = 1;
     param->i_bframe_bias = 0;
     param->b_bframe_pyramid = 0;
+    param->i_direct_8x8_inference_flag = -1;
 
     param->b_deblocking_filter = 1;
     param->i_deblocking_filter_alphac0 = 0;
@@ -132,6 +133,7 @@
     memset( param->cqm_8iy, 16, 64 );
     memset( param->cqm_8py, 16, 64 );
 
+    param->b_allow_invalid_bitstreams = 0;
     param->b_repeat_headers = 1;
     param->b_aud = 0;
 }
@@ -485,10 +487,10 @@
     s += sprintf( s, " bframes=%d", p->i_bframe );
     if( p->i_bframe )
     {
-        s += sprintf( s, " b_pyramid=%d b_adapt=%d b_bias=%d direct=%d wpredb=%d bime=%d",
+        s += sprintf( s, " b_pyramid=%d b_adapt=%d b_bias=%d direct=%d d8x8=%d wpredb=%d bime=%d",
                       p->b_bframe_pyramid, p->b_bframe_adaptive, p->i_bframe_bias,
-                      p->analyse.i_direct_mv_pred, p->analyse.b_weighted_bipred,
-                      p->analyse.b_bidir_me );
+                      p->analyse.i_direct_mv_pred, p->i_direct_8x8_inference_flag,
+                      p->analyse.b_weighted_bipred, p->analyse.b_bidir_me );
     }
 
     s += sprintf( s, " keyint=%d keyint_min=%d scenecut=%d",
Index: x264.h
===================================================================
--- x264.h	(r??vision 525)
+++ x264.h	(copie de travail)
@@ -159,6 +159,7 @@
     int         b_bframe_adaptive;
     int         i_bframe_bias;
     int         b_bframe_pyramid;   /* Keep some B-frames as references */
+    int         i_direct_8x8_inference_flag; /* Use direct_8x8_inference_flag in SPS: (-1: 0 if possible according to level and partition mode) */
 
     int         b_deblocking_filter;
     int         i_deblocking_filter_alphac0;    /* [-6, 6] -6 light filter, 6 strong */
@@ -243,6 +244,15 @@
         char        *psz_zones;     /* alternate method of specifying zones */
     } rc;
 
+    /* b_allow_invalid_bitstreams allow produce invalid bitstream by violating
+     * certains level contraints.
+     *
+     * this breaks interoperability so it should never be set except if you
+     * know in advance which decoder will decode the produced streams and you
+     * know that this decoder support the constraints which are not respected.
+     * */
+    int b_allow_invalid_bitstreams;
+
     /* Muxing parameters */
     int b_aud;                  /* generate access unit delimiters */
     int b_repeat_headers;       /* put SPS/PPS before each keyframe */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060520/36b7181b/attachment.pgp 

From poirierg at gmail.com  Sun May 21 21:10:59 2006
From: poirierg at gmail.com (Guillaume POIRIER)
Date: Sun, 21 May 2006 21:10:59 +0200
Subject: [x264-devel] Re: If you use x264 in another project, let us know !
In-Reply-To: <4468A3D9.3090304@gmx.de>
References: <4468A3D9.3090304@gmx.de>
Message-ID: <4e03026a0605211210i303befa0jf6debbc5e2662326@mail.gmail.com>

Hi,

On 5/15/06, MuldeR <mulder2 at gmx.de> wrote:
> If you use x264 in another project, let us know !
>
> Done so:
> http://free.pages.at/borschdfresser/public/home/html/projects.html#mencoder264

This looks more like a MEncoder front-end than another project using x264.

Anyway, I'd happily add to MPlayer's "related projects" page the link
to your project, but the link seems broken...

Guillaume
-- 
"Success consists of going from failure to failure without loss of enthusiasm."
  -- Winston Churchil

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From salsaman at xs4all.nl  Mon May 22 03:57:51 2006
From: salsaman at xs4all.nl (salsaman)
Date: Mon, 22 May 2006 03:57:51 +0200
Subject: [x264-devel] Re: If you use x264 in another project, let us know
 !
In-Reply-To: <4e03026a0605211210i303befa0jf6debbc5e2662326@mail.gmail.com>
References: <4468A3D9.3090304@gmx.de> <4e03026a0605211210i303befa0jf6debbc5e2662326@mail.gmail.com>
Message-ID: <44711A9F.1050200@xs4all.nl>


> Hi,
>
> On 5/15/06, MuldeR <mulder2 at gmx.de> wrote:
>
>> If you use x264 in another project, let us know !
>>
Have you added LiVES (http://lives.sourceforge.net) ?

Gabriel

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From utsukushigaoka at gmail.com  Mon May 22 09:32:04 2006
From: utsukushigaoka at gmail.com (Lachat Saher)
Date: Mon, 22 May 2006 16:32:04 +0900
Subject: [x264-devel] DCT coefficients
Message-ID: <e44c51930605220032o77d4f1ag7c59a5dd6e0b028a@mail.gmail.com>

Dear All,
Sorry to disturb everybody! I am a newbie and I have to evaluate the visual
effect of changing DCT coefficients. I've read the code, and tried different
experiments, but I am not able to find exactly where they are :'(
May somebody help me?
Thanks a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060522/90f9b3a6/attachment.htm 

From mdeboer at iua.upf.edu  Mon May 22 17:12:37 2006
From: mdeboer at iua.upf.edu (Maarten de Boer)
Date: Mon, 22 May 2006 17:12:37 +0200
Subject: [x264-devel] making a demo/tutorial movie
Message-ID: <20060522171237.66654c2e.mdeboer@iua.upf.es>

Hello,

I am making a demo video of an application I am writing. I post
my experiences since they might be handy for someone else, but
also to ask for some advice on the encoding settings.

The application I am making the demo video of has a rather standard
GUI: sliders, buttons, text. The demo shows how to use this application,
accompanied with spoken text. I write 10 screenshots/second to disk
(including mouse cursor). This was very easy with the GUI library I
use, fltk, which has a function to read the pixels of the current window
into a buffer, which then can be written to disk, but it could also be
done with xvidcap.

Finally, I convert these images to a movie, with the following steps
(all under Linux):

I use a fifo to avoid the need of a large intermediate yuv file.

$ mkfifo /tmp/foo.y4m
$ png2yuv -j video_%04d.png -f 10 -I p -S 420mpeg2 > /tmp/foo.y4m

In another shell, read from the fifo, and write the to h264:

$ x264 --fps 10 -B 500 -o "foo.264" /tmp/foo.y4m

Would it be possible to do the above in a single step? x264 does not
seem to be able to read from the stdin, but ideally, I'd rather pipe
png2yuv output to x264.

Next, I have some audio (spoken while using the application) which I
convert to aac:

$ faac -b 128 --mpeg-vers 4 foo.wav

Finally, I join audio and video in an mp4 file:

$ MP4Box -fps 10 -new -add foo.264 -add foo.aac foo.mp4 -hint

The resulting video looks ok, and plays fine under quicktime, but I am
sure that I could use some x264 settings more suitable for this kind of
material (screenshots). I was hoping that someone has some experience
with this, and could share it. Would it be advisable to do multipass
encoding?

Kind regards, and thanks for a great tool.

Maarten

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Mon May 22 23:08:51 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Mon, 22 May 2006 14:08:51 -0700 (PDT)
Subject: [x264-devel] Re: DCT coefficients
In-Reply-To: <e44c51930605220032o77d4f1ag7c59a5dd6e0b028a@mail.gmail.com>
References: <e44c51930605220032o77d4f1ag7c59a5dd6e0b028a@mail.gmail.com>
Message-ID: <Pine.A41.4.64.0605221406050.67104@dante68.u.washington.edu>

On Mon, 22 May 2006, Lachat Saher wrote:

> Dear All,
> Sorry to disturb everybody! I am a newbie and I have to evaluate the visual
> effect of changing DCT coefficients. I've read the code, and tried different
> experiments, but I am not able to find exactly where they are :'(
> May somebody help me?
> Thanks a lot.

DCT coefficients are stored in x264_t.dct
If you want to modify them, you might take x264_denoise_dct() as an 
example, it already does something like that.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Tue May 23 01:07:58 2006
From: svn at videolan.org (Subversion daemon)
Date: Tue, 23 May 2006 01:07:58 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r526 (pengvado)
Message-ID: <20060522230758.8D5CF2CEA@ganesh.videolan.org>

r526 | pengvado | 2006-05-23 01:07:58 +0200 (Tue, 23 May 2006) | 3 lines
Changed paths:
   M /trunk/encoder/slicetype_decision.c

fix a memory alignment. (no effect on x86, but might be needed for other simd)


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From utsukushigaoka at gmail.com  Tue May 23 11:27:50 2006
From: utsukushigaoka at gmail.com (Lachat Saher)
Date: Tue, 23 May 2006 18:27:50 +0900
Subject: [x264-devel] Re: DCT coefficients
In-Reply-To: <Pine.A41.4.64.0605221406050.67104@dante68.u.washington.edu>
References: <e44c51930605220032o77d4f1ag7c59a5dd6e0b028a@mail.gmail.com>
	 <Pine.A41.4.64.0605221406050.67104@dante68.u.washington.edu>
Message-ID: <e44c51930605230227q26e6624fgeb72329cbd7bd145@mail.gmail.com>

>DCT coefficients are stored in x264_t.dct
>If you want to modify them, you might take x264_denoise_dct() as an
>example, it already does something like that.

Thank you very much
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060523/b6c1a759/attachment.htm 

From admin at via.ecp.fr  Tue May 23 20:29:43 2006
From: admin at via.ecp.fr (System administration)
Date: Tue, 23 May 2006 20:29:43 +0200
Subject: [x264-devel] [Alex Izvorski <aizvorski@auroras.tv>] [ANNOUNCE] interlaced encoding patch for x264
Message-ID: <20060523182943.GB23950@via.ecp.fr>

----- Forwarded message from Alex Izvorski <aizvorski at auroras.tv> -----

From: Alex Izvorski <aizvorski at auroras.tv>
Date: Mon, 22 May 2006 22:25:53 -0700
To: x264-devel at videolan.org
Subject: [ANNOUNCE] interlaced encoding patch for x264
X-Mailer: Evolution 2.2.3 
X-Spam-Status: No, score=-5.3 required=5.0 tests=FORGED_RCVD_HELO,PORN_10,
	SPF_HELO_PASS,SUPERLONG_LINE,UNIFIED_PATCH autolearn=failed 
	version=3.0.3

The deleted attachment is at:
    <http://www.videolan.org/~admin/20060523-videolan/patch>
 
Hello,

I am pleased to announce the initial release of interlaced support for
x264.  This was written by me with invaluable help from Loren Merritt
for Auroras Entertainment LLC.

Current status:
- fixed interlacing only, no PAFF/MBAFF yet
- all analysis modes and all motion estimation options work
- multiple ref frames work
- CABAC and CAVLC work
- no B-frames
- no trellis
- possibly other options don't work: mixed refs, RDO, B-pyramid

Some more information is in the included README.interlacing file.

The patch is relative to x264 r523 from svn, it may not apply cleanly
to the latest version.  The patch is copyright Auroras Entertainment
LLC, 2006 and released under the same terms as x264 (GPL v2 or later).

We would like to support further efforts to develop interlacing, please
get in touch with me if you would like to be involved.

Enjoy!

-Alex Izvorski



*****************************

Alex Izvorski
Director of Software Engineering
Auroras Entertainment

aizvorski at auroras.tv

*****************************

----- End forwarded message -----

-- 
System administration <admin at via.ecp.fr>
VIA, ?cole Centrale Paris, France
-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From utsukushigaoka at gmail.com  Wed May 24 04:26:17 2006
From: utsukushigaoka at gmail.com (Lachat Saher)
Date: Wed, 24 May 2006 11:26:17 +0900
Subject: [x264-devel] Re: DCT coefficients
In-Reply-To: <Pine.A41.4.64.0605221406050.67104@dante68.u.washington.edu>
References: <e44c51930605220032o77d4f1ag7c59a5dd6e0b028a@mail.gmail.com>
	 <Pine.A41.4.64.0605221406050.67104@dante68.u.washington.edu>
Message-ID: <e44c51930605231926l5f29849an725388285df41403@mail.gmail.com>

> DCT coefficients are stored in x264_t.dct
> If you want to modify them, you might take x264_denoise_dct() as an
> example, it already does something like that.
>
> --Loren Merritt
>


It is Ok to modify B- and P-frames DCT-coefficients, but I can t understand
how to change the DCT-coeff for I-frames.
Is it the same way?

Thank you ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060524/d47801e3/attachment.htm 

From mohongfee at gmail.com  Wed May 24 05:39:57 2006
From: mohongfee at gmail.com (hongfee mo)
Date: Wed, 24 May 2006 11:39:57 +0800
Subject: [x264-devel] Re: [Alex Izvorski <aizvorski@auroras.tv>] [ANNOUNCE] interlaced encoding patch for x264
In-Reply-To: <20060523182943.GB23950@via.ecp.fr>
References: <20060523182943.GB23950@via.ecp.fr>
Message-ID: <654ddf950605232039w32e6ebeawbbe53212d2367c1d@mail.gmail.com>

It seems the address is not work now.....

http://www.videolan.org/~admin/20060523-videolan/patch

pls check ,thanks.....


2006/5/24, System administration <admin at via.ecp.fr>:
>
> ----- Forwarded message from Alex Izvorski <aizvorski at auroras.tv> -----
>
> From: Alex Izvorski <aizvorski at auroras.tv>
> Date: Mon, 22 May 2006 22:25:53 -0700
> To: x264-devel at videolan.org
> Subject: [ANNOUNCE] interlaced encoding patch for x264
> X-Mailer: Evolution 2.2.3
> X-Spam-Status: No, score=-5.3 required=5.0 tests=FORGED_RCVD_HELO,PORN_10,
>        SPF_HELO_PASS,SUPERLONG_LINE,UNIFIED_PATCH autolearn=failed
>        version=3.0.3
>
> The deleted attachment is at:
>    <http://www.videolan.org/~admin/20060523-videolan/patch>
>
> Hello,
>
> I am pleased to announce the initial release of interlaced support for
> x264.  This was written by me with invaluable help from Loren Merritt
> for Auroras Entertainment LLC.
>
> Current status:
> - fixed interlacing only, no PAFF/MBAFF yet
> - all analysis modes and all motion estimation options work
> - multiple ref frames work
> - CABAC and CAVLC work
> - no B-frames
> - no trellis
> - possibly other options don't work: mixed refs, RDO, B-pyramid
>
> Some more information is in the included README.interlacing file.
>
> The patch is relative to x264 r523 from svn, it may not apply cleanly
> to the latest version.  The patch is copyright Auroras Entertainment
> LLC, 2006 and released under the same terms as x264 (GPL v2 or later).
>
> We would like to support further efforts to develop interlacing, please
> get in touch with me if you would like to be involved.
>
> Enjoy!
>
> -Alex Izvorski
>
>
>
> *****************************
>
> Alex Izvorski
> Director of Software Engineering
> Auroras Entertainment
>
> aizvorski at auroras.tv
>
> *****************************
>
> ----- End forwarded message -----
>
> --
> System administration <admin at via.ecp.fr>
> VIA, ?cole Centrale Paris, France
> --
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>


-- 
?????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060524/01917aa9/attachment.htm 

From svn at videolan.org  Wed May 24 05:59:19 2006
From: svn at videolan.org (Subversion daemon)
Date: Wed, 24 May 2006 05:59:19 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r527 (pengvado)
Message-ID: <20060524035919.328FF4331@ganesh.videolan.org>

r527 | pengvado | 2006-05-24 05:59:19 +0200 (Wed, 24 May 2006) | 3 lines
Changed paths:
   M /trunk/encoder/cavlc.c
   M /trunk/encoder/encoder.c
   M /trunk/encoder/ratecontrol.c
   M /trunk/encoder/slicetype_decision.c

convert non-fatal errors to message level "warning".


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lll+vlc at m4x.org  Wed May 24 08:49:30 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Wed, 24 May 2006 08:49:30 +0200
Subject: [x264-devel] [PATCH] malloc result test
Message-ID: <20060524064930.GV23574@pavuc.le-loarer.org>

Hi,

It seems that x264_malloc result is nearly never tested in allocation
functions, which could lead to segfaults in some situations.

Here a small patch which adds the correct tests for x264_frame_new
function with correct unallocation when something goes wrong. If this
patch is accepted, I'll go on to have this kind of test where necessary.

Best regards.

-- 
Lo?c

"heaven is not a place, it's a feeling"
-------------- next part --------------
Index: common/frame.c
===================================================================
--- common/frame.c	(r??vision 527)
+++ common/frame.c	(copie de travail)
@@ -35,6 +35,10 @@
     int i_stride;
     int i_lines;
 
+    int b_failled_malloc = 0;
+
+    if ( NULL == frame ) return NULL;
+
     memset( frame, 0, sizeof(x264_frame_t) );
 
     /* allocate frame data (+64 for extra data for me) */
@@ -57,6 +61,7 @@
         frame->i_lines[i] = i_lines / i_divh;
         frame->buffer[i] = x264_malloc( frame->i_stride[i] *
                                         ( frame->i_lines[i] + 64 / i_divh ) );
+        b_failled_malloc |= ( NULL == frame->buffer[i] );
 
         frame->plane[i] = ((uint8_t*)frame->buffer[i]) +
                           frame->i_stride[i] * 32 / i_divh + 32 / i_divw;
@@ -71,6 +76,7 @@
     {
         frame->buffer[4+i] = x264_malloc( frame->i_stride[0] *
                                         ( frame->i_lines[0] + 64 ) );
+        b_failled_malloc |= ( NULL == frame->buffer[4+i] );
 
         frame->filtered[i+1] = ((uint8_t*)frame->buffer[4+i]) +
                                 frame->i_stride[0] * 32 + 32;
@@ -84,6 +90,7 @@
         {
             frame->buffer[7+i] = x264_malloc( frame->i_stride_lowres *
                                             ( frame->i_lines[0]/2 + 64 ) );
+            b_failled_malloc |= ( NULL == frame->buffer[7+i] );
             frame->lowres[i] = ((uint8_t*)frame->buffer[7+i]) +
                                 frame->i_stride_lowres * 32 + 32;
         }
@@ -92,6 +99,7 @@
     if( h->param.analyse.i_me_method == X264_ME_ESA )
     {
         frame->buffer[11] = x264_malloc( frame->i_stride[0] * (frame->i_lines[0] + 64) * sizeof(uint16_t) );
+        b_failled_malloc |= ( NULL == frame->buffer[11] );
         frame->integral = (uint16_t*)frame->buffer[11] + frame->i_stride[0] * 32 + 32;
     }
 
@@ -105,10 +113,15 @@
     frame->mb_type= x264_malloc( i_mb_count * sizeof( int8_t) );
     frame->mv[0]  = x264_malloc( 2*16 * i_mb_count * sizeof( int16_t ) );
     frame->ref[0] = x264_malloc( 4 * i_mb_count * sizeof( int8_t ) );
+    b_failled_malloc |= ( NULL == frame->mb_type )
+        || ( NULL == frame->mv[0] )
+        || ( NULL == frame->ref[0] );
     if( h->param.i_bframe )
     {
         frame->mv[1]  = x264_malloc( 2*16 * i_mb_count * sizeof( int16_t ) );
         frame->ref[1] = x264_malloc( 4 * i_mb_count * sizeof( int8_t ) );
+        b_failled_malloc |= ( NULL == frame->mv[1] )
+            || ( NULL == frame->ref[1] );
     }
     else
     {
@@ -118,20 +131,28 @@
 
     frame->i_row_bits = x264_malloc( i_lines/16 * sizeof( int ) );
     frame->i_row_qp   = x264_malloc( i_lines/16 * sizeof( int ) );
+    b_failled_malloc |= ( NULL == frame->i_row_bits )
+        || ( NULL == frame->i_row_qp );
     for( i = 0; i < h->param.i_bframe + 2; i++ )
         for( j = 0; j < h->param.i_bframe + 2; j++ )
+        {
             frame->i_row_satds[i][j] = x264_malloc( i_lines/16 * sizeof( int ) );
+            b_failled_malloc |= ( NULL == frame->i_row_satds[i][j] );
+        }
 
+    if (b_failled_malloc)
+    {
+        x264_frame_delete( frame );
+        return NULL;
+    }
     return frame;
 }
 
 void x264_frame_delete( x264_frame_t *frame )
 {
     int i, j;
-    for( i = 0; i < frame->i_plane; i++ )
+    for( i = 0; i < 12; i++ )
         x264_free( frame->buffer[i] );
-    for( i = 4; i < 12; i++ ) /* filtered planes */
-        x264_free( frame->buffer[i] );
     for( i = 0; i < X264_BFRAME_MAX+2; i++ )
         for( j = 0; j < X264_BFRAME_MAX+2; j++ )
             x264_free( frame->i_row_satds[i][j] );
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060524/37ad64a7/attachment.pgp 

From dionoea at videolan.org  Wed May 24 20:35:31 2006
From: dionoea at videolan.org (Antoine Cellerier)
Date: Wed, 24 May 2006 20:35:31 +0200
Subject: [x264-devel] Re: [Alex Izvorski <aizvorski@auroras.tv>] [ANNOUNCE] interlaced encoding patch for x264
In-Reply-To: <654ddf950605232039w32e6ebeawbbe53212d2367c1d@mail.gmail.com>
References: <20060523182943.GB23950@via.ecp.fr> <654ddf950605232039w32e6ebeawbbe53212d2367c1d@mail.gmail.com>
Message-ID: <20060524183531.GA19283@via.ecp.fr>

On Wed, May 24, 2006, hongfee mo wrote:
>    [1]http://www.videolan.org/~admin/20060523-videolan/patch

try people.via.ecp.fr instead of www.videolan.org

-- 
Antoine Cellerier
dionoea

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lll+vlc at m4x.org  Thu May 25 11:36:37 2006
From: lll+vlc at m4x.org (=?iso-8859-1?Q?Lo=EFc?= Le Loarer)
Date: Thu, 25 May 2006 11:36:37 +0200
Subject: [x264-devel] Re: [Alex Izvorski <aizvorski@auroras.tv>] [ANNOUNCE] interlaced encoding patch for x264
In-Reply-To: <20060524183531.GA19283@via.ecp.fr>
References: <20060523182943.GB23950@via.ecp.fr> <654ddf950605232039w32e6ebeawbbe53212d2367c1d@mail.gmail.com> <20060524183531.GA19283@via.ecp.fr>
Message-ID: <20060525093637.GW23574@pavuc.le-loarer.org>

Le Wednesday 24 May 2006 ? 20:35:31 +0200, Antoine Cellerier a ?crit:
> On Wed, May 24, 2006, hongfee mo wrote:
> >    [1]http://www.videolan.org/~admin/20060523-videolan/patch
> 
> try people.via.ecp.fr instead of www.videolan.org

So the correct URL is
http://people.via.ecp.fr/~admin/20060523-videolan/patch

Seems that the ML manager should be fixed.

-- 
Lo?c

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From glargo at email.com  Thu May 25 22:11:35 2006
From: glargo at email.com (GILBERTO SANCHEZ)
Date: Thu, 25 May 2006 15:11:35 -0500
Subject: [x264-devel] Relation of bandwidth and bitrate
Message-ID: <20060525201135.A315E164278@ws1-4.us4.outblaze.com>

Hello lists,

First thanks by all answer that i have been recived.

Well, my question is some technical, i need to know the relation ship between Bandwidth and audio and video bitrate used in the compression, and how do i calculate the bitrate (and others parameters implicated) to transmit over a bandwidth especific in realtime.

If you knok some links where i can found this,its has been very helpfully to me.

Thanks

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From bugfood-ml at fatooh.org  Fri May 26 00:42:16 2006
From: bugfood-ml at fatooh.org (Corey Hickey)
Date: Thu, 25 May 2006 15:42:16 -0700
Subject: [x264-devel] Re: [MEncoder-users] Relation of bandwidth and bitrate
In-Reply-To: <20060525201135.A315E164278@ws1-4.us4.outblaze.com>
References: <20060525201135.A315E164278@ws1-4.us4.outblaze.com>
Message-ID: <447632C8.9030505@fatooh.org>

GILBERTO SANCHEZ wrote:
> Hello lists,
> 
> First thanks by all answer that i have been recived.
> 
> Well, my question is some technical, i need to know the relation ship between Bandwidth and audio and video bitrate used in the compression, and how do i calculate the bitrate (and others parameters implicated) to transmit over a bandwidth especific in realtime.
> 
> If you knok some links where i can found this,its has been very helpfully to me.

It's not polite to ask a question on more than one mailing list at the 
same time unless you really really have a good reason to do so. This is 
called "cross-posting" and will likely get you flamed instead of having 
anyone answer your question.

If you ask on one list and nobody answers after a couple days, then try 
another. Don't try them all at once.

I just responded to your question on mencoder-users before I saw you'd 
cross-posted.

-Corey

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From takaaki.yamada at gmail.com  Fri May 26 04:50:12 2006
From: takaaki.yamada at gmail.com (Takaaki Yamada)
Date: Fri, 26 May 2006 11:50:12 +0900
Subject: [x264-devel] Re: DCT coefficients
Message-ID: <80ab005c0605251950l7c963664taca5b2840a58bc0e@mail.gmail.com>

Hello everybody,

I have the same problem, I do not know how to do. Can anyone help me?
Thank you


>It is Ok to modify B- and P-frames DCT-coefficients, but I can t understand
>how to change the DCT-coeff for I-frames.
>Is it the same way?

>Thank you  ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060526/07101ebc/attachment.htm 

From x264dev at orbmu2k.de  Fri May 26 09:00:17 2006
From: x264dev at orbmu2k.de (x264dev at orbmu2k.de)
Date: Fri, 26 May 2006 09:00:17 +0200
Subject: [x264-devel] X264 Feature Request
Message-ID: <20060526065931.98B83370197@faust.powie-net.de>

Hello,
 
i had tested your h264 encoder first time and it is very slowly i think.
230000 frames (1080i) 2 pass encoding will take 14 hours per pass on a Core
Duo 2GHZ. May be thats normal, but can you add a network encoding option to
share the work with other computers?
 
Thanks for reply
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060526/71a31bdd/attachment.htm 

From manao at melix.net  Fri May 26 09:06:37 2006
From: manao at melix.net (Mathieu Monnier)
Date: Fri, 26 May 2006 09:06:37 +0200
Subject: [x264-devel] Re: X264 Feature Request
In-Reply-To: <20060526065931.98B83370197@faust.powie-net.de>
References: <20060526065931.98B83370197@faust.powie-net.de>
Message-ID: <4476A8FD.9020007@melix.net>

Hi,

>  it is very slowly i think

No it isn't. It depends how you configured it.

>  can you add a network encoding option to share the work with other
>  computers?

You may want to have a look at the Elder project :

http://forum.doom9.org/showthread.php?t=102119&highlight=elder

Regards,

Mathieu

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From sddddd at tiscali.co.uk  Fri May 26 09:16:04 2006
From: sddddd at tiscali.co.uk (Rarity)
Date: Fri, 26 May 2006 08:16:04 +0100
Subject: [x264-devel] Illegal Instruction Crash (OS X/Intel Mac)
Message-ID: <E25E4CCA-7D83-488C-9AE9-6AEFC1AA0D66@tiscali.co.uk>

x264 crashes in the following manner:

<begin quote>
$ ffmpeg -i /tmp/test.avi -f rawvideo -s 320x240 - | ./x264 -o ./ 
output.mov - 320x240
FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
   configuration:  --prefix=/usr/local --disable-mmx --enable-faac -- 
enable-mp3lame --enable-x264 --enable-gpl
   libavutil version: 49.0.0
   libavcodec version: 51.9.0
   libavformat version: 50.4.0
   built on May 26 2006 07:32:49, gcc: 4.0.1 (Apple Computer, Inc.  
build 5250)
Input #0, avi, from '/tmp/test.avi':
   Duration: 00:00:02.8, start: 0.000000, bitrate: 1228 kb/s
   Stream #0.0, 25.00 fps(r): Video: h264, yuv420p, 700x394
   Stream #0.1: Audio: mp3, 44100 Hz, stereo, 128 kb/s
Output #0, rawvideo, to 'pipe:':
   Stream #0.0, 25.00 fps(c): Video: rawvideo, yuv420p, 320x240,  
q=2-31, 200 kb/s
Stream mapping:
   Stream #0.0 -> #0.0
Press [q] to stop encoding
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Illegal instruction
<end quote>

gdb indicates some sort of stack corruption. Additionally, the  
following change just after
line 54 of 'common/cpu.c' stops prevents x264 from crashing:

<begin quote>
   x264_cpu_cpuid( 1, &eax, &ebx, &ecx, &edx );

     /* NEW*/
     return 0;

     if( (edx&0x00800000) == 0 )
     {
         /* No MMX */
         return 0;
     }
<end quote>

The latest nightly build of VLC also crashes when attempting to  
transcode to H.264.

Thanks.





-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From info at orbmu2k.de  Fri May 26 08:56:30 2006
From: info at orbmu2k.de (Orbmu2k)
Date: Fri, 26 May 2006 08:56:30 +0200
Subject: [x264-devel] X264 Feature Request
Message-ID: <20060526065544.BC9B7370197@faust.powie-net.de>

Hello,
 
i had tested your h264 encoder first time and it is very slowly i think.
230000 frames (1080i) 2 pass encoding will take 14 hours per pass on a Core
Duo 2GHZ. May be thats normal, but can you add a network encoding option to
share the work with other computers?
 
Thanks for reply
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060526/9e1a692f/attachment.htm 

From svn at videolan.org  Sun May 28 23:14:25 2006
From: svn at videolan.org (Subversion daemon)
Date: Sun, 28 May 2006 23:14:25 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r528 (pengvado)
Message-ID: <20060528211425.60B4910D9F@ganesh.videolan.org>

r528 | pengvado | 2006-05-28 23:14:24 +0200 (Sun, 28 May 2006) | 3 lines
Changed paths:
   M /trunk/Makefile

make -> $(MAKE)


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Tue May 30 09:07:55 2006
From: svn at videolan.org (Subversion daemon)
Date: Tue, 30 May 2006 09:07:55 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r529 (pengvado)
Message-ID: <20060530070755.7708811907@ganesh.videolan.org>

r529 | pengvado | 2006-05-30 09:07:55 +0200 (Tue, 30 May 2006) | 3 lines
Changed paths:
   M /trunk/common/common.h
   M /trunk/common/frame.c
   M /trunk/common/macroblock.c
   M /trunk/common/macroblock.h
   M /trunk/encoder/encoder.c

check some mallocs' return value


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From lorenm at u.washington.edu  Tue May 30 09:19:22 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Tue, 30 May 2006 00:19:22 -0700 (PDT)
Subject: [x264-devel] Re: [PATCH] malloc result test
In-Reply-To: <20060524064930.GV23574@pavuc.le-loarer.org>
References: <20060524064930.GV23574@pavuc.le-loarer.org>
Message-ID: <Pine.A41.4.64.0605300018560.76944@dante65.u.washington.edu>

On Wed, 24 May 2006, Lo?c Le Loarer wrote:

> It seems that x264_malloc result is nearly never tested in allocation
> functions, which could lead to segfaults in some situations.
>
> Here a small patch which adds the correct tests for x264_frame_new
> function with correct unallocation when something goes wrong. If this
> patch is accepted, I'll go on to have this kind of test where necessary.
>
> Best regards.

OK, but it doesn't help unless you check x264_frame_new's return value too 
:)

--Loren Merritt

From nabeeliqbalus at yahoo.com  Tue May 30 09:29:32 2006
From: nabeeliqbalus at yahoo.com (Nabeel Iqbal)
Date: Tue, 30 May 2006 00:29:32 -0700 (PDT)
Subject: [x264-devel] H264 profiles and levels inquiry
Message-ID: <20060530072932.81899.qmail@web31803.mail.mud.yahoo.com>

Hi all,
   my question is basic one . is there any restiction of levels with respect to profiles. in otherer words Baseline profile includes and support all levels (from 1 to 5.1) or restricted to some maximum level like baseline support only level 3 or les.
   
   
   thanking in anticipation for your kind and helping responce.
   
   
   
   
   
   


Regards
Nabeel Iqbal
Department of computer engineering
CASE(www.case.edu.pk)
G-5/1, Islamabad,
Pakistan.
44000

+92-333-5145456
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20060530/4b68b945/attachment.htm 

From lorenm at u.washington.edu  Tue May 30 09:53:55 2006
From: lorenm at u.washington.edu (Loren Merritt)
Date: Tue, 30 May 2006 00:53:55 -0700 (PDT)
Subject: [x264-devel] Re: H264 profiles and levels inquiry
In-Reply-To: <20060530072932.81899.qmail@web31803.mail.mud.yahoo.com>
References: <20060530072932.81899.qmail@web31803.mail.mud.yahoo.com>
Message-ID: <Pine.A41.4.64.0605300051300.104806@dante65.u.washington.edu>

On Tue, 30 May 2006, Nabeel Iqbal wrote:

> is there any restiction of levels with respect to profiles. in other 
> words Baseline profile includes and support all levels (from 1 to 5.1) 
> or restricted to some maximum level like baseline support only level 3 
> or less.

Levels and profiles are completely independent. Of course, any device that 
only supports baseline is probably also too slow to do the high levels. 
But that's for each device to determine, not part of the standard.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From svn at videolan.org  Tue May 30 12:05:57 2006
From: svn at videolan.org (Subversion daemon)
Date: Tue, 30 May 2006 12:05:57 +0200 (CEST)
Subject: [x264-devel] x264: svn commit r530 (titer)
Message-ID: <20060530100557.8BC021193B@ganesh.videolan.org>

r530 | titer | 2006-05-30 12:05:56 +0200 (Tue, 30 May 2006) | 2 lines
Changed paths:
   M /trunk/encoder/encoder.c

Fixed typo that caused x264_encoder_open to always fail

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From son-minh.tran at int-evry.fr  Tue May 30 15:59:32 2006
From: son-minh.tran at int-evry.fr (Son Minh Tran)
Date: Tue, 30 May 2006 15:59:32 +0200
Subject: [x264-devel] Again Hadamard transform
In-Reply-To: <Pine.A41.4.64.0604111356140.125390@dante65.u.washington.edu>
References: <20060410175602.AB0DD8698@ganesh.videolan.org> <443BD0F1.7070108@int-evry.fr> <Pine.A41.4.64.0604111356140.125390@dante65.u.washington.edu>
Message-ID: <447C4FC4.9080408@int-evry.fr>

Dear Loren Merritt,
I check the implementation of SATD in x264. It seems to me that the 
project uses SATD only to calculate the cost for block prediction. It 
does not use this transform in the hierarchical manner for the flat 
block of size 16x16, does it?
Please correct me if I am wrong
Regards
Son Tran

Loren Merritt a ?crit :
> On Tue, 11 Apr 2006, Son Minh Tran wrote:
>
>> Dear All,
>> Would you please let me know if the hamadard transform is 
>> implemented  in x264, or only the DCT?
>> Thank you
>> Regards
>
> Yes, it is implemented. x264 usually calls it "SATD" for "sum of 
> absolute transformed differences".
>
> But "or only the DCT" is misleading. Hadamard is not part of the H.264 
> standard, and is not an alternative to DCT. It is an encoder-side 
> technique to improve speed and/or quality, and is also used in some 
> mpeg-1/2/4 encoders.
> (Well, hadamard is also part of the h264 intra 16x16 dc transform, but 
> asking whether that's implemented is meaningless; it's required.)
>
> --Loren Merritt
>

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From rapennas at gmail.com  Tue May 30 16:28:55 2006
From: rapennas at gmail.com (Rafael Penna)
Date: Tue, 30 May 2006 11:28:55 -0300
Subject: [x264-devel] Re: making a demo/tutorial movie
In-Reply-To: <20060522171237.66654c2e.mdeboer@iua.upf.es>
References: <20060522171237.66654c2e.mdeboer@iua.upf.es>
Message-ID: <4c91dec70605300728o537abb1va08db33bc793eed0@mail.gmail.com>

Hi,

sorry for my bad english. Thanks for help me in the codification of
x264 video. I would like to know how can i decode a video using x264,
from the "archive.264" i would like get the frames in png or jpeg.

Thanks!
Rafael

On 5/22/06, Maarten de Boer <mdeboer at iua.upf.edu> wrote:
> Hello,
>
> I am making a demo video of an application I am writing. I post
> my experiences since they might be handy for someone else, but
> also to ask for some advice on the encoding settings.
>
> The application I am making the demo video of has a rather standard
> GUI: sliders, buttons, text. The demo shows how to use this application,
> accompanied with spoken text. I write 10 screenshots/second to disk
> (including mouse cursor). This was very easy with the GUI library I
> use, fltk, which has a function to read the pixels of the current window
> into a buffer, which then can be written to disk, but it could also be
> done with xvidcap.
>
> Finally, I convert these images to a movie, with the following steps
> (all under Linux):
>
> I use a fifo to avoid the need of a large intermediate yuv file.
>
> $ mkfifo /tmp/foo.y4m
> $ png2yuv -j video_%04d.png -f 10 -I p -S 420mpeg2 > /tmp/foo.y4m
>
> In another shell, read from the fifo, and write the to h264:
>
> $ x264 --fps 10 -B 500 -o "foo.264" /tmp/foo.y4m
>
> Would it be possible to do the above in a single step? x264 does not
> seem to be able to read from the stdin, but ideally, I'd rather pipe
> png2yuv output to x264.
>
> Next, I have some audio (spoken while using the application) which I
> convert to aac:
>
> $ faac -b 128 --mpeg-vers 4 foo.wav
>
> Finally, I join audio and video in an mp4 file:
>
> $ MP4Box -fps 10 -new -add foo.264 -add foo.aac foo.mp4 -hint
>
> The resulting video looks ok, and plays fine under quicktime, but I am
> sure that I could use some x264 settings more suitable for this kind of
> material (screenshots). I was hoping that someone has some experience
> with this, and could share it. Would it be advisable to do multipass
> encoding?
>
> Kind regards, and thanks for a great tool.
>
> Maarten
>
> --
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html


From mdeboer at iua.upf.edu  Wed May 31 17:42:12 2006
From: mdeboer at iua.upf.edu (Maarten de Boer)
Date: Wed, 31 May 2006 17:42:12 +0200
Subject: [x264-devel] Re: making a demo/tutorial movie
In-Reply-To: <4c91dec70605300728o537abb1va08db33bc793eed0@mail.gmail.com>
References: <20060522171237.66654c2e.mdeboer@iua.upf.es>
	<4c91dec70605300728o537abb1va08db33bc793eed0@mail.gmail.com>
Message-ID: <20060531174212.5ce62cdb.mdeboer@iua.upf.es>


You can use mplayer to do this:

mplayer -vo png archive.264
mplayer -vo jpeg archive.264



On Tue, 30 May 2006 11:28:55 -0300
"Rafael Penna" <rapennas at gmail.com> wrote:

> Hi,
> 
> sorry for my bad english. Thanks for help me in the codification of
> x264 video. I would like to know how can i decode a video using x264,
> from the "archive.264" i would like get the frames in png or jpeg.
> 
> Thanks!
> Rafael
> 
> On 5/22/06, Maarten de Boer <mdeboer at iua.upf.edu> wrote:
> > Hello,
> >
> > I am making a demo video of an application I am writing. I post
> > my experiences since they might be handy for someone else, but
> > also to ask for some advice on the encoding settings.
> >
> > The application I am making the demo video of has a rather standard
> > GUI: sliders, buttons, text. The demo shows how to use this application,
> > accompanied with spoken text. I write 10 screenshots/second to disk
> > (including mouse cursor). This was very easy with the GUI library I
> > use, fltk, which has a function to read the pixels of the current window
> > into a buffer, which then can be written to disk, but it could also be
> > done with xvidcap.
> >
> > Finally, I convert these images to a movie, with the following steps
> > (all under Linux):
> >
> > I use a fifo to avoid the need of a large intermediate yuv file.
> >
> > $ mkfifo /tmp/foo.y4m
> > $ png2yuv -j video_%04d.png -f 10 -I p -S 420mpeg2 > /tmp/foo.y4m
> >
> > In another shell, read from the fifo, and write the to h264:
> >
> > $ x264 --fps 10 -B 500 -o "foo.264" /tmp/foo.y4m
> >
> > Would it be possible to do the above in a single step? x264 does not
> > seem to be able to read from the stdin, but ideally, I'd rather pipe
> > png2yuv output to x264.
> >
> > Next, I have some audio (spoken while using the application) which I
> > convert to aac:
> >
> > $ faac -b 128 --mpeg-vers 4 foo.wav
> >
> > Finally, I join audio and video in an mp4 file:
> >
> > $ MP4Box -fps 10 -new -add foo.264 -add foo.aac foo.mp4 -hint
> >
> > The resulting video looks ok, and plays fine under quicktime, but I am
> > sure that I could use some x264 settings more suitable for this kind of
> > material (screenshots). I was hoping that someone has some experience
> > with this, and could share it. Would it be advisable to do multipass
> > encoding?
> >
> > Kind regards, and thanks for a great tool.
> >
> > Maarten
> >
> > --
> > This is the x264-devel mailing-list
> > To unsubscribe, go to: http://developers.videolan.org/lists.html
> >
> >
> 
> -- 
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
> 
> 
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html