Re: [FFmpeg-devel] [PATCH 4/5] x86: hevc_mc: fewer xmm regs used in epel h/v
2015-02-17 8:28 GMT+01:00 Mickaël Raulet : > It seems to me that you are affecting 8 when it is avx2 instead of 11. > Shouldn't it be the opposite? At least this what the commit message says. Huh, brainfart... And the fact that I can't easily test avx2 doesn't help. So here's a patch with the values swapped out. From 2955eea46501d096a47fbf2fb1824daa622f6031 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Mon, 16 Feb 2015 20:12:04 +0100 Subject: [PATCH 2/3] x86: hevc_mc: fewer xmm regs used in epel h/v 11 xmm regs seem only required for avx2. --- libavcodec/x86/hevc_mc.asm | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index 6ef8a60..b86d697 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -730,7 +730,13 @@ cglobal hevc_put_hevc_bi_pel_pixels%1_%2, 6, 6, 6, dst, dststride, src, srcstrid %macro HEVC_PUT_HEVC_EPEL 2 -cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rfilter +%if cpuflag(avx2) +%define XMM_REGS 11 +%else +%define XMM_REGS 8 +%endif + +cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, XMM_REGS, dst, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) EPEL_FILTER %2, mx, m4, m5, rfilter .loop @@ -740,7 +746,7 @@ cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rf LOOP_END dst, src, srcstride RET -cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 11, dst, dststride, src, srcstride, height, mx, rfilter +cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, XMM_REGS, dst, dststride, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) movdqam6, [pw_%2] EPEL_FILTER %2, mx, m4, m5, rfilter @@ -755,7 +761,7 @@ cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 11, dst, dststride, src, srcstride, jnz .loop ; height loop RET -cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, 11, dst, dststride, src, srcstride, src2, height, mx, rfilter +cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, XMM_REGS, dst, dststride, src, srcstride, src2, height, mx, rfilter movdqam6, [pw_bi_%2] EPEL_FILTER %2, mx, m4, m5, rfilter .loop @@ -777,7 +783,7 @@ cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, 11, dst, dststride, src, srcstride, ; int height, int mx, int my, int width) ; ** -cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, 11, dst, src, srcstride, height, r3src, my +cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, XMM_REGS, dst, src, srcstride, height, r3src, my movifnidnmyd, mym sub srcq, srcstrideq EPEL_FILTER %2, my, m4, m5, r3src @@ -789,7 +795,7 @@ cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, 11, dst, src, srcstride, height, r3src, LOOP_END dst, src, srcstride RET -cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, 11, dst, dststride, src, srcstride, height, r3src, my +cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, XMM_REGS, dst, dststride, src, srcstride, height, r3src, my movifnidnmyd, mym movdqam6, [pw_%2] sub srcq, srcstrideq @@ -807,7 +813,7 @@ cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, 11, dst, dststride, src, srcstride, RET -cglobal hevc_put_hevc_bi_epel_v%1_%2, 6, 8, 11, dst, dststride, src, srcstride, src2, height, r3src, my +cglobal hevc_put_hevc_bi_epel_v%1_%2, 6, 8, XMM_REGS, dst, dststride, src, srcstride, src2, height, r3src, my movifnidnmyd, mym movdqam6, [pw_bi_%2] sub srcq, srcstrideq -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] x86: hevc_mc: fewer xmm regs used in epel h/v
It seems to me that you are affecting 8 when it is avx2 instead of 11. Shouldn't it be the opposite? At least this what the commit message says. Mickaël Le mardi 17 février 2015, Christophe Gisquet a écrit : > Hi, > > here's an updated patch, which takes into account the fact avx2 > sometimes uses additional intermediate xmm regs. > > Maybe the fix is actually changing the avx2 code, but avx2 and x86_32 > is a really weird combination. > > -- > Christophe > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] x86: hevc_mc: put_pixels and 1d epel for x86_32
Hi, 2015-02-07 23:11 GMT+01:00 Michael Niedermayer : > this breaks building shared libs: > > /usr/bin/ld: libavcodec/x86/hevc_mc.o: relocation R_X86_64_32 against `.text' > can not be used when making a shared object; recompile with -fPIC > libavcodec/x86/hevc_mc.o: could not read symbols: Bad value > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make: *** [libavcodec/libavcodec.so.56] Error 1 > make: *** Waiting for unfinished jobs I'll need to check, as I don't think the 2 previous patches were updated in a way fixing this. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/doc/Makefile: DBG=1 to preprocess external asm
Hi, 2015-02-08 14:54 GMT+01:00 Christophe Gisquet : > 2015-02-08 14:07 GMT+01:00 Carl Eugen Hoyos : >> Doesn't this also need an update for "make clean"? > > Right, here's an updated one, also improving dependency generation and > allowing more genering (for now) code. Ping? I can probably live with having it in a shell script/function if that patch worries people. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86inc: also warn on sse2 instruction
Hi, 2015-02-08 14:53 GMT+01:00 Christophe Gisquet : > This one is specifically for "might be insn set a or b, but reg size > makes it clearer". Ping? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] x86: hevc_mc: fewer xmm regs used in epel h/v
Hi, here's an updated patch, which takes into account the fact avx2 sometimes uses additional intermediate xmm regs. Maybe the fix is actually changing the avx2 code, but avx2 and x86_32 is a really weird combination. -- Christophe From 2955eea46501d096a47fbf2fb1824daa622f6031 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Mon, 16 Feb 2015 20:12:04 +0100 Subject: [PATCH 2/3] x86: hevc_mc: fewer xmm regs used in epel h/v 11 xmm regs seem only required for avx2. --- libavcodec/x86/hevc_mc.asm | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index 6ef8a60..b86d697 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -730,7 +730,13 @@ cglobal hevc_put_hevc_bi_pel_pixels%1_%2, 6, 6, 6, dst, dststride, src, srcstrid %macro HEVC_PUT_HEVC_EPEL 2 -cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rfilter +%if cpuflag(avx2) +%define XMM_REGS 8 +%else +%define XMM_REGS 11 +%endif + +cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, XMM_REGS, dst, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) EPEL_FILTER %2, mx, m4, m5, rfilter .loop @@ -740,7 +746,7 @@ cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rf LOOP_END dst, src, srcstride RET -cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 11, dst, dststride, src, srcstride, height, mx, rfilter +cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, XMM_REGS, dst, dststride, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) movdqam6, [pw_%2] EPEL_FILTER %2, mx, m4, m5, rfilter @@ -755,7 +761,7 @@ cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 11, dst, dststride, src, srcstride, jnz .loop ; height loop RET -cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, 11, dst, dststride, src, srcstride, src2, height, mx, rfilter +cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, XMM_REGS, dst, dststride, src, srcstride, src2, height, mx, rfilter movdqam6, [pw_bi_%2] EPEL_FILTER %2, mx, m4, m5, rfilter .loop @@ -777,7 +783,7 @@ cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, 11, dst, dststride, src, srcstride, ; int height, int mx, int my, int width) ; ** -cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, 11, dst, src, srcstride, height, r3src, my +cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, XMM_REGS, dst, src, srcstride, height, r3src, my movifnidnmyd, mym sub srcq, srcstrideq EPEL_FILTER %2, my, m4, m5, r3src @@ -789,7 +795,7 @@ cglobal hevc_put_hevc_epel_v%1_%2, 4, 6, 11, dst, src, srcstride, height, r3src, LOOP_END dst, src, srcstride RET -cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, 11, dst, dststride, src, srcstride, height, r3src, my +cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, XMM_REGS, dst, dststride, src, srcstride, height, r3src, my movifnidnmyd, mym movdqam6, [pw_%2] sub srcq, srcstrideq @@ -807,7 +813,7 @@ cglobal hevc_put_hevc_uni_epel_v%1_%2, 5, 7, 11, dst, dststride, src, srcstride, RET -cglobal hevc_put_hevc_bi_epel_v%1_%2, 6, 8, 11, dst, dststride, src, srcstride, src2, height, r3src, my +cglobal hevc_put_hevc_bi_epel_v%1_%2, 6, 8, XMM_REGS, dst, dststride, src, srcstride, src2, height, r3src, my movifnidnmyd, mym movdqam6, [pw_bi_%2] sub srcq, srcstrideq -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] ffmpeg: try to guess a good value for the thread message queue.
On Mon, Feb 16, 2015 at 10:22:17PM +0100, Nicolas George wrote:
> The current value, 8, is too low to be really useful.
> The heuristic tries to allocate enough room for 10 seconds.
>
> Signed-off-by: Nicolas George
> ---
> ffmpeg.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
>
> On my hardware, recording from v4l2 and ALSA produces ALSA underruns if the
> message queue is below ~256-512.
>
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index a52de20..990ce9e 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -3412,9 +3412,29 @@ static void free_input_threads(void)
> }
> }
>
> +static int eval_thread_queue_size(InputFile *f)
> +{
> +int i, s;
> +int64_t sec = 10, fps = 0;
> +
> +for (i = 0; i < f->ctx->nb_streams; i++) {
> +AVStream *st = f->ctx->streams[i];
> +AVCodecContext *c = st->codec;
> +if (c->sample_rate && c->frame_size) {
> +fps += sec * (c->sample_rate / c->frame_size + 1);
> +} else if (st->avg_frame_rate.num && st->avg_frame_rate.den) {
> +fps += 1 + av_rescale(sec, st->avg_frame_rate.num,
> st->avg_frame_rate.den);
> +} else {
> +fps += 25 * sec;
> +}
> +}
> +s = FFMAX(3, FFMIN(20, av_log2(fps) + 1));
iam a bit concerned about the possibility of this unneccesarily
allocating a million packets
i think IIUC this amount will actually be alloated no matter if its
needed or not
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- 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 2/3] ffmpeg: notify when the thread message queue blocks.
On Mon, Feb 16, 2015 at 10:22:16PM +0100, Nicolas George wrote: > This can help finding the source of A-V desync with live input. > > Signed-off-by: Nicolas George > --- > ffmpeg.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] ffplay: factorize subtitle rendering code to a private filter
On Sat, 14 Feb 2015, Clément Bœsch wrote: On Sat, Feb 14, 2015 at 02:08:15AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint --- Makefile | 1 + doc/ffplay.texi | 4 + ffplay.c | 336 + libavfilter/Makefile | 1 + libavfilter/vf_ffplay_subtitle.c | 347 +++ libavfilter/vf_ffplay_subtitle.h | 38 + 6 files changed, 434 insertions(+), 293 deletions(-) create mode 100644 libavfilter/vf_ffplay_subtitle.c create mode 100644 libavfilter/vf_ffplay_subtitle.h This is not the correct way of doing it. The proper way is to integrate subtitles within lavfi. If you want to work toward this, feel free to ask for more details, but it's not trivial. (and no, this patch is not an improvement in the correct direction, sorry) What would be an improvement in the right direction? I see little chance that I will work on subtitles in lavfi, but if there is a better/preferred way to change ffplay to support subtitles in the filter chain without waiting for the whole subtitles-in-libavfilter infrastructure, I may be interested in working toward that. Regards, Marton___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSOC-2015] Call for mentors for GSOC 2015
Hi folks, we decided to participate in GSOC 2015 also this year, and we setup a page on the wiki: http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015 Check also: http://www.google-melange.com/gsoc/events/google/gsoc2015 Michael, Reynaldo, and me will act as administrators for the program. Application review will happen between 23 and 27 of February, so we should get the application and the wiki page in shape for that time. The wiki page is based on the corresponding OPW 2014 page. If you want to add a project, please do so as soon as possible, ask on this list or contact Michael, Reynaldo or me privately if you have any question or request. If you are listed as a mentor but you don't plan to mentor for GSOC 2015, please remove your project entry or your name. Thanks for your time. -- FFmpeg = Furious Fundamental Mastodontic Plastic Enhancing Gem ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/hevcdsp: optimize pixel comparison in sao_edge_filter
On 16/02/15 6:46 PM, Clément Bœsch wrote: > On Mon, Feb 16, 2015 at 09:48:25PM +0100, James Almer wrote: >> ffmpeg | branch: master | James Almer | Mon Feb 16 >> 16:53:31 2015 -0300| [22596383f3b8c7cd8a06570957face3875a73d3b] | committer: >> James Almer >> >> avcodec/hevcdsp: optimize pixel comparison in sao_edge_filter >> >> GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64 >> >> Before >> 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips >> >> After >> 672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips >> >> Reviewed-by: Michael Niedermayer >> Signed-off-by: James Almer >> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=22596383f3b8c7cd8a06570957face3875a73d3b >> --- >> >> libavcodec/hevcdsp_template.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c >> index 9ce7bf2..aeb142c 100644 >> --- a/libavcodec/hevcdsp_template.c >> +++ b/libavcodec/hevcdsp_template.c >> @@ -325,7 +325,7 @@ static void FUNC(sao_band_filter_0)(uint8_t *_dst, >> uint8_t *_src, >> } >> } >> >> -#define CMP(a, b) ((a) > (b) ? 1 : ((a) == (b) ? 0 : -1)) >> +#define CMP(a, b) ((a > b) - (a < b)) >> > > You probably want to keep a and b protected. Done, thanks for pointing it out. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/hevcdsp: optimize pixel comparison in sao_edge_filter
On Mon, Feb 16, 2015 at 09:48:25PM +0100, James Almer wrote: > ffmpeg | branch: master | James Almer | Mon Feb 16 > 16:53:31 2015 -0300| [22596383f3b8c7cd8a06570957face3875a73d3b] | committer: > James Almer > > avcodec/hevcdsp: optimize pixel comparison in sao_edge_filter > > GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64 > > Before > 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips > > After > 672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips > > Reviewed-by: Michael Niedermayer > Signed-off-by: James Almer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=22596383f3b8c7cd8a06570957face3875a73d3b > --- > > libavcodec/hevcdsp_template.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c > index 9ce7bf2..aeb142c 100644 > --- a/libavcodec/hevcdsp_template.c > +++ b/libavcodec/hevcdsp_template.c > @@ -325,7 +325,7 @@ static void FUNC(sao_band_filter_0)(uint8_t *_dst, > uint8_t *_src, > } > } > > -#define CMP(a, b) ((a) > (b) ? 1 : ((a) == (b) ? 0 : -1)) > +#define CMP(a, b) ((a > b) - (a < b)) > You probably want to keep a and b protected. -- Clément B. pgpivP280l6h_.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] ffmpeg: try to guess a good value for the thread message queue.
The current value, 8, is too low to be really useful.
The heuristic tries to allocate enough room for 10 seconds.
Signed-off-by: Nicolas George
---
ffmpeg.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
On my hardware, recording from v4l2 and ALSA produces ALSA underruns if the
message queue is below ~256-512.
diff --git a/ffmpeg.c b/ffmpeg.c
index a52de20..990ce9e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3412,9 +3412,29 @@ static void free_input_threads(void)
}
}
+static int eval_thread_queue_size(InputFile *f)
+{
+int i, s;
+int64_t sec = 10, fps = 0;
+
+for (i = 0; i < f->ctx->nb_streams; i++) {
+AVStream *st = f->ctx->streams[i];
+AVCodecContext *c = st->codec;
+if (c->sample_rate && c->frame_size) {
+fps += sec * (c->sample_rate / c->frame_size + 1);
+} else if (st->avg_frame_rate.num && st->avg_frame_rate.den) {
+fps += 1 + av_rescale(sec, st->avg_frame_rate.num,
st->avg_frame_rate.den);
+} else {
+fps += 25 * sec;
+}
+}
+s = FFMAX(3, FFMIN(20, av_log2(fps) + 1));
+return 1 << s;
+}
+
static int init_input_threads(void)
{
-int i, ret;
+int i, ret, qs;
if (nb_input_files == 1)
return 0;
@@ -3425,8 +3445,10 @@ static int init_input_threads(void)
if (f->ctx->pb ? !f->ctx->pb->seekable :
strcmp(f->ctx->iformat->name, "lavfi"))
f->non_blocking = 1;
+qs = eval_thread_queue_size(f);
+av_log(f->ctx, AV_LOG_VERBOSE, "Using input thread with queue size
%d\n", qs);
ret = av_thread_message_queue_alloc(&f->in_thread_queue,
-8, sizeof(AVPacket));
+qs, sizeof(AVPacket));
if (ret < 0)
return ret;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavd/alsa: set frame_size field.
The value tells the typical size of a packet from the demuxer.
Signed-off-by: Nicolas George
---
libavdevice/alsa-audio-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/alsa-audio-common.c b/libavdevice/alsa-audio-common.c
index bf876ed..f4b86bb 100644
--- a/libavdevice/alsa-audio-common.c
+++ b/libavdevice/alsa-audio-common.c
@@ -260,7 +260,7 @@ av_cold int ff_alsa_open(AVFormatContext *ctx,
snd_pcm_stream_t mode,
snd_strerror(res));
goto fail;
}
-s->period_size = period_size;
+ctx->streams[0]->codec->frame_size = s->period_size = period_size;
res = snd_pcm_hw_params(h, hw_params);
if (res < 0) {
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] ffmpeg: notify when the thread message queue blocks.
This can help finding the source of A-V desync with live input.
Signed-off-by: Nicolas George
---
ffmpeg.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index becd5df..a52de20 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3356,6 +3356,7 @@ static int check_keyboard_interaction(int64_t cur_time)
static void *input_thread(void *arg)
{
InputFile *f = arg;
+unsigned flags = f->non_blocking ? AV_THREAD_MESSAGE_NONBLOCK : 0;
int ret = 0;
while (1) {
@@ -3371,7 +3372,12 @@ static void *input_thread(void *arg)
break;
}
av_dup_packet(&pkt);
-ret = av_thread_message_queue_send(f->in_thread_queue, &pkt, 0);
+ret = av_thread_message_queue_send(f->in_thread_queue, &pkt, flags);
+if (flags && ret == AVERROR(EAGAIN)) {
+flags = 0;
+ret = av_thread_message_queue_send(f->in_thread_queue, &pkt,
flags);
+av_log(f->ctx, AV_LOG_WARNING, "Thread message queue blocking\n");
+}
if (ret < 0) {
if (ret != AVERROR_EOF)
av_log(f->ctx, AV_LOG_ERROR,
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] x86: hevc_mc: save 1 gpr in epel filter loading
On Mon, Feb 16, 2015 at 08:19:01PM +0100, Christophe Gisquet wrote: > 2015-02-16 10:43 GMT+01:00 Christophe Gisquet : > > Obviously I shouldn't unconditionally use r3srcq or equivalent, as > > !PIC just directly access the %%table > > I probably need to define an intermediate, say TABLE, which is either > > r3srcq or %%table, and use it for loading the xmm regs. > > The new attached patch might work, but that's a shot in the dark. seems working applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avodec/hevcdsp: optimize pixel comparison in sao_edge_filter
On 16/02/15 5:45 PM, Michael Niedermayer wrote: > On Mon, Feb 16, 2015 at 05:06:20PM -0300, James Almer wrote: >> GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64 >> >> Before >> 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips >> >> After >> 672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips >> >> Signed-off-by: James Almer >> --- >> Not like the C versions of these functions matter to a CPU like the above, >> but >> this could very well mean a couple extra fps for pre-SSSE3 CPUs with 8bit >> hevc >> content. >> >> Thanks to Zhaoxiu Zeng for inspiring this :P >> >> libavcodec/hevcdsp_template.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c >> index 9ce7bf2..aeb142c 100644 >> --- a/libavcodec/hevcdsp_template.c >> +++ b/libavcodec/hevcdsp_template.c >> @@ -325,7 +325,7 @@ static void FUNC(sao_band_filter_0)(uint8_t *_dst, >> uint8_t *_src, >> } >> } >> >> -#define CMP(a, b) ((a) > (b) ? 1 : ((a) == (b) ? 0 : -1)) >> +#define CMP(a, b) ((a > b) - (a < b)) > > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avodec/hevcdsp: optimize pixel comparison in sao_edge_filter
On Mon, Feb 16, 2015 at 05:06:20PM -0300, James Almer wrote: > GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64 > > Before > 715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips > > After > 672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips > > Signed-off-by: James Almer > --- > Not like the C versions of these functions matter to a CPU like the above, > but > this could very well mean a couple extra fps for pre-SSSE3 CPUs with 8bit > hevc > content. > > Thanks to Zhaoxiu Zeng for inspiring this :P > > libavcodec/hevcdsp_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c > index 9ce7bf2..aeb142c 100644 > --- a/libavcodec/hevcdsp_template.c > +++ b/libavcodec/hevcdsp_template.c > @@ -325,7 +325,7 @@ static void FUNC(sao_band_filter_0)(uint8_t *_dst, > uint8_t *_src, > } > } > > -#define CMP(a, b) ((a) > (b) ? 1 : ((a) == (b) ? 0 : -1)) > +#define CMP(a, b) ((a > b) - (a < b)) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] MPEG-4 audio-video file generation API
Dear ffmpeg coderz, I work for Laoviland Experience, a digital innovation start-up based in Montpellier, France. We develop creative software for inspiration and automation of graphical creations.(see our website www.laoviland.com for additional info). We are searching for specific technical skills for our tool that generates movies from visual routes on digital paintings. What we need is to integrate inside our soft an API that would be able to create and write a movie file in standard MP4 format (MPEG-4 Part 14) with a video track (AVC) and an audio track (AAC). The input of that solution would be the video frames, the sound samples and some movie parameters (bit rate, resolution, and so on). The output would be the MP4 video file. Presently, we can make a video (using the CImg library) but without any sound muxed, unless we use an external tool (like ffmpeg), but that's not what we want. We want to integrate each and every step of the creation right in our soft, getting only one standalone executable, statically compiled under Linux, Windows and MacOS (we use the Qt 5 framework). In our researchs on the existing solutions, we found the ffmpeg library and this mailing list. Several libraries exist to fit our needs, but none is thoroughly documented, and as we need that feature in a short term and our manpower is limited, I launch this call to anyone who could match the interests and skills to achieve such a mission. Feel free to contact me back (me or my director, Jean-Thierry TCHOUMOU, in copy of that mail), for any additional information. Best regards, __ Boris JAULMES Junior software developer Laoviland Experience ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc
Hi Michael, Here is a totally shot in a dark fix attempt for NEON register clobbering for deblocking. Could you test it with qemu and check if it works. -Seppo From: Michael Niedermayer [mich...@niedermayer.cc] Sent: Monday, February 16, 2015 3:28 AM To: Tomperi Seppo Cc: Michael Niedermayer; FFmpeg development discussions and patches; Mickaël Raulet Subject: Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc Hi On Sun, Feb 15, 2015 at 08:31:32PM +, Tomperi Seppo wrote: > Hi! > > The reason is chroma deblocking which is using q4 without pushing it to > stack. :/ > Unfortunately I am in Geneve this week and don't have ARM linux board with me > so it is not easy to test. > > Mickael Raulet: maybe guys at INSA could run tests this week if I make a fix? > Could you ask? If they cant, then i probably can test it too if its a patch which applies cleanly to ffmpeg and testing fate-hevc with --enable-neon-clobber-test under qemu is what is needed i could test on a arm board too if needed > > I also have SAO, qpel and epel NEON patches for latest FFmpeg. They pass > fate-hevc on Jetson TK1, but should be iOS and clobber checked. > > -Seppo > > > > From: Michael Niedermayer [michae...@gmx.at] > Sent: Friday, February 13, 2015 5:38 PM > To: FFmpeg development discussions and patches > Cc: Tomperi Seppo; Mickaël Raulet > Subject: Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc > > On Thu, Feb 05, 2015 at 02:22:28PM +0100, Mickaël Raulet wrote: > > Michael, > > > > Please find some commits that can be cherry picked from > > https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch > > > > > Optimized deblocking filter (8bits only) > > 1b9ee47d2f43b0a029a9468233626102eb1473b8 > > this breaks the neon clobber test see: > fate.ffmpeg.org/report.cgi?time=20150211030204&slot=armv7l-panda-gcc4.6-cortexa8-clobber > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The worst form of inequality is to try to make unequal things equal. > -- Aristotle > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 0001-hevcdsp-HEVC-deblocking-ARM-NEON-register-clobber-fi.patch Description: 0001-hevcdsp-HEVC-deblocking-ARM-NEON-register-clobber-fi.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avodec/hevcdsp: optimize pixel comparison in sao_edge_filter
GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64
Before
715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
After
672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
Signed-off-by: James Almer
---
Not like the C versions of these functions matter to a CPU like the above, but
this could very well mean a couple extra fps for pre-SSSE3 CPUs with 8bit hevc
content.
Thanks to Zhaoxiu Zeng for inspiring this :P
libavcodec/hevcdsp_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 9ce7bf2..aeb142c 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -325,7 +325,7 @@ static void FUNC(sao_band_filter_0)(uint8_t *_dst, uint8_t
*_src,
}
}
-#define CMP(a, b) ((a) > (b) ? 1 : ((a) == (b) ? 0 : -1))
+#define CMP(a, b) ((a > b) - (a < b))
static void FUNC(sao_edge_filter)(uint8_t *_dst, uint8_t *_src, ptrdiff_t
stride_dst, int16_t *sao_offset_val,
int eo, int width, int height) {
--
2.3.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix msvc compilation with --disable-indev=vfwcap
On Tue, Feb 17, 2015 at 04:47:47AM +1100, Matt Oliver wrote: > On 16 February 2015 at 21:26, Michael Niedermayer wrote: > > > On Sun, Feb 08, 2015 at 08:57:52PM +0100, Carl Eugen Hoyos wrote: > > > Hi! > > > > > > Attached patch intends to fix compilation with msvc > > > when the vfwcap input device is disabled. > > > Tested by Bernhard Döbler > > > > > > Please comment, Carl Eugen > > > > probably ok but i am no msvc guy and the msvc people seem not to > > care to review this > > > > > Disabling vfwcap is not something i ever bothered to do. But adding > user32.lib is perfectly acceptable as its a standard windows library > anyway. I havnt fully tested it but it looks good to me. Thanks for reviewing! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: fix a null pointer dereference
On Mon, Feb 16, 2015 at 07:31:42PM +0100, wm4 wrote: > Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where > it tries to dereference the field. > > Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8 > --- > libavformat/hls.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: write package name metadata
On Mon, Feb 16, 2015 at 4:07 AM, wrote:
> On 2015-02-13 01:36, Mark Reid wrote:
>
>> /**
>> + * Convert an UTF-8 string to UTF-16BE and write it.
>> + * @return number of bytes written.
>> + */
>> +int avio_put_str16be(AVIOContext *s, const char *str);
>>
>
> You could maybe split this patch up by making the part that adds this
> function a separate patch. Not that I'm super concerned.
will do.
>
>
> +#define PUT_STR16(type, write) \
>> +int avio_put_str16 ##type(AVIOContext *s, const char *str)\
>> +{\
>> +const uint8_t *q = str;\
>> +int ret = 0;\
>> +int err = 0;\
>> +while (*q) {\
>> +uint32_t ch;\
>> +uint16_t tmp;\
>> +GET_UTF8(ch, *q++, goto invalid;)\
>> +PUT_UTF16(ch, tmp, write(s, tmp); ret += 2;)\
>> +continue;\
>> +invalid:\
>> +av_log(s, AV_LOG_ERROR, "Invaid UTF8 sequence in
>> avio_put_str16" #type "\n");\
>> +err = AVERROR(EINVAL);\
>> +}\
>> +write(s, 0);\
>>
>
> From the last e-mail:
>
> The tests need to be updated because avio_put_str16be writes zero
>> terminated strings and
>> the muxer previously wasn't.
>>
>
> I was going to object to this on the grounds that it wastes a whopping two
> bytes per UTF-16 local tag, but I suspect the possible savings are eaten up
> by KAG alignment anyway. Code simplicity is favorable in this case I think
> :)
>
> I wasn't to thrilled about the 2 bytes either, but seeing that the
function is part of the public api, I didn't want to break anything.
>
> +if (err)\
>> +return err;\
>> +ret += 2;\
>> +return ret;\
>> +}\
>> +
>> +PUT_STR16(le, avio_wl16)
>> +PUT_STR16(be, avio_wb16)
>> +
>> +#undef PUT_STR16
>>
>> int ff_get_v_length(uint64_t val)
>> {
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index 17ad132..c25f5fd 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -624,14 +624,44 @@ static void mxf_write_preface(AVFormatContext *s)
>> }
>>
>> /*
>> - * Write a local tag containing an ascii string as utf-16
>> + * Returns the length of the UTF-16 string, in 16-bit characters,
>> that would result
>> + * from decoding the utf-8 string.
>> + */
>> +static uint64_t mxf_utf16len(const char *utf8_str)
>> +{
>> +const uint8_t *q = utf8_str;
>> +uint64_t size = 0;
>> +while (*q) {
>> +uint32_t ch;
>> +GET_UTF8(ch, *q++, goto invalid;)
>> +if (ch < 0x1)
>> +size++;
>> +else
>> +size += 2;
>> +continue;
>> +invalid:
>> +av_log(NULL, AV_LOG_ERROR, "Invaid UTF8 sequence in
>> mxf_utf16len\n\n");
>> +}
>> +size += 1;
>> +return size;
>> +}
>>
>
> Maybe this could be useful elsewhere too? What's the state of UTF-16 usage
> in lavf?
I couldn't find too much stuff writing utf-16 strings, id3v2, mmst and
subtiles. I think most of them calculate the length after writing.
would utils/avstring.c be good place to put it?
>
> +/*
>> + * Write a local tag containing an utf-8 string as utf-16
>> */
>> static void mxf_write_local_tag_utf16(AVIOContext *pb, int tag, const
>> char *value)
>> {
>> -int i, size = strlen(value);
>> +int size = mxf_utf16len(value);
>> mxf_write_local_tag(pb, size*2, tag);
>> -for (i = 0; i < size; i++)
>> -avio_wb16(pb, value[i]);
>> +avio_put_str16be(pb, value);
>> }
>>
>
> Wow, this thing was really broken before.
>
> Overall the patch looks fine, apart from maybe splitting it up.
>
Okay, I'll split it into two patches and send a new set, thanks for taking
the time to review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] x86: hevc_mc: save 1 gpr in epel filter loading
2015-02-16 10:43 GMT+01:00 Christophe Gisquet : > Obviously I shouldn't unconditionally use r3srcq or equivalent, as > !PIC just directly access the %%table > I probably need to define an intermediate, say TABLE, which is either > r3srcq or %%table, and use it for loading the xmm regs. The new attached patch might work, but that's a shot in the dark. I'll sent the following ones if this one is fine. -- Christophe From 96a5a2e6ceab9350468ea2697c2cf05d5b88cac6 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Sat, 7 Feb 2015 18:49:38 + Subject: [PATCH 1/3] x86: hevc_mc: save 1 gpr in epel filter loading The 3*stride value stored in r3src can be loaded much later, so use r3src instead of a dedicated gpr when possible. --- libavcodec/x86/hevc_mc.asm | 71 +++--- 1 file changed, 35 insertions(+), 36 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index 9a7367a..6ef8a60 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -136,20 +136,22 @@ QPEL_TABLE 10, 8, w, avx2 %endmacro -%macro EPEL_FILTER 2-4; bit depth, filter index +%macro EPEL_FILTER 5 ; bit depth, filter index, xmma, xmmb, gprtmp %if cpuflag(avx2) %assign %%offset 32 %ifdef PIC -lea rfilterq, [hevc_epel_filters_avx2_%1] +lea %5q, [hevc_epel_filters_avx2_%1] +%define FILTER %5q %else -%define rfilterq hevc_epel_filters_avx2_%1 +%define FILTER hevc_epel_filters_avx2_%1 %endif %else %assign %%offset 16 %ifdef PIC -lea rfilterq, [hevc_epel_filters_sse4_%1] +lea %5q, [hevc_epel_filters_sse4_%1] +%define FILTER %5q %else -%define rfilterq hevc_epel_filters_sse4_%1 +%define FILTER hevc_epel_filters_sse4_%1 %endif %endif ;cpuflag(avx2) sub %2q, 1 @@ -158,13 +160,8 @@ QPEL_TABLE 10, 8, w, avx2 %else shl %2q, 5 ; multiply by 32 %endif -%if %0 == 2 -mova m14, [rfilterq + %2q]; get 2 first values of filters -mova m15, [rfilterq + %2q+%%offset] ; get 2 last values of filters -%else -mova %3, [rfilterq + %2q]; get 2 first values of filters -mova %4, [rfilterq + %2q+%%offset] ; get 2 last values of filters -%endif +mova %3, [FILTER + %2q]; get 2 first values of filters +mova %4, [FILTER + %2q+%%offset] ; get 2 last values of filters %endmacro %macro EPEL_HV_FILTER 1 @@ -179,17 +176,17 @@ QPEL_TABLE 10, 8, w, avx2 %endif %ifdef PIC -lea rfilterq, [%%table] +lea r3srcq, [%%table] +%define FILTER r3srcq %else -%define rfilterq %%table +%define FILTER %%table %endif sub mxq, 1 sub myq, 1 shl mxq, %%shift; multiply by 32 shl myq, %%shift; multiply by 32 -mova m14, [rfilterq + mxq]; get 2 first values of filters -mova m15, [rfilterq + mxq+%%offset] ; get 2 last values of filters -lea r3srcq, [srcstrideq*3] +mova m14, [FILTER + mxq]; get 2 first values of filters +mova m15, [FILTER + mxq+%%offset] ; get 2 last values of filters %if cpuflag(avx2) %define %%table hevc_epel_filters_avx2_10 @@ -197,12 +194,14 @@ QPEL_TABLE 10, 8, w, avx2 %define %%table hevc_epel_filters_sse4_10 %endif %ifdef PIC -lea rfilterq, [%%table] +lea r3srcq, [%%table] +%define FILTER r3srcq %else -%define rfilterq %%table +%define FILTER %%table %endif -mova m12, [rfilterq + myq]; get 2 first values of filters -mova m13, [rfilterq + myq+%%offset] ; get 2 last values of filters +mova m12, [FILTER + myq]; get 2 first values of filters +mova m13, [FILTER + myq+%%offset] ; get 2 last values of filters +lea r3srcq, [srcstrideq*3] %endmacro %macro QPEL_FILTER 2 @@ -733,7 +732,7 @@ cglobal hevc_put_hevc_bi_pel_pixels%1_%2, 6, 6, 6, dst, dststride, src, srcstrid %macro HEVC_PUT_HEVC_EPEL 2 cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) -EPEL_FILTER %2, mx, m4, m5 +EPEL_FILTER %2, mx, m4, m5, rfilter .loop EPEL_LOAD %2, srcq-%%stride, %%stride, %1 EPEL_COMPUTE %2, %1, m4, m5, 1 @@ -744,7 +743,7 @@ cglobal hevc_put_hevc_epel_h%1_%2, 5, 6, 11, dst, src, srcstride, height, mx, rf cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 11, dst, dststride, src, srcstride, height, mx, rfilter %assign %%stride ((%2 + 7)/8) movdqam6, [pw_%2] -EPEL_FILTER %2, mx, m4, m5 +EPEL_FILTER %2, mx, m4, m5, rfilter .loop EPEL_LOAD %2, srcq-%%stride, %%stride
Re: [FFmpeg-devel] Add configure option --disable-warnings
I though an extra configure option would have been the most logical way of removing warnings but you are probably right: I will use --extra-cflags instead. Thanks for the feedback. On Sat, Feb 14, 2015 at 9:55 AM, Reimar Döffinger wrote: On 12.02.2015, at 19:56, Gautier Pelloux-Prayer wrote: Hi list, I added an option to disable compiler warnings while building ffmpeg. Reason is that when integrating ffmpeg within another project, I would like to disable these warnings since I cannot fix them myself and having them displayed while building the main project is worthless and noisy. Besides this probably only working with gcc, I kind of think this is nothing we want to encourage by having an extra option. Using --extra-cflags (if I remember right) should be easy enough to use for this, or do I miss something? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] doc/faq: explain DAR/SAR preserving.
L'octidi 28 pluviôse, an CCXXIII, Clement Boesch a écrit :
> A lot of users will want to know how to avoid the transcode.
True. New patch attached.
Regards,
--
Nicolas George
From db3ed4560061be5cbfad5547ef7a2d9af7ccb874 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Mon, 9 Feb 2015 16:17:22 +0100
Subject: [PATCH] doc/faq: explain DAR/SAR preserving.
Signed-off-by: Nicolas George
---
doc/faq.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/doc/faq.texi b/doc/faq.texi
index 494da86..c3db720 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -467,6 +467,40 @@ point acceptable for your tastes. The most common options to do that are
@option{-qscale} and @option{-qmax}, but you should peruse the documentation
of the encoder you chose.
+@section I have a stretched video, why does scaling does not fix it?
+
+A lot of video codecs and formats can store the @emph{aspect ratio} of the
+video: this is the ratio between the width and the height of either the full
+image (DAR, display aspect ratio) or individual pixels (SAR, sample aspect
+ratio). For example, EGA screens at resolution 640×350 had 4:3 DAR and 35:48
+SAR.
+
+Most still image processing work with square pixels, i.e. 1:1 SAR, but a lot
+of video standards, especially from the analogic-numeric transition era, use
+non-square pixels.
+
+Most processing filters in FFmpeg handle the aspect ratio to avoid
+stretching the image: cropping adjusts the DAR to keep the SAR constant,
+scaling adjusts the SAR to keep the DAR constant.
+
+If you want to stretch, or “unstretch”, the image, you need to override the
+information with the
+@url{http://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar, @code{setdar or setsar filters}}.
+
+Do not forget to examine carefully the original video to check whether the
+stretching comes from the image or from the aspect ratio information.
+
+For example, to fix a badly encoded EGA capture, use the following commands,
+either the first one to upscale to square pixels or the second one to set
+the correct aspect ratio or the third one to avoid transcoding (may not work
+depending on the format / codec / player / phase of the moon):
+
+@example
+ffmpeg -i ega_screen.nut -vf scale=640:480,setsar=1 ega_screen_scaled.nut
+ffmpeg -i ega_screen.nut -vf setdar=4/3 ega_screen_anamorphic.nut
+ffmpeg -i ega_screen.nut -aspect 4/3 -c copy ega_screen_overridden.nut
+@end example
+
@chapter Development
@section Are there examples illustrating how to use the FFmpeg libraries, particularly libavcodec and libavformat?
--
2.1.4
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] doc/faq: explain DAR/SAR preserving.
On Mon, Feb 16, 2015 at 07:34:52PM +0100, Nicolas George wrote:
> Le primidi 21 pluviôse, an CCXXIII, Kieran Kunhya a écrit :
> > The DAR for analogue compatible media (e.g. SD DVB) comes from the
> > active samples and not from the "full image".
>
> The exact meaning of DAR in this context is entirely for us to decide. And
> that means collectively, not you alone. And a simple unrelated FAQ entry is
> not the place to discuss it anyway.
>
> New patch attached with an example, and the CGA changed to EGA.
>
> Regards,
>
> --
> Nicolas George
> From 2b238e7df5bd1c00a0c3c6c8b4070f4b6b0fa744 Mon Sep 17 00:00:00 2001
> From: Nicolas George
> Date: Mon, 9 Feb 2015 16:17:22 +0100
> Subject: [PATCH] doc/faq: explain DAR/SAR preserving.
>
> Signed-off-by: Nicolas George
> ---
> doc/faq.texi | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 494da86..c15fcf5 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@ -467,6 +467,38 @@ point acceptable for your tastes. The most common
> options to do that are
> @option{-qscale} and @option{-qmax}, but you should peruse the documentation
> of the encoder you chose.
>
> +@section I have a stretched video, why does scaling does not fix it?
> +
> +A lot of video codecs and formats can store the @emph{aspect ratio} of the
> +video: this is the ratio between the width and the height of either the full
> +image (DAR, display aspect ratio) or individual pixels (SAR, sample aspect
> +ratio). For example, EGA screens at resolution 640×350 had 4:3 DAR and 35:48
> +SAR.
> +
> +Most still image processing work with square pixels, i.e. 1:1 SAR, but a lot
> +of video standards, especially from the analogic-numeric transition era, use
> +non-square pixels.
> +
> +Most processing filters in FFmpeg handle the aspect ratio to avoid
> +stretching the image: cropping adjusts the DAR to keep the SAR constant,
> +scaling adjusts the SAR to keep the DAR constant.
> +
> +If you want to stretch, or “unstretch”, the image, you need to override the
> +information with the
> +@url{http://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar, @code{setdar
> or setsar filters}}.
> +
> +Do not forget to examine carefully the original video to check whether the
> +stretching comes from the image or from the aspect ratio information.
> +
> +For example, to fix a badly encoded EGA capture, use the following commands,
> +either the first one to upscale to square pixels or the second one to set
> +the correct aspect ratio:
> +
> +@example
> +ffmpeg -i ega_screen.nut -vf scale=640:480,setsar=1 ega_screen_scaled.nut
> +ffmpeg -i ega_screen.nut -vf setdar=4/3 ega_screen_anamorphic.nut
> +@end example
> +
A lot of users will want to know how to avoid the transcode.
--
Clément B.
pgp7H4nOcsh8J.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/vc1_mc: create some helper functions for scaling blocks
On Tue, Feb 17, 2015 at 12:38:53AM +0800, zhaoxiu.zeng wrote: > 在 2015/2/14 23:48, Hendrik Leppkes 写道: > > On Sat, Feb 14, 2015 at 4:11 PM, zhaoxiu.zeng > > wrote: > >> From a67cc93ea550ba2670003f5be024626a093a06fd Mon Sep 17 00:00:00 2001 > >> From: Zeng Zhaoxiu > >> Date: Sat, 14 Feb 2015 21:09:28 +0800 > >> Subject: [PATCH 4/5] avcodec/vc1_mc: create some helper functions for > >> scaling > >> blocks > >> > > > > Shouldn't those functions get an inline tag, or even force-inline? > > > > - Hendrik > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > Should be inlined. > > --- > libavcodec/vc1_mc.c | 257 > +++- > 1 file changed, 113 insertions(+), 144 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] doc/faq: explain DAR/SAR preserving.
Le primidi 21 pluviôse, an CCXXIII, Kieran Kunhya a écrit :
> The DAR for analogue compatible media (e.g. SD DVB) comes from the
> active samples and not from the "full image".
The exact meaning of DAR in this context is entirely for us to decide. And
that means collectively, not you alone. And a simple unrelated FAQ entry is
not the place to discuss it anyway.
New patch attached with an example, and the CGA changed to EGA.
Regards,
--
Nicolas George
From 2b238e7df5bd1c00a0c3c6c8b4070f4b6b0fa744 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Mon, 9 Feb 2015 16:17:22 +0100
Subject: [PATCH] doc/faq: explain DAR/SAR preserving.
Signed-off-by: Nicolas George
---
doc/faq.texi | 32
1 file changed, 32 insertions(+)
diff --git a/doc/faq.texi b/doc/faq.texi
index 494da86..c15fcf5 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -467,6 +467,38 @@ point acceptable for your tastes. The most common options to do that are
@option{-qscale} and @option{-qmax}, but you should peruse the documentation
of the encoder you chose.
+@section I have a stretched video, why does scaling does not fix it?
+
+A lot of video codecs and formats can store the @emph{aspect ratio} of the
+video: this is the ratio between the width and the height of either the full
+image (DAR, display aspect ratio) or individual pixels (SAR, sample aspect
+ratio). For example, EGA screens at resolution 640×350 had 4:3 DAR and 35:48
+SAR.
+
+Most still image processing work with square pixels, i.e. 1:1 SAR, but a lot
+of video standards, especially from the analogic-numeric transition era, use
+non-square pixels.
+
+Most processing filters in FFmpeg handle the aspect ratio to avoid
+stretching the image: cropping adjusts the DAR to keep the SAR constant,
+scaling adjusts the SAR to keep the DAR constant.
+
+If you want to stretch, or “unstretch”, the image, you need to override the
+information with the
+@url{http://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar, @code{setdar or setsar filters}}.
+
+Do not forget to examine carefully the original video to check whether the
+stretching comes from the image or from the aspect ratio information.
+
+For example, to fix a badly encoded EGA capture, use the following commands,
+either the first one to upscale to square pixels or the second one to set
+the correct aspect ratio:
+
+@example
+ffmpeg -i ega_screen.nut -vf scale=640:480,setsar=1 ega_screen_scaled.nut
+ffmpeg -i ega_screen.nut -vf setdar=4/3 ega_screen_anamorphic.nut
+@end example
+
@chapter Development
@section Are there examples illustrating how to use the FFmpeg libraries, particularly libavcodec and libavformat?
--
2.1.4
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hls: fix a null pointer dereference
Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where
it tries to dereference the field.
Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8
---
libavformat/hls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f17b826..4fdda34 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1313,14 +1313,14 @@ static int hls_read_header(AVFormatContext *s)
struct playlist *pls = c->playlists[i];
AVInputFormat *in_fmt = NULL;
-if (pls->n_segments == 0)
-continue;
-
if (!(pls->ctx = avformat_alloc_context())) {
ret = AVERROR(ENOMEM);
goto fail;
}
+if (pls->n_segments == 0)
+continue;
+
pls->index = i;
pls->needed = 1;
pls->parent = s;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc
On Mon, Feb 16, 2015 at 12:47:36PM +, Tomperi Seppo wrote:
> More NEON optimizations for testing. fate-hevc passes on Tegra K1, but these
> haven't been tested for NEON clobbering.
>
> -Seppo
>
>
> From: Tomperi Seppo
> Sent: Monday, February 16, 2015 1:30 PM
> To: Michael Niedermayer
> Cc: Michael Niedermayer; FFmpeg development discussions and patches; Mickaël
> Raulet
> Subject: RE: [FFmpeg-devel] DSP function ARM NEON patches for hevc
>
> Hi Michael,
>
> Here is a totally shot in a dark fix attempt for NEON register clobbering for
> deblocking. Could you test it with qemu and check if it works.
>
>
> -Seppo
>
>
> From: Michael Niedermayer [mich...@niedermayer.cc]
> Sent: Monday, February 16, 2015 3:28 AM
> To: Tomperi Seppo
> Cc: Michael Niedermayer; FFmpeg development discussions and patches; Mickaël
> Raulet
> Subject: Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc
>
> Hi
>
> On Sun, Feb 15, 2015 at 08:31:32PM +, Tomperi Seppo wrote:
> > Hi!
> >
> > The reason is chroma deblocking which is using q4 without pushing it to
> > stack. :/
> > Unfortunately I am in Geneve this week and don't have ARM linux board with
> > me so it is not easy to test.
> >
> > Mickael Raulet: maybe guys at INSA could run tests this week if I make a
> > fix? Could you ask?
>
> If they cant, then i probably can test it too if its a patch which
> applies cleanly to ffmpeg and testing fate-hevc with
> --enable-neon-clobber-test under qemu is what is needed
> i could test on a arm board too if needed
>
>
> >
> > I also have SAO, qpel and epel NEON patches for latest FFmpeg. They pass
> > fate-hevc on Jetson TK1, but should be iOS and clobber checked.
> >
> > -Seppo
> >
> >
> >
> > From: Michael Niedermayer [michae...@gmx.at]
> > Sent: Friday, February 13, 2015 5:38 PM
> > To: FFmpeg development discussions and patches
> > Cc: Tomperi Seppo; Mickaël Raulet
> > Subject: Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc
> >
> > On Thu, Feb 05, 2015 at 02:22:28PM +0100, Mickaël Raulet wrote:
> > > Michael,
> > >
> > > Please find some commits that can be cherry picked from
> > > https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch
> > >
> >
> > > Optimized deblocking filter (8bits only)
> > > 1b9ee47d2f43b0a029a9468233626102eb1473b8
> >
> > this breaks the neon clobber test see:
> > fate.ffmpeg.org/report.cgi?time=20150211030204&slot=armv7l-panda-gcc4.6-cortexa8-clobber
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > The worst form of inequality is to try to make unequal things equal.
> > -- Aristotle
> >
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus
> Makefile|3
> hevcdsp_init_neon.c | 159
> hevcdsp_qpel_neon.S | 999
>
> 3 files changed, 1160 insertions(+), 1 deletion(-)
> 9fb0b3c33edf085845b7a0fba3ca77d1ba55dd6c
> 0001-hevcdsp-ARM-NEON-optimized-qpel-functions.patch
> From ce06cb2bea4b051995608b11651b185e7a825a4c Mon Sep 17 00:00:00 2001
> From: Seppo Tomperi
> Date: Wed, 11 Feb 2015 10:20:26 +
> Subject: [PATCH] hevcdsp: ARM NEON optimized qpel functions
>
> ---
> libavcodec/arm/Makefile| 3 +-
> libavcodec/arm/hevcdsp_init_neon.c | 159 ++
> libavcodec/arm/hevcdsp_qpel_neon.S | 999
> +
> 3 files changed, 1160 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/arm/hevcdsp_qpel_neon.S
seems to fail building:
libavformat/utils.o
CC libavcodec/arm/hevcdsp_init_neon.o
AS libavcodec/arm/hevcdsp_qpel_neon.o
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S: Assembler messages:
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: expected } -- `vld1.32
{d0[0]d0[1]d1[0]d1[1]},[r2],r3'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vld1.32 {},[r2],r3'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vld1.32 {},[r2],r3'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vld1.32 {},[r2],r3'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: expected } -- `vst1.32
{d0[0]d0[1]d1[0]d1[1]},[r0],r1'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vst1.32 {},[r0],r1'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vst1.32 {},[r0],r1'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:992: Error: Neon double or quad
precision register expected -- `vst1.32 {},[r0],r1'
ffmpeg/libavcodec/arm/hevcdsp_qpel_neon.S:994: Error: expected } -- `vld1.
Re: [FFmpeg-devel] [PATCH]Fix msvc compilation with --disable-indev=vfwcap
On 16 February 2015 at 21:26, Michael Niedermayer wrote: > On Sun, Feb 08, 2015 at 08:57:52PM +0100, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch intends to fix compilation with msvc > > when the vfwcap input device is disabled. > > Tested by Bernhard Döbler > > > > Please comment, Carl Eugen > > probably ok but i am no msvc guy and the msvc people seem not to > care to review this > > Disabling vfwcap is not something i ever bothered to do. But adding user32.lib is perfectly acceptable as its a standard windows library anyway. I havnt fully tested it but it looks good to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/rtpdec_mpeg4: reassemble fragmented AAC frames
On Fri, Feb 13, 2015 at 10:51:32PM +0100, Gilles Chanteperdrix wrote: > Signed-off-by: Gilles Chanteperdrix > --- > libavformat/rtpdec_mpeg4.c | 84 > +- > 1 file changed, 76 insertions(+), 8 deletions(-) Hi, what about this patch? Regards. -- Gilles. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compile failure with -DDEBUG of HEAD
On Mon, Feb 16, 2015 at 05:05:28PM +, Kevin Wheatley wrote: > This time with patch... > > On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley > wrote: > > Whilst compiling with -DDEBUG I get the following... > > > > libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a': > > libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in > > this function) > > libavformat/rtpdec_h264.c:208: error: (Each undeclared identifier is > > reported only once > > libavformat/rtpdec_h264.c:208: error: for each function it appears in.) > > libavformat/rtpdec_h264.c: In function 'h264_handle_packet_fu_a': > > libavformat/rtpdec_h264.c:259: error: 'data' undeclared (first use in > > this function) > > > > Looks like passing in the needed context to from the calling functions > > would work, > > > > Kevin > rtpdec_h264.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > 408acfcf641594fb964ee06cdd8b54853f52d29e rtpdec_h264_compile_failt.patch > diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c > index 89053ef..24b701c 100644 applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] compile failure with -DDEBUG of HEAD
This time with patch...
On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley
wrote:
> Whilst compiling with -DDEBUG I get the following...
>
> libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a':
> libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in
> this function)
> libavformat/rtpdec_h264.c:208: error: (Each undeclared identifier is
> reported only once
> libavformat/rtpdec_h264.c:208: error: for each function it appears in.)
> libavformat/rtpdec_h264.c: In function 'h264_handle_packet_fu_a':
> libavformat/rtpdec_h264.c:259: error: 'data' undeclared (first use in
> this function)
>
> Looks like passing in the needed context to from the calling functions
> would work,
>
> Kevin
diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index 89053ef..24b701c 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -177,7 +177,7 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext *s,
return 0;
}
-static int h264_handle_packet_stap_a(AVFormatContext *ctx, AVPacket *pkt,
+static int h264_handle_packet_stap_a(AVFormatContext *ctx, PayloadContext *data, AVPacket *pkt,
const uint8_t *buf, int len)
{
int pass = 0;
@@ -234,7 +234,7 @@ static int h264_handle_packet_stap_a(AVFormatContext *ctx, AVPacket *pkt,
return 0;
}
-static int h264_handle_packet_fu_a(AVFormatContext *ctx, AVPacket *pkt,
+static int h264_handle_packet_fu_a(AVFormatContext *ctx, PayloadContext *data, AVPacket *pkt,
const uint8_t *buf, int len)
{
uint8_t fu_indicator, fu_header, start_bit, nal_type, nal;
@@ -308,7 +308,7 @@ static int h264_handle_packet(AVFormatContext *ctx, PayloadContext *data,
buf++;
len--;
// first we are going to figure out the total size
-result = h264_handle_packet_stap_a(ctx, pkt, buf, len);
+result = h264_handle_packet_stap_a(ctx, data, pkt, buf, len);
break;
case 25: // STAP-B
@@ -322,7 +322,7 @@ static int h264_handle_packet(AVFormatContext *ctx, PayloadContext *data,
break;
case 28: // FU-A (fragmented nal)
-result = h264_handle_packet_fu_a(ctx, pkt, buf, len);
+result = h264_handle_packet_fu_a(ctx, data, pkt, buf, len);
break;
case 30: // undefined
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] compile failure with -DDEBUG of HEAD
Whilst compiling with -DDEBUG I get the following... libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a': libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in this function) libavformat/rtpdec_h264.c:208: error: (Each undeclared identifier is reported only once libavformat/rtpdec_h264.c:208: error: for each function it appears in.) libavformat/rtpdec_h264.c: In function 'h264_handle_packet_fu_a': libavformat/rtpdec_h264.c:259: error: 'data' undeclared (first use in this function) Looks like passing in the needed context to from the calling functions would work, Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/vc1_pred: few branchless optimizations
在 2015/2/15 2:42, Christophe Gisquet 写道: > 2015-02-14 17:14 GMT+01:00 Michael Niedermayer : >> On Sat, Feb 14, 2015 at 11:03:13PM +0800, zhaoxiu.zeng wrote: >>> From 7e4038fe1291b857261584e69323486fc955cfb2 Mon Sep 17 00:00:00 2001 >>> From: Zeng Zhaoxiu >>> Date: Sat, 14 Feb 2015 20:08:48 +0800 >>> Subject: [PATCH 3/5] avcodec/vc1_pred: few branchless optimizations >> >> applied >> >> please include benchmark values in future optimization patches > > Yes, please, cf. START/STOP_TIMER macros. > OK. I will obey the rules! Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264: simplify h264_split()
在 2015/2/15 8:38, Michael Niedermayer 写道:
> On Fri, Feb 13, 2015 at 01:51:30PM +0800, Zhaoxiu Zeng wrote:
>> From 52be21b15e078fb52a841aefcf78409a408fe8b4 Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu
>> Date: Fri, 13 Feb 2015 13:37:46 +0800
>> Subject: [PATCH 2/2] avcodec/h264: simplify h264_split()
>>
>> Signed-off-by: Zeng Zhaoxiu
>> ---
>> libavcodec/h264_parser.c | 35 +++
>> 1 file changed, 19 insertions(+), 16 deletions(-)
>
> patch applied
>
> please make sure future patches you submit dont contain line wraps
> like this:
>
> [...]
>> + * nalu_type == 0x05) {
>> * }
>> */
>> -if ((state & 0xFF00) == 0x100 && ((state & 0xFF1F) !=
>> 0x106 || has_pps) &&
>
> [...]
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
OK. That happened when i copied text to web mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/vc1_mc: create some helper functions for scaling blocks
在 2015/2/14 23:48, Hendrik Leppkes 写道:
> On Sat, Feb 14, 2015 at 4:11 PM, zhaoxiu.zeng wrote:
>> From a67cc93ea550ba2670003f5be024626a093a06fd Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu
>> Date: Sat, 14 Feb 2015 21:09:28 +0800
>> Subject: [PATCH 4/5] avcodec/vc1_mc: create some helper functions for scaling
>> blocks
>>
>
> Shouldn't those functions get an inline tag, or even force-inline?
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Should be inlined.
---
libavcodec/vc1_mc.c | 257 +++-
1 file changed, 113 insertions(+), 144 deletions(-)
diff --git a/libavcodec/vc1_mc.c b/libavcodec/vc1_mc.c
index 64f8854..683b620
--- a/libavcodec/vc1_mc.c
+++ b/libavcodec/vc1_mc.c
@@ -32,6 +32,77 @@
#include "mpegvideo.h"
#include "vc1.h"
+static av_always_inline void vc1_scale_luma(uint8_t *srcY,
+int k, int linesize)
+{
+int i, j;
+for (j = 0; j < k; j++) {
+for (i = 0; i < k; i++)
+srcY[i] = ((srcY[i] - 128) >> 1) + 128;
+srcY += linesize;
+}
+}
+
+static av_always_inline void vc1_scale_chroma(uint8_t *srcU, uint8_t *srcV,
+ int k, int uvlinesize)
+{
+int i, j;
+for (j = 0; j < k; j++) {
+for (i = 0; i < k; i++) {
+srcU[i] = ((srcU[i] - 128) >> 1) + 128;
+srcV[i] = ((srcV[i] - 128) >> 1) + 128;
+}
+srcU += uvlinesize;
+srcV += uvlinesize;
+}
+}
+
+static av_always_inline void vc1_lut_scale_luma(uint8_t *srcY,
+uint8_t *lut1, uint8_t *lut2,
+int k, int linesize)
+{
+int i, j;
+
+for (j = 0; j < k; j += 2) {
+for (i = 0; i < k; i++)
+srcY[i] = lut1[srcY[i]];
+srcY += linesize;
+
+if (j + 1 == k)
+break;
+
+for (i = 0; i < k; i++)
+srcY[i] = lut2[srcY[i]];
+srcY += linesize;
+}
+}
+
+static av_always_inline void vc1_lut_scale_chroma(uint8_t *srcU, uint8_t *srcV,
+ uint8_t *lut1, uint8_t *lut2,
+ int k, int uvlinesize)
+{
+int i, j;
+
+for (j = 0; j < k; j += 2) {
+for (i = 0; i < k; i++) {
+srcU[i] = lut1[srcU[i]];
+srcV[i] = lut1[srcV[i]];
+}
+srcU += uvlinesize;
+srcV += uvlinesize;
+
+if (j + 1 == k)
+break;
+
+for (i = 0; i < k; i++) {
+srcU[i] = lut2[srcU[i]];
+srcV[i] = lut2[srcV[i]];
+}
+srcU += uvlinesize;
+srcV += uvlinesize;
+}
+}
+
/** Do motion compensation over 1 macroblock
* Mostly adapted hpel_motion and qpel_motion from mpegvideo.c
*/
@@ -147,11 +218,12 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
|| (unsigned)(src_y - 1)> v_edge_pos- (my&3) - 16 - 3) {
uint8_t *ubuf = s->edge_emu_buffer + 19 * s->linesize;
uint8_t *vbuf = ubuf + 9 * s->uvlinesize;
+const int k = 17 + s->mspel * 2;
srcY -= s->mspel * (1 + s->linesize);
s->vdsp.emulated_edge_mc(s->edge_emu_buffer, srcY,
s->linesize, s->linesize,
- 17 + s->mspel * 2, 17 + s->mspel * 2,
+ k, k,
src_x - s->mspel, src_y - s->mspel,
s->h_edge_pos, v_edge_pos);
srcY = s->edge_emu_buffer;
@@ -169,56 +241,26 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
srcV = vbuf;
/* if we deal with range reduction we need to scale source blocks */
if (v->rangeredfrm) {
-int i, j;
-uint8_t *src, *src2;
-
-src = srcY;
-for (j = 0; j < 17 + s->mspel * 2; j++) {
-for (i = 0; i < 17 + s->mspel * 2; i++)
-src[i] = ((src[i] - 128) >> 1) + 128;
-src += s->linesize;
-}
-src = srcU;
-src2 = srcV;
-for (j = 0; j < 9; j++) {
-for (i = 0; i < 9; i++) {
-src[i] = ((src[i] - 128) >> 1) + 128;
-src2[i] = ((src2[i] - 128) >> 1) + 128;
-}
-src += s->uvlinesize;
-src2 += s->uvlinesize;
-}
+vc1_scale_luma(srcY, k, s->linesize);
+vc1_scale_chroma(srcU, srcV, 9, s->uvlinesize);
}
/* if we deal with intensity compensation we need to scale source
blocks */
if (use_ic) {
-int i, j;
-uint8_t *src, *src2;
-
-src = srcY;
-for (j = 0; j < 17 + s->mspel * 2; j++) {
-
Re: [FFmpeg-devel] [PATCH] Set sse_deps to mmx, not mmxext.
On Mon, 16 Feb 2015 13:31:40 -0300 James Almer wrote: > On 16/02/15 1:22 PM, Alexis Ballier wrote: > > [50cd43f2c] changed that silently, while no modern cpu has mmxext: > > https://en.wikipedia.org/wiki/Extended_MMX > > In this case, mmxext refers to the integer instructions introduced > with SSE, and not this Cyrix set. > AMD cpus pre-Athlon XP featured the integer instructions but not the > float ones. The distinction was made so functions using only the > integer SSE instructions could be run on them. thanks for the clarification; please disregard the patch then ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Set sse_deps to mmx, not mmxext.
On 16/02/15 1:22 PM, Alexis Ballier wrote: > [50cd43f2c] changed that silently, while no modern cpu has mmxext: > https://en.wikipedia.org/wiki/Extended_MMX In this case, mmxext refers to the integer instructions introduced with SSE, and not this Cyrix set. AMD cpus pre-Athlon XP featured the integer instructions but not the float ones. The distinction was made so functions using only the integer SSE instructions could be run on them. > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 1d14d0a..ae73970 100755 > --- a/configure > +++ b/configure > @@ -2010,7 +2010,7 @@ amd3dnowext_deps="amd3dnow" > i686_deps="x86" > mmx_deps="x86" > mmxext_deps="mmx" > -sse_deps="mmxext" > +sse_deps="mmx" > sse2_deps="sse" > sse3_deps="sse2" > ssse3_deps="sse3" > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Set sse_deps to mmx, not mmxext.
[50cd43f2c] changed that silently, while no modern cpu has mmxext: https://en.wikipedia.org/wiki/Extended_MMX --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 1d14d0a..ae73970 100755 --- a/configure +++ b/configure @@ -2010,7 +2010,7 @@ amd3dnowext_deps="amd3dnow" i686_deps="x86" mmx_deps="x86" mmxext_deps="mmx" -sse_deps="mmxext" +sse_deps="mmx" sse2_deps="sse" sse3_deps="sse2" ssse3_deps="sse3" -- 2.3.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] DSP function ARM NEON patches for hevc
On Mon, Feb 16, 2015 at 11:30:26AM +, Tomperi Seppo wrote: > Hi Michael, > > Here is a totally shot in a dark fix attempt for NEON register clobbering for > deblocking. Could you test it with qemu and check if it works. seems working, will apply it to ffmpeg thanks! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: write package name metadata
On 2015-02-13 01:36, Mark Reid wrote:
/**
+ * Convert an UTF-8 string to UTF-16BE and write it.
+ * @return number of bytes written.
+ */
+int avio_put_str16be(AVIOContext *s, const char *str);
You could maybe split this patch up by making the part that adds this
function a separate patch. Not that I'm super concerned.
+#define PUT_STR16(type, write) \
+int avio_put_str16 ##type(AVIOContext *s, const char *str)\
+{\
+const uint8_t *q = str;\
+int ret = 0;\
+int err = 0;\
+while (*q) {\
+uint32_t ch;\
+uint16_t tmp;\
+GET_UTF8(ch, *q++, goto invalid;)\
+PUT_UTF16(ch, tmp, write(s, tmp); ret += 2;)\
+continue;\
+invalid:\
+av_log(s, AV_LOG_ERROR, "Invaid UTF8 sequence in
avio_put_str16" #type "\n");\
+err = AVERROR(EINVAL);\
+}\
+write(s, 0);\
From the last e-mail:
The tests need to be updated because avio_put_str16be writes zero
terminated strings and
the muxer previously wasn't.
I was going to object to this on the grounds that it wastes a whopping
two bytes per UTF-16 local tag, but I suspect the possible savings are
eaten up by KAG alignment anyway. Code simplicity is favorable in this
case I think :)
+if (err)\
+return err;\
+ret += 2;\
+return ret;\
+}\
+
+PUT_STR16(le, avio_wl16)
+PUT_STR16(be, avio_wb16)
+
+#undef PUT_STR16
int ff_get_v_length(uint64_t val)
{
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 17ad132..c25f5fd 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -624,14 +624,44 @@ static void mxf_write_preface(AVFormatContext *s)
}
/*
- * Write a local tag containing an ascii string as utf-16
+ * Returns the length of the UTF-16 string, in 16-bit characters,
that would result
+ * from decoding the utf-8 string.
+ */
+static uint64_t mxf_utf16len(const char *utf8_str)
+{
+const uint8_t *q = utf8_str;
+uint64_t size = 0;
+while (*q) {
+uint32_t ch;
+GET_UTF8(ch, *q++, goto invalid;)
+if (ch < 0x1)
+size++;
+else
+size += 2;
+continue;
+invalid:
+av_log(NULL, AV_LOG_ERROR, "Invaid UTF8 sequence in
mxf_utf16len\n\n");
+}
+size += 1;
+return size;
+}
Maybe this could be useful elsewhere too? What's the state of UTF-16
usage in lavf?
+/*
+ * Write a local tag containing an utf-8 string as utf-16
*/
static void mxf_write_local_tag_utf16(AVIOContext *pb, int tag, const
char *value)
{
-int i, size = strlen(value);
+int size = mxf_utf16len(value);
mxf_write_local_tag(pb, size*2, tag);
-for (i = 0; i < size; i++)
-avio_wb16(pb, value[i]);
+avio_put_str16be(pb, value);
}
Wow, this thing was really broken before.
Overall the patch looks fine, apart from maybe splitting it up.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: optimize twofish cipher
On Mon, Feb 16, 2015 at 03:11:08PM +0530, supraja reddy wrote: > Hello, > > I have attached a patch with optimization for twofish. Please let me know > if any further changes required. > > Following are the results for crypto_bench after optimization. > > lavu TWOFISH size: 1048576 runs: 1024 time: 18.799 +- 0.132 > gcrypt TWOFISH size: 1048576 runs: 1024 time: 25.643 +- 0.096 > tomcrypt TWOFISH size: 1048576 runs: 1024 time: 18.372 +- 0.082 please put these into the commit message, also add a "before" value for lavu TWOFISH so it can be seen by how much this commit makes the code faster [...] > +static uint32_t MDS[4][256]; doesnt thiis depend on the key(size) ? static variables must not change because code could be called from different threads at the same time and the static array would be shared so it could only be correct for one of the 2 threads, the other would produce a wrong result also it seems theres no fate test for twofish yet, such test should be usefull for testing / detecting regressions as its automatically run on many different platforms [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg, when outputting DNxHD due to the incorrect padding placement. Now we add the padding in the correct place, we also always add padding for Final Cut compatibility. Tidy up FATE changes due to padding changes. Kevin From b67ca5347a26227621054c82a688cc0ca44c11a1 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley Date: Mon, 16 Feb 2015 10:40:36 + Subject: [PATCH] Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg, when outputting DNxHD due to the incorrect padding placement. Now we add the padding in the correct place, we also always add padding for Final Cut compatibility. Tidy up FATE changes due to padding changes. Signed-off-by: Kevin Wheatley --- Changelog |3 ++ libavformat/movenc.c |7 +++- tests/ref/lavf/ismv | 12 +++--- tests/ref/lavf/mov| 16 tests/ref/seek/lavf-mov | 44 tests/ref/vsynth/vsynth1-avui |4 +- tests/ref/vsynth/vsynth1-dnxhd-1080i-colr |2 +- tests/ref/vsynth/vsynth1-mpeg4|4 +- tests/ref/vsynth/vsynth1-prores |4 +- tests/ref/vsynth/vsynth1-prores_ks|4 +- tests/ref/vsynth/vsynth1-qtrle|4 +- tests/ref/vsynth/vsynth1-qtrlegray|4 +- tests/ref/vsynth/vsynth1-svq1 |4 +- tests/ref/vsynth/vsynth2-avui |4 +- tests/ref/vsynth/vsynth2-dnxhd-1080i-colr |2 +- tests/ref/vsynth/vsynth2-mpeg4|4 +- tests/ref/vsynth/vsynth2-prores |4 +- tests/ref/vsynth/vsynth2-prores_ks|4 +- tests/ref/vsynth/vsynth2-qtrle|4 +- tests/ref/vsynth/vsynth2-qtrlegray|4 +- tests/ref/vsynth/vsynth2-svq1 |4 +- tests/ref/vsynth/vsynth3-dnxhd-1080i-colr |2 +- tests/ref/vsynth/vsynth3-mpeg4|4 +- tests/ref/vsynth/vsynth3-prores |4 +- tests/ref/vsynth/vsynth3-prores_ks|4 +- tests/ref/vsynth/vsynth3-qtrle|4 +- tests/ref/vsynth/vsynth3-svq1 |4 +- tests/ref/vsynth/vsynth_lena-avui |4 +- tests/ref/vsynth/vsynth_lena-dnxhd-1080i-colr |2 +- tests/ref/vsynth/vsynth_lena-mpeg4|4 +- tests/ref/vsynth/vsynth_lena-prores |4 +- tests/ref/vsynth/vsynth_lena-prores_ks|4 +- tests/ref/vsynth/vsynth_lena-qtrle|4 +- tests/ref/vsynth/vsynth_lena-qtrlegray|4 +- tests/ref/vsynth/vsynth_lena-svq1 |4 +- 35 files changed, 100 insertions(+), 94 deletions(-) diff --git a/Changelog b/Changelog index 0bf7018..8080286 100644 --- a/Changelog +++ b/Changelog @@ -30,6 +30,9 @@ version : - DV RTP payload format (RFC 6469) depacketizer - DXVA2-accelerated HEVC decoding - AAC ELD 480 decoding +- Fix stsd atom corruption in DNxHD QuickTimes +- Add 4 bytes stsd zero padding to video track for all QuickTime outputs + version 2.5: - HEVC/H.265 RTP payload format (draft v6) packetizer diff --git a/libavformat/movenc.c b/libavformat/movenc.c index f95d066..e8b3a6b 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1077,8 +1077,6 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack *track) for (i = 0; i < 10; i++) avio_wb64(pb, 0); -/* extra padding for stsd needed */ -avio_wb32(pb, 0); return 0; } @@ -1674,6 +1672,11 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr mov_write_pasp_tag(pb, track); } +/* extra padding for stsd needed */ +/* https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-61112 */ +/* suggests it is optional, but there are suggestions that Final Cut may need it. */ +avio_wb32(pb, 0); + return update_size(pb, pos); } diff --git a/tests/ref/lavf/ismv b/tests/ref/lavf/ismv index f29b5ff..ea8ea3a 100644 --- a/tests/ref/lavf/ismv +++ b/tests/ref/lavf/ismv @@ -1,9 +1,9 @@ -a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv -312542 ./tests/data/lavf/lavf.ismv +e26cf1bc88f31010c4c34af8eb9580ec *./tests/data/lavf/lavf.ismv +312546 ./tests/data/lavf/lavf.ismv ./tests/data/lavf/lavf.ismv CRC=0x9d9a638a -440d85f9fd5b9f63c2676638782b5c15 *./tests/data/lavf/lavf.ismv -321448 ./tests/data/lavf/lavf.ismv +ed0124f2dab1204869f3afed20d631c9 *./tests/data/lavf/lavf.ismv +321452 ./tests/data/lavf/lavf.ismv ./tests/data/lavf/lavf.ismv CRC=0xe8130120 -a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv -312542 ./tests/data/lavf/lavf.ismv +e26cf1bc88f31010c4c34af8eb9580ec *.
Re: [FFmpeg-devel] [PATCH 5/5] avcodec/vc1_mc: move median4() to mathops.h
On Sat, Feb 14, 2015 at 11:38:40PM +0800, zhaoxiu.zeng wrote:
> 在 2015/2/14 23:18, Paul B Mahol 写道:
> > On 2/14/15, zhaoxiu.zeng wrote:
> >> From 2f68090470ce1f4eb738e7a4af80c78a7b5d461a Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 14 Feb 2015 21:11:18 +0800
> >> Subject: [PATCH 5/5] avcodec/vc1_mc: move median4() to mathops.h
> >>
> >> ---
> >> libavcodec/mathops.h | 14 ++
> >> libavcodec/vc1_mc.c | 11 ---
> >> 2 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/libavcodec/mathops.h b/libavcodec/mathops.h
> >> index 87fca0c..87d110b 100644
> >> --- a/libavcodec/mathops.h
> >> +++ b/libavcodec/mathops.h
> >> @@ -121,6 +121,20 @@ static inline av_const int mid_pred(int a, int b, int
> >> c)
> >> }
> >> #endif
> >>
> >> +#ifndef median4
> >> +#define median4 median4
> >> +static inline av_const int median4(int a, int b, int c, int d)
> >> +{
> >> +if (a < b) {
> >> +if (c < d) return (FFMIN(b, d) + FFMAX(a, c)) / 2;
> >> +else return (FFMIN(b, c) + FFMAX(a, d)) / 2;
> >> +} else {
> >> +if (c < d) return (FFMIN(a, d) + FFMAX(b, c)) / 2;
> >> +else return (FFMIN(a, c) + FFMAX(b, d)) / 2;
> >> +}
> >> +}
> >> +#endif
> >> +
> >> #ifndef sign_extend
> >> static inline av_const int sign_extend(int val, unsigned bits)
> >> {
> >> diff --git a/libavcodec/vc1_mc.c b/libavcodec/vc1_mc.c
> >> index 15840fa..74f34a3 100644
> >> --- a/libavcodec/vc1_mc.c
> >> +++ b/libavcodec/vc1_mc.c
> >> @@ -279,17 +279,6 @@ void ff_vc1_mc_1mv(VC1Context *v, int dir)
> >> }
> >> }
> >>
> >> -static inline int median4(int a, int b, int c, int d)
> >> -{
> >> -if (a < b) {
> >> -if (c < d) return (FFMIN(b, d) + FFMAX(a, c)) / 2;
> >> -else return (FFMIN(b, c) + FFMAX(a, d)) / 2;
> >> -} else {
> >> -if (c < d) return (FFMIN(a, d) + FFMAX(b, c)) / 2;
> >> -else return (FFMIN(a, c) + FFMAX(b, d)) / 2;
> >> -}
> >> -}
> >> -
> >> /** Do motion compensation for 4-MV macroblock - luminance block
> >> */
> >> void ff_vc1_mc_4mv_luma(VC1Context *v, int n, int dir, int avg)
> >> --
> >> 2.1.0
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > why?
>
> We may provide the architecture related optimization.
patch applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix msvc compilation with --disable-indev=vfwcap
On Sun, Feb 08, 2015 at 08:57:52PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch intends to fix compilation with msvc > when the vfwcap input device is disabled. > Tested by Bernhard Döbler > > Please comment, Carl Eugen probably ok but i am no msvc guy and the msvc people seem not to care to review this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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/5] x86: hevc_mc: save 1 gpr in epel filter loading
Hi, 2015-02-16 4:51 GMT+01:00 Michael Niedermayer : > On Sat, Feb 07, 2015 at 06:49:38PM +, Christophe Gisquet wrote: >> The 3*stride value stored in r3src can be loaded much later, >> so use r3src instead of a dedicated gpr when possible. >> --- >> libavcodec/x86/hevc_mc.asm | 65 >> ++ >> 1 file changed, 31 insertions(+), 34 deletions(-) > > This seems to crash fate-hevc-conformance-AMP_D_Hisilicon and > others, didnt had time to look at why Can't test at the moment, but I guess the issue is in the !PIC case where: > %ifdef PIC > -lea rfilterq, [%%table] > +lea r3srcq, [%%table] > %else > %define rfilterq %%table > %endif > @@ -187,9 +184,8 @@ QPEL_TABLE 10, 8, w, avx2 > sub myq, 1 > shl mxq, %%shift; multiply by 32 > shl myq, %%shift; multiply by 32 > -mova m14, [rfilterq + mxq]; get 2 first values of > filters > -mova m15, [rfilterq + mxq+%%offset] ; get 2 last values > of filters > -lea r3srcq, [srcstrideq*3] > +mova m14, [r3srcq + mxq]; get 2 first values of > filters > +mova m15, [r3srcq + mxq+%%offset] ; get 2 last values of > filters Obviously I shouldn't unconditionally use r3srcq or equivalent, as !PIC just directly access the %%table I probably need to define an intermediate, say TABLE, which is either r3srcq or %%table, and use it for loading the xmm regs. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavutil: optimize twofish cipher
Hello,
I have attached a patch with optimization for twofish. Please let me know
if any further changes required.
Following are the results for crypto_bench after optimization.
lavu TWOFISH size: 1048576 runs: 1024 time: 18.799 +- 0.132
gcrypt TWOFISH size: 1048576 runs: 1024 time: 25.643 +- 0.096
tomcrypt TWOFISH size: 1048576 runs: 1024 time: 18.372 +- 0.082
Thanks,
Supraja
From 8863d42845e52a7dcf5bffb875dacdf9a4449c70 Mon Sep 17 00:00:00 2001
From: Supraja Meedinti
Date: Mon, 16 Feb 2015 14:46:24 +0530
Subject: [PATCH] libavutil: optimize twofish cipher
Signed-off-by: Supraja Meedinti
---
libavutil/twofish.c | 54 +
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/libavutil/twofish.c b/libavutil/twofish.c
index 337c099..a300290 100644
--- a/libavutil/twofish.c
+++ b/libavutil/twofish.c
@@ -26,6 +26,10 @@
#define LR(x, n) ((x) << (n) | (x) >> (32 - (n)))
#define RR(x, n) ((x) >> (n) | (x) << (32 - (n)))
+static uint32_t MDS[4][256];
+
+#define MDS_mul(X) (MDS[0][(X) & 0xff] ^ MDS[1][((X) >> 8) & 0xff] ^ MDS[2][((X) >> 16) & 0xff] ^ MDS[3][(X) >> 24])
+
typedef struct AVTWOFISH {
uint32_t K[40];
uint32_t S[4];
@@ -174,6 +178,39 @@ static uint32_t tf_h(uint32_t X, uint32_t L[4], int k)
return AV_RL32(l);
}
+static void precomputeMDS(uint32_t L[4], int k)
+{
+uint8_t y[4], l[4];
+int i;
+for (i = 0; i < 256; i++) {
+y[0] = y[1] = y[2] = y[3] = i;
+if (k == 4) {
+AV_WL32(l, L[3]);
+y[0] = q1[y[0]] ^ l[0];
+y[1] = q0[y[1]] ^ l[1];
+y[2] = q0[y[2]] ^ l[2];
+y[3] = q1[y[3]] ^ l[3];
+}
+if (k >= 3) {
+AV_WL32(l, L[2]);
+y[0] = q1[y[0]] ^ l[0];
+y[1] = q1[y[1]] ^ l[1];
+y[2] = q0[y[2]] ^ l[2];
+y[3] = q0[y[3]] ^ l[3];
+}
+AV_WL32(l, L[1]);
+y[0] = q1[q0[q0[y[0]] ^ l[0]] ^ (L[0] & 0xff)];
+y[1] = q0[q0[q1[y[1]] ^ l[1]] ^ ((L[0] >> 8) & 0xff)];
+y[2] = q1[q1[q0[y[2]] ^ l[2]] ^ ((L[0] >> 16) & 0xff)];
+y[3] = q0[q1[q1[y[3]] ^ l[3]] ^ (L[0] >> 24)];
+
+MDS[0][i] = ((uint32_t)y[0]) ^ ((uint32_t)MD1[y[0]] << 8) ^ ((uint32_t)MD2[y[0]] << 16) ^ ((uint32_t)MD2[y[0]] << 24);
+MDS[1][i] = ((uint32_t)MD2[y[1]]) ^ ((uint32_t)MD2[y[1]] << 8) ^ ((uint32_t)MD1[y[1]] << 16) ^ ((uint32_t)y[1] << 24);
+MDS[2][i] = ((uint32_t)MD1[y[2]]) ^ ((uint32_t)MD2[y[2]] << 8) ^ ((uint32_t)y[2] << 16) ^ ((uint32_t)MD2[y[2]] << 24);
+MDS[3][i] = ((uint32_t)MD1[y[3]]) ^ ((uint32_t)y[3] << 8) ^ ((uint32_t)MD2[y[3]] << 16) ^ ((uint32_t)MD1[y[3]] << 24);
+}
+}
+
static void twofish_encrypt(AVTWOFISH *cs, uint8_t *dst, const uint8_t *src)
{
uint32_t P[4], t0, t1;
@@ -183,12 +220,12 @@ static void twofish_encrypt(AVTWOFISH *cs, uint8_t *dst, const uint8_t *src)
P[2] = AV_RL32(src + 8) ^ cs->K[2];
P[3] = AV_RL32(src + 12) ^ cs->K[3];
for (i = 0; i < 16; i += 2) {
-t0 = tf_h(P[0], cs->S, cs->ksize);
-t1 = tf_h(LR(P[1], 8), cs->S, cs->ksize);
+t0 = MDS_mul(P[0]);
+t1 = MDS_mul(LR(P[1], 8));
P[2] = RR(P[2] ^ (t0 + t1 + cs->K[2 * i + 8]), 1);
P[3] = LR(P[3], 1) ^ (t0 + 2 * t1 + cs->K[2 * i + 9]);
-t0 = tf_h(P[2], cs->S, cs->ksize);
-t1 = tf_h(LR(P[3], 8), cs->S, cs->ksize);
+t0 = MDS_mul(P[2]);
+t1 = MDS_mul(LR(P[3], 8));
P[0] = RR(P[0] ^ (t0 + t1 + cs->K[2 * i + 10]), 1);
P[1] = LR(P[1], 1) ^ (t0 + 2 * t1 + cs->K[2 * i + 11]);
}
@@ -211,12 +248,12 @@ static void twofish_decrypt(AVTWOFISH *cs, uint8_t *dst, const uint8_t *src, uin
P[0] = AV_RL32(src + 8) ^ cs->K[6];
P[1] = AV_RL32(src + 12) ^ cs->K[7];
for (i = 15; i >= 0; i -= 2) {
-t0 = tf_h(P[2], cs->S, cs->ksize);
-t1 = tf_h(LR(P[3], 8), cs->S, cs->ksize);
+t0 = MDS_mul(P[2]);
+t1 = MDS_mul(LR(P[3], 8));
P[0] = LR(P[0], 1) ^ (t0 + t1 + cs->K[2 * i + 8]);
P[1] = RR(P[1] ^ (t0 + 2 * t1 + cs->K[2 * i + 9]), 1);
-t0 = tf_h(P[0], cs->S, cs->ksize);
-t1 = tf_h(LR(P[1], 8), cs->S, cs->ksize);
+t0 = MDS_mul(P[0]);
+t1 = MDS_mul(LR(P[1], 8));
P[2] = LR(P[2], 1) ^ (t0 + t1 + cs->K[2 * i + 6]);
P[3] = RR(P[3] ^ (t0 + 2 * t1 + cs->K[2 * i + 7]), 1);
}
@@ -265,6 +302,7 @@ av_cold int av_twofish_init(AVTWOFISH *cs, const uint8_t *key, int key_bits)
Mo[i] = Key[2 * i + 1];
cs->S[cs->ksize - i - 1] = tf_RS(Me[i], Mo[i]);
}
+precomputeMDS(cs->S,cs->ksize);
for (i = 0; i < 20; i++) {
A = tf_h((2 * i) * rho, Me, cs->ksize);
B = tf_h((2 * i + 1) * rho, Mo, cs->ksize);
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
