weightp coreavc artifacts corruption

[Audionut]

New x264 builds show visual artifacts caused by weightp 2.

Reason, coreavc doesn't support it yet. Will in Version 2.

Solution = VLC player or ffdshow decoder or Media Player Classic Home Theatre

Example,
http://img687.imageshack.us/img687/1263/snap.png

Warning: This post will only be helpful to those who can follow rule 1a.

[CruNcher]

This is a problem many Mobile Devices won't support weightp=2 it seems, so all content you create with it wont probably be interoperable with most Hardware Decoders (or embedded codecs running on DSPs) on the market currently (talking about all the current available 720p HDMI Pmps for example). Weightp=1 seems to be the same Ateme uses since the beginning and have no problems but with X264 weightp=2 streams i can see a bulk of issues coming if it get's used by more and more people i guess it's gonna get problematic once again for the ecosystem around H.264, especially already on the market solutions will be affected, not sure if this is a good thing @ all maybe it would be better to skip weightp=2 completely in terms of interoperability.

I mean it isn't a good thing at all for the user and content producers if it brakes so many Devices already on the market, and be sure not everyone of those will be updated only to support this like CoreCodec now does it. I find this a very Problematic situation if it's really no bug i saw these problems already but visually i see black blocks not like here distored blocks which seem to use weightp=2 i really hope it's a bug (or miscompiled X264 streams floating around, will do my own tests soon) .
This seems to have the potential to become the new Qpel, GMC disaster we had with ASP just in another incarnation we just slowly moving out of the High Profile problem and now another one gets created that seems even more problematic.

[ajp_anton]

Warning: This post will only be helpful to those who can follow rule 1a.Those who follow 1a would've found this info on at least 5 places on this forum even without this.

[unschuldsengel]

I am having the same issue with Flash Player :confused:

[G_M_C]

[...]
This seems to have the potential to become the new Qpel, GMC disaster we had with ASP just in another incarnation we just slowly moving out of the High Profile problem and now another one gets created that seems even more problematic.

Dont know; I've been expirimenting. CoreAVC, ffdshow and others dont seem to accept weightp correctly. But my STD (panasonic BD30) accepts them fine. The refs-problem i posted before hasn't shown up any more (it seems i did the test incorrectly, so i'm running the same test again to rule out errors i made before).

So in this case its not like the GMC we had before, where computers accepted gmc, and STD's didn't. It's the other way around now, and computer-software can be fixed.

And anyway; We were already warned about the problem OP/Audionut mentioned. DS wrote about this potential problem on the x264 GIT even before weightp was added.

[nurbs]

ffdshow works without problems for me.

[Dark Shikari]

Dont know; I've been expirimenting. CoreAVC, ffdshow and others dont seem to accept weightp correctly. But my STD (panasonic BD30) accepts them fine.What the heck are you on about?

We've tested dozens of software and hardware decoders. There are a grand total of two that fail: CoreAVC and the Apple TV. Basically everything else works.

[Sharc]

No problems discovered so far with CoreAVC 1.9.5 using CUDA.

[LoRd_MuldeR]

No problems discovered so far with CoreAVC 1.9.5 using CUDA.

...because CoreAVC with CUDA enabled lets do NVIDIA's VP2 hardware decoder all the work :p

[CpT]

I am having the same issue with Flash Player :confused:


So am I. Exact same issue as shown above in first post.
I can post a screenshot if needed.

Edit: I should add I'm not using coreavc. This seems to traverse across multiple gui's, seems its an x264 issue.

[Dark Shikari]

I already tested this with Flash. It works perfectly (http://mirror05.x264.nl/Dark/Flash/weightp.html). If it didn't, I wouldn't have made it default.

[LoRd_MuldeR]

I already tested this with Flash. It works perfectly (http://mirror05.x264.nl/Dark/Flash/weightp.html). If it didn't, I wouldn't have made it default.

Your sample works perfectly fine with Flash 10.0.32.18, maybe some old/outdated version had problems? :confused:

[CpT]

This has been tested in 2 different flash players and I'm of course using the latest flash.

It can be seen here http://vizmu.com/player/flash/test2.html
Scrub to 50 seconds, it's shortly after that @ 56-59

working version - scrub to 50 seconds.
http://vizmu.com/movie-trailers/724/129861/


When I disable weighted p its fine. It seems to be very specific to the scene type.

[LoRd_MuldeR]

It can be seen here http://vizmu.com/movie-trailers/724/129861/
Scrub to 50 seconds, it's shortly after that.

403 Forbidden

[CpT]

lol, Where do u live? We only allow viewing from a few countries.

[Dark Shikari]

Nothing to do with weightp; looks like a corrupt file to me. Stop using miscompiled builds of x264.

If you have the latest x264 and you don't think your build is miscompiled, give me the exact settings and input file necessary to replicate the problem.

[CpT]

What build do you suggest for 32 bit. I've tried the last few versions from http://x264.nl/ and jeeb's and rack's. All have the same result unless weighted p is disabled.

Edit: Getting settings together for you now. Edit:nvm

[Dark Shikari]

What build do you suggest for 32 bit. I've tried the last few versions from http://x264.nl/ and jeeb's and rack's. All have the same result unless weighted p is disabled.Nevermind; I was wrong, JM says the encode is not corrupt.

Does the problem still occur if you encode with weightp and --nf?

[CpT]

Testing that now.

Edit: just tested, same results with --nf + weighted p

[LoRd_MuldeR]

lol, Where do u live? We only allow viewing from a few countries.

Germany :angry:

[Dark Shikari]

Testing that now.

Edit: just tested, same results with --nf + weighted pUpload it somewhere...

[CpT]

Here's a test page
http://vizmu.com/player/flash/test.html

Direct link,
http://vizmu.com/player/2012-yellostone.mp4

[Chengbin]

What the heck are you on about?

We've tested dozens of software and hardware decoders. There are a grand total of two that fail: CoreAVC and the Apple TV. Basically everything else works.

Make that 5.

All Archos PMPs do not handle weightp properly.

[Dark Shikari]

Make that 5.

All Archos PMPs do not handle weightp properly.Are they broken with weightp, or with dupes? In other words, do they work with --weightp 2 --ref 1?

[Dark Shikari]

Here's a test page
http://vizmu.com/player/flash/test.html

Direct link,
http://vizmu.com/player/2012-yellostone.mp4More things to test:

--weightp 2 --nf --direct temporal
--weightp 2 --nf --direct none
--weightp 2 --nf --bframes 0
--weightp 2 --direct temporal
--weightp 2 --direct none
--weightp 2 --bframes 0

Which ones of those work?

I have a hunch that Flash's direct calculation is broken.

[CpT]

Just tried --weightp 2 --ref 1 and it works

see below, scrub to 50 seconds
http://vizmu.com/player/flash/test.html

direct download -sorry for speed cap.
http://vizmu.com/player/2012-yellostone2.mp4

[Chengbin]

Are they broken with weightp, or with dupes? In other words, do they work with --weightp 2 --ref 1?

Anything other than ref 1 will not work.

[Dark Shikari]

Anything other than ref 1 will not work.Which means it's broken with dupes, not with weightp.

[Chengbin]

Which means it's broken with dupes, not with weightp.

I thought 64bit wasn't broken.

Also, they play fine with ffmpeg-mt.

Is it still duped?

[CpT]

LOL,

I enabled mbtree and it works with 3 ref's + mixed ref's and weighted p @ 2.

So weighted p requires mbtree for flash usage?

[Dark Shikari]

LOL,

I enabled mbtree and it works with 3 ref's + mixed ref's and weighted p @ 2.

So weighted p requires mbtree for flash usage?I find that extraordinarily dubious... MB-tree doesn't change anything with regards to the features used on a bitstream level.

[unschuldsengel]

I enabled mbtree and it works with 3 ref's + mixed ref's and weighted p @ 2.

I have mbtree always on and with weightedp=2 the problem occurs. also with 3 refs.

[CpT]

I have mbtree always on and with weightedp=2 the problem occurs. also with 3 refs.

Are you talking about in flash or elseware.

I'm also running a longer test atm to see if I can reproduce it.

Edit: if I am able to reproduce it. mbtree on = no issue,
But mbtree off + same exact settings the issue occurs.

I'm done testing for for now.

[unschuldsengel]

Are you talking about in flash or elseware

Just Flash, the videos worke fine in VLC etc.

[prOnorama]

lol, Where do u live? We only allow viewing from a few countries.

403 Forbidden here also (Netherlands)

Maybe not use your site (wtf vizmu? lol it sounds like a rodent) but a site that's internationally accessible. Really Germany and The Netherlands aren't the bush-bush geographically or interwebz-wise (http://en.wikipedia.org/wiki/List_of_Internet_Exchange_Points_by_size) also *cough* x264.nl should give a hint

[CpT]

403 Forbidden here also (Netherlands)
(wtf vizmu? lol it sounds like a rodent)

This coming from a guy named prOnoram.

You should have access now btw, So should you Lord Mulder.

[CruNcher]

The Same black blocks on TIs Decoder (Archos 5IT Omap 3440) @ the 5th second like in Chengbins sample :(

[LoRd_MuldeR]

It can be seen here http://vizmu.com/movie-trailers/724/129861/
Scrub to 50 seconds, it's shortly after that.

You should have access now btw, So should you Lord Mulder.

Yes, it works now. Thanks. But I'm unable to spot the distortions around 0:50 in that sample :confused:

[CpT]

Yes, it works now. Thanks. But I'm unable to spot the distortions around 0:50 :confused:

I uploaded a working version to the actual site. Then updated the links in my first post about it.

It can be seen here http://vizmu.com/player/flash/test2.html
Scrub to 50 seconds, it's shortly after that @ 56-59

working version - scrub to 50 seconds.
http://vizmu.com/movie-trailers/724/129861/

[LoRd_MuldeR]

I uploaded a working version to the actual site. Then updated the links in my first post about it.

It can be seen here http://vizmu.com/player/flash/test2.html
Scrub to 50 seconds, it's shortly after that @ 56-59

Oh, yes. Now I can reproduce the distortions in the "explosion" scene :(

[Dark Shikari]

Flash is a broken piece of crap. This is somehow news?

[CruNcher]

CpT your site doesn't seem to work with firefox 3.7a1 ? i see only a white screen with no video playing strange

The Problems don't occur with the 50 second here but already start @ the 6 second and appear some frame then some frame are clear and then you see them (black blocks) again totally unwatchable Mobile this way :(

PS: I hope TI is gonna fix this weightp problem in their current CX64+ DSP Decoder fast, and i wonder if current Tegra has also issues with it (Zune HD, Samsung YP-M1)

[CpT]

Flash is a broken piece of crap. This is somehow news?

/signed! Its a royal pain that's for sure.

@Cruncher
Sound like that version of ff is borked. I don't test with/for pre-release or beta versions of anything. By the time it comes out the whole thing will have been rewritten 100 times over. And tbh I don't give a crap about Mobile viewing.

Sorry for getting OT.

[Astrophizz]

Flash is a broken piece of crap. This is somehow news?

You said it works perfectly with flash and now you say the fact that it doesn't work isn't news? So you changed your stance?

[jmartinr]

@CpT
This one: http://vizmu.com/movie-trailers/812/129863/ shows corruption too at 1:10.

[CpT]

@jmartinr
Yea I'm sure there's quite a few. I ran a bunch of tests but checked emm all in vlc. -apparently was a mistake on my part.

I'm re-encoding that one as I type this. When I get a chance I'll search for more. Thanks for finding it.

[Dark Shikari]

You said it works perfectly with flash and now you say the fact that it doesn't work isn't news? So you changed your stance?"Changed my stance"? What, is this a political issue or something?

I saw evidence that it was broken and concluded that it was broken. What else is there to it?

[Astrophizz]

I worded that wrong, sorry. I just thought it was odd that your first time you said that flash had problems with weightp you said it as though it wasn't anything new.

[Dark Shikari]

I worded that wrong, sorry. I just thought it was odd that your first time you said that flash had problems with weightp you said it as though it wasn't anything new.Flash having problems period isn't anything new ;)

[Astrophizz]

True :)

[CruNcher]

But it's not only flash Mainconcepts Decoder that is affected here. ON which Hardware STB solutions did you evaluated it, is there a list of Chips that are working ?

[plonk420]

just wanted to report --weightp 2 works on PS3 (like 10 refs)

[Dark Shikari]

But it's not only flash Mainconcepts Decoder that is affected here. ON which Hardware STB solutions did you evaluated it, is there a list of Chips that are working ?How about a list of chips that are not working?

The likelihood of a hardware decoder failing to abide by the specification is rather low given the relative thoroughness that ASIC developers give to following the specification.

[CruNcher]

Ok so in case of TIs Omap 3440 Decoder currently used on their DSP it's a Software Implementation bug, i wonder if it's also failing on the new Motorala Droid i guess it uses the same Decoder Core from TI or one of TI's partner my guess somehow is the Decoder is Inginients one :)

[Dark Shikari]

Ok so in case of TIs Omap 3440 Decoder currently used on their DSP it's a Software Implementation bugIIRC the iPhone 3GS uses the OMAP and it decodes things just fine.

[CruNcher]

Nope it uses Samsung S5PC100 Chip (though also Cortex A8 based) and their Decoder Research as seen here http://www.youtube.com/watch?v=tSrsGPgIsEQ and here http://www.youtube.com/watch?v=zEWrV8LuX04

Hopefully we gonna see CoreCodecs own implementation running on the A8 or even better on the A8 + on the CX64+ beagleboard way :)

[Dark Shikari]

It turns out that at least one of the problematic streams (not the "2012" trailer though) contained invalid offsets due to at least one, if not two, bugs in weightp's analysis. This means that most of the problematic decoders probably work just fine.

A fix will be incoming as soon as I can get a hold of Dylan.

[Chengbin]

This means that most of the problematic decoders probably work just fine.

A fix will be incoming as soon as I can get a hold of Dylan.

So after this fix the problematic decoders, like CoreAVC 1.9.5 and Archos PMPs, can play streams with weightp 2 without problems?

[Dark Shikari]

So after this fix the problematic decoders, like CoreAVC 1.9.5 and Archos PMPs, can play streams with weightp 2 without problems?Not all, just some. Flash and CoreAVC 1.9.5 are still broken.

[poisondeathray]

Has Adobe been notified RE: flash and recent x264 changes?

Lots of websites use x264 e.g. vimeo, youtube etc... , maybe not the most recent builds, but it could cause issues soon...

[Dark Shikari]

Has Adobe been notified RE: flash and recent x264 changes?Adobe has been notified.

[LoRd_MuldeR]

I uploaded a working version to the actual site. Then updated the links in my first post about it.

It can be seen here http://vizmu.com/player/flash/test2.html
Scrub to 50 seconds, it's shortly after that @ 56-59

Seems like your distortions are gone in Flash Player 10.1 Prerelease (10,1,51,45).

Download:
http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_p1_plugin_111709.exe

[Dark Shikari]

That was fast, eh? ;)

[elguaxo]

Great news! :)

[lexor]

Adobe release notes say something along the line of using hardware acceleration. So did Adobe fix anything, or did they just get DXVA to fix it for them (kinda like coreavc 1.9.5 also works flawlessly... if you use CUDA)? Either way, good to know it's fixed, somehow.

Less work for Atom, more work for ION :) my HTPC like, very much.

[LoRd_MuldeR]

Adobe release notes say something along the line of using hardware acceleration. So did Adobe fix anything, or did they just get DXVA to fix it for them (kinda like coreavc 1.9.5 also works flawlessly... if you use CUDA)? Either way, good to know it's fixed, somehow.

Well, I checked with "Enable Hardware Acceleration" and without it. There are no artifacts with both of them :)

But can't say for sure that DXVA isn't involved anyway.

However I noticed that with "Enable Hardware Acceleration" the scaling quality is really bad. Looks like Point Resize.

[Killerattacks]

@lexor
If you can trust AnandTech then 10.1 uses DXVA (for the Hardware acceleration):

http://anandtech.com/video/showdoc.aspx?i=3678&p=1

ATI users are still out of luck it seems, since the GPU-acceleration only works with HD4xxx cards (or HD3xxx IGP) and Catalyst 9.11 driver which isn't out yet. The Catalyst 9.11 beta driver doesn't work (tested this myself).

[Dark Shikari]

Adobe release notes say something along the line of using hardware acceleration. So did Adobe fix anything, or did they just get DXVA to fix it for them (kinda like coreavc 1.9.5 also works flawlessly... if you use CUDA)? Either way, good to know it's fixed, somehow.I confirmed with Adobe that the software decoder itself is fixed.

[CruNcher]

x264 0.72.1222 d0ee6f8
built on Aug 20 2009, gcc: 3.4.6

encoded 2419 frames, 11.20 fps, 2949.58 kb/s

x264 0.79.1342 e8501ef
built on Nov 16 2009, gcc: 3.4.6

encoded 2419 frames, 8.73 fps, 2951.58 kb/s

Whats going on i triple checked this and it definitely got a lot slower @ crf, is really the weightp addition the cause of this slowdown ?

im using this encoding settings

x264.exe "%SourceVideo%" --crf 24 --preset veryfast --profile high --cabac -m 3 --no-deblock --weightp 2 --8x8dct -b 3 --aq-mode 2 --ssim --psnr --partitions i8x8,i4x4,p8x8 -o "%SourceVideo%.mp4"

i also have to explicitly force --weightp 2 else only wpredb seems to be used but no wpredp

here the analyse data i couldn't see any difference visually between the encodes but first realized this heavy slowdown :( (Ben Waggoners Dreamworks The Island Trailer)

x264 [info]: i16 v,h,dc,p: 35% 26% 16% 23%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 18% 28% 6% 6% 7% 7% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 20% 12% 7% 9% 9% 9% 7% 8%
x264 [info]: Weighted P-Frames: Y:8.4%

[Dark Shikari]

i also have to explicitly force --weightp 2 else only wpredb seems to be used but no wpredpThat's because weightp isn't on when you use preset veryfast. This is intentional.

[CruNcher]

i guessed so, i also tried it now with --weightp 0 and no weightp @ all no big speed difference i gonna try now to see when this was introduced by checking all builds between 1222-1342, i missed a lot :(

PS: it seems the range of the performance drop is somewhere between 1240 (encoded 2419 frames, 9.73 fps, 2941.27 kb/s)-1280 (encoded 2419 frames, 8.92 fps, 2944.83 kb/s)

[hakujin]

Prefer CoreAVC. Is there any way to disable i.e. --weightp 0 to x264 file with weightp enabled, either via MKVMerge or MeGui?

[CruNcher]

Sorry i was a bit to fast with my assumption the Windows cache blinded me, i should have known better that this was impossible ;)

x264 0.72.1232 c8edc12
built on Aug 25 2009, gcc: 3.4.6

x264 [info]: SSIM Mean Y:0.9533577
x264 [info]: PSNR Mean Y:40.359 U:43.930 V:44.165 Avg:41.213 Global:40.136 kb/s:
2925.99

encoded 2419 frames, 9.82 fps, 2926.42 kb/s

x264 0.79.1342 e8501ef
built on Nov 16 2009, gcc: 3.4.6

[WEIGHTP 1]
x264 [info]: SSIM Mean Y:0.9535975
x264 [info]: PSNR Mean Y:40.390 U:43.942 V:44.190 Avg:41.241 Global:40.179 kb/s:
2951.00

encoded 2419 frames, 8.85 fps, 2951.00 kb/s

[WEIGHTP 2]
x264 [info]: SSIM Mean Y:0.9536431
x264 [info]: PSNR Mean Y:40.377 U:43.927 V:44.175 Avg:41.229 Global:40.180 kb/s:
2951.58

encoded 2419 frames, 8.68 fps, 2951.58 kb/s

looks much more real world :)

[PeterLynn]

Sadly, my standalone LG BD370 can't accept weightp correctly anymore. :(

Edit: LG's latest firmware fixed the problem. :)