Slight stuttering in standalone player

[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.