x264 development

[aegisofrime]

The latest revision, 1442 has this feature:

iPhone compilation support

:D

Does that mean x264 encoding on the iPhone? I'm really looking forward to seeing what speeds it can do.

[Dark Shikari]

The latest revision, 1442 has this feature:

iPhone compilation support

:D

Does that mean x264 encoding on the iPhone? I'm really looking forward to seeing what speeds it can do.It can do realtime (~30fps) 320x240 on an iPhone 3GS with ~ultrafast to ~veryfast. It's probably good for realtime ~15fps full-screen video calls.

[hajj_3]

huge changelog in 1442 compared to 1416, great job by all of you :)

[CpT]

HOly crap:cool: Thanks guys!

[moviefan]

It can do realtime (~30fps) 320x240 on an iPhone 3GS with ~ultrafast to ~veryfast. It's probably good for realtime ~15fps full-screen video calls.

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.

[aegisofrime]

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.

This is probably a question for Apple rather than anyone else. :D Unless you were being sarcastic of course :p

I guess it can be used to replace the current H.264 encoder that the movie recorder current uses; I doubt it's using x264 (since r1442 is the first that can run on the iPhone?). Although GNU licensing issues will probably prevent Apple using it officially?

[Dark Shikari]

Just a quick more or less non-technical question: How should video calls be realized properly as the camera is on the backside of the iPhone? When the recipient sees me I cannot see him because I cannot see my own display :rolleyes:.Obviously we need to add a mirror ;)

[alexVS]

Thanks a lot for x264.exe! This encoder is just great!
Could you please clear up some questions to me:
1. I have not very fast CPU: AMD Athlon64 X2 4000+. Is there a version of x264.exe optimized for this CPU?
2. How much faster x264 64bit works relatively to x264 32bit on the same computer?
3. In megui\tools\x264 folder there is another file "x264..exe" (with dot after filename). What is this file?
Thanks again!

[nurbs]

1) Doesn't matter, you can use any version. The speed differences are minimal.
2) x264 itself will be about 10% faster, but depending on how much time is spent on decoding, resizing and filtering the gain you'll experience will be lower.
3) There isn't in mine, so it's probably a file you accidentally renamed.

[LoRd_MuldeR]

I have not very fast CPU: AMD Athlon64 X2 4000+. Is there a version of x264.exe optimized for this CPU?

Well, if "version" refers to the revision of x264, then one should always pick the latest revision available, because the speed of x264 is constantly improved by the developers.

But if you are referring to "CPU optimized" builds, then picking a build that was optimized for your CPU will only give a minor speed-up - compared to a "generic" build of the same x264 revision.

That's because those compiler-optimizations only effect the plain C code in x264, not the hand-optimized assembler code. And all the speed-critical functions in x264 are assembler code!

(Oh, and note that "amdfam10" optimized builds will NOT work correctly on your CPU! You probably should use a "athlon64-sse3" optimized build. Or simply a "generic" one)

[me7]

Is there a reason why the x64 builds on x264.nl are often outdated? Is there a better place to get x64 builds?

[bob0r]

They are compiled by JEEB.
And by outdated you mean a couple of hours/days behind the 32bit version?

Compiling 64bit requires some manual patching.
Fixes are present, but getting opensource people to do something they hadn't planned.... good luck James!

You must be glad you are getting them this fast at all, because i am too lazy to ever update my XP-32bit.

[JEEB]

Is there a reason why the x64 builds on x264.nl are often outdated? Is there a better place to get x64 builds?
You can always see my page if it's any faster than the update script on bob0r's site.

I think the 64bit builds have been online for... at least four or so hours, while because of revision numbers etc. as well as the updating script it took a few hours to get to the site (git hashes don't seem to be easy enough to bring info to users it seems ;) -- but that's already automatized at the moment).

Granted, I only woke up 6 or so hours ago, so yes -- the builds were a few hours late since I wasn't up n' running at the moment of the pushes. Also, I'm looking forward to actually automatizing this win64 patching of ffmpeg here by using git commit in order to keep the change there :3

Building just the 64bit x264 wouldn't be as problematic if we wouldn't have ffmpeg in there, but I guess that's something that you can deal with it if you try enough :3

Edit: Of course, you could always check out if anyone's doing builds without ffmpeg/ffms2, since that can be automated quite well. I might actually try doing that some day if I feel the need.

[LoRd_MuldeR]

Just for info, another source for pre-compiled x264 CLI for Windows (32-Bit and 64-Bit) is here:
http://www.xvidvideo.ru/x264-video-codec/

[me7]

Thanks for the insight, didn't know that ffmpeg complicates the process.
And yes, a few hours behind isn't too bad, I just didn't know that the 64-bit version requires some additional patching and I wondered if someone thinks "Alright, I just did the x84 compile but I will delay the x64 one, just to keep 'em waiting a bit longer".

Keep up to good work :thanks:

[bob0r]

Additional info: x264.nl checks for updates 24/7 again.
The script also auto mirrors the same rev from JEEB's site.

However since i can't code, the last mirror took a while again.

Let me show you part of the fail script:


revs_dir=/home/xuser/revs/64bit/revision$rev/

if [ ! -d $revs_dir ]; then mkdir -p $revs_dir; fi

if [ -d $revs_dir ]; then
echo ------------------------------------------------;
echo - no new updates, current 64bit revision: $rev ;
echo ------------------------------------------------;
exit 0;
fi


That's why it failed! :o

[LoRd_MuldeR]

I'm encountering reproducible crashes right at the beginning of the second pass with libx264 r1680:

Encoding Video codec : x264: 00:00:00
Encoding Phase : 2nd Pass

Program received signal SIGSEGV, Segmentation fault.
0x03cc7953 in x264_load_deinterleave_8x8x2_fenc_ssse3 () from D:\Avidemux 2.5\libx264-102.dll
(gdb) bt

#0 0x03cc7953 in x264_load_deinterleave_8x8x2_fenc_ssse3 () from D:\Avidemux 2.5\libx264-102.dll
#1 0x03c9aff9 in x264_ac_energy_mb (h=<incomplete type>, mb_x=0, mb_y=0, frame=0x863c440) at encoder/ratecontrol.c:227
#2 0x03c9b5fa in x264_adaptive_quant_frame (h=<incomplete type>, frame=0x863c440, quant_offsets=0x0) at encoder/ratecontrol.c:330
#3 0x03c9b97a in x264_macroblock_tree_read (h=<incomplete type>, frame=0x863c440, quant_offsets=0x0) at encoder/ratecontrol.c:389
#4 0x03cb8305 in x264_encoder_encode (h=<incomplete type>, pp_nal=0x28fab4, pi_nal=0x28fab0, pic_in=0x3c365c8, pic_out=0x28fa30) at encoder/encoder.c:2334
#5 0x03bb2352 in x264Encoder_encodeFrame () from D:\Avidemux 2.5\plugins\videoEncoder\libADM_vidEnc_x264.dll
(gdb)

Single-Pass encoding runs through just fine. Any ideas? :confused:

[Dark Shikari]

That sounds rather unlikely, becase r1680 is 104, not 102.

[LoRd_MuldeR]

That sounds rather unlikely, becase r1680 is 104, not 102.

Had to change that, as the calling app still expects 102. I also compensated the changes between 102 and 104, hopefully :)

Furthermore, as always, you've given absolutely no information I could possibly use to debug any problem.

Here are the settings I used:

#options: 352x288 fps=25/1 timebase=1/25 cabac=1 ref=1 deblock=1:-1:-1 analyse=0x1:0 me=dia subme=2 psy=1 psy_rd=0,00:0,00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=8 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=750 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=abr mbtree=1 bitrate=500 ratetol=1,0 qcomp=0,60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1,40 aq=1:1,00

If you need any more information, please tell me what you need exactly.

[Dark Shikari]

That's going to be hard to "compensate" for, given the fact that the NV12 change was a rather large API change. You can't just flip the number back and expect it to work!

Fix the bloody calling application.

Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

[LoRd_MuldeR]

That's going to be hard to "compensate" for, given the fact that the NV12 change was a rather large API change. You can't just flip the number back and expect it to work!

To my surprise it seems to work pretty well :eek:


Fix the bloody calling application.

Of course that is the "proper" solution, but it cannot always be done immediately. So I try to use a temporary workaround, until the calling app is updated.


Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

:thanks: I will check this as soon as possible...

[LoRd_MuldeR]

Also, fixed. (http://git.videolan.org/?p=x264.git;a=commit;h=84a051f3f1598c4c48de4c84f8750a73d32edeeb)

:thanks: I will check this as soon as possible...

Yup, I can confirm it works now. Thanks for the quick fix! :)

[LoRd_MuldeR]

Is anybody else experiencing crashes of 'x264.exe' during the profiling when trying to build r1722 ???

http://img706.imageshack.us/img706/1518/x264r1722fprofilecrash.th.png (http://img706.imageshack.us/img706/1518/x264r1722fprofilecrash.png)

gcc version 4.5.1 (x86.generic.Komisar) (GCC)

Apparently there's no crash with an "--enable-debug" build, so I cannot debug this :rolleyes:

[LoRd_MuldeR]

Small update:

I made a non-debug and non-fprofiled build, then tested it with all the various parameters combinations that are used in fprofile. No crash...

[MasterNobody]

LoRd_MuldeR
Can't replicate it here. Not with GCC 4.4.3 not with 4.5.1 (http://komisar.gin.by/mingw/cross-mingw.gcc451.generic.20100731.7z). Try with another sample for fprofiling.

[LoRd_MuldeR]

LoRd_MuldeR
Can't replicate it here. Not with GCC 4.4.3 not with 4.5.1 (http://komisar.gin.by/mingw/cross-mingw.gcc451.generic.20100731.7z). Try with another sample for fprofiling.

Doesn't make a difference. I still get a crash as soon as the first test run starts.

My source AVS looks like this:
FFVideoSource("..\Samples\Lossless\crew.704x576.avi")
AssumeFrameBased()

Tried Komisar's GCC 4.5.1 as well as TDM's and also GCC 4.5.2 from Xvidvideo.ru, but the issue is always the same :(

[Boulder]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

[LoRd_MuldeR]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

I don't compile with MP4 support either. Also I don't include lavf/ffms. I'm mainly interested in the "plain" DLL ;)

[MasterNobody]

Doesn't make a difference. I still get a crash as soon as the first test run starts.
As I can't replicate it than only I can suggest is to try configure without --enable-debug and then modify config.mak by removing '-s' for CFLAGS and LDFLAGS and adding '-g' in CFLAGS. Or the other way configure with --enable-debug and then patch config.mak by replacing '-O1' with '-O3' and may be adding '-fomit-frame-pointer'. Then try to run build for fprofiling in gdb.

[LoRd_MuldeR]

Okay, here's the result:

CFLAGS=-Wshadow -O3 -ffast-math -Wall -I. -I../pthreads -march=i686 -mfpmath=sse -msse -std=gnu99 -g -fomit-frame-pointer -fno-tree-vectorize -fprofile-generateD:\x264\x264-src>E:\MinGW.451-TDM\bin\gdb.exe --args d:\x264\x264-src\x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac
--direct temporal --ssim --no-weightb --threads 1 ../sample.avs -o NUL
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from d:\x264\x264-src\x264.exe...done.
(gdb) run
Starting program: d:\x264\x264-src\x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac --direct temporal --ssim --no-weigh
tb --threads 1 ../sample.avs -o NUL
[New Thread 4364.0x13c8]
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0

../../gdb-7.1/gdb/dbxread.c:1337: internal-error: Section index is uninitialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

I don't think this is a GDB issue, as the GDB works with other programs:
http://pastie.org/1168163

[Chikuzen]

x264.nl's r1722 builds seem to be compiled without mp4 output support, at least that's the error that pops up when I try to output mp4.

libgpac is in the state that cannot be compiled with mingw since rev2040.
bob0r said that mp4 output support will remove from x264.nl's build until libgpac comes to be good again at the build with mingw.
(I have complained about GPAC several hours ago. (https://sourceforge.net/projects/gpac/forums/forum/287547/topic/3857579))

[LoRd_MuldeR]

Just to be sure, I just reverted to x264 r1713 and built it in the identical build environment. Everything ran through fine!

So something between r1713 and r1722 must make a difference.

Either there's some bug in x264 r1722 that only shows up under certain circumstances or there's a bug in GCC that is triggered now and wasn't triggered in previous x264...

Thoughts?

[MasterNobody]

LoRd_MuldeR
Without the binary which crash and hopefully with debug info it is problematic to say what is wrong (may be you upload such build or better full x264 compilation directory). Also I hope you test not patched version.

[kemuri-_9]

I've been able to get gdb to get seg faults while as not using it does not get the seg faults, all without profiling.

removing -fomit-frame-pointer stopped the crashing.
this would coincide with --enable-debug not crashing as it does not add -fomit-frame-pointer
oh and i'm using gcc 4.4.4

[LoRd_MuldeR]

LoRd_MuldeR
Without the binary which crash and hopefully with debug info it is problematic to say what is wrong (may be you upload such build or better full x264 compilation directory).

Will do so, stay tuned...

Also I hope you test not patched version.

Usually I include custom patches, but for debugging purposes I of course work with "vanilla" builds ;)

[LoRd_MuldeR]

Here is an exact copy of my build folder as it was when "fprofile" was running, right when 'x264.exe' crashed:
http://mulder.brhack.net/temp/x264_r1722_fprofile_crash.7z

The 'trigger_crash.bat' reliably triggers a crash on my system. You may need to adjust the path inside 'sample.avs' though.

[rack04]

I am using 4.5.2 and I haven't experienced any crashes.

[aegisofrime]

I compiled 1722 successfully just now using instructions from here:

http://doom10.org/index.php?topic=26.0

Plain build, 64-bit without MP4 or FFMS input. Fprofiled too, no problems. Fprofile video is the bridge(far) video from here:

http://trace.kom.aau.dk/yuv/index.html

[MasterNobody]

LoRd_MuldeR
Try with this patch: http://pastie.org/1168299

[LoRd_MuldeR]

LoRd_MuldeR
Try with this patch: http://pastie.org/1168299

It seems that one did the trick!

http://forum.gleitz.info/images/smilies/cheers.gif


[EDIT]

Commited:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=b02df7b3b3b8616078851aab65d77ca435e2ff93;hp=e757d68b1a7f75de97cc472206cae52b770eeefb

Strange that apparently nobody else encountered problems with the regression :confused:

Anyway, thanks for the quick fix :)

[roozhou]

There are tons of work to do to add support for MSVC. If you need to include lavf input support, you still have to use MinGW to compile ffmpeg.

[schweinsz]

I downloaded the x264 version (http://www.xvidvideo.ru/x264-video-codec)to encode raw .yuv to lossless .264 using the following cmd:

D:\sequences\CIF>x264 --partitions "all" --qp 0 --keyint 2 --input-res 352x288 -o frmanls.264 foreman_cif.yuv (http://di-avc.com/x264_lossless.7z)
yuv [info]: 352x288p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.3, bit depth 8
x264 [info]: frame I:150 Avg QP: 0.00 size: 71310
x264 [info]: frame P:150 Avg QP: 0.00 size: 54972
x264 [info]: mb I I16..4: 3.7% 11.8% 84.5%
x264 [info]: mb P I16..4: 0.1% 9.9% 4.6% P16..4: 51.8% 18.6% 9.5% 3.4% 2.1% skip: 0.0%
x264 [info]: 8x8 transform intra:18.9% inter:66.1%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 99.7% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 14% 76% 8% 2%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 55% 13% 1% 2% 2% 2% 1% 2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 37% 7% 3% 11% 5% 6% 4% 4%
x264 [info]: i8c dc,h,v,p: 7% 40% 52% 1%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: kb/s:12628.21

encoded 300 frames, 27.08 fps, 12628.21 kb/s


Then I use the jm17.2 to decode the frmanls.264 to raw .yuv, but I found the reconstructed .yuv is corrupted. There is red blocks and corrupted bottom borders.
Is it a bug in x264 or a bug in jm17.2?


Edit1: I download the official x264 (http://mirror02.x264.nl/x264/revision1724/x264.exe) and find the same problem.

[kieranrk]

I downloaded the x264 version (http://www.xvidvideo.ru/x264-video-codec)to encode raw .yuv to lossless .264 using the following cmd:


JM doesn't support lossless.

[schweinsz]

JM doesn't support lossless.

I suspect your opinion. I ever explored the jm code and found many code related to lossless with the following style:

if(currMB->is_lossless)
{
if ((currMB->c_ipred_mode == VERT_PRED_8)||(currMB->c_ipred_mode == HOR_PRED_8))
Inv_Residual_trans_Chroma(currMB, uv) ;
else
{
for(j=0;j<p_Vid->mb_cr_size_y;j++)
for(i=0;i<p_Vid->mb_cr_size_x;i++)
currSlice->mb_rres [uv+1][j][i]=currSlice->cof[uv+1][j][i];
}
}

[kieranrk]

I suspect your opinion.

If I recall correctly it supports the old (I forget what it was called) lossless standard but not the new one (High 4:4:4 Predictive Profile Lossless).

[LoRd_MuldeR]

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...

[schweinsz]

Indeed, x264 uses the "High 4:4:4 Predictive Profile" in lossless mode. That profile isn't supported by some decoder, quite possible that JM reference is among them.

The H.264 decoder from 'libavcodec' (which includes ffdshow, MPlayer, VLC and friends) as well as 'CoreAVC' do support it though...
Yes, you are right. The JM doesn't support the new lossless mode. I have finished the lossless support of the DiAVC.

[Dark Shikari]

Yes, you are right. The JM doesn't support the new lossless mode.It does, but not for 4:2:0 (iirc) for some stupid reason.

[rallymax]

Hi team,

I did an update of the libav* codebase to get some new features - which in turn required a higher version of x264 so I updated that too. Not a problem I rebuilt libav* and libx264.

The x264_validate_parameters() is failing. I've seen this before and last time I simply commented the libx264.c x4->param changes out and used the x264 defaults instead. I also commented out the x264_validate_parameters#76 score code because I was more worried about getting the thing to run. But.... I know that's not the right thing to do since it's there, most likely, for a very good reason.

What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

I actually need the parameters to make it a legal BluRay stream.

When I commented out the code (above) that changed the parmeters and left it as defaults it processed fine and made a playable stream but Adobe Encore wouldn't recognize it as a legal stream and wanted to re-encode it and thus defeated the whole purpose of making a program using the BEST ENCODER IN THE WORLD!!! :thanks: to ditch the AWEFUL encoder bundled from Adobe.

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

thanks,
Rallymax


Here is the output of the out-of-box libavformat/output-example.c using the libav*.DLLs and libx264-105.DLL...

$ ./output-example xxx.h264
Output #0, h264, to 'xxx.h264':
Stream #0.0: Video: libx264, yuv420p, 352x288, q=2-31, 400 kb/s, 90k tbn, 25 tbc
[libx264 @ 003e1100] broken ffmpeg default settings detected
[libx264 @ 003e1100] use an encoding preset (vpre)
could not open codec


just saw this above "Authoring Professional Blu-Rays with x264" so I'm going to take those parameters and feed them into the x4->param and see how we go with the score.

[LoRd_MuldeR]

Did the NAL HRD patch get folded in since Feb '10? If not does that patch still work?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505 ;)


What should I be doing to to the x4->params.* in libavcodec/libx264.c to get this to not fail?

Initialize your 'x264_param_t' via x264_param_default() and then only overwrite the settings you need to overwrite. Use x264_param_default_preset() to apply presets/tunings.

(FFmpeg is known to set rather "bizarre" default settings for x264, so x264 will detect "broken" FFmpeg default settings to protect the user. Don't know if FFmpeg ever fixed their x264 default settings)


I actually need the parameters to make it a legal BluRay stream.

The commit message shows an example on how to configure x264 for BluRay compatibility...