[FFmpeg-devel] [PATCH 5/6] lavc/vp6: Implement "slice" threading for VP6A decode
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
Ben Jackson AD7GD
<ben at ben.com>
More information about the ffmpeg-devel