Lighthouses of the Pacific Northwest - Blu-ray Test Footage

[jpsdr]

Last Jeeb's version is out, i'll try some encode when back home in few hours...
It's indeed with a lot of fade, but, if i've understood properly, weightp helps only on fading black, not scene change fading, so, it should not be of great help on this case.
Otherwise, it's good to have a test footage to compare pro encoder and x264, now, waiting for result with pro encoder...

[sneaker_ger]

I used 32 bit 1788 from x264.nl, which was build using gcc 4.5.1 - do I have to redo my encodes? It says on fushizen that there could be problems.

[simonhorlick]

Last Jeeb's version is out, i'll try some encode when back home in few hours...
It's indeed with a lot of fade, but, if i've understood properly, weightp helps only on fading black, not scene change fading, so, it should not be of great help on this case.
Otherwise, it's good to have a test footage to compare pro encoder and x264, now, waiting for result with pro encoder...

Weightp interpolates between two macroblocks (afaik), so it should handle fades as in this clip just as well as fades to black. If you encode using weightp make sure you use the latest version with chroma weightp, that removed some artifacts in fades.

[Dark Shikari]

Weightp interpolates between two macroblocks (afaik)No, that's weightb. Weightp interpolates from one past region.

[kolak]

Average is useless:
example:
first pass: 19 fps
second pass: 1 fps
average: 10 fps
overall: 1.05 fps (or 2.1 for each pass)

first pass: 10 fps
second pass: 10 fps
average: 10 fps
overall: 5 fps (or 10 for each pass)

The average of both encodes is the same, but the second encode is almost 5 times faster. The greater the speed difference between the passes, the more useless the average is.

Yes- you work in fps, so overall is more important- sorry.
I work in time- no the same :)

Andrew

[kolak]

No, that's weightb. Weightp interpolates from one past region.

We want build which is BD compliant, with no problems.


Andrew

[sneaker_ger]

Yes- you work in fps, so overall is more important- sorry.
I work in time- no the same :)

Andrew

What? :confused:
Time to encode is proportional to overall fps.

[Gser]

I'll upload it to some other hosts once I can get to it. In a few weeks maybe.

[JEEB]

I used 32 bit 1788 from x264.nl, which was build using gcc 4.5.1 - do I have to redo my encodes? It says on fushizen that there could be problems.
All builds with chroma weightp are affected as long as x86 asm code is used with GCC 4.5.x. Whether or not your encodes were actually affected depends... after all, even I made a test encode or two and neither showed any visual signs of miscompilation. And so have a few other people using similar bugged builds :/ .

<insert a line here how D_S describes GCC 3.4.5 being the only GCC version you should ever use>

[kolak]

What? :confused:
Time to encode is proportional to overall fps.

Yes- not to average.


Andrew

[jpsdr]

<insert a line here how D_S describes GCC 3.4.5 being the only GCC version you should ever use>

I think he said once that it's just because it's the version integrated with... i don't remember what, and he was just simply to lazy to update/install new version...:p

[Stacey Spears]

If you want a Mediatek player to test with, the OPPOs are a good choice. I tested Weightp a while back and the OPPO had no trouble with it.

[Biggiesized]

Wow, this is really fantastic quality :)

I'm lighting a fire under my Q6600 tonight with some testing! Interestingly, a CRF 18 encode (using BluRay restrictions and 30mbps VBV) is so far averaging only 8.4mbps :devil:

I'll throw this at Rhozet tomorrow and see how its MPEG-2 encoder (Mainconcept) does with this, and maybe some HC, just for fun. Hopefully we can see some tests form CC-HDe or another "pro" encoder as well!

Derek

I thought that Carbon Coder used the Canopus MPEG-2 codec.

[shon3i]

If you want a Mediatek player to test with, the OPPOs are a good choice. I tested Weightp a while back and the OPPO had no trouble with it.
I am glad to hear that, but I'll still wait to test myself or get information from some studio.

[Biggiesized]

Here is an encode I did with Sonic CineVision 3.5:

http://rapidshare.com/files/432480550/lighthouse.264

Settings:


2-pass VBR (no turbo first pass)
20 Mbps average
30 Mbps peak
Pyramid B-frames
Exhaustive search modes
100% film grain optimization (forces inter over intra encoding preference); default is 75
All other settings to default


I'm running another encode with 28 Mbps average and 40 Mbps peak, in line with sneaker_ger's parameters. When it's finished I will post it shortly.

[Blue_MiSfit]

@Biggiesized: I think you may be right about Rhozet and Canopus, actually :)

Also... we HAVE to find a better file host. Rapidshare sucks for anyone without a premium account. Mediafire seems to be very slow for some people to upload to.

Mind trying some of the following:
1) Megaupload
2) Enterupload
3) Sendspace
4) ???

[Biggiesized]

Megaupload times out for me.

I used to use Sendspace quite frequently, but they have a small file size cap.

My university's network policies are what's handicapping me. I'm not sure why Rapidshare uploads so fast (~800 KB/s) but others are slow. Probably has to do with the ports used. BitTorrent flies for me. I can get 8 MB/s down and anywhere from 2-4 MB/s up.

[nm]

Mind trying some of the following:
1) Megaupload
2) Enterupload
3) Sendspace
4) ???

SkyDrive?

[Stacey Spears]

Did SkyDrive raise the file size limit? (50MB per file)

[kieranrk]

My university's network policies are what's handicapping me. I'm not sure why Rapidshare uploads so fast (~800 KB/s) but others are slow. Probably has to do with the ports used. BitTorrent flies for me. I can get 8 MB/s down and anywhere from 2-4 MB/s up.

Probably because your university's transit provider is Cogent. Cogent->Cogent speeds are fast. Cogent->everywhere else speeds are slow.

[Stacey Spears]

100% film grain optimization (forces inter over intra encoding preference); default is 75

I always wondered what that actually did. They have a few settings that have sliders but don't provide any real useful information.

[Biggiesized]

I always wondered what that actually did. They have a few settings that have sliders but don't provide any real useful information.
I believed it's explained in the help file manual. Most of the settings are best left to default. If you play with the Detail AQ slider too much, you can totally wreck your picture.

[kolak]

I believed it's explained in the help file manual. Most of the settings are best left to default. If you play with the Detail AQ slider too much, you can totally wreck your picture.

Yep- sometimes very badly. Sonic has no solution for this.
Try content with mixed nature- can go very bad :)

Andrew

[kolak]

I thought that Carbon Coder used the Canopus MPEG-2 codec.

Carbon Coder does not use Mainconcept for MPEG2.
It uses Canopus engine.

Andrew

[Gser]

Also... we HAVE to find a better file host. Rapidshare sucks for anyone without a premium account. Mediafire seems to be very slow for some people to upload to.

Mind trying some of the following:
1) Megaupload
2) Enterupload
3) Sendspace
4) ???

Working on it atm. Downloading as fast as rapidshare will let me. 23 minutes until I can download the last piece. I also intend upon converting it from raw to lagarith to shave some space.

[Stacey Spears]

I also intend upon converting it from raw to lagarith to shave some space.

Be sure to keep it 4:2:0.

[Gser]

Be sure to keep it 4:2:0.

Of course. *rolls eyes*

[Biggiesized]

New Sonic CineVision 3.5 encode using the same settings except for:


28 Mbps average
40 Mbps peak


Not too much difference. Still a problem with fades from black.

I didn't do any segment re-encoding so that can be expected.

http://rapidshare.com/files/432501765/lighthouse2.264

[kolak]

New Sonic CineVision 3.5 encode using the same settings except for:


28 Mbps average
40 Mbps peak


Not too much difference. Still a problem with fades from black.

I didn't do any segment re-encoding so that can be expected.

http://rapidshare.com/files/432501765/lighthouse2.264

Try Blu-code- will do good job with this source. CV is xxxx :)

Andrew

[Biggiesized]

Try Blu-code- will do good job with this source. CV is xxxx :)

Andrew

Blu-code only supports YUY2 and v210 input. I've asked Stacey to try it out since he has the original files.

[Biggiesized]

If this were a tweaking contest, it would be much more interesting.

[shon3i]

No problem you can use Avisynth virtual file system http://forum.doom9.org/showthread.php?t=133313 which turn any avs script to uncompressed virtual avi, it will not use hdd space.

[Gser]

Well I couldn't open the file, so your not getting lagarith.

http://uploadmirrors.com/download/0PIVNFF3/Video.part01.rar
http://uploadmirrors.com/download/XJ7HYPC9/Video.part02.rar
http://uploadmirrors.com/download/0YA8JOQL/Video.part03.rar
http://uploadmirrors.com/download/0479KFRK/Video.part04.rar
http://uploadmirrors.com/download/1BJT3TUR/Video.part05.rar
http://uploadmirrors.com/download/QISOW6KD/Video.part06.rar
http://uploadmirrors.com/download/WXI9TSDZ/Video.part07.rar
http://uploadmirrors.com/download/C36FPAZZ/Video.part08.rar
http://uploadmirrors.com/download/0LEQK4WR/Video.part09.rar
http://uploadmirrors.com/download/BYFOFZYL/Video.part10.rar
That enough links for y'all ;) Hmmmm who says I don't deliver!

[kolak]

Blu-code only supports YUY2 and v210 input. I've asked Stacey to try it out since he has the original files.

Not true- it supports many formats- it does plug in into directshow decoders. It may need YUY2 at the output, but most codec do this by default.
It won't read yuv :) Use rawsource plugin, convert to YUY2 and use virtual file method :)
Fades, smooth gradients are Blu-code's strongest point.

Andrew

[Stacey Spears]

Not true- it supports many formats- it does plug in into directshow decoders. It may need YUY2 at the output, but most codec do this by default.

If you don't send in YUY2, or v210, a poor quality chroma up/down sampling will be performed. You are better off starting with the orignal 16-bit TIFFs and creating a new YUY2 file. This will preserve as much vertical chroma resolution as possible.

3D Blu-code supports IYUV input. In fact, last time I got to use it that is all it supported.

CC SP3 has the same problem. If you send in IYUV, the chroma gets pretty messed up from the up/down scaling. HCEncode, on the other hand, works well with IYUV input.

[AlekseiV]

Here is an encode I did with Sonic CineVision 3.5:http://sovietpride.su/stf/lighthouse.264New Sonic CineVision 3.5 encode using the same settings except for:http://sovietpride.su/stf/lighthouse2.264

(Might need to use a download manager; not sure if my local connection is terrible right now, or if my server's conn. is slow)

Edit: Google indexed these files two minutes after I made this post. That's kind of scary.

[kolak]

If you don't send in YUY2, or v210, a poor quality chroma up/down sampling will be performed. You are better off starting with the orignal 16-bit TIFFs and creating a new YUY2 file. Some of the code out their is introducing a half pixel shift between Y and Cb/Cr because they are using nearest neighbor, which does not account for the co-located horizontal chroma samples.

3D Blu-code supports IYUV input. In fact, last time I got to use it that is all it supported.

CC SP3 has the same problem. If you send in IYUV, the chroma gets pretty messed up from the up/down scaling. HCEncode, on the other hand, works well with IYUV input.

Yes- that's why CTC suggests v210 for CC-HDe and YUY2 for SP encoders.

Sony's Dual Stream encoder (they keep is seperate from Blu-code) does support only yuv, which many companies found annoying :)
CTC has just officially released their MVC version. About RT encoding with all features found in CC-HDe.


Andrew

[Stacey Spears]

CC-HDe works best with IYUV input.

[kolak]

CC-HDe works best with IYUV input.

Not for most people, who use filtering (source gets upscaled internally to 4:4:4 14bits), so v210 is much better in this case.
IYUV is good, but needs to be properly prepared first.


Andrew

[Lyris]

By filtering, I hope you mean some sort of dithering and not the lowpass filter :(
I've seen a few Dreamworks Animated titles that are LPF'd that surely didn't have to be. Surely the compressionists are aware of what it's doing?

[kolak]

By filtering, I hope you mean some sort of dithering and not the lowpass filter :(
I've seen a few Dreamworks Animated titles that are LPF'd that surely didn't have to be. Surely the compressionists are aware of what it's doing?

You would be surprised who is doing encodes for big studios (not always, but happens) :)
LPF may be useful in 5% cases (or less). I never used it.


Andrew

[Lyris]

I don't even find LPF useful for SD DVD. From my experience, all you get is a different picture that I don't ever find to be subjectively better. Most of the time if I have a scene that has such complexity, rolling some high frequencies off doesn't ever help. I sometimes wondered if compressionists liked to turn it on during busy scenes as a way of saying "Look, I tried, I tweaked it".

With that said, I got into this more recently, and encoders have improved...

[kolak]

I don't even find LPF useful for SD DVD. From my experience, all you get is a different picture that I don't ever find to be subjectively better. Most of the time if I have a scene that has such complexity, rolling some high frequencies off doesn't ever help. I sometimes wondered if compressionists liked to turn it on during busy scenes as a way of saying "Look, I tried, I tweaked it".

With that said, I got into this more recently, and encoders have improved...

No- they just use default settings :)


Andrew

[mp3dom]

The question could be 'why it's on by default'. Both SP2/SP3/HDe have LPF on by default. The values on HDe are quite weak but still it's on.

[Lyris]

Maybe we should petition CTC to set LPF *OFF* by default and watch the quality of new releases (on DVD) improve!

[kolak]

The question could be 'why it's on by default'. Both SP2/SP3/HDe have LPF on by default. The values on HDe are quite weak but still it's on.

Don't know :)
Will suggest CTC to make "AS IS" as a default option.

Anyway- is there are solution for fades problem with x264 or not (keeping BD compatibility) :)?


Andrew

[mariush]

I've uploaded the file in the first post on my server... might be a good idea to edit the first post and include there the links posted throughout these pages.

anyways, the url is here: http://mplayer.savedonthe.net/test_files/ , the Lighthouse Test Footage folder - Resume supported, multiple download threads (though I hope you won't kill the server), should be fast ... 1gbps US

[sneaker_ger]

Screenshots of x264 (by me) vs Sonic CineVision (by Biggiesized) at 28000 bps:

http://www.abload.de/img/0009_sourceopva.png
http://www.abload.de/img/0009_slowhpkz.png
http://www.abload.de/img/0009_veryslowmei7.png
http://www.abload.de/img/0009_scv_280007dcs.png

http://www.abload.de/img/1434_sourcejs4o.png
http://www.abload.de/img/1434_slowws71.png
http://www.abload.de/img/1434_veryslowhdkh.png
http://www.abload.de/img/1434_scv_28000nflt.png

http://www.abload.de/img/1756_sourcezsi8.png
http://www.abload.de/img/1756_slowbqyp.png
http://www.abload.de/img/1756_veryslowrcws.png
http://www.abload.de/img/1756_scv_280009g84.png

Both x264 and SCV have problems on the initial fade in, though the difference between preset slow and veryslow is huge. On the second screen all three show some problems, but SCV ranks last IMHO. All three encodes look good on the last screen.

[aegisofrime]

Now we just need a CCe-HD encode to compare... Especially since it was that which spurned this whole debate.

[jpsdr]

Here my encode result with Jeeb's 1788 version, but... i've just discovered that there is a v1790 bugfix...
So, now, here the result with 1788, in 24h, you'll have the result with 1790.
You can get the file here (http://dl.free.fr/oSEWMSVdZ) (352MB).

Encode settings :

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.8 --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.8 --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%

Tune : Film
Bitrate : 25000

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:126 Avg QP:10.33 size:534495
x264 [info]: frame P:715 Avg QP:12.62 size:233392
x264 [info]: frame B:2011 Avg QP:14.96 size: 64621
x264 [info]: consecutive B-frames: 0.9% 2.5% 17.3% 79.3%
x264 [info]: mb I I16..4: 37.0% 40.1% 22.9%
x264 [info]: mb P I16..4: 4.2% 10.8% 4.3% P16..4: 40.8% 25.7% 9.8% 0.9% 2.6% skip: 0.9%
x264 [info]: mb B I16..4: 0.1% 0.9% 0.4% B16..8: 39.8% 17.1% 4.5% direct:10.8% skip:26.3% L0:41.6% L1:41.7% BI:16.7%
x264 [info]: final ratefactor: 12.43
x264 [info]: 8x8 transform intra:49.8% inter:30.4%
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: coded y,uvDC,uvAC intra: 97.1% 82.2% 73.5% inter: 36.7% 35.8% 12.8%
x264 [info]: i16 v,h,dc,p: 4% 5% 79% 12%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 59% 3% 3% 3% 4% 3% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 16% 26% 6% 7% 7% 8% 6% 9%
x264 [info]: i8c dc,h,v,p: 65% 17% 13% 5%
x264 [info]: Weighted P-Frames: Y:20.1% UV:16.9%
x264 [info]: ref P L0: 68.3% 4.5% 26.0% 1.2% 0.0%
x264 [info]: ref B L0: 80.0% 20.0%
x264 [info]: ref B L1: 87.8% 12.2%
x264 [info]: kb/s:24492.21

encoded 2852 frames, 7.31 fps, 24492.21 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:126 Avg QP:11.79 size:454755
x264 [info]: frame P:715 Avg QP:12.71 size:232556
x264 [info]: frame B:2011 Avg QP:14.96 size: 72714
x264 [info]: consecutive B-frames: 0.9% 2.5% 17.3% 79.3%
x264 [info]: mb I I16..4: 25.6% 52.5% 21.9%
x264 [info]: mb P I16..4: 3.0% 6.5% 3.7% P16..4: 40.3% 34.7% 7.8% 1.0% 2.3% skip: 0.7%
x264 [info]: mb B I16..4: 0.0% 0.4% 0.4% B16..8: 38.7% 23.1% 5.1% direct: 9.1% skip:23.2% L0:43.3% L1:42.9% BI:13.8%
x264 [info]: 8x8 transform intra:50.8% inter:33.9%
x264 [info]: direct mvs spatial:97.6% temporal:2.4%
x264 [info]: coded y,uvDC,uvAC intra: 96.4% 75.7% 67.3% inter: 37.8% 28.3% 12.3%
x264 [info]: i16 v,h,dc,p: 5% 6% 69% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 23% 8% 8% 8% 8% 9% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 10% 9% 11% 9% 10% 10% 13%
x264 [info]: i8c dc,h,v,p: 48% 31% 13% 8%
x264 [info]: Weighted P-Frames: Y:20.4% UV:16.9%
x264 [info]: ref P L0: 81.7% 7.1% 9.9% 1.3% 0.0%
x264 [info]: ref B L0: 81.0% 19.0%
x264 [info]: ref B L1: 88.6% 11.4%
x264 [info]: kb/s:24870.79

encoded 2852 frames, 1.70 fps, 24870.79 kb/s