Slight stuttering in standalone player

[RobertM]

Hi folks,

Having some slight problems with stuttering in my BD-25 backups. I didn't notice this earlier because my validation process so far has included 3-steps: 1) confirm burn by allowing ImgBurn to verify the resulting disc. 2) Load in standalone BD player and see that it recognizes the disc and starts to play. 3) Step through the chapters (viewing / listening to a few seconds of each) to the end of the disc.

After some initial system setup issues all my backups have passed this test, and I was starting to feel pretty good about the process. But, what with the recent discussion about LTH discs (which I am using), I decided to do a more in-depth evaluation by viewing the entire discs with a critical eye. I noticed a problem.

It looks like I have some slight stutter at various points on each disc. The stutter is brief, affecting only a fraction of a second of video, and it may occur a dozen or so times in a film. Perhaps it is more frequent, but it doesn't show up well if there isn't much panning or motion going on. The stutter happens repeatably at the same points on the disc. I can backup and re-play a stuttering section with the stutter being absolutely identical each time. I can step through the stutter and see it advance a few frames, then backup one, then advance a few more, then backup one, etc., repeating perhaps 4 to 6 times. Interestingly, if I step through backwards I don't see the stutter. I can eject the disc and put it back in after playing other discs and see the same stutter in the same place.

I've tried re-ripping with the latest release of AnyDVD HD (6.8.0.0) and a binary compare with the previous rip shows the files to be identical.

I switched from Verbatim LTH discs to Verbatim standard 6x BD-R discs and the stutter happens at the same spots.

I tried rebuilding with a different quality setting ("Highest" instead of "Good"), and I still get the stutter, but not at the same spots.

Now, I must note that I only see the stutter in my standalone BD player, a brand new Sony BDP-S380. If I play the BD-Rebuilder output files (which were used for the burn) using PowerDVD on my desktop there is no stutter. If I play the burned disc from my BluRay drive in the desktop (LG WS10LS30) there is no stutter. If I play my original discs in the Sony S380 there is no stutter. So it is only the backup discs in the standalone player that cause the trouble.

I've tried plugging the S380 HDMI output into my 1080p desktop monitor instead of my 720p TV. No change.

I tried fiddling with the S380 output settings (force it to 720p instead of "auto"). No change.

Could it be that the S380 just doesn't like BD-R discs? Or just Verbatim discs? Perhaps I should return the Sony (it's only a week old) and try a different brand.

FWIW, my OS is Win 7 Pro 64 bit.

Any thoughts would be appreciated.


Following are my "Inspect.exe" results and the log for the 2 most recent backups at different quality settings.

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

- Windows Version: 6.1 [7601]
- AVISYNTH Version: 2.5.7.0, Ok
- HAALI Splitter: Ok
- FFDSHOW: 3326, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- BD Rebuilder v0.37.0.8, Ok
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok

-----------------------
[23:00:53] BD Rebuilder v0.37.08 (beta)
- Source: QUANTUMOFSOLACE
- Input BD size: 27.03 GB
- Approximate total content: [01:46:14.368]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Auto Quality: Good (Very Fast), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[23:00:56] PHASE ONE, Encoding
- [23:00:56] Extracting A/V streams [VID_00050]
- [23:13:21] Reencoding: VID_00050 (1 of 1)
- [23:13:21] Collecting video information
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 152,832 frames
- Bitrate: 28,003 Kbs
- [23:13:21] Reencoding: VID_00050, Pass 1 of 1
- [00:22:56] Video Encode complete
- [00:22:56] Reencoding audio tracks (if req'd)
- [00:28:18] Multiplexing M2TS
[00:40:13]PHASE ONE complete
[00:40:13]PHASE TWO - Rebuild Started
- [00:40:13] Rebuilding BD file Structure
[00:55:44] - Encode and Rebuild complete
[00:55:45]JOB: QUANTUMOFSOLACE finished.
-----------------------
[14:21:49] BD Rebuilder v0.37.08 (beta)
- Source: QUANTUMOFSOLACE
- Input BD size: 27.03 GB
- Approximate total content: [01:46:14.368]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: Highest (Very Slow), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[14:22:03] PHASE ONE, Encoding
- [14:22:03] Extracting A/V streams [VID_00050]
- [14:35:49] Reencoding: VID_00050 (1 of 1)
- [14:35:49] Collecting video information
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 152,832 frames
- Bitrate: 28,003 Kbs
- [14:35:49] Reencoding: VID_00050, Pass 1 of 1
- [19:49:58] Video Encode complete
- [19:49:58] Reencoding audio tracks (if req'd)
- [19:55:27] Multiplexing M2TS
[20:05:02]PHASE ONE complete
[20:05:02]PHASE TWO - Rebuild Started
- [20:05:02] Rebuilding BD file Structure
[20:17:24] - Encode and Rebuild complete
[20:17:24]JOB: QUANTUMOFSOLACE finished.


Regards,
Bob

[Capsbackup]

Perhaps rather than return your player, take a few of the discs that have this stutter problem to your local retailer and test them on their different model players, including the one you have.
Those results should prove valuable. ;)

[jdobbs]

At those exceptionally high encode bitrates (28,003 Kbs) it may be possible that when combined with audio at the peak bitrate they are exceeding Blu-Ray's maximum or 48Mbs. I'll check my code and see if that is a possibility. I don't think it is -- especially since I set the video maxrate at 35Mbs and you're not keeping HD audio -- but I'll still check.

Is it possible that the disc has a huge number of audio tracks and you're keeping them all?

[RobertM]

Hi guys,

@Caps: Hmm... good suggestion. I'll see if I can find someone willing to let me try out some different machines.

@JDobbs: These are "movie only" backups, retaining only the English audio and English subs. I've tried another iteration, where I selected "good" quality and 2-pass encoding (instead of 1-pass, as in the previous "good" quality backup). Same stutters in the same places on the burned disc. The resulting m2ts file was a slightly different size than my last "good" quality backup, so I know that it wasn't just creating an identical file, but the stutters are in the same places.

Regards,
Bob

[Ghitulescu]

Have you tried a 100% backup (on a BD-RE DL)? That and the tests previously suggested would single out the cause (player, disc, movie or software).

[RobertM]

@Ghitulescu: I bet that a BD-DL would work perfectly, for reasons detailed below.



I'm starting to get a little more clarity about the nature of this stuttering problem, having made a couple of seemingly pertinent observations.

1. The media is not an issue. After wasting a bunch of BD-R discs producing stuttering versions of "Quantum" I had the idea of bypassing the optical stage altogether by substituting an external harddrive. I copied the BD-Rebuilder output folders ("BDMV" and "Certificate") to the external drive then plugged the drive into the front USB port on the Sony BDP-S380. When played that way the video STILL stutters, in EXACTLY the same positions. Then I tried the same thing with input folders (those produced when ripping from my original discs) and they played just fine, with no stutter. So, it would suggest that something is wrong with the m2ts files that are the output of the rebuilding process.

2. I found a couple of backups that didn't exhibit any stutter (watched them through from start to end). In looking for a commonality I found that the size of the m2ts files were smaller than 23GB, and looking at the BD-Rebuilder log I saw that the video files were NOT re-encoded since they were small enough already. Audio WAS re-encoded. As a test, I ran another backup of "Quantum" with a custom size of 35GB so that the video would not be re-encoded. Presto -- the stutters disappear.

So I conclude that something is messing up my video re-encode process. It seems that BD-Reduilder CAN make perfectly fine backups for me -- demux, re-encode audio, remux, author -- so long as the video isn't re-encoded.

I tried doing a small custom size backup (18GB), to drop the data rate -- no improvement.

I tried uninstalling HAALI, FFDSHOW and AVISynth, deleting their folders, uninstall AVS2DVD, uninstall VPL, remove anything else that looked like it might have an impact on installed codecs, reboot, d/l fresh copied using the link on the "bugs" thread, reinstall -- no improvement.

It could still be that the Sony BDP-S380 is particularly sensitive, I suppose, and that another player would be more accepting of theses m2ts files, but it really feels more and more like an encoding issue. I could be wrong, of course.

Now I'm wondering where to go from here...

...and I find myself asking for help again.

I tried looking for any files that might contain information that would be helpful in troubleshooting, and I've included the content of those files below. With any luck, perhaps someone could spot some setting or script that doesn't look right.

As always, thanks for any help.

Regards,
Bob





Cut/Paste of related file contents:


Inspect.exe
=====================================
- Windows Version: 6.1 [7601]
- AVISYNTH Version: 2.5.7.0, Ok
- HAALI Splitter: Ok
- FFDSHOW: 3326, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- BD Rebuilder v0.37.0.8, Ok
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok


BDREBUILDER.INI
=====================================
[Options]
VERSION=0.37.0.8
MODE=1
ENCODE_QUALITY=0
ONEPASS_ENCODING=2
AUTO_QUALITY=0
TARGET_SIZE=23500
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
SD_CONVERT=0
OPEN_GOP=0
RESIZE_1080=0
DEINTERLACE=1
SD_TO_1080=0
CONVERT_WIDE=0
DTS_REENCODE=1
AC3_REENCODE=1
AC3_640=1
AC3_192=0
KEEP_HD_AUDIO=0
AVCHD=0
REMOVE_WORKFILES=0
MOVIE_ONLY_LOOP=1
REMOVE_OUTPUT=0
USE_FILTERS=0
BDMV_CERT_ONLY=0
USE_LAVF=0
IVTC_PULLDOWN=1
ASSUME_DVD_PAL=0
AUDIO_TRACK_LIMIT=1
SUBTITLE_TRACK_LIMIT=1
CUSTOM_TARGET_SIZE=23500
QUICK_EXTRAS=1
ENCODER=0
[Paths]
SOURCE_PATH=D:\DVD\QUANTUMOFSOLACE\
WORKING_PATH=D:\TEMP\

LASTCMD.TXT
====================================
"D:\DVD\BD_Rebuilder\tools\x264.exe" "D:\TEMP\WORKFILES\VID_00050.AVS" --preset superfast --bluray-compat --b-pyramid strict --weightp 1 --qpmin=0 --bitrate 28003 --level 4.1 --qpfile "D:\TEMP\WORKFILES\VID_00050.CHP" --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 35000 --threads auto --slices 4 --thread-input --output "D:\TEMP\WORKFILES\VID_00050.AVS.264"


BD-REBUILDER.LOG
====================================
-----------------------
[15:50:18] BD Rebuilder v0.37.08 (beta)
- Source: QUANTUMOFSOLACE
- Input BD size: 27.03 GB
- Approximate total content: [01:46:14.368]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: Good (Very Fast), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[15:50:24] PHASE ONE, Encoding
- [15:50:24] Extracting A/V streams [VID_00050]
- [16:03:59] Reencoding: VID_00050 (1 of 1)
- [16:03:59] Collecting video information
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 152,832 frames
- Bitrate: 28,003 Kbs
- [16:03:59] Reencoding: VID_00050, Pass 1 of 1
- [17:11:13] Video Encode complete
- [17:11:13] Reencoding audio tracks (if req'd)
- [17:16:32] Multiplexing M2TS
[17:26:11]PHASE ONE complete
[17:26:11]PHASE TWO - Rebuild Started
- [17:26:11] Rebuilding BD file Structure
[17:37:20] - Encode and Rebuild complete
[17:37:20]JOB: QUANTUMOFSOLACE finished.

QUANTUMOFSOLACE.INF
=======================================
[Status]
LABEL=QUANTUMOFSOLACE
VERSION=v0.37.08 (beta)
SOURCE_SIZE=29027733504
SOURCE_VIDEO_SIZE=29027733504
TARGET_SIZE=24641536000
REDUCTION=.848896314850225
RESIZE_1080=0
AUDIO_TO_KEEP=eng;
KEEP_HD_AUDIO=0
SUBS_TO_KEEP=eng;
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=0
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00050]
AUDIO=1000
PGS=1000000
M2TS_TARGET=24641536000
RATE=28003
NSTART=27000000
NEND=313846560
NSIZE=23207387136
FLINK=0
MLINK=0

AUD_00050_4352.AVS
=======================================
#Created by BD Rebuilder - v0.37.08 (beta)
LoadPlugin("D:\DVD\BD_Rebuilder\tools\nicaudio.dll")
audio=NicDTSSource("00050.track_4352.dts").Amplify(1.2)
ConvertAudioTo16bit(ResampleAudio(audio, 48000))

VID_00050.AVS
=========================================
#Created by BD Rebuilder - v0.37.08 (beta)
DirectshowSource("D:\DVD\QUANTUMOFSOLACE\BDMV\STREAM\00050.m2ts", fps=23.976, framecount=152832, audio=false)
ConvertToYV12().AssumeFPS(24000,1001)

VID_00050.CHP
=============================================
0 I -1
5997 I -1
10730 I -1
14878 I -1
21982 I -1
25598 I -1
29354 I -1
32880 I -1
38084 I -1
41871 I -1
47878 I -1
51503 I -1
56155 I -1
63756 I -1
68135 I -1
75546 I -1
81255 I -1
88164 I -1
93291 I -1
102253 I -1
104402 I -1
111163 I -1
116660 I -1
121264 I -1
128510 I -1
138474 I -1
140961 I -1
146233 I -1
152826 I -1

AUD_00050.meta
=================================================
MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr --vbv-len=500
V_MPEG4/ISO/AVC, "D:\DVD\QUANTUMOFSOLACE\BDMV\STREAM\00050.m2ts", fps=23.976, track=4113
A_DTS, "D:\DVD\QUANTUMOFSOLACE\BDMV\STREAM\00050.M2TS", down-to-dts, track=4352, lang=eng, mplsFile=00001
S_HDMV/PGS, "D:\DVD\QUANTUMOFSOLACE\BDMV\STREAM\00050.M2TS",fps=23.976, track=4608,lang=eng, mplsFile=00001

MUX_00050.meta
==================================================
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --auto-chapters=5 --vbv-len=500
V_MPEG4/ISO/AVC, "D:\TEMP\WORKFILES\VID_00050.AVS.264", fps=23.976, insertSEI, contSPS

MUX_MOVIE_ONLY.meta
====================================================
MUXOPT --no-pcr-on-video-pid --new-audio-pes --blu-ray --vbr --custom-chapters=00:00:00.000;00:04:10.124;00:07:27.530;00:10:20.536;00:15:16.832;00:17:47.649;00:20:24.306;00:22:51.369;00:26:28.420;00:29:06.369;00:33:16.911;00:35:48.104;00:39:02.131;00:44:19.156;00:47:21.797;00:52:30.897;00:56:29.010;01:01:17.173;01:04:51.012;01:11:04.802;01:12:34.433;01:17:16.423;01:21:05.694;01:24:17.719;01:29:19.937;01:36:15.519;01:37:59.248;01:41:39.134;01:46:14.117 --vbv-len=500
V_MPEG4/ISO/AVC, "D:\TEMP\WORKFILES\00050.M2TS", fps=23.976, insertSEI, contSPS, track=4113
A_AC3, "D:\TEMP\WORKFILES\AUD_00050_4352.AC3", lang=eng
S_HDMV/PGS, "D:\TEMP\WORKFILES\00050.track_4608.SUP",fps=23.976,lang=eng

[jdobbs]

C'mon. There are many, many, many, many people who have done thousands of BD-25 backups successfully. Are you saying that just because you're having an issue in your particular instance that BD-RB can't reencode BD-25s? I'm not sure what might be peculiar about your setup -- but apparently something is. There is also the possibility of bitrate spikes with that high bitrate that I mentioned earlier. If it were happening to others I might think X264 or TSMUXER were at fault -- but I'm just not getting any "stuttering" reports from others.

I've added additional code into the next version to ensure the maximum bitrate is never exceeded. But with a movie-only backup like yours with only a couple of audio tracks that aren't HD -- it isn't very likely to be the issue. I have to think the player is suspect (although getting the stutter at the exact same point sure seems to make you scratch your head over that one too).

[laserfan]

LASTCMD.TXT
====================================
"D:\DVD\BD_Rebuilder\tools\x264.exe" "D:\TEMP\WORKFILES\VID_00050.AVS" --preset superfast --bluray-compat --b-pyramid strict --weightp 1 --qpmin=0 --bitrate 28003 --level 4.1 --qpfile "D:\TEMP\WORKFILES\VID_00050.CHP" --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 35000 --threads auto --slices 4 --thread-input --output "D:\TEMP\WORKFILES\VID_00050.AVS.264"
Hmmm maxrate should be 40000, not 35000?

[jdobbs]

Hmmm maxrate should be 40000, not 35000? That's there to give a safety cushion. You never want to push the line just in case the encoder goes a little over at peaks. It also gives room in case there is secondary video (the 40000 it the maximum total for all video streams). In most cases stuttering would only happen if you went higher than the maximum, not lower. There is also a 48000 maximum for the combination of all video, audio, and PGS streams. If he were keeping HD audio, that would be where I'd be concerned -- but he's not.

In the next release I've added code to add all of the video/audio/pgs streams together and make sure it is never possible for them all to get too large. But, frankly, the chance of that happening is pretty small when working with a commercial source. You're encoding from a baseline that already meets that requirement.

[Ghitulescu]

That's there to give a safety cushion. You never want to push the line just in case the encoder goes a little over at peaks. It also gives room in case there is a secondary video (the 40,000 it the maximum total for all streams). Stuttering would only happen if you went higher than the maximum, not lower. There is also a 48000 maximum for the combination of all video, audio, and PGS streams.

How about buffer underrun?

[jdobbs]

How about buffer underrun? It's possible I guess... but with qpmin at "0" wouldn't that be unlikely? I'd have to defer to the X264 experts on that one. You don't see bitrates that high very often... 25GB is a lot of room for 1:45 of movie.

@RobertM

Try using the custom target size and lowering your size to 10GB or so, burn it to a BD-RE, and see if the stuttering goes away. That way we might see if the high bitrate is giving us the problem.

[RobertM]

Hi guys,

Thanks for your replies.

Now, just off the top, don't get me wrong -- I'm certainly NOT saying the BR-Rebuilder is incapable of making encoded BD-25 backups. If this problem were happening to lots of other people then they would surely be mentioning it. While I say that the stutter is "slight", that means that it happens infrequently and for a short period of time. It is often barely perceptible, but sometimes it stands out like a sore thumb, and is plainly, obviously wrong.

I'm tending to disbelieve that the player is responsible, but I'm keeping an open mind. I don't really see why it would balk at handling the re-encoded file and not the original, larger file. But the player still has to process these m2ts files before sending them to the HDMI output, so the player is still in contention as a possible problem. I do plan to try out a couple of other machines, so that I can get closer to 100% sure. The player has been updated to the very latest firmware.

If it is not the player, and not a common problem in the BD-Rebuilder community, then it would have to be something in how the re-encode process is happening on my machine. That's why I included all of those configuration and script files, hoping that some incorrect setting would stand out. I'm trying to do a fairly plain vanilla backup, and so I would expect BD-Rebuilder to just create a standard set of script files and fire them off at the various helper apps. If these scripts and settings look fine then the problem would have to be during the actual encoding operation or the remuxing.

So...

Let me be really clear again: I'm not accusing BD-Rebuilder itself of being at fault, or of other users being insufficiently observant, and I'm tremendously grateful for any help that anyone can provide.

I just was not sure which way to go. Here's my plan:

1. Run another test with custom size 10GB. I don't have my BD-RE discs yet (can't find any locally) but the ones I ordered should arrive today.

2. Test out a couple of other non-Sony players.

3. Regardless of the results of steps 1 and 2, get another HD and make an alternate boot drive on my system. Install a fresh OS on that drive (Win7 or XP) and retry the re-encode.


Thanks again for the help.
Bob

[jdobbs]

I don't think it is a Sony problem... I have two Sony players and neither show it. What I meant is that there may be something wrong with your player...

It's also possible that there is a buffering issue -- and your player is less forgiving than others.

One other thing you might try is playing back the AVS files and watching closely at the points you see stuttering. There's always the chance that it is a CODEC issue of some type and the stutter is there before the encode.

[shon3i]

What is your burning speed? If you burn under 3x you have problem, that not meet TS reading rate at CASE 1 of BD specification, which allow 48mbps, while CASE 2 allow up to 28mbps for all streams.

@jdobbs, about primary/secondary video bitrate:

In case of 525/60 video format and 625/50 video format:
.. The total video bit-rate value of Primary video and Secondary video streams shall be less
than or equal to 40*106 [bits/sec].
.. Maximum video bit-rate for Secondary video streams shall be less than or equal to 8*106
[bits/sec].
• In case of 1920x1080 video format and 1280x720 video format:
.. The total video bit-rate value of Primary video and Secondary video streams shall be less
than or equal to 80*106 [bits/second].
.. Maximum video bit-rate for Secondary video streams shall be less than or equal to is 40*106
[bits/second].

And BDRebulder x264 CMD look now messy. You maybe know --bluray-compat automaticly now reduce settings as should for example if your cmd is

"D:\DVD\BD_Rebuilder\tools\x264.exe" "D:\TEMP\WORKFILES\VID_00050.AVS" --preset superfast --bluray-compat --b-pyramid strict --weightp 1 --qpmin=0 --bitrate 28003 --level 4.1 --qpfile "D:\TEMP\WORKFILES\VID_00050.CHP" --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 35000 --threads auto --slices 4 --thread-input --output "D:\TEMP\WORKFILES\VID_00050.AVS.264"

Can be safetly cuted as

"D:\DVD\BD_Rebuilder\tools\x264.exe" "D:\TEMP\WORKFILES\VID_00050.AVS" --preset superfast --bluray-compat --bitrate 28003 --level 4.1 --qpfile "D:\TEMP\WORKFILES\VID_00050.CHP" --sar 1:1 --pic-struct --vbv-bufsize 30000 --keyint 24 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 35000 --threads auto --slices 4 --thread-input --output "D:\TEMP\WORKFILES\VID_00050.AVS.264"

[RobertM]

I've got news on the player compatibility front. I tried my disc in several players, and here are the results:

Stutters happen at the predicted spots on these devices:
Sony BDP-S380 (mine)
Toshiba BDX1200

Stutters not in evidence:
Sony BDP-S370
Samsung BD-D5300
Panasonic DMP-BD75

So it would now seem pretty clear that something is wrong with the file, and that not all players (even from the same manufacturer) are sensitive to the problem.

I don't have any news on the 10GB build yet. I set the custom size before I started the build, but forgot to SELECT the custom build; it was still set to BD-25. Oops!

I'm going to proceed (once the 10GB build is finished) with the clean OS install on a new drive. I'll do a Win7 install first, then, if unsuccessful, a WinXP install.

@shon3i: My most recent burns have been set to 4x, but I'm not really concerned with the burning at present because I can produce the exact problem using an external HD.

[Ghitulescu]

There is defintively something wrong with the encoding: in my experience Toshiba were the closest players to the standards.

[shon3i]

There is defintively something wrong with the encoding: in my experience Toshiba were the closest players to the standards.
I think problem on tsmuxer side, since x264 in cooperation with commercial muxers have not verifying problems, while tsmuxer can't always pass verify process.

Maybe we can eliminate problem using other muxer, such as EasyBD Lite, it's freeware aslo.

[jdobbs]

@shon3i

The total video bit-rate value of Primary video and Secondary video streams shall be less
than or equal to 80*10^6 [bits/second]

I saw that too (80Mbs) in the standard -- but I don't understand how it can do that when the BD drive has a maximum data transfer rate of 53.948 Mbps and the maximum user rate is 48Mbs? I also see this is the standardData rate from the Drive(RUD): 54*10^6 bits/second So I guess as long as you don't put the video into an M2TS stream or put it on a BD you can go as high as 80Mbs -- which of course makes no sense to me.

I looked at the authoritative BD site and it says 48Mbs as well. Also, here's a quote from the Wiki entry:BD Video movies have a maximum data transfer rate of 54 Mbit/s, a maximum AV bitrate of 48 Mbit/s (for both audio and video data), and a maximum video bit rate of 40 Mbit/s So, when confronted with conflicting date -- I go for the safer. I guess it would be easy enough to make a 70Mbs video and test it, but I'm pretty confident it will fail.

[RobertM]

Well.... no joy :(

I first completed the 10GB custom size build: Still stutters.

Then I installed my new drive and loaded up a fresh copy of Win7 Pro x64. I didn't load ANYTHING extraneous; only BD-Rebuilder, HAALLI, FFDSHOW and AVISynth, all freshly d/l from the "bugs" thread links. I didn't even load Firefox or the drivers for my video card. Result: Still stutters.

Tomorrow I'll reformat the new drive and install XP, instead of Win7, to see if that makes any difference. I'm feeling less optimistic at this point, but we'll see.

The only bright spot is that now I have 2 big drives in my system, and putting the "working" folder on one drive and the source files on another has dramatically reduced the time for the extraction, multiplexing and rebuilding stages -- like by a factor of 2! Re-encoding is only marginally faster, as expected.

Regards,
Bob

[shon3i]

I saw that too (80Mbs) in the standard -- but I don't understand how it can do that when the BD drive has a maximum data transfer rate of 53.948 Mbps and the maximum user rate is 48Mbs? I also see this is the standardBut nowhere in standard say that 54mbs data rate is max, it's minimum if you want use 48mbs for primary AV streams. Please leave wiki pages, they are full of guessing parameters. 80mbs is in case that both primary/secondary videos are HD ie 720/1080. That why secondary video for 720/1080 have same rules as primary video.

However i still think that is Tsmuxer issue, since i few times i checked stream with verifier i saw that TS buffer exceed BD limits.

[jdobbs]

But nowhere in standard say that 54mbs data rate is max, it's minimum if you want use 48mbs for primary AV streams. Please leave wiki pages, they are full of guessing parameters. 80mbs is in case that both primary/secondary videos are HD ie 720/1080. That why secondary video for 720/1080 have same rules as primary video.

However i still think that is Tsmuxer issue, since i few times i checked stream with verifier i saw that TS buffer exceed BD limits.

So you're saying I should lift the maximum bitrate because there may be players that might play it. The minimum is the value you have to work by, just like every other minimum in the standard. The standard also says:Maximum value of TS_recording_rate of the main TS (RTS1) : 48*10^6 bits/second
It's not just the Wiki page but pretty much every reference I can find on the net (including the "Authoritative Blu-Ray Disc FAQ" -- which I have never found to be wrong about anything). I don't feel like arguing and I know you're very knowledgable -- but I'm leaving the max at 48Mbs (just like every other other software package does) -- so lets just leave it at that.

I agree that the issue is probably TSMUXER -- and very probably because of the high bitrate.

[shon3i]

So you're saying I should lift the maximum bitrate because there may be players that might play it.No, i am say that in case both primary and secondary video are 720/1080, The total video bit-rate value of Primary video and Secondary video streams shall be less than or equal to 80*106 [bits/second], and that is completely fine. But i understand you, and i totally agree with your bitrate limits, and maybe you can go little under like 46Mbs.

[RobertM]

Well,.... nothing seems to help.

I just completed a clean install of XP, set up BD-Rebuilder as before, and ran the standard BD-25 backup. Still stutters.

I've now run this process many, many times, with various settings and on (essentially) 3 different systems, including both Win7 and XP, and the results are consistent and repeatable as far as the stutters go. I'm left with a fairly strong conclusion that the re-encoding or muxing stages are causing this problem. I'll also go out on a limb and suggest that it is quite possible that other people are doing backups which contain the same problem, and they won't find out about it until they damage an original disc and have to pull out the backup; depending on their playback system they may be in for a nasty surprise.

If this is really only MY problem then I can suck it up and deal with the fact that I "just can't get there from here". After all, I can always purchase a different player and pretend that the problem doesn't exist. But I feel that some concerted effort could be made to see if the problem is, in fact, more widespread than just on my machine. Does anyone else on this forum have a BDP-S380 (or perhaps 580 or 780) on which they can run some tests? I've found that EVERY disc I've made with re-encoded video has some degree of stuttering, so someone should be able to say "you're crazy,.. I ran the same backup, checked the same points in the movie, and it doesn't happen on my BDP-380"!

I intend to continue to try and troubleshoot this. But I'm not terribly experienced with video encoding, so I'm kind of flailing around a little bit. Any hints at things I should try would be appreciated.

Regards,
Bob

[Big Barn]

Did you check for any updates for your Sony BDP-S380

Dated 04/19/2011 Firmware M06.R.0259

[RobertM]

Yes, I loaded the very latest firmware just after getting the player.

I think I'll spend some time tonight with BDInfo, getting some before-encode and after-encode information for my "Quantum" build.

<edit>
Yes, I loaded firmware version 259.
</edit>

[Capsbackup]

Perhaps try a Full backup of this same movie, and burn to BD-RE and test it on your player. There should be considerably more content with a full backup, thus eliminating the exceeded bitrate concern, if that is the case.
My R1 Blu-ray has about 3.5 hours of content. I did a full backup to BD-R and watched the entire movie on my Sony S360, and it was perfect - with no stutters at all.
Are you sure your Blu-ray burner isn't the cause? :confused:

Software players cannot be used as reliable sources.

[RobertM]

Hi Caps,

I would do that, if you really think that that would be instructive, but I already know that the INPUT files to the burning process contain the problem. I can copy the BD-Rebuilder output folders onto my external HDD, and plug that into the front USB port on the BD player, and the problem is evident. So burning a file with a known problem won't achieve much, in my opinion. But if you really think it would achieve something then I can do so (my BD-RE DL discs have arrived ;) ).

I agree about the s/w players, since they do not exhibit the same problem as my standalone player.

[RobertM]

I have done some work with BDInfo and I've attached the results of 3 particular file scans:

1. The "Quantum_Original" files are from the original ripped m2ts file.

2. The "Quantum_1" files are from the first rebuild, which has the stutters. The build settings are as per the original posting in this thread.

3. The "Quantum_6_GOOD" report is from the first time I was able to make a successful, non-stuttering rebuild. The only difference from the "Quantum_1" build was that I set a "Custom Target size" of 35GB, thereby avoiding the necessity for re-encoding the video. I haven't bothered to include the video rate chart for this because it is identical to the "Quantum_Original" chart, since there was no re-encoding of the video.


Of note:

I was expecting to see charts that looked very similar, but with a scaling difference. But the original and re-encoded charts look quite different. The re-encoded chart is evenly distributed about an average of around 28Mbps, while the original chart has a similar average but a much wider distribution.

Most interestingly, the original shows peak values around 45Mbps while the re-encoded reaches a maximum of about 55Mbps. It seems like, if there is a max bitrate setting of 48Mbps, the re-encoding has somehow exceeded that limit -- or are we not talking about the same things here.

[Video Dude]

I think problem on tsmuxer side, since x264 in cooperation with commercial muxers have not verifying problems, while tsmuxer can't always pass verify process.

Maybe we can eliminate problem using other muxer, such as EasyBD Lite, it's freeware aslo.

RobertM could do a quick test and use EasyBD Lite to mux to determine if tsmuxer is causing the stutter. Either use the BD-RB workfiles or demux a BD-RB created Blu-ray.

[jdobbs]

RobertM could do a quick test and use EasyBD Lite to mux to determine if tsmuxer is causing the stutter. Either use the BD-RB workfiles or demux a BD-RB created Blu-ray.

You know, now that I think about it -- it isn't likely to be TSMUXER. The files that aren't reencoded are still remuxed with TSMUXER, and they are working fine.

@RobertM

A momentary spike that exceeds the max isn't a big deal and should be acceptable as long as it is short. Buffering should allow it for about a half second or so. I can't tell from the charts how long the high bitrate is held -- but it doesn't look very long.

[RobertM]

The files that aren't reencoded are still remuxed with TSMUXER, and they are working fine.

I was thinking the same thing.

The other thing I noticed was that stutters that I typically look for don't seem to correspond exactly with any particular peak on the charts. There are LOTS of short stutters, but some are particularly noticeable because they happen while some smooth motion is taking place, so they become VERY evident to the eye. The 3 particular stutters that I look for are at 0:35:16, 1:28:49 and 1:29:09. The first 2 show up when I do a "Good quality" rebuild, the last 2 when I do a "High quality" rebuild.

I'd feel more confident in my assertions if ANYONE else was observing the same thing. So I'm doing yet another trial, but on a completely different machine this time; my older Pentium 4 XP machine. As a side note, this makes me glad that I built my new machine at X-Mas. The new machine does a rebuild in about 2 hrs, the old one has been working for 10 hrs already, and reports more than 7 hrs to go!

[shon3i]

You know, now that I think about it -- it isn't likely to be TSMUXER. The files that aren't reencoded are still remuxed with TSMUXER, and they are working fine.

@RobertM

A momentary spike that exceeds the max isn't a big deal and should be acceptable as long as it is short. Buffering should allow it for about a half second or so. I can't tell from the charts how long the high bitrate is held -- but it doesn't look very long.
You can't be sure for tsmuxer if we not see buffer analysis of es and ts buffering model. For es, his need Elecard Buffer analyser, and for ts, some BD verifier, so mission impossible. Reason why untoched no stutters even via tsmuxer is not good reason to not still suspect on tsmuxer. x264 is famous of creating short high buffer spikes which can confuse muxing process, and tsmuxer weakness is easy to create overflow in ts buffer model.

First things first. Remux problematic video with other muxer. Ideal now is Easy BD Lite since "passes" verifications, and it's more stable.

[laserfan]

First things first. Remux problematic video with other muxer. Ideal now is Easy BD Lite since "passes" verifications, and it's more stable.Hmmm I've found nothing whatsoever to be "stable" about EasyBD Lite 1.09. Works to mux a program on first installation, then crashes on subsequent attempts (have to un- and re-install). Saving of a project doesn't work (can't use the saved project again). I've tried it 3 or 4 times and it seems like alpha-quality to me.

[shon3i]

By stable i mean muxed output, not program itself.

[laserfan]

No argument there. When I have been able to get it to work, the output was fine.

Whaddya think about this "buffering" discussion shon3i--I still wonder about the "35000 vs 40000" vbv-maxrate setting. It does seem like the only problems I have ever had with x264 is when I've deviated from "standard" settings.

Is there any way jdobbs to tell BD-RB to use --vbv-maxrate 40000 in 37.08? IIRC TWEAK of this setting in the INI will get over-ridden.

[RobertM]

I've run a BDInfo analysis on the unmuxed m2ts file in the working directory. It contains only video, as expected, but the numbers for the video portion are not the same as when I ran the analysis on the muxed BD output folders. Does TSMuxer normally alter the video stream when muxing, or does the DBInfo scanning process yield slight variations when scanning a video stream?

I've attached the working file scan.

Regardless, I'll give EasyBD Lite a go and see what happens.

<edit>
Oh, and an important detail I forgot to mention.... When I play this m2ts file from the working folder on my player it plays without audio or chapters (no surprise), but it also stutters at the expected spots. Further indication that TSMuxer is probably not the problem, but I'm going to try an EasyBD lite mux anyhow, just to be thorough.
</edit>

[jdobbs]

No argument there. When I have been able to get it to work, the output was fine.

Whaddya think about this "buffering" discussion shon3i--I still wonder about the "35000 vs 40000" vbv-maxrate setting. It does seem like the only problems I have ever had with x264 is when I've deviated from "standard" settings.

Is there any way jdobbs to tell BD-RB to use --vbv-maxrate 40000 in 37.08? IIRC TWEAK of this setting in the INI will get over-ridden. That's a non-issue and it's also not "non-standard". Compared to what? If you're already spiking too high with bitrate -- setting maxbitrate higher will just make it worse.

[jdobbs]

@RobertMOne other thing you might try is playing back the AVS files and watching closely at the points you see stuttering. There's always the chance that it is a CODEC issue of some type and the stutter is there before the encode. Did you ever try this?

[RobertM]

Did you ever try this?

No. That got lost in all the other stuff that I was trying. So I just tried it...

1. Right-click on VID_00050.AVS in my workfiles folder
2. Select "open with...", "choose default program".
3. Select "Windows media player"
4. Get an error message "Windows media player has stopped working"
5. Tried the "Check online for a solution" button, but it just waits a few seconds, saying it is searching for a solution, and then closes with no other message.

Hmm...

<edit>
VLC player won't play it either. Is this suggestive of a problem in my system, or should I try to play it some other way.
</edit>

[RobertM]

My EasyBD mux job just completed. Still stutters in the same spots.

It was great that I could put chapter markers just 5sec preceding each suspect position on the disc. Not nice to see the stutters, but nice that I didn't have to search for them.

[shon3i]

A small sample of encoded part that stutter (around) will be nice (uploaded to mediafire), i want to check it in analysers. You can also try to cut original around that position and encode to see is problem still exist. That will make things easier to replicate.

@laserfan, that should be called maxed settings not standard, and they are not recommended, and always need to leave some room for errors. If you look at comercial discs you probably never seen that high settings. I agree with jdobbs.

[laserfan]

2laserfan, that should be called maxed settings not standard, and they are not recommended, and always need to leave some room for errors. If you look at comercial discs you probably never seen that high settings. I agree with jdobbs.
Thanks shon3i for your reply! :)

[jdobbs]

No. That got lost in all the other stuff that I was trying. So I just tried it...

1. Right-click on VID_00050.AVS in my workfiles folder
2. Select "open with...", "choose default program".
3. Select "Windows media player"
4. Get an error message "Windows media player has stopped working"
5. Tried the "Check online for a solution" button, but it just waits a few seconds, saying it is searching for a solution, and then closes with no other message.

Hmm...

<edit>
VLC player won't play it either. Is this suggestive of a problem in my system, or should I try to play it some other way.
</edit> That is a problem... it means that somehow AVISYNTH isn't registered for that file type. That usually means AVISYNTH isn't installed (or isn't installed properly).

[Edit] Well, maybe not. Windows Media Player "used" to work with these -- but I just tried it and it failed on my system too. I'd recommend you download and install "Media Player Classic" and play it back with that.

[Capsbackup]

VLC player won't play it either. Is this suggestive of a problem in my system, or should I try to play it some other way.

Media Player Classic should play the file. It plays all video formats for BD, especially if you are playing the .avs. :cool:

[RobertM]

I guess I was confusing "Media Player Classic" with "Windows Media Player". Once that was pointed out to me I remembered seeing it in the "Tools" folder of the BD-Rebuilder d/l.

MPC plays the m2ts files all right, with no displayed stutter, even on those files that DO stutter on my standalone player. I can step though, frame by frame, and the progression looks smooth.

But it will NOT play the avs file in the "Workfile" folder. I tried to play "VID_00050.AVS" in MPC and it throws the following error message:


Media Player Classic could not render some of the pins in the graph, you may not have the needed codecs or filters installed on the system.


It refers to the following "pin"


H:\Temp\WORKFILES\VID_00050.AVS::Avisynth video #1

Media Type 0:
--------------------------
Video: YV12 1920x1080 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3110400
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 3110400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 28 00 00 00 80 07 00 00 38 04 00 00 01 00 0c 00 (...€...8.......
0040: 59 56 31 32 00 76 2f 00 00 00 00 00 00 00 00 00 YV12.v/.........
0050: 00 00 00 00 00 00 00 00 ........




<edit>
When I installed AVISynth I just let all the default settings stand. Should I have made some different selections? I recall that there were bunch of options.
</edit>

[RobertM]

@shon3i

A small sample of encoded part that stutter (around) will be nice (uploaded to mediafire)

I'd be more than pleased to provide this to you. Err.... what tool do you suggest to clip a section out of the final m2ts?

[jdobbs]

@RobertM

I forgot, you need to tell FFDSHOW to playback raw video in order to play that AVS. From the windows/start button select "Programs" and then "FFDSHOW" -- select "Video Decoder Configuration" and under "Raw Video" choose "All Supported". That way FFDSHOW will decode the YV12 output of the AVS file.

You need to play back the AVS, not the M2TS.

[RobertM]

Thanks, jdobbs, that fixed the MPC playback problem.

So now I can play back the AVS file in MPC, and no stuttering is evident. I then tried again, stepping through the video, frame by frame where the stutters should happen, and the progression of frames seemed smooth.

[shon3i]

Use tsmuxer. Also after cutting try playing that part to see is stutter still there.

[RobertM]

@shon3i

I have cut out 2 parts from the re-encoded m2ts file. They are each 10 sec long, and the stutters happen at about the middle of each clip.

In 00001.m2ts, I can see the cars shudder back and forth as they pass in front of the airport building.

In 00002.m2ts, when the woman jogs past, the railings shudder back and forth.

I verified that these small files DO stutter on my standalone player. I copied them to my external HD, plugged the drive into the USB port on the player. VERY noticeable on my Sony BDP-S380. They DON'T stutter at all when played in MPC on my desktop.

I'm uploading them (Clips.zip) to MediaFire right now. I'll edit this message to indicate when it's done.

<edit>
Just finished uploading. I probably should have uploaded individually, instead of putting the 2 files into one archive. Oh well, here's hoping you're not on dial-up ;)

I've never used MediaFire before. Do I just need to provide this link?
http://www.mediafire.com/download.php?17fdffi2s70vuby
</edit>

[shon3i]

Ok here is report of buffer and yes both clips have buffer errors

Stream info:
file name : C:\Users\shon3i\Desktop\Clips\00002.m2ts
file size : 34 609 152 bytes

video format : AVC/H.264
initial CBP removal relay : 0.86 sec
buffer size : 30 000 000 bits
declared bitrate : 35 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits


Errors:
invalid value at 0.857 sec. (initial_cpb_removal_delay 77 143)
invalid value at 1.858 sec. (initial_cpb_removal_delay 77 143)
invalid value at 3.526 sec. (initial_cpb_removal_delay - 31 681 624)
invalid value at 4.527 sec. (initial_cpb_removal_delay 77 143)
buffer overflow at 4.486 sec. (55 bits)
invalid value at 4.819 sec. (initial_cpb_removal_delay 77 143)

Stream info:
file name : C:\Users\shon3i\Desktop\Clips\00001.m2ts
file size : 34 609 152 bytes

video format : AVC/H.264
initial CBP removal relay : 0.86 sec
buffer size : 30 000 000 bits
declared bitrate : 35 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits


Errors:
invalid value at 0.857 sec. (initial_cpb_removal_delay 77 143)
invalid value at 1.858 sec. (initial_cpb_removal_delay 77 143)
invalid value at 3.526 sec. (initial_cpb_removal_delay 77 143)
invalid value at 4.527 sec. (initial_cpb_removal_delay 77 143)
invalid value at 4.819 sec. (initial_cpb_removal_delay 77 143)
invalid value at 5.737 sec. (initial_cpb_removal_delay 77 143)
invalid value at 6.112 sec. (initial_cpb_removal_delay 77 143)
invalid value at 6.196 sec. (initial_cpb_removal_delay 77 143)
invalid value at 7.197 sec. (initial_cpb_removal_delay 77 143)
invalid value at 8.156 sec. (initial_cpb_removal_delay 77 143)
invalid value at 9.157 sec. (initial_cpb_removal_delay 77 143)
invalid value at 9.658 sec. (initial_cpb_removal_delay 77 143)


This is likely problem in x264 nal hrd model or it's just broken build, or recent updates to x264 broke something older, BUT

when you mux with Easy BD Lite, did you mux from tsmuxer source (m2ts) or direct from .264 file directly came from bdrebulder? This can be also Tsmuxer junk which create on mux if using inserSEI and contSPS options

[RobertM]

when you mux with Easy BD Lite, did you mux from tsmuxer source (m2ts) or direct from .264 file directly came from bdrebulder?

I grabbed the files from the working folder, and I'm pretty sure that they were these:
VID_00050.AVS.264
AUD_00050_4352.AC3
00050.track_4608.sup

I can't be 100% sure because my son is now playing vid games on the "big" computer. I can check in an hour or so.

[shon3i]

I grabbed the files from the working folder, and I'm pretty sure that they were these:
VID_00050.AVS.264
AUD_00050_4352.AC3
00050.track_4608.sup

I can't be 100% sure because my son is now playing vid games on the "big" computer. I can check in an hour or so.
If this is true, we can eliminate tsmuxer completely as guilty for this errors. And looking more on x264 side. I just need this confirmation. It's much harder but you can split from that VID_00050.AVS.264 same position to see is there errors too with dgsplit, and again upload.

[RobertM]

Yes, I'm happy to help.... once I get on my big machine again. With any luck I'll have something for you in a few hours.

[jdobbs]

Ok here is report of buffer and yes both clips have buffer errors





This is likely problem in x264 nal hrd model or it's just broken build, or recent updates to x264 broke something older, BUT

when you mux with Easy BD Lite, did you mux from tsmuxer source (m2ts) or direct from .264 file directly came from bdrebulder? This can be also Tsmuxer junk which create on mux if using inserSEI and contSPS options The builds in use on that version of BD-RB was r1936 (64 bit) or r1937 (32 bit) as it was posted on www.x264.nl.

[shon3i]

Yes, I'm happy to help.... once I get on my big machine again. With any luck I'll have something for you in a few hours.
No problem, now that we have evidence.

The builds in use on that version of BD-RB was r1936 (64 bit) or r1937 (32 bit) as it was posted on www.x264.nl. You know, sh*** happen :) RobertM can aslo try with other buld (komsair) or some previous revision.

[jdobbs]

No problem, now that we have evidence.

You know, sh*** happen :) RobertM can aslo try with other buld (komsair) There's a new build on that site (r1947) for both 64 and 32 bit -- I'm including those in the next release of BD-RB. You never know -- maybe if RobertM updated to those it may just go away. Stranger things have happened.

[Edit] Looks like a newer vesion of X264 was posted today (r1995). There's a couple of fixes in the change log that may mean something:
===========================
commit 9a40ee6a6d7354ed5f453908fc29d813d1886481 r1952
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Wed May 4 11:49:06 2011 +0400

Fix bugs with ratecontrol reconfiguration
Initialization of some parameters was missed or wasn't synchronized with other threads
===========================
commit 20d9cb8c7b79b29857fe7d92c931efbd65f09df1 r1984
Author: Simon Horlick <simonhorlick@gmail.com>
Date: Fri Mar 25 13:36:21 2011 +0000

MBAFF: Modify ratecontrol to update every two rows
===========================
commit 06f5fa5efadd89585577ba78405825002135e1b0 r1955
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu May 12 10:21:16 2011 +0800

Fix bug in NAL buffer resizing
Also properly terminate if NAL buffer resizing fails.
===========================


There may be others, I went through the list pretty quickly.

[RobertM]

maybe if RobertM updated to those it may just go away.

I'm willing to try that. Would I just d/l the 32bit version and replace the existing one in the BD-Rebuilder folder? I've got a 64-bit OS, but I thought that I read that we should stick with the 32-bit version?

[jdobbs]

I'm willing to try that. Would I just d/l the 32bit version and replace the existing one in the BD-Rebuilder folder? I've got a 64-bit OS, but I thought that I read that we should stick with the 32-bit version? The only time the 64 bit version is used is if you have "Use LAVF" selected in SETUP. So if you don't use that option -- just download the 32 bit 8bit-depth version and replace X264.EXE in the TOOLS folder.

[RobertM]

I'll grab a copy of the 32-bit 8-bit-depth version and give it a try. Best to avoid too many new variables at this point.

[Capsbackup]

Is it to early to assume there is a problem with this current build of BD-RB / x264? :confused: Personally I have not experienced any such mentioned symptons, but I have not watched every backup completely that I have created with this current build, BD-RBV03708. ( about 8 backups )
I guess I should watch a few just to be certain though. :(

[jdobbs]

Is it to early to assume there is a problem with this current build of BD-RB / x264? :confused: Personally I have not experienced any such mentioned symptons, but I have not watched every backup completely that I have created with this current build, BD-RBV03708. ( about 8 backups )
I guess I should watch a few just to be certain though. :( Right now I have no idea as to exactly what the problem is... but I'd say that the average bitrate of 28Mbs is the source of the issue -- and that's unusual (or at least it should be). I personally use BD-9 if I'm doing a movie-only backup. I hate to waste a BD-25 when it isn't needed. A guess might be that the high average bitrate is causing the balancing act of allocation to push the upper ranges of demand beyond where they should be -- but the people who are writing code for X264 know a lot more about that than I do.

Remember too that this is a single report in a single encoding environment (I know of no other "stuttering" reports). It's hard to make judgements based on that alone.

[RobertM]

Remember too that this is a single report in a single encoding environment

I agree that we should reserve judgement at the present time. I've tried to be very careful and methodical in my troubleshooting, but I'm very new at this, so it is still possible that I've done something stupid.

But, I would say that there are really more than one encoding environment involved. There are:

1) my default system: i7-950 Win 7 Pro x64.
2) i7-950 with a fresh install of Win 7 Pro x64 on new, separate HDD
3) i7-950 with a fresh install of Win XP x32 on new, separate HDD
4) My old Pentium 4 2.4GHz Win XP x32 (rebuild took 20hrs on this baby!)

So there are 2 physically distinct environments, and I would argue that the 3 instances on my i7 are distinct, each having a separate OS installation and an individual d/l and install of all the BD-rebuilder tools. The results, in all 4 cases, are identical.

[RobertM]

I installed the latest version of x264 32bit -- no difference, still stutters.

So, just to keep everything straight, I compiled a whole new set of samples based on this last rebuild.

I used TSMuxer to take 2 clips from the original ripped m2ts file.
Clip 1 is from 0:35:10 to 0:35:20, or 2110s to 2120s.
Clip 2 is from 1:28:42 to 1:28:52, or 5322s to 5332s.
I used these same values for each set of clips.
00001.m2ts (http://www.mediafire.com/download.php?z1bwbc2td5jqypn) = Original clip 1
00002.m2ts (http://www.mediafire.com/download.php?q1x58suboaf8pa4) = Original clip 2
Theses clips do not stutter.

I took 2 more clips from the BD-rebuilder output m2ts file:
00003.m2ts (http://www.mediafire.com/download.php?ugde2c8btf2w2l4) = BDRebuild clip 1
00004.m2ts (http://www.mediafire.com/download.php?t3mc75wvtshh664) = BDRebuild clip 2
Theses clips DO stutter.

Next I remuxed the files in the "workfiles" folder using EasyBD Lite. These are the files that I picked:
a. VID_00050.AVS.264
b. AUD_00050_4352.AC3
c. 00050.track_4608.sup

I took 2 more clips from the resulting m2ts file:
00005.m2ts (http://www.mediafire.com/download.php?ho2zayxy165fdx9) = EBD Clip 1
00006.m2ts (http://www.mediafire.com/download.php?7an7ynhzz9lfa6p) = EBD Clip 2
Theses clips DO stutter.

Then I used dgsplit to split VID_00050.AVS.264 into 424 chunks, each 50MB in size. The total length of the AVS file is 1:46:14, so, assuming everything is linear and proportional (I'm not sure this is a good assumption), clip 1 should be around chunks 140 and 141, and clip 2 should be around chunks 354 and 355. If there is a better way to determine which chunks are the correct ones then let me know.
AVS_Split_140 (http://www.mediafire.com/download.php?gqo53lxhshd48b4)
AVS_Split_141 (http://www.mediafire.com/download.php?lb41fehz1n34dmg)
AVS_Split_354 (http://www.mediafire.com/download.php?dxztcj2jttewyfx)
AVS_Split_355 (http://www.mediafire.com/download.php?8o0sb8qt9e9dtaq)

[shon3i]

This is internal x264 problem definitely, i just encode some random clip, and i get this buffer errors. I use target bitrate 28K and same VBV settings, using rev 1937 from x264.nl

@RobertM, thanks, you cut it well, and all clips contain buffer errors.

[Ghitulescu]

To completely rule out any other possibility besides x264, could you repeat the encoding with another encoder?

[shon3i]

There is no need for other encoder since this errors not welcome here.

@RobertM if you could try with an earlier build of x264 http://mirror02.x264.nl/x264/32bit/8bit_depth/revision1913/x264.exe, but this is probably not work with recent bdrebuilder because of bluray compat switch. You may aslo need earler version of bdrebilder that not use bluray compat.

[RobertM]

you cut it well, and all clips contain buffer errors

Just to be clear, you don't really mean ALL clips, do you? The first 2 clips that I uploaded last night (00001.m2ts and 00002.m2ts) were from the source files (rip of the original disc), so if THESE contain errors then that would indicate an AnyDVD_HD problem.

[RobertM]

@RobertM if you could try with an earlier build of x264

I'll first try x264 r1995 as per jdobbs. If that fails then I'll see if r1913 will run with my current installation of BD-Rebuilder.

[shon3i]

Just to be clear, you don't really mean ALL clips, do you? The first 2 clips that I uploaded last night (00001.m2ts and 00002.m2ts) were from the source files (rip of the original disc), so if THESE contain errors then that would indicate an AnyDVD_HD problem.
No i mean about cuted/splitted AVS_Split_* files. Because this eliminate tsmuxer as guilty for this.

[RobertM]

Just completed a rebuild using x264-v1995: Still stutters.

Moving on to see if x264-v1913 will play nice with my version of BD-Rebuilder.

[shon3i]

No chance to current BDRebilder will work previous versions. Btw i checked 00001.m2ts and 00002.m2ts of original clip and both are buffer error free.

Btw do not try with 1913 because it still create buffer errors. I need to back few revisions back to see where problem begin.

[RobertM]

I already tried 1913, and, as you suspected, BE-Rebuilder just gives an error message when it tries to re-encode.

Btw do not try with 1913 because it still create buffer errors

Have you confirmed this on your system then? If you are able to recreate these problems on your desktop then I should probably just leave the troubleshooting to you. I don't mind helping, I enjoy it actually, but I'm inexperienced at this and so I don't want to make any incorrect observations leading to unnecessary confusion.

If you want me to test something then please just let me know. But, until then, I'll hold off.

[jdobbs]

No chance to current BDRebilder will work previous versions. Btw i checked 00001.m2ts and 00002.m2ts of original clip and both are buffer error free.

Btw do not try with 1913 because it still create buffer errors. I need to back few revisions back to see where problem begin.

When you find a release that seems to be "pre-buffer-error", BD-RB v0.37.07 should work with it and it can be downloaded from this link (http://www.jdobbs.net/freeware/BD-RBV03707.zip). If need be I can also recompile an old version that has timed out.

[shon3i]

I think i found possible soulution with current revision of x264. Only thihg is need to reduce vbvmaxrate to 33000 or 36000 or something else that but not nothing between 33000<>36000, and i have no idea why some values create those errors and overflows.

RobertM can you test since i can test on stutter, i hope jdobbs can made or explain how to change VBVmaxrate to 32000 will be ideal. If this not pass, i found an older version of x264.

Thanks

[poisondeathray]

shon3i - have you brought this to the x264 devs so they can fix it ?

[shon3i]

shon3i - have you brought this to the x264 devs so they can fix it ?
Yes. But nothing to fix yet without enough evidence. And RobertM is only who can see that stuttering.

[poisondeathray]

Yes. But nothing to fix yet without enough evidence. And RobertM is only who can see that stuttering.

Yes, but buffer overflows/underflows indicate problems.

"Seeing" stuttering is a different matter. Some hardware players can play non compliant streams, correct? Take PS3 for example.

You said went back several x264 versions and they still produced error. Is this x264 reporting the buffer error or 3rd party tool ?

Unless this is only for this particular sample ? Or are you thinking something else ?

[jdobbs]

I think i found possible soulution with current revision of x264. Only thihg is need to reduce vbvmaxrate to 33000 or 36000 or something else that but not nothing between 33000<>36000, and i have no idea why some values create those errors and overflows.

RobertM can you test since i can test on stutter, i hope jdobbs can made or explain how to change VBVmaxrate to 32000 will be ideal. If this not pass, i found an older version of x264.

Thanks Weird. So i the vbv-maxrate is set to 32000 the buffering errors go away?

That's easy enough. I'll recompile with the new maxrate and pos it.

[shon3i]

Weird. So i the vbv-maxrate is set to 32000 the buffering errors go away?Yes. Am also confused too, but seems to work, i just want to see is also stutter free. Lowering VBV seem to work on all samples i test, but i don't know what will happen if bitrate is different or something else, that i am afraid.

Is this x264 reporting the buffer error or 3rd party tool ?Two verifiers that verify NAL HRD model which by BD spec decoders follow, and most decoders seem to not like PS3, so no stutter. I not so sure what general problem is. But good is that almost all samples i try with same settings got these errors.

[jdobbs]

I've updated the first post in the bug thread with a link to v0.38.02 -- which adds a limit of 32000 for --vbv-maxrate.

[RobertM]

I've done some further tests. No good news to report, but a report nonetheless.

I used TSMuxer to take a 1 min clip from my original Quantum files. I loaded this clip (m2ts) file onto a flash drive, plugged into BDP-S380, no stutters. Henceforth I will use this clip for testing - no sense spending 90min each test.

I used BD-Rebuilder, with the "FORCE_ENCODE=1" option, to rebuild with various flavours of x264.

1. BD-RB v0.38.01, default x264, stutters
2. BD-RB v0.38.01, x264-v1913, re-encode fails
3. BD-RB v0.38.01, x264-v1937, stutters
4. BD-RB v0.38.01, x264-v1947, stutters
5. BD-RB v0.38.01, x264-v1995, stutters

1. BD-RB v0.37.07, default x264, stutters
2. BD-RB v0.37.07, x264-v1913, stutters
3. BD-RB v0.37.07, x264-v1937, stutters
4. BD-RB v0.37.07, x264-v1947, stutters
5. BD-RB v0.37.07, x264-v1995, stutters


I have seen stutters in the following:
Quantum of Solace
HP7 part 1
Star Trek (2009)
Iron Man
and, ironically, The King's Speech

These did not display stutters:
How to Train Your Dragon
Batman Begins


Now... on to BD-RB v0.38.02... fingers crossed!

[RobertM]

DARN!


Still the same stutters.

Here's the logfile:

-----------------------
[15:18:19] BD Rebuilder v0.38.02 (beta)
- Source: QUANTUM_CLIP
- Input BD size: 0.22 GB
- Approximate total content: [00:00:59.340]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Quality: Good (Very Fast), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640
[15:18:22] PHASE ONE, Encoding
- [15:18:22] Extracting A/V streams [VID_00000]
- [15:18:24] Reencoding: VID_00000 (1 of 1)
- [15:18:24] Collecting video information
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1,423 frames
- Bitrate: 32,000 Kbs
- [15:18:24] Reencoding: VID_00000, Pass 1 of 1
- [15:19:01] Video Encode complete
- [15:19:01] Reencoding audio tracks (if req'd)
- [15:19:03] Multiplexing M2TS
[15:19:06]PHASE ONE complete
[15:19:06]PHASE TWO - Rebuild Started
- [15:19:06] Rebuilding BD file Structure
[15:19:06] - Encode and Rebuild complete
[15:19:06]JOB: QUANTUM_CLIP finished.


@Shon3i: should I upload the resulting m2ts file to MediaFire for your inspection?

[shon3i]

Yes please. Uhh, this means that errors are not effect on this.

Btw. Can you also upload that source which you use for reencode. I will make few test encodes with different encoders and muxers and send you to test.

[RobertM]

I've been using a 1 min clip from the original movie file, but that is too large (240MB) to send to MediaFire. I'll pare it down to 10 sec, and confirm that the behaviour is still the same when I encode it, and then upload it for you.

But not until after dinner ;)

[shon3i]

Ok when you ready just upload it :)

[RobertM]

I have just clipped the original video to 10 seconds and repeated the rebuild process. I used BD-RB v0.38.02 with it's default version of x264.

00000.m2ts (http://www.mediafire.com/download.php?b961lajb97okml2) is the entire source clip.
VID_00000.AVS.264 (http://www.mediafire.com/download.php?fzf0fu965h4gc7w) is the re-encoded video.
00001.m2ts (http://www.mediafire.com/download.php?5e6334v5s6rxeil) is the output from the BD-Rebuild process.

For verification purposes, I copied both m2ts files to my flash drive and played them in my BDP-S380. 00000.m2ts does not stutter, 00001.m2ts stutters.


Now, I was wondering: how precise is the re-encoding process between systems? If you rebuild 00000.m2ts on your system, using the same versions of BD-Rebuilder, x264, AVISynth and FFDSHOW that I am (all per the current links on the "bugs" thread), would you expect your resulting m2ts files to be bitwise identical to my 00001.m2ts? If it does turn out to be identical, then that would surely be proof that nothing else on my system is interfering with the re-encode process.

[shon3i]

Ok here first samples:

http://www.mediafire.com/?dy5dewandx0224g
http://www.mediafire.com/?sv20si4sdigzi23

More to come if need.

[Sharc]

Ok here first samples:

http://www.mediafire.com/?dy5dewandx0224g
http://www.mediafire.com/?sv20si4sdigzi23

More to come if need.
It looks that from vbv point of view test 1 and test 2 are basically identical.

[RobertM]

Well,... good news and bad news.

First the bad: Both tests you sent me stutter.

So what's could be good about that? These weren't re-encoded on my machine, so that suggests that it is not just imagination, or my system, that is the causing the trouble. Now if only someone else could SEE the problem on another player. I'm tempted to head back to the store and test these clips on the Toshiba player, just for further confirmation.

[shon3i]

It looks that from vbv point of view test 1 and test 2 are basically identical.
Yep that is main idea. Different between them is that Test1 uses tsmuxer, and Test2 Scenarist. Sony Verifier passes both Test1 and Test2, but Test1 has some playlist warning which is not problem here, streams are OK.

@RobertM, that good news only for you :) I already make set of new test, i am uploading it right now.

[shon3i]

Test 3

http://www.mediafire.com/?dxv3ikmi1cx77g9

Test 4

http://www.mediafire.com/?kc1aasx1z1b9v5e

[RobertM]

Well... I'm hoping this isn't just a trick. You didn't just use the original video to see if I'm giving you honest feedback?

Because...

NO STUTTERS.

<edit>
No stutters on test 3 that is. Haven't tried Test 4. Will do right now.
</edit>

[RobertM]

And NO STUTTERS on Test 4 either :)

[shon3i]

OK, Good news indeed. I am ready new sets which uploading now. This will definitely round what happened here :)

Test3- is encoded with lastest Cinevision/Mainconcept and muxed with tsmuer
Test4- is encoded with r1995 x264 but wih L4.0 ~24000 and ~24000 VBV (--bluray-compat --vbv-maxrate 24000 --vbv-bufsize 24000 --level 4.0 --keyint 24 --sar 1:1)

Test5 will be soon finished.

[shon3i]

Test 5
http://www.mediafire.com/?i2y1n9hlpkv7jcf

Test 6
http://www.mediafire.com/?cm3nnnolhhsjvq7

[RobertM]

Test 5 is OK: no stutters.

[shon3i]

Test 7 and 8 are on the way, after these, i definitely can say what is problem here

[Sharc]

Test 4: Frame 127 (I-frame) seems to produce a buffer overflow.

Edit: almost nil, just by 1 bit (or rounding error).

[shon3i]

Test 7
http://www.mediafire.com/?1zie5gdabak0gnm

Test 8
http://www.mediafire.com/?26vn94cnhbwqbj4

[RobertM]

Test 6: No stutter
Test 7: No stutter
Test 8: Stutter

[laserfan]

Well... I'm hoping this isn't just a trick. You didn't just use the original video to see if I'm giving you honest feedback?
I'd be surprised if shon3i sprung a placebo on you.

While we (anxiously) await his results, can you confirm RobertM--you are using a rewriteable BD in your Sony 380, yes?

I was gonna take a look myself and then I realized I had no BD-RE discs. :o

[shon3i]

The result what i am expect, and main difference between all of them is that Test 4/5/6/7 uses preset Slow, while Test 8 and BD Rebulder uses Superfast. And general difference that Test 4/5/6/7 uses mbtree and Test 8/Rebulder not. So obviously some problem in old RC. I think i can make one more test with mbtree on/of

[RobertM]

Hi Laser,

you are using a rewriteable BD in your Sony 380, yes

No, I'm copying Shon3i's test files onto a flash drive and then playing them through the front USB port on my BDP-S380. I found, previously, that files played through the USB port, and those played of BD-R discs, behave the same on this player. So it is not an issue with the optics, or the media, but a data/processing issue.

All of my optical tests were using BD-R discs, not BD-RE. I received my first BD-RE discs AFTER I discovered that the problem was repeatable using the USB port, so I've kept with the USB testing since then.

[shon3i]

Test 9 and 10 are on way. Basiclly they are same settings just one is with, and one without mbtree.

[laserfan]

No, I'm copying Shon3i's test files onto a flash drive and then playing them through the front USB port on my BDP-S380.Ah, I missed that somewhere along-the-line. Thanks, I've never tried a flash drive with my Sonys but will do so!

[shon3i]

Test 9
http://www.mediafire.com/?36v616uu48ay929

Test 10
http://www.mediafire.com/?mp0sxncisk63y99

[RobertM]

Test 9: No stutter.
Test 10: No Stutter.

[shon3i]

Ok that is good. And this preliminary confirm, that preset superfast invoke this. So mbtree has no impact, but probably some other superfast option, there is many.

Soulution is to use minimum Veryfast preset.

@RobertM if you interest i can make new set of test with that settings, to find which option invoke this behavior? In meantime you can encode disc or this sample again but without automatic quality, and use Better(Faster) from encoder menu.

[Video Dude]

Ok that is good. And this preliminary confirm, that preset superfast invoke this. So mbtree has no impact, but probably some other superfast option, there is many.

Soulution is to use minimum Veryfast preset.


shon3i, in RobertM's log files in post #1 of this thread, it appears Robert also experienced the stutter with the other presets as well.


[23:00:53] BD Rebuilder v0.37.08 (beta)
- Source: QUANTUMOFSOLACE
- Input BD size: 27.03 GB
- Approximate total content: [01:46:14.368]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Auto Quality: Good (Very Fast), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640


[14:21:49] BD Rebuilder v0.37.08 (beta)
- Source: QUANTUMOFSOLACE
- Input BD size: 27.03 GB
- Approximate total content: [01:46:14.368]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE-ONLY mode enabled
- Quality: Highest (Very Slow), ABR
- Audio Settings: AC3=1 DTS=1 HD=0 Kbs=640

[Sharc]

Thanks shon3i for tracing this down. It`s a big relief for me that it seems to happen only with superfast settings (?). I was anxiously expecting that I have to redo my backups :eek:

[RobertM]

Yes, if it will help I'll continue to test any samples that you upload.

But regarding my re-encoding with a different "quality" setting,... I'm willing, but skeptical about it solving the problem. Early on I tried the "Highest (Very Slow)" setting, and it still exhibited stutters, but not necessarily in the same spots. But I've never tried "Better" so I'll give it a go.

It might be a couple of hours before I report again... got some chores to do around here.

[jdobbs]

Thanks shon3i for tracing this down. It`s a big relief for me that it seems to happen only with superfast settings (?). I was anxiously expecting that I have to redo my backups :eek: If you go back a few posts you'll find that RobertM was still getting stutters on encodes that had passed the Sony Verifier. I don't know about everyone else -- that seems to indicate the problem is something other than just the encodes. It's also where I decided we're chasing our tails on this. I have to see this an an exercise in helping him -- not in fixing a any specific problem in BD-RB or X264.

We have to remind ourselves that the people who wrote the firmware for his player are also programmers who can make mistakes.

[laserfan]

We have to remind ourselves that the people who wrote the firmware for his player are also programmers who can make mistakes.AFAICT the BSP-S380 is a European player, and shares a common firmware platform with the BDP-S280 and BDP-BX38. I'd not seen/heard of any of these players before so perhaps indeed the problem is in-product--does anyone else here own one of these?

From Post #1:

Perhaps I should return the Sony (it's only a week old) and try a different brand.

That's what I'd do at this point, or at least RobertM take your stuttering discs back to the shop and try them out on other players.

[RobertM]

BSP-S380 is a European player

BDP-S380, actually. And I bought mine in Canada. But we're pretty "European" compared to the US, eh? ;)

RobertM take your stuttering discs back to the shop and try them out on other players

I did that last week, and found an identical stutter on a Toshiba player. That's when I figured that it wasn't only ME, but, perhaps, a wider problem. I am planning to head back to the store tomorrow, with a disc of "Best of the stutters" to see what happens on that machine.

[laserfan]

I did that last week, and found an identical stutter on a Toshiba player.Oh, yeah, I remember that now eh?

Still, I'd be inclined (after all the "exercise") to find another player that plays all. Good luck at the store.:)

[RobertM]

@Shon3i: I'd suggest that we haven't yet found the root problem, if we are simply proposing to change from the "good" quality setting to something else.

Back at my original post on this thread I reported:
I tried rebuilding with a different quality setting ("Highest" instead of "Good"), and I still get the stutter, but not at the same spots.

Looking back on this now, I see that it corresponds precisely with what we have recently determined.

I just did a test, re-encoding my 10-sec test stream at ALL of the available quality levels in BD-Rebuilder. First 1-pass (ABR):
"Good": Stutters
"Better": No stutters
"High": No stutters
"Highest": No stutters
"High Speed": No stutters

Next 2-pass:
"Good": Stutters
"Better": No stutters
"High": No stutters
"Highest": No stutters
"High Speed": No stutters

This is all for the 10-sec clip centered around 0:35:15 in the original stream.

But there is another position in the original stream that DIDN'T stutter when encoded as "Good" but DID stutter when encoded as "Highest". I will revisit that clip and try re-encoding it at all of the available quality levels. I'll post the results once I get a chance to use my desktop computer again (It's my son's turn now).

Regards,
Bob

[RobertM]

I've just completed an extensive series of tests on 3 distinct stutter points within my Quantum rebuilds. For each point, I did the test with both 1-pass (ABR) and 2-pass encoding, and for each of the 5 basic quality settings. I also repeated 2 of the test points for 1-pass (CFR) to see if it makes any difference. All tests were with 0.38.02 and its default version of x264.

Here are the results:

Point 35 -------------------
1-pass (ABR), Good: FAIL
1-pass (ABR), Better: PASS
1-pass (ABR), High: PASS
1-pass (ABR), Highest: PASS
1-pass (ABR), High speed: PASS

2-pass, Good: FAIL
2-pass, Better: PASS
2-pass, High: PASS
2-pass, Highest: PASS
2-pass, High speed: PASS

Point 148 ----------------
1-pass (ABR), Good: FAIL
1-pass (ABR), Better: FAIL
1-pass (ABR), High: FAIL
1-pass (ABR), Highest: FAIL
1-pass (ABR), High speed: PASS

2-pass, Good: FAIL
2-pass, Better: FAIL
2-pass, High: FAIL
2-pass, Highest: FAIL
2-pass, High speed: PASS

Point 149 ----------------
1-pass (ABR), Good: PASS
1-pass (ABR), Better: FAIL
1-pass (ABR), High: FAIL
1-pass (ABR), Highest: FAIL
1-pass (ABR), High speed: PASS

2-pass, Good: PASS
2-pass, Better: FAIL
2-pass, High: FAIL
2-pass, Highest: FAIL
2-pass, High speed: PASS

Point 35 -------------------
1-pass (CFR), Good: FAIL
1-pass (CFR), Better: PASS
1-pass (CFR), High: PASS
1-pass (CFR), Highest: PASS
1-pass (CFR), High speed: PASS

Point 149 -------------------
1-pass (CFR), Good: FAIL
1-pass (CFR), Better: PASS
1-pass (CFR), High: PASS
1-pass (CFR), Highest: PASS
1-pass (CFR), High speed: PASS


Notes:

1. Point 35 is the same sample that I forwarded to Shon3i for analysis. So this agrees with his findings that anything above "Good" quality yields a PASS.
2. Selection of 1-pass (ABR), 1-pass (CFR) or 2-pass doesn't seem to affect this phenomenon.
3. High-speed encoding was the only setting that yielded passes at all 3 points.


Now, I have conducted well over 100 encodes of these sections of the Quantum stream, and the results are 100% consistent. The stutters appear in EXACTLY the same spots, regardless of whether or not I am starting with the entire stream, a 1 minute clip, or a 10 second clip. I can make the stutters come and go at particular locations by changing the encode quality. This happens on those clips that were re-encoded on my system or on Shon3i's system.

So I am left with the conclusion that there really is something going on in these re-encoded streams. The parent streams play perfectly on my BDP-S380, so it doesn't seem like the player has some inherent difficulty playing BD format files. But it does seem like this player is more sensitive than other machines to the damage caused by the re-encoding process. I am going to try out some of these samples on the Toshiba tomorrow.


@Shon3i: I've uploaded the clip for point 148 (http://www.mediafire.com/?95p1jybbypmt5jk). This part fails every test except for "High-Speed Option (BD-25)" (almost opposite to the results for point 35) so it may be a better candidate for analysis.

[jdobbs]

All tests notwithstanding... I personally trust the Sony Verifier.

I also don't agree with the terms "FAIL" and "PASS" -- unless you are using the Verifier. When there is only one user having an issue -- you can't make determinations like that, especially when there are at least a few thousand others who aren't having this issue at all. It is exceptionally unusual for a problem to get this much attention when there isn't a single additional user who can verify a "stutter".

C'mon -- now I'm starting to get annoyed... you've done 100 tests -- all in the exact same environment and played back on the exact same player. Coming to any conclusion is ludicrous.

I'm willing to agree that you have an issue... but so far it appears to be just your issue. I'm certainly not willing to blame X264 (which I consider to be the best H.264 encoder on Earth)... especially when it passes the verifier.

I think it's time we all come back to reality here.

[shon3i]

We can't fully trust in verifiers also, because things like incorrect b-pyramid, weight p and who knows what much other settings will pass also (use fakeinteralced as good example), depends very of verifiers decoder. x264 is wide of settings and now is hard to say any conclusion, but i have some feeling that if i use some commercial encoder this will probably not happen. But on other side i rather to believe something not good with that player. I am keep looking for a while, to dig something.

[jdobbs]

We can't fully trust in verifiers also, because things like incorrect b-pyramid, weight p and who knows what much other settings will pass also (use fakeinteralced as good example), depends very of verifiers decoder. x264 is wide of settings and now is hard to say any conclusion, but i have some feeling that if i use some commercial encoder this will probably not happen. But on other side i rather to believe something not good with that player. I am keep looking for a while, to dig something. I trust the verifier much more than I trust the people who write firmware. I've seen too many firmware errors and issues. I trust it a whole lot more than one person testing tiny clips and running it on a player with questionable firmware.

[RobertM]

Well,... I just got back from a couple of stores.

Using my flash drive I was able to confirm that both the Sony BDP-S370 and BDP-S470 play the files just fine, with no stutter. Then I checked the Toshiba BDX-1200 again, and it DOES stutter, exactly the same as my BDP-S380. Last time I tried it on the Toshiba I was using a BD-R disc, this time the flash drive. Nobody had the newer Sony machines (the x80 series) on display, so I couldn't test them in-store. So, on faith, and a good return policy, I purchased a new BDP-S580. When I got home: No stutter.

So I have confirmed that it's definitely NOT a problem with just one player, given the results with the Toshiba. But neither does it look to be widespread. If the 580 stuttered, then I would be worried about what might happen with other future Sony players. The thing that really bugs me is that it happens EXACTLY the same way on the 380 and the Toshiba. That's one hell of a coincidence... or could it be possible that the Sony and Toshiba units share some internals? .

However,...

I'm not willing to concede that there is nothing wrong with the encoded streams; not yet anyway.

1. I take a ripped stream and play it on my 380 with no trouble.
2. I then re-encode it at "High" setting and play it on my 380 with no trouble.
3. I then re-encode it at "Good" setting an play it on my 380 and it stutters.

Same source, same environment, same media, same player, but different result. Only one variable changed: the quality setting checkbox. Something is obviously different in the re-encoded file.

On the other hand....

Could we say that, yes, the re-encoded streams ARE different, but they are, nonetheless, all compliant. The Sony SHOULD be able to handle ANY compliant stream, but seems to be having trouble. So it could very likely be a problem with the internal playback processing in the device.

I'm not uncomfortable with that last paragraph, so... maybe I am willing to concede ;)

And the Toshiba just happens to have the same problem? Well, that's a troubling fact, but as stated earlier in this thread: stuff happens.

[jdobbs]

You may want to check out the chipset of the two players that are having problems. There is a reasonable chance that they are the same. If that is the case it also means that the baseline firmware (before distributer customization) are likely the same.

How about the plethora of other players? I can say that none of mine (Sony S360, Sony S300, and Samsung C5900) have any stuttering issues at all. By your reasoning they don't count? How about the players that are in use by the other several thousand people who are using the BD-RB beta? They don't count either. It doesn't take an Einstein to point the finger at the most likely problem here...

I'm not saying it is impossible that X264 has an issue -- but I am saying that the probability is much higher that it is the player... I can also say that until I can repeat it or I get confirmation from at least a couple more people - this is not considered a bug to me.

[Sharc]

Does anyone know if the questionable players are Cinavia infected? :devil:

[laserfan]

No Cinavia according to a post here (http://www.avforums.com/forums/14447122-post158.html), though I dunno that's relevant in any way.

Perhaps shon3i will pursue his hunch and yet uncover a problem with x264, but now that he's lost his test platform (Robert's S380) I'm not sure how he might confirm a fix.

[RobertM]

now that he's lost his test platform (Robert's S380)

No, I've still got the 380. I have a couple of weeks before I have to return it. And I'd be glad to continue running tests on it if Shon3i asks.

[laserfan]

No, I've still got the 380. I have a couple of weeks before I have to return it. And I'd be glad to continue running tests on it if Shon3i asks.
Your persistence is to be admired, sir! A final thought I have (sorry lost track if this has been tried before) is that maybe the 380 doesn't like x264's b-pyramid.

Give --b-pyramid none a try in BD-RB's TWEAK_ONE/TWO_PASS lines and see if it takes and makes any difference. Long shot but ya never know...

[RobertM]

Give --b-pyramid none a try in BD-RB's TWEAK_ONE/TWO_PASS lines and see if it takes and makes any difference. Long shot but ya never know

Well, at getting rid of stutters, it works like a charm :)

But I didn't bother with the "tweak" statements, because I'm not sure if it matters where I put those in my BD-REBUILDER.INI file, or if those commands will "take" anyway (I read that BD-Rebuilder will ignore any tweak commands that it doesn't like). So what I did was to create a batch file to do the x264 re-encoding completely outside of BD-Rebuilder. I cut/pasted from a BDR LASTCMD.TXT file, then edited the contents.

Here is the content of the batch file that I created for the "35" point:


D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset ultrafast --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35a_ULTRAFAST.AVS.264"

D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset ultrafast --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --b-pyramid none --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35b_ULTRAFAST_NP.AVS.264"

D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset superfast --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35c_SUPERFAST.AVS.264"

D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset superfast --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --b-pyramid none --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35d_SUPERFAST_NP.AVS.264"

D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset medium --bluray-compat --b-pyramid strict --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35e_MEDIUM.AVS.264"

D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset medium --bluray-compat --b-pyramid strict --weightp 1 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --b-pyramid none --thread-input --output "D:\BD-REBUILDS\BUILDS\WORKFILES\35f_MEDIUM_NP.AVS.264"


You can see that it creates 6 iterations of the clip. I used 3 encoding qualities: ultrafast (which corresponds with the BDR "high speed" option), superfast (=BDR "good") and medium (=BDR "high quality"). For each quality setting I also run another iteration with "--b-pyramid none" added at the end. Note that the medium quality iterations (the last 2) already contain a reference to "--b-pyramid", but I believe that my addition at the end overwrites the original, because it appears later in the option string.

I did the same thing for my test points 148 and 149.

After the 3 re-encode batch files were finished I used tsMuxeR to re-combine the new video files with their original audio. Then I tested all of the new m2ts streams on both the Sony BDP-S580 and S380 players. On the S580 there were no stutters in evidence. On the S380:

35a_ultrafast: GOOD
35b_Ultrafast_np: GOOD
35c_Superfast: BAD
35d_Superfast_np: GOOD
35e_Medium: GOOD
35f_Medium_np: GOOD

148a_ultrafast: GOOD
148b_Ultrafast_np: GOOD
148c_Superfast: BAD
148d_Superfast_np: GOOD
148e_Medium: BAD
148f_Medium_np: GOOD

149a_ultrafast: GOOD
149b_Ultrafast_np: GOOD
149c_Superfast: GOOD
149d_Superfast_np: GOOD
149e_Medium: BAD
149f_Medium_np: GOOD

I took a video of each set of tests on my S380 player, so that anyone who is interested can see what the stutters look like on this player. It is just a video of my screen, so the quality is poor, but the stutters are noticeable. Video of Point 35 (http://www.mediafire.com/download.php?jjhybskyduww7nk) with a stutter at 0:49 (compare with 1:01). Point 148 (http://www.mediafire.com/download.php?icjsel9mrnn05hm) with stutters at 0:30 and 0:54 (but not at 0:42 and 1:06). Point 149 (http://www.mediafire.com/download.php?apm56xdtbsonnjo) with a stutter at 0:56 (but not at 1:08).

So it seems like this phenomenon is likely related to the use of b-pyramids. According the the x264 MeWiki (not sure how trustworthy this is):
b-pyramid

Default: normal
<snip>
If you're encoding for Blu-ray, use 'none' or 'strict'.

It would seem like setting it to "none" wouldn't break any rules. Perhaps turning it off yields a bit less compression?

Now, all this might seem a little pointless to everyone else, because this is only my problem, and I now have an S580 that doesn't exhibit these symptoms. But I still have a nagging feeling that a re-encoded stream would be better if it could play on as many devices as possible without trouble. I'd be happy to trade of a smidgen of compression space to have greater confidence that the disc will playback on both good players and also those with buggy firmware. Or maybe it is a bigger tradeoff than that -- I dunno.


[edit]Sorry, Laser. Forgot to say thanks for the suggestion.

[jdobbs]

@RobertM

BD-RB ignores only the TWEAK commands that could make the encode fail Blu-ray standards. There is a special switch for B-PYRAMID, though.

Just add this to your INI file:

B_PYRAMID=0

It is documented in HIDDENOPTS.TXT. If this is what is causing your "stutter", then it is definitely a bug in the firmware of the S380 -- as "--b-pyramid strict" should be supported within the blu-ray standard.

[shon3i]

I thinking to recommend same and even for weightp. If this fix problem will be nice to test aslo to test with some revision before 1936, to see is this revision change something.

[jdobbs]

I thinking to recommend same and even for weightp. If this fix problem will be nice to test aslo to test with some revision before 1936, to see is this revision change something. It defaults to "1" on Dark Shikari's recommendation (http://forum.doom9.org/showthread.php?p=1461792#post1461792). It can be changed also with the "WEIGHTP=n" INI setting. I haven't gotten any reports that indicated issues.

[Sharc]

Doesn`t --bluray-compat force --weightp 1 anyway?

[shon3i]

It defaults to "1" on Dark Shikari's recommendation (http://forum.doom9.org/showthread.php?p=1461792#post1461792). It can be changed also with the "WEIGHTP=n" INI setting. I haven't gotten any reports that indicated issues.
as you maybe know --bluray-compat option will automatically assume some of options. You don't need anymore to specify these in cmd, and you can't encode without --bluray-compat because utilise all blu-ray hacks. Options that will be set automatically are bframe<=3, ref<=4 for 1080, ref<=6 for 720/576/480, bpyramid<=strict, weightp<=1, aud=1, nalhrd=vbr. So it's all already default now.

[shon3i]

Doesn`t --bluray-compat force --weightp 1 anyway?
Yes but can be lowered to 0 explicitly :)

[laserfan]

Well, at getting rid of stutters, it works like a charm...

It would seem like setting it to "none" wouldn't break any rules. Perhaps turning it off yields a bit less compression?

[edit]Sorry, Laser. Forgot to say thanks for the suggestion.
I had a hunch cuz b-pyramid is one thing that Sony's DVD Architect Pro doesn't like, and the symptom is that although DVDAP will mux the x264 output apparently OK, on playback some frames are played out-of-order (giving the appearance of stutter). I dunno what to make of your seeing it only a few times/movie on just a handful of movies--maybe it has to occur on an otherwise smooth pan in order to see it or some such.

No it doesn't break any BD rules to turn it off, and I've read only that b-pyramid can help quality at lower bitrates, but not appreciably at anything we'd be likely to use and certainly not at 28000Kbps. I've been going back & forth at turning it off vs. leaving it alone (on) but after your experience I'm just gonna turn the bloody thing off for good. If DVDAP doesn't like it and the Sony 380 too, who knows where else it might rear its jittery head. Both with and without, my x264 encodings always look spectacular, so I will do without.

Glad you stuck with this Robert and that I could help you find the culprit. :)

[jdobbs]

as you maybe know --bluray-compat option will automatically assume some of options. You don't need anymore to specify these in cmd, and you can't encode without --bluray-compat because utilise all blu-ray hacks. Options that will be set automatically are bframe<=3, ref<=4 for 1080, ref<=6 for 720/576/480, bpyramid<=strict, weightp<=1, aud=1, nalhrd=vbr. So it's all already default now. Of course, on the other hand, they are fine the way they are -- and I like explicit settings.

[Video Dude]

No it doesn't break any BD rules to turn it off, and I've read only that b-pyramid can help quality at lower bitrates, but not appreciably at anything we'd be likely to use and certainly not at 28000Kbps. I've been going back & forth at turning it off vs. leaving it alone (on) but after your experience I'm just gonna turn the bloody thing off for good. If DVDAP doesn't like it and the Sony 380 too, who knows where else it might rear its jittery head. Both with and without, my x264 encodings always look spectacular, so I will do without.


I was searching the forum for b-pyramid and found this post by Dark Shikari. It's from 2009, I don't know if it is still relevant.

http://forum.doom9.org/showpost.php?p=1338897&postcount=13

[Ghitulescu]

Since B-pyramids presence increases the amount of video data to be buffered in order to get one decoded frame, not all standalones, where the memory is expensive and because of this scarcely used, may not 100% cope with such streams, the insufficiently decoded frame being dropped out (stutter) or repeated.
IIRC the old Sonies could cope with b-pyramids, IIRC Pannnies too, however, the Pioneers couldn't.
One doesn't have this issue on a PC (that is BD compliant in terms of HW).

[RobertM]

Since B-pyramids presence increases the amount of video data to be buffered in order to get one decoded frame, not all standalones, where the memory is expensive and because of this scarcely used, may not 100% cope with such streams

The BDP-S380 it the entry BluRay machine for Sony, while the S580 is a 3D machine. So, presumably, the S580 would have to have greater horsepower under the hood, and that would work to support your argument.

[jdobbs]

Either way, of course, it's a problem within the player -- which isn't what this subforum is really about.

[Ghitulescu]

Either way, of course, it's a problem within the player -- which isn't what this subforum is really about.

Unless B-pyramids or Refs settings are specifically mentioned in the Blu-ray standards (I know only of Refs) - in other words the players accepting relaxed settings are doing us a favour, while the others are simply 100% compliant. Then this is the right forum ...

[RobertM]

which isn't what this subforum is really about

I hear you. But I already conducted one last set of tests, so I'll present those observations now and let it rest after that.



I duplicated my previous panel of tests for point 35, but this time using x264 versions 1913 and 1937. Here are my observations:

x264 version 1913 1937 1995

35a_ultrafast GOOD GOOD GOOD
35b_Ultrafast_np GOOD GOOD GOOD
35c_Superfast BAD BAD BAD
35d_Superfast_np GOOD GOOD GOOD
35e_Medium GOOD GOOD GOOD
35f_Medium_np GOOD GOOD GOOD

So, no difference that I can see.


I then did another panel, using x264-1995, to test the "weightp" setting. I removed the reference to b-pyramids and set "weightp" to 0. Like so:
D:\BD-Rebuilds\Tools\BD_Rebuilder_3802\tools\x264.exe "D:\BD-REBUILDS\BUILDS\QUANTUM_35_DEMUX\00000.track_4113.264" --preset superfast --weightp 0 --qpmin=0 --bitrate 32000 --level 4.1 --sar 1:1 --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 32000 --threads auto --slices 4 --thread-input --output "D:\BD-REBUILDS\BUILDS\TEMP\1995-wp0\35d_SUPERFAST_WP0.AVS.264"

Observations:
35a_ultrafast GOOD
35b_Ultrafast_wp0 GOOD
35c_Superfast BAD
35d_Superfast_wp0 BAD
35e_Medium GOOD
35f_Medium_wp0 GOOD

So, again, no difference.


One last test that I thought of was to take one of the stuttering streams (previously encoded with default b-pyramid setting) and then re-encode it again using the "--b-pyramid none" option. If this works, then it makes a pretty clear argument that there is nothing wrong with data in stuttering stream, since it could be "fixed" for the s380 by simply re-encoding again with an "S380 friendly" setting. I did 4 tests, using the output of each as the input to the next.

Observations:
35c-superfast: BAD
35c2-superfast-np: GOOD
35c3-superfast: GOOD
35c4-superfast-np: GOOD

I had actually expected the stutter might reappear in 35c3, since I was not using the "--b-pyramid none" option when re-encoding 35c2.

A final observation: When I was re-muxing these streams with tsMuxeR, on my first go-around I forgot to set the output to "M2TS muxing", and, instead, it was set to "TS muxing". None of the *.ts streams stuttered on the S380. Not even 35c-superfast, which DID stutter when using the "M2TS muxing" setting.


So, with that,... thanks to all who offered help and suggestions. I'm quite satisfied now with how BD-Rebuilder is working for me.

[jdobbs]

Unless B-pyramids or Refs settings are specifically mentioned in the Blu-ray standards (I know only of Refs) - in other words the players accepting relaxed settings are doing us a favour, while the others are simply 100% compliant. Then this is the right forum ... Referenced B-Frames are specifically mentioned in the standard. While Dark Shikari would be a better source than I -- as I understand it (and I'm pretty sure I'm right) b-pyramid is just a way of doing that. As long as it follows the rules outlined in the standard (and I've been told "strict" does), it should be supported. If it isn't -- the playback device would be at fault.

That doesn't mean I may not change "none" to the default b-pyramid setting for greater compatibility -- but it does mean I shouldn't have to.

[laserfan]

When I was re-muxing these streams with tsMuxeR, on my first go-around I forgot to set the output to "M2TS muxing", and, instead, it was set to "TS muxing". None of the *.ts streams stuttered on the S380. Not even 35c-superfast, which DID stutter when using the "M2TS muxing" setting.
Having first seen an issue with a BD (m2ts) muxed output from Sony DVDAP which stuttered (on a PC sw player iirc), while tsMuxeR output did not, it seems to me we have 3 variables here, more than I can get my head around:

1) x264 output (b-pyramid strict vs none, I've not looked at what "superfast" does)
2) How muxers treat x264 b-pyramid encodings (tsMuxeR, Sony DVDA, EasyBD?)
3) Playback method (SAPs and PC players)

If the only standalone player on Planet Earth that exposes any issues is the 380, the next step would be for an x264 development guru to get interested to pursue this, and RobertM you send your player to him! I'm kidding! :)

[jdobbs]

TS muxing and M2TS muxing should be the same except for the 4 byte timestamp (making each packet 192 bytes rather than 188 bytes). But since TS isn't a part of the blu-ray standard, the routine the device uses to play it might change.

[RobertM]

If the only standalone player on Planet Earth that exposes any issues is the 380

The Toshiba 1200 shows the stutters too. But as JDobbs pointed out, they may well share some internals.

I'm not planning on doing any more testing surrounding this issue -- not for myself anyway -- I'm going to just use the "B_PYRAMID=0" option and be happy. But if some smarter person than me has a suggestion for another meaningful test then I'll be only too happy to comply.

[thevez]

I have the same bd player and i have the same problem as you. Stuttering always happens after a scene change in the movie. My unenlightened guess is that might be when the bitrate is highest. I am looking at the parameters for X264 and i am wondering if the SCENECUT parameter could be used at our advantage in this matter

And btw : My sincere thanks go out to jdobbs for this wonderful piece of software and also for his patience in coping with us

[RobertM]

Is this happening with a current version of BD-RB?

We found that the problem seemed to be related to the usage of the "b-pyramid" command. Once I disabled "b-pyramids" (refer to the hiddenopts file in the BD-RB folder) the stuttering went away for me. JDobbs made a change, months ago, to change the default setting to disabled, so I am surprised that this problem would still be showing up. Perhaps it is not the same issue. I upgraded to a different Bluray player, which doesn't exhibit this problem, so I can no longer conduct any tests regarding this issue.

[thevez]

I am using 39.04 but as you did I will upgrade my Bluray player. Just wanted to let you know it happened to someone else too :) But all you research and findings were very interesting. It shows also that JDobbs cares about his "baby" and its users

[jdobbs]

Is this happening with a current version of BD-RB?

We found that the problem seemed to be related to the usage of the "b-pyramid" command. Once I disabled "b-pyramids" (refer to the hiddenopts file in the BD-RB folder) the stuttering went away for me. JDobbs made a change, months ago, to change the default setting to disabled, so I am surprised that this problem would still be showing up. Perhaps it is not the same issue. I upgraded to a different Bluray player, which doesn't exhibit this problem, so I can no longer conduct any tests regarding this issue. B-Pyramid is definitely disabled by default.