Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Sat, Aug 23, 2014 at 05:51:31AM +0700, Muhammad Faiz wrote: [...] > Update patch to the latest master branch. > > Thank's. > > Muhammad Faiz > > --- > doc/filters.texi | 26 > libavfilter/avf_showcqt.c | 102 > -- > libavfilter/version.h | 2 +- > 3 files changed, 98 insertions(+), 32 deletions(-) > Thanks, applied. Next time please send a git-format-patch (git commit ... && git format-patch -1, or use git send-email) instead, so it saves the committer the time to copy/paste the commit message and author. [...] -- Clément B. pgpnMiUxLoEFx.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] avutil/pixelutils: faster pixelutils_sad_[au]_16x16
On Sun, Aug 17, 2014 at 01:51:13PM +0200, Michael Niedermayer wrote: > On Thu, Aug 14, 2014 at 11:05:13PM +0200, Clément Bœsch wrote: > > ~560 → ~500 decicycles > > > > This is following the comments from Michael in > > https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160599.html > > > > Using 2 registers for accumulator didn't help. On the other hand, > > some re-ordering between the movs and psadbw allowed going ~538 to ~500. > > --- > > libavutil/x86/pixelutils.asm | 14 +- > > 1 file changed, 9 insertions(+), 5 deletions(-) > > should be ok > applied, thanks -- Clément B. pgpaYzMElEx_1.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Sat, Aug 23, 2014 at 3:09 PM, Clément Bœsch wrote: > Next time please send a git-format-patch (git commit ... && git > format-patch -1, or use git send-email) instead, so it saves the committer > the time to copy/paste the commit message and author. > > Thank's for the suggestion Muhammad Faiz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On 17.08.2014 00:49, Andreas Cadhalpun wrote: I have now sent the pkg-config patches to the BTS [1]. I have found a simpler way to make it possible to link packages not using pkg-config against FFmpeg in Debian: The lib*-ffmpeg-dev packages now install symbolic links from the standard lib*.so library names to the suffixed ones. This makes it possible to use the normal linker flags, e.g. '-lavcodec', to link against the FFmpeg libraries with '-ffmpeg' suffix. Therefore I have closed the bugs with the pkg-config patches [1]. Thus, once FFmpeg is through NEW, most packages can just switch the build-dependencies to be build against FFmpeg. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/tiff: add support for LZMA compression
On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote: > Derived from deflate code. > Requires liblzma. > > Signed-off-by: James Almer how can this be tested ? do you have a testcase / sample ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- 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] lavc/tiff: add support for LZMA compression
On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer wrote: > On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote: >> Derived from deflate code. >> Requires liblzma. >> >> Signed-off-by: James Almer > > how can this be tested ? > do you have a testcase / sample ? > This image should be lzma compressed: https://www.flameeyes.eu/tmp/imgsrc001-lzma.tiff - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Do not show an unreadable error code if mov header parsing fails
Hi!
I don't think showing "-1094995529" or similar makes much sense.
The calling application can still decide to show the error
string (as ffmpeg does).
Please comment, Carl Eugen
diff --git a/libavformat/mov.c b/libavformat/mov.c
index b3eb287..ae48c02 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3562,7 +3562,7 @@ static int mov_read_header(AVFormatContext *s)
if (mov->moov_retry)
avio_seek(pb, 0, SEEK_SET);
if ((err = mov_read_default(mov, pb, atom)) < 0) {
-av_log(s, AV_LOG_ERROR, "error reading header: %d\n", err);
+av_log(s, AV_LOG_ERROR, "error reading header\n");
mov_read_close(s);
return err;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/style: Add a comment in the generated css file for the doc in the main repo
Hi, On 25.07.2014 11:25, db0 company wrote: Since the style in the release is the one generated from the website, it has to be the same license. If we add a license to the css/less, then it's better to have the same on the whole website. I'll add one. Did you choose a license already? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
Hi, On 20.07.2014 23:23, Timothy Gu wrote: texi2html is deprecated by upstream in favor of makeinfo/texi2any. See: - https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html - https://wiki.debian.org/Texi2htmlTransition - https://lists.debian.org/debian-devel/2013/05/msg01516.html This is actually two separate changes. But as makeinfo and texi2html adopt 2 (very) different init file syntaxes, it is easier to do the two transitions at once. Based on a patch by Andreas Cadhalpun . Fixes Trac ticket #3232. Signed-off-by: Timothy Gu --- Is there a reason, why this patch hasn't been applied? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
As far as I can see, the only reason those functions are SSE4 is because of the pextrw needed for the following block widths: - 2, used only by chroma; - 6, used by chroma and indirectly by luma; - 12, used by both. The better solution would be to convert all chroma handling to NV12, but it is vastly simpler to modify the above cases to not use pextrw. This is done in 2 steps: - Fix width of 12 to do 8+4 instead of 6+6; - Modify the store macros for width 2 and 6 by passing data through a GPR (alas at the cost for some functions of a supplementary GPR). Christophe Gisquet (2): x86: hevc_mc: split differently calls x86: hevc_mc: convert to ssse3 libavcodec/x86/hevc_mc.asm| 63 +++-- libavcodec/x86/hevcdsp.h | 48 ++-- libavcodec/x86/hevcdsp_init.c | 561 ++ 3 files changed, 362 insertions(+), 310 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] x86: hevc_mc: split differently calls
In some cases, 2 or 3 calls are performed to functions for unusual
widths. Instead, perform 2 calls for different widths to split the
workload.
The 8+16 and 4+8 widths for respectively 8 and more than 8 bits can't
be processed that way without modifications: some calls use unaligned
buffers, and having branches to handle this was resulting in no
micro-benchmark benefit.
For block_w == 12 (around 1% of the pixels of the sequence):
Before:
12758 decicycles in epel_uni, 4093 runs, 3 skips
19389 decicycles in qpel_uni, 8187 runs, 5 skips
22699 decicycles in epel_bi, 32743 runs, 25 skips
34736 decicycles in qpel_bi, 32733 runs, 35 skips
After:
11929 decicycles in epel_uni, 4096 runs, 0 skips
18131 decicycles in qpel_uni, 8184 runs, 8 skips
20065 decicycles in epel_bi, 32750 runs, 18 skips
31458 decicycles in qpel_bi, 32753 runs, 15 skips
---
libavcodec/x86/hevcdsp_init.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index 3b7cc51..6bcced6 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -123,6 +123,45 @@ void
ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *_dst, ptrdiff_t dst
mc_rep_uni_func(name, bitd, step, W, opt);\
mc_rep_bi_func(name, bitd, step, W, opt)
+#define mc_rep_func2(name, bitd, step1, step2, W, opt) \
+void ff_hevc_put_hevc_##name##W##_##bitd##_##opt(int16_t *dst,
\
+ uint8_t *src, ptrdiff_t
_srcstride, int height,\
+ intptr_t mx, intptr_t my, int
width) \
+{
\
+ff_hevc_put_hevc_##name##step1##_##bitd##_##opt(dst, src, _srcstride,
height, mx, my, width); \
+ff_hevc_put_hevc_##name##step2##_##bitd##_##opt(dst + step1, src + (step1
* ((bitd + 7) / 8)), \
+_srcstride, height, mx,
my, width); \
+}
+#define mc_rep_uni_func2(name, bitd, step1, step2, W, opt) \
+void ff_hevc_put_hevc_uni_##name##W##_##bitd##_##opt(uint8_t *dst, ptrdiff_t
dststride, \
+ uint8_t *src, ptrdiff_t
_srcstride, int height,\
+ intptr_t mx, intptr_t my,
int width) \
+{
\
+ff_hevc_put_hevc_uni_##name##step1##_##bitd##_##opt(dst, dststride, src,
_srcstride, height, mx, my, width);\
+ff_hevc_put_hevc_uni_##name##step2##_##bitd##_##opt(dst + (step1 * ((bitd
+ 7) / 8)), dststride,\
+src + (step1 * ((bitd
+ 7) / 8)), _srcstride, \
+height, mx, my,
width); \
+}
+#define mc_rep_bi_func2(name, bitd, step1, step2, W, opt) \
+void ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *dst, ptrdiff_t
dststride, uint8_t *src,\
+ptrdiff_t _srcstride,
int16_t* src2,\
+int height, intptr_t mx,
intptr_t my, int width)\
+{
\
+ff_hevc_put_hevc_bi_##name##step1##_##bitd##_##opt(dst, dststride, src,
_srcstride, src2, height, mx, my, width);\
+ff_hevc_put_hevc_bi_##name##step2##_##bitd##_##opt(dst + (step1 * ((bitd +
7) / 8)), dststride, \
+ src + (step1 * ((bitd +
7) / 8)), _srcstride,\
+ src2 + step1, height,
mx, my, width);\
+}
+
+#define mc_rep_funcs(name, bitd, step, W, opt)\
+mc_rep_func(name, bitd, step, W, opt);\
+mc_rep_uni_func(name, bitd, step, W, opt);\
+mc_rep_bi_func(name, bitd, step, W, opt)
+
+#define mc_rep_funcs2(name, bitd, step1, step2, W, opt) \
+mc_rep_func2(name, bitd, step1, step2, W, opt); \
+mc_rep_uni_func2(name, bitd, step1, step2, W, opt); \
+mc_rep_bi_func2(name, bitd, step1, step2, W, opt)
#if ARCH_X86_64 && HAVE_SSE4_EXTERNAL
@@ -180,7 +219,7 @@ mc_rep_funcs(epel_hv, 8, 8, 48, sse4);
mc_rep_funcs(epel_hv, 8, 8, 32, sse4);
mc_rep_funcs(epel_hv, 8, 8, 24, sse4);
mc_rep_funcs(epel_hv, 8, 8, 16, sse4);
-mc_rep_funcs(epel_hv, 8, 4, 12, sse4);
+mc_rep_funcs2(epel_hv,8, 8, 4, 12, sse4);
mc
[FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
The only sse4 instruction is pextrw, which is used on rather minor functions for small blocks. Therefore use whichever GPR is available to extract the output word. Before (sse4), for block_w == 6: 4627 decicycles in epel_uni, 16377 runs, 7 skips 7422 decicycles in epel_bi, 65501 runs, 35 skips After: 4649 decicycles in epel_uni, 16371 runs, 13 skips 7432 decicycles in epel_bi, 65505 runs, 31 skips --- libavcodec/x86/hevc_mc.asm| 63 +++-- libavcodec/x86/hevcdsp.h | 48 ++-- libavcodec/x86/hevcdsp_init.c | 522 +- 3 files changed, 323 insertions(+), 310 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index e2236ec..eb61b18 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -52,9 +52,9 @@ hevc_epel_filters_%4_%1 times %2 d%3 -2, 58 -EPEL_TABLE 8, 8, b, sse4 -EPEL_TABLE 10, 4, w, sse4 -EPEL_TABLE 12, 4, w, sse4 +EPEL_TABLE 8, 8, b, ssse3 +EPEL_TABLE 10, 4, w, ssse3 +EPEL_TABLE 12, 4, w, ssse3 %macro QPEL_TABLE 4 hevc_qpel_filters_%4_%1 times %2 d%3 -1, 4 @@ -71,13 +71,13 @@ hevc_qpel_filters_%4_%1 times %2 d%3 -1, 4 times %2 d%3 4, -1 %endmacro -QPEL_TABLE 8, 8, b, sse4 -QPEL_TABLE 10, 4, w, sse4 -QPEL_TABLE 12, 4, w, sse4 +QPEL_TABLE 8, 8, b, ssse3 +QPEL_TABLE 10, 4, w, ssse3 +QPEL_TABLE 12, 4, w, ssse3 %define MAX_PB_SIZE 64 -%define hevc_qpel_filters_sse4_14 hevc_qpel_filters_sse4_10 +%define hevc_qpel_filters_ssse3_14 hevc_qpel_filters_ssse3_10 %if ARCH_X86_64 @@ -121,9 +121,9 @@ QPEL_TABLE 12, 4, w, sse4 %macro EPEL_FILTER 2-4; bit depth, filter index %ifdef PIC -lea rfilterq, [hevc_epel_filters_sse4_%1] +lea rfilterq, [hevc_epel_filters_ssse3_%1] %else -%define rfilterq hevc_epel_filters_sse4_%1 +%define rfilterq hevc_epel_filters_ssse3_%1 %endif sub %2q, 1 shl %2q, 5 ; multiply by 32 @@ -138,9 +138,9 @@ QPEL_TABLE 12, 4, w, sse4 %macro EPEL_HV_FILTER 1 %ifdef PIC -lea rfilterq, [hevc_epel_filters_sse4_%1] +lea rfilterq, [hevc_epel_filters_ssse3_%1] %else -%define rfilterq hevc_epel_filters_sse4_%1 +%define rfilterq hevc_epel_filters_ssse3_%1 %endif sub mxq, 1 sub myq, 1 @@ -151,9 +151,9 @@ QPEL_TABLE 12, 4, w, sse4 lea r3srcq, [srcstrideq*3] %ifdef PIC -lea rfilterq, [hevc_epel_filters_sse4_10] +lea rfilterq, [hevc_epel_filters_ssse3_10] %else -%define rfilterq hevc_epel_filters_sse4_10 +%define rfilterq hevc_epel_filters_ssse3_10 %endif movdqa m12, [rfilterq + myq]; get 2 first values of filters movdqa m13, [rfilterq + myq+16] ; get 2 last values of filters @@ -161,9 +161,9 @@ QPEL_TABLE 12, 4, w, sse4 %macro QPEL_FILTER 2 %ifdef PIC -lea rfilterq, [hevc_qpel_filters_sse4_%1] +lea rfilterq, [hevc_qpel_filters_ssse3_%1] %else -%define rfilterq hevc_qpel_filters_sse4_%1 +%define rfilterq hevc_qpel_filters_ssse3_%1 %endif lea %2q, [%2q*8-8] movdqa m12, [rfilterq + %2q*8] ; get 4 first values of filters @@ -357,14 +357,25 @@ QPEL_TABLE 12, 4, w, sse4 %endmacro %macro PEL_8STORE2 3 +%if cpuflag(sse4) pextrw [%1], %2, 0 +%else +movdrfilterd, %2 +mov [%1], rfilterw +%endif %endmacro %macro PEL_8STORE4 3 movd[%1], %2 %endmacro %macro PEL_8STORE6 3 movd[%1], %2 +%if cpuflag(sse4) pextrw[%1+4], %2, 2 +%else +psrldq%2, 4 +movdrfilterd, %2 +mov [%1+4], rfilterw +%endif %endmacro %macro PEL_8STORE8 3 movq [%1], %2 @@ -426,7 +437,7 @@ QPEL_TABLE 12, 4, w, sse4 %endmacro %macro QPEL_SET_POINTER 2 -lea rfilterq, [hevc_qpel_filters_sse4_%1] +lea rfilterq, [hevc_qpel_filters_ssse3_%1] lea %2q, [rfilterq + 8*%2q] %endmacro @@ -535,7 +546,6 @@ QPEL_TABLE 12, 4, w, sse4 %endif %endmacro -INIT_XMM sse4; adds ff_ and _sse4 to function name ; ** ; void put_hevc_mc_pixels(int16_t *dst, ptrdiff_t dststride, ; uint8_t *_src, ptrdiff_t _srcstride, @@ -543,7 +553,7 @@ INIT_XMM sse4; adds ff_ and _sse4 to functio ; ** %macro HEVC_PUT_HEVC_PEL_PIXELS 2 -cglobal hevc_put_hevc_pel_pixels%1_%2, 4, 4, 3, dst, src, srcstride,height +cglobal hevc_put_hevc_pel_pixels%1_%2, 4, 5, 3, dst, src, srcstride, height, rfilter pxor m2, m2 .loop SIMPLE_LOAD %1, %2, srcq, m0 @@ -552,7 +562,7 @@ cglobal hevc_put_hevc_pel_pixels%1_%2, 4, 4, 3, dst, src, srcstride,height LOOP_END dst, src, srcstride RET
Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.
On Fri, Aug 22, 2014 at 07:47:09AM +0200, Reimar Döffinger wrote: > On 22.08.2014, at 07:36, Reimar Döffinger wrote: > > On 22.08.2014, at 04:06, Michael Niedermayer wrote: > >> On Sat, Aug 16, 2014 at 02:43:46PM +0200, Reimar Döffinger wrote: > >>> On Wed, Aug 13, 2014 at 01:57:56PM +0200, Michael Niedermayer wrote: > On Mon, Aug 11, 2014 at 09:17:18PM +0200, Reimar Döffinger wrote: > > Unfortunately this was not explicitly documented and thus > > might be very risky. > > yes > > maybe a AV_DICT_FREE_ARGS_ON_ERROR could be used, but its not as > convenient as getting the behavior by default > >>> > >>> That would add a lot of clutter and make it more inconvenient to use > >>> and likely to be forgotten. > >>> I also honestly see no real use-case for not setting it. > >>> One way to solve this would be to deprecate AV_DICT_DONT_STRDUP_KEY/ > >>> AV_DICT_DONT_STRDUP_VAL, warning that they fail to free on error > >>> and then add new values, e.g. AV_DICT_OWN_KEY (better suggestions?) > >>> with the new behaviour. > >>> Will still be a bit of a pain to replace all uses in FFmpeg, but > >>> manageable. > >>> What do you think? Better suggestions? > >> > >> i guess its either to apply the patch or not, i dont see a better > >> solution. renaming and deprecating options is certainly a bigger mess > >> and doesnt avoid the problem > > > > Given how fixing all uses in FFmpeg would be a bigger mess IMHO I'd favour > > applying it, if necessary with the ABI bump as excuse. > > If you agree apply it (or wait for me to do it this evening at earliest). > > Note I found only one use outside FFmpeg, in VLC's avcommon.h, and it does > not check return value, so it would actually be fixed by this change, too. Pushed, with some minor refinements like bumping minor in case someone really needs to test for it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
For 10bits and 12bits, they should stay sse4 as well because of packusdw. You
need some instructions to convert it to ssse3 see below
static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
{
a = _mm_slli_epi32 (a, 16);
a = _mm_srai_epi32 (a, 16);
b = _mm_slli_epi32 (b, 16);
b = _mm_srai_epi32 (b, 16);
a = _mm_packs_epi32 (a, b);
return a;
}
Mickaël
Le 23 août 2014 à 15:22, Christophe Gisquet a
écrit :
> As far as I can see, the only reason those functions are SSE4 is because
> of the pextrw needed for the following block widths:
> - 2, used only by chroma;
> - 6, used by chroma and indirectly by luma;
> - 12, used by both.
> The better solution would be to convert all chroma handling to NV12, but
> it is vastly simpler to modify the above cases to not use pextrw.
>
> This is done in 2 steps:
> - Fix width of 12 to do 8+4 instead of 6+6;
> - Modify the store macros for width 2 and 6 by passing data through
> a GPR (alas at the cost for some functions of a supplementary GPR).
>
> Christophe Gisquet (2):
> x86: hevc_mc: split differently calls
> x86: hevc_mc: convert to ssse3
>
> libavcodec/x86/hevc_mc.asm| 63 +++--
> libavcodec/x86/hevcdsp.h | 48 ++--
> libavcodec/x86/hevcdsp_init.c | 561 ++
> 3 files changed, 362 insertions(+), 310 deletions(-)
>
> --
> 1.9.2.msysgit.0
>
> ___
> 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 0/2] x86: hevc_mc: port to SSSE3
On 23/08/14 11:07 AM, Mickaël Raulet wrote:
> For 10bits and 12bits, they should stay sse4 as well because of packusdw. You
> need some instructions to convert it to ssse3 see below
>
>
> static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
> {
> a = _mm_slli_epi32 (a, 16);
> a = _mm_srai_epi32 (a, 16);
> b = _mm_slli_epi32 (b, 16);
> b = _mm_srai_epi32 (b, 16);
> a = _mm_packs_epi32 (a, b);
> return a;
> }
There's a PACK macro in lavfi/x86/yasm-16.asm that does this without intrinsics.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
On 23/08/14 10:22 AM, Christophe Gisquet wrote: > The only sse4 instruction is pextrw, which is used on rather minor > functions for small blocks. Therefore use whichever GPR is available > to extract the output word. > > Before (sse4), for block_w == 6: > 4627 decicycles in epel_uni, 16377 runs, 7 skips > 7422 decicycles in epel_bi, 65501 runs, 35 skips > > After: > 4649 decicycles in epel_uni, 16371 runs, 13 skips > 7432 decicycles in epel_bi, 65505 runs, 31 skips > --- > libavcodec/x86/hevc_mc.asm| 63 +++-- > libavcodec/x86/hevcdsp.h | 48 ++-- > libavcodec/x86/hevcdsp_init.c | 522 > +- > 3 files changed, 323 insertions(+), 310 deletions(-) > > diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm > index e2236ec..eb61b18 100644 > --- a/libavcodec/x86/hevc_mc.asm > +++ b/libavcodec/x86/hevc_mc.asm > @@ -52,9 +52,9 @@ hevc_epel_filters_%4_%1 times %2 d%3 -2, 58 > > > > -EPEL_TABLE 8, 8, b, sse4 > -EPEL_TABLE 10, 4, w, sse4 > -EPEL_TABLE 12, 4, w, sse4 > +EPEL_TABLE 8, 8, b, ssse3 > +EPEL_TABLE 10, 4, w, ssse3 > +EPEL_TABLE 12, 4, w, ssse3 > > %macro QPEL_TABLE 4 > hevc_qpel_filters_%4_%1 times %2 d%3 -1, 4 > @@ -71,13 +71,13 @@ hevc_qpel_filters_%4_%1 times %2 d%3 -1, 4 > times %2 d%3 4, -1 > %endmacro > > -QPEL_TABLE 8, 8, b, sse4 > -QPEL_TABLE 10, 4, w, sse4 > -QPEL_TABLE 12, 4, w, sse4 > +QPEL_TABLE 8, 8, b, ssse3 > +QPEL_TABLE 10, 4, w, ssse3 > +QPEL_TABLE 12, 4, w, ssse3 Do these need to be duplicated? You could just remove the suffix and let every version of the function use the same tables. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
On Aug 23, 2014 7:47 AM, "James Almer" wrote:
>
> On 23/08/14 11:07 AM, Mickaël Raulet wrote:
> > For 10bits and 12bits, they should stay sse4 as well because of
packusdw. You need some instructions to convert it to ssse3 see below
> >
> >
> > static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
> > {
> > a = _mm_slli_epi32 (a, 16);
> > a = _mm_srai_epi32 (a, 16);
> > b = _mm_slli_epi32 (b, 16);
> > b = _mm_srai_epi32 (b, 16);
> > a = _mm_packs_epi32 (a, b);
> > return a;
> > }
>
> There's a PACK macro in lavfi/x86/yasm-16.asm that does this without
intrinsics.
You meant yadif-16, right?
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/tiff: add support for LZMA compression
On 23/08/14 8:37 AM, Hendrik Leppkes wrote: > On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer wrote: >> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote: >>> Derived from deflate code. >>> Requires liblzma. >>> >>> Signed-off-by: James Almer >> >> how can this be tested ? >> do you have a testcase / sample ? >> > > This image should be lzma compressed: > https://www.flameeyes.eu/tmp/imgsrc001-lzma.tiff > > - Hendrik I get an assertion failure "width <= bytes_per_row" from this file in tiff_unpack_strip(), before the lzma code even comes to play. libtiff seems to be able to handle it, though, so could open a ticket in track after this gets committed (Without this patch the decoder just aborts as soon as it finds it's lzma). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
On 23/08/14 11:55 AM, Timothy Gu wrote:
> On Aug 23, 2014 7:47 AM, "James Almer" wrote:
>>
>> On 23/08/14 11:07 AM, Mickaël Raulet wrote:
>>> For 10bits and 12bits, they should stay sse4 as well because of
> packusdw. You need some instructions to convert it to ssse3 see below
>>>
>>>
>>> static av_always_inline __m128i _MM_PACKUS_EPI32( __m128i a, __m128i b )
>>> {
>>> a = _mm_slli_epi32 (a, 16);
>>> a = _mm_srai_epi32 (a, 16);
>>> b = _mm_slli_epi32 (b, 16);
>>> b = _mm_srai_epi32 (b, 16);
>>> a = _mm_packs_epi32 (a, b);
>>> return a;
>>> }
>>
>> There's a PACK macro in lavfi/x86/yasm-16.asm that does this without
> intrinsics.
>
> You meant yadif-16, right?
>
> Timothy
Oops, yes i meant that :P
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
Hi, 2014-08-23 16:52 GMT+02:00 James Almer : >> -QPEL_TABLE 8, 8, b, sse4 >> -QPEL_TABLE 10, 4, w, sse4 >> -QPEL_TABLE 12, 4, w, sse4 >> +QPEL_TABLE 8, 8, b, ssse3 >> +QPEL_TABLE 10, 4, w, ssse3 >> +QPEL_TABLE 12, 4, w, ssse3 > > Do these need to be duplicated? You could just remove the suffix and let > every version of the function use the same tables. What do you mean by duplicated? That tables for 10 and 12 are? Otherwise, I'm leaving the ssse3/opt parameter for 2 reasons: - try to not perform changes that aren't required for it to work - I don't know how the avx2 code would look but indeed, if it had to use other tables, it would then use new macro(s) Maybe your suggestions could be delayed after the code is converted to ssse3? Probably there wouldn't be any, but patch conflicts would be cumbersome. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
On 23/08/14 12:11 PM, Christophe Gisquet wrote: > Hi, > > 2014-08-23 16:52 GMT+02:00 James Almer : >>> -QPEL_TABLE 8, 8, b, sse4 >>> -QPEL_TABLE 10, 4, w, sse4 >>> -QPEL_TABLE 12, 4, w, sse4 >>> +QPEL_TABLE 8, 8, b, ssse3 >>> +QPEL_TABLE 10, 4, w, ssse3 >>> +QPEL_TABLE 12, 4, w, ssse3 >> >> Do these need to be duplicated? You could just remove the suffix and let >> every version of the function use the same tables. > > What do you mean by duplicated? That tables for 10 and 12 are? > > Otherwise, I'm leaving the ssse3/opt parameter for 2 reasons: > - try to not perform changes that aren't required for it to work > - I don't know how the avx2 code would look but indeed, if it had to > use other tables, it would then use new macro(s) > > Maybe your suggestions could be delayed after the code is converted to > ssse3? Probably there wouldn't be any, but patch conflicts would be > cumbersome. I was talking about the opt suffix since both the ssse3 and sse4 tables will be the same. And sure, it was just a suggestion, so go with whatever is easier for you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
Hi, 2014-08-23 17:01 GMT+02:00 James Almer : >>> There's a PACK macro in lavfi/x86/yasm-16.asm that does this without >> intrinsics. >> >> You meant yadif-16, right? >> >> Timothy > > Oops, yes i meant that :P I expect it to be needed for the weighted pred functions, so I'll split it from yadif-16 into x264util under a more explicit name (PACK_U32? PACK_U32_TO_16 ?) -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
Hi, 2014-08-23 17:16 GMT+02:00 James Almer : >> What do you mean by duplicated? That tables for 10 and 12 are? [...] > I was talking about the opt suffix since both the ssse3 and sse4 tables will > be the same. Oh ok, in case we have to instantiate sse4 versions. Because at the moment there are only tables for ssse3 with this patch. Ideally, if the loss is sufficiently small between the ssse3 and sse4 versions, we'd just keep the sse3 version, as the object code increase wouldn't be worth it. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] x86: hevc_mc: port to SSSE3
On 23/08/14 12:15 PM, Christophe Gisquet wrote: > Hi, > > 2014-08-23 17:01 GMT+02:00 James Almer : There's a PACK macro in lavfi/x86/yasm-16.asm that does this without >>> intrinsics. >>> >>> You meant yadif-16, right? >>> >>> Timothy >> >> Oops, yes i meant that :P > > I expect it to be needed for the weighted pred functions, so I'll > split it from yadif-16 into x264util under a more explicit name > (PACK_U32? PACK_U32_TO_16 ?) PACKUSDW. Like other macros that emulate a single instruction (PALIGNR, PABSW, etc) you can use its name. The yadif-16.asm macro seems to be for a single register. It will have to be changed to support two. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/tiff: add support for LZMA compression
On 23/08/14 8:31 AM, Michael Niedermayer wrote: > On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote: >> Derived from deflate code. >> Requires liblzma. >> >> Signed-off-by: James Almer > > how can this be tested ? > do you have a testcase / sample ? libtiff can create lzma compressed files. You can install xz-utils from most linux distros. I nonetheless uploaded three files to the ftp (rgb, yuv420p and pal8 to test all code paths). They are called rgv-3c-8b_lzma.tif, yuv-3c-8b_lzma.tif and palette-1c-4b_lzma.tiff ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
On 23/08/14 12:20 PM, Christophe Gisquet wrote: > Hi, > > 2014-08-23 17:16 GMT+02:00 James Almer : >>> What do you mean by duplicated? That tables for 10 and 12 are? > [...] >> I was talking about the opt suffix since both the ssse3 and sse4 tables will >> be the same. > > Oh ok, in case we have to instantiate sse4 versions. Because at the > moment there are only tables for ssse3 with this patch. > > Ideally, if the loss is sufficiently small between the ssse3 and sse4 > versions, we'd just keep the sse3 version, as the object code increase > wouldn't be worth it. Right, i now realize i misread the patch. I assumed you were duplicating the tables with a new ssse3 version instead of renaming the existing sse4. Disregard all this then. Sorry. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] x86: hevc_mc: convert to ssse3
For avx2 I have some to push to the trunk, I did merge it yesterday with all recent changes. But I don t remember what those tables looks like. For 10 and 12bits, ssse3 should slow down the decoding since it uses 4 more instructions in the loop. Le samedi 23 août 2014, Christophe Gisquet a écrit : > Hi, > > 2014-08-23 16:52 GMT+02:00 James Almer >: > >> -QPEL_TABLE 8, 8, b, sse4 > >> -QPEL_TABLE 10, 4, w, sse4 > >> -QPEL_TABLE 12, 4, w, sse4 > >> +QPEL_TABLE 8, 8, b, ssse3 > >> +QPEL_TABLE 10, 4, w, ssse3 > >> +QPEL_TABLE 12, 4, w, ssse3 > > > > Do these need to be duplicated? You could just remove the suffix and let > > every version of the function use the same tables. > > What do you mean by duplicated? That tables for 10 and 12 are? > > Otherwise, I'm leaving the ssse3/opt parameter for 2 reasons: > - try to not perform changes that aren't required for it to work > - I don't know how the avx2 code would look but indeed, if it had to > use other tables, it would then use new macro(s) > > Maybe your suggestions could be delayed after the code is converted to > ssse3? Probably there wouldn't be any, but patch conflicts would be > cumbersome. > > -- > Christophe > ___ > 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] x86: hevc_mc: convert to ssse3
Hi, 2014-08-23 17:48 GMT+02:00 Mickaël Raulet : > For avx2 I have some to push to the trunk, I did merge it yesterday with > all recent changes. But I don t remember what those tables looks like. Well, my point was hypothetical, but I guess this means some conflicts are to be expected when either patchset is merged. Do you have specific (START/STOP_TIMER) and global (using time or -benchmark option) measures? > For 10 and 12bits, ssse3 should slow down the decoding since it uses 4 more > instructions in the loop. Not systematically, as out-of-order execution and several execution ports can "hide" them. But those are too dependent for this and I expect a loss and a need for a sse4 version. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
On Sat, Aug 23, 2014 at 03:13:50PM +0200, Andreas Cadhalpun wrote: > Hi, > > On 20.07.2014 23:23, Timothy Gu wrote: > >texi2html is deprecated by upstream in favor of makeinfo/texi2any. See: > > > >- > >https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html > >- https://wiki.debian.org/Texi2htmlTransition > >- https://lists.debian.org/debian-devel/2013/05/msg01516.html > > > >This is actually two separate changes. But as makeinfo and texi2html > >adopt 2 (very) different init file syntaxes, it is easier to do the two > >transitions at once. > > > >Based on a patch by Andreas Cadhalpun . > > > >Fixes Trac ticket #3232. > > > >Signed-off-by: Timothy Gu > >--- > > Is there a reason, why this patch hasn't been applied? the makeinfo available on our webserver is too old (4.13) a newer version (provided by timothy), did not work if someone wants to work on this, i can give him/her an account note, we plan to migrate things to a box with ubuntu 14.04 but its unknown when this will be finished Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libx264: fix -b_qfactor and -chromaoffset
Currently -b_qfactor and -chromaoffset have no effect in libx264, the
attached patch is an attempt to fix the issue.
Move the corresponding lines after x264_param_default_preset() to
prevent them being overwritten by it, make the two parameters functional.
Also make b_qfactor changeable by x264's tunings after the move.
(feel free to edit the commit message as I am not a native English speaker.)
From d8597d3f708c21deae40b21754173763c5a13658 Mon Sep 17 00:00:00 2001
From: Hii
Date: Sat, 23 Aug 2014 17:08:02 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
---
libavcodec/libx264.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 7793581..8aff14d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
x4->params.b_deblocking_filter = avctx->flags &
CODEC_FLAG_LOOP_FILTER;
-x4->params.rc.f_pb_factor = avctx->b_quant_factor;
-x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
if (x4->preset || x4->tune)
if (x264_param_default_preset(&x4->params, x4->preset, x4->tune) < 0) {
int i;
@@ -430,6 +428,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx->i_quant_factor > 0)
x4->params.rc.f_ip_factor = 1 / fabs(avctx->i_quant_factor);
+if (avctx->b_quant_factor > 0)
+x4->params.rc.f_pb_factor = avctx->b_quant_factor;
+x4->params.analyse.i_chroma_qp_offset = avctx->chromaoffset;
if (avctx->me_method == ME_EPZS)
x4->params.analyse.i_me_method = X264_ME_DIA;
@@ -827,6 +828,7 @@ static const AVCodecDefault x264_defaults[] = {
{ "flags2", "0" },
{ "g","-1" },
{ "i_qfactor","-1" },
+{ "b_qfactor","-1" },
{ "qmin", "-1" },
{ "qmax", "-1" },
{ "qdiff","-1" },
--
1.9.0.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
Hi, On Aug 23, 2014 9:52 AM, "Michael Niedermayer" wrote: > > On Sat, Aug 23, 2014 at 03:13:50PM +0200, Andreas Cadhalpun wrote: > > Is there a reason, why this patch hasn't been applied? > > the makeinfo available on our webserver is too old (4.13) > a newer version (provided by timothy), did not work > if someone wants to work on this, i can give him/her an account It doesn't matter, as the server doesn't use the modified Makefile IIRC. This only makes the users' documentation better at this moment. I still want to work on server integration, but my time is limited. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On Thu, Aug 21, 2014 at 03:16:50AM +0200, Attila Kinali wrote: > Servus, > > On Wed, 20 Aug 2014 18:43:18 +0900 > Norbert Preining wrote: > > > By continuing old fights, inspite of the very clearly friendly and > > open offers and suggestions byu Michael, you and others from AV continue > > simply to insult and be nasty. > > Sorry, but this is not true. Yes, Michael always offers to mend ways > and to do this and that. But he never does. It's just lip service. > He didn't do it before the split and he didn't happen after the split. Theres something about your statements, the one above as well as the ones in other mails in this thread that i dont fully understand You said in this thread that "i'm not a developer and have not written one line of code for libav. i dont even read the mailinglists" (https://lists.debian.org/debian-devel/2014/08/msg00782.html) and IIRC you also didnt read the ffmpeg mailing lists in the time before the fork, except some specific threads, nor are you on the ffmpeg IRC channels and i belive you arent subscribed to the FFmpeg mailing lists now either. I definitly found a unsubscribe statement for your address from march 2011 in the logs. Given that, how can you even know anything about FFmpeg or what its developers do or say or not do or not say ? FFmpeg development discussions are mainly on our mailing list. with a tiny bit on our IRC channels I know you did read some specific threads which where related to the fork as you participated in them. But these where possibly the most heated and aggressive discussions we ever had on ffmpeg-devel. And certainly are not representative for FFmpeg either before or after the fork. > Yes, the people at libav are bitter. Yes, they are angry. But how > would you feel if people would walk up to you at random OSS events > and tell you that X just told them you are the bad guy, that you > steal childrens ice cream? (Yes, this has happend) > > > > I am really impressed by the ability of Michael to take this without > > changing into a more inpolite tone. Which you and others from AV are > > definitely doing. > > If you mean me by "others", then i would like to ask where i have been > impolite. > > > * AV maintainers are averse o any cooperation, and just licking their > > wounds since several years > > You know, that FFmpeg and libav have been cooperating ever since the > split? FFmpeg merges all (or almost all?) patches commited to libav > without further review. normally (for example in the kernel) code is reviewed before it is pushed and not when it is merged. Yet i _try_ to review and test what i merge from libav. To proof that, here are some examples of bugfixes and decissions based on such reviews. These wouldnt exist if the code wouldnt be reviewed. 4 days ago: libav added some () to a condition: https://github.com/libav/libav/commit/d456baafb68cd80c0f537f1d843076e4dd853558 on the ffmpeg side the code was instead changed the following way a year ago http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1e2ab98460761c86268993e7a7ee690876df5efd libav decided not to pick this change, and instead made their own different change as shown above and in the merge i tested both to double check that our solution is correct and libavs isnt, and kept our solution. More precissely libavs breaks decoding of http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue414/black_screen_VC-1.mkv or for example 16days ago libav fixed a few memory leaks https://github.com/libav/libav/commit/5b220e1e19c17b202d83d9be0868d152109ae8f0 but they used the wrong deallocation function, that is free() instead of av_free*() which can lead to memory corruption, Multiple people noticed that and it was fixed in the same git push that pushed the merge http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92deb28945a5f2b58908d383f183cfc1bc1d7fae also there where multiple other related issues found when reviewing the change from libav which where fixed in ffmpeg in the same push as well: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=12b59e57f3d7a37ef7b29d8a1df5eb886b00b4ba http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31eaecfee9d84381945f3d5201775b9b00161d7a http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92a28e9f562124732fa27f0c62118f15a6fee239 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5f8300afc6537e2e06f8f90989d5f268884bb79c but either way, id like to suggest again, we move forward and rather discuss how we can improve the situation, do something about the split and move toward un-doing it! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec sad functions
---
This is 100% untested and probably doesn't even compile.
Can anyone with PPC/Altivec HW test or provide such access?
After the altivec optims are ported we can drop the duplicated version in
libavcodec entirely.
The fate-pixelutils tests should cover the alignment checks; there might be
some fixes in this area as I'm not sure about the requirement.
About the copyright, I put Brian Foley only, because of
59925ef2044e3ba2b5be49a35d37929550e3d6bc. If someone feels like some more
people should be added, please tell me.
---
libavutil/pixelutils.c | 6 +--
libavutil/ppc/Makefile | 3 ++
libavutil/ppc/pixelutils.h | 26 +
libavutil/ppc/pixelutils_altivec.c | 106 +
libavutil/ppc/pixelutils_altivec.h | 30 +++
libavutil/ppc/pixelutils_init.c| 33
6 files changed, 201 insertions(+), 3 deletions(-)
create mode 100644 libavutil/ppc/pixelutils.h
create mode 100644 libavutil/ppc/pixelutils_altivec.c
create mode 100644 libavutil/ppc/pixelutils_altivec.h
create mode 100644 libavutil/ppc/pixelutils_init.c
diff --git a/libavutil/pixelutils.c b/libavutil/pixelutils.c
index 10ff7e8..9a7b7f1 100644
--- a/libavutil/pixelutils.c
+++ b/libavutil/pixelutils.c
@@ -23,6 +23,7 @@
#if CONFIG_PIXELUTILS
#include "x86/pixelutils.h"
+#include "ppc/pixelutils.h"
static av_always_inline int sad_wxh(const uint8_t *src1, ptrdiff_t stride1,
const uint8_t *src2, ptrdiff_t stride2,
@@ -77,9 +78,8 @@ av_pixelutils_sad_fn av_pixelutils_get_sad_fn(int w_bits, int
h_bits, int aligne
if (w_bits != h_bits) // only squared sad for now
return NULL;
-#if ARCH_X86
-ff_pixelutils_sad_init_x86(sad, aligned);
-#endif
+if (ARCH_X86) ff_pixelutils_sad_init_x86(sad, aligned);
+if (ARCH_PPC) ff_pixelutils_sad_init_ppc(sad, aligned);
return sad[w_bits - 1];
#endif
diff --git a/libavutil/ppc/Makefile b/libavutil/ppc/Makefile
index 4fd8d6d..295e4e5 100644
--- a/libavutil/ppc/Makefile
+++ b/libavutil/ppc/Makefile
@@ -1,4 +1,7 @@
OBJS += ppc/cpu.o \
ppc/float_dsp_init.o\
+OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils_init.o
+
ALTIVEC-OBJS += ppc/float_dsp_altivec.o \
+ALTIVEC-OBJS-$(CONFIG_PIXELUTILS) += ppc/pixelutils_altivec.o \
diff --git a/libavutil/ppc/pixelutils.h b/libavutil/ppc/pixelutils.h
new file mode 100644
index 000..c737a69
--- /dev/null
+++ b/libavutil/ppc/pixelutils.h
@@ -0,0 +1,26 @@
+/*
+ * 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 FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVUTIL_PPC_PIXELUTILS_H
+#define AVUTIL_PPC_PIXELUTILS_H
+
+#include "libavutil/pixelutils.h"
+
+void ff_pixelutils_sad_init_ppc(av_pixelutils_sad_fn *sad, int aligned);
+
+#endif /* AVUTIL_PPC_PIXELUTILS_H */
diff --git a/libavutil/ppc/pixelutils_altivec.c
b/libavutil/ppc/pixelutils_altivec.c
new file mode 100644
index 000..5cf338a
--- /dev/null
+++ b/libavutil/ppc/pixelutils_altivec.c
@@ -0,0 +1,106 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * Copyright (c) 2002 Brian Foley
+ *
+ * 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 FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "util_altivec.h"
+#include "pixelutils_altivec.h"
+
+int ff_pixelutils_sad_8x8_altivec(const uint8_t *src1, ptrdiff_t stride1,
+ const uint8_t *src2, ptrdiff_t stride2)
+{
+int i, s;
+const vector unsigned int zero =
+(const vector unsigned int) vec_splat_u32(0);
+const
[FFmpeg-devel] [PATCH 2/2] Correct few "ffmpeg" typos
Signed-off-by: Paul B Mahol --- libavcodec/aasc.c| 2 +- libavcodec/cinepak.c | 2 +- libavcodec/cyuv.c| 2 +- libavcodec/flicvideo.c | 2 +- libavcodec/idcinvideo.c | 2 +- libavcodec/interplayvideo.c | 2 +- libavcodec/libopencore-amr.c | 2 +- libavcodec/libvo-amrwbenc.c | 2 +- libavcodec/msrle.c | 2 +- libavcodec/msvideo1.c| 2 +- libavcodec/qtrle.c | 2 +- libavcodec/ra144.c | 2 +- libavcodec/ra144.h | 2 +- libavcodec/ra288.c | 2 +- libavcodec/ra288.h | 2 +- libavcodec/roqvideodec.c | 2 +- libavcodec/rpza.c| 2 +- libavcodec/smc.c | 2 +- libavcodec/sp5x.h| 2 +- libavcodec/svq1.c| 4 ++-- libavcodec/svq1.h| 4 ++-- libavcodec/svq1_cb.h | 4 ++-- libavcodec/svq1_vlc.h| 2 +- libavcodec/svq1dec.c | 4 ++-- libavcodec/vmdaudio.c| 2 +- libavcodec/vmdvideo.c| 2 +- libavcodec/vp3.c | 2 +- libavcodec/vp3data.h | 2 +- libavcodec/vp3dsp.c | 2 +- libavcodec/vqavideo.c| 2 +- libavcodec/xan.c | 2 +- 31 files changed, 35 insertions(+), 35 deletions(-) diff --git a/libavcodec/aasc.c b/libavcodec/aasc.c index 38658f8..65ef782 100644 --- a/libavcodec/aasc.c +++ b/libavcodec/aasc.c @@ -1,6 +1,6 @@ /* * Autodesk RLE Decoder - * Copyright (C) 2005 the ffmpeg project + * Copyright (c) 2005 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c index 082d0b2..4746289 100644 --- a/libavcodec/cinepak.c +++ b/libavcodec/cinepak.c @@ -1,6 +1,6 @@ /* * Cinepak Video Decoder - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/cyuv.c b/libavcodec/cyuv.c index c686123..6e8e461 100644 --- a/libavcodec/cyuv.c +++ b/libavcodec/cyuv.c @@ -4,7 +4,7 @@ * based on "Creative YUV (CYUV) stream format for AVI": * http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt * - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c index a2d59e8..5bd5fb6 100644 --- a/libavcodec/flicvideo.c +++ b/libavcodec/flicvideo.c @@ -1,6 +1,6 @@ /* * FLI/FLC Animation Video Decoder - * Copyright (C) 2003, 2004 the ffmpeg project + * Copyright (c) 2003, 2004 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/idcinvideo.c b/libavcodec/idcinvideo.c index 80c7d07..7765376 100644 --- a/libavcodec/idcinvideo.c +++ b/libavcodec/idcinvideo.c @@ -1,6 +1,6 @@ /* * id Quake II CIN Video Decoder - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/interplayvideo.c b/libavcodec/interplayvideo.c index 0f6c4e2..96c0cd1 100644 --- a/libavcodec/interplayvideo.c +++ b/libavcodec/interplayvideo.c @@ -1,6 +1,6 @@ /* * Interplay MVE Video Decoder - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c index 4c7b6af..827bded 100644 --- a/libavcodec/libopencore-amr.c +++ b/libavcodec/libopencore-amr.c @@ -1,6 +1,6 @@ /* * AMR Audio decoder stub - * Copyright (c) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/libvo-amrwbenc.c b/libavcodec/libvo-amrwbenc.c index 4216a41..f14d61f 100644 --- a/libavcodec/libvo-amrwbenc.c +++ b/libavcodec/libvo-amrwbenc.c @@ -1,6 +1,6 @@ /* * AMR Audio encoder stub - * Copyright (c) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/msrle.c b/libavcodec/msrle.c index 9f0cac6..260ad80 100644 --- a/libavcodec/msrle.c +++ b/libavcodec/msrle.c @@ -1,6 +1,6 @@ /* * Microsoft RLE video decoder - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/msvideo1.c b/libavcodec/msvideo1.c index e60abee..88397be 100644 --- a/libavcodec/msvideo1.c +++ b/libavcodec/msvideo1.c @@ -1,6 +1,6 @@ /* * Microsoft Video-1 Decoder - * Copyright (C) 2003 the ffmpeg project + * Copyright (c) 2003 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c index 4a4..b367643 100644 --- a/libavcodec/qtrle.c +++ b/libavcodec/qtrle.c @@ -1,6 +1,6 @@ /* * Quicktime Animation (RLE) Video Decoder - * Copyright (C) 2004 the ffmpeg project + * Copyright (c) 2004 The FFmpeg Project * * This file is part of FFmpeg. * diff --git a/libavcodec/ra144.c b/libavcodec/ra144.c index d5ad02f..696a49e 100644 --- a/libav
[FFmpeg-devel] [PATCH 1/2] avcodec/xan: fix style issue
Signed-off-by: Paul B Mahol
---
libavcodec/xan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/xan.c b/libavcodec/xan.c
index 7489113..bb28916 100644
--- a/libavcodec/xan.c
+++ b/libavcodec/xan.c
@@ -556,7 +556,7 @@ static int xan_decode_frame(AVCodecContext *avctx,
int i;
tag = bytestream2_get_le32(&ctx);
size = bytestream2_get_be32(&ctx);
-if(size < 0) {
+if (size < 0) {
av_log(avctx, AV_LOG_ERROR, "Invalid tag size %d\n", size);
return AVERROR_INVALIDDATA;
}
--
1.7.11.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/xan: fix style issue
On Sat, Aug 23, 2014 at 07:40:21PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/xan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/xan.c b/libavcodec/xan.c
> index 7489113..bb28916 100644
> --- a/libavcodec/xan.c
> +++ b/libavcodec/xan.c
> @@ -556,7 +556,7 @@ static int xan_decode_frame(AVCodecContext *avctx,
> int i;
> tag = bytestream2_get_le32(&ctx);
> size = bytestream2_get_be32(&ctx);
> -if(size < 0) {
> +if (size < 0) {
> av_log(avctx, AV_LOG_ERROR, "Invalid tag size %d\n", size);
> return AVERROR_INVALIDDATA;
> }
Obviously OK. No need to send a patch for this.
--
Clément B.
pgpsly0Hz7_Tg.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Correct few "ffmpeg" typos
On Sat, Aug 23, 2014 at 07:40:22PM +, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/aasc.c| 2 +- > libavcodec/cinepak.c | 2 +- > libavcodec/cyuv.c| 2 +- > libavcodec/flicvideo.c | 2 +- > libavcodec/idcinvideo.c | 2 +- > libavcodec/interplayvideo.c | 2 +- > libavcodec/libopencore-amr.c | 2 +- > libavcodec/libvo-amrwbenc.c | 2 +- > libavcodec/msrle.c | 2 +- > libavcodec/msvideo1.c| 2 +- > libavcodec/qtrle.c | 2 +- > libavcodec/ra144.c | 2 +- > libavcodec/ra144.h | 2 +- > libavcodec/ra288.c | 2 +- > libavcodec/ra288.h | 2 +- > libavcodec/roqvideodec.c | 2 +- > libavcodec/rpza.c| 2 +- > libavcodec/smc.c | 2 +- > libavcodec/sp5x.h| 2 +- > libavcodec/svq1.c| 4 ++-- > libavcodec/svq1.h| 4 ++-- > libavcodec/svq1_cb.h | 4 ++-- > libavcodec/svq1_vlc.h| 2 +- > libavcodec/svq1dec.c | 4 ++-- > libavcodec/vmdaudio.c| 2 +- > libavcodec/vmdvideo.c| 2 +- > libavcodec/vp3.c | 2 +- > libavcodec/vp3data.h | 2 +- > libavcodec/vp3dsp.c | 2 +- > libavcodec/vqavideo.c| 2 +- > libavcodec/xan.c | 2 +- > 31 files changed, 35 insertions(+), 35 deletions(-) > Fine with me [...] -- Clément B. pgp0s00vy4Bqs.pgp Description: PGP 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 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
commit missing files
use avctx as context as often as possible
respect field dominance
fix frame size and rate
adapt documentation
Signed-off-by: Deti fliegl
---
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 ++-
libavdevice/decklink_enc.h | 11 -
libavdevice/decklink_enc_c.c| 1 +
13 files changed, 1055 insertions(+), 194 deletions(-)
create mode 100644 libavdevice/decklink_common.cpp
create mode 100644 libavdevice/decklink_common.h
create mode 100644 libavdevice/decklink_common_c.h
create mode 100644 libavdevice/decklink_dec.cpp
create mode 100644 libavdevice/decklink_dec.h
create mode 100644 libavdevice/decklink_dec_c.c
diff --git a/configure b/configure
index f355dad..189542f 100755
--- a/configure
+++ b/configure
@@ -253,7 +253,7 @@ External library support:
native MPEG-4/Xvid encoder exists [no]
--enable-libzmq enable message passing via libzmq [no]
--enable-libzvbi enable teletext support via libzvbi [no]
- --enable-decklinkenable Blackmagick DeckLink output [no]
+ --enable-decklinkenable Blackmagick DeckLink I/O support [no]
--enable-openal enable OpenAL 1.1 capture support [no]
--enable-opencl enable OpenCL code
--enable-opengl enable OpenGL rendering [no]
@@ -2441,6 +2441,8 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h
machine_ioctl_bt848_h dev_video_bktr
caca_outdev_deps="libcaca"
decklink_outdev_deps="decklink pthreads"
decklink_outdev_extralibs="-lstdc++"
+decklink_indev_deps="decklink pthreads"
+decklink_indev_extralibs="-lstdc++"
dshow_indev_deps="IBaseFilter"
dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid"
dv1394_indev_deps="dv1394"
diff --git a/doc/indevs.texi b/doc/indevs.texi
index ce409b9..99e1112 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -922,4 +922,58 @@ Use the MIT-SHM extension for shared memory. Default value
is @code{1}.
It may be necessary to disable it for remote displays.
@end table
+@section decklink
+
+The decklink input device provides capture capabilities for Blackmagic
+DeckLink devices.
+
+To enable this input device, you need the Blackmagic DeckLink SDK and you
+need to configure with the appropriate @code{--extra-cflags}
+and @code{--extra-ldflags}.
+On Windows, you need to run the IDL files through @command{widl}.
+
+DeckLink is very picky about the formats it supports. Pixel format is always
+uyvy422, framerate and video size must be determined for your device with
+@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
+of channels currently is limited to 2 (stereo).
+
+@subsection Options
+
+@table @option
+
+@item list_devices
+If set to @option{true}, print a list of devices and exit.
+Defaults to @option{false}.
+
+@item list_formats
+If set to @option{true}, print a list of supported formats and exit.
+Defaults to @option{false}.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+List input devices:
+@example
+ffmpeg -f decklink -list_devices 1 -i dummy
+@end example
+
+@item
+List supported formats:
+@example
+ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
+@end example
+
+@item
+Capture video clip at 1080i50 (format 11):
+@example
+ffmpeg -f decklink -i 'Intensity Pro@@11' -acodec copy -vcodec copy output.avi
+@end example
+
+@end itemize
+
+
@c man end INPUT DEVICES
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index db301e7..8cf98f0 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -16,7 +16,8 @@ OBJS-$(CONFIG_ALSA_OUTDEV) +=
alsa-audio-common.o \
OBJS-$(CONFIG_AVFOUNDATION_INDEV)+= avfoundation.o
OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
OBJS-$(CONFIG_CACA_OUTDEV) += caca.o
-OBJS-$(CONFIG_DECKLINK_OUTDEV) += decklink_enc.o decklink_enc_c.o
+OBJS-$(CONFIG_DECKLINK_OUTDEV) += decklink_enc.o decklink_enc_c.o
decklink_common.o
+OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o
decklink_common.o
OBJS-$(CONFIG_DSHOW_INDEV) += dshow.o dshow_enummediat
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
> but either way, id like to suggest again, we move forward and > rather discuss how we can improve the situation, do something about > the split and move toward un-doing it! We look forward to seeing you in Dublin then. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec sad functions
On Sat, Aug 23, 2014 at 09:24:33PM +0200, Clément Bœsch wrote: > --- > This is 100% untested and probably doesn't even compile. it does compile, but i dont have a ppc so i cant say if it would work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Common mailing-list for API evolutions
Hi, Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list between the two projects to start communicating again in sane terms. The proposition would be a mailing-list where the 2 projects would send the patches that will make API evolutions. So the projects can continue to drop or add codecs & filters without caring about the other, but will try to communicate more about the API, for the sake of our common users. At first, I suggest that won't engage anything from any of the two projects (so we don't end up in a stalled states such as one project trying to block the other), but it could be seen as a way to introduce some common technical ground. What do you think? On the technical side, we potentially need a neutral party to setup such mailing-list. Is anyone willing to do that? Best regards, -- Clément B. pgpelKtcU89FR.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Common mailing-list for API evolutions
Hi, Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list between the two projects to start communicating again in sane terms. The proposition would be a mailing-list where the 2 projects would send the patches that will make API evolutions. So the projects can continue to drop or add codecs & filters without caring about the other, but will try to communicate more about the API, for the sake of our common users. At first, I suggest that won't engage anything from any of the two projects (so we don't end up in a stalled states such as one project trying to block the other), but it could be seen as a way to introduce some common technical ground. What do you think? On the technical side, we potentially need a neutral party to setup such mailing-list. Is anyone willing to do that? Best regards, -- Clément B. pgpe78o0kYcbG.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Common mailing-list for API evolutions
On Sun, Aug 24, 2014 at 12:27:09AM +0200, Clément Bœsch wrote: > Hi, > > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list > between the two projects to start communicating again in sane terms. > > The proposition would be a mailing-list where the 2 projects would send > the patches that will make API evolutions. So the projects can continue to > drop or add codecs & filters without caring about the other, but will try > to communicate more about the API, for the sake of our common users. > > At first, I suggest that won't engage anything from any of the two > projects (so we don't end up in a stalled states such as one project > trying to block the other), but it could be seen as a way to introduce > some common technical ground. > > What do you think? > > On the technical side, we potentially need a neutral party to setup such > mailing-list. Is anyone willing to do that? > > Best regards, > Please don't reply here, I messed up the libav-devel mail... -- Clément B. pgpvGZVKwQQiR.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not show an unreadable error code if mov header parsing fails
On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> I don't think showing "-1094995529" or similar makes much sense.
> The calling application can still decide to show the error
> string (as ffmpeg does).
>
> Please comment, Carl Eugen
> mov.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 22cbe9fcb08e20f3520d8391f4a03dac1cb464df patchmovheader.diff
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b3eb287..ae48c02 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3562,7 +3562,7 @@ static int mov_read_header(AVFormatContext *s)
> if (mov->moov_retry)
> avio_seek(pb, 0, SEEK_SET);
> if ((err = mov_read_default(mov, pb, atom)) < 0) {
> -av_log(s, AV_LOG_ERROR, "error reading header: %d\n", err);
> +av_log(s, AV_LOG_ERROR, "error reading header\n");
i think av_err2str() might provide a nicer string
[...]
--
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] Filters
> > From: JULIAN GARDNER >To: FFmpeg development discussions and patches >Sent: Monday, 18 August 2014, 19:51 >Subject: Re: [FFmpeg-devel] Filters > > > >> >> From: Clément Bœsch >>To: FFmpeg development discussions and patches >>Sent: Sunday, 20 July 2014, 10:40 >>Subject: Re: [FFmpeg-devel] Filters >> >> >>On Fri, Jul 18, 2014 at 10:33:40PM +0100, JULIAN GARDNER wrote: >>[...] >>> fmpeg -i .ts -vcodec libx264 -b:v 1000k -acodec libfaac -async 1 -vf >>> 'split [mark], drawbox=10:10:100:100:color=green [dontneed];[mark] >>> drawbox=100:100:100;100:color=red [vid];[dontneed][vid] overlay' -y -f >>> mpegts processed.ts >>> >> >>try -filter_complex instead of -vf and >>-map [vid] -y -f mpegts processed.ts -map '[dontneed]' -f null - >> >>[...] >> >>-- >>Clément B. >> > >Thanks for this, its 99% what i need apart from I lose the audio on the [vid] >output. I want the small picture [160x100] output without audio and the >640x360 output with audio > > >Commandlineffmpeg -threads 0 -i >"udp://231.231.11.3:1234?localaddr=192.168.2.123" -filter_complex >'scale=iw/2:ih/2,split [mark], scale=160:90,drawbox=10:10:5:5:color=red >[detect];[mark] drawbox=10:10:10:5:5:color=blue [vid]' -map [detect] -vcodec >libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=512 -bufsize 1M >-r 25 -an -f mpegts >"udp://238.170.112.96:1234?pkt_size=1316&buffer_size=1048576" -map [vid][0:a] >-vcodec libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=1150 >-bufsize 1M -r 25 -acodec libfaac -ab 128k -ar 32k -ac 2 -f mpegts >"udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576" > > >Output (as I know you love this)ffmpeg version N-63057-g63504d8 Copyright (c) >2000-2014 the FFmpeg developers > built on Aug 14 2014 10:36:36 with gcc 4.6 (Ubuntu/Linaro >4.6.4-1ubuntu1~12.04) > configuration: --enable-gpl --enable-version3 --enable-nonfree >--enable-postproc --enable-libfaac --enable-libmp3lame --enable-libx264 >--enable-libzvbi --cc='ccache cc' > libavutil 52. 82.100 / 52. 82.100 > libavcodec 55. 60.103 / 55. 60.103 > libavformat 55. 37.102 / 55. 37.102 > libavdevice 55. 13.101 / 55. 13.101 > libavfilter 4. 5.100 / 4. 5.100 > libswscale 2. 6.100 / 2. 6.100 > libswresample 0. 18.100 / 0. 18.100 > libpostproc 52. 3.100 / 52. 3.100 >Input #0, mpegts, from 'udp://231.231.11.3:1234?localaddr=192.168.2.123': > Duration: N/A, start: 12191.492622, bitrate: 128 kb/s > Program 48 > Stream #0:0[0x41]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, >1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc > Stream #0:1[0x42]: Audio: mp2 ([4][0][0][0] / 0x0004), 48000 Hz, stereo, >s16p, 128 kb/s >Codec AVOption ab (set bitrate (in bits/s)) specified for output file #1 >(udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576) has not been >used for any stream. The most likely reason is either wrong type (e.g. a video >option with no video streams) or that it is a private option of some encoder >which was not actually used for any stream. >[libx264 @ 0x2d72560] VBV maxrate unspecified, assuming CBR >[libx264 @ 0x2d72560] using SAR=1/1 >[libx264 @ 0x2d72560] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 >[libx264 @ 0x2d72560] profile High, level 1.3 >[libx264 @ 0x2d74d60] VBV maxrate unspecified, assuming CBR >[libx264 @ 0x2d74d60] using SAR=1/1 >[libx264 @ 0x2d74d60] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 >[libx264 @ 0x2d74d60] profile High, level 3.0 >Output #0, mpegts, to >'udp://238.170.112.96:1234?pkt_size=1316&buffer_size=1048576': > Metadata: > encoder : Lavf55.37.102 > Stream #0:0: Video: h264 (libx264), yuv420p, 160x90 [SAR 1:1 DAR 16:9], >q=-1--1, 512 kb/s, 90k tbn, 25 tbc >Output #1, mpegts, to >'udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576': > Metadata: > encoder : Lavf55.37.102 > Stream #1:0: Video: h264 (libx264), yuv420p, 640x360 [SAR 1:1 DAR 16:9], >q=-1--1, 1150 kb/s, 90k tbn, 25 tbc >Stream mapping: > Stream #0:0 (h264) -> scale > drawbox -> Stream #0:0 (libx264) > drawbox -> Stream #1:0 (libx264) >Press [q] to stop, [?] for help >[mpegts @ 0x2d40fc0] New 0011 Table, version 255 to 0 >frame= 130 fps= 26 q=-1.0 Lq=-1.0 size= 245kB time=00:00:05.12 bitrate= >392.2kbits/s dup=24 drop=224 > >any idea on how i can get the audio back > >joolz I tried your suggestion of splitting the "-map [vid[0:a]" into "-map [vid] -map [0:a] and I get the following error message Output with label '0:a' does not exist in any defined filter graph, or is already used elsewhere. I managed to get around this by using "-map [vid] -map a:0x42", but why does the split one fail. joolz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use makeinfo to generate html doc for the new website
On Sun, Jul 20, 2014 at 02:23:07PM -0700, Timothy Gu wrote: > texi2html is deprecated by upstream in favor of makeinfo/texi2any. See: > > - https://www.gnu.org/software/texinfo/manual/texinfo/html_node/texi2html.html > - https://wiki.debian.org/Texi2htmlTransition > - https://lists.debian.org/debian-devel/2013/05/msg01516.html > > This is actually two separate changes. But as makeinfo and texi2html > adopt 2 (very) different init file syntaxes, it is easier to do the two > transitions at once. > > Based on a patch by Andreas Cadhalpun . > > Fixes Trac ticket #3232. > > Signed-off-by: Timothy Gu breaks build on ubuntu 12.04 makeinfo: unrecognized option '--init-file=./doc/t2h.pm' Try `makeinfo --help' for more information. makeinfo: unrecognized option '--init-file=./doc/t2h.pm' Try `makeinfo --help' for more information. make: *** [doc/ffmpeg-utils.html] Error 1 make: *** Waiting for unfinished jobs make: *** [doc/ffplay.html] Error 1 HTMLdoc/ffserver.html HTMLdoc/ffprobe-all.html also mac OSX 10.9.4 seems to only have makeinfo 4.8, or at least thats whats installed on the box i looked at [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not show an unreadable error code if mov header parsing fails
On Sunday 24 August 2014 12:50:14 am Michael Niedermayer wrote:
> On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > I don't think showing "-1094995529" or similar makes much sense.
> > The calling application can still decide to show the error
> > string (as ffmpeg does).
> >
> > Please comment, Carl Eugen
> >
> > mov.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 22cbe9fcb08e20f3520d8391f4a03dac1cb464df patchmovheader.diff
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index b3eb287..ae48c02 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3562,7 +3562,7 @@ static int mov_read_header(AVFormatContext *s)
> > if (mov->moov_retry)
> > avio_seek(pb, 0, SEEK_SET);
> > if ((err = mov_read_default(mov, pb, atom)) < 0) {
> > -av_log(s, AV_LOG_ERROR, "error reading header: %d\n", err);
> > +av_log(s, AV_LOG_ERROR, "error reading header\n");
>
> i think av_err2str() might provide a nicer string
I prefer the original patch because ffmpeg -i deadf.mov prints
the same error twice with attached patch and no (or nearly no)
other demuxer behaves like this.
Carl Eugen
diff --git a/libavformat/mov.c b/libavformat/mov.c
index b3eb287..ced721c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3562,7 +3562,7 @@ static int mov_read_header(AVFormatContext *s)
if (mov->moov_retry)
avio_seek(pb, 0, SEEK_SET);
if ((err = mov_read_default(mov, pb, atom)) < 0) {
-av_log(s, AV_LOG_ERROR, "error reading header: %d\n", err);
+av_log(s, AV_LOG_ERROR, "error reading header: %s\n", av_err2str(err));
mov_read_close(s);
return err;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not show an unreadable error code if mov header parsing fails
On Sun, Aug 24, 2014 at 01:16:16AM +0200, Carl Eugen Hoyos wrote:
> On Sunday 24 August 2014 12:50:14 am Michael Niedermayer wrote:
> > On Sat, Aug 23, 2014 at 02:02:49PM +0200, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > I don't think showing "-1094995529" or similar makes much sense.
> > > The calling application can still decide to show the error
> > > string (as ffmpeg does).
> > >
> > > Please comment, Carl Eugen
> > >
> > > mov.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > 22cbe9fcb08e20f3520d8391f4a03dac1cb464df patchmovheader.diff
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index b3eb287..ae48c02 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3562,7 +3562,7 @@ static int mov_read_header(AVFormatContext *s)
> > > if (mov->moov_retry)
> > > avio_seek(pb, 0, SEEK_SET);
> > > if ((err = mov_read_default(mov, pb, atom)) < 0) {
> > > -av_log(s, AV_LOG_ERROR, "error reading header: %d\n", err);
> > > +av_log(s, AV_LOG_ERROR, "error reading header\n");
> >
> > i think av_err2str() might provide a nicer string
>
> I prefer the original patch because ffmpeg -i deadf.mov prints
> the same error twice with attached patch and no (or nearly no)
> other demuxer behaves like this.
apply whichever you prefer
both LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- 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] lavc/tiff: add support for LZMA compression
On Sat, Aug 23, 2014 at 11:57:04AM -0300, James Almer wrote: > On 23/08/14 8:37 AM, Hendrik Leppkes wrote: > > On Sat, Aug 23, 2014 at 1:31 PM, Michael Niedermayer > > wrote: > >> On Fri, Aug 22, 2014 at 11:39:57PM -0300, James Almer wrote: > >>> Derived from deflate code. > >>> Requires liblzma. > >>> > >>> Signed-off-by: James Almer > >> > >> how can this be tested ? > >> do you have a testcase / sample ? > >> > > > > This image should be lzma compressed: > > https://www.flameeyes.eu/tmp/imgsrc001-lzma.tiff > > > > - Hendrik > > I get an assertion failure "width <= bytes_per_row" from this file in > tiff_unpack_strip(), before the lzma code even comes to play. > libtiff seems to be able to handle it, though, so could open a ticket in > track > after this gets committed (Without this patch the decoder just aborts as soon > as it finds it's lzma). applied assert fixed thanks [...] -- 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 0/5] RGB48/64 with bits_per_raw_sample
Christophe Gisquet gmail.com> writes: > 2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos: > > Christophe Gisquet writes: > > > >> Depending on the input and/or filters, you sometime > >> have an input or output pixel format like "rgb48le(12 > >> bpc)". Unfortunately, most often, the 12 bpc > >> information is ignored or stripped. > > > > Could you explain what command line you are trying > > to fix? > > I apparently misunderstand the patchset, I don't > > see how / what it fixes... > > The biggest "issue" is that 10/12bits data is > interpreted as 16bits: I consider this a (important) feature. > - cf. ticket #2966 (that's the remaining missing part) There is a bug: The image has to be rescaled in the demuxer. > - png can only write 16bits data but sometimes it is > not rescaled (image appears darker), cf. the above Is there another example than #2966? > - ppm images are forcibly rescaled to fill the 16bits > (probably lossless but still) etc. If you believe this is a real-world issue, is can easily be fixed afaict. > > Note that I believe it would be completely wrong to > > add additional colourspaces with 8 > Yes, on second thought it has its own bag of issues > (multiplications of codepaths eg in swscale), but > that's to me the only solution that isn't a fragile > hack. Also note that there are already plenty of > those 8http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
