Re: [FFmpeg-devel] [PATCH 4/9] lavf/tcp: add tcp_accept
On Thu, Jul 9, 2015 at 3:31 PM, Nicolas George geo...@nsup.org wrote:
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/tcp.c | 18 ++
1 file changed, 18 insertions(+)
Changes since first version:
- Add av_assert0() check for sc-listen
- Add bitmask for s-flags in ffurl_alloc
- Use ff_accept() instead of accept()
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index f24cad2..6f5e175 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include avformat.h
+#include libavutil/avassert.h
#include libavutil/parseutils.h
#include libavutil/opt.h
#include libavutil/time.h
@@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
return ret;
}
+static int tcp_accept(URLContext *s, URLContext **c)
+{
+TCPContext *sc = s-priv_data;
+TCPContext *cc;
+int ret;
+av_assert0(sc-listen);
+if ((ret = ffurl_alloc(c, s-filename, s-flags AVIO_FLAG_READ_WRITE,
s-interrupt_callback)) 0)
+return ret;
Any reason to remove the other flags? Since it is not possible to add flags
on a context afterwards, setting the flags on the server to have them on the
clients is the most obvious solution. AVIO_FLAG_NONBLOCK does not work, but
AVIO_FLAG_DIRECT does and makes sense for network protocols.
No reason at all, I wasn't aware of that. What other flags should be
kept? Since you suggested filtering s-flags I'm assuming not all
flags from s should be kept?
Should the same filtering then be applied in http_accept() too?
+cc = (*c)-priv_data;
+ret = ff_accept(sc-fd, sc-listen_timeout, s);
+if (ret 0)
+return ff_neterrno();
+cc-fd = ret;
+return 0;
+}
+
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
@@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
URLProtocol ff_tcp_protocol = {
.name= tcp,
.url_open= tcp_open,
+.url_accept = tcp_accept,
.url_read= tcp_read,
.url_write = tcp_write,
.url_close = tcp_close,
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Regards,
Stephan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata
Le decadi 20 messidor, an CCXXIII, Marton Balint a écrit : I'd still use the metadata directive. If someone needs per-stream, or per-packet metadata, he can implement selector directives for that. Like metadata_stream or metadata_interval which will change the scope of the following metadata directives. How about that? I am still uneasy about that. Selectors feel like making the parser more complex, and also there is the issue of self-documentation. When someone reads a concat script and see metadata foo=bar, unless they already know exactly the directive, they will take a guess at what it does, and since packet metadata is rare, especially packet metadata that is duplicated over all the packets, they will probably not guess right. I really think a more specific name would be useful. This is an usability issue, though, so my role as maintainer is not very important: let us ear advice from other people. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
On Thu, Jul 09, 2015 at 05:07:38PM +0300, Ivan Uskov wrote: Hello Michael, Ooops, missed that you modified the file recently. Will prepare another patch. By the way, now I can not compile master repo under --enable-libmfx config, there is compiler error appears: libavcodec/qsvenc_hevc.c:71:5: error: too few arguments to function ‘ff_hevc_extract_rbsp’ Are there some update should be soon? Also, do you know a real reason to make q-width_align = avctx-codec_id == AV_CODEC_ID_HEVC ? 32 : 16; into the qsvenc.c? I did not check it yet and never work with Intel HEVC before but all Intel's samples never perform such check, width alignment in latest Intel's samples is always 16... Its not my code nor my change, i do not know what the correct value is. This change was merged by me and originates from libav. I tried to merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’ ill try to fix that but i dont have a libmfx setup here ATM so If you can check and if needed correct it, that would help alot! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
Hello Michael, Ooops, missed that you modified the file recently. Will prepare another patch. By the way, now I can not compile master repo under --enable-libmfx config, there is compiler error appears: libavcodec/qsvenc_hevc.c:71:5: error: too few arguments to function ‘ff_hevc_extract_rbsp’ Are there some update should be soon? Also, do you know a real reason to make q-width_align = avctx-codec_id == AV_CODEC_ID_HEVC ? 32 : 16; into the qsvenc.c? I did not check it yet and never work with Intel HEVC before but all Intel's samples never perform such check, width alignment in latest Intel's samples is always 16... Thursday, July 9, 2015, 3:18:58 PM, you wrote: MN On Thu, Jul 09, 2015 at 02:24:43PM +0300, Ivan Uskov wrote: Hello All, There is another place into libavcodec/qsvenc.c where height may be aligned to 32 for the case when alignment to 16 is enough. It can be reason of superfluous frame copying. The attached patch does solve this issue. Please review. MN does not apply cleanly MN Applying: libavcodec/qsvenc.c: Fix for too agressive height MN alignment during frame encoding which may be reason of superflous frame copying. MN Using index info to reconstruct a base tree... MN Falling back to patching base and 3-way merge... MN Auto-merging libavcodec/qsvenc.h MN Auto-merging libavcodec/qsvenc.c MN CONFLICT (content): Merge conflict in libavcodec/qsvenc.c MN Failed to merge in the changes. MN Patch failed at 0001 libavcodec/qsvenc.c: Fix for too agressive MN height alignment during frame encoding which may be reason of superflous frame copying. MN [...] -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 9/9] doc/example: Add http multi-client example code
On Thu, Jul 9, 2015 at 3:47 PM, Nicolas George geo...@nsup.org wrote:
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
doc/examples/Makefile | 1 +
doc/examples/http_multiclient.c | 120
2 files changed, 121 insertions(+)
create mode 100644 doc/examples/http_multiclient.c
Changes since first version:
- Move client handling code in separate function
- Close filedescriptors earlier
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 9699f11..8c9501b 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -18,6 +18,7 @@ EXAMPLES= avio_list_dir \
extract_mvs\
filtering_video\
filtering_audio\
+http_multiclient \
metadata \
muxing \
remuxing \
diff --git a/doc/examples/http_multiclient.c
b/doc/examples/http_multiclient.c
new file mode 100644
index 000..a780321
--- /dev/null
+++ b/doc/examples/http_multiclient.c
@@ -0,0 +1,120 @@
+/*
+ * copyright (c) 2015 Stephan Holljes
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * libavformat multi-client network API usage example.
+ *
+ * @example http_multiclient.c
+ * This example will serve a file without decoding or demuxing it over http.
+ * Multiple clients can connect and will receive the same file.
+ */
+
+#include libavformat/avformat.h
+#include unistd.h
+
+void process_client(AVIOContext *client, const char* in_uri)
+{
+AVIOContext *input =NULL;
Nit: space.
+uint8_t buf[1024];
+int ret, n;
+avio_handshake(client);
Check for error.
+fprintf(stderr, Handshake performed.\n);
+fprintf(stderr, Opening input file.\n);
+if ((ret = avio_open2(input, in_uri, AVIO_FLAG_READ, NULL, NULL)) 0)
{
+av_log(input, AV_LOG_ERROR, Failed to open input: %s\n, in_uri);
+return;
+}
I just realized this: how would you go about returning 404 to the client
here?
Good question, I haven't thought about that myself. Adding a 404 error
to handle_http_errors() and calling it with AVERROR_HTTP_NOT_FOUND
could be a solution. I feel like the name handle_http_errors is not
well chosen then, though.
+for(;;) {
+n = avio_read(input, buf, sizeof(buf));
+if (n 0) {
+if (n == AVERROR_EOF)
+break;
+av_log(input, AV_LOG_ERROR, Error reading from input: %s.\n,
+ av_err2str(n));
+ret = n;
+break;
+}
+avio_write(client, buf, n);
+avio_flush(client);
+}
+fprintf(stderr, Flushing client\n);
+avio_flush(client);
+fprintf(stderr, Closing client\n);
+avio_close(client);
+fprintf(stderr, Closing input\n);
+avio_close(input);
+}
+
+int main(int argc, char **argv)
+{
+AVDictionary *options = NULL;
+AVIOContext *client = NULL, *server = NULL;
+const char *in_uri, *out_uri;
+int ret, pid;
+if (argc 3) {
+printf(usage: %s input http://hostname[:port]\n;
+ API example program to serve http to multiple clients.\n
+ \n, argv[0]);
+return 1;
+}
+
+in_uri = argv[1];
+out_uri = argv[2];
+
+av_register_all();
+avformat_network_init();
+
+if ((ret = av_dict_set(options, listen, 2, 0)) 0)
+goto end;
+if ((ret = avio_open2(server, out_uri, AVIO_FLAG_READ_WRITE, NULL,
options)) 0)
+goto end;
+fprintf(stderr, Entering main loop.\n);
+for(;;) {
+if ((ret = avio_accept(server, client)) 0)
+goto end;
+fprintf(stderr, Accepted client, forking process.\n);
+// XXX: Since we don't reap our children and don't ignore signals
+// this produces zombie processes.
+pid = fork();
+if (pid 0) {
+
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
Hello Michael, Ok, I will take care. Thursday, July 9, 2015, 5:47:22 PM, you wrote: MN Its not my code nor my change, i do not know what the correct value MN is. MN This change was merged by me and originates from libav. I tried to MN merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’ MN ill try to fix that but i dont have a libmfx setup here ATM so MN If you can check and if needed correct it, that would help alot! -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] lavf/http: add http_accept
On Thu, Jul 9, 2015 at 3:41 PM, Nicolas George geo...@nsup.org wrote:
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/http.c | 19 +++
1 file changed, 19 insertions(+)
Changes since first version:
- Add av_assert0() check for sc-listen
- Add bitmask for s-flags in ffurl_alloc
Thanks.
diff --git a/libavformat/http.c b/libavformat/http.c
index 676bfd5..3c1ec35 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -25,6 +25,7 @@
#include zlib.h
#endif /* CONFIG_ZLIB */
+#include libavutil/avassert.h
#include libavutil/avstring.h
#include libavutil/opt.h
@@ -382,6 +383,24 @@ static int http_open(URLContext *h, const char *uri,
int flags,
return ret;
}
+static int http_accept(URLContext *s, URLContext **c)
+{
+int ret;
+HTTPContext *sc = s-priv_data;
+HTTPContext *cc;
+URLContext *sl = sc-hd;
+URLContext *cl;
+av_assert0(sc-listen);
+if ((ret = ffurl_alloc(c, s-filename, s-flags AVIO_FLAG_READ_WRITE,
sl-interrupt_callback)) 0)
+goto fail;
Same remark as in my previous mail.
+cc = (*c)-priv_data;
+if ((ret = ffurl_accept(sl, cl)) 0)
+goto fail;
+cc-hd = cl;
Does it make sense to set cc-listen = 1 here, to indicate that the client
is not yet a normal client? It may make the tests for trailers simpler.
I am not sure about the implications. So far setting listen has been
exclusive to server contexts. I'll will give it some thoughts and do
some testing.
+fail:
+return ret;
+}
+
static int http_getc(HTTPContext *s)
{
int len;
Regards,
--
Nicolas George
___
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 9/9] doc/example: Add http multi-client example code
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
doc/examples/Makefile | 1 +
doc/examples/http_multiclient.c | 120
2 files changed, 121 insertions(+)
create mode 100644 doc/examples/http_multiclient.c
Changes since first version:
- Move client handling code in separate function
- Close filedescriptors earlier
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 9699f11..8c9501b 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -18,6 +18,7 @@ EXAMPLES= avio_list_dir \
extract_mvs\
filtering_video\
filtering_audio\
+http_multiclient \
metadata \
muxing \
remuxing \
diff --git a/doc/examples/http_multiclient.c b/doc/examples/http_multiclient.c
new file mode 100644
index 000..a780321
--- /dev/null
+++ b/doc/examples/http_multiclient.c
@@ -0,0 +1,120 @@
+/*
+ * copyright (c) 2015 Stephan Holljes
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * libavformat multi-client network API usage example.
+ *
+ * @example http_multiclient.c
+ * This example will serve a file without decoding or demuxing it over http.
+ * Multiple clients can connect and will receive the same file.
+ */
+
+#include libavformat/avformat.h
+#include unistd.h
+
+void process_client(AVIOContext *client, const char* in_uri)
+{
+AVIOContext *input =NULL;
Nit: space.
+uint8_t buf[1024];
+int ret, n;
+avio_handshake(client);
Check for error.
+fprintf(stderr, Handshake performed.\n);
+fprintf(stderr, Opening input file.\n);
+if ((ret = avio_open2(input, in_uri, AVIO_FLAG_READ, NULL, NULL)) 0) {
+av_log(input, AV_LOG_ERROR, Failed to open input: %s\n, in_uri);
+return;
+}
I just realized this: how would you go about returning 404 to the client
here?
+for(;;) {
+n = avio_read(input, buf, sizeof(buf));
+if (n 0) {
+if (n == AVERROR_EOF)
+break;
+av_log(input, AV_LOG_ERROR, Error reading from input: %s.\n,
+ av_err2str(n));
+ret = n;
+break;
+}
+avio_write(client, buf, n);
+avio_flush(client);
+}
+fprintf(stderr, Flushing client\n);
+avio_flush(client);
+fprintf(stderr, Closing client\n);
+avio_close(client);
+fprintf(stderr, Closing input\n);
+avio_close(input);
+}
+
+int main(int argc, char **argv)
+{
+AVDictionary *options = NULL;
+AVIOContext *client = NULL, *server = NULL;
+const char *in_uri, *out_uri;
+int ret, pid;
+if (argc 3) {
+printf(usage: %s input http://hostname[:port]\n;
+ API example program to serve http to multiple clients.\n
+ \n, argv[0]);
+return 1;
+}
+
+in_uri = argv[1];
+out_uri = argv[2];
+
+av_register_all();
+avformat_network_init();
+
+if ((ret = av_dict_set(options, listen, 2, 0)) 0)
+goto end;
+if ((ret = avio_open2(server, out_uri, AVIO_FLAG_READ_WRITE, NULL,
options)) 0)
+goto end;
+fprintf(stderr, Entering main loop.\n);
+for(;;) {
+if ((ret = avio_accept(server, client)) 0)
+goto end;
+fprintf(stderr, Accepted client, forking process.\n);
+// XXX: Since we don't reap our children and don't ignore signals
+// this produces zombie processes.
+pid = fork();
+if (pid 0) {
+fprintf(stderr, Fork failed.\n);
perror()
+ret = AVERROR(errno);
+goto end;
+}
+if (pid == 0) {
+fprintf(stderr, In child.\n);
+process_client(client, in_uri);
+avio_close(server);
+exit(0);
+}
+
Re: [FFmpeg-devel] [PATCH 7/9] lavf/http: increase range for listen, handle connection closing accordingly, add http_handshake and move handshake logic there
On Thu, Jul 9, 2015 at 3:42 PM, Nicolas George geo...@nsup.org wrote:
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/http.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
Changes since first version:
- Return from http_handshake() if no errors occured instead of falling
through
fail label
- Add av_assert0() check for error in handle_http_errors()
- Remove passthough if error == 0 (should never happen anymore)
Is it possible to use tcp_accept() without tcp_handshake()? If not, you
probably should merge patches 6 and 7.
I'm assuming you meant http_accept() and http_handshake(). On the API
level it should be possible to use them separately, for an application
it would probably not make much sense to use only http_accept()
without http_handshake(). I will merge the patches.
diff --git a/libavformat/http.c b/libavformat/http.c
index 3c1ec35..813870e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -129,7 +129,7 @@ static const AVOption options[] = {
{ 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 },
{ 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, 1, D | E },
+{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 2, D | E },
{ NULL }
};
@@ -305,6 +305,7 @@ static void handle_http_errors(URLContext *h, int error)
static const char bad_request[] = HTTP/1.1 400 Bad
Request\r\nContent-Type: text/plain\r\n\r\n400 Bad Request\r\n;
static const char internal_server_error[] = HTTP/1.1 500 Internal
server error\r\nContent-Type: text/plain\r\n\r\n500 Internal server
error\r\n;
HTTPContext *s = h-priv_data;
+av_assert0(error 0);
if (h-is_connected) {
switch(error) {
case AVERROR_HTTP_BAD_REQUEST:
@@ -317,15 +318,33 @@ static void handle_http_errors(URLContext *h, int
error)
}
}
+static int http_handshake(URLContext *c) {
Nit: inconsistent brace placement.
Fixed locally, will be updated in next patch series.
+int ret, err, new_location;
+HTTPContext *ch = c-priv_data;
+URLContext *cl = ch-hd;
+static const char header[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
+if ((ret = ffurl_handshake(cl)) 0)
+return ret;
+if ((err = http_read_header(c, new_location)) 0)
+goto fail;
+if ((ret = ffurl_write(cl, header, strlen(header))) 0)
+return ret;
+// Avoid returning a positive value from ffurl_write()
+ret = ret 0 ? 0 : ret;
+return ret;
+fail:
+handle_http_errors(c, err);
+return ret;
+}
+
static int http_listen(URLContext *h, const char *uri, int flags,
AVDictionary **options) {
HTTPContext *s = h-priv_data;
int ret;
-static const char header[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
char hostname[1024], proto[10];
char lower_url[100];
const char *lower_proto = tcp;
-int port, new_location;
+int port;
s-chunked_post = 1;
av_url_split(proto, sizeof(proto), NULL, 0, hostname, sizeof(hostname),
port,
NULL, 0, uri);
@@ -333,18 +352,14 @@ static int http_listen(URLContext *h, const char *uri,
int flags,
lower_proto = tls;
ff_url_join(lower_url, sizeof(lower_url), lower_proto, NULL, hostname,
port,
NULL);
-av_dict_set(options, listen, 1, 0);
+if ((ret = av_dict_set_int(options, listen, s-listen, 0)) 0)
+goto fail;
if ((ret = ffurl_open(s-hd, lower_url, AVIO_FLAG_READ_WRITE,
h-interrupt_callback, options)) 0)
goto fail;
-if ((ret = http_read_header(h, new_location)) 0)
- goto fail;
-if ((ret = ffurl_write(s-hd, header, strlen(header))) 0)
- goto fail;
-return 0;
-
+if (s-listen == 1) /* single client */
+ret = http_handshake(h);
fail:
-handle_http_errors(h, ret);
av_dict_free(s-chained_options);
return ret;
}
@@ -1365,6 +1380,8 @@ HTTP_CLASS(http);
URLProtocol ff_http_protocol = {
.name= http,
.url_open2 = http_open,
+.url_accept = http_accept,
+.url_handshake = http_handshake,
.url_read= http_read,
.url_write = http_write,
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
Hello Michael, Please review the attached updated patch about height alignment. The qsvenc_hevc.c compiles now thanks. But same command line that I use for h264_qsv does fail for hevc_qsv with error [hevc_qsv @ 0x25a7620] Unexpected NAL type in the extradata: 52 Here can be lot reasons including too old MXF library (I'm use 2015R4 but latest 2015R6). It is just info, I will review qsvenc_hevc.c later when all known minor defects of qsvenc.c will fixed. Thursday, July 9, 2015, 5:47:22 PM, you wrote: MN This change was merged by me and originates from libav. I tried to MN merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’ MN ill try to fix that but i dont have a libmfx setup here ATM so MN If you can check and if needed correct it, that would help alot! MN Thanks MN [...] -- Best regards, Ivanmailto:ivan.us...@nablet.com 0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add Dynamic Audio Normalizer filter
From: LoRd_MuldeR muld...@gmx.de
Signed-off-by: Paul B Mahol one...@gmail.com
---
doc/filters.texi| 158 ++
libavfilter/Makefile| 1 +
libavfilter/af_dynaudnorm.c | 739
libavfilter/allfilters.c| 1 +
4 files changed, 899 insertions(+)
create mode 100644 libavfilter/af_dynaudnorm.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 3fce874..74c408a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1520,6 +1520,164 @@ Optional. It should have a value much less than 1 (e.g.
0.05 or 0.02) and is
used to prevent clipping.
@end table
+@section dynaudnorm
+Dynamic Audio Normalizer.
+
+This filter applies a certain amount of gain to the input audion in order
+to bring its peak magnitude to a target level (e.g. 0 dBFS). However, in
+contrast to more simple normalization algorithms, the Dynamic Audio
+Normalizer *dynamically* re-adjusts the gain factor to the input audio.
+This allows for applying extra gain to the quiet sections of the audio
+while avoiding distortions or clipping the loud sections. In other words:
+The Dynamic Audio Normalizer will even out the volume of quiet and loud
+sections, in the sense that the volume of each section is brought to the
+same target level. Note, however, that the Dynamic Audio Normalizer achieves
+this goal *without* applying dynamic range compressing. It will retain 100%
+of the dynamic range *within* each section of the audio file.
+
+@table @option
+@item f
+Set the frame length in milliseconds. In range from 10 to 8000 milliseconds.
+Default is 500 milliseconds.
+The Dynamic Audio Normalizer processes the input audio in small chunks,
+referred to as frames. This is required, because a peak magnitude has no
+meaning for just a single sample value. Instead, we need to determine the
+peak magnitude for a contiguous sequence of sample values. While a standard
+normalizer would simply use the peak magnitude of the complete file, the
+Dynamic Audio Normalizer determines the peak magnitude individually for each
+frame. The length of a frame is specified in milliseconds. By default, the
+Dynamic Audio Normalizer uses a frame length of 500 milliseconds, which has
+been found to give good results with most files.
+Note that the exact frame length, in number of samples, will be determined
+automatically, based on the sampling rate of the individual input audio file.
+
+@item g
+Set the Gaussian filter window size. In range from 3 to 301, must be odd
+number. Default is 31.
+Probably the most important parameter of the Dynamic Audio Normalizer is the
+@code{window size} of the Gaussian smoothing filter. The filter's window size
+is specified in frames, centered around the current frame. For the sake of
+simplicity, this must be an odd number. Consequently, the default value of 31
+takes into account the current frame, as well as the 15 preceding frames and
+the 15 subsequent frames. Using a larger window results in a stronger
+smoothing effect and thus in less gain variation, i.e. slower gain
+adaptation. Conversely, using a smaller window results in a weaker smoothing
+effect and thus in more gain variation, i.e. faster gain adaptation.
+In other words, the more you increase this value, the more the Dynamic Audio
+Normalizer will behave like a traditional normalization filter. On the
+contrary, the more you decrease this value, the more the Dynamic Audio
+Normalizer will behave like a dynamic range compressor.
+
+@item p
+Set the target peak value. This specifies the highest permissible magnitude
+level for the normalized audio input. This filter will try to approach the
+target peak magnitude as closely as possible, but at the same time it also
+makes sure that the normalized signal will never exceed the peak magnitude.
+A frame's maximum local gain factor is imposed directly by the target peak
+magnitude. The default value is 0.95 and thus leaves a headroom of 5%*.
+It is not recommended to go above this value.
+
+@item m
+Set the maximum gain factor. In range from 1.0 to 100.0. Default is 10.0.
+The Dynamic Audio Normalizer determines the maximum possible (local) gain
+factor for each input frame, i.e. the maximum gain factor that does not
+result in clipping or distortion. The maximum gain factor is determined by
+the frame's highest magnitude sample. However, the Dynamic Audio Normalizer
+additionally bounds the frame's maximum gain factor by a predetermined
+(global) maximum gain factor. This is done in order to avoid excessive gain
+factors in silent or almost silent frames. By default, the maximum gain
+factor is 10.0, For most inputs the default value should be sufficient and
+it usually is not recommended to increase this value. Though, for input
+with an extremely low overall volume level, it may be necessary to allow even
+higher gain factors. Note, however, that the Dynamic Audio Normalizer does
+not simply apply a hard threshold (i.e. cut off values above the
Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout
On 09/07/15 9:10 AM, Hendrik Leppkes wrote:
On Thu, Jul 9, 2015 at 1:32 PM, wm4 nfx...@googlemail.com wrote:
On Tue, 7 Jul 2015 03:06:24 -0300
James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/libdcadec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 4bc3765..796826e 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -36,6 +36,8 @@ typedef struct DCADecContext {
int buffer_size;
} DCADecContext;
+static int downmix_warned = 0;
+
static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
void *data,
if (exss = dcadec_context_get_exss_info(s-ctx)) {
enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+if (!downmix_warned) {
+uint64_t layout = avctx-request_channel_layout;
+
+if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout ==
AV_CH_LAYOUT_STEREO) !exss-embedded_stereo) ||
+( layout == AV_CH_LAYOUT_5POINT1 !exss-embedded_6ch))
+av_log(avctx, AV_LOG_WARNING, %s downmix was requested
but no custom coefficients are available,
+ this may result in
clipping\n,
+ layout ==
AV_CH_LAYOUT_5POINT1 ? 5.1 : stereo);
+downmix_warned = 1;
+}
+
What does this mean? Does this happen with FFmpeg's DCA decoder too?
It just means that the DCA stream has no embedded downmix
coefficients. It'll downmix using the default coeffs, which can mean
two things, 1) this was intended, and all is fine, 2) downmixing was
not considered, and it may clip.
Personally, I might like a mode where it would downmix if the coeffs
are available, and not downmix if not (so I can downmix clipping-safe
using av/swresample later).
It can't be currently done, as the behavior of the flags is pretty inconsistent
as i described in the patch.
We could however open a ticket asking the dcadec developer to actually change
the implementation so something like that is possible before the first version
is tagged (To avoid ifdeffery).
The native decoder would have the same problem, but I don't know if it
even supports embedded downmixes properly.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Setting the frame rate in libavcodec/libopenh264enc.c
We have been using Cisco's libopenh264 as part of FFmpeg with good results. However, function svc_encode_init() in libavcodec/libopenh264enc.c appears to be setting the frame rate incorrectly. The line of code in question looks like: param.fMaxFrameRate = avctx-time_base.den / avctx-time_base.num; Since fMaxFrameRate is of type float, shouldn't this be something like: param.fMaxFrameRate = avctx-time_base.den / (double)avctx-time_base.num; Or is there some reason why the frame rate should get truncated to an integer? Greg Wolfe, Kodak Alaris (formerly part of Eastman Kodak) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
On Thu, Jul 09, 2015 at 06:34:25PM +0300, Ivan Uskov wrote: Hello Michael, Please review the attached updated patch about height alignment. The qsvenc_hevc.c compiles now thanks. But same command line that I use for h264_qsv does fail for hevc_qsv with error [hevc_qsv @ 0x25a7620] Unexpected NAL type in the extradata: 52 Here can be lot reasons including too old MXF library (I'm use 2015R4 but latest 2015R6). It is just info, I will review qsvenc_hevc.c later when all known minor defects of qsvenc.c will fixed. Thursday, July 9, 2015, 5:47:22 PM, you wrote: MN This change was merged by me and originates from libav. I tried to MN merge things so they work, apparently i failed for ‘ff_hevc_extract_rbsp’ MN ill try to fix that but i dont have a libmfx setup here ATM so MN If you can check and if needed correct it, that would help alot! MN Thanks MN [...] -- Best regards, Ivanmailto:ivan.us...@nablet.com qsvenc.c | 10 ++ qsvenc.h |1 + 2 files changed, 7 insertions(+), 4 deletions(-) f5b7a7c8b54204643242b785b20176eab2d5238a 0001-libavcodec-qsvenc.c-Fix-for-too-agressive-height-ali.patch From 1131ad41f6aedc7aa262ab70e8e320a59cd5121c Mon Sep 17 00:00:00 2001 From: Ivan Uskov ivan.us...@nablet.com Date: Thu, 9 Jul 2015 16:49:36 +0300 Subject: [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout
On Thu, 9 Jul 2015 14:10:40 +0200
Hendrik Leppkes h.lepp...@gmail.com wrote:
On Thu, Jul 9, 2015 at 1:32 PM, wm4 nfx...@googlemail.com wrote:
On Tue, 7 Jul 2015 03:06:24 -0300
James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/libdcadec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 4bc3765..796826e 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -36,6 +36,8 @@ typedef struct DCADecContext {
int buffer_size;
} DCADecContext;
+static int downmix_warned = 0;
+
static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
void *data,
if (exss = dcadec_context_get_exss_info(s-ctx)) {
enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+if (!downmix_warned) {
+uint64_t layout = avctx-request_channel_layout;
+
+if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout ==
AV_CH_LAYOUT_STEREO) !exss-embedded_stereo) ||
+( layout == AV_CH_LAYOUT_5POINT1 !exss-embedded_6ch))
+av_log(avctx, AV_LOG_WARNING, %s downmix was requested
but no custom coefficients are available,
+ this may result in
clipping\n,
+ layout ==
AV_CH_LAYOUT_5POINT1 ? 5.1 : stereo);
+downmix_warned = 1;
+}
+
What does this mean? Does this happen with FFmpeg's DCA decoder too?
It just means that the DCA stream has no embedded downmix
coefficients. It'll downmix using the default coeffs, which can mean
two things, 1) this was intended, and all is fine, 2) downmixing was
not considered, and it may clip.
Personally, I might like a mode where it would downmix if the coeffs
are available, and not downmix if not (so I can downmix clipping-safe
using av/swresample later).
I'd prefer that too.
The native decoder would have the same problem, but I don't know if it
even supports embedded downmixes properly.
Then I guess it doesn't matter, as it won't cause regressions. Thanks
for the explanation.
___
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
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 st...@borho.org 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.
Also, do you need an API bump in configure for this?
Rest LGTM.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not unecessarily consume memory for cuepoints
Michael Niedermayer michaelni at gmx.at writes: Matroska streaming currently consumes memory for cuepoints that are never used if the output stream is no seekable. This can lead to oom. Attached patch fixes ticket #4690. should be ok The patch was merged. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Do not check the table number before warning about the precision
Michael Niedermayer michaelni at gmx.at writes: Imo, the precision check in rtpenc_jpeg.c is wrong: Only the upper four bits contain the precision, the lower four bits are the table number. LGTM Merged by you. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync
Hello All, Current implementation of handling MFXVideoENCODE_EncodeFrameAsync() return codes allows unhanded silent warnings and unclear error reporting if the function return some non-successful code. The attached patch solves this issue and makes troubleshooting more easy. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsvenc.c-improving-handling-for-return-co.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2
On 08.07.2015 18:07, Michael Niedermayer wrote: On Wed, Jul 08, 2015 at 07:24:13AM -0400, Ronald S. Bultje wrote: - last of all, I want to remind you guys that we haven't done a very thorough code analysis to see if this can actually be triggered. As an example, look at commit 458446acfa1441d283dacf9e6e545beb083b8bb0. Before that, vp8 files smaller than 16x16 or vp9 files smaller than 64x64 could cause aborts. The vp9 ones I noticed due to some fate files being so small. I doubt you'll ever find such vp8 files, but they're valid. Let's not add silly checks to replace other silly ones. Do you have any vp9 files triggering this assert? if people prefer i ca revert b8c438e7623644edcfdb508c946a723a3b79b893 or add a check for stride == 0 what do people prefer ? The assert can be triggered by the h264 decoder: mc_dir_part in libavcodec/h264_mb.c calls the 16 bit variant of emulated_edge_mc and thus the assert is triggered due to the sizeof(pixel) factor, even though block_w is smaller than buf_linesize. If that's valid behavior of the h264 decoder, then the assert should be removed, but if on the other hand this is a bug in the h264 decoder, then that should be fixed and the assert remain. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for highlight and hilightcolor box
On 2015-07-06 14:42, Clément Bœsch wrote:
{
int i = 0;
int text_pos = 0;
while (text text_end) {
-for (i = 0; i style_entries; i++) {
-if (s[i]-style_flag text_pos == s[i]-style_end) {
-if (s[i]-style_flag STYLE_FLAG_BOLD)
-av_bprintf(buf, {\\b0});
-if (s[i]-style_flag STYLE_FLAG_ITALIC)
-av_bprintf(buf, {\\i0});
-if (s[i]-style_flag STYLE_FLAG_UNDERLINE)
-av_bprintf(buf, {\\u0});
+if (m-box_flags STYL_BOX) {
+for (i = 0; i m-style_entries; i++) {
+if (m-s[i]-style_flag text_pos ==
m-s[i]-style_end) {
+if (m-s[i]-style_flag STYLE_FLAG_BOLD)
+av_bprintf(buf, {\\b0});
+if (m-s[i]-style_flag STYLE_FLAG_ITALIC)
+av_bprintf(buf, {\\i0});
+if (m-s[i]-style_flag STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, {\\u0});
+}
+}
keep this block not re-idented (and eventually add a /* TODO: reindent
*/
above) to keep the diff small and ease review. You can re-indent in a
later commit.
Do you really mean this? This is not a simple re-indent. The variables
on those
lines are also changing? In which case, I'd include the re-indent at the
same time.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2
On 08.07.2015 01:22, Michael Niedermayer wrote: On Tue, Jul 07, 2015 at 11:32:59PM +0200, Andreas Cadhalpun wrote: I think the assert is a historic leftover: Before commit cc884a35 src_stride 7*MB_SIZE was necessary, because the blocks were interleaved in the tmp buffer and the last block was added with an offset of 6*MB_SIZE. It was changed for src_stride = 7*MB_SIZE to write the blocks sequentially, hence the larger tmp_stride. (A comment about this in the code would have been nice.) yes, should i add one or you want to ? I added one to the patch. Updated version attached. Does that sound good? However, there are still some things in this code which are unclear for me: * Where does the 5 in 'src_stride 2*MB_SIZE + 5' come from? Shouldn't that have been HTAPS_MAX-1, because that is added to block_h, when calling emulated_edge_mc? * Why the factor 2 in 'src_stride 2*MB_SIZE + 5'? Before commit cc884a35 the buffer size was 'src_stride*(b_h+5)' and b_h is at maximum MB_SIZE, not 2*MB_SIZE. I dont remember trying to make the assert be exact just sufficient to detect problems, it was not intended to stay IIRC, so it would have been a waste of time to calculate exactly what the minimum size was also i think that we should only spend time on this investigation if we intend to work on the code. Its hardly worth for just removing the apparently unneeded assert. if you want to improve snow (the algorithm or implementation) then investigating every smal bit does make sense OK. * Why is tmp_step based on MB_SIZE and not (MB_SIZE + HTAPS_MAX-1)? This 'HTAPS_MAX-1' is added to b_w/b_h when calling emulated_edge_mc. to keep things aligned in memory, it may help or be required for SIMD use I suppose that's correct then. Best regards, Andreas From 7747ec5a7e319c05e28c6988caa84ad1f37fd301 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Thu, 9 Jul 2015 19:50:34 +0200 Subject: [PATCH] snow: remove an obsolete av_assert2 It asserts that the frame linesize is larger than 37, but it can be smaller and decoding such frames works. Before commit cc884a35 src_stride 7*MB_SIZE was necessary, because the blocks were interleaved in the tmp buffer and the last block was added with an offset of 6*MB_SIZE. It was changed for src_stride = 7*MB_SIZE to write the blocks sequentially, hence the larger tmp_step. After that the assert was only necessary to make sure that the buffer remained large enough. Since commit bd2b6b33 s-scratchbuf is used as tmp buffer. As part of commit 86e107a7 the minimal scratchbuf size was increased to 256*7*MB_SIZE, which is enough for any src_stride = 7*MB_SIZE. Also add a comment explaining the tmp_step calculation. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavcodec/snow.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/snow.h b/libavcodec/snow.h index 95e07cd..447859f 100644 --- a/libavcodec/snow.h +++ b/libavcodec/snow.h @@ -304,6 +304,8 @@ static av_always_inline void add_yblock(SnowContext *s, int sliced, slice_buffer BlockNode *lb= lt+b_stride; BlockNode *rb= lb+1; uint8_t *block[4]; +// When src_stride is large enough, it is possible to interleave the blocks. +// Otherwise the blocks are written sequentially in the tmp buffer. int tmp_step= src_stride = 7*MB_SIZE ? MB_SIZE : MB_SIZE*src_stride; uint8_t *tmp = s-scratchbuf; uint8_t *ptmp; @@ -347,8 +349,6 @@ static av_always_inline void add_yblock(SnowContext *s, int sliced, slice_buffer if(b_w=0 || b_h=0) return; -av_assert2(src_stride 2*MB_SIZE + 5); - if(!sliced offset_dst) dst += src_x + src_y*dst_stride; dst8+= src_x + src_y*src_stride; -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown
On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote: Hi, On Jul 7, 2015, at 10:35 AM, Michael Niedermayer michae...@gmx.at wrote: On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote: Hi all, Last month I posted a draft of the FFV1 specification formatted in Markdown [1], whereas it currently lives in lyx. From that post there were responses in favor of the use of Markdown formatting and suggestions to not use mathml within a draft targeting an RFC specification and suggestions to update a few urls. I propose to proceed with a format conversion of the FFV1 specification from lyx to Markdown and then I'll file tickets or patches to explore simplifying the mathml expressions and updating the urls. Attached is a patch to convert the formatting (but not meaning) of the FFV1 specification from lyx to markdown. Best Regards, Dave Rice [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851 how can this be edited and converted ? Via pandoc you can get outputs that are close to the current ffv1.html and ffv1.pdf outputs of ffv1.lyx. pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o ffv1.html pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V geometry:margin=1in -o ffv1.pdf I can move this info to a readme. please do ive tried with pandoc --version pandoc 1.9.1.1 and it also fails (all tables messed up), the html in git looks good though does this use features available only in recent pandoc ? [...] -- 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] conversion of FFV1 specification from lyx to markdown
On Jul 9, 2015, at 1:53 PM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote: Hi, On Jul 7, 2015, at 10:35 AM, Michael Niedermayer michae...@gmx.at wrote: On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote: Hi all, Last month I posted a draft of the FFV1 specification formatted in Markdown [1], whereas it currently lives in lyx. From that post there were responses in favor of the use of Markdown formatting and suggestions to not use mathml within a draft targeting an RFC specification and suggestions to update a few urls. I propose to proceed with a format conversion of the FFV1 specification from lyx to Markdown and then I'll file tickets or patches to explore simplifying the mathml expressions and updating the urls. Attached is a patch to convert the formatting (but not meaning) of the FFV1 specification from lyx to markdown. Best Regards, Dave Rice [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851 how can this be edited and converted ? Via pandoc you can get outputs that are close to the current ffv1.html and ffv1.pdf outputs of ffv1.lyx. pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o ffv1.html pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V geometry:margin=1in -o ffv1.pdf I can move this info to a readme. please do Sure. Would you prefer a patch on ffmpeg-devel or a PR in github? ive tried with pandoc --version pandoc 1.9.1.1 I'm using: pandoc --version pandoc 1.13.2.1 I'm only recently introduced to pandoc so I'm not well aware of the difference from 1.9.1.1 to 1.13.3.1, but I do see a lot of references to markdown and table bug fixes in http://pandoc.org/releases.html http://pandoc.org/releases.html after 1.9.1.1. and it also fails (all tables messed up), the html in git looks good though Could you give me access to your pdf so I can see the difference. does this use features available only in recent pandoc ? It seems so. Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Use av_log to print benchmark output
Michael Niedermayer michaelni at gmx.at writes: Attached patch stops -benchmark from using stdout. i wonder why this used printf() maybe wait a day or 2 before applying in case there was a reason that i forgot Merged. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables
Michael Niedermayer michaelni at gmx.at writes: + Only standard Huffman tables are supported\n); I think the error messages should be changed to say that RFC... doesnt allow stuff not that its not supported implying it could be supported Merged with a different error message. I tried to add some information to ticket #3823: -vcodec mjpeg -pix_fmt yuv422p -f rtp fails because it would require encoding in rows of 1 block instead of 2. Other encoders use custom Huffman tables which are also not allowed. I believe there is still a bug with quantisation tables that I'll try to fix. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata
On Thu, 9 Jul 2015, Nicolas George wrote: Le decadi 20 messidor, an CCXXIII, Marton Balint a écrit : I'd still use the metadata directive. If someone needs per-stream, or per-packet metadata, he can implement selector directives for that. Like metadata_stream or metadata_interval which will change the scope of the following metadata directives. How about that? I am still uneasy about that. Selectors feel like making the parser more complex, and also there is the issue of self-documentation. When someone reads a concat script and see metadata foo=bar, unless they already know exactly the directive, they will take a guess at what it does, and since packet metadata is rare, especially packet metadata that is duplicated over all the packets, they will probably not guess right. I really think a more specific name would be useful. What about file_packet_metadata? It clearly states that metadata is set on a file level, and it belongs to packets. This is an usability issue, though, so my role as maintainer is not very important: let us ear advice from other people. Sure, anybody? :) Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Setting the frame rate in libavcodec/libopenh264enc.c
On Thu, Jul 09, 2015 at 03:49:07PM +, Gregory J Wolfe wrote: We have been using Cisco's libopenh264 as part of FFmpeg with good results. However, function svc_encode_init() in libavcodec/libopenh264enc.c appears to be setting the frame rate incorrectly. The line of code in question looks like: param.fMaxFrameRate = avctx-time_base.den / avctx-time_base.num; Since fMaxFrameRate is of type float, shouldn't this be something like: param.fMaxFrameRate = avctx-time_base.den / (double)avctx-time_base.num; equivalent change made thanks [...] -- 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
[FFmpeg-devel] Looking for the answer about windows-based codec(like wmv) license
Hi there. Title says, i have a question about license with windows-based codec, such as wmv, wma. As i know, at least, wma(and wmv) is not same wma which is presented from windows, and it is just compatiable codec so it doesn't require specific license. but i don't know for sure with that. can i use wmv, wma codec without license in FFmpeg? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec: loongson optimized h264pred with mmi
Hi, Michael.
did you install the new FC21 and is there any problem when installing?
the installation maybe freted, but worth.
i add .set arch=loongson3a for last h264pred patch to pass compiling on
FC19-O32, and fate success in both FC19-O32 and FC21-N64.
i think it's ok to use .set arch=loongson3a to bypass using dli in
O32-system, as
these codes only for loongson3 cpu, and 3A, 3B use same option
-march=loongson3a to enable mmi.
---
From f378ba9b5d15495f8fcb93e049ee3538b744ecba Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong zhouxiaoy...@loongson.cn
Date: Thu, 9 Jul 2015 10:59:12 +0800
Subject: [PATCH 1/2] avcodec: loongson optimized h264pred with mmi
Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/h264pred_init_mips.c | 53 +++
libavcodec/mips/h264pred_mips.h | 53 +++
libavcodec/mips/h264pred_mmi.c | 804 +++
4 files changed, 911 insertions(+)
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 5569a03..c16c93a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -58,3 +58,4 @@ MSA-OBJS-$(CONFIG_MPEGVIDEOENC) +=
mips/mpegvideoencdsp_msa.o
MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
+MMI-OBJS-$(CONFIG_H264PRED) += mips/h264pred_mmi.o
diff --git a/libavcodec/mips/h264pred_init_mips.c
b/libavcodec/mips/h264pred_init_mips.c
index 27ff10f..a2124ec 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *Zhou Xiaoyong zhouxiaoy...@loongson.cn
*
* This file is part of FFmpeg.
*
@@ -20,6 +21,7 @@
#include config.h
#include h264dsp_mips.h
+#include h264pred_mips.h
#if HAVE_MSA
static av_cold void h264_pred_init_msa(H264PredContext *h, int codec_id,
@@ -94,6 +96,54 @@ static av_cold void h264_pred_init_msa(H264PredContext *h,
int codec_id,
}
#endif // #if HAVE_MSA
+#if HAVE_MMI
+static av_cold void h264_pred_init_mmi(H264PredContext *h, int codec_id,
+const int bit_depth, const int chroma_format_idc)
+{
+if (bit_depth == 8) {
+if (chroma_format_idc == 1) {
+h-pred8x8 [VERT_PRED8x8 ] = ff_pred8x8_vertical_8_mmi;
+h-pred8x8 [HOR_PRED8x8] = ff_pred8x8_horizontal_8_mmi;
+} else {
+h-pred8x8 [VERT_PRED8x8 ] = ff_pred8x16_vertical_8_mmi;
+h-pred8x8 [HOR_PRED8x8] = ff_pred8x16_horizontal_8_mmi;
+}
+
+h-pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_8_mmi;
+h-pred16x16[VERT_PRED8x8 ] = ff_pred16x16_vertical_8_mmi;
+h-pred16x16[HOR_PRED8x8] = ff_pred16x16_horizontal_8_mmi;
+h-pred8x8l [TOP_DC_PRED] = ff_pred8x8l_top_dc_8_mmi;
+h-pred8x8l [DC_PRED] = ff_pred8x8l_dc_8_mmi;
+h-pred8x8l [HOR_PRED ] = ff_pred8x8l_horizontal_8_mmi;
+
+switch (codec_id) {
+case AV_CODEC_ID_SVQ3:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_svq3_8_mmi;
+;
+break;
+case AV_CODEC_ID_RV40:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_rv40_8_mmi;
+;
+break;
+case AV_CODEC_ID_VP7:
+case AV_CODEC_ID_VP8:
+;
+break;
+default:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_h264_8_mmi;
+break;
+}
+
+if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) {
+if (chroma_format_idc == 1) {
+h-pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_8_mmi;
+h-pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_8_mmi;
+}
+}
+}
+}
+#endif /* HAVE_MMI */
+
av_cold void ff_h264_pred_init_mips(H264PredContext *h, int codec_id,
int bit_depth,
const int chroma_format_idc)
@@ -101,4 +151,7 @@ av_cold void ff_h264_pred_init_mips(H264PredContext *h, int
codec_id,
#if HAVE_MSA
h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
#endif // #if HAVE_MSA
+#if HAVE_MMI
+h264_pred_init_mmi(h, codec_id, bit_depth, chroma_format_idc);
+#endif /* HAVE_MMI */
}
diff --git a/libavcodec/mips/h264pred_mips.h b/libavcodec/mips/h264pred_mips.h
new file mode 100644
index 000..16bf6fc
--- /dev/null
+++ b/libavcodec/mips/h264pred_mips.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong zhouxiaoy...@loongson.cn
+ *
+ * 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
[FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables
Hi!
RFC 2435 requires standard Huffman tables when sending (m)jpeg over rtp.
Related to ticket #3823.
Please comment, Carl Eugen
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 7ee26c4..e9d09e9 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -21,6 +21,7 @@
#include libavcodec/bytestream.h
#include libavcodec/mjpeg.h
+#include libavcodec/jpegtables.h
#include libavutil/intreadwrite.h
#include rtpenc.h
@@ -81,6 +82,26 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t
*buf, int size)
Only 1x1 chroma blocks are supported. Aborted!\n);
return;
}
+} else if (buf[i + 1] == DHT) {
+if ( AV_RB16(buf[i + 2]) 418
+|| i + 420 = size
+|| buf[i + 4] != 0x00
+|| buf[i + 33] != 0x01
+|| buf[i + 62] != 0x10
+|| buf[i + 241] != 0x11
+|| memcmp(buf + i + 5, avpriv_mjpeg_bits_dc_luminance + 1,
16)
+|| memcmp(buf + i + 21, avpriv_mjpeg_val_dc, 12)
+|| memcmp(buf + i + 34, avpriv_mjpeg_bits_dc_chrominance + 1,
16)
+|| memcmp(buf + i + 50, avpriv_mjpeg_val_dc, 12)
+|| memcmp(buf + i + 63, avpriv_mjpeg_bits_ac_luminance + 1,
16)
+|| memcmp(buf + i + 79, avpriv_mjpeg_val_ac_luminance, 162)
+|| memcmp(buf + i + 242, avpriv_mjpeg_bits_ac_chrominance + 1,
16)
+|| memcmp(buf + i + 258, avpriv_mjpeg_val_ac_chrominance,
162)) {
+av_log(s1, AV_LOG_ERROR,
+ Only standard Huffman tables are supported\n);
+return;
+}
+break;
} else if (buf[i + 1] == SOS) {
/* SOS is last marker in the header */
i += AV_RB16(buf[i + 2]) + 2;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Error out if mjpeg over rtp is not 4:2:0
Paul B Mahol onemda at gmail.com writes: Looking at rtpenc_jpeg: 422 is mentioned there. Yes, it might work if you use the right encoder. Patch withdrawn, I sent a new patch that adds an additional necessary check when sending mjpeg. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: Move return code setting code to the error cases
On Thu, Jul 09, 2015 at 12:47:25AM -0300, James Almer wrote:
On 09/07/15 12:26 AM, Michael Niedermayer wrote:
Iam not sure this is better or worse than before
What do people prefer ?
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/hevc_ps.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 1038516..372081a 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -998,7 +998,6 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
sps, 0)) 0)
goto err;
}
-ret = AVERROR_INVALIDDATA;
sps-long_term_ref_pics_present_flag = get_bits1(gb);
if (sps-long_term_ref_pics_present_flag) {
@@ -1006,6 +1005,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
*gb, unsigned int *sps_id,
if (sps-num_long_term_ref_pics_sps 31U) {
av_log(avctx, AV_LOG_ERROR, num_long_term_ref_pics_sps %d is
out of range.\n,
sps-num_long_term_ref_pics_sps);
+ret = AVERROR_INVALIDDATA;
goto err;
}
for (i = 0; i sps-num_long_term_ref_pics_sps; i++) {
@@ -1096,6 +1096,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
*gb, unsigned int *sps_id,
if (sps-log2_ctb_size MAX_LOG2_CTB_SIZE) {
av_log(avctx, AV_LOG_ERROR, CTB size out of range: 2^%d\n,
sps-log2_ctb_size);
+ret = AVERROR_INVALIDDATA;
goto err;
}
if (sps-log2_ctb_size 4) {
@@ -1104,6 +1105,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
*gb, unsigned int *sps_id,
log2_ctb_size %d differs from the bounds of any known
profile\n,
sps-log2_ctb_size);
avpriv_request_sample(avctx, log2_ctb_size %d,
sps-log2_ctb_size);
+ret = AVERROR_INVALIDDATA;
goto err;
}
@@ -1124,29 +1126,34 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
*gb, unsigned int *sps_id,
if (av_mod_uintp2(sps-width, sps-log2_min_cb_size) ||
av_mod_uintp2(sps-height, sps-log2_min_cb_size)) {
av_log(avctx, AV_LOG_ERROR, Invalid coded frame dimensions.\n);
+ret = AVERROR_INVALIDDATA;
goto err;
}
if (sps-max_transform_hierarchy_depth_inter sps-log2_ctb_size -
sps-log2_min_tb_size) {
av_log(avctx, AV_LOG_ERROR, max_transform_hierarchy_depth_inter
out of range: %d\n,
sps-max_transform_hierarchy_depth_inter);
+ret = AVERROR_INVALIDDATA;
goto err;
}
if (sps-max_transform_hierarchy_depth_intra sps-log2_ctb_size -
sps-log2_min_tb_size) {
av_log(avctx, AV_LOG_ERROR, max_transform_hierarchy_depth_intra
out of range: %d\n,
sps-max_transform_hierarchy_depth_intra);
+ret = AVERROR_INVALIDDATA;
goto err;
}
if (sps-log2_max_trafo_size FFMIN(sps-log2_ctb_size, 5)) {
av_log(avctx, AV_LOG_ERROR,
max transform block size out of range: %d\n,
sps-log2_max_trafo_size);
+ret = AVERROR_INVALIDDATA;
goto err;
}
if (get_bits_left(gb) 0) {
av_log(avctx, AV_LOG_ERROR,
Overread SPS by %d bits\n, -get_bits_left(gb));
+ret = AVERROR_INVALIDDATA;
goto err;
}
Why not just replace every goto err with a return AVERROR_INVALIDDATA? The
gotos
seem pointless considering the only code after it is return ret. No memory
being
freed and nothing being uninitialized to justify them.
hmm, ive missed that somehow
done that
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: try to fix \r when build for android on cygwin
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 5833808..46c4788 100755
--- a/configure
+++ b/configure
@@ -475,7 +475,7 @@ sh_quote(){
}
cleanws(){
-echo $@ | sed 's/^ *//;s/ */ /g;s/ *$//;s/\\r//g'
+echo $@ | sed s/^ *//;s/ */ /g;s/ *$//;s/\\r//g
}
filter(){
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add removegrain tests
Signed-off-by: Paul B Mahol one...@gmail.com --- tests/fate/filter-video.mak | 78 +++ tests/ref/fate/filter-removegrain-mode-00 | 2 + tests/ref/fate/filter-removegrain-mode-01 | 2 + tests/ref/fate/filter-removegrain-mode-02 | 2 + tests/ref/fate/filter-removegrain-mode-03 | 2 + tests/ref/fate/filter-removegrain-mode-04 | 2 + tests/ref/fate/filter-removegrain-mode-05 | 2 + tests/ref/fate/filter-removegrain-mode-06 | 2 + tests/ref/fate/filter-removegrain-mode-07 | 2 + tests/ref/fate/filter-removegrain-mode-08 | 2 + tests/ref/fate/filter-removegrain-mode-09 | 2 + tests/ref/fate/filter-removegrain-mode-10 | 2 + tests/ref/fate/filter-removegrain-mode-11 | 2 + tests/ref/fate/filter-removegrain-mode-12 | 2 + tests/ref/fate/filter-removegrain-mode-13 | 2 + tests/ref/fate/filter-removegrain-mode-14 | 2 + tests/ref/fate/filter-removegrain-mode-15 | 2 + tests/ref/fate/filter-removegrain-mode-16 | 2 + tests/ref/fate/filter-removegrain-mode-17 | 2 + tests/ref/fate/filter-removegrain-mode-18 | 2 + tests/ref/fate/filter-removegrain-mode-19 | 2 + tests/ref/fate/filter-removegrain-mode-20 | 2 + tests/ref/fate/filter-removegrain-mode-21 | 2 + tests/ref/fate/filter-removegrain-mode-22 | 2 + tests/ref/fate/filter-removegrain-mode-23 | 2 + tests/ref/fate/filter-removegrain-mode-24 | 2 + 26 files changed, 128 insertions(+) create mode 100644 tests/ref/fate/filter-removegrain-mode-00 create mode 100644 tests/ref/fate/filter-removegrain-mode-01 create mode 100644 tests/ref/fate/filter-removegrain-mode-02 create mode 100644 tests/ref/fate/filter-removegrain-mode-03 create mode 100644 tests/ref/fate/filter-removegrain-mode-04 create mode 100644 tests/ref/fate/filter-removegrain-mode-05 create mode 100644 tests/ref/fate/filter-removegrain-mode-06 create mode 100644 tests/ref/fate/filter-removegrain-mode-07 create mode 100644 tests/ref/fate/filter-removegrain-mode-08 create mode 100644 tests/ref/fate/filter-removegrain-mode-09 create mode 100644 tests/ref/fate/filter-removegrain-mode-10 create mode 100644 tests/ref/fate/filter-removegrain-mode-11 create mode 100644 tests/ref/fate/filter-removegrain-mode-12 create mode 100644 tests/ref/fate/filter-removegrain-mode-13 create mode 100644 tests/ref/fate/filter-removegrain-mode-14 create mode 100644 tests/ref/fate/filter-removegrain-mode-15 create mode 100644 tests/ref/fate/filter-removegrain-mode-16 create mode 100644 tests/ref/fate/filter-removegrain-mode-17 create mode 100644 tests/ref/fate/filter-removegrain-mode-18 create mode 100644 tests/ref/fate/filter-removegrain-mode-19 create mode 100644 tests/ref/fate/filter-removegrain-mode-20 create mode 100644 tests/ref/fate/filter-removegrain-mode-21 create mode 100644 tests/ref/fate/filter-removegrain-mode-22 create mode 100644 tests/ref/fate/filter-removegrain-mode-23 create mode 100644 tests/ref/fate/filter-removegrain-mode-24 diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index f502c45..87af23b 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -129,6 +129,84 @@ fate-filter-overlay_yuv444: CMD = framecrc -c:v pgmyuv -i $(SRC) -filter_complex FATE_FILTER_VSYNTH-$(CONFIG_PHASE_FILTER) += fate-filter-phase fate-filter-phase: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf phase +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-00 +fate-filter-removegrain-mode-00: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=0:0:0 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-01 +fate-filter-removegrain-mode-01: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=1:1:1 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-02 +fate-filter-removegrain-mode-02: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=2:2:2 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-03 +fate-filter-removegrain-mode-03: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=3:3:3 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-04 +fate-filter-removegrain-mode-04: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=4:4:4 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-05 +fate-filter-removegrain-mode-05: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=5:5:5 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-06 +fate-filter-removegrain-mode-06: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=6:6:6 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-07 +fate-filter-removegrain-mode-07: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=7:7:7 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-08 +fate-filter-removegrain-mode-08: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=8:8:8 + +FATE_REMOVEGRAIN += fate-filter-removegrain-mode-09 +fate-filter-removegrain-mode-09: CMD = framecrc -c:v pgmyuv -i $(SRC) -vframes 1 -vf removegrain=9:9:9 + +FATE_REMOVEGRAIN +=
[FFmpeg-devel] [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with mmi
From 86f901e61532d3c06dbd93e15d47a66b119c44f8 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong zhouxiaoy...@loongson.cn
Date: Thu, 9 Jul 2015 14:34:21 +0800
Subject: [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with
mmi
Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/mpegvideo_init_mips.c | 14 ++
libavcodec/mips/mpegvideo_mips.h | 35
libavcodec/mips/mpegvideo_mmi.c | 303 ++
4 files changed, 353 insertions(+)
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index c16c93a..9eb815a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -59,3 +59,4 @@ MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
MMI-OBJS-$(CONFIG_H264PRED) += mips/h264pred_mmi.o
+MMI-OBJS-$(CONFIG_MPEGVIDEO) += mips/mpegvideo_mmi.o
diff --git a/libavcodec/mips/mpegvideo_init_mips.c
b/libavcodec/mips/mpegvideo_init_mips.c
index ee14b31..85a833c 100644
--- a/libavcodec/mips/mpegvideo_init_mips.c
+++ b/libavcodec/mips/mpegvideo_init_mips.c
@@ -19,6 +19,7 @@
*/
#include h263dsp_mips.h
+#include mpegvideo_mips.h
#if HAVE_MSA
static av_cold void dct_unquantize_init_msa(MpegEncContext *s)
@@ -29,9 +30,22 @@ static av_cold void dct_unquantize_init_msa(MpegEncContext
*s)
}
#endif // #if HAVE_MSA
+#if HAVE_MMI
+static av_cold void dct_unquantize_init_mmi(MpegEncContext *s)
+{
+s-dct_unquantize_h263_intra = ff_dct_unquantize_h263_intra_mmi;
+s-dct_unquantize_h263_inter = ff_dct_unquantize_h263_inter_mmi;
+s-dct_unquantize_mpeg1_intra = ff_dct_unquantize_mpeg1_intra_mmi;
+s-dct_unquantize_mpeg1_inter = ff_dct_unquantize_mpeg1_inter_mmi;
+}
+#endif /* HAVE_MMI */
+
av_cold void ff_mpv_common_init_mips(MpegEncContext *s)
{
#if HAVE_MSA
dct_unquantize_init_msa(s);
#endif // #if HAVE_MSA
+#if HAVE_MMI
+dct_unquantize_init_mmi(s);
+#endif /* HAVE_MMI */
}
diff --git a/libavcodec/mips/mpegvideo_mips.h b/libavcodec/mips/mpegvideo_mips.h
new file mode 100644
index 000..dbcea6a
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mips.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong zhouxiaoy...@loongson.cn
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef MPEGVIDEO_MIPS_H
+#define MPEGVIDEO_MIPS_H
+
+#include libavcodec/mpegvideo.h
+
+void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_h263_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+
+#endif /* MPEGVIDEO_MIPS_H */
diff --git a/libavcodec/mips/mpegvideo_mmi.c b/libavcodec/mips/mpegvideo_mmi.c
new file mode 100644
index 000..b3d58bd
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mmi.c
@@ -0,0 +1,303 @@
+/*
+ * Loongson SIMD optimized mpegvideo
+ *
+ * Copyright (c) 2015 Loongson Technology Corporation Limited
+ * Copyright (c) 2015 Zhou Xiaoyong zhouxiaoy...@loongson.cn
+ *Zhang Shuangshuang zhangshuangshu...@ict.ac.cn
+ *
+ * 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 mpegvideo_mips.h
+
+void
[FFmpeg-devel] [PATCH 1/2] avcodec: loongson optimized h264pred with mmi
Hi, Michael.
did you install the new FC21 and is there any problem when installing?
the installation maybe freted, but worth.
i add .set arch=loongson3a for last h264pred patch to pass compiling on
FC19-O32, and fate success in both FC19-O32 and FC21-N64.
i think it's ok to use .set arch=loongson3a to bypass using dli in
O32-system, as
these codes only for loongson3 cpu, and 3A, 3B use same option
-march=loongson3a to enable mmi.
---
From f378ba9b5d15495f8fcb93e049ee3538b744ecba Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong zhouxiaoy...@loongson.cn
Date: Thu, 9 Jul 2015 10:59:12 +0800
Subject: [PATCH 1/2] avcodec: loongson optimized h264pred with mmi
Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/h264pred_init_mips.c | 53 +++
libavcodec/mips/h264pred_mips.h | 53 +++
libavcodec/mips/h264pred_mmi.c | 804 +++
4 files changed, 911 insertions(+)
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 5569a03..c16c93a 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -58,3 +58,4 @@ MSA-OBJS-$(CONFIG_MPEGVIDEOENC) +=
mips/mpegvideoencdsp_msa.o
MSA-OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_msa.o
MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
+MMI-OBJS-$(CONFIG_H264PRED) += mips/h264pred_mmi.o
diff --git a/libavcodec/mips/h264pred_init_mips.c
b/libavcodec/mips/h264pred_init_mips.c
index 27ff10f..a2124ec 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *Zhou Xiaoyong zhouxiaoy...@loongson.cn
*
* This file is part of FFmpeg.
*
@@ -20,6 +21,7 @@
#include config.h
#include h264dsp_mips.h
+#include h264pred_mips.h
#if HAVE_MSA
static av_cold void h264_pred_init_msa(H264PredContext *h, int codec_id,
@@ -94,6 +96,54 @@ static av_cold void h264_pred_init_msa(H264PredContext *h,
int codec_id,
}
#endif // #if HAVE_MSA
+#if HAVE_MMI
+static av_cold void h264_pred_init_mmi(H264PredContext *h, int codec_id,
+const int bit_depth, const int chroma_format_idc)
+{
+if (bit_depth == 8) {
+if (chroma_format_idc == 1) {
+h-pred8x8 [VERT_PRED8x8 ] = ff_pred8x8_vertical_8_mmi;
+h-pred8x8 [HOR_PRED8x8] = ff_pred8x8_horizontal_8_mmi;
+} else {
+h-pred8x8 [VERT_PRED8x8 ] = ff_pred8x16_vertical_8_mmi;
+h-pred8x8 [HOR_PRED8x8] = ff_pred8x16_horizontal_8_mmi;
+}
+
+h-pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_8_mmi;
+h-pred16x16[VERT_PRED8x8 ] = ff_pred16x16_vertical_8_mmi;
+h-pred16x16[HOR_PRED8x8] = ff_pred16x16_horizontal_8_mmi;
+h-pred8x8l [TOP_DC_PRED] = ff_pred8x8l_top_dc_8_mmi;
+h-pred8x8l [DC_PRED] = ff_pred8x8l_dc_8_mmi;
+h-pred8x8l [HOR_PRED ] = ff_pred8x8l_horizontal_8_mmi;
+
+switch (codec_id) {
+case AV_CODEC_ID_SVQ3:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_svq3_8_mmi;
+;
+break;
+case AV_CODEC_ID_RV40:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_rv40_8_mmi;
+;
+break;
+case AV_CODEC_ID_VP7:
+case AV_CODEC_ID_VP8:
+;
+break;
+default:
+h-pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_plane_h264_8_mmi;
+break;
+}
+
+if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) {
+if (chroma_format_idc == 1) {
+h-pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_8_mmi;
+h-pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_8_mmi;
+}
+}
+}
+}
+#endif /* HAVE_MMI */
+
av_cold void ff_h264_pred_init_mips(H264PredContext *h, int codec_id,
int bit_depth,
const int chroma_format_idc)
@@ -101,4 +151,7 @@ av_cold void ff_h264_pred_init_mips(H264PredContext *h, int
codec_id,
#if HAVE_MSA
h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
#endif // #if HAVE_MSA
+#if HAVE_MMI
+h264_pred_init_mmi(h, codec_id, bit_depth, chroma_format_idc);
+#endif /* HAVE_MMI */
}
diff --git a/libavcodec/mips/h264pred_mips.h b/libavcodec/mips/h264pred_mips.h
new file mode 100644
index 000..16bf6fc
--- /dev/null
+++ b/libavcodec/mips/h264pred_mips.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong zhouxiaoy...@loongson.cn
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Do not check the table number before warning about the precision
On Thu, Jul 09, 2015 at 01:26:23AM +0200, Carl Eugen Hoyos wrote: Hi! Imo, the precision check in rtpenc_jpeg.c is wrong: Only the upper four bits contain the precision, the lower four bits are the table number. Please review, Carl Eugen LGTM [...] -- 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] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables
Carl Eugen Hoyos cehoyos at ag.or.at writes: +break; break removed locally. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout
On Tue, 7 Jul 2015 03:06:24 -0300
James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/libdcadec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 4bc3765..796826e 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -36,6 +36,8 @@ typedef struct DCADecContext {
int buffer_size;
} DCADecContext;
+static int downmix_warned = 0;
+
static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
void *data,
if (exss = dcadec_context_get_exss_info(s-ctx)) {
enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+if (!downmix_warned) {
+uint64_t layout = avctx-request_channel_layout;
+
+if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout ==
AV_CH_LAYOUT_STEREO) !exss-embedded_stereo) ||
+( layout == AV_CH_LAYOUT_5POINT1 !exss-embedded_6ch))
+av_log(avctx, AV_LOG_WARNING, %s downmix was requested but
no custom coefficients are available,
+ this may result in
clipping\n,
+ layout == AV_CH_LAYOUT_5POINT1
? 5.1 : stereo);
+downmix_warned = 1;
+}
+
What does this mean? Does this happen with FFmpeg's DCA decoder too?
switch(exss-matrix_encoding) {
case DCADEC_MATRIX_ENCODING_SURROUND:
matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
@@ -195,6 +208,27 @@ static av_cold int dcadec_init(AVCodecContext *avctx)
if (avctx-flags CODEC_FLAG_BITEXACT)
flags |= DCADEC_FLAG_CORE_BIT_EXACT;
+if (avctx-request_channel_layout 0 avctx-request_channel_layout
!= AV_CH_LAYOUT_NATIVE) {
+switch (avctx-request_channel_layout) {
+case AV_CH_LAYOUT_STEREO:
+case AV_CH_LAYOUT_STEREO_DOWNMIX:
+/* libdcadec ignores the 2ch flag if used alone when no custom
downmix coefficients
+ are available, silently outputting a 5.1 downmix if possible
instead.
+ Using both the 2ch and 6ch flags together forces a 2ch
downmix using default
+ coefficients in such cases. This matches the behavior of the
6ch flag when used
+ alone, where a 5.1 downmix is generated if possible,
regardless of custom
+ coefficients being available or not. */
+flags |= DCADEC_FLAG_KEEP_DMIX_2CH | DCADEC_FLAG_KEEP_DMIX_6CH;
+break;
+case AV_CH_LAYOUT_5POINT1:
+flags |= DCADEC_FLAG_KEEP_DMIX_6CH;
+break;
+default:
+av_log(avctx, AV_LOG_WARNING, Invalid
request_channel_layout\n);
+break;
+}
+}
+
s-ctx = dcadec_context_create(flags);
if (!s-ctx)
return AVERROR(ENOMEM);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout
On Thu, Jul 9, 2015 at 1:32 PM, wm4 nfx...@googlemail.com wrote:
On Tue, 7 Jul 2015 03:06:24 -0300
James Almer jamr...@gmail.com wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/libdcadec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 4bc3765..796826e 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -36,6 +36,8 @@ typedef struct DCADecContext {
int buffer_size;
} DCADecContext;
+static int downmix_warned = 0;
+
static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
void *data,
if (exss = dcadec_context_get_exss_info(s-ctx)) {
enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+if (!downmix_warned) {
+uint64_t layout = avctx-request_channel_layout;
+
+if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout ==
AV_CH_LAYOUT_STEREO) !exss-embedded_stereo) ||
+( layout == AV_CH_LAYOUT_5POINT1 !exss-embedded_6ch))
+av_log(avctx, AV_LOG_WARNING, %s downmix was requested but
no custom coefficients are available,
+ this may result in
clipping\n,
+ layout ==
AV_CH_LAYOUT_5POINT1 ? 5.1 : stereo);
+downmix_warned = 1;
+}
+
What does this mean? Does this happen with FFmpeg's DCA decoder too?
It just means that the DCA stream has no embedded downmix
coefficients. It'll downmix using the default coeffs, which can mean
two things, 1) this was intended, and all is fine, 2) downmixing was
not considered, and it may clip.
Personally, I might like a mode where it would downmix if the coeffs
are available, and not downmix if not (so I can downmix clipping-safe
using av/swresample later).
The native decoder would have the same problem, but I don't know if it
even supports embedded downmixes properly.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying.
On Thu, Jul 09, 2015 at 02:24:43PM +0300, Ivan Uskov wrote: Hello All, There is another place into libavcodec/qsvenc.c where height may be aligned to 32 for the case when alignment to 16 is enough. It can be reason of superfluous frame copying. The attached patch does solve this issue. Please review. does not apply cleanly Applying: libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying. Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging libavcodec/qsvenc.h Auto-merging libavcodec/qsvenc.c CONFLICT (content): Merge conflict in libavcodec/qsvenc.c Failed to merge in the changes. Patch failed at 0001 libavcodec/qsvenc.c: Fix for too agressive height alignment during frame encoding which may be reason of superflous frame copying. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 idct functions
From: Shivraj Patil shivraj.pa...@imgtec.com
This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 idct functions in
new file vp9_idct_msa.c
Signed-off-by: Shivraj Patil shivraj.pa...@imgtec.com
---
libavcodec/mips/Makefile |3 +-
libavcodec/mips/vp9_idct_msa.c | 1811
libavcodec/mips/vp9dsp_init_mips.c | 24 +
libavcodec/mips/vp9dsp_mips.h | 29 +
4 files changed, 1866 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/mips/vp9_idct_msa.c
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 6d55a20..7dca55d 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -43,7 +43,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER) +=
mips/hevcdsp_msa.o\
mips/hevc_lpf_sao_msa.o \
mips/hevcpred_msa.o
MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
- mips/vp9_lpf_msa.o
+ mips/vp9_lpf_msa.o\
+ mips/vp9_idct_msa.o
MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
mips/h264idct_msa.o
MSA-OBJS-$(CONFIG_H264QPEL) += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_idct_msa.c b/libavcodec/mips/vp9_idct_msa.c
new file mode 100644
index 000..dad4b18
--- /dev/null
+++ b/libavcodec/mips/vp9_idct_msa.c
@@ -0,0 +1,1811 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 string.h
+#include libavcodec/vp9dsp.h
+#include libavutil/mips/generic_macros_msa.h
+#include vp9dsp_mips.h
+
+#define VP9_DCT_CONST_BITS 14
+
+static const int32_t cospi_1_64 = 16364;
+static const int32_t cospi_2_64 = 16305;
+static const int32_t cospi_3_64 = 16207;
+static const int32_t cospi_4_64 = 16069;
+static const int32_t cospi_5_64 = 15893;
+static const int32_t cospi_6_64 = 15679;
+static const int32_t cospi_7_64 = 15426;
+static const int32_t cospi_8_64 = 15137;
+static const int32_t cospi_9_64 = 14811;
+static const int32_t cospi_10_64 = 14449;
+static const int32_t cospi_11_64 = 14053;
+static const int32_t cospi_12_64 = 13623;
+static const int32_t cospi_13_64 = 13160;
+static const int32_t cospi_14_64 = 12665;
+static const int32_t cospi_15_64 = 12140;
+static const int32_t cospi_16_64 = 11585;
+static const int32_t cospi_17_64 = 11003;
+static const int32_t cospi_18_64 = 10394;
+static const int32_t cospi_19_64 = 9760;
+static const int32_t cospi_20_64 = 9102;
+static const int32_t cospi_21_64 = 8423;
+static const int32_t cospi_22_64 = 7723;
+static const int32_t cospi_23_64 = 7005;
+static const int32_t cospi_24_64 = 6270;
+static const int32_t cospi_25_64 = 5520;
+static const int32_t cospi_26_64 = 4756;
+static const int32_t cospi_27_64 = 3981;
+static const int32_t cospi_28_64 = 3196;
+static const int32_t cospi_29_64 = 2404;
+static const int32_t cospi_30_64 = 1606;
+static const int32_t cospi_31_64 = 804;
+
+static const int32_t sinpi_1_9 = 5283;
+static const int32_t sinpi_2_9 = 9929;
+static const int32_t sinpi_3_9 = 13377;
+static const int32_t sinpi_4_9 = 15212;
+
+#define VP9_DOTP_CONST_PAIR(reg0, reg1, cnst0, cnst1, out0, out1) \
+{ \
+v8i16 k0_m = __msa_fill_h(cnst0); \
+v4i32 s0_m, s1_m, s2_m, s3_m; \
+ \
+s0_m = (v4i32) __msa_fill_h(cnst1);\
+k0_m = __msa_ilvev_h((v8i16) s0_m, k0_m); \
+ \
+ILVRL_H2_SW((-reg1), reg0, s1_m, s0_m);\
+ILVRL_H2_SW(reg0, reg1, s3_m, s2_m); \
+DOTP_SH2_SW(s1_m, s0_m, k0_m, k0_m, s1_m, s0_m); \
+SRARI_W2_SW(s1_m, s0_m, VP9_DCT_CONST_BITS); \
+out0 = __msa_pckev_h((v8i16) s0_m, (v8i16) s1_m);
[FFmpeg-devel] [PATCH 2/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 lpf functions
From: Shivraj Patil shivraj.pa...@imgtec.com
This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 lpf functions in new
file vp9_lpf_msa.c
Signed-off-by: Shivraj Patil shivraj.pa...@imgtec.com
---
libavcodec/mips/Makefile|3 +-
libavcodec/mips/vp9_lpf_msa.c | 2503 +++
libavcodec/mips/vp9dsp_init_mips.c | 25 +
libavcodec/mips/vp9dsp_mips.h | 33 +
libavutil/mips/generic_macros_msa.h |3 +
5 files changed, 2566 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/mips/vp9_lpf_msa.c
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 0728d42..6d55a20 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -42,7 +42,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER) +=
mips/hevcdsp_msa.o\
mips/hevc_idct_msa.o \
mips/hevc_lpf_sao_msa.o \
mips/hevcpred_msa.o
-MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o
+MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
+ mips/vp9_lpf_msa.o
MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
mips/h264idct_msa.o
MSA-OBJS-$(CONFIG_H264QPEL) += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_lpf_msa.c b/libavcodec/mips/vp9_lpf_msa.c
new file mode 100644
index 000..067fd8c
--- /dev/null
+++ b/libavcodec/mips/vp9_lpf_msa.c
@@ -0,0 +1,2503 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 libavcodec/vp9dsp.h
+#include libavutil/mips/generic_macros_msa.h
+#include vp9dsp_mips.h
+
+#define VP9_LPF_FILTER4_8W(p1_in, p0_in, q0_in, q1_in, mask_in, hev_in, \
+ p1_out, p0_out, q0_out, q1_out) \
+{\
+v16i8 p1_m, p0_m, q0_m, q1_m, q0_sub_p0, filt_sign; \
+v16i8 filt, filt1, filt2, cnst4b, cnst3b;\
+v8i16 q0_sub_p0_r, filt_r, cnst3h; \
+ \
+p1_m = (v16i8) __msa_xori_b(p1_in, 0x80);\
+p0_m = (v16i8) __msa_xori_b(p0_in, 0x80);\
+q0_m = (v16i8) __msa_xori_b(q0_in, 0x80);\
+q1_m = (v16i8) __msa_xori_b(q1_in, 0x80);\
+ \
+filt = __msa_subs_s_b(p1_m, q1_m); \
+filt = filt (v16i8) hev_in;\
+q0_sub_p0 = q0_m - p0_m; \
+filt_sign = __msa_clti_s_b(filt, 0); \
+ \
+cnst3h = __msa_ldi_h(3); \
+q0_sub_p0_r = (v8i16) __msa_ilvr_b(q0_sub_p0, q0_sub_p0);\
+q0_sub_p0_r = __msa_dotp_s_h((v16i8) q0_sub_p0_r, (v16i8) cnst3h); \
+filt_r = (v8i16) __msa_ilvr_b(filt_sign, filt); \
+filt_r += q0_sub_p0_r; \
+filt_r = __msa_sat_s_h(filt_r, 7); \
+ \
+/* combine left and right part */\
+filt = __msa_pckev_b((v16i8) filt_r, (v16i8) filt_r);\
+ \
+filt = filt (v16i8) mask_in; \
+cnst4b = __msa_ldi_b(4); \
+filt1 = __msa_adds_s_b(filt, cnst4b);\
+filt1 = 3; \
+
[FFmpeg-devel] [PATCH 4/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 intra functions
From: Shivraj Patil shivraj.pa...@imgtec.com
This patch adds MSA (MIPS-SIMD-Arch) optimizations for VP9 intra functions in
new file vp9_intra_msa.c
Signed-off-by: Shivraj Patil shivraj.pa...@imgtec.com
---
libavcodec/mips/Makefile | 3 +-
libavcodec/mips/vp9_intra_msa.c| 880 +
libavcodec/mips/vp9dsp_init_mips.c | 23 +
libavcodec/mips/vp9dsp_mips.h | 73 +++
4 files changed, 978 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/mips/vp9_intra_msa.c
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 7dca55d..b71d2c4 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -44,7 +44,8 @@ MSA-OBJS-$(CONFIG_HEVC_DECODER) +=
mips/hevcdsp_msa.o\
mips/hevcpred_msa.o
MSA-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_msa.o \
mips/vp9_lpf_msa.o\
- mips/vp9_idct_msa.o
+ mips/vp9_idct_msa.o \
+ mips/vp9_intra_msa.o
MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o\
mips/h264idct_msa.o
MSA-OBJS-$(CONFIG_H264QPEL) += mips/h264qpel_msa.o
diff --git a/libavcodec/mips/vp9_intra_msa.c b/libavcodec/mips/vp9_intra_msa.c
new file mode 100644
index 000..e29e727
--- /dev/null
+++ b/libavcodec/mips/vp9_intra_msa.c
@@ -0,0 +1,880 @@
+/*
+ * Copyright (c) 2015 Shivraj Patil (shivraj.pa...@imgtec.com)
+ *
+ * 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 libavcodec/vp9dsp.h
+#include libavutil/mips/generic_macros_msa.h
+#include vp9dsp_mips.h
+
+#define IPRED_SUBS_UH2_UH(in0, in1, out0, out1) \
+{\
+out0 = __msa_subs_u_h(out0, in0);\
+out1 = __msa_subs_u_h(out1, in1);\
+}
+
+static void intra_predict_vert_4x4_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t src_data;
+
+src_data = LW(src);
+
+SW4(src_data, src_data, src_data, src_data, dst, dst_stride);
+}
+
+static void intra_predict_vert_8x8_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t row;
+uint32_t src_data1, src_data2;
+
+src_data1 = LW(src);
+src_data2 = LW(src + 4);
+
+for (row = 8; row--;) {
+SW(src_data1, dst);
+SW(src_data2, (dst + 4));
+dst += dst_stride;
+}
+}
+
+static void intra_predict_vert_16x16_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t row;
+v16u8 src0;
+
+src0 = LD_UB(src);
+
+for (row = 16; row--;) {
+ST_UB(src0, dst);
+dst += dst_stride;
+}
+}
+
+static void intra_predict_vert_32x32_msa(const uint8_t *src, uint8_t *dst,
+ int32_t dst_stride)
+{
+uint32_t row;
+v16u8 src1, src2;
+
+src1 = LD_UB(src);
+src2 = LD_UB(src + 16);
+
+for (row = 32; row--;) {
+ST_UB2(src1, src2, dst, 16);
+dst += dst_stride;
+}
+}
+
+static void intra_predict_horiz_4x4_msa(const uint8_t *src, int32_t src_stride,
+uint8_t *dst, int32_t dst_stride)
+{
+uint32_t out0, out1, out2, out3;
+
+out0 = src[0 * src_stride] * 0x01010101;
+out1 = src[1 * src_stride] * 0x01010101;
+out2 = src[2 * src_stride] * 0x01010101;
+out3 = src[3 * src_stride] * 0x01010101;
+
+SW4(out0, out1, out2, out3, dst, dst_stride);
+}
+
+static void intra_predict_horiz_8x8_msa(const uint8_t *src, int32_t src_stride,
+uint8_t *dst, int32_t dst_stride)
+{
+uint64_t out0, out1, out2, out3, out4, out5, out6, out7;
+
+out0 = src[0 * src_stride] * 0x0101010101010101;
+out1 = src[1 * src_stride] * 0x0101010101010101;
+out2 = src[2 * src_stride] * 0x0101010101010101;
+out3 = src[3 * src_stride] * 0x0101010101010101;
+out4 = src[4 * src_stride] *
Re: [FFmpeg-devel] [PATCH 01/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [1/4]
On Tue, Jun 30, 2015 at 11:53:03AM +0200, Nedeljko Babic wrote:
From: Jovan Zelincevic jovan.zelince...@imgtec.com
Move existing code to the new template files
Signed-off-by: Nedeljko Babic nedeljko.ba...@imgtec.com
---
libavcodec/aacdec.c| 3132
+---
libavcodec/{aacdec.c = aacdec_template.c} | 623 +---
libavcodec/cbrt_tablegen.c | 16 -
.../{cbrt_tablegen.c = cbrt_tablegen_template.c} |0
libavcodec/sinewin_tablegen.c | 25 -
...ewin_tablegen.c = sinewin_tablegen_template.c} |0
6 files changed, 97 insertions(+), 3699 deletions(-)
copy libavcodec/{aacdec.c = aacdec_template.c} (85%)
copy libavcodec/{cbrt_tablegen.c = cbrt_tablegen_template.c} (100%)
copy libavcodec/{sinewin_tablegen.c = sinewin_tablegen_template.c} (100%)
applied
btw, the diff would have had ~40% fewer added lines shown if done by
using git ... --patience
might make sense to use in the future
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 02/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/4]
On Tue, Jun 30, 2015 at 11:53:04AM +0200, Nedeljko Babic wrote:
From: Jovan Zelincevic jovan.zelince...@imgtec.com
Add fixed point implementation of functions for generating tables
Signed-off-by: Nedeljko Babic nedeljko.ba...@imgtec.com
---
libavcodec/aac.h | 23 +
libavcodec/aacdectab.h | 34 +-
libavcodec/aactab.c| 486
+
libavcodec/aactab.h| 4 +
.../{cbrt_tablegen.c = cbrt_fixed_tablegen.c} | 3 +
libavcodec/cbrt_tablegen.c | 3 +
libavcodec/cbrt_tablegen.h | 17 +-
libavcodec/cbrt_tablegen_template.c| 2 +-
libavcodec/sinewin.c | 1 +
libavcodec/sinewin.h | 20 +-
libavcodec/{sinewin.c = sinewin_fixed.c} | 1 +
...sinewin_tablegen.c = sinewin_fixed_tablegen.c} | 3 +
libavcodec/sinewin_tablegen.c | 3 +
libavcodec/sinewin_tablegen.h | 31 +-
libavcodec/sinewin_tablegen_template.c | 20 +-
libavcodec/tableprint.h| 2 +
16 files changed, 618 insertions(+), 35 deletions(-)
copy libavcodec/{cbrt_tablegen.c = cbrt_fixed_tablegen.c} (94%)
copy libavcodec/{sinewin.c = sinewin_fixed.c} (97%)
copy libavcodec/{sinewin_tablegen.c = sinewin_fixed_tablegen.c} (93%)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [3/4]
On Tue, Jun 30, 2015 at 11:53:05AM +0200, Nedeljko Babic wrote: From: Djordje Pesut djordje.pe...@imgtec.com Add fixed point implementation Signed-off-by: Nedeljko Babic nedeljko.ba...@imgtec.com --- libavcodec/aac.h | 80 ++-- libavcodec/aacdec.c | 5 + libavcodec/aacdec_fixed.c| 444 +++ libavcodec/aacdec_template.c | 421 libavcodec/mdct_template.c | 5 + 5 files changed, 809 insertions(+), 146 deletions(-) create mode 100644 libavcodec/aacdec_fixed.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- 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 04/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [4/4]
On Tue, Jun 30, 2015 at 11:53:06AM +0200, Nedeljko Babic wrote: From: Jovan Zelincevic jovan.zelince...@imgtec.com Build system modified There are several warnings occurring during build after this patch is applied. The cause of most of these warnings is in that some definitions needed here are logical part of sbr module and are added in later patches. When this patches are applied these warnings stop occurring. The only warning that is added here and is not fixed with later patches is warning that warns that type mismatch for table ff_aac_eld_window_480. The reason for this warning is in that ER AAC ELD 480 is not integrated in to the fixed point implementation at this moment and there is no fixed point version of this table. Signed-off-by: Nedeljko Babic nedeljko.ba...@imgtec.com --- configure | 1 + libavcodec/Makefile | 13 ++--- libavcodec/aacdec.c | 1 - libavcodec/aacdec_fixed.c | 1 - libavcodec/allcodecs.c| 1 + 5 files changed, 12 insertions(+), 5 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 Rare item - Common item with rare defect or maybe just a lie Professional - 'Toy' made in china, not functional except as doorstop Experts will know - The seller hopes you are not an expert signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] lavf/tcp: add tcp_accept
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/tcp.c | 18 ++
1 file changed, 18 insertions(+)
Changes since first version:
- Add av_assert0() check for sc-listen
- Add bitmask for s-flags in ffurl_alloc
- Use ff_accept() instead of accept()
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index f24cad2..6f5e175 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include avformat.h
+#include libavutil/avassert.h
#include libavutil/parseutils.h
#include libavutil/opt.h
#include libavutil/time.h
@@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
return ret;
}
+static int tcp_accept(URLContext *s, URLContext **c)
+{
+TCPContext *sc = s-priv_data;
+TCPContext *cc;
+int ret;
+av_assert0(sc-listen);
+if ((ret = ffurl_alloc(c, s-filename, s-flags AVIO_FLAG_READ_WRITE,
s-interrupt_callback)) 0)
+return ret;
Any reason to remove the other flags? Since it is not possible to add flags
on a context afterwards, setting the flags on the server to have them on the
clients is the most obvious solution. AVIO_FLAG_NONBLOCK does not work, but
AVIO_FLAG_DIRECT does and makes sense for network protocols.
+cc = (*c)-priv_data;
+ret = ff_accept(sc-fd, sc-listen_timeout, s);
+if (ret 0)
+return ff_neterrno();
+cc-fd = ret;
+return 0;
+}
+
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
@@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
URLProtocol ff_tcp_protocol = {
.name= tcp,
.url_open= tcp_open,
+.url_accept = tcp_accept,
.url_read= tcp_read,
.url_write = tcp_write,
.url_close = tcp_close,
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Error out for non-standard Huffman tables
On Thu, Jul 09, 2015 at 01:23:58PM +0200, Carl Eugen Hoyos wrote: Hi! RFC 2435 requires standard Huffman tables when sending (m)jpeg over rtp. Related to ticket #3823. Please comment, Carl Eugen rtpenc_jpeg.c | 21 + 1 file changed, 21 insertions(+) f72f54ec4c4d9fb7f8e61dbb4ce48cd5a492c05e patchrtpjpghuffman.diff diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c index 7ee26c4..e9d09e9 100644 --- a/libavformat/rtpenc_jpeg.c +++ b/libavformat/rtpenc_jpeg.c @@ -21,6 +21,7 @@ #include libavcodec/bytestream.h #include libavcodec/mjpeg.h +#include libavcodec/jpegtables.h #include libavutil/intreadwrite.h #include rtpenc.h @@ -81,6 +82,26 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t *buf, int size) Only 1x1 chroma blocks are supported. Aborted!\n); [...] + Only standard Huffman tables are supported\n); I think the error messages should be changed to say that RFC... doesnt allow stuff not that its not supported implying it could be supported [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/rtpenc_jpeg: Fix quantisation table handling
Hi!
Attached patch fixes jpeg over rtp if the encoder placed
quantisation tables into different DQT chunks.
Sample also attached.
Please review, Carl Eugen
diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 13d61a9..84aa66c 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -28,7 +28,7 @@
void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t *buf, int size)
{
RTPMuxContext *s = s1-priv_data;
-const uint8_t *qtables = NULL;
+const uint8_t *qtables[4] = { NULL };
int nb_qtables = 0;
uint8_t type;
uint8_t w, h;
@@ -64,18 +64,25 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t
*buf, int size)
continue;
if (buf[i + 1] == DQT) {
+int tables, j;
if (buf[i + 4] 0xF0)
av_log(s1, AV_LOG_WARNING,
Only 8-bit precision is supported.\n);
/* a quantization table is 64 bytes long */
-nb_qtables = AV_RB16(buf[i + 2]) / 65;
+tables = AV_RB16(buf[i + 2]) / 65;
if (i + 4 + nb_qtables * 65 size) {
av_log(s1, AV_LOG_ERROR, Too short JPEG header. Aborted!\n);
return;
}
+if (nb_qtables + tables 4) {
+av_log(s1, AV_LOG_ERROR, Invalid number of quantisation
tables\n);
+return;
+}
-qtables = buf[i + 4];
+for (j = 0; j tables; j++)
+qtables[nb_qtables + j] = buf + i + 5 + j * 65;
+nb_qtables += tables;
} else if (buf[i + 1] == SOF0) {
if (buf[i + 14] != 17 || buf[i + 17] != 17) {
av_log(s1, AV_LOG_ERROR,
@@ -150,7 +157,7 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t
*buf, int size)
bytestream_put_be16(p, 64 * nb_qtables);
for (i = 0; i nb_qtables; i++)
-bytestream_put_buffer(p, qtables[65 * i + 1], 64);
+bytestream_put_buffer(p, qtables[i], 64);
}
/* copy payload data */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement slice threading
Signed-off-by: Paul B Mahol one...@gmail.com
---
libavfilter/vf_stereo3d.c | 72 ---
1 file changed, 49 insertions(+), 23 deletions(-)
diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index 771bdde..18799d9 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -142,6 +142,7 @@ typedef struct Stereo3DContext {
int pixstep[4];
AVFrame *prev;
double ts_unit;
+int in_off_left[4], in_off_right[4];
} Stereo3DContext;
#define OFFSET(x) offsetof(Stereo3DContext, x)
@@ -485,6 +486,43 @@ static inline uint8_t ana_convert(const int *coeff, const
uint8_t *left, const u
return av_clip_uint8(sum 16);
}
+typedef struct ThreadData {
+Stereo3DContext *s;
+AVFrame *ileft, *iright;
+AVFrame *out;
+} ThreadData;
+
+static int filter_slice(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
+{
+ThreadData *td = arg;
+Stereo3DContext *s = td-s;
+AVFrame *ileft = td-ileft;
+AVFrame *iright = td-iright;
+AVFrame *out = td-out;
+int height = s-out.height;
+int start = (height * jobnr ) / nb_jobs;
+int end = (height * (jobnr+1)) / nb_jobs;
+uint8_t *dst = out-data[0];
+const int **ana_matrix = s-ana_matrix;
+int x, y, il, ir, o;
+const uint8_t *lsrc = ileft-data[0];
+const uint8_t *rsrc = iright-data[0];
+int out_width = s-out.width;
+
+for (y = start; y end; y++) {
+o = out-linesize[0] * y;
+il = s-in_off_left[0] + y * ileft-linesize[0];
+ir = s-in_off_right[0] + y * iright-linesize[0];
+for (x = 0; x out_width; x++, il += 3, ir += 3, o+= 3) {
+dst[o] = ana_convert(ana_matrix[0], lsrc + il, rsrc + ir);
+dst[o + 1] = ana_convert(ana_matrix[1], lsrc + il, rsrc + ir);
+dst[o + 2] = ana_convert(ana_matrix[2], lsrc + il, rsrc + ir);
+}
+}
+
+return 0;
+}
+
static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
{
AVFilterContext *ctx = inlink-dst;
@@ -492,7 +530,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*inpicref)
AVFilterLink *outlink = ctx-outputs[0];
AVFrame *out, *oleft, *oright, *ileft, *iright;
int out_off_left[4], out_off_right[4];
-int in_off_left[4], in_off_right[4];
int i;
switch (s-in.format) {
@@ -534,8 +571,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*inpicref)
for (i = 0; i 4; i++) {
int hsub = i == 1 || i == 2 ? s-hsub : 0;
int vsub = i == 1 || i == 2 ? s-vsub : 0;
-in_off_left[i] = (FF_CEIL_RSHIFT(s-in.row_left, vsub) +
s-in.off_lstep) * ileft-linesize[i] + FF_CEIL_RSHIFT(s-in.off_left *
s-pixstep[i], hsub);
-in_off_right[i] = (FF_CEIL_RSHIFT(s-in.row_right, vsub) +
s-in.off_rstep) * iright-linesize[i] + FF_CEIL_RSHIFT(s-in.off_right *
s-pixstep[i], hsub);
+s-in_off_left[i] = (FF_CEIL_RSHIFT(s-in.row_left, vsub) +
s-in.off_lstep) * ileft-linesize[i] + FF_CEIL_RSHIFT(s-in.off_left *
s-pixstep[i], hsub);
+s-in_off_right[i] = (FF_CEIL_RSHIFT(s-in.row_right, vsub) +
s-in.off_rstep) * iright-linesize[i] + FF_CEIL_RSHIFT(s-in.off_right *
s-pixstep[i], hsub);
out_off_left[i] = (FF_CEIL_RSHIFT(s-out.row_left, vsub) +
s-out.off_lstep) * oleft-linesize[i] + FF_CEIL_RSHIFT(s-out.off_left *
s-pixstep[i], hsub);
out_off_right[i] = (FF_CEIL_RSHIFT(s-out.row_right, vsub) +
s-out.off_rstep) * oright-linesize[i] + FF_CEIL_RSHIFT(s-out.off_right *
s-pixstep[i], hsub);
}
@@ -556,12 +593,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*inpicref)
for (i = 0; i s-nb_planes; i++) {
av_image_copy_plane(oleft-data[i] + out_off_left[i],
oleft-linesize[i] * s-row_step,
-ileft-data[i] + in_off_left[i],
+ileft-data[i] + s-in_off_left[i],
ileft-linesize[i] * s-row_step,
s-linesize[i], s-pheight[i]);
av_image_copy_plane(oright-data[i] + out_off_right[i],
oright-linesize[i] * s-row_step,
-iright-data[i] + in_off_right[i],
+iright-data[i] + s-in_off_right[i],
iright-linesize[i] * s-row_step,
s-linesize[i], s-pheight[i]);
}
@@ -571,7 +608,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*inpicref)
case MONO_R:
for (i = 0; i s-nb_planes; i++) {
av_image_copy_plane(out-data[i], out-linesize[i],
-iright-data[i] + in_off_left[i],
+iright-data[i] + s-in_off_left[i],
iright-linesize[i],
s-linesize[i], s-pheight[i]);
}
@@
Re: [FFmpeg-devel] [PATCH 7/9] lavf/http: increase range for listen, handle connection closing accordingly, add http_handshake and move handshake logic there
Le decadi 20 messidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/http.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
Changes since first version:
- Return from http_handshake() if no errors occured instead of falling
through
fail label
- Add av_assert0() check for error in handle_http_errors()
- Remove passthough if error == 0 (should never happen anymore)
Is it possible to use tcp_accept() without tcp_handshake()? If not, you
probably should merge patches 6 and 7.
diff --git a/libavformat/http.c b/libavformat/http.c
index 3c1ec35..813870e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -129,7 +129,7 @@ static const AVOption options[] = {
{ 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 },
{ 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, 1, D | E },
+{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 2, D | E },
{ NULL }
};
@@ -305,6 +305,7 @@ static void handle_http_errors(URLContext *h, int error)
static const char bad_request[] = HTTP/1.1 400 Bad
Request\r\nContent-Type: text/plain\r\n\r\n400 Bad Request\r\n;
static const char internal_server_error[] = HTTP/1.1 500 Internal
server error\r\nContent-Type: text/plain\r\n\r\n500 Internal server
error\r\n;
HTTPContext *s = h-priv_data;
+av_assert0(error 0);
if (h-is_connected) {
switch(error) {
case AVERROR_HTTP_BAD_REQUEST:
@@ -317,15 +318,33 @@ static void handle_http_errors(URLContext *h, int error)
}
}
+static int http_handshake(URLContext *c) {
Nit: inconsistent brace placement.
+int ret, err, new_location;
+HTTPContext *ch = c-priv_data;
+URLContext *cl = ch-hd;
+static const char header[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
+if ((ret = ffurl_handshake(cl)) 0)
+return ret;
+if ((err = http_read_header(c, new_location)) 0)
+goto fail;
+if ((ret = ffurl_write(cl, header, strlen(header))) 0)
+return ret;
+// Avoid returning a positive value from ffurl_write()
+ret = ret 0 ? 0 : ret;
+return ret;
+fail:
+handle_http_errors(c, err);
+return ret;
+}
+
static int http_listen(URLContext *h, const char *uri, int flags,
AVDictionary **options) {
HTTPContext *s = h-priv_data;
int ret;
-static const char header[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
char hostname[1024], proto[10];
char lower_url[100];
const char *lower_proto = tcp;
-int port, new_location;
+int port;
s-chunked_post = 1;
av_url_split(proto, sizeof(proto), NULL, 0, hostname, sizeof(hostname),
port,
NULL, 0, uri);
@@ -333,18 +352,14 @@ static int http_listen(URLContext *h, const char *uri,
int flags,
lower_proto = tls;
ff_url_join(lower_url, sizeof(lower_url), lower_proto, NULL, hostname,
port,
NULL);
-av_dict_set(options, listen, 1, 0);
+if ((ret = av_dict_set_int(options, listen, s-listen, 0)) 0)
+goto fail;
if ((ret = ffurl_open(s-hd, lower_url, AVIO_FLAG_READ_WRITE,
h-interrupt_callback, options)) 0)
goto fail;
-if ((ret = http_read_header(h, new_location)) 0)
- goto fail;
-if ((ret = ffurl_write(s-hd, header, strlen(header))) 0)
- goto fail;
-return 0;
-
+if (s-listen == 1) /* single client */
+ret = http_handshake(h);
fail:
-handle_http_errors(h, ret);
av_dict_free(s-chained_options);
return ret;
}
@@ -1365,6 +1380,8 @@ HTTP_CLASS(http);
URLProtocol ff_http_protocol = {
.name= http,
.url_open2 = http_open,
+.url_accept = http_accept,
+.url_handshake = http_handshake,
.url_read= http_read,
.url_write = http_write,
.url_seek= http_seek,
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] concatdec: add support for specifying outpoint of files
Le primidi 21 messidor, an CCXXIII, Marton Balint a écrit : I gave it a thought, and if we ensure that the decoding timestamp reaches outpoint instead of the presentation timestamp, can't we overcome the B-frame issue? It's a simple change and seems to do the right thing. I am not sure if it fixes all the issues (likely, with B-frames some issues just can not be solved at the muxer level), but I believe that in muxer, using DTS is almost always better than using PTS, so that should be good. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2
On Thu, Jul 09, 2015 at 08:16:29PM +0200, Andreas Cadhalpun wrote: On 08.07.2015 01:22, Michael Niedermayer wrote: On Tue, Jul 07, 2015 at 11:32:59PM +0200, Andreas Cadhalpun wrote: I think the assert is a historic leftover: Before commit cc884a35 src_stride 7*MB_SIZE was necessary, because the blocks were interleaved in the tmp buffer and the last block was added with an offset of 6*MB_SIZE. It was changed for src_stride = 7*MB_SIZE to write the blocks sequentially, hence the larger tmp_stride. (A comment about this in the code would have been nice.) yes, should i add one or you want to ? I added one to the patch. Updated version attached. Does that sound good? However, there are still some things in this code which are unclear for me: * Where does the 5 in 'src_stride 2*MB_SIZE + 5' come from? Shouldn't that have been HTAPS_MAX-1, because that is added to block_h, when calling emulated_edge_mc? * Why the factor 2 in 'src_stride 2*MB_SIZE + 5'? Before commit cc884a35 the buffer size was 'src_stride*(b_h+5)' and b_h is at maximum MB_SIZE, not 2*MB_SIZE. I dont remember trying to make the assert be exact just sufficient to detect problems, it was not intended to stay IIRC, so it would have been a waste of time to calculate exactly what the minimum size was also i think that we should only spend time on this investigation if we intend to work on the code. Its hardly worth for just removing the apparently unneeded assert. if you want to improve snow (the algorithm or implementation) then investigating every smal bit does make sense OK. * Why is tmp_step based on MB_SIZE and not (MB_SIZE + HTAPS_MAX-1)? This 'HTAPS_MAX-1' is added to b_w/b_h when calling emulated_edge_mc. to keep things aligned in memory, it may help or be required for SIMD use I suppose that's correct then. Best regards, Andreas snow.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 62ba6bae883891f9953478d52d591e5f16aa759e 0001-snow-remove-an-obsolete-av_assert2.patch From 7747ec5a7e319c05e28c6988caa84ad1f37fd301 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Thu, 9 Jul 2015 19:50:34 +0200 Subject: [PATCH] snow: remove an obsolete av_assert2 It asserts that the frame linesize is larger than 37, but it can be smaller and decoding such frames works. Before commit cc884a35 src_stride 7*MB_SIZE was necessary, because the blocks were interleaved in the tmp buffer and the last block was added with an offset of 6*MB_SIZE. It was changed for src_stride = 7*MB_SIZE to write the blocks sequentially, hence the larger tmp_step. After that the assert was only necessary to make sure that the buffer remained large enough. Since commit bd2b6b33 s-scratchbuf is used as tmp buffer. As part of commit 86e107a7 the minimal scratchbuf size was increased to 256*7*MB_SIZE, which is enough for any src_stride = 7*MB_SIZE. Also add a comment explaining the tmp_step calculation. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/utils: use a minimum 32pixel width in avcodec_align_dimensions2() for H.264
Fixes Assertion failure
Found-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/utils.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 96f177d..925b3ed 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -428,10 +428,12 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
*width, int *height,
*width = FFALIGN(*width, w_align);
*height = FFALIGN(*height, h_align);
-if (s-codec_id == AV_CODEC_ID_H264 || s-lowres)
+if (s-codec_id == AV_CODEC_ID_H264 || s-lowres) {
// some of the optimized chroma MC reads one line too much
// which is also done in mpeg decoders with lowres 0
*height += 2;
+*width = FFMAX(*width, 32);
+}
for (i = 0; i 4; i++)
linesize_align[i] = STRIDE_ALIGN;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] snow: remove strange av_assert2
On Thu, Jul 09, 2015 at 08:24:52PM +0200, Andreas Cadhalpun wrote: On 08.07.2015 18:07, Michael Niedermayer wrote: On Wed, Jul 08, 2015 at 07:24:13AM -0400, Ronald S. Bultje wrote: - last of all, I want to remind you guys that we haven't done a very thorough code analysis to see if this can actually be triggered. As an example, look at commit 458446acfa1441d283dacf9e6e545beb083b8bb0. Before that, vp8 files smaller than 16x16 or vp9 files smaller than 64x64 could cause aborts. The vp9 ones I noticed due to some fate files being so small. I doubt you'll ever find such vp8 files, but they're valid. Let's not add silly checks to replace other silly ones. Do you have any vp9 files triggering this assert? if people prefer i ca revert b8c438e7623644edcfdb508c946a723a3b79b893 or add a check for stride == 0 what do people prefer ? The assert can be triggered by the h264 decoder: mc_dir_part in libavcodec/h264_mb.c calls the 16 bit variant of emulated_edge_mc and thus the assert is triggered due to the sizeof(pixel) factor, even though block_w is smaller than buf_linesize. If that's valid behavior of the h264 decoder, then the assert should be removed, but if on the other hand this is a bug in the h264 decoder, then that should be fixed and the assert remain. just posted a patch which should fix these assertion failures [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- 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] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync
On Thu, Jul 09, 2015 at 10:10:17PM +0300, Ivan Uskov wrote: Hello All, Current implementation of handling MFXVideoENCODE_EncodeFrameAsync() return codes allows unhanded silent warnings and unclear error reporting if the function return some non-successful code. The attached patch solves this issue and makes troubleshooting more easy. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com qsvenc.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) ea4b9e9cb073156b0fa4f7ffa4fc4c32c43ab0a1 0001-libavcodec-qsvenc.c-improving-handling-for-return-co.patch From 0b2b547325821ace205ddfbecad13d56cd21ca7b Mon Sep 17 00:00:00 2001 From: Ivan Uskov ivan.us...@nablet.com Date: Thu, 9 Jul 2015 22:01:00 +0300 Subject: [PATCH] libavcodec/qsvenc.c: improving handling for return codes of MFXVideoENCODE_EncodeFrameAsync applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
