View Full Version : x264 development
Sharktooth
10th October 2005, 14:03
AQ is a Haali's patch and it wasnt committed yet.
Manao
10th October 2005, 14:08
afaik, it doesn't use adaptive quantization.
giandrea
11th October 2005, 01:28
hello. sorry for this break. but, is there any way of running x264 on "tiger"?
Sure, with MPlayer/MEncoder. I use it this way. First compile and install the library (get it from SVN), then compile and install MPlayer (get it from CVS), and you have an up-to-date tool to encode H.264, in AVI (unfortunately) via CLI.
Sharktooth
13th October 2005, 03:56
Im not an OSX expert but there should be encoding GUIs supporting x264.
Handbrake: http://handbrake.m0k.org/index.php
Handbrake port for tiger: http://handbrake.darwinports.com/
akupenguin
13th October 2005, 04:44
Does Handbrake count? It doesn't have any codec options at all other than bitrate/qp/pass ...
Sharktooth
13th October 2005, 14:34
well... i never used handbrake so i dont know about its (in)ability to (not) take advantage of the codec options and settings.
however there are also
mConverter: http://mconverter.sourceforge.net/ (dont know if it works on tiger though)
Dvision: http://www.apple.com/downloads/macosx/video/dvision.html
and more...
el divx
16th October 2005, 15:20
Does gprof has to be enabled all the time or only when building with --enable-debug?
Manao
16th October 2005, 16:20
gprof is usefull only to developpers. Using it for a real encode will only slow things down
JnZ
18th October 2005, 20:07
Hi guys,
today I've encoded Band Of Brothers HD to x264 and found strange error.
As you see on frame in attachment. The green rectangles.
Settings:
Input: AVS file:
LoadPlugin("decomb.dll")
OpenDMLSource("BoB1.avi",audio=false)
Trim(712,126914)
Telecide(order=1,guide=1).Decimate()
Output: AVI encoded in VDM 1.5.10.2, 1280x720 res.
x264 settings: x264 r327
2-Pass encoding at 4061kbps
- rate controll default
- 8x8 transform, 2 ref. frames, 3 B frames,Use as reference
- Partition decision: 6 RDO, Hexagonal search, deblock filter off
- every other settings at default
This errors appears only in encoded avi, only in black areas. In AVS opened in VDM not.
EDIT:
Today I found, that error isn't in x264 codec, because when I encoded same AVS script by XVID codec, same green blocks in same frames appears.
jellysandwich
19th October 2005, 22:12
Today I found, that error isn't in x264 codec, because when I encoded same AVS script by XVID codec, same green blocks in same frames appears.
Did you check to see if it's in the source?
js
el divx
22nd October 2005, 08:08
Sharktooth, here's the output when applying your Constant Rate Factor patch:
$ patch -p0 < x264_crf.0.diff
patching file `encoder/encoder.c'
Hunk #2 succeeded at 417 (offset 1 line).
patching file `encoder/ratecontrol.c'
patching file `x264.c'
Hunk #2 FAILED at 471.
Hunk #3 succeeded at 503 (offset 12 lines).
Hunk #4 succeeded at 577 (offset 3 lines).
1 out of 4 hunks FAILED -- saving rejects to x264.c.rej
patching file `common/common.c'
patching file `x264.h'
Hunk #2 succeeded at 207 (offset 3 lines).
Of course, when trying to build it gives out an error.
PS: I had already applied Adaptive quantization V1, ME and RD skip on sub16x16 blocks if 16x16 was found to be a SKIP (core) and RD patch V2 before applying this one.
Sharktooth
22nd October 2005, 13:58
i know. i fixed it manually. but if you dont apply th AQ patch it works as it is.
el divx
22nd October 2005, 14:38
i know. i fixed it manually. but if you dont apply th AQ patch it works as it is.
Can you give out the solution, pleeeaaase?
Edit: Cancel that. I found it:
#define OPT_ADAPTIVE_QP 315
#define OPT_AQ_STRENGTH 316
#define OPT_AQ_SENSITIVITY 317
#define OPT_CRF 318
sr78
24th October 2005, 10:01
Compile x264 on windows
Did anyone compile the x264 on visual studio lately?
I get the following linking errors:
Linking...
xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe'
x264.obj : error LNK2001: unresolved external symbol _strncasecmp
libx264.lib(encoder.obj) : error LNK2001: unresolved external symbol _x264_quant_init
bin/x264.exe : fatal error LNK1120: 2 unresolved externals
Error executing xilink6.exe.
x264.exe - 3 error(s), 0 warning(s)
I know that usually it means I need to add files to project or libraries to link to
but I did not find the proper solution.
Manao
24th October 2005, 10:15
The function is defined in :common/quant.c
common/quant.h
squid_80
24th October 2005, 10:23
From memory, to get it work with visual studio do the following:
1. Add set.c and quant.c (found in the common directory) to the libx264 project, ideally under the core folder.
2. Add a line near the bottom of x264.h like so:#ifdef __X264__
# ifdef _MSC_VER
# define inline __inline
# define DECLARE_ALIGNED( type, var, n ) __declspec(align(n)) type var
// Add this next line:
# define strncasecmp(s1, s2, n) strnicmp(s1, s2, n)
# else
# define DECLARE_ALIGNED( type, var, n ) type var __attribute__((aligned(n)))
# endif
#endif
See how you go with those tips, there might be more that I can't remember.
sr78
24th October 2005, 13:01
Thanks , It compiles.
I had to remove the flag HAVE_MMXEXT though.
Is there a problem with the mmx implementation?
With the flag I get these errors:
Linking...
xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe'
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_8x8_core16_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_core16_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_dc_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_2x2_dc_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_8x8_core32_mmx
libx264.lib(quant.obj) : error LNK2001: unresolved external symbol _x264_quant_4x4_core32_mmx
bin/x264.exe : fatal error LNK1120: 6 unresolved externals
Error executing xilink6.exe.
I looked around in the code , and indeed I see no implementation of any of these functions.am I missing something here?
Manao
24th October 2005, 13:05
Tou need to add the file "common/i386/quant-a.asm" to the vcproj, and to configure it to be compiled with nasm ( as the other asm files are, copy'n'paste their configuration to quant-a.asm's one )
Manao
24th October 2005, 13:07
Tou need to add the file "common/i386/quant-a.asm" to the .dsp, and to configure it to be compiled with nasm ( as the other asm files are, copy'n'paste their configuration to quant-a.asm's one )
squid_80
24th October 2005, 13:22
I knew there was something I'd forgotten. You can also try defining HAVE_SSE2 if you want the SSE2 pixel routines to be used.
sr78
26th October 2005, 07:07
thank a lot :)
giandrea
27th October 2005, 23:10
Now that crosscompile is in, can someone make builds of X264 for Mac/PPC? :) :)
QuadraQ
29th October 2005, 21:51
I've been having some trouble getting MeGUI to work for me, and in the process discovered that the avs script I was using was missing the fps information. Now technically this shouldn't happen of course, but what was interesting was what x264.exe did when passed this avs script. It showed the resolution followed by 0.0 fps and then went into some kind of infiinite loop (with lot's of hard drive activity as well) taking up virtually all of the processor time.
So it's a tiny thing (especially at this point in the development) but I would think that an error of some kind would be preferable behaviour.
max-holz
30th October 2005, 15:57
I have a silly question, beg pardon. In the x264's build thread by Sharktooth I found patches as files with the extension .diff. After I have downloaded the source code from videolan.org, in which way must I use these files for merging patches with the original source?
Sharktooth
30th October 2005, 16:06
supposing you have put the .diff files in the same x264 sources directory:
cd x264_sources_directory
patch < filename.diff -p0
(or patch -i filename.diff -p0)
el divx
30th October 2005, 16:07
Or check leowai's post earlier in this thread:here (http://forum.doom9.org/showthread.php?p=721978#post721978)
EDIT:BTW, Sharktooth, Your "Build Changes" log file found on your x264 builds sticky stops at revision 336.
max-holz
30th October 2005, 16:12
Thanks, I have never compiled x264 source before and I don't know the exactly use of MinGW.
sr78
1st November 2005, 06:43
Does the x264 support the FMO feature?
foxyshadis
1st November 2005, 06:59
This just came up a few days ago.
http://forum.doom9.org/showthread.php?t=101908
Answer: No.
Sharktooth
1st November 2005, 14:43
EDIT:BTW, Sharktooth, Your "Build Changes" log file found on your x264 builds sticky stops at revision 336.
What's wrong with that? It means there are only SVN changes.
el divx
4th November 2005, 18:34
I'm not complaining, I just thought it had been corrupted or something.
Anyway, the newest version of your aq patch fails to apply on "encoder/encoder.c", line 409.
Code in patch:
}
h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -12, 12);
h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
+ if( h->param.analyse.b_aq && h->param.analyse.f_aq_strength <= 0 )
+ h->param.analyse.b_aq = 0;
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;
Code in encoder.c, x264 rev.362:
}
h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -12, 12);
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;
{
const x264_level_t *l = x264_levels;
while( l->level_idc != 0 && l->level_idc != h->param.i_level_idc )
l++;
if( l->level_idc == 0 )
{
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;
else
h->param.analyse.i_mv_range = x264_clip3(h->param.analyse.i_mv_range, 32, 2048);
}
Sharktooth
4th November 2005, 18:38
Some patches are somwhat b0rked. i mean they have to be manually adjusted (usually only few lines shifted) to be applied coz i made them "compatible" with the other patches.
however try the new one (v5)
el divx
4th November 2005, 19:58
Yup, it works geat.
The RDO for b-frames patch though doesn't:
$ patch -p0 < x264_brdo.3.diff
patching file `encoder/analyse.c'
Hunk #1 succeeded at 77 (offset 1 line).
Hunk #3 succeeded at 269 (offset 1 line).
Hunk #5 succeeded at 492 (offset 1 line).
Hunk #7 succeeded at 638 (offset 1 line).
Hunk #9 succeeded at 1292 (offset 1 line).
Hunk #11 succeeded at 1554 (offset 1 line).
Hunk #13 succeeded at 1631 (offset 1 line).
Hunk #15 succeeded at 2111 (offset 155 lines).
Hunk #17 succeeded at 2153 (offset 155 lines).
Hunk #19 succeeded at 2189 (offset 155 lines).
Hunk #21 succeeded at 2208 (offset 155 lines).
Hunk #23 succeeded at 2410 (offset 155 lines).
patching file `x264.c'
Hunk #1 FAILED at 253.
Hunk #2 FAILED at 477.
Hunk #3 succeeded at 521 (offset 10 lines).
Hunk #4 succeeded at 735 (offset 2 lines).
2 out of 4 hunks FAILED -- saving rejects to x264.c.rej
patching file `x264.h'
It must be something similar to this (http://forum.doom9.org/showthread.php?p=727178#post727178).
Sharktooth
4th November 2005, 20:29
yeah... coz it adds options to the CLI interface... see the rejected hunks and apply them manually (the file is x264.c)
they should be:
+#define OPT_B_RDO 316
(316 is already used by another option: AQ, replace it with another number - 318 - and add the line manually)
and
+ { "b-rdo", no_argument, NULL, OPT_B_RDO },
(add it as it is under "subme")
P.S.: remove the "+" sign....
el divx
5th November 2005, 07:40
Did it and worked.
BTW, shouldn't some of the features start making it to the VFW interface? Maybe it's just me, but I think they are starting to pile up(which is good for x264 feature-wise).
Sagittaire
5th November 2005, 10:45
For the first time x264 is little better than NDAVC for OPSNR test (RDO + B-RDO + trellis powerfull) and I use NDAVC HP in full quality mode ... very good job
however NDAVC is always better for SSIM (and IMO for my eyes too) ... perhabs the time for HVS optimisations
IgorC
5th November 2005, 12:06
In fact if OPSNR is higher then x264 is better. Itīs simple. Actually higher OPSNR , higher quality ;)
Sagittaire
5th November 2005, 13:03
In fact if OPSNR is higher then x264 is better. Itīs simple. Actually higher OPSNR , higher quality ;)
in fact +/- 0.05 db for x264 vs NDAVC -> no possible conclusion with OPSNR.
but NDAVC is always the best for SSIM. Psy mode for NDAVC seem very powerfull ... :)
however x264 HP is very better than NDAVC MP or VP7 for metric (OPSNR and SSIM) and at this time x264 HP is the best codec available for metric
squid_80
6th November 2005, 02:10
r355 seems to have broken encoder/cabac.c for Visual Studio:
Compiling...
cl : Command line warning D9002 : ignoring unknown option '/G6'
cabac.c
\x264\encoder\cabac.c(198) : error C2059: syntax error : '}'
---------------------- Done ----------------------
Build: 0 succeeded, 1 failed, 0 skippedIt's talking about this: static const int i_mb_bits[9*3][7] =
{
{ 1,1,0,0,0,1 }, { 1,1,0,0,1,0, }, { 1,0,0 }, /* L0 L0 */
{ 1,1,0,1,0,1 }, { 1,1,0,1,1,0 }, {}, /* L0 L1 */
{ 1,1,1,0,0,0,0 }, { 1,1,1,0,0,0,1 }, {}, /* L0 BI */
{ 1,1,0,1,1,1 }, { 1,1,1,1,1,0 }, {}, /* L1 L0 */
{ 1,1,0,0,1,1 }, { 1,1,0,1,0,0 }, { 1,0,1 }, /* L1 L1 */
{ 1,1,1,0,0,1,0 }, { 1,1,1,0,0,1,1 }, {}, /* L1 BI */
{ 1,1,1,0,1,0,0 }, { 1,1,1,0,1,0,1 }, {}, /* BI L0 */
{ 1,1,1,0,1,1,0 }, { 1,1,1,0,1,1,1 }, {}, /* BI L1 */
{ 1,1,1,1,0,0,0 }, { 1,1,1,1,0,0,1 }, { 1,1,0,0,0,0 }, /* BI BI */
};The compiler doesn't seem to like the empty braces. Any ideas?
Richard Berg
6th November 2005, 02:57
@Sharktooth: I can't get the AVI input in your builds to work. Tried several files with different codecs, always get this error:
avis [error]: unsupported input format (hfyu)
could not open input file 'C:\Vid\Storage\keep\colorbars-huff.avi'
(with different FOURCC & filenames, of course)
Avisynth input works fine.
Richard Berg
6th November 2005, 04:04
I looked at the source code. Apparently only FOURCC == YV12 is supported. That may actually be ok...what I eventually want is to write out the raw frames during the 1st pass so that we don't have to execute the AVS script again on the 2nd/3rd passes. I've made some changes to MeGUI to assist with this, but it looks like it might be easier if I modify x264 too.
akupenguin
6th November 2005, 04:34
The compiler doesn't seem to like the empty braces. Any ideas?
Put something in them. It doesn't matter what.
squid_80
6th November 2005, 04:36
Zeroes it is then. :cool:
sr78
6th November 2005, 11:28
does x264 uses only one slice for each encoded frame?
I looked at the code and I couldn't find the place in which a frame
is devided into more then one slice.
Also , it seems like a SPS is written for each new IDR slice/frame ,is that the case?
shouldn't there be one sequence parameter set for the entire stream?
I am sorry if all these questions are two much , I am trying to get into the details of
the code and will appreciate your patience.
p.s - is there a tool where I can analyze the encoded stream? that is , see the SPS , PPS , number of NAL unit etc.. ?
thanks
akupenguin
6th November 2005, 11:56
does x264 uses only one slice for each encoded frame?
I looked at the code and I couldn't find the place in which a frame
is devided into more then one slice.
encoder/encoder.c: x264_slices_write()
Also , it seems like a SPS is written for each new IDR slice/frame ,is that the case?
shouldn't there be one sequence parameter set for the entire stream?
x264 outputs a SPS for each IDR. If muxing to a format that only wants one for the stream (MP4 or Matroska), then the muxer throws away the duplicates.
p.s - is there a tool where I can analyze the encoded stream? that is , see the SPS , PPS , number of NAL unit etc..?
For bitstream-level analysis, I use JM (http://iphome.hhi.de/suehring/tml/) in trace mode (http://students.washington.edu/lorenm/src/x264/jm.trace.diff).
bond
6th November 2005, 12:55
@Sharktooth: I can't get the AVI input in your builds to work. Tried several files with different codecs, always get this error:
avis [error]: unsupported input format (hfyu)
could not open input file 'C:\Vid\Storage\keep\colorbars-huff.avi'
(with different FOURCC & filenames, of course)
Avisynth input works fine.i assume you have a vfw decoder for hfyu installed?
sr78
6th November 2005, 15:54
[QUOTE=akupenguin]encoder/encoder.c: x264_slices_write()
I looked into x264_slice_write() and I did not see any loop going
over more then one slice. The only loop I see in the code
is going over MB's.
Also , when I look at the stream with an hex editor I see 1 slice per frame.
(I know hex editor is not the easiest way to do it , I just wanted to go deep into the stream).
Sharktooth
6th November 2005, 16:07
I looked at the source code. Apparently only FOURCC == YV12 is supported. That may actually be ok...what I eventually want is to write out the raw frames during the 1st pass so that we don't have to execute the AVS script again on the 2nd/3rd passes. I've made some changes to MeGUI to assist with this, but it looks like it might be easier if I modify x264 too.
As bond said, are you sure you have a huffyuv VFW decoder? Coz x264 accepts only yv12...
Kopernikus
6th November 2005, 16:09
in slice_write() one slice is processed by one Thread.
slices_write() partitions the frame in slices and starts slice_write().
sr78
6th November 2005, 16:35
I can't find slices_write only slice write , was this added lately?
I will try updating my version from the svn
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.