Very weird problem with x264 encode and TotalMedia Theatre 3

[sebazvideo]

I encoded some footage that I shot myself at 23.98 with MeGUI and x264 builds 1564 and 1570 (I started with 1570 but I went back to 1564 just in case 1570 was causing this problem, but it seems to be the same). I built the project using Encore CS4 to a blu-ray folder and then burned to a DVD+RW with Imgburn. I played in my standalone player, the Sony BDP-S300 and it was perfect. It occurred to me to test it also on TotalMedia Theatre 3, and after a minute or so I started getting these horrible artifacts in the pictures linked below.

Trying to rule out different things, I started by playing the BDMV folder from the hard drive in TMT, and the artifacts were still there. So I muxed the original .264 and .ac3 files with TSMuxer, and the artifacts still showed. Then I changed a few parameters and did a few more tests, although I didn't build a BD structure, I just set MeGUI to do an auto-encode to m2ts. No matter what parameters I changed, I still see these artifacts.

One weird thing is that these files only show these artifacts when played on TMT3, not on Splash Lite, Windows Media Player or VLC. The other weird thing is that TMT3 plays perfectly well other files encoded with x264, but they are from older builds.

These are the settings I used in MeGUI, and below are the links to the screen captures (I didn't insert the images directly because they made the text layout too wide):

program --level 4.1 --pass 2 --bitrate 20000 --stats ".stats" --slow-firstpass --keyint 24 --min-keyint 2 --b-pyramid strict --ref 4 --slices 4 --vbv-bufsize 14000 --vbv-maxrate 14500 --no-fast-pskip --aud --nal-hrd vbr --sar 1:1 --output "output" "input"


Cap 1 (http://imgur.com/v3s6P.jpg)

Cap 2 (http://imgur.com/uS53x.jpg)

Cap 3 (http://imgur.com/aUDmV.jpg)

Cap 4 (http://imgur.com/gxPMi.jpg)(this one is the way it's supposed to be)

I have also tried profile 4.0 and no slices, --bframes 4, --ref 4 and some other changes I can't even remember, but these artifacts appear on every single encode when played in TMT3.

Now, can anyone guess what could be causing these artifacts by looking at the captures from TMT3?

Thanks

[Dark Shikari]

Have you tried --weightp 0?

[poisondeathray]

also, won't those buffer values of --vbv-bufsize 14000 --vbv-maxrate 14500 , potentially cause problems with an avg bitrate of 20Mbps ?

[sebazvideo]

Have you tried --weightp 0?

Thanks, I'll try that now and report back in about 30 minutes.

[sebazvideo]

also, won't those buffer values of --vbv-bufsize 14000 --vbv-maxrate 14500 , potentially cause problems with an avg bitrate of 20Mbps ?

Well, I play by ear because I don't know what most of these values mean. I'm trying to encode everything as close as possible to the blu-ray spec, but at the same time to be able to play from DVD media at 20 Mbps which is the highest safe bitrate my blu-ray player will allow, and I hope most others as well. I used to type in 20000 for both --vbv values, guessing they might have to be the same as the bitrate, but I read on many threads that the safe numbers for them are 14000 and 14500, so I changed that.

Can anyone clear that out for me? Are they supposed to be the same as the main bitrate or not?

[Dark Shikari]

Well, I play by ear because I don't know what most of these values mean. I'm trying to encode everything as close as possible to the blu-ray spec, but at the same time to be able to play from DVD media at 20 Mbps which is the highest safe bitrate my blu-ray player will allow, and I hope most others as well. I used to type in 20000 for both --vbv values, guessing they might have to be the same as the bitrate, but I read on many threads that the safe numbers for them are 14000 and 14500, so I changed that.

Can anyone clear that out for me? Are they supposed to be the same as the main bitrate or not?By definition, bitrate cannot be higher than max bitrate (obviously).

[poisondeathray]

Those vbv values were suggested for DVD media, which use lower bitrates than blu-ray media

Some players can play higher bitrates on DVD media, but not all can, and it has to do partly with rotation speed and transfer rate.

To be safe it was suggested to use --vbv-maxrate <15Mbps for DVD media to be compatible with ALL players (several threads recommend this, and many users who provided feedback in the BD-RB and multiavchd threads) , otherwise you get studdering. Remember , this is the rate at which data is entering the buffer. It doesn't make sense if the data leaving is greater than that

You can read about the settings here
http://mewiki.project357.com/wiki/X264_Settings

[sebazvideo]

Have you tried --weightp 0?

Thanks a lot for the tip, that was actually the offending parameter. All perfect now.

[sebazvideo]

Those vbv values were suggested for DVD media, which use lower bitrates than blu-ray media

Some players can play higher bitrates on DVD media, but not all can, and it has to do partly with rotation speed and transfer rate.

To be safe it was suggested to use --vbv-maxrate <15Mbps for DVD media to be compatible with ALL players (several threads recommend this, and many users who provided feedback in the BD-RB and multiavchd threads) , otherwise you get studdering. Remember , this is the rate at which data is entering the buffer. It doesn't make sense if the data leaving is greater than that


So I gather that if I want to use a 20 Mbps bitrate, then VBV maxrate should be also 20 Mbps, but what about VBV buffer? Should it also be 20, or lower?

[kieranrk]

So I gather that if I want to use a 20 Mbps bitrate, then VBV maxrate should be also 20 Mbps, but what about VBV buffer? Should it also be 20, or lower?

It should be whatever the appropriate spec requires.

[sebazvideo]

It should be whatever the appropriate spec requires.

That really doesn't tell me anything.

[shon3i]

@sebazvideo, what buld of x264 you use? i mean where you download from?

[mp3dom]

I think there's something strange in your encode since TMT3 (at least the revision 160 and up) doesn't have any problem regarding weightp 2.
I use it almost always without problems.

[sebazvideo]

@sebazvideo, what buld of x264 you use? i mean where you download from?

I use the one that comes with MeGUI, from the development server, which as of now is 1570

[shon3i]

Because i have same problem with some of "patched" bulds, i recommend you to download from x264.nl and overwrite it in MeGUI and try again to see if happenend again.

[sebazvideo]

Because i have same problem with some of "patched" bulds, i recommend you to download from x264.nl and overwrite it in MeGUI and try again to see if happenend again.

Oh, so the x264 build that comes from the MeGUi dev. servers is not the official one, but a patched one instead?

[LoRd_MuldeR]

Oh, so the x264 build that comes from the MeGUi dev. servers is not the official one, but a patched one instead?

There are no "official" builds. There only is an "official" source code repository. Everybody can make his/her own builds. Or grab one of the various pre-build binaries ;)

But if you have trouble, then it's always a good thing to start with a "vanilla" build, that doesn't contain any experimental patches - builds from http://x264.nl/ for example.

Still a borked built environment (borked compiler, borked libs, etc) may result a buggy build, even without any source code patches.

So in case you encounter weird behavior, it's probably not be the worst idea to try builds from different people or even make your own one (it really is not THAT hard).

[GZZ]

I had the same issue. If I used version r1542 I have no issue with --weightp 2 in TMT3 (all patches), but when I change to version r1563+ I start to get pixel errors in TMT3 (but only when hardware acceleration is on). But I notice that one of the change between r1542 and r1563 is the following:

(r1555)
Remove reordering restrictions from weightp
Apparently the spec does allow two consecutive copies of the same frame in the reference list.
This involves an incredibly ugly hack to wrap around the frame number.
Very slight compression improvement.

I also had issue playing my encoded file on my PS3 with R1563+, it just gives me a black screen but it does play. This didnt happen with version r1542 and previous version.

Does this mean that even if --weightp was set to 2 in previous version (r1542 and before) then it was change to 0 and thats why version r1542 dosnt make pixel errors in TMT3 ?

I created 2 samples, one with R1542 and R1563. The sample is from the movie American Virgin (its not pr0n!). It contains the first 2000 frames of the movie, try load the *.264 files into TMT3 with Hardware Acceleration set to On. From my test the file in the R1542 package plays just perfect, where the one in R1563 has also of pixel errors in all the parts of the screen that are moving. Since TMT3 is the same and I have used the same script for the 2 samples, but different encoder version (r1542 vs r1563) anyone have a clue why this happens, is it because of the above change in code in x264 ?

R1542 (78 mb) (http://hbar.dk/Files/R1542.rar)
R1563 (78 mb) (http://hbar.dk/Files/R1563.rar)

[LoRd_MuldeR]

I had the same issue. If I used version r1542 I have no issue with --weightp 2 in TMT3 (all patches), but when I change to version r1563+ I start to get pixel errors in TMT3 (but only when hardware acceleration is on). But I notice that one of the change between r1542 and r1563 is the following:

(r1555)
Remove reordering restrictions from weightp
Apparently the spec does allow two consecutive copies of the same frame in the reference list.
This involves an incredibly ugly hack to wrap around the frame number.
Very slight compression improvement.

I also had issue playing my encoded file on my PS3 with R1563+, it just gives me a black screen but it does play. This didnt happen with version r1542 and previous version.

Does this mean that even if --weightp was set to 2 in previous version (r1542 and before) then it was change to 0 and thats why version r1542 dosnt make pixel errors in TMT3 ?

Maybe related to this:
http://forum.doom9.org/showthread.php?t=154089

[shon3i]

It seems that CoreAVC have problem too, without CUDA too. I just finished encoding of one move, and whole movie have nasty pixel artifacts. Btw i test patched buld with open-gop, but with closed gop, some blocks are shown during fast forward, that i newer seen.

[GZZ]

Maybe related to this:
http://forum.doom9.org/showthread.php?t=154089

Maybe, but the samples on the above link are removed from the server, so cant test it.

Also I updated my post before I saw your reply, I uploaded 2 samples.

[LoRd_MuldeR]

It seems that CoreAVC have problem too, without CUDA too. I just finished encoding of one move, and whole movie have nasty pixel artifacts.

CoreAVC 1.x is known to be broken with respect to Weight-P for a long time now. Not only after the recent change. And they won't fix it. Only upgrade to 2.0 helps.

Or are you talking about CoreAVC 2.0 here ???

[sebazvideo]

Well, excuse my ignorance, but is not using weightp a big deal? It might be, I'm just asking because I don't even know what it's for, but I'm happy as long as picture quality is still great and it plays everywhere.

[LoRd_MuldeR]

Well, excuse my ignorance, but is not using weightp a big deal? It might be, I'm just asking because I don't even know what it's for, but I'm happy as long as picture quality is still great and it plays everywhere.

It greatly improves fades and probably doesn't do anything outside of fades.

See for details:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=87de2346225721e8ca68a1b59bc87133fc598a42

[GZZ]

I tested this a bit more and it seems since version r1563 playback on my PS3 has been broken when using --weightp 1 or 2, weightp 0 seems to work just fine. When playing movie files with weightp 1 or 2 I get a black screen.

So maybe its a bug in the PS3 software, but why did it work just fine with weightp 2 in previous version of r1563.

Should I go back and keep using R1542 with weightp 2 or should I set it to 0 and use the newest version ??

[GZZ]

I think I found my issue. It was related to my output file. I had set the output file to mkv instead of 264, for some reason playback is broken if I mux a mkv file to avchd instead of a 264 file (same settings used). So is mkv output damage or is it tsmuxer that cant handle mkv correctly when muxing to avchd ?

[shon3i]

So is mkv output damage or is it tsmuxer that cant handle mkv correctly when muxing to avchd ?
neither, you need always to use .264 output for Blu-Ray/AVCHD, because calculations for NAL-HRD/SPS are different for containers.

Or are you talking about CoreAVC 2.0 here ??? 2.0 ofc, i am realy confused, i am doing some other test's to see is there any problem. I will report ASAP

[laserfan]

I just did a new encoding using 1583 (vanilla build from x264.nl) where last I'd used 1542 from JEEB (plain vanilla too afaik) and upon checking my encoding with TMT 3.0 found these nasty pixelation problems. In both cases I'd left weightp to default (which I understand is 2 or Smart Analysis). Now I'm re-doing with --weightp 0 just to double-check, then I will use the original anyway as I'm gonna burn to Blu-ray disc for set-top playback.

I'm just sorta surprised that a.) something changed between 1542 and 1583 that is so very "different" to TMT and b.) that Arcsoft has said "we don't care" to a report to them of problems with decoding x264 w/weightp.

Just when I think I have a good, working PC playback mechanism for checking my encodings! :o

[laserfan]

OK, leaving weightp to default w/x264 versions >1542 causes TMT to choke; changing to --weightp 0 and TMT is fine again. But it seems TMT is OK with weightp 2 if Hardware Acceleration is turned off. Something hinky about HA implementation in TMT I guess.

At any rate it plays in my STB player so I will leave weightp at default and HA turned-off in TMT.

[CruNcher]

hehe i would be not really surprised but if i can guess into the blue i would say 3 letters ;) A T I ?

[laserfan]

hehe i would be not really surprised but if i can guess into the blue i would say 3 letters ;) A T I ?No, in my case four :p N V D A

[kieranrk]

There was some multi-dupe-ref thing in mpc-hc's dxva that needed to be written so perhaps TMT is missing similar code.

[laserfan]

There's a new update to TMT (3.0.1.185) which purports to fix "corruption":

http://www.arcsoft.com/forum/forum_posts.asp?TID=6464&PID=29589&title=totalmedia-theatre-301185-release-notes#29589

Has anyone here tried it yet? I can't download 'til tomorrow else I'd check myself...

[laserfan]

Ok I installed the latest update, and it appears that all the corruption associated with weightp=2 and maybe opengop too has been fixed. With HA turned-on they were unwatchable, with HA turned off they were watchable but "dirty". Both settings are very smooth now.

I updated all-the-way from 161 (to 185) so maybe there were interim fixes I missed, but there you have it afaict. Anyone else notice better imagery with 185?