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,


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.

[G_M_C]

Originally Posted by CruNcher

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

[Dark Shikari]

Originally Posted by G_M_C

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]

Originally Posted by Sharc

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

[Chengbin]

Originally Posted by Dark Shikari

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]

Originally Posted by Chengbin

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?

[ajp_anton]

Originally Posted by Audionut

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

[CpT]

Originally Posted by unschuldsengel

I am having the same issue with Flash Player

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. If it didn't, I wouldn't have made it default.

[LoRd_MuldeR]

Originally Posted by Dark Shikari

I already tested this with Flash. It works perfectly. 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?

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

[nurbs]

ffdshow works without problems for me.

[CruNcher]

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

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

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

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