[FFmpeg-devel] questions about VP8 decode, we found that there seems some buggs of code

[Wei Gao]

2013/4/20 Ronald S. Bultje <rsbultje at gmail.com>

> Hi,
>
>
> On Fri, Apr 19, 2013 at 5:10 PM, Wei Gao <highgod0401 at gmail.com> wrote:
>
> > 2013/4/20 Ronald S. Bultje <rsbultje at gmail.com>
> > > On Fri, Apr 19, 2013 at 12:12 AM, Carl Eugen Hoyos <cehoyos at ag.or.at>
> > > wrote:
> > > > Wei Gao <highgod0401 <at> gmail.com> writes:
> > > >
> > > > > We want use GPU to decode VP8, but the output is a
> > > > > little different from C code. So we reference the C
> > > > > code and find there are some bits overflowed.
> > > >
> > > > Without a sample, this is not very likely to get fixed.
> > > >
> > >
> > > More importantly, you have not yet shown to me that your GPU decoder is
> > > correct. Dixie and libvpx are the reference implementations, does your
> > GPU
> > > decode match them, and does ffvp8 give different output? Or do ffvp8,
> > dixie
> > > and libvpx match, but GPU gives different output?
> >
> > Hi, our GPU vp8 dcoder is written by us and it is different from the
> > libvpx, it is being debugging now.
> >
>
> I understand that, but that was not my question. You make the claim that
> ffvp8 has a potential bug, which causes different output compared to your
> GPU decoder. So we have 2 decoders, your GPU decoder and ffmpeg's VP8
> decoder (ffvp8), which apparently give different output. Your claim is that
> therefore, ffvp8 has a bug.
>
> My point is, you haven't shown that yet. A bug can only be shown by showing
> me a sample that causes undetermined behaviour, e.g. referencing
> uninitialized or unallocated memory or something along those lines, which
> can be confirmed in asan or valgrind. A bug can also be shown by giving me
> a sample where ffvp8 has different output than the reference decoder, that
> being dixie or libvpx.
>
> The comparison of ffvp8 and your GPU decoder is thus largely irrelevant.
> Them being different shows that at least one of the two has a bug. It
> doesn't show which of the two has a bug, and doesn't rule out the
> possibility that both are buggy.
>
> Please do the following:
> A) test against libvpx/dixie. If ffvp8 and libvpx/dixie match, your GPU
> decoder has a bug. If your GPU decoder and libvpx/dixie match, ffvp8 has a
> bug. If neither match, both your GPU decoder and ffvp8 have a bug.
> B) (if ffvp8 has a bug,) please provide samples. We can't fix bugs unless
> we have samples.
> C) I saw some IRC communication regarding code, I am willing to explain
> code where necessary, but I don't think I'm anywhere near your timezone,
> and not really available much on IRC ATM, so feel free to ask for code
> explanations on the mailinglist instead. I'll be happy to assist.
>
Hi, thanks for your help, it is our mistake, we should add the same pad
length of height as the CPU code, the data of pad we add is larger then the
CPU code.And the data is the same now.

Thanks.

>
> HTH,
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>