Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Hendrik Leppkes]

On Tue, Nov 7, 2017 at 12:28 AM, Mironov, Mikhail
 wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Michael Niedermayer
>> Sent: November 6, 2017 5:47 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
>> GPUs based on AMF SDK
>>
>> On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
>> > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00
>> 2001
>> > From: mmironov 
>> > Date: Fri, 27 Oct 2017 13:03:15 -0400
>> > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
>> AMD
>> > GPUs  based on AMF SDK
>> >
>> > Signed-off-by: mmironov 
>> > ---
>> >  Changelog|3 +-
>> >  compat/amd/amfsdkenc.h   | 1753
>> ++
>> >  configure|   25 +
>> >  libavcodec/Makefile  |4 +
>> >  libavcodec/allcodecs.c   |2 +
>> >  libavcodec/amfenc.c  |  515 ++
>> >  libavcodec/amfenc.h  |  137 
>> >  libavcodec/amfenc_h264.c |  366 ++  libavcodec/amfenc_hevc.c
>> > |  294 
>> >  libavcodec/version.h |4 +-
>> >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
>> > 100644 compat/amd/amfsdkenc.h  create mode 100644
>> libavcodec/amfenc.c
>> > create mode 100644 libavcodec/amfenc.h  create mode 100644
>> > libavcodec/amfenc_h264.c  create mode 100644 libavcodec/amfenc_hevc.c
>>
>> This seems to fail building in mingw64
>
> This is strange. Just in case: my build setup is described here:
> https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
>
> I also attached full amfsdkenc.h header file in case I made a mistake with 
> git integration.
>
>
>>
>> make
>> CC  libavcodec/amfenc.o
>> In file included from src/libavcodec/amfenc.c:22:0:
>> src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
>> ‘ID3D11VideoDevice’
>>  ID3D11VideoDevice   *video_device;
>>  ^
>> src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
>> ‘ID3D11VideoContext’
>>  ID3D11VideoContext  *video_context;
>>  ^
>
> This is declared in d3d11.h and came with mingw64. Mine version has it:
> msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> Is it possible that we use different versions of mingw? Do you have it 
> declared?
>

If you use/rely on hwcontext_d3d11va, you should probably have a
configure dependency on that part being available.

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

[FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Karthick J]

---
 libavformat/avio_internal.h | 8 
 libavformat/aviobuf.c   | 8 
 2 files changed, 16 insertions(+)

diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
index c01835d..04c1ad5 100644
--- a/libavformat/avio_internal.h
+++ b/libavformat/avio_internal.h
@@ -133,6 +133,14 @@ int ffio_open_dyn_packet_buf(AVIOContext **s, int 
max_packet_size);
 int ffio_fdopen(AVIOContext **s, URLContext *h);
 
 /**
+ * Return the URLContext associated with the AVIOContext
+ *
+ * @param s IO context
+ * @return pointer to URLContext or NULL.
+ */
+URLContext *ffio_geturlcontext(AVIOContext *s);
+
+/**
  * Open a write-only fake memory stream. The written data is not stored
  * anywhere - this is only used for measuring the amount of data
  * written.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 3b4c843..1353c80 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -980,6 +980,14 @@ fail:
 return AVERROR(ENOMEM);
 }
 
+URLContext* ffio_geturlcontext(AVIOContext *s) {
+AVIOInternal *internal = s->opaque;
+if (internal)
+return internal->h;
+else
+return NULL;
+}
+
 int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
 {
 uint8_t *buffer;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/3] libavformat/http: Handled multiple_requests option during write

[Karthick J]

---
 libavformat/http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index bd9148f..0854c01 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1527,7 +1527,7 @@ static int http_write(URLContext *h, const uint8_t *buf, 
int size)
 
 /* silently ignore zero-size data since chunk encoding that would
  * signal EOF */
-if (size > 0) {
+if (size > 0 || s->multiple_requests) {
 /* upload data using chunked encoding */
 snprintf(temp, sizeof(temp), "%x\r\n", size);
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Karthick J]

---
 doc/muxers.texi  |  3 +++
 libavformat/hlsenc.c | 50 +++---
 2 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 91bbe67..1e1468c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -794,6 +794,9 @@ files.
 @item http_user_agent
 Override User-Agent field in HTTP header. Applicable only for HTTP output.
 
+@item http_persistent
+Use persistent HTTP connections. Applicable only for HTTP output.
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5ea9d21..4a581b4 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -44,6 +44,7 @@
 
 #include "avformat.h"
 #include "avio_internal.h"
+#include "http.h"
 #include "internal.h"
 #include "os_support.h"
 
@@ -175,6 +176,7 @@ typedef struct HLSContext {
 double initial_prog_date_time;
 char current_segment_final_filename_fmt[1024]; // when renaming segments
 char *user_agent;
+int http_persistent;
 } HLSContext;
 
 static int get_int_from_double(double val)
@@ -215,10 +217,40 @@ static int mkdir_p(const char *path) {
 return ret;
 }
 
+static int is_http_proto(char *filename) {
+const char *proto = avio_find_protocol_name(filename);
+return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
"https")) : 0;
+}
+
+static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
+  AVDictionary **options) {
+HLSContext *hls = s->priv_data;
+int http_base_proto = is_http_proto(filename);
+int err;
+if (*pb == NULL || !http_base_proto || !hls->http_persistent) {
+err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
+} else {
+URLContext *http_url_context = ffio_geturlcontext(*pb);
+err = ff_http_do_new_request(http_url_context, filename);
+}
+return err;
+}
+
+static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
+HLSContext *hls = s->priv_data;
+int http_base_proto = is_http_proto(filename);
+
+if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
+ff_format_io_close(s, pb);
+} else if (*pb) {
+URLContext *http_url_context = ffio_geturlcontext(*pb);
+http_url_context->prot->url_write(http_url_context, NULL, 0);
+}
+}
+
 static void set_http_options(AVFormatContext *s, AVDictionary **options, 
HLSContext *c)
 {
-const char *proto = avio_find_protocol_name(s->filename);
-int http_base_proto = proto ? (!av_strcasecmp(proto, "http") || 
!av_strcasecmp(proto, "https")) : 0;
+int http_base_proto = is_http_proto(s->filename);
 
 if (c->method) {
 av_dict_set(options, "method", c->method, 0);
@@ -228,6 +260,8 @@ static void set_http_options(AVFormatContext *s, 
AVDictionary **options, HLSCont
 }
 if (c->user_agent)
 av_dict_set(options, "user_agent", c->user_agent, 0);
+if (c->http_persistent)
+av_dict_set_int(options, "multiple_requests", 1, 0);
 
 }
 
@@ -1263,17 +1297,17 @@ static int hls_start(AVFormatContext *s)
 err = AVERROR(ENOMEM);
 goto fail;
 }
-err = s->io_open(s, &oc->pb, filename, AVIO_FLAG_WRITE, &options);
+err = hlsenc_io_open(s, &oc->pb, filename, &options);
 av_free(filename);
 av_dict_free(&options);
 if (err < 0)
 return err;
 } else
-if ((err = s->io_open(s, &oc->pb, oc->filename, AVIO_FLAG_WRITE, 
&options)) < 0)
+if ((err = hlsenc_io_open(s, &oc->pb, oc->filename, &options)) < 0)
 goto fail;
 if (c->vtt_basename) {
 set_http_options(s, &options, c);
-if ((err = s->io_open(s, &vtt_oc->pb, vtt_oc->filename, 
AVIO_FLAG_WRITE, &options)) < 0)
+if ((err = hlsenc_io_open(s, &vtt_oc->pb, vtt_oc->filename, &options)) 
< 0)
 goto fail;
 }
 av_dict_free(&options);
@@ -1661,9 +1695,10 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 hls->size = new_start_pos - hls->start_pos;
 
 if (!byterange_mode) {
-ff_format_io_close(s, &oc->pb);
+hlsenc_io_close(s, &oc->pb,
+hls->fmp4_init_mode ? hls->base_output_dirname : 
oc->filename);
 if (hls->vtt_avf) {
-ff_format_io_close(s, &hls->vtt_avf->pb);
+hlsenc_io_close(s, &hls->vtt_avf->pb, hls->vtt_avf->filename);
 }
 }
 if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
@@ -1829,6 +1864,7 @@ static const AVOption options[] = {
 {"epoch", "seconds since epoch", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH }, INT_MIN, INT_MAX, E, 
"start_sequence_source_type" },
 {"datetime", "current datetime as MMDDhhmmss", 0, AV_OPT_TYPE_CONST, 
{.i64 = HLS_START_SEQUENCE_AS_FORMATTED_DATETIME }, INT_MIN, INT_MAX, E, 
"start_sequ

Re: [FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/7/17, 10:45 AM, "Jeyapal, Karthick"  wrote:
>
>>On 11/3/17, 9:44 PM, "Aman Gupta"  wrote:
>>
>>I recently implemented keepalive support in the hls demuxer, and have been
>>using it with a lot of success. See my patchset:
>>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html
>>
>>Aman
>
>Thanks a lot for your excellent suggestion. 
>I was not aware of the global function ff_http_do_new_request.
>Now I will attempt to re-implement this feature along similar lines of your 
>patch.
>
>Regards,
>Karthick 

Well, usage of global function ff_http_do_new_request made it much simpler.
Have submitted a completely new patch series for the same feature.
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219301.html
Hope the new approach is acceptable :)

Regards,
Karthick

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

[FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Carl Eugen Hoyos]

Hi!

Attached patch fixes compilation with current libressl, related to ticket #6801.

Please comment, Carl Eugen
From 9e660d1bbe0842264971f1e4e8c2539bdb36cd4c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 7 Nov 2017 13:25:55 +0100
Subject: [PATCH] lavf/tls_openssl: Fix compilation with current libressl.

Fixes a bug related to ticket #6801.
---
 libavformat/tls_openssl.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 1443e90..1e261d3 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -43,7 +43,7 @@ typedef struct TLSContext {
 TLSShared tls_shared;
 SSL_CTX *ctx;
 SSL *ssl;
-#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_NUMBER)
 BIO_METHOD* url_bio_method;
 #endif
 } TLSContext;
@@ -137,7 +137,7 @@ static int tls_close(URLContext *h)
 SSL_CTX_free(c->ctx);
 if (c->tls_shared.tcp)
 ffurl_close(c->tls_shared.tcp);
-#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_NUMBER)
 if (c->url_bio_method)
 BIO_meth_free(c->url_bio_method);
 #endif
@@ -147,7 +147,7 @@ static int tls_close(URLContext *h)
 
 static int url_bio_create(BIO *b)
 {
-#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_NUMBER)
 BIO_set_init(b, 1);
 BIO_set_data(b, NULL);
 BIO_set_flags(b, 0);
@@ -164,7 +164,7 @@ static int url_bio_destroy(BIO *b)
 return 1;
 }
 
-#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_NUMBER)
 #define GET_BIO_DATA(x) BIO_get_data(x)
 #else
 #define GET_BIO_DATA(x) (x)->ptr
@@ -212,7 +212,7 @@ static int url_bio_bputs(BIO *b, const char *str)
 return url_bio_bwrite(b, str, strlen(str));
 }
 
-#if OPENSSL_VERSION_NUMBER < 0x101fL
+#if OPENSSL_VERSION_NUMBER < 0x101fL || defined(LIBRESSL_VERSION_NUMBER)
 static BIO_METHOD url_bio_method = {
 .type = BIO_TYPE_SOURCE_SINK,
 .name = "urlprotocol bio",
@@ -276,7 +276,7 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op
 ret = AVERROR(EIO);
 goto fail;
 }
-#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_NUMBER)
 p->url_bio_method = BIO_meth_new(BIO_TYPE_SOURCE_SINK, "urlprotocol bio");
 BIO_meth_set_write(p->url_bio_method, url_bio_bwrite);
 BIO_meth_set_read(p->url_bio_method, url_bio_bread);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]configure: libvmaf is not GPLv2-compatible

[Carl Eugen Hoyos]

2017-11-06 14:20 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> I believe the following patch is necessary to fix the libvmaf license
> dependencies.

Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Timo Rothenpieler]

Am 07.11.2017 um 13:28 schrieb Carl Eugen Hoyos:

Hi!

Attached patch fixes compilation with current libressl, related to ticket #6801.

Please comment, Carl Eugen


Wouldn't it be better to move that check to configure, so it does not 
build the openssl backend with libressl, and then merge the libtls 
backend that's been posted, so there is proper support for libressl 
instead of an ever growing collection of #ifdefs?




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[James Almer]

On 11/7/2017 10:04 AM, Timo Rothenpieler wrote:
> Am 07.11.2017 um 13:28 schrieb Carl Eugen Hoyos:
>> Hi!
>>
>> Attached patch fixes compilation with current libressl, related to
>> ticket #6801.
>>
>> Please comment, Carl Eugen
> 
> Wouldn't it be better to move that check to configure, so it does not
> build the openssl backend with libressl, and then merge the libtls
> backend that's been posted, so there is proper support for libressl
> instead of an ever growing collection of #ifdefs?

I would very much rather have a way to get libressl to compile with
tls_openssl.c, or just reject it altogether, than adding a duplicate
module just for a fork that pretends to be compatible with a version of
openssl but not providing the required API for it.

I refuse to give special treatment to such a sloppy fork, especially
when adding it would increase the complexity in configure (As only one
tls module can be compiled per build).
An "if not defined libressl" for every openssl >= 1.1 check is simpler
and easier to maintain than a whole separate duplicate module.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Timo Rothenpieler]

I would very much rather have a way to get libressl to compile with
tls_openssl.c, or just reject it altogether, than adding a duplicate
module just for a fork that pretends to be compatible with a version of
openssl but not providing the required API for it.

I refuse to give special treatment to such a sloppy fork, especially
when adding it would increase the complexity in configure (As only one
tls module can be compiled per build).
An "if not defined libressl" for every openssl >= 1.1 check is simpler
and easier to maintain than a whole separate duplicate module.


From how I understand it, libtls is an entirely new API, so it would 
not be a duplicate of the openssl backend.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[James Almer]

On 11/7/2017 10:28 AM, Timo Rothenpieler wrote:
>> I would very much rather have a way to get libressl to compile with
>> tls_openssl.c, or just reject it altogether, than adding a duplicate
>> module just for a fork that pretends to be compatible with a version of
>> openssl but not providing the required API for it.
>>
>> I refuse to give special treatment to such a sloppy fork, especially
>> when adding it would increase the complexity in configure (As only one
>> tls module can be compiled per build).
>> An "if not defined libressl" for every openssl >= 1.1 check is simpler
>> and easier to maintain than a whole separate duplicate module.
> 
> From how I understand it, libtls is an entirely new API, so it would not
> be a duplicate of the openssl backend.

Then how is Carl's patch supposed to work? Unless you mean new API on
top of the inherited openssl 1.0 API. If that's the case and such new
libressl specific API is worth using then a separate module could be
considered (Or just some more ifdeffery in tls_openssl.c, much like we
do for openssl 1.1), but if it works as is then as i said I want to
avoid new TLS modules as much as possible.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Timo Rothenpieler]

Am 07.11.2017 um 14:37 schrieb James Almer:

On 11/7/2017 10:28 AM, Timo Rothenpieler wrote:

I would very much rather have a way to get libressl to compile with
tls_openssl.c, or just reject it altogether, than adding a duplicate
module just for a fork that pretends to be compatible with a version of
openssl but not providing the required API for it.

I refuse to give special treatment to such a sloppy fork, especially
when adding it would increase the complexity in configure (As only one
tls module can be compiled per build).
An "if not defined libressl" for every openssl >= 1.1 check is simpler
and easier to maintain than a whole separate duplicate module.


 From how I understand it, libtls is an entirely new API, so it would not
be a duplicate of the openssl backend.


Then how is Carl's patch supposed to work? Unless you mean new API on
top of the inherited openssl 1.0 API. If that's the case and such new
libressl specific API is worth using then a separate module could be
considered (Or just some more ifdeffery in tls_openssl.c, much like we
do for openssl 1.1), but if it works as is then as i said I want to
avoid new TLS modules as much as possible.


LibreSSL offers an older version of the openssl API in libssl, and at 
the same time also a new somewhat cleaner one in libtls, which right now 
is just a wrapper, but who knows if it becomes the new default at some 
point.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Hendrik Leppkes]

On Tue, Nov 7, 2017 at 1:28 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes compilation with current libressl, related to ticket 
> #6801.
>

I believe we basically had that exact same patch on the ML before, and
the consensus was to not have a jungle of #ifdefs in the code, and
instead have configure figure it out.

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

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[James Almer]

On 11/7/2017 10:48 AM, Hendrik Leppkes wrote:
> On Tue, Nov 7, 2017 at 1:28 PM, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes compilation with current libressl, related to ticket 
>> #6801.
>>
> 
> I believe we basically had that exact same patch on the ML before, and
> the consensus was to not have a jungle of #ifdefs in the code, and
> instead have configure figure it out.

configure could at most refuse to compile tls_openssl with libressl, but
nothing to make it build successfully without ifdeffery.

Is that preferred?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Hello,

I tried to address all issues.
I did not have time yet to try more image formats, so it is still only 
YUV420P.


Please review.

Greetings,
FelixFrom a235f56518fc1f11698a5028dfd4b654989993c5 Mon Sep 17 00:00:00 2001
From: Felix Matouschek 
Date: Tue, 24 Oct 2017 13:11:23 +0200
Subject: [PATCH] avdevice: add android_camera indev
To: ffmpeg-devel@ffmpeg.org

This commit adds an indev for Android devices on API level 24+ which
uses the Android NDK Camera2 API to capture video from builtin cameras

Signed-off-by: Felix Matouschek 
---
 Changelog|   1 +
 configure|   6 +
 doc/indevs.texi  |  40 ++
 libavdevice/Makefile |   1 +
 libavdevice/alldevices.c |   1 +
 libavdevice/android_camera.c | 848 +++
 libavdevice/version.h|   2 +-
 7 files changed, 898 insertions(+), 1 deletion(-)
 create mode 100644 libavdevice/android_camera.c

diff --git a/Changelog b/Changelog
index 6592d868da..f58cd810e0 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
   requires 2.1 (or later) and pkg-config.
 - VDA dropped (use VideoToolbox instead)
+- Add android_camera indev
 
 
 version 3.4:
diff --git a/configure b/configure
index 7a53bc76c7..d52b18fab3 100755
--- a/configure
+++ b/configure
@@ -3068,6 +3068,8 @@ xmv_demuxer_select="riffdec"
 xwma_demuxer_select="riffdec"
 
 # indevs / outdevs
+android_camera_indev_deps="android camera2ndk mediandk pthreads"
+android_camera_indev_extralibs="-landroid -lcamera2ndk -lmediandk"
 alsa_indev_deps="alsa"
 alsa_outdev_deps="alsa"
 avfoundation_indev_deps="avfoundation corevideo coremedia pthreads"
@@ -5836,6 +5838,10 @@ check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
+check_lib android android/native_window.h ANativeWindow_acquire -landroid
+check_lib mediandk "stdint.h media/NdkImage.h" AImage_delete -lmediandk
+check_lib camera2ndk "stdbool.h stdint.h camera/NdkCameraManager.h" ACameraManager_create -lcamera2ndk
+
 enabled appkit   && check_apple_framework AppKit
 enabled audiotoolbox && check_apple_framework AudioToolbox
 enabled avfoundation && check_apple_framework AVFoundation
diff --git a/doc/indevs.texi b/doc/indevs.texi
index d308bbf7de..07056d762e 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -63,6 +63,46 @@ Set the number of channels. Default is 2.
 
 @end table
 
+@section android_camera
+
+Android camera input device.
+
+This input devices uses the Android Camera2 NDK API which is
+available on devices with API level 24+. The availability of
+android_camera is autodetected during configuration.
+
+This device allows capturing from all cameras on an Android device,
+which are integrated into the Camera2 NDK API.
+
+The available cameras are enumerated internally and can be selected
+with the @var{camera_index} parameter. The input file string is
+discarded.
+
+Generally the back facing camera has index 0 while the front facing
+camera has index 1.
+
+@subsection Options
+
+@table @option
+
+@item video_size
+Set the video size given as a string such as 640x480 or hd720.
+Falls back to the first available configuration reported by
+Android if requested video size is not available or by default.
+
+@item framerate
+Set the video framerate.
+Falls back to the first available configuration reported by
+Android if requested framerate is not available or by default (-1).
+
+@item camera_index
+Set the index of the camera to use. Default is 0.
+
+@item input_queue_size
+Set the maximum number of frames to buffer. Default is 5.
+
+@end table
+
 @section avfoundation
 
 AVFoundation input device.
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 8228d62147..f11a6f2a86 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -14,6 +14,7 @@ OBJS-$(CONFIG_SHARED)+= reverse.o
 # input/output devices
 OBJS-$(CONFIG_ALSA_INDEV)+= alsa_dec.o alsa.o timefilter.o
 OBJS-$(CONFIG_ALSA_OUTDEV)   += alsa_enc.o alsa.o
+OBJS-$(CONFIG_ANDROID_CAMERA_INDEV)  += android_camera.o
 OBJS-$(CONFIG_AVFOUNDATION_INDEV)+= avfoundation.o
 OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
 OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index b767b6a718..2c8d9035da 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -42,6 +42,7 @@ static void register_all(void)
 {
 /* devices */
 REGISTER_INOUTDEV(ALSA, alsa);
+REGISTER_INDEV   (ANDROID_CAMERA,   android_camera);
 REGISTER_INDEV   (AVFOUNDATION, avfoundation);
 REGISTER_INDEV   (BKTR, bktr);
 REGISTER_OUTDEV  (CACA, caca);
diff --git a/libavdev

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Am 02.11.2017 16:20, schrieb Daniel Kučera:


some devices have cameras which are unlisted - this condition makes
them unusable.


How does one use unlisted devices? As far as I understood all supported
devices are listed. If the Camera2 API does not support the camera
it cannot be used.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: November 7, 2017 3:25 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Tue, Nov 7, 2017 at 12:28 AM, Mironov, Mikhail
>  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Michael Niedermayer
> >> Sent: November 6, 2017 5:47 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for
> AMD
> >> GPUs based on AMF SDK
> >>
> >> On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> >> > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17
> 00:00:00
> >> 2001
> >> > From: mmironov 
> >> > Date: Fri, 27 Oct 2017 13:03:15 -0400
> >> > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
> >> AMD
> >> > GPUs  based on AMF SDK
> >> >
> >> > Signed-off-by: mmironov 
> >> > ---
> >> >  Changelog|3 +-
> >> >  compat/amd/amfsdkenc.h   | 1753
> >> ++
> >> >  configure|   25 +
> >> >  libavcodec/Makefile  |4 +
> >> >  libavcodec/allcodecs.c   |2 +
> >> >  libavcodec/amfenc.c  |  515 ++
> >> >  libavcodec/amfenc.h  |  137 
> >> >  libavcodec/amfenc_h264.c |  366 ++
> >> > libavcodec/amfenc_hevc.c
> >> > |  294 
> >> >  libavcodec/version.h |4 +-
> >> >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
> >> > 100644 compat/amd/amfsdkenc.h  create mode 100644
> >> libavcodec/amfenc.c
> >> > create mode 100644 libavcodec/amfenc.h  create mode 100644
> >> > libavcodec/amfenc_h264.c  create mode 100644
> >> > libavcodec/amfenc_hevc.c
> >>
> >> This seems to fail building in mingw64
> >
> > This is strange. Just in case: my build setup is described here:
> > https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
> >
> > I also attached full amfsdkenc.h header file in case I made a mistake with
> git integration.
> >
> >
> >>
> >> make
> >> CC  libavcodec/amfenc.o
> >> In file included from src/libavcodec/amfenc.c:22:0:
> >> src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
> >> ‘ID3D11VideoDevice’
> >>  ID3D11VideoDevice   *video_device;
> >>  ^
> >> src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
> >> ‘ID3D11VideoContext’
> >>  ID3D11VideoContext  *video_context;
> >>  ^
> >
> > This is declared in d3d11.h and came with mingw64. Mine version has it:
> > msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> > Is it possible that we use different versions of mingw? Do you have it
> declared?
> >
> 
> If you use/rely on hwcontext_d3d11va, you should probably have a
> configure dependency on that part being available.

OK, use of hwcontext_d3d11va  is optional, I will put the dependent parts of 
the code under #ifdef

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

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

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[Hendrik Leppkes]

On Tue, Nov 7, 2017 at 2:57 PM, James Almer  wrote:
> On 11/7/2017 10:48 AM, Hendrik Leppkes wrote:
>> On Tue, Nov 7, 2017 at 1:28 PM, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> Attached patch fixes compilation with current libressl, related to ticket 
>>> #6801.
>>>
>>
>> I believe we basically had that exact same patch on the ML before, and
>> the consensus was to not have a jungle of #ifdefs in the code, and
>> instead have configure figure it out.
>
> configure could at most refuse to compile tls_openssl with libressl, but
> nothing to make it build successfully without ifdeffery.
>
> Is that preferred?

I meant to have configure figure out properly if OpenSSL 1.1 API is
available, and not repeat that check in the code several times, which
is growing more complex now.

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

Re: [FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

[James Almer]

On 11/7/2017 12:15 PM, Hendrik Leppkes wrote:
> On Tue, Nov 7, 2017 at 2:57 PM, James Almer  wrote:
>> On 11/7/2017 10:48 AM, Hendrik Leppkes wrote:
>>> On Tue, Nov 7, 2017 at 1:28 PM, Carl Eugen Hoyos  wrote:
 Hi!

 Attached patch fixes compilation with current libressl, related to ticket 
 #6801.

>>>
>>> I believe we basically had that exact same patch on the ML before, and
>>> the consensus was to not have a jungle of #ifdefs in the code, and
>>> instead have configure figure it out.
>>
>> configure could at most refuse to compile tls_openssl with libressl, but
>> nothing to make it build successfully without ifdeffery.
>>
>> Is that preferred?
> 
> I meant to have configure figure out properly if OpenSSL 1.1 API is
> available, and not repeat that check in the code several times, which
> is growing more complex now.
> 
> - Hendrik

So you mean replacing "#if OPENSSL_VERSION_NUMBER >= 0x101fL &&
!defined(LIBRESSL_VERSION_NUMBER)" with "#if CONFIG_OPENSSL_1_1" or
similar? Should be easy and agree it's slightly cleaner.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Daniel Kučera]

2017-11-07 15:25 GMT+01:00 Felix Matouschek :
> Am 02.11.2017 16:20, schrieb Daniel Kučera:
>
>> some devices have cameras which are unlisted - this condition makes
>> them unusable.
>
>
> How does one use unlisted devices? As far as I understood all supported
> devices are listed. If the Camera2 API does not support the camera
> it cannot be used.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

It's used like here:
https://github.com/danielkucera/ZidoStreamer/blob/master/app/src/main/java/eu/danman/zidostreamer/zidostreamer/StreamService.java#L62

If I open standard streaming or camera app, no camera is listed.

-- 

S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

> Am 07.11.2017 um 16:17 schrieb Daniel Kučera :
> 
> It's used like here:
> https://github.com/danielkucera/ZidoStreamer/blob/master/app/src/main/java/eu/danman/zidostreamer/zidostreamer/StreamService.java#L62
> 
> If I open standard streaming or camera app, no camera is listed.

Note that your application uses the Camera Java API, this indev uses the 
Camera2 NDK API.

I think this cannot be compared directly. Could you test it in your specific 
case, whether the camera is somehow available through the NDK? Please note that 
the Camera2 NDK API only works on devices with API Level 24+ (Android 7.0).

As far as I have seen the camera in your device must also specifically support 
the Camera2 API. Cameras that are designed for the old API are only available 
in the Java version of the Camera2 API. 

You can check this in Java with: 
https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

The NDK version only supports cameras that are on the hardware level LIMITED or 
above.

Greetings,
Felix

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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Daniel Kučera]

2017-11-07 18:47 GMT+01:00 Felix Matouschek :
>
>> Am 07.11.2017 um 16:17 schrieb Daniel Kučera :
>>
>> It's used like here:
>> https://github.com/danielkucera/ZidoStreamer/blob/master/app/src/main/java/eu/danman/zidostreamer/zidostreamer/StreamService.java#L62
>>
>> If I open standard streaming or camera app, no camera is listed.
>
> Note that your application uses the Camera Java API, this indev uses the 
> Camera2 NDK API.
>

You are probably right. My device has Android 4.4.2 only without any
hope for update so it won't work anyway.


-- 

S pozdravom / Best regards
Daniel Kucera.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_tile: add skip option

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  5 +
 libavfilter/vf_tile.c | 53 ++-
 2 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 2ba6e04166..a6d537485b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14439,6 +14439,11 @@ refer to the pad video filter.
 Specify the color of the unused area. For the syntax of this option, check the
 "Color" section in the ffmpeg-utils manual. The default value of @var{color}
 is "black".
+
+@item skip
+Set the number of frames to skip from input before rendering output frame.
+The default value is @code{0}, meaning skip @var{nb_frames} frames. If it is 
more
+than @var{nb_frames} its is set to @var{nb_frames}.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index e9d246fc73..089872831f 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -37,11 +37,13 @@ typedef struct TileContext {
 unsigned w, h;
 unsigned margin;
 unsigned padding;
+unsigned skip;
 unsigned current;
 unsigned nb_frames;
 FFDrawContext draw;
 FFDrawColor blank;
 AVFrame *out_ref;
+AVFrame *prev_out_ref;
 uint8_t rgba_color[4];
 } TileContext;
 
@@ -58,6 +60,8 @@ static const AVOption tile_options[] = {
 { "padding", "set inner border thickness in pixels", OFFSET(padding),
 AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1024, FLAGS },
 { "color",   "set the color of the unused area", OFFSET(rgba_color), 
AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
+{ "skip", "set how many frames to skip for each render", OFFSET(skip),
+AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
@@ -90,6 +94,10 @@ static av_cold int init(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
+if (!tile->skip)
+tile->skip = tile->nb_frames;
+tile->skip = FFMIN(tile->skip, tile->nb_frames);
+
 return 0;
 }
 
@@ -120,19 +128,19 @@ static int config_props(AVFilterLink *outlink)
 outlink->h = tile->h * inlink->h + total_margin_h;
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 outlink->frame_rate = av_mul_q(inlink->frame_rate,
-   av_make_q(1, tile->nb_frames));
+   av_make_q(1, tile->skip));
 ff_draw_init(&tile->draw, inlink->format, 0);
 ff_draw_color(&tile->draw, &tile->blank, tile->rgba_color);
 
 return 0;
 }
 
-static void get_current_tile_pos(AVFilterContext *ctx, unsigned *x, unsigned 
*y)
+static void get_tile_pos(AVFilterContext *ctx, unsigned *x, unsigned *y, 
unsigned current)
 {
 TileContext *tile= ctx->priv;
 AVFilterLink *inlink = ctx->inputs[0];
-const unsigned tx = tile->current % tile->w;
-const unsigned ty = tile->current / tile->w;
+const unsigned tx = current % tile->w;
+const unsigned ty = current / tile->w;
 
 *x = tile->margin + (inlink->w + tile->padding) * tx;
 *y = tile->margin + (inlink->h + tile->padding) * ty;
@@ -144,7 +152,7 @@ static void draw_blank_frame(AVFilterContext *ctx, AVFrame 
*out_buf)
 AVFilterLink *inlink = ctx->inputs[0];
 unsigned x0, y0;
 
-get_current_tile_pos(ctx, &x0, &y0);
+get_tile_pos(ctx, &x0, &y0, tile->current);
 ff_fill_rectangle(&tile->draw, &tile->blank,
   out_buf->data, out_buf->linesize,
   x0, y0, inlink->w, inlink->h);
@@ -160,8 +168,13 @@ static int end_last_frame(AVFilterContext *ctx)
 
 while (tile->current < tile->nb_frames)
 draw_blank_frame(ctx, out_buf);
+tile->current = tile->nb_frames - tile->skip;
+if (tile->current) {
+av_frame_free(&tile->prev_out_ref);
+tile->prev_out_ref = av_frame_clone(out_buf);
+}
 ret = ff_filter_frame(outlink, out_buf);
-tile->current = 0;
+tile->out_ref = NULL;
 return ret;
 }
 
@@ -176,7 +189,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
 AVFilterLink *outlink = ctx->outputs[0];
 unsigned x0, y0;
 
-if (!tile->current) {
+if (!tile->out_ref) {
 tile->out_ref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
 if (!tile->out_ref) {
 av_frame_free(&picref);
@@ -194,7 +207,21 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
   0, 0, outlink->w, outlink->h);
 }
 
-get_current_tile_pos(ctx, &x0, &y0);
+if (tile->prev_out_ref) {
+unsigned x1, y1, i;
+
+for (i = tile->skip; i < tile->nb_frames; i++) {
+get_tile_pos(ctx, &x1, &y1, i);
+get_tile_pos(ctx, &x0, &y0, i - tile->skip);
+ff_copy_rectangle2(&tile->draw,
+   tile->out_ref->data, tile->out_ref->linesize,
+   tile->prev_out_ref->data, 
tile->prev_out_ref->linesize,
+   x0, y0

Re: [FFmpeg-devel] libavcodec/mpegvideo : remove warning introduce by previous patch

[Martin Vignali]

2017-11-07 3:38 GMT+01:00 James Almer :

> On 11/6/2017 8:05 PM, Martin Vignali wrote:
> > Hello,
> >
> > Sorry, i put the ret variable declaration in the previous patch, at the
> > wrong place (at the start of the func, instead of inside the
> > FF_API_DEBUG_MV part
> >
> > patch in attach fix warning,
> >
> > Martin
>
> I'm not sure why you bothered to change disabled code in the first
> place, but pushed nonetheless.
>
>
the goal is to remove all use of this func,
Following doc/api changes, avcodec_get_chroma_sub_sample is deprecated
since 2012

Maybe this deprecated function can be remove soon (without depending of
other things)

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

[FFmpeg-devel] avcodec/losslessvideodsp : add avx2 for add_left_pred

[Martin Vignali]

Hello,

patchs in attach add avx2 version for add_left_pred

Pass fate test for me

checkasm test (kaby lake os 10.12)
with width = 1024

add_left_pred_zero_c: 1229.7
add_left_pred_zero_ssse3: 269.7
add_left_pred_zero_avx2: 217.9

0001-checkasm-llviddsp-test-return-of-add_left_pred-16
Modify the checkasm test in order to test the return value of the function

0002-avcodec-x86-lossless_videodsp.asm-make-macro-for-add
Create a macro for the SSSE3 version in order to add the avx2 version

0003-avcodec-x86-lossless_videodsp-add-avx2-version-for-a
Add the avx2 version

Martin


0001-checkasm-llviddsp-test-return-of-add_left_pred-16.patch
Description: Binary data


0002-avcodec-x86-lossless_videodsp.asm-make-macro-for-add.patch
Description: Binary data


0003-avcodec-x86-lossless_videodsp-add-avx2-version-for-a.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] lavu: add an AV_FRAME_DATA_GAMMA side data type

[Rostislav Pehlivanov]

On 6 November 2017 at 18:03, Nicolas George  wrote:

> Le sextidi 16 brumaire, an CCXXVI, Rostislav Pehlivanov a écrit :
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  doc/APIchanges  | 3 +++
> >  libavutil/frame.h   | 6 ++
> >  libavutil/version.h | 2 +-
> >  3 files changed, 10 insertions(+), 1 deletion(-)
>
> Sorry if it has come up before, but why not just add
>
> AVRational gamma;
>
> with 0/0 meaning unspecified? It seems like a relevant information, at
> least as much as AVColor*. And overall much simpler.
>
> Regards,
>
> --
>   Nicolas George
>

Gamma info is related to mastering info so API users expect to get both
using the same API rather than look for new fields in avframe and evaluate
whether they're different on a per-frame basis.
Also, it prevents from adding more fields to avframe and making a bigger
mess.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] fate/magicyuv : add test for magicyuv encoding

[Martin Vignali]

Hello,

Patch in attach add tests for magicyuv encoding (for the 3 prediction
(left, median, gradient))

0001-fate-magicyuv-move-decoding-test-to-magicyuv.mak-fil
move magicyuvdecoding test inside a new file

0002-fate-magicyuvenc-add-test-for-magicyuv-encoding
add test for encoding (based on utvideoencoding test, but limited to 5
output frames)


the framecrc of each output command, have been compared (after decoding) to
original data (using same flags)
the framecrc is the same.


Tested on x86_64 osx

Martin


0001-fate-magicyuv-move-decoding-test-to-magicyuv.mak-fil.patch
Description: Binary data


0002-fate-magicyuvenc-add-test-for-magicyuv-encoding.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fate/magicyuv : add test for magicyuv encoding

[Paul B Mahol]

On 11/7/17, Martin Vignali  wrote:
> Hello,
>
> Patch in attach add tests for magicyuv encoding (for the 3 prediction
> (left, median, gradient))
>
> 0001-fate-magicyuv-move-decoding-test-to-magicyuv.mak-fil
> move magicyuvdecoding test inside a new file
>
> 0002-fate-magicyuvenc-add-test-for-magicyuv-encoding
> add test for encoding (based on utvideoencoding test, but limited to 5
> output frames)
>
>
> the framecrc of each output command, have been compared (after decoding) to
> original data (using same flags)
> the framecrc is the same.
>
>
> Tested on x86_64 osx
>
> Martin
>

No need for this, encoder is still experimental.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for AMD

[Carl Eugen Hoyos]

2017-11-07 17:17 GMT+01:00 mmironov :

> diff --git a/Changelog b/Changelog
> index 6592d86..f0d22fa 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,7 +6,8 @@ version :
>  - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
>requires 2.1 (or later) and pkg-config.
>  - VDA dropped (use VideoToolbox instead)
> -
> +- AMF H.264 encoder
> +- AMF HEVC encoder

Please do not remove the empty line and please merge the two new lines.

Does the AMD hardware really support encoding to H.264 baseline?
I always thought baseline does not exist in the wild.

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

Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC encoding for AMD

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 7, 2017 4:44 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW accelerated H.264 and HEVC
> encoding for AMD
> 
> 2017-11-07 17:17 GMT+01:00 mmironov :
> 
> > diff --git a/Changelog b/Changelog
> > index 6592d86..f0d22fa 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -6,7 +6,8 @@ version :
> >  - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG
> now
> >requires 2.1 (or later) and pkg-config.
> >  - VDA dropped (use VideoToolbox instead)
> > -
> > +- AMF H.264 encoder
> > +- AMF HEVC encoder
> 
> Please do not remove the empty line and please merge the two new lines.

Sorry, where? My last change was to add #if CONFIG_D3D11VA.

> 
> Does the AMD hardware really support encoding to H.264 baseline?
> I always thought baseline does not exist in the wild.

It does but was exposed in public API more by accident then by intention. 
I removed it from ffmpeg integration as Mark requested. 

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

[FFmpeg-devel] Ffmpeg Lens Correction

[Agustín Trombotto]

Hi!
I ‘m working in a Project where we make a software to take 
images from an ip camera using Python embed in a raspberry. I have all the 
parameters of the camera (fx, fy, cx, cy, alpha, k1, k2, k3, p1, p2) calibrated 
in Matlab.
I would like to use ffmpeg to get the video from de camera with 
those parameters but lens corrections only use four of them (k1, k2, cx, cy). 
Do you know any library used by ffmpeg to use those other parameters? I can’t 
get good results.
Thanks you for now,
My regards,
Agustin
Enviado desde Correo para 
Windows 10

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

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

On Mon, Nov 06, 2017 at 12:30:02AM +, Rostislav Pehlivanov wrote:
> On 5 November 2017 at 23:39, Aurelien Jacobs  wrote:
> 
> > The encoder was reverse engineered from binary library and from
> > EP0398973B1 patent (long expired).
> > The decoder was simply deduced from the encoder.
> > ---
> >  doc/general.texi|   2 +
> >  libavcodec/Makefile |   2 +
> >  libavcodec/allcodecs.c  |   1 +
> >  libavcodec/aptx.c   | 854 ++
> > ++
> >  libavcodec/avcodec.h|   1 +
> >  libavcodec/codec_desc.c |   7 +
> >  6 files changed, 867 insertions(+)
> >  create mode 100644 libavcodec/aptx.c
> >
> 
> Very nice job

Thanks !

> > +
> > +static const int32_t quantization_factors[32] = {
> > +2048 << 11,
> > +2093 << 11,
> > +2139 << 11,
> > +2186 << 11,
> > +2233 << 11,
> > +2282 << 11,
> > +2332 << 11,
> > +2383 << 11,
> > +2435 << 11,
> > +2489 << 11,
> > +2543 << 11,
> > +2599 << 11,
> > +2656 << 11,
> > +2714 << 11,
> > +2774 << 11,
> > +2834 << 11,
> > +2896 << 11,
> > +2960 << 11,
> > +3025 << 11,
> > +3091 << 11,
> > +3158 << 11,
> > +3228 << 11,
> > +3298 << 11,
> > +3371 << 11,
> > +3444 << 11,
> > +3520 << 11,
> > +3597 << 11,
> > +3676 << 11,
> > +3756 << 11,
> > +3838 << 11,
> > +3922 << 11,
> > +4008 << 11,
> > +};
> >
> 
> 
> First of all, please put all numbers on the same line.
> Second of all, its pointless to do a shift here, either change the numbers
> or better yet, since you already do a shift down:
> 
> 
> 
> > +/* update quantization factor */
> > +idx = (invert_quantize->factor_select & 0xFF) >> 3;
> > +shift -= invert_quantize->factor_select >> 8;
> > +invert_quantize->quantization_factor = quantization_factors[idx] >>
> > shift;
> > +}
> >
> 
> 
> Which would be equivalent to:
> 
>  idx = (invert_quantize->factor_select & 0xFF) >> 3;
> > shift -= invert_quantize->factor_select >> 8;
> > invert_quantize->quantization_factor = (quantization_factors[idx] << 11)
> > >> shift;
> >
> 
> The compiler ought to be smart enough to handle that as a single operation.

I don't think the compiler will optimze as much, but that's a trivial
operation, and there is no mesurable difference, so indeed, I moved
the shift out of the table and cleaned up the formatting.

> > +static int##size##_t rshift##size(int##size##_t value, int shift)
> >  \
> >
> > +static int##size##_t rshift##size##_clip24(int##size##_t value, int
> > shift)\
> >
> > +static void aptx_update_codeword_history(Channel *channel)
> >
> > +static void aptx_generate_dither(Channel *channel)
> >
> >
> +static void aptx_qmf_filter_signal_push(FilterSignal *signal, int32_t
> > sample)
> >
> > +static int32_t aptx_qmf_convolution(FilterSignal *signal,
> > +const int32_t coeffs[FILTER_TAPS],
> > +int shift)
> >
> > +static void aptx_qmf_polyphase_analysis(FilterSignal signal[NB_FILTERS],
> > +const int32_t
> > coeffs[NB_FILTERS][FILTER_TAPS],
> > +int shift,
> > +int32_t samples[NB_FILTERS],
> > +int32_t *low_subband_output,
> > +int32_t *high_subband_output)
> > +
> >
> 
> 
> Add an inline flag to small functions like these. Won't make a difference
> but eh.

Done.

> > +
> > +static void aptx_quantise_difference(Quantize *quantize,
> > + int32_t sample_difference,
> > + int32_t dither,
> > + int32_t quantization_factor,
> > + ConstTables *tables)
> >
> 
> English spelling of quantize? I prefer quantize since that's how its
> spelled throughout the entire codebase.

Good catch. Fixed.

> > +{
> > +const int32_t *intervals = tables->quantize_intervals;
> > +int32_t quantized_sample, dithered_sample, parity_change;
> > +int32_t d, mean, interval, inv;
> > +int64_t error;
> > +
> > +quantized_sample = aptx_bin_search(FFABS(sample_difference) >> 4,
> > +   quantization_factor,
> > +   intervals, tables->tables_size);
> > +
> > +d = rshift32_clip24(MULH(dither, dither), 7) - (1 << 23);
> > +d = rshift64(MUL64(d, 
> > tables->quantize_dither_factors[quantized_sample]),
> > 23);
> > +
> > +intervals += quantized_sample;
> > +mean = (intervals[1] + intervals[0]) / 2;
> > +interval = intervals[1] - intervals[0];
> > +if (sample_difference < 0)
> > +interval = -interval;
> >
> 
> 
> Can be simplified to:
> interval *= 1 - 2*(sample_difference < 0);
> or
> interval *= sample_difference < 0 ? -1 : +1;

I prefer:
interva

[FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Aurelien Jacobs]

The encoder was reverse engineered from binary library and from
EP0398973B1 patent (long expired).
The decoder was simply deduced from the encoder.
---
 doc/general.texi|   2 +
 libavcodec/Makefile |   2 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/aptx.c   | 826 
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 6 files changed, 839 insertions(+)
 create mode 100644 libavcodec/aptx.c

diff --git a/doc/general.texi b/doc/general.texi
index 9e6ae13435..4a89531c47 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -991,6 +991,8 @@ following image formats are supported:
 @item Amazing Studio PAF Audio @tab @tab  X
 @item Apple lossless audio   @tab  X  @tab  X
 @tab QuickTime fourcc 'alac'
+@item aptX   @tab  X  @tab  X
+@tab Used in Bluetooth A2DP
 @item ATRAC1 @tab @tab  X
 @item ATRAC3 @tab @tab  X
 @item ATRAC3+@tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3a33361f33..25706a263d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -188,6 +188,8 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o 
mjpegenc_common.o \
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
+OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
+OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 98655ddd7c..61abe9939c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -406,6 +406,7 @@ static void register_all(void)
 REGISTER_DECODER(AMRNB, amrnb);
 REGISTER_DECODER(AMRWB, amrwb);
 REGISTER_DECODER(APE,   ape);
+REGISTER_ENCDEC (APTX,  aptx);
 REGISTER_DECODER(ATRAC1,atrac1);
 REGISTER_DECODER(ATRAC3,atrac3);
 REGISTER_DECODER(ATRAC3AL,  atrac3al);
diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
new file mode 100644
index 00..b2879ea370
--- /dev/null
+++ b/libavcodec/aptx.c
@@ -0,0 +1,826 @@
+/*
+ * Audio Processing Technology codec for Bluetooth (aptX)
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * 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 "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "internal.h"
+#include "mathops.h"
+
+
+enum channels {
+LEFT,
+RIGHT,
+NB_CHANNELS
+};
+
+enum subbands {
+LF,  // Low Frequency (0-5.5 kHz)
+MLF, // Medium-Low Frequency (5.5-11kHz)
+MHF, // Medium-High Frequency (11-16.5kHz)
+HF,  // High Frequency (16.5-22kHz)
+NB_SUBBANDS
+};
+
+#define NB_FILTERS 2
+#define FILTER_TAPS 16
+
+typedef struct {
+int pos;
+int32_t buffer[2*FILTER_TAPS];
+} FilterSignal;
+
+typedef struct {
+FilterSignal outer_filter_signal[NB_FILTERS];
+FilterSignal inner_filter_signal[NB_FILTERS][NB_FILTERS];
+} QMFAnalysis;
+
+typedef struct {
+int32_t quantized_sample;
+int32_t quantized_sample_parity_change;
+int32_t error;
+} Quantize;
+
+typedef struct {
+int32_t quantization_factor;
+int32_t factor_select;
+int32_t reconstructed_difference;
+} InvertQuantize;
+
+typedef struct {
+int32_t prev_sign[2];
+int32_t s_weight[2];
+int32_t d_weight[24];
+int32_t pos;
+int32_t reconstructed_differences[48];
+int32_t previous_reconstructed_sample;
+int32_t predicted_difference;
+int32_t predicted_sample;
+} Prediction;
+
+typedef struct {
+int32_t codeword_history;
+int32_t dither_parity;
+int32_t dither[NB_SUBBANDS];
+
+QMFAnalysis qmf;
+Quantize quantize[NB_SUBBANDS];
+InvertQuantize invert_quantize[NB_SUBBANDS];
+Prediction prediction[NB_SUBBANDS];
+} Channel;
+
+typedef struct {
+int32_t sync_idx;
+Channel channels[NB_CHANNELS];
+} AptXContext;
+
+
+static const int32_t quantize_intervals_LF[65] = {
+  -9948,9948,   29860,   49808,   69822,   89

[FFmpeg-devel] [PATCH 2/2] aptx: add raw muxer and demuxer for aptX

[Aurelien Jacobs]

---
 doc/general.texi |  1 +
 libavformat/Makefile |  2 ++
 libavformat/allformats.c |  1 +
 libavformat/aptxdec.c| 58 
 libavformat/rawenc.c | 13 +++
 libavformat/utils.c  |  1 +
 6 files changed, 76 insertions(+)
 create mode 100644 libavformat/aptxdec.c

diff --git a/doc/general.texi b/doc/general.texi
index 4a89531c47..79e0bd0993 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -439,6 +439,7 @@ library:
 @item QCP   @tab   @tab X
 @item raw ADTS (AAC)@tab X @tab X
 @item raw AC-3  @tab X @tab X
+@item raw aptX  @tab X @tab X
 @item raw Chinese AVS video @tab X @tab X
 @item raw CRI ADX   @tab X @tab X
 @item raw Dirac @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index caebe5b146..21fb892a81 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -92,6 +92,8 @@ OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
 OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
+OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
+OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
 avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5ad9..40964a0df0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -67,6 +67,7 @@ static void register_all(void)
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
 REGISTER_MUXDEMUX(APNG, apng);
+REGISTER_MUXDEMUX(APTX, aptx);
 REGISTER_DEMUXER (AQTITLE,  aqtitle);
 REGISTER_MUXDEMUX(ASF,  asf);
 REGISTER_DEMUXER (ASF_O,asf_o);
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
new file mode 100644
index 00..90ce789454
--- /dev/null
+++ b/libavformat/aptxdec.c
@@ -0,0 +1,58 @@
+/*
+ * RAW aptX demuxer
+ *
+ * Copyright (C) 2017  Aurelien Jacobs 
+ *
+ * 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 "avformat.h"
+#include "rawdec.h"
+
+#define APTX_BLOCK_SIZE   4
+#define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
+
+static int aptx_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_APTX;
+st->codecpar->format = AV_SAMPLE_FMT_S32P;
+st->codecpar->channels = 2;
+st->codecpar->sample_rate = 44100;
+st->codecpar->bits_per_coded_sample = 4;
+st->codecpar->block_align = APTX_BLOCK_SIZE;
+st->codecpar->frame_size = APTX_PACKET_SIZE;
+st->start_time = 0;
+return 0;
+}
+
+static int aptx_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+return av_get_packet(s->pb, pkt, APTX_PACKET_SIZE);
+}
+
+AVInputFormat ff_aptx_demuxer = {
+.name   = "aptx",
+.long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
+.extensions = "aptx",
+.read_header= aptx_read_header,
+.read_packet= aptx_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index f640121cb4..aa3ef76fbf 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -91,6 +91,19 @@ AVOutputFormat ff_adx_muxer = {
 };
 #endif
 
+#if CONFIG_APTX_MUXER
+AVOutputFormat ff_aptx_muxer = {
+.name  = "aptx",
+.long_name = NULL_IF_CONFIG_SMALL("raw aptX (Audio Processing 
Technology for Bluetooth)"),
+.extensions= "aptx",
+.audio_codec   = AV_CODEC_ID_APTX,
+.video_codec   = AV_CODEC_ID_NONE,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
 #if CONFIG_CAVSVIDEO_MUXER
 AVOutputFormat ff_cavsvideo_muxer = {
 .name  = "cavsvideo",
dif

Re: [FFmpeg-devel] Ffmpeg Lens Correction

[Rostislav Pehlivanov]

On 7 November 2017 at 20:47, Agustín Trombotto 
wrote:

>
> Hi!
> I ‘m working in a Project where we make a software to take
> images from an ip camera using Python embed in a raspberry. I have all the
> parameters of the camera (fx, fy, cx, cy, alpha, k1, k2, k3, p1, p2)
> calibrated in Matlab.
> I would like to use ffmpeg to get the video from de camera
> with those parameters but lens corrections only use four of them (k1, k2,
> cx, cy). Do you know any library used by ffmpeg to use those other
> parameters? I can’t get good results.
> Thanks you for now,
> My regards,
> Agustin
> Enviado desde Correo para
> Windows 10
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

vf_convolve can, but you'll need to convert those parameters to a frame
such that when convolved with the input it would do the correction
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] aptx: implement the aptX bluetooth codec

[Rostislav Pehlivanov]

On 7 November 2017 at 22:26, Aurelien Jacobs  wrote:

> The encoder was reverse engineered from binary library and from
> EP0398973B1 patent (long expired).
> The decoder was simply deduced from the encoder.
> ---
>  doc/general.texi|   2 +
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/aptx.c   | 826 ++
> ++
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  6 files changed, 839 insertions(+)
>  create mode 100644 libavcodec/aptx.c
>
>
LGTM, will apply tomorrow unless there are any complains



interval *= -(sample_difference < 0) | 1;
>

Neat, I'll keep this trick in mind
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fixing small memory leak when wrapping texture in AVD3D11FrameDescriptor

[Aaron Levinson]

On 11/4/2017 9:43 PM, Greg Wessels wrote:

---
  libavutil/hwcontext_d3d11va.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 52683b9..65dd665 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -123,6 +123,7 @@ static void d3d11va_frames_uninit(AVHWFramesContext *ctx)
  static void free_texture(void *opaque, uint8_t *data)
  {
  ID3D11Texture2D_Release((ID3D11Texture2D *)opaque);
+av_free(data);
  }
  
  static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)




LGTM.  I've also noticed a memory leak with hardware-accelerated D3D11 
H.264 decoding, and this patch fixes the issue.  The actual memory leak 
originates from wrap_texture_buf() in the same file from the following line:


AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));

and there will be one leak per surface per hardware decoding session. 
The number of surfaces can vary, but for H.264 and HEVC, it is equal to 
20 (4 + 16).  So, for H.264, there will be 20 leaks per decoding session.


It would be helpful to see this committed soon.  Additionally, I looked 
at the libav source base, and this issue exists there as well.


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

Re: [FFmpeg-devel] [PATCH] Fixing small memory leak when wrapping texture in AVD3D11FrameDescriptor

[James Almer]

On 11/7/2017 10:50 PM, Aaron Levinson wrote:
> On 11/4/2017 9:43 PM, Greg Wessels wrote:
>> ---
>>   libavutil/hwcontext_d3d11va.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/libavutil/hwcontext_d3d11va.c
>> b/libavutil/hwcontext_d3d11va.c
>> index 52683b9..65dd665 100644
>> --- a/libavutil/hwcontext_d3d11va.c
>> +++ b/libavutil/hwcontext_d3d11va.c
>> @@ -123,6 +123,7 @@ static void
>> d3d11va_frames_uninit(AVHWFramesContext *ctx)
>>   static void free_texture(void *opaque, uint8_t *data)
>>   {
>>   ID3D11Texture2D_Release((ID3D11Texture2D *)opaque);
>> +    av_free(data);
>>   }
>>     static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
>>
> 
> LGTM.  I've also noticed a memory leak with hardware-accelerated D3D11
> H.264 decoding, and this patch fixes the issue.  The actual memory leak
> originates from wrap_texture_buf() in the same file from the following
> line:
> 
>     AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
> 
> and there will be one leak per surface per hardware decoding session.
> The number of surfaces can vary, but for H.264 and HEVC, it is equal to
> 20 (4 + 16).  So, for H.264, there will be 20 leaks per decoding session.
> 
> It would be helpful to see this committed soon.  Additionally, I looked
> at the libav source base, and this issue exists there as well.
> 
> Aaron Levinson

I'm not the maintainer of hwcontext_d3d11va, but the patch is pretty
straightforward, so pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: move priv_pts from AVStream to an internal struct

[James Almer]

On 11/6/2017 8:43 PM, Michael Niedermayer wrote:
> On Sun, Nov 05, 2017 at 03:06:56PM -0300, James Almer wrote:
>> It has no reason to be in a public header, even if defined as private.
>>
>> Signed-off-by: James Almer 
>> ---
>> To be honest, none of the fields below the "not part of the API" notice
>> have any reason to be in the public struct, but this one is particularly
>> pointless and ugly to have there as FFFrac is defined in internal.h
>>
>>  libavformat/avformat.h |  2 --
>>  libavformat/internal.h |  2 ++
>>  libavformat/mux.c  | 18 +-
>>  libavformat/utils.c|  6 +++---
>>  4 files changed, 14 insertions(+), 14 deletions(-)
> 
> probably ok
> 
> thx

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Steven Liu]

2017-11-07 21:32 GMT+08:00 Dixit, Vishwanath :
>
>
>>On 11/3/17, 8:31 PM, "刘歧"  wrote:
>>look at your mail title please!
>>and read the test case which i write for the fate-filter-hls-append
>
> Thanks for your clarification on sample HLS encoder test.  I have referred to 
> the test fate-filter-hls-append and added one more test with name 
> filter-hls-vs-with-master. This new test verifies HLS variant stream creation 
> and master playlist creation.
> Apart from this, I have made a minor snprintf related update, based on the 
> comment by Michael Niedermayer and also have re-based the earlier patches. 
> Please find the updated patches in the attachment and let us know if they are 
> fine.
>
> Thanks & Regards,
> Vishwanath
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


There have no master playlist after use patchset:

test command line at bellow:


liuqideMBP:xxx liuqi$ ./ffmpeg -f lavfi -i color=red -f lavfi -i
anullsrc -g 25 -r 25 -b:v:0 1000k -b:v:1 256k -b:a:1 64k -b:a:1 32k
-map 0:v -map 1:a -map 0:v -map 1:a -f hls -var_stream_map "v:0,a:0
v:1,a:1" -t 10 -hls_time 2 output_sl.m3u8
ffmpeg version N-88638-gc72abbd0dc Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 8.1.0 (clang-802.0.42)
  configuration: --enable-fontconfig --enable-gpl --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libspeex --enable-libx264 --enable-libx265
--enable-libfdk-aac --enable-version3 --cc='ccache gcc'
--enable-nonfree --enable-videotoolbox
  libavutil  56.  0.100 / 56.  0.100
  libavcodec 58.  1.100 / 58.  1.100
  libavformat58.  2.102 / 58.  2.102
  libavdevice58.  0.100 / 58.  0.100
  libavfilter 7.  0.101 /  7.  0.101
  libswscale  5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc55.  0.100 / 55.  0.100
Input #0, lavfi, from 'color=red':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 320x240
[SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Input #1, lavfi, from 'anullsrc':
  Duration: N/A, start: 0.00, bitrate: 705 kb/s
Stream #1:0: Audio: pcm_u8, 44100 Hz, stereo, u8, 705 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
  Stream #1:0 -> #0:1 (pcm_u8 (native) -> aac (native))
  Stream #0:0 -> #0:2 (rawvideo (native) -> h264 (libx264))
  Stream #1:0 -> #0:3 (pcm_u8 (native) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0x7fdf7e040c00] using SAR=1/1
[libx264 @ 0x7fdf7e040c00] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX
[libx264 @ 0x7fdf7e040c00] profile High, level 2.0
[libx264 @ 0x7fdf7e040c00] 264 - core 148 r2694 3b70645 - H.264/MPEG-4
AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html -
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2
threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1
interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2
b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=25
keyint_min=2 scenecut=40 intra_refresh=0 rc_lookahead=25 rc=abr
mbtree=1 bitrate=1000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4
ip_ratio=1.40 aq=1:1.00
[libx264 @ 0x7fdf7e043600] using SAR=1/1
[libx264 @ 0x7fdf7e043600] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX
[libx264 @ 0x7fdf7e043600] profile High, level 1.3
[libx264 @ 0x7fdf7e043600] 264 - core 148 r2694 3b70645 - H.264/MPEG-4
AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html -
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2
threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1
interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2
b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=25
keyint_min=2 scenecut=40 intra_refresh=0 rc_lookahead=25 rc=abr
mbtree=1 bitrate=256 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4
ip_ratio=1.40 aq=1:1.00
[hls @ 0x7fdf7e03f000] Opening 'output_sl0_0.ts' for writing
[hls @ 0x7fdf7e03f000] Opening 'output_sl0_1.ts' for writing
Output #0, hls, to 'output_sl.m3u8':
  Metadata:
encoder : Lavf58.2.102
Stream #0:0: Video: h264 (libx264), yuv420p(progressive), 320x240
[SAR 1:1 DAR 4:3], q=-1--1, 1000 kb/s, 25 fps, 90k tbn, 25 tbc
Metadata:
  encoder : Lavc58.1.100 libx264
Side data:
  cpb: bitrate max/min/avg: 0/0/100 buffer size: 0 vbv_delay: -1
Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, 128 kb/s
Metadata:
  encoder : Lavc58.1.100 aac
Stream #0:2: Video: h264 (libx264), yuv420p(

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Dixit, Vishwanath]

>There have no master playlist after use patchset:
>
>test command line at bellow:
>   
>
>liuqideMBP:xxx liuqi$ ./ffmpeg -f lavfi -i color=red -f lavfi -i
>anullsrc -g 25 -r 25 -b:v:0 1000k -b:v:1 256k -b:a:1 64k -b:a:1 32k
>-map 0:v -map 1:a -map 0:v -map 1:a -f hls -var_stream_map "v:0,a:0
>v:1,a:1" -t 10 -hls_time 2 output_sl.m3u8
 
Master playlist is creation is optional. It is created only when 
-master_pl_name parameter is set. Please use the command as below
./ffmpeg -f lavfi -i color=red -f lavfi –I anullsrc -g 25 -r 25 -b:v:0 1000k 
-b:v:1 256k -b:a:1 64k -b:a:1 32k  -map 0:v -map 1:a -map 0:v -map 1:a -f hls 
-var_stream_map "v:0,a:0  v:1,a:1" -master_pl_name  master.m3u8 -t 10 -hls_time 
2 output_sl.m3u8

Regards,
Vishwanath


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