[FFmpeg-devel] [PATCH]lavc/cdg: Add transparency

[Carl Eugen Hoyos]

Hi!

Attached patch implements transparency for cdg files, reproducible with 
our fate sample.

Please comment, Carl Eugen
diff --git a/libavcodec/cdgraphics.c b/libavcodec/cdgraphics.c
index aca7cb0..87ad5e7 100644
--- a/libavcodec/cdgraphics.c
+++ b/libavcodec/cdgraphics.c
@@ -49,6 +49,7 @@
 #define CDG_INST_TILE_BLOCK6
 #define CDG_INST_SCROLL_PRESET20
 #define CDG_INST_SCROLL_COPY  24
+#define CDG_INST_TRANSPARENT_COL  28
 #define CDG_INST_LOAD_PAL_LO  30
 #define CDG_INST_LOAD_PAL_HIGH31
 #define CDG_INST_TILE_BLOCK_XOR   38
@@ -67,6 +68,7 @@ typedef struct CDGraphicsContext {
 AVFrame *frame;
 int hscroll;
 int vscroll;
+int transparency;
 } CDGraphicsContext;
 
 static av_cold int cdg_decode_init(AVCodecContext *avctx)
@@ -76,6 +78,7 @@ static av_cold int cdg_decode_init(AVCodecContext *avctx)
 cc->frame = av_frame_alloc();
 if (!cc->frame)
 return AVERROR(ENOMEM);
+cc->transparency = -1;
 
 avctx->width   = CDG_FULL_WIDTH;
 avctx->height  = CDG_FULL_HEIGHT;
@@ -120,6 +123,8 @@ static void cdg_load_palette(CDGraphicsContext *cc, uint8_t 
*data, int low)
 g = ((color >> 4) & 0x000F) * 17;
 b = ((color ) & 0x000F) * 17;
 palette[i + array_offset] = 0xFFU << 24 | r << 16 | g << 8 | b;
+if (cc->transparency >= 0)
+palette[cc->transparency] &= 0xFF;
 }
 cc->frame->palette_has_changed = 1;
 }
@@ -341,6 +346,9 @@ static int cdg_decode_frame(AVCodecContext *avctx,
 if (ret < 0)
 return ret;
 break;
+case CDG_INST_TRANSPARENT_COL:
+cc->transparency = cdg_data[0] & 0xF;
+break;
 default:
 break;
 }
diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index d128c75..8b70b08 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -85,7 +85,7 @@ FATE_VIDEO-$(call DEMDEC, MPEGPS, CAVS) += fate-cavs
 fate-cavs: CMD = framecrc -i $(TARGET_SAMPLES)/cavs/cavs.mpg -an
 
 FATE_VIDEO-$(call DEMDEC, CDG, CDGRAPHICS) += fate-cdgraphics
-fate-cdgraphics: CMD = framecrc -i 
$(TARGET_SAMPLES)/cdgraphics/BrotherJohn.cdg -pix_fmt rgb24 -t 1
+fate-cdgraphics: CMD = framecrc -i 
$(TARGET_SAMPLES)/cdgraphics/BrotherJohn.cdg -pix_fmt rgba -t 1
 
 FATE_VIDEO-$(call DEMDEC, AVI, CLJR) += fate-cljr
 fate-cljr: CMD = framecrc -i $(TARGET_SAMPLES)/cljr/testcljr-partial.avi
diff --git a/tests/ref/fate/cdgraphics b/tests/ref/fate/cdgraphics
index a782059..ee02f5d 100644
--- a/tests/ref/fate/cdgraphics
+++ b/tests/ref/fate/cdgraphics
@@ -1,213 +1,213 @@
 #tb 0: 1/300
-0,  0,  0,1,   194400, 0x46ad80da
-0,  1,  1,1,   194400, 0x46ad80da
-0,  2,  2,1,   194400, 0x9392c3b9
-0,  3,  3,1,   194400, 0x9392c3b9
-0,  4,  4,1,   194400, 0x9392c3b9
-0,  5,  5,1,   194400, 0x9392c3b9
-0,  6,  6,1,   194400, 0x9392c3b9
-0,  7,  7,1,   194400, 0x9392c3b9
-0,  8,  8,1,   194400, 0x9392c3b9
-0,  9,  9,1,   194400, 0x9392c3b9
-0, 10, 10,1,   194400, 0x9392c3b9
-0, 11, 11,1,   194400, 0x9392c3b9
-0, 12, 12,1,   194400, 0x9392c3b9
-0, 13, 13,1,   194400, 0x9392c3b9
-0, 14, 14,1,   194400, 0x9392c3b9
-0, 15, 15,1,   194400, 0x9392c3b9
-0, 16, 16,1,   194400, 0x46ad80da
-0, 17, 17,1,   194400, 0x46ad80da
-0, 18, 18,1,   194400, 0x46ad80da
-0, 19, 19,1,   194400, 0x46ad80da
-0, 20, 20,1,   194400, 0x46ad80da
-0, 21, 21,1,   194400, 0x46ad80da
-0, 22, 22,1,   194400, 0x46ad80da
-0, 23, 23,1,   194400, 0x46ad80da
-0, 24, 24,1,   194400, 0x46ad80da
-0, 25, 25,1,   194400, 0x46ad80da
-0, 26, 26,1,   194400, 0x46ad80da
-0, 27, 27,1,   194400, 0x46ad80da
-0, 28, 28,1,   194400, 0x46ad80da
-0, 29, 29,1,   194400, 0x46ad80da
-0, 30, 30,1,   194400, 0x46ad80da
-0, 31, 31,1,   194400, 0x46ad80da
-0, 32, 32,1,   194400, 0x9392c3b9
-0, 33, 33,1,   194400, 0x9ff8cbb1
-0, 34, 34,1,   194400, 0xd015dba1
-0, 35, 35,1,   194400, 0x6a39f18b
-0, 37, 37,1,   194400, 0x7b8cf983
-0, 38, 38,1,   194400, 0x07a20f7c
-0, 40, 40,1,   194400, 0xa63e2962
-0, 41, 41,1,   194400, 0x2dd54447
-0, 43,   

Re: [FFmpeg-devel] [PATCH] avfilter/vf_removegrain: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

On Mon, Oct 26, 2015 at 5:50 AM, Michael Niedermayer
 wrote:
> On Sun, Oct 25, 2015 at 03:10:27PM -0400, Ganesh Ajjanagadde wrote:
>> filter_slice calls qsort, so qsort is in a performance critical
>> position. AV_QSORT is substantially faster due to the inlining of the
>> comparison callback. Thus, the increase in performance is worth the
>> increase in binary size.
>>
>> Sample benchmark (x86-64, Haswell, GNU/Linux),
>> filter-removegrain-mode-02 (from FATE)
>> new:
>>   24060 decicycles in qsort,   1 runs,  0 skips
>>   15690 decicycles in qsort,   2 runs,  0 skips
>>9307 decicycles in qsort,   4 runs,  0 skips
>>5572 decicycles in qsort,   8 runs,  0 skips
>>3485 decicycles in qsort,  16 runs,  0 skips
>>2517 decicycles in qsort,  32 runs,  0 skips
>>1979 decicycles in qsort,  64 runs,  0 skips
>>1911 decicycles in qsort, 128 runs,  0 skips
>>1568 decicycles in qsort, 256 runs,  0 skips
>>1596 decicycles in qsort, 512 runs,  0 skips
>>1614 decicycles in qsort,1024 runs,  0 skips
>>1874 decicycles in qsort,2046 runs,  2 skips
>>2186 decicycles in qsort,4094 runs,  2 skips
>>
>> old:
>>  246960 decicycles in qsort,   1 runs,  0 skips
>>  135765 decicycles in qsort,   2 runs,  0 skips
>>   70920 decicycles in qsort,   4 runs,  0 skips
>>   37710 decicycles in qsort,   8 runs,  0 skips
>>   20831 decicycles in qsort,  16 runs,  0 skips
>>   12225 decicycles in qsort,  32 runs,  0 skips
>>8083 decicycles in qsort,  64 runs,  0 skips
>>6270 decicycles in qsort, 128 runs,  0 skips
>>5321 decicycles in qsort, 256 runs,  0 skips
>>4860 decicycles in qsort, 512 runs,  0 skips
>>4424 decicycles in qsort,1024 runs,  0 skips
>>4191 decicycles in qsort,2046 runs,  2 skips
>>4934 decicycles in qsort,4094 runs,  2 skips
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vf_removegrain.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> LGTM
>
> thanks

pushed, thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> 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] libavcodec/qsv.c: Re-design session control and internal allocation

[Hendrik Leppkes]

On Mon, Oct 26, 2015 at 12:44 PM, wm4  wrote:
> On Mon, 26 Oct 2015 11:22:38 +0100
> Gwenole Beauchesne  wrote:
>
>
>> >> /**
>> >>  * Hardware Accelerator identifier.
>> >>  *
>> >>  * @note
>> >>  * A hardware accelerator can be device-less. This means that only the
>> >>  * underlying hardware resource, e.g. a Linux dma_buf handle, is being
>> >>  * transported in the AVFrame. That hardware resource could be mapped
>> >>  * through standard OS-dependent calls, e.g. mmap() on Linux.
>> >>  */
>> >> enum AVHWAccelId {
>> >> AV_HWACCEL_ID_NONE = -1,
>> >> AV_HWACCEL_ID_VAAPI,
>> >> AV_HWACCEL_ID_NB,   ///< Not part of ABI
>> >> };
>> >>
>> >> Name to be improved if people have better suggestions, as this really
>> >> is to be seen as HW resource, not necessarily attached to a particular
>> >> HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
>> >> VA surface.
>> >
>> > OK. (Minor nit: if ID_NONE is valid and means HW API without context,
>> > maybe it should be 0, not -1. Also, if it was meant this way, maybe
>> > these should still have their own ID for other purposes.)
>>
>> In my current model, ID_NONE is not meant to be valid because the
>> hwaccel side data shall only exist for hwaccel purposes. Besides,
>> having ID_NONE set to -1 is consistent with other liavu enums and
>> convenient to have ID_NB express directly the exact number of
>> hwaccels.
>
> OK, this makes sense to me.
>
>> >> I am reworking the patch series as I changed my mind again: current
>> >> map strategy was overly complex (and required to be). There were at
>> >> least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
>> >> am now preferring a unique av_hwaccel_frame_get_pixels() defined as
>> >> follow:
>> >>
>> >> /**
>> >>  * Returns AVFrame pixels into linear memory
>> >>  *
>> >>  * This function takes a snapshot of the underlying HW surface and
>> >>  * exposes it to SW backed memory. This may involve a copy from GPU
>> >>  * memory to CPU memory.
>> >>  *
>> >>  * @note
>> >>  * There is no effort underway to commit the modified pixels back to
>> >>  * GPU memory when the \ref dst AVFrame is released.
>> >>  *
>> >>  * @param[in] src   the source frame to read
>> >>  * @param[inout] dstthe target frame to update, or create if NULL
>> >>  * @param[in] flags an optional combination of AV_FRAME_FLAG_xxx flags
>> >>  * @return 0 on success, an AVERROR code on failure.
>> >>  */
>> >> int
>> >> av_hwaccel_frame_get_pixels(AVFrame *src, AVFrame **dst, unsigned flags);
>> >>
>> >> i.e. the cost of allocating and copying AVFrame metadata should be
>> >> less than the actual work needed behind the scene. So, it looks like a
>> >> better interim solution for starters.
>> >
>> > So this is for read-access only, right? If it can map data, there
>> > also needs to be an unmap function, and the user would have to know
>> > about when to use it.
>>
>> Well, put can be implementing by reversing src/dst in this function. :)
>> Actually, this can be av_hwaccel_frame_copy(), but the benefit of
>> having get_pixels() is to leave out the allocation business to lavu
>> and just having the user to bother about _unref().
>
> Also makes sense to me.
>
> What is a problem is that mapped frames and CPU frames (let's call pure
> CPU-allocated surfaces that) are not exactly the same thing. If the API
> user assumes the frame is a CPU frame, it might reference it for a long
> time, which would cause various problems. On the other hand, you don't
> want the user to force copying a frame if it's really a CPU frame.
>
> Maybe this is not really a problem. I'm just mentioning it as another
> detail.
>
>> >> For compatibility, that's also the idea behind another generic
>> >> AV_PIX_FMT_HWACCEL that would enforce data[i] to be clear of any
>> >> user-supplied pointers, and buf[i] shall be filled in by appropriate
>> >> accessors, or while creating the side-data, e.g.
>> >> av_vaapi_frame_create_side_data(). i.e. when lavc swallows up an
>> >> AVFrame with new-style hwaccel, this is where the AV_PIX_FMT_VAAPI
>> >> would be replaced with AV_PIX_FMT_HWACCEL. Replace "swallows up" with
>> >> e.g. av_vaapi_frame_convert_in_place() if you prefer. Otherwise, IMHO,
>> >> the old-style fields should live untouched, hence the need to keep the
>> >> hwaccel side-data around.
>> >
>> > Isn't the problem more about output?
>> >
>> > Again, there's the problem with the current hwaccel API selecting the
>> > hwaccel with get_format(), just using the hwaccel-specific pixfmt.
>>
>> I also envision a need for AVCodecContext.hwaccel_id field + possibly
>> .get_hwaccel(). Just so that to depart from that pixfmt tie.
>
> There are some of us who would like this. Of course it makes the API
> change larger. Also, I do find it useful to have pixfmt distinguish
> between underlying surface types (i.e. the hwaccel API). For example,
> if we add support for hw filters to 

[FFmpeg-devel] [PATCH] lavu/stereo3d: add serialization and deserialization functions

[Rodger Combs]

---
 doc/APIchanges   |   3 ++
 libavutil/Makefile   |   1 +
 libavutil/stereo3d.c | 137 +++
 libavutil/stereo3d.h |  47 
 libavutil/version.h  |   2 +-
 tests/fate/libavutil.mak |   4 ++
 6 files changed, 193 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index f6b583e..f191b81 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2015-10-24 - xxx - lavu 55.5.100 - stereo3d.h
+  Add serialization and deserialization functions for AVStereo3D
+
 2015-10-22 - xxx - lavc 57.9.100 / lavc 57.5.0 - avcodec.h
   Add data and linesize array to AVSubtitleRect, to be used instead of
   the ones from the embedded AVPicture.
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1bac2b9..c924e6e 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -188,6 +188,7 @@ TESTPROGS = adler32 
\
 ripemd  \
 sha \
 sha512  \
+stereo3d\
 softfloat   \
 tree\
 twofish \
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 50cd928..1804268 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -23,6 +23,7 @@
 
 #include "mem.h"
 #include "stereo3d.h"
+#include "bprint.h"
 
 AVStereo3D *av_stereo3d_alloc(void)
 {
@@ -41,3 +42,139 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame)
 
 return (AVStereo3D *)side_data->data;
 }
+
+struct type_name {
+const char *name;
+const char *description;
+};
+
+static const struct type_name type_names[] = {
+[AV_STEREO3D_2D]   = {"2D",   "2D"},
+[AV_STEREO3D_SIDEBYSIDE]   = {"SBS",  "side by side"},
+[AV_STEREO3D_TOPBOTTOM]= {"TB",   "top and bottom"},
+[AV_STEREO3D_FRAMESEQUENCE]= {"FS",   "frame alternate"},
+[AV_STEREO3D_CHECKERBOARD] = {"CB",   "checkerboard"},
+[AV_STEREO3D_SIDEBYSIDE_QUINCUNX]  = {"SBSQ", "side by side (quincunx 
subsampling)"},
+[AV_STEREO3D_LINES]= {"LI",   "interleaved lines"},
+[AV_STEREO3D_COLUMNS]  = {"CI",   "interleaved columns"},
+};
+
+static const struct type_name flag_names[] = {
+[0] = {"INV", "inverted"}
+};
+
+void av_get_stereo3d_string(char *buf, int buf_size, AVStereo3D *stereo3d, int 
humanize)
+{
+AVBPrint bp;
+
+av_bprint_init_for_buffer(, buf, buf_size);
+av_bprint_stereo3d(, stereo3d, humanize);
+}
+
+const char *av_stereo3d_type_get_name(enum AVStereo3DType type)
+{
+if ((unsigned)type >= FF_ARRAY_ELEMS(type_names))
+return NULL;
+return type_names[type].name;
+}
+
+const char *av_stereo3d_type_get_description(enum AVStereo3DType type)
+{
+if ((unsigned)type >= FF_ARRAY_ELEMS(type_names))
+return NULL;
+return type_names[type].description;
+}
+
+void av_bprint_stereo3d(struct AVBPrint *bp, const AVStereo3D *stereo3d, int 
humanize)
+{
+int i;
+
+if ((unsigned)stereo3d->type < FF_ARRAY_ELEMS(type_names))
+av_bprintf(bp, "%s", humanize ? type_names[stereo3d->type].description
+  : type_names[stereo3d->type].name);
+else
+av_bprintf(bp, "%s", humanize ? "unknown" : "UND");
+
+for (i = 0; i < FF_ARRAY_ELEMS(flag_names); i++) {
+if (stereo3d->flags & (1 << i)) {
+if (humanize)
+av_bprintf(bp, " (%s)", flag_names[i].description);
+else
+av_bprintf(bp, "+%s", flag_names[i].name);
+}
+}
+}
+
+int av_get_stereo3d(AVStereo3D *stereo3d, const char *name)
+{
+int found;
+int i;
+const char *end = strchr(name, '+');
+int len;
+
+if (end)
+len = end - name;
+else
+len = strlen(name);
+
+found = 0;
+for (i = 0; i < FF_ARRAY_ELEMS(type_names); i++) {
+if (!strncmp(name, type_names[i].name, len)) {
+stereo3d->type = i;
+found = 1;
+break;
+}
+}
+
+if (!found)
+return AVERROR(EINVAL);
+
+while (end) {
+name = end + 1;
+end = strchr(name, '+');
+if (end)
+len = end - name;
+else
+len = strlen(name);
+
+found = 0;
+for (i = 0; i < FF_ARRAY_ELEMS(flag_names); i++) {
+if (!strncmp(name, flag_names[i].name, len)) {
+stereo3d->flags |= (1 << i);
+found = 1;
+break;
+}
+}

[FFmpeg-devel] [PATCH 10/12] tools/crypto_bench: switch to OpenSSL's faster AES API

[Rodger Combs]

---
 tools/crypto_bench.c | 85 +---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 15bb5f1..8a468ba 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -244,6 +244,7 @@ static void run_lavu_xtea(uint8_t *output,
 #include 
 #include 
 #include 
+#include 
 
 #define DEFINE_CRYPTO_WRAPPER(suffix, function)  \
 static void run_crypto_ ## suffix(uint8_t *output,   \
@@ -258,74 +259,82 @@ DEFINE_CRYPTO_WRAPPER(sha256,SHA256)
 DEFINE_CRYPTO_WRAPPER(sha512,SHA512)
 DEFINE_CRYPTO_WRAPPER(ripemd160, RIPEMD160)
 
-static void run_crypto_aes128(uint8_t *output,
-  const uint8_t *input, unsigned size)
+static void run_crypto_aes128(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_128_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_192_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_256_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_128_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_192_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_256_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_blowfish(uint8_t *output,
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 11/12] tools/crypto_bench: add support for multiple lavu versions by cpuflag

[Rodger Combs]

---
 tools/crypto_bench.c | 50 ++
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 8a468ba..b513c55 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -32,6 +32,7 @@
 #include "libavutil/crc.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/timer.h"
+#include "libavutil/cpu.h"
 
 #ifndef AV_READ_TIME
 #define AV_READ_TIME(x) 0
@@ -65,6 +66,7 @@ struct hash_impl {
 const char *name;
 void (*run)(uint8_t *output, const uint8_t *input, unsigned size);
 const char *output;
+int cpu_versions;
 };
 
 /***
@@ -667,6 +669,16 @@ static unsigned crc32(const uint8_t *data, unsigned size)
 return av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, data, size);
 }
 
+static const struct {
+int flag;
+const char *name;
+} cpu_flag_tab[] = {
+#if ARCH_X86
+{ AV_CPU_FLAG_AESNI, "aesni"  },
+#endif
+{ 0 }
+};
+
 static void run_implementation(const uint8_t *input, uint8_t *output,
struct hash_impl *impl, unsigned size)
 {
@@ -677,9 +689,31 @@ static void run_implementation(const uint8_t *input, 
uint8_t *output,
 double mtime, ttime = 0, ttime2 = 0, stime;
 uint8_t outref[MAX_OUTPUT_SIZE];
 
+if (!strcmp(impl->lib, "lavu")) {
+char lib_name[32];
+struct hash_impl impl2 = *impl;
+int real_flags = av_get_cpu_flags();
+int current_flags = real_flags;
+impl2.cpu_versions = 0;
+impl2.lib = lib_name;
+for (i = 0; cpu_flag_tab[i].flag; i++) {
+if (cpu_flag_tab[i].flag & impl->cpu_versions & real_flags) {
+snprintf(lib_name, sizeof(lib_name), "lavu_%s", 
cpu_flag_tab[i].name);
+run_implementation(input, output, , size);
+current_flags &= ~cpu_flag_tab[i].flag;
+av_force_cpu_flags(current_flags);
+}
+}
+impl2.lib = "lavu_c";
+run_implementation(input, output, , size);
+av_force_cpu_flags(real_flags);
+return;
+}
+
 if (enabled_libs  && !av_stristr(enabled_libs,  impl->lib) ||
 enabled_algos && !av_stristr(enabled_algos, impl->name))
 return;
+
 if (!sscanf(impl->output, "crc:%x", )) {
 outlen = strlen(impl->output) / 2;
 for (i = 0; i < outlen; i++) {
@@ -718,8 +752,8 @@ static void run_implementation(const uint8_t *input, 
uint8_t *output,
 fflush(stdout);
 }
 
-#define IMPL_USE(lib, name, symbol, output) \
-{ #lib, name, run_ ## lib ## _ ## symbol, output },
+#define IMPL_USE(lib, name, symbol, output, ...) \
+{ #lib, name, run_ ## lib ## _ ## symbol, output, __VA_ARGS__ },
 #define IMPL(lib, ...) IMPL_USE_ ## lib(lib, __VA_ARGS__)
 #define IMPL_ALL(...) \
 IMPL(lavu,   __VA_ARGS__) \
@@ -736,12 +770,12 @@ struct hash_impl implementations[] = {
 IMPL(lavu, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
 IMPL(tomcrypt, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
 IMPL_ALL("RIPEMD-160", ripemd160, 
"62a5321e4fc8784903bb43ab7752c75f8b25af00")
-IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888")
-IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b")
-IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a")
-IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe")
-IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8")
-IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c")
+IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c", AV_CPU_FLAG_AESNI)
 IMPL_ALL("CAMELLIA",   camellia,  "crc:7abb59a7")
 IMPL_ALL("CAST-128",   cast128,   "crc:456aa584")
 IMPL_ALL("BLOWFISH",   blowfish,  "crc:33e8aa74")
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Moritz Barsnick]

On Sun, Oct 25, 2015 at 17:35:32 +0100, Nicolas George wrote:
> +@table @option
> +@item limit
> +Time limit for the pauses. Any pause longer than that will be considered
> +a timestamp discontinuity and reset the timer. Default is 2 seconds.
> +@end table
[...]
> +static const AVOption options[] = {
> +{ "limit", "sleep time limit", OFFSET(limit), AV_OPT_TYPE_DURATION, { 
> .i64 = 200 }, 0, INT64_MAX, FLAGS },
> +{ NULL }
> +};

$ ffmpeg -h filter=realtime
[...]
realtime AVOptions:
  limit..FVA... sleep time limit (default 2e+06)


It's misleading to mention "seconds" and to expect microseconds. Or to
mention "2" in one place and "200" in the other.

-> Time limit for the pauses in microseconds. [...]  Default is 200 (2 
seconds).
   [...]
   { "limit", "sleep time limit (in microseconds)", OFFSET(limit), 
AV_OPT_TYPE_DURATION, { .i64 = 200 }, 0, INT64_MAX, FLAGS },

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_removegrain: replace qsort with AV_QSORT

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 03:10:27PM -0400, Ganesh Ajjanagadde wrote:
> filter_slice calls qsort, so qsort is in a performance critical
> position. AV_QSORT is substantially faster due to the inlining of the
> comparison callback. Thus, the increase in performance is worth the
> increase in binary size.
> 
> Sample benchmark (x86-64, Haswell, GNU/Linux),
> filter-removegrain-mode-02 (from FATE)
> new:
>   24060 decicycles in qsort,   1 runs,  0 skips
>   15690 decicycles in qsort,   2 runs,  0 skips
>9307 decicycles in qsort,   4 runs,  0 skips
>5572 decicycles in qsort,   8 runs,  0 skips
>3485 decicycles in qsort,  16 runs,  0 skips
>2517 decicycles in qsort,  32 runs,  0 skips
>1979 decicycles in qsort,  64 runs,  0 skips
>1911 decicycles in qsort, 128 runs,  0 skips
>1568 decicycles in qsort, 256 runs,  0 skips
>1596 decicycles in qsort, 512 runs,  0 skips
>1614 decicycles in qsort,1024 runs,  0 skips
>1874 decicycles in qsort,2046 runs,  2 skips
>2186 decicycles in qsort,4094 runs,  2 skips
> 
> old:
>  246960 decicycles in qsort,   1 runs,  0 skips
>  135765 decicycles in qsort,   2 runs,  0 skips
>   70920 decicycles in qsort,   4 runs,  0 skips
>   37710 decicycles in qsort,   8 runs,  0 skips
>   20831 decicycles in qsort,  16 runs,  0 skips
>   12225 decicycles in qsort,  32 runs,  0 skips
>8083 decicycles in qsort,  64 runs,  0 skips
>6270 decicycles in qsort, 128 runs,  0 skips
>5321 decicycles in qsort, 256 runs,  0 skips
>4860 decicycles in qsort, 512 runs,  0 skips
>4424 decicycles in qsort,1024 runs,  0 skips
>4191 decicycles in qsort,2046 runs,  2 skips
>4934 decicycles in qsort,4094 runs,  2 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vf_removegrain.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[wm4]

On Mon, 26 Oct 2015 11:22:38 +0100
Gwenole Beauchesne  wrote:


> >> /**
> >>  * Hardware Accelerator identifier.
> >>  *
> >>  * @note
> >>  * A hardware accelerator can be device-less. This means that only the
> >>  * underlying hardware resource, e.g. a Linux dma_buf handle, is being
> >>  * transported in the AVFrame. That hardware resource could be mapped
> >>  * through standard OS-dependent calls, e.g. mmap() on Linux.
> >>  */
> >> enum AVHWAccelId {
> >> AV_HWACCEL_ID_NONE = -1,
> >> AV_HWACCEL_ID_VAAPI,
> >> AV_HWACCEL_ID_NB,   ///< Not part of ABI
> >> };
> >>
> >> Name to be improved if people have better suggestions, as this really
> >> is to be seen as HW resource, not necessarily attached to a particular
> >> HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
> >> VA surface.  
> >
> > OK. (Minor nit: if ID_NONE is valid and means HW API without context,
> > maybe it should be 0, not -1. Also, if it was meant this way, maybe
> > these should still have their own ID for other purposes.)  
> 
> In my current model, ID_NONE is not meant to be valid because the
> hwaccel side data shall only exist for hwaccel purposes. Besides,
> having ID_NONE set to -1 is consistent with other liavu enums and
> convenient to have ID_NB express directly the exact number of
> hwaccels.

OK, this makes sense to me.

> >> I am reworking the patch series as I changed my mind again: current
> >> map strategy was overly complex (and required to be). There were at
> >> least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
> >> am now preferring a unique av_hwaccel_frame_get_pixels() defined as
> >> follow:
> >>
> >> /**
> >>  * Returns AVFrame pixels into linear memory
> >>  *
> >>  * This function takes a snapshot of the underlying HW surface and
> >>  * exposes it to SW backed memory. This may involve a copy from GPU
> >>  * memory to CPU memory.
> >>  *
> >>  * @note
> >>  * There is no effort underway to commit the modified pixels back to
> >>  * GPU memory when the \ref dst AVFrame is released.
> >>  *
> >>  * @param[in] src   the source frame to read
> >>  * @param[inout] dstthe target frame to update, or create if NULL
> >>  * @param[in] flags an optional combination of AV_FRAME_FLAG_xxx flags
> >>  * @return 0 on success, an AVERROR code on failure.
> >>  */
> >> int
> >> av_hwaccel_frame_get_pixels(AVFrame *src, AVFrame **dst, unsigned flags);
> >>
> >> i.e. the cost of allocating and copying AVFrame metadata should be
> >> less than the actual work needed behind the scene. So, it looks like a
> >> better interim solution for starters.  
> >
> > So this is for read-access only, right? If it can map data, there
> > also needs to be an unmap function, and the user would have to know
> > about when to use it.  
> 
> Well, put can be implementing by reversing src/dst in this function. :)
> Actually, this can be av_hwaccel_frame_copy(), but the benefit of
> having get_pixels() is to leave out the allocation business to lavu
> and just having the user to bother about _unref().

Also makes sense to me.

What is a problem is that mapped frames and CPU frames (let's call pure
CPU-allocated surfaces that) are not exactly the same thing. If the API
user assumes the frame is a CPU frame, it might reference it for a long
time, which would cause various problems. On the other hand, you don't
want the user to force copying a frame if it's really a CPU frame.

Maybe this is not really a problem. I'm just mentioning it as another
detail.

> >> For compatibility, that's also the idea behind another generic
> >> AV_PIX_FMT_HWACCEL that would enforce data[i] to be clear of any
> >> user-supplied pointers, and buf[i] shall be filled in by appropriate
> >> accessors, or while creating the side-data, e.g.
> >> av_vaapi_frame_create_side_data(). i.e. when lavc swallows up an
> >> AVFrame with new-style hwaccel, this is where the AV_PIX_FMT_VAAPI
> >> would be replaced with AV_PIX_FMT_HWACCEL. Replace "swallows up" with
> >> e.g. av_vaapi_frame_convert_in_place() if you prefer. Otherwise, IMHO,
> >> the old-style fields should live untouched, hence the need to keep the
> >> hwaccel side-data around.  
> >
> > Isn't the problem more about output?
> >
> > Again, there's the problem with the current hwaccel API selecting the
> > hwaccel with get_format(), just using the hwaccel-specific pixfmt.  
> 
> I also envision a need for AVCodecContext.hwaccel_id field + possibly
> .get_hwaccel(). Just so that to depart from that pixfmt tie.

There are some of us who would like this. Of course it makes the API
change larger. Also, I do find it useful to have pixfmt distinguish
between underlying surface types (i.e. the hwaccel API). For example,
if we add support for hw filters to libavfilter, how would you prevent
that a vdpau filter takes vaapi surfaces as input?

So I'm not sure if a single AV_PIX_FMT_HWACCEL is the way to go, even
if we make access to 

[FFmpeg-devel] [PATCH 12/12] FATE: add crypto protocol test

[Rodger Combs]

---
 tests/fate/avformat.mak| 1 +
 tests/lavf-regression.sh   | 8 
 tests/ref/lavf-fate/crypto | 3 +++
 3 files changed, 12 insertions(+)
 create mode 100644 tests/ref/lavf-fate/crypto

diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 1d13434..21b8f8a 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -68,6 +68,7 @@ fate-lavf: $(FATE_LAVF)
 FATE_LAVF_FATE-$(call ALLYES, MATROSKA_DEMUXER   OGG_MUXER)  += ogg_vp3
 FATE_LAVF_FATE-$(call ALLYES, MOV_DEMUXERLATM_MUXER) += latm
 FATE_LAVF_FATE-$(call ALLYES, MP3_DEMUXERMP3_MUXER)  += mp3
+FATE_LAVF_FATE-$(call ALLYES, NUT_MUXER  CRYPTO_PROTOCOL)+= crypto
 
 FATE_LAVF_FATE +=  $(FATE_LAVF_FATE-yes:%=fate-lavf-fate-%)
 $(FATE_LAVF_FATE): CMD = lavffatetest
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index a37f714..5c90ae8 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-regression.sh
@@ -168,6 +168,14 @@ if [ -n "$do_wtv" ] ; then
 do_lavf wtv "" "-acodec mp2 -threads 1"
 fi
 
+if [ -n "$do_crypto" ] ; then
+crypto_flags="-key 0123456789abcdef0011223344556677 -iv 
aabbccddeeff1133557799987654"
+file=${target_path}/${outfile}lavf.crypto.nut
+run_avconv $DEC_OPTS -f image2 -vcodec pgmyuv -i $raw_src $DEC_OPTS -ar 44100 
-f s16le -i $pcm_src $ENC_OPTS -b:a 64k -t 1 -qscale:v 10 -acodec mp2 -ab 64k 
-ar 44100 -threads 1 $crypto_flags crypto:$file
+do_md5sum $file
+echo $(wc -c $file)
+do_avconv_crc crypto $DEC_OPTS $crypto_flags -i crypto:$file
+fi
 
 # streamed images
 # mjpeg
diff --git a/tests/ref/lavf-fate/crypto b/tests/ref/lavf-fate/crypto
new file mode 100644
index 000..a993a7b
--- /dev/null
+++ b/tests/ref/lavf-fate/crypto
@@ -0,0 +1,3 @@
+a12b1a78ebc04786a694394a4d6d6c41 
*/Users/rcombs/source/ffmpeg/./tests/data/lavf-fate/lavf.crypto.nut
+319968 /Users/rcombs/source/ffmpeg/./tests/data/lavf-fate/lavf.crypto.nut
+crypto CRC=0xec6c3c68
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 04/12] lavu/aes: align AVAES struct members

[Rodger Combs]

---
 libavutil/aes_internal.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavutil/aes_internal.h b/libavutil/aes_internal.h
index e5bf4bd..4944258 100644
--- a/libavutil/aes_internal.h
+++ b/libavutil/aes_internal.h
@@ -21,6 +21,7 @@
 #ifndef AVUTIL_AES_INTERNAL_H
 #define AVUTIL_AES_INTERNAL_H
 
+#include "mem.h"
 #include 
 
 typedef union {
@@ -33,8 +34,8 @@ typedef union {
 typedef struct AVAES {
 // Note: round_key[16] is accessed in the init code, but this only
 // overwrites state, which does not matter (see also commit ba554c0).
-av_aes_block round_key[15];
-av_aes_block state[2];
+DECLARE_ALIGNED(16, av_aes_block, round_key)[15];
+DECLARE_ALIGNED(16, av_aes_block, state)[2];
 int rounds;
 void (*crypt)(struct AVAES *a, uint8_t *dst, const uint8_t *src, int 
count, uint8_t *iv, int rounds);
 } AVAES;
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 02/12] lavu/aes: move AVAES to separate internal header

[Rodger Combs]

---
 libavutil/aes.c  | 16 +---
 libavutil/aes_internal.h | 41 +
 2 files changed, 42 insertions(+), 15 deletions(-)
 create mode 100644 libavutil/aes_internal.h

diff --git a/libavutil/aes.c b/libavutil/aes.c
index b59e7de..61e9dd1 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -22,24 +22,10 @@
 
 #include "common.h"
 #include "aes.h"
+#include "aes_internal.h"
 #include "intreadwrite.h"
 #include "timer.h"
 
-typedef union {
-uint64_t u64[2];
-uint32_t u32[4];
-uint8_t u8x4[4][4];
-uint8_t u8[16];
-} av_aes_block;
-
-typedef struct AVAES {
-// Note: round_key[16] is accessed in the init code, but this only
-// overwrites state, which does not matter (see also commit ba554c0).
-av_aes_block round_key[15];
-av_aes_block state[2];
-int rounds;
-} AVAES;
-
 const int av_aes_size= sizeof(AVAES);
 
 struct AVAES *av_aes_alloc(void)
diff --git a/libavutil/aes_internal.h b/libavutil/aes_internal.h
new file mode 100644
index 000..e2841ef
--- /dev/null
+++ b/libavutil/aes_internal.h
@@ -0,0 +1,41 @@
+/*
+ * copyright (c) 2015 Rodger Combs 
+ *
+ * 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_AES_INTERNAL_H
+#define AVUTIL_AES_INTERNAL_H
+
+#include 
+
+typedef union {
+uint64_t u64[2];
+uint32_t u32[4];
+uint8_t u8x4[4][4];
+uint8_t u8[16];
+} av_aes_block;
+
+typedef struct AVAES {
+// Note: round_key[16] is accessed in the init code, but this only
+// overwrites state, which does not matter (see also commit ba554c0).
+av_aes_block round_key[15];
+av_aes_block state[2];
+int rounds;
+} AVAES;
+
+#endif /* AVUTIL_AES_INTERNAL_H */
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 06/12] lavu/aes: add x86 AESNI optimizations

[Rodger Combs]

crypto_bench comparison for AES-128-ECB:

lavu_aesni AES-128-ECB  size: 1048576  runs:   1024  time:0.596 +- 0.081
lavu_c AES-128-ECB  size: 1048576  runs:   1024  time:   17.007 +- 2.131
crypto AES-128-ECB  size: 1048576  runs:   1024  time:0.612 +- 1.857
gcrypt AES-128-ECB  size: 1048576  runs:   1024  time:1.123 +- 0.224
tomcrypt   AES-128-ECB  size: 1048576  runs:   1024  time:9.038 +- 0.790

Improved-By: Henrik Gramner 
---
 libavutil/aes.c  |  4 +++
 libavutil/aes_internal.h |  2 ++
 libavutil/x86/Makefile   |  4 ++-
 libavutil/x86/aes.asm| 92 
 libavutil/x86/aes_init.c | 37 +++
 5 files changed, 138 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/x86/aes.asm
 create mode 100644 libavutil/x86/aes_init.c

diff --git a/libavutil/aes.c b/libavutil/aes.c
index 4b871a0..40db681 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -161,6 +161,8 @@ static void aes_decrypt(AVAES *a, uint8_t *dst, const 
uint8_t *src,
 void av_aes_crypt(AVAES *a, uint8_t *dst, const uint8_t *src,
   int count, uint8_t *iv, int decrypt)
 {
+if (count <= 0)
+return;
 a->crypt(a, dst, src, count, iv, a->rounds);
 }
 
@@ -200,6 +202,8 @@ int av_aes_init(AVAES *a, const uint8_t *key, int key_bits, 
int decrypt)
 uint8_t alog8[512];
 
 a->crypt = decrypt ? aes_decrypt : aes_encrypt;
+if (ARCH_X86)
+ff_init_aes_x86(a, decrypt);
 
 if 
(!enc_multbl[FF_ARRAY_ELEMS(enc_multbl)-1][FF_ARRAY_ELEMS(enc_multbl[0])-1]) {
 j = 1;
diff --git a/libavutil/aes_internal.h b/libavutil/aes_internal.h
index 4944258..dfa2039 100644
--- a/libavutil/aes_internal.h
+++ b/libavutil/aes_internal.h
@@ -40,4 +40,6 @@ typedef struct AVAES {
 void (*crypt)(struct AVAES *a, uint8_t *dst, const uint8_t *src, int 
count, uint8_t *iv, int rounds);
 } AVAES;
 
+void ff_init_aes_x86(AVAES *a, int decrypt);
+
 #endif /* AVUTIL_AES_INTERNAL_H */
diff --git a/libavutil/x86/Makefile b/libavutil/x86/Makefile
index eb70a62..4ac6219 100644
--- a/libavutil/x86/Makefile
+++ b/libavutil/x86/Makefile
@@ -1,4 +1,5 @@
-OBJS += x86/cpu.o   \
+OBJS += x86/aes_init.o  \
+x86/cpu.o   \
 x86/float_dsp_init.o\
 x86/lls_init.o  \
 
@@ -10,5 +11,6 @@ YASM-OBJS += x86/cpuid.o  
  \
  $(EMMS_OBJS__yes_)  \
  x86/float_dsp.o\
  x86/lls.o  \
+ x86/aes.o  \
 
 YASM-OBJS-$(CONFIG_PIXELUTILS) += x86/pixelutils.o  \
diff --git a/libavutil/x86/aes.asm b/libavutil/x86/aes.asm
new file mode 100644
index 000..57d87f9
--- /dev/null
+++ b/libavutil/x86/aes.asm
@@ -0,0 +1,92 @@
+;*
+;* Copyright (c) 2015 Rodger Combs 
+;*
+;* 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
+;**
+
+%include "x86util.asm"
+
+SECTION .text
+
+;-
+; void ff_aes_decrypt(AVAES *a, uint8_t *dst, const uint8_t *src,
+; int count, uint8_t *iv, int rounds)
+;-
+%macro AES_CRYPT 1
+cglobal aes_%1rypt, 6,6,2
+shl  r3d, 4
+add  r5d, r5d
+add   r0, 0x60
+add   r2, r3
+add   r1, r3
+neg   r3
+pxor  m1, m1
+test  r4, r4
+je .block
+movu  m1, [r4] ; iv
+.block:
+movu  m0, [r2+r3] ; state
+%ifidn %1, enc
+pxor  m0, m1
+%endif
+pxor  m0, [r0+8*r5-0x60]
+cmp  r5d, 24
+je .rounds12
+jl .rounds10
+aes%1 m0, [r0+0x70]
+

[FFmpeg-devel] [PATCH 05/12] lavu/aes: test CBC functionality

[Rodger Combs]

---
 libavutil/aes.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavutil/aes.c b/libavutil/aes.c
index 4fa01ea..4b871a0 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -280,7 +280,7 @@ int main(int argc, char **argv)
 { 0x10, 0xa5, 0x88, 0x69, 0xd7, 0x4b, 0xe5, 0xa3,
   0x74, 0xcf, 0x86, 0x7c, 0xfb, 0x47, 0x38, 0x59 }
 };
-uint8_t pt[16], rpt[2][16]= {
+uint8_t pt[32], rpt[2][16]= {
 { 0x6a, 0x84, 0x86, 0x7c, 0xd7, 0x7e, 0x12, 0xad,
   0x07, 0xea, 0x1b, 0xe8, 0x95, 0xc5, 0x3f, 0xa3 },
 { 0 }
@@ -291,7 +291,8 @@ int main(int argc, char **argv)
 { 0x6d, 0x25, 0x1e, 0x69, 0x44, 0xb0, 0x51, 0xe0,
   0x4e, 0xaa, 0x6f, 0xb4, 0xdb, 0xf7, 0x84, 0x65 }
 };
-uint8_t temp[16];
+uint8_t temp[32];
+uint8_t iv[2][16];
 int err = 0;
 
 av_log_set_level(AV_LOG_DEBUG);
@@ -317,16 +318,19 @@ int main(int argc, char **argv)
 av_lfg_init(, 1);
 
 for (i = 0; i < 1; i++) {
-for (j = 0; j < 16; j++) {
+for (j = 0; j < 32; j++) {
 pt[j] = av_lfg_get();
 }
+for (j = 0; j < 16; j++) {
+iv[0][j] = iv[1][j] = av_lfg_get();
+}
 {
 START_TIMER;
-av_aes_crypt(, temp, pt, 1, NULL, 0);
+av_aes_crypt(, temp, pt, 2, iv[0], 0);
 if (!(i & (i - 1)))
 av_log(NULL, AV_LOG_ERROR, "%02X %02X %02X %02X\n",
temp[0], temp[5], temp[10], temp[15]);
-av_aes_crypt(, temp, temp, 1, NULL, 1);
+av_aes_crypt(, temp, temp, 2, iv[1], 1);
 STOP_TIMER("aes");
 }
 for (j = 0; j < 16; j++) {
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 01/12] lavu: add AESNI CPU flag

[Rodger Combs]

---
 configure |  4 
 doc/APIchanges|  3 +++
 libavutil/cpu.c   |  4 
 libavutil/cpu.h   |  1 +
 libavutil/version.h   |  2 +-
 libavutil/x86/cpu.c   |  2 ++
 libavutil/x86/cpu.h   |  3 +++
 libavutil/x86/x86inc.asm  | 13 +++--
 tests/checkasm/checkasm.c |  1 +
 9 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/configure b/configure
index a38b290..340c7e7 100755
--- a/configure
+++ b/configure
@@ -368,6 +368,7 @@ Optimization options (experts only):
   --disable-fma3   disable FMA3 optimizations
   --disable-fma4   disable FMA4 optimizations
   --disable-avx2   disable AVX2 optimizations
+  --disable-aesni  disable AESNI optimizations
   --disable-armv5tedisable armv5te optimizations
   --disable-armv6  disable armv6 optimizations
   --disable-armv6t2disable armv6t2 optimizations
@@ -1635,6 +1636,7 @@ ARCH_EXT_LIST_LOONGSON="
 "
 
 ARCH_EXT_LIST_X86_SIMD="
+aesni
 amd3dnow
 amd3dnowext
 avx
@@ -2128,6 +2130,7 @@ sse3_deps="sse2"
 ssse3_deps="sse3"
 sse4_deps="ssse3"
 sse42_deps="sse4"
+aesni_deps="sse42"
 avx_deps="sse42"
 xop_deps="avx"
 fma3_deps="avx"
@@ -6010,6 +6013,7 @@ if enabled x86; then
 echo "3DNow! extended enabled   ${amd3dnowext-no}"
 echo "SSE enabled   ${sse-no}"
 echo "SSSE3 enabled ${ssse3-no}"
+echo "AESNI enabled ${aesni-no}"
 echo "AVX enabled   ${avx-no}"
 echo "XOP enabled   ${xop-no}"
 echo "FMA3 enabled  ${fma3-no}"
diff --git a/doc/APIchanges b/doc/APIchanges
index f6b583e..206ced3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2015-10-11 - xxx - lavu 57.5.100 - cpu.h
+  Add AV_CPU_FLAG_AESNI.
+
 2015-10-22 - xxx - lavc 57.9.100 / lavc 57.5.0 - avcodec.h
   Add data and linesize array to AVSubtitleRect, to be used instead of
   the ones from the embedded AVPicture.
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index c64baf9..1acae01 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -118,6 +118,7 @@ int av_parse_cpu_flags(const char *s)
 #define CPUFLAG_FMA4 (AV_CPU_FLAG_FMA4 | CPUFLAG_AVX)
 #define CPUFLAG_AVX2 (AV_CPU_FLAG_AVX2 | CPUFLAG_AVX)
 #define CPUFLAG_BMI2 (AV_CPU_FLAG_BMI2 | AV_CPU_FLAG_BMI1)
+#define CPUFLAG_AESNI(AV_CPU_FLAG_AESNI| CPUFLAG_SSE42)
 static const AVOption cpuflags_opts[] = {
 { "flags"   , NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 }, INT64_MIN, 
INT64_MAX, .unit = "flags" },
 #if   ARCH_PPC
@@ -145,6 +146,7 @@ int av_parse_cpu_flags(const char *s)
 { "3dnow"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_3DNOW   
 },.unit = "flags" },
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_3DNOWEXT
 },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
+{ "aesni"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AESNI   
 },.unit = "flags" },
 #elif ARCH_ARM
 { "armv5te",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV5TE 
 },.unit = "flags" },
 { "armv6",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV6   
 },.unit = "flags" },
@@ -205,6 +207,7 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
 { "3dnow"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_3DNOW   
 },.unit = "flags" },
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_3DNOWEXT },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
+{ "aesni",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AESNI   
 },.unit = "flags" },
 
 #define CPU_FLAG_P2 AV_CPU_FLAG_CMOV | AV_CPU_FLAG_MMX
 #define CPU_FLAG_P3 CPU_FLAG_P2 | AV_CPU_FLAG_MMX2 | AV_CPU_FLAG_SSE
@@ -340,6 +343,7 @@ static const struct {
 { AV_CPU_FLAG_AVX2,  "avx2"   },
 { AV_CPU_FLAG_BMI1,  "bmi1"   },
 { AV_CPU_FLAG_BMI2,  "bmi2"   },
+{ AV_CPU_FLAG_AESNI, "aesni"  },
 #endif
 { 0 }
 };
diff --git a/libavutil/cpu.h b/libavutil/cpu.h
index 9403eca..bff8518 100644
--- a/libavutil/cpu.h
+++ b/libavutil/cpu.h
@@ -42,6 +42,7 @@
 #define AV_CPU_FLAG_ATOM 0x1000 ///< Atom processor, some SSSE3 
instructions are slower
 #define AV_CPU_FLAG_SSE4 0x0100 ///< Penryn SSE4.1 functions
 #define AV_CPU_FLAG_SSE420x0200 ///< Nehalem SSE4.2 functions
+#define AV_CPU_FLAG_AESNI   0x8 ///< Advanced Encryption Standard 
functions
 #define AV_CPU_FLAG_AVX  0x4000 ///< AVX functions: requires OS 
support even if YMM registers aren't used
 #define AV_CPU_FLAG_AVXSLOW   0x800 ///< AVX supported, but slow when 
using YMM registers (e.g. Bulldozer)
 #define AV_CPU_FLAG_XOP 

[FFmpeg-devel] [PATCH 09/12] tools/crypto_bench: add AES-CBC modes

[Rodger Combs]

---
 tools/crypto_bench.c | 140 +--
 1 file changed, 137 insertions(+), 3 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index ad20f95..15bb5f1 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -52,6 +52,7 @@ static const char *enabled_algos;
 static unsigned specified_runs;
 
 static const uint8_t *hardcoded_key = "FFmpeg is the best program ever.";
+static const uint8_t hardcoded_iv[16] = {0};
 
 static void fatal_error(const char *tag)
 {
@@ -136,6 +137,39 @@ static void run_lavu_aes256(uint8_t *output, const uint8_t 
*input, unsigned size
 av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
 }
 
+static void run_lavu_aes128cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 128, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
+static void run_lavu_aes192cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 192, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
+static void run_lavu_aes256cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 256, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
 static void run_lavu_blowfish(uint8_t *output,
   const uint8_t *input, unsigned size)
 {
@@ -258,6 +292,42 @@ static void run_crypto_aes256(uint8_t *output, const 
uint8_t *input, unsigned si
 AES_encrypt(input + i, output + i, );
 }
 
+static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 128, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
+static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 192, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
+static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 256, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
 static void run_crypto_blowfish(uint8_t *output,
 const uint8_t *input, unsigned size)
 {
@@ -355,6 +425,39 @@ static void run_gcrypt_aes256(uint8_t *output, const 
uint8_t *input, unsigned si
 gcry_cipher_encrypt(aes, output, size, input, size);
 }
 
+static void run_gcrypt_aes128cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 16);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
+static void run_gcrypt_aes192cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES192, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 24);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
+static void run_gcrypt_aes256cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES256, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 32);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
 static void run_gcrypt_blowfish(uint8_t *output,
 const uint8_t *input, unsigned size)
 {
@@ -459,6 +562,30 @@ static void run_tomcrypt_aes256(uint8_t *output, const 
uint8_t *input, unsigned
 

Re: [FFmpeg-devel] [PATCH] lavu/opt: enhance printing durations.

[Nicolas George]

Le quintidi 5 brumaire, an CCXXIV, Clement Boesch a écrit :
> > Note: While I am touching the options code, I have this crazy idea about
> > replacing AV_OPT_TYPE_* that would allow to get out of escaping hell
> > completely. I will not have time to act on it soon, but if someone wants to
> > hear about it...
> What escaping are you talking about?

All the levels of backslashes you have to put before delimiters. For
example, if you want to put a two minutes duration in a filter graph
description, you can not write "testsrc=d=2:00", because the colon will
delimit the option. You have to write a largish number of backslashes in
front of the colon. It becomes ever worse when nesting values: think of
colons inside the localtime expansion inside the text option of the drawtext
filter.

I believe we could avoid that almost entirely.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: add testsrc2 test source.

[Nicolas George]

Le quintidi 5 brumaire, an CCXXIV, Clement Boesch a écrit :
> Same. I also think the noise could get some improvement with a wider
> color spectrum.

I agree, but unfortunately, there is no drawutils API to blend a colored
mask. It would be necessary to write one, and I do not want to spend too
much effort on this.

I could change the color pseudo-randomly between the squares instead of
making just a checkered pattern. Or I could blend random noise in red, then
green then blue in a random order (alpha blending does not commute). Any
suggestion?

Also: I agree that testsrc2 is not the best name ever, but I have no idea
what to make of it. It could be testsrc with an option to select the mode,
the default being the old mode (then printing a warning that the default
will change, then changing the default). Again, what do people prefer?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/stereo3d: add serialization and deserialization functions

[Michael Niedermayer]

On Mon, Oct 26, 2015 at 02:05:54AM -0500, Rodger Combs wrote:
> ---
>  doc/APIchanges   |   3 ++
>  libavutil/Makefile   |   1 +
>  libavutil/stereo3d.c | 137 
> +++
>  libavutil/stereo3d.h |  47 
>  libavutil/version.h  |   2 +-
>  tests/fate/libavutil.mak |   4 ++
>  6 files changed, 193 insertions(+), 1 deletion(-)

did you forget to add a file ?

reference file './tests/ref/fate/stereo3d' not found
./tests/fate-run.sh: 287: ./tests/fate-run.sh: cannot open 
tests/data/fate/stereo3d.diff: No such file
Test stereo3d failed. Look at tests/data/fate/stereo3d.err for details.
make: *** [fate-stereo3d] Error 1
make: *** Waiting for unfinished jobs

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Moritz Barsnick]

> This is how it works with fields of type AV_OPT_TYPE_DURATION: the value is
> internally in microseconds (AV_TIME_BASE), but the user interface converts
> the strings in seconds, multiplying them by 100, or even in
> H:MM:SS.DD.

Ah, I missed that fact. I just scanned "ffmpeg -h full" for other
options using microseconds and how they document them - not their
actual source and the type.

> The display of the default value is inconsistent, though. I just sent a
> patch about it.

Good work.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[Clément Bœsch]

On Sun, Oct 25, 2015 at 01:53:07AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> Heres another suggested addition to the voting committee
> also off topic but i wonder if "[DECISSION]" in the subject is the best
> choice for this
> 
> I Suggest to add all people who pushed or pull-requested 20 or more commits
> according to the commiter field in the last year (the initial voting committee
> members where based on the Author field)
> 
> I used the following to generate the list (this sadly can still change if
> people push changes with commit dates in the past, i suggest that such cases
> wont be considered)
> The command explicitly excludes "enemy merges" as these have not been
> requested by the commiters
> excluding all merges results in a list with the same people just
> somewhat different numbers
> 
> git log libav/master..master --no-merges  --since=2014-10-25T00:00:00Z 
> --until 2015-10-25T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 
> 's/<.*//' |sort | uniq -c | sort -nr
> 
> most of these developers are already in the voting committee
> here is the list that command generated locally at around 1 o clock local time
> 
>3691 Commit: Michael Niedermayer
> 334 Commit: Paul B Mahol
> 242 Commit: Clément Bœsch
> 205 Commit: Carl Eugen Hoyos
> 203 Commit: James Almer
> 154 Commit: Ronald S. Bultje
> 115 Commit: Rostislav Pehlivanov
>  88 Commit: Lukasz Marek
>  77 Commit: Andreas Cadhalpun
>  64 Commit: Reynaldo H. Verdejo Pinochet
>  56 Commit: Stefano Sabatini
>  44 Commit: Hendrik Leppkes
>  40 Commit: Marton Balint
>  39 Commit: Nicolas George
>  38 Commit: Philip Langdale
>  37 Commit: Timothy Gu
>  29 Commit: wm4
>  27 Commit: Ganesh Ajjanagadde
>  20 Commit: Reimar Döffinger
>  20 Commit: Lou Logan
> 
> The newly added developers would be
> Ganesh Ajjanagadde
> Lou Logan
> Marton Balint
> Philip Langdale
> Reimar Döffinger
> 
> All of them have also contributed significantly outside of just self
> pushed commits.
> I belive they all should be on the voting comittee
> 

Sure.

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/opt: enhance printing durations.

[Clément Bœsch]

On Mon, Oct 26, 2015 at 09:56:37PM +0100, Nicolas George wrote:
> Le quintidi 5 brumaire, an CCXXIV, Clement Boesch a écrit :
> > > Note: While I am touching the options code, I have this crazy idea about
> > > replacing AV_OPT_TYPE_* that would allow to get out of escaping hell
> > > completely. I will not have time to act on it soon, but if someone wants 
> > > to
> > > hear about it...
> > What escaping are you talking about?
> 
> All the levels of backslashes you have to put before delimiters. For
> example, if you want to put a two minutes duration in a filter graph
> description, you can not write "testsrc=d=2:00", because the colon will
> delimit the option. You have to write a largish number of backslashes in
> front of the colon. It becomes ever worse when nesting values: think of
> colons inside the localtime expansion inside the text option of the drawtext
> filter.
> 
> I believe we could avoid that almost entirely.
> 

Oh. Wasn't "testsrc=d='2:00'" supposed to work, just like comma & friends
in eval inside filters options?

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee

[Clément Bœsch]

On Mon, Oct 26, 2015 at 09:55:05PM +0100, Paul B Mahol wrote:
> On 10/26/15, Clement Boesch  wrote:
> > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clement Boesch wrote:
> >> Hi Voting Committee
> >>
> >> This mail is an attempt to try out the process described on
> >> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html
> >>
> >> This thread is a call for the following people:
> >> Michael Niedermayer
> >> Clement Boesch
> >> James Almer
> >> Paul B Mahol
> >> Carl Eugen Hoyos
> >> Andreas Cadhalpun
> >> Ronald S. Bultje
> >> wm4
> >> Lukasz Marek
> >> Rostislav Pehlivanov
> >> Hendrik Leppkes
> >> Christophe Gisquet
> >> Reynaldo H. Verdejo Pinochet
> >>
> >> As a first discussion, I'd like to discuss the introduction of new people
> >> to
> >> this list (alphabetical order).
> >>
> >> Nicolas George
> >> Rodger Combs
> >> Stefano Sabatini
> >> Timothy Gu
> >>
> >> I personally would like these people to join the group.
> >>
> >
> > Paul, Ronald, wm4, Hendrik, Christophe (and myself) agreed to all these
> > people joining the committee. The other remained silent.
> >
> > 46% OK
> > 54% No opinion
> > 0%  Refused
> >
> > The voting committee now includes the following people:
> >
> >  Michael Niedermayer
> >  Clement Boesch
> >  James Almer
> >  Paul B Mahol
> >  Carl Eugen Hoyos
> >  Andreas Cadhalpun
> >  Ronald S. Bultje
> >  wm4
> >  Lukasz Marek
> >  Rostislav Pehlivanov
> >  Hendrik Leppkes
> >  Christophe Gisquet
> >  Reynaldo H. Verdejo Pinochet
> >  Nicolas George
> >  Rodger Combs
> >  Stefano Sabatini
> >  Timothy Gu
> 
> I object 4th position on this list, i should be on 2nd position ;-/

You should always aim for the top. Don't be so modest.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavu/stereo3d: add serialization and deserialization functions

[Rodger Combs]

---
 doc/APIchanges   |   3 ++
 libavutil/Makefile   |   1 +
 libavutil/stereo3d.c | 137 +++
 libavutil/stereo3d.h |  47 
 libavutil/version.h  |   2 +-
 tests/fate/libavutil.mak |   4 ++
 tests/ref/fate/stereo3d  |  16 ++
 7 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/stereo3d

diff --git a/doc/APIchanges b/doc/APIchanges
index f6b583e..f191b81 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2015-10-24 - xxx - lavu 55.5.100 - stereo3d.h
+  Add serialization and deserialization functions for AVStereo3D
+
 2015-10-22 - xxx - lavc 57.9.100 / lavc 57.5.0 - avcodec.h
   Add data and linesize array to AVSubtitleRect, to be used instead of
   the ones from the embedded AVPicture.
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1bac2b9..c924e6e 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -188,6 +188,7 @@ TESTPROGS = adler32 
\
 ripemd  \
 sha \
 sha512  \
+stereo3d\
 softfloat   \
 tree\
 twofish \
diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 50cd928..1804268 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -23,6 +23,7 @@
 
 #include "mem.h"
 #include "stereo3d.h"
+#include "bprint.h"
 
 AVStereo3D *av_stereo3d_alloc(void)
 {
@@ -41,3 +42,139 @@ AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame)
 
 return (AVStereo3D *)side_data->data;
 }
+
+struct type_name {
+const char *name;
+const char *description;
+};
+
+static const struct type_name type_names[] = {
+[AV_STEREO3D_2D]   = {"2D",   "2D"},
+[AV_STEREO3D_SIDEBYSIDE]   = {"SBS",  "side by side"},
+[AV_STEREO3D_TOPBOTTOM]= {"TB",   "top and bottom"},
+[AV_STEREO3D_FRAMESEQUENCE]= {"FS",   "frame alternate"},
+[AV_STEREO3D_CHECKERBOARD] = {"CB",   "checkerboard"},
+[AV_STEREO3D_SIDEBYSIDE_QUINCUNX]  = {"SBSQ", "side by side (quincunx 
subsampling)"},
+[AV_STEREO3D_LINES]= {"LI",   "interleaved lines"},
+[AV_STEREO3D_COLUMNS]  = {"CI",   "interleaved columns"},
+};
+
+static const struct type_name flag_names[] = {
+[0] = {"INV", "inverted"}
+};
+
+void av_get_stereo3d_string(char *buf, int buf_size, AVStereo3D *stereo3d, int 
humanize)
+{
+AVBPrint bp;
+
+av_bprint_init_for_buffer(, buf, buf_size);
+av_bprint_stereo3d(, stereo3d, humanize);
+}
+
+const char *av_stereo3d_type_get_name(enum AVStereo3DType type)
+{
+if ((unsigned)type >= FF_ARRAY_ELEMS(type_names))
+return NULL;
+return type_names[type].name;
+}
+
+const char *av_stereo3d_type_get_description(enum AVStereo3DType type)
+{
+if ((unsigned)type >= FF_ARRAY_ELEMS(type_names))
+return NULL;
+return type_names[type].description;
+}
+
+void av_bprint_stereo3d(struct AVBPrint *bp, const AVStereo3D *stereo3d, int 
humanize)
+{
+int i;
+
+if ((unsigned)stereo3d->type < FF_ARRAY_ELEMS(type_names))
+av_bprintf(bp, "%s", humanize ? type_names[stereo3d->type].description
+  : type_names[stereo3d->type].name);
+else
+av_bprintf(bp, "%s", humanize ? "unknown" : "UND");
+
+for (i = 0; i < FF_ARRAY_ELEMS(flag_names); i++) {
+if (stereo3d->flags & (1 << i)) {
+if (humanize)
+av_bprintf(bp, " (%s)", flag_names[i].description);
+else
+av_bprintf(bp, "+%s", flag_names[i].name);
+}
+}
+}
+
+int av_get_stereo3d(AVStereo3D *stereo3d, const char *name)
+{
+int found;
+int i;
+const char *end = strchr(name, '+');
+int len;
+
+if (end)
+len = end - name;
+else
+len = strlen(name);
+
+found = 0;
+for (i = 0; i < FF_ARRAY_ELEMS(type_names); i++) {
+if (!strncmp(name, type_names[i].name, len)) {
+stereo3d->type = i;
+found = 1;
+break;
+}
+}
+
+if (!found)
+return AVERROR(EINVAL);
+
+while (end) {
+name = end + 1;
+end = strchr(name, '+');
+if (end)
+len = end - name;
+else
+len = strlen(name);
+
+found = 0;
+for (i = 0; i < FF_ARRAY_ELEMS(flag_names); i++) {
+if (!strncmp(name, flag_names[i].name, len)) {
+stereo3d->flags |= (1 << 

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[Andreas Cadhalpun]

On 25.10.2015 01:53, Michael Niedermayer wrote:
> The newly added developers would be
> Ganesh Ajjanagadde
> Lou Logan
> Marton Balint
> Philip Langdale
> Reimar Döffinger
> 
> All of them have also contributed significantly outside of just self
> pushed commits.
> I belive they all should be on the voting comittee

I agree.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swr: do not reject channel layouts that use channel 63

[Michael Niedermayer]

On Sun, Oct 25, 2015 at 06:31:02PM +0100, wm4 wrote:
> Channel layouts are essentially uint64_t, and every value is valid.
> ---
>  libswresample/options.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

this LGTM if no unsiged int64 support is added to avoptions

[...]
-- 
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] Use ff_thread_once() to initialize sin/cos static tables.

[Dale Curtis]

On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje 
wrote:
>
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.
>

(from the right account this time)

Just so we're all on the same page, this is trivial, but will get a bit
messy unless I'm missing something. The ff_thread_once() API only takes a
void(void) function, so unless there's partial specialization hiding
somewhere we need prototypes for each partial initialization. I.e.
ff_init_ff_cos_static_table_init_4(), ff_init_ff_cos_static_table_init_5(),
ff_init_ff_cos_static_table_init_6(), etc for 4..16. We would also then
have an array of AVOnce items for entries 4..16 where each entry would
correspond to calling the paired initialization function.

Is this what everyone had in mind?

- dale
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Mark Harris a écrit :
> > +if (sleep > s->limit || sleep < -s->limit) {
> > +av_log(ctx, AV_LOG_WARNING,
> > +   "time discontinuity detected: %"PRIi64" us, 
> > resetting\n",
> > +   sleep);
> Won't this also be shown when there is no discontinuity but it isn't
> able to keep up with realtime (e.g. due to a very high frame rate)?
> The message is misleading in that situation.

This is true, but I consider it an acceptable approximation for now. I am
sure any user would guess what it means if the CPU is permanently at 100%
and this warning is printed repeatedly. An heuristic could be added to
detect when processing is slower than realtime and print a warning
accordingly, but tuning it would require more time than I want to spend on
this right now.

> The argument to av_usleep() is an unsigned int.  Should the maximum
> limit be UINT_MAX rather than INT64_MAX?  Alternatively it could call
> av_usleep() in a loop if the value is too large for one call.

Good catch, although it would probably not matter in practice: that would
involve a >1 hour gap between frames, the user actually wanting to sleep for
that time and having set the limit accordingly. But all the same, I added
this locally:

+for (; sleep > 6; sleep -= 6)
+av_usleep(6);

(I used 6 instead of UINT_MAX because I do not trust values too near
the limit value for that kind of system call; a spurious wakeup every
10 minutes is acceptable. Also, it will probably be easier to guess what it
means when reading strace output.)

Thanks for the review.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swr: do not reject channel layouts that use channel 63

[wm4]

On Mon, 26 Oct 2015 20:31:00 +0100
Michael Niedermayer  wrote:

> On Sun, Oct 25, 2015 at 06:31:02PM +0100, wm4 wrote:
> > Channel layouts are essentially uint64_t, and every value is valid.
> > ---
> >  libswresample/options.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)  
> 
> this LGTM if no unsiged int64 support is added to avoptions

When I wanted to give a try, I noticed that the min/max fields are
double, and that double doesn't have enough mantissa bits to cover the
full range. So adding a uint64 type for this purpose would be just as
broken.

I'm wonder whether setting min/max to -inf/inf would make sense. In a
way it'd be better than INT64_MAX (which is a lie, because after
rounding it's INT64_MAX+1), but in the end it's the same thing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#2]

[Clément Bœsch]

On Sun, Oct 25, 2015 at 02:23:21PM +0100, Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXIV, Michael Niedermayer a écrit :
> > Heres another suggested addition to the voting committee
> > also off topic but i wonder if "[DECISSION]" in the subject is the best
> > choice for this
> 
> Remember: before voting, there is campaigning. Basically: first propose
> something and let people discuss bugs in your shell one-liner and whether 19
> is a better threshold than 20, or if someone should be included for other
> reasons than commits. Then, when the discussion is settled, post the list of
> names with "DECISION".
> 
> > The newly added developers would be
> > Ganesh Ajjanagadde
> > Lou Logan
> > Marton Balint
> > Philip Langdale
> > Reimar Döffinger
> 
> Fine by me. Actually, I intended to do a similar search, but I was waiting
> for Clément to proclaim the results of the last vote (hint, hint).
> 

Ah haha well, I was confused at your last mail, I thought it was
meaningless so... well I guess I will have summarize soon :)

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/stereo3d: add serialization and deserialization functions

[James Almer]

On 10/26/2015 4:45 PM, Rodger Combs wrote:
> diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
> index 1135dc9..8b8aced 100644
> --- a/libavutil/stereo3d.h
> +++ b/libavutil/stereo3d.h
> @@ -149,4 +149,51 @@ AVStereo3D *av_stereo3d_alloc(void);
>   */
>  AVStereo3D *av_stereo3d_create_side_data(AVFrame *frame);
>  
> +/**
> + * Parse a string to an AVStereo3D struct.
> + *
> + * @param stereo3d struct to fill
> + * @param name name to parse, in the format returned by av_bprint_stereo3d() 
> with
> + * humanize = 0
> + * @return 0 on success; negative AVERROR code on error.
> + */
> +int av_get_stereo3d(AVStereo3D *stereo3d, const char *name);
> +
> +/**
> + * Return a description of an AVStereo3D.
> + *
> + * @param buf buffer to write into
> + * @param buf_size size in bytes of the buffer
> + * @param stereo3d the struct to describe
> + * @param humanize if non-zero, returns a human-readable string; see 
> av_bprint_stereo3d()
> + */
> +void av_get_stereo3d_string(char *buf, int buf_size, AVStereo3D *stereo3d, 
> int humanize);
> +
> +struct AVBPrint;
> +/**
> + * Append a description of an AVStereo3D to a bprint buffer.
> + *
> + * @param bp buffer to write into
> + * @param stereo3d the struct to describe
> + * @param humanize if non-zero, append a human-readable string. Otherwise, 
> append a
> +   machine-readable string that can be parsed with 
> av_get_stereo3d().
> + */
> +void av_bprint_stereo3d(struct AVBPrint *bp, const AVStereo3D *stereo3d, int 
> humanize);

Shouldn't the exported symbols be all av_stereo3d_*?

Something like av_stereo3d_init(), av_stereo3d_get_string() and 
av_stereo3d_set_string()
would be better.

> +
> +/**
> + * Get the name of a given AVStereo3DType.
> + *
> + * @return type name on success, NULL on error.
> + */
> +const char *av_stereo3d_type_get_name(enum AVStereo3DType type);
> +
> +/**
> + * Get the description of a given AVStereo3DType.
> + *
> + * @return type description on success, NULL on error.
> + */
> +const char *av_stereo3d_type_get_description(enum AVStereo3DType type);
> +
> +
> +
>  #endif /* AVUTIL_STEREO3D_H */

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/opt: enhance printing durations.

[Clément Bœsch]

On Mon, Oct 26, 2015 at 09:19:58PM +0100, Nicolas George wrote:
> Trim unneeded leading components and trailing zeros.
> Move the formating code in a separate function.
> Use the function also to format the default value, it was currently
> printed as plain integer, inconsistent to the way it is parsed.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavutil/opt.c| 48 +++-
>  tests/ref/fate/opt |  8 
>  2 files changed, 47 insertions(+), 9 deletions(-)
> 
> 

> Note: While I am touching the options code, I have this crazy idea about
> replacing AV_OPT_TYPE_* that would allow to get out of escaping hell
> completely. I will not have time to act on it soon, but if someone wants to
> hear about it...

What escaping are you talking about?

> 
> 
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index da1eb16..4fd25ff 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -26,6 +26,7 @@
>   */
>  
>  #include "avutil.h"
> +#include "avassert.h"
>  #include "avstring.h"
>  #include "channel_layout.h"
>  #include "common.h"
> @@ -639,6 +640,41 @@ int av_opt_set_dict_val(void *obj, const char *name, 
> const AVDictionary *val, in
>  return 0;
>  }
>  
> +static void format_duration(char *buf, size_t size, int64_t d)
> +{
> +char *e;
> +
> +av_assert0(size >= 25);
> +if (d < 0 && d != INT64_MIN) {
> +*(buf++) = '-';
> +size--;
> +d = -d;
> +}
> +if (d == INT64_MAX)
> +snprintf(buf, size, "INT64_MAX");
> +else if (d == INT64_MIN)
> +snprintf(buf, size, "INT64_MIN");
> +else if (d > (int64_t)3600*100)
> +snprintf(buf, size, "%"PRId64":%02d:%02d.%06d", d / 36,
> + (int)((d / 6000) % 60),
> + (int)((d / 100) % 60),
> + (int)(d % 100));
> +else if (d > 60*100)
> +snprintf(buf, size, "%d:%02d.%06d",
> + (int)(d / 6000),
> + (int)((d / 100) % 60),
> + (int)(d % 100));
> +else
> +snprintf(buf, size, "%d.%06d",
> + (int)(d / 100),
> + (int)(d % 100));
> +e = buf + strlen(buf);
> +while (e > buf && e[-1] == '0')
> +*(--e) = 0;
> +if (e > buf && e[-1] == '.')
> +*(--e) = 0;
> +}
> +
>  int av_opt_get(void *obj, const char *name, int search_flags, uint8_t 
> **out_val)
>  {
>  void *dst, *target_obj;
> @@ -704,9 +740,8 @@ int av_opt_get(void *obj, const char *name, int 
> search_flags, uint8_t **out_val)
>  break;
>  case AV_OPT_TYPE_DURATION:
>  i64 = *(int64_t *)dst;
> -ret = snprintf(buf, sizeof(buf), "%"PRIi64":%02d:%02d.%06d",
> -   i64 / 36, (int)((i64 / 6000) % 60),
> -   (int)((i64 / 100) % 60), (int)(i64 % 100));
> +format_duration(buf, sizeof(buf), i64);
> +ret = strlen(buf); // no overflow possible, checked by an assert
>  break;
>  case AV_OPT_TYPE_COLOR:
>  ret = snprintf(buf, sizeof(buf), "0x%02x%02x%02x%02x",
> @@ -1097,9 +1132,12 @@ static void opt_list(void *obj, void *av_log_obj, 
> const char *unit,
>  }
>  break;
>  }
> -case AV_OPT_TYPE_DURATION:
> -log_value(av_log_obj, AV_LOG_INFO, opt->default_val.i64);
> +case AV_OPT_TYPE_DURATION: {
> +char buf[25];
> +format_duration(buf, sizeof(buf), opt->default_val.i64);
> +av_log(av_log_obj, AV_LOG_INFO, "%s", buf);
>  break;
> +}
>  case AV_OPT_TYPE_INT:
>  case AV_OPT_TYPE_INT64: {
>  const char *def_const = get_opt_const_name(obj, opt->unit, 
> opt->default_val.i64);
> diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt
> index e9132a5..7b47d42 100644
> --- a/tests/ref/fate/opt
> +++ b/tests/ref/fate/opt
> @@ -31,7 +31,7 @@ TestContext AVOptions:
>-pix_fmt   E... set pixfmt (default 0bgr)
>-sample_fmt E... set samplefmt (default s16)
>-video_rate E... set videorate (default "25")
> -  -duration E... set duration (default 1000)
> +  -duration E... set duration (default 0.001)
>-color   E... set color (default "pink")
>-cl E... set channel layout (default 
> 0x137)
>-binE... set binary value
> @@ -97,7 +97,7 @@ name: bool2 default:1 error:
>  name: bool3 default:1 error:
>  
>  Test av_opt_serialize()
> -num=0,toggle=1,rational=1/1,string=default,escape=\\\=\,,flags=0x0001,size=200x300,pix_fmt=0bgr,sample_fmt=s16,video_rate=25/1,duration=0:00:00.001000,color=0xffc0cbff,cl=0x137,bin=62696E00,bin1=,bin2=,num64=1,flt=0.33,dbl=0.33,bool1=auto,bool2=true,bool3=false
> 

Re: [FFmpeg-devel] [PATCH] FATE: add crypto protocol test

[Michael Niedermayer]

On Mon, Oct 26, 2015 at 12:47:28PM -0500, Rodger Combs wrote:
> ---
>  tests/fate/avformat.mak| 1 +
>  tests/lavf-regression.sh   | 9 +
>  tests/ref/lavf-fate/crypto | 3 +++
>  3 files changed, 13 insertions(+)
>  create mode 100644 tests/ref/lavf-fate/crypto

is this missing some dependancy ?

--- ./tests/ref/lavf-fate/crypto2015-10-26 21:53:22.631814785 +0100
+++ tests/data/fate/lavf-fate-crypto2015-10-26 21:58:02.671820684 +0100
@@ -1,3 +0,0 @@
-a12b1a78ebc04786a694394a4d6d6c41 *./tests/data/lavf-fate/lavf.crypto.nut
-319968 ./tests/data/lavf-fate/lavf.crypto.nut
-crypto CRC=0xec6c3c68
Test lavf-fate-crypto failed. Look at tests/data/fate/lavf-fate-crypto.err for 
details.
make: *** [fate-lavf-fate-crypto] Error 1
make: *** Waiting for unfinished jobs

[...]
-- 
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

Re: [FFmpeg-devel] [PATCH] lavfi: add realtime filter.

[Nicolas George]

Le quintidi 5 brumaire, an CCXXIV, Moritz Barsnick a écrit :
> $ ffmpeg -h filter=realtime
> [...]
> realtime AVOptions:
>   limit..FVA... sleep time limit (default 2e+06)
> 
> 
> It's misleading to mention "seconds" and to expect microseconds. Or to
> mention "2" in one place and "200" in the other.
> 
> -> Time limit for the pauses in microseconds. [...]  Default is 200 (2 
> seconds).
>[...]
>{ "limit", "sleep time limit (in microseconds)", OFFSET(limit), 
> AV_OPT_TYPE_DURATION, { .i64 = 200 }, 0, INT64_MAX, FLAGS },

This is how it works with fields of type AV_OPT_TYPE_DURATION: the value is
internally in microseconds (AV_TIME_BASE), but the user interface converts
the strings in seconds, multiplying them by 100, or even in
H:MM:SS.DD.

The display of the default value is inconsistent, though. I just sent a
patch about it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] FATE: add crypto protocol test

[Rodger Combs]

---
 tests/Makefile   | 5 +
 tests/fate/avformat.mak  | 1 +
 tests/lavf-regression.sh | 9 +
 tests/ref/lavf/crypto| 3 +++
 4 files changed, 18 insertions(+)
 create mode 100644 tests/ref/lavf/crypto

diff --git a/tests/Makefile b/tests/Makefile
index 7ee4a46..c501813 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -82,6 +82,11 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER 
$(lastword $(1))_DECODER  \
  $(firstword $(2))_ENCODER $(lastword $(2))_DECODER  \
  $(firstword $(3))_MUXER   $(lastword $(3))_DEMUXER)
 
+ENCDEC2PRO = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword $(1))_DECODER 
 \
+$(firstword $(2))_ENCODER $(lastword $(2))_DECODER 
 \
+$(firstword $(3))_MUXER   $(lastword $(3))_DEMUXER 
 \
+$(firstword $(4))_PROTOCOL)
+
 DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
 ENCMUX  = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)
 
diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 1d13434..e65c3f9 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -6,6 +6,7 @@ FATE_LAVF-$(call ENCDEC,  PCM_S16BE, AU)
 += au
 FATE_LAVF-$(call ENCDEC2, MPEG4,  MP2,   AVI)+= avi
 FATE_LAVF-$(call ENCDEC,  BMP,   IMAGE2) += bmp
 FATE_LAVF-$(call ENCDEC,  PCM_S16BE, CAF)+= caf
+FATE_LAVF-$(call ENCDEC2PRO, MPEG4,   MP2,   NUT, CRYPTO)+= crypto
 FATE_LAVF-$(call ENCDEC,  DPX,   IMAGE2) += dpx
 FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, AVI)+= dv_fmt
 FATE_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2,   FFM)+= ffm
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index a37f714..58287ff 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-regression.sh
@@ -168,6 +168,15 @@ if [ -n "$do_wtv" ] ; then
 do_lavf wtv "" "-acodec mp2 -threads 1"
 fi
 
+if [ -n "$do_crypto" ] ; then
+crypto_flags="-key 0123456789abcdef0011223344556677 -iv 
aabbccddeeff1133557799987654"
+file=${outfile}lavf.crypto.nut
+f=${target_path}/$file
+run_avconv $DEC_OPTS -f image2 -vcodec pgmyuv -i $raw_src $DEC_OPTS -ar 44100 
-f s16le -i $pcm_src $ENC_OPTS -b:a 64k -t 1 -qscale:v 10 -acodec mp2 -ab 64k 
-ar 44100 -threads 1 $crypto_flags crypto:$f
+do_md5sum $file
+echo $(wc -c $file)
+do_avconv_crc crypto $DEC_OPTS $crypto_flags -i crypto:$f
+fi
 
 # streamed images
 # mjpeg
diff --git a/tests/ref/lavf/crypto b/tests/ref/lavf/crypto
new file mode 100644
index 000..d1dfd66
--- /dev/null
+++ b/tests/ref/lavf/crypto
@@ -0,0 +1,3 @@
+a12b1a78ebc04786a694394a4d6d6c41 *./tests/data/lavf/lavf.crypto.nut
+319968 ./tests/data/lavf/lavf.crypto.nut
+crypto CRC=0xec6c3c68
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavu/opt: enhance printing durations.

[Nicolas George]

Trim unneeded leading components and trailing zeros.
Move the formating code in a separate function.
Use the function also to format the default value, it was currently
printed as plain integer, inconsistent to the way it is parsed.

Signed-off-by: Nicolas George 
---
 libavutil/opt.c| 48 +++-
 tests/ref/fate/opt |  8 
 2 files changed, 47 insertions(+), 9 deletions(-)


Note: While I am touching the options code, I have this crazy idea about
replacing AV_OPT_TYPE_* that would allow to get out of escaping hell
completely. I will not have time to act on it soon, but if someone wants to
hear about it...


diff --git a/libavutil/opt.c b/libavutil/opt.c
index da1eb16..4fd25ff 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -26,6 +26,7 @@
  */
 
 #include "avutil.h"
+#include "avassert.h"
 #include "avstring.h"
 #include "channel_layout.h"
 #include "common.h"
@@ -639,6 +640,41 @@ int av_opt_set_dict_val(void *obj, const char *name, const 
AVDictionary *val, in
 return 0;
 }
 
+static void format_duration(char *buf, size_t size, int64_t d)
+{
+char *e;
+
+av_assert0(size >= 25);
+if (d < 0 && d != INT64_MIN) {
+*(buf++) = '-';
+size--;
+d = -d;
+}
+if (d == INT64_MAX)
+snprintf(buf, size, "INT64_MAX");
+else if (d == INT64_MIN)
+snprintf(buf, size, "INT64_MIN");
+else if (d > (int64_t)3600*100)
+snprintf(buf, size, "%"PRId64":%02d:%02d.%06d", d / 36,
+ (int)((d / 6000) % 60),
+ (int)((d / 100) % 60),
+ (int)(d % 100));
+else if (d > 60*100)
+snprintf(buf, size, "%d:%02d.%06d",
+ (int)(d / 6000),
+ (int)((d / 100) % 60),
+ (int)(d % 100));
+else
+snprintf(buf, size, "%d.%06d",
+ (int)(d / 100),
+ (int)(d % 100));
+e = buf + strlen(buf);
+while (e > buf && e[-1] == '0')
+*(--e) = 0;
+if (e > buf && e[-1] == '.')
+*(--e) = 0;
+}
+
 int av_opt_get(void *obj, const char *name, int search_flags, uint8_t 
**out_val)
 {
 void *dst, *target_obj;
@@ -704,9 +740,8 @@ int av_opt_get(void *obj, const char *name, int 
search_flags, uint8_t **out_val)
 break;
 case AV_OPT_TYPE_DURATION:
 i64 = *(int64_t *)dst;
-ret = snprintf(buf, sizeof(buf), "%"PRIi64":%02d:%02d.%06d",
-   i64 / 36, (int)((i64 / 6000) % 60),
-   (int)((i64 / 100) % 60), (int)(i64 % 100));
+format_duration(buf, sizeof(buf), i64);
+ret = strlen(buf); // no overflow possible, checked by an assert
 break;
 case AV_OPT_TYPE_COLOR:
 ret = snprintf(buf, sizeof(buf), "0x%02x%02x%02x%02x",
@@ -1097,9 +1132,12 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 }
 break;
 }
-case AV_OPT_TYPE_DURATION:
-log_value(av_log_obj, AV_LOG_INFO, opt->default_val.i64);
+case AV_OPT_TYPE_DURATION: {
+char buf[25];
+format_duration(buf, sizeof(buf), opt->default_val.i64);
+av_log(av_log_obj, AV_LOG_INFO, "%s", buf);
 break;
+}
 case AV_OPT_TYPE_INT:
 case AV_OPT_TYPE_INT64: {
 const char *def_const = get_opt_const_name(obj, opt->unit, 
opt->default_val.i64);
diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt
index e9132a5..7b47d42 100644
--- a/tests/ref/fate/opt
+++ b/tests/ref/fate/opt
@@ -31,7 +31,7 @@ TestContext AVOptions:
   -pix_fmt   E... set pixfmt (default 0bgr)
   -sample_fmt E... set samplefmt (default s16)
   -video_rate E... set videorate (default "25")
-  -duration E... set duration (default 1000)
+  -duration E... set duration (default 0.001)
   -color   E... set color (default "pink")
   -cl E... set channel layout (default 
0x137)
   -binE... set binary value
@@ -97,7 +97,7 @@ name: bool2 default:1 error:
 name: bool3 default:1 error:
 
 Test av_opt_serialize()
-num=0,toggle=1,rational=1/1,string=default,escape=\\\=\,,flags=0x0001,size=200x300,pix_fmt=0bgr,sample_fmt=s16,video_rate=25/1,duration=0:00:00.001000,color=0xffc0cbff,cl=0x137,bin=62696E00,bin1=,bin2=,num64=1,flt=0.33,dbl=0.33,bool1=auto,bool2=true,bool3=false
+num=0,toggle=1,rational=1/1,string=default,escape=\\\=\,,flags=0x0001,size=200x300,pix_fmt=0bgr,sample_fmt=s16,video_rate=25/1,duration=0.001,color=0xffc0cbff,cl=0x137,bin=62696E00,bin1=,bin2=,num64=1,flt=0.33,dbl=0.33,bool1=auto,bool2=true,bool3=false
 Setting entry with key 'num' to value '0'
 Setting entry with key 'toggle' to value '1'
 Setting entry 

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee

[Clément Bœsch]

On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> Hi Voting Committee
> 
> This mail is an attempt to try out the process described on
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html
> 
> This thread is a call for the following people:
> Michael Niedermayer
> Clément Bœsch
> James Almer
> Paul B Mahol
> Carl Eugen Hoyos
> Andreas Cadhalpun
> Ronald S. Bultje
> wm4
> Lukasz Marek
> Rostislav Pehlivanov
> Hendrik Leppkes
> Christophe Gisquet
> Reynaldo H. Verdejo Pinochet
> 
> As a first discussion, I'd like to discuss the introduction of new people to
> this list (alphabetical order).
> 
> Nicolas George
> Rodger Combs
> Stefano Sabatini
> Timothy Gu
> 
> I personally would like these people to join the group.
> 

Paul, Ronald, wm4, Hendrik, Christophe (and myself) agreed to all these
people joining the committee. The other remained silent.

46% OK
54% No opinion
0%  Refused

The voting committee now includes the following people:

 Michael Niedermayer
 Clément Bœsch
 James Almer
 Paul B Mahol
 Carl Eugen Hoyos
 Andreas Cadhalpun
 Ronald S. Bultje
 wm4
 Lukasz Marek
 Rostislav Pehlivanov
 Hendrik Leppkes
 Christophe Gisquet
 Reynaldo H. Verdejo Pinochet
 Nicolas George
 Rodger Combs
 Stefano Sabatini
 Timothy Gu

Regards,

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: add testsrc2 test source.

[Clément Bœsch]

On Sun, Oct 25, 2015 at 04:06:15PM +, Paul B Mahol wrote:
> On 10/25/15, Nicolas George  wrote:
> > Le quartidi 4 brumaire, an CCXXIV, Nicolas George a ecrit :
> >> Similar to testsrc, but using drawutils and therefore
> >> supporting a lot of pixel formats instead of just rgb24.
> >> This allows using it as input for other tests without
> >> requiring a format conversion.
> >> It is also slightly faster than testsrc for some reason.
> >>
> >> Signed-off-by: Nicolas George 
> >
> > Forgot to add: to see what it looks like without applying and compiling:
> >
> > http://www.normalesup.org/~george/tmp/testsrc2.mp4
> > http://www.normalesup.org/~george/tmp/testsrc2.png
> >
> 
> WOW, really looks nice. I slightly dislike name, have no better
> alternative though.
> 

Same. I also think the noise could get some improvement with a wider
color spectrum.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/filters.texi: ebur128 grammar fix

[Kyle Swanson]

---
 doc/filters.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 1de6a2f..2914e40 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12958,7 +12958,7 @@ This mode requires a build with @code{libswresample}.
 Treat mono input files as "dual mono". If a mono file is intended for playback
 on a stereo system, its EBU R128 measurement will be perceptually incorrect.
 If set to @code{true}, this option will compensate for this effect.
-Multi-channel input files are not effected by this option.
+Multi-channel input files are not affected by this option.
 
 @item panlaw
 Set a specific pan law to be used for the measurement of dual mono files.
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

[Hendrik Leppkes]

On Mon, Oct 26, 2015 at 11:29 PM, Kieran Kunhya  wrote:
> From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya 
> Date: Mon, 26 Oct 2015 22:26:35 +
> Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays
>
> Fixes crashes on fuzzed files
>
> ---
>  libavcodec/opusdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
> index acae6e1..03dd872 100644
> --- a/libavcodec/opusdec.c
> +++ b/libavcodec/opusdec.c
> @@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
> *avctx, void *data,
>  memset(frame->extended_data[i], 0, frame->linesize[0]);
>  }
>
> -if (c->gain_i) {
> +if (c->gain_i && decoded_samples >= 8) {
>  c->fdsp.vector_fmul_scalar((float*)frame->extended_data[i],
> (float*)frame->extended_data[i],
> c->gain, FFALIGN(decoded_samples, 8));

> 0 might be less arbitrary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

[Kieran Kunhya]

From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
From: Kieran Kunhya 
Date: Mon, 26 Oct 2015 22:26:35 +
Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

Fixes crashes on fuzzed files

---
 libavcodec/opusdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
index acae6e1..03dd872 100644
--- a/libavcodec/opusdec.c
+++ b/libavcodec/opusdec.c
@@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
*avctx, void *data,
 memset(frame->extended_data[i], 0, frame->linesize[0]);
 }

-if (c->gain_i) {
+if (c->gain_i && decoded_samples >= 8) {
 c->fdsp.vector_fmul_scalar((float*)frame->extended_data[i],
(float*)frame->extended_data[i],
c->gain, FFALIGN(decoded_samples, 8));
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

[Kieran Kunhya]

On 26 October 2015 at 22:48, Hendrik Leppkes  wrote:
> On Mon, Oct 26, 2015 at 11:29 PM, Kieran Kunhya  wrote:
>> From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
>> From: Kieran Kunhya 
>> Date: Mon, 26 Oct 2015 22:26:35 +
>> Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays
>>
>> Fixes crashes on fuzzed files
>>
>> ---
>>  libavcodec/opusdec.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
>> index acae6e1..03dd872 100644
>> --- a/libavcodec/opusdec.c
>> +++ b/libavcodec/opusdec.c
>> @@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
>> *avctx, void *data,
>>  memset(frame->extended_data[i], 0, frame->linesize[0]);
>>  }
>>
>> -if (c->gain_i) {
>> +if (c->gain_i && decoded_samples >= 8) {
>>  c->fdsp.vector_fmul_scalar((float*)frame->extended_data[i],
>> (float*)frame->extended_data[i],
>> c->gain, FFALIGN(decoded_samples, 
>> 8));
>
>> 0 might be less arbitrary.

New version:

From 25edf86e35773d419b4bcc7aeeb7b96d0f1ef958 Mon Sep 17 00:00:00 2001
From: Kieran Kunhya 
Date: Mon, 26 Oct 2015 23:08:31 +
Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

Fixes crashes on fuzzed files
---
 libavcodec/opusdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
index acae6e1..93c72c3 100644
--- a/libavcodec/opusdec.c
+++ b/libavcodec/opusdec.c
@@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
*avctx, void *data,
 memset(frame->extended_data[i], 0, frame->linesize[0]);
 }

-if (c->gain_i) {
+if (c->gain_i && decoded_samples > 0) {
 c->fdsp.vector_fmul_scalar((float*)frame->extended_data[i],
(float*)frame->extended_data[i],
c->gain, FFALIGN(decoded_samples, 8));
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters.texi: ebur128 grammar fix

[Lou Logan]

On Mon, Oct 26, 2015, at 02:44 PM, Kyle Swanson wrote:
> ---
>  doc/filters.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 1de6a2f..2914e40 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -12958,7 +12958,7 @@ This mode requires a build with
> @code{libswresample}.
>  Treat mono input files as "dual mono". If a mono file is intended for
>  playback
>  on a stereo system, its EBU R128 measurement will be perceptually
>  incorrect.
>  If set to @code{true}, this option will compensate for this effect.
> -Multi-channel input files are not effected by this option.
> +Multi-channel input files are not affected by this option.

LGTM. If anyone wants to push feel free to do so, otherwise I'll do it
but I won't be able to until 5 pm UTC -8 at the earliest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

[Michael Niedermayer]

On Mon, Oct 26, 2015 at 11:09:44PM +, Kieran Kunhya wrote:
> On 26 October 2015 at 22:48, Hendrik Leppkes  wrote:
> > On Mon, Oct 26, 2015 at 11:29 PM, Kieran Kunhya  wrote:
> >> From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001
> >> From: Kieran Kunhya 
> >> Date: Mon, 26 Oct 2015 22:26:35 +
> >> Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length 
> >> arrays
> >>
> >> Fixes crashes on fuzzed files
> >>
> >> ---
> >>  libavcodec/opusdec.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
> >> index acae6e1..03dd872 100644
> >> --- a/libavcodec/opusdec.c
> >> +++ b/libavcodec/opusdec.c
> >> @@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
> >> *avctx, void *data,
> >>  memset(frame->extended_data[i], 0, frame->linesize[0]);
> >>  }
> >>
> >> -if (c->gain_i) {
> >> +if (c->gain_i && decoded_samples >= 8) {
> >>  c->fdsp.vector_fmul_scalar((float*)frame->extended_data[i],
> >> (float*)frame->extended_data[i],
> >> c->gain, FFALIGN(decoded_samples, 
> >> 8));
> >
> >> 0 might be less arbitrary.
> 
> New version:
> 
> From 25edf86e35773d419b4bcc7aeeb7b96d0f1ef958 Mon Sep 17 00:00:00 2001
> From: Kieran Kunhya 
> Date: Mon, 26 Oct 2015 23:08:31 +
> Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays
> 
> Fixes crashes on fuzzed files
> ---
>  libavcodec/opusdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/opusdec.c b/libavcodec/opusdec.c
> index acae6e1..93c72c3 100644
> --- a/libavcodec/opusdec.c
> +++ b/libavcodec/opusdec.c
> @@ -587,7 +587,7 @@ static int opus_decode_packet(AVCodecContext
> *avctx, void *data,
>  memset(frame->extended_data[i], 0, frame->linesize[0]);
>  }
> 
> -if (c->gain_i) {
> +if (c->gain_i && decoded_samples > 0) {

applied

thanks

PS: the >0 isnt needed but does no harm and maybe its more
robust in the future ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- 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] FATE: add crypto protocol test

[Michael Niedermayer]

On Mon, Oct 26, 2015 at 07:57:34PM -0500, Rodger Combs wrote:
> ---
>  tests/Makefile   | 5 +
>  tests/fate/avformat.mak  | 1 +
>  tests/lavf-regression.sh | 9 +
>  tests/ref/lavf/crypto| 3 +++
>  4 files changed, 18 insertions(+)
>  create mode 100644 tests/ref/lavf/crypto
> 
> diff --git a/tests/Makefile b/tests/Makefile
> index 7ee4a46..c501813 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile

fate passes now correctly, thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fix: assigning instead of comparing

[AppChecker]

Signed-off-by: AppChecker 
---
 libavformat/webmdashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index 898e464..76e7eda 100644
--- a/libavformat/webmdashenc.c
+++ b/libavformat/webmdashenc.c
@@ -194,7 +194,7 @@ static int write_representation(AVFormatContext *s, 
AVStream *stream, char *id,
 avio_printf(s->pb, " width=\"%d\"", stream->codec->width);
 if (stream->codec->codec_type == AVMEDIA_TYPE_VIDEO && output_height)
 avio_printf(s->pb, " height=\"%d\"", stream->codec->height);
-if (stream->codec->codec_type = AVMEDIA_TYPE_AUDIO && output_sample_rate)
+if (stream->codec->codec_type == AVMEDIA_TYPE_AUDIO && output_sample_rate)
 avio_printf(s->pb, " audioSamplingRate=\"%d\"", 
stream->codec->sample_rate);
 if (w->is_live) {
 // For live streams, Codec and Mime Type always go in the 
Representation tag.
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[wm4]

On Mon, 26 Oct 2015 15:01:50 +0100
Gwenole Beauchesne  wrote:

> 2015-10-26 12:44 GMT+01:00 wm4 :
> > On Mon, 26 Oct 2015 11:22:38 +0100
> > Gwenole Beauchesne  wrote:
> >
> >  
> >> >> /**
> >> >>  * Hardware Accelerator identifier.
> >> >>  *
> >> >>  * @note
> >> >>  * A hardware accelerator can be device-less. This means that only the
> >> >>  * underlying hardware resource, e.g. a Linux dma_buf handle, is being
> >> >>  * transported in the AVFrame. That hardware resource could be mapped
> >> >>  * through standard OS-dependent calls, e.g. mmap() on Linux.
> >> >>  */
> >> >> enum AVHWAccelId {
> >> >> AV_HWACCEL_ID_NONE = -1,
> >> >> AV_HWACCEL_ID_VAAPI,
> >> >> AV_HWACCEL_ID_NB,   ///< Not part of ABI
> >> >> };
> >> >>
> >> >> Name to be improved if people have better suggestions, as this really
> >> >> is to be seen as HW resource, not necessarily attached to a particular
> >> >> HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
> >> >> VA surface.  
> >> >
> >> > OK. (Minor nit: if ID_NONE is valid and means HW API without context,
> >> > maybe it should be 0, not -1. Also, if it was meant this way, maybe
> >> > these should still have their own ID for other purposes.)  
> >>
> >> In my current model, ID_NONE is not meant to be valid because the
> >> hwaccel side data shall only exist for hwaccel purposes. Besides,
> >> having ID_NONE set to -1 is consistent with other liavu enums and
> >> convenient to have ID_NB express directly the exact number of
> >> hwaccels.  
> >
> > OK, this makes sense to me.
> >  
> >> >> I am reworking the patch series as I changed my mind again: current
> >> >> map strategy was overly complex (and required to be). There were at
> >> >> least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
> >> >> am now preferring a unique av_hwaccel_frame_get_pixels() defined as
> >> >> follow:
> >> >>
> >> >> /**
> >> >>  * Returns AVFrame pixels into linear memory
> >> >>  *
> >> >>  * This function takes a snapshot of the underlying HW surface and
> >> >>  * exposes it to SW backed memory. This may involve a copy from GPU
> >> >>  * memory to CPU memory.
> >> >>  *
> >> >>  * @note
> >> >>  * There is no effort underway to commit the modified pixels back to
> >> >>  * GPU memory when the \ref dst AVFrame is released.
> >> >>  *
> >> >>  * @param[in] src   the source frame to read
> >> >>  * @param[inout] dstthe target frame to update, or create if NULL
> >> >>  * @param[in] flags an optional combination of AV_FRAME_FLAG_xxx 
> >> >> flags
> >> >>  * @return 0 on success, an AVERROR code on failure.
> >> >>  */
> >> >> int
> >> >> av_hwaccel_frame_get_pixels(AVFrame *src, AVFrame **dst, unsigned 
> >> >> flags);
> >> >>
> >> >> i.e. the cost of allocating and copying AVFrame metadata should be
> >> >> less than the actual work needed behind the scene. So, it looks like a
> >> >> better interim solution for starters.  
> >> >
> >> > So this is for read-access only, right? If it can map data, there
> >> > also needs to be an unmap function, and the user would have to know
> >> > about when to use it.  
> >>
> >> Well, put can be implementing by reversing src/dst in this function. :)
> >> Actually, this can be av_hwaccel_frame_copy(), but the benefit of
> >> having get_pixels() is to leave out the allocation business to lavu
> >> and just having the user to bother about _unref().  
> >
> > Also makes sense to me.
> >
> > What is a problem is that mapped frames and CPU frames (let's call pure
> > CPU-allocated surfaces that) are not exactly the same thing. If the API
> > user assumes the frame is a CPU frame, it might reference it for a long
> > time, which would cause various problems. On the other hand, you don't
> > want the user to force copying a frame if it's really a CPU frame.
> >
> > Maybe this is not really a problem. I'm just mentioning it as another
> > detail.
> >  
> >> >> For compatibility, that's also the idea behind another generic
> >> >> AV_PIX_FMT_HWACCEL that would enforce data[i] to be clear of any
> >> >> user-supplied pointers, and buf[i] shall be filled in by appropriate
> >> >> accessors, or while creating the side-data, e.g.
> >> >> av_vaapi_frame_create_side_data(). i.e. when lavc swallows up an
> >> >> AVFrame with new-style hwaccel, this is where the AV_PIX_FMT_VAAPI
> >> >> would be replaced with AV_PIX_FMT_HWACCEL. Replace "swallows up" with
> >> >> e.g. av_vaapi_frame_convert_in_place() if you prefer. Otherwise, IMHO,
> >> >> the old-style fields should live untouched, hence the need to keep the
> >> >> hwaccel side-data around.  
> >> >
> >> > Isn't the problem more about output?
> >> >
> >> > Again, there's the problem with the current hwaccel API selecting the
> >> > hwaccel with get_format(), just using the hwaccel-specific pixfmt.  
> >>
> >> I also envision a need for AVCodecContext.hwaccel_id field + possibly
> >> 

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Tinglin Liu]

On Mon, Oct 26, 2015 at 8:06 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 10/23/2015 7:41 PM, Tinglin Liu wrote:
> > Derek, would you do the amend and push? Let me know if you need me to
> > resend an amended patch. Thanks.
>
> Amended and pushed.
>
> As before: Is there a sample somewhere we can add a FATE test for?
>

​One example:
​
https://drive.google.com/file/d/0Bxqhl1579b3ETmVQb01pRDZjVjQ/view?usp=sharing
​

​It has two meta key-value pairs
com.android.version 6.0
com.android.capture.fps  120.00​

​Thanks for the pushing.​



>
> - Derek
> ___
> 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] Using ffmpeg library

[mohamed larbi gharib]

Hi,

Thank you Lou for your answer.

Best regards.

2015-10-22 17:14 GMT-04:00 Lou Logan :

> On Thu, 22 Oct 2015 16:04:05 -0400, mohamed larbi gharib wrote:
>
> > Hi,
> >
> > Thank you for your help.
> >
> > I would like to get information on what library shall I use for parsing
> > data from a transport stream file MPEG2/h264.
> >
> > I would like to use ffprobe tools but as functions in my program (written
> > in C) returning a structure with stream index codec_name codec_tag and
> > codec_type and extra information.
> >
> > example:
> >
> > struct stream{
> >int index;
> >char* codec_name;
> >char* codec_tag;
> >char* codec_type;
> >//
> > }
> >
> > Actually I am using ffprobe in CLI outputting in JSON format and than I
> > parse the information using cJSON (https://github.com/kbranigan/cJSON)
> but
> > it is too slow.
> >
> > Best regards,
>
>
> Wrong mailing list. You should ask this on the libav-user mailing list.
> ffmpeg-devel is only for patch submissions and discussions involving
> the development of FFmpeg.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



-- 
GHARIB  Larbi
Diplômé en Génie Électrique à l'Université Laval

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Hendrik Leppkes]

On Mon, Oct 26, 2015 at 1:12 PM, wm4  wrote:
> On Mon, 26 Oct 2015 12:56:31 +0100
> Hendrik Leppkes  wrote:
>
>> >> > I think doing cropping as metadata would also simplify code a lot. For
>> >> > example, nobody has to worry about non-mod-2 yuv420 anymore, and how it
>> >> > should be handled. It's less tricky, more correct, more efficient.
>> >>
>> >> OK. A crop side-data is desired then. I somehow was convinced that it
>> >> wouldn't matter for SW. Though, it would actually be really need that
>> >
>> > At least this is my opinion. I would like to have such cropping side
>> > data, instead of half-broken ad-hoc cropping in the decoder and things
>> > like coded_width.
>> >
>> > I don't know what most others think about this. I suspect most would
>> > find such a change too intrusive. At least for hwaccel it's mandatory
>> > though. (What we currently do just barely works, and I need hacks in my
>> > own code to reconstruct the real surface size.)
>>
>> 99% of all cropping use-cases are extremely simple (only bottom/right)
>> and don't require any secret magic in any code.
>> I don't mind adding extra cropping metadata, but if you just don't
>> care about top/left cropping, simply adjusting width/height is as
>> trivial as it gets.
>>
>> Adding mandatory new metadata that every user app has to support to
>> avoid getting 1920x1088 in the future seems a bit ill-advised.
>
> Well, I've seen you complaining multiple times that non-mod-2 yuv420
> does not make any sense...

Obviously it doesn't, but I blame the users creating that, not the decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[Derek Buitenhuis]

On 10/23/2015 7:41 PM, Tinglin Liu wrote:
> Derek, would you do the amend and push? Let me know if you need me to
> resend an amended patch. Thanks.

Amended and pushed.

As before: Is there a sample somewhere we can add a FATE test for?

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Gwenole Beauchesne]

2015-10-26 12:44 GMT+01:00 wm4 :
> On Mon, 26 Oct 2015 11:22:38 +0100
> Gwenole Beauchesne  wrote:
>
>
>> >> /**
>> >>  * Hardware Accelerator identifier.
>> >>  *
>> >>  * @note
>> >>  * A hardware accelerator can be device-less. This means that only the
>> >>  * underlying hardware resource, e.g. a Linux dma_buf handle, is being
>> >>  * transported in the AVFrame. That hardware resource could be mapped
>> >>  * through standard OS-dependent calls, e.g. mmap() on Linux.
>> >>  */
>> >> enum AVHWAccelId {
>> >> AV_HWACCEL_ID_NONE = -1,
>> >> AV_HWACCEL_ID_VAAPI,
>> >> AV_HWACCEL_ID_NB,   ///< Not part of ABI
>> >> };
>> >>
>> >> Name to be improved if people have better suggestions, as this really
>> >> is to be seen as HW resource, not necessarily attached to a particular
>> >> HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
>> >> VA surface.
>> >
>> > OK. (Minor nit: if ID_NONE is valid and means HW API without context,
>> > maybe it should be 0, not -1. Also, if it was meant this way, maybe
>> > these should still have their own ID for other purposes.)
>>
>> In my current model, ID_NONE is not meant to be valid because the
>> hwaccel side data shall only exist for hwaccel purposes. Besides,
>> having ID_NONE set to -1 is consistent with other liavu enums and
>> convenient to have ID_NB express directly the exact number of
>> hwaccels.
>
> OK, this makes sense to me.
>
>> >> I am reworking the patch series as I changed my mind again: current
>> >> map strategy was overly complex (and required to be). There were at
>> >> least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
>> >> am now preferring a unique av_hwaccel_frame_get_pixels() defined as
>> >> follow:
>> >>
>> >> /**
>> >>  * Returns AVFrame pixels into linear memory
>> >>  *
>> >>  * This function takes a snapshot of the underlying HW surface and
>> >>  * exposes it to SW backed memory. This may involve a copy from GPU
>> >>  * memory to CPU memory.
>> >>  *
>> >>  * @note
>> >>  * There is no effort underway to commit the modified pixels back to
>> >>  * GPU memory when the \ref dst AVFrame is released.
>> >>  *
>> >>  * @param[in] src   the source frame to read
>> >>  * @param[inout] dstthe target frame to update, or create if NULL
>> >>  * @param[in] flags an optional combination of AV_FRAME_FLAG_xxx flags
>> >>  * @return 0 on success, an AVERROR code on failure.
>> >>  */
>> >> int
>> >> av_hwaccel_frame_get_pixels(AVFrame *src, AVFrame **dst, unsigned flags);
>> >>
>> >> i.e. the cost of allocating and copying AVFrame metadata should be
>> >> less than the actual work needed behind the scene. So, it looks like a
>> >> better interim solution for starters.
>> >
>> > So this is for read-access only, right? If it can map data, there
>> > also needs to be an unmap function, and the user would have to know
>> > about when to use it.
>>
>> Well, put can be implementing by reversing src/dst in this function. :)
>> Actually, this can be av_hwaccel_frame_copy(), but the benefit of
>> having get_pixels() is to leave out the allocation business to lavu
>> and just having the user to bother about _unref().
>
> Also makes sense to me.
>
> What is a problem is that mapped frames and CPU frames (let's call pure
> CPU-allocated surfaces that) are not exactly the same thing. If the API
> user assumes the frame is a CPU frame, it might reference it for a long
> time, which would cause various problems. On the other hand, you don't
> want the user to force copying a frame if it's really a CPU frame.
>
> Maybe this is not really a problem. I'm just mentioning it as another
> detail.
>
>> >> For compatibility, that's also the idea behind another generic
>> >> AV_PIX_FMT_HWACCEL that would enforce data[i] to be clear of any
>> >> user-supplied pointers, and buf[i] shall be filled in by appropriate
>> >> accessors, or while creating the side-data, e.g.
>> >> av_vaapi_frame_create_side_data(). i.e. when lavc swallows up an
>> >> AVFrame with new-style hwaccel, this is where the AV_PIX_FMT_VAAPI
>> >> would be replaced with AV_PIX_FMT_HWACCEL. Replace "swallows up" with
>> >> e.g. av_vaapi_frame_convert_in_place() if you prefer. Otherwise, IMHO,
>> >> the old-style fields should live untouched, hence the need to keep the
>> >> hwaccel side-data around.
>> >
>> > Isn't the problem more about output?
>> >
>> > Again, there's the problem with the current hwaccel API selecting the
>> > hwaccel with get_format(), just using the hwaccel-specific pixfmt.
>>
>> I also envision a need for AVCodecContext.hwaccel_id field + possibly
>> .get_hwaccel(). Just so that to depart from that pixfmt tie.
>
> There are some of us who would like this. Of course it makes the API
> change larger.

I don't think it would be too larger. I rather think the move would be
less intrusive, thus smoother.

My vision is:
- You want hwaccel: you report those you are interested 

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[wm4]

On Mon, 26 Oct 2015 12:56:31 +0100
Hendrik Leppkes  wrote:

> >> > I think doing cropping as metadata would also simplify code a lot. For
> >> > example, nobody has to worry about non-mod-2 yuv420 anymore, and how it
> >> > should be handled. It's less tricky, more correct, more efficient.  
> >>
> >> OK. A crop side-data is desired then. I somehow was convinced that it
> >> wouldn't matter for SW. Though, it would actually be really need that  
> >
> > At least this is my opinion. I would like to have such cropping side
> > data, instead of half-broken ad-hoc cropping in the decoder and things
> > like coded_width.
> >
> > I don't know what most others think about this. I suspect most would
> > find such a change too intrusive. At least for hwaccel it's mandatory
> > though. (What we currently do just barely works, and I need hacks in my
> > own code to reconstruct the real surface size.)  
> 
> 99% of all cropping use-cases are extremely simple (only bottom/right)
> and don't require any secret magic in any code.
> I don't mind adding extra cropping metadata, but if you just don't
> care about top/left cropping, simply adjusting width/height is as
> trivial as it gets.
> 
> Adding mandatory new metadata that every user app has to support to
> avoid getting 1920x1088 in the future seems a bit ill-advised.

Well, I've seen you complaining multiple times that non-mod-2 yuv420
does not make any sense...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Hendrik Leppkes
> Gesendet: Donnerstag, 22. Oktober 2015 17:56
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session
> control and internal allocation
> 
> On Wed, Oct 14, 2015 at 11:47 AM, Hendrik Leppkes 
> wrote:
> > On Wed, Oct 7, 2015 at 7:07 PM, Ivan Uskov 
> wrote:
> >> Hello wm4,
> >>
> >> Wednesday, October 7, 2015, 7:40:45 PM, you wrote:
> >>
> >> w> There's no automagic way to get this done.
> >>
> >> w> Hardware accelerators like vaapi and vdpau need the same thing.
> >> w> These have special APIs to set an API context on the decoder.
> Some
> >> w> APIs use hwaccel_context, vdpau uses av_vdpau_bind_context().
> >>
> >> w> The hwaccel_context pointer is untyped (just a void*), and what
> it
> >> w> means is implicit to the hwaccel or the decoder that is used. It
> >> w> could point to some sort of qsv state, which will have to be
> >> w> explicitly allocated and set by the API user (which might be
> ffmpeg.c).
> >> So  if  I will implement something like ffmpeg_qsv.c (using
> ffmpeg_vdpau.c as
> >> example)   and   extend  the  hwaccels[]  into  ffmpeg_opt.c  by
> corresponded
> >> qsv entries it  would  be the acceptable solution, correct?
> >>
> >> w> For filters there is no such thing yet. New API would have to be
> >> w> created. For filters in particular, we will have to make sure
> that
> >> w> the API isn't overly qsv-specific, and that it is extendable to
> >> w> other APIs (like for example vaapi or vdpau).
> >> Ok,   if   VPP  could be the  issue  I  would  like  to  get
> working  direct
> >> link qsv_decoder-qsv_encoder first.
> >>
> >
> > Libav has a patch that does exactly this, allow direct QSV->QSV
> > transcoding with help of some utility code in ffmpeg.c/avconv.c You
> > might want to look at that instead of re-inventing it. That'll help
> > make everyones live easier, as I'll just merge it when the time
> comes,
> > and the codebases don't diverge too drastically.
> >
> 
> This functionality has been merged now. It works for some samples.
> You can try to use it with a command line like this:
> 
> ffmpeg -hwaccel qsv -c:v h264_qsv -i h264.ts -c:v h264_qsv output.mkv
> 
> This will transcode using a QSV->QSV pipeline, no copying to system
> memory, and about 2.5x faster on my IVB laptop.
> 
> However, its broken on a lot of more complex H264 files, you'll get
> errors like get_buffer() failed - this is because our qsvdec behaves
> rather strangely, and instead of buffering input data when needed, it
> buffers output surfaces, which is not ideal, since it bloats up the
> memory usage an the number of surfaces required explodes into infinity.
> I know how to fix it - just restore the decoder to the same buffering
> model as it originally used, buffer input data instead of output
> surfaces. Unless someone else wants to fix it, I'll simply do it in the
> next week or so.

Hi Henrik,

Let me know if you need help to fix that, sounds like a good chance to learn 
more about the workflow. 
But, this could also result in extra work to double check my code. So, what do 
you think ?

Best,
Sven

> 
> - Hendrik
> ___
> 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 07/12] checkasm: add tests for AES

[Henrik Gramner]

On Mon, Oct 26, 2015 at 9:25 AM, Rodger Combs  wrote:
> ---
>  tests/checkasm/Makefile   |  2 +-
>  tests/checkasm/aes.c  | 61 
> +++
>  tests/checkasm/checkasm.c |  1 +
>  tests/checkasm/checkasm.h |  1 +
>  4 files changed, 64 insertions(+), 1 deletion(-)

https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181136.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swr: do not reject channel layouts that use channel 63

[Derek Buitenhuis]

On 10/25/2015 5:31 PM, wm4 wrote:
> Channel layouts are essentially uint64_t, and every value is valid.
> ---
>  libswresample/options.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Probably needs a micro version bump.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/riff.c: Adding support of PCM_S24LE in WAVEFORMATEXTENSIBLE

[Derek Buitenhuis]

On 10/22/2015 11:27 PM, Thierry Foucu wrote:
> here is another version to fix the file.

This looks no more hacky than what already exists in the file, I guess...

I'm sure Hendrik has an opinion.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 12/12] FATE: add crypto protocol test

[James Almer]

On 10/26/2015 5:25 AM, Rodger Combs wrote:
> ---
>  tests/fate/avformat.mak| 1 +
>  tests/lavf-regression.sh   | 8 
>  tests/ref/lavf-fate/crypto | 3 +++
>  3 files changed, 12 insertions(+)
>  create mode 100644 tests/ref/lavf-fate/crypto
> 
> diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
> index 1d13434..21b8f8a 100644
> --- a/tests/fate/avformat.mak
> +++ b/tests/fate/avformat.mak
> @@ -68,6 +68,7 @@ fate-lavf: $(FATE_LAVF)
>  FATE_LAVF_FATE-$(call ALLYES, MATROSKA_DEMUXER   OGG_MUXER)  += 
> ogg_vp3
>  FATE_LAVF_FATE-$(call ALLYES, MOV_DEMUXERLATM_MUXER) += latm
>  FATE_LAVF_FATE-$(call ALLYES, MP3_DEMUXERMP3_MUXER)  += mp3
> +FATE_LAVF_FATE-$(call ALLYES, NUT_MUXER  CRYPTO_PROTOCOL)+= 
> crypto
>  
>  FATE_LAVF_FATE +=  $(FATE_LAVF_FATE-yes:%=fate-lavf-fate-%)
>  $(FATE_LAVF_FATE): CMD = lavffatetest
> diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
> index a37f714..5c90ae8 100755
> --- a/tests/lavf-regression.sh
> +++ b/tests/lavf-regression.sh
> @@ -168,6 +168,14 @@ if [ -n "$do_wtv" ] ; then
>  do_lavf wtv "" "-acodec mp2 -threads 1"
>  fi
>  
> +if [ -n "$do_crypto" ] ; then
> +crypto_flags="-key 0123456789abcdef0011223344556677 -iv 
> aabbccddeeff1133557799987654"
> +file=${target_path}/${outfile}lavf.crypto.nut
> +run_avconv $DEC_OPTS -f image2 -vcodec pgmyuv -i $raw_src $DEC_OPTS -ar 
> 44100 -f s16le -i $pcm_src $ENC_OPTS -b:a 64k -t 1 -qscale:v 10 -acodec mp2 
> -ab 64k -ar 44100 -threads 1 $crypto_flags crypto:$file
> +do_md5sum $file
> +echo $(wc -c $file)
> +do_avconv_crc crypto $DEC_OPTS $crypto_flags -i crypto:$file
> +fi
>  
>  # streamed images
>  # mjpeg
> diff --git a/tests/ref/lavf-fate/crypto b/tests/ref/lavf-fate/crypto
> new file mode 100644
> index 000..a993a7b
> --- /dev/null
> +++ b/tests/ref/lavf-fate/crypto
> @@ -0,0 +1,3 @@
> +a12b1a78ebc04786a694394a4d6d6c41 
> */Users/rcombs/source/ffmpeg/./tests/data/lavf-fate/lavf.crypto.nut
> +319968 /Users/rcombs/source/ffmpeg/./tests/data/lavf-fate/lavf.crypto.nut

This is obviously not correct. It should be a relative path starting with 
./tests

> +crypto CRC=0xec6c3c68
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] FATE: add crypto protocol test

[Rodger Combs]

---
 tests/fate/avformat.mak| 1 +
 tests/lavf-regression.sh   | 9 +
 tests/ref/lavf-fate/crypto | 3 +++
 3 files changed, 13 insertions(+)
 create mode 100644 tests/ref/lavf-fate/crypto

diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 1d13434..21b8f8a 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -68,6 +68,7 @@ fate-lavf: $(FATE_LAVF)
 FATE_LAVF_FATE-$(call ALLYES, MATROSKA_DEMUXER   OGG_MUXER)  += ogg_vp3
 FATE_LAVF_FATE-$(call ALLYES, MOV_DEMUXERLATM_MUXER) += latm
 FATE_LAVF_FATE-$(call ALLYES, MP3_DEMUXERMP3_MUXER)  += mp3
+FATE_LAVF_FATE-$(call ALLYES, NUT_MUXER  CRYPTO_PROTOCOL)+= crypto
 
 FATE_LAVF_FATE +=  $(FATE_LAVF_FATE-yes:%=fate-lavf-fate-%)
 $(FATE_LAVF_FATE): CMD = lavffatetest
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index a37f714..58287ff 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-regression.sh
@@ -168,6 +168,15 @@ if [ -n "$do_wtv" ] ; then
 do_lavf wtv "" "-acodec mp2 -threads 1"
 fi
 
+if [ -n "$do_crypto" ] ; then
+crypto_flags="-key 0123456789abcdef0011223344556677 -iv 
aabbccddeeff1133557799987654"
+file=${outfile}lavf.crypto.nut
+f=${target_path}/$file
+run_avconv $DEC_OPTS -f image2 -vcodec pgmyuv -i $raw_src $DEC_OPTS -ar 44100 
-f s16le -i $pcm_src $ENC_OPTS -b:a 64k -t 1 -qscale:v 10 -acodec mp2 -ab 64k 
-ar 44100 -threads 1 $crypto_flags crypto:$f
+do_md5sum $file
+echo $(wc -c $file)
+do_avconv_crc crypto $DEC_OPTS $crypto_flags -i crypto:$f
+fi
 
 # streamed images
 # mjpeg
diff --git a/tests/ref/lavf-fate/crypto b/tests/ref/lavf-fate/crypto
new file mode 100644
index 000..ab682c9
--- /dev/null
+++ b/tests/ref/lavf-fate/crypto
@@ -0,0 +1,3 @@
+a12b1a78ebc04786a694394a4d6d6c41 *./tests/data/lavf-fate/lavf.crypto.nut
+319968 ./tests/data/lavf-fate/lavf.crypto.nut
+crypto CRC=0xec6c3c68
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel