Hi, On Tue, May 17, 2011 at 2:38 PM, Reinhard Tartler <[email protected]> wrote: > On Tue, May 17, 2011 at 04:44:30PM +0200, Kostya wrote: >> On Thu, May 12, 2011 at 10:13:57PM -0400, Ronald S. Bultje wrote: >> > Hi, >> > >> > On Thu, May 12, 2011 at 8:39 PM, Ronald S. Bultje <[email protected]> >> > wrote: >> > > On Thu, May 12, 2011 at 5:53 PM, Ronald S. Bultje <[email protected]> >> > > wrote: >> > >> If deblock_mode==2, we should deblock slice edges also. This >> > >> can obviously only be done once all slices have finished >> > >> decoding. >> > >> --- >> > >> libavcodec/h264.c | 23 +++++++++++++++++------ >> > >> 1 files changed, 17 insertions(+), 6 deletions(-) >> > > >> > > Jason just told me I misread the code, so ignore this for now. >> > >> > This patch works better, I think. Output for test sample at 16 >> > slice-threads is now identical to JM and the code remains in-loop. >> > >> > Ronald >> >> > From e7b2c6ceab21f47316149e1fde6eecc9cb897d7c Mon Sep 17 00:00:00 2001 >> > From: Ronald S. Bultje <[email protected]> >> > Date: Thu, 12 May 2011 21:46:56 -0400 >> > Subject: [PATCH] h264: fix loopfilter with threading at slice boundaries. >> > >> > --- >> > libavcodec/h264.c | 20 +++++++++++++------- >> > 1 files changed, 13 insertions(+), 7 deletions(-) >> >> ok if tested > > Unfortunately, this patch breaks makes my sandy sad: > > TEST h264-conformance-hcmp1_hhi_a > --- > /home/siretart/libav/libav/tests/ref/fate/h264-conformance-frext-pph10i4_panasonic_a > 2011-05-14 14:56:01.292294380 +0200 > +++ tests/data/fate/h264-conformance-frext-pph10i4_panasonic_a > 2011-05-17 20:36:05.019580759 +0200
Ah, yes, this sample has bitstream errors (JM fails to decode it also). JM with my settings aborts, so I don't know what the proper decoding routine is after it quits. Basically the reason my patch changes the output is that currently, we run the loopfilter per row. If a slice aborts halfway a row because we're running into trouble with the bitstream, then we won't run the loopfilter on that row at all. My patch makes it now run the loopfilter on the block up until the point where the error occurred. I believe that is more correct. Are people OK with me updating the ref crcs for this sample when I commit this? (And again, this doesn't change the output for the parts that JM decodes, only the parts where errors occur, and JM exits at that point with default settings. I am not sure if I want to compare our error resilience and JMs to give identical output...) Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
