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

[Michael Niedermayer]

On Fri, Sep 14, 2012 at 10:24:12PM -0700, Ben Jackson wrote:
> 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
> tests.
> 
> 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.

yes, agree, it makes most sense


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120915/d78c3a64/attachment.asc>