Jan

You can spot a minor difference between the comparison shots when switching back and forth between them. It's mainly in the grain pattern. But you won't notice any of that during playback anyway.

It's going to take 2 or 3 days with the faster settings ;-) With the slower settings, which lead to only a slightly better preservation of fine detail, the encoding time would nearly double. However you have to keep in mind that Harmy is using a Core2Duo Mobile to encode, which is pretty slow compared to newer generations of CPUs.

Maybe TSMuxer splits only on IDR-frames. If so, there won't be any artifacts anyway, but splitting won't be frame exact either. When I think about it now, you wouldn't need that in this case, would you?

Harmy said:

I hope h_h's new 5.1 will be included. The MKV will be a BD compliant stream, so theoretically, if you used TS Muxer, you could split it into two AVCHD DVD9s.

This is likely to cause artifacts at cuttings points. The only tool that I haven't had such a problem with is Smart Cutter. However, I only use it for DVB streams, not Bluray.

As discussed per PM rendering the AVI in several parts is possible as we're using Avisynth input.

Harmy said:

So I should definitely render the AVI in RGB then?

As long as we can't fix this weird problem, yes.

EDIT: Once you did that, we could render the avisynth script that I have to Ut Video YUV first using VirtualDub. This way you'd have a lossless file with correct frame rate, correct colorspace at a smaller size. 

Sorry guys, guess I mixed it up completely. All your lossless files display orange reds on my setup Harmy. Only the encoded video for which I forced a color space conversion in avisynth is fine, so your final encode should be as well. I have really no idea why all that happens. Guess I have to do some tests later on.

The UtVideo RGB file of that scene worked fine on my end. I played it back using LAV Filters with MadVR in MPC-HC. I then encoded the sample to x264 using ConverttoYV12(matrix="rec.709") and the colors stayed exactly the same, no reds that turned into orange. Here's a link. You can check it yourselves.

https://rapidshare.com/files/671478413/Leia-RGB-sample_colorfix.mkv

Harmy, if you want render said scene to UtVideo YUV420, upload it and I'll check if everything is fine.

Usually decoders decide which colorspace to use based on the resolution of the video, which should be fine. So I think the renderer messes something up here. 

MadVR is the best option qualitywise if your GPU is powerful enough to handle it. However, EVR CP should as well do the colorspace conversion just fine. The only settings that differ between optimal and default renderer settings are "Full Floating Point Processing" and "Disable Aero", which shouldn't have those kind of effects. 

Harmy, which renderer do you use in MPC-HC?

You mixed up quite a bit there. Crf=1 means that you're doing a lossless one-pass-encode. However, you limit the MAXIMUM bitrate to 25MBit/s via --vbv-maxrate. Remember, this is the maximum bitrate, NOT the average. I think what you'll get in the end is a video stream with a constant bitrate of 25MBit/s. Better use 2-pass and adjust the AVERAGE bitrate (--bitrate xx). This way scenes with a different complexity are encoded with different bitrates, which helps quality a lot. Vbv-maxrate and vbv-bufsize are only there to limit bitrate peaks so you don't get stuttering during playback. For Bluray use maxrate 40000 and bufsize 30000.

Here are good basic settings for Bluray: www.x264bluray.com 

jabbo5150 said:

Harmy said:

Yes, 15GB video stream is the plan.

I have an Oppo BDP-93. Would this be something I could dump onto a flash drive and play that way? Would it be fast enough to handle it or will I need to use a hard drive?

According to the Oppo Wiki the video stream used for the mkv should be playable. Audio and subtitles might be an issue though depending on the codec/format, which is unfortunately always an issue with hardware players. While they support certain codecs on Bluray or in an m2ts container, they don't when you use mkv.

BD compliancy limits the maximum bitrate to 40MBit/sec, which equals to 5MByte/sec. If the sequential read speed of the flash drive is faster than that no stutters should occur.

You are very welcome Harmy :-)

I used your UtVideo RGB sample and loaded it in avisynth using FFVideoSource. The video has to be indexed first of course. This is the avisynth script:

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")

FFVideoSource("E:\star wars\Leia-RGB-sample.avi", threads=1)

ConvertToYV12(matrix="rec709")

The only magic is to add matrix="rec709", which makes sure the output uses HD color space BT709 with limited TV range, meaning 16-235.

The x264 commandline had the following options checked as well, but I think it works correctly if you leave them out:

--colorprim "bt709" --transfer "bt709" --colormatrix "bt709"

These are the options to use for HD releases. For the DVD one should first resize in RGB and then convert to REC601 using the colormatrix plugin for avisynth. The reason is that most players/decoders will assume the colorspace based on the video resolution. So it must be set accordingly, otherwise the decoder assumes the wrong one and you get color shifts during playback.

Unfortunately UtVideo codec does not allow to specify rec709 when rendering to YUV420. Maybe there's an option in Premiere for that?

Ok guys, I got something. As I suspected from the beginning it seems to be a problem with BT601 vs. BT709 colorspace. The former is usually used for SD, while the latter is used for HD.

I uploaded an encode, please check if the colors, blacks and whites are correct.

https://rapidshare.com/files/671478413/Leia-RGB-sample_colorfix.mkv

Thanks for the sample Harmy, I'll do some tests later or tomorrow.

Well, RGB => YUV420 is a lossy conversion (rounding errors etc.). It does however consider the fact that the human eye is much more sensitive to brightness than it is to color and thereby achieves a much better compressibility. So I think it's a combination of both. But even if that much color information is thrown away, you should not see much of a difference. The color shift that we see here should not happen I think.

Also, you have to remember that your source is not RGB anyway. Most of it originates from Bluray, HDTV or DVD, which already use YUV420.

You are welcome Harmy :-)

Rendering at 8 bit is fine since the finale encode has to be 8 bit anyway, at least if it should be playable on hardware players.

The color space stuff is complicated for me as well. The thing is that there will always be a conversion to YUV420 somewhere. It either happens when rendering in Premiere or in the encoding process. 

Can you upload a sample of the scene you posted screenshots of? Render it with UtVideo RGB. Output colorspace should be BT.709 or Rec.709 if that's available.

Harmy, I sent you a mail with detailed instructions on how to render to UtVideo Codec from Premiere. It's a lossless codec with a good compression ratio. I was able to reduce file size of the lossless avi you posted earlier by 75%! Choose the YUV420 variant and render a short sequence. I think there should be no color space issues present this way.  

Do we have any idea how it looks in the LPP print negative1 uses for his project?

Harmy said:

I'll definitely want those German tracks, thanks Laserschwert :-)

@Jan: But what program should I use? X264 is a codec, so I assume that I'll need some software to run it, right?

No, you can simply copy x264.exe on your harddrive and run it via commandline. Alternatively you can use one of the many GUIs, f.e. MeGUI. It's a matter of taste really.

Harmy said:

Thanks guys. I am a total avisynth analphabet but I really want to do it right, so if avisynth is the way to go, I'll need a lot of help with that.

Well, as long as you don't do any filtering like resizing, debanding, sharpening etc. you don't need avisynth at all, as x264 can index any video that is playable by libav/ffmpeg on its own.

Thanks for the update -1

For those who have an account, the V3 DVDs are available on the Usenet group as well.

Just watched WP3 and WP4 and they're both awesome. Very well done Harmy.

Wow, looks perfect

Hostmaster said:

Harmy said:

Mediafire sounds pretty good. A 200mb limit is unfortunate, especially for a 25GB BD but it's not impossible.

I was also thinking, how difficult would it be to create a sort of a Blu-Ray skeleton, so that people who have the MKV (which will have the same video stream for the main movie as the BD) could simply download that and then mux it together to create a fully functioning BD?  Would that be possible?

If mediafire speed is good, 200mb it's not so bad... ;-) Specially for the AVCHD project.

Tsmuxer can convert a mkv file into a BD or AVCHD in minutes, for an emergency solution it's ok, but just to make a disc without menus.

First of all thank you Harmy, WP3R2 really is great :-)

Well, I think there is a possibility to release it the way Harmy thought of. However I have never tried that personally, so it should be tested before release.

He could author a BD with menus and everything and save it to a folder, using whatever authoring software he wants to. Then he could delete the m2ts for the main movie, rar the rest of the files and upload them.

People would then take the mkv and remux it to m2ts using TsMuxer. Then they'd copy it in the appropriate folder. The last step would be to use Imageburn and create an iso.

About the upload: How long do you have to wait at mediafire before you can download the next file?

I would really go for usenet, at least as a second way of distribution. Yes, many ISPs don't offer usenet access anymore, but since they didn't cover binary groups this doesn't really matter here, does it? To download binaries/files you have to pay (or get a free test account). However, prices are rather low I'd say and files have a very high retention of rougly 3 years or even more for some providers.

@djchaseb: No, the whole OT will be reworked as v2.0