[FFmpeg-devel] H264: Fix non_zero_count_cache for deblocking in fields

[Michael Niedermayer]

Hi

On Fri, Nov 30, 2007 at 10:58:23AM +0100, Martin Zlomek wrote:
> Hello,
>
> attached patch paff-nnz.diff fixes obvious typo in fill_caches() if PAFF is 
> in use.
> Then, there are correct values in non_zero_count_cache used in the 
> deblocking filter.
> Not optimized version of the filter (i.e. filter_mb()) gives output that is
> equivalent to the reference decoder output. Tested on these conformance 
> samples
> (http://ftp3.itu.ch/av-arch/jvt-site/draft_conformance/00readme_suz0420.html):
>   CVFI1_Sony_D.jsv
>   CVFI1_SVA_C.264
>   MR6_BT_B.h264
>   Sharp_MP_Field_1_B.jvt
>   Sharp_MP_Field_2_B.jvt
>   Sharp_MP_Field_3_B.jvt
>
> Nevertheless, there is still the problem in the fast version of the filter
> (filter_mb_fast()) that I metioned in thread
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-October/037249.html.
> I do not understand MMX instructions so far, thus I am not able to fix this
> problem soon.

see
wget http://www.intel.com/design/processor/manuals/25366{5,6,7}.pdf --user-agent='Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)'


> Loren Merritt sent patch for this some time ago, but it seems it is not 
> working...
>
> If you do not demand speed, you can "switch off" fast version of the filter
> in fields by attached patch paff-deblock-notoptimized.diff. BTW. how much 
> faster
> is the fast version - has anybody measured it?
[...]

> Index: libavcodec/h264.c
> ===================================================================
> --- libavcodec/h264.c	(revision 11112)
> +++ libavcodec/h264.c	(working copy)
> @@ -172,7 +172,7 @@
>      int i;
>  
>      //FIXME deblocking could skip the intra and nnz parts.
> -    if(for_deblock && (h->slice_num == 1 || h->slice_table[mb_xy] == h->slice_table[mb_xy-s->mb_stride]) && !FRAME_MBAFF)
> +    if(for_deblock && (h->slice_num == 1 || h->slice_table[mb_xy] == h->slice_table[mb_xy - (s->mb_stride << FIELD_PICTURE)]) && !FRAME_MBAFF)
>          return;
>  
>      //wow what a mess, why didn't they simplify the interlacing&intra stuff, i can't imagine that these complex rules are worth it

patch ok

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071212/e5508cd4/attachment.pgp>