[FFmpeg-devel] Parallelized h264 proof-of-concept

[Michael Niedermayer]

Hi

On Fri, May 18, 2007 at 11:00:57PM +0200, Andreas ?man wrote:
[...]
> The issues left to fix are:
> 
> o The error resilience data structures are not protected (but
>   still shared). This usually manifests itself into:
> 
> [h264 @ 0xb7c64208]concealing 0 DC, 0 AC, 0 MV errors
> 
>   because the s->error_count decrement races between
>   cpus. This is pretty easy to fix if the avcodec thread
>   implementations would expose a locking primitive.

you dont need any locking, just n seperate error_counts, one for each
thread, and then sum them at the end


> 
> o deblocking doesn't work correctly. When deblocking is enabled
>   the md5 sum output from my test program changes for every run.
>   I quite sure this is caused by the fact that deblocking is done
>   over the entire frame, not locally per slice, and thus, if
>   slices complete out-of-order, there will be errors.
>   I don't see any visual artifacts, but something is fishy for
>   sure. I'll need to nail the exact reason before i can be
>   more specific about problems / solutions here.

this is serious, md5 must match ...


> 
> o The SVQ3 decoding has not yet been adapted. (one need to configure
>   with --disable-decoder=svq3 to compile at all now)

that too is serious, nothing may break ... though theres no need to make
SVQ3 multithreaded too ...


[...]
> Okay, a few words about the changes.
> 
> A new structure H264Thread (name suggestions very welcome) is
> passed around to almost all functions. This structure is
> local for every slice (perhaps H264Slice would be a better
> name) and contains all members from H264Context that
> changed during slice decode. I also moved a few things
> (most notably mb_[xy]) from MpegEncContext here.

what about copying the MpegEncContect & H264Context for each thread
and using them, this should significantly reduce the changes
needed (note i didnt look at your patch at all ...)

also look at how slice level multithreading is implemented for
mpeg2/mpeg4 ...


[...]
> Anyway,
> If this is something that ffmpeg is willing to integrate
> I'd like to get a few pointers, hints and answers on the
> topics above before I continue with the stuff that's left.

iam not against slice level threading support, though the
implementation must be clean, simple and there must be no
speedloss for the single threaded case (>1% is completely
unacceptable)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070518/73ceae6c/attachment.pgp>