Re: [FFmpeg-devel] [PATCH]Allow using libopenjpeg 2.x
On 16.09.2014, at 22:35, Carl Eugen Hoyos wrote: > Hi! > > Attached patch allows using libopenjpeg 2.x (tested with 2.1) here. Doesn't it make sense to prefer the newest version, i.e. we should check for this first and not last? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 14/18] avfilter: remove obsolete FF_API_FILL_FRAME cruft
On 9/15/14, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavfilter/avcodec.c | 20
> libavfilter/avcodec.h | 41 -
> libavfilter/version.h | 3 ---
> 3 files changed, 64 deletions(-)
>
> diff --git a/libavfilter/avcodec.c b/libavfilter/avcodec.c
> index ba11a25..e0d9015 100644
> --- a/libavfilter/avcodec.c
> +++ b/libavfilter/avcodec.c
> @@ -135,23 +135,3 @@ int avfilter_copy_buf_props(AVFrame *dst, const
> AVFilterBufferRef *src)
> return 0;
> }
> #endif
> -
> -#if FF_API_FILL_FRAME
> -int avfilter_fill_frame_from_audio_buffer_ref(AVFrame *frame,
> - const AVFilterBufferRef
> *samplesref)
> -{
> -return avfilter_copy_buf_props(frame, samplesref);
> -}
> -
> -int avfilter_fill_frame_from_video_buffer_ref(AVFrame *frame,
> - const AVFilterBufferRef
> *picref)
> -{
> -return avfilter_copy_buf_props(frame, picref);
> -}
> -
> -int avfilter_fill_frame_from_buffer_ref(AVFrame *frame,
> -const AVFilterBufferRef *ref)
> -{
> -return avfilter_copy_buf_props(frame, ref);
> -}
> -#endif
> diff --git a/libavfilter/avcodec.h b/libavfilter/avcodec.h
> index 8bbdad2..d3d0e20 100644
> --- a/libavfilter/avcodec.h
> +++ b/libavfilter/avcodec.h
> @@ -66,45 +66,4 @@ AVFilterBufferRef
> *avfilter_get_buffer_ref_from_frame(enum AVMediaType type,
>int perms);
> #endif
>
> -#if FF_API_FILL_FRAME
> -/**
> - * Fill an AVFrame with the information stored in samplesref.
> - *
> - * @param frame an already allocated AVFrame
> - * @param samplesref an audio buffer reference
> - * @return >= 0 in case of success, a negative AVERROR code in case of
> - * failure
> - * @deprecated Use avfilter_copy_buf_props() instead.
> - */
> -attribute_deprecated
> -int avfilter_fill_frame_from_audio_buffer_ref(AVFrame *frame,
> - const AVFilterBufferRef
> *samplesref);
> -
> -/**
> - * Fill an AVFrame with the information stored in picref.
> - *
> - * @param frame an already allocated AVFrame
> - * @param picref a video buffer reference
> - * @return >= 0 in case of success, a negative AVERROR code in case of
> - * failure
> - * @deprecated Use avfilter_copy_buf_props() instead.
> - */
> -attribute_deprecated
> -int avfilter_fill_frame_from_video_buffer_ref(AVFrame *frame,
> - const AVFilterBufferRef
> *picref);
> -
> -/**
> - * Fill an AVFrame with information stored in ref.
> - *
> - * @param frame an already allocated AVFrame
> - * @param ref a video or audio buffer reference
> - * @return >= 0 in case of success, a negative AVERROR code in case of
> - * failure
> - * @deprecated Use avfilter_copy_buf_props() instead.
> - */
> -attribute_deprecated
> -int avfilter_fill_frame_from_buffer_ref(AVFrame *frame,
> -const AVFilterBufferRef *ref);
> -#endif
> -
> #endif /* AVFILTER_AVCODEC_H */
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index 6ebb1ce..4b1a359 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -55,9 +55,6 @@
> #ifndef FF_API_FOO_COUNT
> #define FF_API_FOO_COUNT(LIBAVFILTER_VERSION_MAJOR <
> 6)
> #endif
> -#ifndef FF_API_FILL_FRAME
> -#define FF_API_FILL_FRAME (LIBAVFILTER_VERSION_MAJOR <
> 5)
> -#endif
> #ifndef FF_API_BUFFERSRC_BUFFER
> #define FF_API_BUFFERSRC_BUFFER (LIBAVFILTER_VERSION_MAJOR <
> 5)
> #endif
> --
> 1.8.5.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: port mmxext and sse2 sad functions to yasm
On Tue, Sep 16, 2014 at 09:41:47PM -0300, James Almer wrote: > Also add a missing c->pix_abs[0][0] initialization, and sse2 versions of > sad16_x2, sad16_y2 and sad16_xy2 (%15 to %20 faster than mmxext). > Since the _xy2 versions are not bitexact, they are accordingly marked as > approximate. > > Signed-off-by: James Almer > --- > libavcodec/x86/me_cmp.asm| 330 > +++ > libavcodec/x86/me_cmp_init.c | 203 +++--- > 2 files changed, 379 insertions(+), 154 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On Mon, Sep 15, 2014 at 11:19 AM, Amnon Israely wrote: > It's work already more than 24h > > Maybe it's not a big problem but in some scenario may do some problem > > Input #0, decklink, from 'DeckLink SDI (3)@3': > Duration: N/A, start: 0.00, bitrate: 172032 kb/s > Stream #0:0: Audio: pcm_s16le, 48000 Hz, 8 channels, s16, 6144 kb/s > Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x576, > 165888 kb/s, 25 tbr, 1000k tbn, 25 tbc > > Audio stream map to 0:0 > > What do you think might be the problem here? > 2014-09-14 17:33 GMT+03:00 Amnon Israely : > > > I can help with testing under Linux. > > We use many deckling devices in production. > > > > 2014-09-14 17:15 GMT+03:00 Dave Rice : > > > >> > >> On Sep 14, 2014, at 7:07 AM, Deti Fliegl wrote: > >> > >> > I really would like to bring things forward, but currently nobody > wants > >> to review this patch. It's primarily something that is used under Linux > and > >> not Windows. So please would anyone have a look at my patch. > >> > >> I have a few decklink devices and would be happy to review this on Mac. > >> Does it work on Mac? > >> Dave Rice > >> > >> > Deti > >> > > >> > On 30.08.14 01:22, Michael Niedermayer wrote: > >> >> On Sat, Aug 23, 2014 at 10:50:37PM +0200, Deti Fliegl wrote: > >> >>> On 19.08.14 15:43, Carl Eugen Hoyos wrote: > >> Deti Fliegl fliegl.de> writes: > >> > >> > Minor update to propagate field dominance. > >> > >> At least a Changelog entry and a libavdevice version > >> bump are still missing, but consider waiting for a > >> real review. > >> >>> Well in the meantime I updated my patch once again to add proper > >> >>> frame sizes and frame rates to the video codec. Maybe somebody wants > >> >>> to review the patch. > >> >>> > >> >>> Deti > >> >>> > >> >> > >> >>> configure |4 > >> >>> doc/indevs.texi | 54 > >> >>> libavdevice/Makefile|5 > >> >>> libavdevice/alldevices.c|2 > >> >>> libavdevice/decklink_common.cpp | 229 + > >> >>> libavdevice/decklink_common.h | 98 +++ > >> >>> libavdevice/decklink_common_c.h | 32 ++ > >> >>> libavdevice/decklink_dec.cpp| 531 > >> > >> >>> libavdevice/decklink_dec.h | 32 ++ > >> >>> libavdevice/decklink_dec_c.c| 54 > >> >>> libavdevice/decklink_enc.cpp| 196 +- > >> >> > >> >> moving code from (like from decklink_enc.cpp to decklink_common.cpp) > >> >> should be in a seperate patch > >> >> > >> >> > >> >>> libavdevice/decklink_enc.h | 11 > >> >>> libavdevice/decklink_enc_c.c|1 > >> >>> 13 files changed, 1055 insertions(+), 194 deletions(-) > >> >> > >> >> If you want to maintain this code, please add yourself to the > >> >> MAINTAINERs file > >> >> > >> >> > >> >> [...] > >> >> > >> >>> +#ifdef _WIN32 > >> >>> +char *dup_wchar_to_utf8(wchar_t *w) > >> >> > >> >> non static functions should have a ff_ prefix (or av if they are > >> >> public but that isnt) > >> >> > >> >> also i dont really know windows & decklink stuff, so iam not the > >> >> ideal one to review ... > >> >> > >> >> [...] > >> >> > >> >> > >> >> > >> >> ___ > >> >> 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 > >> > >> ___ > >> 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 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Fix miscompilation for i586.
On Sun, Sep 14, 2014 at 01:01:45AM +0200, Mikulas Patocka wrote: > > > Hi > > > > > > Here I'm sending two patches to fix portability for 586-class machines > > > (Pentium, K6, etc.) > > > > > > > > > If the CPU is generic, 386, 486 or pentium, we must not use cmov in inline > > > assembler. > > > > > > Note that some Linux distributions are compiled for i686, and for them it > > > is > > > possible to use cmov in the assembler (because gcc uses it anyway). To > > > test for > > > this case, we test for defined(__i686__) || defined(__athlon__) || > > > defined(__SSE__) (these macros are driven by -march flag to gcc) and use > > > cmov if > > > one of these conditions is true. > > > > > > --- > > > configure|4 > > > libavcodec/x86/mathops.h |2 +- > > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > Index: ffmpeg/configure > > > === > > > --- ffmpeg.orig/configure 2014-09-12 21:46:25.710512294 +0200 > > > +++ ffmpeg/configure2014-09-12 21:46:32.099587711 +0200 > > > @@ -3840,8 +3840,12 @@ elif enabled sparc; then > > > elif enabled x86; then > > > > > > case $cpu in > > > +generic) > > > +disable i686 > > > +;; > > i686 extensions were specifically enabled some time ago by default, > > since we live in a modern world. > > If you're building for a older system, its your responsibility to pass > > the appropriate option. > > > > > i[345]86|pentium) > > > cpuflags="-march=$cpu" > > > +disable i686 > > > disable mmx > > > ;; > > > # targets that do NOT support nopl and conditional mov (cmov) > > > Index: ffmpeg/libavcodec/x86/mathops.h > > > === > > > --- ffmpeg.orig/libavcodec/x86/mathops.h2014-09-12 > > > 21:46:05.823390224 +0200 > > > +++ ffmpeg/libavcodec/x86/mathops.h 2014-09-12 21:46:32.116251966 > > > +0200 > > > @@ -69,7 +69,7 @@ static av_always_inline av_const int64_t > > > > > > #endif /* ARCH_X86_32 */ > > > > > > -#if HAVE_I686 > > > +#if HAVE_I686 || defined(__i686__) || defined(__athlon__) || > > > defined(__SSE__) > > > /* median of 3 */ > > > #define mid_pred mid_pred > > > static inline av_const int mid_pred(int a, int b, int c) > > > > I don't like this part, configure should control if the code is used, > > and if the i686 extensions are not enabled in configure, then they > > should not be built here. > > In my opinion you could remove HAVE_I686 and disable/enable i686 at all. > > The user sets CFLAGS="-march=xxx" variable when running ./configure and it > selects the instruction set that is being generated. This is problematic, it would work with gcc and clang i assume but we support many more compilers and i suspect it wont work for all. Though maybe that wouldnt matter as they probably dont do gcc inline asm either But it would also be a special case as all other "what to built" cpu extensions are controled by configure --enable/disable- flags also having to use -march to disable could be annoying for debuging as -march affects alot more > > In the program, you can easily determine what -march was passed to the > compiler and react to it - if one of __i686__, __athlon__, __SSE__ is > defined, you can use cmov, because the compiler is already generating > cmov. thats true, but maybe its better if you put this check in configure so the --enable/disable flags can be used to override it but iam not really opposed to this hunk either if others are ok with it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] x86/me_cmp: port mmxext and sse2 sad functions to yasm
On Wed, Sep 17, 2014 at 11:41:32AM +0200, James Almer wrote: > ffmpeg | branch: master | James Almer | Tue Sep 16 > 21:41:47 2014 -0300| [0456d169c469a79e305813d14c873fe698c8c572] | committer: > Michael Niedermayer > > x86/me_cmp: port mmxext and sse2 sad functions to yasm > > Also add a missing c->pix_abs[0][0] initialization, and sse2 versions of > sad16_x2, sad16_y2 and sad16_xy2 (%15 to %20 faster than mmxext). > Since the _xy2 versions are not bitexact, they are accordingly marked as > approximate. > > Signed-off-by: James Almer > Signed-off-by: Michael Niedermayer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0456d169c469a79e305813d14c873fe698c8c572 > --- > > libavcodec/x86/me_cmp.asm| 330 > ++ > libavcodec/x86/me_cmp_init.c | 203 +++--- > 2 files changed, 379 insertions(+), 154 deletions(-) > > diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm > index b0741f3..27176f4 100644 > --- a/libavcodec/x86/me_cmp.asm > +++ b/libavcodec/x86/me_cmp.asm > @@ -23,6 +23,10 @@ > > %include "libavutil/x86/x86util.asm" > > +SECTION_RODATA > + > +cextern pb_1 > + > SECTION .text > > %macro DIFF_PIXELS_1 4 > @@ -465,3 +469,329 @@ cglobal hf_noise%1, 3,3,0, pix1, lsize, h > INIT_MMX mmx > HF_NOISE 8 > HF_NOISE 16 > + > +;--- > +;int ff_sad_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int > stride, int h); > +;--- > +INIT_MMX mmxext > +cglobal sad8, 4, 4, 0, v, pix1, pix2, stride > +movu m2, [pix2q] > +movu m1, [pix2q+strideq] > +psadbwm2, [pix1q] > +psadbwm1, [pix1q+strideq] > +paddw m2, m1 > + > +%rep 3 > +leapix1q, [pix1q+strideq*2] > +leapix2q, [pix2q+strideq*2] > +movu m0, [pix2q] > +movu m1, [pix2q+strideq] > +psadbwm0, [pix1q] > +psadbwm1, [pix1q+strideq] > +paddw m2, m0 > +paddw m2, m1 > +%endrep > +movd eax, m2 > +RET > + Sorry to notice that now but... what happened to the h parameter? [...] -- Clément B. pgpAmbTLCENS7.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Fix miscompilation for i586.
Hi, On Wed, Sep 17, 2014 at 4:08 AM, Michael Niedermayer wrote: > On Sun, Sep 14, 2014 at 01:01:45AM +0200, Mikulas Patocka wrote: > > In the program, you can easily determine what -march was passed to the > > compiler and react to it - if one of __i686__, __athlon__, __SSE__ is > > defined, you can use cmov, because the compiler is already generating > > cmov. > > thats true, > but maybe its better if you put this check in configure so the > --enable/disable flags can be used to override it +1 on this. For code that is clearly intended to be shared between compilers (and many compilers support inline asm), I don't think we want to use compiler-specific flags. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] x86/me_cmp: port mmxext and sse2 sad functions to yasm
On Wed, Sep 17, 2014 at 01:18:12PM +0200, Clément Bœsch wrote: > On Wed, Sep 17, 2014 at 11:41:32AM +0200, James Almer wrote: > > ffmpeg | branch: master | James Almer | Tue Sep 16 > > 21:41:47 2014 -0300| [0456d169c469a79e305813d14c873fe698c8c572] | > > committer: Michael Niedermayer > > > > x86/me_cmp: port mmxext and sse2 sad functions to yasm > > > > Also add a missing c->pix_abs[0][0] initialization, and sse2 versions of > > sad16_x2, sad16_y2 and sad16_xy2 (%15 to %20 faster than mmxext). > > Since the _xy2 versions are not bitexact, they are accordingly marked as > > approximate. > > > > Signed-off-by: James Almer > > Signed-off-by: Michael Niedermayer > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0456d169c469a79e305813d14c873fe698c8c572 > > --- > > > > libavcodec/x86/me_cmp.asm| 330 > > ++ > > libavcodec/x86/me_cmp_init.c | 203 +++--- > > 2 files changed, 379 insertions(+), 154 deletions(-) > > > > diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm > > index b0741f3..27176f4 100644 > > --- a/libavcodec/x86/me_cmp.asm > > +++ b/libavcodec/x86/me_cmp.asm > > @@ -23,6 +23,10 @@ > > > > %include "libavutil/x86/x86util.asm" > > > > +SECTION_RODATA > > + > > +cextern pb_1 > > + > > SECTION .text > > > > %macro DIFF_PIXELS_1 4 > > @@ -465,3 +469,329 @@ cglobal hf_noise%1, 3,3,0, pix1, lsize, h > > INIT_MMX mmx > > HF_NOISE 8 > > HF_NOISE 16 > > + > > +;--- > > +;int ff_sad_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int > > stride, int h); > > +;--- > > +INIT_MMX mmxext > > +cglobal sad8, 4, 4, 0, v, pix1, pix2, stride > > +movu m2, [pix2q] > > +movu m1, [pix2q+strideq] > > +psadbwm2, [pix1q] > > +psadbwm1, [pix1q+strideq] > > +paddw m2, m1 > > + > > +%rep 3 > > +leapix1q, [pix1q+strideq*2] > > +leapix2q, [pix2q+strideq*2] > > +movu m0, [pix2q] > > +movu m1, [pix2q+strideq] > > +psadbwm0, [pix1q] > > +psadbwm1, [pix1q+strideq] > > +paddw m2, m0 > > +paddw m2, m1 > > +%endrep > > +movd eax, m2 > > +RET > > + > > Sorry to notice that now but... what happened to the h parameter? i had missed that when reviewing fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] archive ffmpeg all objs into one lib, feasible?
I've build ffmpeg static libraries, and all necessary objs (*.o) generated in their source directory. I use 'ar' to archive all these objs into one libffmpeg.a. command: *ar rc libffmpeg.a *.o* I notice that, there are some objs have same name in different dirs, for example *libavformat/4xm.o and libavcodec/4xm.o*. by 'nm libffmpeg.a', it seems both objs are there? 'man ar' I find that, if obj with same name and Exactly with same function symbols, latter one will be replaced ,right? by this 'ar' way, will libffmpeg.a work correctly? because there so many symbols I can't test every one. thanks for help! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] x86/me_cmp: port mmxext and sse2 sad functions to yasm
On 17/09/14 9:07 AM, Michael Niedermayer wrote: > On Wed, Sep 17, 2014 at 01:18:12PM +0200, Clément Bœsch wrote: >> On Wed, Sep 17, 2014 at 11:41:32AM +0200, James Almer wrote: >>> ffmpeg | branch: master | James Almer | Tue Sep 16 >>> 21:41:47 2014 -0300| [0456d169c469a79e305813d14c873fe698c8c572] | >>> committer: Michael Niedermayer >>> >>> x86/me_cmp: port mmxext and sse2 sad functions to yasm >>> >>> Also add a missing c->pix_abs[0][0] initialization, and sse2 versions of >>> sad16_x2, sad16_y2 and sad16_xy2 (%15 to %20 faster than mmxext). >>> Since the _xy2 versions are not bitexact, they are accordingly marked as >>> approximate. >>> >>> Signed-off-by: James Almer >>> Signed-off-by: Michael Niedermayer >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0456d169c469a79e305813d14c873fe698c8c572 >>> --- >>> >>> libavcodec/x86/me_cmp.asm| 330 >>> ++ >>> libavcodec/x86/me_cmp_init.c | 203 +++--- >>> 2 files changed, 379 insertions(+), 154 deletions(-) >>> >>> diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm >>> index b0741f3..27176f4 100644 >>> --- a/libavcodec/x86/me_cmp.asm >>> +++ b/libavcodec/x86/me_cmp.asm >>> @@ -23,6 +23,10 @@ >>> >>> %include "libavutil/x86/x86util.asm" >>> >>> +SECTION_RODATA >>> + >>> +cextern pb_1 >>> + >>> SECTION .text >>> >>> %macro DIFF_PIXELS_1 4 >>> @@ -465,3 +469,329 @@ cglobal hf_noise%1, 3,3,0, pix1, lsize, h >>> INIT_MMX mmx >>> HF_NOISE 8 >>> HF_NOISE 16 >>> + >>> +;--- >>> +;int ff_sad_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int >>> stride, int h); >>> +;--- >>> +INIT_MMX mmxext >>> +cglobal sad8, 4, 4, 0, v, pix1, pix2, stride >>> +movu m2, [pix2q] >>> +movu m1, [pix2q+strideq] >>> +psadbwm2, [pix1q] >>> +psadbwm1, [pix1q+strideq] >>> +paddw m2, m1 >>> + >>> +%rep 3 >>> +leapix1q, [pix1q+strideq*2] >>> +leapix2q, [pix2q+strideq*2] >>> +movu m0, [pix2q] >>> +movu m1, [pix2q+strideq] >>> +psadbwm0, [pix1q] >>> +psadbwm1, [pix1q+strideq] >>> +paddw m2, m0 >>> +paddw m2, m1 >>> +%endrep >>> +movd eax, m2 >>> +RET >>> + >> >> Sorry to notice that now but... what happened to the h parameter? > > i had missed that when reviewing > > fixed It's not needed. I purposely removed it and made it a fixed %rep since it's supposedly guaranteed to be 8. Check the inline version it replaced. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Adobe HTTP Dynamic Streaming (HDS) demuxer improvements
After contacting the original author of the the patch posted in:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154612.html
I attach a new patch with improvements:
- Better codec detection in amfmetata
- Better live streams handling (Get current segment, calculate next
segment..etc)
- Parse tabs in raw xml (0x09)
Tested streams:
http://livehds.rasset.ie/hds-live/_definst_/rte1/rte1_288p.f4m
http://livehds.rasset.ie/hds-live/_definst_/rte2/rte2_288p.f4m
http://livehds.rasset.ie/hds-live/_definst_/newsnow/newsnow_288p.f4m
TODO:
- Parse child manifest, ex:
http://www.rte.ie/manifests/rte1.f4m
http://www.rte.ie/manifests/newsnow.f4m
- Implement fragment caching.
diff --git Changelog Changelog
index 6260d0c..053d36d 100644
--- Changelog
+++ Changelog
@@ -7,6 +7,7 @@ version :
- large optimizations in dctdnoiz to make it usable
- request icecast metadata by default
- support for using metadata in stream specifiers in fftools
+- Adobe HTTP Dynamic Streaming (HDS) demuxer
version 2.3:
diff --git configure configure
index f355dad..f8645bf 100755
--- configure
+++ configure
@@ -261,6 +261,7 @@ External library support:
--enable-x11grab enable X11 grabbing [no]
--disable-xlib disable xlib [autodetect]
--disable-zlib disable zlib [autodetect]
+ --disable-xml2 disable XML parsing using the C library libxml2 [autodetect]
Toolchain options:
--arch=ARCH select architecture [$arch]
@@ -1386,6 +1387,7 @@ EXTERNAL_LIBRARY_LIST="
openssl
x11grab
xlib
+xml2
zlib
"
@@ -2386,6 +2388,7 @@ f4v_muxer_select="mov_muxer"
flac_demuxer_select="flac_parser"
hds_muxer_select="flv_muxer"
hls_muxer_select="mpegts_muxer"
+hds_demuxer_select="xml2"
image2_alias_pix_demuxer_select="image2_demuxer"
image2_brender_pix_demuxer_select="image2_demuxer"
ipod_muxer_select="mov_muxer"
@@ -4756,6 +4759,12 @@ fi
disabled zlib || check_lib zlib.h zlibVersion -lz || disable zlib
disabled bzlib || check_lib2 bzlib.h BZ2_bzlibVersion -lbz2 || disable bzlib
+disabled xml2 || {
+check_pkg_config libxml-2.0 libxml2/libxml/xmlversion.h xmlCheckVersion &&
+require_pkg_config libxml-2.0 libxml2/libxml/xmlversion.h xmlCheckVersion
+} || disable xml2
+
+
check_lib math.h sin -lm && LIBM="-lm"
disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersion -lcrystalhd || disable crystalhd
diff --git libavformat/Makefile libavformat/Makefile
index 11d3e9c..30fe33c 100644
--- libavformat/Makefile
+++ libavformat/Makefile
@@ -170,6 +170,7 @@ OBJS-$(CONFIG_H263_MUXER)+= rawenc.o
OBJS-$(CONFIG_H264_DEMUXER) += h264dec.o rawdec.o
OBJS-$(CONFIG_H264_MUXER)+= rawenc.o
OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
+OBJS-$(CONFIG_HDS_DEMUXER) += hdsdec.o amfmetadata.o f4mmanifest.o f4fbox.o flvtag.o
OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
OBJS-$(CONFIG_HLS_DEMUXER) += hls.o
diff --git libavformat/allformats.c libavformat/allformats.c
index c3b9ba5..5489cc4 100644
--- libavformat/allformats.c
+++ libavformat/allformats.c
@@ -137,7 +137,7 @@ void av_register_all(void)
REGISTER_MUXDEMUX(H261, h261);
REGISTER_MUXDEMUX(H263, h263);
REGISTER_MUXDEMUX(H264, h264);
-REGISTER_MUXER (HDS, hds);
+REGISTER_MUXDEMUX(HDS, hds);
REGISTER_MUXDEMUX(HEVC, hevc);
REGISTER_MUXDEMUX(HLS, hls);
REGISTER_DEMUXER (HNM, hnm);
diff --git libavformat/version.h libavformat/version.h
index c09bd88..8b8a690 100644
--- libavformat/version.h
+++ libavformat/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFORMAT_VERSION_MAJOR 56
-#define LIBAVFORMAT_VERSION_MINOR 1
+#define LIBAVFORMAT_VERSION_MINOR 2
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
diff --git libavformat/amfmetadata.c libavformat/amfmetadata.c
new file mode 100644
index 000..7068e87
--- /dev/null
+++ libavformat/amfmetadata.c
@@ -0,0 +1,232 @@
+/*
+ * Adobe Action Message Format Parser
+ * Copyright (c) 2013 Cory McCarthy
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FF
Re: [FFmpeg-devel] [PATCH] Adobe HTTP Dynamic Streaming (HDS) demuxer improvements
Gorilla Maguila gmail.com> writes:
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154612.html
>
> I attach a new patch with improvements:
I wanted to write an answer with a few minor remarks
but just saw that several issues from the original
review are still valid:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/171211/focus=171212
(missing av_log context, not using av_freep() which
is safer, many unneeded and ugly casts, the probe
function has a too high score or not enough tests)
Maybe you should double-check for unchecked reads
from external data, I cannot comment if they were
fixed.
Also please format if-else if like this:
if(cond1) {
do1;
} else if(cond2) {
...
Note that "} else if" should be all in one line.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] x86/me_cmp: port mmxext and sse2 sad functions to yasm
On Wed, Sep 17, 2014 at 01:14:33PM -0300, James Almer wrote: > On 17/09/14 9:07 AM, Michael Niedermayer wrote: > > On Wed, Sep 17, 2014 at 01:18:12PM +0200, Clément Bœsch wrote: > >> On Wed, Sep 17, 2014 at 11:41:32AM +0200, James Almer wrote: > >>> ffmpeg | branch: master | James Almer | Tue Sep 16 > >>> 21:41:47 2014 -0300| [0456d169c469a79e305813d14c873fe698c8c572] | > >>> committer: Michael Niedermayer > >>> > >>> x86/me_cmp: port mmxext and sse2 sad functions to yasm > >>> > >>> Also add a missing c->pix_abs[0][0] initialization, and sse2 versions of > >>> sad16_x2, sad16_y2 and sad16_xy2 (%15 to %20 faster than mmxext). > >>> Since the _xy2 versions are not bitexact, they are accordingly marked as > >>> approximate. > >>> > >>> Signed-off-by: James Almer > >>> Signed-off-by: Michael Niedermayer > >>> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0456d169c469a79e305813d14c873fe698c8c572 > >>> --- > >>> > >>> libavcodec/x86/me_cmp.asm| 330 > >>> ++ > >>> libavcodec/x86/me_cmp_init.c | 203 +++--- > >>> 2 files changed, 379 insertions(+), 154 deletions(-) > >>> > >>> diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm > >>> index b0741f3..27176f4 100644 > >>> --- a/libavcodec/x86/me_cmp.asm > >>> +++ b/libavcodec/x86/me_cmp.asm > >>> @@ -23,6 +23,10 @@ > >>> > >>> %include "libavutil/x86/x86util.asm" > >>> > >>> +SECTION_RODATA > >>> + > >>> +cextern pb_1 > >>> + > >>> SECTION .text > >>> > >>> %macro DIFF_PIXELS_1 4 > >>> @@ -465,3 +469,329 @@ cglobal hf_noise%1, 3,3,0, pix1, lsize, h > >>> INIT_MMX mmx > >>> HF_NOISE 8 > >>> HF_NOISE 16 > >>> + > >>> +;--- > >>> +;int ff_sad_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int > >>> stride, int h); > >>> +;--- > >>> +INIT_MMX mmxext > >>> +cglobal sad8, 4, 4, 0, v, pix1, pix2, stride > >>> +movu m2, [pix2q] > >>> +movu m1, [pix2q+strideq] > >>> +psadbwm2, [pix1q] > >>> +psadbwm1, [pix1q+strideq] > >>> +paddw m2, m1 > >>> + > >>> +%rep 3 > >>> +leapix1q, [pix1q+strideq*2] > >>> +leapix2q, [pix2q+strideq*2] > >>> +movu m0, [pix2q] > >>> +movu m1, [pix2q+strideq] > >>> +psadbwm0, [pix1q] > >>> +psadbwm1, [pix1q+strideq] > >>> +paddw m2, m0 > >>> +paddw m2, m1 > >>> +%endrep > >>> +movd eax, m2 > >>> +RET > >>> + > >> > >> Sorry to notice that now but... what happened to the h parameter? > > > > i had missed that when reviewing > > > > fixed > > It's not needed. I purposely removed it and made it a fixed %rep since it's > supposedly > guaranteed to be 8. > Check the inline version it replaced. hmm, we need a 8x4 for interlaced chroma motion estimation but maybe we just dont support interlaced chroma ME, i dont remember still i think its better if our code can handle that case so support for interlaced chroma ME ca be added without needing to update the asm [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Status of dvdsub "forced_subs_only" patch
> On Tuesday, September 16, 2014 1:34 PM, Nicholas Robbins > wrote: > > Ok, I seem to have a partial solution. > > I thought that the place to put this would be in the dvdsubenc.c. So I made > the > following changes (sorry for inline patch) > > So, it seems like what I am doing produces a mangled dvdsub track, but one > that > ffmpeg can make sense of. It isn't just some muxing thing since if I run > only.mkv through mkvmerge, it doesn't get fixed. > > How can I finish this patch? Any thoughts on this? I don't think I should submit this patch since it produces corrupted tracks. But it works good enough for me (I just wash the subtitle mkv with ffmpeg again) -Nick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 14/18] avfilter: remove obsolete FF_API_FILL_FRAME cruft
On 17/09/14 4:40 AM, Paul B Mahol wrote: > On 9/15/14, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavfilter/avcodec.c | 20 >> libavfilter/avcodec.h | 41 - >> libavfilter/version.h | 3 --- >> 3 files changed, 64 deletions(-) > > lgtm Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
Hi FFmpeg web folks, When visiting http://fate.ffmpeg.org/ using a browser that enforces CORS[1], loading the FontAwesome icon font causes this error: Font from origin 'https://ffmpeg.org' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed access. The fateserver commit that introduced this (b74b380b) includes this change: > diff --git a/index.cgi b/index.cgi > index 7204591..105cb86 100755 > --- a/index.cgi > +++ b/index.cgi > [...] > print "Content-type: text/html\r\n"; > +print "Access-Control-Allow-Origin: https://ffmpeg.org\r\n";; However, this won't help, since the Access-Control-Allow-Origin header needs to be on the requested resource (in this case, fontawesome-webfont.*), not the requester. To make fate.ffmpeg.org work correctly, the above header would need to be added to the web server configuration for the files in ffmpeg.org/fonts with http://fate.ffmpeg.org (or *) as the allowed origin. When testing, be sure to start with a fresh session (e.g. incognito window in Chrome) - if you visit ffmpeg.org first, the font will be cached and the icons on fate.ffmpeg.org will work by accident. Thanks, -- Daniel [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Make swscale x86 ASM depend less on registers been preserved across blocks
Hi! I'm not sure we can count on registers been preserved across ASM blocks. Moreover, this causes problems with utils that instrument the code by inserting function calls between lines (like ThreadSanitizer). The attached patch fix one instance of this problem in swscale. -Vitor 0001-swscale-x86-do-not-expect-registers-to-be-preserved-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] More specific error codes
I have got many complaints about FFmpeg error codes being too abstract. Not helpful for quick resolution, in a lot of such cases real issue with application must be investigated manually (by reviewing log with debug loglevel and/or sniffing traffic). E.g., "Invalid data" may mean almost everything, including 404 Not Found by RTSP. I propose to introduce more specific error codes, like - "resource not found", - "auth failed" and so on. Please let me know what you think about this. For now, is there a reference table for possible reasons of currently used error codes? -- Andrey Utkin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
On Wed, Sep 17, 2014 at 11:33:32AM -0700, Daniel Verkamp wrote: > Hi FFmpeg web folks, > > When visiting http://fate.ffmpeg.org/ using a browser that enforces > CORS[1], loading the FontAwesome icon font causes this error: > > Font from origin 'https://ffmpeg.org' has been blocked from loading > by Cross-Origin Resource Sharing policy: No > 'Access-Control-Allow-Origin' header is present on the requested > resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed > access. > > The fateserver commit that introduced this (b74b380b) includes this change: > > > diff --git a/index.cgi b/index.cgi > > index 7204591..105cb86 100755 > > --- a/index.cgi > > +++ b/index.cgi > > [...] > > print "Content-type: text/html\r\n"; > > +print "Access-Control-Allow-Origin: https://ffmpeg.org\r\n";; > > However, this won't help, since the Access-Control-Allow-Origin header > needs to be on the requested resource (in this case, > fontawesome-webfont.*), not the requester. > > To make fate.ffmpeg.org work correctly, the above header would need to > be added to the web server configuration for the files in > ffmpeg.org/fonts with http://fate.ffmpeg.org (or *) as the allowed > origin. as you seem to know this / have researched it already can you post what i need to add to httpd.conf to make this work ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] archive ffmpeg all objs into one lib, feasible?
No, it won't work because the libraries are for different purposes. as per your example, 4xm in the libavcodec directory is for decoding the file, it implements the actual algorithm. 4xm in the libavformat directory is for demuxing the codec from the 4xm container, you need both for it to work. On Wed, Sep 17, 2014 at 10:37 AM, Lynn Yu wrote: > I've build ffmpeg static libraries, and all necessary objs (*.o) generated > in their source directory. > > I use 'ar' to archive all these objs into one libffmpeg.a. > > command: *ar rc libffmpeg.a *.o* > > I notice that, there are some objs have same name in different dirs, for > example *libavformat/4xm.o and libavcodec/4xm.o*. > > by 'nm libffmpeg.a', it seems both objs are there? > > 'man ar' I find that, if obj with same name and Exactly with same function > symbols, latter one will be replaced ,right? > > by this 'ar' way, will libffmpeg.a work correctly? because there so many > symbols I can't test every one. > > thanks for help! > ___ > 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 1/2] ffplay: factorize frame queue operations
On Wed, 17 Sep 2014, Michael Niedermayer wrote: On Wed, Sep 17, 2014 at 03:47:09AM +0200, Michael Niedermayer wrote: On Wed, Sep 17, 2014 at 12:19:49AM +0200, Marton Balint wrote: On Sat, 6 Sep 2014, Marton Balint wrote: Create a generic frame and a frame queue struct to handle video picture queues and subtitle picture queues with common code. Also add the possibility to queue AVFrames, however at the moment we only use SDL_Overlay buffers for video and AVSubtitles for subtitles. Signed-off-by: Marton Balint --- ffplay.c | 357 +++ 1 file changed, 199 insertions(+), 158 deletions(-) diff --git a/ffplay.c b/ffplay.c index 833b5b1..c59065f 100644 Hello Michael, Please merge from my stable branch for the ffplay patches: 5a5128b ffplay: factorize frame queue operations 1643764 ffplay: use frame queue to determine last used pos merged Seems this causes problems on apple: http://fate.ffmpeg.org/report.cgi?time=20140917022057&slot=x86_64-darwin-gcc-4.9 ill commit something that might fix the build in a moment so its not left broken but please check it when you have time Your fix is OK, thanks, and sorry for the hiccup. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] More specific error codes
On Wed, 17 Sep 2014 22:56:27 +0300 Andrey Utkin wrote: > I have got many complaints about FFmpeg error codes being too > abstract. Not helpful for quick resolution, in a lot of such cases > real issue with application must be investigated manually (by > reviewing log with debug loglevel and/or sniffing traffic). > E.g., "Invalid data" may mean almost everything, including 404 Not > Found by RTSP. > I propose to introduce more specific error codes, like > - "resource not found", > - "auth failed" > and so on. > Please let me know what you think about this. I agree. Specifically, wrapping unix error codes is more than useless. Logging could also be better. It's true that you can't give an error code for everything, because some things are just too special, and you'd end up with an unusable amount of error codes. It would be fine to just print an error message via the log callback. Unfortunately, it's hard to separate random errors from corrupted or unexpected data, and error messages that might actually be helpful to the user. Also, the log callback is global. Sometimes libav* will print messages that make sense only with ffmpeg or ffplay cli (like the warning about experimental decoders). The real problem is that there are hundreds of kloc code which all handles this inconsistently/badly, and cleaning that up would be not feasible. > For now, is there a reference table for possible reasons of currently > used error codes? > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make swscale x86 ASM depend less on registers been preserved across blocks
On Wed, Sep 17, 2014 at 09:21:08PM +0200, Vitor Sessak wrote:
> Hi!
>
> I'm not sure we can count on registers been preserved across ASM
> blocks. Moreover, this causes problems with utils that instrument the
> code by inserting function calls between lines (like ThreadSanitizer).
>
> The attached patch fix one instance of this problem in swscale.
>
> -Vitor
> swscale.c | 82
> +++---
> 1 file changed, 42 insertions(+), 40 deletions(-)
> 7fe9f7a0c1a7c1ed843b891f5f810fbd94a2e03f
> 0001-swscale-x86-do-not-expect-registers-to-be-preserved-.patch
> From f1c59628b2baeb9994bed8947c0a2c228610bf4f Mon Sep 17 00:00:00 2001
> From: Vitor Sessak
> Date: Wed, 17 Sep 2014 21:10:16 +0200
> Subject: [PATCH] swscale/x86: do not expect registers to be preserved across
> inline ASM blocks
>
> ---
> libswscale/x86/swscale.c | 82
> +---
> 1 file changed, 42 insertions(+), 40 deletions(-)
>
> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> index c4c0e28..38157c8 100644
> --- a/libswscale/x86/swscale.c
> +++ b/libswscale/x86/swscale.c
> @@ -205,36 +205,19 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
> filterSize,
> yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset);
> return;
> }
> -if (offset) {
> -__asm__ volatile("movq (%0), %%xmm3\n\t"
> - "movdqa%%xmm3, %%xmm4\n\t"
> - "psrlq $24, %%xmm3\n\t"
> - "psllq $40, %%xmm4\n\t"
> - "por %%xmm4, %%xmm3\n\t"
> - :: "r"(dither)
> - );
> -} else {
> -__asm__ volatile("movq (%0), %%xmm3\n\t"
> - :: "r"(dither)
> - );
> -}
> -filterSize--;
not sure i missed it but it seems this is lost in teh new code
> -__asm__ volatile(
> -"pxor %%xmm0, %%xmm0\n\t"
> -"punpcklbw %%xmm0, %%xmm3\n\t"
> -"movd %0, %%xmm1\n\t"
> -"punpcklwd %%xmm1, %%xmm1\n\t"
> -"punpckldq %%xmm1, %%xmm1\n\t"
> -"punpcklqdq %%xmm1, %%xmm1\n\t"
> -"psllw $3, %%xmm1\n\t"
> -"paddw %%xmm1, %%xmm3\n\t"
> -"psraw $4, %%xmm3\n\t"
> -::"m"(filterSize)
> - );
> -__asm__ volatile(
> -"movdqa%%xmm3, %%xmm4\n\t"
> -"movdqa%%xmm3, %%xmm7\n\t"
> -"movl %3, %%ecx\n\t"
> +#define MAIN_FUNCTION \
> +"pxor %%xmm0, %%xmm0 \n\t" \
> +"punpcklbw %%xmm0, %%xmm3 \n\t" \
> +"movd %4, %%xmm1 \n\t" \
> +"punpcklwd %%xmm1, %%xmm1 \n\t" \
> +"punpckldq %%xmm1, %%xmm1 \n\t" \
> +"punpcklqdq %%xmm1, %%xmm1 \n\t" \
> +"psllw $3, %%xmm1 \n\t" \
> +"paddw %%xmm1, %%xmm3 \n\t" \
> +"psraw $4, %%xmm3 \n\t" \
> +"movdqa %%xmm3, %%xmm4 \n\t" \
> +"movdqa %%xmm3, %%xmm7 \n\t" \
> +"movl %3, %%ecx \n\t" \
> "mov %0, %%"REG_d" \n\t"\
> "mov(%%"REG_d"), %%"REG_S" \n\t"\
> ".p2align 4 \n\t" /* FIXME
> Unroll? */\
> @@ -252,20 +235,39 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
> filterSize,
> " jnz1b \n\t"\
> "psraw $3, %%xmm3 \n\t"\
> "psraw $3, %%xmm4 \n\t"\
> -"packuswb %%xmm4, %%xmm3 \n\t"
> -"movntdq %%xmm3, (%1, %%"REG_c")\n\t"
> +"packuswb %%xmm4, %%xmm3 \n\t"\
> +"movntdq %%xmm3, (%1, %%"REG_c")\n\t"\
> "add $16, %%"REG_c" \n\t"\
> "cmp %2, %%"REG_c" \n\t"\
> -"movdqa%%xmm7, %%xmm3\n\t"
> -"movdqa%%xmm7, %%xmm4\n\t"
> +"movdqa %%xmm7, %%xmm3\n\t" \
> +"movdqa %%xmm7, %%xmm4\n\t" \
> "mov %0, %%"REG_d" \n\t"\
> "mov(%%"REG_d"), %%"REG_S" \n\t"\
> -"jb 1b \n\t"\
> -:: "g" (filter),
> - "r" (dest-offset), "g" ((x86_reg)(dstW+offset)), "m" (offset)
> -: XMM_CLOBBERS("%xmm0" , "%xmm1" , "%xmm2" , "%xmm3" , "%xmm4" ,
> "%xmm5" , "%xmm7" ,)
> - "%"REG_d, "%"REG_S, "%"REG_c
> -);
> +"jb 1b \n\t"
> +
> +if (offset) {
> +__asm__ volatile(
> +"movq %5, %%xmm3 \n\t"
> +
Re: [FFmpeg-devel] [PATCH] Make swscale x86 ASM depend less on registers been preserved across blocks
On Wed, Sep 17, 2014 at 10:31 PM, Michael Niedermayer wrote:
> On Wed, Sep 17, 2014 at 09:21:08PM +0200, Vitor Sessak wrote:
>> Hi!
>>
>> I'm not sure we can count on registers been preserved across ASM
>> blocks. Moreover, this causes problems with utils that instrument the
>> code by inserting function calls between lines (like ThreadSanitizer).
>>
>> The attached patch fix one instance of this problem in swscale.
>>
>> -Vitor
>
>> swscale.c | 82
>> +++---
>> 1 file changed, 42 insertions(+), 40 deletions(-)
>> 7fe9f7a0c1a7c1ed843b891f5f810fbd94a2e03f
>> 0001-swscale-x86-do-not-expect-registers-to-be-preserved-.patch
>> From f1c59628b2baeb9994bed8947c0a2c228610bf4f Mon Sep 17 00:00:00 2001
>> From: Vitor Sessak
>> Date: Wed, 17 Sep 2014 21:10:16 +0200
>> Subject: [PATCH] swscale/x86: do not expect registers to be preserved across
>> inline ASM blocks
>>
>> ---
>> libswscale/x86/swscale.c | 82
>> +---
>> 1 file changed, 42 insertions(+), 40 deletions(-)
>>
>> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
>> index c4c0e28..38157c8 100644
>> --- a/libswscale/x86/swscale.c
>> +++ b/libswscale/x86/swscale.c
>> @@ -205,36 +205,19 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
>> filterSize,
>> yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither,
>> offset);
>> return;
>> }
>> -if (offset) {
>> -__asm__ volatile("movq (%0), %%xmm3\n\t"
>> - "movdqa%%xmm3, %%xmm4\n\t"
>> - "psrlq $24, %%xmm3\n\t"
>> - "psllq $40, %%xmm4\n\t"
>> - "por %%xmm4, %%xmm3\n\t"
>> - :: "r"(dither)
>> - );
>> -} else {
>> -__asm__ volatile("movq (%0), %%xmm3\n\t"
>> - :: "r"(dither)
>> - );
>> -}
>
>> -filterSize--;
>
> not sure i missed it but it seems this is lost in teh new code
Good catch. Fixed!
>> -__asm__ volatile(
>> -"pxor %%xmm0, %%xmm0\n\t"
>> -"punpcklbw %%xmm0, %%xmm3\n\t"
>> -"movd %0, %%xmm1\n\t"
>> -"punpcklwd %%xmm1, %%xmm1\n\t"
>> -"punpckldq %%xmm1, %%xmm1\n\t"
>> -"punpcklqdq %%xmm1, %%xmm1\n\t"
>> -"psllw $3, %%xmm1\n\t"
>> -"paddw %%xmm1, %%xmm3\n\t"
>> -"psraw $4, %%xmm3\n\t"
>> -::"m"(filterSize)
>> - );
>> -__asm__ volatile(
>> -"movdqa%%xmm3, %%xmm4\n\t"
>> -"movdqa%%xmm3, %%xmm7\n\t"
>> -"movl %3, %%ecx\n\t"
>> +#define MAIN_FUNCTION \
>> +"pxor %%xmm0, %%xmm0 \n\t" \
>> +"punpcklbw %%xmm0, %%xmm3 \n\t" \
>> +"movd %4, %%xmm1 \n\t" \
>> +"punpcklwd %%xmm1, %%xmm1 \n\t" \
>> +"punpckldq %%xmm1, %%xmm1 \n\t" \
>> +"punpcklqdq %%xmm1, %%xmm1 \n\t" \
>> +"psllw $3, %%xmm1 \n\t" \
>> +"paddw %%xmm1, %%xmm3 \n\t" \
>> +"psraw $4, %%xmm3 \n\t" \
>> +"movdqa %%xmm3, %%xmm4 \n\t" \
>> +"movdqa %%xmm3, %%xmm7 \n\t" \
>> +"movl %3, %%ecx \n\t" \
>> "mov %0, %%"REG_d" \n\t"\
>> "mov(%%"REG_d"), %%"REG_S" \n\t"\
>> ".p2align 4 \n\t" /* FIXME
>> Unroll? */\
>> @@ -252,20 +235,39 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
>> filterSize,
>> " jnz1b \n\t"\
>> "psraw $3, %%xmm3 \n\t"\
>> "psraw $3, %%xmm4 \n\t"\
>> -"packuswb %%xmm4, %%xmm3 \n\t"
>> -"movntdq %%xmm3, (%1, %%"REG_c")\n\t"
>> +"packuswb %%xmm4, %%xmm3 \n\t"\
>> +"movntdq %%xmm3, (%1, %%"REG_c")\n\t"\
>> "add $16, %%"REG_c" \n\t"\
>> "cmp %2, %%"REG_c" \n\t"\
>> -"movdqa%%xmm7, %%xmm3\n\t"
>> -"movdqa%%xmm7, %%xmm4\n\t"
>> +"movdqa %%xmm7, %%xmm3\n\t" \
>> +"movdqa %%xmm7, %%xmm4\n\t" \
>> "mov %0, %%"REG_d" \n\t"\
>> "mov(%%"REG_d"), %%"REG_S" \n\t"\
>> -"jb 1b \n\t"\
>> -:: "g" (filter),
>> - "r" (dest-offset), "g" ((x86_reg)(dstW+offset)), "m" (offset)
>> -: XMM_CLOBBERS("%xmm0" , "%xmm1" , "%xmm2" , "%xmm3" , "%xmm4" ,
>> "%xmm5" , "%xmm7" ,)
>> - "%"REG_d, "%"REG_S, "%"RE
[FFmpeg-devel] [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid compiler confusion
Hi,
FFmpeg failed to build in Debian on powerpc/ppc64el with the following
error:
libavfilter/deshake.h:51:24: warning: declaration does not declare anything
MotionVector vector; ///< Motion vector
^
libavfilter/vf_deshake.c: In function 'find_motion':
libavfilter/vf_deshake.c:297:20: error: expected identifier before
'__attribute__'
t->vector.x = x - deshake->rx;
^
Attached patch fixes this problem by renaming vector to vec.
Best regards,
Andreas
>From 4288c94547fff0cbe6a3065f529bc8d732f61308 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Thu, 18 Sep 2014 00:08:05 +0200
Subject: [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid
compiler confusion
The token 'vector' is a keyword in the Vector/SIMD Multimedia Extension data types and thus should not be used as a variable name.
This fixes building on powerpc/ppc64el.
Signed-off-by: Andreas Cadhalpun
---
libavfilter/deshake.h| 2 +-
libavfilter/vf_deshake.c | 50
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/libavfilter/deshake.h b/libavfilter/deshake.h
index 62e81c3..becd6c2 100644
--- a/libavfilter/deshake.h
+++ b/libavfilter/deshake.h
@@ -48,7 +48,7 @@ typedef struct {
} MotionVector;
typedef struct {
-MotionVector vector; ///< Motion vector
+MotionVector vec; ///< Motion vector
double angle; ///< Angle of rotation
double zoom; ///< Zoom percentage
} Transform;
diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index ccc263b..b5d5457 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -294,8 +294,8 @@ static void find_motion(DeshakeContext *deshake, uint8_t *src1, uint8_t *src2,
for (x = 0; x < deshake->rx * 2 + 1; x++) {
//av_log(NULL, AV_LOG_ERROR, "%5d ", deshake->counts[x][y]);
if (deshake->counts[x][y] > count_max_value) {
-t->vector.x = x - deshake->rx;
-t->vector.y = y - deshake->ry;
+t->vec.x = x - deshake->rx;
+t->vec.y = y - deshake->ry;
count_max_value = deshake->counts[x][y];
}
}
@@ -304,12 +304,12 @@ static void find_motion(DeshakeContext *deshake, uint8_t *src1, uint8_t *src2,
p_x = (center_x - width / 2.0);
p_y = (center_y - height / 2.0);
-t->vector.x += (cos(t->angle)-1)*p_x - sin(t->angle)*p_y;
-t->vector.y += sin(t->angle)*p_x + (cos(t->angle)-1)*p_y;
+t->vec.x += (cos(t->angle)-1)*p_x - sin(t->angle)*p_y;
+t->vec.y += sin(t->angle)*p_x + (cos(t->angle)-1)*p_y;
// Clamp max shift & rotation?
-t->vector.x = av_clipf(t->vector.x, -deshake->rx * 2, deshake->rx * 2);
-t->vector.y = av_clipf(t->vector.y, -deshake->ry * 2, deshake->ry * 2);
+t->vec.x = av_clipf(t->vec.x, -deshake->rx * 2, deshake->rx * 2);
+t->vec.y = av_clipf(t->vec.y, -deshake->ry * 2, deshake->ry * 2);
t->angle = av_clipf(t->angle, -0.1, 0.1);
//av_log(NULL, AV_LOG_ERROR, "%d x %d\n", avg->x, avg->y);
@@ -407,8 +407,8 @@ static int config_props(AVFilterLink *link)
DeshakeContext *deshake = link->dst->priv;
deshake->ref = NULL;
-deshake->last.vector.x = 0;
-deshake->last.vector.y = 0;
+deshake->last.vec.x = 0;
+deshake->last.vec.y = 0;
deshake->last.angle = 0;
deshake->last.zoom = 0;
@@ -476,57 +476,57 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
// Copy transform so we can output it later to compare to the smoothed value
-orig.vector.x = t.vector.x;
-orig.vector.y = t.vector.y;
+orig.vec.x = t.vec.x;
+orig.vec.y = t.vec.y;
orig.angle = t.angle;
orig.zoom = t.zoom;
// Generate a one-sided moving exponential average
-deshake->avg.vector.x = alpha * t.vector.x + (1.0 - alpha) * deshake->avg.vector.x;
-deshake->avg.vector.y = alpha * t.vector.y + (1.0 - alpha) * deshake->avg.vector.y;
+deshake->avg.vec.x = alpha * t.vec.x + (1.0 - alpha) * deshake->avg.vec.x;
+deshake->avg.vec.y = alpha * t.vec.y + (1.0 - alpha) * deshake->avg.vec.y;
deshake->avg.angle = alpha * t.angle + (1.0 - alpha) * deshake->avg.angle;
deshake->avg.zoom = alpha * t.zoom + (1.0 - alpha) * deshake->avg.zoom;
// Remove the average from the current motion to detect the motion that
// is not on purpose, just as jitter from bumping the camera
-t.vector.x -= deshake->avg.vector.x;
-t.vector.y -= deshake->avg.vector.y;
+t.vec.x -= deshake->avg.vec.x;
+t.vec.y -= deshake->avg.vec.y;
t.angle -= deshake->avg.angle;
t.zoom -= deshake->avg.zoom;
// Invert the motion to undo it
-t.vector.x *= -1;
-t.vector.y *= -1;
+t.vec.x *= -1;
+t.vec.y *= -1;
t.angle *= -1;
// Write statistics to file
if (deshake->fp) {
-snprintf(tmp, 256, "%f, %f, %f, %f, %f, %f, %f, %
Re: [FFmpeg-devel] [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid compiler confusion
Andreas Cadhalpun googlemail.com> writes: > FFmpeg failed to build in Debian on powerpc/ppc64el > with the following error: Out of curiosity: How can I reproduce this? I believe I tested on ppc64 Linux last week... In any case: No objections here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid compiler confusion
On 18.09.2014 00:33, Carl Eugen Hoyos wrote: Andreas Cadhalpun googlemail.com> writes: FFmpeg failed to build in Debian on powerpc/ppc64el with the following error: Out of curiosity: How can I reproduce this? I believe I tested on ppc64 Linux last week... If you have a Debian jessie/sid installation, just clone the Debian packaging repository [1], install the build-dependencies mentioned in debian/control, (apply the patch from debian/patches) and build the package: fakeroot debian/rules binary-arch Note that I only tested on a powerpc qemu emulation, but since the failure on Debian's ppc64el buildd [2] is identical, I assume it will be fixed there as well. In any case: No objections here, Carl Eugen OK. Best regards, Andreas 1: https://anonscm.debian.org/git/collab-maint/ffmpeg.git 2: https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=ppc64el&ver=7%3A2.4-1&stamp=1410840865 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Make swscale x86 ASM depend less on registers been preserved across blocks
On Wed, Sep 17, 2014 at 10:55:52PM +0200, Vitor Sessak wrote:
> On Wed, Sep 17, 2014 at 10:31 PM, Michael Niedermayer
> wrote:
> > On Wed, Sep 17, 2014 at 09:21:08PM +0200, Vitor Sessak wrote:
> >> Hi!
> >>
> >> I'm not sure we can count on registers been preserved across ASM
> >> blocks. Moreover, this causes problems with utils that instrument the
> >> code by inserting function calls between lines (like ThreadSanitizer).
> >>
> >> The attached patch fix one instance of this problem in swscale.
> >>
> >> -Vitor
> >
> >> swscale.c | 82
> >> +++---
> >> 1 file changed, 42 insertions(+), 40 deletions(-)
> >> 7fe9f7a0c1a7c1ed843b891f5f810fbd94a2e03f
> >> 0001-swscale-x86-do-not-expect-registers-to-be-preserved-.patch
> >> From f1c59628b2baeb9994bed8947c0a2c228610bf4f Mon Sep 17 00:00:00 2001
> >> From: Vitor Sessak
> >> Date: Wed, 17 Sep 2014 21:10:16 +0200
> >> Subject: [PATCH] swscale/x86: do not expect registers to be preserved
> >> across
> >> inline ASM blocks
> >>
> >> ---
> >> libswscale/x86/swscale.c | 82
> >> +---
> >> 1 file changed, 42 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> >> index c4c0e28..38157c8 100644
> >> --- a/libswscale/x86/swscale.c
> >> +++ b/libswscale/x86/swscale.c
> >> @@ -205,36 +205,19 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
> >> filterSize,
> >> yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither,
> >> offset);
> >> return;
> >> }
> >> -if (offset) {
> >> -__asm__ volatile("movq (%0), %%xmm3\n\t"
> >> - "movdqa%%xmm3, %%xmm4\n\t"
> >> - "psrlq $24, %%xmm3\n\t"
> >> - "psllq $40, %%xmm4\n\t"
> >> - "por %%xmm4, %%xmm3\n\t"
> >> - :: "r"(dither)
> >> - );
> >> -} else {
> >> -__asm__ volatile("movq (%0), %%xmm3\n\t"
> >> - :: "r"(dither)
> >> - );
> >> -}
> >
> >> -filterSize--;
> >
> > not sure i missed it but it seems this is lost in teh new code
>
> Good catch. Fixed!
>
> >> -__asm__ volatile(
> >> -"pxor %%xmm0, %%xmm0\n\t"
> >> -"punpcklbw %%xmm0, %%xmm3\n\t"
> >> -"movd %0, %%xmm1\n\t"
> >> -"punpcklwd %%xmm1, %%xmm1\n\t"
> >> -"punpckldq %%xmm1, %%xmm1\n\t"
> >> -"punpcklqdq %%xmm1, %%xmm1\n\t"
> >> -"psllw $3, %%xmm1\n\t"
> >> -"paddw %%xmm1, %%xmm3\n\t"
> >> -"psraw $4, %%xmm3\n\t"
> >> -::"m"(filterSize)
> >> - );
> >> -__asm__ volatile(
> >> -"movdqa%%xmm3, %%xmm4\n\t"
> >> -"movdqa%%xmm3, %%xmm7\n\t"
> >> -"movl %3, %%ecx\n\t"
> >> +#define MAIN_FUNCTION \
> >> +"pxor %%xmm0, %%xmm0 \n\t" \
> >> +"punpcklbw %%xmm0, %%xmm3 \n\t" \
> >> +"movd %4, %%xmm1 \n\t" \
> >> +"punpcklwd %%xmm1, %%xmm1 \n\t" \
> >> +"punpckldq %%xmm1, %%xmm1 \n\t" \
> >> +"punpcklqdq %%xmm1, %%xmm1 \n\t" \
> >> +"psllw $3, %%xmm1 \n\t" \
> >> +"paddw %%xmm1, %%xmm3 \n\t" \
> >> +"psraw $4, %%xmm3 \n\t" \
> >> +"movdqa %%xmm3, %%xmm4 \n\t" \
> >> +"movdqa %%xmm3, %%xmm7 \n\t" \
> >> +"movl %3, %%ecx \n\t" \
> >> "mov %0, %%"REG_d" \n\t"\
> >> "mov(%%"REG_d"), %%"REG_S" \n\t"\
> >> ".p2align 4 \n\t" /*
> >> FIXME Unroll? */\
> >> @@ -252,20 +235,39 @@ static void yuv2yuvX_sse3(const int16_t *filter, int
> >> filterSize,
> >> " jnz1b \n\t"\
> >> "psraw $3, %%xmm3 \n\t"\
> >> "psraw $3, %%xmm4 \n\t"\
> >> -"packuswb %%xmm4, %%xmm3 \n\t"
> >> -"movntdq %%xmm3, (%1, %%"REG_c")\n\t"
> >> +"packuswb %%xmm4, %%xmm3 \n\t"\
> >> +"movntdq %%xmm3, (%1, %%"REG_c")\n\t"\
> >> "add $16, %%"REG_c" \n\t"\
> >> "cmp %2, %%"REG_c" \n\t"\
> >> -"movdqa%%xmm7, %%xmm3\n\t"
> >> -"movdqa%%xmm7, %%xmm4\n\t"
> >> +"movdqa %%xmm7, %%xmm3\n\t" \
> >> +"movdqa %%xmm7, %%xmm4\n\t" \
> >> "mov %0, %%"REG_d" \n\t"\
> >> "mov(%%"REG_d"), %%"REG_S" \n\t"\
> >> -"jb
Re: [FFmpeg-devel] [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid compiler confusion
On Thu, Sep 18, 2014 at 12:16:42AM +0200, Andreas Cadhalpun wrote: > Hi, > > FFmpeg failed to build in Debian on powerpc/ppc64el with the > following error: > libavfilter/deshake.h:51:24: warning: declaration does not declare anything > MotionVector vector; ///< Motion vector > ^ > libavfilter/vf_deshake.c: In function 'find_motion': > libavfilter/vf_deshake.c:297:20: error: expected identifier before > '__attribute__' > t->vector.x = x - deshake->rx; > ^ > > Attached patch fixes this problem by renaming vector to vec. > > Best regards, > Andreas > deshake.h|2 +- > vf_deshake.c | 50 +- > 2 files changed, 26 insertions(+), 26 deletions(-) > fc1e8bc509d59d55b3cc68b37f78c749707195c0 > vf_deshake-rename-Transform.vector-to-Transform.vec-.patch > From 4288c94547fff0cbe6a3065f529bc8d732f61308 Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Thu, 18 Sep 2014 00:08:05 +0200 > Subject: [PATCH] vf_deshake: rename Transform.vector to Transform.vec to avoid > compiler confusion applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtpenc_chain: Set timebase
On Thu, Jul 24, 2014 at 12:14:14AM +0200, Michael Niedermayer wrote: > Avoid warning that its not set > > Signed-off-by: Michael Niedermayer > --- > libavformat/rtpenc_chain.c |2 ++ > 1 file changed, 2 insertions(+) a variant of this was applied by martin and merged by me [...] -- 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
Re: [FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
On Thu, Aug 28, 2014 at 12:14:48AM -0300, James Almer wrote: > On 27/08/14 11:53 PM, Wei Gao wrote: > > 2014-08-13 9:45 GMT+08:00 Timothy Gu : > > > >> On Aug 12, 2014 6:43 PM, "highgod0401" wrote: > >> > >>> Hi > >>> > >>> Warning is OK for me. > >> > >> Do you plan to change the API? > >> > > > > Hi > > > > Sorry for the late reply, could you tell me more details? How to change > > it? I will change it according your suggestion. > > > > Thanks > > Best regards > > It was more a question to know if there were any plans to change the API in > the short term. That way we'll know if the API should be considered not > stable, > and thus disabled on shared builds. > > Nonetheless, I'll take the chance to raise an issue: libavutil/opencl.h is > including "config.h", a header that's not installed, to check for > HAVE_CL_CL_H. > This is broken, meaning that nothing has been able to use the OpenCL API > outside > of the couple libavfilter filters you modified. > > I suggest using libavutil/avconfig.h instead, a generated and installed > header, > but there may be a better/cleaner way. CCing wei please fix the config.h include stuff also please decide if the API is experimental or not if its experimental it MUST be clearly shown to be in the configure help so that users know that they enable experimental API when specifying --enable-opencl If its not experimental then the API can only be changed in ways that maintain API & ABI compatibility. 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
[FFmpeg-devel] [PATCH] x86/me_cmp: combine sad functions into a single macro
No point in having the sad8 functions separate now that the loop is no longer unrolled. Signed-off-by: James Almer --- libavcodec/x86/me_cmp.asm | 221 +++--- 1 file changed, 93 insertions(+), 128 deletions(-) diff --git a/libavcodec/x86/me_cmp.asm b/libavcodec/x86/me_cmp.asm index ef591f5..b657642 100644 --- a/libavcodec/x86/me_cmp.asm +++ b/libavcodec/x86/me_cmp.asm @@ -473,43 +473,35 @@ HF_NOISE 16 ;--- ;int ff_sad_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int stride, int h); ;--- -INIT_MMX mmxext -cglobal sad8, 5, 5, 0, v, pix1, pix2, stride, h +;%1 = 8/16 +%macro SAD 1 +cglobal sad%1, 5, 5, 3, v, pix1, pix2, stride, h movu m2, [pix2q] movu m1, [pix2q+strideq] psadbwm2, [pix1q] psadbwm1, [pix1q+strideq] paddw m2, m1 -sub hd, 2 - -.loop: -leapix1q, [pix1q+strideq*2] -leapix2q, [pix2q+strideq*2] -movu m0, [pix2q] -movu m1, [pix2q+strideq] -psadbwm0, [pix1q] -psadbwm1, [pix1q+strideq] +%if %1 != mmsize +movu m0, [pix2q+8] +movu m1, [pix2q+strideq+8] +psadbwm0, [pix1q+8] +psadbwm1, [pix1q+strideq+8] paddw m2, m0 paddw m2, m1 +%endif sub hd, 2 -jne .loop - -movd eax, m2 -RET - -%macro SAD16 0 -cglobal sad16, 5, 5, 3, v, pix1, pix2, stride, h -pxor m2, m2 align 16 -.loop +.loop: +leapix1q, [pix1q+strideq*2] +leapix2q, [pix2q+strideq*2] movu m0, [pix2q] movu m1, [pix2q+strideq] psadbwm0, [pix1q] psadbwm1, [pix1q+strideq] paddw m2, m0 paddw m2, m1 -%if mmsize == 8 +%if %1 != mmsize movu m0, [pix2q+8] movu m1, [pix2q+strideq+8] psadbwm0, [pix1q+8] @@ -517,8 +509,6 @@ align 16 paddw m2, m0 paddw m2, m1 %endif -leapix1q, [pix1q+strideq*2] -leapix2q, [pix2q+strideq*2] sub hd, 2 jg .loop %if mmsize == 16 @@ -530,47 +520,47 @@ align 16 %endmacro INIT_MMX mmxext -SAD16 +SAD 8 +SAD 16 INIT_XMM sse2 -SAD16 +SAD 16 ;-- ;int ff_sad_x2_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int stride, int h); ;-- -INIT_MMX mmxext -cglobal sad8_x2, 5, 5, 0, v, pix1, pix2, stride, h +;%1 = 8/16 +%macro SAD_X2 1 +cglobal sad%1_x2, 5, 5, 5, v, pix1, pix2, stride, h movu m0, [pix2q] movu m2, [pix2q+strideq] +%if mmsize == 16 +movu m3, [pix2q+1] +movu m4, [pix2q+strideq+1] +pavgb m0, m3 +pavgb m2, m4 +%else pavgb m0, [pix2q+1] pavgb m2, [pix2q+strideq+1] +%endif psadbwm0, [pix1q] psadbwm2, [pix1q+strideq] paddw m0, m2 -sub hd, 2 - -.loop: -leapix1q, [pix1q+2*strideq] -leapix2q, [pix2q+2*strideq] -movu m1, [pix2q] -movu m2, [pix2q+strideq] -pavgb m1, [pix2q+1] -pavgb m2, [pix2q+strideq+1] -psadbwm1, [pix1q] -psadbwm2, [pix1q+strideq] +%if %1 != mmsize +movu m1, [pix2q+8] +movu m2, [pix2q+strideq+8] +pavgb m1, [pix2q+9] +pavgb m2, [pix2q+strideq+9] +psadbwm1, [pix1q+8] +psadbwm2, [pix1q+strideq+8] paddw m0, m1 paddw m0, m2 +%endif sub hd, 2 -jne .loop - -movd eax, m0 -RET - -%macro SAD16_X2 0 -cglobal sad16_x2, 5, 5, 5, v, pix1, pix2, stride, h -pxor m0, m0 align 16 .loop: +leapix1q, [pix1q+2*strideq] +leapix2q, [pix2q+2*strideq] movu m1, [pix2q] movu m2, [pix2q+strideq] %if mmsize == 16 @@ -586,7 +576,7 @@ align 16 psadbwm2, [pix1q+strideq] paddw m0, m1 paddw m0, m2 -%if mmsize == 8 +%if %1 != mmsize movu m1, [pix2q+8] movu m2, [pix2q+strideq+8] pavgb m1, [pix2q+9] @@ -596,8 +586,6 @@ align 16 paddw m0, m1 paddw m0, m2 %endif -leapix1q, [pix1q+2*strideq] -leapix2q, [pix2q+2*strideq] sub hd, 2 jg .loop %if mmsize == 16 @@ -609,56 +597,45 @@ align 16 %endmacro INIT_MMX mmxext -SAD16_X2 +SAD_X2 8 +SAD_X2 16 INIT_XMM sse2 -SAD16_X2 +SAD_X2 16 ;-- ;int ff_sad_y2_(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, int stride, int h); ;-- -INIT_MMX mmxext -cglobal sad8_y2, 5, 5, 0, v, pix1, pix2, stride, h +;%1 = 8/16 +%macro SAD_Y2 1 +cglobal sad%1_y2, 5, 5, 4, v, pix1, pix2,
Re: [FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
On Wed, Sep 17, 2014 at 12:59 PM, Michael Niedermayer wrote: > On Wed, Sep 17, 2014 at 11:33:32AM -0700, Daniel Verkamp wrote: >> Hi FFmpeg web folks, >> >> When visiting http://fate.ffmpeg.org/ using a browser that enforces >> CORS[1], loading the FontAwesome icon font causes this error: >> >> Font from origin 'https://ffmpeg.org' has been blocked from loading >> by Cross-Origin Resource Sharing policy: No >> 'Access-Control-Allow-Origin' header is present on the requested >> resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed >> access. [...] > > as you seem to know this / have researched it already > can you post what i need to add to httpd.conf to make this work ? Something like this (untested) should work: Header set Access-Control-Allow-Origin "*" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: combine sad functions into a single macro
On Wed, Sep 17, 2014 at 10:15:30PM -0300, James Almer wrote: > No point in having the sad8 functions separate now that the loop is no > longer unrolled. > > Signed-off-by: James Almer > --- > libavcodec/x86/me_cmp.asm | 221 > +++--- > 1 file changed, 93 insertions(+), 128 deletions(-) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/me_cmp: combine sad functions into a single macro
On 17/09/14 11:44 PM, Michael Niedermayer wrote: > On Wed, Sep 17, 2014 at 10:15:30PM -0300, James Almer wrote: >> No point in having the sad8 functions separate now that the loop is no >> longer unrolled. >> >> Signed-off-by: James Almer >> --- >> libavcodec/x86/me_cmp.asm | 221 >> +++--- >> 1 file changed, 93 insertions(+), 128 deletions(-) > > should be ok Pushed. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] archive ffmpeg all objs into one lib, feasible?
I think you misunderstand what I mean. Of course I know how each lib works. I want to know, if I 'ar' the libavformat.a libavcodec.a into one libffmpeg.a, how can I retain their function symbols in the new libffmpeg.a. 2014-09-18 4:21 GMT+08:00 Marcus Johnson : > No, it won't work because the libraries are for different purposes. > > as per your example, 4xm in the libavcodec directory is for decoding the > file, it implements the actual algorithm. 4xm in the libavformat directory > is for demuxing the codec from the 4xm container, you need both for it to > work. > > On Wed, Sep 17, 2014 at 10:37 AM, Lynn Yu wrote: > > > I've build ffmpeg static libraries, and all necessary objs (*.o) > generated > > in their source directory. > > > > I use 'ar' to archive all these objs into one libffmpeg.a. > > > > command: *ar rc libffmpeg.a *.o* > > > > I notice that, there are some objs have same name in different dirs, for > > example *libavformat/4xm.o and libavcodec/4xm.o*. > > > > by 'nm libffmpeg.a', it seems both objs are there? > > > > 'man ar' I find that, if obj with same name and Exactly with same > function > > symbols, latter one will be replaced ,right? > > > > by this 'ar' way, will libffmpeg.a work correctly? because there so many > > symbols I can't test every one. > > > > thanks for help! > > ___ > > 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 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
On Wed, Sep 17, 2014 at 07:16:30PM -0700, Daniel Verkamp wrote: > On Wed, Sep 17, 2014 at 12:59 PM, Michael Niedermayer > wrote: > > On Wed, Sep 17, 2014 at 11:33:32AM -0700, Daniel Verkamp wrote: > >> Hi FFmpeg web folks, > >> > >> When visiting http://fate.ffmpeg.org/ using a browser that enforces > >> CORS[1], loading the FontAwesome icon font causes this error: > >> > >> Font from origin 'https://ffmpeg.org' has been blocked from loading > >> by Cross-Origin Resource Sharing policy: No > >> 'Access-Control-Allow-Origin' header is present on the requested > >> resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed > >> access. > [...] > > > > as you seem to know this / have researched it already > > can you post what i need to add to httpd.conf to make this work ? > > Something like this (untested) should work: > > > Header set Access-Control-Allow-Origin "*" > added seems to work thx [...] -- 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] archive ffmpeg all objs into one lib, feasible?
On Sep 17, 2014 7:58 PM, "Lynn Yu" wrote: > > I think you misunderstand what I mean. Of course I know how each lib works. > I want to know, if I 'ar' the libavformat.a libavcodec.a into one > libffmpeg.a, how can I retain their function symbols in the new libffmpeg.a. There won't be any symbol clash, because if there is a clash, statically linking an application (e.g. ffmpeg) that uses all the libraries won't work. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Cross-origin resource error on fate.ffmpeg.org
On Sep 17, 2014 8:02 PM, "Michael Niedermayer" wrote: > > On Wed, Sep 17, 2014 at 07:16:30PM -0700, Daniel Verkamp wrote: > > On Wed, Sep 17, 2014 at 12:59 PM, Michael Niedermayer wrote: > > > On Wed, Sep 17, 2014 at 11:33:32AM -0700, Daniel Verkamp wrote: > > >> Hi FFmpeg web folks, > > >> > > >> When visiting http://fate.ffmpeg.org/ using a browser that enforces > > >> CORS[1], loading the FontAwesome icon font causes this error: > > >> > > >> Font from origin 'https://ffmpeg.org' has been blocked from loading > > >> by Cross-Origin Resource Sharing policy: No > > >> 'Access-Control-Allow-Origin' header is present on the requested > > >> resource. Origin 'http://fate.ffmpeg.org' is therefore not allowed > > >> access. > > [...] > > > > > > as you seem to know this / have researched it already > > > can you post what i need to add to httpd.conf to make this work ? > > > > Something like this (untested) should work: > > > > > > > Header set Access-Control-Allow-Origin "*" > > I think only allowing *.ffmpeg.org is safer from a security PoV. I am already aware of this problem when I wrote the patch that changed the behavior. See http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2014-July/160502.html Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] archive ffmpeg all objs into one lib, feasible?
Yes, I think you're right. Thanks for help! 2014-09-18 11:46 GMT+08:00 Timothy Gu : > On Sep 17, 2014 7:58 PM, "Lynn Yu" wrote: > > > > I think you misunderstand what I mean. Of course I know how each lib > works. > > I want to know, if I 'ar' the libavformat.a libavcodec.a into one > > libffmpeg.a, how can I retain their function symbols in the new > libffmpeg.a. > > There won't be any symbol clash, because if there is a clash, statically > linking an application (e.g. ffmpeg) that uses all the libraries won't > work. > > Timothy > ___ > 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
[FFmpeg-devel] [PATCH]: libavcodec/webp
Hi, the webp lossless doc was unclear regarding palette index falling out of range. See issue #206 [1] for the bug report. The solution retained was to treat out-of-range index as color 0x, so we could keep the speed-up in libwebp (we use fake extra entries in the cmap to handle out-of-bound values without the extra branch). The doc was clarified (along with few other loose ends) in patch #71605 [2] Attached is the fix for ffmpeg's webp decoder to treat out-of-bound index as transparent-black instead of reporting an error. note: the bug entry has a test webp file to exercise this feature/patch, in case. thanks! /skal [1] https://code.google.com/p/webp/issues/detail?id=206 [2] https://gerrit.chromium.org/gerrit/#/c/71605/ 0001-libavcodec-webp-treat-out-of-bound-palette-index-as-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
