x264 development

[kieranrk]

Originally Posted by mp3dom

Is there a reason why some decoder chipset (players) have problems handling duplicates while (as far as I know) the same players doesn't exhibit the problem with other commercial titles (that still uses weighted prediction for P frames but supposedly doesn't use dupes?). Probably in the BD specs there isn't a clearly statements about this, because in the other case all players would have decoded the stream with dupes correctly (from the beginning or via a firmware upgrade)

Well they can't just mention every single H.264 feature in the Blu-Ray spec. There's only a dozen or so pages about H.264.

[sneaker_ger]

The problem wasn't only in Blu-Ray players, but also software non-Blu-Ray specific players. And both hardware and software manufactors have acknowledged their mistake and have fixed the problem in newer products (and some of them fixed it with firmware updates for older products). It's just that no encoder made use of it until it was implemented in x264, so manufactors didn't have any such stream for their product testing and were thus unaware of the problem.

[sneaker_ger]

Originally Posted by shon3i

You can't use use bluray compat without setting proper level

Of course I can. 1080p24:
x264 --bluray-compat --vbv-maxrate 24000 --vbv-bufsize 24000 --keyint 24 --sar 1:1 -o out.264 input.file

100% Blu-Ray compliant.

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...

[rallymax]

so... let me get this right...

Some of you are complaining about a command line switch (--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself). A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

These are the same people that are using x264 for FREE, and don't contribute to the coding effort.

If you MUST have a patch that differs from the mainline development of x264 then do the 5 or so steps to get MSYS, GIT the repos, SVN things like ffmpeg, do "configure ...;make install" for ffmpeg then "configure ...;make install" for x264. If that's too much why don't you go and whine to that PATCH feature developer to get them to change --bluray-compat to your interpretation.

How about showing some appreciation for the volunteer effort that the x264 Dev's give EVERY DAY FOR FREE.

To devs - you rock. I'm excited and appreciative every day of your gift to the community.

[sneaker_ger]

Originally Posted by rallymax

(--blueray-compat) that is compeletely optional (because you can still write the explicit commands yourself).

You can't, some of the options are only available through --blueray-compat

Originally Posted by rallymax

A command line switch that just happens to not jibe with your strict interpretation of the spec becuase you disguard that there is such a thing as "the real world" status of the spec.

The x264 devs also regard it as spec compliant. It's only to care for older, buggy players.

Originally Posted by rallymax

If you MUST have a patch that differs from the mainline development of x264 why don't you go and whine to that branch developer to get them to change --bluray-compat to your interpretation.

That developer is active here, so whining here is an option. Patching is also trivial (delete a single line), but setting up a compiling environment is not and doing regular compiles is a lot of work.

Originally Posted by rallymax

To devs - you rock. I'm excited and appreciative every day of your gift to the community.

This.

[Selur]

summing the feedback my last post got up:

--bluray-compat

• enables a bunch of 'Blu-ray hacks':
  - min-CR + level 4.1 hack
  - Special b-pyramid SEI
  - B-frames cannot reference frames outside their minigop
  - Open-GOP keyframe interval hack
• renders '--open-gop' parameters obsolete:
  - now: --bluray-compat + --open-gop <> old version: --open-gop bluray
  - now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD
• enforces:
  - aud=1
  - nalhrd=vbr
  (-> these are not needed in the command line when using '--bluray-compat')
• restricts:
  - bframes to: 3 or less
  - bpyramid to: strict or none
  - max references to: 6 or less
  - weightp to: 1 or 0

[Dark Shikari]

It doesn't enforce nalhrd=vbr, it restricts nalhrd >= vbr.

[iSeries]

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?

[Dark Shikari]

Originally Posted by iSeries

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?

It's not.

[Sharc]

Originally Posted by iSeries

This is getting more and more confusing. So --nal-hrd is needed in the command line? Or not?

I use this site as a reference. It appears to be well maintained and corresponds with the latest version from http://x264.nl.

... and the information given here in the first post (sticky).

[shon3i]

Originally Posted by sneaker_ger

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]

Originally Posted by Selur

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]

Originally Posted by 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

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]

Originally Posted by thegame

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?...postcount=1371