Software To Encode Blu Ray Files

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