Log in

View Full Version : x264 weightp vs mainconcept


seeker010
25th July 2014, 22:36
been a lurker here for a while, but had a question that's been bugging me. hope the experts can weight in.

I have a Geforce 7300 go that supports the h264 mocomp acceleration level. Both WMP and the Modern UI Video app in windows 8 can take advantage of it (all modern ui apps actually).

What I've found is that when I encode 1 video using Adobe Premiere Elements (using the 64bit avisynth plugin) with the ipad target (haven't tried any other targets), the video plays back relatively artifact free.

However, if I use x264 (preset medium level 3.1 main), some frames have some corrupted blocks. If I use tune fastdecode, the corruption goes away, so I tried to toggle cabac, deblock, weightp and no-weightb individually to see with switch was responsible. I had thought it was the deblock parameter, but it was actually weightp. Even setting it to 1 does not remove the corruption. Only setting it to 0 (totally disabling it) helps 99%. combining weightp 0 and no-weightb gives me about as artifact free a picture as the Premiere encode.

When I check the Premiere encoded file using AVInaptic, it says weighted p frame prediction was enabled, but weighted b was not.

So my question is, is there a fundamental difference between how the 2 encoders handle weighted P frame prediction?

I know, geforce 7300 go is ancient, driver is bugged (e.g. bsod when trying to decode 1920x1080 wmv-hd, but works fine with anamorphic 1440x1080 wmvhd), I can use the lavfilter software decoder, I can just disable weightp, just stick using premiere, etc etc. I know all that, I'm just curious about the problem, or if there are some other combination of switches that allows a non zero value for weightp that fixes the corruption on decode.

xooyoozoo
25th July 2014, 23:27
This might be relevant. (http://x264dev.multimedia.cx/archives/212)

seeker010
26th July 2014, 02:18
This might be relevant. (http://x264dev.multimedia.cx/archives/212)

thanks. that was informative. but still leaves me puzzled why mainconcept's weight p frame prediction works.

F J Walter
28th July 2014, 01:19
I don't know the full details but the "broken" decoders take shortcuts in regard to how they refer to reference frames that work fine for the most part, but start showing their limitations with some of the ways weighted prediction can be used.

"Conservative" encoders don't use weighted prediction in such a way that would harm these decoders. This would also mean that they miss out on a tiny bit of efficiency.

seeker010
30th July 2014, 05:24
I don't know the full details but the "broken" decoders take shortcuts in regard to how they refer to reference frames that work fine for the most part, but start showing their limitations with some of the ways weighted prediction can be used.

"Conservative" encoders don't use weighted prediction in such a way that would harm these decoders. This would also mean that they miss out on a tiny bit of efficiency.

gotcha. so really it would be like a 0.5 blind and deaf offset --weightp setting for really broken decoders, which is hardly worth the effort since all modern day decoders don't have the problem.