x264 development

[DVD Logic]

Ok. Thanks!

Anyway, just interesting where I can find detailed and accurate description of B-Pyramid for x264?

Regards,
Valery.

[burfadel]

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious :)

[Dark Shikari]

Looking at the code for 4:4:4 encoding support, it looks like a fair amount of code for normal encoding has changed too. I'm just curious about effect these changes will have on ordinary YV12 encoding?
Will it be:
- None, as I misinterpreted what I read?
- No differences in speed or output
- Slight speed difference but same output?
- Same speed but slightly different output?
- Slightly different speed and output?

I realise a change in output may somewhat equate to different speed, I was more referring to 'slight' as being slightly noticeable, not 0.1 percent!

Just curious :)Output should not change at all; this is part of my regression-testing.

It will probably be marginally slower. I templated all the parts of the code that had significant slowdowns (CABAC, macroblock_encode) to avoid significant speed loss.

[burfadel]

I guess marginally slower and a slight change in output wouldn't matter as long as its not a drop in quality :) Its quite an impressive amount of code! If it is a little slower, would probably be a good time to release any speed improvements there might be at the same time to help cancel it out. I'm just thinking on the spot here of course, but I'm thinking if people notice a slowdown this thread might get bombarded! Alternatively, if there are any quality tweaks/improvements, that would also help to cancel peoples opinions :)

That said, thankyou for the work and effort put into x264, its easy to see its a great quality program (the code, quality and speed of results etc) and I personally don't think there are too many programs that would even come close to x264's all-round level when you consider every factor of the program.

[DVD Logic]

This isn't actually answering your question, but for Blu-Ray you shouldn't care much about that - you should just follow the information in the picture_timing_sei for muxing.

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help, dear developers, what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

[kieranrk]

Not all encoders set correct PTS value to picture_timing_sei field. We calculate DTS and PTS "manually", but with B-pyramids we can't calculate accurate value. Would you please help what algorithm can detect that B-pyramids are present in AVC. As we can't find any info about B-pyramids in H264 specification.

Don't do this...If the encoder does not set correct values then you should fail and tell the user to encode using Blu-Ray settings. Silly hacks like this will not work properly as seen by tsmuxer.

[DVD Logic]

tsMuxer works fine with B-pyramids.

[kieranrk]

tsMuxer works fine with B-pyramids.

The hacks it uses fail with pulldown though.

[dstln]

I think I've told this to you guys before when I had similar problems, but directly encoding from .avi fraps is again broken in x264. Now it even manages to crash x264 after indexing :O Using avisynth as the intermediary instead of ffms/lavf again works fine. I'm not sure of exactly the point that it's crashing when I try directly.

Using the latest x264 along with fraps 3.40. I'm guessing fraps updates their codec fairly regularly...

[Snowknight26]

Works fine here using latest x264 revision/Fraps. Update your Fraps.

[Chikuzen]

@dstln
Lavf was broken immediately after r2008 was released.
http://forum.doom9.org/showthread.php?p=1508934#post1508934

After a day, this bug was fixed, and x64 binary redistributed by x264.nl was replaced.
Download x264.exe again, and test it.

[dstln]

Thanks for the replies, I'll try again. Guessing I got the early one.

edit: still happening after updating x264 (ffms appears to start), I'll try recording with newer fraps when I get a chance. It looks like they've fixed some recording bugs recently.

[Atak_Snajpera]

How to enable multithreaded decoding in Lavf ? Unfortunately ffms is useless for .mts so I can't use it.

[Chikuzen]

How to enable multithreaded decoding in Lavf ? Unfortunately ffms is useless for .mts so I can't use it.

http://komisar.gin.by/old/2008/p/x264_demuxer_threads.1995.diff

[Atak_Snajpera]

--demuxer-threads <integer> Force a specific number of threads for demuxer (lavf, ffms)

Thanks

[upyzl]

Excuse me
r2037 is released right now on git.videolan.org
commit 9977b595fb7591e3616fa98677baf6e84e0f7029 r2036
Author: Dan Larkin <danielhlarkin@gmail.com>
Date: Wed Jul 13 12:45:23 2011 -0500

Add --subme 11, which disables all early terminations in analysis
Necessary for a future trellis mode decision/motion estimation patch.
Also add the slowest presets to the regression test.
Does it mean that subme 11 is incomplete now?

and
commit 3765dfdd27bd206a800a61c38c0a6639d762db3b r2022
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Jul 15 15:06:37 2011 +0400

Fix use of deprecated libavcodec functions
Replace avcodec_open with avcodec_open2. Now requires libavcodec 53.6.0 or newer.

x264.nl builds
x264 -V
x264 0.116.2037 f8ebd4a
(libswscale 2.0.0)
(libavformat 53.3.0)
(ffmpegsource 2.15.4.1)
built on Jul 23 2011, gcc: 4.5.3 (x86_64.multilib.Komisar)
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 3 or later
maybe lavf should be updated?

[Boulder]

I don't think it's incomplete itself. It seems to be enabled if you set --preset placebo, at least according to the full help.

[Selur]

small question regarding "--subme 11": Does it like --subme 10 require trellis=2 and aq-mode>0, or does it require something else?

[LoRd_MuldeR]

small question regarding "--subme 11": Does it like --subme 10 require trellis=2 and aq-mode>0, or does it require something else?

787 if( h->param.analyse.i_subpel_refine >= 10 && (h->param.analyse.i_trellis != 2 || !h->param.rc.i_aq_mode) )
788 h->param.analyse.i_subpel_refine = 9;

[Selur]

Thanks! :)

[Snake91]

How much gain can we get from subme11? And what about future trellis (mmm maybe it's too early:p)?

[Selur]

it's a placebo setting, so probably nothing visible to the human eye. ;)

[Target Practice]

How much gain can we get from subme11?I did a test: subme 10 (http://www.mediafire.com/file/35y7y4t25kr8jaj/subme10.mkv), subme 11 (http://www.mediafire.com/file/vm62iud3wgb76q7/subme11.mkv)

http://img685.imageshack.us/img685/6130/subme11psnrdifference.png

[Snake91]

Thanks ;), imho only for video maniacs! (and with an ancient q6600 I can't join the party:p)

[upyzl]

@Boulder
Yes, it is available...maybe new Trellis (will)do improve it

@Target Practice
use SSIM is better...because both subme 10 & 11 need AQ on

This is my draft test

Clip A Clip B
1 2 3 Avg fps SSIM 1 2 3 Avg fps SSIM
umh+subme10 29.70 29.66 29.72 29.693 0.9942365 17.00 16.99 17.01 17.000 0.9742235
umh+subme11 18.59 18.59 18.60 18.593 0.9943463 11.06 11.06 11.07 11.063 0.9745654
tesa+subme10 24.22 24.03 24.20 24.150 0.9943326 12.79 12.81 12.81 12.803 0.9745798

paras: --seek 500 --frames 900 --vf resize:768,432 -p2 --stats "tmp.stat" -B 500 --me umh/tesa -t 2 -m 10/11 --tune ssim --ssim

[jpsdr]

In one of the last updates of x264, there is subme=11 added for a future treillis patch.
Is it possible to have some informations about this future patch ?
(Is it a new treillis mode or improvement of actual mode ? What average % improvement can be achieved ? A rought ETA, are we talking about weeks or months ?)

[cyberbeing]

The future trellis patch is Dan Larkin's (dlarkin) Google Summer of Code Project, Trellis Motion Estimation (http://wiki.videolan.org/SoC_2011/x264_Trellis_Motion_Estimation). If you are curious about specifics, you could probably go on IRC and ask him.

[mandarinka]

Currently, he's probably on the verge of madness from all the work though, because the program is near the finish. IMHO it's better to stay patient here at the forums, and don't hamper the actual development being done.

[schweinsz]

Does the current x264 support 10bits encoding for interlace?

[kieranrk]

Does the current x264 support 10bits encoding for interlace?

Yes it does.

[rallymax]

Hi all,
with the following line I'm getting playback at half speed from my bgra4444 src.
In Windows Media Player it plays at half speed but the progress bar is at 100% after the first frame.
In Adobe Premiere CS5 it will only play the first 2 frames.

I can't work out how to fix it.

Any pointers greatly appreciated. :thanks:
(I've tried -tff etc and it's the same.)

x264 --quiet --profile main --stdin raw --input-csp bgra --input-res 720x480 --fps 29.970 --level 4.1 --bitrate 8000 --vbv-maxrate 9000 --sar 40:33 -o 480p29.97.264 -

My source is a raw stream of BGRA4444 (8bit). Unfortunately I can't work out how to put that into a file so I can't post an example. But I can tell you it's the x264 example output with a timecode burnt into it for 10 seconds.

One again, thank you for pointers as to why it's wrong.

Here is the output MediaInfo
General
Complete name : M:\My Videos\480p29.97.264
Format : AVC
Format/Info : Advanced Video Codec
File size : 11.9 MiB

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Bit rate : 10 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Bits/(Pixel*Frame) : 0.965
Writing library : x264 core 116
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=tff / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=10000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

[J_Darnley]

My source is a raw stream of BGRA4444 (8bit). Unfortunately I can't work out how to put that into a file so I can't post an example. But I can tell you it's the x264 example output with a timecode burnt into it for 10 seconds.

You're piping it into x264, redirect into a file instead. Something like: whatever > file

As for the too slow problem, are you setting the right framerate?

[JEEB]

Due to the two patches I got onto le x264 development tree, I'd like to post a test build that should help us see how badly I failed: It contains the 'color matrix and range from lavf/ffms' as well as the 'use simple bit shift for 8bit->x264 output bitness conversion in case of limited range' patches put onto 2074. Enjoy.

32bit Build, 10bit output (http://x264.fushizen.eu/files/dev/2074_range_matrix_and_8to10.7z)

Disclaimer: The latter patch is knowingly unoptimized and I was surprised it went through as quickly as it did to the development repo, as it isn't templated yet. Also, the limited range higher bit depth dithering algorithm was shamelessly taken off of 06_taro's patch, so I have no idea if it's completely correct (I had pinged irock about it, but I have yet to have gotten any response on that). The limited range 8->output bit depth conversion does now use a simple bit shift, though -- which should be the correct way. Thus, I am enthusiastic in hearing of results with this fix in place.

Edit: Binary overwritten by a newer one, completely let the high bit depth -> 16bit converter slip my mind in input/raw.c .

[mandarinka]

Cool! Thanks.

[rallymax]

You're piping it into x264, redirect into a file instead. Something like: whatever > file

As for the too slow problem, are you setting the right framerate?

OK I recompiled my program to pipe the raw stream of BGRA4444 to a file instead of to x264 and then used that file as the input to x264. I get the same result.
I also confirmed that my output loop was called 300 times (30 fps x 10 seconds) which is correct.... so it begs the question with the above command line (specifically --fps 29.970) why does it play back at half speed in Windows Media Player and in Premiere CS5.5 it detects it as being 1 frame long????
I'm starting to think it is a .264 decoder thing - I'll use something to encapsulate it in a mp4 container (coz x264 doesn't support that right???)

[nm]

I'm starting to think it is a .264 decoder thing

Definitely! We didn't even imagine you were trying to use the elementary stream directly.

I'll use something to encapsulate it in a mp4 container (coz x264 doesn't support that right???)

x264 does support MP4 output when built with GPAC and pretty much all the binaries people are sharing do have that support. If you use a self-compiled version and don't want to go through all the trouble, just use MP4Box.

[G_M_C]

I see that 4:2:2 has been comitted recently (http://repo.or.cz/w/x264.git), but no post in the 'development' thread yet. This post is to let everybody wanting to work with 4:2:2 know.

But also for a short question of mine, on 10bit: When i use an 8-bit source on 10-bit x264. When does x264 do the converting from 8-bit to 10-bit ? Is that done before the filtering stage or after ?
( ex:8bit input -> conversion to 10bit -> resize -> encoding stage )

[aegisofrime]

I saw that XOP and FMA support has been added.

I'm curious as to how much of a speedup these instruction sets provide. I'm building a new encoding rig soon, and such information would be helpful as to whether to get an i7-2600K now or hold out for Bulldozer. Given AMD's recent habit of delaying, I'm not exactly sure when it will be launched.

According to this supposed marketing slide from AMD (http://img.donanimhaber.com/images/haber/amdfxpressdeck_12a_dh_fx57.jpg), Bulldozer is only slightly slower than the i7-2600K. I'm wondering if the new instruction set support will change this, and if so by how much.

Thanks!

[MasterNobody]

But also for a short question of mine, on 10bit: When i use an 8-bit source on 10-bit x264. When does x264 do the converting from 8-bit to 10-bit ? Is that done before the filtering stage or after ?
( ex:8bit input -> conversion to 10bit -> resize -> encoding stage )
After. Depth filter is the last in chain (before sending data to libx264).

[G_M_C]

After. Depth filter is the last in chain (before sending data to libx264).

K, thx :)

But doesnt conversion to 10-bit, before resizing theorethically lead to better quality ?

[sneaker_ger]

The problem is probably that all of the filters are 8 bit only.

[Soliloquy]

as to whether to get an i7-2600K now or hold out for Bulldozer.

I don't think AMD will be beating intel anytime soon, so the 2600K will probably be your best bet if you want the faster cpu. I don't have any hard data to back that up though.

[aegisofrime]

I don't think AMD will be beating intel anytime soon, so the 2600K will probably be your best bet if you want the faster cpu. I don't have any hard data to back that up though.

Do click on the slide that I linked to.

Granted that it is a marketing slide, but if true then it means that Bulldozer is awfully close to 2600K.

I'm guessing that the x264 developers probably have access to a Bulldozer CPU. I'm hoping they can release performance details after the NDA is lifted :p

[Dark Shikari]

Indeed, I have SSH access to a bulldozer. Unfortunately I can't say much~

[LigH]

Indeed, I have SSH access to a bulldozer.

LigH imagines the consequences if that was not a CPU but road-paving equipment... :p

[hajj_3]

nice to see that you have got your hands on a bulldozer cpu. Will there be new optimisations for bulldozer within a few weeks of bulldozer's release?

Can't wait to see the speed of bulldozer compared to intel.

I saw some benchmarks yesterday that show the highend bulldozer 8 core (£200) is about the same speed with x264 as the highend intel core i7 990x which is £800. It is supposed to be around 20% faster than the core i7 2600k SKT1155 (£240) too.

Have you got your hands on the bulldozer 16 core server cpu too?

[Selur]

little question:
Since x264 supports 4:2:2/4:4:4 is there anything missing to make x264 High 4:2:2/4:4:4 compatible? If not will there be a High422/High444 '--profile' option in the near future?

Cu Selur

[sneaker_ger]

Currently 4:2:2 will always be Hi422P and 4:4:4 always be Hi444PP AFAIK, to control you set --output-csp iXXX. I don't think it currently offers Hi444PP for 4:2:2 content. :confused:

[Midzuki]

LigH imagines the consequences if that was not a CPU but road-paving equipment... :p

The *compression-efficiency* would be much higher, granted. :D

[Ice009]

I'm building a new encoding rig soon, and such information would be helpful as to whether to get an i7-2600K now or hold out for Bulldozer. Given AMD's recent habit of delaying, I'm not exactly sure when it will be launched.


I want to build an encoding rig too with either a 2600K or Bulldozer 8150. I'm in no hurry though so I'll wait until Bulldozer is out before making a decision. Are you in a hurry? If you're not, you may as well wait and see how Bulldozer performs.