Has anyone used X264 to produce a replicated BD title?

[Guest]

Many Blu-rays disable that because they blur too much. Please provide evidence for this claim.

[poisondeathray]

1) Are there limits to subme? Megui's blu-ray profile has "--subme 2" toggled.
2) Are there limits to me? Megui's blu-ray profile has "--me dia" toggled.



Can you clarify: Do you mean for 1st pass settings? Because they are set differently in the Megui blu-ray profile

[Revgen]

Can you clarify: Do you mean for 1st pass settings? Because they are set differently in the Megui blu-ray profile

They are 2nd pass.

When I open the MEGui Blu-Ray preset, the options are shown in the box.

program --profile high --level 4.1 --preset fast --pass 2 --bitrate 8000 --stats ".stats" --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --no-mbtree --me dia --subme 2 --partitions none --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --sar 1:1--output "output" "input"

Clearly 4.1 cannot be compatible without slices, so it needs to be modified. I'm just trying to figure out exactly what needs to be changed.

[poisondeathray]

They are 2nd pass.

When I open the MEGui Blu-Ray preset, the options are shown in the box.


We must be using different builds/presets because your commandline looks completely different (fast preset, partitions none !? )


Clearly 4.1 cannot be compatible without slices, so it needs to be modified. I'm just trying to figure out exactly what needs to be changed.


I don't think the profile needs to be modified, because it works on the majority of SAPs just fine. This thread is about replication and that's a different story...

[Revgen]

We must be using different builds/presets because your commandline looks completely different (fast preset, partitions none !? )



I don't think the profile needs to be modified, because it works on the majority of SAPs just fine. This thread is about replication and that's a different story...

I'm just trying to find out which settings are compatible and what the limits are. MeGUI's settings just raised my curiosity.

[shon3i]

obvious that people do not read posts carefully :) so i make the table to make things be easier.

http://tom.niko.users.sbb.rs/bdtable.jpg

This setings are based on Blu-Ray specification and documentation not H264.

btw.
Max bframes = 3

if you use x264 as encoder then don't use B-pyramid because can broke DBP, but B-Pyramid is generaly alowed thing (Sonic Scenarist use it but automaticly decrase ref by one)

mixed-refs is probably allowed, but some H264 developer better to answer because maybe can break DBP aslo? Mainconcept developer (Sergey) found that b-pyramid broke DBP in x264, maybe him know something about?

EDIT: About GOP thing. Blu-Ray allow both Open and Closed GOP structure, for H264.

Recommend GOP is min-max is 2-24 but everything from 1-30 can be used from both mix and max. Max value aslo depend how many b-frames used. If Bframes = 0 you can use anything from 1 to 30 for both min and max value
if bframes = 1 min also can be 1-30 but max value can be 2,4,6,8,10,12,14,16,18,20,22,24,26,28,30
if bframes = 2 min 1-30, max 3,6,9,12,15,18,21,24,27,30
if bframes = 3 min 1-30, max 4,8,12,16,20,24,28,30

minimum 2 is recommended by authorung apps, 1 is fine too

[Chengbin]

Please provide evidence for this claim.

I believe benwaggoner mentioned that from this thread (http://forum.doom9.org/showthread.php?t=147300&page=2)

Why would we assume 30-70% lower? Not arguing, but that seems a pretty specific assumption.

A lot of Blu-ray titles wind up having In-loop deblocking turned off for most of the title in order to eliminate the softening effect. That seems a little...aggressive to me, but that certainly would have an impact.

But anyway, I suspect you'd find that actual discs's defects are found in the IYUV masters more often than not.

But even given 20 Mbps and 70%, and using power of 0.75 as a rule of thumb, that'd be still be 14 Mbps 1080p, equivalent to 7.6 Mbps ABR 720p with x264, which should be well more than ample.

Quote:
That's part of the problem as well. They need to start using real HD digital cameras
They are, but we're still going to be watching movies shot with all kinds of cameras for decades to come.

Even I find excellent compresibility poor consolation for a bad story or poor acting .

[Revgen]

^I've never had problems with X264's inloop filter overblurring details at Blu-Ray or HD-DVD resolutions and bitrates as long as it's at -1:-1 or less. Even at 0:0, it's hardly noticeable. Perhaps the AVC encoders they are using have substandard inloop filter implementation.

[Manao]

Perhaps the AVC encoders they are using have substandard inloop filter implementation. That doesn't exist. Everybody must use the same deblocking algorithm. However, since deblocking's strength is inherently adaptive with the quantizer (the higher the quantizer the stronger), and since x264 tends to be a lot more efficient than other encoders (translate : most of the time, at the same bitrate, it'll use a quantizer lower by 1 or 2), at the same deblocking settings and same bitrates, x264 may seem to deblock less.

[Revgen]

That doesn't exist. Everybody must use the same deblocking algorithm. However, since deblocking's strength is inherently adaptive with the quantizer (the higher the quantizer the stronger), and since x264 tends to be a lot more efficient than other encoders (translate : most of the time, at the same bitrate, it'll use a quantizer lower by 1 or 2), at the same deblocking settings and same bitrates, x264 may seem to deblock less.

That seems like a fancy way of saying that the other AVC encoders suck. ;)

That seems to explain it then.

[Dark Shikari]

That doesn't exist. Everybody must use the same deblocking algorithm. However, since deblocking's strength is inherently adaptive with the quantizer (the higher the quantizer the stronger), and since x264 tends to be a lot more efficient than other encoders (translate : most of the time, at the same bitrate, it'll use a quantizer lower by 1 or 2), at the same deblocking settings and same bitrates, x264 may seem to deblock less.That seems like an odd statement; with psy, especially psy-trellis, x264 uses significantly higher quantizers than normal.

[benwaggoner]

Please provide evidence for this claim.
I'm not sure if there are any public references to this fact, but I can confrim that this has long been standard practice in BD production for A-list titles. At NAB, a couple different BD encoder vendors were touting their ability to turn it off as a feature.

I don't know if it's default for all the tools, or as used by all compressionists. But many studio BD titles will have big sections where in-loop is off entirely.

I also agree that this shouldn't be needed in theory, and am not sure how really needed it is in practice. Most professional optical disc compressionists don't have that much of a compression science background, and often keep using "best practices" established long ago, even if the reason for them has long since been addressed. There's plenty of exceptions to that rule. Most great Photoshop artists couldn't do a whiteboard calculation of the effect of cumulative 8-bit rounding errors. But they still end up with photos that look a lot better than mine :).

About three years ago I saw a then 10 year old Toshiba MPEG-2 encoder still being used for A-list titles!

[Lyris]

and often keep using "best practices" established long ago, even if the reason for them has long since been addressed.
(Cough) lowpass filter (cough) ;)

[benwaggoner]

(Cough) lowpass filter (cough) ;)
...which did make some sense in the early DVD era, since a progressive encode viewed on an interlaced display could have frequencies about Nyquist in 240 lines per field, resulting in some aliasing issues.

For which a vertical lowpass filter would make sense. However it seems the practice that emerged was to use a 0.3 pixel vertical blur.

Which may have been tempting because it'd make compression a decent bit easier as well.

There was quite a kerfuffle in the pre-launch days of HD DVD where we kept having to assure AVS Forum that we weren't encouraging that practice, and in fact did not include a vertical blur filter as part of PEP :).

Not that it would have been needed much even when playing back on a 1080i display, given that film sources are very rarely going to have any frequencies that high in a 1080 frame.

My bias has long been to optimize for those who have good, well-calibrated displays, since by definition they're the ones who cared about quality, and have earned it. We certainly need to make sure things don't stink on consumer displays, but the most accurate experience should be achieved by the most accureate calibration.

[Lyris]

I totally agree with your last paragraph - aiming high instead of the lowest common denominator is the way to go, because like you say, the people who have the equipment that creates such issues probably won't even notice or care about them anyway.

[Biggiesized]

I have the trailers for "The Island" and "Match Point" from Dreamworks with permission to redistribute for compression testing. I've got Lagarith 1920x1080p23.769 with 5.1 audio AVI files I could probably post somewhere.
Both would be great, but if you had to choose between the two, go with The Island.

How soon do you think you can get these up, Ben?

[Chengbin]

Lyris, have you tried encoding a 30-35Mbps encode using x264 to see how good it looks just for kicks?

[Lyris]

Yes. Many times. I wouldn't get funny looks if I called them "essentially lossless".

[benwaggoner]

Both would be great, but if you had to choose between the two, go with The Island.

How soon do you think you can get these up, Ben?
I'm uploading Island to my SkyDrive right now (in 50 MB chunks), and it should be done sometime tomorrow.

[benwaggoner]

Yes. Many times. I wouldn't get funny looks if I called them "essentially lossless".
Did you compare those to 25 Mbps peak single-slice?

My expectation is that Level 4.0 would reach quality saturation with x264 for large classes of content, particularly 1080p24. Full-frame 1080i30 would be the most likely exception, particuarly highly detailed and fast-motion stuff like sports shot with fast shutter speeds.

Before we ask the x264 devs to tackle the apparently challenging and otherwise not broadly useful work to get slicing added back in, there probably should be some clear samples of where Level 4.1 would offer a percetible quality advantage over Level 4.0 as currently supported.

[Chengbin]

And if x264, at level 4.0, is beating out the best commercial encoder at 35Mbps, maybe you can just use the x264 encode, since at level 4.0 it is completely compliant to the Blu-ray specs.

[Revgen]

Even 1920x1080i broadcast quality streams (ones actually sent from the tower before they are sent to the cable tv provider) tend to be no more than 18mbps to 22mbps. And that's for 60i material broadcast with MPEG-2. 1920x1080p at 24p with AVC or VC1 should be fine at Level 4.0.

[kolak]

Lyris, have you tried encoding a 30-35Mbps encode using x264 to see how good it looks just for kicks?

I've done it with uncompressed 30p source and compared to 2 pro encoders. x264 is good, very good :)


Andrew

[Guest]

Discussion of adaptive deblocking was moved here:

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

[benwaggoner]

Both would be great, but if you had to choose between the two, go with The Island.

How soon do you think you can get these up, Ben?
Give this a shot:

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/The%20Island%20Trailer

[plonk420]

thank you, sir! was going to offer to share it on FTP and give out the URL to those who requested it, but this works well enough!

[Biggiesized]

Give this a shot:

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/The%20Island%20Trailer
Thank you, Ben! You are a gentleman and a scholar.

Could you please provide a checksum as well?

I didn't know SkyDrive offered free storage. That's a handy little tool from Microsoft.

How much bandwidth are you allotted per month?

[Lyris]

That's some gorgeous footage, but wow, I'm surprised at what happens during the fades. I think I speak for many people in saying "thank you for giving us some studio quality footage that isn't Big Buck Bunny" :)

[dvdboy]

I'm trying to use x264 on some test encodes in ScenaristBD 5.1.2 using this command line:

program --profile high --pass 2 --bitrate 20000 --stats ".stats" --level 4 --keyint 24 --min-keyint 2 --ref 4 --b-adapt 2 --direct auto --deblock -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --me umh --thread-input --interlaced --output "output" "input" --mvrange 511 --nal-hrd --sar 1:1

MUI creation seems to go fine, but when I go to multiplex the project I get the following error:

2009-08-18T08:52:17Z|ERROR|MUX_SN_E_TS_UNDERFLOW_ERR|F:\x264 Test\01.00.0000\Output\MUX\BDROM\DB\BDMV\STREAM/00002.m2ts|0|Buffer underflows|TSWrapper.dll::CTSWrapper::ProcThreadMain::Video buffer underflows. - |

Apologies for such a stupid question, but is this a problem with my commandline, or does Scenarist just not like the encode for some reason?

[shon3i]

It is obvious that encoded stream have buffer underflows. Sinece x264 VBV sistem isn't stable and NAL HRD aslo isn't stable, you can try with new lookahead VBV or if you use maybe to try to downgrade to older x264 to see is there difference.

Aslo you miss --aud in your comand line, maybe is that catch?

[dvdboy]

I'll try the --aud command. THe above was created by MeGUI, which I believe reccently update it's x264 'engine'.

[laserfan]

Give this a shot:

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/The%20Island%20TrailerCan someone please post what the total download size (approx)? Is it a couple Gb? I need to know before I attempt to DL; my ISP limits my downloads... :(

[Chengbin]

Can someone please post what the total download size (approx)? Is it a couple Gb? I need to know before I attempt to DL; my ISP limits my downloads... :(

45x50mb=2.25GB

[J_Darnley]

I guess it is 2217MB, based on the fact the first piece is 50MB, and the last being 17MB and there being 45 in total.

[laserfan]

Thanks. I remembered that bw had said "50Mb chunks" but wanted to confirm.

[kieranrk]

Is there any way of downloading that programmatically?

[Biggiesized]

Is there any way of downloading that programmatically?
I don't think so. The URLs look to be randomly server generated and not batch compatible since they don't follow a sequence.

[kieranrk]

Never mind. I downloaded them one by one.

[nm]

I don't think so. The URLs look to be randomly server generated and not batch compatible since they don't follow a sequence.
wget can handle such situations but it probably requires a bit of trial-and-error to do it without mirroring the whole site :)

[Biggiesized]

Wow I thought I had trouble opening the split archive until I calculated a checksum on all the files only to learn that I forgot to download one part! D'oh!

EDIT: For anybody's reference, the checksum (I now have all 45 parts) that was calculated for me was:

http://img8.imageshack.us/img8/8049/checksum.png

[Lyris]

Wow I thought I had trouble opening the split archive until I calculated a checksum on all the files only to learn that I forgot to download one part! D'oh!
I did the exact same thing!

Interesting that there's so much banding during fades. Also there's a great shot where Ewan McGregor's eye has clearly had VFX work done to the side of it, but they've forgotten to add grain to conceal the compositing. All the things you begin to notice when you stare at video for too long :)

BTW, I've also been trying out the Elecard AVC encoder with this trailer. It has options for writing HRD info into the stream, and also support for multiple slices, so in theory it should be BDMV compliant. Results are good, but not at the level of Mainconcept Reference - or indeed, x264.

[Chengbin]

Interesting that there's so much banding during fades.

Are you using mbtree? mbtree is known to mess up on fades. weight-p will correct that, and it is coming in a few weeks.

[woah!]

Are you using mbtree? mbtree is known to mess up on fades. weight-p will correct that, and it is coming in a few weeks.

he means the source has terrible fades in it already....

[tyee]

I can't seem to download the trailer anymore. It was working this morning but not now. Same thing for everyone else?

[CruNcher]

Thx to Ben and DreamWorks for sharing this Source nice task :)

@tyee
Still works here

[Audionut]

I can't get the archives open. I've tried winrar, 7-zip, renaming the extensions.

I can select all the files and extract with 7-zip, but it only creats a 2.16GB .7z file that itself can't be extracted.

Any ideas what i'm doing wrong?

[Lyris]

I had the same problem at first - be absolutely sure that you have all 45 parts.

[Audionut]

you have all 45 parts.

No problem there.

[Chengbin]

Just to keep this thread on topic:

Lyris, so what do you plan to use? x264 at level 4.0, or Mainconcept Reference?

[woah!]

i am finding 15mbps with L4.0 bluray settings is near on perfect with that trailer source.... i forget how good x264 is at times...

heres a few compare screens if anyones interested...


http://tinyurl.com/njy77a