[libav-devel] [RFC] avio checksum functionality
Hi, I'm wondering if we could completely hide the avio checksum fields from the public structure by moving it to an internal field or extend it to be able to use any hash function from avutil and fully expose it to our users. The current situation is less than optimal. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
On Sat, Dec 08, 2012 at 08:42:36AM -0800, Ronald S. Bultje wrote: > On Sat, Dec 8, 2012 at 8:41 AM, Måns Rullgård wrote: > > "Ronald S. Bultje" writes: > >> Use this in VP8/H264-8bit loopfilter functions so they can be used if > >> there is no aligned stack (e.g. MSVC 32bit or ICC 10.x). > >> --- > >> libavcodec/x86/h264_deblock.asm | 27 ++ > >> libavcodec/x86/h264dsp_init.c | 4 +- > >> libavcodec/x86/vp8dsp.asm | 68 --- > >> libavcodec/x86/vp8dsp_init.c| 8 -- > >> libavutil/x86/x86inc.asm| 185 > >> > >> 5 files changed, 191 insertions(+), 101 deletions(-) > > > > How is this different from the patch you sent yesterday? > > It adds a missing %endrep for win64. ... extra good karma for using --annotate with git-send-email ... Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avio: K&R cosmetic formatting
---
libavformat/aviobuf.c | 121 --
1 file changed, 67 insertions(+), 54 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 15d132d..b762d10 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -76,27 +76,31 @@ int ffio_init_context(AVIOContext *s,
int (*write_packet)(void *opaque, uint8_t *buf, int
buf_size),
int64_t (*seek)(void *opaque, int64_t offset, int whence))
{
-s->buffer = buffer;
+s->buffer = buffer;
s->buffer_size = buffer_size;
-s->buf_ptr = buffer;
-s->opaque = opaque;
+s->buf_ptr = buffer;
+s->opaque = opaque;
+
url_resetbuf(s, write_flag ? AVIO_FLAG_WRITE : AVIO_FLAG_READ);
-s->write_packet = write_packet;
-s->read_packet = read_packet;
-s->seek = seek;
-s->pos = 0;
-s->must_flush = 0;
-s->eof_reached = 0;
-s->error = 0;
-s->seekable = AVIO_SEEKABLE_NORMAL;
+
+s->write_packet= write_packet;
+s->read_packet = read_packet;
+s->seek= seek;
+s->pos = 0;
+s->must_flush = 0;
+s->eof_reached = 0;
+s->error = 0;
+s->seekable= AVIO_SEEKABLE_NORMAL;
s->max_packet_size = 0;
-s->update_checksum= NULL;
-if(!read_packet && !write_flag){
-s->pos = buffer_size;
+s->update_checksum = NULL;
+
+if (!read_packet && !write_flag) {
+s->pos = buffer_size;
s->buf_end = s->buffer + buffer_size;
}
s->read_pause = NULL;
s->read_seek = NULL;
+
return 0;
}
@@ -120,15 +124,17 @@ AVIOContext *avio_alloc_context(
static void flush_buffer(AVIOContext *s)
{
if (s->buf_ptr > s->buffer) {
-if (s->write_packet && !s->error){
-int ret= s->write_packet(s->opaque, s->buffer, s->buf_ptr -
s->buffer);
-if(ret < 0){
+if (s->write_packet && !s->error) {
+int ret = s->write_packet(s->opaque, s->buffer,
+ s->buf_ptr - s->buffer);
+if (ret < 0) {
s->error = ret;
}
}
-if(s->update_checksum){
-s->checksum= s->update_checksum(s->checksum, s->checksum_ptr,
s->buf_ptr - s->checksum_ptr);
-s->checksum_ptr= s->buffer;
+if (s->update_checksum) {
+s->checksum = s->update_checksum(s->checksum, s->checksum_ptr,
+ s->buf_ptr - s->checksum_ptr);
+s->checksum_ptr = s->buffer;
}
s->pos += s->buf_ptr - s->buffer;
}
@@ -236,13 +242,13 @@ int64_t avio_size(AVIOContext *s)
{
int64_t size;
-if(!s)
+if (!s)
return AVERROR(EINVAL);
if (!s->seek)
return AVERROR(ENOSYS);
size = s->seek(s->opaque, 0, AVSEEK_SIZE);
-if(size<0){
+if (size < 0) {
if ((size = s->seek(s->opaque, -1, SEEK_END)) < 0)
return size;
size++;
@@ -288,29 +294,31 @@ int avio_put_str16le(AVIOContext *s, const char *str)
uint16_t tmp;
GET_UTF8(ch, *q++, break;)
-PUT_UTF16(ch, tmp, avio_wl16(s, tmp);ret += 2;)
+PUT_UTF16(ch, tmp, avio_wl16(s, tmp); ret += 2;)
}
avio_wl16(s, 0);
ret += 2;
return ret;
}
-int ff_get_v_length(uint64_t val){
-int i=1;
+int ff_get_v_length(uint64_t val)
+{
+int i = 1;
-while(val>>=7)
+while (val >>= 7)
i++;
return i;
}
-void ff_put_v(AVIOContext *bc, uint64_t val){
-int i= ff_get_v_length(val);
+void ff_put_v(AVIOContext *bc, uint64_t val)
+{
+int i = ff_get_v_length(val);
-while(--i>0)
-avio_w8(bc, 128 | (val>>(7*i)));
+while (--i > 0)
+avio_w8(bc, 128 | (val >> (7 * i)));
-avio_w8(bc, val&127);
+avio_w8(bc, val & 127);
}
void avio_wl64(AVIOContext *s, uint64_t val)
@@ -353,9 +361,12 @@ void avio_wb24(AVIOContext *s, unsigned int val)
static void fill_buffer(AVIOContext *s)
{
-uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer <
s->buffer_size ? s->buf_end : s->buffer;
-int len= s->buffer_size - (dst - s->buffer);
-int max_buffer_size = s->max_packet_size ? s->max_packet_size :
IO_BUFFER_SIZE;
+uint8_t *dst= !s->max_packet_size &&
+ s->buf_end - s->buffer < s->buffer_size ?
+ s->buf_end : s->buffer;
+int len = s->buffer_size - (dst - s->buffer);
+int max_buffer_size = s->max_packet_size ?
+ s->max_packet_size : IO_BUFFER_SIZE;
/* can't fill the buffer without read_packet, just set EOF if appropiate */
if (!s->read_packet && s->buf_ptr >= s->buf_end)
@@ -365,10 +376,11 @@ static void fill_buffer(AVIOContext *s)
if (s->eof_reached)
return;
-if(s->update_checksum && dst == s->buffer){
-if(s->buf_end > s->checksum_ptr)
-
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
On 12/09/2012 02:05 AM, Luca Barbato wrote: > I was waiting for the local x86 experts to chip in, did you test it on > win64 and mac I take, I can try it on linux if nobody did already. on amd64 seems fine as well. I guess can be pushed tomorrow. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] dsputil: drop non-compliant "fast" qpel mc functions
On 12/9/12 1:32 AM, Mans Rullgard wrote: --- libavcodec/dsputil.c | 16 - libavcodec/dsputil.h | 3 -- libavcodec/h263dec.c | 5 +-- libavcodec/h264.c | 11 ++- libavcodec/x86/dsputil_avg_template.c | 51 - libavcodec/x86/dsputil_mmx.c | 61 --- 6 files changed, 3 insertions(+), 144 deletions(-) To make cleaner the move makes sense to remove fringe features, probably could be interesting adding such approximate functions as a more encompassing project later if there is need for it. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
On 12/9/12 1:14 AM, Ronald S. Bultje wrote: Hi, On Sat, Dec 8, 2012 at 4:12 PM, Ronald S. Bultje wrote: From: "Ronald S. Bultje" Use this in VP8/H264-8bit loopfilter functions so they can be used if there is no aligned stack (e.g. MSVC 32bit or ICC 10.x). --- libavcodec/x86/h264_deblock.asm | 27 ++ libavcodec/x86/h264dsp_init.c | 4 +- libavcodec/x86/vp8dsp.asm | 68 --- libavcodec/x86/vp8dsp_init.c| 8 -- libavutil/x86/x86inc.asm| 185 5 files changed, 191 insertions(+), 101 deletions(-) One more fix for invalid stack free'ing if a YMM function on win64 used >6 registers, but no stack. Any more reviews, or can this be applied? I was waiting for the local x86 experts to chip in, did you test it on win64 and mac I take, I can try it on linux if nobody did already. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] dsputil: drop non-compliant "fast" qpel mc functions
---
libavcodec/dsputil.c | 16 -
libavcodec/dsputil.h | 3 --
libavcodec/h263dec.c | 5 +--
libavcodec/h264.c | 11 ++-
libavcodec/x86/dsputil_avg_template.c | 51 -
libavcodec/x86/dsputil_mmx.c | 61 ---
6 files changed, 3 insertions(+), 144 deletions(-)
diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
index d4471dc..cf32c70 100644
--- a/libavcodec/dsputil.c
+++ b/libavcodec/dsputil.c
@@ -2657,8 +2657,6 @@ int ff_check_alignment(void){
av_cold void ff_dsputil_init(DSPContext* c, AVCodecContext *avctx)
{
-int i, j;
-
ff_check_alignment();
#if CONFIG_ENCODERS
@@ -2869,9 +2867,6 @@ av_cold void ff_dsputil_init(DSPContext* c,
AVCodecContext *avctx)
c->prefetch= just_return;
-memset(c->put_2tap_qpel_pixels_tab, 0,
sizeof(c->put_2tap_qpel_pixels_tab));
-memset(c->avg_2tap_qpel_pixels_tab, 0,
sizeof(c->avg_2tap_qpel_pixels_tab));
-
#undef FUNC
#undef FUNCC
#define FUNC(f, depth) f ## _ ## depth
@@ -2970,17 +2965,6 @@ av_cold void ff_dsputil_init(DSPContext* c,
AVCodecContext *avctx)
if (ARCH_SH4)ff_dsputil_init_sh4 (c, avctx);
if (ARCH_BFIN) ff_dsputil_init_bfin (c, avctx);
-for (i = 0; i < 4; i++) {
-for (j = 0; j < 16; j++) {
-if(!c->put_2tap_qpel_pixels_tab[i][j])
-c->put_2tap_qpel_pixels_tab[i][j] =
-c->put_h264_qpel_pixels_tab[i][j];
-if(!c->avg_2tap_qpel_pixels_tab[i][j])
-c->avg_2tap_qpel_pixels_tab[i][j] =
-c->avg_h264_qpel_pixels_tab[i][j];
-}
-}
-
ff_init_scantable_permutation(c->idct_permutation,
c->idct_permutation_type);
}
diff --git a/libavcodec/dsputil.h b/libavcodec/dsputil.h
index c1bd401..241708e 100644
--- a/libavcodec/dsputil.h
+++ b/libavcodec/dsputil.h
@@ -348,9 +348,6 @@ typedef struct DSPContext {
qpel_mc_func put_h264_qpel_pixels_tab[4][16];
qpel_mc_func avg_h264_qpel_pixels_tab[4][16];
-qpel_mc_func put_2tap_qpel_pixels_tab[4][16];
-qpel_mc_func avg_2tap_qpel_pixels_tab[4][16];
-
me_cmp_func pix_abs[2][4];
/* huffyuv specific */
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 6281ed2..f2911e4 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -613,10 +613,7 @@ retry:
s->next_p_frame_damaged=0;
}
-if((s->avctx->flags2 & CODEC_FLAG2_FAST) &&
s->pict_type==AV_PICTURE_TYPE_B){
-s->me.qpel_put= s->dsp.put_2tap_qpel_pixels_tab;
-s->me.qpel_avg= s->dsp.avg_2tap_qpel_pixels_tab;
-}else if((!s->no_rounding) || s->pict_type==AV_PICTURE_TYPE_B){
+if((!s->no_rounding) || s->pict_type==AV_PICTURE_TYPE_B){
s->me.qpel_put= s->dsp.put_qpel_pixels_tab;
s->me.qpel_avg= s->dsp.avg_qpel_pixels_tab;
}else{
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 36f4c60..b3257e8 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -2361,15 +2361,8 @@ static int decode_slice_header(H264Context *h,
H264Context *h0)
int default_ref_list_done = 0;
int last_pic_structure, last_pic_dropable;
-/* FIXME: 2tap qpel isn't implemented for high bit depth. */
-if ((s->avctx->flags2 & CODEC_FLAG2_FAST) &&
-!h->nal_ref_idc && !h->pixel_shift) {
-s->me.qpel_put = s->dsp.put_2tap_qpel_pixels_tab;
-s->me.qpel_avg = s->dsp.avg_2tap_qpel_pixels_tab;
-} else {
-s->me.qpel_put = s->dsp.put_h264_qpel_pixels_tab;
-s->me.qpel_avg = s->dsp.avg_h264_qpel_pixels_tab;
-}
+s->me.qpel_put = s->dsp.put_h264_qpel_pixels_tab;
+s->me.qpel_avg = s->dsp.avg_h264_qpel_pixels_tab;
first_mb_in_slice = get_ue_golomb(&s->gb);
diff --git a/libavcodec/x86/dsputil_avg_template.c
b/libavcodec/x86/dsputil_avg_template.c
index 1a4343d..4fc188c 100644
--- a/libavcodec/x86/dsputil_avg_template.c
+++ b/libavcodec/x86/dsputil_avg_template.c
@@ -802,54 +802,3 @@ static void DEF(avg_pixels16_xy2)(uint8_t *block, const
uint8_t *pixels, int lin
DEF(avg_pixels8_xy2)(block , pixels , line_size, h);
DEF(avg_pixels8_xy2)(block+8, pixels+8, line_size, h);
}
-
-#define QPEL_2TAP_L3(OPNAME) \
-static void DEF(OPNAME ## 2tap_qpel16_l3)(uint8_t *dst, uint8_t *src, int
stride, int h, int off1, int off2){\
-__asm__ volatile(\
-"1:\n\t"\
-"movq (%1,%2), %%mm0 \n\t"\
-"movq 8(%1,%2), %%mm1 \n\t"\
-PAVGB" (%1,%3), %%mm0 \n\t"\
-PAVGB" 8(%1,%3), %%mm1 \n\t"\
-PAVGB" (%1),%%mm0 \n\t"\
-PAVGB" 8(%1),%%mm1 \n\t"\
-STORE_OP( (%1,%4),%%mm0)\
-STORE_OP(8(%1,%4),%%mm1)\
-"movq %%mm0, (%1,%4) \n\t"\
-"movq %%mm1, 8(%1,%4) \n\t"\
-"add %5, %1 \n\t"\
-"decl %0 \n\t"\
-"jnz 1b \
[libav-devel] [RFC PATCH 0/2] Separate h264 qpel from dsputil
This is a rough stab at splitting off h264 qpel from dsputil. It is ugly in places and incomplete (arm and ppc not updated), but it builds and passes tests. Comments welcome. Mans Rullgard (2): dsputil: drop non-compliant "fast" qpel mc functions Separate h264 qpel from dsptuil libavcodec/Makefile | 1 + libavcodec/dsputil.c | 43 --- libavcodec/dsputil.h | 6 - libavcodec/dsputil_template.c | 596 +- libavcodec/h263dec.c | 5 +- libavcodec/h264.c | 13 +- libavcodec/h264.h | 2 + libavcodec/h264qpel.c | 86 + libavcodec/h264qpel.h | 38 +++ libavcodec/h264qpel_template.c| 550 +++ libavcodec/hpel_template.h| 100 ++ libavcodec/rv30dsp.c | 12 +- libavcodec/rv40dsp.c | 28 +- libavcodec/x86/Makefile | 1 + libavcodec/x86/dsputil_avg_template.c | 51 --- libavcodec/x86/dsputil_mmx.c | 154 + libavcodec/x86/h264_qpel.c| 126 +++ 17 files changed, 939 insertions(+), 873 deletions(-) create mode 100644 libavcodec/h264qpel.c create mode 100644 libavcodec/h264qpel.h create mode 100644 libavcodec/h264qpel_template.c create mode 100644 libavcodec/hpel_template.h -- 1.8.0 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
Hi, On Sat, Dec 8, 2012 at 4:12 PM, Ronald S. Bultje wrote: > From: "Ronald S. Bultje" > > Use this in VP8/H264-8bit loopfilter functions so they can be used if > there is no aligned stack (e.g. MSVC 32bit or ICC 10.x). > --- > libavcodec/x86/h264_deblock.asm | 27 ++ > libavcodec/x86/h264dsp_init.c | 4 +- > libavcodec/x86/vp8dsp.asm | 68 --- > libavcodec/x86/vp8dsp_init.c| 8 -- > libavutil/x86/x86inc.asm| 185 > > 5 files changed, 191 insertions(+), 101 deletions(-) One more fix for invalid stack free'ing if a YMM function on win64 used >6 registers, but no stack. Any more reviews, or can this be applied? Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
From: "Ronald S. Bultje"
Use this in VP8/H264-8bit loopfilter functions so they can be used if
there is no aligned stack (e.g. MSVC 32bit or ICC 10.x).
---
libavcodec/x86/h264_deblock.asm | 27 ++
libavcodec/x86/h264dsp_init.c | 4 +-
libavcodec/x86/vp8dsp.asm | 68 ---
libavcodec/x86/vp8dsp_init.c| 8 --
libavutil/x86/x86inc.asm| 185
5 files changed, 191 insertions(+), 101 deletions(-)
diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index c124c4d..1f1dbc6 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -398,14 +398,12 @@ DEBLOCK_LUMA
;-
; void deblock_v8_luma( uint8_t *pix, int stride, int alpha, int beta, int8_t
*tc0 )
;-
-cglobal deblock_%1_luma_8, 5,5
+cglobal deblock_%1_luma_8, 5,5,8,2*%2
lea r4, [r1*3]
dec r2 ; alpha-1
neg r4
dec r3 ; beta-1
add r4, r0 ; pix-3*stride
-%assign pad 2*%2+12-(stack_offset&15)
-SUB esp, pad
movam0, [r4+r1] ; p1
movam1, [r4+2*r1] ; p0
@@ -443,22 +441,19 @@ cglobal deblock_%1_luma_8, 5,5
DEBLOCK_P0_Q0
mova[r4+2*r1], m1
mova[r0], m2
-ADD esp, pad
RET
;-
; void deblock_h_luma( uint8_t *pix, int stride, int alpha, int beta, int8_t
*tc0 )
;-
INIT_MMX cpuname
-cglobal deblock_h_luma_8, 0,5
+cglobal deblock_h_luma_8, 0,5,8,0x60+HAVE_ALIGNED_STACK*12
movr0, r0mp
movr3, r1m
lear4, [r3*3]
subr0, 4
lear1, [r0+r4]
-%assign pad 0x78-(stack_offset&15)
-SUBesp, pad
-%define pix_tmp esp+12
+%define pix_tmp esp+12*HAVE_ALIGNED_STACK
; transpose 6x16 -> tmp space
TRANSPOSE6x8_MEM PASS8ROWS(r0, r1, r3, r4), pix_tmp
@@ -500,7 +495,6 @@ cglobal deblock_h_luma_8, 0,5
movq m3, [pix_tmp+0x48]
TRANSPOSE8x4B_STORE PASS8ROWS(r0, r1, r3, r4)
-ADDesp, pad
RET
%endmacro ; DEBLOCK_LUMA
@@ -631,7 +625,7 @@ DEBLOCK_LUMA v, 16
%define mpb_0 m14
%define mpb_1 m15
%else
-%define spill(x) [esp+16*x+((stack_offset+4)&15)]
+%define spill(x) [esp+16*x]
%define p2 [r4+r1]
%define q2 [r0+2*r1]
%define t4 spill(0)
@@ -646,10 +640,7 @@ DEBLOCK_LUMA v, 16
;-
; void deblock_v_luma_intra( uint8_t *pix, int stride, int alpha, int beta )
;-
-cglobal deblock_%1_luma_intra_8, 4,6,16
-%if ARCH_X86_64 == 0
-sub esp, 0x60
-%endif
+cglobal deblock_%1_luma_intra_8, 4,6,16,ARCH_X86_64*0x50-0x50
lea r4, [r1*4]
lea r5, [r1*3] ; 3*stride
dec r2d; alpha-1
@@ -698,9 +689,6 @@ cglobal deblock_%1_luma_intra_8, 4,6,16
LUMA_INTRA_SWAP_PQ
LUMA_INTRA_P012 [r0], [r0+r1], [r0+2*r1], [r0+r5]
.end:
-%if ARCH_X86_64 == 0
-add esp, 0x60
-%endif
RET
INIT_MMX cpuname
@@ -737,12 +725,10 @@ cglobal deblock_h_luma_intra_8, 4,9
addrsp, 0x88
RET
%else
-cglobal deblock_h_luma_intra_8, 2,4
+cglobal deblock_h_luma_intra_8, 2,4,8,0x80
lear3, [r1*3]
subr0, 4
lear2, [r0+r3]
-%assign pad 0x8c-(stack_offset&15)
-SUBrsp, pad
%define pix_tmp rsp
; transpose 8x16 -> tmp space
@@ -773,7 +759,6 @@ cglobal deblock_h_luma_intra_8, 2,4
lear0, [r0+r1*8]
lear2, [r2+r1*8]
TRANSPOSE8x8_MEM PASS8ROWS(pix_tmp+8, pix_tmp+0x38, 0x10, 0x30),
PASS8ROWS(r0, r2, r1, r3)
-ADDrsp, pad
RET
%endif ; ARCH_X86_64
%endmacro ; DEBLOCK_LUMA_INTRA
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index ac231cb..73d4990 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -275,18 +275,16 @@ void ff_h264dsp_init_x86(H264DSPContext *c, const int
bit_depth,
c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_sse2;
c->biweight_h264_pixels_tab[1] = ff_h264_biweight_8_sse2;
-#if HAVE_ALIGNED_STACK
c->h264_v_loop_filter_luma =
ff_deblock_v_luma_8_sse2;
c->h264_h_loop_filter_luma =
ff_deblock_h_luma_8_sse2;
c->h264_v_loop_filter_luma_intra =
ff_deblock_v_luma_intra_8_sse2;
c->h264_h_loop_filter_luma_intra =
ff_deblock_h_luma_intra_8_sse2;
-#endif /* HAVE_ALIGNED_STACK */
}
if (EXTERNAL_SSSE3(mm_flags)) {
c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_ssse3;
c->biweight_h264_pixels
Re: [libav-devel] [PATCH 1/1] svq3: make slice type value unsigned to match svq3_get_ue_golomb return type
On 12/8/12 10:37 PM, Janne Grunau wrote: --- libavcodec/svq3.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) Ok, I guess. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/1] svq3: make slice type value unsigned to match svq3_get_ue_golomb return type
---
libavcodec/svq3.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c
index 013dee8..0bfc73e 100644
--- a/libavcodec/svq3.c
+++ b/libavcodec/svq3.c
@@ -750,6 +750,7 @@ static int svq3_decode_slice_header(AVCodecContext *avctx)
MpegEncContext *s = &h->s;
const int mb_xy = h->mb_xy;
int i, header;
+unsigned slice_id;
header = get_bits(&s->gb, 8);
@@ -784,12 +785,12 @@ static int svq3_decode_slice_header(AVCodecContext *avctx)
skip_bits_long(&s->gb, 0);
}
-if ((i = svq3_get_ue_golomb(&s->gb)) >= 3) {
-av_log(h->s.avctx, AV_LOG_ERROR, "illegal slice type %d \n", i);
+if ((slice_id = svq3_get_ue_golomb(&s->gb)) >= 3) {
+av_log(h->s.avctx, AV_LOG_ERROR, "illegal slice type %d \n", slice_id);
return -1;
}
-h->slice_type = golomb_to_pict_type[i];
+h->slice_type = golomb_to_pict_type[slice_id];
if ((header & 0x9F) == 2) {
i = (s->mb_num < 64) ? 6 : (1 + av_log2(s->mb_num - 1));
--
1.7.12.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/4] hls: add start_number option
On 08/12/2012 06:17, Luca Barbato wrote:
> +{ "start_number", "first number in the sequence",
> OFFSET(number), AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> {"hls_time", "segment length in seconds",
> OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
LGTM but what about alignment?
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: fix arithmetic overflows in avformat_seek_file()
Janne Grunau writes: > On 2012-12-07 13:54:02 +, Måns Rullgård wrote: >> The values compared here can be more than INT64_MAX apart. Since the >> difference is always positive, converting to uint64_t before subtracting >> gives the correct result without overflows. > > s/(without)/\1 undefined/ it still relies on defined over/underflow > behavior of unsigned types. No, unsigned wraparound is not termed an overflow. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: fix arithmetic overflows in avformat_seek_file()
On 2012-12-07 13:54:02 +, Måns Rullgård wrote: > The values compared here can be more than INT64_MAX apart. Since the > difference is always positive, converting to uint64_t before subtracting > gives the correct result without overflows. s/(without)/\1 undefined/ it still relies on defined over/underflow behavior of unsigned types. > Signed-off-by: Mans Rullgard > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index 12b054d..cd46caf 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -1762,7 +1762,7 @@ int avformat_seek_file(AVFormatContext *s, int > stream_index, int64_t min_ts, int > //Fallback to old API if new is not implemented but old is > //Note the old has somewat different sematics > if(s->iformat->read_seek || 1) > -return av_seek_frame(s, stream_index, ts, flags | (ts - min_ts > > (uint64_t)(max_ts - ts) ? AVSEEK_FLAG_BACKWARD : 0)); > +return av_seek_frame(s, stream_index, ts, flags | ((uint64_t)ts - > min_ts > (uint64_t)max_ts - ts ? AVSEEK_FLAG_BACKWARD : 0)); > > // try some generic seek like seek_frame_generic() but with new ts > semantics > } patch ok Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
Hi, On Sat, Dec 8, 2012 at 8:41 AM, Måns Rullgård wrote: > "Ronald S. Bultje" writes: > >> From: "Ronald S. Bultje" >> >> Use this in VP8/H264-8bit loopfilter functions so they can be used if >> there is no aligned stack (e.g. MSVC 32bit or ICC 10.x). >> --- >> libavcodec/x86/h264_deblock.asm | 27 ++ >> libavcodec/x86/h264dsp_init.c | 4 +- >> libavcodec/x86/vp8dsp.asm | 68 --- >> libavcodec/x86/vp8dsp_init.c| 8 -- >> libavutil/x86/x86inc.asm| 185 >> >> 5 files changed, 191 insertions(+), 101 deletions(-) > > How is this different from the patch you sent yesterday? It adds a missing %endrep for win64. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
"Ronald S. Bultje" writes: > From: "Ronald S. Bultje" > > Use this in VP8/H264-8bit loopfilter functions so they can be used if > there is no aligned stack (e.g. MSVC 32bit or ICC 10.x). > --- > libavcodec/x86/h264_deblock.asm | 27 ++ > libavcodec/x86/h264dsp_init.c | 4 +- > libavcodec/x86/vp8dsp.asm | 68 --- > libavcodec/x86/vp8dsp_init.c| 8 -- > libavutil/x86/x86inc.asm| 185 > > 5 files changed, 191 insertions(+), 101 deletions(-) How is this different from the patch you sent yesterday? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] x86inc: support stack mem allocation and re-alignment in PROLOGUE.
From: "Ronald S. Bultje"
Use this in VP8/H264-8bit loopfilter functions so they can be used if
there is no aligned stack (e.g. MSVC 32bit or ICC 10.x).
---
libavcodec/x86/h264_deblock.asm | 27 ++
libavcodec/x86/h264dsp_init.c | 4 +-
libavcodec/x86/vp8dsp.asm | 68 ---
libavcodec/x86/vp8dsp_init.c| 8 --
libavutil/x86/x86inc.asm| 185
5 files changed, 191 insertions(+), 101 deletions(-)
diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm
index c124c4d..1f1dbc6 100644
--- a/libavcodec/x86/h264_deblock.asm
+++ b/libavcodec/x86/h264_deblock.asm
@@ -398,14 +398,12 @@ DEBLOCK_LUMA
;-
; void deblock_v8_luma( uint8_t *pix, int stride, int alpha, int beta, int8_t
*tc0 )
;-
-cglobal deblock_%1_luma_8, 5,5
+cglobal deblock_%1_luma_8, 5,5,8,2*%2
lea r4, [r1*3]
dec r2 ; alpha-1
neg r4
dec r3 ; beta-1
add r4, r0 ; pix-3*stride
-%assign pad 2*%2+12-(stack_offset&15)
-SUB esp, pad
movam0, [r4+r1] ; p1
movam1, [r4+2*r1] ; p0
@@ -443,22 +441,19 @@ cglobal deblock_%1_luma_8, 5,5
DEBLOCK_P0_Q0
mova[r4+2*r1], m1
mova[r0], m2
-ADD esp, pad
RET
;-
; void deblock_h_luma( uint8_t *pix, int stride, int alpha, int beta, int8_t
*tc0 )
;-
INIT_MMX cpuname
-cglobal deblock_h_luma_8, 0,5
+cglobal deblock_h_luma_8, 0,5,8,0x60+HAVE_ALIGNED_STACK*12
movr0, r0mp
movr3, r1m
lear4, [r3*3]
subr0, 4
lear1, [r0+r4]
-%assign pad 0x78-(stack_offset&15)
-SUBesp, pad
-%define pix_tmp esp+12
+%define pix_tmp esp+12*HAVE_ALIGNED_STACK
; transpose 6x16 -> tmp space
TRANSPOSE6x8_MEM PASS8ROWS(r0, r1, r3, r4), pix_tmp
@@ -500,7 +495,6 @@ cglobal deblock_h_luma_8, 0,5
movq m3, [pix_tmp+0x48]
TRANSPOSE8x4B_STORE PASS8ROWS(r0, r1, r3, r4)
-ADDesp, pad
RET
%endmacro ; DEBLOCK_LUMA
@@ -631,7 +625,7 @@ DEBLOCK_LUMA v, 16
%define mpb_0 m14
%define mpb_1 m15
%else
-%define spill(x) [esp+16*x+((stack_offset+4)&15)]
+%define spill(x) [esp+16*x]
%define p2 [r4+r1]
%define q2 [r0+2*r1]
%define t4 spill(0)
@@ -646,10 +640,7 @@ DEBLOCK_LUMA v, 16
;-
; void deblock_v_luma_intra( uint8_t *pix, int stride, int alpha, int beta )
;-
-cglobal deblock_%1_luma_intra_8, 4,6,16
-%if ARCH_X86_64 == 0
-sub esp, 0x60
-%endif
+cglobal deblock_%1_luma_intra_8, 4,6,16,ARCH_X86_64*0x50-0x50
lea r4, [r1*4]
lea r5, [r1*3] ; 3*stride
dec r2d; alpha-1
@@ -698,9 +689,6 @@ cglobal deblock_%1_luma_intra_8, 4,6,16
LUMA_INTRA_SWAP_PQ
LUMA_INTRA_P012 [r0], [r0+r1], [r0+2*r1], [r0+r5]
.end:
-%if ARCH_X86_64 == 0
-add esp, 0x60
-%endif
RET
INIT_MMX cpuname
@@ -737,12 +725,10 @@ cglobal deblock_h_luma_intra_8, 4,9
addrsp, 0x88
RET
%else
-cglobal deblock_h_luma_intra_8, 2,4
+cglobal deblock_h_luma_intra_8, 2,4,8,0x80
lear3, [r1*3]
subr0, 4
lear2, [r0+r3]
-%assign pad 0x8c-(stack_offset&15)
-SUBrsp, pad
%define pix_tmp rsp
; transpose 8x16 -> tmp space
@@ -773,7 +759,6 @@ cglobal deblock_h_luma_intra_8, 2,4
lear0, [r0+r1*8]
lear2, [r2+r1*8]
TRANSPOSE8x8_MEM PASS8ROWS(pix_tmp+8, pix_tmp+0x38, 0x10, 0x30),
PASS8ROWS(r0, r2, r1, r3)
-ADDrsp, pad
RET
%endif ; ARCH_X86_64
%endmacro ; DEBLOCK_LUMA_INTRA
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index ac231cb..73d4990 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -275,18 +275,16 @@ void ff_h264dsp_init_x86(H264DSPContext *c, const int
bit_depth,
c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_sse2;
c->biweight_h264_pixels_tab[1] = ff_h264_biweight_8_sse2;
-#if HAVE_ALIGNED_STACK
c->h264_v_loop_filter_luma =
ff_deblock_v_luma_8_sse2;
c->h264_h_loop_filter_luma =
ff_deblock_h_luma_8_sse2;
c->h264_v_loop_filter_luma_intra =
ff_deblock_v_luma_intra_8_sse2;
c->h264_h_loop_filter_luma_intra =
ff_deblock_h_luma_intra_8_sse2;
-#endif /* HAVE_ALIGNED_STACK */
}
if (EXTERNAL_SSSE3(mm_flags)) {
c->biweight_h264_pixels_tab[0] = ff_h264_biweight_16_ssse3;
c->biweight_h264_pixels
Re: [libav-devel] [PATCH 4/4] img2: document the options available
On 2012-12-08 06:17:05 +0100, Luca Barbato wrote:
> ---
> doc/demuxers.texi | 13 +
> doc/muxers.texi | 5 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index c3049dd..2d5c425 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -64,6 +64,19 @@ Note that the pattern must not necessarily contain "%d" or
> avconv -i img.jpeg img.png
> @end example
>
> +@table @option
> +@item -pixel_format @var{format}
> +Set the pixel format (for raw image)
> +@item -video_size @var{size}
> +Set the frame size (for raw image)
> +@item -framerate@var{rate}
> +Set the frame rate
> +@item -loop @var{bool}
> +Loop over the images
> +@item -start_number @var{start}
> +Specify the first number in the sequence
> +@end table
> +
> @section applehttp
>
> Apple HTTP Live Streaming demuxer.
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 4104137..4973f1a 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -168,6 +168,11 @@ Note also that the pattern must not necessarily contain
> "%d" or
> avconv -i in.avi -f image2 -frames:v 1 img.jpeg
> @end example
>
> +@table @option
> +@item -start_number @var{number}
> +Start the sequence from @var{number}.
> +@end table
> +
> @section MOV/MP4/ISMV
>
> The mov/mp4/ismv muxer supports fragmentation. Normally, a MOV/MP4
ok,
If someone is really motivated: a automated method for extracting
codec/demux specific options for the documentation might be a good idea.
Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/4] hls: add start_number option
On 2012-12-08 06:17:02 +0100, Luca Barbato wrote:
> ---
> doc/muxers.texi | 1 +
> libavformat/hlsenc.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 570041d..a2a9ce4 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -109,6 +109,7 @@ avconv -i in.nut out.m3u8
> @item -hls_time segment length in seconds
> @item -hls_list_size maximum number of playlist entries
> @item -hls_wrap number after which index wraps
> +@item -start_number first number in the sequence
> @end table
>
> @anchor{image2}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 88f47e0..1003b85 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -295,6 +295,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
> #define OFFSET(x) offsetof(HLSContext, x)
> #define E AV_OPT_FLAG_ENCODING_PARAM
> static const AVOption options[] = {
> +{ "start_number", "first number in the sequence",
> OFFSET(number), AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> {"hls_time", "segment length in seconds",
> OFFSET(time),AV_OPT_TYPE_FLOAT, {.dbl = 2}, 0, FLT_MAX, E},
> {"hls_list_size", "maximum number of playlist entries",
> OFFSET(size),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
> {"hls_wrap", "number after which the index wraps",
> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
ok
Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] h264: K&R formatting cosmetics
On 2012-12-08 03:16:18 +0100, Luca Barbato wrote: > On 12/8/12 2:51 AM, Luca Barbato wrote: > > On 12/8/12 2:45 AM, Clément Bœsch wrote: > >> On Sat, Dec 08, 2012 at 02:17:04AM +0100, Luca Barbato wrote: > >> Review in form of patches mostly welcome for this one > > > > It is an uncrustify pass with some of the glaring ugliness removed, I > > was expecting to miss some and thus I asked for updated patches as > > review process to speed up cleaning up the cleaning up. > > > > An update will follow up tomorrow I guess. > > Patch postponed pending Janne work on h264 for now. You misunderstood me. This file is save. Current diffstat for adaptive-mt h264 is libavcodec/h264.c| 479 +-- libavcodec/h264.h| 6 + libavcodec/h264_direct.c | 4 +- libavcodec/h264_ps.c | 3 + libavcodec/h264_refs.c | 30 +++-- libavcodec/mpegvideo.c | 14 ++- libavcodec/svq3.c| 7 +- libavformat/mov.c| 2 +- 8 files changed, 350 insertions(+), 195 deletions(-) So reindenting h264.c and maybe h264_refs.c would be annoying, the rest is manegable. Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] lavu: add av_lfg_get_flt() to get a random float
On Fri, Dec 07, 2012 at 04:01:29PM -0500, Justin Ruggles wrote:
> --- a/libavutil/lfg.h
> +++ b/libavutil/lfg.h
> @@ -41,6 +43,14 @@ static inline unsigned int av_lfg_get(AVLFG *c){
>
> /**
> + * Get the next random float, in the range -0.5 to 0.5, using an ALFG.
> + */
> +static inline float av_lfg_get_flt(AVLFG *lfg)
> +{
> +return (av_lfg_get(lfg) / (float)UINT32_MAX) - 0.5f;
> +}
Please also document the parameter, we'll never get Doxygen warnings
under control otherwise..
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/1] mjpeg: initialize input padding after unescaped buffer to zero
On 12/8/12 4:24 PM, Janne Grunau wrote: Fixes valgrind --undef-value-errors=yes warnings caused by valid overreads in the fate vsynth jpegls, cover-art-ape and cover-art-wv tests. --- Ok. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/1] mjpeg: initialize input padding after unescaped buffer to zero
Fixes valgrind --undef-value-errors=yes warnings caused by valid
overreads in the fate vsynth jpegls, cover-art-ape and cover-art-wv
tests.
---
libavcodec/mjpegdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 104a63d..0b22bca 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1387,6 +1387,8 @@ int ff_mjpeg_find_marker(MJpegDecodeContext *s,
}
*unescaped_buf_ptr = s->buffer;
*unescaped_buf_size = dst - s->buffer;
+memset(s->buffer + *unescaped_buf_size, 0,
+ FF_INPUT_BUFFER_PADDING_SIZE);
av_log(s->avctx, AV_LOG_DEBUG, "escaping removed %td bytes\n",
(buf_end - *buf_ptr) - (dst - s->buffer));
@@ -1428,6 +1430,8 @@ int ff_mjpeg_find_marker(MJpegDecodeContext *s,
*unescaped_buf_ptr = dst;
*unescaped_buf_size = (bit_count + 7) >> 3;
+memset(s->buffer + *unescaped_buf_size, 0,
+ FF_INPUT_BUFFER_PADDING_SIZE);
} else {
*unescaped_buf_ptr = *buf_ptr;
*unescaped_buf_size = buf_end - *buf_ptr;
--
1.7.12.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec: Fix a typo in an option description
On Sat, Dec 08, 2012 at 10:08:14AM +0100, Anton Khirnov wrote: > On Fri, 07 Dec 2012 16:01:40 +0100, Diego Biurrun wrote: > > On Fri, Dec 07, 2012 at 03:50:49PM +0200, Martin Storsjö wrote: > > > --- > > > libavcodec/options_table.h |2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > I suggest to hold off on this spelling fix and collect more typo fixes > > into a larger batch so as to not clutter up the git log too much with > > trivial commits. I have a commit locally that collects typo fixes and > > I have folded your patch into it. I'll send it when it has reached > > a size that it feels worth publishing. > > I disagree. > > What you said might make sense for purely internal invisible stuff like > variable names or comments, but this is an option description that will > be shown to a user. We should fix such things immediately IMO. If you see such urgency, why don't you go ahead and fix all the typos in that file? There surely is no shortage ... :) I'll send a patch tomorrow. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/4] hls: use a meaningful long name
On Sat, Dec 08, 2012 at 06:17:03AM +0100, Luca Barbato wrote: > --- > libavformat/hlsenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Should be OK. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] hls: improve options description
On Sat, Dec 08, 2012 at 06:17:04AM +0100, Luca Barbato wrote: > --- > doc/muxers.texi | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) LGTM Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec: Fix a typo in an option description
On Fri, 07 Dec 2012 16:01:40 +0100, Diego Biurrun wrote: > On Fri, Dec 07, 2012 at 03:50:49PM +0200, Martin Storsjö wrote: > > --- > > libavcodec/options_table.h |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > I suggest to hold off on this spelling fix and collect more typo fixes > into a larger batch so as to not clutter up the git log too much with > trivial commits. I have a commit locally that collects typo fixes and > I have folded your patch into it. I'll send it when it has reached > a size that it feels worth publishing. > I disagree. What you said might make sense for purely internal invisible stuff like variable names or comments, but this is an option description that will be shown to a user. We should fix such things immediately IMO. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
