BD Rebuilder Beta - Bug Reports Only

[jdobbs]

Had a dvd encode recently take 6hrs using X264 frameserving. I usually use DGDecNV, but since I was watching some videos at the same time, I switched it. My CPU usage was averaging 22 - 30%. Not sure what could have caused this. Been pretty busy, so I haven't been able to post. I'll have to see if I can repeat this. Because my recent reorganizing has lost the information :p

JD, the HC encoder is used for DVD, eh? Is it 6 core capable?

I noticed the progress now shows pass 2 for DVD's. Is it possible that this change has caused the slowness?It is multi-threaded, but I don't how far it takes it.

[Lathe]

Hmmm, I wonder if I somehow changed something without realizing it...? I am running another encode tonight and I DID change the frame server back to LAVF like I usually use. Granted, this Blu-ray is almost 35 Gigs which would make some difference, but still the first pass, with all my usual settings which normally takes about 1 to 1 1/2 hours took about 2 hours 10 minutes and the 2nd pass is slated to take like 15 hours! Very strange; it has never taken that long before. I wonder if something is different with this new version (4805) or if I have missed something somewhere. I'm working off my SSD drive too. Quite odd...

One interesting difference though, is that when using the directshow frame server, when it began it's first pass I got a runtime error prompt (one that I have been getting at times when using x264 - I attached a picture of it a page or two earlier here on this thread) I clicked 'OK' and it continued. And then when it began it's 2nd pass, I got the same error again and it wouldn't continue until I had clicked 'OK'. However, tonight with LAVF, it smoothly began both passes just fine without any prompts.

Maybe my machine is haunted... :devil:

[omegaman7]

Any changes to how Pseudo files are created?

[jdobbs]

Hmmm, I wonder if I somehow changed something without realizing it...? I am running another encode tonight and I DID change the frame server back to LAVF like I usually use. Granted, this Blu-ray is almost 35 Gigs which would make some difference, but still the first pass, with all my usual settings which normally takes about 1 to 1 1/2 hours took about 2 hours 10 minutes and the 2nd pass is slated to take like 15 hours! Very strange; it has never taken that long before. I wonder if something is different with this new version (4805) or if I have missed something somewhere. I'm working off my SSD drive too. Quite odd...

One interesting difference though, is that when using the directshow frame server, when it began it's first pass I got a runtime error prompt (one that I have been getting at times when using x264 - I attached a picture of it a page or two earlier here on this thread) I clicked 'OK' and it continued. And then when it began it's 2nd pass, I got the same error again and it wouldn't continue until I had clicked 'OK'. However, tonight with LAVF, it smoothly began both passes just fine without any prompts.

Maybe my machine is haunted... :devil:The size of the input disc isn't really that important in terms of encode time. How many frames are you encoding?

As for the default changing to Directshow... there used to be a different indicator in the INI for each possible decoder. There now is only one that has a value set for each of the possible decoders. So as of a couple of versions back, you will default to Directshow until you change it. It will then stay with your choice until you change it again.

[jdobbs]

Any changes to how Pseudo files are created?No changes.

[Lathe]

The size of the input disc isn't really that important in terms of encode time. How many frames are you encoding?

As for the default changing to Directshow... there used to be a different indicator in the INI for each possible decoder. There now is only one that has a value set for each of the possible decoders. So as of a couple of versions back, you will default to Directshow until you change it. It will then stay with your choice until you change it again.

Thanks for letting me know. Unfortunately my comp DID crash during the encode last night, so I don't have the specs; but, I will carefully check it out when I try again.

[jdobbs]

Thanks for letting me know. Unfortunately my comp DID crash during the encode last night, so I don't have the specs; but, I will carefully check it out when I try again.If x264 is crashing on your system (as you mentioned earlier), it's highly probable your system isn't stable. I'd open up the box and see if you have accumulated dust on your processor heatsink that may be causing overheating.

[Lathe]

If x264 is crashing on your system (as you mentioned earlier), it's highly probable your system isn't stable. I'd open up the box and see if you have accumulated dust on your processor heatsink that may be causing overheating.

Excellent suggestion; thanks JD.

[daberti]

Excellent suggestion; thanks JD.

It would be a good idea to install a temperature monitoring sw like CoreTemp.
It also has Temperature limiting features.

@JD
I've noticed that with CRF elapsed a certain amount of time the X264 encoding speed greatly improves.
I suspect the first 30% or alike is done before speed increase.
Could you please explain?

Thanks

[jdobbs]

It would be a good idea to install a temperature monitoring sw like CoreTemp.
It also has Temperature limiting features.

@JD
I've noticed that with CRF elapsed a certain amount of time the X264 encoding speed greatly improves.
I suspect the first 30% or alike is done before speed increase.
Could you please explain?

ThanksI can think of no reason why the speed would change mid-encoding. It may be possible that there was some high level of complexity in the first 30%, but that's unlikely. It's more likely it is something other than BD-RB/X264. Perhaps some background process was running on your PC?

[daberti]

I can think of no reason why the speed would change mid-encoding. It may be possible that there was some high level of complexity in the first 30%, but that's unlikely. It's more likely it is something other than BD-RB/X264. Perhaps some background process was running on your PC?

I cross-checked, no antivirus, closed Dropbox, maybe it is just related to this very movie (No Capre No Glory). And maybe it is peculiar of Alternate.
I will encode Once Upon A Time In America later, to see what happens and will let you know.

[jdobbs]

Thanks for letting me know. Unfortunately my comp DID crash during the encode last night, so I don't have the specs; but, I will carefully check it out when I try again.You weren't, by chance, encoding a DVD import and resizing it, were you? I noticed something odd early today in TSMUXER that could (very rarely, I'd guess) cause it to detect a 480i/29.97 source as 480p/29.97 (it might also happen on 576i/25, but I haven't seen it). That caused an encode failure on a source I tried. Interestingly TSMUXER lists it at 480i -- but sets the MPLS as 480p/29.97 (which is illegal for a BD primary source). I've added a workaround that will be included in the next release of BD-RB.

[daberti]

You weren't, by chance, encoding a DVD import and resizing it, were you? I noticed something odd early today in TSMUXER that could (very rarely, I'd guess) cause it to detect a 480i/29.97 source as 480p/29.97 (it might also happen on 576i/25, but I haven't seen it). That caused an encode failure on a source I tried. Interestingly TSMUXER lists it at 480i -- but sets the MPLS as 480p/29.97 (which is illegal for a BD primary source). I've added a workaround that will be included in the next release of BD-RB.

By no means I were JD.
Source was BD, No Capre No Glory, as I mentioned earlier.

Wait..wait..Holy Crap..Exactly where it started to get faster no more video is present, just audio and a black screen :(
Source is 1080p destination is the same.

[Capsbackup]

Wait..wait..Holy Crap..Exactly where it started to get faster no more video is present, just audio and a black screen :(
Source is 1080p destination is the same.

Possible a bad rip! :(
Check your source where you think the location of it going to black screen.

[jdobbs]

A note for everyone:

I'm hoping to include an ALTERNATE output capability to HEVC (H.265) in the next release. It will work only to MKV. I think it will be a good alternative for creating high-quality backups of BD movies, while using significantly less space. In order to support it in the way I hope, you will need a Directshow filter that supports H.265. This link (https://github.com/strukturag/LAVFilters/releases/download/v0.1.3/libde265-filters-0.1.3.exe) points to an installer for the libde265 directshow filter. I tested it (a little) and it will play back an H.265 MKV via Media Player Classic (found in the BD-RB TOOLS\MPC folder). More information on the project and the filter are available here (https://github.com/strukturag/LAVFilters/releases) and here (http://www.libde265.org).

[omegaman7]

H.265 eh? JDobbs! You're amazing :D Donation time :) Go by yourself breakfast, lunch, a movie, whichever you desire ;)

[daberti]

Possible a bad rip! :(
Check your source where you think the location of it going to black screen.

Rip is perfect mate.
The funny thing is that the very same encoding done via same options but MULTIPROCESS=1 as hidden option did the things right :(

[jdobbs]

Rip is perfect mate.
The funny thing is that the very same encoding done via same options but MULTIPROCESS=1 as hidden option did the things right :(I assume you are using Directshow? Maybe it was interrupted during the split. Try it again, from scratch with MULTIPROCESS=2 (or whatever you were using), and let me know how it comes out.

[jdobbs]

H.265 eh? JDobbs! You're amazing :D Donation time :) Go by yourself breakfast, lunch, a movie, whichever you desire ;)Thanks. I'm doing testing now using SSIM to try and determine the relationship between CRF values for each encoder (X264 & X265). There'll also have to be a conversion to H.264 if importing HEVC to make it compatible with BD (at least until they finalize H.265 support)... but I do that now with a DIVX or MPEG-4 sources, so it shouldn't be a big deal. I just have to do it as lossless as possible while keeping a reasonable interim size.

[HWK]

A note for everyone:
... In order to support it in the way I hope, you will need a Directshow filter that supports H.265. This link (https://github.com/strukturag/LAVFilters/releases/download/v0.1.3/libde265-filters-0.1.3.exe) points to an installer for the libde265 directshow filter. I tested it (a little) and it will play back an H.265 MKV via Media Player Classic (found in the BD-RB TOOLS\MPC folder). More information on the project and the filter are available here (https://github.com/strukturag/LAVFilters/releases) and here (http://www.libde265.org).

Media player classic home cinema also support hevc playback, however it doesn't depend on filters.

Tsmuxer also handle hevc and output could be m2ts or others.

[jdobbs]

Media player classic home cinema also support hevc playback, however it doesn't depend on filters.

Tsmuxer also handle hevc and output could be m2ts or others.Hmm... I'll have to try the Directshow filter I'm using, but I don't think has the ability to demux from M2TS. Of course that wouldn't prevent another type of playback... but for now I'll probably limit it to MKV.

[HWK]

Hmm... I'll have to try the Directshow filter I'm using, but I don't think has the ability to demux from M2TS. Of course that wouldn't prevent another type of playback... but for now I'll probably limit it to MKV.

Yes, it can. I recently ran test just for you.

[daberti]

I assume you are using Directshow? Maybe it was interrupted during the split. Try it again, from scratch with MULTIPROCESS=2 (or whatever you were using), and let me know how it comes out.

I'm trying again.
I'm doing ALTERNATE so Directshow should be used anyway.

1)without MULTIPROCESS
2)with multiprocess=1

Will tell you later.

BTW: H265 in next release? you rule :)

Edit:
Without Multiprocess: same failure if 1080p. If i choose to resize to 720p there is no issue. Mmmmhh..I begin thinking something......so I'm changin a setting to verify my ideas.

Edit
Yes, I was right. JD, you told me that ALTERNATE switches on FFDshow for frame serving even if LAVF is On. Yet something is going wrong.
If I resize to 720p LAVF is disabled and all goes good.
If I use MULTIPROCESS LAVF is disabled at any HD resolution, ditto as above.
If I leave LAVF on and I don't choose DirectShow Frame Serving (leaving LAVF on) the problem arise.

[HWK]

I'm trying again.
I'm doing ALTERNATE so Directshow should be used anyway.

1)without MULTIPROCESS
2)with multiprocess=1

Will tell you later.

BTW: H265 in next release? you rule :)

Hail to Jdobbs :D, seriously this is great step forward. However don't get too confident I did few 1080P sources to H.265 and they take their sweet time.

[daberti]

Hail to Jdobbs :D, seriously this is great step forward. However don't get too confident I did few 1080P sources to H.265 and they take their sweet time.

Yeah, I did some test as well...takes quite some time to encode

[HWK]

Which version of H.265 encoder did you use and what was your source clip?

I am using one located here http://forum.doom9.org/showthread.php?t=168814

[daberti]

Which version of H.265 encoder did you use and what was your source clip?

I am using one located here http://forum.doom9.org/showthread.php?t=168814

The same shipped with Handbrake nightly build HandBrake-svn6391_x86_64-Win_GUI.exe

Source clip was the same I'm encoding these days: No Capre No Glory (BD)

[jdobbs]

I'm trying again.
I'm doing ALTERNATE so Directshow should be used anyway.

1)without MULTIPROCESS
2)with multiprocess=1

Will tell you later.

BTW: H265 in next release? you rule :)

Edit:
Without Multiprocess: same failure if 1080p. If i choose to resize to 720p there is no issue. Mmmmhh..I begin thinking something......so I'm changin a setting to verify my ideas.

Edit
Yes, I was right. JD, you told me that ALTERNATE switches on FFDshow for frame serving even if LAVF is On. Yet something is going wrong.
If I resize to 720p LAVF is disabled and all goes good.
If I use MULTIPROCESS LAVF is disabled at any HD resolution, ditto as above.
If I leave LAVF on and I don't choose DirectShow Frame Serving (leaving LAVF on) the problem arise.Ok. I'll test with LAVF set and output to ALTERNATE. Which ALTERNATE preset did you use? Better yet, post your log on the one that failed.

[soneca]

Cool, this is a great addition to BDRB, but while I do not change my media players, I do not care HEVC.

[Lathe]

It would be a good idea to install a temperature monitoring sw like CoreTemp.
It also has Temperature limiting features.

@JD
I've noticed that with CRF elapsed a certain amount of time the X264 encoding speed greatly improves.
I suspect the first 30% or alike is done before speed increase.
Could you please explain?

Thanks

Thanks! I do have an on board monitor that keeps track of all the temperatures and such. They seem fine; I even stuck a big fan on the side, blowing in on the MOBO and CPU, thinking that might help also. I sure don't know; very odd... I've got the guy who built it though and he is pretty sharp, so I just need to drag it over there. I will do what JD said though and give it a good cleaning.

As far as the speed of encoding goes, it is SO dang weird now. I have absolutely NO idea what changed, but now encodes (using LAVF like I always do) take like twice as long (12 hours instead of 6) I'm pretty sure everything is the same and it LOOKS like I am topping out my CPU while encoding too. Most odd... I even used version 4707 just as a momentary test comparison, just to start it and see how fast it was going, but it appeared to be about the same as the newer version. I can't for the life of me figure out WHAT has changed. Oh well, at least it is getting done, and I guess if I INSIST on using these x264 tweaks (the same ones I've always used on demanding encodes) I'm just gonna hafta live with it taking longer. I can tell immediately that the fps are a lot slower than they were before. I'll play around with it and see if I am indeed missing something. But, I AM glad that the program is working and doing an excellent job though!

[daberti]

Ok. I'll test with LAVF set and output to ALTERNATE. Which ALTERNATE preset did you use? Better yet, post your log on the one that failed.

The two logs (the failing one comes first):

[09/12/14] BD Rebuilder v0.48.05 (beta)
[18:21:48] Source: L_UOMO_CHE_FISSA_LE_CAPRE_00000
- Input BD size: 20,18 GB
- Approximate total content: [01:34:03.971]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[18:21:51] PHASE ONE, Encoding
- [18:21:51] Processing: VID_00000 (1 of 1)
- [18:21:51] Extracting A/V streams [VID_00000]
- [18:33:32] Reencoding video [VID_00000]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 135.320 frames
- [18:33:32] Reencoding: VID_00000, Pass 1 of 1
- [19:17:24] Video Encode complete
- [19:17:24] Processing audio tracks
- Track 4352 (ita): Keeping original audio
[19:17:24]PHASE ONE complete
[19:17:24]PHASE TWO - Rebuild Started
- [19:17:24] Building ALTERNATE OUTPUT Structure
[19:18:14] - Encode and Rebuild complete
[19:18:14] JOB: L_UOMO_CHE_FISSA_LE_CAPRE finished.
----------------------
[09/12/14] BD Rebuilder v0.48.05 (beta)
[19:54:59] Source: L_UOMO_CHE_FISSA_LE_CAPRE_00000
- Input BD size: 20,18 GB
- Approximate total content: [01:34:03.971]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[19:55:02] PHASE ONE, Encoding
- [19:55:02] Processing: VID_00000 (1 of 1)
- [19:55:02] Extracting A/V streams [VID_00000]
- [20:07:00] Reencoding video [VID_00000]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 135.320 frames
- [20:07:00] Reencoding: VID_00000, Pass 1 of 1
- [21:18:29] Video Encode complete
- [21:18:29] Processing audio tracks
- Track 4352 (ita): Keeping original audio
[21:18:29]PHASE ONE complete
[21:18:29]PHASE TWO - Rebuild Started
- [21:18:29] Building ALTERNATE OUTPUT Structure
[21:21:23] - Encode and Rebuild complete
[21:21:23] JOB: L_UOMO_CHE_FISSA_LE_CAPRE finished.

*****
Both done at Fastest encoding option, CRF 20, NO Multiprocess.
Feel free to ask further information-

[jdobbs]

Thanks. I'm doing testing now using SSIM to try and determine the relationship between CRF values for each encoder (X264 & X265). There'll also have to be a conversion to H.264 if importing HEVC to make it compatible with BD (at least until they finalize H.265 support)... but I do that now with a DIVX or MPEG-4 sources, so it shouldn't be a big deal. I just have to do it as lossless as possible while keeping a reasonable interim size.Just an update. It looks like X264 and X265's CRF values are very closely aligned. The PSNR is very close for each setting I tested. Close enough that it makes you think it may be the metric used for CRF. That's a good thing -- as I won't have to do any conversions to give consistent results.

Based on my tests, it looks like you will see a reduction in file size of between 31-33% for an identical level of quality when you create a backup MKV using HEVC rather than AVC. That doesn't reach the 50% reduction you see advertised often -- but that's probably because I'm testing at higher quality levels and bitrates (typical of a backup). HEVC would likely get higher reduction levels while maintaing the same quality when it is forced to fit into highly constrained bitrates (like you might see in satellite transmission). Also, I'm using a single source video across all my testing... but I think that's ok for what I'm trying to accomplish.

I'm now doing SSIM tests to see how closely it aligns with PSNR. But SSIM testing is pretty slow...

[Sharc]

You have probably already seen the x264/x265 comparative discussion here (http://forum.doom9.org/showthread.php?p=1689053#post1689053).

[jdobbs]

You have probably already seen the x264/x265 comparative discussion here (http://forum.doom9.org/showthread.php?p=1689053#post1689053).Yeah. But I like to do my own testing. Sometimes people like to report what they want to see as opposed to objective facts. I set pretty strict rules for myself when I do testing of this type. I also tailor my testing for BD-RB and BD backups as opposed to possible other uses.

[HWK]

That doesn't reach the 50% reduction you see advertised often -- but that's probably because I'm testing at higher quality levels and bitrates (typical of a backup). HEVC would likely get higher reduction levels while maintaing the same quality when it is forced to fit into highly constrained bitrates (like you might see in satellite transmission). Also, I'm using a single source video across all my testing... but I think that's ok for what I'm trying to accomplish.



Jdobbs, I think 50 % reduction is theoretical maximum, also hevc compression would truly shine on 4K sources.

[daberti]

Thanks! I do have an on board monitor that keeps track of all the temperatures and such. They seem fine; I even stuck a big fan on the side, blowing in on the MOBO and CPU, thinking that might help also. I sure don't know; very odd... I've got the guy who built it though and he is pretty sharp, so I just need to drag it over there. I will do what JD said though and give it a good cleaning.

As far as the speed of encoding goes, it is SO dang weird now. I have absolutely NO idea what changed, but now encodes (using LAVF like I always do) take like twice as long (12 hours instead of 6) I'm pretty sure everything is the same and it LOOKS like I am topping out my CPU while encoding too. Most odd... I even used version 4707 just as a momentary test comparison, just to start it and see how fast it was going, but it appeared to be about the same as the newer version. I can't for the life of me figure out WHAT has changed. Oh well, at least it is getting done, and I guess if I INSIST on using these x264 tweaks (the same ones I've always used on demanding encodes) I'm just gonna hafta live with it taking longer. I can tell immediately that the fps are a lot slower than they were before. I'll play around with it and see if I am indeed missing something. But, I AM glad that the program is working and doing an excellent job though!

Question: are you sure that Thermal compound is still there between Cpu and its cooler?

Other than this building to ALTERNATE, CRF 20, Better speed, and FFDshow frame serving I scored 1.7x speed than with LAVF. No MULTIPROCESS FYI.

@JD
When your H265 code will be ready it will be time for another donation, as you're doing a heck of a work.

[Lathe]

You weren't, by chance, encoding a DVD import and resizing it, were you? I noticed something odd early today in TSMUXER that could (very rarely, I'd guess) cause it to detect a 480i/29.97 source as 480p/29.97 (it might also happen on 576i/25, but I haven't seen it). That caused an encode failure on a source I tried. Interestingly TSMUXER lists it at 480i -- but sets the MPLS as 480p/29.97 (which is illegal for a BD primary source). I've added a workaround that will be included in the next release of BD-RB.

No, I pretty much never resize anything (unless in rare cases where I'm starting with an out of spec AR or something, but not in this case, it was a full, normal Blu-ray) But, thanks for the information though; good to know.

[Lathe]

Question: are you sure that Thermal compound is still there between Cpu and its cooler?

Other than this building to ALTERNATE, CRF 20, Better speed, and FFDshow frame serving I scored 1.7x speed than with LAVF. No MULTIPROCESS FYI.

@JD
When your H265 code will be ready it will be time for another donation, as you're doing a heck of a work.

Yes, you could very well be right; this has occurred to me before. The way it is acting, despite the additional fan, would likely suggest something heat related.

Thanks for the information about encoding speed; it is indeed quite curious as to the difference in speed now. I'm gonna keep working on it to see if I can figure it out.

[Lathe]

This was interesting. A reply on the basic BDRB guide thread at ClubMice came up and the fellow who updates the guide there said this:

"The latest version as I am writing this post is 0.48.05. I've noticed some different behavior in the program regarding frame-serving. Jdobbs has added a line that can make DirectShowSource the default frame server, and has removed an option to use FFVideoSource that was only in the program for a few editions before being abandoned.

The reason I mention this is that CRF encoding seems to be disabled when using the internal LAV filters for frame serving. You'll need to select DirectShowSource if you intend to make a one pass CRF encoding."

I didn't really quite understand what he was saying about the LAV filters (which I use) Would this have anything at all to do with my slower encoding speeds now as opposed to before...? I DO normally use High Quality, 2 Pass though; it doesn't seem like that would be affected by what he is talking about. Do you suppose that some of my 'Tweaks' are being processed or treated differently than before? These are the standard tweaks that I use when encoding either a rather large and/or a rather demanding Blu-ray:

TWEAK_PASS_TWO=--deblock -1:-1 --psy-rd 1.00:0.20 --me umh --subme 8 --trellis 2 --direct auto --qcomp 0.50 --b-adapt 2

Again, in the past when incorporating these same tweaks and primary settings with just about any Blu-ray, the 2nd pass would normally take around 6-7 hours. Now it takes 11-12 (BTW, your HQ setting I believe already sets the me & subme at these values if I'm not mistaken - at 'Highest' it sets the subme at 9 which is indeed overkill and did take forever, but these specific tweaks never really added that much time before)

[Sharc]

TWEAK_PASS_TWO=--deblock -1:-1 --psy-rd 1.00:0.20 --me umh --subme 8 --trellis 2 --direct auto --qcomp 0.50 --b-adapt 2

- Post your lastcmd.txt
- Why tweak like this? You risk to spoil pass 1 by forcing conflicting settings in pass 2. Leave --trellis 2 and --direct auto and --qcomp 0.50 and --b-adapt 2 away, or better just select Auto-quality and see what you gain in speed, and tell us the difference in quality.

[Lathe]

- Post your lastcmd.txt
- Why tweak like this? You risk to spoil pass 1 by forcing conflicting settings in pass 2. Leave --trellis 2 and --direct auto and --qcomp 0.50 and --b-adapt 2 away, or better just select Auto-quality and see what you gain in speed, and tell us the difference in quality.

Yeah, I was thinking that I probably should just leave it with maybe tune--film. I'm pretty sure that with Auto-quality it would indeed be a lot faster. But, even with that said, still... it IS kind of weird that before this WITH these tweaks, the encode times were ALWAYS considerably shorter (about half) So, I figured at THAT time that it didn't really take that much longer, so I'd throw them in. Now, it doesn't seem to be the case and it takes twice as long. But, you could very well be right and I probably should leave it on Auto or just tune--film (I do want the Deblock though to sharpen the picture as per 'Film' settings and I DO kind of like the filmlike Psychovisual bump too - neither of these are ever activated in BDRB, and neither is Trellis) Also, from what I've READ, the qcomp 0.50 contributes to a slightly sharper picture too, but I'm just going by what Selur, the guy who created HYBRID said about his settings. I'm certainly NOT an expert, by any means!

When you say 'Conflicting settings', isn't adding Tweaks merely choosing stronger settings for the final 2nd pass than would normally be determined by a first pass based upon an Auto or lesser setting? In other words, aren't you just 'Telling' x264 to use those higher settings rather than relying on what it's first pass 'Determines' based upon the Auto or a lighter setting? Is there really a 'Conflict'? I'm still VERY green at this, so I'm probably just missing something important here, but just going by what I've learned so far, that is how I understand it.

FWIW, the encodes that I've been doing have turned out breathtakingly beautiful! The delineation and the depth of field especially in long shots or dark shots is pretty amazing. But, perhaps I would get that anyway with Auto :)

Oh, I'll check my last command txt too next time I do an encode.

BTW, it appears that perhaps my major PC issue may indeed be heat related; I'm working on that now. Thanks for the suggestions!

[jdobbs]

Just an update. It looks like X264 and X265's CRF values are very closely aligned. The PSNR is very close for each setting I tested. Close enough that it makes you think it may be the metric used for CRF. That's a good thing -- as I won't have to do any conversions to give consistent results.

Based on my tests, it looks like you will see a reduction in file size of between 31-33% for an identical level of quality when you create a backup MKV using HEVC rather than AVC. That doesn't reach the 50% reduction you see advertised often -- but that's probably because I'm testing at higher quality levels and bitrates (typical of a backup). HEVC would likely get higher reduction levels while maintaing the same quality when it is forced to fit into highly constrained bitrates (like you might see in satellite transmission). Also, I'm using a single source video across all my testing... but I think that's ok for what I'm trying to accomplish.

I'm now doing SSIM tests to see how closely it aligns with PSNR. But SSIM testing is pretty slow...Finished the SSIM testing... it pretty much just mirrored what I saw in PSNR. I'm now making updates to the ALTERNATE routines to support HEVC and implementing the encoding. After that I'll have to make some changes to the Video Import area to support importing the MKVs created.

[HWK]

I am assuming jdobbs at this stage it gone be only MKV.

On a side note I am thinking when time comes you will be able to offer 4K bluray support since tsmuxer already works with 4K and hevc.

May I ask which hevc encoder you are using and build if possible.

[Sharc]

Is there really a 'Conflict'? I'm still VERY green at this, so I'm probably just missing something important here, but just going by what I've learned so far, that is how I understand it.

You can't wildly play with special settings for pass 2. Some are ok, others must be identical to pass 1. Let BD-RB do it's job without any "smart tweaks" which will disqualify for a BD-RB bug report -- see jdobb's statement in this respect.

[jdobbs]

I am assuming jdobbs at this stage it gone be only MKV.

On a side note I am thinking when time comes you will be able to offer 4K bluray support since tsmuxer already works with 4K and hevc.

May I ask which hevc encoder you are using and build if possible.X265. There are daily builds, so I just grab one every now and then.

Yeah, I'm hoping to get ahead of the power-curve on 4K bluray (and HEVC at HD res). Right now I'm just implementing MKV support.

[daberti]

X265. There are daily builds, so I just grab one every now and then.

Yeah, I'm hoping to get ahead of the power-curve on 4K bluray (and HEVC at HD res). Right now I'm just implementing MKV support.

You're already doing a very good job...take your time JD :)

[worknstiff]

RE: Yeah, I'm hoping to get ahead of the power-curve on 4K bluray (and HEVC at HD res).

I think they are going to have to make some bigger bluray's for 3D @ 4K + dolby atmos, lol.

[jdobbs]

RE: Yeah, I'm hoping to get ahead of the power-curve on 4K bluray (and HEVC at HD res).

I think they are going to have to make some bigger bluray's for 3D @ 4K + dolby atmos, lol. I'm sure at some point you'll see BD-XL with 100GB become more common. I'm using a BDXL-RE now and it's pretty handy having that much storage on a single disc.

[Lathe]

You can't wildly play with special settings for pass 2. Some are ok, others must be identical to pass 1. Let BD-RB do it's job without any "smart tweaks" which will disqualify for a BD-RB bug report -- see jdobb's statement in this respect.

Okidoke. No more stray 'Tweak'n' reports here then :)

[jdobbs]

Hmm... I'll have to try the Directshow filter I'm using, but I don't think has the ability to demux from M2TS. Of course that wouldn't prevent another type of playback... but for now I'll probably limit it to MKV.

Yes, it can. I recently ran test just for you.I tried it. I muxed a H265 M2TS with TSMUXER and then tried to view it in Media Player Classic using the directshow filter. It crashed MPC. What player are you using?