Software To Encode Blu Ray Files

[zerohash]

Hi,

I want to purchase a pro level software encoder to author Blu Ray movies. Some have advice me Cinemacraft and some Pixeltools and few Net Blender. Please advice me which one should i go for and which one is the best. Just wanted to know if there is any or much of a difference between these 3.
It will be a great help.

Zerohash.

[shon3i]

Why you want to buy "pro" encoder, why not first give chance to free x264 encoder?Because is fully blu-ray compatible, can encode superb quality.

[zerohash]

I want a pro level encoder because i will be encoding movies which are going for replication and are to be released in commercial market and also we need the best to compete with our competitors too.

[aegisofrime]

What makes you think x264 isn't pro level?

[kieranrk]

I want a pro level encoder because i will be encoding movies which are going for replication and are to be released in commercial market and also we need the best to compete with our competitors too.

x264 is the best encoder. It has been approved for use by Criterion Collection (which sponsored x264's compliance testing) and by GDMX, a Warner Bros subsidiary.

There are replicated discs in production as I type this.

See my signature for more information.

[shon3i]

I want a pro level encoder because i will be encoding movies which are going for replication and are to be released in commercial market and also we need the best to compete with our competitors too.
You definitely want to use x264 if you want to beat competitors. There is no other encoder can do that.

[zerohash]

Thanking you all for your replies and help. Was wondering why do people pay 14K + USD for Cinemacraft or 4K +USD to Pixeltools when x264 is available for free. Please let me know your views. Thanks.

[nm]

Thanking you all for your replies and help. Was wondering why do people pay 14K + USD for Cinemacraft or 4K +USD to Pixeltools when x264 is available for free. Please let me know your views. Thanks.

Because they think like you did when you started this thread.

[nurbs]

Because people think stuff that costs a lot of money is better. That's why there is a market for 100€ HDMI cables (1m).

[aegisofrime]

Because people think stuff that costs a lot of money is better. That's why there is a market for 100€ HDMI cables (1m).

Agreed.

Software Engineer: Sir, I think we should use x264. It's the best encoder and it's free!

Big Boss: It's free? Nothing that's good is free! No way! We are going to pay millions for <insert commercial software> and that's the end of it!

[shon3i]

Ok, there is some weaknesses in x264 that makes CCE-HD better for blu-ray authoring (eg. fades can be problem even on very high bitrate), but again after we compare that maybe not ugly fades and cost of CCE :) x264 is absolutely winner.

[poisondeathray]

The other potential weakness is no segment re-encoding

[mp3dom]

In general the word 'best' in this forum is not allowed but is permitted only for x264 :D

Trying to stay as objective as possible, there's really no 'best' because every encoder (pro or not) have its strengths and weak points.
Some encoders performs better with particular footage, some others works better with lower bitrate, other gives more fidelity at higher bitrates and so on. This excluding that some encoders have more speed than others or offers more features than others.

The decision is up to you but consider that, actually, there isn't one only encoder that output the 'best' quality in every possible field (or, if it exists, I've not tested it yet).

Here the people thinks that I'm against x264, but indeed I've replicated BDs using x264 so I'm really no fan of a specific encoder, but rather I'm choosing every time the one that gave me the best output quality.

I would only suggest to stay away from CineVision. In general the output quality is lower than the output quality of other pro-encoders.

Good luck.

[zerohash]

Is it Cinevision or Cinemacraft?

[laserfan]

You need an authoring tool, as well as an encoder. The only "pro grade" authoring tool that I've been exposed to is Sony Vegas Pro w/DVD Architect, and I know it doesn't like some settings of x264. What do folks here see as the top-of-the-line BD authoring (menu-making) software today?

[poisondeathray]

What do folks here see as the top-of-the-line BD authoring (menu-making) software today?

Scenarist , with a top of the line price as well. Perhaps Blu-print

[kieranrk]

Scenarist , with a top of the line price as well. Perhaps Blu-print

Netblender Do Studio as well.

[mp3dom]

Actually the most expansive BD authoring tool is Blu-Print (50.000$) which use abstraction layer. Scenarist was priced-down at the beginning of the year. Now Scenarist BD Pro + Scenarist QC (the bluray emulator for checking what's been compiled) + Lemony Pro (subtitles software) is priced at about 20.000$ (probably less). There are also DoStudio (abstraction layer too) and Kaleidoscope at the pro level.

[kolak]

The other potential weakness is no segment re-encoding

And speed :(

[Dark Shikari]

And speed :(Why, is x264 too fast for you? Would you rather have something slower?

[kolak]

The other potential weakness is no segment re-encoding

And speed and tweaking possibility and reviewing encoded video and lack of support for 10bit feed- maybe this can be done?
Also "proper" support is missing and no one to blame when there is something wrong with encode on replicated disc :)

Also as mp3dom said- some encoders works better than others on certain source types. I use 3 and not always the same :)

Still x264 is good to start with, because won't cost you a penny! You may like it and stay with it.

Andrew

[kolak]

Actually the most expansive BD authoring tool is Blu-Print (50.000$) which use abstraction layer. Scenarist was priced-down at the beginning of the year. Now Scenarist BD Pro + Scenarist QC (the bluray emulator for checking what's been compiled) + Lemony Pro (subtitles software) is priced at about 20.000$ (probably less). There are also DoStudio (abstraction layer too) and Kaleidoscope at the pro level.

Where did you get this price from for Scenarist BD?
It's more like price for Studio version not PRO.


Andrew

[Dark Shikari]

And speed and tweaking possibility and reviewing encoded video and lack of support for 10bit feedx264 supports 10-bit input just fine. And seriously, "lack of tweaking" for an encoder with more options than every single pro encoder combined? Complaining about speed for the fastest software encoder in the world? Is this some kind of troll?

Seriously, criticize x264 for its actual problems, not its strengths! :rolleyes:

[kolak]

x264 supports 10-bit input just fine. And seriously, "lack of tweaking" for an encoder with more options than every single pro encoder combined? Is this some kind of troll?

Good :)

but what about conversion to 8bit, where is it happening?
I want to feed 10bit through some dithering filter and than (as 8bit) to x264.
Is this possible with avisynth?

I encode with Cinemacraft at 1.5 faster than RT at full quality for 24p. x264 is 2-3 times slower than RT to get the same quality on the same machine.

Thanks,
Andrew

[Dark Shikari]

Good :)

but what about conversion to 8bit, where is it happening?It happens at the end of x264's filter chain. Whatever bit depth you currently have is dithered down (or up) to whatever your x264 build's bit depth is.

For example:

10-bit input (v210) -> dither to 8-bit -> libx264
or
16-bit input (libavcodec) -> dither to 8-bit -> libx264

I want to feed 10bit through some dithering filter and than (as 8bit) to x264.
Is this possible with avisynth? Avisynth doesn't support 10-bit, so no.

I encode with Cinemacraft at 1.5 faster than RT at full quality for 24p. x264 is 2-3 times slower than RT to get the same quality.It's not my fault if you insist on using extremely slow encoding settings. I can get 1.5x faster than realtime for 1080p with quite reasonable quality, and my CPU is terrible.

[kolak]

It happens at the end of x264's filter chain. Whatever bit depth you currently have is dithered down (or up) to whatever your x264 build's bit depth is.

For example:

10-bit input (v210) -> dither to 8-bit -> libx264
or
16-bit input (libavcodec) -> dither to 8-bit -> libx264

Avisynth doesn't support 10-bit, so no.

It's not my fault if you insist on using extremely slow encoding settings. I can get 1.5x faster than realtime for 1080p with quite reasonable quality, and my CPU is terrible.

Read it properly :)
I said- to get the same quality on the same machine.
Going down with settings quickly takes quality down.
Some encodes are extreamly close to the source with PSNR about 50dB.

As I said some time ago: encoding for BD is not the same as encoding for web.

I would love to see a product based on x264- with proper GUI, review, input filters etc. Pieces are there, but someone needs to create a product. Quality is the main thing, but still not everything in typical authoring workflow.


Andrew

[Dark Shikari]

Read it properly :)
I said- to get the same quality on the same machine.
Going down with settings quickly takes quality down.
Some encodes are extreamly close to the source with PSNR about 50dB.If you're claiming to measure "quality" with PSNR, you have no idea what you're doing to begin with.

Also, if you want a real all-in-one Blu-ray tool made using x264... there is one currently being made :) But I can't give more info than that.

[kolak]

If you're claiming to measure "quality" with PSNR, you have no idea what you're doing to begin with.

I measure it with my eye frame by frame- PSNR is for your information.

Cinemacraft does not show PSNR (neither Blu-code), but allows you in very friendly way compare whole encode to the source (or filtered file) frame by frame and it will output this over HD-SDI to properly calibrated monitor (if you wish).

Can't wait for this tool :)

btw...have you seen this:

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

some new method for very low bitrate encoding for web and mobile devices.


Andrew

[mp3dom]

Whatever bit depth you currently have is dithered down (or up) to whatever your x264 build's bit depth is.
Do you know which kind of dithering is applied? Noise shaping, random number, roundings etc? Thanks.

[kolak]

Do you know which kind of dithering is applied? Noise shaping, random number, roundings etc? Thanks.

Yes- I also would like to know.


Andrew

[Dark Shikari]

Do you know which kind of dithering is applied? Noise shaping, random number, roundings etc? Thanks.x264 uses a variant on Sierra-2-4A error diffusion, a faster alternative to Floyd-Steinberg error diffusion. x264's implementation is explicitly designed such that if the input is upscaled within x264 to a higher bit depth, then downscaled using error diffusion, the result will be losslessly identical to the input.

[Blue_MiSfit]

Hi kolak:

Any chance you could provide some samples from Cinemacraft? I'd love to see how it compares to x264.

Derek

[kolak]

Hi kolak:

Any chance you could provide some samples from Cinemacraft? I'd love to see how it compares to x264.

Derek

Sample of what?
Any file?

Andrew

[kolak]

x264 uses a variant on Sierra-2-4A error diffusion, a faster alternative to Floyd-Steinberg error diffusion. x264's implementation is explicitly designed such that if the input is upscaled within x264 to a higher bit depth, then downscaled using error diffusion, the result will be losslessly identical to the input.

Sounds good.
Smooth CGI is very difficult to encode.

Andrew

[Blue_MiSfit]

Maybe crowdrun, parkjoy, some other easily available, challenging uncompressed sequence.

Derek

[kolak]

Maybe crowdrun, parkjoy, some other easily available, challenging uncompressed sequence.

Derek

Probably x264 is going be better for these sources, due to its better compressibility possibilities.
These sources are not representative- better to have 5min from some film source or join many available short samples (with different picture nature) into one bigger source and use this as a source.


Andre

[Dark Shikari]

Probably x264 is going be better for these sources, due to its better compressibility possibilities.
These sources are not representative- better to have 5min from some film source or join many available short samples (with different picture nature) into one bigger source and use this as a source.All of those are film sources, and there's a wide variety of them, all short samples. :rolleyes:

[Blue_MiSfit]

I can probably create test files from an HDCAM-SR tape if need be...

Otherwise yes I think many of the EBU samples concatenated would be interesting.

[kolak]

All of those are film sources, and there's a wide variety of them, all short samples. :rolleyes:

Yes, but short and very specific. The best is to join different once.
10sec sample of a same scene wont let you see bitrate allocation for example.

Andrew

[Dark Shikari]

Yes, but short and very specific. The best is to join different once.
10sec sample of a same scene wont let you see bitrate allocation for example.

AndrewSolution: cat a ton of them together, silly! :D

[Eric69]

I want a pro level encoder because i will be encoding movies which are going for replication and are to be released in commercial market and also we need the best to compete with our competitors too.

On top of trying x264, Id consider using Do Studio for your authoring. Its an abstraction layer tool but it is BD-J and uses 32bit graphics. It has some bugs but I dont think you'd be interested in customized BD-J development.

I only do HDMV title myself but have had some clients recently ask me why my graphics aren't as "clean" as another title done with Do Studio. I tried to explain why but it went over their heads. I just might need to dump Scenarist HDMV for Do Studio to compete? Who knows?

[kolak]

Solution: cat a ton of them together, silly! :D

No- solution is described in post 36 :D

Andrew

[Dark Shikari]

No- solution is described in post 36 :D

AndrewEr, so you're going to take a lossy Blu-ray film source and compress it again? That's no "solution", that's stupid. Use a lossless film source, like the Fairytale samples.

[kolak]

Er, so you're going to take a lossy Blu-ray film source and compress it again? That's no "solution", that's stupid. Use a lossless film source, like the Fairytale samples.

No- it's about joining many short clips. Where does it say about some Blu-ray source?


Andrew

[Dark Shikari]

No- it's about joining many short clips. Where does it say about some Blu-ray source?


AndrewYou said you weren't going to use the lossless source, but rather you were going to assemble some clips from some other (probably lossy, since Blu-rays are lossy) film source.

Or, if you're testing using a lossless film source that isn't public, you'll test using a source that we can't use, and thus we can't compare anything to your results.

[kolak]

You said you weren't going to use the lossless source, but rather you were going to assemble some clips from some other (probably lossy, since Blu-rays are lossy) film source.

Or, if you're testing using a lossless film source that isn't public, you'll test using a source that we can't use, and thus we can't compare anything to your results.

I don't knwo how you read my posts-others seams to have no problems.

I said that one short clisp is not good- best is to join many. It was about publicly available ones.

Never mentioned any lossy, or BD source- it's all your assumption.

Andrew

[nm]

I don't knwo how you read my posts-others seams to have no problems.

I'm having difficulty.

I said that one short clisp is not good- best is to join many. It was about publicly available ones.

Um, that's what DS has been saying as well?!

Never mentioned any lossy, or BD source- it's all your assumption.

Yes, because you were arguing against him.

[kolak]

Um, that's what DS has been saying as well?!


Yes, because you were arguing against him.

No comments :)


Andrew

[jethro]

The idea that there may be a better encoder than x264, for specific purpose (i.e. BD) at that, is like blasphemy for some users on this board and users claiming that are ridiculed.
If we get to see sample encodings, then we could judge - this is called evidence.

Solution: cat a ton of them together, silly! :D
No- solution is described in post 36 :D

Andrew

'cat' in geekspeak means concatenate, so D_S is saying the same thing here.

[kolak]

The idea that there may be a better encoder than x264, for specific purpose (i.e. BD) at that, is like blasphemy for some users on this board and users claiming that are ridiculed.
If we get to see sample encodings, then we could judge - this is called evidence.



'cat' in geekspeak means concatenate, so D_S is saying the same thing here.

DS repeated few times tha same what I have said :)

[RunningSkittle]

DS repeated few times tha same what I have said :)

Then why cant you post sample output already?

[MasterNobody]

DS repeated few times tha same what I have said :)
But you still seems don't want to show results of "Pro" encoders for such test.

[kolak]

But you still seems don't want to show results of "Pro" encoders for such test.

It's not like I don't want- I don't need to or have no interest to do it.
I have access to many encoders: pro once and x264 and I've done comparision for myself.

I don't question quality of x264- I question x264 usage in professional authoring house (compared to pro encoders).
It's BD compliant now, amazing quality, it's free, but I still don't know any place which uses it, why?

I think you can find answer in my posts.

All current BDs have mostly very good quality video and almost all done with pro encoders. Most bad once are due to bad sources.

Andrew

[jethro]

It's not like I don't want- I don't need to or have no interest to do it.

Andrew
Yes, but some of us would have interest in a comparison sample(s). Can you be bothered? It really should not take you that much time.

[kieranrk]

It's BD compliant now, amazing quality, it's free, but I still don't know any place which uses it, why?


There are 3 authoring houses, one of which is very large, and 2 independent film makers who are using x264 for creating Blu-Rays.

[kolak]

There are 3 authoring houses, one of which is very large, and 2 independent film makers who are using x264 for creating Blu-Rays.

If I would open my company I would probably also use it :)

x264 does not blend nicely into typical workflow, but I hope it will change.

Andrew

[kolak]

Yes, but some of us would have interest in a comparison sample(s). Can you be bothered? It really should not take you that much time.

x264 is not a clear winner at BD bitrates, so the best is to have more than 1 encoder.

Andrew

[nm]

x264 is not a clear winner at BD bitrates, so the best is to have more than 1 encoder.

Like jethro, I'm also interested in seeing this myself. Not that I could afford CCE anyway, but I'd like to see what I'm missing.

[kolak]

Like jethro, I'm also interested in seeing this myself. Not that I could afford CCE anyway, but I'd like to see what I'm missing.

Speed and great features in terms of usability/reviewing your encodes. 100% BD compatibility and very good support.

Typical x264 use does not put almost any limitation on it- but BD spec is very limited. Once you put BD limits on x264 its advantage is not so obvious, but still you can get amazing quality. All Pro encoders are designed only for BD usage and tweaked for this purpose only, so they're not a competition for x264 for eg. web encoding.


Andrew

[nm]

Speed and great features in terms of usability/reviewing your encodes. 100% BD compatibility and very good support.

While the UI stuff is important for an authoring workflow, I'm personally only interested in the encoder component: mainly quality/speed and secondarily in achieving good results with Blu-ray-compatible settings. If you can show us where x264 fails compared to <insert a pro encoder>, it might spark some ideas in improving x264.

[shon3i]

it might spark some ideas in improving x264

Here is conclusion from one of people (mp3dom) that daily author BD, and he comparing x264 to Blu-Code and CCE-HD.


The Pro:
- Free: This is, I think, the main pro. It's free while the pro-encoders cost at least (now) 30.000+ $. It's a great difference. Surely who can't (or don't want to) spend so much can put an eye to x264 which is surely the best free encoder available.
- Picture quality: The picture quality is very high. Currently I think that in the middle-lower bitrate range (< 15/20 Mbps for 1080p) no one can beat x264 since it can produce impressive quality. At 25-40 Mbps range x264 can produce better pictures quality for really difficult scenes (I mean, scenes that will be hardly available in real life encoding like filming a closeup of a riverbed with slight water, anyway it's right to say it!). Really cool! Smiley
- Avs/other support: The fact that it supports AviSynth and other codecs is another plus. Who need to filter/adjust the source can use filtered lossless YV12 files and fed it to the encoder without colorspace conversion.

The Cons:
- Speed: Actually (compared to other pro-encoders) the speed is low. At 25-40 Mbps range (excluding the really hard scenes previously mentioned) the quality of pro-encoders match the x264 output (with veryslow+subme 10+merange 64) but the speed of the pro-encoders is at least 8x fast. If I lower the x264 settings (to match the speed) the picture quality is visible inferior. This, anyway, is not a big problem, since we're speaking of a free encoder and if the picture quality is the most important thing I'll wait without much trouble.
- Color banding/gradients smoothing: I think IMHO that actually x264 put more efforts to offer great picture quality on complex scenes than trying to save color banding or subtle grain. For reference, Blu-Code is somewhat inferior on really complex scenes but this is noticeable only on a frame-by-frame comparison and not (or not so much) on a normal view. On the other hand, it saves color banding (and preserve color smoothing) in a better way (it has a special option and presets) and this is noticeable on a normal view since the problem is visible also (or above all) on static scenes. To obtain similar results in x264 I need to add gradfun2db or subtle grain to preserve the smoothing but this introduce some visible grain which is not great if you have a "flat" image (but also is somewhat different from the original master). Since I mainly work with animation, this is my main 'problem' with x264.
- Grain retention: Like color banding, the grain retention (even with the tune grain preset) in x264 is somewhat inferior to the pro-encoders (and I'm speaking of 30+ Mbps avg bitrates). There are frames where the grain is well mantained but other frames shows grain+flat microblocks which is somewhat not really acceptable for BD at those bitrates (30+ Mbps avg). Also on dark scenes (near black/dark gray) sometimes you can see some microblocks with subtle color difference (ie. dark gray background with some dark gray microblocks that shows a slight green tint). This is not a problem of calibrated monitor, since I look the results on an hardware calibrated pro-monitor (for reference, the DeltaE of the calibration is less than 0.5)
- Fades: Even with weightp 2, the fades shows often macroblocks problem in some frames. For reference, Blu-Code (and up) encoder has routines to 'catch' fades and treat it in a different way (don't know if x264 has something similar but, anyway the results of x264 is poorer compared to what other pro-encoders can produce). I've downloaded the x264 Demo BD and (for example) I can says that frames 5-7-9-11-13-15-17-18-21 (the first fade in) of BigBuckBunny shows this problem. If the source has subtle grain the result is even worst due to the facts that the macroblocks kills the grain so this is even more noticeable. I know that BBB doesn't have weightp 2 and max bitrate is limited, but this problem comes even at high bitrates and with weightp enabled (sure the problem is less pronounced at high bitrates, but the effect is similar). I was able to mitigate (in part or at all) this problem disabling mbtree, set trellis to 0 and deadzone (intra/inter) to 0.
- Segment encoding: I don't pretend x264 to support segment encoding in any way, but I wrote here for reference, that this is a big 'plus' for other pro encoders since it allows not only to re-encode some difficult parts of the stream but also to change settings for particular or different footage. For example one movie can have some scenes with film grain while others could be clean or shows some banding problem on some scenes. This can allow to treat different scenes with different settings. In x264 it could be do in same thing using zones of course (great parameter!) but this require even more time to obtain a final stream because you need first to encode the film (crf or 2 pass), then watch the movie and write down the part that need special treatment and then redo the full encoding again from start but with zones parameter (like I current do).

At the end I think that *actually* x264 is not well suitable for commercial BD encodings. Anyway, since the topic says "improvements discussion", I will be really happy if x264 can have a better grain/banding/color smoothing retention. Regarding fades, if it could 'catch' fades and apply special settings automatically (I mean if the bitrate is high and x264 catch a fade, it could set mbtree/trellis/deadzone/other settings automatically, regardless the settings you could use in the CLI) it could be very useful.

Thanks for the attention.


source: http://doom10.org/index.php?topic=298.0

I completly agree with this statement.

[nm]

Here is conclusion from one of people (mp3dom) that daily author BD, and he comparing x264 to Blu-Code and CCE-HD.

[...]

I completly agree with this statement.

Could you post a sample Blu-code/CCE-HD/... encode from publicly available lossless source(s) that exhibits your pet peeve issue? A speed comparison might also be insightful, although difficult to control and check.

[shon3i]

Could you post a sample Blu-code/CCE/... encode from publicly available lossless source(s) I wish if i could. I will also thinking to upload parkjoy sample for Dark Shikari test, which is extremly interesting result, but i don't want to risk.

[poisondeathray]

I wish if i could. I will also thinking to upload parkjoy sample for Dark Shikari test, which is extremly interesting result, but i don't want to risk.

I don't understand what is the risk shon3i ?

Would it be misallocation of company resources or something like that ?

[kolak]

Could you post a sample Blu-code/CCE-HD/... encode from publicly available lossless source(s) that exhibits your pet peeve issue? A speed comparison might also be insightful, although difficult to control and check.

There is no problem to measure speed.
You do both encodes from the same uncompressed source on the same PC and that's all.
x264 will be much slower on pressets, which give about the same quality- simple.


Andrew

[kolak]

Here is conclusion from one of people (mp3dom) that daily author BD, and he comparing x264 to Blu-Code and CCE-HD.



source: http://doom10.org/index.php?topic=298.0

I completly agree with this statement.

I agree with most of it if not all.
Speed, lack of segment re-encode and difficult reviewing of your encodes are the biggest issues.

Andrew

[nm]

There is no problem to measure speed.
You do both encodes from the same uncompressed source on the same PC and that's all.
x264 will be much slower on pressets, which give about the same quality- simple.
The problem is that only few people here have access to the same professional encoders, so checking the results is slightly difficult. That means we'll just need to take your word for it. :)

But throw us some sample streams, pretty please.

[kolak]

The problem is that only few people here have access to the same professional encoders, so checking the results is slightly difficult. That means we'll just need to take your word for it. :)

But throw us some sample streams, pretty please.

Exactly, so you can't tell that pro encoders are crap.
There are many amazing BDs out there which were done with pro encoders, so they are not crap.

If x264would be much better at BD bitrates everyone would be using it. It can match, outperform, or being worse on some source, but overall it's slower and does not fit well in workflow, so big studios are not jumping into it. They've already paid their money for pro encoders and untill they see clear advantage there is no need for change.
If you setup small compnay x264 is the first thing to try for encoding part.


Andrew

[nm]

Exactly, so you can't tell that pro encoders are crap.
There are many amazing BDs out there which were done with pro encoders, so they are not crap.

I've never said or implied that they would be. As for x264 developers, they are proud of their software and are quick to dismiss claims without concrete evidence. For example the 8 times faster encoding speed compared to x264, which is one of the most optimized piece of x86 software around, is so extraordinary that it's difficult to swallow without any proof whatsoever.

If x264would be much better at BD bitrates everyone would be using it. It can match, outperform, or being worse on some source, but overall it's slower and does not fit well in workflow, so big studios are not jumping into it. they already paid their money for pro encoders and untill they see clear advantage there is no need for change.

Ok. I think your point has been made and we can proceed with the interesting stuff. Samples?

[kolak]

I've never said or implied that they would be. As for x264 developers, they are proud of their software and are quick to dismiss claims without concrete evidence. For example the 8 times faster encoding speed compared to x264, which is one of the most optimized piece of x86 software around, is so extraordinary that it's difficult to swallow without any proof whatsoever.



I didn't say 8x.
I would say at few times. This makes massive difference-time is money and you can't afford encodes at 2-8fps/sec.

Try yourself- yuv source 30Mbit average, BD limitations with slow presets. To match pro encoders quality you need slow or very slow pressets to be used.

Cinemacraft does RT or faster. Blu-code hal RT or fatser (on modern 8 core machine), but it supports farm encoding, so you can use all PC in your studio and can have even 3 times faster than RT :)
You can setup 8 encodes for night and have all done during night- using all PC in your studio.


Andrew

[poisondeathray]

but it supports farm encoding

Which one? Blu-code or CCE-HD or both ?

[kolak]

Which one? Blu-code or CCE-HD or both ?

Blu-code supports farm encoding. You can add many machines and all easy and no additional fees.
CC-HDe not, but it's very fast on one machine. It does 3D encoding at about RT also.

Andrew

[poisondeathray]

Is the license cost different for additional machines ?

[kieranrk]

It can match, outperform, or being worse on some source, but overall it's slower and does not fit well in workflow, so big studios are not jumping into it.

As I have said already big studios are already jumping into (sic) it. There are at least half a dozen replicated discs either fully or partially encoded with x264 out there.

[kolak]

Is the license cost different for additional machines ?

No.

Andrew

[kolak]

As I have said already big studios are already jumping into (sic) it. There are at least half a dozen replicated discs either fully or partially encoded with x264 out there.

Good- this may lead to nice GUI.

Andrew

[poisondeathray]

Blu-code supports farm encoding. You can add many machines and all easy and no additional fees.



Thanks, Sorry I didn't see your earlier reply before posting :)

[kieranrk]

Good- this may lead to nice GUI.


Yes, somebody is writing a GUI.

[Lyris]

KieranRK: I notice on your site you mention that versions of "Amelie" and "Crouching Tiger Hidden Dragon" have been encoded with x264. What versions? Are they releases in Spain?

Do you know of any other replicated titles using it - you mentioned half a dozen? It's all very exciting.

[mp3dom]

"La tigre e il dragone" and "Il favoloso mondo di Amelie" are italian translations, so probably Kieranrk refers to 2 italians BD. The distributor is 01/BiM but I don't know which italian authoring house made it (I don't own the titles, but as I've red it now I'm just too curious to know it so probably I'll go to some Blockbuster to rent it :)).
So, kieranrk, if I'm not wrong, they've used x264 to encode only the menu right? (or the whole disc?)

[kolak]

"La tigre e il dragone" and "Il favoloso mondo di Amelie" are italian translations, so probably Kieranrk refers to 2 italians BD. The distributor is 01/BiM but I don't know which italian authoring house made it (I don't own the titles, but as I've red it now I'm just too curious to know it so probably I'll go to some Blockbuster to rent it :)).
So, kieranrk, if I'm not wrong, they've used x264 to encode only the menu right? (or the whole disc?)

There is nothing to be scared about to use x264 until disc will go through Sony's verifier. I would not do it without verification at this moment.


Andrew

[shon3i]

There is nothing to be scared about to use x264 until disc will go through Sony's verifier. I would not do it without verification at this moment.


Andrew
x264 is pass verification using Sony verifier without problems. Criterion Collection confirms, and i verified using sony verifier dozen times. So there is no problem, x264 produce compilant BD stream.

[mp3dom]

I'm not scared, I was just only curious to know the authoring house. :) Anyway I've replicated a BD disc with valid pass of Sony verifier (x264 was used to encode 2 extras). Luckily no disc were reported to malfunctioning due to the encoding so I'm assuming all went ok. The disc was made some time ago, when Open-GOP was not yet committed.

[kolak]

x264 is pass verification using Sony verifier without problems. Criterion Collection confirms, and i verified using sony verifier dozen times. So there is no problem, x264 produce compilant BD stream.

That's why I said- for now.
I know that many streams were verified and fine, but I would still not risk, especially where there is no one to blame :) It's a bit to early for me, but no once it's verified than no problem.


Andrew

[Dark Shikari]

That's why I said- for now.
I know that many streams were verified and fine, but I would still not risk, especially where there is no one to blame :)What you are posting is called FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt). Stop it. If you cannot post based on facts, don't post at all.

[kolak]

What you are posting is called FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt). Stop it. If you cannot post based on facts, don't post at all.

Ok- do you give me ( as a main x264 developer) guarantee that if I make a disc replicated in 200K copies and there are playback issues (due to not valid video stream) you will cover the cost of recalling it from the market?

Andrew

[Dark Shikari]

Ok- do you give me ( as a main x264 developer) guarantee that if I make a disc replicated in 200K copies and there are playback issues (due to not valid video stream) you will cover the cost of recalling it from the market?

AndrewThat would be the job of the validator manufacturer. If a stream passes validation, but does not play due to being invalid, it means the validator failed to perform its task, and the validator manufacturer is liable.

Again, I would like to remind you that this is FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Microsoft), the same tactic used by SCO and Microsoft for years against free software. By using it, you are just as bad as Darl McBridge and the SCO Group.

[kolak]

That would be the job of the validator manufacturer. If a stream passes validation, but does not play due to being invalid, it means the validator failed to perform its task, and the validator manufacturer is liable.

No- replication plants has nothing to do with validating video compatibility.
They are only responsible for disc being properly pressed and being identical to the image delivered for replication.
It's authoring house responsibility to make sure that all assets are compliant.


Andrew

[mp3dom]

We all knows that in case of so high number replications, no one would take responsability and re-doing the full project again and replication for 'free' is a big money loss. In that case I agree with kolak. It's better to stay on the safe side.
For lower replication (may I say... below 2.000 copies?) you can better take some risks... and infact x264 is more suited for independent labels/distributor that press lower copies than a big major (plus it's free ).

Alternatively, you can send the BD to studios that check compatiblity with a vast amount of players. In that case if the video is invalid they're responsible of the 'validation'... but in general this step is expansive.

[kieranrk]

KieranRK: I notice on your site you mention that versions of "Amelie" and "Crouching Tiger Hidden Dragon" have been encoded with x264. What versions? Are they releases in Spain?


They are Italian releases. Those are the only replicated titles I have names for and which I can post on the site right now.

Ok- do you give me ( as a main x264 developer) guarantee that if I make a disc replicated in 200K copies and there are playback issues (due to not valid video stream) you will cover the cost of recalling it from the market?


This is totally ridiculous. Virtually all commercial and open source software is released WITHOUT WARRANTY and there is almost certainly no warranty in the EULA of any of the "pro" encoders. A software manufacturer is not liable for any issues that occur with the software. The user has to conduct their own due diligence (i.e test it in a verifier). For example if business documents are corrupted because Microsoft Office fails it is NOT the fault of Microsoft - you have no legal claim against them.

[kolak]

We all knows that in case of so high number replications, no one would take responsability and re-doing the full project again and replication for 'free' is a big money loss. In that case I agree with kolak. It's better to stay on the safe side.
For lower replication (may I say... below 2.000 copies?) you can better take some risks... and infact x264 is more suited for independent labels/distributor that press lower copies than a big major (plus it's free ).

Alternatively, you can send the BD to studios that check compatiblity with a vast amount of players. In that case if the video is invalid they're responsible of the 'validation'... but in general this step is expansive.

Yes- one of our clients was using Testronics for every DVD project- it's expensive. They test on 25 most buggy players and spot check on others. After many projects and no issues they decided not to do it. They still do it for BD.


Andrew

[kolak]

They are Italian releases. Those are the only replicated titles I have names for and which I can post on the site right now.



This is totally ridiculous. Virtually all commercial and open source software is released WITHOUT WARRANTY and there is almost certainly no warranty in the EULA of any of the "pro" encoders. A software manufacturer is not liable for any issues that occur with the software. The user has to conduct their own due diligence (i.e test it in a verifier). For example if business documents are corrupted because Microsoft Office fails it is NOT the fault of Microsoft - you have no legal claim against them.

As far as I know there is some limited warranty and if problem is in the software than you can try to get some money back.

Andrew

[Dark Shikari]

We all knows that in case of so high number replications, no one would take responsability and re-doing the full project again and replication for 'free' is a big money loss. In that case I agree with kolak. It's better to stay on the safe side.
For lower replication (may I say... below 2.000 copies?) you can better take some risks... and infact x264 is more suited for independent labels/distributor that press lower copies than a big major (plus it's free ).And do you think Microsoft will compensate you if Excel eats your accounting documents?! Hint: no.

Commercial software is no "safer" than open source, nor does it have any more of a warranty. And clearly people in the business aren't actually worried, considering an extremely major authoring house is now moving to x264 for major titles.
As far as I know there is some limited warranty and if problem is in the software than you can try to get some money back.

AndrewThe amount you can get back is limited to the price of the software, i.e. totally useless.

With free software, you can at least blame the people who wrote the code. With commercial software, there is no responsibility at all, no guarantee, no warranty!

[kolak]

And do you think Microsoft will compensate you if Excel eats your accounting documents?!

Commercial software is no "safer" than open source, nor does it have any more of a warranty. And clearly people in the business aren't actually worried, considering an extremely major authoring house is now moving to x264 for major titles. ;)
The amount you can get back is limited to the price of the software, i.e. totally useless.

Good- anyone can move.

Lets wait for official announcement because for now there are titles, companies using x264, but no names :)
It's fair to me to say this being accused that I don't provide any files, etc.


Andrew

[kieranrk]

Lets wait for official announcement because for now there are titles, companies using x264, but no names :)


Why would a company need to announce they're using x264?

[kolak]

Why would a company need to announce they're using x264?

The don't need.

I don't know- some tell what they use. If x264 is the best than why not?


Andrew

[mp3dom]

And do you think Microsoft will compensate you if Excel eats your accounting documents?! Hint: no.
Absolutely not, but you can overcome this. For important files you can have backups or mirrors or everything else. In case of video encodings, the pro-encoders are certified (and advertised) to be 100% in BD-specs (that is anyway different to say: "it pass the verification of Sony verifier"). For example the old problem of x264 regarding buffer underflow under some circumstance was 'fixed' only thanks to the long perseverance of shon3i after he made a lot of tests comparing the results of x264 with other 'certified' pro-encoders. (I had too the same problem...maybe shon3i remember this). Previously the problem was indicated as 'bad muxers' or 'bugs of Scenarist'.


Commercial software is no "safer" than open source, nor does it have any more of a warranty.
They're no safer, but the facts that they're more 'used' somewhat are more 'safer' or less prone to compatibility problems.
For x264 there are actually too low response IMHO from the 'BD world' to say that it's 100% in specs or to risk a high replication number.


And clearly people in the business aren't actually worried, considering an extremely major authoring house is now moving to x264 for major titles.

I'm anxious to see those streams and the settings used (if they ever keep it in the header, but I don't think they'll keep it). I'm curious to see if they'll use all the x264 features (open-gop, weightp 2, values of psy-rd etc) or if they'll limit something. Also, I will be very happy to do a full BD with x264 if some developer is disposed to follow and help me choosing right settings or fine-tuning the encoder for particular footage (i.e. keeping color smoothing/subtle grain across an entire film without altering the quality of all the rests, etc)

[kieranrk]

I'm anxious to see those streams and the settings used (if they ever keep it in the header, but I don't think they'll keep it). I'm curious to see if they'll use all the x264 features (open-gop, weightp 2, values of psy-rd etc) or if they'll limit something.

They use the settings in my guide.


Absolutely not, but you can overcome this. For important files you can have backups or mirrors or everything else. In case of video encodings, the pro-encoders are certified (and advertised) to be 100% in BD-specs (that is anyway different to say: "it pass the verification of Sony verifier"). For example the old problem of x264 regarding buffer underflow under some circumstance was 'fixed' only thanks to the long perseverance of shon3i after he made a lot of tests comparing the results of x264 with other 'certified' pro-encoders. (I had too the same problem...maybe shon3i remember this). Previously the problem was indicated as 'bad muxers' or 'bugs of Scenarist'.


If you modify settings while not actually knowing what you're doing, what do you expect? Bad user input is not a bug. For the record it was Trahald that found out the answer.

[kolak]

Absolutely not, but you can overcome this. For important files you can have backups or mirrors or everything else. In case of video encodings, the pro-encoders are certified (and advertised) to be 100% in BD-specs (that is anyway different to say: "it pass the verification of Sony verifier"). For example the old problem of x264 regarding buffer underflow under some circumstance was 'fixed' only thanks to the long perseverance of shon3i after he made a lot of tests comparing the results of x264 with other 'certified' pro-encoders. (I had too the same problem...maybe shon3i remember this). Previously the problem was indicated as 'bad muxers' or 'bugs of Scenarist'.


They're no safer, but the facts that they're more 'used' somewhat are more 'safer' or less prone to compatibility problems.
For x264 there are actually too low response IMHO from the 'BD world' to say that it's 100% in specs or to risk a high replication number.


I'm anxious to see those streams and the settings used (if they ever keep it in the header, but I don't think they'll keep it). I'm curious to see if they'll use all the x264 features (open-gop, weightp 2, values of psy-rd etc) or if they'll limit something.

Yep- you have to work in industry to understand this.

Making disc, which is going be replicated in big numbers is not the same as ripping BD for playback on iPod.


Andrew

[kolak]

What has change in last few months regarding using x264 for BD encoding?

Open Gop has been added? Anything else?


Thanks,
Andrew

[kolak]

They use the settings in my guide.




If you modify settings while not actually knowing what you're doing, what do you expect? Bad user input is not a bug. For the record it was Trahald that found out the answer.

You should write note how to change max bitrate. Also I would suggest to use 39Mbits instead of 40Mbit- just for safety. No one will notice this 1Mbit difference, but you not pushing standard/player to limits.

Chapters is not an advanced feature- it's very basic one when you do proper disc.


Andrew

[kieranrk]

You should write note how to change max bitrate. Also I would suggest to use 39Mbits instead of 40Mbit- just for safety. No one will notice this 1Mbit difference, but you not pushing standard/player to limits.


If it makes you feel better by all means do so.

Chapters is not an advanced feature- it's very basic one when you do proper disc.

Clarified this point.

[mp3dom]

They use the settings in my guide. Ok, thanks.


If you modify settings while not actually knowing what you're doing, what do you expect? Bad user input is not a bug.

You can't say this (at least in this case) because *no one* is supposed to know that vbv-bufsize should never been greater than vbv-maxrate especially when you see that other 'encodes' have a max bitrate of 20 Mbps while keeping (fake?) the buffer size to 30 Mbps. It's a technical information that can have who own the specs (encoder developers) but not all authoring studios (also in your guide/template you never say that so a normal user is prone to made errors if he lowers the vbv-maxrate to 20 Mbps and keeps the vbv-bufsize to 30 Mbps). You can't assume for sure that we are all developers that own the BD specs. Infact with pro-encoders you can't made operations out-of-specs while with x264 you can. This is the main problem that you (developers in general) are understimating.

If you really want to say that the x264 output is 100% bd certified, you should not allow to output an out-of-spec stream in any way. If Warner (example) made 1 million BDs 'out-of-specs' are you brave enough to say to them that they're all stupids because they've inserted bad parameters?


For the record it was Trahald that found out the answer.
I remember it was Trahald, anyway thanks for pointing out.
Luckily Trahald is a developer who thought at that time that 'maybe' the problem could be inside x264. Dark Shikari for example always (IMHO) assume that x264 is bug less and the faults comes always from others.

[shon3i]

For the record it was Trahald that found out the answer. Luckily, Trahald is only developer who wanted to drive this issue to the end. Mine first assumption that things going crazy after CPB removal delay jump over 1 sec. And luckily Trahald found drmpeg posts that confirm this, but after serious testings, with comparing x264 VBV model to "pro" encoders VBV model, Trahald is examine all of this "pro" streams, and based on this make numerious of special patches that aslo i tested several times and it's take few days/weeks, after we basicly conclude that CPB > 1sec is definitly problem, but drmpeg post make this officialy.

And we know that --vbv-maxrate 24000 --vbv-bufsize 30000 is not illegal option for Blu-Ray as long CPB delay is not >1. That is completly fine, no matter how is pointless.

[kolak]

Kieranrk, your site links to the latest build.

How reliable is latest build in terms of BD compliancy?
What are the chances that latest build breakes it?


Thanks,
Andrew

[kieranrk]

How reliable is latest build in terms of BD compliancy?
What are the chances that latest build breakes it?


Unlikely. Dark Shikari runs many regression tests before pushing.

[Blue_MiSfit]

Very unlikely. Besides, 1745 has been out for quite awhile now (several weeks, which is a fairly long time for x264 updates). This is usually a good sign ;)

Derek

[Lyris]

If you really want to say that the x264 output is 100% bd certified, you should not allow to output an out-of-spec stream in any way. If Warner (example) made 1 million BDs 'out-of-specs' are you brave enough to say to them that they're all stupids because they've inserted bad parameters?
That's the golden issue, I think. As we can see in this thread, disc authors who are stamping out thousands of copies are quite rightly completely paranoid (myself included). When x264 appears promising BD compliance with outstanding picture quality, people naturally think it's too good to be true.

Of course, x264 was not just written for people wanting to produce BD compliant video and you can easily make a mistake with it. I suppose the BD-centered GUI will mitigate those fears?

I'm glad to hear that new versions are unlikely to break compliance. This was a fear on the back of my mind. (Like I said - paranoid. I have had a compatibility issue before and it's no fun).

[kolak]

Very unlikely. Besides, 1745 has been out for quite awhile now (several weeks, which is a fairly long time for x264 updates). This is usually a good sign ;)

Derek

Ok- good to know.


Andrew

[kieranrk]

If you really want to say that the x264 output is 100% bd certified, you should not allow to output an out-of-spec stream in any way.

If you follow the instructions your stream will be compliant. Would you blame a car manufacturer for someone driving a car off a cliff?

[kolak]

If you follow the instructions your stream will be compliant. Would you blame a car manufacturer for someone driving a car off a cliff?

Do you mean- I can only copy and paste your command line?
What if my B frames are much worse than others and I want to fix this?

Andrew

[Blue_MiSfit]

If you really want to say that the x264 output is 100% bd certified, you should not allow to output an out-of-spec stream in any way.


This could probably be accomplished with a --tune bluray or --enforce bluray preset, if such a thing were deemed important enough by the developers.

As we all know, x264 is much more than a BluRay encoder ;)

Derek

[kieranrk]

What if my B frames are much worse than others and I want to fix this?


What do you mean by "B frames are much worse than others"?

[mp3dom]

If you follow the instructions your stream will be compliant.
If I have 20 mbps of audio stream and I follow your guide, the final file will be rejected due to the fact that you specify maxrate of 40 mbps. After the Scenarist error message (bitrate too high) a user probably understand that it needs to lower the bitrate so the first thing he can think of is to lower the vbv-maxrate to 20 mbps. How do you think that the user automatically will lower the vbv-bufsize on his own? This cover the casual user. A BD employee already knows to lower the bitrates so it would change your profile changing only vbv-maxrate but not vbv-bufsize because: A) It's not a required knowledge for this kind of user B) It's not required at all with any other 'bd-certified' encoder

Would you blame a car manufacturer for someone driving a car off a cliff?
No, but I blame if the car manufacturer advertise that the car has the highest top speed of all the competitors without saying that this supremacy is met only on downhill by a F1-pilot.

[kolak]

What do you mean by "B frames are much worse than others"?

Much worse quality. Happened on the first source file, which I have tested- 60i live recording.


Andrew

[poisondeathray]

What if my B frames are much worse than others and I want to fix this?



Many people reduce the ipratio (and pbratio if not using mb-tree) . You will get more even distribution between frametypes

[Blue_MiSfit]

If I have 20 mbps of audio stream and I follow your guide, the final file will be rejected due to the fact that you specify maxrate of 40 mbps. After the Scenarist error message (bitrate too high) a user probably understand that it needs to lower the bitrate so the first thing he can think of is to lower the vbv-maxrate to 20 mbps. How do you think that the user automatically will lower the vbv-bufsize on his own? This cover the casual user. A BD employee already knows to lower the bitrates so it would change your profile changing only vbv-maxrate but not vbv-bufsize because: A) It's not a required knowledge for this kind of user B) It's not required at all with any other 'bd-certified' encoder


No, but I blame if the car manufacturer advertise that the car has the highest top speed of all the competitors without saying that this supremacy is met only on downhill by a F1-pilot.

@mp3dom:
You're missing the distinction between a GUI and an encoder :)

x264 does as it's told. Adjusting bufsize / maxrate to account for other streams is the job of the user or calling application (i.e. an encoding GUI).

@kolak:
I'd be interested to see this case, can you upload a small sample?

Derek

[shon3i]

How do you think that the user automatically will lower the vbv-bufsize on his own?And buffer size is untouchable option in most encoders. I think option like --device bluray will be compromise and safety switch that always execute after all switches and check is everything fine, if not automaticlly reduce all need options. In that way command line for blu-ray will be much simpler.

[poisondeathray]

Who is working on the GUI ? or is it super-duper top secret ?

These are some good ideas tossed around here that might help to improve the GUI and/or make it more user friendly

[mp3dom]

And buffer size is untouchable option in most encoders. I think option like --device bluray will be compromise and safety switch that always execute after all switches and check is everything fine, if not automaticlly reduce all need options. In that way command line for blu-ray will be much simpler.

Exactly, or at least put some warnings in the CLI (if someone wants to keep the encoder 'engine' free of any restriction) as already happends for parameters that can potentially compromise the final output.

[Eric69]

Can x264 insert I Frames for chapter marks? That is a pretty big deal in a professional encoder.

[kolak]

Many people reduce the ipratio (and pbratio if not using mb-tree) . You will get more even distribution between frametypes

Yes- it did help, but this is fine tuning and I don't know if it can break BD compatibility. I assume it does not.


Andrew

[poisondeathray]

Can x264 insert I Frames for chapter marks? That is a pretty big deal in a professional encoder.


yes, using a qpfile
http://sites.google.com/site/x264bluray/advanced-features/chapters
http://mewiki.project357.com/wiki/X264_Settings#qpfile

But it would be nicer if a GUI made it more user friendly to do

[kolak]

Has this problem being fixed?

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


Andrew

[shon3i]

But it would be nicer if a GUI made it more user friendly to do
yep, http://forum.doom9.org/showthread.php?t=150148

[poisondeathray]

^ Nice work shon3i :)

[Blue_MiSfit]

Very cool!! Well done, shon3i!

[Dark Shikari]

Yes- it did help, but this is fine tuning and I don't know if it can break BD compatibility. I assume it does not.Changing the quality of the video obviously does not affect Blu-ray compatibility; don't be thick.

Also, --tune grain already does this.

[laserfan]

Can x264 insert I Frames for chapter marks? That is a pretty big deal in a professional encoder.
The Google link above talks about K frames while shon3i's ChapterGen makes qpfiles with I frames. Which is correct for ID'ing frames for Chapters?

[J_Darnley]

The Google link above talks about K frames while shon3i's ChapterGen makes qpfiles with I frames. Which is correct for ID'ing frames for Chapters?

I will force an IDR frame, K will force a keyframe. These are only different when using open-gop.

[shon3i]

I will force an IDR frame, K will force a keyframe. These are only different when using open-gop.
'Keyframe' or K is a generic keyframe/seekpoint type that equates to a IDR I-Frame if --open-gop is none, otherwise it equates to a Non-IDR I-Frame flagged with the Recovery Point SEI

Which K practicly not good if open-gop is used, because authoring apps expect an IRD I frame. Otherwise will get tons of warnings of missed chapter points.

[laserfan]

Hmmm OK I guess I will stick with using I instead of K then, as it always seems to work (and I do typically use open-gop).

[shon3i]

Hmmm OK I guess I will stick with using I instead of K then, as it always seems to work (and I do typically use open-gop).
I don't know what muxer you use, but with Scenarist and Blu-Print K and open-gop will not go.

[kolak]

I don't know what muxer you use, but with Scenarist and Blu-Print K and open-gop will not go.

BD spec does not require I frames on chapters, but it's way better to have them.

Andrew

[kolak]

Tried lates x264on 8 core machine.

Source- old, grainy film. Command line from kieranrk guide for 1080p (veryslow changed to slow)

First pass:
slow= 14fps
2nd pass:
slow= 9fps

Veryslow is unusable in real world (case of authoring house)- speed is 2fps for 2nd pass.

Changing to tune grain helped, but still grain gets softend.

update:

It looks like x264 falls only on openig bit, where there are pans over water. Once it gets to "normal" scenes than quality is very good. Shame that there is no segment re-rencode :)

Does lowering PSY at high bitrates help?
There are some parts of the frame which gets distorted- is it due to PSY? It looks a bit strange- nice frame with patches of worse qulity.

Sample frame (ignore red painting please):

http://rapidshare.com/files/429589247/sample.rar


Andrew

[shon3i]

I think that is product of Psy-trellis, if you use enough bitrate try to disable whole Psy-RDO or just Psy-Trellis.

[Dark Shikari]

First pass:
slow= 14fps
2nd pass:
slow= 9fpsDude, you're input-bottlenecked. Stop complaining x264 is slow when you can't even make your input faster than 14fps. :rolleyes:

[kolak]

Dude, you're input-bottlenecked. Stop complaining x264 is slow when you can't even make your input faster than 14fps. :rolleyes:

Dude - I have 16 disks raid :) About 450MB/sec is my limit due to 4Gbit FC connection, so please stop.

When I ask simple, direct question almost never get answer, just your funny assumptions. What about quality problem? This kind of patches are unacceptable at 30Mbit.

What is the "correct" speed for slow pressets on 8 core (2x E5450 Xeons, 8Gb of RAM) machine?


Andrew

[shon3i]

You can have a space shuttle, but you still have bottleneck. There is something that use resources. I have better speed on my QuadCore Phenom than you, obviously you not doing something properly

[kolak]

Slow pressets?

Hmmm- what bottleneck?

I have 30-50% CPU usage during 1st pass and 90-100% during 2nd. Is this correct?
No poblem for CC-HDe to do about 18fps, same source, same machine, same time.

If there is a problem than I relay want to sort it out, but I can't see any.
What is the best source format for x264?

I'm not using any avisynth filtering- simple avisource.


Andrew

[shon3i]

On slow preset i have ~6-7fps > 30mbps @ 1080p24.

And i aslo use avisource or feed directly raw to x264.

I think your 18fps CEE is too slow also, last time i checked on mine home pc i aslo have almost realtime speeds.

[kolak]

On slow preset i have ~6-7fps > 30mbps @ 1080p24.

And i aslo use avisource or feed directly raw to x264.

I think your 18fps CEE is too slow also, last time i checked on mine home pc i aslo have almost realtime speeds.

You said you have it faster :)
These are not i7 Xeons, but old E5450.

CC-HDe realtime in Quality mode on 4 core machine? No way :) (maybe if you overclok it to 4GHz)

Andrew

[RunningSkittle]

on a stock Q6600 decoding 1080p vc-1 from the matrix-reloaded bluray, i get ~16+fps on first pass and ~6pfs on second with kierank settings and preset slow. This is with a slow aging IDE drive. Yours should be MUCH faster than mine.

[kolak]

on a stock Q6600 decoding 1080p vc-1 from the matrix-reloaded bluray, i get ~16+fps on first pass and ~6pfs on second with kierank settings and preset slow. This is with a slow aging IDE drive. Yours should be MUCH faster than mine.

Hollywood (also already encoded) sources are very easy.
I will try different source- easier one.
My CPU usage is about 100% during 2nd pass- can be source.

Andrew

[kolak]

On slow preset i have ~6-7fps > 30mbps @ 1080p24.

And i aslo use avisource or feed directly raw to x264.

I think your 18fps CEE is too slow also, last time i checked on mine home pc i aslo have almost realtime speeds.

yv12.avi would be the best?

Does tune grain make it slower?

Andrew

[nm]

What about quality problem? This kind of patches are unacceptable at 30Mbit.

Can you provide a source clip to reproduce the issue?

[kolak]

Can you provide a source clip to reproduce the issue?

No- it's a "proper" movie source.

I will download something public to check possible speed issues.

Andrew

[kolak]

on a stock Q6600 decoding 1080p vc-1 from the matrix-reloaded bluray, i get ~16+fps on first pass and ~6pfs on second with kierank settings and preset slow. This is with a slow aging IDE drive. Yours should be MUCH faster than mine.

I have Q9650, so can also try. Also (soon) on 12 core killer machine.

Andrew

[Blue_MiSfit]

kolak:

You're using AVISource on an uncompressed YV12 AVI file, or feeding raw input to x264, either of which is living on your uber-RAID, correct? Also, your RAID does have plenty of free space, correct? An uncompressed source should be the easiest and fastest possible input to x264 (i.e. using as little CPU time to decode as possible), provided your I/O can handle it. It sure seems like yours should be able do ;)

Regardless, seeing 100% CPU Usage on second pass does indicate that you're not I/O bottlenecked there at least.

Dark_Shikari et al, stop me if I'm wrong, but this info combined with ~50% utilization on first pass means (to me) that you're getting bottlenecked in first pass by frame type decision, which IIRC isn't multithreaded.. right?

Derek

[kolak]

kolak:

You're using AVISource on an uncompressed YV12 AVI file, or feeding raw input to x264, either of which is living on your uber-RAID, correct? Also, your RAID does have plenty of free space, correct? An uncompressed source should be the easiest and fastest possible input to x264 (i.e. using as little CPU time to decode as possible), provided your I/O can handle it. It sure seems like yours should be able do ;)

Regardless, seeing 100% CPU Usage on second pass does indicate that you're not I/O bottlenecked there at least.

Dark_Shikari et al, stop me if I'm wrong, but this info combined with ~50% utilization on first pass means (to me) that you're getting bottlenecked in first pass by frame type decision, which IIRC isn't multithreaded.. right?

Derek

My RAID and PC itself are absolutely fine.

This is the point- 100% CPU taken by x264 on 2nd pass.
I don't think 1st pass ever used 100% CPU.
I will try different source file- this one is very difficult.

Andrew

[Blue_MiSfit]

I have a machine free that should very closely match yours:

Dual 3GHz Quad-Core Xeons (X5450, older, hotter version of your E5450 CPUs. Same speed though)
4GB RAM
Server 2003 32 bit

My source will be a piece of a BluRay that I've remuxed to MKV. Granted not the same source, but if your I/O isn't a factor you should actually get (slightly) FASTER speeds, since you aren't spending any CPU time on decode.

I'm using the CLI suggested here http://sites.google.com/site/x264bluray/home/1080i-p target an average bitrate of 25mbps.

I'll update this post shortly with numbers for --preset slow and --preset veryslow

Finally, please don't post samples to rapidshare. Use mediafire, megaupload, or some other service that doesn't suck horribly. Thanks :)

Derek

[Blue_MiSfit]

OK so my performance numbers line up with yours, kolak. See below:


Dual X5450 CPUs - 8 physical cores
--preset slow:
First pass - ~40% CPU Usage, 13.46fps.
Second pass - 100% CPU Usage, 9.38fps

--preset veryslow:
First pass - ~40% CPU Usage, 13.45fps.
Second pass - 100% CPU Usage, 2.52fps


Also did a test on a system with dual X5570 CPUs (3 GHz Nehalem quad cores):


Dual X5570 CPUs - 8 physical cores, 16 logical cores

--preset veryslow:
First pass - ~40% CPU Usage, 14.94fps.
Second pass - 100% CPU Usage, 3.5fps


Performance sounds about right.

Anyone have ideas on why first pass doesn't scale to 100% usage? Only thing I can think of is the frame type decision (b-adapt 2), which IIRC isn't multithreaded. Am I correct here??

Derek

[kolak]

OK so my performance numbers line up with yours, kolak. See below:


Dual X5450 CPUs - 8 physical cores
--preset slow:
First pass - ~40% CPU Usage, 13.46fps.
Second pass - 100% CPU Usage, 9.38fps

--preset veryslow:
First pass - ~40% CPU Usage, 13.45fps.
Second pass - 100% CPU Usage, 2.52fps


Also did a test on a system with dual X5570 CPUs (3 GHz Nehalem quad cores):


Dual X5570 CPUs - 8 physical cores, 16 logical cores

--preset veryslow:
First pass - ~40% CPU Usage, 14.94fps.
Second pass - 100% CPU Usage, 3.5fps


Performance sounds about right.

Anyone have ideas on why first pass doesn't scale to 100% usage? Only thing I can think of is the frame type decision (b-adapt 2), which IIRC isn't multithreaded. Am I correct here??

Derek

Yep- about the same. Maybe you also have some bottleneck :)


Andrew

[Biggiesized]

Very unlikely. Besides, 1745 has been out for quite awhile now (several weeks, which is a fairly long time for x264 updates). This is usually a good sign ;)

Derek
Seriously, what's up with that?

I need to get my fix! It's been about a month!

[kolak]

Tried different source- quite clean, shot on RED.

Slow presset (tune film):

1st pass- 20fps
2nd pass- 14fps

There is quite big speed difference depending on the source nature.

Andrew

[shon3i]

You said you have it faster :)
These are not i7 Xeons, but old E5450.

CC-HDe realtime in Quality mode on 4 core machine? No way :) (maybe if you overclok it to 4GHz)

Andrew
It is faster i have ~7fps with 4 cores, you have ~9fps with 8 cores? Mine procesor is AMD Phenom I your is Intel, i think is from same era.

Btw you don't need to go with slower presets, you can just fine beat CEE with medium preset and you will definitly have more speed. CEE is faster because is not complex as x264 is, and output quality is superb because bitrate is huge. x264 on that bitrate can be safetly downgraded to lover presents eg medium, while keep quality. CCE will probably been better in fades, dark areas.

[kolak]

It is faster i have ~7fps with 4 cores, you have ~9fps with 8 cores? Mine procesor is AMD Phenom I your is Intel, i think is from same era.

Btw you don't need to go with slower presets, you can just fine beat CEE with medium preset and you will definitly have more speed. CEE is faster because is not complex as x264 is, and output quality is superb because bitrate is huge. x264 on that bitrate can be safetly downgraded to lover presents eg medium, while keep quality. CCE will probably been better in fades, dark areas.

It's not faster- my encode will be finished earlier:)

Also - look at my 2nd test :) x264 is sensitive for source nature- speed varies a lot.

With source, which I've tried x264 does not beat CC-HDe even at slow pressets. Some frames are better, but overall CC-HDe quality is more constant. x264 has very good, but also relatively bad frames.

Andrew

[shon3i]

It's not faster- my encode will be finished earlierYep, but not significant, you should get ~15fps for same commandline, also my processor is not clocked and work at default 2.2Ghz.

Difference in speeds with different way of feeding source mean bottleneck. Your decoder use significant process power to decode frames or something else. You maybe get more speed with CCE on way that x264 gives you higher speed.

[kolak]

Yep, but not significant, you should get ~15fps for same commandline, also my processor is not clocked and work at default 2.2Ghz.

Difference in speeds with different way of feeding source mean bottleneck. Your decoder use significant process power to decode frames or something else. You maybe get more speed with CCE on way that x264 gives you higher speed.

Look at me 2nd test :) I get 14fps for 2nd pass.

It depends what you feed into encoder. It also depends how encoder is sensitive for surces with different nature. Some are more some less.

I don't have any bottleneck on source stage- tried different sources- yv12, Canopus HQ and always the same.
Blue_MiSfit also getting the same speeds.
90% people test x264 with BD ripped sources- mostly nice film source alreday after encode- very easy to encode.

Try grainy source and you won't get 7fps on your machine :)

Tried turning off PSY- not good at all.

Andrew

[shon3i]

90% people test x264 with BD ripped sources- mostly nice film source alreday after encode- very easy to encode.Yes, but on my workplace i usualy encode from HD-SDI, yv12 or some lossless codec (huffyuv for example)

Tried turning off PSY- not good at all.What about --psy-rd 1.0:0 or --psy-rd 0.7:0??

[kolak]

Yes, but on my workplace i usualy encode from HD-SDI, yv12 or some lossless codec (huffyuv for example)

What about --psy-rd 1.0:0 or --psy-rd 0.7:0??

Tried --psy-rd 0.5:0.0 - also not good. Grain tends to be blocky.
Will try with 0.8.


Andrew

[Blue_MiSfit]

kolak,

Can you describe your encoding workflow in CCE-HDe? How many passes are you running? Any filtering, custom bit allocation / quantization, etc?

Also, you posted a file on rapidshare. Any chance you could post it somewhere actually usable, like mediafire etc?

Thanks!

Derek

[Biggiesized]

Or if you upload to Rapidshare, register an account so we can download the file more than 10 times.

[kolak]

kolak,

Can you describe your encoding workflow in CCE-HDe? How many passes are you running? Any filtering, custom bit allocation / quantization, etc?

Also, you posted a file on rapidshare. Any chance you could post it somewhere actually usable, like mediafire etc?

Thanks!

Derek

2 or 3. If there is a time 4.
I almost never use filtering. Just playing with Q Charasterictics, Quantize, sometimes Grain and Matrixes.
When needed use Region for tweaking bits allocation on the frame.

Next time won't use rapidshare:)

Andrew

[Blue_MiSfit]

kolak:

It's not really fair to compare x264 to manually tweaked CCE-HDe encodes, especially when it comes to region tweaking! If you do, at least make tweaks to zones in x264.

You might argue that we're comparing two encoders, but actually we're comparing two encoder CORES. CCE-HDe has a very full featured GUI wrapped around it, and x264 very well may have a similar GUI in the future. Let's keep things fair :)

Derek

[Dark Shikari]

It's completely braindead to make a comparison which consists entirely of "looking for areas that look bad" when, with one encoder, every time you see such an area, you go back and boost the quality with zones.

It's like comparing two books, except every time you find a part you don't like in one of the books, you rewrite it (but not the other one). Then, you declare the rewritten book to be the better one. This isn't just malicious, this is cheating.

[kolak]

kolak:

It's not really fair to compare x264 to manually tweaked CCE-HDe encodes, especially when it comes to region tweaking! If you do, at least make tweaks to zones in x264.

You might argue that we're comparing two encoders, but actually we're comparing two encoder CORES. CCE-HDe has a very full featured GUI wrapped around it, and x264 very well may have a similar GUI in the future. Let's keep things fair :)

Derek

Both encodes were simple 2 pass encodes- no tweaking.
This what I have said applies to my typical workflow- not for this test.
CC-HDe gives more consistent quality between frames.

DS- is not about some parts of the encode - is more about single frames or even parts on the single frame. Blu-code does the same, where CC-HDe will keep whole frame more constant in quality (also more constant quality between I,P and B frames).

I have not finished my test and waiting for suggestions.
You can quickly see quality differences between I,P,B frames with subtract option in avisynth. I frames are much better. What is the solution?

Tried playing with PSY, but it didn't help.

Andrew

[MasterNobody]

I have not finished my test and waiting for suggestions.
Suggestion. Stop posting until you provide samples and settings (so anyone can reproduce your results) to confirm that you don't lie/cheat :devil:. Because till now you only make bold statements without objective proofs.

[kolak]

Suggestion. Stop posting until you provide samples and settings (so anyone can reproduce your results) to confirm that you don't lie/cheat :devil:. Because till now you only make bold statements without objective proofs.

I've said what settings I have used. Gave a sample of a problematic frame. Also explained what are the problems with x264 encode and asked about solution.

Tried lowering PSY- not good at all.

Andrew

[MasterNobody]

I've said what settings I have used.
I never seen your full command lines.
Gave a sample of a problematic frame.You mean rapidshare crap link which return "The file of the above link no longer exists" and which 10 download limit was probably reached even before you posted the link :devil: ?
This can't be counted as sample.
Also you don't provide source sample so we can't say that it is not in the source. And again you don't want to use public available sources (without any real reason except trolling).
Also explained what are the problems with x264 encode and asked about solution.
We don't need yours explanations, we need real samples (both which you claim "good" and "bad").

[Blue_MiSfit]

Nobody can see your sample because you put it on rapidshare and that dies after only a few downloads!!

Please re-post this sample!

Also, MasterNobody is quite correct in saying that your explanations are simply not adequate for validating your claims. We need test cases that we can actually verify on our end.

Derek

[kolak]

Nobody can see your sample because you put it on rapidshare and that dies after only a few downloads!!

Please re-post this sample!

Also, MasterNobody is quite correct in saying that your explanations are simply not adequate for validating your claims. We need test cases that we can actually verify on our end.

Derek

Explanation is very clear- much better quality I frames (than P, B).
Patches of much worse quality areas on a single frame.

And please stop saying nonsense like- we don't know if it's not on the source :)

If you read my posts you will find command line:)

I can't provide this source file, because it's a "proper" film source.
I have Avatar trailer uncompressed source- do you think I can put it on the web?

Trying download this:

http://www.freehillproductions.com/RED/

Crossing The Line trailer. Shot on RED, ProRes source. This would be good source for testing.

Don't have this encode anymore- but can redo.

Andrew

[kolak]

Another test:

Source:

ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/1080p/

station2.yuv (fps assumed to 23.976)

x264 com:

x264 --bitrate 28000 --preset slow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 38000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1

3 random (25,26,27), consecutive frames (source, pro encoder, x264):

http://www.mediafire.com/?39n5lzrzj83zfqw

x264_V2 is the same command but with tune grain.


Andrew

[nm]

3 random (25,26,27), consecutive frames (source, pro encoder, x264):

http://www.mediafire.com/?39n5lzrzj83zfqw

The first x264 encode keeps grain/noise in the sky. The pro encoder flattens it and x264_V2 even more so.

x264_V2 is the same command but with tune grain.

Hmm. Doesn't look like that to me. Maybe the first x264 encode was with --tune grain and V2 with --tune film?

I'm downloading the source to try it out later.

[kolak]

No tweaking in pro encoder.
Almost default settings.

x264 encodes are not swapped.


Andrew

[nm]

Did you only run one pass?

[kolak]

Did you only run one pass?

2

Redoing tune grain encode- maybe it was 1 pass!

Now it's definately 2 pass:

http://www.mediafire.com/?az7dibmsu44c6sp


also tweaked pro

http://www.mediafire.com/?bzav321o6adw3z1




Andrew

[kieranrk]

Crossing The Line trailer. Shot on RED, ProRes source. This would be good source for testing.


Crossing The Line is quite an apt film considering what the date is. (though it isn't uncompressed ;-) )

There's also:

http://warosu.org/island/Island_1080p24_lag_51_%5bB76E513A%5d.avi

(someone seems to have mirrored it)

[kolak]

Crossing The Line is quite an apt film considering what the date is. (though it isn't uncompressed ;-) )

There's also:

http://warosu.org/island/Island_1080p24_lag_51_%5bB76E513A%5d.avi

(someone seems to have mirrored it)

ProRes is good enough.
It's real source, slow, high motion, gradients of sky and also moments with deatiled elements.
I'm having problems to download it.

[kolak]

In my test x264 encodes are about 2.5MB under ideal size.

35.911Kb ideal size

x264 is about 32.767Kb
pro is 35.903Kb


Andrew

[Doom9]

Also, MasterNobody is quite correct in saying that your explanations are simply not adequate for validating your claims. We need test cases that we can actually verify on our end.I can only second that (or third?) - we all know you prefer CCE-HD, but having heard that, it's either time to move on, or we restrain ourselfes to verifiable facts.

For starters, don't hid behind sources that cannot be shared. If you need examples on how a fair comparison is to be conducted, refer to my codec comparisons... they use publicly available sources, encoders, and all settings have been published - so if anybody does not agree with the results, they have all that is needed to see with their own eyes.

[kolak]

I can only second that (or third?) - we all know you prefer CCE-HD, but having heard that, it's either time to move on, or we restrain ourselfes to verifiable facts.

For starters, don't hid behind sources that cannot be shared. If you need examples on how a fair comparison is to be conducted, refer to my codec comparisons... they use publicly available sources, encoders, and all settings have been published - so if anybody does not agree with the results, they have all that is needed to see with their own eyes.

I don't prefer any encoder- I use few, because none of them is the best for every source file.

I also see place for x264 :)

Done test on publicly available source and posted some frames- whole source has the same nature and these frames are representative for the whole file.

Tomorrow will try different source.


Andrew

[kolak]

Crossing The Line is quite an apt film considering what the date is. (though it isn't uncompressed ;-) )

There's also:

http://warosu.org/island/Island_1080p24_lag_51_%5bB76E513A%5d.avi

(someone seems to have mirrored it)

What is it?

Not interested in CGI.


Andrew

[MasterNobody]

kolak
And again you ignore what other tells you. For information, screenshots are not the same as samples. You must provide samples to be useful to this thread (and forum at all). If you forgot (or may be never known :devil: ) samples are relatively short encoded video files.

Done test on publicly available source and posted some frames- whole source has the same nature and these frames are representative for the whole file.
And this is again only words without any proof (I and a lot of other members can't believe you only on words).

[Doom9]

And where are the settings for CCE-HD? After all.. somebody else might have it and would like to reproduce (so you need to give as much information as is needed.. (e.g. ecl file if they still use that).

Also, be mindful of our forum rule 12.. better, best.. (the forum software has already tagged this thread with the best attribute) it's all a slippery territory. If nobody comes along with a CCE-HD box, it's pretty much pointless to compare because nobody will be able to verify your results. So the whole CCE-HD vs x264 argument might actually fit better into a CCE-HD support forum since x264 is obtainable by everybody whereas CCE-HD is more than one year's salary for a lot of people.

@edit: MasterNobody is correct of course.. because only few have access to commercial encoders, it makes sense that you provide the encoded samples that the average person cannot reproduce on their own - not that this would allow ruling out any mischief on your end though (VAF comes to mind) but at least it's a start.

[kolak]

kolak
And again you ignore what other tells you. For information, screenshots are not the same as samples. You must provide samples to be useful to this thread (and forum at all). If you forgot (or may be never known :devil: ) samples are relatively short encoded video files.

BMP are 100% quality of the decoded file.
You can choose any frame number to post.
Do you think I seat and create fake BMPs?

Try x264 yourself- source is free and compare.

I can decode pro video and post it as an uncompressed.

Andrew

[nm]

In my test x264 encodes are about 2.5MB under ideal size.

That's probably normal for x264 with a short clip like this one.

35.911Kb ideal size

x264 is about 32.767Kb
pro is 35.903Kb

Was that with the station2.yuv source? Which framerate did you use and how do you calculate that size exactly?

Because I arrive at these numbers:

313 frames, 24000/1001 fps, encoded at 28 Mbps:
28000000 * (313/(24000/1001.0)) / (8*1024) ~= 44621 kB

313 frames, 30000/1001 fps, encoded at 28 Mbps:
28000000 * (313/(30000/1001.0)) / (8*1024) ~= 35696 kB

If you assumed the source was 30000/1001 fps, that would explain why I got slightly better results when encoding it at 24000/1001 fps.


I can decode pro video and post it as an uncompressed.

What stops you from posting compressed streams?

[ajp_anton]

Why do all the pro screenshots look like they went through fft3dfilter before the encode?
In most parts of the pictures, I actually like the x264 version better.

[kolak]

And where are the settings for CCE-HD? After all.. somebody else might have it and would like to reproduce (so you need to give as much information as is needed.. (e.g. ecl file if they still use that).

Also, be mindful of our forum rule 12.. better, best.. (the forum software has already tagged this thread with the best attribute) it's all a slippery territory. If nobody comes along with a CCE-HD box, it's pretty much pointless to compare because nobody will be able to verify your results. So the whole CCE-HD vs x264 argument might actually fit better into a CCE-HD support forum since x264 is obtainable by everybody whereas CCE-HD is more than one year's salary for a lot of people.

@edit: MasterNobody is correct of course.. because only few have access to commercial encoders, it makes sense that you provide the encoded samples that the average person cannot reproduce on their own - not that this would allow ruling out any mischief on your end though (VAF comes to mind) but at least it's a start.

True- pointless discussion. Any authoring house can have demo of CC-HDe and compare by themself.
It's maybe just an information for others, who never will be able access pro encoders, that there are at least as good as x264 AVC encoders.
90% doom9 visitors don't know it.

Andrew

[kolak]

That's probably normal for x264 with a short clip like this one.



Was that with the station2.yuv source? Which framerate did you use and how do you calculate that size exactly?

Because I arrive at these numbers:

313 frames, 24000/1001 fps, encoded at 28 Mbps:
28000000 * (313/(24000/1001.0)) / (8*1024) ~= 44621 kB

313 frames, 30000/1001 fps, encoded at 28 Mbps:
28000000 * (313/(30000/1001.0)) / (8*1024) ~= 35696 kB

If you assumed the source was 30000/1001 fps, that would explain why I got slightly better results when encoding it at 24000/1001 fps.


What stops you from posting compressed streams?

I haven't used whole file. My download has crashed, so I have used what was downloaded- 246 frames.

Andrew

[Blue_MiSfit]

Why won't you post compressed video samples?!?

That's all anyone wants!!! Screenshots only tell you a part of the story!!!

Derek

[kolak]

Why do all the pro screenshots look like they went through fft3dfilter before the encode?
In most parts of the pictures, I actually like the x264 version better.

It's your imagination :)

There was no filtering at all.

It's not about what do you like better, but which is closer to the source :)
Compare them in Photoshop to the source frames and you will see difference. Both encoders are very good, but you can see that not the same.


Andrew

[MasterNobody]

Try x264 yourself- source is free and compare.Of course I can do this. But next is not acceptable:I can decode pro video and post it as an uncompressed.
Because this way I can't check that you don't cheating.
So I need encoded sample at least by "Pro" encoder of publically available source (used station2.yuv is OK). Until than I will continue to think that you only trolling.

[kolak]

Why won't you post compressed video samples?!?

That's all anyone wants!!! Screenshots only tell you a part of the story!!!

Derek

True- that's why I can post decompressed uncompressed/lossless version of the pro encoder.

When you get your version better ask if you can post any encoded video- the answer will be that you're not allowed, until you own the software. You may end up with problems.

Andrew

[Doom9]

It's maybe just an information for others, who never will be able access pro encoders, that there are at least as good as x264 AVC encoders.
90% doom9 visitors don't know it.Seeing as most commercial Blu-rays use commercial encoders, I doubt people would think there's but one H.264 encoder out there.
And yet, why should they care too much about something that's unobtainable to them anyway?

Now if you work for an authoring place and can get the expensive toys and would like to compare to x264, perhaps you can work out something with the x264 authors that satisfies both the needs by the copyright holders and the needs of the people helping you out.

[kolak]

Seeing as most commercial Blu-rays use commercial encoders, I doubt people would think there's but one H.264 encoder out there.
And yet, why should they care too much about something that's unobtainable to them anyway?

Now if you work for an authoring place and can get the expensive toys and would like to compare to x264, perhaps you can work out something with the x264 authors that satisfies both the needs by the copyright holders and the needs of the people helping you out.

This is the work :)

It's helping to make x264 even better, by showing that pro encoders can match or outperform x264.

It's also about GUI for x264, which I'm talking about all the time. As a compressionist you have to have ability to verify you encoding and quickly mark and re encode problematic places. All pro encoders offers this- in one or another way.
Speed is also a small issue, but because x264 is free you can have many instances running on many PCs. Farm encoding would be nice, but not essential.
You can also include output through Black Magic card to external broadcast monitor. BM's SDK is available and I think easy to implement. Blu-code and CC-HDe do it.

I think x264 came to the point where money starts talking, which is not good.


Andrew

[kieranrk]

You can also include output through Black Magic card to external broadcast monitor. BM's SDK is available and I think easy to implement.

A patch has been written for ffmpeg for input but i'm not sure about output.

[kolak]

A patch has been written for ffmpeg for input but i'm not sure about output.

Good to know.

Andrew

[Blue_MiSfit]

When you get your version better ask if you can post any encoded video- the answer will be that you're not allowed, until you own the software. You may end up with problems.


OK, so maybe I can't post compressed samples if I don't own the software.

It sounds like your company does own the software, so why can't you post compressed samples?!

Derek

[kolak]

OK, so maybe I can't post compressed samples if I don't own the software.

It sounds like your company does own the software, so why can't you post compressed samples?!

Derek

It does not own it :(


Andrew

[MasterNobody]

I think x264 came to the point where money starts talking, which is not good.
I only see exactly opposite. You promoting not publically available / not free (cost a lot of money) "Pro" encoder by making non clean comparisons. On there other hand x264 is still free (until you want something non-GPL) and publically available.
And if you can't (not allowed to) provide even encoded sample than stop this comparisons and promotion of "Pro" encoders because this only looks like FUD.

[ajp_anton]

It's your imagination :)

There was no filtering at all.

It's not about what do you like better, but which is closer to the source :)
Compare them in Photoshop to the source frames and you will see difference. Both encoders are very good, but you can see that not the same.

AndrewWhat is my imagination? That the pro screens look filtered? I never said they were, but hey, we're not talking about lossless here. Sacrifices have to be made. Pro apparently does it by smoothening the image. x264 (with psy) by not caring as much about looking like the source.
We all know PSNR/SSIM/whatever likes the smoothening solution better. My eyes seem to like psy. What are you going to do about it?

[kolak]

I only see exactly opposite. You promoting not publically available / not free (cost a lot of money) "Pro" encoder by making non clean comparisons. On there other hand x264 is still free (until you want something non-GPL) and publically available.
And if you can't (not allowed to) provide even encoded sample than stop this comparisons and promotion of "Pro" encoders because this only looks like FUD.

It's not promoting. If some company wants to buy a pro encoder than they always request a demo- you can't make decision base on some posts on the forum, when it comes to $K.


Andrew

[kolak]

What is my imagination? That the pro screens look filtered? I never said they were, but hey, we're not talking about lossless here. Sacrifices have to be made. Pro apparently does it by smoothening the image. x264 (with psy) by not caring as much about looking like the source.
We all know PSNR/SSIM/whatever likes the smoothening solution better. My eyes seem to like psy. What are you going to do about it?

Maybe source was filtered- it's only HDCAM (8bit, 4:2:0), nothing special.


Andrew

[AnonCrow]

You can quickly see quality differences between I,P,B frames with subtract option in avisynth. I frames are much better. What is the solution?

Not that I'd recommend it, but have you tried lowering ipratio or pbratio [1] yet ?


[1] would require disabling mbtree, which is even less advisable

[Biggiesized]

If anyone has a Windows XP Professional x64 Edition rig that meets the specs of CC-HDe, I could help arrange a little shoot out. ;)

EDIT: Mods, let me know if this is an unacceptable proposition.

[kolak]

If anyone has a Windows XP Professional x64 Edition rig that meets the specs of CC-HDe, I could help arrange a little shoot out. ;)

EDIT: Mods, let me know if this is an unacceptable proposition.

No problem if you prove that you have valid license.


Andrew

[kolak]

Done another test- fast action, film source. Trailer- lots of scene changes, etc.

This is not about comparing to other encoders- just about x264.

Some frames of x264 ecnode looks amazing, but...they are fallowed by much worse quality frames.
This is my biggest complain- not consistent quality over I,P, B frames.

Areas to improve: fades, cross fades, water scenes, something like fog, clouds.


Andrew

[Doom9]

And how exactly are you providing any substantiated information this time?
Where's the source, where's the complete x264 commandline for each pass?
Blanket statements like
This is my biggest complain- not consistent quality over I,P, B frames.

Areas to improve: fades, cross fades, water scenes, something like fog, clouds.need to be backed up with proof (not that they can I think.. every source being different and all), or you need to find yourself another board.

[kolak]

And how exactly are you providing any substantiated information this time?
Where's the source, where's the complete x264 commandline for each pass?
Blanket statements like
need to be backed up with proof (not that they can I think.. every source being different and all), or you need to find yourself another board.

Take any source you like and you will have the same effect.
I tried few source and it's always the same. There are always frames with relatively bad frames- vey often these are cosecutive frames- ver good than bad. I assume these are B frames.

Always the same command line as posted before- just bitrate changed to 24mbit.

There are much more experienced x264 users than I, but i haven't seen any test at BD bitrates at all.
All is at low bitrates, which is far away from things which go to BD disc. This is about encoder for use for BD encodes.


Andrew

[kolak]

Trying kieranrk (Iland) source. I will post video if problem is still there.

[Doom9]

Sorry not good enough. You would be wise to have a quick look at the top of every page...for starters.. whose forum is it, and then what rules do we have (pay special attention to rule 16 and re-read the posts in this thread made by people who have Doom9 Team member badge.. those are the guys who enforce those rules).

[kolak]

40 sec part of kieranrk source from few posts above.

x264 --bitrate 28000 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 38000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 --psnr -o P:\iland_x264.264 R:\c.avs

This time veryslow prest, 2 pass.

http://www.mediafire.com/?2to0bhtmvop878x

Same thing- some frames are relatively bad (mostly B frames).

Good example, frames: 343, 465, 551, 560,561,562 (for some reason few frames), 568, 580, 581 (than perfect 582), 584, 585 (than perfect 586), 857 (destroyed few bottom lines- PSY?)..... and so on (no time to analyze whole video). Some of them are very bad.

Any solution?

Source is public, so anyone can try.


Andrew

[nurbs]

You forgot to post the other encode with your preferred encoder. We all can do the encode you posted ourselves. Hard to tell if x264 delivers inferior results if there is nothing to compare it to.

[kolak]

You forgot to post the other encode with your preferred encoder. We all can do the encode you posted ourselves. Hard to tell if x264 delivers inferior results if there is nothing to compare it to.

Source is the thing to compare to. Many frames are bad and I think there should be a way to fix it. x264 is to good to have such a bad frames.
Other encoder keeps more consistent quality, but it does not matter.

Is there a way to improve x264 encode?

Tune grain does not really help, even if the source is very grainy.


Andrew

[Dark Shikari]

Good example, frames: 343, 465, 551, 560,561,562 (for some reason few frames), 568, 580, 581 (than perfect 582), 584, 585 (than perfect 586), 857 (destroyed few bottom lines- PSY?)..... and so on (no time to analyze whole video). Some of them are very bad.You are a waste of my goddamn time.

I went out of my way to check every single one of the frames you listed. I watched the sections over and over and over.

Every single one looked basically perfect.

You're wasting my time, time that could be better spent on improving x264 than attempting to find the ghosts that you claim to be seeing.

And even if you're right, and the grain retention isn't as good as you want it to be... why didn't you use --tune grain if that's what you're complaining about? I even actively recommend it for Blu-ray usage. You tweak CCE-HD all you want, but you ignore the basic documentation when using x264.

Finally, you haven't posted any comparison of any encoder doing any better. A quick test with Mainconcept, for example, shows that it fails laughably here. Are you claiming your encoder is better than Mainconcept? If so, put up, or shut up: post samples, or stop making claims.

[Hagbard23]

@kolak: Do you even know, what a B-Frame is??? I think you are ridiculous...sorry...write your own codec and do better....

[kolak]

You are a waste of my goddamn time.

I went out of my way to check every single one of the frames you listed. I watched the sections over and over and over.

Every single one looked basically perfect.

You're wasting my time, time that could be better spent on improving x264 than attempting to find the ghosts that you claim to be seeing.

And even if you're right, and the grain retention isn't as good as you want it to be... why didn't you use --tune grain if that's what you're complaining about? I even actively recommend it for Blu-ray usage. You tweak CCE-HD all you want, but you ignore the basic documentation when using x264.

Finally, you haven't posted any comparison of any encoder doing any better. A quick test with Mainconcept, for example, shows that it fails laughably here. Are you claiming your encoder is better than Mainconcept? If so, put up, or shut up. You are nothing but lying scum who talks smack about everyone other than himself but cannot back up a single word he says.

Did you compare it to the source or just looked at the encoded file?
I tried tune grain- but you ignore what I write :)

Mainconcept is.....


Is this a perfect frame?:

http://www.mediafire.com/?wpqqjy7kj9e8vc1

first from the list.

Andrew

[Dark Shikari]

Did you compare it to the source or just looked at the encoded file?I just looked at the encoded file, because obviously, viewers watching a Blu-ray at home do not have the "source" to compare to!

I tried tune grain- but you ignore what I write :)Of course I do, because you're a cheat. If you say "--tune grain doesn't help", you probably actually mean "it helps a lot, so I omitted it from my test to make x264 look worse".

[kolak]

I just looked at the encoded file, because obviously, viewers watching a Blu-ray at home do not have the "source" to compare to!

Of course I do, because you're a liar and a cheat. If you say "--tune grain doesn't help", you probably actually mean "it helps a lot, so I omitted it from my test to make x264 look worse".

Encode yourself and show me that I've made mistake :)

I'm not an user- I'm compressionist and my job is to make it as close to the source as possible.


Andrew

[Biggiesized]

My offer still stands if someone wants to give CC-HDe a whirl themselves.

[Audionut]

I'd be happy to give it a go to post some real samples.

[Blue_MiSfit]

kolak, if you can't post COMPRESSED streams from CCE-HDe because of an NDA or something, that's fine.

Encode these streams to lossless x264 and post them up here :)

Derek

[Biggiesized]

I think he doesn't have any right to post the streams, encoded or otherwise, without the content owner's permission.

[aegisofrime]

I think he doesn't have any right to post the streams, encoded or otherwise, without the content owner's permission.

No, kolak claims that you can't post encoded streams if you don't own the license for the encoder.

True- that's why I can post decompressed uncompressed/lossless version of the pro encoder.

When you get your version better ask if you can post any encoded video- the answer will be that you're not allowed, until you own the software. You may end up with problems.

Andrew

Which doesn't make a lot of sense to me, but that's what he said.

[kolak]

No, kolak claims that you can't post encoded streams if you don't own the license for the encoder.



Which doesn't make a lot of sense to me, but that's what he said.

You can have trial version of CC-HDe, so you can test it, etc.
During this time software is not yours and you can't post any encoded files without permission- simple. If you buy software than you can do what you want :)

Rights to actual video used in test is another story- you also need permission or use publicly available source.

I was about to post Iland sample, but DS ignorance stopped me.
I'm still waiting for suggestions to improve Iland encode or for someone to post his version. Have enough of being accused for lying etc- where is prove that I lower quality of x264 encodes or manipulate them in any way?
Source is there, so everyone can try and prove it.

My bottleneck end up being also only "shouting" and now for some reasons my x264 encodes are not real (worse than they should be)- give ma a break :)


Andrew

[aegisofrime]

I see...

To clear things up, for those who wants to check the source or try to replicate the issue (if any), the source kolak used is apparently this:

Crossing The Line is quite an apt film considering what the date is. (though it isn't uncompressed ;-) )

There's also:

http://warosu.org/island/Island_1080p24_lag_51_%5bB76E513A%5d.avi

(someone seems to have mirrored it)

Warning, it's also 2.6GB large. Nothing major in the age of broadband, but still.

[nurbs]

I was about to post Iland sample, but DS ignorance stopped me.
I find it very interesting that whenever it comes to samples that show that CCE-HD really delivers superior or more constant quality for a given source you find another excuse why you won't post it.

[mp3dom]

I'm trying to download the "Island" source. If I have enough time I'll post the results.
Anyway you're 'attacking' kolak too much. I haven't seen its encodes but for some of his statements I agree with him. I have found myself that 'b' frames (without open-gop) potentially can have some problems (for example in retaining color gradients). It's for this reason that most of the times for animation I prefer to use another encoder which is more consistent across frames. Open-gop seems to help quite a lot but some problems still remains. Also I've found (dunno where's the problem) that on some encodes (always animation) on fast scenes there's some sort of temporal 'ghosting' (I don't have a better explanation). It's like some high frequencies of the previous frame (characters edges for example) are retained in the current frame. This happends to me with one of the last 16xx version of x264. Haven't tried with the latest 1766 release, maybe it's already fixed.

[Audionut]

If you can't post a sample for whatever reason. You don't jump onto a board and make statements that said encoder is better.

Simple.

Here's one for you.

The sun isn't heavy. You'll just have to believe me. Because the license says I can't post a sample.

[Biggiesized]

You're using The Island trailer? You can get a pretty transparent encode using Carbon Coder's MPEG-2 engine around 30 Mb/s average. It's not very difficult content.

If you can't post the encoded stream because the trial license forbids you (and it sounds completely ludicrous), then transcode that encode using x264 lossless. You should be able to get around the restriction using that method.

[mp3dom]

You're using The Island trailer? You can get a pretty transparent encode using Carbon Coder's MPEG-2 engine around 30 Mb/s average. It's not very difficult content.

At the end, what is (and where to find it) a good source for these kind of tests?

[aegisofrime]

At the end, what is (and where to find it) a good source for these kind of tests?

I'm guessing Parkrun should do the job. Very complex scene.

Get it here:

http://www.w6rz.net/

[mp3dom]

Yes, parkrun should be a good clip to test, but the problem is that I can't find an uncompressed source. The 'best' quality that I can find on that website is the 23 mbps clip which is already full of artefacts. I think a lossless or near lossless file would be more appropriate. Also clips with grain/color smoothing should be good too.

[kieranrk]

http://media.xiph.org/video/derf/

[mp3dom]

Thanks. I'm downloading some samples right now.

[kolak]

I'm guessing Parkrun should do the job. Very complex scene.

Get it here:

http://www.w6rz.net/

This is not true.

In any "real" source you may find 5% (if not less or any) as difficult scenes as parkrun- not a good source at all. Also it's to short, have only one scene and constant nature.


This trailer is a good source- typical movie source. It has any type of scenes: slow, fast, heavy grain, fades, etc. It tests every part of the encoder engine.

BD encoding is different than encoding for web or at 8Mbits. You have different goals to achieve.

I said forget comparision for a moment.

Source is there, I showed that x264 produces quite bad frames, which should not be seen at 28Mbit encode. Haven't done anything special- used suggested command line, tried to change few things, but it did not help.


Andrew

[kolak]

I find it very interesting that whenever it comes to samples that show that CCE-HD really delivers superior or more constant quality for a given source you find another excuse why you won't post it.

They were always the same: no rights to software, no rights to source (can be sort out).

DS is a new one :)

Andrew

[kolak]

You're using The Island trailer? You can get a pretty transparent encode using Carbon Coder's MPEG-2 engine around 30 Mb/s average. It's not very difficult content.

If you can't post the encoded stream because the trial license forbids you (and it sounds completely ludicrous), then transcode that encode using x264 lossless. You should be able to get around the restriction using that method.


Word "pretty" makes a big difference.

This is what I wanted to do.

Andrew

[poisondeathray]

This trailer is a good source- typical movie source. It has any type of scenes: slow, fast, heavy grain, fades, etc. It tests any part of the encoder engine.



I agree this trailer contains different elements that will test an encoder, but in general trailers are not a representative source of the actual movie.

There are too many frequent scene changes in a compressed amount of time compared to a real movie.




Source is there, I showed that x264 produces quite bad frames, which should not be seen at 28Mbit encode. Haven't done anything special- used suggested command line, tried to change few things, but it did not help.


And how do the other encoder(s) perform ?

[kolak]

I agree this trailer contains different elements that will test an encoder, but in general trailers are not a representative source of the actual movie.

There are too many frequent scene changes in a compressed amount of time compared to a real movie.

And how do the other encoder(s) perform ?

Yes- this is true, but also should help x264. Other encoders do open gop. Can I use open gop in x264- doe sit break BD compatibility or is it safe to sue?

Other encoders: as I said- more consistent quality between frames.

x264 makes I frames "to good", so B frames suffer.
If someone knows hot to tweak this x264 will also make "perfect" encode.

Andrew

[kieranrk]

Yes- this is true, but also should help x264. Other encoders do open gop. Can I use open gop in x264- doe sit break BD compatibility or is it safe to sue?


--open-gop bluray

[nm]

http://www.mediafire.com/?2to0bhtmvop878x

Same thing- some frames are relatively bad (mostly B frames).

Good example, frames: 343, 465, 551, 560,561,562 (for some reason few frames), 568, 580, 581 (than perfect 582), 584, 585 (than perfect 586), and so on (no time to analyze whole video). Some of them are very bad.

I couldn't replicate the issue at the scenes you mention but I haven't yet looked the whole video through. I can see the bad frames in your video though.

Link (http://hattivatti.dy.fi/video/the_island.28mbps.part.264) to my encode. I used x264 r1766.

857 (destroyed few bottom lines- PSY?).....

This is in my encode too at many scenes where there are grainy flat areas at the borders. Seems to be the psy-aq issue that you reported earlier (http://forum.doom9.org/showthread.php?t=153872).

[kolak]

I couldn't replicate the issue at the scenes you mention but I haven't yet looked the whole video through. I can see the bad frames in your video though.

Link (http://hattivatti.dy.fi/video/the_island.28mbps.part.264) to my encode. I used x264 r1766.



This is in my encode too at many scenes where there are grainy flat areas at the borders. Seems to be the psy-aq issue that you reported earlier (http://forum.doom9.org/showthread.php?t=153872).

Settings?
Use first 40sec (961 frames)- that's what I have.


Andrew

[nm]

Settings?
Same as yours, including the 12 threads, although I only have a dual core CPU.

Use first 40sec (961 frames)- that's what I have.
Well, I can make another encode, but it will take a while.

There's also a slight difference in my source because I don't have a Windows instance available right now, so I had to use MPlayer on Linux to decode the Lagarith source and for some reason it could only do that by converting to RGB in between. If I force YV12 or YUY2 output in codecs.conf, the codec throws an error.

So, I'll try to decode the source properly first.

[kolak]

Same as yours, including the 12 threads, although I only have a dual core CPU.


Well, I can make another encode, but it will take a while.

There's also a slight difference in my source because I don't have a Windows instance available right now, so I had to use MPlayer on Linux to decode the Lagarith source and for some reason it could only do that by converting to RGB in between. If I force YV12 or YUY2 output in codecs.conf, the codec throws an error.

So, I'll try to decode the source properly first.


I use YUY2 as a source (961 first frames).

x264 --bitrate 28000 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 38000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1


12 threads?
Same?

Use same lenth, but I can see that your video is different. There are almost no bad frames.

Andrew

[nm]

x264 --bitrate 28000 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 38000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1

12 threads?
Same?
Yes. You can also check the settings stored in the stream. You have an 8-core CPU, so x264 uses 12 threads.

Your settings:
x264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 -
http://www.videolan.org/x264.html - options: cabac=1 ref=4 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-3 threads=12 sliced_threads=0 slices=4 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=24 keyint_min=2 scenecut=40 intra_refresh=0 rc_lookahead=24 rc=2pass mbtree=1 bitrate=28000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 vbv_maxrate=38000 vbv_bufsize=30000 ip_ratio=1.40 aq=1:1.00 nal_hrd=vbr

My settings:
x264 - core 107 r1766 f9f0035 - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 -
http://www.videolan.org/x264.html - options: cabac=1 ref=4 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-3 threads=12 sliced_threads=0 slices=4 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=24 keyint_min=2 scenecut=40 intra_refresh=0 rc_lookahead=24 rc=2pass mbtree=1 bitrate=28000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 vbv_maxrate=38000 vbv_bufsize=30000 ip_ratio=1.40 aq=1:1.00 nal_hrd=vbr

[kolak]

Yes. You can also check the settings stored in the stream. You have an 8-core CPU, so x264 uses 12 threads.

Your settings:


My settings:

So- does my build have a bug?

I downloaded it only few days ago.


Andrew

[nm]

So- does my build have a bug?

That's a possibility, so you could at least try encoding the same clip with the latest version. Might be something else too. Are you using x264.nl builds?

[kolak]

That's a possibility, so you could at least try encoding the same clip with the latest version. Might be something else too. Are you using x264.nl builds?

Yes- it was downloaded few days ago from this site.

Going to try new one and compare. Interesting- at leats someone tried, not juts shouted.

Andrew

[poisondeathray]

you should try --tune grain

[kolak]

Sorted!
No bad frames.
There are still some PSY artefacts on some frames (will try different strenth), but overall quality is great.
I will try slow preset- because veryslow is to slow.


So x264 builds are nto that stable as I was promised :)
Will try tune grain,but quality already is very good- not much to be improved (just some PSY side effects).


Andrew

[nm]

you should try --tune grain

As kolak said, the issue is not about tuning for grain. Some frames in his clip were encoded at significantly worse quality compared to surrounding frames. I don't see that in my encode, at least in those parts of the video.

[kolak]

As kolak said, the issue is not about tuning for grain. Some frames in his clip were encoded at significantly worse quality compared to surrounding frames. I don't see that in my encode, at least in those parts of the video.

All sorted with new build.
I'm happy with quality, but 2fps is to slow.
Will try slow presset, which gives acceptable speed. It should not affect quality that much.

There are some problems with scenes with high grain (scenes with cars). I will try tune grain.
Fast action sceses are problematic- much different than it was with older build. It's all due to PSY. Some details gets totaly flatten.

Andrew

[nm]

All sorted with new build.

Good, now we can get to business! :)

[kolak]

Please check frame 910.


Andrew

[nm]

Please check frame 910.
I'd say that's simply a difficult 13-frame sequence. All the frames are somewhat smoothed, so maybe there just aren't enough bits available.

Does some other encoder give better results?

[kolak]

Tune grain helps- in grainy parts, but still very fast motion scenes causing a problems for x264 (slow preset).

Here is something to compare to (frames 888-930):

http://www.mediafire.com/?7zxeva4elepjqzn

Waiting for nice GUI :)


Andrew

[mp3dom]

I'm slowly :( downloading the trailer too. I think the x264 command line should be 'enhanced' to use at least open gop like all other encoders do.
A patched version with fade-improvements should be useful too. From the encoded file posted by nm the fades are quite bad (haven't seen the source yet, maybe it's already in it?)

[nm]

A patched version with fade-improvements should be useful too. From the encoded file posted by nm the fades are quite bad (haven't seen the source yet, maybe it's already in it?)
The blocky fade to the Dreamworks logo is in the source.

[Sharc]

x264 makes I frames "to good", so B frames suffer.
If someone knows hot to tweak this x264 will also make "perfect" encode.
--ipratio 1.1

Added: you may also want to try
--no-mbtree --pbratio 1.1

good luck

[kolak]

--ipratio 1.1

Added: you may also want to try
--no-mbtree --pbratio 1.1

good luck

This is sorted- it looks like I was using buggy build.


Andrew

[laserfan]

This is sorted- it looks like I was using buggy build.
Congratulations on 13 pages of off-topic nonsense! :rolleyes::devil:

[kolak]

Congratulations on 13 pages of off-topic nonsense! :rolleyes::devil:

Yes and no :)

I was using build, which was downloaded few days ago and apparently was very stable.
At least we know that there was a problem. I was assured that latest build are stable- last one was not changed for a month?
It is only good job of nm that he at least tried to reproduced my problem- not just shouted :)

It was not off topic anyway.


Andrew

[kolak]

I'd say that's simply a difficult 13-frame sequence. All the frames are somewhat smoothed, so maybe there just aren't enough bits available.

Does some other encoder give better results?

Compare to the file which I have posted. It can be done better. It looks like problems with very high motion.
It's extract from the whole encode- no segment re-encode was used.


Andrew

[mp3dom]

Uhmm, the black bars are not 100% black. They contains noise. Maybe x264 is wasting bits trying to preserve this. Infact in your sequence the noise in the black bars are more smoothed out than the nm's file.

Edit: I must admit that on pure films x264 performs really well or at least it doesn't shows problems that appears when working mainly with animations (cg or cells). Maybe the grain helps.

[kolak]

Uhmm, the black bars are not 100% black. They contains noise. Maybe x264 is wasting bits trying to preserve this. Infact in your sequence the noise in the black bars are more smoothed out than the nm's file.

Edit: I must admit that on pure films x264 performs really well or at least it doesn't shows problems that appears when working mainly with animations (cg or cells). Maybe the grain helps.

All on source- bit strange source. If there is something which is not going be seen than you ignore it. That's why it's important to view encodes on properly calibrated monitor. Many PC monitors show stuff which won't be visible on TVs.

Grain does help :) x264 does very good job on this source- this high motion part is the only problem. Rest of the file is basically like source (some PSY side effects on some frames- I think could be avoided).

Andrew

[nm]

Compare to the file which I have posted. It can be done better. It looks like problems with very high motion.

CC-HDe saves bits in grainy "flat" areas like the sky, parts of the asphalt and the black bars as mp3dom mentioned. They come out worse than in the x264 encode and therefore bits can be used in the higher contrast areas to improve quality there.

Looks like a matter of different psy tuning to me. I noticed the same in the station2.yuv sample. Maybe we could get a similar effect with current x264 if someone knows which knobs to turn?

[mp3dom]

Honestly I've not seen so many details lost. Can you point out where to look please? On the other hand, I'm more worried about the visible artefacts in the sequence from frame 1019 to frame 1045 (both inclusive).

[kolak]

CC-HDe saves bits in grainy "flat" areas like the sky, parts of the asphalt and the black bars as mp3dom mentioned. They come out worse than in the x264 encode and therefore bits can be used in the higher contrast areas to improve quality there.

Looks like a matter of different psy tuning to me. I noticed the same in the station2.yuv sample. Maybe we could get a similar effect with current x264 if someone knows which knobs to turn?

Black bars should be black :) Pro encoders have settings to even such a areas to make them black. No need to waste bits there.

There is a lots of details lost on some of x264 frames in this high motion part. When engine is highly optimised you're more likely to have side effects. There are random flatten patches on x264 frames in different places of the encoded file- most of them are small, not an issue, but sometimes they get visible and to big, like frame 910 and some later. Big flat areas- this can be fixed I think.

Other encoders degrade frame more even- whole frame is bit softer, where x264 makes patches of much worse areas. I prefer pro encoders, but also think x264 can be tweaked to do the same- just needs some adjustments for high bitrate (eg. BD) encodes.

When you compare make sure you compare few consecutive frames and use monitor with high enough resolution to see 1:1 preview.


Andrew

[mp3dom]

On my encode (same settings as kolak/nm, but only using a modified build with fade-compensate patch) in the final credits (dreamworks presents etc etc) the grain is quite smoothed out (compared to all other frames where the grain is well retained). Maybe it's a problem of the custom build. Does it happends to both of you too? I'll try with an original x264 build.

Is there a way to fix the smoothing that can came across frame boundaries (where the image finish and starts black bars)?

[Sharc]

Black bars should be black :) Pro encoders have settings to even such a areas to make them black. No need to waste bits there.

Did you re-encode the black borders from the trailer?
If so, I think it would make a big difference if you crop the borders from the original and add them back with avisynth before encoding with x264.
In your encoded sample 'iland_x264.264' the black borders were horribly noisy, indeed wasting a lot of bits. I have not seen this before with x264, unless the original was lousy.

[jpsdr]

On my encode (same settings as kolak/nm, but only using a modified build with fade-compensate patch)
Jeeb's build containt also a noise optimisation patch.
Maybe it's something to try (combined with tune grain) ?

[kolak]

Did you re-encode the black borders from the trailer?
If so, I think it would make a big difference if you crop the borders from the original and add them back with avisynth before encoding with x264.
In your encoded sample 'iland_x264.264' the black borders were horribly noisy, indeed wasting a lot of bits. I have not seen this before with x264, unless the original was lousy.

This could be done. It's on the source, but I think it wont be visible on properly set TV. I can check. No filtering/source modification was done in any of the encodes.


Andrew

[Sagittaire]

I will make encoding with MPEG2, VC1 and various H264 encoder ... and with professional pre-filtering (blacks borders, black noise filtering ... etc etc)

[kolak]

I will make encoding with MPEG2, VC1 and various H264 encoder ... and with professional pre-filtering (blacks borders, black noise filtering ... etc etc)

I don't think MPEG2 or VC1 will hold on to x264, but why not :)


Andrew

[Sagittaire]

I don't think MPEG2 or VC1 will hold on to x264, but why not :)


Andrew

at 38 Mbps ... all encodeur will produce good job ... it's easy with good pre-filtering ... see HDDVD quality with only 24 Mbps for primary video stream

[kolak]

at 38 Mbps ... all encodeur will produce good job ... it's easy with good pre-filtering ... see HDDVD quality with only 24 Mbps for primary video stream

28Mbit :) (38Mbit max)

x264 is not just good- it's almost like a source (just few problematic places).

Please don't filter - filtering kills all encodes- it's just a Hollywood invention for lack of the proper encoder in early stages of HD DVD and Blu-ray format.
Yes- 80% of HD DVD discs were filtered which everyone could tell- this is not what you want :) If you filter make it the way so you can't tell it was used.
There is no need for any filtering at BD bitrates. There may be some cases (5%), but it's rare and Iland trailer is definately not one of them :)

You can make bars pure black, because there is no need to waste bits there, but rest of it compresses quite well as it is.

Andrew

[Lyris]

at 38 Mbps ... all encodeur will produce good job ... I wouldn't count on it. I've seen some AVC encoders that turn grain into patchy ugliness at ~38mbps.

[Blue_MiSfit]

Nothing wrong with cropping out noisy mattes and re-adding clean versions.

@kolak: Correct me if I'm wrong, but AFAIK you STILL haven't provided any examples of CCE-HDe with "The Island" trailer via a standard 2 pass encode. There are no licensing issues here as I can see. This is a public source, and you can transcode the CCE-HDe to x264 lossless, but still refuse to do so.

In other words, there's still absolutely no real evidence whatsoever that CCE-HDe is any better than x264 without its special filtering / bit allocation methods. Without any REAL EVIDENCE, this thread is just trolling. You continue to parrot CCE-HDe marketing-speak, which isn't impressive.

I strongly doubt that CCE-HDe (without a bunch of passes or special manual tweaking) makes these "problematic places" look better than a standard 2 pass x264 encode without introducing "problematic places" of its own.

If you're actually interested in continuing meaningful discussion here, post a full encode from CCE-HDe, or shut up. I'm sick of your subjective, meaningless statements like "CCE-HDe produce more even quality"

I'm surprised that updating x264 builds made that much of a difference. I was under the impression that 1745 (which was the latest for several weeks) had no outstanding issues.

Derek

[kolak]

Nothing wrong with cropping out noisy mattes and re-adding clean versions.

@kolak: Correct me if I'm wrong, but AFAIK you STILL haven't provided any examples of CCE-HDe with "The Island" trailer via a standard 2 pass encode. There are no licensing issues here as I can see. This is a public source, and you can transcode the CCE-HDe to x264 lossless, but still refuse to do so.

In other words, there's still absolutely no real evidence whatsoever that CCE-HDe is any better than x264 without its special filtering / bit allocation methods. Without any REAL EVIDENCE, this thread is just trolling. You continue to parrot CCE-HDe marketing-speak, which isn't impressive.

I strongly doubt that CCE-HDe (without a bunch of passes or special manual tweaking) makes these "problematic places" look better than a standard 2 pass x264 encode without introducing "problematic places" of its own.

If you're actually interested in continuing meaningful discussion here, post a full encode from CCE-HDe, or shut up. I'm sick of your subjective, meaningless statements like "CCE-HDe produce more even quality"

I'm surprised that updating x264 builds made that much of a difference. I was under the impression that 1745 (which was the latest for several weeks) had no outstanding issues.

Derek

I'm even more surprised that other build has bugs- I've been told that they are stable.

Downlaod old build and do encode, download new build and do encode and compare!!

Show me that there is no problem with this older build or shut up! At this point many people shout louder than me with no evindence for thier statements.
Only nm provide a sample, which quickly allowed to sort out problem with bad B frames.

You have sample from my encode ( http://www.mediafire.com/?7zxeva4elepjqzn )- read posts- and it's this problematic place. No tweaking at ll was done- it's just an extract from 3 pass encode.


Andrew

[kypec]

I'm surprised that updating x264 builds made that much of a difference. I was under the impression that 1745 (which was the latest for several weeks) had no outstanding issues.
Yes, this is something which worries me too, though I'm not a professional encoder, just a home enthusiast. I can't believe there was/is that big difference between the latest r1772 and (originally tested by kolak) r1745.:(
Perhaps some of these fixes were crucial, what do you think?commit 5dfbfc357406e641c80d9de74c85fce4ece6b5ba r1753
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Mon Nov 8 19:56:29 2010 -0800

Fix stupid bug in B-frame VBV size prediction

commit 601c0e38ef957ecca3792521beb335113ba49e3b r1765
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Sat Nov 6 17:47:27 2010 -0700

Improve flash detection's behavior near the end of the video
Flash detection catches situations like AAAABBCCDDDD, where A,B,C,D are frames in different scenes.
x264 would place a keyframe on the first "D".
However, if the video ended on the last "C", x264 would place a keyframe on the first "C", even though C classifies as a flash.
This change fixes this issue.

commit c9dad9e1508a4d430b9bab72c8875892cf7fef3c r1772
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Thu Nov 11 01:40:52 2010 +0300

Improve flash detection algorithm change in r1765
Now only disables scenecuts only near real end of video, not just prior to forced keyframes.

[kolak]

Yes, this is something which worries me too, though I'm not a professional encoder, just a home enthusiast. I can't believe there was/is that big difference between the latest r1772 and (originally tested by kolak) r1745.:(
Perhaps some of these fixes were crucial, what do you think?commit 5dfbfc357406e641c80d9de74c85fce4ece6b5ba r1753
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Mon Nov 8 19:56:29 2010 -0800

Fix stupid bug in B-frame VBV size prediction

commit 601c0e38ef957ecca3792521beb335113ba49e3b r1765
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Sat Nov 6 17:47:27 2010 -0700

Improve flash detection's behavior near the end of the video
Flash detection catches situations like AAAABBCCDDDD, where A,B,C,D are frames in different scenes.
x264 would place a keyframe on the first "D".
However, if the video ended on the last "C", x264 would place a keyframe on the first "C", even though C classifies as a flash.
This change fixes this issue.

commit c9dad9e1508a4d430b9bab72c8875892cf7fef3c r1772
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Thu Nov 11 01:40:52 2010 +0300

Improve flash detection algorithm change in r1765
Now only disables scenecuts only near real end of video, not just prior to forced keyframes.



Maybe- build 1766 fixes the problem and this is important.


Andrew

[kolak]

Uhmm, the black bars are not 100% black. They contains noise. Maybe x264 is wasting bits trying to preserve this. Infact in your sequence the noise in the black bars are more smoothed out than the nm's file.

Edit: I must admit that on pure films x264 performs really well or at least it doesn't shows problems that appears when working mainly with animations (cg or cells). Maybe the grain helps.

This black bars are black on properly calibrated TV.

I'm blanking 142 pixels from top and bottom for other tests- no need to waste bits there.

Andrew

[RunningSkittle]

You have sample from my encode ( http://www.mediafire.com/?7zxeva4elepjqzn )- read posts- and it's this problematic place. No tweaking at ll was done- it's just an extract from 3 pass encode.


Andrew

3 pass??? And you only uploaded 42 frames???
(Also why RAR??? think of the children!!!)

[kypec]

Maybe- build 1766 fixes the problem and this is important.
Andrew
Are you using 32-bit or 64-bit x264.exe builds in your tests?

[kolak]

Are you using 32-bit or 64-bit x264.exe builds in your tests?

32-bit

Andrew

[kolak]

3 pass??? And you only uploaded 42 frames???
(Also why RAR??? think of the children!!!)

Yes- 3passes. Some encoders are designed to do many passes- not just 2.


Andrew

[RunningSkittle]

Yes- 3passes. Some encoders are designed to do many passes- not just 2.


Andrew

???


-p, --pass <integer> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file

[kolak]

???


-p, --pass <integer> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file


Will try, but there is no problem with x264 quality, except high motion part of the source. Not sure if 3rd pass will help with this.

Andrew

[kolak]

3pass encode (tune grain, veryslow) did not help with fast motion scenes. Also some fades (not all) are softend a lot as mp3dom said.


Andrew

[shon3i]

Ok, since kolak refuses to post CCE HD sample, i asked CCE support did i can post some test samples with their encoder, and they answer is yes, along is sample licence allow this. So i will today install XP64-bit on mine home pc, and i will encode every source with lastest CCE-HD you want. Just please give me source you want.

[Doom9]

I'm surprised that updating x264 builds made that much of a difference. I was under the impression that 1745 (which was the latest for several weeks) had no outstanding issues.Maybe a bad compile? Haven't certain builds in the past had issues not because of the code, but because of the compiler/settings used to create the build?

In other words, there's still absolutely no real evidence whatsoever that CCE-HDe is any better than x264 without its special filtering / bit allocation methods. Without any REAL EVIDENCE, this thread is just trolling.Given his claim that encoded results cannot be shared in any form, this makes the whole idea of a comparison pointless and any claims to superiority cannot be taken at face value because they cannot be backed up.

Biggiesized has made an interesting offer - so let me lay the ground rules for encoder comparisons

1) Source must be publicly available.
2) Encoder build (that includes revision, 32bit/64bit.. who compiled it, compiler settings, the works) must be shared along with any and all settings
3) Avisynth scripts must be shared.
4) Encoded results must be shared.

If you cannot do any of those, don't bother posting.

Last but not least, video quality is in the eye of the beholder... so, you liking something better doesn't make it better.

Finally, there seems to be a lot of "look here, x264 does this and this not good", "look it's not stable" (though there's only one person experiencing a problem) which frankly doesn't feel very productive and I am not convinced that certain people are really on a quest to get better looking encodes from one encoder rather than to find reasons not to use that same encoder.

[kolak]

Maybe a bad compile? Haven't certain builds in the past had issues not because of the code, but because of the compiler/settings used to create the build?

Given his claim that encoded results cannot be shared in any form, this makes the whole idea of a comparison pointless and any claims to superiority cannot be taken at face value because they cannot be backed up.

Biggiesized has made an interesting offer - so let me lay the ground rules for encoder comparisons

1) Source must be publicly available.
2) Encoder build (that includes revision, 32bit/64bit.. who compiled it, compiler settings, the works) must be shared along with any and all settings
3) Avisynth scripts must be shared.
4) Encoded results must be shared.

If you cannot do any of those, don't bother posting.

Last but not least, video quality is in the eye of the beholder... so, you liking something better doesn't make it better.

Finally, there seems to be a lot of "look here, x264 does this and this not good", "look it's not stable" (though there's only one person experiencing a problem) which frankly doesn't feel very productive and I am not convinced that certain people are really on a quest to get better looking encodes from one encoder rather than to find reasons not to use that same encoder.

Ask Biggiesized for CC-HDe license first- also to specify CC-HDe version (last is 1.11).
Rest of the x264 file is very good- just pointing elements, which causes problem.
This is in few posts- x264 encode looks like a source (except some parts).

Andrew

[mp3dom]

I'm interested too in this comparison. I would only suggest to test sources that differs each others (for example, sources with grain, sources without grain, sources with flash/fades/cg/color smoothing, sources that doesn't comes from movies, sources with/without black bars etc.) to see where an encoder performs better than other and in what areas. Also a source with some combination of all of the mentioned above could be useful to see if a particular 'preset' is well suited for different kind of footage. The aim is to avoid as much as possible the segment encoding.

In response to Blue_MiSfit: in the past I've tested some different build of x264 (from about 15xx to 16xx rev.) and I've seen too some problems on B frames. Visible smoothing in some areas and color banding... and I've used an average of 35 Mbps. Maybe the final results depends on the source or the settings (i was using qpmin=0, but maybe the encoder works best with default qpmin=10). Anyway, in general, I can't test every new build every time it's out. I take a build and test it. After the results I decide which encoder to use for a particular footage. On the 'Island' trailer I've no problems to say that the results are very good (excluding some problems already mentioned, like the smoothing on the rows near the bottom black bars, the cg part which shows compression artefacts and (to me) the smoothing on the final credits). Maybe if there's a way to solve this too I would be very happy.

Personally I've tested the results of x264 for quite a month in the past before choosing which encoder to use for an encoding session. One of the most annoying thing about x264 is the fact that it doesn't offer yet a segment encoding. All encoders doesn't offer the maximum quality at the first step. If a segment look bad with a pro-encoder (it happends always) I can set a markin and markout and encode only that part with different settings. If it's not yet good enough, I can redo the segment again and again. The same cannot be made with x264... you can use zones but you need to redo a full encoding from scratch which is extremely time-consuming and it's not guarantee to obtain a good results. So if it's not good you need to change again and redo from scratch again. Something unacceptable to me.

[nurbs]

Also some fades (not all) are softend a lot as mp3dom said.
You'll be happy to hear that Dark Shikari et al. are working to extend weightp to take chroma information into account and first tests showed big improvements on fades. With a little luck it might even come out with the next round of updates.

[kolak]

You'll be happy to hear that Dark Shikari et al. are working to extend weightp to take chroma information into account and first tests showed big improvements on fades. With a little luck it might even come out with the next round of updates.

Yes- will be happy.
Good :)

My last tune grain, very slow presset, 3pass encode:

http://www.mediafire.com/?74ik6z3b2tzfsp1


I'm just pointing things which needs improvemnt. 90% of the encoded file has very good quality- no problems, but it also has frames with very bad quality (and no segment re-encode). This is not good for BD use.


Andrew

[laserfan]

If you cannot do any of those, don't bother posting.
And one wonders why you have let this thread drone-on the way it has? :rolleyes:

[kolak]

And one wonders why you have let this thread drone-on the way it has? :rolleyes:

I also said at some point- forget comparision.
Focus on x264 usage for BD and it's weekneses in this area.


Andrew

[sneaker_ger]

You'll be happy to hear that Dark Shikari et al. are working to extend weightp to take chroma information into account and first tests showed big improvements on fades. With a little luck it might even come out with the next round of updates.

Too bad nobody wants to risk using weightp for commercial blu-rays because of some faulty players.

[nurbs]

I totally forgot about that, probably because those limitations don't concern my own encodes. :)
Maybe I don't remember correctly, but I think mbtree without weightp has worse fades than encodes without mbtree, so turning that off might be worth trying. That comes with other disadvantages of course.

[kolak]

I have 2 more things to try:

Mbtree off and Open GOP.

Also just 2 more things to sort out- few bad fades and problems on high motion scene.


Andrew

[Blue_MiSfit]

Yes- 3passes. Some encoders are designed to do many passes- not just 2.


Andrew

[friendly troll]
What this really means is that some encoders aren't smart enough to do a good job of rate control in two passes, and have to do multiple passes to get the job done ;)
[/friendly troll]

In all honesty though, I've never liked the idea of seeing improvement after 2 passes - segment re-encoding aside, of course! From a totally uninformed (I'm no programmer), gut feeling perspective, you shouldn't need more than 2 passes to do a really solid job.

I'm going to download this source and do some testing of my own.

Derek

[nm]

Yes, this is something which worries me too, though I'm not a professional encoder, just a home enthusiast. I can't believe there was/is that big difference between the latest r1772 and (originally tested by kolak) r1745.:(
Perhaps some of these fixes were crucial, what do you think?commit 5dfbfc357406e641c80d9de74c85fce4ece6b5ba r1753
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Mon Nov 8 19:56:29 2010 -0800

Fix stupid bug in B-frame VBV size prediction

Yes, that r1753 commit is the one that fixed kolak's issue. I suspected this earlier, but didn't have time to test.

If someone still wants to see what the problem was, here (http://hattivatti.dy.fi/video/the_island-r1752) are sample clips and a frame comparison (frame 550 is fine with both r1752 and r1753, frame 551 is bad with r1752. It's difficult to notice without comparing to the source frame.)

[kolak]

[friendly troll]
What this really means is that some encoders aren't smart enough to do a good job of rate control in two passes, and have to do multiple passes to get the job done ;)
[/friendly troll]

In all honesty though, I've never liked the idea of seeing improvement after 2 passes - segment re-encoding aside, of course! From a totally uninformed (I'm no programmer), gut feeling perspective, you shouldn't need more than 2 passes to do a really solid job.

I'm going to download this source and do some testing of my own.

Derek

It's not really true. It's the same when you have some function and looking for global minimum (lowest distortion)- not easy to find.

What CC-HDe gains from many passes can be seen on Q (quantization) value (with ffdshow decoder) - it's very constant for every scene- eg 18+-1, where x264 will be more like 18+-3 for different frames. Don't know if this really matters, but this is the difference between these encoders. Is this why I say CC-HDe quality is more consistent between frames? Their engine is designed do flatten Q value over whole encode.

Andrew

[Blue_MiSfit]

What CC-HDe gains from many passes can be seen on Q (quantization) value (with ffdshow decoder) - it's very constant for every scene- eg 18+-1, where x264 will be more like 18+-3 for different frames. Don't know if this really matters, but this is the difference between these encoders. Is this why I say CC-HDe quality is more consistent between frames?



You are a bit confused there, friend :)

The QP value reported by ffdshow is basically meaningless. I BELIEVE it's the average frame QP. Recall that adaptive quantization applies different QPs to different macroblocks according to scene complexity and the psy model.

If "consistent (quality) between frames" as you say was actually defined by the QP, you could just encode everything at a constant QP ;)

[Reasonably well informed but maybe not 100% technically accurate explanation

Unfortunately, if you do this quality will not be even, because:
1) Some scenes/frames/macroblocks are more difficult to compress than the movie's average, or maybe more important from a psy perspective. These scenes will need a lower QP overall to look "good"
2) Many bits will have been wasted by coding easy or unimportant areas at the constant QP. If we were doing 2 pass VBR, these areas could handle a higher QP, freeing up bits to lower the QP for parts like 1)

As I understand it, CRF is designed to give relatively even quality in a single pass, and is therefore loved in scenarios where precise rate control isn't necessary

UNFORTUNATELY... BluRay is definitely not one of these scenarios ;) .... actually I wonder how a VBV capped CRF encode would look... I'll have to try that :)

[/Reasonably well informed but maybe not 100% technically accurate explanation]

[kolak]

You are a bit confused there, friend :)

The QP value reported by ffdshow is basically meaningless. I BELIEVE it's the average frame QP. Recall that adaptive quantization applies different QPs to different macroblocks according to scene complexity and the psy model.

If "consistent (quality) between frames" as you say was actually defined by the QP, you could just encode everything at a constant QP ;)

[Reasonably well informed but maybe not 100% technically accurate explanation

Unfortunately, if you do this quality will not be even, because:
1) Some scenes/frames/macroblocks are more difficult to compress than the movie's average, or maybe more important from a psy perspective. These scenes will need a lower QP overall to look "good"
2) Many bits will have been wasted by coding easy or unimportant areas at the constant QP. If we were doing 2 pass VBR, these areas could handle a higher QP, freeing up bits to lower the QP for parts like 1)

As I understand it, CRF is designed to give relatively even quality in a single pass, and is therefore loved in scenarios where precise rate control isn't necessary

UNFORTUNATELY... BluRay is definitely not one of these scenarios ;) .... actually I wonder how a VBV capped CRF encode would look... I'll have to try that :)

[/Reasonably well informed but maybe not 100% technically accurate explanation]

Q does change from scene change to scene change. But in the same scene it's kept very constant (between I,P, B frames) on CC-HDe encodes.

Andrew

[poisondeathray]

How realistic would a segment based re-encoding feature be for the x264 GUI in development? Very unlikely in the near future? or is it something actually being considered ?

[Blue_MiSfit]

kolak:

My point is, that's probably actually sub-optimal from a quality perspective.

Derek

[kolak]

kolak:

My point is, that's probably actually sub-optimal from a quality perspective.

Derek

Yes- at this quality can't tell difference between encoded and source anyway.

Andrew

[aegisofrime]

How realistic would a segment based re-encoding feature be for the x264 GUI in development? Very unlikely in the near future? or is it something actually being considered ?

If you REALLY wanted to...

1) Split file with MKVToolnix

2) As you can only split at Keyframe intervals (I believe), one still has to find the exact frame number MKVToolnix split the file at. Then create a Avisynth Trim script, and re-encode.

3) Append with MKVToolnix

Of course, it's tedious and I believe DS said that it's less than optimal from a quality standpoint. Also, I believe you can't mix files encoded with different x264 versions.

As always, correct this noob if he's wrong (which is very likely)

[poisondeathray]

If you REALLY wanted to...

1) Split file with MKVToolnix

2) As you can only split at Keyframe intervals (I believe), one still has to find the exact frame number MKVToolnix split the file at. Then create a Avisynth Trim script, and re-encode.

3) Append with MKVToolnix

Of course, it's tedious and I believe DS said that it's less than optimal from a quality standpoint. Also, I believe you can't mix files encoded with different x264 versions.

As always, correct this noob if he's wrong (which is very likely)


1) MKV won't work, it has to be elementary stream. You get issues with some muxers when video is wrapped in mkv (or any container) beforehand

2) What happens to VBV values ? what happens to the joined segments? I suspect there would be potential playback issues the way it works now

I suspect segment re-encoding will be difficult to implement correctly

[Blue_MiSfit]

I just did The Island trailer, (anyone else have problems downloading? Chrome kept finishing the download at ~1GB, and I had to use wget to actually download the damn thing!!!)

I was quite impressed with the results using x264 1772, and the following CLI:


c:\x264.exe --bitrate 25000 --preset slow --tune film --open-gop bluray --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1
-o out.264 Island_1080p24_x264Lossless_6chFLAC.mkv --index island.idx

c:\x264.exe --bitrate 25000 --preset slow --tune film --open-gop bluray --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2
-o out.264 Island_1080p24_x264Lossless_6chFLAC.mkv --index island.idx


Main differences from the x264bluray.com suggested settings:
1) preset slow instead of preset veryslow. I was impatient.
2) weightp enabled instead of forced off. This is safe for BluRay as long as you're ok with expecting your BD player to have updated firmware (you should be IMO)
3) open-gop enabled in BluRay compliant mode
4) 25mbps ABR

I pre-processed the AVI Lagarith / PCM source into x264 Lossless / FLAC using the following AviSynth script:

AVISource("...Island_1080p24_lag_51_[B76E513A].avi")
crop(0,142,0,-142)
addborders(0,142,0,142)


This cleaned up the mattes which did have some nasty crud in them. It was probably on the mezzanine file or tape for wherever this source actually came from.

The end result was absolutely fantastic. Did a lot of comparison in a new avisynth script like this:

a=dss2("input.mkv")
b=dss2("output.m2ts")

interleave(a,b)

I can see pixel differences between the two, but basically there's no difference, even in high complexity scenes.

My only gripe is that I'm also seeing the bottom few lines of picture being quite blurred out in most scenes. I'm not sure what the cause of this is, perhaps D_S or another dev/wizard can offer insight?

Here's a couple of screengrabs. Not that useful, but the issue is extremely obvious in these frames. Note the total lack of grain / detail at the very bottom of the active picture
Source frame:http://img24.imageshack.us/img24/2561/01islandsourceframe892.png
Encode frame: http://img593.imageshack.us/img593/7973/02islandx264frame892.png

The active picture area is 1920x796 (142 pixels of matte on top and bottom), which obviously isn't mod16. The source mattes were 140 on top and 141 on bottom, which obviously doesn't jive too well when cropping YV12!!!

I'm trying another encode where I crop 140 top, 142 bottom, and scale the active picture area to 1920x800 before encoding as I type this...

I'll post a complete stream tomorrow. Someone is eating up all my upstream at the moment :)

Derek

[sneaker_ger]

2) weightp enabled instead of forced off. This is safe for BluRay as long as you're ok with expecting your BD player to have updated firmware (you should be IMO)

I'm not so sure if this is true. I heard people saying for example that the LG BD 370 got a fix for weightp (smart), but it actually only fixed weightp in mkv, not AVCHD/Blu-Ray. I wouldn't bet on all players having fixed firmwares for weightp in Blu-Ray. At the end of the day I'd rather accept some quality loss than customers complaining about artifacts. Because the latter could cost you some serious money, but no one will complain about the quality loss.

[Blue_MiSfit]

http://i301.photobucket.com/albums/nn57/addaminsain/1261914823840.jpg

Yes.. I've just realized that I should not have mattes starting on non mod16 boundaries (thanks D_S). It will cause precisely the issues I've seen here.

SO... let it be a lesson to us all! When prepping content for BluRay encoding, CHECK THE SIZE OF YOUR MATTES OMG!!!

This source's mattes were screwed up to begin with, but I didn't exactly help matters....

/facepalm

Derek

[aegisofrime]

1) MKV won't work, it has to be elementary stream. You get issues with some muxers when video is wrapped in mkv (or any container) beforehand

2) What happens to VBV values ? what happens to the joined segments? I suspect there would be potential playback issues the way it works now

I suspect segment re-encoding will be difficult to implement correctly

Hmmm. I encode my videos with MeGUI with MKV extension, and when my encoding crashes, I "resume" it with a variant of the method that I posted above. I'm not sure about you but it works for me :)

As for VBV, never used that before so I won't know. :(

I'm not so sure if this is true. I heard people saying for example that the LG BD 370 got a fix for weightp (smart), but it actually only fixed weightp in mkv, not AVCHD/Blu-Ray. I wouldn't bet on all players having fixed firmwares for weightp in Blu-Ray. At the end of the day I'd rather accept some quality loss than customers complaining about artifacts. Because the latter could cost you some serious money, but no one will complain about the quality loss.

Especially when customers have no idea what the source looks like, so they have no source to compare the encode to :)

Of course, I'm assuming that you are authoring something other than customer's home videos (like commercial videos).

[Dark Shikari]

Sorry guys, you've all been trolled.

All of you. Every single last one of you. Including me. We've all been had.

kolak, I congratulate you on a successful prank. You've managed to take an encoder that is laughably awful and convince people that it's even worth considering. Though few were likely convinced it was better than x264, many expected -- including myself -- that it was actually a worthwhile encoder, worthy of x264's competition. Really, I was hoping CCE HD was at least decent, in the hopes that I could copy some ideas from it. You had me completely fooled.

But all good things must come to an end, even truly epic trolls. Because now I have access to a copy of CCE-HD. And I'm doing an encoder review on your pile of garbage. Not a very detailed one, as I'm not going to dedicate hours to throwing all my test clips at this, but one nonetheless.

Test case: parkjoy 1080p (Slowed down to 24000/1001fps for Blu-ray compatibility)
Bitrate: 14mbps
x264 commandline: --preset veryslow --weightp 0 --ref 4 --tune film --keyint 24 --slices 4 --aud --nal-hrd vbr --bframes 3 --b-pyramid strict --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --slow-firstpass (2-pass)
CCE-HD options: Full screenshots (http://x264.nl/developers/Dark_Shikari/ccehd/settings.png)

Area 1: Mode decision

1. CCE-HD doesn't even try to use i4x4 or i16x16 blocks. It only uses i8x8 for its intra modes.

2. CCE-HD does not do any 16x8 or 8x16 motion searches. It practically never uses such blocks; the only case they even occur is when a p8x8 block happens to have two pairs of identical motion vectors via sheer luck. Thus, effectively, CCE-HD only uses 16x16 and 8x8 modes (like Xvid or Theora).

3. CCE-HD has relatively limited analysis in B-frames (no 8x8 direct blocks for example).

Area 2: Motion estimation

1. CCE-HD has a nasty tendency to get whole bunches of completely wrong motion vectors even in areas of trivial motion.

Image: CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdmvs.png)

2. CCE-HD is completely incapable of capturing large-scale, long-distance motion. In this example, x264 perfectly captures the motion of the tree over the course of 4 frames, while CCE-HD utterly fails to, coding the entire tree as intra, despite only having to handle a distance of 3 frames (due to the encoder choosing to use fewer B-frames).

Image: x264 (http://x264.nl/developers/Dark_Shikari/ccehd/x264modes.png) / CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdmodes.png) (orange/red is intra, blue is inter, yellow is skip)

Area 3: Psy/Overall

CCE-HD is quite blurry even at 14mbps despite having adaptive quantization. What more do you want?

Image: x264 (http://x264.nl/developers/Dark_Shikari/ccehd/x264_10000.png) / CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdquality.png) / Source (http://x264.nl/developers/Dark_Shikari/ccehd/source.png)

























Actually, I lied. The above comparison is between x264 at 10mbps and CCE-HD at 14mbps. Here's what x264 actually looks like at the same bitrate. (http://x264.nl/developers/Dark_Shikari/ccehd/x264_14000.png)

Samples: x264 14mbit (http://x264.nl/developers/Dark_Shikari/ccehd/x264_14000.h264), x264 10mbit (http://x264.nl/developers/Dark_Shikari/ccehd/x264_10000.h264), CCE-HD 14mbit (http://x264.nl/developers/Dark_Shikari/ccehd/ccehd.h264)

Are you familiar with the phrase "the jig is up"?

[nurbs]

I think something is wrong with the 14Mbps x264 screenshot. The colors are off compared to the 10Mbps x264 and the CCE-HD screenshot.

[Dark Shikari]

I think something is wrong with the 14Mbps x264 screenshot. The colors are off compared to the 10Mbps x264 and the CCE-HD screenshot.BT.601/709 mismatch, fixed.

[chompy]

Thanks DS for your comparison... The only inconvenient I see (getting forward of kolak) is that 14Mbps can difficultly be considered blu-ray bitrate.

Greetings

[jpsdr]

I just did The Island trailer, (anyone else have problems downloading? Chrome kept finishing the download at ~1GB, and I had to use wget to actually download the damn thing!!!)
I was quite impressed with the results using x264 1772, and the following CLI:


Have you try the Jeeb's version, wich include weightp also for chroma, and the fade compensation patch ?
I think result will be even better.

[jpsdr]

Because now I have access to a copy of CCE-HD.
Being the devil's lawyer, what version of CCE-HD ?
Also, what version of x264 ?
Agree also that test should have been made at least at 25~30Mb, to be more on blu-ray configuration.
Because those who apparently use pro encoder (i think at mp3dom and shon3i), never deny the fact that at "low" bitrate, x264 is indubitabely the best.

Now, DS, i think the fact that you have access to CCE-HD is an excellent think, beacause shon3i and mp3dom, "often" talk of some banding and small others problems, specialy on animation, at high bitrate, there is with x264 and not with pro encoder. I think they speak principaly of CCE-HD and Blu-code.
See post of mp3dom here (http://doom10.org/index.php?topic=298.msg2132#msg2132).

So, if shon3i/mp3dom and DS could you pleeaaaaseeee work together, to find/provide (even privately and secretely if there is license issues ;)) a sample wich exibit the "problems" on x264 and not with CCE-HD, this way DS (and x264 team) can compare and eventualy (if possible) find how to improve x264, would be reeeaalyyy (seriously) an excellent thing.
I think we are all trying to improve x264.

[shon3i]

@Dark Shikari, many thanks for comparation.

We all know that CCE HD is suck on mid-low bitrates. Here we talking about >25mbps and higher. x264 on that bitrate not show enough respect with fades, grain, noise, where CCE HD gives more overall respect, while other scenes are "like kolak says" more constant quality. That is whole point. We know that x264 is far efficient than any encoder.

[Dark Shikari]

Being the devil's lawyer, what version of CCE-HD ?Some 2010 version.

@Dark Shikari, many thanks for comparation.

We all know that CCE HD is suck on mid-low bitrates. Here we talking about >25mbps and higher. x264 on that bitrate not show enough respect with fades, grain, noise, where CCE HD gives more overall respect, while other scenes are "like kolak says" more constant quality. That is whole point. We know that x264 is far efficient than any encoder.Real Blu-rays are rarely authored at over 25mbps; commercial Blu-rays often go as low as 18 average. Also, "only good at high bitrates" is marketing terminology for "extremely bad, so you need to give it high bitrates before it stops sucking".

while other scenes are "like kolak says" more constant quality."Constantly awful" is not a good thing.

a sample wich exibit the "problems" on x264 and not with CCE-HDYou're missing the point entirely. There are many ways x264 could be improved, particularly in the realm of "very near transparent encoding", and I'm absolutely welcome to any ideas for this. I already have a pretty decent list of things that could be done, but obviously such a list is nowhere near complete.

However, if you are looking at CCE-HD as a "target" for that improvement, you're crazy. This is like trying to improve a Ferrari by taking apart a Ford Focus. Can the Ferrari be improved? Absolutely, no doubt about it! But surely you can find better ways to do it than by analyzing a vastly inferior car.

I'm done with this thread. If people want to continue feeding a dead troll, feel free. If you actually care about improving x264, you will stop blathering about CCE-HD and instead investigate ways to improve x264. Anyone who continues harping on about how we should waste our time comparing ourselves to amateur-grade encoding software instead of doing real development is clearly not actually interested in improving x264. As such, I will ignore all future comments on Doom9 from such people.

[Biggiesized]

Real Blu-rays are rarely authored at over 25mbps; commercial Blu-rays often go as low as 18 average. Also, "only good at high bitrates" is marketing terminology for "extremely bad, so you need to give it high bitrates before it stops sucking"

That's a pretty bold claim. There are dozens of Blu-rays authored which have an average bit rate over 25 Mbps, especially Sony Blu-rays with flat aspect ratios.

[Dark Shikari]

That's a pretty bold claim. There are dozens of Blu-rays authored which have an average bit rate over 25 MbpsSure, there are some, though not an enormous number in the large scheme of things. But more importantly, saying "we can do a good job at 35mbps" is completely meaningless, because so can MPEG-2. So can Bink.

(Now, I agree that more should use higher bitrates; most Blu-rays have a large portion of their space wasted by pointlessly duplicated and large audio tracks.)

[kolak]

Sorry guys, you've all been trolled.

All of you. Every single last one of you. Including me. We've all been had.

kolak, I congratulate you on a successful prank. You've managed to take an encoder that is laughably awful and convince people that it's even worth considering. Though few were likely convinced it was better than x264, many expected -- including myself -- that it was actually a worthwhile encoder, worthy of x264's competition. Really, I was hoping CCE HD was at least decent, in the hopes that I could copy some ideas from it. You had me completely fooled.

But all good things must come to an end, even truly epic trolls. Because now I have access to a copy of CCE-HD. And I'm doing an encoder review on your pile of garbage. Not a very detailed one, as I'm not going to dedicate hours to throwing all my test clips at this, but one nonetheless.

Test case: parkjoy 1080p (Slowed down to 24000/1001fps for Blu-ray compatibility)
Bitrate: 14mbps
x264 commandline: --preset veryslow --weightp 0 --ref 4 --tune film --keyint 24 --slices 4 --aud --nal-hrd vbr --bframes 3 --b-pyramid strict --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 30000 --slow-firstpass (2-pass)
CCE-HD options: Full screenshots (http://x264.nl/developers/Dark_Shikari/ccehd/settings.png)

Area 1: Mode decision

1. CCE-HD doesn't even try to use i4x4 or i16x16 blocks. It only uses i8x8 for its intra modes.

2. CCE-HD does not do any 16x8 or 8x16 motion searches. It practically never uses such blocks; the only case they even occur is when a p8x8 block happens to have two pairs of identical motion vectors via sheer luck. Thus, effectively, CCE-HD only uses 16x16 and 8x8 modes (like Xvid or Theora).

3. CCE-HD has relatively limited analysis in B-frames (no 8x8 direct blocks for example).

Area 2: Motion estimation

1. CCE-HD has a nasty tendency to get whole bunches of completely wrong motion vectors even in areas of trivial motion.

Image: CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdmvs.png)

2. CCE-HD is completely incapable of capturing large-scale, long-distance motion. In this example, x264 perfectly captures the motion of the tree over the course of 4 frames, while CCE-HD utterly fails to, coding the entire tree as intra, despite only having to handle a distance of 3 frames (due to the encoder choosing to use fewer B-frames).

Image: x264 (http://x264.nl/developers/Dark_Shikari/ccehd/x264modes.png) / CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdmodes.png) (orange/red is intra, blue is inter, yellow is skip)

Area 3: Psy/Overall

CCE-HD is quite blurry even at 14mbps despite having adaptive quantization. What more do you want?

Image: x264 (http://x264.nl/developers/Dark_Shikari/ccehd/x264_10000.png) / CCE-HD (http://x264.nl/developers/Dark_Shikari/ccehd/ccehdquality.png) / Source (http://x264.nl/developers/Dark_Shikari/ccehd/source.png)

Actually, I lied. The above comparison is between x264 at 10mbps and CCE-HD at 14mbps. Here's what x264 actually looks like at the same bitrate. (http://x264.nl/developers/Dark_Shikari/ccehd/x264_14000.png)

Samples: x264 14mbit (http://x264.nl/developers/Dark_Shikari/ccehd/x264_14000.h264), x264 10mbit (http://x264.nl/developers/Dark_Shikari/ccehd/x264_10000.h264), CCE-HD 14mbit (http://x264.nl/developers/Dark_Shikari/ccehd/ccehd.h264)

Are you familiar with the phrase "the jig is up"?

1. You will be contacted by CTC with question about license.
2. Your test file is useless- it's very special file and in real life encodes this kind of scenes almost does not exist.
3. Your test file does only test compressibility- which we all know x264 has the best.
4. You use bitrates which are way below BD typical use- CC-HDe was not designed for web encoding.
5. Look at your screen grabs- did you enable 4x4 matrixes? You have no clue how to use CC-HDe- it's not "press Encode button" encoder. Stop pretending (when needed) being an idiot- becuse you're not :)
6. Show me your encode of Iland trailer with CC-HDe. Do you want to bet my version will be way better?
7. What was the version- 1.09.05? It's an old one.
8. You have no clue about encoding for BD and typical workflow in authoring studio.


Andrew

[shon3i]

If you actually care about improving x264, you will stop blathering about CCE-HD and instead investigate ways to improve x264.As long that improvment can be used for BD authoring, and solove current problems, otherwise, ccehd will be better choice for studios.

[kolak]

@Dark Shikari, many thanks for comparation.

We all know that CCE HD is suck on mid-low bitrates. Here we talking about >25mbps and higher. x264 on that bitrate not show enough respect with fades, grain, noise, where CCE HD gives more overall respect, while other scenes are "like kolak says" more constant quality. That is whole point. We know that x264 is far efficient than any encoder.

Yes- but DS does not get it and when he can test it, he chooses 14mbit on extreamly difficult one scene sample.
No comments :)

DS- thanks for test- your comments will be analyzed.

Andrew

[kolak]

I just did The Island trailer, (anyone else have problems downloading? Chrome kept finishing the download at ~1GB, and I had to use wget to actually download the damn thing!!!)

I was quite impressed with the results using x264 1772, and the following CLI:

[code]
c:\x264.exe --bitrate 25000 --preset slow --tune film --open-gop bluray --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1
-o out.264 Island_1080p24_x264Lossless_6chFLAC.mkv --index island.idx

c:\x264.exe --bitrate 25000 --preset slow --tune film --open-gop bluray --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000

.....

Derek

Check frame 910 and few after.
Also fade after 605 frame.

Tried no mbtree, open-gop: nothing helps for fades problem and high motion scenes :(

Andrew

[Hagbard23]

Originally Posted by Dark Shikari View Post
Sorry guys, you've all been trolled.

All of you. Every single last one of you. Including me. We've all been had.

<BIGGRIN> No, No, good sport....not me...not me...i have not been trolled...</BIGGRIN>

http://forum.doom9.org/showthread.php?p=1457278#post1457278

Kolak: Give it up, and please go away...you are wasting our time and nobody wants to read your indulgements...you are out man...far out...

1. You will be contacted by CTC with question about license.

Sounds like you are a bit ill, man...just go...go away to your cellar and try some dope to keep you down...

[RunningSkittle]

Check frame 910 and few after.
Also fade after 605 frame.

Andrew

Sorry Kolak, we know x264 can use some improvements /DS impersonation/ patches welcome!, but overall it makes CCE look like a joke. Saying "throw more bits at it!!!" does not make a good encoder!

As already said:
"the jig is up"

[kolak]

Sorry Kolak, we know x264 can use some improvements /DS impersonation/ patches welcome!, but overall it makes CCE look like a joke. Saying "throw more bits at it!!!" does not make a good encoder!

As already said:

Sorry- but CC-HDe is never product than x264- can use many improvements- this is not an argument :)

There is no real adventage which x264 has over CC-HDe at BD bitrates. Iland trailer, which is quite a good, typical source showed this. DS test had almost nothing to do with BD.

Only nm has done some test and posted video and as it's very good, it has problems and in overall quality does not win with CC-HDe.

I showed real problems in x264 at BD bitrates and for today there is no way to solve them.

Still waiting to see perfect encode of Iland triler from x264. 961 first frames (that's what I have got), BD pressets, 28Mbit average bitrate (38Mbit max) with 140, 142 black bars (top, bottom).


Andrew

[kolak]

...
Sounds like you are a bit ill, man...just go...go away to your cellar and try some dope to keep you down...



You need license to use this software compared to free x264.

Andrew

[jpsdr]

I'll try to get the trailler, and see what i can achieve...

Edit :
With x264, forget to specify...

[kolak]

I'll try to get the trailler, and see what i can achieve...

Thanks.


Andrew

[jpsdr]

Ok, since kolak refuses to post CCE HD sample, i asked CCE support did i can post some test samples with their encoder, and they answer is yes, along is sample licence allow this. So i will today install XP64-bit on mine home pc, and i will encode every source with lastest CCE-HD you want. Just please give me source you want.

The Island trailer would be the best choice i think. Some encode have already been made with x264, i'll try also one, so, it can be compared.

[aegisofrime]

You need license to use this software compared to free x264.

Andrew

Are you accusing DS of pirating the software? What makes you think he can't get it legitimately?

Sorry- but CC-HDe is never product than x264- can use many improvements- this is not an argument :)

Does not compute. For someone who's from the UK, your English is horrendous, and sometimes downright incomprehensible. And after so many posts it seems that you still can't spell "Island" properly.

You claim that people "shout" at you, but you can help reduce misunderstanding by articulating your posts properly.

[kolak]

Are you accusing DS of pirating the software? What makes you think he can't get it legitimately?



Does not compute. For someone who's from the UK, your English is horrendous, and sometimes downright incomprehensible. And after so many posts it seems that you still can't spell "Island" properly.

You claim that people "shout" at you, but you can help reduce misunderstanding by articulating your posts properly.

English is not my native language.

CC-HDe can't be installed on any machine. It needs more than just a dongle to work. CTC provides preinstalled system drive in case of problems.


Andrew

[Biggiesized]

This is a short but sweet clip from RED; it was the first public footage of the RED One with the new Mysterium-X sensor.

It's a piece of cake to encode, but it's another "film" source to test nonetheless.

Should we test the encoders against it?

EDIT: The source file is 1080p ProRes LT. I can prepare a 1080p i420 source for everyone to use this afternoon.

[kolak]

This is a short but sweet clip from RED; it was the first public footage of the RED One with the new Mysterium-X sensor.

It's a piece of cake to encode, but it's another "film" source to test nonetheless.

Should we test the encoders against it?

EDIT: The source file is 1080p ProRes LT. I can prepare a 1080p i420 source for everyone to use this afternoon.

Where is it:)

ProRes is fine- just use QT input plugin in avisynth- it gives YUY2 on the output (with no gamma or other color shifts).


Andrew

[nm]

ProRes is fine- just use QT input plugin in avisynth- it gives YUY2 on the output (with no gamma or other color shifts).

I'd rather have huffyuv or anything that can be decoded with current FFmpeg.

[kolak]

I'd rather have huffyuv or anything that can be decoded with current FFmpeg.

OK- just ProRes is small and has good enough quality.


Andrew

[RunningSkittle]

The reason a lot of us havnt tried the island trailer is
1) huge file
2) ffmpeg cant decode lagarith, so you need windows. Some of dont have windows,:script: and dont want wine.

[Biggiesized]

Where is it:)

ProRes is fine- just use QT input plugin in avisynth- it gives YUY2 on the output (with no gamma or other color shifts).


Andrew

I was going to dump a YUV raw file so both x264 and CC-HDe can import it for encoding comparisons.

[jpsdr]

The reason a lot of us havnt tried the island trailer is
1) huge file

Yeah.... 2.6Go at 100kB/s... it's looooonnnggggg...... Argh !


2) ffmpeg cant decode lagarith, so you need windows. Some of dont have windows,:script: and dont want wine.
Oh ? Lagarith ? Nice, i was affraid of some unusual codec...

[kolak]

I was going to dump a YUV raw file so both x264 and CC-HDe can import it for encoding comparisons.

RAR or ZIP is at least :)


Andrew

[kolak]

Yeah.... 2.6Go at 100kB/s... it's looooonnnggggg...... Argh !


Oh ? Lagarith ? Nice, i was affraid of some unusual codec...

Do it over night- mine has dropped, so I have only 960 frames :)


Andrew

[Audionut]

ftp://island@94.242.206.22/

Includes original Lagarith file.
Encode to Huffy file.
And 200Mb 7z's of the Huffy file.


edit: don't expect it to stay there for ever.

[jpsdr]

Do it over night- mine has dropped, so I have only 960 frames :)
Andrew

Same problem with me, download suddenly stoped at 1GB, i have only 962 frames.
I'll do with this.

[kolak]

Same problem with me, download suddenly stoped at 1GB, i have only 962 frames.
I'll do with this.

Fine, enough- just add bars to cover this noisy black areas (140,142).


Andrew

[kolak]

The reason a lot of us havnt tried the island trailer is
1) huge file
2) ffmpeg cant decode lagarith, so you need windows. Some of dont have windows,:script: and dont want wine.

These are the reasons why you didn't try :)

Andrew

[Reimar]

2) ffmpeg cant decode lagarith, so you need windows. Some of dont have windows,:script: and dont want wine.

If you are motivated enough, you can find a decoder here:
http://repo.or.cz/w/FFMpeg-mirror/lagarith.git
discussion:
http://archives.free.net.ph/message/20090918.112008.10d3d282.en.html
No promises that it will work 100% though (though a lossless codec using x86 floating-point I'd not trust regardless of the decoder).

[Audionut]

Welcome to my little tutorial

How to over-saturate x264 "with the bitrate required for pro-encoders", "to work".

avisource("d:\island.avi")
crop(0,142,0,-142)
addborders(0,142,0,142)

Revision 1772 64pit patched build from here: http://x264.fushizen.eu/
x264 --preset placebo --tune grain --level 4.1 --pass 1 -B 25000 --me umh --bframes 3 --keyint 24 --open-gop bluray
--qpmin 0 --aq-mode 2 --fade-compensate 0.8 --rc-lookahead 120 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --acodec none -o

x264 --preset placebo --tune grain --level 4.1 --pass 2 -B 25000 --me umh --bframes 3 --keyint 24 --open-gop bluray
--qpmin 0 --aq-mode 2 --fade-compensate 0.8 --rc-lookahead 120 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --acodec none -o

Good example, frames: 343, 465, 551, 560,561,562 (for some reason few frames), 568, 580, 581 (than perfect 582), 584, 585 (than perfect 586), 857 (destroyed few bottom lines- PSY?)..... and so on (no time to analyze whole video). Some of them are very bad.

http://img87.imageshack.us/img87/9964/343encode.png
http://img508.imageshack.us/img508/6064/343source.png

http://img709.imageshack.us/img709/2473/465encode.png
http://img833.imageshack.us/img833/1337/465source.png

http://img228.imageshack.us/img228/4712/551encode.png
http://img843.imageshack.us/img843/4735/551source.png

http://img130.imageshack.us/img130/14/561encode.png
http://img179.imageshack.us/img179/691/561source.png

http://img820.imageshack.us/img820/4504/581encode.png
http://img822.imageshack.us/img822/219/581source.png

http://img703.imageshack.us/img703/4252/857encode.png
http://img574.imageshack.us/img574/4744/857source.png

[kolak]

Welcome to my little tutorial

How to over-saturate x264 "with the bitrate required for pro-encoders", "to work".

avisource("d:\island.avi")
crop(0,142,0,-142)
addborders(0,142,0,142)

Revision 1772 64pit patched build from here: http://x264.fushizen.eu/
x264 --preset placebo --tune grain --level 4.1 --pass 1 -B 25000 --me umh --bframes 3 --keyint 24 --open-gop bluray
--qpmin 0 --aq-mode 2 --fade-compensate 0.8 --rc-lookahead 120 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --acodec none -o

x264 --preset placebo --tune grain --level 4.1 --pass 2 -B 25000 --me umh --bframes 3 --keyint 24 --open-gop bluray
--qpmin 0 --aq-mode 2 --fade-compensate 0.8 --rc-lookahead 120 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000
--b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --acodec none -o



http://img87.imageshack.us/img87/9964/343encode.png
http://img508.imageshack.us/img508/6064/343source.png

http://img709.imageshack.us/img709/2473/465encode.png
http://img833.imageshack.us/img833/1337/465source.png

http://img228.imageshack.us/img228/4712/551encode.png
http://img843.imageshack.us/img843/4735/551source.png

http://img130.imageshack.us/img130/14/561encode.png
http://img179.imageshack.us/img179/691/561source.png

http://img820.imageshack.us/img820/4504/581encode.png
http://img822.imageshack.us/img822/219/581source.png

http://img703.imageshack.us/img703/4252/857encode.png
http://img574.imageshack.us/img574/4744/857source.png

Bad B frames were already sorted.

Nothing special with your frames- they are just as they should be at this bitrate.
I'll post same frames from pro encoder- so you will see that it's not joke like on DS test.

Can I just ask about speed for your encodes:)?

You can post frame 910 to see if placebo fixes it.


Andrew

[Audionut]

Nothing special with your frames- they are just as they should be at this bitrate.

Check the quote. They're some of the frames you claimed to be crap.

Can I just ask about speed for your encodes:)?

1.42 and 1.40fps. On a q6600 @ 3.2

More than acceptable. But maybe your onto something here. If I was working in an authoring house I would be doing stupid stuff like encoding with --preset ultrafast

Because at the end of the day, speed is more important that quality when releasing an encode to millions of viewers.

You can post frame 910 to see if placebo fixes it.

Doesn't matter what frame I post, the only thing broken in the first place was your ability to encode.

http://img213.imageshack.us/img213/5575/910encode.png
http://img253.imageshack.us/img253/6954/910source.png

I'll post same frames from pro encoder-
Really!!!! Have you been given permission?

[jpsdr]

My encoded test are finished (3 different files), but actualy my upload speed is at 4kb/s, so, will be for later...

[kolak]

Check the quote. there some of the frames you claimed to be crap.



1.42 and 1.40fps. On a q6600 @ 3.2

More than acceptable. But maybe your onto something here. If I was working in an authoring house I would be doing stupid stuff like encoding with --preset ultrafast

Because at the end of the day, speed is more important that quality when releasing an encode to millions of viewers.



Doesn't matter what frame I post, the only thing broken in the first place was your ability to encode.

http://img213.imageshack.us/img213/5575/910encode.png
http://img253.imageshack.us/img253/6954/910source.png

Yes- you know that this speed is unrealistic for authoring house. Pressets slow are fine.
Not sure who was your client- I can't do ultrafast for sure.

910 still bad- even at placebo- lots of details lost.


Andrew

[kieranrk]

Not sure who was your client- I can't do ultrafast for sure.


He said "if".

[kolak]

Check the quote. They're some of the frames you claimed to be crap.



1.42 and 1.40fps. On a q6600 @ 3.2

More than acceptable. But maybe your onto something here. If I was working in an authoring house I would be doing stupid stuff like encoding with --preset ultrafast

Because at the end of the day, speed is more important that quality when releasing an encode to millions of viewers.



Doesn't matter what frame I post, the only thing broken in the first place was your ability to encode.

http://img213.imageshack.us/img213/5575/910encode.png
http://img253.imageshack.us/img253/6954/910source.png


Really!!!! Have you been given permission?

http://www.mediafire.com/?7zxeva4elepjqzn (frames 888-930)

I've already done it. Compare frames 910 and later.
Most of the frames are like x264+ there are no much worse ones.

Fades and high motion frames are my only complains with x264. We can leave lack of some usable GUI and segment re-encodes for now.


Andrew

[Audionut]

Yes- you know that this speed is unrealistic for authoring house.

Since you are an "expert", what speeds are acceptable. FPS wise.

You do realise the difference in speed between my little cpu and the powerhouse that CCHDe comes with?

And what affect that has on encoded FPS?

910 still bad- even at placebo- lots of details lost.

You are the master of blanket statements.

[kolak]

He said "if".

Sorry- "if"
Yes- but this just shows that he has no real knowledge abut this job. Some clients don't care- some will ask you to show your results on massive TV and compare them to HDCAM-SR source.

Andrew

[kolak]

Since you are an "expert", what speeds are acceptable. FPS wise.

You do realise the difference in speed between my little cpu and the powerhouse that CCHDe comes with?

And what affect that has on encoded FPS?



You are the master of blanket statements.

If you don't see problem than with have nothing to talk about.

I do realize because I use only dual CPU machines- so maybe you don't :)

Half RT is ok- even with 12 cores machine x264 needs slow pressets to have acceptable speed.

CC-HDe does at least RT (up to 2 x faster than RT) on this powerhouse+ it has segment re-encoding- so x264 speed wise has no chance.


Andrew

[Biggiesized]

I'm uploading the source to Megaupload now, but it's going to be a long time before it's complete.

EDIT: Megaupload keeps botching the upload. I'll have to find another solution.

[sneaker_ger]

For the record, my simple encode:
AviSynth:
AVISource("Island_1080p24_huffy.avi")
crop(0,142,0,-142)
addborders(0,142,0,142)

Uses unpatched 1772 64bit from x264.nl.
avs2yuv island.avs - | x264 - --demuxer y4m --pre
set slow --tune grain --level 4.1 --weightp 0 --pass 1 -B 28000 --vbv-bufsize 30
000 --vbv-maxrate 38000 --slices 4 --keyint 24 --open-gop bluray --nal-hrd vbr -
-b-pyramid strict --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt
709" -o island.mkv
avs2yuv island.avs - | x264 - --demuxer y4m --pre
set slow --tune grain --level 4.1 --weightp 0 --pass 2 -B 28000 --vbv-bufsize 30
000 --vbv-maxrate 38000 --slices 4 --keyint 24 --open-gop bluray --nal-hrd vbr -
-b-pyramid strict --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt
709" -o island.mkv

http://www.abload.de/img/343sourcecy7q.png
http://www.abload.de/img/343encode2aic.png

http://www.abload.de/img/465sourcefl8x.png
http://www.abload.de/img/465encodevbij.png

http://www.abload.de/img/551sourceoxw2.png
http://www.abload.de/img/551encodeez96.png

http://www.abload.de/img/561sourcedlhl.png
http://www.abload.de/img/561encodeuz36.png

http://www.abload.de/img/581source6afi.png
http://www.abload.de/img/581encodetbs6.png

http://www.abload.de/img/857sourcewbub.png
http://www.abload.de/img/857encodex9w0.png

http://www.abload.de/img/910sourcewxd9.png
http://www.abload.de/img/910encoderyx6.png

Average fps over both passes 5.4 ( or 10.8 - however you calculate). Core i7-860 @ stock.

[kolak]

For the record, my simple encode:
AviSynth:
AVISource("Island_1080p24_huffy.avi")
crop(0,142,0,-142)
addborders(0,142,0,142)

Uses unpatched 1772 64bit from x264.nl.
avs2yuv island.avs - | x264 - --demuxer y4m --pre
set slow --tune grain --level 4.1 --weightp 0 --pass 1 -B 28000 --vbv-bufsize 30
000 --vbv-maxrate 38000 --slices 4 --keyint 24 --open-gop bluray --nal-hrd vbr -
-b-pyramid strict --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt
709" -o island.mkv
avs2yuv island.avs - | x264 - --demuxer y4m --pre
set slow --tune grain --level 4.1 --weightp 0 --pass 2 -B 28000 --vbv-bufsize 30
000 --vbv-maxrate 38000 --slices 4 --keyint 24 --open-gop bluray --nal-hrd vbr -
-b-pyramid strict --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt
709" -o island.mkv

http://www.abload.de/img/343sourcecy7q.png
http://www.abload.de/img/343encode2aic.png

http://www.abload.de/img/465sourcefl8x.png
http://www.abload.de/img/465encodevbij.png

http://www.abload.de/img/551sourceoxw2.png
http://www.abload.de/img/551encodeez96.png

http://www.abload.de/img/561sourcedlhl.png
http://www.abload.de/img/561encodeuz36.png

http://www.abload.de/img/581source6afi.png
http://www.abload.de/img/581encodetbs6.png

http://www.abload.de/img/857sourcewbub.png
http://www.abload.de/img/857encodex9w0.png

http://www.abload.de/img/910sourcewxd9.png
http://www.abload.de/img/910encoderyx6.png

Average fps over both passes 5.4 ( or 10.8 - however you calculate). Core i7-860 @ stock.

Please crop 140 and 142.
Problem with bad B frames has been fixed (it was buggy x264 build).

Current problem- fades (frames after 605), and section with cars eg, frame 910 and later.

Your 910 looks much better than Audionut's one- even if he used placebo pressets. Looks like every x264 build produce different quality.

Andrew

[poisondeathray]

Your 910 looks much better than Audionut's one- even if he used placebo pressets. Looks like every x264 build produce different quality.



They used different settings; but more importantly one was 28Mb/s, the other was 25Mb/s

[sneaker_ger]

I chose 142 because that's what Blue_MiSfit and Audionut used. Don't know if I want to do all the work again.

Here's a picture of kolak's 910 if anyone wants to compare:
http://www.abload.de/img/910kolakcceqbew.png

[sneaker_ger]

They used different settings; but more importantly one was 28Mb/s, the other was 25Mb/s

Yes, I used the bitrate as requested by kolak. Note that Audionut uses a patched build (chroma weightp, fade compensation), while mine is unpatched plus I deactivated weightp completely.

[kolak]

They used different settings; but more importantly one was 28Mb/s, the other was 25Mb/s

Yes- I've noticed it.


Andrew

[kolak]

I chose 142 because that's what Blue_MiSfit and Audionut used. Don't know if I want to do all the work again.

Here's a picture of kolak's 910 if anyone wants to compare:
http://www.abload.de/img/910kolakcceqbew.png

Yes- that's one of my first encodes (without bars).

Does it look like a garbage compared to x264 (placebo pressets)?
I don't think so- there are also more frames to compare, but I will make new encode (with black bars).


Andrew

[poisondeathray]

So how does CCE-HD do on the Island trailer @ 25Mb/s or 28Mb/s without segment re-encoding ?

[nurbs]

Also what is your system and how fast is CCE-HD on it?

[sneaker_ger]

Yes- that's one of my first encodes (without bars).

Does it look like a garbage compared to x264 (placebo pressets)?
I don't think so- there are also more frames to compare, but I will make new encode (with black bars).


Andrew

Please choose 142 142, so we can compare to the other encodes.

[kolak]

So how does CCE-HD do on the Island trailer @ 25Mb/s or 28Mb/s without segment re-encoding ?

This 888-930 sample are extract from 3 pass encode- no segment re-encode.

You get me wrong- x264 is great, but for BD encodes you want your file to be almost like a source. It's all there with x264, except some problem with fades and high motion scenes. It will depend on the source (we have tested one)- some of them may not introduce any problems, but some of them may introduce even more and without segment re-encoding it will be difficult to fix (and time consuming).
Other way- x264 problem is not with quality, but lack of some features, which all other pro encoders have. This is getting much more important if we talk about x264 usage for professional BD encodes.


Andrew

[Biggiesized]

http://rapidshare.com/files/432122371/LeoMX_1080p_i420.7z

If you're unfamiliar with .7z archives, use 7-zip to open them up.

http://www.7-zip.org/

EDIT: I've taken the old files offline. Use the new link above instead. It's one download instead of many.

[kolak]

Also what is your system and how fast is CCE-HD on it?

8 core (2x E5450) HP machine.

CC-HDe is about 15fps in Quality mode.
x264 needs slow pressets (which are still ok with quality) to have acceptable speed. Veryslow is 2-3fps.


Andrew

[sneaker_ger]

Also: download the complete file so the comparison is fair.

[kolak]

Please choose 142 142, so we can compare to the other encodes.

It was changed to be mod16, but I can use 142,142.


Andrew

[kolak]

Also: download the complete file so the comparison is fair.

Limit you file to 961 frames please- this will be faster. Yes- we have to use the same source.
We have another source to download :)


Andrew

[kolak]

Okay, RapidShare was tenfold faster than Megaupload. However, I did have to break the source file into 100 MB chunks.

http://rapidshare.com/files/431289233/LeoMX_1080p_i420.7z.001
http://rapidshare.com/files/431289782/LeoMX_1080p_i420.7z.002
http://rapidshare.com/files/431289791/LeoMX_1080p_i420.7z.003
http://rapidshare.com/files/431289800/LeoMX_1080p_i420.7z.004
http://rapidshare.com/files/431289795/LeoMX_1080p_i420.7z.005

If you're unfamiliar with .7z archives, use 7-zip to open them up.

http://www.7-zip.org/

How long is it?


Andrew

[poisondeathray]

This 888-930 sample are 3 pass encode- no segment re-encode.

You get me wrong- x264 is great, but for BD encodes you want your file to be almost like a source. It's all there with x264, except some problem with fades and high motion scenes. It will depend on the source (we have tested one)- some of them may not introduce any problems, but some of them may introduce even more and without segment re-encoding it will be difficult to fix (and time consuming).
Other way- x264 problem is not with quality, but lack of some features, which all other pro encoders have. This is getting much more important if we talk about x264 usage for professional BD encodes.


Andrew


How did I get you wrong? :confused: ....All I asked was how did CCE-HD perform

Sorry, I missed your other post , thanks for posting that
http://forum.doom9.org/showthread.php?p=1458157#post1458157

http://www.mediafire.com/?7zxeva4elepjqzn



So to clarify, what bitrate was that one done at ?

So in your opinion, do you think that 888-930 CCE-HD sample was close to the source? Or would you need to re-encode it

I agree with your other points about x264, but this has been known for a long time (poor fades, no segment re-encoding). You could try the fade-compensation patch

[Biggiesized]

The source is about 36 seconds and includes fades from and to black.

[kolak]

For the record, my simple encode:
AviSynth:
AVISource("Island_1080p24_huffy.avi")
crop(0,142,0,-142)
addborders(0,142,0,142)



Can you post frames after 605 (fade ones)?
Your file seams to be quite consistent with quality.

Thanks,
Andrew

[kolak]

How did I get you wrong? :confused: ....All I asked was how did CCE-HD perform

Sorry, I missed your other post , thanks for posting that
http://forum.doom9.org/showthread.php?p=1458157#post1458157

http://www.mediafire.com/?7zxeva4elepjqzn



So to clarify, what bitrate was that one done at ?

So in your opinion, do you think that 888-930 CCE-HD sample was close to the source? Or would you need to re-encode it

I agree with your other points about x264, but this has been known for a long time (poor fades, no segment re-encoding). You could try the fade-compensation patch

It was not directly to you- about getting me wrong.

It was 28Mbits (38Mbits max).

It was one of my first tries- I had bit better results, but its good enough.

Andrew

[sneaker_ger]

Can you post frames after 605 (fade ones)?
Your file seams to be quite consistent with quality.

Thanks,
Andrew

Choose yourself:
http://rapidshare.com/files/431294027/island.mkv

We should keep in mind that this is an action packed trailer - the complete movie should be easier to encode.

[ajp_anton]

After 20 pages, has anyone posted a kolak-approved sample encoded by CCE-HD?

[kolak]

Choose yourself:
http://rapidshare.com/files/431294027/island.mkv

But we should keep in mind that this is a action packed trailer - the complete movie should be easier to encode.

Thanks.
Rapidshare again :)

That's why I've chosen 28Mbit average. Movie would be probably transparent at about 24Mbits.
Recently done title with 22Mbits (shot on RED) and it was as close to the source as this trailer. In the same time interlaced 60i live footage is sometimes problematic even at 36Mbit.



Andrew

[kieranrk]

In the same time interlaced 60i live footage is sometimes problematic even at 36Mbit.


There's also tallships.yuv which is 60i live footage with very difficult water scenes.

[kolak]

After 20 pages, has anyone posted a kolak-approved sample encoded by CCE-HD?

No.

Only this (some decompressed section):

http://www.mediafire.com/?7zxeva4elepjqzn


Andrew

[kolak]

There's also tallships.yuv which is 60i live footage with very difficult water scenes.

I was looking for it. Where can I find source?


Andrew

[nm]

I was looking for it. Where can I find source?

Here's my torrent (@ 2 Mbps since there are no other seeders for the original version now):
http://video-test-sequences.hexagon.cc/torrents

[Audionut]

If you don't see problem than with have nothing to talk about.

So you can't pinpoint exactly where the problems are with my encode?

Look at how easy it is.

Here is the source at 100% crop and 400% enlarge,
http://img87.imageshack.us/img87/2127/source.png

Here is x264 at 28Mbits,
http://img571.imageshack.us/img571/9090/x264y.png

And here is your encode,
http://img242.imageshack.us/img242/5418/cchde.png

Notice how yours is blurry and has chroma shift?

This is fun, lets compare some more.

I do realize because I use only dual CPU machines- so maybe you don't :)

Good answer. :rolleyes:

Half RT is ok

How many encodes do you do in a day?
Maybe if you didn't have to "segment" re-encode everything, you wouldn't be so worried about speed.

I try and do things right the first time with an encoder that is capable of it.

Yes..... (without bars).

I didn't realise we were allowed to cheat!!

[TheFluff]

Yes- that's one of my first encodes (without bars).

Does it look like a garbage compared to x264 (placebo pressets)?
I don't think so- there are also more frames to compare, but I will make new encode (with black bars).

The claim you're trying to defend is that x264 produces bad output. Dark Shikari may have accused CCE-HD of being a shitty inefficient encoder (which, incidentally, is obviously true; the only reason it gets away with being so shitty is that everyone uses it with bitrates at which even VP6 could manage a decent output) but that does not have anything to do with your original claim. Do you or do you not admit that x264 does not produce any worse output than CCE-HD at these ridiculous bitrates?

Personally, while I can spot differences between the source and x264 encode screenshots posted above, the differences are completely insignificant and aren't even worth discussing. Nobody will sit around doing frame-by-frame pixel comparisons between source and bluray on their TV.

Also, when will you admit to being a CTC employee out astroturfing in your spare time?

[kolak]

The claim you're trying to defend is that x264 produces bad output. Dark Shikari may have accused CCE-HD of being a shitty inefficient encoder (which, incidentally, is obviously true; the only reason it gets away with being so shitty is that everyone uses it with bitrates at which even VP6 could manage a decent output) but that does not have anything to do with your original claim. Do you or do you not admit that x264 does not produce any worse output than CCE-HD at these ridiculous bitrates?

Personally, while I can spot differences between the source and x264 encode screenshots posted above, the differences are completely insignificant and aren't even worth discussing. Nobody will sit around doing frame-by-frame pixel comparisons between source and bluray on their TV.

Also, when will you admit to being a CTC employee out astroturfing in your spare time?

No- that some frames are much worse quality (with visible softnes and blocking) and this is the problem. I already said this many times. Even if pro encoders may be a bit less sharp they will not produce visible blocking or other problems (or if they will it's very easy to fix). Maybe it's only my personal choice, but I prefer more consistent quality than even bit better with random much worse frames.

As you said at this bitrate difference is very small, but this is the way how it should be and x264 can do it with no problem.
Lets hope some fix for fades/high motion problems will come and all will be sorted.

Latest 1772 (sneaker_ger) build seams to be better already- looks like DS is doing some fixes when we talk about the problems:)
I'm not CTC employee.

Andrew

[kolak]

So you can't pinpoint exactly where the problems are with my encode?

Look at how easy it is.

Here is the source at 100% crop and 400% enlarge,
http://img87.imageshack.us/img87/2127/source.png

Here is x264 at 28Mbits,
http://img571.imageshack.us/img571/9090/x264y.png

And here is your encode,
http://img242.imageshack.us/img242/5418/cchde.png

Notice how yours is blurry and has chroma shift?

This is fun, lets compare some more.



Good answer. :rolleyes:



How many encodes do you do in a day?
Maybe if you didn't have to "segment" re-encode everything, you wouldn't be so worried about speed.

I try and do things right the first time with an encoder that is capable of it.



I didn't realise we were allowed to cheat!!

Even if I prefer way how 264 keeps all grain no one will see this difference at 1:1.
This is not the problem- there is one which is visible at 1:1.
Don't you see it?

Haven't seen encoder which will do 90min movie without any problems. If x264 can do it than great.

What cheating? You have to go back and read posts form the beginning- this is an old encode with no modification to the source. So it's actually in the favour for x264.

What if you find droput on your ecnoded file (it happens a lot)? Another 10h encode- no time for this :(

Andrew

[jpsdr]

Ok, if you want to check, my encodes:
Files can be downloaded here (http://dl.free.fr/bDrp1utB6). Don't know what download speed you'll get, be a little patient, file is 400MB.
The x264 version used is 1772 Jeeb's x64 build.

You have 3 different encodes.
File Island-1.264
Encode parameters :

@echo off

SET E_SRC=%5%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%5%1.stats
SET TUNING=%4
SET LOG_FILE_1=%5%1_log_1.txt
SET LOG_FILE_2=%5%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --subme 7 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

Bitrate : 28000 Tune : film

Log result files
1rst pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:13.14 size:375631
x264 [info]: frame P:355 Avg QP:19.63 size:170983
x264 [info]: frame B:559 Avg QP:19.78 size:119872
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 43.7% 41.6% 14.7%
x264 [info]: mb P I16..4: 7.7% 38.2% 4.5% P16..4: 15.4% 6.8% 2.0% 0.4% 0.2% skip:24.7%
x264 [info]: mb B I16..4: 1.1% 13.9% 0.9% B16..8: 23.2% 10.9% 3.5% direct:11.5% skip:35.0% L0:35.1% L1:36.1% BI:28.9%
x264 [info]: 8x8 transform intra:73.8% inter:57.9%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: coded y,uvDC,uvAC intra: 86.7% 85.1% 69.9% inter: 38.4% 42.8% 19.0%
x264 [info]: i16 v,h,dc,p: 41% 10% 34% 15%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 13% 38% 5% 6% 5% 7% 6% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 17% 28% 6% 8% 6% 9% 6% 9%
x264 [info]: i8c dc,h,v,p: 55% 21% 14% 10%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 60.8% 11.9% 25.6% 1.6% 0.1%
x264 [info]: ref B L0: 90.0% 10.0%
x264 [info]: ref B L1: 91.0% 9.0%
x264 [info]: kb/s:29057.84

encoded 962 frames, 7.66 fps, 29057.84 kb/s

2nd pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:17.75 size:286576
x264 [info]: frame P:355 Avg QP:20.04 size:170442
x264 [info]: frame B:559 Avg QP:20.60 size:123406
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 38.6% 49.4% 12.0%
x264 [info]: mb P I16..4: 7.4% 36.9% 4.4% P16..4: 11.7% 8.3% 2.0% 0.4% 0.2% skip:28.7%
x264 [info]: mb B I16..4: 0.9% 14.2% 1.0% B16..8: 21.3% 12.8% 5.0% direct: 8.0% skip:36.8% L0:36.5% L1:34.9% BI:28.5%
x264 [info]: 8x8 transform intra:75.2% inter:56.7%
x264 [info]: direct mvs spatial:87.1% temporal:12.9%
x264 [info]: coded y,uvDC,uvAC intra: 88.1% 83.8% 70.0% inter: 37.1% 36.1% 15.1%
x264 [info]: i16 v,h,dc,p: 42% 13% 26% 19%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 11% 16% 8% 12% 9% 12% 9% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 11% 11% 9% 13% 10% 13% 9% 16%
x264 [info]: i8c dc,h,v,p: 44% 25% 14% 17%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 73.5% 9.1% 16.1% 1.1% 0.1%
x264 [info]: ref B L0: 87.5% 12.5%
x264 [info]: ref B L1: 91.2% 8.8%
x264 [info]: kb/s:28561.15

encoded 962 frames, 2.21 fps, 28561.15 kb/s


File : Island-2.264
Encode parameters :

@echo off

SET E_SRC=%5%1.avs
SET E_DST=%3%1.264
SET STAT_FILE=%5%1.stats
SET TUNING=%4
SET LOG_FILE_1=%5%1_log_1.txt
SET LOG_FILE_2=%5%1_log_2.txt

REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

REM Set of Buffer (ici le buffer)
set BUF_BR=30000

REM 1ère passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 1 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --fgo 10 --subme 7 --me "umh" --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --output NUL %E_SRC% 2> %LOG_FILE_1%

REM 2ème passe
x264_x64.exe --profile "high" --preset "placebo" --tune %TUNING% --pass 2 --bitrate %2 --stats %STAT_FILE% --level "4.1" --qpmin 0 --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --keyint 24 --min-keyint 2 --mvrange 511 --ref 4 --bframe 3 --slices 4 --b-pyramid "strict" --open-gop "bluray" --fade-compensate 0.7 --fgo 10 --aq-mode 2 --aud --nal-hrd "vbr" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --videoformat "ntsc" --sar 1:1 --threads 0 --thread-input --output %E_DST% %E_SRC% 2> %LOG_FILE_2%

Bitrate : 28000 Tune : Film

Log files:
1rst pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:13.61 size:364583
x264 [info]: frame P:355 Avg QP:19.78 size:169528
x264 [info]: frame B:559 Avg QP:20.03 size:123344
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 42.8% 36.2% 21.0%
x264 [info]: mb P I16..4: 3.7% 14.5% 2.7% P16..4: 23.0% 20.5% 6.7% 0.9% 1.9% skip:26.2%
x264 [info]: mb B I16..4: 0.3% 3.1% 0.2% B16..8: 34.8% 10.8% 6.1% direct:12.3% skip:32.4% L0:40.9% L1:44.0% BI:15.1%
x264 [info]: 8x8 transform intra:60.3% inter:43.7%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: coded y,uvDC,uvAC intra: 81.2% 80.8% 68.9% inter: 50.8% 53.7% 25.5%
x264 [info]: i16 v,h,dc,p: 47% 12% 30% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 15% 38% 5% 6% 5% 7% 5% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 14% 33% 6% 8% 6% 9% 6% 9%
x264 [info]: i8c dc,h,v,p: 57% 20% 11% 12%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 59.8% 14.6% 21.8% 3.8% 0.1%
x264 [info]: ref B L0: 86.9% 13.1%
x264 [info]: ref B L1: 89.5% 10.5%
x264 [info]: kb/s:29236.15

encoded 962 frames, 6.70 fps, 29236.15 kb/s

2nd pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:17.78 size:281279
x264 [info]: frame P:355 Avg QP:19.64 size:171351
x264 [info]: frame B:559 Avg QP:20.83 size:120241
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 36.4% 47.3% 16.3%
x264 [info]: mb P I16..4: 3.3% 11.9% 2.1% P16..4: 21.0% 25.5% 5.4% 0.7% 1.5% skip:28.6%
x264 [info]: mb B I16..4: 0.2% 1.9% 0.2% B16..8: 34.4% 11.9% 7.8% direct:10.4% skip:33.3% L0:41.7% L1:45.2% BI:13.1%
x264 [info]: 8x8 transform intra:61.9% inter:45.4%
x264 [info]: direct mvs spatial:81.8% temporal:18.2%
x264 [info]: coded y,uvDC,uvAC intra: 79.2% 77.4% 68.2% inter: 50.3% 50.3% 24.6%
x264 [info]: i16 v,h,dc,p: 54% 17% 18% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 11% 11% 10% 14% 10% 13% 9% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 8% 10% 11% 16% 11% 15% 10% 15%
x264 [info]: i8c dc,h,v,p: 29% 19% 8% 44%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 67.4% 9.9% 20.0% 2.5% 0.1%
x264 [info]: ref B L0: 84.3% 15.7%
x264 [info]: ref B L1: 89.0% 11.0%
x264 [info]: kb/s:28222.09

encoded 962 frames, 2.05 fps, 28222.09 kb/s


File : Island-3.264
Encode parameters : Sames as file Island-2.264.
Bitrate : 28000 Tune : grain

Log files :
1rst pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:17.26 size:290926
x264 [info]: frame P:355 Avg QP:20.48 size:171553
x264 [info]: frame B:559 Avg QP:20.05 size:126960
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 30.5% 50.4% 19.1%
x264 [info]: mb P I16..4: 4.3% 14.9% 3.2% P16..4: 24.4% 19.3% 6.5% 0.8% 1.8% skip:24.8%
x264 [info]: mb B I16..4: 0.4% 2.7% 0.4% B16..8: 32.3% 11.7% 6.8% direct:13.7% skip:32.0% L0:36.6% L1:42.7% BI:20.7%
x264 [info]: 8x8 transform intra:62.8% inter:39.3%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: coded y,uvDC,uvAC intra: 80.5% 81.2% 69.6% inter: 51.8% 57.4% 35.8%
x264 [info]: i16 v,h,dc,p: 42% 13% 31% 14%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 18% 37% 4% 6% 5% 7% 5% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 14% 33% 6% 8% 6% 9% 6% 9%
x264 [info]: i8c dc,h,v,p: 58% 20% 11% 12%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 59.9% 14.4% 22.0% 3.7% 0.1%
x264 [info]: ref B L0: 87.6% 12.4%
x264 [info]: ref B L1: 89.2% 10.8%
x264 [info]: kb/s:29077.51

encoded 962 frames, 6.76 fps, 29077.51 kb/s

2nd pass :

avs [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:48 Avg QP:19.27 size:257403
x264 [info]: frame P:355 Avg QP:20.85 size:170340
x264 [info]: frame B:559 Avg QP:20.90 size:123996
x264 [info]: consecutive B-frames: 12.2% 12.1% 29.8% 46.0%
x264 [info]: mb I I16..4: 30.5% 53.7% 15.8%
x264 [info]: mb P I16..4: 3.9% 11.0% 2.5% P16..4: 22.0% 25.0% 5.5% 0.7% 1.5% skip:27.7%
x264 [info]: mb B I16..4: 0.2% 1.4% 0.2% B16..8: 31.3% 13.3% 8.4% direct:11.3% skip:33.8% L0:37.7% L1:43.3% BI:19.0%
x264 [info]: 8x8 transform intra:60.4% inter:39.2%
x264 [info]: direct mvs spatial:87.7% temporal:12.3%
x264 [info]: coded y,uvDC,uvAC intra: 78.0% 76.5% 68.2% inter: 51.0% 53.9% 34.8%
x264 [info]: i16 v,h,dc,p: 43% 19% 21% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 15% 11% 10% 14% 9% 12% 8% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 5% 8% 11% 10% 16% 11% 15% 10% 15%
x264 [info]: i8c dc,h,v,p: 30% 20% 9% 41%
x264 [info]: Weighted P-Frames: Y:7.0% UV:6.2%
x264 [info]: ref P L0: 67.9% 10.0% 19.7% 2.3% 0.2%
x264 [info]: ref B L0: 86.4% 13.6%
x264 [info]: ref B L1: 89.2% 10.8%
x264 [info]: kb/s:28340.57

encoded 962 frames, 2.06 fps, 28340.57 kb/s


Now, i let you guys get the files, and make analysis/compare.

[kolak]

Ok, if you want to check, my encodes:
Files can be downloaded here (http://dl.free.fr/bDrp1utB6). Don't know what download speed you'll get, be a little patient, file is 400MB.
The x264 version used is 1772 Jeeb's x64 build.

You have 3 different encodes.
File Island-1.264
Encode parameters :

Bitrate : 28000 Tune : film

Log result files
1rst pass :

2nd pass :


File : Island-2.264
Encode parameters :

Bitrate : 28000 Tune : Film

Log files:
1rst pass :

2nd pass :


File : Island-3.264
Encode parameters : Sames as file Island-2.264.
Bitrate : 28000 Tune : grain

Log files :
1rst pass :

2nd pass :


Now, i let you guys get the files, and make analysis/compare.

Thanks.
Will have a look.

Andrew

[kolak]

Now, i let you guys get the files, and make analysis/compare.

They are not very good- number one is the best, but nothing special compared to other x264 encodes.
2 and 3 are one of the worse I've seen from x264- also big problems on fades, eg frame 612 in ver 3.


Andrew

[kolak]

Choose yourself:
http://rapidshare.com/files/431294027/island.mkv

We should keep in mind that this is an action packed trailer - the complete movie should be easier to encode.

http://www.mediafire.com/?vo96wyk2zau2svl

Is this on the source? There is more of it, not good at all :(

http://www.mediafire.com/imgbnc.php/e1f08707f0ef7d4ba12ea08aad0be2f3379c726ede1a4bd21f550feec7e5ebb06g.jpg

Andrew

[sneaker_ger]

Yes, it's on the source.
http://www.abload.de/img/1215source3iel.png

[ajp_anton]

After 20 pages, has anyone posted a kolak-approved sample encoded by CCE-HD?
No.

Only this (some decompressed section):

http://www.mediafire.com/?7zxeva4elepjqzn


Andrew
So why do people not just stop arguing until you actually prove *anything* that you've said so far?

[kolak]

Yes, it's on the source.
http://www.abload.de/img/1215source3iel.png

Ok.

Fades are still problematic in your encode.


Andrew

[kolak]

So why do people not just stop arguing until you actually prove *anything* that you've said so far?

x264 gained a lot from this disccusion.

What do you want me to prove?

Andrew

[creamyhorror]

So what problems/weaknesses in x264's output do you think are left to deal with (besides segment encoding)? Just fades? Is there still an issue with "overly bad frames"?

It's been an interesting thread and perhaps some area of improvement for x264 will emerge. Or possibly even a fair comparison with a studio-level encoder at Blu-ray bitrates, elusive as it's proven.

[nm]

x264 gained a lot from this disccusion.
The commits so far have got nothing to do with this, AFAIK.

What do you want me to prove?
We still haven't seen an actual encoded stream from any encoder but x264. Except Dark Shikari's samples, which you didn't like.

Does your company own any other "pro" encoder so that you could post some encoded streams?

[sneaker_ger]

Same binary, same settings, except weightp is set to 1 instead of 0. (5.4 fps over both passes)

http://www.abload.de/img/185sourcekfz0.png
http://www.abload.de/img/185encodeweightp1mg8u.png
http://www.abload.de/img/185encodekdtp.png (my old encode for comparison)

I don't know if you want to call that problematic, but on these the difference to the source seems most obvious. (On other frames I had to look several times to make sure I didn't accidentally copy the source frame twice.)

http://rapidshare.com/files/431454531/island_weightp1.mkv

[kolak]

Same binary, same settings, except weightp is set to 1 instead of 0. (5.4 fps over both passes)

http://www.abload.de/img/185sourcekfz0.png
http://www.abload.de/img/185encodeweightp1mg8u.png
http://www.abload.de/img/185encodekdtp.png (my old encode for comparison)

I don't know if you want to call that problematic, but on these the difference to the source seems most obvious. (On other frames I had to look several times to make sure I didn't accidentally copy the source frame twice.)

http://rapidshare.com/files/431454531/island_weightp1.mkv

It's still bad.

I will post my video, so you can check that there are no bad (much worse quality) frames.


Andrew

[kolak]

So what problems/weaknesses in x264's output do you think are left to deal with (besides segment encoding)? Just fades? Is there still an issue with "overly bad frames"?

It's been an interesting thread and perhaps some area of improvement for x264 will emerge. Or possibly even a fair comparison with a studio-level encoder at Blu-ray bitrates, elusive as it's proven.

Bad frames were due to buggy build- this has been sorted.

Fades and high motion scenes are left (sometime x264 flattens details there).
Fades are more important.


Andrew

[mp3dom]

I'm trying latest official non-patched build from x264.nl. Maybe for films it works wonderfully, but with anime I can't get decent results in 'sensible' parts (fades, grain retention etc) and I'm obtaining again what I've wrote months ago.
This is my commandline:

--pass 2 --profile high --preset veryslow --tune film --keyint 24 --b-adapt 2 --bframes 3 --ref 4 --b-pyramid strict --open-gop bluray
--slices 4 --bitrate 35000 --vbv-maxrate 40000 --vbv-bufsize 30000 --no-fast-pskip --no-dct-decimate --weightp 2 --sar 1:1 --level 4.1
--videoformat ntsc --colorprim bt709 --transfer bt709 --colormatrix bt709 --nal-hrd vbr --aud --pic-struct

As everyone can see, bitrate used is *huge* (35 Mbps - reached during final encode so the file is not undersize/oversize) and I'm using weightp 2 to push the maximum from fades (even if it can create problems on some standalones). Sequence is about 4400 frames (3 minutes long) and is a real source of a real anime movie. I cannot share the source to public because it's unreleased material but I'm posting some screenshots and parts of it. The sequence starts with a long fade from noisy dark grey.
Just for reference: encoding speed (on my core i7 920) if someone is interested:
x264 preset veryslow: ~1-1.5 fps (variable)
proencoder: ~4-6 fps (variable - plain 2 pass vbr, no segment encoding)

Note: pro-enc source have a YV12->YUY2->YV12 colorspace conversion applied (the encoder doesn't accepts YV12). There's also a chroma shift that I'm currently investigating.

All the images follows this order: source-proencoder-x264
Every image has the first part as the original image encoded and an 'enhanced' part with luma/contrast boost that shows better what are the results.

Frame 0 (first frame, I frame):
0000 (http://i56.tinypic.com/2a9uwq8.png)
As you can see, the noise changes a lot in a strange pattern, way different than the original

Frame 45:
0045 (http://i53.tinypic.com/34tb97s.png)
This frame is at the beginning of the fadein. It starts to slowy shows some part of image (which is a 'tunnel' effect). The x264 version losts completely the grain and shows some macroblocks. From frame 45 to 60 all frames shows an alternation of grain/no grain while the original all have grain.

Frame 61:
0061 (http://i53.tinypic.com/98zsxi.png)
As you can see here, the grain is messed up and the image have too much distortion. The pro-encoder have chroma shift as said above (I'm watching into it) anyway the grain is retained in a better way.

Frame 1884:
1884 (http://i52.tinypic.com/14ka0p3.png)
Again the grain changes its pattern. You can also see some minor macroblocks. This image comes immediately after a scenechange so, presumably (but not sure) is an I frame. It needs 3-4 frames before retaining the original grain again.

Frame 2286:
2286 (http://i52.tinypic.com/2445zeo.png)
Same as above.

Frame 2291:
2291 (http://img263.imageshack.us/img263/3407/2291comparison.png)
As above, you can see that the grain is less homogeneous.


These are just examples.
To be honest and objective as possible, actually I cannot find a good/valid reason to switch to use x264 in favor of my pro-encoder of choice (the lack of segment encoding is a problem, because in this example of 35Mbps avg I need to use it but simply I cannot encode the whole 2 hrs movie at 1 fps! This will take days!)

If Dark Shikari is really interested for giving suggestions or has requests, he can contact me via PM. If he want to attack/accuse me or thinks I'm trolling, it's better if he simply ignore this post.

[Biggiesized]

mp3dom, thanks for your contribution. This discussion is very important if x264 is to be taken seriously as a professional Blu-ray encoder.

Were you using Blu-code as your professional encoder?

[Blue_MiSfit]

I'd very much like to see the real screenshots, not specific channels etc.

Also, can you post the full streams from both encoders please? If you have legal issues with posting the full streams from your "pro encoder", can you transcode to a lossless, or at least zipped YUV?

[shon3i]

I think he cannot post streams (even x264) due source legal issues.

I cannot share the source to public because it's unreleased material but I'm posting some screenshots and parts of it.

[sneaker_ger]

Also, can you post the full streams from both encoders please? If you have legal issues with posting the full streams from your "pro encoder", can you transcode to a lossless, or at least zipped YUV?

I cannot share the source to public because it's unreleased material

Maybe it would be possible to do a comparison using a publicly available source? (If you find anything that shows the same problems.)

[Puncakes]

Don't want x264 to use its compression magic? Turn it off. --trellis 0 --deadzone-intra 2 --deadzone-inter 2 --no-mbtree --qcomp 0.8 --aq-strength 0.5 --fade-compensate 1.0 --ipratio 1.0 --pbratio 1.0

Shazam, transparent encodes at Blu-ray bitrates, but crap encodes at reasonable bitrates.

[kolak]

I'd very much like to see the real screenshots, not specific channels etc.

Also, can you post the full streams from both encoders please? If you have legal issues with posting the full streams from your "pro encoder", can you transcode to a lossless, or at least zipped YUV?

Just check fades on Island trailer- the same. Big (easily visible) problems on fades. This is main x264 weakness.
Tried different things and nothing helps.


Andrew

[jpsdr]

I'm trying latest official non-patched build from x264.nl.

Maybe you should try last Jeeb's version (1772_v2), with fade compensation and Chroma weightp improvement, to check if at least on fade, there is improvements.

Edit : New commit apparently, so, i would advice to wait Jeeb's 1788 with fade compensation, to try if it improves things.

[shon3i]

Don't want x264 to use its compression magic? Turn it off. --trellis 0 --deadzone-intra 2 --deadzone-inter 2 --no-mbtree --qcomp 0.8 --aq-strength 0.5 --fade-compensate 1.0 --ipratio 1.0 --pbratio 1.0

Shazam, transparent encodes at Blu-ray bitrates, but crap encodes at reasonable bitrates.
I am aslo thinked same, anyway in near past when x264 has no AQ and PSY-RD, transparency be easily achieved with higher bitrate and weaker settings, for example on some video i use

Warning: this is old x264 cmd
--bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -2:-2 --crf 18 --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 1 which give me total transparency, while some other heavy settings like partition all, trellis 2 and other totaly destroy picture.

Aslo from mine test x264 deblocker produce smother image than some pro encoders, -2:-2 is something like MC -1:-1, Atemes adaptive -1 and etc.

[mp3dom]

I'd very much like to see the real screenshots, not specific channels etc.

The screenshots are real but due to the source I cannot share screenshots that can be used to easily detect the source so I've posted some part of the images. The problems anyway cover the entire image. I only have boosted the luma/contrast just to show better the artefacts. No other 'manipulation' was made.


Also, can you post the full streams from both encoders please? If you have legal issues with posting the full streams from your "pro encoder", can you transcode to a lossless, or at least zipped YUV?
No I can't, the problem is not the encoded file, but the source. The source is unreleased and not yet available so I cannot share it.


Maybe it would be possible to do a comparison using a publicly available source? (If you find anything that shows the same problems.)

No problem if I can find something similar. I mainly work with animation, not films so excluding my sources it's quite difficult to find something else. Anyway I'm watching into it.


Just check fades on Island trailer- the same. Big (easily visible) problems on fades. This is main x264 weakness.

Yes, fades are problematic at least on anime (i would say). Anyway only the first 3 screenshots posted by me refers to a 'fadein' problem. All the others screenshots came from scenechange or with moderate/high complexity scenes.


Maybe you should try last Jeeb's version (1772_v2), with fade compensation and Chroma weightp improvement, to check if at least on fade, there is improvements.

I've tried it previously but the results were exactly the same (at least on the first frames, with the long fadein). Due to this problem I thought that it was a build miscompilation and switched to official build but results were again the same, as you can see.

[Blue_MiSfit]

Frankly, if you can't share anything real, this is a completely useless test. There's absolutely no way any of it can be verified.

For all we know you could be an employee of any company that develops "pro encoders" with a vested interest in making x264 look bad.

If this was my forum, I'd remove your posts. Technically they're against Doom9's request that codec comparisons be completely transparent (i.e access to source, encodes, and settings across the board so they can all be replicated).

Derek

[Biggiesized]

I've been given permission to post a 2+ minute source that has lots of gradients and fades. The author would like you guys to test x264 with it in order to improve its fading quality and gradient retention. You can also compare other encoders to it. This footage is meant to be tested using applicable Blu-ray settings.

Should I start another thread to post it so it doesn't get lost in this kerfuffle?

[kieranrk]

Should I start another thread to post it so it doesn't get lost in this kerfuffle?

Yes you should.

[kolak]

Frankly, if you can't share anything real, this is a completely useless test. There's absolutely no way any of it can be verified.

For all we know you could be an employee of any company that develops "pro encoders" with a vested interest in making x264 look bad.

If this was my forum, I'd remove your posts. Technically they're against Doom9's request that codec comparisons be completely transparent (i.e access to source, encodes, and settings across the board so they can all be replicated).

Derek

Try any source yourself (even Island trailer)- no need to go any further. Show that there is no problem- simple.

There were many x264 encodes of this source (done by different people and with different builds) and all of them have the same problem- fades (also a smaller problems on high motion scenes).


Andrew

[Biggiesized]

I'm going to reupload the Leo test footage too. I know realize that it can be greater than 100MB in size. This will remove the hassle of multiple downloads.

[Biggiesized]

Okay, Leo is now one 7-zip archive to download:

http://rapidshare.com/files/432122371/LeoMX_1080p_i420.7z

Should I leave the others up?

[mp3dom]

Frankly, if you can't share anything real, this is a completely useless test. There's absolutely no way any of it can be verified.

I'm not interested that other users will verify my unreleased sources or other users tests my unreleased sources. It's enough that some developer/contributor, if really is interested in suggesting better parameters/improving/fixing x264, contact me (as already happened, editor's note).


For all we know you could be an employee of any company that develops "pro encoders" with a vested interest in making x264 look bad.

Bah... I'm quite astonished by your comment as, if I understand correctly, you're working in a company that made post-production or other similar tasks so you should understand our position when working with unreleased material. Also if you want to extends x264 encoder capabilities to bluray you should put in account that 99% of the times the authoring houses works with unreleased material so it's not easy to ask for sources above all in an internet forum clearly visible on all the world. What do you expects? That we choose an encoder using bluray rips as a source? That we share videos when we've signed NDA?Anyway I'm not obliged to use x264 and if you think I'm not trustworthy you can simply ignore me. In this current developement state, with my footages (animation) probably I'll continue to use other encoders at high bitrates. All others can continue to use x264 and encode HD data at 10 Mbps and says 'Wow!' (just as a note: I thought to do a good thing for the community spending my spare time (that I could invest in something better) making a comparison with my footage... evidently I was wrong). I will continue to watch the x264 progression state and I'll start to use it when it will start to completely satisfy me.


If this was my forum, I'd remove your posts. Technically they're against Doom9's request that codec comparisons be completely transparent (i.e access to source, encodes, and settings across the board so they can all be replicated).

Derek
I'm not here to persuade you (or all other users) that proencoders are better. I haven't even said what proencoder I've used for the 'comparison' because I don't want to focus the post in a "x264 vs. proencoder <name>" fight.
Anyway... no problem, if the moderators thinks that my previous post is against doom9 policy, they're free to remove it. Evidently x264 is already perfect as is.

[kieranrk]

Evidently x264 is already perfect as is.

Nobody ever said that.

[kolak]

Okay, Leo is now one 7-zip archive to download:

http://rapidshare.com/files/432122371/LeoMX_1080p_i420.7z

Should I leave the others up?

Thanks.

I have seen this footage- bit boring, but can test fades and gradients retention.

Andrew

[aegisofrime]

I'm not interested that other users will verify my unreleased sources or other users tests my unreleased sources. It's enough that some developer/contributor, if really is interested in suggesting better parameters/improving/fixing x264, contact me (as already happened, editor's note).

What did the developer tell you? If it's possible I think it would be great if you could share that with the rest of us so that we know what to do if we encounter the same problems you are having, and how to fix it.

[shon3i]

Thanks.

I have seen this footage- bit boring, but can test fades and gradients retention.

Andrew
Yep, but is good example for x264, even on veryslow x264 fail on this source, and produce banding and unacceptable fades

[Sagittaire]

I'm trying latest official non-patched build from x264.nl. Maybe for films it works wonderfully, but with anime I can't get decent results in 'sensible' parts (fades, grain retention etc) and I'm obtaining again what I've wrote months ago.
This is my commandline:

--pass 2 --profile high --preset veryslow --tune film --keyint 24 --b-adapt 2 --bframes 3 --ref 4 --b-pyramid strict --open-gop bluray
--slices 4 --bitrate 35000 --vbv-maxrate 40000 --vbv-bufsize 30000 --no-fast-pskip --no-dct-decimate --weightp 2 --sar 1:1 --level 4.1
--videoformat ntsc --colorprim bt709 --transfer bt709 --colormatrix bt709 --nal-hrd vbr --aud --pic-struct

As everyone can see, bitrate used is *huge* (35 Mbps - reached during final encode so the file is not undersize/oversize) and I'm using weightp 2 to push the maximum from fades (even if it can create problems on some standalones). Sequence is about 4400 frames (3 minutes long) and is a real source of a real anime movie. I cannot share the source to public because it's unreleased material but I'm posting some screenshots and parts of it. The sequence starts with a long fade from noisy dark grey.
Just for reference: encoding speed (on my core i7 920) if someone is interested:
x264 preset veryslow: ~1-1.5 fps (variable)
proencoder: ~4-6 fps (variable - plain 2 pass vbr, no segment encoding)

Note: pro-enc source have a YV12->YUY2->YV12 colorspace conversion applied (the encoder doesn't accepts YV12). There's also a chroma shift that I'm currently investigating.

All the images follows this order: source-proencoder-x264
Every image has the first part as the original image encoded and an 'enhanced' part with luma/contrast boost that shows better what are the results.

Frame 0 (first frame, I frame):
0000 (http://i56.tinypic.com/2a9uwq8.png)
As you can see, the noise changes a lot in a strange pattern, way different than the original

Frame 45:
0045 (http://i53.tinypic.com/34tb97s.png)
This frame is at the beginning of the fadein. It starts to slowy shows some part of image (which is a 'tunnel' effect). The x264 version losts completely the grain and shows some macroblocks. From frame 45 to 60 all frames shows an alternation of grain/no grain while the original all have grain.

Frame 61:
0061 (http://i53.tinypic.com/98zsxi.png)
As you can see here, the grain is messed up and the image have too much distortion. The pro-encoder have chroma shift as said above (I'm watching into it) anyway the grain is retained in a better way.

Frame 1884:
1884 (http://i52.tinypic.com/14ka0p3.png)
Again the grain changes its pattern. You can also see some minor macroblocks. This image comes immediately after a scenechange so, presumably (but not sure) is an I frame. It needs 3-4 frames before retaining the original grain again.

Frame 2286:
2286 (http://i52.tinypic.com/2445zeo.png)
Same as above.

Frame 2291:
2291 (http://img263.imageshack.us/img263/3407/2291comparison.png)
As above, you can see that the grain is less homogeneous.


These are just examples.
To be honest and objective as possible, actually I cannot find a good/valid reason to switch to use x264 in favor of my pro-encoder of choice (the lack of segment encoding is a problem, because in this example of 35Mbps avg I need to use it but simply I cannot encode the whole 2 hrs movie at 1 fps! This will take days!)

If Dark Shikari is really interested for giving suggestions or has requests, he can contact me via PM. If he want to attack/accuse me or thinks I'm trolling, it's better if he simply ignore this post.


well it's non realistic demonstation because why make good encoding for invisible image part?

Moreover most professional encoder use black level normalisation pre-filter for cut all PSY invisible black part. It's possible to make better encoding in low luma level but it's a volontary PSY optimisation for x264.

[Sagittaire]

Possible to have other source for Island trailer because download stop at 1 Go. I will make good professional encoding with x264 and other codec too ...

[shon3i]

well it's non realistic demonstation because why make good encoding for invisible image part?Well it's not invisible if you have well calibrated monitor and good eye. mp3dom make this enhanced versions to point people where to look, not everyone can notice, especialy when we have not full screenshots or part of stream.

[mp3dom]

well it's non realistic demonstation because why make good encoding for invisible image part?
I can assure you that it's indeed visible. The enhancement was made to show the artefacts to everybody (for those who have too dark monitor or uncalibrated). Also, as shon3i as already said, without fullscreen screenshots is hard to see it well.

[Biggiesized]

Professional encoding and reviewing should be done on monitors with higher black levels so these compression artifacts in the dark parts are easier to spot.

[Sharc]

Interesting dispute.
It seems that tremendous focus is put onto finding frames where x264 is inferior to 'pro' encoders. Any frames discovered where x264 is superior?
How about watching the movie as opposed to analyzing individual frames? How does x264 compare?

[sneaker_ger]

Possible to have other source for Island trailer because download stop at 1 Go. I will make good professional encoding with x264 and other codec too ...

ftp://island@94.242.206.22/

[nm]

Interesting dispute.
It seems that tremendous focus is put onto finding frames where x264 is inferior to 'pro' encoders. Any frames discovered where x264 is superior?

Not really because nobody has yet posted a complete CC-HDe encode of the trailer. Kolak made a 42-frame segment available as a raw AVI.

How about watching the movie as opposed to analyzing individual frames? How does x264 compare?

Fades are probably the only place where one might notice a difference on playback.

@kolak & mp3dom: which fade did you find most problematic in The Island -trailer?

[mp3dom]

If you watch it in realtime the fadein produced by x264 is *visible* inferior because the fadein is quite long (about 5 secs). For all the rest there's no visible difference in realtime... both streams are near the same. If you watch closely you can spot the difference (the proencoded stream is a bit less sharp with grain, a bit 'soften' up but some shoots have less micro blocks in complex parts, while x264 retain the original sharpness in grain but some parts have too 'different' grain retained and some minor micro blocks in complex parts). The microblocks are anyway difficult to spot, almost not-visible even in a frame by frame comparison so it's not a real problem to me.

Edit:
nm: I'm not working on the island trailer as it's not my typical 'source'. I'm working on my source (which you can see some screenshots in one of my previous post). Even this comment ^^^ refers to my source

[nm]

nm: I'm not working on the island trailer as it's not my typical 'source'. I'm working on my source (which you can see some screenshots in one of my previous post). Even this comment ^^^ refers to my source

Well, I agree with Blue_MiSfit that this is not useful or even interesting for the rest of us. We want to test and replicate things on a publicly available source.

[Sharc]

Has anyone tried revision 1788 of x264? It should improve fades.

[shon3i]

Has anyone tried revision 1788 of x264? It should improve fades.
Not usefull for authorting BD's, can cost of compatibility issues

[Sharc]

Not usefull for authorting BD's, can cost of compatibility issues
Why? Does the latest revision produce non-compliant streams?
Is 1788 different from previous revisions in this respect?

[simonhorlick]

Why? Does the latest revision produce non-compliant streams?
Is 1788 different from previous revisions in this respect?

commit 9488de4f74637360301e3cb1e6c7f25a41a93a37
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Sun Nov 14 03:34:26 2010 -0800

Chroma weighted prediction
Like luma weighted prediction, dramatically improves compression in fades.
Up to 4-8db chroma PSNR gain in extreme cases (short, perfect fade-outs).
On actual videos, helps up to ~1% overall.
One example video with a decent number of fades (ef OP): 0.8% bitrate reduct
Fixes a lot of artifacts in fades at lower bitrates.

Original patch by Dylan Yudaken <dyudaken@gmail.com>.

[sneaker_ger]

It's not different from earlier versions, it's just that some players are buggy (http://x264dev.multimedia.cx/archives/212) and produce artifacts when playing encodes with weighted p prediction (at least the "smart" one), although it is allowed by the BD standard. That's why many stay away from it when encoding for Blu-Ray.

[shon3i]

Why? Does the latest revision produce non-compliant streams?
Is 1788 different from previous revisions in this respect?
No, --weightp from start are incompatible with some chipsets.

[shon3i]

It's not different from earlier versions, it's just that some players are buggy (http://x264dev.multimedia.cx/archives/212) and produce artifacts when playing encodes with weighted p prediction (at least the "smart" one), although it is allowed by the BD standard. That's why many stay away from it when encoding for Blu-Ray.
Yep, Blu-Code aslo use weightp/b.

[kolak]

Possible to have other source for Island trailer because download stop at 1 Go. I will make good professional encoding with x264 and other codec too ...

Use what you have.
Use VirtualDub to recover avi.


Andrew

[Sharc]

It's not different from earlier versions, it's just that some players are buggy (http://x264dev.multimedia.cx/archives/212) and produce artifacts when playing encodes with weighted p prediction (at least the "smart" one), although it is allowed by the BD standard. That's why many stay away from it when encoding for Blu-Ray.
Ah, the issue with the weighted p. .....:rolleyes:

[jpsdr]

Okay, Leo is now one 7-zip archive to download:
http://rapidshare.com/files/432122371/LeoMX_1080p_i420.7z
Should I leave the others up?

With what can i open this file :confused:
Is it possible to open it with VirtualDub or with an avisynth script ?
If yes, how ?

Thanks.

[kolak]

Yep, Blu-Code aslo use weightp/b.

But I never heard of any problems on any player.


Andrew

[kolak]

With what can i open this file :confused:
Is it possible to open it with VirtualDub or with an avisynth script ?
If yes, how ?

Thanks.

It's an archive. 7zip or WinRar will unpack it.


Andrew

[kolak]

Has anyone tried revision 1788 of x264? It should improve fades.

I will try with Island trailer just to check if it solves problems.


Andrew

[jpsdr]

Lol !!! I know, it's the .yuv file i don't know what to do with !

Maybe wait for Jeeb's release with fade compensation patch (and use --fade-compensate command with a value of 0.7 or 0.8).

[kolak]

Lol !!! I know, it's the .yuv file i don't know what to do with !

Maybe wait for Jeeb's release with fade compensation patch (and use --fade-compensate command with a value of 0.7 or 0.8).

Feed to x264- it should read it. I use avisynth with rawsource plugin.

Download rawsource plugin (http://avisynth.org/warpenterprises/) and use:

rawsource("file.yuv", 1920, 1080, "i420")
assumefps(24000,1001)


Andrew

[jpsdr]

Thanks. I just wanted to see what it was...

[JEEB]

In case it wasn't mentioned here yet -- for those using my builds: There was a miscompilation issue or something with both the first and second patched 1777 builds, so please don't use them (tested on linux just now and had no problems, even with the patches I usually use). Only certain sources would be negatively affected though, which made it hard to actually find :| (the test encode I did was mechas fine looking, too) . Unpatched builds didn't seem to have been affected (I build the 64bit builds that get hosted on x264.nl as well).

I'm just getting home at the moment, and shall build a new build with updated sources + test it with the samples I've gotten in two-three hours.

Edit: Tested, switched to another similar and found the same problem so new builds'll have to wait until tomorrow. I don't want to set up another mingw system tonight.

[Stacey Spears]

Not usefull for authorting BD's, can cost of compatibility issues

The best way to get bugs fixed is to release discs they can't play. Let the consumers put pressure on the player manufacturers. Maybe not so good for a feature film, but for a test disc, it is always my goal to break non-compliant players.

[Stacey Spears]

Professional encoding and reviewing should be done on monitors with higher black levels so these compression artifacts in the dark parts are easier to spot.

It is common practice for the major US compression facilities to turn up the black level in order to see artifacts at, or near, black. This is one of the major reasons they re-encode. The reason for doing it is because they have no guarantee that it will be viewed on a properly calibrated display.

[kolak]

It is common practice for the major US compression facilities to turn up the black level in order to see artifacts at, or near, black. This is one of the major reasons they re-encode. The reason for doing it is because they have no guarantee that it will be viewed on a properly calibrated display.

That's what I do, but also always watch video on properly calibrate monitor.


Andrew

[Biggiesized]

With what can i open this file :confused:
Is it possible to open it with VirtualDub or with an avisynth script ?
If yes, how ?

Thanks.
You don't even have to go the AviSynth route.

Add the following to your x264 command line:

--fps 24000/1001 --input-csp i420 --input-res 1920x1080

As long as you specify the .yuv as your source file, those parameters will formally identify the type of video for x264.

[jpsdr]

I didn't want to encode, i wanted to take a look at the file first to see what it was. Thanks to the raw input pluggin. As source code is avaible, i'll try to see if i can compile it for avisynth x64...

[Didée]

( RawSource Avisynth x64 -- http://forum.doom9.org/showthread.php?p=1411605#post1411605 )

[jpsdr]

Wonderfull !! Many thanks.

[iSeries]

Hi,

Regarding --weightp, does anyone know what current stand-alone blu ray players do not like it?

[Stacey Spears]

OPPO is fine with weightp, which uses Mediatek.

[kolak]

Okay, Leo is now one 7-zip archive to download:

http://rapidshare.com/files/432122371/LeoMX_1080p_i420.7z

Should I leave the others up?

Anyone tried this?
I have total mess on the fade with x264 :(

Andrew

[kieranrk]

http://dl.dropbox.com/u/2701213/x264/LeoMX_1080p_i420.7z.torrent

[shon3i]

Anyone tried this?
I have total mess on the fade with x264

Andrew
Yep, same here without weightp, both fade in and fade out, are horrible.

my settings is:
2 pass, 30000kbps for target bitrate
--preset slow --tune film --level 4.1 --bframes 3 --ref 4 --keyint 24 --vbv-maxrate 40000 --vbv-bufsize 30000 --b-pyramid strict --aud --nal-hrd vbr --sar 1:1 --slices 4 --qpmin 0 --weightp 0

it's easy to replicate.

--weightp 2 it seem to reslove all problems with fades, and it's a lot better than other x264 bulds (pre 1787), but is totaly usless for me, until i not get some official information from some studio that not have problems with it in replication.

[kolak]

Yep, same here without weightp, both fade in and fade out, are horrible.

my settings is:
2 pass, 30000kbps for target bitrate


it's easy to replicate.

--weightp 2 it seem to reslove all problems with fades, and it's a lot better than other x264 bulds (pre 1787), but is totaly usless for me, until i not get some official information from some studio that not have problems with it in replication.

I tried old build (1776- not sure) and it is a big mess- totally unacceptable.
Will try new build.

Andrew

[Groucho2004]

Anyone tried this?
I have total mess on the fade with x264 :(

Andrew

Have you tried to disable mb-tree?
For some sources I use "--no-mbtree" and "--weightp 0" which seems to solve all problems with fades (although encoding is less efficient).

[kolak]

Have you tried to disable mb-tree?
For some sources I use "--no-mbtree" and "--weightp 0" which seems to solve all problems with fades (although encoding is less efficient).

--no mbtree affects quality quite lot. I would rather not to use it.
There is new build- need to try this.


Andrew

[AlexW]

--no mbtree affects quality quite lot. I would rather not to use it.

You could also try playing with qcomp a bit, values closer to 1.0 will increase the amount of bits that are spent in complex scenes, this is true for mbtree and no-mbtree.

[kolak]

Something to compare to:

http://www.mediafire.com/?ydz7rd3xbtylp6i

Leo- 250 first frames from pro encoder (28Mbit/40Mbit)

Andrew

[Doom9]

Something to compare to:What encoder, what version, what settings? You know the drill..

[kolak]

What encoder, what version, what settings? You know the drill..

One of the pro encoders- bitrates is there- settings accordingly to the source (to make it good)- simple 2 pass encode, just to show that fade is good quality (and not only fade). It's a bit softer than x264, but overall good quality. Can't match fades even with weightp 2 with latest x264 build.
If people don't believe it's not my problem- you can delete my post.


Andrew

[mp3dom]

Needs a bit of tweak anyway, frames 83-84-85 (and some others) are a bit bad and shows macroblocks. Am I wrong? Anyway overall seems good to me too.

[kolak]

Needs a bit of tweak anyway, frames 83-84-85 (and some others) are a bit bad and shows macroblocks. Am I wrong? Anyway overall seems good to me too.

It may be PowerDVD decoder through directshowsource- sometimes shows blocking. Never when played in the actual player.
Early frames of fade will be difficult to fix- this is simple 2 pass encode.

Could not match with x264- close, but not better.

Andrew

[fields_g]

One of the pro encoders- bitrates is there- settings accordingly to the source (to make it good)- simple 2 pass encode, just to show that fade is good quality (and not only fade).
Andrew

Am I misunderstanding, or was my laughter justified?
"One" of the pro encoders ?!?!?
"Bitrates is there" == figure it out for your self???
"settings accordingly to source" - You could not provide any better info?

I've seen some of the comments in the past and thought some people were a bit hard on you.... but...Come on... Are you really trying to work with the community? Even if you think it doesn't matter... humor us. You cannot get a group consensus without at least an attempt to be transparent.

I still hope I am misunderstanding you though.

[kolak]

Am I misunderstanding, or was my laughter justified?
"One" of the pro encoders ?!?!?
"Bitrates is there" == figure it out for your self???
"settings accordingly to source" - You could not provide any better info?

I've seen some of the comments in the past and thought some people were a bit hard on you.... but...Come on... Are you really trying to work with the community? Even if you think it doesn't matter... humor us. You cannot get a group consensus without at least an attempt to be transparent.

I still hope I am misunderstanding you though.

Bitrate is in the post :)
One of the pro encoders- does not matter which one- you use one, which works the best with specific source. I don't use just one.
Settings-again- the one, which produce the best result. Tried 2 different and posted video from one of them. Each encoder has different settings- x264 very specific, so what does it help? It was tuned for gradient retention and small changes in the picture- because of the nature of the sample.

What settings do you use with x264? The one which work the best for specific source, fades problem, etc- that's why we have tune option. They are also limited.
Whole point is to show that video stays BD compliant and it can be done as good as x264 or better. If you don't trust me than nothing will help- settings, encoder, etc.
It's real file- I don't tweak it in Photoshop :)


Andrew

[Biggiesized]

It's fairly obvious which encoder he is using. He's only been talking about it for the past few days.

I can post a Blu-code result when I get back to my apartment on Sunday.

[sneaker_ger]

If you don't trust me than nothing will help- settings, encoder, etc.

If you'd post an h.264 stream and a screenshot of your settings people here might start trusting you. If you keep on posting only small lossless parts of a sample no one will stand for your claims.

[kolak]

If you'd post an h.264 stream and a screenshot of your settings people here might start trusting you. If you keep on posting only small lossless parts of a sample no one will stand for your claims.

I don't care- video talks for itself - nothing more is needed. Stream is BD compliant at 28/40Mbit and that's all. Whatever setting were used, whatever encoder it does not matter- x264 needs improvements for fades and they are comnig.


Andrew

[Biggiesized]

Here is the Leo footage encoded with Blu-code with 28 Mb/s average and 40 Mb/s maximum bit rates:

http://rapidshare.com/files/434369566/Leo.m2ts

[2themax]

Leo footage encoded with CC-HDe at 18Mb/s average and 30Mb/s maximum.
http://www.fileserve.com/file/PC5jxzC

[Biggiesized]

Leo footage encoded with Blu-code at 18 Mb/s average and 30 Mb/s maximum bit rates:

http://rapidshare.com/files/434609046/Leo2.m2ts

Looks almost as transparent as the other encode. I noticed only a few deblocking artifacts here and there.

[Biggiesized]

Did anyone do an encode of Leo with x264?

[sneaker_ger]

Here:

x264 1804 64bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset slow --tune grain
--bframes 3 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --bitrate 18000
--pass 1 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid str
ict -o leo_18_slow.mkv LeoMX_1080p_i420.yuv --demuxer raw --input-csp i420 --inp
ut-res 1920x1080
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:40 Avg QP:10.09 size:135118
x264 [info]: frame P:293 Avg QP:12.44 size:103631
x264 [info]: frame B:542 Avg QP:12.76 size: 85487
x264 [info]: consecutive B-frames: 4.0% 7.2% 64.0% 24.9%
x264 [info]: mb I I16..4: 84.9% 0.0% 15.1%
x264 [info]: mb P I16..4: 60.0% 0.0% 0.0% P16..4: 17.1% 0.0% 0.0% 0.0% 0
.0% skip:23.0%
x264 [info]: mb B I16..4: 34.3% 0.0% 0.0% B16..8: 20.7% 0.0% 0.0% direct:
14.9% skip:30.2% L0:30.0% L1:31.6% BI:38.3%
x264 [info]: final ratefactor: 12.46
x264 [info]: direct mvs spatial:97.0% temporal:3.0%
x264 [info]: coded y,uvDC,uvAC intra: 74.0% 60.9% 51.8% inter: 38.9% 13.1% 5.6%
x264 [info]: i16 v,h,dc,p: 36% 14% 42% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 41% 4% 6% 5% 5% 5% 6%
x264 [info]: i8c dc,h,v,p: 76% 10% 12% 2%
x264 [info]: Weighted P-Frames: Y:8.2% UV:6.8%
x264 [info]: kb/s:17997.68

encoded 875 frames, 19.36 fps, 17997.84 kb/s

x264 --fps 24000/1001 --level 4.1 --preset slow --tune grain
--bframes 3 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --bitrate 18000
--pass 2 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid str
ict -o leo_18_slow.mkv LeoMX_1080p_i420.yuv --demuxer raw --input-csp i420 --inp
ut-res 1920x1080
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:40 Avg QP:10.22 size:229928
x264 [info]: frame P:293 Avg QP:12.88 size:141999
x264 [info]: frame B:542 Avg QP:13.22 size: 61179
x264 [info]: consecutive B-frames: 4.0% 7.2% 64.0% 24.9%
x264 [info]: mb I I16..4: 37.1% 61.1% 1.8%
x264 [info]: mb P I16..4: 3.8% 30.6% 0.7% P16..4: 14.5% 13.1% 9.1% 0.0% 0
.0% skip:28.1%
x264 [info]: mb B I16..4: 0.6% 9.7% 0.3% B16..8: 15.0% 9.9% 3.2% direct:
2.4% skip:58.9% L0:35.3% L1:45.0% BI:19.7%
x264 [info]: 8x8 transform intra:83.2% inter:45.4%
x264 [info]: direct mvs spatial:78.4% temporal:21.6%
x264 [info]: coded y,uvDC,uvAC intra: 89.3% 90.5% 89.5% inter: 21.3% 29.2% 21.8%

x264 [info]: i16 v,h,dc,p: 41% 5% 28% 25%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 8% 32% 7% 7% 8% 8% 8% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 9% 20% 10% 10% 10% 10% 10% 14%
x264 [info]: i8c dc,h,v,p: 71% 11% 8% 10%
x264 [info]: Weighted P-Frames: Y:8.9% UV:6.8%
x264 [info]: ref P L0: 62.4% 36.4% 1.2%
x264 [info]: ref B L0: 83.6% 16.4%
x264 [info]: ref B L1: 85.7% 14.3%
x264 [info]: kb/s:18405.26

encoded 875 frames, 10.43 fps, 18405.43 kb/s

overall fps: 6.78 (core i7-860 @ stock)

http://rapidshare.com/files/435036467/leo_18_slow.mkv (no wait, full speed)


======

x264 1804 64bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset veryslow --tune g
rain --bframes 3 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --bitrate 18
000 --pass 1 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid
strict -o leo_18_veryslow.mkv LeoMX_1080p_i420.yuv --demuxer raw --input-csp i4
20 --input-res 1920x1080
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:40 Avg QP:10.08 size:135814
x264 [info]: frame P:293 Avg QP:12.43 size:103776
x264 [info]: frame B:542 Avg QP:12.76 size: 85292
x264 [info]: consecutive B-frames: 4.0% 7.2% 64.0% 24.9%
x264 [info]: mb I I16..4: 84.9% 0.0% 15.1%
x264 [info]: mb P I16..4: 60.1% 0.0% 0.0% P16..4: 17.1% 0.0% 0.0% 0.0% 0
.0% skip:22.8%
x264 [info]: mb B I16..4: 34.4% 0.0% 0.0% B16..8: 20.7% 0.0% 0.0% direct:
14.8% skip:30.1% L0:30.3% L1:31.3% BI:38.4%
x264 [info]: final ratefactor: 12.47
x264 [info]: direct mvs spatial:97.4% temporal:2.6%
x264 [info]: coded y,uvDC,uvAC intra: 74.3% 61.0% 52.0% inter: 39.1% 13.3% 5.7%
x264 [info]: i16 v,h,dc,p: 36% 14% 42% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 41% 4% 6% 5% 5% 5% 6%
x264 [info]: i8c dc,h,v,p: 76% 10% 12% 2%
x264 [info]: Weighted P-Frames: Y:8.2% UV:6.8%
x264 [info]: kb/s:17989.90

encoded 875 frames, 21.80 fps, 17990.06 kb/s

x264 --fps 24000/1001 --level 4.1 --preset veryslow --tune g
rain --bframes 3 --slices 4 --vbv-maxrate 30000 --vbv-bufsize 30000 --bitrate 18
000 --pass 2 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid
strict -o leo_18_veryslow.mkv LeoMX_1080p_i420.yuv --demuxer raw --input-csp i4
20 --input-res 1920x1080
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:40 Avg QP:12.22 size:187576
x264 [info]: frame P:293 Avg QP:13.56 size:123091
x264 [info]: frame B:542 Avg QP:13.31 size: 72472
x264 [info]: consecutive B-frames: 4.0% 7.2% 64.0% 24.9%
x264 [info]: mb I I16..4: 42.7% 51.1% 6.2%
x264 [info]: mb P I16..4: 10.3% 19.1% 2.8% P16..4: 16.5% 16.9% 5.3% 0.2% 0
.7% skip:28.2%
x264 [info]: mb B I16..4: 3.9% 4.1% 1.0% B16..8: 18.8% 18.3% 7.5% direct:
3.4% skip:43.0% L0:39.9% L1:45.0% BI:15.0%
x264 [info]: 8x8 transform intra:53.6% inter:16.4%
x264 [info]: direct mvs spatial:78.4% temporal:21.6%
x264 [info]: coded y,uvDC,uvAC intra: 91.4% 88.8% 87.8% inter: 21.1% 29.5% 23.0%

x264 [info]: i16 v,h,dc,p: 17% 3% 52% 28%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 10% 40% 6% 5% 6% 6% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 8% 14% 11% 11% 11% 11% 11% 15%
x264 [info]: i8c dc,h,v,p: 69% 12% 7% 11%
x264 [info]: Weighted P-Frames: Y:8.9% UV:6.8%
x264 [info]: ref P L0: 64.0% 34.8% 1.2%
x264 [info]: ref B L0: 82.6% 17.4%
x264 [info]: ref B L1: 83.1% 16.9%
x264 [info]: kb/s:18161.13

encoded 875 frames, 2.18 fps, 18161.30 kb/s

overall fps: 1.98 (core i7-860 @ stock)

http://rapidshare.com/files/435038097/leo_18_veryslow.mkv (no wait, full speed)

[Sagittaire]

Well after analysing it appear that island trailer is not uncompressed source (there are clearly dct flat block in fade for example). I don't know if x264 produce good fade but if ou have fat block in source then you have fat block in encode too (crappy source done crappy encoding ... lol). It's not really serious for compressionist to not detect that ... ??!

[kolak]

Well after analysing it appear that island trailer is not uncompressed source (there are clearly dct flat block in fade for example). I don't know if x264 produce good fade but if ou have fat block in source then you have fat block in encode too (crappy source done crappy encoding ... lol). It's not really serious for compressionist to not detect that ... ??!

Blocking in opening fade was mentioned already. Whole source is a bit strange, but in the same time it's a source.

Andrew

[kieranrk]

http://x264dev.multimedia.cx/archives/643

[Lyris]

Fantastic news.
I'm delighted to see, of all people, Warner Home Video use something other than VC-1.
I wonder if we'll see a situation where the background menu videos look better than the main feature if they keep that up :p

I have nothing against VC-1 as such, I fondly remember the first days of HD DVD vs BD where HD DVD was kicking ass thanks to not using MPEG-2, but I can't imagine new work is being done on VC-1 encoders lately?

[Lyris]

Update: multiple review sites are saying that "Cats & Dogs: The Revenge of Kitty Galore" from Warner is an AVC encode. For Warner to use AVC is very unusual. Coincidence? The only other case of them using AVC I know of is a French-exclusive title that must have been authored locally.

http://www.dvdtalk.com/reviews/45856/cats-dogs-revenge-of-kitty-galore/

Don't suppose anyone actually wants to buy the movie to tell us if it was encoded with x264 ;)

[kolak]

Update: multiple review sites are saying that "Cats & Dogs: The Revenge of Kitty Galore" from Warner is an AVC encode. For Warner to use AVC is very unusual. Coincidence? The only other case of them using AVC I know of is a French-exclusive title that must have been authored locally.

http://www.dvdtalk.com/reviews/45856/cats-dogs-revenge-of-kitty-galore/

Don't suppose anyone actually wants to buy the movie to tell us if it was encoded with x264 ;)

Blu-ray.com review ( http://www.blu-ray.com/movies/Cats-and-Dogs-The-Revenge-of-Kitty-Galore-Blu-ray/15960/#Review )

The Revenge of Kitty Galore scampers onto Blu-ray with a strong (but imperfect) 1080p/AVC-encoded video transfer. (That's right, AVC MPEG-4. Between Cats & Dogs and Flipped, it appears Warner may finally be putting the VC-1 codec out to pasture.) Balk at the film's faux-gritty, 007 palette all you want; colors are rich, primaries are ripe, lasers and explosions light up the screen, and black levels are nice and deep (in all but a handful of problematic, effects-heavy nighttime shots). Yes, a few faces are flushed, and a few more skew a bit orange, but fleshtones (or fur-tones as it were) are generally warm and lifelike. Likewise, soft shots pop up from time to time, but none are indicative of a prevailing technical issue. Fine textures are precisely resolved, definition is crisp and clean (without the help of any egregious edge enhancement), and animal hair, practical or CG, bristles believably. Oddities abound though. While the film's grainfield is fairly consistent and largely unobtrusive, it also tends to spike rather violently; so much so that the grain sometimes becomes a ragged, blocky mess. Minor artifacting, banding and crush pop up as well, as does some negligible aliasing. Still, each eyesore is brief, fleeting and easy to overlook. Cats & Dogs may not be a great family film, but Warner's video transfer is impressive enough to prevent parents from regretting every dollar of their purchase.

Looking at screen grabs thay don't look very good, but can be source or jpeg.

Andrew

[Sagittaire]

Well VC1 work really well at BluRay bitrate ... and certainely really good MPEG2 encoder too ...

Anyway here analysing from Island Trailer:

Pictures:
2419 100.0% Q = 0 19 25 27990 kbits/s 46.81 dB
I 228 9.4% Q = 9 19 24 29128 kbits/s 48.27 dB
P 1192 49.3% Q = 0 19 25 31184 kbits/s 46.59 dB
B 999 41.3% Q = 9 19 24 23920 kbits/s 46.74 dB


Macroblocks:
ALL I P B I/P I/B P/P B/B

Q 18.4 18.8 18.5 18.3 20.3 19.9 16.4 17.8
Bits/mb 142.9 148.8 159.2 122.0 238.1 257.8 69.9 79.5

Intra 45.4% 100.0% 53.1% 23.8% 100.0% 100.0%
Inter 26.3% 19.4% 40.6% 41.4% 53.3%
Direct 3.2% 7.7% 10.1%
Skip 25.0% 27.5% 27.9% 58.6% 36.6%

16x16 14.2% 24.9% 10.1% 15.0% 10.1% 15.0%
8x8 66.2% 63.5% 66.8% 67.5% 66.8% 67.5%
4x4 19.5% 11.7% 23.1% 17.5% 23.1% 17.5%

16x16 63.5% 47.2% 72.8% 47.2% 72.8%
16x8 15.9% 22.4% 12.1% 22.4% 12.1%
8x16 11.9% 19.0% 7.8% 19.0% 7.8%
8x8 8.7% 11.4% 7.2% 11.4% 7.2%


DCT-4x4 55.3% 36.5% 52.3% 63.3% 33.2% 32.5% 73.8% 72.9%
DCT-8x8 44.7% 63.5% 47.7% 36.7% 66.8% 67.5% 26.2% 27.1%


Summary:
2419/2419 frames encoded, for a total of 344817.4 kbytes
27997.6 kbits/s (missing target by 0.009% or 29.9 kbytes)
Average PSNR: 46.8089 (Y 45.8560, U 50.1849, V 50.9594)
Overall PSNR: 45.7605 (Y 44.6433, U 49.3878, V 49.8189)
Average SSIM: 87.7638 (Y 86.4450, U 92.9471, V 93.7852)
Elapsed time: 3119.5 seconds (0.78 fps)
Encoding speed: 0.81 fps (0.78 fps)

... and it's not really a hard source for AVC encoder ... after good filtering ... !!!

[Sagittaire]

I will make encoding with various AVC encoder and VC1 and MPEG2 ...

[Lyris]

Well VC1 work really well at BluRay bitrate ...

Sometimes not so much at Warner Home Video bitrates, though :p

I've not had a look at a lot of Warner BDs lately, but I seem to remember they pre-filter everything to reduce the high frequency content.

[Sagittaire]

Sometimes not so much at Warner Home Video bitrates, though :p

I've not had a look at a lot of Warner BDs lately, but I seem to remember they pre-filter everything to reduce the high frequency content.

well VC1 look really good at BR bitrate (similar to MPEG4 ASP efficiency). After if Warner Home Video encoding are not really good it's perhaps not VC1 codec responsability ...

[kolak]

... and it's not really a hard source for AVC encoder ... after good filtering ... !!!

It does not need any filtering- What woudl you like to filter there- grain?


Andrew

[Sagittaire]

It does not need any filtering- What woudl you like to filter there- grain?


Andrew

Well all source need filtering (even CGI source with banding). For Island I cut really high frequency (really fine grain) and grain in low luma part (because grain here is useless and encoder will use lower quant in these part with complexity mask). I make correct correct mod8 image part and black borders. You must always make that for grainy source. It's the base for good encoding. You will see the result ... with H264 en others codec too.

[kolak]

Well all source need filtering (even CGI source with banding). For Island I cut really high frequency (really fine grain) and grain in low luma part (because grain here is useless and encoder will use lower quant in these part with complexity mask). I make correct correct mod8 image part and black borders. You must always make that for grainy source. It's the base for good encoding. You will see the result ... with H264 en others codec too.

As long as you can't see side effects it's fine, but in many cases not needed at all.


Andrew

[kieranrk]

I've not had a look at a lot of Warner BDs lately, but I seem to remember they pre-filter everything to reduce the high frequency content.

The encoder they used was very poor. From the analysis I saw of it apparently all it did was exhaustive SAD, sometimes producing hilariously inefficient motion vectors.

[kolak]

Another AVC encode from Warner

http://www.blu-ray.com/movies/Flipped-Blu-ray/16525/#Review


Andrew

[Sagittaire]

Well ... someone have good ftp for island trailer encoding. I have result here for Ateme, Mainconcept, x264, VC1 and MPEG2 ...

[Biggiesized]

What did you use for VC-1 encoding? PSE won't accept Lagarith as a source format (unless you transcoded).

[kolak]

What did you use for VC-1 encoding? PSE won't accept Lagarith as a source format (unless you transcoded).

I'm not sure why are you obsessed so much about transcoding?
If I convert Lagarith to eg. YUY2 what does it change?


Andrew

[mp3dom]

PSE natively accepts IYUV which is the same as i420.
Sagittaire, all of the tested encoders should outputs BD-compliant stream to be valid.

[Biggiesized]

He was talking about the Island trailer. That was losslessly compressed with Lagarith.

[kolak]

He was talking about the Island trailer. That was losslessly compressed with Lagarith.

So what? What is the problem- if needed can be converted to other lossless or uncompressed format.


Andrew

[Sagittaire]

PSE natively accepts IYUV which is the same as i420.
Sagittaire, all of the tested encoders should outputs BD-compliant stream to be valid.

Well I use BluRay compatible profil for all codec (without wpred for all H264 codec). I use VC1 SDK encoder from MS for produce VC1 stream and old TPMEG encoder for MPEG2 stream. I will post ES mux in TS container.

I have transparent result for Ateme and x264 (crf 19 for x264 is not really a problem for quality with this source ... !!!). Really good result for Mainconcept and VC1. Really good surprise with MPEG2 with really acceptable quality (good grain retention without blocking even for high motion part). No problem for fade for all codec.

[digitalvideo]

Hi Sagittaire,

is Ateme now BD-compliant ?

[Sagittaire]

Hi Sagittaire,

is Ateme now BD-compliant ?

Well my old build have command line for that ...

[digitalvideo]

Can i know witch build?

[Lyris]

Sagittaire, how are you verifying BD compliance? Have you done in-depth checks, or are you just confirming it plays on a set-top player?

[kolak]

Well I use BluRay compatible profil for all codec (without wpred for all H264 codec). I use VC1 SDK encoder from MS for produce VC1 stream and old TPMEG encoder for MPEG2 stream. I will post ES mux in TS container.

I have transparent result for Ateme and x264 (crf 19 for x264 is not really a problem for quality with this source ... !!!). Really good result for Mainconcept and VC1. Really good surprise with MPEG2 with really acceptable quality (good grain retention without blocking even for high motion part). No problem for fade for all codec.

Have to see to these "good fades" without wpred.


Andrew

[Sagittaire]

Can i know witch build?

It's beta test build with complete BluRay profil (HDR, slice, flag ... etc)


Sagittaire, how are you verifying BD compliance? Have you done in-depth checks, or are you just confirming it plays on a set-top player?

well I don't make that here because probleme for this thread is fade quality. Anyway if you use good command line you have always BR compliance at least with x264 (major probleme is always VBV compliance and x264 make autocheck HDR compliance)


Have to see to these "good fades" without wpred.

Well low quant imply high quality. Anyway it's difficult to see that with Island trailer because fade quality are natively bad for the source. Anyway x264 reproduce exactly source quality.

[kolak]

Well low quant imply high quality. Anyway it's difficult to see that with Island trailer because fade quality are natively bad for the source. Anyway x264 reproduce exactly source quality.

Whatever they look like on the source does not really matter- we want them to be the same on the encoded file.
You can try Leo sample file for testing fades (or Lighthouses footage).
I tried to convince Ateme to make BD compliant encoder, but they were not interested. This was long time ago. Their engine is quite good.

Andrew

[Sagittaire]

Go for Lighthouses footage but the result will be the same. It's easy for me to have good result for all codec.

Ftp for post the result?

[Sagittaire]

Particulary useless if the encoding make average q10 for x264 like the Lighthouses footage ... !!!

[kolak]

Particulary useless if the encoding make average q10 for x264 like the Lighthouses footage ... !!!

Upload x264 sample to one of the free hosting sites.
Lighthouses footage is to check fades (also Leo).
Island trailer is typical film source (just has fast scene changes).

I don't care about stats- eye is the best measurement :)

Andrew

[Sagittaire]

Island trailer is typical film source (just has fast scene changes).
Andrew

Not particulary a problem with good filtering ... even for MPEG2 codec ... !?

[kolak]

Not particulary a problem with good filtering ... even for MPEG2 codec ... !?

I'm not saying that it's difficult, just typical.
It's rather quite easy even without any filtering.

Andrew