[FFmpeg-devel] [PATCH 3/4] ituh263dec: Optimize new RL_VLC based decoding.

2014-08-31 Thread Reimar Döffinger 
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/ituh263dec.c | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 26f0ec5..083f5ae 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -418,7 +418,7 @@ static void h263_decode_dquant(MpegEncContext *s){
 static int h263_decode_block(MpegEncContext * s, int16_t * block,
  int n, int coded)
 {
-int level, i, j, last, run;
+int level, i, j, run;
 RLTable *rl = ff_h263_rl_inter;
 const uint8_t *scan_table;
 GetBitContext gb= s-gb;
@@ -493,26 +493,22 @@ retry:
 if (CONFIG_FLV_DECODER  s-h263_flv  1) {
 int is11 = SHOW_UBITS(re, s-gb, 1);
 SKIP_CACHE(re, s-gb, 1);
-last = SHOW_UBITS(re, s-gb, 1);
-SKIP_CACHE(re, s-gb, 1);
-run = SHOW_UBITS(re, s-gb, 6);
+run = SHOW_UBITS(re, s-gb, 7) + 1;
 if (is11) {
-SKIP_COUNTER(re, s-gb, 6);
+SKIP_COUNTER(re, s-gb, 1 + 7);
 UPDATE_CACHE(re, s-gb);
 level = SHOW_SBITS(re, s-gb, 11);
-SKIP_COUNTER(re, s-gb, 1 + 1 + 6 + 11);
+SKIP_COUNTER(re, s-gb, 11);
 } else {
-SKIP_CACHE(re, s-gb, 6);
+SKIP_CACHE(re, s-gb, 7);
 level = SHOW_SBITS(re, s-gb, 7);
-SKIP_COUNTER(re, s-gb, 1 + 1 + 6 + 7);
+SKIP_COUNTER(re, s-gb, 1 + 7 + 7);
 }
 } else {
-last = SHOW_UBITS(re, s-gb, 1);
-SKIP_CACHE(re, s-gb, 1);
-run = SHOW_UBITS(re, s-gb, 6);
-SKIP_CACHE(re, s-gb, 6);
+run = SHOW_UBITS(re, s-gb, 7) + 1;
+SKIP_CACHE(re, s-gb, 7);
 level = (int8_t)SHOW_UBITS(re, s-gb, 8);
-SKIP_COUNTER(re, s-gb, 1 + 6 + 8);
+SKIP_COUNTER(re, s-gb, 7 + 8);
 if(level == -128){
 UPDATE_CACHE(re, s-gb);
 if (s-codec_id == AV_CODEC_ID_RV10) {
@@ -528,15 +524,19 @@ retry:
 }
 }
 } else {
-run--;
-last = run = 192;
-run = 63;
 if (SHOW_UBITS(re, s-gb, 1))
 level = -level;
 SKIP_COUNTER(re, s-gb, 1);
 }
 i += run;
-if (i = 64){
+if (i  64){
+// redo update without last flag
+i = i - run + ((run-1)63);
+if (i  64) {
+// only last marker, no overrun
+block[scan_table[i]] = level;
+break;
+}
 if(s-alt_inter_vlc  rl == ff_h263_rl_inter  !s-mb_intra){
 CLOSE_READER(re, s-gb);
 //Looks like a hack but no, it's the way it is supposed to 
work ...
@@ -549,11 +549,8 @@ retry:
 av_log(s-avctx, AV_LOG_ERROR, run overflow at %dx%d i:%d\n, 
s-mb_x, s-mb_y, s-mb_intra);
 return -1;
 }
-j = scan_table[i];
+j = scan_table[i-1];
 block[j] = level;
-if (last)
-break;
-i++;
 }
 CLOSE_READER(re, s-gb);
 }
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] ituh263dec: Optimize new RL_VLC based decoding.

2014-08-31 Thread Michael Niedermayer 
On Sun, Aug 31, 2014 at 04:48:43PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavcodec/ituh263dec.c | 39 ++-
  1 file changed, 18 insertions(+), 21 deletions(-)
 
 diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
 index 26f0ec5..083f5ae 100644
 --- a/libavcodec/ituh263dec.c
 +++ b/libavcodec/ituh263dec.c
 @@ -418,7 +418,7 @@ static void h263_decode_dquant(MpegEncContext *s){
  static int h263_decode_block(MpegEncContext * s, int16_t * block,
   int n, int coded)
  {
 -int level, i, j, last, run;
 +int level, i, j, run;
  RLTable *rl = ff_h263_rl_inter;
  const uint8_t *scan_table;
  GetBitContext gb= s-gb;
 @@ -493,26 +493,22 @@ retry:
  if (CONFIG_FLV_DECODER  s-h263_flv  1) {
  int is11 = SHOW_UBITS(re, s-gb, 1);
  SKIP_CACHE(re, s-gb, 1);
 -last = SHOW_UBITS(re, s-gb, 1);
 -SKIP_CACHE(re, s-gb, 1);
 -run = SHOW_UBITS(re, s-gb, 6);
 +run = SHOW_UBITS(re, s-gb, 7) + 1;
  if (is11) {
 -SKIP_COUNTER(re, s-gb, 6);
 +SKIP_COUNTER(re, s-gb, 1 + 7);
  UPDATE_CACHE(re, s-gb);
  level = SHOW_SBITS(re, s-gb, 11);
 -SKIP_COUNTER(re, s-gb, 1 + 1 + 6 + 11);
 +SKIP_COUNTER(re, s-gb, 11);
  } else {
 -SKIP_CACHE(re, s-gb, 6);
 +SKIP_CACHE(re, s-gb, 7);
  level = SHOW_SBITS(re, s-gb, 7);
 -SKIP_COUNTER(re, s-gb, 1 + 1 + 6 + 7);
 +SKIP_COUNTER(re, s-gb, 1 + 7 + 7);
  }
  } else {
 -last = SHOW_UBITS(re, s-gb, 1);
 -SKIP_CACHE(re, s-gb, 1);
 -run = SHOW_UBITS(re, s-gb, 6);
 -SKIP_CACHE(re, s-gb, 6);
 +run = SHOW_UBITS(re, s-gb, 7) + 1;
 +SKIP_CACHE(re, s-gb, 7);
  level = (int8_t)SHOW_UBITS(re, s-gb, 8);
 -SKIP_COUNTER(re, s-gb, 1 + 6 + 8);
 +SKIP_COUNTER(re, s-gb, 7 + 8);
  if(level == -128){
  UPDATE_CACHE(re, s-gb);
  if (s-codec_id == AV_CODEC_ID_RV10) {
 @@ -528,15 +524,19 @@ retry:
  }
  }
  } else {
 -run--;
 -last = run = 192;
 -run = 63;
  if (SHOW_UBITS(re, s-gb, 1))
  level = -level;
  SKIP_COUNTER(re, s-gb, 1);
  }
  i += run;
 -if (i = 64){
 +if (i  64){
 +// redo update without last flag
 +i = i - run + ((run-1)63);
 +if (i  64) {
 +// only last marker, no overrun
 +block[scan_table[i]] = level;
 +break;
 +}
  if(s-alt_inter_vlc  rl == ff_h263_rl_inter  !s-mb_intra){
  CLOSE_READER(re, s-gb);
  //Looks like a hack but no, it's the way it is supposed to 
 work ...

 @@ -549,11 +549,8 @@ retry:
  av_log(s-avctx, AV_LOG_ERROR, run overflow at %dx%d i:%d\n, 
 s-mb_x, s-mb_y, s-mb_intra);
  return -1;
  }
 -j = scan_table[i];
 +j = scan_table[i-1];

the - 1 feels avoidable

patch should be ok


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] ituh263dec: Optimize new RL_VLC based decoding.

2014-08-31 Thread Reimar Döffinger 
On Sun, Aug 31, 2014 at 07:09:13PM +0200, Michael Niedermayer wrote:
 On Sun, Aug 31, 2014 at 04:48:43PM +0200, Reimar Döffinger wrote:
  @@ -549,11 +549,8 @@ retry:
   av_log(s-avctx, AV_LOG_ERROR, run overflow at %dx%d i:%d\n, 
  s-mb_x, s-mb_y, s-mb_intra);
   return -1;
   }
  -j = scan_table[i];
  +j = scan_table[i-1];
 
 the - 1 feels avoidable

I have no good idea how so far.
Note that it is not really an extra cost: we save on a i++ at this place
exchange...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] ituh263dec: Optimize new RL_VLC based decoding.

2014-08-31 Thread Michael Niedermayer 
On Sun, Aug 31, 2014 at 08:06:54PM +0200, Reimar Döffinger wrote:
 On Sun, Aug 31, 2014 at 07:09:13PM +0200, Michael Niedermayer wrote:
  On Sun, Aug 31, 2014 at 04:48:43PM +0200, Reimar Döffinger wrote:
   @@ -549,11 +549,8 @@ retry:
av_log(s-avctx, AV_LOG_ERROR, run overflow at %dx%d 
   i:%d\n, s-mb_x, s-mb_y, s-mb_intra);
return -1;
}
   -j = scan_table[i];
   +j = scan_table[i-1];
  
  the - 1 feels avoidable
 
 I have no good idea how so far.

cant i be offset at entry  exit of the loop ?
or
scan_table be offset by -1 ?

anyway not really important, its faster as is than before so this is
maybe better in a seperate later patch


 Note that it is not really an extra cost: we save on a i++ at this place
 exchange...
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] ituh263dec: Optimize new RL_VLC based decoding.

2014-08-31 Thread Reimar Döffinger 
On Sun, Aug 31, 2014 at 08:14:04PM +0200, Michael Niedermayer wrote:
 On Sun, Aug 31, 2014 at 08:06:54PM +0200, Reimar Döffinger wrote:
  On Sun, Aug 31, 2014 at 07:09:13PM +0200, Michael Niedermayer wrote:
   On Sun, Aug 31, 2014 at 04:48:43PM +0200, Reimar Döffinger wrote:
@@ -549,11 +549,8 @@ retry:
 av_log(s-avctx, AV_LOG_ERROR, run overflow at %dx%d 
i:%d\n, s-mb_x, s-mb_y, s-mb_intra);
 return -1;
 }
-j = scan_table[i];
+j = scan_table[i-1];
   
   the - 1 feels avoidable
  
  I have no good idea how so far.
 
 cant i be offset at entry  exit of the loop ?
 or
 scan_table be offset by -1 ?

*facepalm*. Yes, something like that should be possible.

 anyway not really important, its faster as is than before so this is
 maybe better in a seperate later patch

Considering how many bugs I had in this one, yes,
I rather have this one out and tested before I break
it again :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel