[FFmpeg-devel] [PATCH 5/6] lavc/vp6: Implement "slice" threading for VP6A decode

Ben Jackson ben at ben.com
Sat Sep 15 07:24:12 CEST 2012

On Fri, Sep 14, 2012 at 11:21:02PM +0200, Michael Niedermayer wrote:
> On Thu, Sep 13, 2012 at 09:43:06PM -0700, Ben Jackson wrote:
> > The YUV channels of VP6 are encoded in a highly linear fashion which does
> > not have any slice-like concept to thread.  The alpha channel of VP6A is
> > fairly independent of the YUV and comprises 40% of the work.  This patch
> > uses the THREAD_SLICE capability to split the YUV and A decodes into
> > separate threads.
> this patch breaks "make fate"

I can repro this.  Sorry for the oversight -- fate didn't run clean on my
FreeBSD box and I got distracted before figuring out how to run specific

I looked at the actual differences and it's 1 or 2 LSBs in the alpha
channel sporadically throughout the frame.

I think this is a bug I inadvertently fixed.  It is caused by state
leaking from the YUV header parse into the A header.  By splitting them
into separate structures I prevented that from happening.  Thus the
filter_selection and sample_variance_threshold (in this particular case)
are preserved from the previous alpha header (because a specific header
bit in the alpha section said to let them "coast").

Unfortunately I have only a VP6 spec and so all I know about VP6A is
from looking at the ffmpeg source.  The "A" channel is definitely bolted
on and all the other "model" information is separate between YUV and A,
but I still can't say for sure if the old behavior was right or if
the new behavior is right.

My best guess is to update tests/ref/fate/vp6a with the new results.
Alternatively I can make the new code "bug compatible" (I already did
that to verify I can pass fate-vp6a).  Either way I'll submit a new
patch stack because I did a couple of minor cleanups while searching
for this.

Ben Jackson AD7GD
<ben at ben.com>

More information about the ffmpeg-devel mailing list