View Full Version : BD Rebuilder Beta - Bug Reports Only
DoctorM
12th October 2015, 01:21
The movie is split into three .M2TS files and I'm doing a movie-only encoding.
I started the re-encoding again and it used the x64 version until it got to part 3 then shifted to 32-bit x264 and LAV directshow filter.
I'm still not seeing it change encoders between passes though... now I'm starting to think I was just being crazy.
You're right, it is the same decoder, but apparently there is no hardware decoder available in it. Not a big deal I suppose, it's just something unexpected based on the settings.
jdobbs
12th October 2015, 02:35
That's because the last segment wouldn't have the ATCDelta flag set. Trust me, it's better this way.
DoctorM
12th October 2015, 05:06
That's because the last segment wouldn't have the ATCDelta flag set. Trust me, it's better this way.
Trusted.
dirty211
17th October 2015, 22:33
I have noticed that when an MKV containing an Atmos audio stream is imported into BD Rebuilder the Atmos stream is not available when you go to encode or burn it. It seems that it defaults to the core or second audio stream. Not sure if this is a bug or just designed that way. I couldn't find any info on this in the thread so I thought Id share it here.
Ch3vr0n
17th October 2015, 22:54
BDRB is standard compliant, atmos is NOT part of the official BD standard. It's an extension/add-on to it. It's neither a bug nor designed that way. Jdobbs may choose to add support but that's up to him. It you want to keep the audio or an atmos track you will need to keep HD audio intact for that specific movie.
Verstuurd vanaf mijn Nexus 7 met Tapatalk
dirty211
17th October 2015, 23:18
Understood. I know that BDRB handles Atmos well when encoding a full disc encode thru standard bluray structure folder and the end result is a compressed bd25 with Atmos intact. I just noticed it wasn't available when importing MKV and trying to convert to BD folder structure. Jdobbs does a fantastic job with BDRB and I will continue to support whether he adds it or not.
jdobbs
18th October 2015, 15:23
Understood. I know that BDRB handles Atmos well when encoding a full disc encode thru standard bluray structure folder and the end result is a compressed bd25 with Atmos intact. I just noticed it wasn't available when importing MKV and trying to convert to BD folder structure. Jdobbs does a fantastic job with BDRB and I will continue to support whether he adds it or not.The problem is, that since it isn't a part of the standard -- there is no documentation as to how you would actually activate it in movie-only BD backup.
bjones
18th October 2015, 15:32
It tells me my system has a custom driver and I have to update from the manufacturer. Oh well.
jdobbs, you should still be able to use the Intel driver, the custom ones by the mfg aren't usually kept up to date once they've moved on to the next model.. and they just sometimes have some extra options but definitely not worth staying behind rev for.
I did have problems updating to the intel driver when it added in Win 10 support in the Spring and had to revert back to the last one that was built for win 7/8.1. It may be fixed in the latest one. I haven't checked.
your processor has a HD4400 in it so you should be able to use the same one I do for my HD4600 on Win7sp1x64 - its the win64_153619 file version for driver ver 4170
link -
https://downloadcenter.intel.com/download/24870/Intel-Iris-Iris-Pro-and-HD-Graphics-Driver-for-Windows-7-8-8-1-64bit
BJ
Starfiresg1
18th October 2015, 16:31
I recently did a movie only encode with the option to resize to 1440x1080. The output has a wrong aspect ratio of 4:3 instead of 16:9. The source was 1920x1080 MPEG-4.
What I noticed was that it used the x64-Version of x264 even through I've it set to use DirectShow instead of x264's internal LAV.
I took a look at last_cmd while trying to find the problem:
"G:\Program Files (x86)\BD-Rebuilder\tools\x264-64.exe" "H:\BDMV\STREAM\00005.m2ts" --preset medium --bluray-compat
--demuxer lavf --fps 24000/1001 --no-interlaced --video-filter resize:width=1440,height=1080,sar=1:1,method=bilinear
--b-pyramid none --weightp 1 --qpmin=0 --bitrate 3463 --level 4.0 --qpfile "K:\BR-TEMP\WORKFILES\VID_00005.CHP" --sar 4:3
--aud --nal-hrd vbr --pic-struct --vbv-bufsize 13000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 15000
--threads auto --thread-input --stats "K:\BR-TEMP\WORKFILES\00005.m2ts.264.stats" --pass 1 --output NUL
I think the "sar=1:1" in the resize-filter takes precedence over the "--sar 4:3" in the command line here and causes the wrong AR in the final output?
Log:
[10.18.15] BD Rebuilder v0.50.11
[14:10:32] Source: VAMPIRE_00002
- Input BD size: 21,13 GB
- Approximate total content: [01:58:28.100]
- Target BD size: 4,36 GB
- Windows Version: 6.2 [9200]
- MOVIE-ONLY mode enabled
- Resize: 1920 to 1440 enabled
- Auto Quality: High Quality (Default), Two Pass
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[14:10:35] PHASE ONE, Encoding
- [14:10:35] Processing: VID_00005 (1 of 2)
- [14:10:35] Extracting A/V streams [VID_00005]
- [14:14:43] Reencoding video [VID_00005]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 170.112 frames
- Convert: 1440x1080, 23,976fps, 170.112 frames
- Bitrate: 3.463 Kbs
- [14:14:43] Reencoding: VID_00005, Pass 1 of 2
- [14:39:51] Reencoding: VID_00005, Pass 2 of 2
- [16:38:48] Video Encode complete
- [16:38:48] Processing audio tracks
- Track 4352 (deu): Reencoding audio to AC3...
- Track 4353 (eng): Reencoding audio to AC3...
- [16:47:32] Processing: VID_00015 (2 of 2)
- [16:47:32] Extracting A/V streams [VID_00015]
- [16:47:38] Reencoding video [VID_00015]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 312 frames
- Convert: 1440x1080, 23,976fps, 312 frames
- [16:47:38] Reencoding: VID_00015, Pass 1 of 1
- [16:47:43] Video Encode complete
[16:47:43]PHASE ONE complete
[16:47:43]PHASE TWO - Rebuild Started
- [16:47:43] Rebuilding AVCHD file Structure
[16:49:22] - Encode and Rebuild complete
[16:49:22] JOB: VAMPIRE finished.
Settings:
[Options]
VERSION=0.50.0.11
ENCODER=0
MODE=3
ENCODE_QUALITY=2
ONEPASS_ENCODING=0
AUTO_QUALITY=1
AUDIO_TO_KEEP=deu;eng;ger;
SUBS_TO_KEEP=deu;eng;ger;
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=1
RESIZE_720=0
DEINTERLACE=1
SD_TO_1080=0
IGNORE_3D=0
CONVERT_WIDE=0
DTS_REENCODE=0
AC3_REENCODE=0
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=0
AUDIO_DRC=0
DECODER=0
AVCHD=1
REMOVE_WORKFILES=0
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=1
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=1
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=21500
FRIM_SW_DECODE=0
FRIM_SW_ENCODE=1
TARGET_SIZE=4469
SHOW_ENCODER=0
MOVIEONLY_TYPE=0
ALTCRF=23
ALT_TARGET=1024
ALTMETHOD=0
ALTAUTOCROP=0
QUICK_PLAY_THRESHOLD=15
MENU_BACKGROUND=G:\Program Files (x86)\BD-Rebuilder\misc\menuback.jpg
IMPORT_THRESHOLD=40
MENU_AUTO_BACKGROUND=1
MENU_AUTO_DVDAUDIO=1
MENU_PLAY_SEQUENTIAL=0
MENU_START_WITH_MENU=1
IMPORT_LIMIT_LANG=1
IMPORT_KEEP_PLAYALL=0
PGSTOSRT=0
[Paths]
SOURCE_PATH=H:\
WORKING_PATH=K:\BR-TEMP\
jdobbs
18th October 2015, 22:33
I think the "sar=1:1" in the resize-filter takes precedence over the "--sar 4:3" in the command line here and causes the wrong AR in the final output? If the source is 1920x1080, then the SAR in the resize should be correct. I'll have to look and see when/how the --sar 4:3 gets inserted, it's been a while since I looked at that code.
Sharc
18th October 2015, 22:48
If the source is 1920x1080, then the SAR in the resize should be correct. I'll have to look and see when/how the --sar 4:3 gets inserted, it's been a while since I looked at that code.
If the source of 1920x1080 for DAR 16:9 is resized to 1440x1080 the --sar must be signalled as 4:3 in order to play it back correctly as 16:9. So it is correct to include --sar 4:3 in the commandline. It must not get overruled by --sar 1:1.
jdobbs
19th October 2015, 14:27
If the source of 1920x1080 for DAR 16:9 is resized to 1440x1080 the --sar must be signalled as 4:3 in order to play it back correctly as 16:9. So it is correct to include --sar 4:3 in the commandline. It must not get overruled by --sar 1:1.You are exactly right. So, I guess I would have to assume the problem is in the playback unit.
I'll do a couple just to be sure.
Starfiresg1
19th October 2015, 19:12
It must not get overruled by --sar 1:1.
I wasn't suggesting changing the --sar settings - I thought that maybe the already present sar=1:1 in the resize parameters was causing an issue. I just restarted the task with encoder output enabled (SHOW_ENCODER=1) and immediately noticed the sar is displayed as 1:1 in the output:
lavf [info]: 1920x1080p 1:1 @ 24/1 fps (cfr)
resize [info]: resizing to 1440x1080
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile High, level 4.0
The resulting output has a display ratio of 4:3 (verified with mediainfo).
When I changed the resize-filter to use a sar of 4:3 (--video-filter resize:width=1440,height=1080,sar=4:3,method=bilinear) the encoder would display a sar of 4:3:
lavf [info]: 1920x1080p 1:1 @ 24/1 fps (cfr)
resize [info]: resizing to 1440x1080
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
The resulting output has a display ratio of 16:9 (verified with mediainfo) and looks correct.
After this i did something crazy and changed the --sar command-line to 20:2 just to see what happens:
lavf [info]: 1920x1080p 1:1 @ 24/1 fps (cfr)
resize [info]: resizing to 1440x1080
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
Again the output has a display ratio of 16:9.
It seems as soon as the resize-filter contains an sar-argument the --sar command-line doesn't do anything?!
Note: I tested this on a short trailer-clip (02:28) from the same disc.
Sharc
19th October 2015, 19:32
It seems to be the internal lavf frame server which overrules the command line --sar 4:3.
I am always using DGDecNV with 32bit x264 and never had a problem with 1440x1080 / 16:9 DAR.
eduardomurilo89
19th October 2015, 21:42
Sorry to bother you guys, but I haven't found anything about the subject, so maybe you can help me. I want to know if there's a way to enable Menu encoding on BDRebuilder, I feel that I'm losing precious space with them not encoded. Thanks in advance!
jdobbs
19th October 2015, 21:50
@Starfiresg1
I'll do some testing and get to the bottom of it.
B737Driver
19th October 2015, 22:36
Sorry to rehash, but Sir jdobbs,
Do you know if there is a way in the FRIM modules to specify the graphics gpu to use for encoding? I know my Win10 system will support it, it just needs some nudging in what to use.
Still trying to get this thing to work in Win10 with Intel Quick Sync.
BTW, sorry you weren't able to get it running on your laptop; the quicksync is a significant capability
Thanks
jdobbs
20th October 2015, 00:02
If you set FRIM_SW_ENCODE=0 and FRIM_SW_DECODE=0 then BD-RB will use the default settings for FRIMEncode -- which is "Automatic". In that mode the quicksync drivers should recognized your processor and work accordingly. Outside of that, there's really not much I can contribute to the functioning. You might want to browse through the FRIMEncode thread (http://forum.doom9.org/showthread.php?t=169651&highlight=frimencode) and see if there is anything else.
B737Driver
21st October 2015, 18:41
Solved my issue with FRIM, Windows 10, and Intel Quicksync.
After a lot of dorking around with FRIM on the command line, I learned this was not a quicksync issue as I would frequently get the error: “cannot get YUV420 frame from input avi-file …”, so iqs never had a chance to start. I finally figured out this is a CODEC issue. I use FFDSHOW and have it setup exactly as prescribed in the initial post for BDRB setup. One thing I added in the Video Decoder Configuration dialog box under Codecs was Raw video | All Supported. But this still didn’t work.
I then downloaded the latest version of x86 ffdshow I could find: v1.3.4533, 20140929. This compiled version of ffdshow adds another configuration box called VFW Configuration; the title on the dialog box once opened is “ffdshow video ENCODER configuration”. FRIMEncode WORKS AFTER SETTING “RAW VIDEO” in this box to “ALL SUPPORTED.”
I then initially had an issue frame serving with DirectShowSource (the encoding would stop and hang around 19% in), so I switched to FRIM serving and it works fine so far on 2 different movies. 2D BluRays recoded to 25 BDR using the High Quality setting averages 150 fps. Without FRIM and IQS I was getting around 16-18 fps.
Hope this helps someone else… worknstiff?? And why did the older ffdshow work fine in Win7x64 and not in Win10x64--I haven't a freakin' clue :)
BTW, thanks, jdobbs, for pointing me to the FRIM forum page—it gave me a lot of ideas for testing that finally led me to the solution.
[edit: for reference, my cpu is an i5-3570K that is almost 3 years old]
Capsbackup
21st October 2015, 21:33
Solved my issue with FRIM, Windows 10, and Intel Quicksync.
I then downloaded the latest version of x86 ffdshow I could find: v1.3.4533, 20140929. This compiled version of ffdshow adds another configuration box called VFW Configuration; the title on the dialog box once opened is “ffdshow video ENCODER configuration”. FRIMEncode WORKS AFTER SETTING “RAW VIDEO” in this box to “ALL SUPPORTED.”
The recommended ffdshow, available on the first page with the other downloads, has this same VFW Configuration too.
jdobbs
21st October 2015, 22:24
Solved my issue with FRIM, Windows 10, and Intel Quicksync.
After a lot of dorking around with FRIM on the command line, I learned this was not a quicksync issue as I would frequently get the error: “cannot get YUV420 frame from input avi-file …”, so iqs never had a chance to start. I finally figured out this is a CODEC issue. I use FFDSHOW and have it setup exactly as prescribed in the initial post for BDRB setup. One thing I added in the Video Decoder Configuration dialog box under Codecs was Raw video | All Supported. But this still didn’t work.
I then downloaded the latest version of x86 ffdshow I could find: v1.3.4533, 20140929. This compiled version of ffdshow adds another configuration box called VFW Configuration; the title on the dialog box once opened is “ffdshow video ENCODER configuration”. FRIMEncode WORKS AFTER SETTING “RAW VIDEO” in this box to “ALL SUPPORTED.”
I then initially had an issue frame serving with DirectShowSource (the encoding would stop and hang around 19% in), so I switched to FRIM serving and it works fine so far on 2 different movies. 2D BluRays recoded to 25 BDR using the High Quality setting averages 150 fps. Without FRIM and IQS I was getting around 16-18 fps.
Hope this helps someone else… worknstiff?? And why did the older ffdshow work fine in Win7x64 and not in Win10x64--I haven't a freakin' clue :)
BTW, thanks, jdobbs, for pointing me to the FRIM forum page—it gave me a lot of ideas for testing that finally led me to the solution.
[edit: for reference, my cpu is an i5-3570K that is almost 3 years old]Had you tried uninstalling and reinstalling FFDSHOW using the recommended version? I just wonder if it was the reinstall that did it rather than the new version.
By the way, when BD-RB runs FRIM it saves the existing RAWV setting, and then sets RAWV to ALL SUPPORTED before it executes the FRIM command line. It then resets it to its original values upon FRIM completion. So changing that setting in the FFDSHOW configuration really has no effect.
eduardomurilo89
22nd October 2015, 01:21
Guys, anything on the menu encoding? Thanks in advance!
jdobbs
22nd October 2015, 04:30
Guys, anything on the menu encoding? Thanks in advance!The size of menus just isn't significant enough to bother -- and the likelihood of issues is greatly increased.
B737Driver
22nd October 2015, 13:32
Had you tried uninstalling and reinstalling FFDSHOW using the recommended version? I just wonder if it was the reinstall that did it rather than the new version.
By the way, when BD-RB runs FRIM it saves the existing RAWV setting, and then sets RAWV to ALL SUPPORTED before it executes the FRIM command line. It then resets it to its original values upon FRIM completion. So changing that setting in the FFDSHOW configuration really has no effect.
In my testing to find the right settings for the Codec, I installed and uninstalled about 3 versions of ffdshow. Before I wrote my experience up to post here yesterday, I uninstalled the version I described as working and reinstalled the recommended one from here to test again. Capsbackup, I could not for the life of me find the same VFW dialog box.
I am just a modest user and don't, at all, presume to know a lot of how all this stuff works. What I do know is in the recommended version I could not find the Encoder settings and BDRB/FRIM no workie. Install this latest version of ffdshow and change the Encoder setting, BDRB/FRIM workie.
I don't care which version I use so long as I can get it to work. [edit: I'm all ears if someone can tell me how to find the VFW config routine in the recommended version; it does not come up in the start menus when I install it]
[edit2: Oh, and remember, I am now running Win10. I don't know what the OS has to do with it, but BDRB/FRIM worked fine in Win7 without finding this extra setting in ffdshow.]
KeVe1983
22nd October 2015, 15:22
Just a stupid question
Can i use Intel Quick Synch for encoding, if i use the internal gpu also as graphic output for my monitor?
I don't have a graphic card in my desktop pc, so i use the intel cpu internal HD4600 graphic for my monitor.
I copied the both lines FRIM_SW_DECODE=0 & FRIM_SW_ENCODE=0 into the .ini file and selected FRIm Source in BDRB Setup, but just get max 15FPS while encoding. Have an i5 4460
Edit: Also a little bug
I'm using BDRB for some years now and this "bug" present from the first time.
If you select german for the language and subtitles to keep in the setup it doesn't work
You have to edit the .ini file and add "deu" to the AUDIO_TO_KEEP and SUBS_TO_KEEP line.
Otherwise German is not selected if you load a Bluray and want the German language to be selected automatically
jdobbs
22nd October 2015, 15:23
[edit2: Oh, and remember, I am now running Win10. I don't know what the OS has to do with it, but BDRB/FRIM worked fine in Win7 without finding this extra setting in ffdshow.]It's possible that Win10 increase security settings and the changes to the registry (done by BD-RB) is now being blocked somehow. I'll have to do some testing on my Win10 machine.
jdobbs
22nd October 2015, 15:26
Just a stupid question
Can i use Intel Quick Synch for encoding, if i use the internal gpu also as graphic output for my monitor?
I don't have a graphic card in my desktop pc, so i use the intel cpu internal HD4600 graphic for my monitor.
I copied the both lines FRIM_SW_DECODE=0 & FRIM_SW_ENCODE=0 into the .ini file and selected FRIm Source in BDRB Setup, but just get max 15FPS while encoding. Have an i5 4460That's similar to what I see on my Intel-video system. I can set those to 0, but the speed doesn't seem to increase at all. If I remember correctly, though, it would cause the encode to fail on my non-Intel machines.
Honestly, though, there are people a LOT more familiar with Quick-Sync than I am -- and they'd probably be more help to you.
Starfiresg1
22nd October 2015, 17:55
I copied the both lines FRIM_SW_DECODE=0 & FRIM_SW_ENCODE=0 into the .ini file and selected FRIm Source in BDRB Setup, but just get max 15FPS while encoding. Have an i5 4460
When I did testing with FRIM-Hardware-Encoding for MVC-encodes (quite a while back) at some point It would only use hardware encoding if I copied libmfxhw32.dll from the Intel Quicksync-Folder ("C:\Program Files\Intel\Media SDK") to the "Tools"-folder of BD-Rebuilder. This used to work previously - probably caused by either an update to FRIM or the Intel Driver. My guess is that older drivers added the Media SDK to the %PATH%-variable - so that the DLL could be used more easily - at present it's not in there and Frim probably doesn't find it.
Edit: Also a little bug
I'm using BDRB for some years now and this "bug" present from the first time.
If you select german for the language and subtitles to keep in the setup it doesn't work
You have to edit the .ini file and add "deu" to the AUDIO_TO_KEEP and SUBS_TO_KEEP line.
Both "German" settings are already in there (deu and ger) - the list is sorted by the codes so they are a few entries apart.
jdobbs
22nd October 2015, 18:44
That's weird. So you're saying "deu" and "ger" are already in the line -- but you have to add it to the end to get it to work? Can you post what your AUDIO_TO_KEEP line looks like?
KeVe1983
22nd October 2015, 19:26
When I did testing with FRIM-Hardware-Encoding for MVC-encodes (quite a while back) at some point It would only use hardware encoding if I copied libmfxhw32.dll from the Intel Quicksync-Folder ("C:\Program Files\Intel\Media SDK") to the "Tools"-folder of BD-Rebuilder. This used to work previously - probably caused by either an update to FRIM or the Intel Driver. My guess is that older drivers added the Media SDK to the %PATH%-variable - so that the DLL could be used more easily - at present it's not in there and Frim probably doesn't find it.
Both "German" settings are already in there (deu and ger) - the list is sorted by the codes so they are a few entries apart.
Thanks for your help
Did not work for me.
Copied the file to the tools folder, but it seems BDRB did not encode with HW.
How can i check if HW is used for encoding?
Updated the Bios and did all settings in BIOS for using the iGPU
But it still seems that BDRB will not use the GPU
That's weird. So you're saying "deu" and "ger" are already in the line -- but you have to add it to the end to get it to work? Can you post what your AUDIO_TO_KEEP line looks like?
My mistake, didn't notice the "deu" checkbox in language setup.
Selected it and now it's working
Starfiresg1
22nd October 2015, 20:43
Thanks for your help
Did not work for me.
Copied the file to the tools folder, but it seems BDRB did not encode with HW.
How can i check if HW is used for encoding?
I just tested it - in order for FRIM to use hardware acceleration I had to rename (or delete) the file libmfxsw32.dll (software library) in the tools folder. FRIM then used the hardware library (libmfxhw32.dll) even if its not copied to the tools folder.
You could add/change the setting SHOW_ENCODER=1 in BDREBUILDER.INI - this will display the decoder windows (FRIM, x264, etc.) during encoding. FRIM will display if it is using software or hardware at the very beginning of the output - maybe you need to scroll up a bit.
Media SDK impl HARDWARE (2) - D3D11 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Note: closing the window will abort the encode - so you should disable it when no longer needed.
jdobbs
22nd October 2015, 20:58
I just tested it - in order for FRIM to use hardware acceleration I had to rename (or delete) the file libmfxsw32.dll (software library) in the tools folder. FRIM then used the hardware library (libmfxhw32.dll) even if its not copied to the tools folder.Interesting. I'm going to try that with my laptop.
[Edit] WOW! That did it for me. My 3D encode went from 8 fps to 68 fps -- and when I tested it, it played back great. GREAT INFORMATION! I'll do more testing, but hopefully all I'll have to do is include libmfxhw32.dll in the tools folder. If that isn't enough, I can always have BD-RB temporarily rename it during encoding. I'm also going to do some testing on 2D encodes.
:goodpost::thanks:
KeVe1983
22nd October 2015, 21:18
This also works for me!
Media SDK impl HARDWARE - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw64.dll)
Media SDK version 1.16
http://abload.de/img/unbenanntf3u2k.png
Got 80-83 FPS @High Quality (Default), ABR
Looks like i can do Gravity 3DBD 50->25 in about an hour
:thanks:
Starfiresg1
22nd October 2015, 21:31
Glad to hear it's working :)
I gave it up quite some time ago after testing because there where visual artifacts in the MVC stream when hardware acceleration was used - AVC was fine however. Haven't tested in a while however - could have been a driver issue ... or as Haswell issue.
Quick note: If you are using Windows 10 don't update
to the latest driver (15.40.7.64.4279) if you use a discrete graphics card. With this one I can only use Quicksync if I have a monitor attached to the internal card (and I also can't add a "fake display" in display settings either). Previous driver (15.40.4.64.4256) was fine as far as I remember.
jdobbs
22nd October 2015, 21:35
From what I can tell, I don't need a hardware DLL. It just works...
KeVe1983
22nd October 2015, 21:36
Using Win7, so no problems here.
Just got a new setup with i5 4460.
I had artefacts in 3D MVC encodes too while using my i3 4330 the last weeks.
But i did not use HW encoding it was a normal SW encode.
Will check it with the new enncode
Edit:
Encode done in 52 minutes
But have artefacts :(
B737Driver
22nd October 2015, 22:16
Glad to hear some others have been able to get QS to work!
It's a shame that such cool hardware capability is not a ubiquitous tool after 3+ years: it takes so many little, and sometimes inconsistent, variables to get it work...
I still have the sw version of the .dll in my bdrb "tools" folder, but the system is definitely running on the hardware version from the sdk folder for me:
Media SDK impl HARDWARE (2) - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version 1.11
I have my motherboard vga plugged into my monitor, but I don't use it...I use the dvi from my NVidia graphics card (selected at the monitor). With this plugged in but unused I get the extended desktop, and the Intel Graphics Utility is actually selectable. BDRB started up and ran fine, but the D3D9 came up as D3D11, it ran slower (~90 fps), and then crashed about 10% into the recode. Plugged the monitor back in and my speeds are about 120-135 fps, and so far it is 53% in and hasn't crashed. Why the hell would that matter????
Bottom line: ton of variables...find the combination that works and enjoy the huge speed increase with unnoticeable quality degradation. Ugh--frustrating! Fortunately, I have found that combo for now...
jdobbs
22nd October 2015, 23:03
I did some testing. If I force the encode to hardware mode (using the -hw switch) instead of allowing for autodetection (the default) then you don't have to rename the libmfxsw32.dll file. I'll make changes to the next release so the -hw switch is forced when FRIM_SW_ENCODE is set to "0".
KeVe1983
23rd October 2015, 06:36
jdobbs any thougts about the artefacts with 3D encodes?
Had issues with my old i3 4330 and now also with the i5 4460
But with my i3 i didn't use HW encoding.
Okay, so if i can see and read here it's an issue with SW Players?!
Using PDVD15 for playback.
So any way to fix this?
Don't wont to burn to optical disc and use hardware player.
Just want to use my HTPC for Playback.
jdobbs
23rd October 2015, 11:20
I've never personally experienced it, but up till now I've always used sw encoding. If it is an issue with the playback unit -- then it is something, I would suspect, that only the playback software could address. I'm not sure what I, or the Intel developers, for that matter, could do about it.
KeVe1983
23rd October 2015, 11:35
This problem was discussed here several times.
It seems to affect all sw players (PDVD, TMT, WinDVD), but on hw players it should run fine.
So i think it has something to do with FRIM!
Full Blurays are running fine in 3D at PDVD.
They just got messed up after encoding.
And i tried a lot of 3D Discs before with mit i3 and without hw encoding.
Have used sw encoding and got the same messed up BD25 encodes with artifacts
jdobbs
23rd October 2015, 15:43
I understand... but the gold standard is hardware players. I can point you to multiple other issues discussed in this forum that exist in software players even though the stream is fully BD compliant (example: in-mux 3D). Frankly, IMHO, the SW players just aren't very good. That's why I generally only respond to problems that have been confirmed on hardware players.
That doesn't mean I wouldn't be open to a workaround to help make it work better in those players -- I've done that dozens of times before. But adding code to circumvent other software's problems is a far throw from actually accepting responsibility for them, and I suspect the FRIM author (and the Intel developers) might feel the same way.
KeVe1983
23rd October 2015, 20:30
Sorry i did not want to attack you, that was just my thought.
You're doing a great job.
Found another interesting thing.
Glitches are only visible on the left side/eye
http://abload.de/thumb/img2015102321115335kr3.jpg (http://abload.de/image.php?img=img2015102321115335kr3.jpg) http://abload.de/thumb/img20151023211147y7k7c.jpg (http://abload.de/image.php?img=img20151023211147y7k7c.jpg)
jdobbs
23rd October 2015, 21:53
No problem. I didn't mean to sound defensive -- I just wanted to express that there's a limit to how much one can do when the problem appears to be elsewhere.
yahknow1
24th October 2015, 19:14
How is BDRebuilder been with Windows 10? I've been thinking about upgrading from Windows 7 Professional and am worried it won't work as well? Thanks for all your work btw Dobbs!
jdobbs
24th October 2015, 23:37
I'm running it on Windows 10 with no issues.
sgrundy
25th October 2015, 11:57
How is BDRebuilder been with Windows 10? I've been thinking about upgrading from Windows 7 Professional and am worried it won't work as well? Thanks for all your work btw Dobbs!Only issue you *might* run in to if you use a NVIDIA card is with LAV filters. If that's the case then make sure CUVID is not selected under hardware acceleration.
EDIT: The problem arises when having SLI enabled, it will cause BD Rebuilder to spit out a file with no video stream just audio. Either disable SLI first or change the hardware acceleration setting as mentioned above. Should have been more clear in the first post.
jdobbs
25th October 2015, 19:14
Only issue you *might* run in to if you use an NVIDIA card is with LAV filters. If that's the case then make sure CUVID is not selected under hardware acceleration.Good to know. I hadn't heard that -- and I'm going to upgrade one of my Win7 machines (with an NVIDIA card) to Win10 soon.
sgrundy
25th October 2015, 19:42
Good to know. I hadn't heard that -- and I'm going to upgrade one of my Win7 machines (with an NVIDIA card) to Win10 soon.It's an SLI / Win 10 problem, updated initial post to reflect that. Whoops.
datman
29th October 2015, 23:27
John Wick seems to have a problem. It jumps around like the multiple vid files are in the wrong order, just a guess.
I did a movie only backup I’ll see if a full reactes any different.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.