[FFmpeg-devel] [PATCH v8] Add support for Audible AA files

[Vesselin Bontchev]

Hi!

It would be awesome to have this patch merged in FFmpeg.

VesselinFrom d8a6d0d7052ebdb7caa8dd9a7d571a68339d7acc Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev 
Date: Sun, 19 Jul 2015 23:16:36 +0200
Subject: [PATCH] Add support for Audible AA files

https://en.wikipedia.org/wiki/Audible.com#Quality
---
 doc/demuxers.texi|   6 +
 doc/general.texi |   2 +
 libavformat/Makefile |   1 +
 libavformat/aadec.c  | 303 +++
 libavformat/allformats.c |   1 +
 5 files changed, 313 insertions(+)
 create mode 100644 libavformat/aadec.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index eb7cd4b..34bfc9b 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -18,6 +18,12 @@ enabled demuxers.
 
 The description of some of the currently available demuxers follows.
 
+@section aa
+
+Audible Format 2, 3, and 4 demuxer.
+
+This demuxer is used to demux Audible Format 2, 3, and 4 (.aa) files.
+
 @section applehttp
 
 Apple HTTP Live Streaming demuxer.
diff --git a/doc/general.texi b/doc/general.texi
index a260e79..2b782e0 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -228,6 +228,8 @@ library:
 @item 8088flex TMV  @tab   @tab X
 @item AAX   @tab   @tab X
 @tab Audible Enhanced Audio format, used in audiobooks.
+@item AA@tab   @tab X
+@tab Audible Format 2, 3, and 4, used in audiobooks.
 @item ACT Voice @tab   @tab X
 @tab contains G.729 audio
 @item Adobe Filmstrip   @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cc73fd8..466da51 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -59,6 +59,7 @@ OBJS-$(CONFIG_SHARED)+= log2_tab.o golomb_tab.o
 
 # muxers/demuxers
 OBJS-$(CONFIG_A64_MUXER) += a64.o rawenc.o
+OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
 OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o rawdec.o
 OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
 OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
diff --git a/libavformat/aadec.c b/libavformat/aadec.c
new file mode 100644
index 000..8e6140e
--- /dev/null
+++ b/libavformat/aadec.c
@@ -0,0 +1,303 @@
+/*
+ * Audible AA demuxer
+ * Copyright (c) 2015 Vesselin Bontchev
+ *
+ * Header parsing is borrowed from https://github.com/jteeuwen/audible project.
+ * Copyright (c) 2001-2014, Jim Teeuwen
+ *
+ * Redistribution and use in source and binary forms, with or without modification,
+ * are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice, this
+ *list of conditions and the following disclaimer.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
+ * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/tea.h"
+#include "libavutil/opt.h"
+
+#define AA_MAGIC 1469084982 /* this identifies an audible .aa file */
+#define MAX_CODEC_SECOND_SIZE 3982
+#define MAX_TOC_ENTRIES 16
+#define MAX_DICTIONARY_ENTRIES 128
+#define TEA_BLOCK_SIZE 8
+
+typedef struct AADemuxContext {
+AVClass *class;
+uint8_t *aa_fixed_key;
+int aa_fixed_key_len;
+int codec_second_size;
+int current_codec_second_size;
+int chapter_idx;
+struct AVTEA *tea_ctx;
+uint8_t file_key[16];
+int64_t current_chapter_size;
+} AADemuxContext;
+
+static int get_second_size(char *codec_name)
+{
+int result = -1;
+
+if (!strcmp(codec_name, "mp332")) {
+result = 3982;
+} else if (!strcmp(codec_name, "acelp16")) {
+result = 2000;
+} else if (!strcmp(codec_name, "acelp85")) {
+result = 1045;
+}
+
+return result;
+}
+
+static int aa_read_header(AVFormatContext *s)
+{
+int i, j, idx, largest_idx = -1;
+uint32_t nkey, nval, toc_size, npairs, header_seed, start;
+char key[128], val[128], codec_name[64] = {0};
+uint8_t output[24], dst[8], src[8];
+int64_t largest_size = -1, current_size = -1;
+struct toc_entry {
+uint32_t offset;
+uint32_t size;
+} TOC[MAX_TOC_ENTRIES];
+uint32_t header_key_part[4];
+uint8_t header_

Re: [FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Ganesh Ajjanagadde]

On Wed, Aug 19, 2015 at 10:24 PM, Ganesh Ajjanagadde  wrote:
> On Wed, Aug 19, 2015 at 9:14 PM, Stephan Holljes
>  wrote:
>> On Thu, Aug 20, 2015 at 2:39 AM, Ganesh Ajjanagadde  wrote:
>>> On Wed, Aug 19, 2015 at 7:59 PM, Stephan Holljes
>>>  wrote:
 On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde  
 wrote:
> On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
>  wrote:
>> ---
>>  libavformat/http.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index a136918..4dbef3f 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
>> status_code)
>>  reply_text = "OK";
>>  content_type = "application/octet-stream";
>>  break;
>> +case 301:
>> +reply_code = 301;
>> +reply_text = "Moved Permanently";
>> +break;
>
> 301 is usually used for URL redirection,
> and you don't seem to do anything beyond setting the message.
> There needs to be additional logic somewhere to handle this.
> Nevertheless, it is still ok as a patch to me,
> since I assume this will be handled later on.
> I strongly suggest adding something to clarify this in the commit message.

 I did not think about that and so far I have only used it in my
 modified ffserver code. What makes a 301 reply different from the
 other replies? Maybe I didn't understand the RFC correctly.
>>>
>>> Quoting from the RFC:
>>> "The new permanent URI SHOULD be given by the Location field in the 
>>> response.
>>> Unless the request method was HEAD,
>>> the entity of the response SHOULD contain a short hypertext note with
>>> a hyperlink to the new URI(s). "
>>>
>>> My point is that somewhere in the response a new URI must be provided,
>>> so that the client can go to the redirected location.
>>> I don't know where/how such logic should go, but it needs to be done.
>>>
>>
>> Ah yes, thus far the application had to take care of that. Using the
>> location field in HTTPContext seems like a good place to store this
>> information. I will work on a patch that includes this. Thanks!
>
> BTW, are you sure line 383 is right?
> message_len could be set above sizeof(message) (if we hit the buffer
> size limit).
> I do not think (but can't confirm easily) that ffurl_write requires
> size < sizeof(buf).

sorry, typo: do not think -> think

> See e.g line 1097 - use the strlen function to get the correct message length,
> or alternatively (to avoid the strlen call) saturate the return value
> of snprintf
> to the value you need.
>
> In fact, I don't know why strlen is being used in 1097,
> it is an additional call that can be avoided by utilizing return value
> of the snprintf.
> You might want to look into this and similar instances.
>
>>

>
>>  case AVERROR_HTTP_SERVER_ERROR:
>>  case 500:
>>  reply_code = 500;
>>  reply_text = "Internal server error";
>>  break;
>> +case 503:
>> +reply_code = 503;
>> +reply_text = "Service Unavailable";
>> +break;
>
> Looks ok to me.
>
>>  default:
>>  return AVERROR(EINVAL);
>>  }
>> --
>> 2.1.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Ganesh Ajjanagadde]

On Wed, Aug 19, 2015 at 9:14 PM, Stephan Holljes
 wrote:
> On Thu, Aug 20, 2015 at 2:39 AM, Ganesh Ajjanagadde  wrote:
>> On Wed, Aug 19, 2015 at 7:59 PM, Stephan Holljes
>>  wrote:
>>> On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde  
>>> wrote:
 On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
  wrote:
> ---
>  libavformat/http.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index a136918..4dbef3f 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
> status_code)
>  reply_text = "OK";
>  content_type = "application/octet-stream";
>  break;
> +case 301:
> +reply_code = 301;
> +reply_text = "Moved Permanently";
> +break;

 301 is usually used for URL redirection,
 and you don't seem to do anything beyond setting the message.
 There needs to be additional logic somewhere to handle this.
 Nevertheless, it is still ok as a patch to me,
 since I assume this will be handled later on.
 I strongly suggest adding something to clarify this in the commit message.
>>>
>>> I did not think about that and so far I have only used it in my
>>> modified ffserver code. What makes a 301 reply different from the
>>> other replies? Maybe I didn't understand the RFC correctly.
>>
>> Quoting from the RFC:
>> "The new permanent URI SHOULD be given by the Location field in the response.
>> Unless the request method was HEAD,
>> the entity of the response SHOULD contain a short hypertext note with
>> a hyperlink to the new URI(s). "
>>
>> My point is that somewhere in the response a new URI must be provided,
>> so that the client can go to the redirected location.
>> I don't know where/how such logic should go, but it needs to be done.
>>
>
> Ah yes, thus far the application had to take care of that. Using the
> location field in HTTPContext seems like a good place to store this
> information. I will work on a patch that includes this. Thanks!

BTW, are you sure line 383 is right?
message_len could be set above sizeof(message) (if we hit the buffer
size limit).
I do not think (but can't confirm easily) that ffurl_write requires
size < sizeof(buf).
See e.g line 1097 - use the strlen function to get the correct message length,
or alternatively (to avoid the strlen call) saturate the return value
of snprintf
to the value you need.

In fact, I don't know why strlen is being used in 1097,
it is an additional call that can be avoided by utilizing return value
of the snprintf.
You might want to look into this and similar instances.

>
>>>

>  case AVERROR_HTTP_SERVER_ERROR:
>  case 500:
>  reply_code = 500;
>  reply_text = "Internal server error";
>  break;
> +case 503:
> +reply_code = 503;
> +reply_text = "Service Unavailable";
> +break;

 Looks ok to me.

>  default:
>  return AVERROR(EINVAL);
>  }
> --
> 2.1.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavf/http: Add error codes 301 and 503 and make replies more customizable

[Stephan Holljes]

Signed-off-by: Stephan Holljes 
---
 libavformat/http.c | 44 +++-
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index bfe6801..996c130 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -331,9 +331,10 @@ int ff_http_averror(int status_code, int default_averror)
 static int http_write_reply(URLContext* h, int status_code)
 {
 int ret, body = 0, reply_code, message_len;
-const char *reply_text, *content_type;
+const char *reply_text, *content_type, *location = NULL, *headers = "\r\n";
 HTTPContext *s = h->priv_data;
 char message[BUFFER_SIZE];
+char body_content[BUFFER_SIZE];
 content_type = "text/plain";
 
 if (status_code < 0)
@@ -359,28 +360,61 @@ static int http_write_reply(URLContext* h, int 
status_code)
 reply_text = "OK";
 content_type = "application/octet-stream";
 break;
+case 301:
+reply_code = 301;
+reply_text = "Moved Permanently";
+if (av_strcasecmp(s->method, "HEAD")) {
+if (!s->location) {
+av_log(s, AV_LOG_WARNING, "Reply code 301, but no redirection 
url set\n");
+break;
+}
+location = av_strdup(s->location);
+}
+
+break;
 case AVERROR_HTTP_SERVER_ERROR:
 case 500:
 reply_code = 500;
 reply_text = "Internal server error";
 break;
+case 503:
+reply_code = 503;
+reply_text = "Service Unavailable";
+break;
 default:
 return AVERROR(EINVAL);
 }
+if (s->reply_text)
+reply_text = s->reply_text;
+if (s->content_type)
+content_type = s->content_type;
+if (s->headers)
+headers = s->headers;
+if (s->body) {
+av_strlcpy(body_content, s->body, BUFFER_SIZE);
+body = 1;
+} else {
+snprintf(body_content, BUFFER_SIZE, "%03d %s\r\n", reply_code, 
reply_text);
+}
+
 if (body) {
 s->chunked_post = 0;
 message_len = snprintf(message, sizeof(message),
  "HTTP/1.1 %03d %s\r\n"
  "Content-Type: %s\r\n"
  "Content-Length: %zu\r\n"
+ "%s%s"
+ "%s"
  "\r\n"
- "%03d %s\r\n",
+ "%s",
  reply_code,
  reply_text,
  content_type,
- strlen(reply_text) + 6, // 3 digit status code + space + \r\n
- reply_code,
- reply_text);
+ strlen(body_content),
+ location ? "Location: " : "",
+ location ? location : "",
+ headers,
+ body_content);
 } else {
 s->chunked_post = 1;
 message_len = snprintf(message, sizeof(message),
-- 
2.1.0

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

[FFmpeg-devel] [PATCH 1/2] lavf/http: Parse and/or expose various client data.

[Stephan Holljes]

Signed-off-by: Stephan Holljes 
---
 libavformat/http.c | 40 ++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index a136918..bfe6801 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -64,12 +64,14 @@ typedef struct HTTPContext {
 int64_t chunksize;
 int64_t off, end_off, filesize;
 char *location;
+char *host;
 HTTPAuthState auth_state;
 HTTPAuthState proxy_auth_state;
 char *headers;
 char *mime_type;
 char *user_agent;
 char *content_type;
+char *body;
 /* Set if the server correctly handles Connection: close and will close
  * the connection after feeding us the content. */
 int willclose;
@@ -107,10 +109,14 @@ typedef struct HTTPContext {
 int reconnect;
 int listen;
 char *resource;
+char *query;
+char *http_version;
 int reply_code;
+char *reply_text;
 int is_multi_client;
 HandshakeState handshake_step;
 int is_connected_server;
+int skip_read_header;
 } HTTPContext;
 
 #define OFFSET(x) offsetof(HTTPContext, x)
@@ -123,6 +129,7 @@ static const AVOption options[] = {
 { "chunked_post", "use(s) chunked transfer-encoding for posts", 
OFFSET(chunked_post), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, D | E },
 { "headers", "set custom HTTP headers, can override built in default 
headers", OFFSET(headers), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D | E },
 { "content_type", "set a specific content type for the POST messages", 
OFFSET(content_type), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D | E },
+{ "body", "set the body of a simple HTTP reply", OFFSET(body), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
 { "user_agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, { .str = DEFAULT_USER_AGENT }, 0, 0, D },
 { "user-agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, { .str = DEFAULT_USER_AGENT }, 0, 0, D },
 { "multiple_requests", "use persistent connections", 
OFFSET(multiple_requests), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D | E },
@@ -141,10 +148,14 @@ static const AVOption options[] = {
 { "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, { .i64 
= 0 }, 0, INT64_MAX, D },
 { "end_offset", "try to limit the request to bytes preceding this offset", 
OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
 { "method", "Override the HTTP method or set the expected HTTP method from 
a client", OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
+{ "http_version", "The http version string received from a client.", 
OFFSET(http_version), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, D | 
AV_OPT_FLAG_READONLY },
 { "reconnect", "auto reconnect after disconnect before EOF", 
OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
 { "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0 
}, 0, 2, D | E },
 { "resource", "The resource requested by a client", OFFSET(resource), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
+{ "query", "The query requested by a client", OFFSET(query), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
 { "reply_code", "The http status code to return to a client", 
OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
+{ "reply_text", "Set a custom reply text to replace standard HTTP 
replies", OFFSET(reply_text), AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, E},
+{ "hostname", "The Host-parameter of an incoming HTTP request.", 
OFFSET(host), AV_OPT_TYPE_STRING, { .str = NULL}, 0, 0, E},
 { NULL }
 };
 
@@ -506,6 +517,7 @@ static int http_accept(URLContext *s, URLContext **c)
 HTTPContext *cc;
 URLContext *sl = sc->hd;
 URLContext *cl = NULL;
+char *peeraddr;
 
 av_assert0(sc->listen);
 if ((ret = ffurl_alloc(c, s->filename, s->flags, &sl->interrupt_callback)) 
< 0)
@@ -515,6 +527,9 @@ static int http_accept(URLContext *s, URLContext **c)
 goto fail;
 cc->hd = cl;
 cc->is_multi_client = 1;
+if ((ret = av_opt_get(cc, "sock_addr_str", AV_OPT_SEARCH_CHILDREN, 
&peeraddr)) < 0)
+return ret;
+av_log(s, AV_LOG_TRACE, "Peer address: %s\n", peeraddr);
 fail:
 return ret;
 }
@@ -702,7 +717,7 @@ static int process_line(URLContext *h, char *line, int 
line_count,
 {
 HTTPContext *s = h->priv_data;
 const char *auto_method =  h->flags & AVIO_FLAG_READ ? "POST" : "GET";
-char *tag, *p, *end, *method, *resource, *version;
+char *tag, *p, *end, *method, *resource, *query = NULL, *version;
 int ret;
 
 /* end of header */
@@ -720,6 +735,7 @@ static int process_line(URLContext *h, char *line, int 
line_count,
 p++;
 *(p++) = '\0';
 av_log(h, AV_LOG_TRACE, "Received method: %s\n", method);
+av_log(h, AV_LOG_TRACE, "Expected method: %s\n", s->method);
 if (s->method) {
   

Re: [FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Stephan Holljes]

Hi,

since I reworked how http_write_reply() works a bit, I will add
another patch prior to adding the error codes. The patch exposes
various options to customize HTTP replies. These are used by
http_write_reply().

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

Re: [FFmpeg-devel] [PATCH] avcodec/libx265: allow 12bit input formats, update warnings

[Stephen Hutchinson]

On 7/9/2015 11:58 AM, Derek Buitenhuis wrote:

Hi,

Apologies if this comes through as HTML. I am internet-less and
using the Gmail web interface.

On Wed, Jul 8, 2015 at 11:54 PM, Steve Borho  wrote:

The range extension profiles have been fully ratified so there
is no reason to require -strict experimental for them. However
Main12 support in x265 is experimental so I check for that
instead.


[...]


-if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL &&
-!av_pix_fmt_desc_get(avctx->pix_fmt)->log2_chroma_w) {
+if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL && 
ctx->api->bit_depth == 12) {


Style nit: Add a break like it previously had.



It seems as though x265 no longer warns about 12-bit
as experimental as of commit 6f40c6ed826c from 21 hours
ago (at this time of writing), so it's probably a good
thing this patch hadn't been committed yet.

Although the reason I was keeping an eye on this patch
was for the '4:2:2 and 4:4:4 no longer needing
-strict experimental' part.


Also, do you need an API bump in configure for this?



There's still the question of this, though.  To be
paranoid about making sure the warning on x265's
side doesn't show up, the check could be bumped to
the current version 71, although some/most of the
commits under X265_BUILD 71 do emit that warning for
12-bit.

If it were me, I'd split the 4:2:2/4:4:4 stuff out
into one patch (any API bump for that would have
already been covered by multilib), and then put all
the 12-bit adding in a second patch for whatever
comes of the API bumping discussion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Stephan Holljes]

On Thu, Aug 20, 2015 at 2:39 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Aug 19, 2015 at 7:59 PM, Stephan Holljes
>  wrote:
>> On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde  
>> wrote:
>>> On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
>>>  wrote:
 ---
  libavformat/http.c | 8 
  1 file changed, 8 insertions(+)

 diff --git a/libavformat/http.c b/libavformat/http.c
 index a136918..4dbef3f 100644
 --- a/libavformat/http.c
 +++ b/libavformat/http.c
 @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
 status_code)
  reply_text = "OK";
  content_type = "application/octet-stream";
  break;
 +case 301:
 +reply_code = 301;
 +reply_text = "Moved Permanently";
 +break;
>>>
>>> 301 is usually used for URL redirection,
>>> and you don't seem to do anything beyond setting the message.
>>> There needs to be additional logic somewhere to handle this.
>>> Nevertheless, it is still ok as a patch to me,
>>> since I assume this will be handled later on.
>>> I strongly suggest adding something to clarify this in the commit message.
>>
>> I did not think about that and so far I have only used it in my
>> modified ffserver code. What makes a 301 reply different from the
>> other replies? Maybe I didn't understand the RFC correctly.
>
> Quoting from the RFC:
> "The new permanent URI SHOULD be given by the Location field in the response.
> Unless the request method was HEAD,
> the entity of the response SHOULD contain a short hypertext note with
> a hyperlink to the new URI(s). "
>
> My point is that somewhere in the response a new URI must be provided,
> so that the client can go to the redirected location.
> I don't know where/how such logic should go, but it needs to be done.
>

Ah yes, thus far the application had to take care of that. Using the
location field in HTTPContext seems like a good place to store this
information. I will work on a patch that includes this. Thanks!

>>
>>>
  case AVERROR_HTTP_SERVER_ERROR:
  case 500:
  reply_code = 500;
  reply_text = "Internal server error";
  break;
 +case 503:
 +reply_code = 503;
 +reply_text = "Service Unavailable";
 +break;
>>>
>>> Looks ok to me.
>>>
  default:
  return AVERROR(EINVAL);
  }
 --
 2.1.0

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

Re: [FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Ganesh Ajjanagadde]

On Wed, Aug 19, 2015 at 7:59 PM, Stephan Holljes
 wrote:
> On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde  wrote:
>> On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
>>  wrote:
>>> ---
>>>  libavformat/http.c | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/libavformat/http.c b/libavformat/http.c
>>> index a136918..4dbef3f 100644
>>> --- a/libavformat/http.c
>>> +++ b/libavformat/http.c
>>> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
>>> status_code)
>>>  reply_text = "OK";
>>>  content_type = "application/octet-stream";
>>>  break;
>>> +case 301:
>>> +reply_code = 301;
>>> +reply_text = "Moved Permanently";
>>> +break;
>>
>> 301 is usually used for URL redirection,
>> and you don't seem to do anything beyond setting the message.
>> There needs to be additional logic somewhere to handle this.
>> Nevertheless, it is still ok as a patch to me,
>> since I assume this will be handled later on.
>> I strongly suggest adding something to clarify this in the commit message.
>
> I did not think about that and so far I have only used it in my
> modified ffserver code. What makes a 301 reply different from the
> other replies? Maybe I didn't understand the RFC correctly.

Quoting from the RFC:
"The new permanent URI SHOULD be given by the Location field in the response.
Unless the request method was HEAD,
the entity of the response SHOULD contain a short hypertext note with
a hyperlink to the new URI(s). "

My point is that somewhere in the response a new URI must be provided,
so that the client can go to the redirected location.
I don't know where/how such logic should go, but it needs to be done.

>
>>
>>>  case AVERROR_HTTP_SERVER_ERROR:
>>>  case 500:
>>>  reply_code = 500;
>>>  reply_text = "Internal server error";
>>>  break;
>>> +case 503:
>>> +reply_code = 503;
>>> +reply_text = "Service Unavailable";
>>> +break;
>>
>> Looks ok to me.
>>
>>>  default:
>>>  return AVERROR(EINVAL);
>>>  }
>>> --
>>> 2.1.0
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> 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] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Stephan Holljes]

On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
>  wrote:
>> ---
>>  libavformat/http.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index a136918..4dbef3f 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
>> status_code)
>>  reply_text = "OK";
>>  content_type = "application/octet-stream";
>>  break;
>> +case 301:
>> +reply_code = 301;
>> +reply_text = "Moved Permanently";
>> +break;
>
> 301 is usually used for URL redirection,
> and you don't seem to do anything beyond setting the message.
> There needs to be additional logic somewhere to handle this.
> Nevertheless, it is still ok as a patch to me,
> since I assume this will be handled later on.
> I strongly suggest adding something to clarify this in the commit message.

I did not think about that and so far I have only used it in my
modified ffserver code. What makes a 301 reply different from the
other replies? Maybe I didn't understand the RFC correctly.

>
>>  case AVERROR_HTTP_SERVER_ERROR:
>>  case 500:
>>  reply_code = 500;
>>  reply_text = "Internal server error";
>>  break;
>> +case 503:
>> +reply_code = 503;
>> +reply_text = "Service Unavailable";
>> +break;
>
> Looks ok to me.
>
>>  default:
>>  return AVERROR(EINVAL);
>>  }
>> --
>> 2.1.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 02/13] avfilter: add missing FF_API_AVFILTERPAD_PUBLIC guard

[Michael Niedermayer]

On Tue, Aug 18, 2015 at 11:47:45PM +0200, Andreas Cadhalpun wrote:
> On 18.08.2015 05:34, Michael Niedermayer wrote:
> > On Sat, Aug 08, 2015 at 01:31:51PM +0200, Andreas Cadhalpun wrote:
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavfilter/avfilter.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > tools/graph2dot fails to build without FF_API_AVFILTERPAD_PUBLIC
> > it seems
> 
> Yes, though it's only indirectly related to this patch.
> Anyway, patch for that attached.
> 
> Best regards,
> Andreas
> 

>  graph2dot.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 560d5f42580115baf305ba8ff985202b248b4864  
> 0001-graph2dot-use-avfilter_pad_get_name-accessor-functio.patch
> From 5c8d576ed73499cb41d8b7c5952f5917bca0df22 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 18 Aug 2015 23:07:37 +0200
> Subject: [PATCH] graph2dot: use avfilter_pad_get_name accessor function

LGTM

thanks

[...]

-- 
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] lavf/ftp: implement move and delete callbacks

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 11:52:14PM +0200, Mariusz Szczepańczyk wrote:
> ---
>  libavformat/ftp.c | 61 
> +++
>  1 file changed, 61 insertions(+)

applied

btw, if you want git write access, then send me your public ssh
key

thanks

[...]
-- 
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] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Ganesh Ajjanagadde]

On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes
 wrote:
> ---
>  libavformat/http.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index a136918..4dbef3f 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
> status_code)
>  reply_text = "OK";
>  content_type = "application/octet-stream";
>  break;
> +case 301:
> +reply_code = 301;
> +reply_text = "Moved Permanently";
> +break;

301 is usually used for URL redirection,
and you don't seem to do anything beyond setting the message.
There needs to be additional logic somewhere to handle this.
Nevertheless, it is still ok as a patch to me,
since I assume this will be handled later on.
I strongly suggest adding something to clarify this in the commit message.

>  case AVERROR_HTTP_SERVER_ERROR:
>  case 500:
>  reply_code = 500;
>  reply_text = "Internal server error";
>  break;
> +case 503:
> +reply_code = 503;
> +reply_text = "Service Unavailable";
> +break;

Looks ok to me.

>  default:
>  return AVERROR(EINVAL);
>  }
> --
> 2.1.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/ftp: implement move and delete callbacks

[Mariusz Szczepańczyk]

---
 libavformat/ftp.c | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index db233c9..51f491c 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -1038,6 +1038,65 @@ static int ftp_close_dir(URLContext *h)
 return 0;
 }
 
+static int ftp_delete(URLContext *h)
+{
+FTPContext *s = h->priv_data;
+char command[MAX_URL_SIZE];
+static const int del_codes[] = {250, 421, 450, 500, 501, 502, 530, 550, 0};
+static const int rmd_codes[] = {250, 421, 500, 501, 502, 530, 550, 0};
+int ret;
+
+if ((ret = ftp_connect(h, h->filename)) < 0)
+goto cleanup;
+
+snprintf(command, sizeof(command), "DELE %s\r\n", s->path);
+if (ftp_send_command(s, command, del_codes, NULL) == 250) {
+ret = 0;
+goto cleanup;
+}
+
+snprintf(command, sizeof(command), "RMD %s\r\n", s->path);
+if (ftp_send_command(s, command, rmd_codes, NULL) == 250)
+ret = 0;
+else
+ret = AVERROR(EIO);
+
+cleanup:
+ftp_close(h);
+return ret;
+}
+
+static int ftp_move(URLContext *h_src, URLContext *h_dst)
+{
+FTPContext *s = h_src->priv_data;
+char command[MAX_URL_SIZE], path[MAX_URL_SIZE];
+static const int rnfr_codes[] = {350, 421, 450, 500, 501, 502, 503, 530, 
0};
+static const int rnto_codes[] = {250, 421, 500, 501, 502, 503, 530, 532, 
553, 0};
+int ret;
+
+if ((ret = ftp_connect(h_src, h_src->filename)) < 0)
+goto cleanup;
+
+snprintf(command, sizeof(command), "RNFR %s\r\n", s->path);
+if (ftp_send_command(s, command, rnfr_codes, NULL) != 350) {
+ret = AVERROR(EIO);
+goto cleanup;
+}
+
+av_url_split(0, 0, 0, 0, 0, 0, 0,
+ path, sizeof(path),
+ h_dst->filename);
+snprintf(command, sizeof(command), "RNTO %s\r\n", path);
+if (ftp_send_command(s, command, rnto_codes, NULL) == 250)
+ret = 0;
+else
+ret = AVERROR(EIO);
+
+cleanup:
+ftp_close(h_src);
+return ret;
+}
+
 URLProtocol ff_ftp_protocol = {
 .name= "ftp",
 .url_open= ftp_open,
@@ -1052,5 +,7 @@ URLProtocol ff_ftp_protocol = {
 .url_open_dir= ftp_open_dir,
 .url_read_dir= ftp_read_dir,
 .url_close_dir   = ftp_close_dir,
+.url_delete  = ftp_delete,
+.url_move= ftp_move,
 .flags   = URL_PROTOCOL_FLAG_NETWORK,
 };
-- 
2.4.6

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

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Hi,

2015-08-19 21:57 GMT+02:00 wm4 :
> On Wed, 19 Aug 2015 19:32:27 +0200
> Gwenole Beauchesne  wrote:
>
>> 2015-08-19 19:19 GMT+02:00 Gwenole Beauchesne :
>> > Hi,
>> >
>> > 2015-08-19 18:50 GMT+02:00 wm4 :
>> >> On Wed, 19 Aug 2015 18:01:36 +0200
>> >> Gwenole Beauchesne  wrote:
>> >>
>> >>> Add av_vaapi_set_pipeline_params() interface to initialize the internal
>> >>> FFVAContext with a valid VA display, and optional parameters including
>> >>> a user-supplied VA context id.
>> >>>
>> >>> This is preparatory work for delegating VA pipeline (decoder) creation
>> >>> to libavcodec. Meanwhile, if this new interface is used, the user shall
>> >>> provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
>> >>> Otherwise, the older vaapi_context approach is still supported.
>> >>>
>> >>> This is an API change. The whole vaapi_context structure is no longer
>> >>> needed, and thus deprecated.
>> >>>
>> >>> Signed-off-by: Gwenole Beauchesne 
>> >>> ---
>> >>>  doc/APIchanges  |  6 ++--
>> >>>  libavcodec/vaapi.c  | 87 
>> >>> -
>> >>>  libavcodec/vaapi.h  | 49 +++--
>> >>>  libavcodec/vaapi_internal.h |  4 +++
>> >>>  4 files changed, 134 insertions(+), 12 deletions(-)
>> >>>
>> >>> diff --git a/doc/APIchanges b/doc/APIchanges
>> >>> index aa92b69..fcdaa26 100644
>> >>> --- a/doc/APIchanges
>> >>> +++ b/doc/APIchanges
>> >>> @@ -16,8 +16,10 @@ libavutil: 2014-08-09
>> >>>  API changes, most recent first:
>> >>>
>> >>>  2015-xx-xx - lavc 56.58.100 - vaapi.h
>> >>> -  Deprecate old VA-API context (vaapi_context) fields that were only
>> >>> -  set and used by libavcodec. They are all managed internally now.
>> >>> +  Add new API to configure the hwaccel/vaapi pipeline, currently
>> >>> +  useful for decoders: av_vaapi_set_pipeline_params()
>> >>> +  Deprecate old VA-API context (vaapi_context) structure, which is no
>> >>> +  longer used for initializing a VA-API decode pipeline.
>> >>>
>> >>>  2015-xx-xx - lavu 54.31.100 - pixfmt.h
>> >>>Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
>> >>> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
>> >>> index c081bb5..afddbb3 100644
>> >>> --- a/libavcodec/vaapi.c
>> >>> +++ b/libavcodec/vaapi.c
>> >>> @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
>> >>> VABufferID *buffers, unsigned int
>> >>>  }
>> >>>  }
>> >>>
>> >>> +/** @name VA-API pipeline parameters (internal) */
>> >>> +/**@{*/
>> >>> +/** Pipeline configuration flags 
>> >>> (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
>> >>> +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
>> >>> +/** User-supplied VA display handle */
>> >>> +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
>> >>> +/**@}*/
>> >>> +
>> >>> +#define OFFSET(x) offsetof(FFVAContext, x)
>> >>> +static const AVOption FFVAContextOptions[] = {
>> >>> +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
>> >>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
>> >>> +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", 
>> >>> OFFSET(user_display),
>> >>> +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
>> >>> +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
>> >>> OFFSET(user_context_id),
>> >>> +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
>> >>> +{ NULL, }
>> >>> +};
>> >>> +#undef OFFSET
>> >>> +
>> >>> +static const AVClass FFVAContextClass = {
>> >>> +.class_name = "FFVAContext",
>> >>> +.item_name  = av_default_item_name,
>> >>> +.option = FFVAContextOptions,
>> >>> +.version= LIBAVUTIL_VERSION_INT,
>> >>> +};
>> >>> +
>> >>> +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay 
>> >>> display,
>> >>> + uint32_t flags, AVDictionary **params)
>> >>> +{
>> >>> +int ret;
>> >>> +
>> >>> +if (!display) {
>> >>> +av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
>> >>> +return AVERROR(EINVAL);
>> >>> +}
>> >>> +
>> >>> +if (params && *params)
>> >>> +av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
>> >>> +
>> >>> +ret = av_dict_set_int(&avctx->internal->hwaccel_config,
>> >>> +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
>> >>> +if (ret != 0)
>> >>> +return ret;
>> >>> +
>> >>> +return av_dict_set_int(&avctx->internal->hwaccel_config,
>> >>> +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
>> >>> +   (int64_t)(intptr_t)display, 0);
>> >>> +}
>> >>> +
>> >>>  int ff_vaapi_context_init(AVCodecContext *avctx)
>> >>>  {
>> >>>  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
>> >>> -const struct vaapi_context * const user_vactx = 
>> >>> avctx->hwaccel_context;
>> >>> +int ret;
>> >>>
>> >>> -if (!user_vactx) {
>> >>> -av_log(avctx, AV_LOG_ERROR, "Hardware acceleration conte

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[wm4]

On Wed, 19 Aug 2015 19:32:27 +0200
Gwenole Beauchesne  wrote:

> 2015-08-19 19:19 GMT+02:00 Gwenole Beauchesne :
> > Hi,
> >
> > 2015-08-19 18:50 GMT+02:00 wm4 :
> >> On Wed, 19 Aug 2015 18:01:36 +0200
> >> Gwenole Beauchesne  wrote:
> >>
> >>> Add av_vaapi_set_pipeline_params() interface to initialize the internal
> >>> FFVAContext with a valid VA display, and optional parameters including
> >>> a user-supplied VA context id.
> >>>
> >>> This is preparatory work for delegating VA pipeline (decoder) creation
> >>> to libavcodec. Meanwhile, if this new interface is used, the user shall
> >>> provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
> >>> Otherwise, the older vaapi_context approach is still supported.
> >>>
> >>> This is an API change. The whole vaapi_context structure is no longer
> >>> needed, and thus deprecated.
> >>>
> >>> Signed-off-by: Gwenole Beauchesne 
> >>> ---
> >>>  doc/APIchanges  |  6 ++--
> >>>  libavcodec/vaapi.c  | 87 
> >>> -
> >>>  libavcodec/vaapi.h  | 49 +++--
> >>>  libavcodec/vaapi_internal.h |  4 +++
> >>>  4 files changed, 134 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/doc/APIchanges b/doc/APIchanges
> >>> index aa92b69..fcdaa26 100644
> >>> --- a/doc/APIchanges
> >>> +++ b/doc/APIchanges
> >>> @@ -16,8 +16,10 @@ libavutil: 2014-08-09
> >>>  API changes, most recent first:
> >>>
> >>>  2015-xx-xx - lavc 56.58.100 - vaapi.h
> >>> -  Deprecate old VA-API context (vaapi_context) fields that were only
> >>> -  set and used by libavcodec. They are all managed internally now.
> >>> +  Add new API to configure the hwaccel/vaapi pipeline, currently
> >>> +  useful for decoders: av_vaapi_set_pipeline_params()
> >>> +  Deprecate old VA-API context (vaapi_context) structure, which is no
> >>> +  longer used for initializing a VA-API decode pipeline.
> >>>
> >>>  2015-xx-xx - lavu 54.31.100 - pixfmt.h
> >>>Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
> >>> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
> >>> index c081bb5..afddbb3 100644
> >>> --- a/libavcodec/vaapi.c
> >>> +++ b/libavcodec/vaapi.c
> >>> @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
> >>> VABufferID *buffers, unsigned int
> >>>  }
> >>>  }
> >>>
> >>> +/** @name VA-API pipeline parameters (internal) */
> >>> +/**@{*/
> >>> +/** Pipeline configuration flags 
> >>> (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
> >>> +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
> >>> +/** User-supplied VA display handle */
> >>> +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
> >>> +/**@}*/
> >>> +
> >>> +#define OFFSET(x) offsetof(FFVAContext, x)
> >>> +static const AVOption FFVAContextOptions[] = {
> >>> +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
> >>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
> >>> +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", 
> >>> OFFSET(user_display),
> >>> +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
> >>> +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
> >>> OFFSET(user_context_id),
> >>> +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
> >>> +{ NULL, }
> >>> +};
> >>> +#undef OFFSET
> >>> +
> >>> +static const AVClass FFVAContextClass = {
> >>> +.class_name = "FFVAContext",
> >>> +.item_name  = av_default_item_name,
> >>> +.option = FFVAContextOptions,
> >>> +.version= LIBAVUTIL_VERSION_INT,
> >>> +};
> >>> +
> >>> +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay 
> >>> display,
> >>> + uint32_t flags, AVDictionary **params)
> >>> +{
> >>> +int ret;
> >>> +
> >>> +if (!display) {
> >>> +av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
> >>> +return AVERROR(EINVAL);
> >>> +}
> >>> +
> >>> +if (params && *params)
> >>> +av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
> >>> +
> >>> +ret = av_dict_set_int(&avctx->internal->hwaccel_config,
> >>> +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
> >>> +if (ret != 0)
> >>> +return ret;
> >>> +
> >>> +return av_dict_set_int(&avctx->internal->hwaccel_config,
> >>> +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
> >>> +   (int64_t)(intptr_t)display, 0);
> >>> +}
> >>> +
> >>>  int ff_vaapi_context_init(AVCodecContext *avctx)
> >>>  {
> >>>  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
> >>> -const struct vaapi_context * const user_vactx = 
> >>> avctx->hwaccel_context;
> >>> +int ret;
> >>>
> >>> -if (!user_vactx) {
> >>> -av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
> >>> (hwaccel_context) does not exist.\n");
> >>> -return AVERROR(ENOSYS);
> >>> -}
> >>> +vactx->klass = &FFVAContextClass;
> >>> +av_

Re: [FFmpeg-devel] [PATCH]Postpone vdpau removal

[Philip Langdale]

On 2015-08-19 12:15, Andreas Cadhalpun wrote:

On 19.08.2015 21:10, Philip Langdale wrote:

I'll need to take a look at it, which I can do later this week.


OK, thanks.

There's definitely code left that references the old api that can be 
removed.
But removing it may not be trivial if it's sufficiently tangled up, as 
this might be.


I see.


In this particular case, vdpau_render_state has continued to be used but 
the only field
used is the surface ID. So it should simply be replaced by an array of 
surface IDs.


Similarly the vdpau_render_state entry in vdpau_frame_data should be 
directly replaced

by a surface ID.

This is something I can do over the weekend if someone else doesn't get 
to it first.


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

Re: [FFmpeg-devel] [PATCH] */version.h: Add note/recommandition about bumping major

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 08:55:53PM +0200, Andreas Cadhalpun wrote:
> On 19.08.2015 11:56, Michael Niedermayer wrote:
> > On Tue, Aug 18, 2015 at 11:52:39PM +0200, Andreas Cadhalpun wrote:
> >> On 18.08.2015 12:28, Michael Niedermayer wrote:
> >>> From: Michael Niedermayer 
> >>>
> >>> If preferred, i can also apply this after the bump, in case its felt that
> >>> this would cause too much delay/work
> >>>
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/version.h  |4 
> >>>  libavformat/version.h |5 +
> >>>  libavutil/version.h   |4 
> >>>  3 files changed, 13 insertions(+)
> >>>
> >>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>> index 1b37a9e..cf9c924 100644
> >>> --- a/libavcodec/version.h
> >>> +++ b/libavcodec/version.h
> >>> @@ -46,6 +46,10 @@
> >>>   * FF_API_* defines may be placed below to indicate public API that will 
> >>> be
> >>>   * dropped at a future version bump. The defines themselves are not part 
> >>> of
> >>>   * the public API and may change, break or disappear at any time.
> >>> + *
> >>> + * @note, when bumping the major version it is recommandeded to manually
> >>> + * disable each FF_API_* in its own commit instead of disabling them all
> >>> + * at once through the bump. This improves the git bissect-ability of 
> >>> the change.
> >>>   */
> >>
> >> I think that is a good idea,
> > 
> > 
> >> but instead of disabling the FF_API_* defines
> >> they should be removed together with the code guarded by them.
> >> Otherwise chances are that the old, disabled code will never get removed,
> >> see e.g. FF_API_OLD_GRAPH_PARSE.
> > 
> > that would increase the workload for bumping and also make it harder
> > to test for regressions caused by FF_API* in the days/week following
> > the bump. so my feeling is toward that keeping disabling and removing
> > seperate would be better
> 
> You have a point there, so I'm fine with that approach too.

ok, applied


> 
> Though, of course, there shouldn't be any regressions in the first place. ;)

no, of course not

thanks

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH]Postpone vdpau removal

[Andreas Cadhalpun]

On 19.08.2015 21:10, Philip Langdale wrote:
> I'll need to take a look at it, which I can do later this week.

OK, thanks.

> There's definitely code left that references the old api that can be removed.
> But removing it may not be trivial if it's sufficiently tangled up, as this 
> might be. 

I see.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH]Postpone vdpau removal

[Philip Langdale]

I'll need to take a look at it, which I can do later this week. There's 
definitely code left that references the old api that can be removed. But 
removing it may not be trivial if it's sufficiently tangled up, as this might 
be. 

--phil

On Aug 19, 2015 11:52 AM, Andreas Cadhalpun  
wrote:
>
> On 19.08.2015 01:08, Philip Langdale wrote: 
> > On 2015-08-18 15:59, Andreas Cadhalpun wrote: 
> >> On 18.08.2015 23:15, Philip Langdale wrote: 
> >>> Do we have any known applications that still use the old API. 
> >>> Even mplayer, of all things, uses the new API. 
> >> 
> >> I'm not exactly sure what you meant here, but FF_API_VDPAU 
> >> is mainly about the (AV_)PIX_FMT_VDPAU_* pixel formats, which 
> >> mplayer is still using, e.g. [1]. 
> > 
> > mplayer contains code that handles these formats, but by using the new 
> > API, it will never actually see content on those formats. This is now 
> > dead code in mplayer. 
>
> But that code still gets compiled, so when I try building mplayer 
> with a FFmpeg version without FF_API_CAP_VDPAU I get the following error: 
> libvo/vo_vdpau.c:177:34: error: array type has incomplete element type 
> static struct vdpau_render_state  surface_render[MAX_VIDEO_SURFACES]; 
>   ^ 
>
> Do you mean that this code can just be removed? 
>
> Best regards, 
> Andreas 
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] */version.h: Add note/recommandition about bumping major

[Andreas Cadhalpun]

On 19.08.2015 11:56, Michael Niedermayer wrote:
> On Tue, Aug 18, 2015 at 11:52:39PM +0200, Andreas Cadhalpun wrote:
>> On 18.08.2015 12:28, Michael Niedermayer wrote:
>>> From: Michael Niedermayer 
>>>
>>> If preferred, i can also apply this after the bump, in case its felt that
>>> this would cause too much delay/work
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/version.h  |4 
>>>  libavformat/version.h |5 +
>>>  libavutil/version.h   |4 
>>>  3 files changed, 13 insertions(+)
>>>
>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>> index 1b37a9e..cf9c924 100644
>>> --- a/libavcodec/version.h
>>> +++ b/libavcodec/version.h
>>> @@ -46,6 +46,10 @@
>>>   * FF_API_* defines may be placed below to indicate public API that will be
>>>   * dropped at a future version bump. The defines themselves are not part of
>>>   * the public API and may change, break or disappear at any time.
>>> + *
>>> + * @note, when bumping the major version it is recommandeded to manually
>>> + * disable each FF_API_* in its own commit instead of disabling them all
>>> + * at once through the bump. This improves the git bissect-ability of the 
>>> change.
>>>   */
>>
>> I think that is a good idea,
> 
> 
>> but instead of disabling the FF_API_* defines
>> they should be removed together with the code guarded by them.
>> Otherwise chances are that the old, disabled code will never get removed,
>> see e.g. FF_API_OLD_GRAPH_PARSE.
> 
> that would increase the workload for bumping and also make it harder
> to test for regressions caused by FF_API* in the days/week following
> the bump. so my feeling is toward that keeping disabling and removing
> seperate would be better

You have a point there, so I'm fine with that approach too.

Though, of course, there shouldn't be any regressions in the first place. ;)

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH]Postpone vdpau removal

[Andreas Cadhalpun]

On 19.08.2015 01:08, Philip Langdale wrote:
> On 2015-08-18 15:59, Andreas Cadhalpun wrote:
>> On 18.08.2015 23:15, Philip Langdale wrote:
>>> Do we have any known applications that still use the old API.
>>> Even mplayer, of all things, uses the new API.
>>
>> I'm not exactly sure what you meant here, but FF_API_VDPAU
>> is mainly about the (AV_)PIX_FMT_VDPAU_* pixel formats, which
>> mplayer is still using, e.g. [1].
> 
> mplayer contains code that handles these formats, but by using the new
> API, it will never actually see content on those formats. This is now
> dead code in mplayer.

But that code still gets compiled, so when I try building mplayer
with a FFmpeg version without FF_API_CAP_VDPAU I get the following error:
libvo/vo_vdpau.c:177:34: error: array type has incomplete element type
 static struct vdpau_render_state  surface_render[MAX_VIDEO_SURFACES];
  ^

Do you mean that this code can just be removed?

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/indevs: add various missing options

[Lou Logan]

On Tue, 18 Aug 2015 22:24:42 -0400, Ganesh Ajjanagadde wrote:

> minor nit on article usage: set grabbing frame rate -> set the
> grabbing frame rate.
> I mention this since it is mostly correct and helps consistency.

Change made.

> Sourceforge has run into trouble with ad blockers/malware heuristics
> due to the crapware that comes
> loaded on a bunch of stuff there:
> https://news.ycombinator.com/item?id=9738305
> Ideally one would like a non Sourceforge link, but I can't find a
> better link for this purpose.
> Thus it is fine with me unless someone can find a better link.

The link was already there, but I moved it (yeah, more of a cosmetic
thing but who cares).

> minor nit on article usage: Set number of channels -> Set the number of 
> channels

Change made.
 
> article usage: Set frame rate -> Set the frame rate

Change made.

> article usage: Select video device -> Select the video device
> with same name -> with the same name

Change made and pushed. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

2015-08-19 19:19 GMT+02:00 Gwenole Beauchesne :
> Hi,
>
> 2015-08-19 18:50 GMT+02:00 wm4 :
>> On Wed, 19 Aug 2015 18:01:36 +0200
>> Gwenole Beauchesne  wrote:
>>
>>> Add av_vaapi_set_pipeline_params() interface to initialize the internal
>>> FFVAContext with a valid VA display, and optional parameters including
>>> a user-supplied VA context id.
>>>
>>> This is preparatory work for delegating VA pipeline (decoder) creation
>>> to libavcodec. Meanwhile, if this new interface is used, the user shall
>>> provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
>>> Otherwise, the older vaapi_context approach is still supported.
>>>
>>> This is an API change. The whole vaapi_context structure is no longer
>>> needed, and thus deprecated.
>>>
>>> Signed-off-by: Gwenole Beauchesne 
>>> ---
>>>  doc/APIchanges  |  6 ++--
>>>  libavcodec/vaapi.c  | 87 
>>> -
>>>  libavcodec/vaapi.h  | 49 +++--
>>>  libavcodec/vaapi_internal.h |  4 +++
>>>  4 files changed, 134 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index aa92b69..fcdaa26 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -16,8 +16,10 @@ libavutil: 2014-08-09
>>>  API changes, most recent first:
>>>
>>>  2015-xx-xx - lavc 56.58.100 - vaapi.h
>>> -  Deprecate old VA-API context (vaapi_context) fields that were only
>>> -  set and used by libavcodec. They are all managed internally now.
>>> +  Add new API to configure the hwaccel/vaapi pipeline, currently
>>> +  useful for decoders: av_vaapi_set_pipeline_params()
>>> +  Deprecate old VA-API context (vaapi_context) structure, which is no
>>> +  longer used for initializing a VA-API decode pipeline.
>>>
>>>  2015-xx-xx - lavu 54.31.100 - pixfmt.h
>>>Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
>>> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
>>> index c081bb5..afddbb3 100644
>>> --- a/libavcodec/vaapi.c
>>> +++ b/libavcodec/vaapi.c
>>> @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
>>> VABufferID *buffers, unsigned int
>>>  }
>>>  }
>>>
>>> +/** @name VA-API pipeline parameters (internal) */
>>> +/**@{*/
>>> +/** Pipeline configuration flags 
>>> (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
>>> +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
>>> +/** User-supplied VA display handle */
>>> +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
>>> +/**@}*/
>>> +
>>> +#define OFFSET(x) offsetof(FFVAContext, x)
>>> +static const AVOption FFVAContextOptions[] = {
>>> +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
>>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
>>> +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", OFFSET(user_display),
>>> +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
>>> +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
>>> OFFSET(user_context_id),
>>> +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
>>> +{ NULL, }
>>> +};
>>> +#undef OFFSET
>>> +
>>> +static const AVClass FFVAContextClass = {
>>> +.class_name = "FFVAContext",
>>> +.item_name  = av_default_item_name,
>>> +.option = FFVAContextOptions,
>>> +.version= LIBAVUTIL_VERSION_INT,
>>> +};
>>> +
>>> +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
>>> + uint32_t flags, AVDictionary **params)
>>> +{
>>> +int ret;
>>> +
>>> +if (!display) {
>>> +av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
>>> +return AVERROR(EINVAL);
>>> +}
>>> +
>>> +if (params && *params)
>>> +av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
>>> +
>>> +ret = av_dict_set_int(&avctx->internal->hwaccel_config,
>>> +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
>>> +if (ret != 0)
>>> +return ret;
>>> +
>>> +return av_dict_set_int(&avctx->internal->hwaccel_config,
>>> +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
>>> +   (int64_t)(intptr_t)display, 0);
>>> +}
>>> +
>>>  int ff_vaapi_context_init(AVCodecContext *avctx)
>>>  {
>>>  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
>>> -const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
>>> +int ret;
>>>
>>> -if (!user_vactx) {
>>> -av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
>>> (hwaccel_context) does not exist.\n");
>>> -return AVERROR(ENOSYS);
>>> -}
>>> +vactx->klass = &FFVAContextClass;
>>> +av_opt_set_defaults(vactx);
>>>
>>> -vactx->display  = user_vactx->display;
>>> -vactx->config_id= user_vactx->config_id;
>>> -vactx->context_id   = user_vactx->context_id;
>>> +#if FF_API_VAAPI_CONTEXT
>>> +FF_DISABLE_DEPRECATION_WARNINGS
>>> +if (avctx->hwaccel_context) {
>>

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Hi,

2015-08-19 18:50 GMT+02:00 wm4 :
> On Wed, 19 Aug 2015 18:01:36 +0200
> Gwenole Beauchesne  wrote:
>
>> Add av_vaapi_set_pipeline_params() interface to initialize the internal
>> FFVAContext with a valid VA display, and optional parameters including
>> a user-supplied VA context id.
>>
>> This is preparatory work for delegating VA pipeline (decoder) creation
>> to libavcodec. Meanwhile, if this new interface is used, the user shall
>> provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
>> Otherwise, the older vaapi_context approach is still supported.
>>
>> This is an API change. The whole vaapi_context structure is no longer
>> needed, and thus deprecated.
>>
>> Signed-off-by: Gwenole Beauchesne 
>> ---
>>  doc/APIchanges  |  6 ++--
>>  libavcodec/vaapi.c  | 87 
>> -
>>  libavcodec/vaapi.h  | 49 +++--
>>  libavcodec/vaapi_internal.h |  4 +++
>>  4 files changed, 134 insertions(+), 12 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index aa92b69..fcdaa26 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -16,8 +16,10 @@ libavutil: 2014-08-09
>>  API changes, most recent first:
>>
>>  2015-xx-xx - lavc 56.58.100 - vaapi.h
>> -  Deprecate old VA-API context (vaapi_context) fields that were only
>> -  set and used by libavcodec. They are all managed internally now.
>> +  Add new API to configure the hwaccel/vaapi pipeline, currently
>> +  useful for decoders: av_vaapi_set_pipeline_params()
>> +  Deprecate old VA-API context (vaapi_context) structure, which is no
>> +  longer used for initializing a VA-API decode pipeline.
>>
>>  2015-xx-xx - lavu 54.31.100 - pixfmt.h
>>Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
>> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
>> index c081bb5..afddbb3 100644
>> --- a/libavcodec/vaapi.c
>> +++ b/libavcodec/vaapi.c
>> @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
>> VABufferID *buffers, unsigned int
>>  }
>>  }
>>
>> +/** @name VA-API pipeline parameters (internal) */
>> +/**@{*/
>> +/** Pipeline configuration flags 
>> (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
>> +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
>> +/** User-supplied VA display handle */
>> +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
>> +/**@}*/
>> +
>> +#define OFFSET(x) offsetof(FFVAContext, x)
>> +static const AVOption FFVAContextOptions[] = {
>> +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
>> +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", OFFSET(user_display),
>> +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
>> +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
>> OFFSET(user_context_id),
>> +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
>> +{ NULL, }
>> +};
>> +#undef OFFSET
>> +
>> +static const AVClass FFVAContextClass = {
>> +.class_name = "FFVAContext",
>> +.item_name  = av_default_item_name,
>> +.option = FFVAContextOptions,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +
>> +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
>> + uint32_t flags, AVDictionary **params)
>> +{
>> +int ret;
>> +
>> +if (!display) {
>> +av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +if (params && *params)
>> +av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
>> +
>> +ret = av_dict_set_int(&avctx->internal->hwaccel_config,
>> +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
>> +if (ret != 0)
>> +return ret;
>> +
>> +return av_dict_set_int(&avctx->internal->hwaccel_config,
>> +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
>> +   (int64_t)(intptr_t)display, 0);
>> +}
>> +
>>  int ff_vaapi_context_init(AVCodecContext *avctx)
>>  {
>>  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
>> -const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
>> +int ret;
>>
>> -if (!user_vactx) {
>> -av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
>> (hwaccel_context) does not exist.\n");
>> -return AVERROR(ENOSYS);
>> -}
>> +vactx->klass = &FFVAContextClass;
>> +av_opt_set_defaults(vactx);
>>
>> -vactx->display  = user_vactx->display;
>> -vactx->config_id= user_vactx->config_id;
>> -vactx->context_id   = user_vactx->context_id;
>> +#if FF_API_VAAPI_CONTEXT
>> +FF_DISABLE_DEPRECATION_WARNINGS
>> +if (avctx->hwaccel_context) {
>> +const struct vaapi_context * const user_vactx = 
>> avctx->hwaccel_context;
>> +vactx->user_display = (uintptr_t)user_vactx->display;
>> +vactx->

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[wm4]

On Wed, 19 Aug 2015 18:01:36 +0200
Gwenole Beauchesne  wrote:

> Add av_vaapi_set_pipeline_params() interface to initialize the internal
> FFVAContext with a valid VA display, and optional parameters including
> a user-supplied VA context id.
> 
> This is preparatory work for delegating VA pipeline (decoder) creation
> to libavcodec. Meanwhile, if this new interface is used, the user shall
> provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
> Otherwise, the older vaapi_context approach is still supported.
> 
> This is an API change. The whole vaapi_context structure is no longer
> needed, and thus deprecated.
> 
> Signed-off-by: Gwenole Beauchesne 
> ---
>  doc/APIchanges  |  6 ++--
>  libavcodec/vaapi.c  | 87 
> -
>  libavcodec/vaapi.h  | 49 +++--
>  libavcodec/vaapi_internal.h |  4 +++
>  4 files changed, 134 insertions(+), 12 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index aa92b69..fcdaa26 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -16,8 +16,10 @@ libavutil: 2014-08-09
>  API changes, most recent first:
>  
>  2015-xx-xx - lavc 56.58.100 - vaapi.h
> -  Deprecate old VA-API context (vaapi_context) fields that were only
> -  set and used by libavcodec. They are all managed internally now.
> +  Add new API to configure the hwaccel/vaapi pipeline, currently
> +  useful for decoders: av_vaapi_set_pipeline_params()
> +  Deprecate old VA-API context (vaapi_context) structure, which is no
> +  longer used for initializing a VA-API decode pipeline.
>  
>  2015-xx-xx - lavu 54.31.100 - pixfmt.h
>Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
> index c081bb5..afddbb3 100644
> --- a/libavcodec/vaapi.c
> +++ b/libavcodec/vaapi.c
> @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, VABufferID 
> *buffers, unsigned int
>  }
>  }
>  
> +/** @name VA-API pipeline parameters (internal) */
> +/**@{*/
> +/** Pipeline configuration flags 
> (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
> +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
> +/** User-supplied VA display handle */
> +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
> +/**@}*/
> +
> +#define OFFSET(x) offsetof(FFVAContext, x)
> +static const AVOption FFVAContextOptions[] = {
> +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
> +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", OFFSET(user_display),
> +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
> +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
> OFFSET(user_context_id),
> +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
> +{ NULL, }
> +};
> +#undef OFFSET
> +
> +static const AVClass FFVAContextClass = {
> +.class_name = "FFVAContext",
> +.item_name  = av_default_item_name,
> +.option = FFVAContextOptions,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
> + uint32_t flags, AVDictionary **params)
> +{
> +int ret;
> +
> +if (!display) {
> +av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +if (params && *params)
> +av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
> +
> +ret = av_dict_set_int(&avctx->internal->hwaccel_config,
> +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
> +if (ret != 0)
> +return ret;
> +
> +return av_dict_set_int(&avctx->internal->hwaccel_config,
> +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
> +   (int64_t)(intptr_t)display, 0);
> +}
> +
>  int ff_vaapi_context_init(AVCodecContext *avctx)
>  {
>  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
> -const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
> +int ret;
>  
> -if (!user_vactx) {
> -av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
> (hwaccel_context) does not exist.\n");
> -return AVERROR(ENOSYS);
> -}
> +vactx->klass = &FFVAContextClass;
> +av_opt_set_defaults(vactx);
>  
> -vactx->display  = user_vactx->display;
> -vactx->config_id= user_vactx->config_id;
> -vactx->context_id   = user_vactx->context_id;
> +#if FF_API_VAAPI_CONTEXT
> +FF_DISABLE_DEPRECATION_WARNINGS
> +if (avctx->hwaccel_context) {
> +const struct vaapi_context * const user_vactx = 
> avctx->hwaccel_context;
> +vactx->user_display = (uintptr_t)user_vactx->display;
> +vactx->user_context_id  = user_vactx->context_id;
> +}
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
>  
> +vactx->context_id   = VA_INVALID_ID;

[FFmpeg-devel] [PATCH] lavf/http: Add 301 and 503 error codes to http_write_reply()

[Stephan Holljes]

---
 libavformat/http.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index a136918..4dbef3f 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int 
status_code)
 reply_text = "OK";
 content_type = "application/octet-stream";
 break;
+case 301:
+reply_code = 301;
+reply_text = "Moved Permanently";
+break;
 case AVERROR_HTTP_SERVER_ERROR:
 case 500:
 reply_code = 500;
 reply_text = "Internal server error";
 break;
+case 503:
+reply_code = 503;
+reply_text = "Service Unavailable";
+break;
 default:
 return AVERROR(EINVAL);
 }
-- 
2.1.0

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

[FFmpeg-devel] [RFC 1/4] hwaccel: add infrastructure to hold accelerator config options.

[Gwenole Beauchesne]

The options are live from AVHWaccel.init() to AVHWAccel.uninit(). As such,
they are specific to an active hwaccel and have a meaning to that hwaccel
only during initialization. Options can be initialized by the user during
AVCodecContext.get_format() with hwaccel-specific (public) helper functions.

This is an internal infrastructure change/addition only.

Signed-off-by: Gwenole Beauchesne 
---
 libavcodec/internal.h | 14 ++
 libavcodec/utils.c|  2 ++
 2 files changed, 16 insertions(+)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index f93a196..413e49b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -157,6 +157,20 @@ typedef struct AVCodecInternal {
  * hwaccel-specific private data
  */
 void *hwaccel_priv_data;
+
+/**
+ * Hardware acceleration config options.
+ *
+ * Those options are live from AVHWAccel.init() to AVHWAccel.uninit().
+ * As such, they are specific to an active hwaccel and have a meaning
+ * to that specific hwaccel only during initialization. Initialization
+ * occurs during AVCodecContext.get_format() through hwaccel-specific
+ * helper functions.
+ *
+ * Options are written by the user and read by the hwaccel. Exposing
+ * hwaccel options to the user is not permitted.
+ */
+AVDictionary *hwaccel_config;
 } AVCodecInternal;
 
 struct AVCodecDefault {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4da16ee..d6be93d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1231,6 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const enum 
AVPixelFormat *fmt)
 if (avctx->hwaccel && avctx->hwaccel->uninit)
 avctx->hwaccel->uninit(avctx);
 av_freep(&avctx->internal->hwaccel_priv_data);
+av_dict_free(&avctx->internal->hwaccel_config);
 avctx->hwaccel = NULL;
 
 ret = avctx->get_format(avctx, choices);
@@ -2923,6 +2924,7 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 if (avctx->hwaccel && avctx->hwaccel->uninit)
 avctx->hwaccel->uninit(avctx);
 av_freep(&avctx->internal->hwaccel_priv_data);
+av_dict_free(&avctx->internal->hwaccel_config);
 
 av_freep(&avctx->internal);
 }
-- 
1.9.1

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

[FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Add av_vaapi_set_pipeline_params() interface to initialize the internal
FFVAContext with a valid VA display, and optional parameters including
a user-supplied VA context id.

This is preparatory work for delegating VA pipeline (decoder) creation
to libavcodec. Meanwhile, if this new interface is used, the user shall
provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
Otherwise, the older vaapi_context approach is still supported.

This is an API change. The whole vaapi_context structure is no longer
needed, and thus deprecated.

Signed-off-by: Gwenole Beauchesne 
---
 doc/APIchanges  |  6 ++--
 libavcodec/vaapi.c  | 87 -
 libavcodec/vaapi.h  | 49 +++--
 libavcodec/vaapi_internal.h |  4 +++
 4 files changed, 134 insertions(+), 12 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index aa92b69..fcdaa26 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -16,8 +16,10 @@ libavutil: 2014-08-09
 API changes, most recent first:
 
 2015-xx-xx - lavc 56.58.100 - vaapi.h
-  Deprecate old VA-API context (vaapi_context) fields that were only
-  set and used by libavcodec. They are all managed internally now.
+  Add new API to configure the hwaccel/vaapi pipeline, currently
+  useful for decoders: av_vaapi_set_pipeline_params()
+  Deprecate old VA-API context (vaapi_context) structure, which is no
+  longer used for initializing a VA-API decode pipeline.
 
 2015-xx-xx - lavu 54.31.100 - pixfmt.h
   Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index c081bb5..afddbb3 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
+/** @name VA-API pipeline parameters (internal) */
+/**@{*/
+/** Pipeline configuration flags (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) 
*/
+#define AV_VAAPI_PIPELINE_PARAM_FLAGS   "flags"
+/** User-supplied VA display handle */
+#define AV_VAAPI_PIPELINE_PARAM_DISPLAY "display"
+/**@}*/
+
+#define OFFSET(x) offsetof(FFVAContext, x)
+static const AVOption FFVAContextOptions[] = {
+{ AV_VAAPI_PIPELINE_PARAM_FLAGS, "flags", OFFSET(flags),
+  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
+{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, "VA display", OFFSET(user_display),
+  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
+{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, "VA context id", 
OFFSET(user_context_id),
+  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
+{ NULL, }
+};
+#undef OFFSET
+
+static const AVClass FFVAContextClass = {
+.class_name = "FFVAContext",
+.item_name  = av_default_item_name,
+.option = FFVAContextOptions,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
+ uint32_t flags, AVDictionary **params)
+{
+int ret;
+
+if (!display) {
+av_log(avctx, AV_LOG_ERROR, "No valid VA display supplied.\n");
+return AVERROR(EINVAL);
+}
+
+if (params && *params)
+av_dict_copy(&avctx->internal->hwaccel_config, *params, 0);
+
+ret = av_dict_set_int(&avctx->internal->hwaccel_config,
+  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
+if (ret != 0)
+return ret;
+
+return av_dict_set_int(&avctx->internal->hwaccel_config,
+   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
+   (int64_t)(intptr_t)display, 0);
+}
+
 int ff_vaapi_context_init(AVCodecContext *avctx)
 {
 FFVAContext * const vactx = ff_vaapi_get_context(avctx);
-const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
+int ret;
 
-if (!user_vactx) {
-av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
(hwaccel_context) does not exist.\n");
-return AVERROR(ENOSYS);
-}
+vactx->klass = &FFVAContextClass;
+av_opt_set_defaults(vactx);
 
-vactx->display  = user_vactx->display;
-vactx->config_id= user_vactx->config_id;
-vactx->context_id   = user_vactx->context_id;
+#if FF_API_VAAPI_CONTEXT
+FF_DISABLE_DEPRECATION_WARNINGS
+if (avctx->hwaccel_context) {
+const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
+vactx->user_display = (uintptr_t)user_vactx->display;
+vactx->user_context_id  = user_vactx->context_id;
+}
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 
+vactx->context_id   = VA_INVALID_ID;
 vactx->pic_param_buf_id = VA_INVALID_ID;
 vactx->iq_matrix_buf_id = VA_INVALID_ID;
 vactx->bitplane_buf_id  = VA_INVALID_ID;
 
+ret = av_opt_set_dict(vactx, &avctx->internal->hwaccel_config);
+if (ret != 0)
+return ret;
+
+vactx->display  = (void *)(uintptr_t)vact

[FFmpeg-devel] [RFC 4/4] vaapi: add common utilities.

[Gwenole Beauchesne]

Handful set of self-contained utility functions:
- ff_vaapi_get_error():
  Converts VA status to an FFmpeg error code
- ff_vaapi_get_profiles():
  Retrieves all supported profiles
- ff_vaapi_get_entrypoints():
  Retrieves all supported entrypoints for the supplied profile
- ff_vaapi_get_chroma_format():
  Converts FFmpeg pixel format to VA chroma format
- ff_vaapi_get_pixel_format():
  Converts FFmpeg pixel format to VA fourcc

At some point, they could be migrated to some libavutil_vaapi and
exposed from there.

Signed-off-by: Gwenole Beauchesne 
---
 libavcodec/Makefile  |   4 +-
 libavcodec/vaapi_utils.c | 178 +++
 libavcodec/vaapi_utils.h |  53 ++
 3 files changed, 233 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/vaapi_utils.c
 create mode 100644 libavcodec/vaapi_utils.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d595fe1..15f5a1b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -696,7 +696,7 @@ OBJS-$(CONFIG_VIMA_DECODER)   += vima.o 
adpcm_data.o
 # hardware accelerators
 OBJS-$(CONFIG_D3D11VA)+= dxva2.o
 OBJS-$(CONFIG_DXVA2)  += dxva2.o
-OBJS-$(CONFIG_VAAPI)  += vaapi.o
+OBJS-$(CONFIG_VAAPI)  += vaapi.o vaapi_utils.o
 OBJS-$(CONFIG_VDA)+= vda.o videotoolbox.o
 OBJS-$(CONFIG_VIDEOTOOLBOX)   += videotoolbox.o
 OBJS-$(CONFIG_VDPAU)  += vdpau.o
@@ -919,7 +919,7 @@ SKIPHEADERS-$(CONFIG_QSV)  += qsv.h 
qsv_internal.h
 SKIPHEADERS-$(CONFIG_QSVDEC)   += qsvdec.h
 SKIPHEADERS-$(CONFIG_QSVENC)   += qsvenc.h
 SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
-SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_internal.h
+SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_internal.h vaapi_utils.h
 SKIPHEADERS-$(CONFIG_VDA)  += vda.h vda_vt_internal.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vda_vt_internal.h
diff --git a/libavcodec/vaapi_utils.c b/libavcodec/vaapi_utils.c
new file mode 100644
index 000..5f8a5fa
--- /dev/null
+++ b/libavcodec/vaapi_utils.c
@@ -0,0 +1,178 @@
+/*
+ * vaapi_utils.c - Video Acceleration API (VA-API) utilities
+ *
+ * Copyright (C) 2013-2015 Intel Corporation
+ *   Author: Gwenole Beauchesne 
+ *
+ * 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 "vaapi_utils.h"
+
+/* Converts VA status to an FFmpeg error code */
+int
+ff_vaapi_get_error(VAStatus status)
+{
+int ret;
+
+switch (status) {
+case VA_STATUS_ERROR_OPERATION_FAILED:
+ret = AVERROR(ENOTSUP);
+break;
+case VA_STATUS_ERROR_INVALID_DISPLAY:
+case VA_STATUS_ERROR_INVALID_CONFIG:
+case VA_STATUS_ERROR_INVALID_CONTEXT:
+case VA_STATUS_ERROR_INVALID_SURFACE:
+case VA_STATUS_ERROR_INVALID_BUFFER:
+case VA_STATUS_ERROR_INVALID_IMAGE:
+case VA_STATUS_ERROR_INVALID_SUBPICTURE:
+ret = AVERROR(EINVAL);
+break;
+case VA_STATUS_ERROR_INVALID_PARAMETER:
+case VA_STATUS_ERROR_INVALID_VALUE:
+ret = AVERROR(EINVAL);
+break;
+case VA_STATUS_ERROR_ALLOCATION_FAILED:
+ret = AVERROR(ENOMEM);
+break;
+case VA_STATUS_ERROR_UNIMPLEMENTED:
+ret = AVERROR(ENOSYS);
+break;
+case VA_STATUS_ERROR_SURFACE_BUSY:
+ret = AVERROR(EBUSY);
+break;
+default:
+ret = AVERROR_UNKNOWN;
+break;
+}
+return ret;
+}
+
+/* Retrieves all supported profiles */
+int
+ff_vaapi_get_profiles(VADisplay display, VAProfile **profiles_ptr,
+unsigned int *n_profiles_ptr)
+{
+VAStatus status;
+int n_profiles, ret;
+
+n_profiles = vaMaxNumProfiles(display);
+ret = av_reallocp_array(profiles_ptr, n_profiles, sizeof(VAProfile));
+if (ret != 0)
+return ret;
+
+status = vaQueryConfigProfiles(display, *profiles_ptr, &n_profiles);
+if (status != VA_STATUS_SUCCESS)
+return ff_vaapi_get_error(status);
+
+if (n_profiles_ptr)
+*n_profiles_ptr = n_profiles;
+return 0;
+}
+
+/* Retrieves all supported entrypoints for the supplied profile */
+int
+ff_vaapi_get_

[FFmpeg-devel] [RFC 2/4] hwaccel: try get_buffer*() if hwaccel alloc_frame() yields ENOSYS.

[Gwenole Beauchesne]

By default, lavc can manage frame buffer allocations itself without
explicit intervention from the user and custom get_buffer*() hooks.
In view to simplifying usages, there is a desire to operate on the
same model for hardware accelerated pipelines, i.e. delegate all HW
resources management to lavc.

AVHWAccel.alloc_frame() can serve this purpose just fine. However,
if the previous model is needed, whereby get_buffer*() hooks are
required, there is zero chance to call into them if alloc_frame() is
defined.

One way to solve this problem is simply to detect this usage model
from the hwaccel implementation and return AVERROR(ENOSYS) in the
.alloc_frame() hook so that to notify get_buffer_internal() to try
to call into .get_buffer*() hooks.

This is an internal semantical change only, and does not affect any
existing hwaccel implementation.

Signed-off-by: Gwenole Beauchesne 
---
 libavcodec/utils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d6be93d..321bdde 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -903,7 +903,9 @@ static int get_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame, int flags)
 if (hwaccel) {
 if (hwaccel->alloc_frame) {
 ret = hwaccel->alloc_frame(avctx, frame);
-goto end;
+if (ret != AVERROR(ENOSYS))
+goto end;
+/* Try out through get_buffer2() interfaces */
 }
 } else
 avctx->sw_pix_fmt = avctx->pix_fmt;
-- 
1.9.1

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

[FFmpeg-devel] [RFC 0/4] vaapi: delegate HW resources allocation to lavc

[Gwenole Beauchesne]

Hi,

As indicated before, I foresee at most 2 use-cases for lavc/vaapi:
1. Allow for implicit allocation of HW resources in lavc ;
2. Allow for the user to share the pain and manage the HW resources:
   a. The old way through AVCodecContext.get_format() + maintaining a
  vaapi_context struct + multiple calls to .get_buffer2() or the
  even older .get_buffer*() family of functions ;
   b. The new way without vaapi_context, but through a unique
  interface, yet flexible: av_vaapi_set_pipeline_params(). In such
  case, the user provides VA display & context + .get_buffer2()
  hooks to satisfy his desire.

That's the goal: provide a simple enablement path of the client
application, yet still allowing for extended usages if ever needed.

To that end, I only need 2 non-intrusive and minimal additions/changes
to the core hwaccel infrastructure. One hwaccel_config dict to hold
pipeline parameters, and one fixlet to allow for fallbacks to
.get_buffer2().

On the vaapi side, there is a bit more fun to write/merge, but I would
like to prepare for even more additions. In short, I need various
casual helper functions related to vaapi, and that could be useful to
not only vaapi decoders, but also filters. For now, I stuffed the
minimal set of helpers I immediately need into libavcodec/vaapi_utils.c.

How much would you like a libavutil_vaapi/libavhwaccel_vaapi library?
This is really utility functions like av_freep() variants to
destroying VA resources (i.e. restting id to VA_INVALID_ID after
release for instance), converting a VAStatus to some FFmpeg error,
etc.

I have attached two additional patches so that to give a glimpse at
how it could look like.

Regards,
Gwenole Beauchesne (4):
  hwaccel: add infrastructure to hold accelerator config options.
  hwaccel: try get_buffer*() if hwaccel alloc_frame() yields ENOSYS.
  vaapi: add new API to configure a VA pipeline.
  vaapi: add common utilities.

 doc/APIchanges  |   6 +-
 libavcodec/Makefile |   4 +-
 libavcodec/internal.h   |  14 
 libavcodec/utils.c  |   6 +-
 libavcodec/vaapi.c  |  87 --
 libavcodec/vaapi.h  |  49 +++-
 libavcodec/vaapi_internal.h |   4 +
 libavcodec/vaapi_utils.c| 178 
 libavcodec/vaapi_utils.h|  53 +
 9 files changed, 386 insertions(+), 15 deletions(-)
 create mode 100644 libavcodec/vaapi_utils.c
 create mode 100644 libavcodec/vaapi_utils.h

-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH v2 2/3] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Hi,

2015-08-19 16:12 GMT+02:00 Michael Niedermayer :
> On Wed, Aug 19, 2015 at 11:03:05AM +0200, Gwenole Beauchesne wrote:
>> Move libavcodec managed objects from the public struct vaapi_context
>> to a new privately owned FFVAContext. This is done so that to clean up
>> and streamline the public structure, but also to prepare for new codec
>> support, thus requiring new internal data to be added in there.
>>
>> The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
>> shall no longer be accessed from within vaapi_*.c codec support files.
>>
>> v2: add one minor check for hwaccel_context existence, mark older
>>   vaapi_context fields as deprecated until we reach lavc major+2,
>>   amend doc/APIchanges.
>>
>> Signed-off-by: Gwenole Beauchesne 
>> ---
>>  doc/APIchanges  |  4 
>>  libavcodec/vaapi.c  | 40 +++-
>>  libavcodec/vaapi.h  | 16 
>>  libavcodec/vaapi_h264.c | 10 +++---
>>  libavcodec/vaapi_internal.h | 42 --
>>  libavcodec/vaapi_mpeg2.c|  8 ++--
>>  libavcodec/vaapi_mpeg4.c| 11 +--
>>  libavcodec/vaapi_vc1.c  | 11 +--
>>  libavcodec/version.h|  3 +++
>>  9 files changed, 121 insertions(+), 24 deletions(-)
> [...]
>
>> diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
>> index 815a27e..4448a2e 100644
>> --- a/libavcodec/vaapi.h
>> +++ b/libavcodec/vaapi.h
>> @@ -31,6 +31,8 @@
>>   */
>>
>>  #include 
>> +#include 
>> +#include "version.h"
>
> is this intended to be  and not 
> "libavutil/attributes.h" ?

You are right. There are also other includes to fix. Though, I have
only removed the one that I was too bored to see hanging around. I
will fix.

Thanks,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] checkasm: Explicitly declare function prototypes

[Henrik Gramner]

On Tue, Aug 18, 2015 at 8:41 PM, Michael Niedermayer
 wrote:
> tested on 32&64bit x86, qemu arm & mips
>
> should be ok
>
> Thanks

Thanks for testing. Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/3] vaapi: streamline public context structure.

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 11:03:05AM +0200, Gwenole Beauchesne wrote:
> Move libavcodec managed objects from the public struct vaapi_context
> to a new privately owned FFVAContext. This is done so that to clean up
> and streamline the public structure, but also to prepare for new codec
> support, thus requiring new internal data to be added in there.
> 
> The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
> shall no longer be accessed from within vaapi_*.c codec support files.
> 
> v2: add one minor check for hwaccel_context existence, mark older
>   vaapi_context fields as deprecated until we reach lavc major+2,
>   amend doc/APIchanges.
> 
> Signed-off-by: Gwenole Beauchesne 
> ---
>  doc/APIchanges  |  4 
>  libavcodec/vaapi.c  | 40 +++-
>  libavcodec/vaapi.h  | 16 
>  libavcodec/vaapi_h264.c | 10 +++---
>  libavcodec/vaapi_internal.h | 42 --
>  libavcodec/vaapi_mpeg2.c|  8 ++--
>  libavcodec/vaapi_mpeg4.c| 11 +--
>  libavcodec/vaapi_vc1.c  | 11 +--
>  libavcodec/version.h|  3 +++
>  9 files changed, 121 insertions(+), 24 deletions(-)
[...]

> diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
> index 815a27e..4448a2e 100644
> --- a/libavcodec/vaapi.h
> +++ b/libavcodec/vaapi.h
> @@ -31,6 +31,8 @@
>   */
>  
>  #include 
> +#include 
> +#include "version.h"

is this intended to be  and not 
"libavutil/attributes.h" ?

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] GSoC Weekly report (libswscale)

[Ronald S. Bultje]

Hi

On Wed, Aug 19, 2015 at 9:45 AM, Pedro Arthur  wrote:

> patch committed.


Nice work!

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

Re: [FFmpeg-devel] [PATCH] fate: rename -error option to -error_rate.

[Michael Niedermayer]

On Mon, Aug 17, 2015 at 04:57:46PM -0400, Ronald S. Bultje wrote:
> This fixes fate when FF_API_ERROR_RATE=0.
> ---
>  tests/fate/vcodec.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

probably ok

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] fate: rename -error option to -error_rate.

[Paul B Mahol]

On 8/19/15, Ronald S. Bultje  wrote:
> Hi,
>
> On Mon, Aug 17, 2015 at 4:57 PM, Ronald S. Bultje 
> wrote:
>
>> This fixes fate when FF_API_ERROR_RATE=0.
>> ---
>>  tests/fate/vcodec.mak | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
>> index 11eb4f7..d4d0df5 100644
>> --- a/tests/fate/vcodec.mak
>> +++ b/tests/fate/vcodec.mak
>> @@ -211,7 +211,7 @@ fate-vsynth%-mpeg4-adv:  ENCOPTS = -qscale 9
>> -flags +mv4+aic   \
>>
>>  fate-vsynth%-mpeg4-error:ENCOPTS = -qscale 7 -flags +mv4+aic\
>> -data_partitioning 1 -mbd rd \
>> -   -ps 250 -error 10
>> +   -ps 250 -error_rate 10
>>
>>  fate-vsynth%-mpeg4-nr:   ENCOPTS = -qscale 8 -flags +mv4 -mbd rd
>> -nr 200
>>
>
> Ping.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] GSoC Weekly report (libswscale)

[Pedro Arthur]

patch committed.

2015-08-19 7:11 GMT-03:00 Michael Niedermayer :

> On Tue, Aug 18, 2015 at 11:36:16PM -0300, Pedro Arthur wrote:
> > Added copyright.
> > I've tried to push it (git push ffmpeg master --dry-run) but got the
> > following error:
> > fatal: remote error: access denied or repository not exported:
> /ffmpeg.git
> > with remote:
> > ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (fetch)
> > ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (push)
> >
> > is it correct?
>
> > Anyway I'm attaching the patch.
>
> still looks good
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
>
> ___
> 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 6/6] fate: change lavf.ffm ref.

[Hendrik Leppkes]

On Wed, Aug 19, 2015 at 3:20 PM, Ronald S. Bultje  wrote:
> Hi guys,
>
> On Mon, Aug 17, 2015 at 11:52 AM, Ronald S. Bultje 
> wrote:
>
>> (This should only be applied when we bump version.) Removing the -ab
>> option changes the codec settings serialization, so the ffm ref changes
>> whenever we bump version and remove -ab.
>> ---
>>  tests/ref/lavf/ffm | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/ref/lavf/ffm b/tests/ref/lavf/ffm
>> index 5de2f39..76b7716 100644
>> --- a/tests/ref/lavf/ffm
>> +++ b/tests/ref/lavf/ffm
>> @@ -1,3 +1,3 @@
>> -d5d4e5e3eec336ae6680dde035870564 *./tests/data/lavf/lavf.ffm
>> +4c3d2892c1d1be292f7b91788a0f7e17 *./tests/data/lavf/lavf.ffm
>>  376832 ./tests/data/lavf/lavf.ffm
>>  ./tests/data/lavf/lavf.ffm CRC=0x000e23ae
>> --
>> 2.1.2
>
>
> So, uhm, I'd like to get the last few patches in. I want to consider some
> options for this one, specifically. The diff between old and new .ffm is
> this:
>
> $ strings /tmp/old.ffm|grep ^b=|tr ',' '\n'>/tmp/old.ffm.hdr
> $ strings /tmp/new.ffm|grep ^b=|tr ',' '\n'>/tmp/new.ffm.hdr
> $ diff -u /tmp/{old,new}.ffm.hdr
> --- /tmp/old.ffm.hdr 2015-08-19 09:17:06.0 -0400
> +++ /tmp/new.ffm.hdr 2015-08-19 09:17:15.0 -0400
> @@ -1,5 +1,4 @@
>  b=64000
> -ab=64000
>  flags=0x0080
>  ar=44100
>  ac=1
>
> And this happens upon version bump if we consider "ab" deprecated (which I
> do). I can introduce a FF_OPT_FLAG_DEPRECATED in lavu/internal.h, mark "ab"
> as such, and handle that flag in opt_serialize. I could even mark that flag
> (in addition to being private) under FF_API_OLD_AVOPTIONS, so that it
> magically disappears upon version bump.
>
> We can also just wait for version bump and then apply this patch right
> after FF_API_OLD_AVOPTIONS becomes 0.
>

I think just applying it when needed is probably best. No huge effort,
just need to remember it after the bump.

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

Re: [FFmpeg-devel] [PATCH] Put remaining pieces of CODEC_FLAG_EMU_EDGE under FF_API_EMU_EDGE.

[Ronald S. Bultje]

Hi,

On Mon, Aug 17, 2015 at 12:25 PM, Ronald S. Bultje 
wrote:

> The amv one probably looks suspicious, but since it's an intra-only
> codec, I couldn't possibly imagine what it would use the edge for,
> and the vsyncht fate result doesn't change, so it's probably OK.
> ---
>  ffmpeg_opt.c  | 2 ++
>  ffplay.c  | 4 
>  libavcodec/mjpegenc.c | 2 ++
>  libavcodec/snowenc.c  | 6 +-
>  libavcodec/wmv2dec.c  | 2 ++
>  5 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 66a43b4..689d12a 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -662,9 +662,11 @@ static void add_input_streams(OptionsContext *o,
> AVFormatContext *ic)
>  case AVMEDIA_TYPE_VIDEO:
>  if(!ist->dec)
>  ist->dec = avcodec_find_decoder(dec->codec_id);
> +#if FF_API_EMU_EDGE
>  if (av_codec_get_lowres(dec)) {
>  dec->flags |= CODEC_FLAG_EMU_EDGE;
>  }
> +#endif
>
>  ist->resample_height  = ist->dec_ctx->height;
>  ist->resample_width   = ist->dec_ctx->width;
> diff --git a/ffplay.c b/ffplay.c
> index cc61dde..3d8673b 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -2550,11 +2550,15 @@ static int stream_component_open(VideoState *is,
> int stream_index)
>  }
>  av_codec_set_lowres(avctx, stream_lowres);
>
> +#if FF_API_EMU_EDGE
>  if(stream_lowres) avctx->flags |= CODEC_FLAG_EMU_EDGE;
> +#endif
>  if (fast)
>  avctx->flags2 |= AV_CODEC_FLAG2_FAST;
> +#if FF_API_EMU_EDGE
>  if(codec->capabilities & AV_CODEC_CAP_DR1)
>  avctx->flags |= CODEC_FLAG_EMU_EDGE;
> +#endif
>
>  opts = filter_codec_opts(codec_opts, avctx->codec_id, ic,
> ic->streams[stream_index], codec);
>  if (!av_dict_get(opts, "threads", NULL, 0))
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index ee0b16e..f15de58 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -224,9 +224,11 @@ static int amv_encode_picture(AVCodecContext *avctx,
> AVPacket *pkt,
>
>  av_pix_fmt_get_chroma_sub_sample(avctx->pix_fmt, &chroma_h_shift,
> &chroma_v_shift);
>
> +#if FF_API_EMU_EDGE
>  //CODEC_FLAG_EMU_EDGE have to be cleared
>  if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
>  return AVERROR(EINVAL);
> +#endif
>
>  if ((avctx->height & 15) && avctx->strict_std_compliance >
> FF_COMPLIANCE_UNOFFICIAL) {
>  av_log(avctx, AV_LOG_ERROR,
> diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
> index 16c7e05..9f74c9e 100644
> --- a/libavcodec/snowenc.c
> +++ b/libavcodec/snowenc.c
> @@ -1602,7 +1602,11 @@ static int encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
>  s->lambda = 0;
>  }//else keep previous frame's qlog until after motion estimation
>
> -if (s->current_picture->data[0] &&
> !(s->avctx->flags&CODEC_FLAG_EMU_EDGE)) {
> +if (s->current_picture->data[0]
> +#if FF_API_EMU_EDGE
> +&& !(s->avctx->flags&CODEC_FLAG_EMU_EDGE)
> +#endif
> +) {
>  int w = s->avctx->width;
>  int h = s->avctx->height;
>
> diff --git a/libavcodec/wmv2dec.c b/libavcodec/wmv2dec.c
> index f8128dc..cd17358 100644
> --- a/libavcodec/wmv2dec.c
> +++ b/libavcodec/wmv2dec.c
> @@ -453,7 +453,9 @@ static av_cold int wmv2_decode_init(AVCodecContext
> *avctx)
>  Wmv2Context *const w = avctx->priv_data;
>  int ret;
>
> +#if FF_API_EMU_EDGE
>  avctx->flags |= CODEC_FLAG_EMU_EDGE;
> +#endif
>
>  if ((ret = ff_msmpeg4_decode_init(avctx)) < 0)
>  return ret;


Ping.

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

Re: [FFmpeg-devel] [PATCH] fate: rename -error option to -error_rate.

[Ronald S. Bultje]

Hi,

On Mon, Aug 17, 2015 at 4:57 PM, Ronald S. Bultje 
wrote:

> This fixes fate when FF_API_ERROR_RATE=0.
> ---
>  tests/fate/vcodec.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
> index 11eb4f7..d4d0df5 100644
> --- a/tests/fate/vcodec.mak
> +++ b/tests/fate/vcodec.mak
> @@ -211,7 +211,7 @@ fate-vsynth%-mpeg4-adv:  ENCOPTS = -qscale 9
> -flags +mv4+aic   \
>
>  fate-vsynth%-mpeg4-error:ENCOPTS = -qscale 7 -flags +mv4+aic\
> -data_partitioning 1 -mbd rd \
> -   -ps 250 -error 10
> +   -ps 250 -error_rate 10
>
>  fate-vsynth%-mpeg4-nr:   ENCOPTS = -qscale 8 -flags +mv4 -mbd rd
> -nr 200
>

Ping.

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

Re: [FFmpeg-devel] [PATCH 6/6] fate: change lavf.ffm ref.

[Ronald S. Bultje]

Hi guys,

On Mon, Aug 17, 2015 at 11:52 AM, Ronald S. Bultje 
wrote:

> (This should only be applied when we bump version.) Removing the -ab
> option changes the codec settings serialization, so the ffm ref changes
> whenever we bump version and remove -ab.
> ---
>  tests/ref/lavf/ffm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/ref/lavf/ffm b/tests/ref/lavf/ffm
> index 5de2f39..76b7716 100644
> --- a/tests/ref/lavf/ffm
> +++ b/tests/ref/lavf/ffm
> @@ -1,3 +1,3 @@
> -d5d4e5e3eec336ae6680dde035870564 *./tests/data/lavf/lavf.ffm
> +4c3d2892c1d1be292f7b91788a0f7e17 *./tests/data/lavf/lavf.ffm
>  376832 ./tests/data/lavf/lavf.ffm
>  ./tests/data/lavf/lavf.ffm CRC=0x000e23ae
> --
> 2.1.2


So, uhm, I'd like to get the last few patches in. I want to consider some
options for this one, specifically. The diff between old and new .ffm is
this:

$ strings /tmp/old.ffm|grep ^b=|tr ',' '\n'>/tmp/old.ffm.hdr
$ strings /tmp/new.ffm|grep ^b=|tr ',' '\n'>/tmp/new.ffm.hdr
$ diff -u /tmp/{old,new}.ffm.hdr
--- /tmp/old.ffm.hdr 2015-08-19 09:17:06.0 -0400
+++ /tmp/new.ffm.hdr 2015-08-19 09:17:15.0 -0400
@@ -1,5 +1,4 @@
 b=64000
-ab=64000
 flags=0x0080
 ar=44100
 ac=1

And this happens upon version bump if we consider "ab" deprecated (which I
do). I can introduce a FF_OPT_FLAG_DEPRECATED in lavu/internal.h, mark "ab"
as such, and handle that flag in opt_serialize. I could even mark that flag
(in addition to being private) under FF_API_OLD_AVOPTIONS, so that it
magically disappears upon version bump.

We can also just wait for version bump and then apply this patch right
after FF_API_OLD_AVOPTIONS becomes 0.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: correct handling of dynamic frame size changing has been implemented

[Michael Niedermayer]

On Tue, Aug 04, 2015 at 01:52:07PM +0300, Ivan Uskov wrote:
> Hello All,
> 
> This patch for libavcodec/qsvdec.c does implement a correct handling
> of a case when frame dimensions were changed somewhere in middle of stream.
> Please review.
>   
> 
> -- 
> Best regards,
>  Ivan  mailto:ivan.us...@nablet.com

>  qsvdec.c |  145 
> +--
>  qsvdec.h |   11 
>  2 files changed, 134 insertions(+), 22 deletions(-)
> 3be72c7ca6c33135462b717ebc45d30e888758b9  
> 0001-libavcodec-qsvdec.c-correct-handling-of-dynamic-fram.patch
> From d57e9ac37e0398751f9fbcd74c2cf68eda129850 Mon Sep 17 00:00:00 2001
> From: Ivan Uskov 
> Date: Tue, 4 Aug 2015 06:40:06 -0400
> Subject: [PATCH] libavcodec/qsvdec.c: correct handling of dynamic frame size
>  changing has been implemented

ping
can someone review and test this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH] Added PicTiming SEI

[Hendrik Leppkes]

On Wed, Aug 19, 2015 at 1:57 PM, Sven Dueking  wrote:
>
>
>> -Ursprüngliche Nachricht-
>> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
>> von Michael Niedermayer
>> Gesendet: Mittwoch, 19. August 2015 13:51
>> An: FFmpeg development discussions and patches
>> Betreff: Re: [FFmpeg-devel] [PATCH] Added PicTiming SEI
>>
>> On Wed, Aug 19, 2015 at 09:17:40AM +0100, Sven Dueking wrote:
>> > From: Sven Dueking 
>> >
>> > ---
>> >  libavcodec/qsvenc.c  | 3 +++
>> >  libavcodec/qsvenc.h  | 1 +
>> >  libavcodec/qsvenc_h264.c | 1 +
>> >  3 files changed, 5 insertions(+)
>>
>> applied
>>
>> thanks
>
> Thanks, I will add a couple of other settings this week, do you prefer a
> patch for each setting or is it ok add more than one setting ?

Every distinct functional change should be its own patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/qsvdec.c: the ff_get_format() missed at refactoring has been restored

[Michael Niedermayer]

On Tue, Aug 11, 2015 at 01:57:17PM +0300, Ivan Uskov wrote:
> Hello Hendrik,
> 
> Tuesday, August 11, 2015, 11:33:41 AM, you wrote:
> 
> HL> On Sun, Aug 9, 2015 at 5:32 PM, Ivan Uskov  wrote:
> >> Hello All,
> >>
> >> This patch, next two patches and also the patch posted by me a August 4
> >> are fixing all issues about QSV-accelerated decoding.
> >>
> >> I will absent two next weeks since August 11 and will not accessible
> >> by e-mail. But even if these patches will not applied to master
> >> repository are can be used as hot fix to solve corresponded issues.
> >>
> >> About this patch. It does restore missed ff_get_format() call which
> >> necessary to select AV_PIX_FMT_QSV format.
> >>
> >>
> 
> HL> Are you able to test if QSV pixfmt output works with this patch applied?
> HL> Unfortunately the ffmpeg CLI tool does not have such functionality yet.
> Unfortunately, it is the sole patch which I was not able to test by
> myself.

> Do you have an ability to provide it to user which reported
> about regression before?

1 week passed, so i assume thats not possible and as it was
said that this is " probably fine"


> HL> Otherwise it looks simple enough and is probably fine.

applied

thanks

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH] Added PicTiming SEI

[Sven Dueking]

> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Michael Niedermayer
> Gesendet: Mittwoch, 19. August 2015 13:51
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added PicTiming SEI
> 
> On Wed, Aug 19, 2015 at 09:17:40AM +0100, Sven Dueking wrote:
> > From: Sven Dueking 
> >
> > ---
> >  libavcodec/qsvenc.c  | 3 +++
> >  libavcodec/qsvenc.h  | 1 +
> >  libavcodec/qsvenc_h264.c | 1 +
> >  3 files changed, 5 insertions(+)
> 
> applied
> 
> thanks

Thanks, I will add a couple of other settings this week, do you prefer a
patch for each setting or is it ok add more than one setting ? 
> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> The bravest are surely those who have the clearest vision of what is
> before them, glory and danger alike, and yet notwithstanding go out to
> meet it. -- Thucydides

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

Re: [FFmpeg-devel] [PATCH] Added PicTiming SEI

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 09:17:40AM +0100, Sven Dueking wrote:
> From: Sven Dueking 
> 
> ---
>  libavcodec/qsvenc.c  | 3 +++
>  libavcodec/qsvenc.h  | 1 +
>  libavcodec/qsvenc_h264.c | 1 +
>  3 files changed, 5 insertions(+)

applied

thanks

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: fix small memory leaks on error

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 01:06:56AM -0700, Neil Birkbeck wrote:
> Fixing small leaks that can occur when mkv_write_tracks fails in 
> mkv_write_header
> (e.g., if video track has unknown codec). Also changing mkv_write_seekhead to 
> take
> the MatroskaMuxContext to avoid having dangling pointers.
> 
> Signed-off-by: Neil Birkbeck 
> ---
>  libavformat/matroskaenc.c | 67 
> +++
>  1 file changed, 44 insertions(+), 23 deletions(-)

applied

thanks

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH v2 2/3] vaapi: streamline public context structure.

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 11:03:05AM +0200, Gwenole Beauchesne wrote:
> Move libavcodec managed objects from the public struct vaapi_context
> to a new privately owned FFVAContext. This is done so that to clean up
> and streamline the public structure, but also to prepare for new codec
> support, thus requiring new internal data to be added in there.
> 
> The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
> shall no longer be accessed from within vaapi_*.c codec support files.
> 
> v2: add one minor check for hwaccel_context existence, mark older
>   vaapi_context fields as deprecated until we reach lavc major+2,
>   amend doc/APIchanges.
> 
> Signed-off-by: Gwenole Beauchesne 
> ---
>  doc/APIchanges  |  4 
>  libavcodec/vaapi.c  | 40 +++-
>  libavcodec/vaapi.h  | 16 
>  libavcodec/vaapi_h264.c | 10 +++---
>  libavcodec/vaapi_internal.h | 42 --
>  libavcodec/vaapi_mpeg2.c|  8 ++--
>  libavcodec/vaapi_mpeg4.c| 11 +--
>  libavcodec/vaapi_vc1.c  | 11 +--
>  libavcodec/version.h|  3 +++
>  9 files changed, 121 insertions(+), 24 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index f5ba678..7d339ac 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2014-08-09
>  
>  API changes, most recent first:
>  
> +2015-xx-xx - lavc 56.57.0 - vaapi.h
 ^^^
this version does not, exist


[...]
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 2e7cf40..995c3e9 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -181,6 +181,9 @@

there should be a micro (or minor) bump here so that APIchanges
can refer to the version in which the deprecation happened

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH v2 1/3] vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Michael Niedermayer]

On Wed, Aug 19, 2015 at 11:03:04AM +0200, Gwenole Beauchesne wrote:
> Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
> to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
> that is aliased to the older VLD variant.
> 
> This is an API change.
> 
> v2: fix build when FF_API_VAAPI=0, mark older pixel formats as
>   deprecated until we reach lavu major+2, amend doc/APIchanges.
> 
> Signed-off-by: Gwenole Beauchesne 
> ---
>  doc/APIchanges   |  6 ++
>  libavcodec/h263dec.c |  2 +-
>  libavcodec/h264_slice.c  |  2 +-
>  libavcodec/mpeg12dec.c   |  2 +-
>  libavcodec/vaapi_h264.c  |  2 +-
>  libavcodec/vaapi_mpeg2.c |  2 +-
>  libavcodec/vaapi_mpeg4.c |  4 ++--
>  libavcodec/vaapi_vc1.c   |  4 ++--
>  libavcodec/vc1dec.c  |  2 +-
>  libavutil/pixdesc.c  |  9 +
>  libavutil/pixfmt.h   | 12 
>  libavutil/version.h  |  3 +++
>  12 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index cce2ddb..f5ba678 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,12 @@ libavutil: 2014-08-09
>  
>  API changes, most recent first:
>  
> +2015-xx-xx - lavc 54.30.0 - pixfmt.h
 ^^^
this looks wrong
that version doesnt exist and doesnt end in 100+

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] GSoC Weekly report (libswscale)

[Michael Niedermayer]

On Tue, Aug 18, 2015 at 11:36:16PM -0300, Pedro Arthur wrote:
> Added copyright.
> I've tried to push it (git push ffmpeg master --dry-run) but got the
> following error:
> fatal: remote error: access denied or repository not exported: /ffmpeg.git
> with remote:
> ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (fetch)
> ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (push)
> 
> is it correct?

> Anyway I'm attaching the patch.

still looks good

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] GSoC Weekly report (libswscale)

[Michael Niedermayer]

On Tue, Aug 18, 2015 at 11:36:16PM -0300, Pedro Arthur wrote:
> Added copyright.
> I've tried to push it (git push ffmpeg master --dry-run) but got the
> following error:
> fatal: remote error: access denied or repository not exported: /ffmpeg.git
> with remote:
> ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (fetch)
> ffmpeggit+ssh://source.ffmpeg.org/ffmpeg.git (push)

its:
g...@source.ffmpeg.org:ffmpeg

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH v2 3/3] vaapi: fix usage of invalid buffer ids.

[wm4]

On Wed, 19 Aug 2015 11:03:06 +0200
Gwenole Beauchesne  wrote:

> Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
> vaapi_*.c support files now that we have private data initialized and
> managed by libavcodec. Previously, the only requirement for the public
> vaapi_context struct was to be zero-initialized.
> 
> This fixes support for 3rdparty VA drivers that strictly conform to
> the API whereby an invalid buffer id is VA_INVALID_ID and the first
> valid buffer id can actually be zero.
> 
> Signed-off-by: Gwenole Beauchesne 
> ---
>  libavcodec/vaapi.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
> index 5dc43e1..d5f8fa2 100644
> --- a/libavcodec/vaapi.c
> +++ b/libavcodec/vaapi.c
> @@ -35,9 +35,9 @@ static void destroy_buffers(VADisplay display, VABufferID 
> *buffers, unsigned int
>  {
>  unsigned int i;
>  for (i = 0; i < n_buffers; i++) {
> -if (buffers[i]) {
> +if (buffers[i] != VA_INVALID_ID) {
>  vaDestroyBuffer(display, buffers[i]);
> -buffers[i] = 0;
> +buffers[i] = VA_INVALID_ID;
>  }
>  }
>  }
> @@ -55,6 +55,10 @@ int ff_vaapi_context_init(AVCodecContext *avctx)
>  vactx->display  = user_vactx->display;
>  vactx->config_id= user_vactx->config_id;
>  vactx->context_id   = user_vactx->context_id;
> +
> +vactx->pic_param_buf_id = VA_INVALID_ID;
> +vactx->iq_matrix_buf_id = VA_INVALID_ID;
> +vactx->bitplane_buf_id  = VA_INVALID_ID;
>  return 0;
>  }
>  
> @@ -68,18 +72,18 @@ int ff_vaapi_render_picture(FFVAContext *vactx, 
> VASurfaceID surface)
>  VABufferID va_buffers[3];
>  unsigned int n_va_buffers = 0;
>  
> -if (!vactx->pic_param_buf_id)
> +if (vactx->pic_param_buf_id == VA_INVALID_ID)
>  return 0;
>  
>  vaUnmapBuffer(vactx->display, vactx->pic_param_buf_id);
>  va_buffers[n_va_buffers++] = vactx->pic_param_buf_id;
>  
> -if (vactx->iq_matrix_buf_id) {
> +if (vactx->iq_matrix_buf_id != VA_INVALID_ID) {
>  vaUnmapBuffer(vactx->display, vactx->iq_matrix_buf_id);
>  va_buffers[n_va_buffers++] = vactx->iq_matrix_buf_id;
>  }
>  
> -if (vactx->bitplane_buf_id) {
> +if (vactx->bitplane_buf_id != VA_INVALID_ID) {
>  vaUnmapBuffer(vactx->display, vactx->bitplane_buf_id);
>  va_buffers[n_va_buffers++] = vactx->bitplane_buf_id;
>  }
> @@ -119,7 +123,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
>  return -1;
>  vactx->slice_buf_ids = slice_buf_ids;
>  
> -slice_param_buf_id = 0;
> +slice_param_buf_id = VA_INVALID_ID;
>  if (vaCreateBuffer(vactx->display, vactx->context_id,
> VASliceParameterBufferType,
> vactx->slice_param_size,
> @@ -128,7 +132,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
>  return -1;
>  vactx->slice_count = 0;
>  
> -slice_data_buf_id = 0;
> +slice_data_buf_id = VA_INVALID_ID;
>  if (vaCreateBuffer(vactx->display, vactx->context_id,
> VASliceDataBufferType,
> vactx->slice_data_size,
> @@ -147,7 +151,7 @@ static void *alloc_buffer(FFVAContext *vactx, int type, 
> unsigned int size, uint3
>  {
>  void *data = NULL;
>  
> -*buf_id = 0;
> +*buf_id = VA_INVALID_ID;
>  if (vaCreateBuffer(vactx->display, vactx->context_id,
> type, size, 1, NULL, buf_id) == VA_STATUS_SUCCESS)
>  vaMapBuffer(vactx->display, *buf_id, &data);

All 3 patches look good, and I'd say they can be merged now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] */version.h: Add note/recommandition about bumping major

[Michael Niedermayer]

On Tue, Aug 18, 2015 at 11:52:39PM +0200, Andreas Cadhalpun wrote:
> On 18.08.2015 12:28, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > If preferred, i can also apply this after the bump, in case its felt that
> > this would cause too much delay/work
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/version.h  |4 
> >  libavformat/version.h |5 +
> >  libavutil/version.h   |4 
> >  3 files changed, 13 insertions(+)
> > 
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 1b37a9e..cf9c924 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -46,6 +46,10 @@
> >   * FF_API_* defines may be placed below to indicate public API that will be
> >   * dropped at a future version bump. The defines themselves are not part of
> >   * the public API and may change, break or disappear at any time.
> > + *
> > + * @note, when bumping the major version it is recommandeded to manually
> > + * disable each FF_API_* in its own commit instead of disabling them all
> > + * at once through the bump. This improves the git bissect-ability of the 
> > change.
> >   */
> 
> I think that is a good idea,


> but instead of disabling the FF_API_* defines
> they should be removed together with the code guarded by them.
> Otherwise chances are that the old, disabled code will never get removed,
> see e.g. FF_API_OLD_GRAPH_PARSE.

that would increase the workload for bumping and also make it harder
to test for regressions caused by FF_API* in the days/week following
the bump. so my feeling is toward that keeping disabling and removing
seperate would be better

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH] configure: Use pkg-config for libkvazaar.

[Nicolas George]

Le primidi 1er fructidor, an CCXXIII, Michael Niedermayer a écrit :
> Also i think the primary question about supporting fallbacks
> is if there is a volunteer to maintain such support.
> If there is, there should be no objections against it.

Well, there are, especially with that extra requirement:

>Of course if there is a volunteer, people
> should still work together and not try to cause each other extra work
> and rather help.

The additional code complexity acts as a deterrent for people who may want
to rework the detection in depth (for example to implement --enable-auto, an
option several users have shown an interest for), and the "play nice"
requirement means they can not just hack the annoying code away and get to
work.

Furthermore, the fallbacks would make the whole process slower with
--enable-auto. For something completely useless ("install pkg-config is
almost always a simpler solution, and even when it is not enough, reasonably
simple solutions exist), that makes a lot of drawbacks.

I intend to object any kind of fallback that get in the way like that,
because they get in the way. I have a few ideas on how to make a fallback
that does not get in the way, but I expect that they will be silently
ignored again.

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 v2 2/3] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Move libavcodec managed objects from the public struct vaapi_context
to a new privately owned FFVAContext. This is done so that to clean up
and streamline the public structure, but also to prepare for new codec
support, thus requiring new internal data to be added in there.

The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
shall no longer be accessed from within vaapi_*.c codec support files.

v2: add one minor check for hwaccel_context existence, mark older
  vaapi_context fields as deprecated until we reach lavc major+2,
  amend doc/APIchanges.

Signed-off-by: Gwenole Beauchesne 
---
 doc/APIchanges  |  4 
 libavcodec/vaapi.c  | 40 +++-
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 10 +++---
 libavcodec/vaapi_internal.h | 42 --
 libavcodec/vaapi_mpeg2.c|  8 ++--
 libavcodec/vaapi_mpeg4.c| 11 +--
 libavcodec/vaapi_vc1.c  | 11 +--
 libavcodec/version.h|  3 +++
 9 files changed, 121 insertions(+), 24 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index f5ba678..7d339ac 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2015-xx-xx - lavc 56.57.0 - vaapi.h
+  Deprecate old VA-API context (vaapi_context) fields that were only
+  set and used by libavcodec. They are all managed internally now.
+
 2015-xx-xx - lavc 54.30.0 - pixfmt.h
   Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
   indicates the nature of the underlying storage: a VA surface.
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 6ac22e6..5dc43e1 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -21,6 +21,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/log.h"
 #include "h264.h"
 #include "vaapi_internal.h"
 
@@ -41,7 +42,28 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
-int ff_vaapi_render_picture(struct vaapi_context *vactx, VASurfaceID surface)
+int ff_vaapi_context_init(AVCodecContext *avctx)
+{
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
+const struct vaapi_context * const user_vactx = avctx->hwaccel_context;
+
+if (!user_vactx) {
+av_log(avctx, AV_LOG_ERROR, "Hardware acceleration context 
(hwaccel_context) does not exist.\n");
+return AVERROR(ENOSYS);
+}
+
+vactx->display  = user_vactx->display;
+vactx->config_id= user_vactx->config_id;
+vactx->context_id   = user_vactx->context_id;
+return 0;
+}
+
+int ff_vaapi_context_fini(AVCodecContext *avctx)
+{
+return 0;
+}
+
+int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID surface)
 {
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
@@ -81,7 +103,7 @@ int ff_vaapi_render_picture(struct vaapi_context *vactx, 
VASurfaceID surface)
 return 0;
 }
 
-int ff_vaapi_commit_slices(struct vaapi_context *vactx)
+int ff_vaapi_commit_slices(FFVAContext *vactx)
 {
 VABufferID *slice_buf_ids;
 VABufferID slice_param_buf_id, slice_data_buf_id;
@@ -121,7 +143,7 @@ int ff_vaapi_commit_slices(struct vaapi_context *vactx)
 return 0;
 }
 
-static void *alloc_buffer(struct vaapi_context *vactx, int type, unsigned int 
size, uint32_t *buf_id)
+static void *alloc_buffer(FFVAContext *vactx, int type, unsigned int size, 
uint32_t *buf_id)
 {
 void *data = NULL;
 
@@ -133,22 +155,22 @@ static void *alloc_buffer(struct vaapi_context *vactx, 
int type, unsigned int si
 return data;
 }
 
-void *ff_vaapi_alloc_pic_param(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_pic_param(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAPictureParameterBufferType, size, 
&vactx->pic_param_buf_id);
 }
 
-void *ff_vaapi_alloc_iq_matrix(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_iq_matrix(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAIQMatrixBufferType, size, 
&vactx->iq_matrix_buf_id);
 }
 
-uint8_t *ff_vaapi_alloc_bitplane(struct vaapi_context *vactx, uint32_t size)
+uint8_t *ff_vaapi_alloc_bitplane(FFVAContext *vactx, uint32_t size)
 {
 return alloc_buffer(vactx, VABitPlaneBufferType, size, 
&vactx->bitplane_buf_id);
 }
 
-VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct vaapi_context *vactx, 
const uint8_t *buffer, uint32_t size)
+VASliceParameterBufferBase *ff_vaapi_alloc_slice(FFVAContext *vactx, const 
uint8_t *buffer, uint32_t size)
 {
 uint8_t *slice_params;
 VASliceParameterBufferBase *slice_param;
@@ -181,7 +203,7 @@ VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct 
vaapi_context *vactx, co
 
 void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx->hwaccel_context;
+ 

[FFmpeg-devel] [PATCH v2 3/3] vaapi: fix usage of invalid buffer ids.

[Gwenole Beauchesne]

Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
vaapi_*.c support files now that we have private data initialized and
managed by libavcodec. Previously, the only requirement for the public
vaapi_context struct was to be zero-initialized.

This fixes support for 3rdparty VA drivers that strictly conform to
the API whereby an invalid buffer id is VA_INVALID_ID and the first
valid buffer id can actually be zero.

Signed-off-by: Gwenole Beauchesne 
---
 libavcodec/vaapi.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 5dc43e1..d5f8fa2 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -35,9 +35,9 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 {
 unsigned int i;
 for (i = 0; i < n_buffers; i++) {
-if (buffers[i]) {
+if (buffers[i] != VA_INVALID_ID) {
 vaDestroyBuffer(display, buffers[i]);
-buffers[i] = 0;
+buffers[i] = VA_INVALID_ID;
 }
 }
 }
@@ -55,6 +55,10 @@ int ff_vaapi_context_init(AVCodecContext *avctx)
 vactx->display  = user_vactx->display;
 vactx->config_id= user_vactx->config_id;
 vactx->context_id   = user_vactx->context_id;
+
+vactx->pic_param_buf_id = VA_INVALID_ID;
+vactx->iq_matrix_buf_id = VA_INVALID_ID;
+vactx->bitplane_buf_id  = VA_INVALID_ID;
 return 0;
 }
 
@@ -68,18 +72,18 @@ int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID 
surface)
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
 
-if (!vactx->pic_param_buf_id)
+if (vactx->pic_param_buf_id == VA_INVALID_ID)
 return 0;
 
 vaUnmapBuffer(vactx->display, vactx->pic_param_buf_id);
 va_buffers[n_va_buffers++] = vactx->pic_param_buf_id;
 
-if (vactx->iq_matrix_buf_id) {
+if (vactx->iq_matrix_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx->display, vactx->iq_matrix_buf_id);
 va_buffers[n_va_buffers++] = vactx->iq_matrix_buf_id;
 }
 
-if (vactx->bitplane_buf_id) {
+if (vactx->bitplane_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx->display, vactx->bitplane_buf_id);
 va_buffers[n_va_buffers++] = vactx->bitplane_buf_id;
 }
@@ -119,7 +123,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx->slice_buf_ids = slice_buf_ids;
 
-slice_param_buf_id = 0;
+slice_param_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx->display, vactx->context_id,
VASliceParameterBufferType,
vactx->slice_param_size,
@@ -128,7 +132,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx->slice_count = 0;
 
-slice_data_buf_id = 0;
+slice_data_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx->display, vactx->context_id,
VASliceDataBufferType,
vactx->slice_data_size,
@@ -147,7 +151,7 @@ static void *alloc_buffer(FFVAContext *vactx, int type, 
unsigned int size, uint3
 {
 void *data = NULL;
 
-*buf_id = 0;
+*buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx->display, vactx->context_id,
type, size, 1, NULL, buf_id) == VA_STATUS_SUCCESS)
 vaMapBuffer(vactx->display, *buf_id, &data);
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v2 1/3] vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.

This is an API change.

v2: fix build when FF_API_VAAPI=0, mark older pixel formats as
  deprecated until we reach lavu major+2, amend doc/APIchanges.

Signed-off-by: Gwenole Beauchesne 
---
 doc/APIchanges   |  6 ++
 libavcodec/h263dec.c |  2 +-
 libavcodec/h264_slice.c  |  2 +-
 libavcodec/mpeg12dec.c   |  2 +-
 libavcodec/vaapi_h264.c  |  2 +-
 libavcodec/vaapi_mpeg2.c |  2 +-
 libavcodec/vaapi_mpeg4.c |  4 ++--
 libavcodec/vaapi_vc1.c   |  4 ++--
 libavcodec/vc1dec.c  |  2 +-
 libavutil/pixdesc.c  |  9 +
 libavutil/pixfmt.h   | 12 
 libavutil/version.h  |  3 +++
 12 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index cce2ddb..f5ba678 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2015-xx-xx - lavc 54.30.0 - pixfmt.h
+  Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
+  indicates the nature of the underlying storage: a VA surface.
+  Deprecate old VA-API related pixel formats: AV_PIX_FMT_VAAPI_MOCO,
+  AV_PIX_FMT_VAAPI_IDCT, AV_PIX_FMT_VAAPI_VLD.
+
 2015-xx-xx - lavu 54.30.0
   xxx -  Add av_blowfish_alloc().
   xxx -  Add av_rc4_alloc().
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 8f28a94..c85ea9d 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -720,7 +720,7 @@ frame_end:
 
 const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
 #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
 AV_PIX_FMT_VDPAU,
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index e330489..5c116b0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -946,7 +946,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
 #endif
 #if CONFIG_H264_VAAPI_HWACCEL
-*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+*fmt++ = AV_PIX_FMT_VAAPI;
 #endif
 #if CONFIG_H264_VDA_HWACCEL
 *fmt++ = AV_PIX_FMT_VDA_VLD;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 4f60a1c..3e5ef0e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1213,7 +1213,7 @@ static const enum AVPixelFormat 
mpeg2_hwaccel_pixfmt_list_420[] = {
 AV_PIX_FMT_D3D11VA_VLD,
 #endif
 #if CONFIG_MPEG2_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
 AV_PIX_FMT_VIDEOTOOLBOX,
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 151aca9..55ee2fc 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
 .name   = "h264_vaapi",
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H264,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_h264_start_frame,
 .end_frame  = vaapi_h264_end_frame,
 .decode_slice   = vaapi_h264_decode_slice,
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 87fab89..27c69cd 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
 .name   = "mpeg2_vaapi",
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG2VIDEO,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg2_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg2_decode_slice,
diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
index 9b283f7..5b2e9d4 100644
--- a/libavcodec/vaapi_mpeg4.c
+++ b/libavcodec/vaapi_mpeg4.c
@@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
 .name   = "mpeg4_vaapi",
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG4,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
@@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
 .name   = "h263_vaapi",
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H263,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
i

[FFmpeg-devel] [PATCH v2 0/3] vaapi: minor refinements & fixes

[Gwenole Beauchesne]

Hi,

This is preparatory and minimal work in view to supporting other (WIP)
changes. I will push those by tomorrow if there is no other strong
objections.

For convenience, I have placed the code here:


Regards,
Gwenole Beauchesne (3):
  vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).
  vaapi: streamline public context structure.
  vaapi: fix usage of invalid buffer ids.

 doc/APIchanges  | 10 
 libavcodec/h263dec.c|  2 +-
 libavcodec/h264_slice.c |  2 +-
 libavcodec/mpeg12dec.c  |  2 +-
 libavcodec/vaapi.c  | 60 -
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 12 ++---
 libavcodec/vaapi_internal.h | 42 ++-
 libavcodec/vaapi_mpeg2.c| 10 +---
 libavcodec/vaapi_mpeg4.c| 15 +---
 libavcodec/vaapi_vc1.c  | 15 +---
 libavcodec/vc1dec.c |  2 +-
 libavcodec/version.h|  3 +++
 libavutil/pixdesc.c |  9 +++
 libavutil/pixfmt.h  | 12 +
 libavutil/version.h |  3 +++
 16 files changed, 173 insertions(+), 42 deletions(-)

-- 
1.9.1

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

[FFmpeg-devel] [PATCH] avfilter: add waveform monitor filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  74 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_histogram.c |   1 +
 libavfilter/vf_waveform.c  | 397 +
 5 files changed, 474 insertions(+)
 create mode 100644 libavfilter/vf_waveform.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7b386ef..9d56980 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10885,6 +10885,80 @@ Only deinterlace frames marked as interlaced.
 Default value is @samp{all}.
 @end table
 
+@section waveform
+Video waveform monitor.
+
+The waveform monitor plots color component intensity. By default luminance
+only. Each column of the waveform corresponds to a column of pixels in the
+source video.
+
+It accepts the following options:
+
+@table @option
+@item mode, m
+Can be either @code{row}, or @code{column}. Default is @code{column}.
+In row mode, the graph on the left side represents color component value 0 and
+the right side represents value = 255. In column mode, the top side represents
+color component value = 0 and bottom side represents value = 255.
+
+@item step, s
+Set step. Smaller values are useful to find out how many values of the same
+luminance are distributed across input rows/columns.
+Default value is @code{10}. Allowed range is [1, 255].
+
+@item mirror, r
+Set mirroring mode. @code{0} means unmirrored, @code{1} means mirrored.
+In mirrored mode, higher values will be represented on the left
+side for @code{row} mode and at the top for @code{column} mode. Default is
+@code{1} (mirrored).
+
+@item display, d
+Set display mode.
+It accepts the following values:
+@table @samp
+@item overlay
+Presents information identical to that in the @code{parade}, except
+that the graphs representing color components are superimposed directly
+over one another.
+
+This display mode makes it easier to spot relative differences or similarities
+in overlapping areas of the color components that are supposed to be identical,
+such as neutral whites, grays, or blacks.
+
+@item parade
+Display separate graph for the color components side by side in
+@code{row} mode or one below the other in @code{column} mode.
+
+Using this display mode makes it easy to spot color casts in the highlights
+and shadows of an image, by comparing the contours of the top and the bottom
+graphs of each waveform. Since whites, grays, and blacks are characterized
+by exactly equal amounts of red, green, and blue, neutral areas of the picture
+should display three waveforms of roughly equal width/height. If not, the
+correction is easy to perform by making level adjustments the three waveforms.
+@end table
+Default is @code{parade}.
+
+@item components, c
+Set which color components to display. Default is 1, which means only luminance
+or red color component if input is in RGB colorspace. If is set for example to
+7 it will display all 3 (if) available color components.
+
+@item envelope, e
+@table @samp
+@item none
+No envelope, this is default.
+
+@item instant
+Instant envelope, minimum and maximum values presented in graph will be easily
+visible even with small @code{step} value.
+
+@item peak
+Hold minimum and maximum values presented in graph across time. This way you
+can still spot out of range values without constantly looking at waveforms.
+@end table
+
+@end table
+
 @section xbr
 Apply the xBR high-quality magnification filter which is designed for pixel
 art. It follows a set of edge-detection rules, see
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 75581f2..b15eaf4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -231,6 +231,7 @@ OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += 
vidstabutils.o vf_vidstabdetect.
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
+OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o
 OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ce51382..0756dbb 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -246,6 +246,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
 REGISTER_FILTER(VIGNETTE,   vignette,   vf);
 REGISTER_FILTER(W3FDIF, w3fdif, vf);
+REGISTER_FILTER(WAVEFORM,   waveform,   vf);
 REGISTER_FILTER(XBR,xbr,vf);
 REGISTER_FILTER(YADIF,  yadif,  vf);
 REGISTER_FILTER(ZMQ,zmq,vf);
diff --git a/libavfilter/vf_histogram.c b/libavfilter/vf_histogram.c
index 31004b7..7e32b3c 100644
--- a/libavfilter/vf_histogram.c
+++ b

Re: [FFmpeg-devel] [PATCH 1/5] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Hi,

2015-08-19 0:02 GMT+02:00 Andreas Cadhalpun :
> On 18.08.2015 17:26, Gwenole Beauchesne wrote:
>> Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
>> to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
>> that is aliased to the older VLD variant.
>>
>> Signed-off-by: Gwenole Beauchesne 
>> ---
>>  libavcodec/h263dec.c |  2 +-
>>  libavcodec/h264_slice.c  |  2 +-
>>  libavcodec/mpeg12dec.c   |  2 +-
>>  libavcodec/vaapi_h264.c  |  2 +-
>>  libavcodec/vaapi_mpeg2.c |  2 +-
>>  libavcodec/vaapi_mpeg4.c |  4 ++--
>>  libavcodec/vaapi_vc1.c   |  4 ++--
>>  libavcodec/vc1dec.c  |  2 +-
>>  libavutil/pixdesc.c  |  9 +
>>  libavutil/pixfmt.h   | 12 
>>  libavutil/version.h  |  3 +++
>>  11 files changed, 34 insertions(+), 10 deletions(-)
>>
> [...]
>> --- a/libavutil/version.h
>> +++ b/libavutil/version.h
>> @@ -107,6 +107,9 @@
>>  #ifndef FF_API_AVFRAME_LAVC
>>  #define FF_API_AVFRAME_LAVC (LIBAVUTIL_VERSION_MAJOR < 55)
>>  #endif
>> +#ifndef FF_API_VAAPI
>> +#define FF_API_VAAPI(LIBAVUTIL_VERSION_MAJOR < 55)
>> +#endif
>
> I think the deprecation should be at least in one release before it is 
> removed.
> Hence using '< 56' would be better.
> Also mentioning this change in doc/APIchanges would be good.
>
> The same goes for FF_API_VAAPI_CONTEXT from the second patch.

You are right. Thanks.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Added PicTiming SEI

[Sven Dueking]

From: Sven Dueking 

---
 libavcodec/qsvenc.c  | 3 +++
 libavcodec/qsvenc.h  | 1 +
 libavcodec/qsvenc_h264.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 57f5fe4..6f97240 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -146,6 +146,9 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->extco.CAVLC= avctx->coder_type == FF_CODER_TYPE_VLC 
?
 MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_UNKNOWN;
 
+q->extco.PicTimingSEI = q->pic_timing_sei ?
+MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_UNKNOWN;
+
 q->extparam[0] = (mfxExtBuffer *)&q->extco;
 
 q->param.ExtParam= q->extparam;
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 19be2aa..2316488 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -61,6 +61,7 @@ typedef struct QSVEncContext {
 int preset;
 int avbr_accuracy;
 int avbr_convergence;
+int pic_timing_sei;
 
 char *load_plugins;
 } QSVEncContext;
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 95396fc..b15f6b2 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -69,6 +69,7 @@ static const AVOption options[] = {
 { "idr_interval", "Distance (in I-frames) between IDR frames", 
OFFSET(qsv.idr_interval), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "avbr_accuracy","Accuracy of the AVBR ratecontrol",
OFFSET(qsv.avbr_accuracy),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
 { "avbr_convergence", "Convergence of the AVBR ratecontrol", 
OFFSET(qsv.avbr_convergence), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
+{ "pic_timing_sei","Insert picture timing SEI with pic_struct_syntax 
element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
 
 { "profile", NULL, OFFSET(qsv.profile), AV_OPT_TYPE_INT, { .i64 = 
MFX_PROFILE_UNKNOWN }, 0, INT_MAX, VE, "profile" },
 { "unknown" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_UNKNOWN 
 }, INT_MIN, INT_MAX, VE, "profile" },
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: fix small memory leaks on error

[Neil Birkbeck]

Fixing small leaks that can occur when mkv_write_tracks fails in 
mkv_write_header
(e.g., if video track has unknown codec). Also changing mkv_write_seekhead to 
take
the MatroskaMuxContext to avoid having dangling pointers.

Signed-off-by: Neil Birkbeck 
---
 libavformat/matroskaenc.c | 67 +++
 1 file changed, 44 insertions(+), 23 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7f82804..1325c3f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -309,6 +309,23 @@ static void put_xiph_size(AVIOContext *pb, int size)
 }
 
 /**
+ * Free the members allocated in the mux context.
+ */
+static void mkv_free(MatroskaMuxContext *mkv) {
+if (mkv->main_seekhead) {
+av_freep(&mkv->main_seekhead->entries);
+av_freep(&mkv->main_seekhead);
+}
+if (mkv->cues) {
+av_freep(&mkv->cues->entries);
+av_freep(&mkv->cues);
+}
+av_freep(&mkv->tracks);
+av_freep(&mkv->stream_durations);
+av_freep(&mkv->stream_duration_offsets);
+}
+
+/**
  * Initialize a mkv_seekhead element to be ready to index level 1 Matroska
  * elements. If a maximum number of elements is specified, enough space
  * will be reserved at the current file location to write a seek head of
@@ -368,8 +385,9 @@ static int mkv_add_seekhead_entry(mkv_seekhead *seekhead, 
unsigned int elementid
  * @return The file offset where the seekhead was written,
  * -1 if an error occurred.
  */
-static int64_t mkv_write_seekhead(AVIOContext *pb, mkv_seekhead *seekhead)
+static int64_t mkv_write_seekhead(AVIOContext *pb, MatroskaMuxContext *mkv)
 {
+mkv_seekhead *seekhead = mkv->main_seekhead;
 ebml_master metaseek, seekentry;
 int64_t currentpos;
 int i;
@@ -406,8 +424,8 @@ static int64_t mkv_write_seekhead(AVIOContext *pb, 
mkv_seekhead *seekhead)
 currentpos = seekhead->filepos;
 }
 fail:
-av_freep(&seekhead->entries);
-av_free(seekhead);
+av_freep(&mkv->main_seekhead->entries);
+av_freep(&mkv->main_seekhead);
 
 return currentpos;
 }
@@ -1397,9 +1415,10 @@ static int mkv_write_header(AVFormatContext *s)
 }
 
 mkv->tracks = av_mallocz_array(s->nb_streams, sizeof(*mkv->tracks));
-if (!mkv->tracks)
-return AVERROR(ENOMEM);
-
+if (!mkv->tracks) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 ebml_header = start_ebml_master(pb, EBML_ID_HEADER, 0);
 put_ebml_uint   (pb, EBML_ID_EBMLVERSION,   1);
 put_ebml_uint   (pb, EBML_ID_EBMLREADVERSION,   1);
@@ -1419,11 +1438,13 @@ static int mkv_write_header(AVFormatContext *s)
 // isn't more than 10 elements if we only write one of each other
 // currently defined level 1 element
 mkv->main_seekhead= mkv_start_seekhead(pb, mkv->segment_offset, 10);
-if (!mkv->main_seekhead)
-return AVERROR(ENOMEM);
+if (!mkv->main_seekhead) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 
 ret = mkv_add_seekhead_entry(mkv->main_seekhead, MATROSKA_ID_INFO, 
avio_tell(pb));
-if (ret < 0) return ret;
+if (ret < 0) goto fail;
 
 segment_info = start_ebml_master(pb, MATROSKA_ID_INFO, 0);
 put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, 100);
@@ -1472,7 +1493,7 @@ static int mkv_write_header(AVFormatContext *s)
 
 ret = mkv_write_tracks(s);
 if (ret < 0)
-return ret;
+goto fail;
 
 for (i = 0; i < s->nb_chapters; i++)
 mkv->chapter_id_offset = FFMAX(mkv->chapter_id_offset, 1LL - 
s->chapters[i]->id);
@@ -1480,24 +1501,25 @@ static int mkv_write_header(AVFormatContext *s)
 if (mkv->mode != MODE_WEBM) {
 ret = mkv_write_chapters(s);
 if (ret < 0)
-return ret;
+goto fail;
 
 ret = mkv_write_tags(s);
 if (ret < 0)
-return ret;
+goto fail;
 
 ret = mkv_write_attachments(s);
 if (ret < 0)
-return ret;
+goto fail;
 }
 
 if (!s->pb->seekable && !mkv->is_live)
-mkv_write_seekhead(pb, mkv->main_seekhead);
+mkv_write_seekhead(pb, mkv);
 
 mkv->cues = mkv_start_cues(mkv->segment_offset);
-if (!mkv->cues)
-return AVERROR(ENOMEM);
-
+if (!mkv->cues) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 if (pb->seekable && mkv->reserve_cues_space) {
 mkv->cues_pos = avio_tell(pb);
 put_ebml_void(pb, mkv->reserve_cues_space);
@@ -1524,6 +1546,9 @@ static int mkv_write_header(AVFormatContext *s)
 }
 
 return 0;
+fail:
+mkv_free(mkv);
+return ret;
 }
 
 static int mkv_blockgroup_size(int pkt_size)
@@ -2015,7 +2040,7 @@ static int mkv_write_trailer(AVFormatContext *s)
 return ret;
 }
 
-mkv_write_seekhead(pb, mkv->main_seekhead);
+mkv_write_seekhead(pb, mkv);
 
 // update the duration
 av_log(s, AV_LOG_DEBUG, "end duration = %"