Slight stuttering in standalone player

[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