x264 development

[shon3i]

But that wasn't even my point - it's that we were talking about the bluray-compat option which limits ref frames to a maximum of 6. period. We shouldn't mix things up to prevent confusion. Selur already was. But maybe I'm just splitting hairs...I told you several times it work in conjunction with other parameters, and there is no confusion if i say that bluray compat will limit up to 4 references with 1080 L4 or 4.1, that will happen, that is whole point.

And in addition to Selur post

bluray compat will enable pic-struct for interlaced, fake-interalced, pulldown, and not for progressive. Because that required by BD specs.

[Selur]

bluray compat will enable pic-struct for interlaced, fake-interalced, pulldown, and not for progressive. Because that required by BD specs.
Oh, I thought that interlaced, fake-interlaced and pulldown had already enforced pic-struct before bluray compat was around, but it could be that I just did that in my code. :)

Cu Selur

[shon3i]

Oh, I thought that interlaced, fake-interlaced and pulldown had already enforced pic-struct before bluray compat was around, but it could be that I just did that in my code. :)

Cu Selur
It's been mandatory for interlaced and pulldown, but for fake interlaced not. Now situation stay same except for fake interlaced in conjunction bluray compat use pic-struct, because is need for blu-ray. fake interlaced itself not use pic-struct because have other cases where need to signal frame differently.

[Selur]

Thanks for clearing that up. :)

[Mug Funky]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.

i encoded a 2000 frame 3:2 video (some old anime that was on the system) without IVTC using --tff on the regular compile and Simon Horlick's git. i then IVTC'd the result and PSNR'd them against the source (with IVTC).

i got an overall PSNR increase of just under 2dB. not too shabby.

i couldn't really see any difference, but this monitor is crap.

take it with a grain of salt of course :)

[Sagittaire]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.

i encoded a 2000 frame 3:2 video (some old anime that was on the system) without IVTC using --tff on the regular compile and Simon Horlick's git. i then IVTC'd the result and PSNR'd them against the source (with IVTC).

i got an overall PSNR increase of just under 2dB. not too shabby.

i couldn't really see any difference, but this monitor is crap.

take it with a grain of salt of course :)


2 dB is actualy the difference bettween MPEG4 ASP and MPEG4 AVC. MBAFF is extremely high gain performance for interlaced source!

it's Blu Ray compliant?

[Mug Funky]

well, that's on the first source i checked.

i'm going to play a bit more in the coming days and use some more realistic sources and see how it goes.

my methodology is probably full of holes, but of course it's a promising result either way.

[thegame]

Hi, I just want to apologize up front if this question seems pretty dumb LOL, but how in the world do you open and look at your statsfile? and should there be a statsfile and mbtree file? or are these the same thing? I try to open with notepad and all it does is freeze, I am still fighting what I asked about on page 69 regarding the qpfile and I-Frames, I did this and my file encoded but when authored in up most chapters were still off, there HAS to be a way to get these chapters to place correctly.

Thanks in advance

[laserfan]

Hi, I just want to apologize up front if this question seems pretty dumb
It's not dumb, but neither is it a topic for this developers thread. Try starting a new thread in the Blu-ray Authoring subforum and maybe you will get more looks/responses.

If you do, you'll have to provide more details about what exactly you are trying to do (than you have so far).

[thegame]

Sorry about posting here, the reason I did is because a few pages back(page 69) I was asking about the qpfile and forced I-Frame placement and got help on that and I asked how could I verify the placement and was told to look at the statsfile, well as I asked above, how in the world do you open it to view it?

http://forum.doom9.org/showpost.php?p=1490953&postcount=1371

[J_Darnley]

You should be able to open the stats file in any text editor. Perhaps it is too large for notepad, use something better. You won't be able to see much in the mbtree file because it is a binary file.

[ajp_anton]

i just tried out the recent MBAFF changes that were committed.

preliminary tests show positive results.
How recent? Can't find any MBAFF-related in the x264.nl changelog.

[sneaker_ger]

How recent? Can't find any MBAFF-related in the x264.nl changelog.

He's probably talking about the dev git (https://github.com/DarkShikari/x264-devel/commits/master), but it looks like the mbaff additions got removed again.

[upyzl]

About r1944

why not turn off psy-rd <RD:Trellis> when set subme<6 or trellis=0 as before?
I think that's the right info for users... even I want to advise deleting deadzone info when used trellis=2 at the same time...

and also about merange on umh/esa/tesa (http://forum.doom9.org/showthread.php?p=1497461#post1497461)
maybe 4~256 is a good valid range

[MasterNobody]

About r1944

why not turn off psy-rd <RD:Trellis> when set subme<6 or trellis=0 as before?
I think that's the right info for users... even I want to advise deleting deadzone info when used trellis=2 at the same time...
Did you read the commit message (this part "Also avoid encoder_reconfig turning off psy_rd/trellis.")? That was made because --subme and --trellis can be changed later by reconfiguration (for example --zones) and so if user explicitly didn't disabled them they should be enabled. Btw internally they of course disabled with subme<6 or trellis=0 but parameters not reseted. As for deadzone they still have effect even with --trellis 2 also again reconfiguration allow changing trellis.
and also about merange on umh/esa/tesa (http://forum.doom9.org/showthread.php?p=1497461#post1497461)
maybe 4~256 is a good valid range
It would be 4..1024 range (https://github.com/DarkShikari/x264-devel/commit/492f744a97ab1a6d796c9cecf1efa8a90d64e3b4)

[upyzl]

@MasterNobody

Thanks very much for the explanation
Now I understand...

[MrVideo]

renders '--open-gop' parameters obsolete:


It makes them a little more than obsolete. It causes x264 to fail with an error that it can't open the option. Because --open-gop no longer has options, the very next word in the line is considered the file to open because it doesn't start with --.

I got caught with that and couldn't figure out why it couldn't open "none" when it was an option for --open-gop. I removed "none" as a test and discovered that it now worked.

It would have been nice if x264 still looked for a potential option and if so, spit out a warning that it is now obsolete and reference --bluray-compat in the warning.

After the failure, I started digging and a posting over on Doom10 pointed to this thread. That resulted in my changing some more stuff in my CLI (adding the --bluray-compat option and removing two others).

[MrVideo]

Below is the CLI I use for encoding video so that I can edit it with VRD:

x264 --pass 2 --profile high --level $LEVEL --bitrate $BITRATE --ref $REF \
--deblock 1:-1:-1 --me umh --subme 10 --psy-rd 1.00:0.15 --merange 24 \
--trellis 2 --deadzone-inter 21 --deadzone-intra 11 --fast-pskip \
--threads 12 --slices 4 --nr 0 --bframes 3 --b-pyramid strict \
--b-adapt 2 --b-bias 0 --direct auto --weightp 0 --keyint $KEYINT \
--min-keyint 1 --scenecut 40 --rc-lookahead 60 --ratetol 1.0 \
--qcomp 0.60 --qpmin 10 --qpmax 51 --qpstep 4 --cplxblur 20.0 \
--qblur 0.5 --vbv-maxrate $MAXBITRATE --vbv-bufsize $BUFSIZE \
--ipratio 1.40 --aud --nal-hrd vbr --open-gop $INTERLACED \
--sar $SAR --qpfile "${DIRNAME}/${NAME}_qpfile.txt" \
--input-res $RES --stats "${DIRNAME}/${NAME}.stats" \
--output "${DIRNAME}/${NAME}.264" \
"tmp.fifo.yuv"

If the video is interlaced, the $INTERLACED variable will be set to --tff.

Before the recent changes, the --open-gop had none as its option.

What the above did for me is create IDR frames at the locations where I frames are normally placed and at locations set in the qpfile.

But now, instead of IDR frames, it is only I frames.

How do I get IDR frames back? Why was the functionality of IDR frame generation removed, or was it an error in the first place and I stumbled upon it?

[sneaker_ger]

If you use "K" it will depend on your open-gop setting - you can still force "I" or "i". Or does this not work for you?

/edit:
To make sure I get you straight:
1.) Before, you had open-gop deactivated ("--open-gop none")
2.) Now you have open-gop activated ("--open-gop")

and you're wondering why x264 behaves differently?

[MrVideo]

If you use "K" it will depend on your open-gop setting - you can still force "I" or "i". Or does this not work for you?

/edit:
To make sure I get you straight:
1.) Before, you had open-gop deactivated ("--open-gop none")
2.) Now you have open-gop activated ("--open-gop")

and you're wondering why x264 behaves differently?

Yes. Why, because the rules of the game have changed in the middle of the game. There isn't a changelog with the source distribution. Is there a place that lists major operational changes like this and explains what the changes affect and what the CLI settings should be? Maybe a separate thread, that doesn't allow discussion, that lists functional changes to the options and fully explains the previous setting combinations and what the new settings are to match the old.

Doing a little digging, a posting over on Doom10 (think it is a page back here as well) indicates that without --bluray-compat the --open-gop acts as it was --open-gop cbrHD under the old code. But, cbrHD was not an option, as they were none, normal and bluray. Because the posting didn't make sense, it was shoved aside.

While the developers understand what is going on with the changes, we poor users are sorta left out in the cold. I'd like to see a dedicated thread, as described above, as that would really help us users.

[sneaker_ger]

Yeah, such a place does not exist.
The only thing you can do is to watch the changelog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) every time a new version gets released.

[Astrophizz]

The mailing list sends out batch changelogs with commentary.

[MrVideo]

The mailing list sends out batch changelogs with commentary.

Thanks. Where does one sign up?

[Astrophizz]

Thanks. Where does one sign up?

http://mailman.videolan.org/listinfo/x264-devel
A small warning though. When a new update batch is pushed out every couple of weeks, you'll get an email with a newsletter summarizing what changed plus and email for each change.

[MrVideo]

A small warning though. When a new update batch is pushed out every couple of weeks, you'll get an email with a newsletter summarizing what changed plus and email for each change.

That's OK. It will be a drop in the bucket, compared to the rest of what I get on a daily basis.

Thanks for the info.

[3ds]

If i see it right, the minimal encoding arguments for 1080p23.976 / 1080p24 bluray compatibility are :
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 24 --slices 4

But why must i add vbv-maxrate, vbv-bufsize, keyint and slices? x264 can calculate them from the given resolution/fps, isn't it?

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

[LigH]

Btw. the --fullhelp about --bluray-compat should list the parameters that would be set (e.g.: http://forum.doom9.org/showthread.php?p=1493513#post1493513 )

:goodpost: I agree.

[nurbs]

Even knowing that your target is Blu Ray there are two possible vbv values for 1080p. This also affects the number of slices. Depending on that there are also two different keyint parameters that are valid. Just by that commandline x264 can't know which of the two you want. See the Blu Ray encoding sticky.

[sneaker_ger]

Is there any reason to use --b-pyramid strict outside of Blu-Ray? I'm asking because its parameters didn't got removed, unlike with --open-gop.

[3ds]

Even knowing that your target is Blu Ray there are two possible vbv values for 1080p. This also affects the number of slices. Depending on that there are also two different keyint parameters that are valid. Just by that commandline x264 can't know which of the two you want. See the Blu Ray encoding sticky.
We have two choices for level 4.1 and level 4.0, if i look to Primary Video Rules from: http://forum.doom9.org/showthread.php?t=154533

So x264 must know witch level should be used. Idea: --bluray-compat used highest level (--level 4.1) as default, but the user can add --level 4.0

So there are any information to calculate all needed restrictions values (e.g. max bitrate, buffer size etc.)

btw. is there ever a reason to use a smaller level than 4.1? All bluray players should play level 4.1, isn't it?

[mp3dom]

btw. is there ever a reason to use a smaller level than 4.1? All bluray players should play level 4.1, isn't it?
Standard Def video doesn't need 40 Mbps to be encoded, even for max bitrate. In general level 3.2 or 4.0 is enough (maxrate is 24 Mbps) and this allows to have 1 slice only. It can be a matter of taste, you can encode anyway a standard def. video with level 4.1 and 4 slices.

[nurbs]

When you want to put a Blu Ray structure on DVD using level 4.0 is also better since you can use longer GOPs and don't need slices, so you get a little better compression.

[QBhd]

When you want to put a Blu Ray structure on DVD using level 4.0 is also better since you can use longer GOPs and don't need slices, so you get a little better compression.

In this scenario, the only difference would be the # of slices... What is the benefit of going with slices 1 over slices 4 from a quality stand point?

QB

[nurbs]

VBV would also be different in that scenario since DVDs usually don't have high enough transfer speed to support the full level 4.0 bitrate. Since you have lower bitrate you can also use 2 second GOPs. Going from 4 slices to 1 won't give much benefit, I'd guess way less than 1%, but every bit helps.

[burfadel]

The new rev 1995 builds on x264.nl are 25.4mb... To me thats just a little large? 25.4MB! I didn't bother downloading it since there's something wrong with it.
(mirror01 didn't seem to respond, the other mirrors all came up with 25.4mb)...

[Dark Shikari]

jarod forgot to strip his builds.

[Boulder]

Is Simon Horlick's work on MBAFF now finished or are there any new things (except from optimizations and fine-tunings) expected?

[upyzl]

It seems that I don't need to deint NTSC-30i any longer when see the changes of MBAFF if I encode just for myself by r1995...

[laserfan]

Is Simon Horlick's work on MBAFF now finished
Having followed the commit history (https://github.com/DarkShikari/x264-devel/commits/master) for a little while now I'd been amazed at the output of this individual, and with the recent release (and an interlaced project I'll be interested to try with r1995) I had to look him-up. Apparently one of the things one has to do these days is keep a blog journal. (http://simonhorlick.blogspot.com/2010/04/diary-of-x264-mbaff-developer.html)

Altho I can bearly spel MBAFF ;) I appreciate all the work! :)

[Brazil2]

on x264.nl
mirror01 didn't seem to respond
Mirror01 seems to be down for several weeks.

[IgorC]

Are there any x264's benchmarks of ARM Cortex-A9 and Atom?
What is the state of omptimizations for ARM's SIMD extension NEON vs Atom and performance per watt?

Google search doesn't return much on it.

[Blue_MiSfit]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.

[Boulder]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.Can you post some test results? I've got a pile of DVD extras to encode as interlaced to add to my media jukebox, and I've been waiting for the feature to be finished :)

[Sharc]

Seriously, MBAFF is badass. I can officially forget about mainconcept now.
What do you mean by "badass" (for us non-native English speakers)? Google didn't translate "badass" for me .....
Is MBAFF generally poor (in x264)? Or dou you mean that it is now much better in x264 than Mainconcepts hence you can forget Mainconcept? I am still interested in doing interlaced (MBAFF) encodes.
Thanks for enlightening me :)

[nixo]

Badass = awesome, great.

--
Nikolaj

[Groucho2004]

Google didn't translate "badass" for me .....

You must be using the wrong Google. :)

Second link I got from Google:
http://www.urbandictionary.com/define.php?term=badass

Interpretations 2 and 4 on that page would be a match to what Blue_MiSfit meant.

[Sharc]

Thanks guys. Great to learn that its meaning is so positive for x264 MBAFF!

[Blue_MiSfit]

Correct. It's a substantial improvement in quality (or even metrics like psnr if you optimze for that).

Some random hard 3:2 content picked up about 1 db in psnr in my fairly restrictive tests: 1.2mbps cbr 480i, short GOPs and small buffers as required for a specific client. 1db of PSNR is quite substantial, to say nothing of the visual improvement when using psy optimizations.

Derek

[CruNcher]

Yeah especially for the user they don't have to care anymore if their content is progressive or interlaced content even both mixed on the same frame thus being macroblock adaptive will be equally well encoded that's a big plus of usability improvement in the encoding framework :)
MBAFF was the first step to have a Interoperability layer for old (analog TV age interlaced content) for moving on into the full progressive digital age without braking old analog concepts and still allow Broadcasters to save bandwidth if they want or need to put some more stations on the transponders :)
Nice finally to see it it arriving in x264 after so much years :)

[Boulder]

Did anyone test CRF mode yet? I did a very quick test and noticed that the previous build (without adaptive MBAFF) produced a smaller file with the same settings and CRF. So do we need to adjust CRF again to compensate for the changes?