Software To Encode Blu Ray Files

[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