x264 development

[Doom9]

This is a partial continuation of the former x264 development thread (http://forum.doom9.org/showthread.php?t=80910). This thread is meant purely for development purposes, which does not include making any feature requests, especially not for features to be added to the VfW interface!. Any VfW relates issues have to go here (http://forum.doom9.org/showthread.php?t=108569) instead. Any bugreports also do not belong to this thread but either in the VfW thread, or the x264 cli bugreport thread (http://forum.doom9.org/showthread.php?p=798509#post798509).

[macher]

I am new to x264 code
The decoder testing part in x264.c was removed some months ago and it has not returned since then. The exact release was a snapshot of 24-08-2005.
I want to work on the decoder for a project of my own. In that old snapshot the only thing in the coments was something like "The decoder test part is not working and we would appreciate some help in this direction". I would like to know what eactly were the problems in this regard and how much work i would have to put in to get it working again ?

[akupenguin]

The decoder supposedly supports baseline profile only. I have no idea how close to working it was in 2004, since I have never compiled it. In addition to just making it work, much will need to be updated to match changes in the functions shared with the encoder, which have been modified since then.

[macher]

from the compilation that i have i cannot get a clue as to which profiles it is supporting because i didnt see any comments about it(may b i ddint look hard enough). but i think it should be a bit more advanced.

[akupenguin]

No B-frames, no cabac, no wpred, no interlacing, and it was written before high profile existed. That makes it baseline.

[macher]

and nobody ever mad eany changes to it ?

[akupenguin]

Fenrir converted from cvs to svn in 2004-06-03, at which point earlier revision history was lost. The decoder has not been modified since then.

[macher]

is there any other open source decoder which supports the main profile or at least compatible with common output formats?

[akupenguin]

http://forum.doom9.org/showthread.php?t=108570

[macher]

thanks

[lspbeyond]

I have implemented the x264 decoder supported baseline profile several weeks ago. Unexpected, the current x264 program structure is not suitable for decoder. Especially of the interpolation module and the macroblock context cache load/save module. The experimental results show that it's half lower than ffmpeg libavcodec.
However, I won't stop improving my decoder. For I think the structure of h.264 decoder of ffmpeg libavcodec is so bad. And it's decoding speed is not fast enough.

[Leo 69]

I think the structure of h.264 decoder of ffmpeg libavcodec is so bad. And it's decoding speed is not fast enough.

That's right. Kick some CoreAVC's asses out there too :D

And now my question to the developers. What is to be done to the X264 encoder in order to improve visual quality and compressibility (i.e. what features are yet to be implemented) ?
Is there a roadmap for improving or anything else ?
It is always interesting to know in advance about what we may expect in the future, isn't it ?

Thanks

[akupenguin]

There is no plan, do not ask about future features, I will not discuss anything I'm writing until it's ready to test.

[Kostarum Rex Persia]

Well, Leo 69, try to read TODO list from http://students.washington.edu/lorenm/src/x264/todo.txt

[Tommy Carrot]

The RD subpel motion estimation (--subme 7) added in rev.476 is the old patch finally committed to the svn, or is it a completely new approach?

[Romario]

I don't know for sure, but I think that RD subpel motion estimation(--subme 7) is a old patch, with necessary changes.

[ChronoCross]

it's the old patch updated to work with the new svn. I think he may have made some updates to it in other ways as well.

[CEC]

Is the in-loop filter adaptive??? I made a high bitrate encode (720x576 2500 kbps) once with in-loop and once without! I can't see a difference between them!!!!!!

[Sharktooth]

yes it is.

[CEC]

Thanks for making it clear to me!!!:thanks:

In the Sticky: "MPEG-4 AVC/H.264 Information" bond doesn't say anything about adaptive loop in x264!!!

[IgorC]

I hope this link will be considirated as corelative (not like crossposting) http://forum.doom9.org/showthread.php?p=810697#post810697

[akupenguin]

In the Sticky: "MPEG-4 AVC/H.264 Information" bond doesn't say anything about adaptive loop in x264
Becuase all h264 codecs have adaptive loopfilter. It's impossible to make one that isn't adaptive, and still comply with the standard.

[7zeal]

I am trying to compress (2 pass, sharktooth's x264 530 - on the HQ-Insane profile, and 2000 kbps) a HD 720p movie (1280x528 @ 23.976 - a little cropped, it's widescreen) from wmv content.
I am running the first pass, as so:

H:\Movies>x264.exe --f
ps 23.976 --pass 1 --bitrate 2000 --stats "H:\Movies\[......] 16x9 72
0p WM9 HD-DVD.stats" --bframes 3 --b-pyramid --filter -2,-1 --subme 1 --analyse
none --direct auto --me dia --cqmfile "C:\Codecs\x264\Matrices\eqm_avc_hr.cfg" --progress --no-psnr --output NUL "H:\Movies\[.........] 16x9 720p WM9 HD-DVD.avs"
x264 [info]: file name gives 16x9
avis [info]: 1280x528 @ 23.98 fps (181032 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!

and it finally ends up writing this (you can see, not ALL the frames were written to the .stats file)

encoded frames: 180851/181032 (99.9%), 10.24 fps, eta 0:00:17
H:\Movies>

Now, as I call pass 2 with all the other options enabled, it throws out this error:
x264 [error]: 2nd pass has more frames than 1st pass (181032 vs 180999)
x264_encoder_open failed

I am using the same x264 commandline as the latest MeGui or StaxRip 0.9.9.2, in fact this first occured while trying to compress through MeGui, x264 HQ-Insane, then I wrote the commands on my own into the console, trying to figure out what I should change - no success. StaxRip 0.9.9.0 had the same difficulty (with Sharktooth's x264 build 467 if I remember well)

I tried to trim the movie from the avs script, cutting until that last frame encoded into the .stats file , so pass 2 worked.
However, though x264 said "23.98 fps", as I took a part of the encoded movie and muxed it into mp4 (latest mp4box), BSPlayer recognized it as 25 fps. (?)
The aac encoded is perfectly synched with the source wav from the wmv, BUT the encoded x264 movie (even from minute 3) seems to be earlier I think than the wmv. (???) why..
This happened before I ran x264 with --fps 23.976 - but I don't think it made a difference since it recognized it anyway as 23.98.

[daverc]

encoded frames: 180851/181032 (99.9%), 10.24 fps, eta 0:00:17

It happens to me when the source is directshowsource in the avs script and ffdshow does audio filtering, especially channel mixing.

Try to disable every filtering before launching your avs script.

[Sharktooth]

this is the dev thread and it has nothing to do with those kind of questions...

[7zeal]

I thought it was an x264 bug, doesn't that qualify?

[Sharktooth]

yes, sorry, i was a bit too drastic.

[7zeal]

It happens to me when the source is directshowsource in the avs script and ffdshow does audio filtering, especially channel mixing.

Try to disable every filtering before launching your avs script.

Thanks, seems like I may have a lead here..:P
(note: have lastest ffdshow-2546-gcc4.0.3-sse2-x264)
I had "Dolby Surround Downmix" on at audio processing plugins to be loaded automatically, but don't know if it's to blame, unchecked it anyway. (oh, and "subtitles" was also ticked for automatic loading in ffdshow at video decoder config).
I also have 'Avisynth' ticked at the video decoder config... hmm
It's suppose to bring ffdshow filters into avisynth. I left it on.
Is there anything else I should be doing ? I'll get back to you after running the first pass.

Thanks

[7zeal]

Same behaviour .. All ffdshow filters out, and the first pass still stops at 99% , 24 sec remaining.
What's wrong?

[ChronoCross]

Same behaviour .. All ffdshow filters out, and the first pass still stops at 99% , 24 sec remaining.
What's wrong?

This is the development thread. Bug-reports do not go here. Open a new thread or find the bug-thread. Thanks

[Xesdeeni]

Please forgive me (and be kind) if these are braindead questions (consider the source):

I'm trying to determine what the output file format is for the various apps wrapping the codec, specifically under Windows. Obviously the DirectShow AVI filter wraps the data in an AVI file format. But does the command line application use another file format? Which one(s)? And is it true that the h.264 standard file format is Quicktime (MOV)?

Xesdeeni

[GodofaGap]

CLI can output to raw h264, Matroska and mp4 (if compiled with GPAC library). There is not one standard container for h264.

[bond]

There is not one standard container for h264.indeed, there are three:
1) .mp4
2) .mpg
3) .ts

[Sergey A. Sablin]

indeed, there are three:
1) .mp4
2) .mpg
3) .ts

what is .mpg here? PS? or AVC Annex B format?

[RBF]

Sergey
.mpg -> PS
AVC Annex B is the byte stream format, not the container format, неправда ли?

[Sergey A. Sablin]

Sergey
.mpg -> PS
AVC Annex B is the byte stream format, not the container format, неправда ли?

right, just want to clarify things - I saw many .mpg files with TS/PS/VES/AnnexB inside. Sometimes even just audio.

[bond]

yep, i meant PS with .mpg

[Romario]

Look at this, can anyone confirm that devs read this.

http://www3.intel.com/cd/software/products/asmo-na/eng/219766.htm

[KoD]

Intel has those libraries on sale for quite some time. But it's not like they're free for use.

[Romario]

I don't know why Intel want money for this.

If this package become freeware, then devs can optimize their programs and codecs for Intel Core 2 architecture MUCH EASIER.

[Koti]

I don't know why Intel want money for this.

If this package become freeware, then devs can optimize their programs and codecs for Intel Core 2 architecture MUCH EASIER.

you could always buy the libraries for x264 dev's ;)

[Romario]

Yes, but I can't.

[KoD]

Because Intel is not making money only from selling Core2 Duo processors. They are actually producing more hardware and software than just cpus for personal computers.

[Romario]

Certainly, but...

If someone decide to make pressure on Intel software division, who knows what can happen? :)

[Sharktooth]

It's like asking M$ to make Windows OpenSource...
and however x264 has ASM optimizations that maybe are even faster than intel libs...

[Adub]

faster, really? is that because they are done by hand? But I thought that x264 hadn't been all the way optimized yet.

[Sharktooth]

Hand optimizations are always better than third party libs (that work well only on certain scenarios), also qualitywise x264 is as fast if not faster than commercial h.264 encoders... so how can you say it's not optimized?
Maybe there could be further speed optimizations but it's already quite fast.

[Adub]

I thought that Ateme blew it out of the water, maybe not in terms of quality, but speed wise. Maybe I am just hearing voices again.

Also, I ask about hand optimizations because I am interesting in learning to program and speed is a fetish. Ha! :)

[imcold]

so, learn about programming. It's fun and it doesn't hurt - allright, debugging can be very frustrating, but the bigger will be your joy after you finnaly manage to make the code behave the way you want.
Large programs are broken into smaller parts: functions. When you want to make your program run faster, you search for the functions that are most computationally intensive and then you find a better (faster) algorithm for it, you rewrite it in assembly, or very often both. Compiler may not generate the best assembly code for your function -it's just a program, not thinking being- in contrast with creator of the code, who is perfectly aware of what the function is supposed to do. Optimalizations (most of the time?) take advantage of SIMD (single instruction - multiple data) instructions: MMX, 3DNow!, SSE1/2/3 aso. They are kind of... parallel processing instructions, they provide huge speedup if properly used. X264 has plenty of optimized functions. It's kind of complicated for compiler to rewrite your function into SIMD instructions. So is for humans... but humans are intelligent, thinking beings, and creative too. You can find out an algorithm, that would work much better in SIMD. Compiler sort of... can't. That's why I believe humans will always (or for a very long time) be better for optimizing.

Also, about optimizing for some CPU - under this I understand using instructions that suit the CPU is best at: be it 3DNow for (old?) amds, SSE2 for core2, 64-bit instructions for 64bit processors on 64-bit OS etc. So in my eyes x264 is pretty much optimized for core2. Also I admire the programmers that take part in developing our beloved oss encoders and find them very skilled and inteligent (and I am most thankful for their work); I doubt that Intel's optimized code would be significantly faster - IF it would be faster at all.

sorry if this was kind of boring reading :D (also corrections welcomed). I also think that x264 is very fast taking it's complexicity (that makes me dizzy) into consideration (hey, it got faster by >30% during 2006 according to my tests). Big thankyou for the devs.

[pgb]

Hear, hear, imcold!

Anyone wanting to learn more about real programming and squeezing the most out of those clock cycles could do worse than read Don Knuth's magnum opus:

http://www-cs-faculty.stanford.edu/~knuth/taocp.html

And I'd like to add my thanks to the X264 developers too.

Happy holidays, everyone!

[Adub]

Thanks guys! I will give them a read when I have the time.

[dancho]

if you wanna learn more check this links:

Software optimization resources :http://www.agner.org/optimize/

Assembly Optimization Tips : http://www.mark.masmcode.com/

[Inventive Software]

Got a suggestion. Bear with me. :)

The progress indicator only updates every (total frames / 1000), thus for a 100000 frame movie, it updates every 100 frames. This is a little slow with some resolutions, so why not have it update the progress every frame and not by percentage? The current percentage could then go down to 2dp or 3dp instead of 1dp to accomodate the longer encodes, and be calculated each frame.

[check]

You can get something like that if you enable verbose mode.

[chadamir]

Sorry if this crosses over into feature request territory, but in the advanced dvd authoring forum we've been discussing codecs that are hd-dvd compliant. X264 is not. Some minor header changes need to be made to conform to spec. Is this being worked on? Fantastic work otherwise, certainly my choice for pc backups.

Heres the thread: http://forum.doom9.org/showthread.php?t=119392&page=4

[akupenguin]

No. I am not interested in HD-DVD or any other application that adds requirements beyond the H.264 standard for no good reason.

[chadamir]

But aren't the two data structures in the reference encoder?

[akupenguin]

You tell me. Can you make an HD-DVD compliant stream using JM? Does anyone even know what the constraints are?

[chadamir]

I guess the people on the forum who have the specs know. I do know JM supports those data structures which were said to be needed by those who have the specs. I thought JM only outputs avi and I have a feeling demuxing would ruin it.

[Manao]

I guess the people on the forum who have the specs knowNo. They have only a vague idea of what some of the constraints may be. Those who effectively have the specs are most probably under NDA and can't disclose them ( CF : http://forum.doom9.org/showthread.php?p=882932#post882932 )

[Sagittaire]

No. I am not interested in HD-DVD or any other application that adds requirements beyond the H.264 standard for no good reason.

Well it's really strange ... ???

It's like say "I am not interested in DVD or any other application that adds requirements beyond the MPEG2 standard for no good reason"

Actually all the MPEG2 encoder without DVD compliant support are completely useless. Tomorrow all the AVC encoder without HDDVD/BD compliant support will be completely useless ...

[bond]

in the end we simply need an avc stream that is hddvd compliant and analyse it in detail

i till now didnt see such a stream

[Manao]

Trying to second guess Loren : you want it, do it yourself, and he'll commit it.

Adding HDDVD support to x264 is boring, dull, and technically potentially illegal(yet) since the specifications don't seem to be public. There are much more interesting things to do in x264 than that ( for one, interlacing support ( half ironic *cough* ) ). Personnal motivation is still the principal incentive when coding for open source software.

Anyway, Loren must feel a bit lonely lately, so if somebody who was actually interested in HD DVD were to add such a fonctionnality, I think he'd be more than welcome.

Actually all the MPEG2 encoder without DVD compliant support are completely uselessDVD compliancy has nothing to do with the mpeg2 bitstream, so any encoder that respect the VBV buffer is 'DVD compliant'. Requirements put by HD DVD on the h264 bitstream are much more invasive and complicated, and are best handled in the encoder itself.

[vsv]

in the end we simply need an avc stream that is hddvd compliant and analyse it in detail

i till now didnt see such a stream

Just decrypt any HD-DVD released in Japan by backupHDDVD
http://forum.doom9.org/showthread.php?t=119871

and demux streams with HD DVD Demuxer
http://dvd-logic.com/hddemuxer.htm

[chadamir]

I will post a short hd-dvd image made with an avc for all to enjoy.

The following is a sample video file and an authored disc using it.
It was encoded with mainconcept H264 encoder version 2.1 and
sonic scenarist 4. It is 1920x1080i encoded as interlaced.


http://download.yousendit.com/6F2F833F3F48859A
Only 100 downloads so don't send it around kthnx.

[chadamir]

Using Inlet semaphore I've gotten the header. I'll now encode the same file using x264 at 4.1 profile and see how it differs

Summary
Source file : C:\Target\Untitled\0\emotion1.mpv
Width : 1920
Height : 1088
Frame rate : 59.9402 fps
FourCC :
Total frames : 0
File duration : 00:00:00:00
File bit rate : 0 bps
Video bit rate : 0 bps
Encode : CBR
Target bit rate : 8,000,000 bps
Buffer window : 2500 ms
Max key frame : 0 ms
Min quant : 0
Max quant : 0

Sequence Parameter Set
Field Value Description
profile_idc 100 High Profile
constraint_set0_flag 0
constraint_set1_flag 0
constraint_set2_flag 0
constraint_set3_flag 0
reserved_zero_4bits 0
level_idc 41 Level 4.1
seq_parameter_set_id 0
chroma_format_idc 1
bit_depth_luma_minus8 0
bit_depth_chroma_minus8 0
lossless_qpprime_y_zero_flag 0
seq_scaling_matrix_present_flag 0
log2_max_frame_num_minus4 4
pic_order_cnt_type 0
...log2_max_pic_order_cnt_lsb_minus4 4
num_ref_frames 4 Maximum number of reference frames for inter-prediction
gaps_in_frame_num_value_allowed_flag 0
pic_width_in_mbs_minus1 119 (1920)
pic_height_in_map_units_minus1 33 (544)
frame_mbs_only_flag 0 Frame or field macroblocks
...mb_adaptive_frame_field_flag 0
direct_8x8_inference_flag 1
frame_cropping_flag 1
...frame_crop_left_offset 0
...frame_crop_right_offset 0
...frame_crop_top_offset 0
...frame_crop_bottom_offset 2 (8)
vui_parameters_present_flag 1
...aspect_ratio_info_present_flag 1
.......aspect_ratio_idc 1 1:1
...overscan_info_present_flag 0
...video_signal_type_present_flag 1
.......video_format 2 NTSC
.......video_full_range_flag 0 luma/chroma range = 219/224
.......colour_description_present_flag 1
...........colour_primaries 1 ITU-R BT.709
...........transfer_characteristics 1 ITU-R BT.709
...........matrix_coefficients 1 ITU-R BT.709
...chroma_loc_info_present_flag 0
...timing_info_present_flag 1
.......num_units_in_tick 1001
.......time_scale 60000
.......fixed_frame_rate_flag 1
...nal_hrd_parameters_present_flag 1
.......cpb_cnt_minus1 0
.......bit_rate_scale 1
.......cpb_size_scale 3
.......bit_rate_value_minus1 1 62499 (8000000 bits/sec)
.......cpb_size_value_minus1 1 43399 (5555200 bits)
.......cbr_flag 1 0
.......initial_cpb_removal_delay_length_minus1 31
.......cpb_removal_delay_length_minus1 17
.......dpb_output_delay_length_minus1 17
.......time_offset_length 24
...vcl_hrd_parameters_present_flag 0
...low_delay_hrd_flag 0
...pic_struct_present_flag 1
...bitstream_restriction_flag 1
.......motion_vectors_over_pic_boundaries_flag 1 Motion vectors may exceed picture boundary
.......max_bytes_per_pic_denom 0
.......max_bits_per_mb_denom 0
.......log2_max_mv_length_horizontal 10 +/- 256
.......log2_max_mv_length_vertical 10 +/- 256
.......num_reorder_frames 1
.......max_dec_frame_buffering 4 Maximum frame decode buffers required

Edit:

The same file then demuxed from the EVO and put through semaphore

Source file : C:\0\VTS_001\Titles\t001_v001c001.m4v
Width : 1920
Height : 1088
Frame rate : 59.9402 fps
FourCC :
Total frames : 0
File duration : 00:00:00:00
File bit rate : 0 bps
Video bit rate : 0 bps
Encode : CBR
Target bit rate : 8,000,000 bps
Buffer window : 2500 ms
Max key frame : 0 ms
Min quant : 0
Max quant : 0

Sequence Parameter Set
Field Value Description
profile_idc 100 High Profile
constraint_set0_flag 0
constraint_set1_flag 0
constraint_set2_flag 0
constraint_set3_flag 0
reserved_zero_4bits 0
level_idc 41 Level 4.1
seq_parameter_set_id 0
chroma_format_idc 1
bit_depth_luma_minus8 0
bit_depth_chroma_minus8 0
lossless_qpprime_y_zero_flag 0
seq_scaling_matrix_present_flag 0
log2_max_frame_num_minus4 4
pic_order_cnt_type 0
...log2_max_pic_order_cnt_lsb_minus4 4
num_ref_frames 4 Maximum number of reference frames for inter-prediction
gaps_in_frame_num_value_allowed_flag 0
pic_width_in_mbs_minus1 119 (1920)
pic_height_in_map_units_minus1 33 (544)
frame_mbs_only_flag 0 Frame or field macroblocks
...mb_adaptive_frame_field_flag 0
direct_8x8_inference_flag 1
frame_cropping_flag 1
...frame_crop_left_offset 0
...frame_crop_right_offset 0
...frame_crop_top_offset 0
...frame_crop_bottom_offset 2 (8)
vui_parameters_present_flag 1
...aspect_ratio_info_present_flag 1
.......aspect_ratio_idc 1 1:1
...overscan_info_present_flag 0
...video_signal_type_present_flag 1
.......video_format 2 NTSC
.......video_full_range_flag 0 luma/chroma range = 219/224
.......colour_description_present_flag 1
...........colour_primaries 1 ITU-R BT.709
...........transfer_characteristics 1 ITU-R BT.709
...........matrix_coefficients 1 ITU-R BT.709
...chroma_loc_info_present_flag 0
...timing_info_present_flag 1
.......num_units_in_tick 1001
.......time_scale 60000
.......fixed_frame_rate_flag 1
...nal_hrd_parameters_present_flag 1
.......cpb_cnt_minus1 0
.......bit_rate_scale 1
.......cpb_size_scale 3
.......bit_rate_value_minus1 1 62499 (8000000 bits/sec)
.......cpb_size_value_minus1 1 43399 (5555200 bits)
.......cbr_flag 1 0
.......initial_cpb_removal_delay_length_minus1 31
.......cpb_removal_delay_length_minus1 17
.......dpb_output_delay_length_minus1 17
.......time_offset_length 24
...vcl_hrd_parameters_present_flag 0
...low_delay_hrd_flag 0
...pic_struct_present_flag 1
...bitstream_restriction_flag 1
.......motion_vectors_over_pic_boundaries_flag 1 Motion vectors may exceed picture boundary
.......max_bytes_per_pic_denom 0
.......max_bits_per_mb_denom 0
.......log2_max_mv_length_horizontal 10 +/- 256
.......log2_max_mv_length_vertical 10 +/- 256
.......num_reorder_frames 1
.......max_dec_frame_buffering 4 Maximum frame decode buffers required

[chadamir]

--pass 2 --bitrate 8000 --stats ".stats" --level 4.1 --ref 4 --bframes 2 --no-b-adapt --direct temporal --analyse p8x8,b8x8,i4x4 --vbv-maxrate 768 --threads auto --thread-input --progress --no-psnr --no-ssim --interlaced --output "C:\Documents and Settings\Chad\Desktop\x264header2.264" "C:\Documents and Settings\Chad\Desktop\x264header.avs"

Source file : C:\Documents and Settings\Chad\Desktop\x264header2.264
Width : 1920
Height : 1088
Frame rate : 59.9402 fps
FourCC :
Total frames : 249
File duration : 00:00:04:08
File bit rate : 31,670,915 bps
Video bit rate : 17,685,959 bps
Encode : CBR
Target bit rate : 4,000,000 bps
Buffer window : 2500 ms
Max key frame : 0 ms
Min quant : 17
Max quant : 27

Sequence Parameter Set
Field Value Description
profile_idc 77 Main Profile
constraint_set0_flag 0
constraint_set1_flag 1 Main profile constraints (clause A.2.2)
constraint_set2_flag 0
constraint_set3_flag 0
reserved_zero_4bits 0
level_idc 41 Level 4.1
seq_parameter_set_id 0
log2_max_frame_num_minus4 5
pic_order_cnt_type 0
...log2_max_pic_order_cnt_lsb_minus4 6
num_ref_frames 5 Maximum number of reference frames for inter-prediction
gaps_in_frame_num_value_allowed_flag 0
pic_width_in_mbs_minus1 119 (1920)
pic_height_in_map_units_minus1 33 (544)
frame_mbs_only_flag 0 Frame or field macroblocks
...mb_adaptive_frame_field_flag 1
direct_8x8_inference_flag 1
frame_cropping_flag 1
...frame_crop_left_offset 0
...frame_crop_right_offset 0
...frame_crop_top_offset 0
...frame_crop_bottom_offset 2 (8)
vui_parameters_present_flag 1
...aspect_ratio_info_present_flag 0
...overscan_info_present_flag 0
...video_signal_type_present_flag 0
...chroma_loc_info_present_flag 0
...timing_info_present_flag 1
.......num_units_in_tick 1001
.......time_scale 60000
.......fixed_frame_rate_flag 1
...nal_hrd_parameters_present_flag 0
...vcl_hrd_parameters_present_flag 0
...pic_struct_present_flag 0
...bitstream_restriction_flag 1
.......motion_vectors_over_pic_boundaries_flag 1 Motion vectors may exceed picture boundary
.......max_bytes_per_pic_denom 0
.......max_bits_per_mb_denom 0
.......log2_max_mv_length_horizontal 11 +/- 512
.......log2_max_mv_length_vertical 11 +/- 512
.......num_reorder_frames 1
.......max_dec_frame_buffering 5 Maximum frame decode buffers required

There are some discrepancies between my settings and the header. I ended up with 5 reference frames instead of 4. And I chose high profile in megui. Also there's all the header info that's simply not there.

[chadamir]

HD-DVD profile from megui

Sequence Parameter Set
Field Value Description
profile_idc 77 Main Profile
constraint_set0_flag 0
constraint_set1_flag 1 Main profile constraints (clause A.2.2)
constraint_set2_flag 0
constraint_set3_flag 0
reserved_zero_4bits 0
level_idc 41 Level 4.1
seq_parameter_set_id 0
log2_max_frame_num_minus4 5
pic_order_cnt_type 0
...log2_max_pic_order_cnt_lsb_minus4 6
num_ref_frames 5 Maximum number of reference frames for inter-prediction
gaps_in_frame_num_value_allowed_flag 0
pic_width_in_mbs_minus1 119 (1920)
pic_height_in_map_units_minus1 33 (544)
frame_mbs_only_flag 0 Frame or field macroblocks
...mb_adaptive_frame_field_flag 1
direct_8x8_inference_flag 1
frame_cropping_flag 1
...frame_crop_left_offset 0
...frame_crop_right_offset 0
...frame_crop_top_offset 0
...frame_crop_bottom_offset 2 (8)
vui_parameters_present_flag 1
...aspect_ratio_info_present_flag 0
...overscan_info_present_flag 0
...video_signal_type_present_flag 0
...chroma_loc_info_present_flag 0
...timing_info_present_flag 1
.......num_units_in_tick 1001
.......time_scale 60000
.......fixed_frame_rate_flag 1
...nal_hrd_parameters_present_flag 0
...vcl_hrd_parameters_present_flag 0
...pic_struct_present_flag 0
...bitstream_restriction_flag 1
.......motion_vectors_over_pic_boundaries_flag 1 Motion vectors may exceed picture boundary
.......max_bytes_per_pic_denom 0
.......max_bits_per_mb_denom 0
.......log2_max_mv_length_horizontal 11 +/- 512
.......log2_max_mv_length_vertical 11 +/- 512
.......num_reorder_frames 1
.......max_dec_frame_buffering 5 Maximum frame decode buffers required

[chadamir]

Ok thanks to bond we got the header to this point

profile_idc 100 High Profile
constraint_set0_flag 0
constraint_set1_flag 0
constraint_set2_flag 0
constraint_set3_flag 0
reserved_zero_4bits 0
level_idc 41 Level 4.1
seq_parameter_set_id 0
chroma_format_idc 1
bit_depth_luma_minus8 0
bit_depth_chroma_minus8 0
lossless_qpprime_y_zero_flag 0
seq_scaling_matrix_present_flag 0
log2_max_frame_num_minus4 1
pic_order_cnt_type 0
...log2_max_pic_order_cnt_lsb_minus4 2
num_ref_frames 4 Maximum number of reference frames for inter-prediction
gaps_in_frame_num_value_allowed_flag 0
pic_width_in_mbs_minus1 119 (1920)
pic_height_in_map_units_minus1 67 (1088)
frame_mbs_only_flag 1 Frame macroblocks only (no field)
direct_8x8_inference_flag 1
frame_cropping_flag 1
...frame_crop_left_offset 0
...frame_crop_right_offset 0
...frame_crop_top_offset 0
...frame_crop_bottom_offset 4 (8)
vui_parameters_present_flag 1
...aspect_ratio_info_present_flag 1
.......aspect_ratio_idc 1 1:1
...overscan_info_present_flag 0
...video_signal_type_present_flag 1
.......video_format 2 NTSC
.......video_full_range_flag 0 luma/chroma range = 219/224
.......colour_description_present_flag 1
...........colour_primaries 1 ITU-R BT.709
...........transfer_characteristics 1 ITU-R BT.709
...........matrix_coefficients 1 ITU-R BT.709
...chroma_loc_info_present_flag 0
...timing_info_present_flag 1
.......num_units_in_tick 1001
.......time_scale 60000
.......fixed_frame_rate_flag 1
...nal_hrd_parameters_present_flag 0
...vcl_hrd_parameters_present_flag 0
...pic_struct_present_flag 0
...bitstream_restriction_flag 1
.......motion_vectors_over_pic_boundaries_flag 1 Motion vectors may exceed picture boundary
.......max_bytes_per_pic_denom 0
.......max_bits_per_mb_denom 0
.......log2_max_mv_length_horizontal 11 +/- 512
.......log2_max_mv_length_vertical 11 +/- 512
.......num_reorder_frames 1
.......max_dec_frame_buffering 4 Maximum frame decode buffers required

But no NAL HRD.

[Inventive Software]

You can get something like that if you enable verbose mode.

Tried that, didn't give what I wanted. Essentially, a better progress indicator is what I'd like, if that's not too much to ask. I'd do it myself, but my coding's non-existant (practically).

[akupenguin]

It's like say "I am not interested in DVD or any other application that adds requirements beyond the MPEG2 standard for no good reason"
Exactly. If I were writing an MPEG2 encoding library, I wouldn't put anything DVD-specific in it. Of course, profile/level/VBV/GOP/etc are all configurable, but it's up to the application or user to configure them appropriately.

So: If you determine that HDDVD needs some H.264 feature like maybe a specific SEI message or one of the optional fields in the SPS, then feel free to implement it and send a patch. But I will reject any application-specific kludges, just like I rejected magiK's PSP-mode patch.

There are some discrepancies between my settings and the header. I ended up with 5 reference frames instead of 4. And I chose high profile in megui. Also there's all the header info that's simply not there.
x264's --ref selects the number of L0 references used by P-frames, not necessarily the DPB size. (Maybe someday I'll add a mode to optimize for max quality per DBP size instead of per encoding time/complexity.)
x264 signals the lowest profile that allows all your enabled features. You can't select high profile without enabling some feature that needs high profile.

[hpn]

For those who like patches I just got around to adding something small I've always thought was missing while encoding - total time on the progress indicator: patch (http://x264.net/x264_clock1-614.diff)

The progress indicator only updates every (total frames / 1000), thus for a 100000 frame movie, it updates every 100 frames. This is a little slow with some resolutions
Also in the patch - up to 10'000 times per input file seems more enjoyable with negligible speed penalty (a second/hour or something).

[Malow]

if someone need another hd-dvd compilant h.264 ES, go here:

http://forum.doom9.org/showthread.php?p=919921#post919921

[pyrates]

came across this strange error, here's the output:

C:\>x264.exe --pass 2 --bitrate 4665 --stats "L:\movie\108
0i.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct auto --direct-8x8 -1 --filter -2,-1 --subme 7 --trelli
s 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 6 --non-determ
inistic --cqmfile "E:\eqm_avc_hr.cfg" --progress -
-no-psnr --output "L:\movie\1080i.264" "L:\movie\1080i.a
vs"
avis [info]: 1920x1080 @ 23.98 fps (172975 frames)
x264 [warning]: width or height not divisible by 16 (1920x1080), compression wil
l suffer.
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
x264 [warning]: VBV maxrate specified, but no bufsize.
mb type: 7 mes: 10552/172975 (6.1%), 0.50 fps, eta 89:44:29
mv: l1r0 (115,407)
limit: 352
mb_xy: 1,11
completed: 264
Assertion failed: 0, file encoder/analyse.c, line 2714

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I am using the MT plugin for avisynth 2.5.6a with the following avisynth script:

SetMTMode(6,0)
# Modify the path so that it finds your decomb dll file #
LoadPlugin("E:\DeComb\decomb521.dll")

# Modify the path so that it finds your MPEG2DEC dll file #
LoadPlugin("E:\DGMPGDec\DGDecode.dll")


LoadPlugin("E:\MKVMagic\exe\filter\Convolution3D.dll")
LoadPlugin("E:\MKVMagic\exe\filter\deen.dll")
LoadPlugin("E:\MKVMagic\exe\filter\MSharpen.dll")
LoadPlugin("E:\MKVMagic\exe\filter\tdeint.dll")
LoadPlugin("E:\MKVMagic\exe\filter\UnFilter.dll")
LoadPlugin("E:\MKVMagic\exe\filter\undot.dll")

import("E:\MvBob\mvbob.avs")
import("E:\AVS Scripts\convert60ito24p.avsi")
Import("E:\MKVMagic\exe\filter\HybridFuPP.avsi")

# Modify the path so that it finds the d2v file you created using dvd2avi #
MPEG2Source("L:\movie\movie.d2v")
#audio=wavSource("E:\24.1.wav")
#audiodub(video,audio)
#Crop(left, top, -right, -bottom)
Crop(0, 0, -0, -0)

# Assume Top Field
#AssumeTFF().SeparateFields()
#Telecide(order=1)
# Assume Bottom Field
#AssumeBFF().SeparateFields()
Telecide(order=0)

# Reduce down to 23.976 fps
Decimate()

Undot()
Convolution3d(preset="movieHQ")

HybridFuPP(preset="High")

#assumefps(23976,1000)
assumefps(24000,1001)

I'm using build 614 of x264. The error occurs quite randomly I find but it is always the same error referencing the same line. Anyone know what it means?

[akupenguin]

It means that somehow the motion estimation failed to limit itself to the available range, and ended up using pixels that might not yet have been encoded by another thread.

[bkman]

Akupenguin, are you aware of the problem with direct B-frame modes and AQ or certain custom matrices? They can currently cause artifacts in some scenes unless the direct mode is set to "none".

Hopefully you can fix it, as disabling the direct B-frame modes wastes bitrate.

[pyrates]

It means that somehow the motion estimation failed to limit itself to the available range, and ended up using pixels that might not yet have been encoded by another thread.

So does this mean it is a bug and can be fixed?

[ChronoCross]

Akupenguin, are you aware of the problem with direct B-frame modes and AQ or certain custom matrices? They can currently cause artifacts in some scenes unless the direct mode is set to "none".

Hopefully you can fix it, as disabling the direct B-frame modes wastes bitrate.

AQ is an unsupported patch. As for custom matirces........any examples?

[bkman]

*.mp4 guy mentions that the problem occurs with some of his matrices in his Custom Matrix topic.

[akupenguin]

Akupenguin, are you aware of the problem with direct B-frame modes and AQ or certain custom matrices? They can currently cause artifacts in some scenes unless the direct mode is set to "none".
No, I am not aware of any such. I have heard some people suggest disabling B-direct as a last-ditch attempt to remove some artifacts, but I don't recall any cases where it actually worked. I always figured it was similar to people not using B-frames in XviD: a mistaken assumption that anything that improves compression ratio shouldn't be used if you want very high quality.

Artifacts related to cqm (assuming they're not a direct consequence of the matrix's frequency distribution) are probably due to the cqm deviating too far from the bitrate-per-qp values of the flat matrix. x264 makes some assumptions about the quality level of a given qp, and I'm not likely to work very hard at generalizing them for all cqms when you can always scale a cqm to match the flat matrix. (That and I'm not convinced that cqms are useful in the first place.)

[*.mp4 guy]

To be fair X264 does have trouble with b direct at times even with the standard matrix (though I haven't had any trouble in this reguard in a long time, so it may have been fixed). I'm also not sure that the problems are completely related to quality/qp, I think X264 may have trouble with cqm's that have a low dc coeficient even if they are similar in quality/qp to the flat matrix(just a guess though). I probably should mention that I have nothing against Bframes, or space saving features, I always use bframes in Xvid and X264, and whenevere possible I use B direct.

B Direct usualy only has trouble on smooth low contrast sources like the new starwars movies and you need a good crt (or any lcd with high contrast) to notice the problems, since they usually manifest as jittery flat blocks in almost flat areas.

As to matrices usefulness, all I have to say to that is banding, and low level detail loss (I don't care about noise loss personally). The flat matrix just isn't good at preventing banding and its reliance on inloop filtering to remove blocks removes small details aswell, though it preserves high frequencies amazingly well. Until the flat matrix stops banding and stops needing high inloop settings to have normal blocking levels (which might happen) matrices will be usefull to people who dislike banding and the "washed out" look inloop can cause more then ringing and slight blurring of prominent details.

I would like to have band free encodes with the standard matrix, but right now it isn't happening and cqm's are the best solution I'm aware of.

[*.mp4 guy]

Update: here is an example (http://www.megaupload.com/?d=1KGU9XJR)
This example is a lot more blatant then usual, the clouds in the beginning really seam to throw something off, though there are some (much less obvious) artifacts in other parts of the clip.

heres the matrix used:

INTRA4X4_LUMA =
15,6,15,22,
6,7,25,30,
15,25,38,48,
22,30,48,96

INTRA4X4_CHROMAU =
16,6,24,72,
6,8,41,144,
24,41,96,200,
72,144,200,255

INTRA4X4_CHROMAV =
16,6,24,72,
6,8,41,144,
24,41,96,200,
72,144,200,255

INTER4X4_LUMA =
4,11,15,22,
11,11,25,30,
15,25,38,48,
22,30,48,96

INTER4X4_CHROMAU =
5,16,16,16,
16,16,16,56,
16,16,72,96,
16,56,96,128

INTER4X4_CHROMAV =
5,16,16,16,
16,16,16,56,
16,16,72,96,
16,56,96,128

INTRA8X8_LUMA =
24,7,7,12,15,20,21,23
8,9,14,15,18,21,23,21
10,12,15,17,17,21,26,20
14,15,17,17,18,33,30,23
15,17,17,21,26,39,39,29
18,18,20,24,33,39,41,35
21,24,29,34,39,45,45,38
27,35,36,39,38,38,38,38

INTER8X8_LUMA =
6,10,13,13,15,16,18,22
10,10,12,15,15,16,21,24
13,12,15,16,19,21,25,27
13,15,16,21,24,28,30,34
15,15,19,24,30,36,37,40
16,16,21,28,36,42,45,52
18,21,25,30,37,45,55,72
22,24,27,34,40,52,72,96
I was actually trying to make the matrix more "compatible" to x264 by getting it closer to the compressability of the standard matrix... Doesn't seem to have worked. Its not spot on with the standard matrice's compressability, but I don't think it is far enough off to justify these results.

I'm currently making an encode without b predict to see if that fixes the problem as it has for me in the past.

[akupenguin]

also try with and without b-rdo

[*.mp4 guy]

The problem clip used b rdo, when I tested the clip with b predict disabled the problem went away. Right now I am working on getting a lossless file of a subset of the clip to exhibit the same behavior, after that I will test the clip with b predict enabled but without b rdo. I'll update this post when I am done.

[edit]
Quick summary of results
938KB B-rdo+B=predict enabled: prominent noticible artifacts
1210KB B-rdo disabled, B predict enabled: slight jerkiness of motion in low contrast areas, probably justified by space savings, ie everything is fine
1321KB B-rdo enabled, B predict disabled: everything is fine, however worse quality/space ratio then with b prediction enabled and b-rdo disabled

Here is a link (http://www.megaupload.com/?d=GYJ2Y6XH) with everything you need to reproduce the results.

[elguaxo]

I would be interested in doing a similar test like yours, but targeting the same filesize for all combinations. However I can't download anything from megaupload: All download slots assigned to your country (Argentina) are currently in use.

Could you upload the files somewhere else? Thanks!

[*.mp4 guy]

Files uploaded somewhere else (http://www.mytempdir.com/1146936).

[elguaxo]

Thanks, the new link works fine!

My eyes are not so fine-tuned like yours, I can spot the artifacts, but it was difficult.

M4G HRM V1.5 is the matrix some posts above?

[*.mp4 guy]

M4G HRM V1.5 is the matrix some posts above?
Yes, I probably should have more clear on that or included it in the archive to make things easier. I still have to do more testing to see how it compares to the old version, and I have to adjust the 4x4 luma matrices before it will be finnished.



My eyes are not so fine-tuned like yours, I can spot the artifacts, but it was difficult.
Its probably your monitor, not your eyes that made the problem hard to spot. The monitor I'm using is very unforgiving of artifacts compared to most crts.

[noclip]

I'm not a big fan of x264's logo (the firey one). It makes the best (IMHO) AVC encoder out there look second rate to somebody not well-versed in such things. Here's a slightly cleaner version which, if you want to use it, you can feel free to as it is in the public domain.

http://img340.imageshack.us/img340/5628/x264largedr4.png

[akupenguin]

The firey one is not x264's logo, it's x264.nl's logo. There is no official x264 logo.
Of the logos proposed so far, my favorite is the old vfw icon, though I never saw a large render of it.
http://img128.imageshack.us/img128/1286/x264icontb3.png

[noclip]

The firey one is not x264's logo, it's x264.nl's logo. There is no official x264 logo.

Ah. Well as I said, public domain, so if you ever feel like you need one...

[bob0r]

The VFW icon is just the same logo noclip posted, but with the 3 colors added.

So making a big render is quite easy.



... i have a whole week all for myself, i was thinking of a new design for x264.nl, but as usual i lack any graphical insight what so ever! :o

I was thinking a more dark style like:
http://x264.nl/x264_blue.png
But this is just fooling around.

[poyupay]

The VFW icon is just the same logo noclip posted, but with the 3 colors added.

yeah right! looks like that:

http://img329.imageshack.us/img329/2084/draft1fi5.png

or maybe like that...:

http://img329.imageshack.us/img329/4840/draft2er4.png

only drafts though. but if you're interested... :D

[AGDenton]

Hi,

[631] introduces a few SSE3-optimized functions for the x86_64 branch. I'm on a 386 right now, so I can't test them, but could you provide an estimate of their performance impact?

Also, there seems to be a few processors out there (Yonah, for instance) which support SSE3 but not EM64T : would SSE3 optimizations in the i386 branch be feasible, or benefitial ?

Best regards,

AG

[Manao]

rev631 introduces SSSE3 optimized functions, not SSE3. AFAIK, all SSSE3 processors are 64bits. Still, some people might want to use a 32 bits OS and a SSSE3 version would be appreciated for them.

It would be feasible and benefitial, you just need to find the guy to do it.

[Cef]

Hi,

I made x264 ssse3 builds since i couldn't find any, sharing if anyone interested
http://cef.neuf.fr/x264/x264_x86_r637.7z
http://cef.neuf.fr/x264/x264_x64_r637.7z

[Adub]

Thanks mate!

Yo, Sharktooth!
Are you making builds that support ssse3 as well, or are you sticking with the lesser optimizations?

[ChronoCross]

Thanks mate!

Yo, Sharktooth!
Are you making builds that support ssse3 as well, or are you sticking with the lesser optimizations?


ssse3 only works on intel processors.

[Eretria-chan]

ssse3 only works on intel processors.

Does it? AMD Athlon 64 X2 supports SSE3. Cpu-Z confirms this. SSE4 is Intel-only for the moment, though, AFAIK.

[Manao]

Electria-chan : SSE4 has been renamed SSSE3. So ChronoCross is right.

ChronoCross: strange, I was getting the impression that SharkTooth was an Intel fanboy :p

[Adub]

No, he is an AMD fanboy.
Shucks, does anyone know where we can get patched ssse3 builds?

[Romario]

Electria-chan : SSE4 has been renamed SSSE3. So ChronoCross is right.

Noo, SSE3 is SSE3, SSE4 is future instruction set designed for Penryn arhitecture (45 nm shrink of Core 2 Duo and Core 2 Quad).

[Manao]

Romario : count the number of Ss and check on the internet. But don't confuse users anymore than necessary when you're wrong - and wrong you are. MMX < SSE < SSE2 < SSE3 < SSSE3 < SSE4, and SSE4 doesn't yet exist, period.

[Adub]

Okay, now that that has been settled, does anyone know if their will be other ssse3 builds besides the two provided by our good man Cef? I am hoping for the patches that Sharktooth usually includes as well.

[Bigmango]

Hi,

I made x264 ssse3 builds since i couldn't find any, sharing if anyone interested
http://cef.neuf.fr/x264/x264_x86_r637.7z
http://cef.neuf.fr/x264/x264_x64_r637.7z

Wow thanks !!

Please keep them coming ;)

[Cef]

Please keep them coming ;)
Here goes
x264_x86_r644.7z (http://cef.neuf.fr/x264/x264_x86_r644.7z)
x264_x64_r644.7z (http://cef.neuf.fr/x264/x264_x64_r644.7z)
and source (http://cef.neuf.fr/x264/x264_src_r644.7z)

Okay, now that that has been settled, does anyone know if their will be other ssse3 builds besides the two provided by our good man Cef? I am hoping for the patches that Sharktooth usually includes as well.

I guess I could add them, if he doesn't mind.

[Adub]

That would be great!

Edit: Although, now that I think about it, are the patches really necessary? I mean a majority of them have already been incorporated into x264. Does anyone know if the patches compiled by Sharktooth actually make that big of a difference in quality?


Thanks a lot Cef, and know that you are always appreciated here.

[foxyshadis]

The signature patch is trivial, to increase MeGUI compatibility iirc, but the AQ patch is quite important to a lot of people.

An SSSE3 build will only make sense on x64, since the SSSE3 code is only currently enabled there. For optimizing the C code, well, it's not worth a special compile just to print the options list with SSSE3.

[Cef]

I enabled ssse3 in 32bit too, basically copy/paste with few passing parameters change. Except for x264_pixel_sa8d_8x8_ssse3/x264_pixel_sa8d_16x16_ssse3, which use way too many xmm registers to be converted to 32bit.

[Adub]

Thanks alot Cef!
I have yet to use your latest build, but your older one actually fixed a problem I was having with the previous X264 builds. And I think (it may have been my imagination) it was 2 fps faster.
Double thanks!

[Cef]

np at all. I made r644 builds with aq patch, just take previous links and replace 640 with 644. Both my 32 and 64bit builds are faster than anything I could find, on my core 2 duo. So if you have a C2D it's probably not your imagination. I think we're off-topic though, sorry about the spam >.<

[foxyshadis]

Nah, it's on-topic enough for a development thread. If you enabled all the satd & quant functions, did you submit a patch to akupenguin or the list? I'm sure he'd commit it. (You can edit new links into your old posts, if you want to, btw.)

[Cef]

did you submit a patch to akupenguin or the list?
Do you mean x264-devel (http://www.videolan.org/developers/lists.html) ? Quant changed in rev642 and is both 32 and 64bit now anyway, I could do that for satd I guess.

[Adub]

Yeah, I am using a core 2 duo, and I can definetly see a slight speed increase. I am downloading you latest build now.

[squid_80]

The 64-bit build doesn't run at all, it crashes immediately on startup. Did you check the code to see if it was win64 compatible?

[Cef]

which one? 644 runs just fine here. There was a bug in previous builds, coming from you actually :p movdqa rsp+16 with stack misaligned in x264_pixel_ssim_end4_sse2. Btw much props for your work on win64 asm :thanks:

[Bigmango]

The 645 build from x264.nl crashes every time after about 5 frames. Does anyone have the same experience ?

I am back to Cef's 644 build.

[LoRd_MuldeR]

Maybe it's related to this?
http://forum.doom9.org/showthread.php?p=979857#post979857

[Bigmango]

Maybe it's related to this?
http://forum.doom9.org/showthread.php?p=979857#post979857

Hmmm... I don't know. I am having this problem with the CLI version; the crash happens with the official x264.nl 645 exe.

But Cef's 644 exe works fine, both are using sse2... :confused:

[akupenguin]

The crash (http://forum.doom9.org/showthread.php?p=979857#post979857) is due to a bug in gcc. Cef built a win64 version, so he can't have been using gcc.

[Bigmango]

The crash (http://forum.doom9.org/showthread.php?p=979857#post979857) is due to a bug in gcc. Cef built a win64 version, so he can't have been using gcc.

Ok, thx for the info.

Btw, I am using Cef's x86 version.

[LoRd_MuldeR]

Bigmango, try Gruntster's rev645 build with the new fix included:
http://www.razorbyte.com.au/x264

[Bigmango]

Bigmango, try Gruntster's rev645 build with the new fix included:
http://www.razorbyte.com.au/x264

Oh, it's the lib; so I can try avidemux again :)

:thanks:

[squid_80]

which one? 644 runs just fine here. There was a bug in previous builds, coming from you actually :p movdqa rsp+16 with stack misaligned in x264_pixel_ssim_end4_sse2. Btw much props for your work on win64 asm :thanks:
I had r637, it was crashing in exactly that spot. 644 runs good. Not sure how I came up with [rsp+16] which presumably would never have worked.
Also the handle leak I was getting when using multiple threads seems to be gone; did you do something to fix it, has pthreads been updated since I made a build, or did the problem just mysteriously go away?

[bob0r]

When the patch is applied to the svn, i will remove the notes and everything should be ok again.

So hopefully in the next revision its all ok again.

Keep testing, using and reporting! :thanks:

[Cef]

Not sure how I came up with [rsp+16] which presumably would never have worked.
Maybe you never noticed it, with my usual settings the bug wasn't triggered, I happened to find it while running x264 with no options for a quick test.

Also the handle leak I was getting when using multiple threads seems to be gone; did you do something to fix it, has pthreads been updated since I made a build, or did the problem just mysteriously go away?
Actually it's not using pthread, just some #define's falling back on win32 threads, cause I had trouble getting pthread to work, but now I got it to work, please check x264_x64_r645.7z (http://cef.neuf.fr/x264/x264_x64_r645.7z)

[squid_80]

Can't open that .7z file: winrar 3.62 reports unknown format or damaged. Same with 7-zip 4.44 beta.

[Cef]

Sorry about that, try again.

[squid_80]

Got it, shows the same handle leak that I was seeing with before. :(

[Cef]

I think I found the problem, some inline asm in ptw32_InterlockedCompareExchange.c was ignored when compiling pthread for amd64. Should be gone now : x264_x64_r648 (http://cef.neuf.fr/x264/x264_x64_r648.7z)

[Terranigma]

I hope it works. x264, for me, seems to have been b0rken after revision 644 :(

---
Nope, doesn't even start up. =/

[Adub]

Cef, are you going to do a x86 build?

[Terranigma]

yes cef, when you do builds, could you do an x86 build as well? :D

[Bigmango]

I hope it works. x264, for me, seems to have been b0rken after revision 644 :(

---
Nope, doesn't even start up. =/

The latest 648 build works great for me. It seems the problem was fixed since build 646.

Did you try it ?

Here:
http://x264.nl/
http://mirror01.x264.nl/x264/revision648/x264.exe

[Terranigma]

The latest 648 build works great for me. It seems the problem was fixed since build 646.

Did you try it ?

Here:
http://x264.nl/
http://mirror01.x264.nl/x264/revision648/x264.exe


It works, but unfortunately I can't use adaptive quantization for dark scenes. Perhaps the commandline for aq changed? :confused:
I've made profiles using aq. =P


Anyways, i'd like to say that It seems x264's now twice as fast as before :D

[burfadel]

Adaptive quantisation is only an experimental patch apparently! The builds at x264.nl are pure svn builds. Although adaptive quantiser is experimental I find it works very well! it mustn't be quite ready though...

You have to search for the adaptive quantiser builds. Sharktooth makes them but he doesn't always have the time to stay updated, he's still with revision 635. CEF on this thread actually has the latest adaptive quantiser build... rev 645 for x86 and rev 648 for x64. Both work great! I'm sure he'll put up a rev 648 for x86 at some stage as people have asked him for it... He did a good job of implementing SSSE3 instructions! :)

It works, but unfortunately I can't use adaptive quantization for dark scenes. Perhaps the commandline for aq changed? :confused:
I've made profiles using aq. =P


Anyways, i'd like to say that It seems x264's now twice as fast as before :D

[Terranigma]

Thanks burfadel for the prompt reply. Look like i'll have to look forward to a build by cef :cool:

[Selur]

What about the one here:
http://forum.doom9.org/showpost.php?p=980523&postcount=130

[Terranigma]

that's for x64.

[Selur]

oh, you are right overlooked that sorry :)

[Romario]

About SSE3 implementation in recent x264 builds, can someone explain to me what parts of the code is changed?

Speed-ups?

[Manao]

SSS3, and, yes, it results in speed up.

[akupenguin]

There are only 2 places I found where SSSE3 could be used: satd uses PABS, and quantization uses PSIGN and PABS.
PHADD/PHSUB looked interesting, and they do reduce the code size, but at least on a current Core2 they're so much slower than PADD/PSUB that it's faster to transpose, column sum, transpose than to row sum.

[Manao]

Did you do deblocking already ? Or do you consider it not as important (speedwise) in an encoder as in a decoder.

[akupenguin]

Both: I didn't see anything in deblocking that would change, and there's already several deblocking optimizations in ffmpeg that I haven't bothered to port. Deblocking spends more time in C code (computing the filter strengths) than in asm (munging pixels).
There are some absolute value computations, but they can't be done with PABS because the intermediate signed value would take 9 bits, whereas the current code can get away without ever unpacking the pixels from 8 bits.

The horizontal 6tap filter would benefit from PALIGNR, but then it would probably benefit even more from SSE2 (currently it's only MMX). And again that's not in the inner loop when encoding.

[Cef]

Cef, are you going to do a x86 build?
Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

[Terranigma]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

Thanks a lot Cef. :devil:

[akapuma]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)
Thank you very much.

Best regards

akapuma

[Bigmango]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

Your link does not work ?


Multiple Choices
The document name you requested (/x264/x264_x86_r648.7z) could not be found on this server. However, we found documents with names similar to the one you requested.

Available documents:

* /x264/x264_x86_r640.7z (mistyped character)
* /x264/x264_x86_r644.7z (mistyped character)
* /x264/x264_x86_r645.7z (mistyped character)

[burfadel]

Works for me! he must have fixed the link :)

Thanks Cef for making these builds, its much appreciated!

[squid_80]

I think I found the problem, some inline asm in ptw32_InterlockedCompareExchange.c was ignored when compiling pthread for amd64. Should be gone now : x264_x64_r648 (http://cef.neuf.fr/x264/x264_x64_r648.7z)
Looks perfect. Congrats on fixing it and thanks for doing x64 builds so I don't feel guilty about not keeping mine up-to-date.

[burfadel]

He also include the AQ patch which is great! :)

[Dannyboy007]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?

[bob0r]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?
http://x264.nl/jab.gif

[Bigmango]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?

The container has nothing to do with quality. It's only what it is... a "container".

The advantage with mkv, is that you can keep all the DVD sound tracks and subtitles. The disadvantage is that there is almost no hardware player support for mkv.

MP4 has more hardware player support, but compared to mkv, it has a lot of restrictions. You can't put DTS or AC3 tracks in MP4, and if I remember well, it is also limited to max 2 subtitles.

MKV is the better container.

[Dannyboy007]

I see. Thanks a lot Bigmango!

[bond]

in MP4, and if I remember well, it is also limited to max 2 subtitles.not true, you can place as much subs as you want in mp4

[Selur]

little feature request: option to stop x264 from exporting all the x264 encoding settings into the userdata.

[Terranigma]

little feature request: option to stop x264 from exporting all the x264 encoding settings into the userdata.

x264 Author's Response (http://forum.doom9.org/showthread.php?p=989015#post989015)

[Bigmango]

not true, you can place as much subs as you want in mp4

Ok, I was not sure on that one. Thx for correcting this.

[Sagittaire]

Possible to implement pulldown flags in x264 elementary stream ... ?

[Terranigma]

cef, any chance for a rev 651 build?
r651 | pengvado | 2007-04-21 13:32:34 +0200 (Sat, 21 Apr 2007) | 3 lines

cabac: use bytestream instead of bitstream.
35% faster cabac, 20% faster overall lossless, ~1% faster overall at normal bitrates.

[burfadel]

cef, any chance for a rev 651 build?

Make that 652 build :)

The aq patch is great! I wonder why it hasn't been included in the final build yet!

The thread patch sounds interesting, I wonder when that will be ready for inclusion!

Oh, and Cef you should let Sharktooth etc know what settings you use for your x264 compilation, because it seems to be way faster (same quality of course). Its not just a few percent either, it flies in comparison on my Core 2 Duo :)

[burfadel]

Cef's builds can be found on his x264 page here:

http://cef.neuf.fr/x264/

Hopefully he keeps up the good work and updates it soon with the latest build! He's currently got 650 up.

[e-Pawel]

The aq patch is great! I wonder why it hasn't been included in the final build yet!


What is that aq patch? What is its advantage???

[Terranigma]

What is that aq patch? What is its advantage???
Quote:
One part of the settings for Adaptive Quantisation. Adaptive Quantisation allows different parts of a frame to use different quantisers, as opposed to the whole frame using the same quantizer. The common use for this in XviD was that it would compress light and dark areas more, thus freeing bits for parts that were more noticable. Adaptive Quantisation works differently in x264 because it was added by Haali to address a problem that large blue areas could sometimes look blocky. Adaptive Quantisation in x264 assigns more bits to dark and blue areas to help stop them blocking up. This particular setting instructs the amount to adjust QP per Macroblock. Setting 0.0 is no Adaptive Quantisation, and 1.1 is considered strong. It is recommended that you only use this setting if your source is particularly blocky in blue areas only wheras the rest of the image looks fine.

[Selur]

little question about all the patches:

What has to happen for a patch to become part of the main branch?

Cu Selur

[Cef]

Cef's builds can be found on his x264 page here:

http://cef.neuf.fr/x264/

Hopefully he keeps up the good work and updates it soon with the latest build! He's currently got 650 up.

Thanks for noticing :) I updated to 654 today, sorry about the delay.

[LoRd_MuldeR]

little question about all the patches:

What has to happen for a patch to become part of the main branch?

Cu Selur

I guess the developers must be willing to accept and maintain the patch.
Just adding the patch to the SVN isn't enough, as future changes might break the patch.

[Terranigma]

Thanks for noticing :) I updated to 654 today, sorry about the delay.

Welcome back Cef, we missed you :D

[burfadel]

New build of x264 out, 656. Very small changes in regards to speed apparently, but still its the first update in a while!

[fight2win]

how to update x264 in megui to latest version???

[Terranigma]

how to update x264 in megui to latest version???

By copying the x264.exe file to megui\tools\x264

[burfadel]

Long wait, 658 is out :) very small changes but its an update! :D

[mroz]

I'm trying to find out what the current state of support is for interlaced encoding (in respect of future pal dv encodes).

I've spent a good three nights searching the web including this forum & can't find any mention more recent than last year, none of which were definitive but did make it clear interlaced support is still young.

DeathTheSheep's guide http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html states trellis & b frames have to be disabled. Is this still the case or is it maybe specific to the VfW version (seems unlikely)? Disabling b frames seems so extreme as to make me question whether I ought to consider x264 yet for this application. I think in such a case I'd have to restrict x264 to dv with only low motion & then deinterlace prior to encoding, which would be a shame.

Yet when I look at various third party front ends several seem to allow selection of interlaced functionality without any caveats either built into their code or docs - eg Megui iirc & certainly h264enc.

Is there any information available elsewhere?

I hope it was okay to pose this question in the dev thread. :thanks: for an excellent codec btw.

[akupenguin]

Trellis and B-frames work with interlacing.
B-pyramid might not, there's a bug I still have to track down.

[mroz]

:thanks: for the lightening quick response. I'll give interlaced encoding a go when I next have a batch of miniDV tapes to edit - quite curious so might have to do some testing soon.

[simonhowson]

I'm wondering if the motion estimation in next generation intel CPUs could help x264? Intel have sample code on their webpage here (http://softwarecommunity.intel.com/articles/eng/1246.htm) explaining how the new SIMD instruction is designed specifically to help speedup modern video encoders.

I was considering buying a Core 2 Quad CPU when the prices are cut on July 22nd. But if these new instructions are going to make their next gneration CPUs even better for video encoding, then I may wait for those.

Does x264 rely on these sort of motion estimation? Or is it unlikely that this feature will help with the way x264 works?

I mainly encode to the iPod 5.5 profile in MeGUI, does this even use motion estimation? Or is it only used in higher profiles?

[Terranigma]

I think someone, maybe even myself, should consider compiling patched builds from the sources in Cef's absence. Now if only there was a package that contained everything I need to compile......

[Manao]

simonhowson : http://forum.doom9.org/showthread.php?p=993986#post993986

So SSE4 isn't that usefull for the motion estimation. It will speed up the codec, but don't expect miracles.

[simonhowson]

simonhowson : http://forum.doom9.org/showthread.php?p=993986#post993986

So SSE4 isn't that usefull for the motion estimation. It will speed up the codec, but don't expect miracles.
Ahh, thanks for the reply, so it looks like the main improvement will be the bigger caches (6 MB rather than 4 MB).

[mroz]

How important is L2 cache to x264? I'm currently using a bunch of old Athlon XP machines & have always built AMD in the past as I like value for money. Probably be building a new machine in the next three months & will obviously be switching to Intel Core 2.

The cpu will either be the price slashed Quad 6600 or an overclocked budget E21xx. As x264 encoding will be a common task for the box I just wanted to check how big an impact the cache size will have.

Obviously I'd rather have the quad, but it'll depend on exact prices, how many pennies I have in the jar & expected relative performance.

[burfadel]

There is a massive difference metween the Q6600 and the ultra budget one you suggested. If you are thinking of an E6300 or E6400, you should pass those as they have been superceded by the E6320 and the E6420. The E6320 and E6420 have 4mb of L2 cache compared to the E6300 and E6400's 2mb, but run at the same speed. They are also the same price, so going for the older 6300's and 6400's would be silly (unless they cut the price in half or something).

[mroz]

There is a massive difference between the Q6600 and the ultra budget one you suggested.

I realise that. I just wanted to be able to make a judgement based on performance as one component only, but to do that I need to know how important cache size is to x264. How important is it?

Thanks for the other info.

Any c2d is going to massively outperform my old machines. A quad would be nice but even slashed it will still cost significantly more than an E21xx & cost is a major concern, especially as over the next year I'd like to replace all three of our existing desktop machines.

Normally I go with value first (ie minimal price : performance) & keep to the budget end of the spectrum, but if the price cut to the Q6600 makes it /much/ better value I might aim for it. I'm not likely to go for anything mid range unless they look to be at least as good value as the Q6600. I don't want to go into further detail about my reasoning as that would take this off thread.

Can anyone answer the cache question?

[akupenguin]

I have only one data point on the cache question, so take this with a grain of salt:
An Athlon64 w/ 1MB L2 cache is 5% faster per clock cycle than an Athlon64 w/ 512KB L2 cache when running x264.

[mroz]

:thanks:

A small data set indeed, but if cache size was the only difference it still seems potentially significant. Ta for the info.

Reminds me, I seem to recall reading elsewhere about the idea to bundle some performance analysis & reporting code with standard x264 builds. As I like stats that'd be a cool thing to see. I hope that idea gets off the ground. Must search for that thread.

Thanks again.

[Manao]

That would be : http://forum.doom9.org/showthread.php?p=1011128#post1011128

[mroz]

Ooh, lovely data :) Now I do want a quad.

Wasn't the thread I stumbled over before though - that talked of x264 incorporating code to gather stats automatically.

[Terranigma]

Update: x264 revision 659 by Cef (http://cef.neuf.fr/x264/) :)

[JarrettH]

rev 662

Add vertical and horizontal luma deblocking accelerated with Altivec,
based on Graham Booker's code written for FFmpeg with slight modifications
to re-use x264's macros

can anyone explain more about this change?

[Manao]

It speeds up the deblocking on power PC

[burfadel]

Altivec is the PowerPC (older Macintosh) version of SSE (thankyou Wikipedia!). Therefore it will provide no benefit for a x86/x64 based comptuer.

Here's the next question... is deblocking fully SSE/SSE2/SSE3/SSSE3 optimised? ...

[Manao]

For x86, it's mmx/isse only.
For x64, it's mmx/isse & sse2 only.

Deblocking will gain some speed with SSE2 on p4/conroe in x86, and with SSSE3 in both x86/x64. However, on the whole encoding process, that speed gain is negligible, especially when subme is high.

[JarrettH]

thanks, i've been looking for a reason to update from 656, guess that isn't it :p

[burfadel]

thanks, i've been looking for a reason to update from 656, guess that isn't it :p

Update to 661 though...!

Oh, and use cef's build, they're noticeably faster (several percent) on Core 2's anyway.

Plus he has the thread pool patch, aq patch etc so with the extra settings to can maximise the cpu use, leading to a little extra speed.

If someone knew what they were doing, they could update the x86 code to maximise the use of sse/sse2/sse3/ssse3, as there's many parts that aren't using the fastest implementation if available.

[rbt01]

how to use the C version instead of asm version of the module in codec?

I want to use the dct.c instead of the dct-a.asm.

[burfadel]

Here's a good question:...
Media Player Classic has the options to use pixel shaders, and you can select the pixel shader version through the editor. These do things such as sharpening etc.

I was wondering whether its possible to port it into x264, and have certain functions completed with the pixel shaders (preferable 3 or 4 due to their speed, but with the ability to select shader 2 on older cards)? I'm sure Gabest would be ok with that, as long as you get prior permission.

Even if you also have to port the (preferably) EVR mode (as this is the preferred mode in Vista for the future, and is available on XP through Net framework 3).

Is this at all possible? I realise it would require a bit of work, but at least there's a base to start from. This could give a very significant boost to encoding performance (in theory)...

[Inventive Software]

how to use the C version instead of asm version of the module in codec?

I want to use the dct.c instead of the dct-a.asm.

If you mean when you compile, I can't remember cause I've not done it in years, but if you mean when encoding, then add:
--no-asm
to the command line.

[Terranigma]

akupenguin, could you comment on what the change is for revision 665? I just seen a new version posted at x264.nl, but nothing of a changelog. Thanks in advance :)

[Bigmango]

akupenguin, could you comment on what the change is for revision 665? I just seen a new version posted at x264.nl, but nothing of a changelog. Thanks in advance :)

r665 | pengvado | 2007-07-13 01:48:23 +0200 (Fri, 13 Jul 2007) | 2 lines

extend zones to support (some) encoding parameters in addition to ratecontrol.

[celtic_druid]

"extend zones to support (some) encoding parameters in addition to ratecontrol."

[bob0r]

gcc -o x264.exe x264.o matroska.o muxers.o libx264.a -lpthreadGC2 -lwsock32 -lgpac_static -lwinmm -lvfw32 -s -fprofile-generate
libx264.a(ratecontrol.o):ratecontrol.c:(.text+0x4077): undefined reference to `strtok_r'
libx264.a(ratecontrol.o):ratecontrol.c:(.text+0x422d): undefined reference to `strtok_r'
make[1]: *** [x264.exe] Error 1
make[1]: Leaving directory `/home/user/x264'
make: *** [fprofiled] Error 2

Any clue anyone? (i see Cef compiled it)

[Sharktooth]

are you sure you did a correct svn checkout?
i cant check what's going on at the moment, but it seems you could have some old files on your local copy (or maybe a typo in the sources??!? check the changes on the SVN)

[bob0r]

Trax has the same issue, only x264 changed, nothing on my system.

[Sharktooth]

try updating glibc. if it still fails then HAVE_STRTOK_R / NO_STRTOK_R must be implemented ...

[Selur]

"extend zones to support (some) encoding parameters in addition to ratecontrol."
some additional infos would be nice, since --longhelp doesn't show any additional infos :)

[bob0r]

try updating glibc. if it still fails then HAVE_STRTOK_R / NO_STRTOK_R must be implemented ...

Might you help me with telling me what to update?
lib and include files? If so which ones... i dont want to mess up my current system :)

Compiling whines about some port thingy....

[Sharktooth]

the GNU C Library... http://www.gnu.org/software/libc/

[bob0r]

Temp solution found here:
http://forum.doom9.org/showthread.php?p=1024677#post1024677

Note, i will not update x264.nl with a patched version, ill wait for this to be fixed in SVN.

Thanks for the help!

[MetalPhreak]

"extend zones to support (some) encoding parameters in addition to ratecontrol."
some additional infos would be nice, since --longhelp doesn't show any additional infos :)

I'd also like to know what parameters can be used with zones, usage examples?

[akupenguin]

8x8dct, b-bias, b-pyramid, bime, brdo, chrome-me, dct-decimate, deblock, direct, fast-pskip, me, merange, mixed-ref, nr, partitions, ref, scenecut, subme, trellis.

example:
x264 in.avs -o out.264 --crf 20 --deblock -2:-2 --zones 1000,2000,deblock=0:0/2000,3000,nodeblock


Regarding strtok_r: I just remembered there's a reason strtok_r is necessary and strtok doesn't work. It's not just making x264 as a whole re-entrant, but even within one call to zones it depends on strtok_r being re-entrant. So if you have multiple zones and any of them use the new parameters, parsing will fail on windows. I'm not interested in re-implementing strtok (not that it's hard, just I don't care), so it will stay broken until someone submits a patch.

[Selur]

@akupenguin: any plans to extend zones, that one can force an IDR Frame at it's beginning? (sometimes one might want cutpoints at specific frames)

[Cef]

I found a small bug in ratecontrol.c, h->rc->zones[i].param are allocated with regular malloc and freed with x264_free. It probably goes unnoticed on most platforms, but it's actually crashing in my build.

[Trahald]

Regarding strtok_r: I just remembered there's a reason strtok_r is necessary and strtok doesn't work. It's not just making x264 as a whole re-entrant, but even within one call to zones it depends on strtok_r being re-entrant. So if you have multiple zones and any of them use the new parameters, parsing will fail on windows. I'm not interested in re-implementing strtok (not that it's hard, just I don't care), so it will stay broken until someone submits a patch.

im just using
#ifdef _MSC_VER
#define strtok_r strtok_s
#endif

in ratecontrol.h

from what i read the problem is solely on a gnu compile. (i compile in msvc)

[TheRyuu]

I've built x264 using a newer GCC 4.2.1.

The reason I don't like GCC 3.4.x is because when you use -O3, it turns on -frename-registers (or whatever it's called :p). That option is useless (IMO) (but it can be useful on x86_64), not to mention the newer GCC versions are better at optimizations.

You can get it here (rev667b x86). (http://www.esnips.com/doc/27a5b2cc-5b04-4d82-bb7a-ae6a200e1d39/x264_x86_r667b)
(if you want to try it :))

It was compiled with the rev. 667b source code from Cef's build site. I'm finding that this version is faster then the current Cef builds. (if only by a little bit, 34 sec. compared to 36 sec. on a fast 1:30 file with a fast 1 pass encode, probably a greater speed difference would be noticeable on a larger encode, but I'll take any more speed I can get no matter how little on x264).

It was also compiled with march=i686 (for all you people who don't have an sse cpu) and with mtune=pentium3 (which would enable sse for people who have it) which pretty much make the build all around compatible with almost any cpu and allows newer cpu's to take advantage of sse.

Like I said, I just like building things with the newer GCC since I find things faster and sometimes more stable.

I can't see any downsides to using the newer GCC 4.2.1 (thanks to cc979 ;)) I find it more stable, optimizations are better (no -frename-registers), etc..

Thanks and Enjoy, cya :)

P.S.
Cflags were:
-ffast-math -fomit-frame-pointer -march=i686 -mtune=pentium3 -mfpmath=387 -and any other standard flags
additional ldflags:
-Wl,-O1 -Wl,--sort-common

[akupenguin]

The reason I don't like GCC 3.4.x is because when you use -O3, it turns on -frename-registers (or whatever it's called :p). That option is useless (IMO) (but it can be useful on x86_64), not to mention the newer GCC versions are better at optimizations.
Why should you care whether any given option is enabled? The only question is which compiler generates faster code.
Anyway, if it really bothers you, then the obvious solution is -O3 -fno-rename-registers.

It was also compiled with march=i686 (for all you people who don't have an sse cpu) and with mtune=pentium3 (which would enable sse for people who have it) which pretty much make the build all around compatible with almost any cpu and allows newer cpu's to take advantage of sse.
Either the binary contains sse or it doesn't. gcc doesn't generate runtime cpu detection, so any binary that contains sse won't run on pre-sse computers. -march determines what instructions are available, -mtune only determines scheduling.

[TheRyuu]

Why should you care whether any given option is enabled? The only question is which compiler generates faster code.
Anyway, if it really bothers you, then the obvious solution is -O3 -fno-rename-registers.

I care what I compile my programs with, don't you?
I also care because -frename-registers is pretty much useless on anything but x86_64, and it bloats code IMO (would be about the same speed, sometimes there might be a slight gain, but still, IMO, not worth it and could be counter productive too)
It was eventually taken out of -O3 also although thats besides the point. :p

The real purpose of the post wasn't to tell my personal opinions on compiler options though, it was to show that a newer GCC is better at optimizing x264 then the older (mingw 3.4.4) one.

Either the binary contains sse or it doesn't. gcc doesn't generate runtime cpu detection, so any binary that contains sse won't run on pre-sse computers. -march determines what instructions are available, -mtune only determines scheduling.

Thats what I meant I guess. It was build for i686 but is optimized for the pentium3, correct?
That should allow someone with an i686 cpu to run it, but also allow someone with a pentium3 or above to use the extra optimizations, right? (I don't fully understand how -march+-mtune really work together yet I guess)

Just sharing some experience building it thats all. :)

[akupenguin]

It was build for i686 but is optimized for the pentium3, correct?
That should allow someone with an i686 cpu to run it, but also allow someone with a pentium3 or above to use the extra optimizations, right?
Right.
A given instruction takes different numbers of cycles on different cpus. A given computation can be expressed many ways, using different combinations of instructions.
Of all the alternatives that would run on the cpu specified by -march, gcc picks the alternative that's fastest for the cpu specified by -mtune.

Example of how -march can help: -march=pentium4 goes through contortions to avoid register-to-register mov instructions, because mov is really slow on pentium4. So if it needs a value in 2 registers, it loads it twice from memory, whereas most other cpus would load it once and then mov to the other register.

The point I was correcting is: -march=i686 -mtune=pentium3 doesn't use sse because i686 can't run sse, even if sse would be the fastest way to implement something on pentium3.

Nitpicking your cflags: -mfpmath=387 is redundant. Not only is it the default, it's also the only possibility given that sse is disallowed.

[burfadel]

I've built x264 using a newer GCC 4.2.1.

The reason I don't like GCC 3.4.x is because when you use -O3, it turns on -frename-registers (or whatever it's called :p). That option is useless (IMO) (but it can be useful on x86_64), not to mention the newer GCC versions are better at optimizations.

You can get it here (rev667b x86). (http://www.esnips.com/doc/27a5b2cc-5b04-4d82-bb7a-ae6a200e1d39/x264_x86_r667b)
(if you want to try it :))

It was compiled with the rev. 667b source code from Cef's build site. I'm finding that this version is faster then the current Cef builds. (if only by a little bit, 34 sec. compared to 36 sec. on a fast 1:30 file with a fast 1 pass encode, probably a greater speed difference would be noticeable on a larger encode, but I'll take any more speed I can get no matter how little on x264).

It was also compiled with march=i686 (for all you people who don't have an sse cpu) and with mtune=pentium3 (which would enable sse for people who have it) which pretty much make the build all around compatible with almost any cpu and allows newer cpu's to take advantage of sse.

Like I said, I just like building things with the newer GCC since I find things faster and sometimes more stable.

I can't see any downsides to using the newer GCC 4.2.1 (thanks to cc979 ;)) I find it more stable, optimizations are better (no -frename-registers), etc..

Thanks and Enjoy, cya :)

P.S.
Cflags were:
-ffast-math -fomit-frame-pointer -march=i686 -mtune=pentium3 -mfpmath=387 -and any other standard flags
additional ldflags:
-Wl,-O1 -Wl,--sort-common

I tried it, it was slightly slower on my computer by a few percent than the 667b build made by Cef. I have a Core 2 Duo E6600.

I believe Cef optimised the builds for the Core 2 Duo himself, it just goes to show different compiling optimisations work better for different CPU types :)

[TheRyuu]

Right.
A given instruction takes different numbers of cycles on different cpus. A given computation can be expressed many ways, using different combinations of instructions.
Of all the alternatives that would run on the cpu specified by -march, gcc picks the alternative that's fastest for the cpu specified by -mtune.

Example of how -march can help: -march=pentium4 goes through contortions to avoid register-to-register mov instructions, because mov is really slow on pentium4. So if it needs a value in 2 registers, it loads it twice from memory, whereas most other cpus would load it once and then mov to the other register.

The point I was correcting is: -march=i686 -mtune=pentium3 doesn't use sse because i686 can't run sse, even if sse would be the fastest way to implement something on pentium3.

Nitpicking your cflags: -mfpmath=387 is redundant. Not only is it the default, it's also the only possibility given that sse is disallowed.

Thanks.
Adding sse wouldn't really matter anyway since most of it is in asm though right?

Whatever though.
New build here. (http://www.esnips.com/doc/a1d6e08a-0dc8-4baa-8d9b-ee0f3a1cee07/x264_x86_667b_2)

[sampath]

is there a bug in recent vfw build of cefs. It gives error messeage : second pass has more frames than first pass 331>328 .but i didn't change frames at passes?$$

x86 vfw r677 on virtualdub1.6.19

i didn' encounter this on the snow_xmas vfw build

[akupenguin]

Symptom of the fact that vfw is incompatible with B-frames or x264's threads, whichever of those you're using. No, it can't be fixed.

[daWsOn_s]

Hi I'm now trying the new 667 Cef release and I've discovered an acceleration in enconding of about 40% , is that general?

[Terranigma]

Cef, do you plan on updating to rev.671, or do you not find the current crop of changes significant enough?

[morph166955]

the only changes since r665 have to do with the configure script and a few small build options, nothing that should change the binary in any way (theoretically). So what I won't speak for Cef, I doubt hes going to update it since there really is no reason based on the changes that were done.

[Sharktooth]

yep, 667 and 671 bins would be identical. however this is x264 dev thread where ppl should talk about development, not about bugs, not about vfw (that's no longer mantained) and not about builds.
thanks.

[rbt01]

can anybody give me a suggestion, i can't use the long option, such as : --pass 1 --bitrate 2000

[JarrettH]

maybe look at the megui x264 profiles for command line examples

[Vesi]

I have downloaded megui from sourceforge and got all the updates, i want to do xvid rips and x264, so my question is that i have read this thread http://forum.doom9.org/showthread.php?t=89979.
and i'm using HP 3200+ (2,20 GHz) with 1GB DDR memory. do i need those pathes and file which made by sharktooth?

[Sharktooth]

no. x264 and xvid are already included in megui updates.

[Vesi]

no. x264 and xvid are already included in megui updates.

Thanks alot Sharktooth. I really appreciate your work.
@ one thing more what i was thinking that H264 give the highest quality.would it be a good idea to rip with A/R 720*320 for 1CD 650MB with good quality source? thanks

[akupenguin]

Initial review of the instructions to be included in SSE5 (http://developer.amd.com/sse5.jsp). Note that I'm only discussing the functionality, I have no idea of the speeds of the instructions yet. There were some SSSE3 instructions that looked interesting, and reduced the instruction count of some functions, but when run on a Core2 turned out to be much slower than the equivalent multiple SSE2 instructions.

First, discard all the floating-point instructions, because video codecs don't use floating-point.

PCMOV: generally useful anywhere the scalar version of the algorithm has branches, e.g. deblocking.
PCOM*: might save a MOV or a negation over PCMP*, if one wants a predicate other than EQ or LE.
PPERM: zigzag scan in 2 instructions. (finally equivalent to altivec)
PHADD*: useful in all the pixel comparison functions, especially satd. (note that these aren't the same as SSSE3's PHADD*)
PMADC*: SSD and SSIM.
PMAC*: DCT (but not HCT).
PSHLB: I have occasionally wanted this. the per-element shift amount isn't important though, only that there wasn't previously any byte shift instruction.

[SpAwN_gUy]

apparently.. i've found whole bunch of patches at Cef's place on x264.nl...

can anybody give an advice.. which should be applied, and which are not so usefull?
(i'm going to supreme quality ;) ... speed does not matter)

[Audionut]

can anybody give an advice.. which should be applied, and which are not so usefull?
(i'm going to supreme quality ;) ... speed does not matter)


Current Patches, Where to get them, How they affect speed/output
http://forum.doom9.org/showthread.php?t=130364

[LigH]

Excuse my non-developer based question...

A user in the german doom9/Gleitz board spotted news about the evision 683, implementing quant_2x2_dc for Altivec; despite the fact that Altivec is irrellevant for (intel compatible) PC owners, he just wondered why he never saw any "2x2" option in MeGUI...

Could you briefly explain how far the distance is between quant_NxN[_dc] functions and macroblock partitions (with or without DCT)?

[Manao]

In intra macroblock, once the 4x4 DCTs are made, the DC of each of the DCT are retransformed with another DCT. For luma, there are 16 blocks so it's another 4x4 DCT. For chroma, there are only 4 4x4 blocks, so it's a 2x2 DCT. It's done only on DCs coefficients.

[LigH]

This abbreviation is too short to search for, sorry...

DCT = Discrete Cosine Transform;
DC = ?

[Manao]

The DC is the DCT coefficient that represents the average of the untransformed block. It is usually opposed to the ACs, which are the remaining coefficients (those that represent the variations in the block).

If I am not mistaken, the names come from electricity (Alternative Current / Direct Current).

[neuron2]

This abbreviation is too short to search for, sorry... Use google and put site:forum.doom9.org after the search term(s). E.g.:

dc coefficients site:forum.doom9.org

@Manao

You are not mistaken.

[LigH]

Wonderful... Indeed, I remember AC/DC, just didn't expect such a similarity. ;) - Now I understand quite well.

BTW, I was quite surprised by the rating of AltiVec in the german Wikipedia article ("ignored and underestimated"). Nice to see that a few developers try to use all means of optimizations, even if only few people may get an advantage.

Fun and success! :cool:

[mroz]

Actually you can get useful info from just searching on dc coefficients (at least with Google), which is odd as I thought it discarded two character words from the search string.

[Adub]

No, just the common ones like "to" or "of".

[Inventive Software]

Feature request that'll get me shot at.... implement interlaced and esa and interlaced and direct=temporal, as per the errors I got when I tried to encode interlaced to interlaced with x264.

[Dark Shikari]

Feature request that'll get me shot at.... implement interlaced and esa and interlaced and direct=temporal, as per the errors I got when I tried to encode interlaced to interlaced with x264.I could easily implement ESA and Interlaced simply by having it swap to the standard (and mindbogglingly slow) ESA algorithm instead of the SEA algorithm that x264 currently uses :)

[Inventive Software]

You could keep the current one for progressive input, and switch it when the user flags interlaced. :) I just thought I'd mention it as it flagged up when I encoded interlaced content.

It's just as well it doesn't work as I'd like it to... interlaced decoding seems to be broken with ffdshow and interlaced x264 encodes. :(

[nm]

It's just as well it doesn't work as I'd like it to... interlaced decoding seems to be broken with ffdshow and interlaced x264 encodes. :(
You'll need to use mod-32 height. That's a limitation in libavcodec's decoder.

[Inventive Software]

Bugger... did wonder what was wrong with it. Thanks.

EDIT: Just done some quick calcs, and I am using mod-32 height... 720x576. You sure that's not mod-32 width as well as height?

[Sagekilla]

Bugger... did wonder what was wrong with it. Thanks.

EDIT: Just done some quick calcs, and I am using mod-32 height... 720x576. You sure that's not mod-32 width as well as height?

720 / 32 = 22.5, it's the width that's the problem.

Edit: Whoa, just realized it's not necessarily mod32. 720 / 16 = 45, works fine.

[Inventive Software]

Sussed that one, and I tested with a binary of ffplay, and it's ffdshow that's the problem.

EDIT: It's also my idiotness that didn't update ffdshow from rev 1620 to rev 1656! Cos that fixed the problem! Doh! :o

[akupenguin]

Just so that anyone reading doesn't get funny ideas: width does not need to be mod32.