CoreAVC decoding bugs - is it really a h.264 compliant decoder?

[TheFluff]

Well, since I've repeatedly tried and failed to report this to CoreCodec, I figured I'd stir up some discussion here instead.

To take things from the beginning... it all started with someone (I think it was Egh) noticing that CoreAVC produced small, seemingly random blocking artefacts in certain places in certain encodes, whereas libavcodec did not. Since this problem was extremely rare (only one known encode it appeared in), I didn't think much of it at the time, but then I encountered it in one of my own encodes and got curious about what caused it. I started investigating the problem in a more systematic fashion, and to my surprise it turned out that in many cases even where there weren't any artefacts blatantly obvious to the naked eye of a casual observer, CoreAVC's output was decidedly different from ffdshow's, even with both being set to the same output colorspace, with the same deblocking settings, and without any postprocessing filters enabled in ffdshow.

At this point I got decidedly suspicious, since I was under the impression that according to the specification, H.264 decoders are supposed to produce results that are bit-wise identical to that of the reference decoder. Since not all samples seemed affected, I and Lord (another resident of #cccp) started investigating exactly what encoding parameters caused CoreAVC to produce weird outputs, and pretty soon we had it narrowed down to inloop deblocking. After experimenting a bit, we found that certain (rather insane) deblocking settings on the encoding side could consistently cause CoreAVC to go absolutely bonklers, producing extremely blocky results. This seemed unrelated to what originally caused me to start the investigation (namely the small blocking artefacts) since those appeared even with "sane" deblocking settings, were much rarer, and also almost impossible to reproduce.

In particular, these x264 settings are good for demonstrating the extreme blockiness problem: x264.exe --qp 16 --ipratio 1 --filter 6:-6
Encoding ~200 frames of almost anything at all (that has motion) with this commandline and playing it back with both CoreAVC and another h.264 decoder (libavcodec, the reference decoder, or even Nero's decoder) will make the problem extremely visible to the naked eye. Here (http://uppcon.com/thefluff/samples/coreavc-DELICIOUS-BLOCKS.mkv) is a short sample (~500 frames) encoded with the above commandline (7.5 MB), and here (http://uppcon.com/thefluff/samples/nhg-18-coreavc-blocking-bug.mkv) is another that shows the smaller random blocking artefacts.

Concluding our tests, it seems that CoreAVC's deblocking is completely broken if the input was encoded with x264's --filter x:y where x > 0, y <= 0. For some reason the difference tends to be much smaller or not present at all in certain QP ranges, depending on what filter settings were used. In the most extreme case, 6:-6, the difference is clearly visible from about QP=4 to QP=27. This, however, seems rather heavily sample-dependent.


Now, the question is: since libavcodec is rapidly catching up to CoreAVC's decoding speed, why are we bothering with this DRM-filled buggy software at all? CoreCodec calls it "the world's fastest software H.264 decoder", but if its output differs this much from the reference decoder's, can it even be called a H.264 decoder? Wouldn't that be false marketing? Also, all this raises the suspicion that part of the reason for CoreAVC's speed might be that some corners have been cut when it comes to precision...

EDIT: I'd also appreciate if someone could explain exactly how strict the specs are when it comes to inloop deblocking.

[Rectal Prolapse]

libavcodec has improved that much? Cool! Thank you for the heads up - I wonder if it will run well on an Core2 Allendale@3GHz with a 20 mbit/sec h264 MBAFF stream?

Anyways, I'm glad you did the test - only people with encoder experience would find bugs like these.

Have you tried submitting the bug on the CoreAVC website/forum?

[TheFluff]

Have you tried submitting the bug on the CoreAVC website/forum?

Yes, now I have, since I FINALLY managed to access it without it timing out on me. The bugtracker still seems down though.

[_xxl]

From libavcodec h.264.c:
if((s->avctx->flags2 & CODEC_FLAG2_FAST) && !s->current_picture.reference){
s->me.qpel_put= s->dsp.put_2tap_qpel_pixels_tab;
s->me.qpel_avg= s->dsp.avg_2tap_qpel_pixels_tab;
}else{
s->me.qpel_put= s->dsp.put_h264_qpel_pixels_tab;
s->me.qpel_avg= s->dsp.avg_h264_qpel_pixels_tab;
}

return 0;
}
You need the latest ffdshow.
http://www.mytempdir.com/1105983
The same results if libavcodec.dll is compiled with "FAST".
"dsp.put(avg)_2tap_qpel_pixels_tab" are used.

[Daodan]

Also a nice comparison here:
http://www.uploadtemple.com/thumb/1165615987.png (http://www.uploadtemple.com/view.php/1165615987.png)

All shots taken with default setings, inloop deblocker ON. Not my find btw..

[TheFluff]

@Daodan: yep, I've seen that one as well, checkers encoded it IIRC.

[glb]

Yes, now I have, since I FINALLY managed to access it without it timing out on me. The bugtracker still seems down though.

No you didn't. You created a link to this thread in a CorePlayer forum.

[TheFluff]

Yes, indeed, very wrong forum, dunno what I was smoking. But I didn't see the point about copypasting the entire thread there since I've already given all relevant information I have in this one.

And since the CoreAVC people now have a (link to a) very detailed description of the problem, I don't see how it isn't "reported". I guess I could email them but apparently they don't ever answer their email so I don't really see the point.

[check]

Here's another stream with the problem. It's the source for the video shots daodan posted above, except I don't think his shots are particularly accurate. In my case, ffdshow seems to decode as per the reference decoder, while coreavc exhibits that scary blocking.
http://files.project357.com/uploads/coreavc_decoding_error_example_rx.mkv (http://files.project357.com/uploads/index.php?dir=&file=coreavc_decoding_error_example_rx.mkv)

[BetaBoy]

TheFluff... a little over the top post? On your concerns. The blockiness issue is a bug that is in our tracker to be fixed.

As far as your comment on compliance... my opinion is that CoreAVC and Ateme are the most compliant atm but I leave that for the D9 forum to discuss.

[PicardGK]

We try our best to check the decoder against compilance and other h264 clips (byte exact output compared to reference decoder). But bugs can still happen. In this case it was typo in the source :( Speed won't be affected.

[ChronoCross]

I'm glad that these people say that coreavc is shitty without even seeing the code.......sad.

[TheFluff]

The blockiness issue is a bug that is in our tracker to be fixed.
Good for you, I guess. I wouldn't know, since the bug tracker just times out when I try to connect to it... (which is why I posted here in the first place).

We try our best to check the decoder against compilance and other h264 clips (byte exact output compared to reference decoder).
That's good to hear. I guess you just didn't test any samples at all with filter 1:0 or something ;)

I'm glad that these people say that coreavc is shitty without even seeing the code.......sad.
Well, since I can't see the source code, the only thing I see is the output. And since the output is, well, broken, I don't see how I could consider it NOT shitty.

[TheFluff]

EDIT: this was in reply to a post by ChronoCross that in essence said "you're talking about a bug that affects maybe 0.0001% of all clips". It seems to have been deleted for some reason...

(original reply follows)

Please read the original post again. ALL clips that use filter x:y where x>0 and y<=0 seems to suffer from it (and that's not that extremely specific, IMNSHO - there are 169 (13*13) possible combinations of filter parameters, and 42 (6*7) of those are affected). Filter 1:0 isn't all that weird - it's certainly more common than those "0.0001% of all clips" you babble about.

Then there's also the issue of check's sample, which, AFAIK, uses filter 0:0 and STILL has blocking artefacts.

In conclusion: please check the facts better before you start claiming stuff is insignificant.

[IgorC]

I remember some metric measurements SSIM of Core and ffdshow with not extrevagant but usual deblock 0-0. CoreAVC had slightly lower result. then it's not bit perfect decoding.
But you won't notice a dig difference ( will you at all?) , but certainly will do a higher speed :)

[ChronoCross]

I'm just curious as to how often you encode clips using those particular set of rules. I understand that there are possible combinations however do they have any practical use?

[Manao]

But you won't notice a dig difference ( will you at all?) , but certainly will do a higher speedI wonder if that sentence is worded correctly. So just put again the emphasis on what Picard said : it's a bug, not a way to speed up decoding at the cost of quality. And correcting the bug doesn't slow down the decoding process.

[Manao]

@ChronoCross : you sound more and more like a guy who has been buying some shares in CoreAvc :p. A bug is a bug, there is no small bug as soon as the bug is known and some people suffer from it. Anyway, the first reported bug is fixed, so end of story ( for that one ).

[Trahald]

I think his point may have been the extreme reaction to a rare circumstance. (ie if tons of people that use coreavc had to be told that there was a decoding error then it may not qualify for making coreavc crap or make the marketing false) its just a bug like lots of (if not all) programs have.

[IgorC]

I wonder if that sentence is worded correctly. So just put again the emphasis on what Picard said : it's a bug, not a way to speed up decoding at the cost of quality. And correcting the bug doesn't slow down the decoding process.
Hm. then it should be very old bug. Because even alpha versions haven't identical results while Nero and ffdshow gived identical solidly higher SSIM result.

It may be bug but also it maybe some speed optimization at quality cost. Also maybe they are totally independent things.

[_xxl]

http://www.vid-labs.com/products/products.htm

Our highly optimised H.264/AVC codec provides impressive video quality and compression performance. The codec incorporates patent-pending complexity reduction algorithms that adapt to the video clip content and selectively bypass parts of the coding process. These unique algorithms can save up to 70% of the processing power (compared with other codec products) without compromising quality or compression performance.

@all

What is your opinion regarding this?
Is the output bit identical with the referece h.264 codec?
It has something to do with the human visual perception?

[foxyshadis]

That's an encoder. Also, gee, they compare its speed to the reference codec, that's like comparing your IQ to a second-grader's. Call me when it compares itself to any optimized implementation, or offers any sort of downloadable trial. (I'm pretty sure that site has been there without change for years. I've seen it a few times before.)

[bond]

let's wait for the next version which hopefully has the bug fixed and produces identical output to the other decoders and than check the speed again

lets not speculate before knowing the facts

[ChronoCross]

I think his point may have been the extreme reaction to a rare circumstance. (ie if tons of people that use coreavc had to be told that there was a decoding error then it may not qualify for making coreavc crap or make the marketing false) its just a bug like lots of (if not all) programs have.

pretty much what I meant....glad someone has some ability to read. The whole point is how this didn't seem to affect anyones viewing experience. The rare circumstances by which this bug is apparent is in situations that aren't used by 99% of people working with h264. Granted it is a bug but it's not one that warrants the attention that it seems to be getting.

[Manao]

A third of MeGUI profiles are likely to create such a bug, since it seems to happen as soon as the deblocking strength alpha / beta differs. So where do these 99% come from ?

[IgorC]

But even for -2:-2 CoreAVC hasn't the same metric results comparing to ffdshow and nero decoders.
I tried different players, encoders, settings.

[ChronoCross]

A third of MeGUI profiles are likely to create such a bug, since it seems to happen as soon as the deblocking strength alpha / beta differs. So where do these 99% come from ?

noticeable? I think not.... your talking metrics then sure it could happen on quite a few clips where it is not bitwise actuate. How many clips have you noticed it on where your not intentionally trying to do it?

Edit: For all practical purposes standard De-blocking models will suffice for most clips. As I also said before it is indeed a bug but the impact is greatly exaggerated considering this is 1.2.......and has already been beta tested by quite a few doom9's premier members.

[TheFluff]

I dunno about anyone else, but when I started looking closer at CoreAVC I first thought the output looked subtly different, but I dismissed it as the placebo effect. Turns out I was right, after all, in several 1:0 clips I have I can now actually see the differences with the naked eye, now that I know what to look for.

[mrkazador]

Sorry to raise a dead topic but im having the same problem, here's a cut and paste from my thread somewhere else...

Finished watching a movie and noticed some weird blocking/artifacts. After doing some tests I realized its the codec, CoreAvc.

CoreAvc
http://img262.imageshack.us/img262/9162/coreavcsw1.th.jpg (http://img262.imageshack.us/my.php?image=coreavcsw1.jpg)

FFDSHOW
http://img262.imageshack.us/img262/5729/ffdshowzx7.th.jpg (http://img262.imageshack.us/my.php?image=ffdshowzx7.jpg)

Switch back between the two frames and notice some discoloration, blocking, and extra noise when using CoreAvc. Using ffdshow everything is shown as it should, perfect. Its not just this movie, it happens to all x264 encodes.


Zoom Player 5 Pro
CoreAvc v1.2 (No de-blocking and deinterlacing, tried with or without, same...)
Haali Media Splitter

[ChronoCross]

it's fixed in the next version it was a simple typo in the code.

[migrena]

how official is this?

[BetaBoy]

The Beta testers that had the issue stated it has been fixed.

[migrena]

so its as official as it can be, thx

[TheFluff]

Well, official or not, but three and a half months later there still hasn't been any release that fixes this. Excuse me gentlemen, but what exactly do you think you're doing here?

Also, I hear rumours about some sort of secret prerelease thing that reportedly fixes this issue and also (kinda) fixes the broken blacklevels one, but that one has another funky blocking issue... Makes you wonder what kind of code CoreAVC really contains. And people say open source has bad code quality? How ironic.

Edit: so 1.3 is "kinda" out. Fun.

[migrena]

i think coreavc team needs to allocate more human resources to to this project to finish this long awaited gpu support, encoder etc...

[BetaBoy]

Makes you wonder what kind of code CoreAVC really contains.

'p0rn'