[FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
This has a few TODOs like adjusting the run tables instead
of having a -1 in the decode loop.
But please review the general idea.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/flv.h| 1 -
libavcodec/flvdec.c | 12 ---
libavcodec/h261dec.c| 27 +++-
libavcodec/ituh263dec.c | 55 +++--
4 files changed, 57 insertions(+), 38 deletions(-)
diff --git a/libavcodec/flv.h b/libavcodec/flv.h
index 16bc88b..df50820 100644
--- a/libavcodec/flv.h
+++ b/libavcodec/flv.h
@@ -28,6 +28,5 @@ void ff_flv_encode_picture_header(MpegEncContext * s, int
picture_number);
void ff_flv2_encode_ac_esc(PutBitContext *pb, int slevel, int level, int run,
int last);
int ff_flv_decode_picture_header(MpegEncContext *s);
-void ff_flv2_decode_ac_esc(GetBitContext *gb, int *level, int *run, int *last);
#endif /* AVCODEC_FLV_H */
diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 3b048f6..db413f2 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -22,18 +22,6 @@
#include flv.h
#include libavutil/imgutils.h
-void ff_flv2_decode_ac_esc(GetBitContext *gb, int *level, int *run, int *last)
-{
-int is11 = get_bits1(gb);
-*last = get_bits1(gb);
-*run = get_bits(gb, 6);
-if (is11) {
-*level = get_sbits(gb, 11);
-} else {
-*level = get_sbits(gb, 7);
-}
-}
-
int ff_flv_decode_picture_header(MpegEncContext *s)
{
int format, width, height;
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 301ecc1..5f0eb59 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -258,7 +258,7 @@ static int decode_mv_component(GetBitContext *gb, int v)
static int h261_decode_block(H261Context *h, int16_t *block, int n, int coded)
{
MpegEncContext *const s = h-s;
-int code, level, i, j, run;
+int level, i, j, run;
RLTable *rl = ff_h261_rl_tcoeff;
const uint8_t *scan_table;
@@ -303,27 +303,32 @@ static int h261_decode_block(H261Context *h, int16_t
*block, int n, int coded)
s-block_last_index[n] = i - 1;
return 0;
}
+{
+OPEN_READER(re, s-gb);
for (;;) {
-code = get_vlc2(s-gb, rl-vlc.table, TCOEFF_VLC_BITS, 2);
-if (code 0) {
+UPDATE_CACHE(re, s-gb);
+GET_RL_VLC(level, run, re, s-gb, rl-rl_vlc[0], TCOEFF_VLC_BITS, 2,
0);
+if (run == 66 level) {
av_log(s-avctx, AV_LOG_ERROR, illegal ac vlc code at %dx%d\n,
s-mb_x, s-mb_y);
return -1;
}
-if (code == rl-n) {
+if (run == 66) {
/* escape */
/* The remaining combinations of (run, level) are encoded with a
* 20-bit word consisting of 6 bits escape, 6 bits run and 8 bits
* level. */
-run = get_bits(s-gb, 6);
-level = get_sbits(s-gb, 8);
-} else if (code == 0) {
+run = SHOW_UBITS(re, s-gb, 6);
+SKIP_CACHE(re, s-gb, 6);
+level = SHOW_SBITS(re, s-gb, 8);
+SKIP_COUNTER(re, s-gb, 6 + 8);
+} else if (level == 0) {
break;
} else {
-run = rl-table_run[code];
-level = rl-table_level[code];
-if (get_bits1(s-gb))
+run--;
+if (SHOW_UBITS(re, s-gb, 1))
level = -level;
+SKIP_COUNTER(re, s-gb, 1);
}
i += run;
if (i = 64) {
@@ -335,6 +340,8 @@ static int h261_decode_block(H261Context *h, int16_t
*block, int n, int coded)
block[j] = level;
i++;
}
+CLOSE_READER(re, s-gb);
+}
s-block_last_index[n] = i - 1;
return 0;
}
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index ce454c3..9078c9e 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 code, level, i, j, last, run;
+int level, i, j, last, run;
RLTable *rl = ff_h263_rl_inter;
const uint8_t *scan_table;
GetBitContext gb= s-gb;
@@ -479,36 +479,59 @@ static int h263_decode_block(MpegEncContext * s, int16_t
* block,
return 0;
}
retry:
+{
+OPEN_READER(re, s-gb);
for(;;) {
-code = get_vlc2(s-gb, rl-vlc.table, TEX_VLC_BITS, 2);
-if (code 0){
+UPDATE_CACHE(re, s-gb);
+GET_RL_VLC(level, run, re, s-gb, rl-rl_vlc[0], TEX_VLC_BITS, 2, 0);
+if (run == 66 level){
av_log(s-avctx, AV_LOG_ERROR, illegal ac vlc code at %dx%d\n,
s-mb_x, s-mb_y);
return -1;
}
-if (code == rl-n) {
+if (run == 66) {
/* escape */
if (CONFIG_FLV_DECODER s-h263_flv 1) {
-ff_flv2_decode_ac_esc(s-gb, level, run, last);
+
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... So I might be doing some fairly stupid things. Still, it passes make fate. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
Hi, On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
On Sun, Aug 31, 2014 at 08:37:56AM -0400, Ronald S. Bultje wrote: Hi, On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Well, but then there is the question how many GET_VL_RLC may end up using at most. And that will depend on even more, for example, how much will it have used at most when you get into the escape path? I think this is quite tricky if you want to do it optimally, so I just guessed so far... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
Hi, On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 08:37:56AM -0400, Ronald S. Bultje wrote: On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Well, but then there is the question how many GET_VL_RLC may end up using at most. And that will depend on even more, for example, how much will it have used at most when you get into the escape path? I think this is quite tricky if you want to do it optimally, so I just guessed so far... I'm not sure that's a good idea. So, basically, you want to make pessimistic assumptions, not 90% worst or anything, just worst-possible case. Because after all, any bitstream that did decode correctly before should still decode correctly after. So If you want to use GET_VL_RLC, just assume it'll consume the max number bits within its vlc code set. Once every 1/n_entries times, it actually will (assuming random input), and you want to keep handling that case. If you want to specifically optimize short codes, make a branch (i.e. if code_len .. or if code_prefix ... or whatever). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
On Sun, Aug 31, 2014 at 09:24:24AM -0400, Ronald S. Bultje wrote: Hi, On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 08:37:56AM -0400, Ronald S. Bultje wrote: On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Well, but then there is the question how many GET_VL_RLC may end up using at most. And that will depend on even more, for example, how much will it have used at most when you get into the escape path? I think this is quite tricky if you want to do it optimally, so I just guessed so far... I'm not sure that's a good idea. So, basically, you want to make pessimistic assumptions, not 90% worst or anything, just worst-possible case. Because after all, any bitstream that did decode correctly before should still decode correctly after. So If you want to use GET_VL_RLC, just assume it'll consume the max number bits within its vlc code set. Once every 1/n_entries times, it actually will (assuming random input), and you want to keep handling that case. If you want to specifically optimize short codes, make a branch (i.e. if code_len .. or if code_prefix ... or whatever). The point is we already _have_ those branches. And the escape code is one specific VLC code. So we should know _exactly_ how much we consumed, and can rely on that. You just have to find all the proper information. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
Hi, On Sun, Aug 31, 2014 at 9:38 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 09:24:24AM -0400, Ronald S. Bultje wrote: On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 08:37:56AM -0400, Ronald S. Bultje wrote: On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote: This has a few TODOs like adjusting the run tables instead of having a -1 in the decode loop. But please review the general idea. I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Well, but then there is the question how many GET_VL_RLC may end up using at most. And that will depend on even more, for example, how much will it have used at most when you get into the escape path? I think this is quite tricky if you want to do it optimally, so I just guessed so far... I'm not sure that's a good idea. So, basically, you want to make pessimistic assumptions, not 90% worst or anything, just worst-possible case. Because after all, any bitstream that did decode correctly before should still decode correctly after. So If you want to use GET_VL_RLC, just assume it'll consume the max number bits within its vlc code set. Once every 1/n_entries times, it actually will (assuming random input), and you want to keep handling that case. If you want to specifically optimize short codes, make a branch (i.e. if code_len .. or if code_prefix ... or whatever). The point is we already _have_ those branches. And the escape code is one specific VLC code. So we should know _exactly_ how much we consumed, and can rely on that. You just have to find all the proper information. Ah, ok, then it's fine, cool. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
On Sun, Aug 31, 2014 at 03:38:21PM +0200, Reimar Döffinger wrote: On Sun, Aug 31, 2014 at 09:24:24AM -0400, Ronald S. Bultje wrote: On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: I forgot to say: this is the first time I use this API, and I was quite confused. And in particular I am not sure how much I can safely read from the cache without updating... 25, right? Anything less, we'd advance a byte in update. Well, but then there is the question how many GET_VL_RLC may end up using at most. And that will depend on even more, for example, how much will it have used at most when you get into the escape path? I think this is quite tricky if you want to do it optimally, so I just guessed so far... I'm not sure that's a good idea. So, basically, you want to make pessimistic assumptions, not 90% worst or anything, just worst-possible case. Because after all, any bitstream that did decode correctly before should still decode correctly after. So If you want to use GET_VL_RLC, just assume it'll consume the max number bits within its vlc code set. Once every 1/n_entries times, it actually will (assuming random input), and you want to keep handling that case. If you want to specifically optimize short codes, make a branch (i.e. if code_len .. or if code_prefix ... or whatever). The point is we already _have_ those branches. And the escape code is one specific VLC code. So we should know _exactly_ how much we consumed, and can rely on that. You just have to find all the proper information. If I checked things correctly, luckily that makes no difference. The escape code is 7 bits, the full one is 9 bits. However we either read 15 or 19 additional bits, so we do not need to update in the 15 bit and we need to in the 19 bit case no matter what. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
