Software To Encode Blu Ray Files

[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