Lighthouses of the Pacific Northwest - Blu-ray Test Footage

[Biggiesized]

If any of you know Stacey Spears in a professional or personal capacity, please send him your thanks. :thanks:

Stacey shot this footage for his newest Blu-ray release, Lighthouses of the Pacific Northwest.

http://upload.hattix.co.uk/files/lighthouse_frontcover.jpg (http://www.amazon.com/Lighthouses-Pacific-Northwest-Blu-ray-Stacey/dp/B0043TY5GO/)

Please visit his website at www.lighthousesof.com for more information.

Source information:
Camera: RED One Digital Cinema Camera
Frame rate: 23.976 fps (progressive)
No. frames: 2852
Resolution: 1920x1080
Color subsampling: 4:2:0
FourCC: IYUV/I420
Container: Raw YUV
Color conversion: ITU-R Recommendation BT.709 (SMPTE 274M)
Original files contact: stacey [at] spearsandmunsil [dot] com
Restrictions of use: Encoder testing only. No right to redistribute the source in any form for the purpose of commercial gain.
Copyright: Copyright Stacey Spears
Date of Recording: 2009
Source: Stacey Spears


http://upload.hattix.co.uk/files/200px-RapidShare_Logo.svg.png
Source Download:
http://rapidshare.com/files/431994422/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.001
http://rapidshare.com/files/431994464/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.002
http://rapidshare.com/files/431994447/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.003
http://rapidshare.com/files/431994455/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.004
http://rapidshare.com/files/431994470/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.005
http://rapidshare.com/files/431994468/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.006
http://rapidshare.com/files/431993279/1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.007

Files are split into 500,000,000 byte chunks.

md5 checksum:
bda76236651479744bd2beb3a1e65e85

[kieranrk]

With all due respect rapidshare links are totally useless. Please could you use a better file hoster like mediafire or torrent file or similar.

[Biggiesized]

Why are they useless? My university connection times out if I try to upload it anywhere else.

I could create a torrent, but that would require me to have my computer run 24/7.

[kieranrk]

Why are they useless? My university connection times out if I try to upload it anywhere else.


I can't even download the thing. It says no servers are available. On the rare occasions when it does work speeds are glacial. This happens for pretty much everybody.

If you want I can let you upload it to an FTP server. (will probably have to ask someone on a fast link to make it into a torrent or something)

[bnshrdr]

Why are they useless? My university connection times out if I try to upload it anywhere else.

I could create a torrent, but that would require me to have my computer run 24/7.

Not once at least one other person seeds it once they download it. I'm sure someone around here would volunteer.

[Dark Shikari]

Why are they useless?Because Rapidshare caps you to one download per day if you're lucky enough to get a download at all?

[Audionut]

I've got an FTP server capable of 250mbits if you want.

Or if you create a torrent I'll grab it and help seed from the same server.

PM me for ftp details if you wish.

[Biggiesized]

Someone PM'd me with FTP details. I will put it up there. Give me about an hour.

EDIT: Uploading now, but FTP transfers are much slower for me than uploading to Rapidshare.

[Biggiesized]

Because Rapidshare caps you to one download per day if you're lucky enough to get a download at all?
Hrmm... I only get timed caps of about 20 minutes before I can download again.

[Biggiesized]

My FTP upload keeps timing out and resetting itself after 2 hours straight of trying. Someone has already downloaded the entire sequence. Would that person mind hosting it on their own FTP server or possibly uploading it to TheFluff's?

Here is his contact information: http://forum.doom9.org/member.php?u=59238

[TheRyuu]

Hrmm... I only get timed caps of about 20 minutes before I can download again.

Yea, so each download is going to go slow as shit plus 20 minutes in between each download = too much :effort: to try and download it.

Rapidshare has sucked, sucks now, and probably always will suck.

[Przemek_Sperling]

I could create a torrent, but that would require me to have my computer run 24/7.

Not really, you can always use BurnBit http://burnbit.com

[Przemek_Sperling]

I think that Wuala (www.wuala.com) is the best for such sharing. Just download and install Wuala, use coupons from http://www.retailmenot.com/view/wuala.com to make it larger (all these "I-LIKE- work. and don't you worry, there are always some kind of coupons), upload the file and make it public. As easy as abc.

[jpsdr]

Having an account on rapidshare, i'll try to download it. When done, if your proposition of FTP stays kieranrk, i'll PM you.

[jpsdr]

Wonderfull ! The last weeks my internet connection sucked, but not this morning !
I've finished downloaded the files.

[Blue_MiSfit]

Very cool. I look forward to seeing this and doing some proper full-up testing.

[Biggiesized]

Not really, you can always use BurnBit http://burnbit.com

Can you explain how this Burnbit works? It seems like it turns their hosting into a 3rd party torrent seeder in addition to everyone else acting as a normal seeder.

I think that Wuala (www.wuala.com) is the best for such sharing. Just download and install Wuala, use coupons from http://www.retailmenot.com/view/wuala.com to make it larger (all these "I-LIKE- work. and don't you worry, there are always some kind of coupons), upload the file and make it public. As easy as abc.

Unfortunately, the file is too large to be uploaded even with the coupons. They only give you an additional 1 GB free storage. The file in a zip or 7-zip archive is at least 3 GB.

[shon3i]

Very cool. I look forward to seeing this and doing some proper full-up testing.
Yep, but nothing new that we already not know. x264 still have problem with fades, black levels, banding etc (30mbps@veryslow).

[Biggiesized]

Let me know when you guys get the file up on an FTP server. I'll add the link to the first post.

[kolak]

Yea, so each download is going to go slow as shit plus 20 minutes in between each download = too much :effort: to try and download it.

Rapidshare has sucked, sucks now, and probably always will suck.

No- just there is no such a thing like FREE these days- whatever it's :)


Andrew

[AlekseiV]

Lighthouses test footage.torrent (https://sovietpride.su/stf/Lighthouses test footage.torrent)
Should work.

[kolak]

Lighthouses test footage.torrent (https://sovietpride.su/stf/Lighthouses test footage.torrent)
Should work.

Let people with fast upload speed download it first.


Andrew

[AlekseiV]

I have a 100mbit server backing the torrent.

[jpsdr]

Now that i have the files, what do i do with them ?
I thought they were old format splitted rar, but it's not. I think they should be re-united, but how ?

[sneaker_ger]

Use a program that supports 7z (http://www.7-zip.org/).

[AlekseiV]

If you have the .7z.### files, WinRAR can open them if you merge them.
copy /B 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.7z.00* archive.7z
(on windows)

7zip can open them without needing a merge. WinRAR can open the .7z (in the torrent) just fine.

[sneaker_ger]

Mediafire: (uses LZMA2 so you might need to update your 7zip/WinRAR)
http://www.mediafire.com/?9t8k9le98wqst

[kolak]

Mediafire: (uses LZMA2 so you might need to update your 7zip/WinRAR)
http://www.mediafire.com/?9t8k9le98wqst

Very slow- rapidshare at least is fast- once you get to he download link :)

Andrew

[sneaker_ger]

Rapidshare links are already in the start post.

[sneaker_ger]

x264 1788 32bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset slow --tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000
--pass 1 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict
-o lighthouse_br_28000.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --demuxer raw --input-csp i420

x264 --fps 24000/1001 --level 4.1 --preset slow --tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000
--pass 2 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict
-o lighthouse_br_28000.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --demuxer raw --input-csp i420

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

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

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



http://rapidshare.com/files/432252669/lighthouse_br_28000_slow.mkv
http://www.mediafire.com/?rimg4ekqqr77q

[Stacey Spears]

Yep, but nothing new that we already not know. x264 still have problem with fades, black levels, banding etc (30mbps@veryslow).

The point of providng the source was to have some additional test content to help improve fades and gradients.

[Stacey Spears]

Use a program that supports 7z.

I like IZArc myself.

[sneaker_ger]

x264 1788 32bit from x264.nl

Settings are the same as before, except preset veryslow instead of slow (and bframes kept at 3).
x264 --fps 24000/1001 --level 4.1 --preset veryslow --bframes 3 --tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 1 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthouse_br_28000_veryslow.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --demuxer raw --input-csp i420
x264 --fps 24000/1001 --level 4.1 --preset veryslow --bframes 3 --tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 2 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthouse_br_28000_veryslow.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --demuxer raw --input-csp i420
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/1434_sourcejs4o.png
http://www.abload.de/img/1434_slowws71.png
http://www.abload.de/img/1434_veryslowhdkh.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://rapidshare.com/files/432315400/lighthouse_br_28000_veryslow.mkv
http://www.mediafire.com/?bi64kc8tnbpqa

Looking forward to see some non-x264-encodes.

[Stacey Spears]

I would target 20avg and 30pk. This is a common rate for a high profile title from Disney. They like to include more than one lossless audio track.

[poisondeathray]

Very slow- rapidshare at least is fast- once you get to he download link :)




you're joking right ?

with mediafire, you can use download accellerators (multiple simultaneous connections to 1 file) , or use multiple simulataneous connections for different files as well - and best of all it's free

for rapidshare it's slower, and you have to wait bewteen downloads if there's even a download slot available

[poisondeathray]

The point of providng the source was to have some additional test content to help improve fades and gradients.

Thanks for making this test content available

[Biggiesized]

I would target 20avg and 30pk. This is a common rate for a high profile title from Disney. They like to include more than one lossless audio track.
I wish this were true for Ponyo's release. The Japanese track got the short end of the stick.

[Blue_MiSfit]

Yes, thanks very much for this content. I'll seed it with my last breath :)

Derek

[sneaker_ger]

I would target 20avg and 30pk. This is a common rate for a high profile title from Disney. They like to include more than one lossless audio track.

If we all can agree on specific bitrates I will redo the encodes, unless someone else beats me to it. But I'd like to see some non-x264-encodes first.

[Blue_MiSfit]

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

[Lyris]

I wish this were true for Ponyo's release. The Japanese track got the short end of the stick.
Do you actually have a sound system, soundproofed room, and set of ears that let you hear any audio compression artefacts though?

[Blue_MiSfit]

This is a fade torture test :D

Awesome

[shon3i]

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 I want to suggest to use this video, it's more complex for fades and grain.

http://forum.doom9.org/showthread.php?p=1459036#post1459036

Anyway did someone want to make rules for test? My opinion:

1. Strict Blu-Ray compilance (so weightp should be disabled as developers suggest)
2. 25mbps
3. Post average speed during encode, i know it's useless, but i will share my results, it's interest to see what speeds can be get for "same" quality.

[Biggiesized]

Do you actually have a sound system, soundproofed room, and set of ears that let you hear any audio compression artefacts though?
All I have are my Sennheiser HD 600 headphones.

I think the claim of indiscernible transparency can be argued when we're measuring lossless versus full DTS (1509) or Dolby Digital Plus. However, an audio spectrogram shows significant differences between Dolby Digital (640) and lossless.

The Japanese release had DTS-HD MA. The U.S. release featured Dolby TrueHD for the English dub and plain Jane DD for Japanese audio.

But I digress...

[sneaker_ger]

Anyway did someone want to make rules for test? My opinion:

1. Strict Blu-Ray compilance (so weightp should be disabled as developers suggest)
2. 25mbps
3. Post average speed during encode, i know it's useless, but i will share my results, it's interest to see what speeds can be get for "same" quality.

1. Completely? I've yet to see any backed up complains about weightp 1, so I'd like to disagree.
2. I'm fine with anything from 20 to 30 Mbit
3. Why not? But we have to make sure we use the same formula. Example:
first pass: encoded 2852 frames, 17.96 fps
second pass: encoded 2852 frames, 6.29 fps
overall fps: 4,65

But I digress...

Indeed, two pages arguing about the best one click hoster is enough off topic for the rest of this thread.

[Dark Shikari]

Weightp on Blu-rays is probably fine now that Mediatek have fixed their firmware.

[Lyris]

With BD the situation is a little different than DVD, since "Average Joes" have been introduced to firmware updates (studios did a good job of explaining updates with little leaflets packed into the titles). But even still, when you're going into replication, if it doesn't work with everything, it's probably not fine.

Do you know how many players were affected? MTK's BD solution was pretty new - I know the Oppo players used it, were there any others?

[sneaker_ger]

LG and Phillips

[kolak]

1. Completely? I've yet to see any backed up complains about weightp 1, so I'd like to disagree.
2. I'm fine with anything from 20 to 30 Mbit
3. Why not? But we have to make sure we use the same formula. Example:
first pass: encoded 2852 frames, 17.96 fps
second pass: encoded 2852 frames, 6.29 fps
overall fps: 4,65



Indeed, two pages arguing about the best one click hoster is enough off topic for the rest of this thread.

Where is 4.65 does come from?

It should be 12.13 as an average speed.

Andrew

[sneaker_ger]

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.

[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

[J_Darnley]

Big thanks to those seeding the torrent. Some of you have fantastic connections.

[AlekseiV]

Here is the test footage in H264 lossless: http://sovietpride.su/stf/lighthouses_h264lossless.mkv

Encoded with x264 0.108.1790 8eaf8a6 8bit
Settings: x264_64 --fps 24000/1001 --qp 0 --preset slow --demuxer raw --input-csp i420 --output lighthouses_h264lossless.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv

Filesize is 2.06GB

[Biggiesized]

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).
Definitely a much bigger visual improvement. Try the newest patched build and up the bit rate to 28 Mbps.

[sneaker_ger]

So we agreed on 28000 - 40000 - 30000 now? Good. That's especially useful to verify the claims about x264 being inferior at high bitrates.
Next question: will we allow weightp 1? Weightp 2 seems out of the question for commercial Blu-Rays.
I will also redo my encodes with 1790 (probably tomorrow), because my old ones might be affected by the bugs. I will also do a test in shifting the initial fade in to the center of the timeline.

[jpsdr]

Ok, i'll do at 28 MB, it was Shon3i who wanted 25 MB.
So, where are the Blu-Code and CCe-HD encode ????
Can this footage be used to provide the banding problem mp3dom and shon3i are talking about ?
Working personnaly 99.9% with anime, i'm more interesting with the "banding problem" than fading.

Edit : I personnaly do encoding (my own fansub indeed) for myself and eventualy some friends. Weightp 2 is totaly Blu-Ray compliant, so, my policy for those who have crapy players is : "Buy a player wich works". So, i'll not disable something wich improve quality because there is buggy players ! So, compare has to be made with all the possible options Blu-ray compliant, and not "crapy bugged player compliant".
I think you've understood i totaly disagree disable weightp, and will not in the test encode i'll provide, and weightp should also be used on the pro encode (CCe-HD, Blu-Code), we are still waiting, to be able to compare the encoder at their best capability.

[Dark Shikari]

So we agreed on 28000 - 40000 - 30000 now? Good. That's especially useful to verify the claims about x264 being inferior at high bitrates.
Next question: will we allow weightp 1? Weightp 2 seems out of the question for commercial Blu-Rays.If you care about fades, you can use --ref 1 with --weightp 2, which will disable dupes. You could also just trivially edit the code to disable dupes if you are really that worried about some hypothetical broken player.

[sneaker_ger]

Interesting. I may just try it.
But if it's trivial to avoid, how about you add a non-dupes mode? Could make some people happy. Or is this a matter of principle?
About "hypothetical" broken players: well, they're broken in practice. And as far as I know the LG BD370 is still not fully fixed.

[kolak]

If you care about fades, you can use --ref 1 with --weightp 2, which will disable dupes. You could also just trivially edit the code to disable dupes if you are really that worried about some hypothetical broken player.

Yes, it looks simple- player issue.
In reality is not that easy. Client will ask you, why is this happening, becuse user will say it's a faulty disc. The most annoying part is that home user will say- I have 30 BDs and all are fine, why yours is wrong? Even if your stream is BD compliant your client will ask questions and want explanation. If you say you knew about it than it's even worse! It's not easy in reality when you have thousand of discs shipped and people reporting playback problems. No one will take such a risk- you have to understand this.


Andrew

[Gser]

How very nice of him to give us this material. I think I'll try mpeg2 next.
CCE SP3. Very simple profile without dith quant. 3+1 passes, avg bitrate 7500, 2000-9000. Nat1 quant.
http://uploadmirrors.com/download/1QSV29JP/test.m2v
Converted to YUY2 with t3dLUT, spline36 to pal standard, speed up to 25fps and full range.

[kolak]

I think you've understood i totaly disagree disable weightp, and will not in the test encode i'll provide, and weightp should also be used on the pro encode (CCe-HD, Blu-Code), we are still waiting, to be able to compare the encoder at their best capability.

They both use it and I never heard of any playback problems.


Andrew

[AlexW]

They both use it and I never heard of any playback problems.

The pro encoders likely don't use duplicate refs for their explicit weighted prediction which is probably why they don't have any problems on the Mediatek chipset.
I'm currently working on a patch that will change x264's weightp so that weightp 1 will be the same as weightp 2 except without any duplicates, which should fix any compatibility problems on these chipsets.

[Biggiesized]

Will this be a forked patch or will it eventually be committed to the main build?

[kolak]

How very nice of him to give us this material. I think I'll try mpeg2 next.
CCE SP3. Very simple profile without dith quant. 3+1 passes, avg bitrate 7500, 2000-9000. Nat1 quant.

Converted to YUY2 with t3dLUT, spline36 to pal standard, speed up to 25fps and full range.

Stay on topic.


Andrew

[kolak]

The pro encoders likely don't use duplicate refs for their explicit weighted prediction which is probably why they don't have any problems on the Mediatek chipset.
I'm currently working on a patch that will change x264's weightp so that weightp 1 will be the same as weightp 2 except without any duplicates, which should fix any compatibility problems on these chipsets.

Don't know what they use- results are very good (specially with Blu-code) and work fine on all players.


Andrew

[AlexW]

Will this be a forked patch or will it eventually be committed to the main build?
It will eventually be committed.

[jpsdr]

The pro encoders likely don't use duplicate refs for their explicit weighted prediction which is probably why they don't have any problems on the Mediatek chipset.
I'm currently working on a patch that will change x264's weightp so that weightp 1 will be the same as weightp 2 except without any duplicates, which should fix any compatibility problems on these chipsets.

What will be the option wich give the best (theorical) result in that case ?
If [1] will be the same as [2], what will be the point of [2] ?
Because, actualy, there is :

--weightp <integer> Weighted prediction for P-frames [2]
- 0: Disabled
- 1: Blind offset
- 2: Smart analysis


So, even if my english is not excellent, obviously the method/algorithm of [2] is different and better than [1].

[nm]

So, even if my english is not excellent, obviously the method/algorithm of [2] is different and better than [1].

AlexW will replace current --weightp 1 method with a variant of --weightp 2. The latter will remain slightly more efficient, but the new method 1 should be better than the current version.

[jpsdr]

So, if i'm right, we should have :
--weigthp 1 : New version better than old, almost as good as 2, and probably compliant with broken chipset.
--weigthp 2 : Still a little better than new 1, totaly completely fully Blu-Ray compliant, but not with some broken chipset, but totaly with non bugged chipset.
As i'm not in the replicate process, i think i'll stay with [2] for my use even when this update will be commited.

[shon3i]

Edit : I personnaly do encoding (my own fansub indeed) for myself and eventualy some friends. Weightp 2 is totaly Blu-Ray compliant, so, my policy for those who have crapy players is : "Buy a player wich works". So, i'll not disable something wich improve quality because there is buggy players ! So, compare has to be made with all the possible options Blu-ray compliant, and not "crapy bugged player compliant".
I think you've understood i totaly disagree disable weightp, and will not in the test encode i'll provide, and weightp should also be used on the pro encode (CCe-HD, Blu-Code), we are still waiting, to be able to compare the encoder at their best capability. But this encoders are strict Blu-Ray only, so x264 need to be, otherwise we are on begining. Btw tomorrow i will post Blu-Code encode with lastest MVC encoder, i am just wait answer from sony with updated version.

I'm currently working on a patch that will change x264's weightp so that weightp 1 will be the same as weightp 2 except without any duplicates, which should fix any compatibility problems on these chipsets. OMG, weightp bluray :) I hope will be at least efficient as current weightp 2, because old weightp 2 is not doing good job on fades.

[kolak]

But this encoders are strict Blu-Ray only, so x264 need to be, otherwise we are on begining. Btw tomorrow i will post Blu-Code encode with lastest MVC encoder, i am just wait answer from sony with updated version.

OMG, weightp bluray :) I hope will be at least efficient as current weightp 2, because old weightp 2 is not doing good job on fades.

I've treid latest build with weightp 2 on Leo sample and it's close, but bit worse than pro encoder. Big improvement over weightp 0.

Andrew

[Didée]

How very nice of him to give us this material. I think I'll try mpeg2 next.
CCE SP3. Very simple profile without dith quant. 3+1 passes, avg bitrate 7500, 2000-9000. Nat1 quant.

Converted to YUY2 with t3dLUT, spline36 to pal standard, speed up to 25fps and full range.
Stay on topic.

Andrew
The topic is "Blu-ray Test Footage". Mpeg-2 is a valid video codec to be used on BR.

Hence, the post was on topic, your reminder was inappropriate.

[kolak]

The topic is "Blu-ray Test Footage". Mpeg-2 is a valid video codec to be used on BR.

Hence, the post was on topic, your reminder was inappropriate.

Gser does SD encodes- not sure what is the reason.
You can try MPEG2, but we know it will be worse than any AVC.


Andrew

[jpsdr]

But this encoders are strict Blu-Ray only, so x264 need to be, otherwise we are on begining.
I thought x264 was, and weightp was also, it's what x264 developper said, if i remember properly. So, unless any x264 said weightp 2 is not Blu-Ray compliant, i don't see any problem. For me, Blu-Ray compliant is not the same thing as being compliant with bad chipset. I don't care about them !

[Lyris]

MPEG2 is valid perhaps - but not really relevant anymore.

I thought x264 was, and weightp was also, it's what x264 developper said, if i remember properly. So, unless any x264 said weightp 2 is not Blu-Ray compliant, i don't see any problem. For me, Blu-Ray compliant is not the same thing as being compliant with bad chipset. I don't care about them !
Real spec vs "Real-world" spec. I personally always author for maximum player compatibility.

[jpsdr]

Yes, but doing this imply to align to the lowest... Imagine if among the chipset there was a heavy buggy crapped chipset wich doesn't support almost all the interesting features of h264 property, you'll author disgarding all the possibility ?
I've never agree with the policy of "punish all the group if one is guilty". I don't see why other should support (or be punsihed with) "lower quality" because you can't encode with the best quality/options because someone else somewhere screwed-up !
Instead of oblige the guilty/faulty guy to adjust and correct his fault, you are adjusting yourself to him. Because some players are not totaly compliant, you "lower" quality for everyone, and adjust to the incorrect ? This is total irrespect from my point of view, and don't want to be "punished" because of someone else. And, on this way, how could you expect the guilty to correct, if you adjust to him ?
This is my personnal opinion, and a little too much off topic maybe...
New encoding with v1790 is on his way, will be posted tomorrow from my work (speed is x10 than on my home...).

[kieranrk]

Yes, but doing this imply to align to the lowest... Imagine if among the chipset there was a heavy buggy crapped chipset wich doesn't support almost all the interesting features of h264 property, you'll author disgarding all the possibility ?


http://en.wikipedia.org/wiki/D%C3%A9formation_professionnelle

[kolak]

Yes, but doing this imply to align to the lowest... Imagine if among the chipset there was a heavy buggy crapped chipset wich doesn't support almost all the interesting features of h264 property, you'll author disgarding all the possibility ?
I've never agree with the policy of "punish all the group if one is guilty". I don't see why other should support (or be punsihed with) "lower quality" because you can't encode with the best quality/options because someone else somewhere screwed-up !
Instead of oblige the guilty/faulty guy to adjust and correct his fault, you are adjusting yourself to him. Because some players are not totaly compliant, you "lower" quality for everyone, and adjust to the incorrect ? This is total irrespect from my point of view, and don't want to be "punished" because of someone else. And, on this way, how could you expect the guilty to correct, if you adjust to him ?
This is my personnal opinion, and a little too much off topic maybe...
New encoding with v1790 is on his way, will be posted tomorrow from my work (speed is x10 than on my home...).

There is a spec to mandate things- without it you would have one big mess. Even so if there are buggy players and there is a way to avoid their bugs it will be avoided. It's not a big deal in this case- for some reason pro encoder have no big problems with fades or compatibility and nothing need to be switched off. x264 goes way beyond BD spec and for BD use it need to be restricted. If you don't like it do what you want, but don't expect authoring houses (mainly big ones) doing it the same. You have no clue what money can be involved if disc has to be recalled from the market. If it does not play on some of your friends player you will make him another one, because it's just a fun for you.
Warner still uses VC1 and it has nothing to do with quality- it's a money and power world and you won't change it :)

Get a job as a compressionist and you will see :)

Andrew

[Lyris]

magine if among the chipset there was a heavy buggy crapped chipset wich doesn't support almost all the interesting features of h264 property, you'll author disgarding all the possibility ?
Short answer: no. Obviously there are limits. If there was such a player, I imagine it would get recalled and fixed pretty quickly.

I agree with what you say though - why punish the people with working hardware. Not everything should be lowest common denominator; even although I know most people out there have their TVs in Dynamic Mode with the Greyscale and Colour way off standard, I don't sabotage video masters to try and make them look decent on poorly set up display devices.

[Blue_MiSfit]

We're very off topic here.

The only players that had issues with weightp have since been issued firmware updates. That seals the deal for me. You can still make the argument that it might not be "wise" to replicate discs that could play incorrectly on old firmware, but really - how hard is it to put a little note in a BluRay package that says "if you own players xxx yyy zzz you may need to update your firmware"?

I find it extremely hard to believe that anyone who actually owns a bluray player doesn't have internet access and a USB thumb drive ><

Let's get back on topic, testing some encoders! Also, please don't share samples if you cant give any details on how they are encoded.

Derek

[kieranrk]

I find it extremely hard to believe that anyone who actually owns a bluray player doesn't have internet access and a USB thumb drive ><


Blu-Ray players on oil rigs, ships? I don't think it's unreasonable to cater to the lowest common denominator in this case.


If it does not play on some of your friends player you will make him another one, because for you it's just a fun for you.


I agree with you. jpsdr is just clouding the conversation.

[jpsdr]

You have no clue what money can be involved if disc has to be recalled from the market.
I can imagine, but if your disk is not faulty, and players are, it's the players which should be recalled, not the disk.
Player manufacturer simply choose in that case the easy way round, not assuming their faults, and putting others to assume for them. Still, it's my point of view.
End, promise, next post will be for the link of the encoded file...:p

[kolak]

I can imagine, but if your disk is not faulty, and players are, it's the players which should be recalled, not the disk.
Player manufacturer simply choose in that case the easy way round, not assuming their faults, and putting others to assume for them. Still, it's my point of view.
End, promise, next post will be for the link of the encoded file...:p

Yes, but again- this is real world and not everything is as it should be :)

Andrew

[mariush]

Andrew... with the same reasoning, artists should only paint in grayscale because some people are colorblind and they'd complain they can't understand your work properly as they don't see red or they see green and blue as the same color.

You shouldn't sacrifice the quality and the way your work is supposed to be shown for some players, unless they're a large part of the market. Should grow some balls and just say... your player is crappy , get another and if you don't like it return the disc and we refund you....

[aegisofrime]

Andrew... with the same reasoning, artists should only paint in grayscale because some people are colorblind and they'd complain they can't understand your work properly as they don't see red or they see green and blue as the same color.

You shouldn't sacrifice the quality and the way your work is supposed to be shown for some players, unless they're a large part of the market. Should grow some balls and just say... your player is crappy , get another and if you don't like it return the disc and we refund you....

I have to agree. While wide compatibility is nice, at some point one has to leave behind the crappier players. Such a decision should be based on what is there to be gained by using weightp, and what will be lost by not using it.

Similarly, you don't see game developers restricting their work so as to accommodate people with really outdated computers. And the issue with players is much simpler since like Blue Misfit said, there are firmware updates to fix those problems.

[jpsdr]

Ok, end of my off topic, back to subject :
You can find the result of my encode with Jeeb's 1790 version here (http://dl.free.fr/li84LctMb) (396MB).

Encoding parameters are the same than those described in my post #100 (http://forum.doom9.org/showpost.php?p=1459705&postcount=100), except bitrate is 28MB as requested.

Log files :
1st 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: 9.68 size:576170
x264 [info]: frame P:715 Avg QP:12.18 size:259790
x264 [info]: frame B:2011 Avg QP:14.64 size: 73171
x264 [info]: consecutive B-frames: 0.9% 2.5% 17.3% 79.3%
x264 [info]: mb I I16..4: 40.8% 36.2% 23.0%
x264 [info]: mb P I16..4: 7.2% 11.9% 5.1% P16..4: 36.7% 24.9% 9.9% 0.9% 2.8% skip: 0.5%
x264 [info]: mb B I16..4: 0.5% 1.2% 0.5% B16..8: 37.9% 18.7% 5.3% direct:11.0% skip:24.9% L0:40.9% L1:41.2% BI:17.9%
x264 [info]: 8x8 transform intra:44.8% inter:27.5%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: coded y,uvDC,uvAC intra: 97.7% 85.0% 77.6% inter: 39.8% 36.5% 14.0%
x264 [info]: i16 v,h,dc,p: 3% 4% 81% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 11% 61% 3% 3% 3% 3% 3% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 15% 30% 6% 7% 6% 7% 6% 8%
x264 [info]: i8c dc,h,v,p: 67% 16% 13% 5%
x264 [info]: Weighted P-Frames: Y:20.1% UV:16.9%
x264 [info]: ref P L0: 67.9% 4.7% 26.3% 1.2% 0.0%
x264 [info]: ref B L0: 80.1% 19.9%
x264 [info]: ref B L1: 88.0% 12.0%
x264 [info]: kb/s:27271.11

encoded 2852 frames, 6.97 fps, 27271.10 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.20 size:486688
x264 [info]: frame P:715 Avg QP:12.24 size:259307
x264 [info]: frame B:2011 Avg QP:14.57 size: 84046
x264 [info]: consecutive B-frames: 0.9% 2.5% 17.3% 79.3%
x264 [info]: mb I I16..4: 30.5% 47.1% 22.3%
x264 [info]: mb P I16..4: 4.2% 7.0% 4.2% P16..4: 36.3% 35.9% 8.3% 1.0% 2.4% skip: 0.6%
x264 [info]: mb B I16..4: 0.1% 0.5% 0.4% B16..8: 35.2% 25.9% 6.7% direct: 9.7% skip:21.5% L0:42.8% L1:42.4% BI:14.8%
x264 [info]: 8x8 transform intra:46.5% inter:26.7%
x264 [info]: direct mvs spatial:97.6% temporal:2.4%
x264 [info]: coded y,uvDC,uvAC intra: 97.3% 79.5% 72.0% inter: 43.2% 30.4% 13.8%
x264 [info]: i16 v,h,dc,p: 4% 5% 71% 20%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 26% 8% 7% 7% 8% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 11% 9% 11% 9% 10% 10% 13%
x264 [info]: i8c dc,h,v,p: 52% 27% 13% 8%
x264 [info]: Weighted P-Frames: Y:20.4% UV:16.9%
x264 [info]: ref P L0: 81.4% 7.2% 10.1% 1.2% 0.0%
x264 [info]: ref B L0: 80.8% 19.2%
x264 [info]: ref B L1: 88.6% 11.4%
x264 [info]: kb/s:27960.45

encoded 2852 frames, 1.63 fps, 27960.45 kb/s


Now, i repeat my question to shon3i and mp3dom : Does this file exhibit the banding problem (more visible on anime source probably) you're talking about ?

[kolak]

I have to agree. While wide compatibility is nice, at some point one has to leave behind the crappier players. Such a decision should be based on what is there to be gained by using weightp, and what will be lost by not using it.

Similarly, you don't see game developers restricting their work so as to accommodate people with really outdated computers. And the issue with players is much simpler since like Blue Misfit said, there are firmware updates to fix those problems.

Yes, yes, yes- but as I said- none of the authoring houses (specially big ones) will release discs with known problems if they can be avoided- simple. There are no proeblems with pro encoders, so there is no restricted discs. x264 could be used even by big studios, but not with settings which may introduce playback problems. If other encoders can do nice fades without making problems for players, x264 also can- just a matter of some improvements.

Andrew

[chompy]

It's nice to see how big studio care with playback issues due to codec that can be solved with firmware update, but they forget that they seem to look anywhere else when force you to update your player firmware with every new release due to the new proctections they include.

Greetings

[kieranrk]

It's nice to see how big studio care with playback issues due to codec that can be solved with firmware update, but they forget that they seem to look anywhere else when force you to update your player firmware with every new release due to the new proctections they include.


To play devils advocate it's only FOX that does that with BD+.

[hank315]

Just for fun, here's a MPEG2 HD version using HCenc, first 450 frames.
Bitrate 30Mb/s, 40Mb/s max.

Download here (http://www.mediafire.com/?l71vm8288765qzn)

[jpsdr]

So..... i feel a little lonely with my x264 stream post...:(

[kolak]

So..... i feel a little lonely with my x264 stream post...:(

It's to slow. We need at least 8fps overall speed, so 2h movie can be done over night :)


Andrew

[sneaker_ger]

I get about 5,5 fps with my i7-860 @ stock and preset slow, so a 2 hour movie will take less than 9 hours. Pros will use a better computer, so it can be achieved easily.

[kolak]

I get about 5,5 fps with my i7-860 @ stock and preset slow, so a 2 hour movie will take less than 9 hours. Pros will use a better computer, so it can be achieved easily.

Yes- slow is ok.
Posted by jpsdr vidoe was done with placebo- way to slow (maybe good as reference).


Andrew

[mariush]

It's to slow. We need at least 8fps overall speed, so 2h movie can be done over night :)


Andrew

1500$ 1x http://www.newegg.com/Product/Product.aspx?Item=N82E16816101317

3076$ 4x http://www.newegg.com/Product/Product.aspx?Item=N82E16819105267

440$ 4x http://www.newegg.com/Product/Product.aspx?Item=N82E16820134977

-----------------------------------------

5016$ 4x12 core, 16GB ram (hdd, keyboard, mouse not included)

Encoding speed: priceless :D

[jpsdr]

We are trying to see the best x264 can achieve, and after, even if with the "best" parameters there still problems, to show them, and compare with pro encode ! I've made this as a REFERENCE. Unless in my parameters there is one wich is know to screw the encode, or if there is even better parameters to use, this stream is to be used as a reference, to show where problem are, and to be compared with result of pro encoder.
I thought we were here to try to search where x264 is faulty at his best capability, and improve it, and not make a race.
I don't see what the speed has to do with it ! I think it's not the point here. Improve algorithm, and after eventualy improve speed.

We are still waiting :
- Analyse of the stream i've provided to show where x264 is not "good enough". Kolak, you had done this before, no ?
- A stream coming from pro encoder with same average bitrate (28MB), which provide better result than x264, wich x264 developper can analyse and find maybe clues to improve it, in fade and banding.

[kolak]

We are trying to see the best x264 can achieve, and after, even if with the "best" parameters there still problems, to show them, and compare with pro encode ! I've made this as a REFERENCE. Unless in my parameters there is one wich is know to screw the encode, or if there is even better parameters to use, this stream is to be used as a reference, to show where problem are, and to be compared with result of pro encoder.
I thought we were here to try to search where x264 is faulty at his best capability, and improve it, and not make a race.
I don't see what the speed has to do with it ! I think it's not the point here. Improve algorithm, and after eventualy improve speed.

We are still waiting :
- Analyse of the stream i've provided to show where x264 is not "good enough". Kolak, you had done this before, no ?
- A stream coming from pro encoder with same average bitrate (28MB), which provide better result than x264, wich x264 developper can analyse and find maybe clues to improve it, in fade and banding.

I have job- not always have time to spent for tests :)
Try Leo sample- I've posted some video to compare to.

Andrew

[kolak]

1500$ 1x http://www.newegg.com/Product/Product.aspx?Item=N82E16816101317

3076$ 4x http://www.newegg.com/Product/Product.aspx?Item=N82E16819105267

440$ 4x http://www.newegg.com/Product/Product.aspx?Item=N82E16820134977

-----------------------------------------

5016$ 4x12 core, 16GB ram (hdd, keyboard, mouse not included)

Encoding speed: priceless :D

If you run Blu-code on this you will have probably 3-4x faster than RT :) It runs many seperate processes so would use all at 100%. It does it on 2x6 core i7 Xeons, including HT cores.
I wonder how x264 would scale.


Andrew

[shon3i]

Guys sorry for delay, Blu-Code will be upped today :) I need little more time coz my house upload is less than 1 mbit ;)

[jpsdr]

New x264 version, but no regression fix, bugfix or improvement involved in the parameters i've used, so, no need to make a new encode.

[sneaker_ger]

x264 1804 32bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset slow --tune film --slic
es 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 1 --weightp
1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthouse_b
r_slow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --dem
uxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:126 Avg QP: 9.03 size:481953
x264 [info]: frame P:722 Avg QP:11.44 size:206748
x264 [info]: frame B:2004 Avg QP:13.12 size:102206
x264 [info]: consecutive B-frames: 1.0% 3.0% 18.2% 77.7%
x264 [info]: mb I I16..4: 57.0% 0.0% 43.0%
x264 [info]: mb P I16..4: 58.7% 0.0% 0.0% P16..4: 40.4% 0.0% 0.0% 0.0% 0
.0% skip: 0.9%
x264 [info]: mb B I16..4: 43.1% 0.0% 0.0% B16..8: 21.9% 0.0% 0.0% direct:
21.7% skip:13.3% L0:31.6% L1:32.9% BI:35.6%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 92.0% 65.1% 50.9% inter: 48.4% 34.0% 11.3%

x264 [info]: i16 v,h,dc,p: 12% 13% 67% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 19% 4% 9% 5% 8% 6% 13%
x264 [info]: i8c dc,h,v,p: 70% 14% 14% 2%
x264 [info]: Weighted P-Frames: Y:20.9% UV:17.0%
x264 [info]: kb/s:27898.19

encoded 2852 frames, 16.33 fps, 27898.24 kb/s

x264 --fps 24000/1001 --level 4.1 --preset slow --tune film --slic
es 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 2 --weightp
1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthouse_b
r_slow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.yuv --dem
uxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:126 Avg QP:11.55 size:483071
x264 [info]: frame P:722 Avg QP:12.63 size:231337
x264 [info]: frame B:2004 Avg QP:14.30 size: 92602
x264 [info]: consecutive B-frames: 1.0% 3.0% 18.2% 77.7%
x264 [info]: mb I I16..4: 6.8% 72.0% 21.2%
x264 [info]: mb P I16..4: 0.8% 12.0% 2.5% P16..4: 36.4% 27.5% 20.4% 0.0% 0
.0% skip: 0.4%
x264 [info]: mb B I16..4: 0.0% 2.3% 0.8% B16..8: 31.1% 20.6% 8.3% direct:
8.2% skip:28.6% L0:40.7% L1:39.9% BI:19.5%
x264 [info]: 8x8 transform intra:74.7% inter:51.4%
x264 [info]: direct mvs spatial:98.3% temporal:1.7%
x264 [info]: coded y,uvDC,uvAC intra: 97.3% 87.3% 80.6% inter: 51.9% 38.0% 13.3%

x264 [info]: i16 v,h,dc,p: 15% 13% 46% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 9% 22% 10% 10% 10% 10% 10% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 11% 7% 9% 12% 11% 12% 11% 14%
x264 [info]: i8c dc,h,v,p: 57% 23% 13% 8%
x264 [info]: Weighted P-Frames: Y:21.3% UV:17.0%
x264 [info]: ref P L0: 69.3% 30.1% 0.7%
x264 [info]: ref B L0: 78.9% 21.1%
x264 [info]: ref B L1: 88.3% 11.7%
x264 [info]: kb/s:27807.22

encoded 2852 frames, 7.15 fps, 27807.27 kb/s

overall fps: 4.97 (core i7-860 @ stock)

http://www.abload.de/img/0009_sourceopva.png
http://www.abload.de/img/0009_slowhpkz.png (1788)
http://www.abload.de/img/0009_slow_1804vzi1.png (1804)


http://www.abload.de/img/1434_sourcejs4o.png
http://www.abload.de/img/1434_slowws71.png (1788)
http://www.abload.de/img/1434_slow_18043xiz.png (1804)

http://www.abload.de/img/1756_sourcezsi8.png
http://www.abload.de/img/1756_slowbqyp.png (1788)
http://www.abload.de/img/1756_slow_1804992p.png (1804)

Huge improvement on frame 9.


http://rapidshare.com/files/433232344/lighthouse_br_slow_28000_1804.mkv (this is paid for, so you should have full speed + no wait)

[mp3dom]

Huge improvement on frame 9.

Because from 1804 qpmin default value is 0 (previously was 10). Rev 1788 with explicit qpmin=0 should output the same frame.

[sneaker_ger]

Yes, I noticed the change. Also weightp 1 was modified.

[sneaker_ger]

x264 1804 32bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset veryslow --tune film --
slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 1 --weig
htp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthou
se_br_veryslow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.y
uv --demuxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:134 Avg QP: 8.71 size:503229
x264 [info]: frame P:410 Avg QP:11.22 size:234193
x264 [info]: frame B:2308 Avg QP:12.90 size:109334
x264 [info]: consecutive B-frames: 0.5% 1.0% 3.7% 9.0% 13.6% 26.5% 17.5% 8.
8% 19.5%
x264 [info]: mb I I16..4: 57.0% 0.0% 43.0%
x264 [info]: mb P I16..4: 61.3% 0.0% 0.0% P16..4: 37.9% 0.0% 0.0% 0.0% 0
.0% skip: 0.8%
x264 [info]: mb B I16..4: 45.4% 0.0% 0.0% B16..8: 18.5% 0.0% 0.0% direct:
21.5% skip:14.7% L0:29.7% L1:31.8% BI:38.6%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 93.2% 68.5% 55.6% inter: 43.7% 27.9% 9.4%
x264 [info]: i16 v,h,dc,p: 11% 12% 70% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 19% 4% 9% 5% 8% 6% 13%
x264 [info]: i8c dc,h,v,p: 70% 14% 14% 2%
x264 [info]: Weighted P-Frames: Y:20.5% UV:17.6%
x264 [info]: kb/s:27963.80

encoded 2852 frames, 7.27 fps, 27963.85 kb/s

x264 --fps 24000/1001 --level 4.1 --preset veryslow --tune film --
slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --pass 2 --weig
htp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict -o lighthou
se_br_veryslow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_Video_IYUV.y
uv --demuxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:134 Avg QP:10.09 size:535877
x264 [info]: frame P:410 Avg QP:12.37 size:269358
x264 [info]: frame B:2308 Avg QP:13.55 size:101300
x264 [info]: consecutive B-frames: 0.5% 1.0% 3.7% 9.0% 13.6% 26.5% 17.5% 8.
8% 19.5%
x264 [info]: mb I I16..4: 49.0% 28.2% 22.8%
x264 [info]: mb P I16..4: 18.5% 15.2% 6.8% P16..4: 25.2% 19.8% 9.8% 1.0% 2
.9% skip: 0.8%
x264 [info]: mb B I16..4: 3.7% 1.9% 0.9% B16..8: 25.0% 21.6% 9.3% direct:
9.8% skip:27.9% L0:36.9% L1:37.9% BI:25.2%
x264 [info]: 8x8 transform intra:31.9% inter:15.1%
x264 [info]: direct mvs spatial:97.2% temporal:2.8%
x264 [info]: coded y,uvDC,uvAC intra: 98.9% 88.5% 83.5% inter: 43.6% 26.0% 9.9%
x264 [info]: i16 v,h,dc,p: 2% 3% 79% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 32% 7% 6% 6% 7% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 12% 11% 10% 11% 10% 11% 10% 13%
x264 [info]: i8c dc,h,v,p: 63% 18% 10% 9%
x264 [info]: Weighted P-Frames: Y:20.7% UV:17.6%
x264 [info]: ref P L0: 76.0% 23.7% 0.2%
x264 [info]: ref B L0: 84.6% 15.4%
x264 [info]: ref B L1: 86.1% 13.9%
x264 [info]: kb/s:27980.57

encoded 2852 frames, 1.22 fps, 27980.62 kb/s

overall fps: 1.04 (core i7-860 @ stock)

http://www.abload.de/img/0009_sourceopva.png
http://www.abload.de/img/0009_veryslowmei7.png (1788)
http://www.abload.de/img/0009_veryslow_1804xaxb.png (1804)

http://www.abload.de/img/1434_sourcejs4o.png
http://www.abload.de/img/1434_veryslowhdkh.png (1788)
http://www.abload.de/img/1434_veryslow_1804olks.png (1804)

http://www.abload.de/img/1756_sourcezsi8.png
http://www.abload.de/img/1756_veryslowrcws.png (1788)
http://www.abload.de/img/1756_veryslow_1804lzfe.png (1804)

http://rapidshare.com/files/433238089/lighthouse_br_veryslow_28000_1804.mkv (this is paid for, so you should have full speed + no wait)

[STaRGaZeR]

Huge improvement on frame 9.

I think we all agree that it's still a terrible frame. Any improvements in this area are welcomed!

And just a FYI, you're encoding with Blu-ray settings (keyint 24, open-gop bluray, etc) yet you're using more bframes than allowed in the Blu-ray spec. You should reduce them.

[sneaker_ger]

Nice catch. I did lower them on my 1788 encode and forgot to use the switch on this one. Won't be able to redo it until sunday or monday, though.

[Sharc]

Just for fun, here's a MPEG2 HD version using HCenc, first 450 frames.
Bitrate 30Mb/s, 40Mb/s max.

Download here (http://www.mediafire.com/?l71vm8288765qzn)
Looks great, hank, with mpeg-2....

[Lyris]

Until the sky turns into bands!

[Jarod Middelman]

... (this is paid for, so you should have full speed + no wait)

Waste of money, next time just give me a PM with a none paid link and ill put it on x264.nl or a mirror.
Better even would be to come to #x264 on freenode and give me a PM there.

[mariush]

Maybe he uses it for other purposes too, so "is paid for" does not imply he paid now money just for this link.

I also have a paid Rapidshare account, very useful for various things.

[sneaker_ger]

I appreciate the offer, but it's basically like mariush said: you only need to buy an account and have spare traffic, so it's cheap unless too many users download the files.

Here's the redone veryslow encode with 3 bframes:
x264 1804 64bit from x264.nl

x264 --fps 24000/1001 --level 4.1 --preset veryslow --bframes 3 --
tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --p
ass 1 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict
-o lighthouse_br_veryslow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_
Video_IYUV.yuv --demuxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:126 Avg QP: 9.03 size:481521
x264 [info]: frame P:722 Avg QP:11.44 size:206589
x264 [info]: frame B:2004 Avg QP:13.11 size:102328
x264 [info]: consecutive B-frames: 1.0% 3.0% 18.2% 77.7%
x264 [info]: mb I I16..4: 57.0% 0.0% 43.0%
x264 [info]: mb P I16..4: 58.7% 0.0% 0.0% P16..4: 40.4% 0.0% 0.0% 0.0% 0
.0% skip: 0.9%
x264 [info]: mb B I16..4: 43.0% 0.0% 0.0% B16..8: 21.9% 0.0% 0.0% direct:
21.8% skip:13.2% L0:31.6% L1:32.9% BI:35.5%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 92.0% 65.2% 50.9% inter: 48.4% 34.0% 11.3%

x264 [info]: i16 v,h,dc,p: 12% 13% 67% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 19% 4% 9% 5% 8% 6% 13%
x264 [info]: i8c dc,h,v,p: 70% 14% 14% 2%
x264 [info]: Weighted P-Frames: Y:20.9% UV:16.9%
x264 [info]: kb/s:27903.25

encoded 2852 frames, 18.18 fps, 27903.30 kb/s

x264 --fps 24000/1001 --level 4.1 --preset veryslow --bframes 3 --
tune film --slices 4 --vbv-maxrate 40000 --vbv-bufsize 30000 --bitrate 28000 --p
ass 2 --weightp 1 --keyint 24 --open-gop bluray --nal-hrd vbr --b-pyramid strict
-o lighthouse_br_veryslow_28000_1804.mkv 1920x1080p24_Chapter_01_000102_002953_
Video_IYUV.yuv --demuxer raw --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:126 Avg QP:11.12 size:472701
x264 [info]: frame P:722 Avg QP:12.67 size:227901
x264 [info]: frame B:2004 Avg QP:13.77 size: 94995
x264 [info]: consecutive B-frames: 1.0% 3.0% 18.2% 77.7%
x264 [info]: mb I I16..4: 42.9% 34.4% 22.7%
x264 [info]: mb P I16..4: 11.3% 11.7% 4.0% P16..4: 29.9% 26.3% 12.1% 0.9% 3
.1% skip: 0.7%
x264 [info]: mb B I16..4: 2.1% 1.3% 0.6% B16..8: 28.1% 24.9% 9.9% direct:
10.1% skip:23.0% L0:40.3% L1:39.2% BI:20.4%
x264 [info]: 8x8 transform intra:38.4% inter:16.1%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: coded y,uvDC,uvAC intra: 98.9% 85.4% 79.2% inter: 48.8% 30.4% 11.8%

x264 [info]: i16 v,h,dc,p: 2% 3% 79% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 14% 32% 7% 6% 6% 7% 7% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 13% 10% 10% 11% 10% 11% 10% 13%
x264 [info]: i8c dc,h,v,p: 59% 21% 11% 8%
x264 [info]: Weighted P-Frames: Y:21.3% UV:16.9%
x264 [info]: ref P L0: 69.7% 29.6% 0.7%
x264 [info]: ref B L0: 79.3% 20.7%
x264 [info]: ref B L1: 86.7% 13.3%
x264 [info]: kb/s:27875.00

encoded 2852 frames, 1.66 fps, 27875.06 kb/s

overall fps: 1.52 (core i7-860 @ stock)

http://www.abload.de/img/0009_veryslow_1804_3b2olt.png
http://www.abload.de/img/1434_veryslow_1804_3bkr2w.png
http://www.abload.de/img/1756_veryslow_1804_3bgqwp.png

http://rapidshare.com/files/433856904/lighthouse_br_veryslow_28000_1804_3b.mkv (no wait, full speed)

[sneaker_ger]

And this is what happens when you shift the start to the middle:

source:
http://www.abload.de/img/0009_sourceopva.png

slow:
http://www.abload.de/img/0009_slow_1804vzi1.png
http://www.abload.de/img/0009_slow_1804_timeshiwzp2.png (shifted)

veryslow:
http://www.abload.de/img/0009_veryslow_1804_3b2olt.png
http://www.abload.de/img/0009_veryslow_1804_timhx9i.png (shifted)

Slow seems to have benefited much from timeshift.
Logs and streams available on request.

[Jarod Middelman]

Awesome video, very very nice. Funny how the fading only really shows when the video is playing, but when you pause, it looks fine. Each frame of that video is a perfect wallpaper!

I have mirrored the video anyway, great stuff!

[Lyris]

Do you have a link to the mirror? I can't see anything on the x264.nl main page, unless I'm somehow missing it.

[Jarod Middelman]

Is the link from post1460940 (http://forum.doom9.org/showthread.php?p=1460940#post1460940) not working then?

[Lyris]

Works, thanks - missed it while skim-reading. I assumed it was another PNG.

[jpsdr]

9 pages of thread, and not yet any stream encoded with CCE-HD or Blu-Code, to show how/where they are better than x264...:(

[Biggiesized]

Blu-code doesn't accept IYUV or YV12 input.

I plan to post the Leo encode this afternoon using Blu-code in the other thread.

[jpsdr]

And what prevent to convert to YUY2, for exemple ? It's some kind of lame excuse...

[sneaker_ger]

Aren't both leo and lighthouse i420? :confused:

[Biggiesized]

I have the source format for Leo, but not the Lighthouse footage. I can post any format for Leo that can be derived from 10-bit 4:2:2 ProRes LT.

[kieranrk]

I have the source format for Leo, but not the Lighthouse footage. I can post any format for Leo that can be derived from 10-bit 4:2:2 ProRes LT.

Ah the Leo source wasn't uncompressed.

[kolak]

Ah the Leo source wasn't uncompressed.

All intermediate codecs are about HDCAM-SR quality.
All "uncompressed" source which you think about comes in 95% from HDCAM-SR tape.

Andrew

[Blue_MiSfit]

ProRes LT is definitely NOT HDCAM-SR quality. LT is their low bitrate, better than proxy, worse than regular flavor of ProRes.

Vanilla ProRes is maybe the same as HDCAM-SR, ProRes HQ definitely closer.

Derek

[kolak]

ProRes LT is definitely NOT HDCAM-SR quality. LT is their low bitrate, kinda-sorta proxy flavor of ProRes.

Vanilla ProRes is maybe the same as HDCAM-SR, ProRes HQ definitely closer.

Derek

Yes- LT won't be near HDCAM-SR.
New Canopus HQX can be even better than HDCAM-SR SQ, and it does support 10bit now.


Andrew

[Biggiesized]

ProRes LT is definitely NOT HDCAM-SR quality. LT is their low bitrate, better than proxy, worse than regular flavor of ProRes.

Vanilla ProRes is maybe the same as HDCAM-SR, ProRes HQ definitely closer.

Derek

I am in complete agreement with this. If you look closely in the footage, there are a number of compression artifacts, especially in the dark region around his legs. My only bother about the footage is that it is CLEARLY not transparent. ProRes HQ might be visually transparent on something like this, but we'll never know.

Derek, do you think you can access some HDCAM-SR or D5 tape for testing?

[Blue_MiSfit]

I'd love to, and have access to plenty of both... but licensing issues make me very nervous.

[Biggiesized]

Who could you consult about that? Is there someone at your company in charge of managing distribution rights?

[kolak]

I am in complete agreement with this. If you look closely in the footage, there are a number of compression artifacts, especially in the dark region around his legs. My only bother about the footage is that it is CLEARLY not transparent. ProRes HQ might be visually transparent on something like this, but we'll never know.

Derek, do you think you can access some HDCAM-SR or D5 tape for testing?

I compared Cineform, DNxHD, Canopus HQ and HQX.
Thay are about HDCAM-SR quality. HQX at highest setting is close to lossless. You need to zoom 3x (in case of HQX 5x) to see single pixel difference compared to source.
ProRes is even better than DNxHD according to Apple white paper. LT is offline version- so definatelly no as good as HQ version.

D5 is not that great. Next tim I will try to record to HDCAM-SR and capture it back to uncompressed to compare it.
Sony is about to release direct show decoder for SR format (for free aparently)- you will be able to copy tape to file- 1:1 copy. It will be MXF file with SR codec copied through data port on SR deck. Quite interesting.

Andrew

[Lyris]

Glad to hear they're embracing file-based workflow in that way. Tape is just an annoyance to me at this stage - most hard disks can just as easily be shipped around!

[kieranrk]

ProRes is even better than DNxHD according to Apple white paper.

:devil:

[Firebird]

x264 1867 32bit from x264.nl with qpomp 0.95

ffms [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
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:120 Avg QP:12.90 size:360995
x264 [info]: frame P:796 Avg QP:13.44 size:187924
x264 [info]: frame B:1936 Avg QP:13.50 size:115470
x264 [info]: consecutive B-frames: 5.8% 4.1% 20.8% 69.3%
x264 [info]: mb I I16..4: 45.8% 35.3% 18.8%
x264 [info]: mb P I16..4: 21.8% 11.7% 3.3% P16..4: 29.5% 20.0% 9.3% 0.5% 1
.8% skip: 2.1%
x264 [info]: mb B I16..4: 7.3% 2.2% 0.8% B16..8: 24.5% 21.8% 9.9% direct:
11.8% skip:21.9% L0:37.4% L1:38.3% BI:24.2%
x264 [info]: 8x8 transform intra:29.2% inter:17.9%
x264 [info]: direct mvs spatial:97.4% temporal:2.6%
x264 [info]: coded y,uvDC,uvAC intra: 99.0% 91.1% 86.4% inter: 52.4% 37.0% 10.4%

x264 [info]: i16 v,h,dc,p: 2% 1% 80% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 33% 7% 6% 6% 7% 7% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 10% 8% 10% 12% 11% 12% 11% 13%
x264 [info]: i8c dc,h,v,p: 63% 18% 11% 8%
x264 [info]: Weighted P-Frames: Y:21.9% UV:18.2%
x264 [info]: ref P L0: 71.7% 27.5% 0.8%
x264 [info]: ref B L0: 81.4% 18.6%
x264 [info]: ref B L1: 87.6% 12.4%
x264 [info]: kb/s:28008.41
Frame 9:
Source - http://h-4.abload.de/img/0009_sourceopva.png
Encode - http://img709.imageshack.us/img709/5004/79778265.png


http://www.megaupload.com/?d=7TGJ14C0

[mp3dom]

I think is not a good idea to raise qcomp so much. I don't know if it's for this change, but the image have a good amount of small artefacts (ringing and loss of details, look at the roof).

[Firebird]

Yeah, i know. It was a test.

[simonhorlick]

There were some improvements to weighted prediction in the latest x264 (1867) in case anyone wants to try their encodes again.

[kolak]

There are few new titles from Warner with AVC encodes- is it x264?

Andrew