View Full Version : BD Rebuilder Beta - Bug Reports Only
HWK
15th September 2014, 02:06
I am using media player classic home cinema.
Also can you send sample file which crash, I will try to play and see if there something I can do.
Sent from my SM-G900W8 using Tapatalk
jedihyte
15th September 2014, 03:24
So I tried this twice to make sure something did not happen the 1st time, but it did it the second encode as well. I tried to make a Full-Backup BD-25 encode on auto settings of the 3D disc of Coraline. After the encode, I burn the ISO to a BD-R and play it on my LG blu-ray player. It actually locks up the player, and I have to unplug the power on the player to get the disc to eject. If I play the ISO on PowerDVD, it will play the Universal picture intro, then it goes to another Universal animation. This animation just loops for hour and 30 min. If you play the original disc a menu comes up asking you what language you want, and after you choose the language it goes on to the Main Coraline 3D menu. I can play the M2TS file of the movie that gets encoded- so BD Rebuilder is rebuilding the movie fine, but for some reason after the encode, this language menu does not trigger and you can’t continue on to play the movie.
- Approximate total content: [01:44:31.640]
- Target BD size: 22.95 GB
- Windows Version: 6.2 [9200]
- Quality: Good (Very Fast), ABR
- MVC 3D Output Mode enabled
- Decoding/Frame serving: FRIMDecode
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[11:29:55] PHASE ONE, Encoding
- [11:29:55] Processing: VID_00001 (1 of 1)
- [11:29:55] Extracting A/V streams [VID_00001]
- [11:40:41] Reencoding video [VID_00001]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 144,677 frames
- Bitrate: 25,198 Kbs
- Using FRIMEncoder for MVC encoding
- [11:40:41] Reencoding: VID_00001, Pass 1 of 1
- [18:13:07] Video Encode complete
- [18:13:07] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [18:13:07] Multiplexing M2TS
- [18:24:38] Scanning for 3D CLPI info...
[18:30:46]PHASE ONE complete
[18:30:46]PHASE TWO - Rebuild Started
- [18:30:46] Converting SSIF file references
- [18:32:03] Rebuilding BD-3D file Structure
[18:32:22] - Encode and Rebuild complete
[18:32:22] Writing BD structure to ISO file
- ImgBurn completed successfully
- CORALINE_3D_BUNDLE folder removed.
- WORKFILES folder removed.
[18:42:15] JOB: CORALINE_3D_BUNDLE finished.
daberti
15th September 2014, 10:38
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?
JD, why don't you use VLC with H265 plugin from here?
https://github.com/strukturag/vlc-2.1/releases/tag/2.1.4-libde265-3
Download a ZIP version than search for the H265 plugin and just move it into the proper plugin\codec dir of normal vlc player
Sharc
15th September 2014, 11:43
MPC-HC seems to work well here with x265 / .mkv encodes.
It's a 2-minutes short test video which has been encoded with x265 1.3+145-44cb33846e0e:[Windows][GCC 4.8.2][64 bit].
I didn't test with files of long duration though.
jdobbs
15th September 2014, 13:57
JD, why don't you use VLC with H265 plugin from here?
https://github.com/strukturag/vlc-2.1/releases/tag/2.1.4-libde265-3
Download a ZIP version than search for the H265 plugin and just move it into the proper plugin\codec dir of normal vlc playerI don't want to create something that applies to a single player... I want it to work through directshow so it works with anything that supports it.
jdobbs
15th September 2014, 13:59
MPC-HC seems to work well here with x265 / .mkv encodes.
It's a 2-minutes short test video which has been encoded with x265 1.3+145-44cb33846e0e:[Windows][GCC 4.8.2][64 bit].
I didn't test with files of long duration though.I'm having no problem with MKV. I've done lots of those. It's only M2TS files that make it crash. I'm think it's because there is no M2TS demuxer as a part of the directshow plug-in, but I can't say for sure.
It really doesn't matter -- BD-RB doesn't do ALTERNATE muxes to M2TS anyway. It was just a part of some testing I was doing. The important thing is that it can be used with AVISYNTH so a backup to MKV can be reencoded into a BD later.
jdobbs
15th September 2014, 14:13
I am using media player classic home cinema.
Also can you send sample file which crash, I will try to play and see if there something I can do.
Sent from my SM-G900W8 using TapatalkHow are you feeding AVISYNTH input to x265 for encoding? I'm using AVS2YUV for frame serving via stdin. I seem to be getting a lot of failures... but oddly all I have to do is restart the encode and it will finish. Weird.
I'll do some testing with avs4x265 later today.
daberti
15th September 2014, 17:22
I don't want to create something that applies to a single player... I want it to work through directshow so it works with anything that supports it.
I misunderstood your original post.
I thought you were looking for an H265 capable player .
HWK
15th September 2014, 19:27
Jdobbs, I am feeding raw files to encoder and will try other method as well.
Sent from my SM-G900W8 using Tapatalk
Sharc
16th September 2014, 07:54
How are you feeding AVISYNTH input to x265 for encoding? I'm using AVS2YUV for frame serving via stdin. I seem to be getting a lot of failures... but oddly all I have to do is restart the encode and it will finish. Weird.
For my tests I do like
- indexing the demuxed videofile (.264) with DGindexNV.exe
- feeding to x265 via avs4x265.exe
Commandline like:
"C:\...path_to...\avs4x265.exe" --x265-binary "C:\...path_to...\x265.exe" --crf 20 --preset fast --output "C:\...path_to...\test_out.mkv" "C:\...path_to...\testscript.avs"
[Added:]
Stepping through the various --preset (ultrafast ... slow) and keeping --crf fixed (20) I noticed that the filesize is continually growing from 62 to 82 MB for my 1 minute testclip. The source video filesize is 130 MB.
Speed drops from 7 fps to 1 fps on my system.
jdobbs
16th September 2014, 15:32
For my tests I do like
- indexing the demuxed videofile (.264) with DGindexNV.exe
- feeding to x265 via avs4x265.exe
Commandline like:
"C:\...path_to...\avs4x265.exe" --x265-binary "C:\...path_to...\x265.exe" --crf 20 --preset fast --output "C:\...path_to...\test_out.mkv" "C:\...path_to...\testscript.avs"
[Added:]
Stepping through the various --preset (ultrafast ... slow) and keeping --crf fixed (20) I noticed that the filesize is continually growing from 62 to 82 MB for my 1 minute testclip. The source video filesize is 130 MB.
Speed drops from 7 fps to 1 fps on my system.I gave avs4x264 a go... but I don't like the fact that it gives no status feedback. If the filesize wasn't growing you'd just think it had frozen.
I got AVS2YUV to work correctly. The problem was in my code, not theirs.
Sharc
16th September 2014, 17:16
I gave avs4x264 a go... but I don't like the fact that it gives no status feedback. If the filesize wasn't growing you'd just think it had frozen.
I got AVS2YUV to work correctly. The problem was in my code, not theirs.
Good to know it's working now.
As for avs4x265 the status & progress & encoder settings are displayed in the commandline window.
daberti
16th September 2014, 17:27
@Sharc
H265 (x265) encoding (DirectShow frame server) can be made also via MeGui
jdobbs
16th September 2014, 19:34
Good to know it's working now.
As for avs4x265 the status & progress & encoder settings are displayed in the commandline window.Hmmm... all I saw was the command itself in the window caption area. I didn't see any status at all, or another window for that matter.
mparade
16th September 2014, 19:41
Do you know if x265 has an MVC support with CRF encoding option? That would be, I think, a great step forward.
HWK
16th September 2014, 21:20
No it doesn't support mvc codec
Sent from my SM-G900W8 using Tapatalk
Sharc
16th September 2014, 23:59
Hmmm... all I saw was the command itself in the window caption area. I didn't see any status at all, or another window for that matter.
This is what I am getting:
c:\Program Files Video\x265 testbed>"C:\Program Files Video\x265 testbed\avs4x26
5.exe" --x265-binary ".\x265.exe" --crf 20 --preset superfast --output "c:\Prog
ram Files Video\x265 testbed\panama.mkv" "c:\Program Files Video\x265 testbed\pa
nama.avs"
yuv [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.3+185-2fb61cc75152
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x265 [info]: WPP streams / pool / frames : 69 / 4 / 2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: CU size : 32
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 44 / 1 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 0.0 / 0
x265 [info]: tools: cfm esd rd=2 lft sao-lcu signhide fast-intra
[31.5%] 506/1608 frames, 5.18 fps, 6585.11 kb/s, eta 0:03:32
jdobbs
17th September 2014, 00:31
Hmmm... I didn't even think X265 supported output to MKV... I'll try it again.
Sharc
17th September 2014, 07:40
Hmmm... I didn't even think X265 supported output to MKV... I'll try it again.
Make sure to using the latest version of avs4x265 (http://kurtnoise.free.fr/x265/)(v0.5). Old versions do not output all the info.
sneaker_ger
17th September 2014, 07:51
Just because you can set the output file name extension to ".mkv" does not mean the x265cli will actually output an mkv file.
Sharc
17th September 2014, 08:13
Good point. Yes, it's still a raw HEVC bitstream.
Sharc
17th September 2014, 09:46
@jdobbs
See sneaker_ger's note. It's better to use for example .265 as extension rather than .mkv which is misleading; sorry.
My tests with muxing:
- Muxing the .265 video+DTS audio to .mkv using mkvmerge works
- Muxing the .265 video+DTS audio to .m2ts using tsMuxeR works here as well. No crashes so far....
TheEthic
17th September 2014, 11:42
Greetings and a great day!
For years and used BDRebuilder and all good so far, the problem is in the menu of the series in this case The Originals, Helix ...
Works:
Sound / Buttons / Select the audio and subtitles, etc.
That does not work:
The image or video menu background.
For some reason it makes black (gray in some cases)
All BD works perfectly, except for the image or video menu background.
I put all the clips in blank, and I make sure not to leave blank the menu, but I do what makes me do the same on black background menu.
Here my settings:
[Options]
VERSION=0.48.0.5
ENCODER=0
MODE=1
ENABLE_TEST=1
ENCODE_QUALITY=4
ONEPASS_ENCODING=0
AUTO_QUALITY=0
QUICK_EXTRAS=1
TARGET_SIZE=23500
AUTO_BURN=2
AUDIO_TO_KEEP=eng;spa;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
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=1
DECODER=0
AVCHD=1
REMOVE_WORKFILES=1
REMOVE_OUTPUT=1
USE_FILTERS=0
BDMV_CERT_ONLY=1
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=23500
ENABLE_BLANKING=1
Thanks.!
jdobbs
17th September 2014, 14:51
@TheEthic
Your post is in violation of Rule #6. The source path in your post clearly indicates illegally obtained content. Further discussion of this matter will result in strikes and possible loss of access to this forum.
jdobbs
17th September 2014, 15:09
@jdobbs
See sneaker_ger's note. It's better to use for example .265 as extension rather than .mkv which is misleading; sorry.
My tests with muxing:
- Muxing the .265 video+DTS audio to .mkv using mkvmerge works
- Muxing the .265 video+DTS audio to .m2ts using tsMuxeR works here as well. No crashes so far....I didn't get any crashes in the muxing, or in playing the resulting MKV file. I got crashes when trying to play an M2TS file (created by TSMUXER) back via directshow using libde265 (even though it has an option to support splitting of MPEG-TS formats). It also crashes if I try to read it using an AVS via DirectshowSource().
jdobbs
17th September 2014, 21:48
Wow. I'm very impressed with HEVC encoding using X265. It's incredible at low bitrates. I just did a short 1920x1080 computer animated cartoon with the bitrate set to 800kbs for the video just for the heck of it... I can't believe how good it looks. :eek:
Sharc
17th September 2014, 22:17
Wow. I'm very impressed with HEVC encoding using X265. It's incredible at low bitrates. I just did a short 1920x1080 computer animated cartoon with the bitrate set to 800kbs for the video just for the heck of it... I can't believe how good it looks. :eek:
What is your player now? MPC-HC with internal LAV works well here for .mkv and .m2ts).
Any special encoder settings used, or just one of the --presets?
Even "normal" 1920x1080 movies look quite good at bitrates as low as about 1100 kbps with --preset faster. Perhaps some loss of details, but nobody here complained in first quick blind tests at reasonable viewing distance..... :cool:
omegaman7
17th September 2014, 22:40
I've always known that X264 could compress anime to fairly low bitrates, given the simple color space nature of cartoons/cgi. But THAT is impressive JD. Can't wait til X265 is more mainstream ;)
TheEthic
17th September 2014, 23:54
@TheEthic
Your post is in violation of Rule #6. The source path in your post clearly indicates illegally obtained content. Further discussion of this matter will result in strikes and possible loss of access to this forum.
Ops my fault. I did not realize that ... I already edited. And I put the question again and thanks for the help.!
the problem is in the menu of the series in this case The Originals, Helix ...
Works:
Sound / Buttons / Select the audio and subtitles, etc.
That does not work:
The image or video menu background.
For some reason it makes black (gray in some cases)
All BD works perfectly, except for the image or video menu background.
I put all the clips in blank, and I make sure not to leave blank the menu, but I do what makes me do the same on black background menu.
Here my settings:
[Options]
VERSION=0.48.0.5
ENCODER=0
MODE=1
ENABLE_TEST=1
ENCODE_QUALITY=4
ONEPASS_ENCODING=0
AUTO_QUALITY=0
QUICK_EXTRAS=1
TARGET_SIZE=23500
AUTO_BURN=2
AUDIO_TO_KEEP=eng;spa;
SUBS_TO_KEEP=all
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
RESIZE_1440=0
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=1
DECODER=0
AVCHD=1
REMOVE_WORKFILES=1
REMOVE_OUTPUT=1
USE_FILTERS=0
BDMV_CERT_ONLY=1
IVTC_PULLDOWN=0
ASSUME_DVD_PAL=0
FRIMSOURCE=0
COMPLETION_BEEP=0
OUTPUT_SBS=0
NEROAAC=0
SUPTITLE=0
AUDIO_TRACK_LIMIT=0
SUBTITLE_TRACK_LIMIT=0
CUSTOM_TARGET_SIZE=23500
ENABLE_BLANKING=1
Thanks.!
HWK
18th September 2014, 00:31
Editing won't do much good by itself, you will require to provide proof that you own it for help. Even though mention original but due to nature of what happened before uploading screenshot that you own would be nice and will make sure forum stay out of trouble.
TheEthic
18th September 2014, 00:44
Editing won't do much good by itself, you will require to provide proof that you own it for help. Even though mention original but due to nature of what happened before uploading screenshot that you own would be nice and will make sure forum stay out of trouble.
Sorry but did not understand your comment ... :confused:
videoh
18th September 2014, 02:22
Sorry but did not understand your comment ... :confused: Se #11 here:
http://forum.doom9.org/announcement.php?a=36
jdobbs
18th September 2014, 02:24
@TheEthic
Your post is in violation of Rule #6. The source path in your post clearly indicates illegally obtained content. Further discussion of this matter will result in strikes and possible loss of access to this forum.What part of "Further discussion of this matter will result in strikes..." did you not understand? Editing your post doesn't change the fact that you are obviously attempting to copy illegally obtained content. By attempting to edit and continue discussion you have also violated rule #16.
Strike for Rule #6 violation issued. Careful -- you are within one strike of suspension...
HWK
18th September 2014, 03:28
Wow. I'm very impressed with HEVC encoding using X265. It's incredible at low bitrates. I just did a short 1920x1080 computer animated cartoon with the bitrate set to 800kbs for the video just for the heck of it... I can't believe how good it looks. :eek:
Jdobbs, did you get chance to try something else other than animation. Also what preset you are using most of the time.
I am currently doing saving private ryan to test efficiency.
Sent from my SM-G900W8 using Tapatalk
Sharc
18th September 2014, 08:38
For my smartphone I am getting very pleasant results for 1280x720, --crf 27 (approx 1200 kbps), --preset fast, at affordable encoding speed of 12fps thanks to the lower resolution.
jdobbs
18th September 2014, 12:54
Jdobbs, did you get chance to try something else other than animation. Also what preset you are using most of the time.
I am currently doing saving private ryan to test efficiency.
Sent from my SM-G900W8 using Tapatalk
I was just seeing how it looked at low bitrates. I'm still doing testing and will try some other sources.
I used BD-RB's "High Quality" -- which translates to X265's preset "medium". For now I've set the default bitrate in BD-RB's ALTERNATE window for HEVC to 2000 Kbs for video. But, of course, that can be changed in the ALTERNATE.TXT file.
HWK
18th September 2014, 16:02
Are you using default setting for x265 or something different.
I am not sure if it happens with your source or not, if you try to seek forward or backward picture get corrupted until next IDR frame.
I just finished saving private ryan and noticed video need at least ABR 3000+ to achieve good quality on that particular source.
I am gone try two pass next.
Sharc
18th September 2014, 16:43
Are you using default setting for x265 or something different.
I just finished saving private ryan and noticed video need at least ABR 3000+ to achieve good quality on that particular source.
For which settings / preset / resolution?
Did you compare with x264? I would assume you would need about 4000+ kbps for similar quality, but probably about 3 times faster encoding speed....
HWK
18th September 2014, 17:15
I am using preset medium with resolution 1920*1080 and getting 15 fps during encode. However choosing preset slow (which is next available option after medium speed goes to 6 fps)
Major difference I noticed motion estimation goes from hex to star and result in lower speed. If I chose uneven multihex I get 13 fps on same source and result in better quality.
I am still tweaking and see how it goes, currently doing two pass encode and will keep posted.
sonate
18th September 2014, 17:33
I've always known that X264 could compress anime to fairly low bitrates, given the simple color space nature of cartoons/cgi. But THAT is impressive JD. Can't wait til X265 is more mainstream ;)
For sure it's coming soon. http://www.blu-ray.com/news/?id=14923
So now it's time for some of us to upgrade again? I have to admit that Hi-Def has made a huge difference to my viewing pleasure and what it does especially for some of the early B&W such as Cocteau's Beauty and the Beast is as grand as what it does for modern cinema. But for instance with Blade Runner, an all time favorite, I have already bought that movie five times in various formats. But I think at this point, unless the motion pix industry is willing to let me trade in my previous versions for the latest 4k holy grail, it's time I stop supporting them.
Fortunately I believe I can still obtain much satisfaction from HD and the many SD DVD's which have not yet been transferred to HD, and those are many. If per chance I feel as if I'm cheating myself out of the fruits of technology, I'll just remind myself that not too long ago I was watching VHS.
Sharc
18th September 2014, 18:08
I am using preset medium with resolution 1920*1080 and getting 15 fps during encode. However choosing preset slow (which is next available option after medium speed goes to 6 fps)
Major difference I noticed motion estimation goes from hex to star and result in lower speed. If I chose uneven multihex I get 13 fps on same source and result in better quality.
I am still tweaking and see how it goes, currently doing two pass encode and will keep posted.
I have been using preset faster which is almost twice as fast as medium; and the quality deterioration was very minor. This impression may depend on the source and PC monitor though.
omegaman7
18th September 2014, 18:41
1080p is certainly adequate for me, presently. But I'll likely be in the market during tax time, for a 3D display. Might as well get a 4K display at the same time ;) I'm probably also upgrading my Nvidia GPU. I believe my encodes would benefit from it ;)
sonate
18th September 2014, 19:35
1080p is certainly adequate for me, presently. But I'll likely be in the market during tax time, for a 3D display. Might as well get a 4K display at the same time ;) I'm probably also upgrading my Nvidia GPU. I believe my encodes would benefit from it ;)
I'm sure it will be nice and wish you the most enjoyment pleasure. I just spent 36K on a complete rebuild for my piano and another 20K for stone walls to terrace my house which is on a fairly steep hill. So not much money left at the moment.
When flat screens first emerged, I was skeptical about the longevity of the backlights and LCD array but they have proven to last far longer then the time many people actually keep them. Far more advanced replacements cost significantly less it seems, so you practically have to give the used outdated one away or trash it.
jdobbs
18th September 2014, 20:01
Are you using default setting for x265 or something different.
I am not sure if it happens with your source or not, if you try to seek forward or backward picture get corrupted until next IDR frame.
I just finished saving private ryan and noticed video need at least ABR 3000+ to achieve good quality on that particular source.
I am gone try two pass next.What measure are you using to determine quality? I don't think you can use subjective measurements like "good quality". I'd recommend PSNR. I think you'll find that a bitrate of 2000 Kbs with preset medium will give you approximately the same PSNR value as CRF 23 (in x264 or x265). CRF 23 is generally considered to be very good quality.
I haven't seen any seeking issues yet. Using MPC has some delays when I seek, though. MPC-HC works perfectly.
If you want to compare it and see what gets a similar quality level to x264 at a given bitrate, you need to do a PSNR comparison on both of them. When the value is close -- then the bitrates are comparable.
I'm still doing testing, though.
HWK
18th September 2014, 20:12
Okay, I will do PSNR test soon, did you get to try 4K source?
jdobbs
18th September 2014, 21:50
Okay, I will do PSNR test soon, did you get to try 4K source?No I haven't tried 4k. I did do some testing with Full-SBS 3D though.
The problem I have now is that I can't use DirectshowSource() to read from an HEVC M2TS so I can reencode after an import, even though it's supposed to work with libde265... I get a crash.
Sharc
18th September 2014, 22:33
If you want to compare it and see what gets a similar quality level to x264 at a given bitrate, you need to do a PSNR comparison on both of them. When the value is close -- then the bitrates are comparable.
Do you need to force --aq-mode 0 for PSNR comparisons being valid? If so, doesn't this take any psy enhancements out of the equation?
jdobbs
19th September 2014, 00:03
Do you need to force --aq-mode 0 for PSNR comparisons being valid? If so, doesn't this take any psy enhancements out of the equation?There's something you could find wrong with any metric... but I think PSNR is the best choice. SSIM might be a little better -- but it takes longer and, in my experience, gives pretty much the same results as PSNR.
I wouldn't modify any settings for testing -- you should use the ones you use most often. That's the only true test.
soneca
19th September 2014, 00:41
I know, aq mode can not be used with PSNR.
A test with computer animated cartoon.
x265 - preset slow - crf 22 - 1229.71 kb/s > psnr = 47.847
x264 - preset slow - crf 18 - 2759.39 kb/s > psnr = 47.834
In "theory" we have achieved the same quality at half the bitrate. :scared:
I did not know that the X265 had already reached this level.
HWK
19th September 2014, 03:29
The problem I have now is that I can't use DirectshowSource() to read from an HEVC M2TS so I can reencode after an import, even though it's supposed to work with libde265... I get a crash.
Did you try Lav filters and see if it works for you, it has decoder and splitter builtin.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.