Re: [FFmpeg-devel] [PATCH 01/23] avcodec: add color_range to AVCodec struct and use it

2017-12-12 Thread Michael Niedermayer
On Tue, Dec 12, 2017 at 02:55:59PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/avcodec.h | 1 +
>  libavcodec/utils.c   | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..df715fd5ee 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>  uint8_t max_lowres; ///< maximum value for lowres 
> supported by the decoder
>  const AVClass *priv_class;  ///< AVClass for the private 
> context
>  const AVProfile *profiles;  ///< array of recognized 
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +const enum AVColorRange *color_ranges;  ///< array of supported color 
> ranges by encoder, or  NULL if unknown, array is terminated by -1
>  
>  /*
>   * No fields below this line are part of the public API. They
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 873f39f9bd..41cc6fbf2c 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
>  avctx->color_range = AVCOL_RANGE_JPEG;
>  }
> +if (avctx->codec->color_range)
> +avctx->color_range = avctx->codec->color_range;

This doesnt build, i can thus not easily bisect some fate failure:

libavcodec/utils.c: In function ‘avcodec_open2’:
libavcodec/utils.c:882:25: error: ‘const struct AVCodec’ has no member named 
‘color_range’
 if (avctx->codec->color_range)
 ^
libavcodec/utils.c:883:46: error: ‘const struct AVCodec’ has no member named 
‘color_range’
 avctx->color_range = avctx->codec->color_range;


[...]

 #dimensions 0: 128x128
-#sar 0: 72/72
+#sar 0: 1/1
 0,  0,  0,1,49152, 0xe0013dee
Test png-rgb24 failed. Look at tests/data/fate/png-rgb24.err for details.
make: *** [fate-png-rgb24] Error 1
TESTpsd-rgba
TESTpsd-rgba64
TESTpsd-ya8
TESTpsd-ya16
--- ./tests/ref/fate/png-int-rgb24  2017-12-13 00:39:32.256314963 +0100
--
 #dimensions 0: 128x128
-#sar 0: 2835/2835
+#sar 0: 1/1
 0,  0,  0,1,49152, 0xe0013dee
Test png-int-rgb24 failed. Look at tests/data/fate/png-int-rgb24.err for 
details.
make: *** [fate-png-int-rgb24] Error 1
TESTpsd-lena-127x127-rgb24
TESTpsd-lena-rgb-rle-127x127-16b
TESTpsd-lena-rgb-rle-127x127-8b
TESTpsd-lena-rgba-rle-128x128-8b
TESTpsd-lena-256c
--
 0,  0,  0,1, 1600, 0x01a481a9
 0,  1,  1,1, 1600, 0x01a481a9
 0,  2,  2,1, 1600, 0x01a481a9
TESTlossless-alac
Test pngparser failed. Look at tests/data/fate/pngparser.err for details.
make: *** [fate-pngparser] Error 1
TESTlossless-meridianaudio
TESTralf
TESTlossless-shorten
TESTlossless-tak
TESTlossless-truehd-5.1


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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


Re: [FFmpeg-devel] [PATCH v2] libavcodec/mpegvideo_parser: improve detection of progressive mpeg2

2017-12-12 Thread Aman Gupta
On Fri, Dec 8, 2017 at 9:10 AM, Michael Niedermayer 
wrote:

> On Thu, Dec 07, 2017 at 04:05:15PM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > Previously many progressive mpeg2video samples were detected as
> interlaced
> > by ffmpeg/ffprobe. For example, https://tmm1.s3.amazonaws.com/720p.ts
> >
> > Before:
> >
> > Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
> >   Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
> >   Program 2
> >   Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv, bottom
> first), 1280x720 ...
> >
> > After:
> >
> > Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
> >   Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
> >   Program 2
> >   Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv,
> progressive), 1280x720 ...
>
> commit message sounds ok
> no more comments from me, please wait a bit with applying so others
> can comment too
>

Applied. Thanks for the review.

Aman


>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The greatest way to live with honor in this world is to be what we pretend
> to be. -- Socrates
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2 4/5] avformat/hls: allow open_input to be re-used

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

---
 libavformat/hls.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 5c1895c180..f75c8f5eaa 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1145,7 +1145,7 @@ static void intercept_id3(struct playlist *pls, uint8_t 
*buf,
 pls->is_id3_timestamped = (pls->id3_mpegts_timestamp != 
AV_NOPTS_VALUE);
 }
 
-static int open_input(HLSContext *c, struct playlist *pls, struct segment *seg)
+static int open_input(HLSContext *c, struct playlist *pls, struct segment 
*seg, AVIOContext **in)
 {
 AVDictionary *opts = NULL;
 int ret;
@@ -1172,7 +1172,7 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg)
seg->url, seg->url_offset, pls->index);
 
 if (seg->key_type == KEY_NONE) {
-ret = open_url(pls->parent, >input, seg->url, c->avio_opts, opts, 
_http);
+ret = open_url(pls->parent, in, seg->url, c->avio_opts, opts, 
_http);
 } else if (seg->key_type == KEY_AES_128) {
 AVDictionary *opts2 = NULL;
 char iv[33], key[33], url[MAX_URL_SIZE];
@@ -1203,7 +1203,7 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg)
 av_dict_set(, "key", key, 0);
 av_dict_set(, "iv", iv, 0);
 
-ret = open_url(pls->parent, >input, url, opts2, opts, _http);
+ret = open_url(pls->parent, in, url, opts2, opts, _http);
 
 av_dict_free();
 
@@ -1230,11 +1230,11 @@ static int open_input(HLSContext *c, struct playlist 
*pls, struct segment *seg)
  * noticed without the call, though.
  */
 if (ret == 0 && !is_http && seg->key_type == KEY_NONE && seg->url_offset) {
-int64_t seekret = avio_seek(pls->input, seg->url_offset, SEEK_SET);
+int64_t seekret = avio_seek(*in, seg->url_offset, SEEK_SET);
 if (seekret < 0) {
 av_log(pls->parent, AV_LOG_ERROR, "Unable to seek to offset 
%"PRId64" of HLS segment '%s'\n", seg->url_offset, seg->url);
 ret = seekret;
-ff_format_io_close(pls->parent, >input);
+ff_format_io_close(pls->parent, in);
 }
 }
 
@@ -1260,7 +1260,7 @@ static int update_init_section(struct playlist *pls, 
struct segment *seg)
 if (!seg->init_section)
 return 0;
 
-ret = open_input(c, pls, seg->init_section);
+ret = open_input(c, pls, seg->init_section, >input);
 if (ret < 0) {
 av_log(pls->parent, AV_LOG_WARNING,
"Failed to open an initialization section in playlist %d\n",
@@ -1426,7 +1426,7 @@ reload:
 if (ret)
 return ret;
 
-ret = open_input(c, v, seg);
+ret = open_input(c, v, seg, >input);
 if (ret < 0) {
 if (ff_check_interrupt(c->interrupt_callback))
 return AVERROR_EXIT;
-- 
2.14.3 (Apple Git-98)

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


[FFmpeg-devel] [PATCH v2 3/5] avformat/hls: add http_persistent option

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

This teaches the HLS demuxer to use the HTTP protocols
multiple_requests=1 option, to take advantage of "Connection:
Keep-Alive" when downloading playlists and segments from the HLS server.

With the new option, you can avoid TCP connection and TLS negotiation
overhead, which is particularly beneficial when streaming via a
high-latency internet connection.

Similar to the http_persistent option recently implemented in hlsenc.c
---
 doc/demuxers.texi |  3 +++
 libavformat/hls.c | 68 +++
 2 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..18ff7101ac 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -316,6 +316,9 @@ segment index to start live streams at (negative values are 
from the end).
 @item max_reload
 Maximum number of times a insufficient list is attempted to be reloaded.
 Default value is 1000.
+
+@item http_persistent
+Use persistent HTTP connections. Applicable only for HTTP streams.
 @end table
 
 @section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ab6ff187a6..5c1895c180 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -26,6 +26,7 @@
  * http://tools.ietf.org/html/draft-pantos-http-live-streaming
  */
 
+#include "libavformat/http.h"
 #include "libavutil/avstring.h"
 #include "libavutil/avassert.h"
 #include "libavutil/intreadwrite.h"
@@ -94,6 +95,7 @@ struct playlist {
 AVIOContext pb;
 uint8_t* read_buffer;
 AVIOContext *input;
+int input_read_done;
 AVFormatContext *parent;
 int index;
 AVFormatContext *ctx;
@@ -206,6 +208,8 @@ typedef struct HLSContext {
 int strict_std_compliance;
 char *allowed_extensions;
 int max_reload;
+int http_persistent;
+AVIOContext *playlist_pb;
 } HLSContext;
 
 static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
@@ -256,6 +260,7 @@ static void free_playlist_list(HLSContext *c)
 av_freep(>pb.buffer);
 if (pls->input)
 ff_format_io_close(c->ctx, >input);
+pls->input_read_done = 0;
 if (pls->ctx) {
 pls->ctx->pb = NULL;
 avformat_close_input(>ctx);
@@ -640,7 +645,24 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+if (c->http_persistent && *pb && av_strstart(proto_name, "http", NULL)) {
+URLContext *uc = ffio_geturlcontext(*pb);
+av_assert0(uc);
+(*pb)->eof_reached = 0;
+ret = ff_http_do_new_request(uc, url);
+if (ret == AVERROR_EXIT) {
+ff_format_io_close(c->ctx, >playlist_pb);
+return ret;
+} else if (ret < 0) {
+av_log(s, AV_LOG_WARNING,
+"keepalive request failed for '%s', retrying with new 
connection: %s\n",
+url, av_err2str(ret));
+ff_format_io_close(c->ctx, pb);
+ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+}
+} else {
+ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+}
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -683,10 +705,27 @@ static int parse_playlist(HLSContext *c, const char *url,
 char tmp_str[MAX_URL_SIZE];
 struct segment *cur_init_section = NULL;
 
+if (!in && c->http_persistent && c->playlist_pb) {
+in = c->playlist_pb;
+URLContext *uc = ffio_geturlcontext(in);
+av_assert0(uc);
+in->eof_reached = 0;
+ret = ff_http_do_new_request(uc, url);
+if (ret == AVERROR_EXIT) {
+ff_format_io_close(c->ctx, >playlist_pb);
+return ret;
+} else if (ret < 0) {
+av_log(c->ctx, AV_LOG_WARNING,
+"keepalive request failed for '%s', retrying with new 
connection: %s\n",
+url, av_err2str(ret));
+ff_format_io_close(c->ctx, >playlist_pb);
+in = NULL;
+}
+}
+
 if (!in) {
 #if 1
 AVDictionary *opts = NULL;
-close_in = 1;
 /* Some HLS servers don't like being sent the range header */
 av_dict_set(, "seekable", "0", 0);
 
@@ -696,10 +735,18 @@ static int parse_playlist(HLSContext *c, const char *url,
 av_dict_set(, "headers", c->headers, 0);
 av_dict_set(, "http_proxy", c->http_proxy, 0);
 
+if (c->http_persistent)
+av_dict_set(, "multiple_requests", "1", 0);
+
 ret = c->ctx->io_open(c->ctx, , url, AVIO_FLAG_READ, );
 av_dict_free();
 if (ret < 0)
 return ret;
+
+if (c->http_persistent)
+c->playlist_pb = in;
+else
+close_in = 1;
 #else
 ret = open_in(c, , url);
 if (ret < 0)
@@ -,6 +1158,9 

[FFmpeg-devel] [PATCH v2 5/5] avformat/hls: add http_multiple option

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

This improves network throughput of the hls demuxer by avoiding
the latency introduced by downloading segments one at a time.

The problem is particularly noticable over high-latency network
connections: for instance, if RTT is 250ms, there will a 250ms idle
period between when one segment response is read and the next one
starts.

The obvious solution to this is to use HTTP pipelining, where a
second request can be sent (on the persistent http/1.1 connection)
before the first response is fully read. Unfortunately the way the
http protocol is implemented in avformat makes implementing pipleining
very complex.

Instead, this commit simulates pipelining using two separate persistent
http connections. This has the advantage of working independently of
the http_persistent option, and can be used with http/1.0 servers as
well. The pair of connections is swapped every time a new segment starts
downloading, and a request for the next segment is sent on the secondary
connection right away. This means the second response will be ready and
waiting by the time the current response is fully read.
---
 doc/demuxers.texi |  3 +++
 libavformat/hls.c | 51 ---
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 18ff7101ac..f2181fbb93 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -319,6 +319,9 @@ Default value is 1000.
 
 @item http_persistent
 Use persistent HTTP connections. Applicable only for HTTP streams.
+
+@item http_multiple
+Use multiple HTTP connections for downloading HTTP segments.
 @end table
 
 @section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f75c8f5eaa..487fa9a82f 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -96,6 +96,8 @@ struct playlist {
 uint8_t* read_buffer;
 AVIOContext *input;
 int input_read_done;
+AVIOContext *input_next;
+int input_next_requested;
 AVFormatContext *parent;
 int index;
 AVFormatContext *ctx;
@@ -209,6 +211,7 @@ typedef struct HLSContext {
 char *allowed_extensions;
 int max_reload;
 int http_persistent;
+int http_multiple;
 AVIOContext *playlist_pb;
 } HLSContext;
 
@@ -261,6 +264,9 @@ static void free_playlist_list(HLSContext *c)
 if (pls->input)
 ff_format_io_close(c->ctx, >input);
 pls->input_read_done = 0;
+if (pls->input_next)
+ff_format_io_close(c->ctx, >input_next);
+pls->input_next_requested = 0;
 if (pls->ctx) {
 pls->ctx->pb = NULL;
 avformat_close_input(>ctx);
@@ -920,6 +926,14 @@ static struct segment *current_segment(struct playlist 
*pls)
 return pls->segments[pls->cur_seq_no - pls->start_seq_no];
 }
 
+static struct segment *next_segment(struct playlist *pls)
+{
+int n = pls->cur_seq_no - pls->start_seq_no + 1;
+if (n >= pls->n_segments)
+return NULL;
+return pls->segments[n];
+}
+
 enum ReadFromURLMode {
 READ_NORMAL,
 READ_COMPLETE,
@@ -1361,6 +1375,7 @@ static int read_data(void *opaque, uint8_t *buf, int 
buf_size)
 int ret;
 int just_opened = 0;
 int reload_count = 0;
+struct segment *seg;
 
 restart:
 if (!v->needed)
@@ -1368,7 +1383,6 @@ restart:
 
 if (!v->input || (c->http_persistent && v->input_read_done)) {
 int64_t reload_interval;
-struct segment *seg;
 
 /* Check that the playlist is still needed before opening a new
  * segment. */
@@ -1426,11 +1440,20 @@ reload:
 if (ret)
 return ret;
 
-ret = open_input(c, v, seg, >input);
+if (c->http_multiple && v->input_next_requested) {
+AVIOContext *tmp = v->input;
+v->input = v->input_next;
+v->input_next = tmp;
+v->input_next_requested = 0;
+ret = 0;
+} else {
+ret = open_input(c, v, seg, >input);
+}
 if (ret < 0) {
 if (ff_check_interrupt(c->interrupt_callback))
 return AVERROR_EXIT;
-av_log(v->parent, AV_LOG_WARNING, "Failed to open segment of 
playlist %d\n",
+av_log(v->parent, AV_LOG_WARNING, "Failed to open segment %d of 
playlist %d\n",
+   v->cur_seq_no,
v->index);
 v->cur_seq_no += 1;
 goto reload;
@@ -1438,6 +1461,20 @@ reload:
 just_opened = 1;
 }
 
+seg = next_segment(v);
+if (c->http_multiple && !v->input_next_requested && seg) {
+ret = open_input(c, v, seg, >input_next);
+if (ret < 0) {
+if (ff_check_interrupt(c->interrupt_callback))
+return AVERROR_EXIT;
+av_log(v->parent, AV_LOG_WARNING, "Failed to open segment %d of 
playlist %d\n",
+   v->cur_seq_no + 1,
+   v->index);
+} else {
+v->input_next_requested = 1;
+}
+  

[FFmpeg-devel] [PATCH v2 0/5] avformat/hls: improve network performance

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

This patchset improves the overall network performance of the hls
demuxer when streaming from an HTTP/1.1 server, using two new
options: http_persistent and http_multiple.

Here is a very unscientific benchmark showing the throughput and fps
increases achieved by both options (individually and together). In
this case I was downloading 150 2s segments from another computer
over my local network. Throughput gains over the internet would be
considerably more dramatic as higher latencies are involved (and
https is often used, adding tls negotiation overhead as well).

$ ./ffmpeg -http_persistent 0 -http_multiple 0 \
   -i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
frame=17967 fps=1221 time=00:04:59.99 speed=20.4x

$ ./ffmpeg -http_persistent 0 -http_multiple 1 \
   -i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
frame=17967 fps=1282 time=00:04:59.99 speed=21.4x

$ ./ffmpeg -http_persistent 1 -http_multiple 0 \
   -i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
frame=17967 fps=1727 time=00:04:59.99 speed=28.8x

$ ./ffmpeg -http_persistent 1 -http_multiple 1 \
   -i "http://10.0.1.10:8080/test.m3u8; -c copy -f null /dev/null
frame=17967 fps=1864 time=00:04:59.99 speed=31.1x

Aman Gupta (5):
  avformat/http: ff_http_do_new_request() returns EINVAL if re-used with
different hostname
  avformat/http: add "Opening" info logging to ff_http_do_new_request
  avformat/hls: add http_persistent option
  avformat/hls: allow open_input to be re-used
  avformat/hls: add http_multiple option

 doc/demuxers.texi  |   6 +++
 libavformat/hls.c  | 131 +++--
 libavformat/http.c |  17 +++
 3 files changed, 141 insertions(+), 13 deletions(-)

-- 
2.14.3 (Apple Git-98)

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


[FFmpeg-devel] [PATCH v2 1/5] avformat/http: ff_http_do_new_request() returns EINVAL if re-used with different hostname

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

This will prevent improper use of ff_http_do_new_request() if the user
tries to send a request for a different host to a previously connected
persistent http/1.1 connection.
---
 libavformat/http.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index cf86adc617..a3c36423fc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -306,6 +306,22 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 HTTPContext *s = h->priv_data;
 AVDictionary *options = NULL;
 int ret;
+char hostname1[1024], hostname2[1024], proto1[10], proto2[10];
+int port1, port2;
+
+av_url_split(proto1, sizeof(proto1), NULL, 0,
+ hostname1, sizeof(hostname1), ,
+ NULL, 0, s->location);
+av_url_split(proto2, sizeof(proto2), NULL, 0,
+ hostname2, sizeof(hostname2), ,
+ NULL, 0, uri);
+if (port1 != port2 || strncmp(hostname1, hostname2, sizeof(hostname2)) != 
0) {
+av_log(h, AV_LOG_ERROR, "Cannot reuse HTTP connection for different 
host: %s:%d != %s:%d\n",
+hostname1, port1,
+hostname2, port2
+);
+return AVERROR(EINVAL);
+}
 
 ret = http_shutdown(h, h->flags);
 if (ret < 0)
-- 
2.14.3 (Apple Git-98)

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


[FFmpeg-devel] [PATCH v2 2/5] avformat/http: add "Opening" info logging to ff_http_do_new_request

2017-12-12 Thread Aman Gupta
From: Aman Gupta 

This mimics logging that was added in 53e0d5d7247 for security
purposes.
---
 libavformat/http.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index a3c36423fc..ffdf11cf7e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -336,6 +336,7 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 if (!s->location)
 return AVERROR(ENOMEM);
 
+av_log(s, AV_LOG_INFO, "Opening \'%s\' for %s\n", uri, h->flags & 
AVIO_FLAG_WRITE ? "writing" : "reading");
 ret = http_open_cnx(h, );
 av_dict_free();
 return ret;
-- 
2.14.3 (Apple Git-98)

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


Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing returneofcause play fail

2017-12-12 Thread Michael Niedermayer
On Mon, Dec 11, 2017 at 08:37:43PM +0800, Tiejun.Peng wrote:
> yes, it  is.
> maybe we should add every stream's status and the whole file status can't  be 
> fail only by  one of streams.
> but the modification will be too much and the effect  is extensive.

iam not sure i understand what you suggest but
this issue can be avoided by avoiding the overlap between the error
codes.
simply adding a otherwise not used error code for signaling that
data is truncated but everything is fine and code can continue
should work.
we can also use EOF as in your patch if people feel the advantages
outweight the risk. I just dont want this to be done as undocumented
sideeffect.
If EOF return implies everything must have been fully consistently
initialized then this must be documented

[...]

-- 
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] checkasm/vf_hflip : add test for vf_hflip SIMD

2017-12-12 Thread Michael Niedermayer
On Mon, Dec 11, 2017 at 11:28:53AM +0100, Martin Vignali wrote:
> >
> > It doesn't run (the test is skipped) on 32-bit VS 2017 with command:
> > configure --enable-gpl --toolchain=msvc && make fate-rsync
> > SAMPLES=../fate-suite && make fate SAMPLES=../fate-suite
> >
> > With exactly the same command it runs on 64-bit VS 2017.
> > With similar command line (without '--toolchain=msvc') it runs on 32-bit
> > and 64-bit mingw/GCC.
> >
> 
> Strange, the test is not supposed to be run with fate, using the previous
> patch.
> 
> New patch in attach, with an add in fate/checkasm.mak
> 
> Martin

>  hflip.h|1 +
>  vf_hflip.c |   14 ++
>  2 files changed, 11 insertions(+), 4 deletions(-)
> b772a922ec6882c3954caae6fca47d74ba9f1939  
> 0001-avfilter-vf_hflip-move-context-func-init-in.patch
> From c3e8eaa7f9cd40a833cd679e975f48d1763287f9 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Mon, 11 Dec 2017 11:22:56 +0100
> Subject: [PATCH 1/2] avfilter/vf_hflip : move context func init in 
>  ff_hflip_init

Tested on linux/mingw 32/64 x86 and linux mips/arm

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


Re: [FFmpeg-devel] [PATCH] avformat/mux: factorize AVFormatContext->avoid_negative_ts initialization

2017-12-12 Thread James Almer
On 12/12/2017 4:30 PM, Michael Niedermayer wrote:
> On Mon, Dec 11, 2017 at 01:04:41AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/mux.c | 24 
>>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> LGTM
> 
> thx

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


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread wm4
On Tue, 12 Dec 2017 18:28:28 -0300
James Almer  wrote:

> On 12/12/2017 4:38 AM, wm4 wrote:
> > On Mon, 11 Dec 2017 22:56:24 +0100
> > Michael Niedermayer  wrote:
> >   
> >> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:  
> >>> On Fri, 8 Dec 2017 18:51:52 +0100
> >>> Carl Eugen Hoyos  wrote:
> >>> 
>  2017-12-08 18:45 GMT+01:00 Tiejun.Peng :
> > i agree with you. too much  experience value in condition of Judgement  
> > like this:
> > "else if(max_frames>=4 && max_frames >= p->buf_size/1)".
> >  why  it is the value ? it is hard to known.
> > maybe  the work of cleaned up  need a few days, so i just  repair of 
> > the probe.  
> 
>  Please be careful:
>  As you already know, this probe function is the result of many
>  user reports, many tests and turning many knobs. You cannot
>  "repair" it (easily).
> 
>  If you know of any false positives of the current probe function,
>  please report them!
> >>>
> >>> It plays ELF files as mp3.
> >>>
> >>> You've been ignoring this issue, though.
> >>>
> >>> This probe function is really pretty bad.
> >>
> >> The probe code determines the most likely format from the set of
> >> supported formats.
> >> We do not support playing excutable files (that makes no sense), thus
> >> these do not get detected.
> >>
> >> Is there a usecase where detecting not just the most likely multimedia
> >> format but detecting that a file is not any multimedia format
> >> makes sense ?  
> > 
> > Not playing noise and looking like a huge fuckup of a media application
> > when opening a bunch of files that might include unknown file types?
> > Lots of software is using this to detect whether something is a media
> > file in the first place, too.
> >   
> >> Also if a format is detected with a low score the user is informed about
> >> this via "Format %s detected only with low score of %d,"  
> > 
> > Doesn't help much if legitimate files get a low probe score. AFAIK in
> > my case this happened mostly because of large ID3v2 tags, which
> > restricted or even removed any useful media data from the probe buffer.
> > An API to detect id3 tags (and their size to skip them) would probably
> > be nice for this.  
> 
> ID3v2 tags are handled in avformat_open_input(), unlike APE tags. If
> it's not currently being skipped before filling the probe buffers, it
> could perhaps be implemented.

It doesn't look like even avformat_open_input() skips the id3v2. But
av_probe_input_format*() does. Unfortunately, it uses it only to play
weird games with the probe score, which makes this sort of useless for
API users (and for ffmpeg CLI itself this isn't ideal either). If the
API user assumes that a low probe score always means it has to give the
prober more data, and a given file is something semi-broken that simply
always returns a low score, the API user will be made to read tons of
data into memory for no reason.

That's something I'd like to avoid, and the easiest way is to limit the
probe buffer to something relatively small. But id3v2s can be quite big
(embedded high res cover art), so that's where it becomes a problem
wrt. mp3 in particular.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread Carl Eugen Hoyos
2017-12-12 22:26 GMT+01:00 wm4 :
> On Tue, 12 Dec 2017 22:13:30 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2017-12-12 22:12 GMT+01:00 Paul B Mahol :
>> > On 12/12/17, Carl Eugen Hoyos  wrote:
>> >> 2017-12-11 11:43 GMT+01:00 wm4 :
>> >>
>> >>> You've been ignoring this issue, though.
>> >>
>> >> Please stop using this mailing list for your insults.
>> >
>> > Nobody insulted you
>>
>> I am not sure if he only wanted to insult me...
>
> While I wouldn't mind commenting upon your unpleasant personality in
> colorful ways, it's true that you've known about this ELF issue for a
> very long time, but haven't ever fixed it.

I am 100% sure you don't want to spread lies here but may I
remind you of my first email above where I explain that
applying this patch would introduce the issue that was fixed
because of your report?

And while here: Please share the sample that triggers the
amr bug - you seem to have forgotten that you are responsible
for the issue.

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


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread James Almer
On 12/12/2017 4:38 AM, wm4 wrote:
> On Mon, 11 Dec 2017 22:56:24 +0100
> Michael Niedermayer  wrote:
> 
>> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
>>> On Fri, 8 Dec 2017 18:51:52 +0100
>>> Carl Eugen Hoyos  wrote:
>>>   
 2017-12-08 18:45 GMT+01:00 Tiejun.Peng :  
> i agree with you. too much  experience value in condition of Judgement  
> like this:
> "else if(max_frames>=4 && max_frames >= p->buf_size/1)".
>  why  it is the value ? it is hard to known.
> maybe  the work of cleaned up  need a few days, so i just  repair of the 
> probe.

 Please be careful:
 As you already know, this probe function is the result of many
 user reports, many tests and turning many knobs. You cannot
 "repair" it (easily).

 If you know of any false positives of the current probe function,
 please report them!  
>>>
>>> It plays ELF files as mp3.
>>>
>>> You've been ignoring this issue, though.
>>>
>>> This probe function is really pretty bad.  
>>
>> The probe code determines the most likely format from the set of
>> supported formats.
>> We do not support playing excutable files (that makes no sense), thus
>> these do not get detected.
>>
>> Is there a usecase where detecting not just the most likely multimedia
>> format but detecting that a file is not any multimedia format
>> makes sense ?
> 
> Not playing noise and looking like a huge fuckup of a media application
> when opening a bunch of files that might include unknown file types?
> Lots of software is using this to detect whether something is a media
> file in the first place, too.
> 
>> Also if a format is detected with a low score the user is informed about
>> this via "Format %s detected only with low score of %d,"
> 
> Doesn't help much if legitimate files get a low probe score. AFAIK in
> my case this happened mostly because of large ID3v2 tags, which
> restricted or even removed any useful media data from the probe buffer.
> An API to detect id3 tags (and their size to skip them) would probably
> be nice for this.

ID3v2 tags are handled in avformat_open_input(), unlike APE tags. If
it's not currently being skipped before filling the probe buffers, it
could perhaps be implemented.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread wm4
On Tue, 12 Dec 2017 22:13:30 +0100
Carl Eugen Hoyos  wrote:

> 2017-12-12 22:12 GMT+01:00 Paul B Mahol :
> > On 12/12/17, Carl Eugen Hoyos  wrote:  
> >> 2017-12-11 11:43 GMT+01:00 wm4 :
> >>  
> >>> You've been ignoring this issue, though.  
> >>
> >> Please stop using this mailing list for your insults.  
> >
> > Nobody insulted you  
> 
> I am not sure if he only wanted to insult me...

While I wouldn't mind commenting upon your unpleasant personality in
colorful ways, it's true that you've known about this ELF issue for a
very long time, but haven't ever fixed it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/3] qsv/h264enc: fix cavlc option setting useless issue

2017-12-12 Thread Carl Eugen Hoyos
2017-11-22 4:09 GMT+01:00 Li, Zhong :
> It is due to the dulicate option "coder" (which should be
> deprecated) is set to cabac

Why don't you deprecate -cavlc instead?

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


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread Carl Eugen Hoyos
2017-12-12 22:12 GMT+01:00 Paul B Mahol :
> On 12/12/17, Carl Eugen Hoyos  wrote:
>> 2017-12-11 11:43 GMT+01:00 wm4 :
>>
>>> You've been ignoring this issue, though.
>>
>> Please stop using this mailing list for your insults.
>
> Nobody insulted you

I am not sure if he only wanted to insult me...

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


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread Paul B Mahol
On 12/12/17, Carl Eugen Hoyos  wrote:
> 2017-12-11 11:43 GMT+01:00 wm4 :
>
>> You've been ignoring this issue, though.
>
> Please stop using this mailing list for your insults.

Nobody insulted you, perhaps you should be really insulted anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

2017-12-12 Thread Carl Eugen Hoyos
2017-12-11 11:43 GMT+01:00 wm4 :

> You've been ignoring this issue, though.

Please stop using this mailing list for your insults.

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


[FFmpeg-devel] [PATCH 2/2] patcheck: Add 'threshhold' to common typo list

2017-12-12 Thread Kelly Ledford
Signed-off-by: Kelly Ledford 
---
 tools/patcheck | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/patcheck b/tools/patcheck
index 26137d6b21..101a542ff3 100755
--- a/tools/patcheck
+++ b/tools/patcheck
@@ -68,7 +68,7 @@ $EGREP $OPT '^\+ *(const *|)static' $*| $EGREP --color=always 
'[^=]= *(0|NULL)[^
 cat $TMP
 hiegrep '# *ifdef * (HAVE|CONFIG)_' 'ifdefs that should be #if' $*
 
-hiegrep 
'\b(awnser|cant|dont|wont|doesnt|usefull|successfull|occured|teh|alot|wether|skiped|skiping|heigth|informations|colums|loosy|loosing|ouput|seperate|preceed|upto|paket|posible|unkown|inpossible|dimention|acheive|funtions|overriden|outputing|seperation|initalize|compatibilty|bistream|knwon|unknwon|choosen|additonal|gurantee|availble|wich|begining|milisecond|missmatch)\b'
 'common typos' $*
+hiegrep 
'\b(awnser|cant|dont|wont|doesnt|usefull|successfull|occured|teh|alot|wether|skiped|skiping|heigth|informations|colums|loosy|loosing|ouput|seperate|preceed|upto|paket|posible|unkown|inpossible|dimention|acheive|funtions|overriden|outputing|seperation|initalize|compatibilty|bistream|knwon|unknwon|choosen|additonal|gurantee|availble|wich|begining|milisecond|missmatch|threshhold)\b'
 'common typos' $*
 
 hiegrep 'av_log\( *NULL' 'Missing context in av_log' $*
 hiegrep '[^sn]printf' 'Please use av_log' $*
-- 
2.13.6

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


[FFmpeg-devel] [PATCH 1/2] libavfilter/af_dcshift.c: Fixed repeated spelling error

2017-12-12 Thread Kelly Ledford
'threshhold' should be 'threshold'

Signed-off-by: Kelly Ledford 
---
 libavfilter/af_dcshift.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavfilter/af_dcshift.c b/libavfilter/af_dcshift.c
index 6d33daee0b..e007efe05e 100644
--- a/libavfilter/af_dcshift.c
+++ b/libavfilter/af_dcshift.c
@@ -28,7 +28,7 @@
 typedef struct DCShiftContext {
 const AVClass *class;
 double dcshift;
-double limiterthreshhold;
+double limiterthreshold;
 double limitergain;
 } DCShiftContext;
 
@@ -47,7 +47,7 @@ static av_cold int init(AVFilterContext *ctx)
 {
 DCShiftContext *s = ctx->priv;
 
-s->limiterthreshhold = INT32_MAX * (1.0 - (fabs(s->dcshift) - 
s->limitergain));
+s->limiterthreshold = INT32_MAX * (1.0 - (fabs(s->dcshift) - 
s->limitergain));
 
 return 0;
 }
@@ -111,14 +111,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 
 d = src[j];
 
-if (d > s->limiterthreshhold && dcshift > 0) {
-d = (d - s->limiterthreshhold) * s->limitergain /
- (INT32_MAX - s->limiterthreshhold) +
- s->limiterthreshhold + dcshift;
-} else if (d < -s->limiterthreshhold && dcshift < 0) {
-d = (d + s->limiterthreshhold) * s->limitergain /
- (INT32_MAX - s->limiterthreshhold) -
- s->limiterthreshhold + dcshift;
+if (d > s->limiterthreshold && dcshift > 0) {
+d = (d - s->limiterthreshold) * s->limitergain /
+ (INT32_MAX - s->limiterthreshold) +
+ s->limiterthreshold + dcshift;
+} else if (d < -s->limiterthreshold && dcshift < 0) {
+d = (d + s->limiterthreshold) * s->limitergain /
+ (INT32_MAX - s->limiterthreshold) -
+ s->limiterthreshold + dcshift;
 } else {
 d = dcshift * INT32_MAX + d;
 }
-- 
2.13.6

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


Re: [FFmpeg-devel] [PATCH] avformat/mux: factorize AVFormatContext->avoid_negative_ts initialization

2017-12-12 Thread Michael Niedermayer
On Mon, Dec 11, 2017 at 01:04:41AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/mux.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)

LGTM

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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


Re: [FFmpeg-devel] [PATCH] avfilter/formats: fix wrong function name in error message

2017-12-12 Thread Michael Niedermayer
On Tue, Dec 12, 2017 at 01:59:18PM +0800, Jun Zhao wrote:
> 
> 
> On 2017/12/7 8:49, Jun Zhao wrote:
> >
> > On 2017/12/5 17:25, Hendrik Leppkes wrote:
> >> On Tue, Dec 5, 2017 at 6:42 AM, Jun Zhao  wrote:
> >>> On 2017/12/5 2:32, Michael Niedermayer wrote:
>  On Mon, Dec 04, 2017 at 11:07:11AM +0100, Hendrik Leppkes wrote:
> > On Mon, Dec 4, 2017 at 10:53 AM, Moritz Barsnick  
> > wrote:
> >> On Mon, Dec 04, 2017 at 13:02:20 +0800, Jun Zhao wrote:
> >>> Use perdefined micro __FUNCTION__ rather than hard coding function 
> >>> name
> >>> to fix wrong function name in error message.
> >> AFAICT, "__FUNCTION__" is a C99 feature and thereby not supported by
> >> ffmpeg style. Or should it be? (It might be "supported by all compilers
> >> we care about".)
> >>
> >> http://ffmpeg.org/developer.html#C-language-features
> >>
> > __FUNCTION__ is not C99, its a compiler extension (which is understood
> > by GCC and some other compilers). __func__ is the C99 keyword.
> > Its likely that not all compilers we currently support would have
> > __func__, if they all have __FUNCTION__ however I cannot tell.
>  There are some matches for __FUNCTION__ in git, so i wonder if all
>  compilers we support do support it
> >>> So now we have 2 option:
> >>>
> >>> 1). Find a ways to get the current function on different platforms in
> >>> C90,
> >>> https://stackoverflow.com/questions/7008485/func-or-function-or-manual-const-char-id
> >>> have some information for this way. (lot of #if defined )
> >>> 2). Just remove __FUNCTION__ from the code. Total 5 __FUNCTION__ in
> >>> source code when grep the code.
> >>>
> >>> Personally, I prefer option 2 than option 1, any comments?
> >> If __FUNCTION__ is already in use right now (and hence supported by
> >> all compilers we have), it should be fine to use it again, so no need
> >> for complex ifdefs, I would think.
> >> In fact I just checked, and its in use in a key part in avformat, not
> >> even an optional module, so any compiler not supporting it would
> >> already fail building it now.
> >>
> >> - Hendrik
> > I agree, so we need to wait more comments for this ?
> 
> Any comments, Michael ? or we need to remove all __FUNCTION__ from the
> code ?

ill apply the patch as it seems all concerns have been resolved IIUC

thx

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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


Re: [FFmpeg-devel] [PATCH] configure: Fix detection of vp9 decoder/encoder

2017-12-12 Thread Felix Matouschek

Am 12.12.2017 15:37, schrieb James Almer:

No, this is not correct. If anything has to be added here, it would be
$libm_extralibs. -lm is not needed/available on some systems.


Ok, changed it.


Also, you should be using pkg-config. Its job is to make sure all the
cflags and ldflags are correct for your system.
This shitty fallback shouldn't be here in the first place, but some
people are too stubborn about it.


The Android NDK has no pkg-config so it is somehow useful.From b2f30f087aaf7d1284ebe08a09adc478df80ba22 Mon Sep 17 00:00:00 2001
From: Felix Matouschek 
Date: Tue, 12 Dec 2017 10:42:40 +0100
Subject: [PATCH] configure: Fix detection of vp9 decoder/encoder
To: ffmpeg-devel@ffmpeg.org

At least on Android the vp9 decoder/encoder needs $libm_extralibs
to successfully link, it was missing in the check_lib calls for vp9

Signed-off-by: Felix Matouschek 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 8cf48ae1cf..df149024d3 100755
--- a/configure
+++ b/configure
@@ -5918,11 +5918,11 @@ enabled libvpx&& {
 }
 enabled libvpx_vp9_decoder && {
 check_pkg_config libvpx_vp9_decoder "vpx >= 1.4.0" "vpx/vpx_decoder.h vpx/vp8dx.h" vpx_codec_vp9_dx ||
-check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
+check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx $libm_extralibs
 }
 enabled libvpx_vp9_encoder && {
 check_pkg_config libvpx_vp9_encoder "vpx >= 1.4.0" "vpx/vpx_encoder.h vpx/vp8cx.h" vpx_codec_vp9_cx ||
-check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
+check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx $libm_extralibs
 }
 if disabled_all libvpx_vp8_decoder libvpx_vp9_decoder libvpx_vp8_encoder libvpx_vp9_encoder; then
 die "libvpx enabled but no supported decoders found"
-- 
2.14.1.windows.1

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


Re: [FFmpeg-devel] [PATCH] configure: Fix detection of vp9 decoder/encoder

2017-12-12 Thread James Almer
On 12/12/2017 6:55 AM, Felix Matouschek wrote:
> This fixes the detection of the vp9 decoder/encoder.
> 
> The vp9 decoder/encoder needs libm to successfully link, -lm was missing
> in the check_lib calls for vp9 in configure.
> 
> 0001-configure-Fix-detection-of-vp9-decoder-encoder.patch
> 
> 
> From 0b5bbd7c30f3a76b2e0ab6ceae2bfaebe944b279 Mon Sep 17 00:00:00 2001
> From: Felix Matouschek 
> Date: Tue, 12 Dec 2017 10:42:40 +0100
> Subject: [PATCH] configure: Fix detection of vp9 decoder/encoder
> To: ffmpeg-devel@ffmpeg.org
> 
> The vp9 decoder/encoder needs libm to successfully link,
> -lm was missing in the check_lib calls for vp9
> 
> Signed-off-by: Felix Matouschek 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 8cf48ae1cf..4581850fe5 100755
> --- a/configure
> +++ b/configure
> @@ -5918,11 +5918,11 @@ enabled libvpx&& {
>  }
>  enabled libvpx_vp9_decoder && {
>  check_pkg_config libvpx_vp9_decoder "vpx >= 1.4.0" 
> "vpx/vpx_decoder.h vpx/vp8dx.h" vpx_codec_vp9_dx ||
> -check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
> "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
> +check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" 
> "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx -lm

No, this is not correct. If anything has to be added here, it would be
$libm_extralibs. -lm is not needed/available on some systems.

Also, you should be using pkg-config. Its job is to make sure all the
cflags and ldflags are correct for your system.
This shitty fallback shouldn't be here in the first place, but some
people are too stubborn about it.

>  }
>  enabled libvpx_vp9_encoder && {
>  check_pkg_config libvpx_vp9_encoder "vpx >= 1.4.0" 
> "vpx/vpx_encoder.h vpx/vp8cx.h" vpx_codec_vp9_cx ||
> -check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
> "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
> +check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" 
> "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx -lm
>  }
>  if disabled_all libvpx_vp8_decoder libvpx_vp9_decoder libvpx_vp8_encoder 
> libvpx_vp9_encoder; then
>  die "libvpx enabled but no supported decoders found"
> -- 2.14.1.windows.1
> 
> 
> 
> ___
> 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 01/23] avcodec: add color_range to AVCodec struct and use it

2017-12-12 Thread wm4
On Tue, 12 Dec 2017 14:55:59 +0100
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/avcodec.h | 1 +
>  libavcodec/utils.c   | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 5db6a81320..df715fd5ee 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3376,6 +3376,7 @@ typedef struct AVCodec {
>  uint8_t max_lowres; ///< maximum value for lowres 
> supported by the decoder
>  const AVClass *priv_class;  ///< AVClass for the private 
> context
>  const AVProfile *profiles;  ///< array of recognized 
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +const enum AVColorRange *color_ranges;  ///< array of supported color 
> ranges by encoder, or  NULL if unknown, array is terminated by -1

wouldn't it be terminated by AVCOL_RANGE_UNSPECIFIED? (The enum might be
backed by an unsigned integer type, so this is not just bikeshed.)

>  
>  /*
>   * No fields below this line are part of the public API. They
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 873f39f9bd..41cc6fbf2c 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
>  avctx->color_range = AVCOL_RANGE_JPEG;
>  }
> +if (avctx->codec->color_range)
> +avctx->color_range = avctx->codec->color_range;
>  if (avctx->codec->supported_samplerates) {
>  for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
>  if (avctx->sample_rate == 
> avctx->codec->supported_samplerates[i])

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


[FFmpeg-devel] [PATCH 06/23] avfilter: negotiate color_range between filters

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 fftools/ffmpeg.c|  2 ++
 fftools/ffmpeg_filter.c | 56 +---
 libavcodec/utils.c  | 13 --
 libavfilter/avfilter.c  |  9 ---
 libavfilter/avfilter.h  |  4 ++-
 libavfilter/avfiltergraph.c | 53 ++
 libavfilter/buffersink.c| 16 
 libavfilter/buffersink.h|  1 +
 libavfilter/buffersrc.c |  4 +++
 libavfilter/formats.c   | 63 +
 libavfilter/formats.h   | 31 ++
 libavfilter/internal.h  | 11 
 libavfilter/vf_format.c | 46 -
 libavfilter/vf_noise.c  |  6 -
 libavfilter/vf_scale.c  | 17 +---
 libavfilter/vsrc_testsrc.c  | 15 +--
 tests/fate/filter-video.mak |  2 +-
 tests/fate/pixlet.mak   |  2 +-
 18 files changed, 332 insertions(+), 19 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 6aff3366c5..64de55d9a5 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3390,6 +3390,8 @@ static int init_output_stream_encode(OutputStream *ost)
 enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample,
  
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth);
 
+enc_ctx->color_range = 
av_buffersink_get_color_range(ost->filter->filter);
+
 enc_ctx->framerate = ost->frame_rate;
 
 ost->st->avg_frame_rate = ost->frame_rate;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 877fd670e6..cc7d700b46 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -89,6 +89,28 @@ enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
AVCodecContext *enc_ctx, AVCod
 return target;
 }
 
+static enum AVColorRange choose_color_range(AVStream *st, AVCodecContext 
*enc_ctx, AVCodec *codec, enum AVColorRange target)
+{
+if (codec && codec->color_ranges) {
+const enum AVColorRange *p = codec->color_ranges;
+
+for (; *p != -1; p++) {
+if (*p == target)
+break;
+}
+if (*p == -1) {
+if (target != AVCOL_RANGE_UNSPECIFIED)
+av_log(NULL, AV_LOG_WARNING,
+   "Incompatible color range '%s' for codec '%s', 
auto-selecting color range '%s'\n",
+   av_color_range_name(target),
+   codec->name,
+   av_color_range_name(codec->color_ranges[0]));
+return codec->color_ranges[0];
+}
+}
+return target;
+}
+
 void choose_sample_fmt(AVStream *st, AVCodec *codec)
 {
 if (codec && codec->sample_fmts) {
@@ -127,7 +149,19 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
 return av_strdup(av_get_pix_fmt_name(ost->enc_ctx->pix_fmt));
 }
 if (ost->enc_ctx->pix_fmt != AV_PIX_FMT_NONE) {
-return av_strdup(av_get_pix_fmt_name(choose_pixel_fmt(ost->st, 
ost->enc_ctx, ost->enc, ost->enc_ctx->pix_fmt)));
+AVIOContext *s = NULL;
+uint8_t *ret;
+int len;
+
+if (avio_open_dyn_buf() < 0)
+exit_program(1);
+
+avio_printf(s, "%s:%s", av_get_pix_fmt_name(choose_pixel_fmt(ost->st, 
ost->enc_ctx, ost->enc, ost->enc_ctx->pix_fmt)),
+
av_color_range_name(choose_color_range(ost->st, ost->enc_ctx, ost->enc, 
ost->enc_ctx->color_range)));
+
+len = avio_close_dyn_buf(s, );
+ret[len] = 0;
+return ret;
 } else if (ost->enc && ost->enc->pix_fmts) {
 const enum AVPixelFormat *p;
 AVIOContext *s = NULL;
@@ -144,7 +178,20 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
 
 for (; *p != AV_PIX_FMT_NONE; p++) {
 const char *name = av_get_pix_fmt_name(*p);
-avio_printf(s, "%s|", name);
+avio_printf(s, "%s", name);
+if (*(p + 1) != AV_PIX_FMT_NONE)
+avio_printf(s, "|");
+else
+avio_printf(s, ":");
+}
+
+if (ost->enc->color_ranges) {
+const enum AVColorRange *c = ost->enc->color_ranges;
+
+for (; *c != -1; c++) {
+const char *name = av_color_range_name(*c);
+avio_printf(s, "%s|", name);
+}
 }
 len = avio_close_dyn_buf(s, );
 ret[len - 1] = 0;
@@ -777,10 +824,11 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 av_bprint_init(, 0, 1);
 av_bprintf(,
  "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d:sws_param=flags=%d",
+ "pixel_aspect=%d/%d:sws_param=flags=%d:color_range=%s",
  ifilter->width, ifilter->height, ifilter->format,
  tb.num, tb.den, sar.num, sar.den,
- SWS_BILINEAR + ((ist->dec_ctx->flags_CODEC_FLAG_BITEXACT) ? 

[FFmpeg-devel] [PATCH 03/23] avfilter/buffersrc: recognize color_range as additonal parameter and set it to input link

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/buffersrc.c | 18 ++
 libavfilter/buffersrc.h |  5 +
 2 files changed, 23 insertions(+)

diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index cd56f8ca45..51a1a9fb49 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -52,6 +52,7 @@ typedef struct BufferSourceContext {
 int   w, h;
 enum AVPixelFormat  pix_fmt;
 AVRationalpixel_aspect;
+int   color_range;
 char  *sws_param;
 
 AVBufferRef *hw_frames_ctx;
@@ -109,6 +110,8 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx, 
AVBufferSrcParameters *par
 s->h = param->height;
 if (param->sample_aspect_ratio.num > 0 && 
param->sample_aspect_ratio.den > 0)
 s->pixel_aspect = param->sample_aspect_ratio;
+if (param->color_range > AVCOL_RANGE_UNSPECIFIED)
+s->color_range = param->color_range;
 if (param->frame_rate.num > 0 && param->frame_rate.den > 0)
 s->frame_rate = param->frame_rate;
 if (param->hw_frames_ctx) {
@@ -279,6 +282,11 @@ static av_cold int init_video(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
+if (!av_color_range_name(c->color_range)) {
+av_log(ctx, AV_LOG_ERROR, "Invalid color_range parameter provided.\n");
+return AVERROR(EINVAL);
+}
+
 if (!(c->fifo = av_fifo_alloc(sizeof(AVFrame*
 return AVERROR(ENOMEM);
 
@@ -309,6 +317,15 @@ static const AVOption buffer_options[] = {
 { "time_base", NULL, OFFSET(time_base),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
 { "frame_rate",NULL, OFFSET(frame_rate),   
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
 { "sws_param", NULL, OFFSET(sws_param),
AV_OPT_TYPE_STRING,.flags = V },
+{ "color_range",   NULL, OFFSET(color_range),  
AV_OPT_TYPE_INT,  { .i64 = AVCOL_RANGE_UNSPECIFIED }, 0, INT_MAX, V, 
"range" },
+{ "unspecified",   NULL,   0, AV_OPT_TYPE_CONST, 
{.i64=AVCOL_RANGE_UNSPECIFIED},  0, 0, V, "range"},
+{ "unknown",   NULL,   0, AV_OPT_TYPE_CONST, 
{.i64=AVCOL_RANGE_UNSPECIFIED},  0, 0, V, "range"},
+{ "limited",   NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  
   0, 0, V, "range"},
+{ "tv",NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  
   0, 0, V, "range"},
+{ "mpeg",  NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  
   0, 0, V, "range"},
+{ "full",  NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  
   0, 0, V, "range"},
+{ "pc",NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  
   0, 0, V, "range"},
+{ "jpeg",  NULL,   0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  
   0, 0, V, "range"},
 { NULL },
 };
 
@@ -434,6 +451,7 @@ static int config_props(AVFilterLink *link)
 link->w = c->w;
 link->h = c->h;
 link->sample_aspect_ratio = c->pixel_aspect;
+link->color_range = c->color_range;
 
 if (c->hw_frames_ctx) {
 link->hw_frames_ctx = av_buffer_ref(c->hw_frames_ctx);
diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
index 0652113f2b..7129db6bd9 100644
--- a/libavfilter/buffersrc.h
+++ b/libavfilter/buffersrc.h
@@ -114,6 +114,11 @@ typedef struct AVBufferSrcParameters {
  * Audio only, the audio channel layout
  */
 uint64_t channel_layout;
+
+   /**
+ * Video only
+ */
+enum AVColorRange color_range;
 } AVBufferSrcParameters;
 
 /**
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 01/23] avcodec: add color_range to AVCodec struct and use it

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/avcodec.h | 1 +
 libavcodec/utils.c   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..df715fd5ee 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3376,6 +3376,7 @@ typedef struct AVCodec {
 uint8_t max_lowres; ///< maximum value for lowres 
supported by the decoder
 const AVClass *priv_class;  ///< AVClass for the private 
context
 const AVProfile *profiles;  ///< array of recognized profiles, 
or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
+const enum AVColorRange *color_ranges;  ///< array of supported color 
ranges by encoder, or  NULL if unknown, array is terminated by -1
 
 /*
  * No fields below this line are part of the public API. They
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 873f39f9bd..41cc6fbf2c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -879,6 +879,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
 avctx->color_range = AVCOL_RANGE_JPEG;
 }
+if (avctx->codec->color_range)
+avctx->color_range = avctx->codec->color_range;
 if (avctx->codec->supported_samplerates) {
 for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
 if (avctx->sample_rate == 
avctx->codec->supported_samplerates[i])
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 08/23] avcodec/mpeg4videoenc: mark as limited color range only

2017-12-12 Thread Paul B Mahol
lavf-mkv changes only because of metadata.

Signed-off-by: Paul B Mahol 
---
 libavcodec/mpeg4videoenc.c |  1 +
 libavcodec/mpegvideo_enc.c |  4 
 tests/ref/lavf/mkv |  8 
 tests/ref/seek/lavf-mkv| 44 ++--
 4 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index 494452c938..97d6069b6d 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -1396,6 +1396,7 @@ AVCodec ff_mpeg4_encoder = {
 .encode2= ff_mpv_encode_picture,
 .close  = ff_mpv_encode_end,
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.color_ranges   = (const enum AVColorRange[]) { AVCOL_RANGE_MPEG, -1 },
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS,
 .priv_class = _class,
 };
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index f1f4989231..399b8dece1 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -4864,6 +4864,7 @@ AVCodec ff_h263p_encoder = {
 .close  = ff_mpv_encode_end,
 .capabilities   = AV_CODEC_CAP_SLICE_THREADS,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.color_ranges   = (const enum AVColorRange[]){ AVCOL_RANGE_MPEG, -1 },
 .priv_class = _class,
 };
 
@@ -4884,6 +4885,7 @@ AVCodec ff_msmpeg4v2_encoder = {
 .encode2= ff_mpv_encode_picture,
 .close  = ff_mpv_encode_end,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.color_ranges   = (const enum AVColorRange[]){ AVCOL_RANGE_MPEG, -1 },
 .priv_class = _class,
 };
 
@@ -4904,6 +4906,7 @@ AVCodec ff_msmpeg4v3_encoder = {
 .encode2= ff_mpv_encode_picture,
 .close  = ff_mpv_encode_end,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.color_ranges   = (const enum AVColorRange[]){ AVCOL_RANGE_MPEG, -1 },
 .priv_class = _class,
 };
 
@@ -4924,5 +4927,6 @@ AVCodec ff_wmv1_encoder = {
 .encode2= ff_mpv_encode_picture,
 .close  = ff_mpv_encode_end,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.color_ranges   = (const enum AVColorRange[]){ AVCOL_RANGE_MPEG, -1 },
 .priv_class = _class,
 };
diff --git a/tests/ref/lavf/mkv b/tests/ref/lavf/mkv
index 0083033958..bd0302b14f 100644
--- a/tests/ref/lavf/mkv
+++ b/tests/ref/lavf/mkv
@@ -1,6 +1,6 @@
-7c8697c324e8ad79c5ea14364a6c39b8 *./tests/data/lavf/lavf.mkv
-472759 ./tests/data/lavf/lavf.mkv
+80092ba5b6833704dd04bd9f7f75366d *./tests/data/lavf/lavf.mkv
+472766 ./tests/data/lavf/lavf.mkv
 ./tests/data/lavf/lavf.mkv CRC=0xec6c3c68
-9767a3b526d7e56d7400164cb888990c *./tests/data/lavf/lavf.mkv
-320603 ./tests/data/lavf/lavf.mkv
+b919b159a2dd7c9c7cd45cc36f204754 *./tests/data/lavf/lavf.mkv
+320610 ./tests/data/lavf/lavf.mkv
 ./tests/data/lavf/lavf.mkv CRC=0xec6c3c68
diff --git a/tests/ref/seek/lavf-mkv b/tests/ref/seek/lavf-mkv
index cea34e99ac..368e86cd14 100644
--- a/tests/ref/seek/lavf-mkv
+++ b/tests/ref/seek/lavf-mkv
@@ -1,48 +1,48 @@
-ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:834 size:   
208
+ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:841 size:   
208
 ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1050 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1057 size: 
27837
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 0.971000 pts: 0.971000 pos: 292476 size: 
27834
+ret: 0 st: 0 flags:1 dts: 0.971000 pts: 0.971000 pos: 292483 size: 
27834
 ret: 0 st: 0 flags:0  ts: 0.788000
-ret: 0 st: 0 flags:1 dts: 0.971000 pts: 0.971000 pos: 292476 size: 
27834
+ret: 0 st: 0 flags:1 dts: 0.971000 pts: 0.971000 pos: 292483 size: 
27834
 ret: 0 st: 0 flags:1  ts:-0.317000
-ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1050 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1057 size: 
27837
 ret:-1 st: 1 flags:0  ts: 2.577000
 ret: 0 st: 1 flags:1  ts: 1.471000
-ret: 0 st: 1 flags:1 dts: 0.993000 pts: 0.993000 pos: 320317 size:   
209
+ret: 0 st: 1 flags:1 dts: 0.993000 pts: 0.993000 pos: 320324 size:   
209
 ret: 0 st:-1 flags:0  ts: 0.365002
-ret: 0 st: 0 flags:1 dts: 0.491000 pts: 0.491000 pos: 147023 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.491000 pts: 0.491000 pos: 147030 size: 
27925
 ret: 0 st:-1 flags:1  ts:-0.740831
-ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1050 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.011000 pts: 0.011000 pos:   1057 size: 
27837
 ret:-1 st: 0 

[FFmpeg-devel] [PATCH 02/23] avfilter/avfilter: add color_range to AVFilterLink struct

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/avfilter.c | 2 ++
 libavfilter/avfilter.h | 2 ++
 libavfilter/video.c| 8 +++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b98b32bacb..4a579bb49d 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -336,6 +336,8 @@ int avfilter_config_links(AVFilterContext *filter)
 link->w = inlink->w;
 if (!link->h)
 link->h = inlink->h;
+if (!link->color_range)
+link->color_range = inlink->color_range;
 } else if (!link->w || !link->h) {
 av_log(link->src, AV_LOG_ERROR,
"Video source filters must set their output link's "
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 47546c15e5..40ad28ffd8 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -584,6 +584,8 @@ struct AVFilterLink {
  */
 AVBufferRef *hw_frames_ctx;
 
+enum AVColorRange color_range;///< color range type, video only
+
 #ifndef FF_INTERNAL_FIELDS
 
 /**
diff --git a/libavfilter/video.c b/libavfilter/video.c
index 6f9020b9fe..8f12cb7080 100644
--- a/libavfilter/video.c
+++ b/libavfilter/video.c
@@ -43,6 +43,7 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, 
int h)
 
 AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
 {
+AVFrame *frame = NULL;
 int pool_width = 0;
 int pool_height = 0;
 int pool_align = 0;
@@ -86,7 +87,12 @@ AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int 
w, int h)
 }
 }
 
-return ff_frame_pool_get(link->frame_pool);
+frame = ff_frame_pool_get(link->frame_pool);
+if (!frame)
+return NULL;
+frame->color_range = link->color_range;
+
+return frame;
 }
 
 AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 13/23] avcodec/fraps: replace YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/fraps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/fraps.c b/libavcodec/fraps.c
index 7a7673f73f..b2025b5d3f 100644
--- a/libavcodec/fraps.c
+++ b/libavcodec/fraps.c
@@ -218,7 +218,7 @@ static int decode_frame(AVCodecContext *avctx,
 f->pict_type = AV_PICTURE_TYPE_I;
 f->key_frame = 1;
 
-avctx->pix_fmt = version & 1 ? is_pal ? AV_PIX_FMT_PAL8 : AV_PIX_FMT_BGR24 
: AV_PIX_FMT_YUVJ420P;
+avctx->pix_fmt = version & 1 ? is_pal ? AV_PIX_FMT_PAL8 : AV_PIX_FMT_BGR24 
: AV_PIX_FMT_YUV420P;
 avctx->color_range = version & 1 ? AVCOL_RANGE_UNSPECIFIED
  : AVCOL_RANGE_JPEG;
 avctx->colorspace = version & 1 ? AVCOL_SPC_UNSPECIFIED : AVCOL_SPC_BT709;
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 05/23] avfilter/vf_scale: make use of color_range from filter links

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_scale.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 9f45032e85..802f841cc3 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -303,9 +303,15 @@ static int config_props(AVFilterLink *outlink)
 if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
 av_opt_set_int(*s, "src_range",
scale->in_range == AVCOL_RANGE_JPEG, 0);
+else
+av_opt_set_int(*s, "src_range",
+   inlink->color_range == AVCOL_RANGE_JPEG, 0);
 if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
 av_opt_set_int(*s, "dst_range",
scale->out_range == AVCOL_RANGE_JPEG, 0);
+   else
+av_opt_set_int(*s, "dst_range",
+   outlink->color_range == AVCOL_RANGE_JPEG, 0);
 
 if (scale->opts) {
 AVDictionaryEntry *e = NULL;
@@ -416,6 +422,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 if(   in->width  != link->w
|| in->height != link->h
|| in->format != link->format
+   || in->color_range != link->color_range
|| in->sample_aspect_ratio.den != link->sample_aspect_ratio.den || 
in->sample_aspect_ratio.num != link->sample_aspect_ratio.num) {
 int ret;
 
@@ -429,6 +436,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 link->dst->inputs[0]->format = in->format;
 link->dst->inputs[0]->w  = in->width;
 link->dst->inputs[0]->h  = in->height;
+link->dst->inputs[0]->color_range = in->color_range;
 
 link->dst->inputs[0]->sample_aspect_ratio.den = 
in->sample_aspect_ratio.den;
 link->dst->inputs[0]->sample_aspect_ratio.num = 
in->sample_aspect_ratio.num;
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 22/23] avformat/rtpenc_jpeg: remove usage of YUVJ formats

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavformat/rtpenc_jpeg.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/libavformat/rtpenc_jpeg.c b/libavformat/rtpenc_jpeg.c
index 38eb2e68eb..e0e7afebfc 100644
--- a/libavformat/rtpenc_jpeg.c
+++ b/libavformat/rtpenc_jpeg.c
@@ -46,13 +46,11 @@ void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t 
*buf, int size)
 h = AV_CEIL_RSHIFT(s1->streams[0]->codecpar->height, 3);
 
 /* get the pixel format type or fail */
-if (s1->streams[0]->codecpar->format == AV_PIX_FMT_YUVJ422P ||
-(s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
- s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV422P)) {
+if (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
+ s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV422P) {
 type = 0;
-} else if (s1->streams[0]->codecpar->format == AV_PIX_FMT_YUVJ420P ||
-   (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
-s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV420P)) {
+} else if (s1->streams[0]->codecpar->color_range == AVCOL_RANGE_JPEG &&
+s1->streams[0]->codecpar->format == AV_PIX_FMT_YUV420P) {
 type = 1;
 } else {
 av_log(s1, AV_LOG_ERROR, "Unsupported pixel format\n");
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 23/23] avfilter: remove YUVJ pixel format usage

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/avf_showspectrum.c |  2 +-
 libavfilter/vaf_spectrumsynth.c|  4 +---
 libavfilter/vf_atadenoise.c|  3 ---
 libavfilter/vf_avgblur.c   |  4 +---
 libavfilter/vf_bitplanenoise.c |  2 --
 libavfilter/vf_blend.c |  1 -
 libavfilter/vf_bwdif.c |  2 --
 libavfilter/vf_colorspace.c|  1 -
 libavfilter/vf_convolution.c   |  4 +---
 libavfilter/vf_convolve.c  |  4 +---
 libavfilter/vf_cover_rect.c|  3 +--
 libavfilter/vf_cropdetect.c|  6 +++---
 libavfilter/vf_deband.c|  4 +---
 libavfilter/vf_deflicker.c |  3 ---
 libavfilter/vf_deshake.c   |  3 +--
 libavfilter/vf_displace.c  |  4 +---
 libavfilter/vf_drawbox.c   |  3 +--
 libavfilter/vf_extractplanes.c |  6 --
 libavfilter/vf_fade.c  |  3 +--
 libavfilter/vf_fftfilt.c   |  6 +++---
 libavfilter/vf_fillborders.c   |  4 +---
 libavfilter/vf_find_rect.c |  1 -
 libavfilter/vf_framepack.c |  3 +--
 libavfilter/vf_framerate.c | 10 +-
 libavfilter/vf_fspp.c  |  2 --
 libavfilter/vf_gblur.c |  4 +---
 libavfilter/vf_histogram.c |  8 
 libavfilter/vf_hqdn3d.c|  4 
 libavfilter/vf_hysteresis.c|  4 +---
 libavfilter/vf_idet.c  |  4 
 libavfilter/vf_interlace.c |  4 ++--
 libavfilter/vf_lenscorrection.c|  4 ++--
 libavfilter/vf_limiter.c   |  4 +---
 libavfilter/vf_lut.c   |  2 --
 libavfilter/vf_lut2.c  |  4 +---
 libavfilter/vf_maskedclamp.c   |  4 +---
 libavfilter/vf_maskedmerge.c   |  4 +---
 libavfilter/vf_mestimate.c |  3 ---
 libavfilter/vf_midequalizer.c  |  4 +---
 libavfilter/vf_minterpolate.c  |  3 ---
 libavfilter/vf_mpdecimate.c|  2 --
 libavfilter/vf_neighbor.c  |  1 -
 libavfilter/vf_nlmeans.c   |  3 ---
 libavfilter/vf_nnedi.c |  3 ---
 libavfilter/vf_ocr.c   |  3 ---
 libavfilter/vf_overlay.c   |  6 +++---
 libavfilter/vf_perspective.c   |  1 -
 libavfilter/vf_phase.c |  1 -
 libavfilter/vf_pp.c| 12 
 libavfilter/vf_pp7.c   |  2 --
 libavfilter/vf_premultiply.c   | 10 +-
 libavfilter/vf_psnr.c  |  2 --
 libavfilter/vf_pullup.c|  4 +---
 libavfilter/vf_readeia608.c|  3 ---
 libavfilter/vf_readvitc.c  |  5 -
 libavfilter/vf_remap.c |  1 -
 libavfilter/vf_removegrain.c   |  2 --
 libavfilter/vf_rotate.c|  4 ++--
 libavfilter/vf_signalstats.c   |  2 --
 libavfilter/vf_signature.c |  3 ---
 libavfilter/vf_spp.c   |  2 --
 libavfilter/vf_ssim.c  |  2 --
 libavfilter/vf_stereo3d.c  |  5 -
 libavfilter/vf_threshold.c |  4 +---
 libavfilter/vf_tinterlace.c| 11 ++-
 libavfilter/vf_unsharp.c   |  4 ++--
 libavfilter/vf_uspp.c  |  2 --
 libavfilter/vf_vaguedenoiser.c |  3 ---
 libavfilter/vf_vectorscope.c   | 10 +-
 libavfilter/vf_w3fdif.c|  3 ---
 libavfilter/vf_waveform.c  | 10 ++
 libavfilter/vf_yadif.c |  4 
 libavfilter/vf_zoompan.c   |  3 ---
 libavfilter/vf_zscale.c|  3 ---
 libavfilter/vsrc_testsrc.c |  2 +-
 tests/ref/fate/filter-pixfmts-lut  |  4 
 tests/ref/fate/filter-pixfmts-pullup   |  5 -
 tests/ref/fate/filter-pixfmts-rotate   |  2 --
 tests/ref/fate/filter-pixfmts-tinterlace_cvlpf |  4 
 tests/ref/fate/filter-pixfmts-tinterlace_merge |  4 
 tests/ref/fate/filter-pixfmts-tinterlace_pad   |  4 
 tests/ref/fate/filter-pixfmts-tinterlace_vlpf  |  4 
 82 files changed, 63 insertions(+), 250 deletions(-)

diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 956f62f3ad..33449df315 100644
--- a/libavfilter/avf_showspectrum.c

[FFmpeg-devel] [PATCH 21/23] avfilter/vf_setrange: change outlink color_range too

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_setparams.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index 8427f98ba8..98a4aa2ad3 100644
--- a/libavfilter/vf_setparams.c
+++ b/libavfilter/vf_setparams.c
@@ -56,6 +56,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 return ff_filter_frame(ctx->outputs[0], frame);
 }
 
+static int config_output(AVFilterLink *outlink)
+{
+SetParamsContext *s = outlink->src->priv;
+
+if (s->color_range >= 0)
+outlink->color_range = s->color_range;
+
+return 0;
+}
+
 static const AVFilterPad inputs[] = {
 {
 .name = "default",
@@ -69,6 +79,7 @@ static const AVFilterPad outputs[] = {
 {
 .name = "default",
 .type = AVMEDIA_TYPE_VIDEO,
+.config_props = config_output,
 },
 { NULL }
 };
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 19/23] libavcodec/hevcdec: remove usage of YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/hevcdec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 433a7056ea..d1b54b1db5 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -363,7 +363,6 @@ static enum AVPixelFormat get_format(HEVCContext *s, const 
HEVCSPS *sps)
 
 switch (sps->pix_fmt) {
 case AV_PIX_FMT_YUV420P:
-case AV_PIX_FMT_YUVJ420P:
 #if CONFIG_HEVC_DXVA2_HWACCEL
 *fmt++ = AV_PIX_FMT_DXVA2_VLD;
 #endif
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 18/23] avcodec/roqvideoenc: do not use YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/roqvideoenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index ac05123dc6..18f7dd5368 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -1132,7 +1132,8 @@ AVCodec ff_roq_encoder = {
 .init = roq_encode_init,
 .encode2  = roq_encode_frame,
 .close= roq_encode_end,
-.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUVJ444P,
+.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_NONE },
+.color_ranges = (const enum AVColorRange[]){ AVCOL_RANGE_JPEG, -1},
 .priv_class = _class,
 };
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 20/23] avfilter/vf_blackdetect: use color_range from inlink

2017-12-12 Thread Paul B Mahol
Remove YUVJ pixel format usage.

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_blackdetect.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c
index 06ef9988d1..ff4b9eebb9 100644
--- a/libavfilter/vf_blackdetect.c
+++ b/libavfilter/vf_blackdetect.c
@@ -61,13 +61,6 @@ static const AVOption blackdetect_options[] = {
 
 AVFILTER_DEFINE_CLASS(blackdetect);
 
-#define YUVJ_FORMATS \
-AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, 
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P
-
-static const enum AVPixelFormat yuvj_formats[] = {
-YUVJ_FORMATS, AV_PIX_FMT_NONE
-};
-
 static int query_formats(AVFilterContext *ctx)
 {
 static const enum AVPixelFormat pix_fmts[] = {
@@ -76,7 +69,6 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_NV12, AV_PIX_FMT_NV21,
-YUVJ_FORMATS,
 AV_PIX_FMT_NONE
 };
 
@@ -94,7 +86,7 @@ static int config_input(AVFilterLink *inlink)
 blackdetect->black_min_duration =
 blackdetect->black_min_duration_time / av_q2d(inlink->time_base);
 
-blackdetect->pixel_black_th_i = ff_fmt_is_in(inlink->format, yuvj_formats) 
?
+blackdetect->pixel_black_th_i = inlink->color_range == AVCOL_RANGE_JPEG ?
 // luminance_minimum_value + pixel_black_th * luminance_range_size
  blackdetect->pixel_black_th *  255 :
 16 + blackdetect->pixel_black_th * (235 - 16);
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 17/23] avcodec/hevc_ps: do not use YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Color range is already set.

Signed-off-by: Paul B Mahol 
---
 libavcodec/hevc_ps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index a4f7ed60f7..19ec2d7ebf 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -578,8 +578,6 @@ static void decode_vui(GetBitContext *gb, AVCodecContext 
*avctx,
 vui->video_format= get_bits(gb, 3);
 vui->video_full_range_flag   = get_bits1(gb);
 vui->colour_description_present_flag = get_bits1(gb);
-if (vui->video_full_range_flag && sps->pix_fmt == AV_PIX_FMT_YUV420P)
-sps->pix_fmt = AV_PIX_FMT_YUVJ420P;
 if (vui->colour_description_present_flag) {
 vui->colour_primaries= get_bits(gb, 8);
 vui->transfer_characteristic = get_bits(gb, 8);
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 09/23] avcodec/mjpegdec: replace YUVJ pixel formats

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/mjpegdec.c| 18 +-
 libavcodec/tdsc.c|  2 +-
 tests/fate/vcodec.mak|  4 ++--
 tests/ref/fate/api-mjpeg-codec-param |  4 ++--
 tests/ref/fate/exif-image-embedded   |  2 +-
 tests/ref/fate/exif-image-jpg|  2 +-
 6 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index e005dd0cd3..55676d8576 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -467,7 +467,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && 
s->component_id[2] == 'A') {
 s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP : 
AV_PIX_FMT_GBRP16;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -509,7 +509,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x22122100:
 case 0x21211100:
 case 0x22211200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -517,7 +517,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x1100:
 case 0x22112200:
 case 0x1100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -549,7 +549,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 } else {
 if (pix_fmt_id == 0x1400)
 s->upscale_v[1] = s->upscale_v[2] = 1;
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV440P : AV_PIX_FMT_YUVJ440P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV440P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -562,7 +562,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 goto unk_pixfmt;
 s->upscale_h[0] = s->upscale_h[1] = 1;
 } else {
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV422P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 }
@@ -570,13 +570,13 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x3100:
 if (s->bits > 8)
 goto unk_pixfmt;
-s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV444P : 
AV_PIX_FMT_YUVJ444P;
+s->avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 s->upscale_h[1] = s->upscale_h[2] = 2;
 break;
 case 0x22121100:
 case 0x22111200:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV422P : AV_PIX_FMT_YUVJ422P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV422P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
@@ -584,7 +584,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 case 0x2200:
 case 0x4200:
 case 0x2400:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUVJ420P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 else  s->avctx->pix_fmt = AV_PIX_FMT_YUV420P16;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
 if (pix_fmt_id == 0x4200) {
@@ -598,7 +598,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 }
 break;
 case 0x4100:
-if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? 
AV_PIX_FMT_YUV411P : AV_PIX_FMT_YUVJ411P;
+if (s->bits <= 8) s->avctx->pix_fmt = AV_PIX_FMT_YUV411P;
 else
 goto unk_pixfmt;
 s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG : 
AVCOL_RANGE_JPEG;
diff --git a/libavcodec/tdsc.c b/libavcodec/tdsc.c
index 4182404cf0..af92ef6ccc 100644
--- a/libavcodec/tdsc.c
+++ b/libavcodec/tdsc.c
@@ -357,7 +357,7 @@ static int 

[FFmpeg-devel] [PATCH 16/23] avcodec/h264_slice: do not use YUVJ pixel formats

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/h264_slice.c | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index aad5484588..a75ab08c29 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -820,15 +820,10 @@ static enum AVPixelFormat get_pixel_format(H264Context 
*h, int force_callback)
 if (CHROMA444(h)) {
 if (h->avctx->colorspace == AVCOL_SPC_RGB)
 *fmt++ = AV_PIX_FMT_GBRP;
-else if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ444P;
 else
 *fmt++ = AV_PIX_FMT_YUV444P;
 } else if (CHROMA422(h)) {
-if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ422P;
-else
-*fmt++ = AV_PIX_FMT_YUV422P;
+*fmt++ = AV_PIX_FMT_YUV422P;
 } else {
 #if CONFIG_H264_DXVA2_HWACCEL
 *fmt++ = AV_PIX_FMT_DXVA2_VLD;
@@ -845,8 +840,6 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 #endif
 if (h->avctx->codec->pix_fmts)
 choices = h->avctx->codec->pix_fmts;
-else if (h->avctx->color_range == AVCOL_RANGE_JPEG)
-*fmt++ = AV_PIX_FMT_YUVJ420P;
 else
 *fmt++ = AV_PIX_FMT_YUV420P;
 }
@@ -992,17 +985,6 @@ fail:
 return ret;
 }
 
-static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
-{
-switch (a) {
-case AV_PIX_FMT_YUVJ420P: return AV_PIX_FMT_YUV420P;
-case AV_PIX_FMT_YUVJ422P: return AV_PIX_FMT_YUV422P;
-case AV_PIX_FMT_YUVJ444P: return AV_PIX_FMT_YUV444P;
-default:
-return a;
-}
-}
-
 static int h264_init_ps(H264Context *h, const H264SliceContext *sl, int 
first_slice)
 {
 const SPS *sps;
@@ -1047,7 +1029,7 @@ static int h264_init_ps(H264Context *h, const 
H264SliceContext *sl, int first_sl
  || h->mb_height != sps->mb_height
 ));
 if (h->avctx->pix_fmt == AV_PIX_FMT_NONE
-|| (non_j_pixfmt(h->avctx->pix_fmt) != 
non_j_pixfmt(get_pixel_format(h, 0
+|| (h->avctx->pix_fmt != get_pixel_format(h, 0)))
 must_reinit = 1;
 
 if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 15/23] avcodec/mdec: replace YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/mdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index 330b761279..637158d231 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -227,7 +227,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 ff_init_scantable(a->idsp.idct_permutation, >scantable,
   ff_zigzag_direct);
 
-avctx->pix_fmt  = AV_PIX_FMT_YUVJ420P;
+avctx->pix_fmt  = AV_PIX_FMT_YUV420P;
 avctx->color_range = AVCOL_RANGE_JPEG;
 
 /* init q matrix */
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 14/23] avcodec/roqvideodec: replace YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/roqvideodec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/roqvideodec.c b/libavcodec/roqvideodec.c
index 0ab7d399d6..c5b7bbe236 100644
--- a/libavcodec/roqvideodec.c
+++ b/libavcodec/roqvideodec.c
@@ -190,7 +190,7 @@ static av_cold int roq_decode_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 }
 
-avctx->pix_fmt = AV_PIX_FMT_YUVJ444P;
+avctx->pix_fmt = AV_PIX_FMT_YUV444P;
 avctx->color_range = AVCOL_RANGE_JPEG;
 
 return 0;
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 12/23] avcodec/svq3: replace YUVJ pixel format

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/svq3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c
index a937b2f951..4c6d838a15 100644
--- a/libavcodec/svq3.c
+++ b/libavcodec/svq3.c
@@ -1158,7 +1158,7 @@ static av_cold int svq3_decode_init(AVCodecContext *avctx)
 ff_hpeldsp_init(>hdsp, avctx->flags);
 ff_tpeldsp_init(>tdsp);
 
-avctx->pix_fmt = AV_PIX_FMT_YUVJ420P;
+avctx->pix_fmt = AV_PIX_FMT_YUV420P;
 avctx->color_range = AVCOL_RANGE_JPEG;
 
 s->avctx = avctx;
@@ -1652,6 +1652,6 @@ AVCodec ff_svq3_decoder = {
 .capabilities   = AV_CODEC_CAP_DRAW_HORIZ_BAND |
   AV_CODEC_CAP_DR1 |
   AV_CODEC_CAP_DELAY,
-.pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUVJ420P,
+.pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
  AV_PIX_FMT_NONE},
 };
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 11/23] avcodec/mjpegenc: add support for non-YUVJ formats

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/mjpegenc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index d2fcb8e191..4824406bcb 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -415,8 +415,10 @@ AVCodec ff_mjpeg_encoder = {
 .close  = ff_mpv_encode_end,
 .capabilities   = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS 
| AV_CODEC_CAP_INTRA_ONLY,
 .pix_fmts   = (const enum AVPixelFormat[]) {
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, 
AV_PIX_FMT_NONE
 },
+.color_ranges   = (const enum AVColorRange[]){AVCOL_RANGE_JPEG, -1},
 .priv_class = _class,
 };
 #endif
@@ -439,8 +441,9 @@ AVCodec ff_amv_encoder = {
 .encode2= amv_encode_picture,
 .close  = ff_mpv_encode_end,
 .pix_fmts   = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
 },
+.color_ranges   = (const enum AVColorRange[]){AVCOL_RANGE_JPEG, -1},
 .priv_class = _class,
 };
 #endif
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 07/23] avcodec/proresenc: prores supports limited color range only

2017-12-12 Thread Paul B Mahol
Add .color_range field to encoder's AVCodec struct.

Signed-off-by: Paul B Mahol 
---
 libavcodec/proresenc_anatoliy.c | 2 ++
 libavcodec/proresenc_kostya.c   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 0516066163..38e7839fe3 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -611,6 +611,7 @@ AVCodec ff_prores_aw_encoder = {
 .close  = prores_encode_close,
 .encode2= prores_encode_frame,
 .pix_fmts   = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV422P10, 
AV_PIX_FMT_NONE},
+.color_ranges   = (const enum AVColorRange[]){AVCOL_RANGE_MPEG, -1},
 .capabilities   = AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
 .profiles   = profiles
 };
@@ -625,6 +626,7 @@ AVCodec ff_prores_encoder = {
 .close  = prores_encode_close,
 .encode2= prores_encode_frame,
 .pix_fmts   = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV422P10, 
AV_PIX_FMT_NONE},
+.color_ranges   = (const enum AVColorRange[]){AVCOL_RANGE_MPEG, -1},
 .capabilities   = AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
 .profiles   = profiles
 };
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 149dc81b3c..1ce1737dbd 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1367,5 +1367,6 @@ AVCodec ff_prores_ks_encoder = {
   AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
   AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_NONE
   },
+.color_ranges   = (const enum AVColorRange[]){ AVCOL_RANGE_MPEG, -1 },
 .priv_class = _class,
 };
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 04/23] avfilter/buffersink: export color_range from filtergraph output

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/buffersink.c | 1 +
 libavfilter/buffersink.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 0f87b5439a..897396cac4 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -194,6 +194,7 @@ MAKE_AVFILTERLINK_ACCESSOR(AVRational   , frame_rate
 )
 MAKE_AVFILTERLINK_ACCESSOR(int  , w  )
 MAKE_AVFILTERLINK_ACCESSOR(int  , h  )
 MAKE_AVFILTERLINK_ACCESSOR(AVRational   , sample_aspect_ratio)
+MAKE_AVFILTERLINK_ACCESSOR(enum AVColorRange, color_range)
 
 MAKE_AVFILTERLINK_ACCESSOR(int  , channels   )
 MAKE_AVFILTERLINK_ACCESSOR(uint64_t , channel_layout )
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index 21d6bb505b..e6d6504832 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -114,6 +114,7 @@ AVRational   av_buffersink_get_frame_rate  
(const AVFilterContext *c
 int  av_buffersink_get_w   (const AVFilterContext 
*ctx);
 int  av_buffersink_get_h   (const AVFilterContext 
*ctx);
 AVRational   av_buffersink_get_sample_aspect_ratio (const AVFilterContext 
*ctx);
+enum AVColorRange av_buffersink_get_color_range(const AVFilterContext 
*ctx);
 
 int  av_buffersink_get_channels(const AVFilterContext 
*ctx);
 uint64_t av_buffersink_get_channel_layout  (const AVFilterContext 
*ctx);
-- 
2.11.0

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


[FFmpeg-devel] [PATCH 10/23] avcodec/mjpegdec: remove YUVJ pixel format usage

2017-12-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/mjpegdec.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 55676d8576..160bbfd34b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2415,12 +2415,9 @@ the_end:
 
 if (AV_RB32(s->upscale_h)) {
 int p;
-av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
-   avctx->pix_fmt == AV_PIX_FMT_YUV444P  ||
-   avctx->pix_fmt == AV_PIX_FMT_YUVJ440P ||
+av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUV444P  ||
avctx->pix_fmt == AV_PIX_FMT_YUV440P  ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P ||
-   avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P  ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P16||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P  ||
@@ -2476,14 +2473,10 @@ the_end:
 }
 if (AV_RB32(s->upscale_v)) {
 int p;
-av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVJ444P ||
-   avctx->pix_fmt == AV_PIX_FMT_YUV444P  ||
-   avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
+av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUV444P ||
avctx->pix_fmt == AV_PIX_FMT_YUV422P  ||
-   avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
avctx->pix_fmt == AV_PIX_FMT_YUV420P  ||
avctx->pix_fmt == AV_PIX_FMT_YUV440P  ||
-   avctx->pix_fmt == AV_PIX_FMT_YUVJ440P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA444P ||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P  ||
avctx->pix_fmt == AV_PIX_FMT_YUVA420P16||
-- 
2.11.0

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


[FFmpeg-devel] [PATCH] avfilter/drawbox+drawgrid - add option to prevent overwriting, of source pixels

2017-12-12 Thread Gyan Doshi
As noted in ticket #6911, drawbox and drawgrids implement anomalous 
behaviour if the source or user-color has alpha - source pixels are 
destroyed. Patch introduces new boolean option, whose default value, 
allows both expected result and current behaviour.


Regards,
Gyan
From cc2979978a8c101588c237c0bc9b6c03731b10e9 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 11 Dec 2017 22:35:18 +0530
Subject: [PATCH] avfilter/drawbox+drawgrid - add option to prevent overwriting
 of source pixels

If the user-supplied color in drawbox and drawgrid filters is non-opaque,
the box & grid painting overwrites the input's pixels (including alpha).
Users typically expect the alpha of the specified color to only act as a key
for compositing on top of the main input.

Added option allows users to select between replacement and composition.
Tested and documented.
---
 doc/filters.texi | 10 ++
 libavfilter/vf_drawbox.c |  7 +--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 3346438231..70105b928a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7146,6 +7146,11 @@ The expression which sets the thickness of the box edge.
 A value of @code{fill} will create a filled box. Default value is @code{3}.
 
 See below for the list of accepted constants.
+
+@item replace
+Applicable if the input has alpha. With value @code{1}, the pixels of the 
painted box
+will overwrite the video's color and alpha pixels.
+Default is @code{0}, which composites the box onto the input, leaving the 
video's alpha intact.
 @end table
 
 The parameters for @var{x}, @var{y}, @var{w} and @var{h} and @var{t} are 
expressions containing the
@@ -7243,6 +7248,11 @@ video with inverted luma.
 The expression which sets the thickness of the grid line. Default value is 
@code{1}.
 
 See below for the list of accepted constants.
+
+@item replace
+Applicable if the input has alpha. With @code{1} the pixels of the painted grid
+will overwrite the video's color and alpha pixels.
+Default is @code{0}, which composites the grid onto the input, leaving the 
video's alpha intact.
 @end table
 
 The parameters for @var{x}, @var{y}, @var{w} and @var{h} and @var{t} are 
expressions containing the
diff --git a/libavfilter/vf_drawbox.c b/libavfilter/vf_drawbox.c
index d351846594..c9cb63dbd1 100644
--- a/libavfilter/vf_drawbox.c
+++ b/libavfilter/vf_drawbox.c
@@ -80,6 +80,7 @@ typedef struct DrawBoxContext {
 char *w_expr, *h_expr; ///< expression for width and height
 char *t_expr;  ///< expression for thickness
 int have_alpha;
+int replace;
 } DrawBoxContext;
 
 static const int NUM_EXPR_EVALS = 5;
@@ -213,7 +214,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 int plane, x, y, xb = s->x, yb = s->y;
 unsigned char *row[4];
 
-if (s->have_alpha) {
+if (s->have_alpha && s->replace) {
 for (y = FFMAX(yb, 0); y < frame->height && y < (yb + s->h); y++) {
 row[0] = frame->data[0] + y * frame->linesize[0];
 row[3] = frame->data[3] + y * frame->linesize[3];
@@ -286,6 +287,7 @@ static const AVOption drawbox_options[] = {
 { "c", "set color of the box", 
OFFSET(color_str), AV_OPT_TYPE_STRING, { .str = "black" }, CHAR_MIN, CHAR_MAX, 
FLAGS },
 { "thickness", "set the box thickness",
OFFSET(t_expr),AV_OPT_TYPE_STRING, { .str="3" },   CHAR_MIN, CHAR_MAX, 
FLAGS },
 { "t", "set the box thickness",
OFFSET(t_expr),AV_OPT_TYPE_STRING, { .str="3" },   CHAR_MIN, CHAR_MAX, 
FLAGS },
+{ "replace",   "replace color & alpha",
OFFSET(replace),   AV_OPT_TYPE_BOOL,   { .i64=0 }, 0,1,
FLAGS },
 { NULL }
 };
 
@@ -354,7 +356,7 @@ static int drawgrid_filter_frame(AVFilterLink *inlink, 
AVFrame *frame)
 int plane, x, y;
 uint8_t *row[4];
 
-if (drawgrid->have_alpha) {
+if (drawgrid->have_alpha && drawgrid->replace) {
 for (y = 0; y < frame->height; y++) {
 row[0] = frame->data[0] + y * frame->linesize[0];
 row[3] = frame->data[3] + y * frame->linesize[3];
@@ -418,6 +420,7 @@ static const AVOption drawgrid_options[] = {
 { "c", "set color of the grid",   OFFSET(color_str), 
AV_OPT_TYPE_STRING, { .str = "black" }, CHAR_MIN, CHAR_MAX, FLAGS },
 { "thickness", "set grid line thickness", OFFSET(t_expr),
AV_OPT_TYPE_STRING, {.str="1"}, CHAR_MIN, CHAR_MAX, FLAGS },
 { "t", "set grid line thickness", OFFSET(t_expr),
AV_OPT_TYPE_STRING, {.str="1"}, CHAR_MIN, CHAR_MAX, FLAGS },
+{ "replace",   "replace color & alpha",   OFFSET(replace),   
AV_OPT_TYPE_BOOL,   { .i64=0 }, 0,1,FLAGS },
 { NULL }
 };
 
-- 
2.11.1.windows.1___
ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH] configure: Fix detection of vp9 decoder/encoder

2017-12-12 Thread Felix Matouschek

This fixes the detection of the vp9 decoder/encoder.

The vp9 decoder/encoder needs libm to successfully link, -lm was missing 
in the check_lib calls for vp9 in configure.From 0b5bbd7c30f3a76b2e0ab6ceae2bfaebe944b279 Mon Sep 17 00:00:00 2001
From: Felix Matouschek 
Date: Tue, 12 Dec 2017 10:42:40 +0100
Subject: [PATCH] configure: Fix detection of vp9 decoder/encoder
To: ffmpeg-devel@ffmpeg.org

The vp9 decoder/encoder needs libm to successfully link,
-lm was missing in the check_lib calls for vp9

Signed-off-by: Felix Matouschek 
---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 8cf48ae1cf..4581850fe5 100755
--- a/configure
+++ b/configure
@@ -5918,11 +5918,11 @@ enabled libvpx&& {
 }
 enabled libvpx_vp9_decoder && {
 check_pkg_config libvpx_vp9_decoder "vpx >= 1.4.0" "vpx/vpx_decoder.h vpx/vp8dx.h" vpx_codec_vp9_dx ||
-check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
+check_lib libvpx_vp9_decoder "vpx/vpx_decoder.h vpx/vp8dx.h" "vpx_codec_vp9_dx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx -lm
 }
 enabled libvpx_vp9_encoder && {
 check_pkg_config libvpx_vp9_encoder "vpx >= 1.4.0" "vpx/vpx_encoder.h vpx/vp8cx.h" vpx_codec_vp9_cx ||
-check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx
+check_lib libvpx_vp9_encoder "vpx/vpx_encoder.h vpx/vp8cx.h" "vpx_codec_vp9_cx VPX_IMG_FMT_HIGHBITDEPTH" -lvpx -lm
 }
 if disabled_all libvpx_vp8_decoder libvpx_vp9_decoder libvpx_vp8_encoder libvpx_vp9_encoder; then
 die "libvpx enabled but no supported decoders found"
-- 
2.14.1.windows.1

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


Re: [FFmpeg-devel] [PATCH 24/29] avcodec/qsv: remove YUVJ pixel format usage

2017-12-12 Thread Paul B Mahol
On 12/12/17, Bang He  wrote:
> hi, why need to remove this format?

Because it is deprecated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext hw_device_ctx if set

2017-12-12 Thread Matthieu Bouron
On Mon, Dec 11, 2017 at 10:10:24PM +, Mark Thompson wrote:
> On 11/12/17 12:34, Matthieu Bouron wrote:
> >>
> >> New patch attached fixing errors in get_format() by keeping the original
> >> AVCodecHWConfigInternal (ad-hoc) and adding a new one (hw-device) with the
> >> device_type field set to the MediaCodec.
> >>
> >> The updated patchset works without errors with both the old hwaccel method 
> >> and
> >> the new device_ctx method.
> > 
> > From 2bbdae2141ba8ca8db54175f4440ac8190f5953d Mon Sep 17 00:00:00 2001
> > From: Aman Gupta 
> > Date: Sun, 3 Dec 2017 17:32:22 -0800
> > Subject: [PATCH 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext
> >  hw_device_ctx if set
> > 
> > Signed-off-by: Matthieu Bouron 
> > ---
> >  libavcodec/mediacodecdec.c|  8 
> >  libavcodec/mediacodecdec_common.c | 14 +-
> >  2 files changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > index 86cc629430..c8ad0b80e7 100644
> > --- a/libavcodec/mediacodecdec.c
> > +++ b/libavcodec/mediacodecdec.c
> > @@ -543,6 +543,14 @@ static const AVCodecHWConfigInternal 
> > *mediacodec_hw_configs[] = {
> >  },
> >  .hwaccel = NULL,
> >  },
> > +&(const AVCodecHWConfigInternal) {
> > +.public  = {
> > +.pix_fmt = AV_PIX_FMT_MEDIACODEC,
> > +.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX,
> 
> This wants to be combined with the previous entry (or together the methods): 
> ff_get_format() looks for the first entry matching the pix_fmt, so it will 
> never find this one.  I think this might work anyway because AD_HOC is 
> technically "do whatever you like, I can't check it", but it also wouldn't 
> notice e.g. a non-matching device in that case.

Patch updated with the two entries merged. Thanks.
I tested with both methods (hw device ctx and the old hwaccel way) and no
error came up.

-- 
Matthieu B.
>From 7266745203a2467719f21a31c8b4f94390eaeb6b Mon Sep 17 00:00:00 2001
From: Aman Gupta 
Date: Sun, 3 Dec 2017 17:32:22 -0800
Subject: [PATCH 2/2] libavcodec/mediacodec: use AVMediaCodecDeviceContext
 hw_device_ctx if set

Signed-off-by: Matthieu Bouron 
---
 libavcodec/mediacodecdec.c|  5 +++--
 libavcodec/mediacodecdec_common.c | 14 +-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 86cc629430..7b282a1d68 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -538,8 +538,9 @@ static const AVCodecHWConfigInternal 
*mediacodec_hw_configs[] = {
 &(const AVCodecHWConfigInternal) {
 .public  = {
 .pix_fmt = AV_PIX_FMT_MEDIACODEC,
-.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
-.device_type = AV_HWDEVICE_TYPE_NONE,
+.methods = AV_CODEC_HW_CONFIG_METHOD_AD_HOC |
+   AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX,
+.device_type = AV_HWDEVICE_TYPE_MEDIACODEC,
 },
 .hwaccel = NULL,
 },
diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index cb2f6ae5e5..a9147f3a08 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "libavutil/common.h"
+#include "libavutil/hwcontext_mediacodec.h"
 #include "libavutil/mem.h"
 #include "libavutil/log.h"
 #include "libavutil/pixfmt.h"
@@ -476,7 +477,18 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 if (pix_fmt == AV_PIX_FMT_MEDIACODEC) {
 AVMediaCodecContext *user_ctx = avctx->hwaccel_context;
 
-if (user_ctx && user_ctx->surface) {
+if (avctx->hw_device_ctx) {
+AVHWDeviceContext *device_ctx = 
(AVHWDeviceContext*)(avctx->hw_device_ctx->data);
+if (device_ctx->type == AV_HWDEVICE_TYPE_MEDIACODEC) {
+if (device_ctx->hwctx) {
+AVMediaCodecDeviceContext *mediacodec_ctx = 
(AVMediaCodecDeviceContext *)device_ctx->hwctx;
+s->surface = 
ff_mediacodec_surface_ref(mediacodec_ctx->surface, avctx);
+av_log(avctx, AV_LOG_INFO, "Using surface %p\n", 
s->surface);
+}
+}
+}
+
+if (!s->surface && user_ctx && user_ctx->surface) {
 s->surface = ff_mediacodec_surface_ref(user_ctx->surface, avctx);
 av_log(avctx, AV_LOG_INFO, "Using surface %p\n", s->surface);
 }
-- 
2.15.1

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


Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

2017-12-12 Thread Paul B Mahol
On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 3:36 PM, James Almer  wrote:
>> On 12/11/2017 11:28 AM, Hendrik Leppkes wrote:
>>> On Mon, Dec 11, 2017 at 2:22 PM, Paul B Mahol  wrote:
 On 12/11/17, Hendrik Leppkes  wrote:
> On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol 
> wrote:
>>>
>>> Fine, but it's inevitable that the encoder supports the J formats
>>> still
>>> for a while.
>>
>>
>> Why are you all dismissive about this?
>
>
> Because we have an established way to remove things like this, and
> that doesn't happen over night.
> Its not ok for stuff to stop working without a replacement in place
> for a sufficient time before that, so people can migrate.
>
> First, implement replacement and add visible deprecation messages -
> and then wait the established deprecation period before actually
> removing it.

 Bullshit, J formats are deprecated for ages.
>>>
>>>
>>> A deprecation is only meaningful if there is actually a replacement
>>> you can use - which did not exist yet.
>>>
>>> Want to encode jpeg right now? Have to use J format. No way around
>>> that. And many more of such cases.
>>> As such, you can't just make the J format non-functional over night.
>>> Thats not going to fly.
>>
>> And how will we get users to migrate? We have printed a "deprecated,
>> don't use" message that has been ignored by absolutely everyone for a
>> whole decade. What could we do or add now that will actually get people
>> to read and pay attention to a "for real now guise" warning?
>>
>> The current warning gives instructions about the supposed replacement,
>> yet it doesn't work. Even if it suddenly starts to work, who the hell is
>> going to try it again after it failed time and time again for like
>> twenty different releases?
>
> Thats no excuse for blindly breaking it without even giving users a
> chance to migrate. Migration period has to be observed. If users still
> don't react, there is nothing we can do about that - but we can do our
> best to give them a chance.
>
> The message currently is being generated by swscale as far as I can
> tell, unless I missed it somewhere else. Moving it to a more prominent
> position (perhaps encoder/filter init) and rewording it would be a
> good start.
>
>>
>>>
>>> Either do it properly, or don't do it at all.
>>
>> Someone finally started to work on getting rid of one the oldest, most
>> annoying hacks in the codebase. Help or suggestions in how to implement
>> said compatibility layer and deprecation period would be much better
>> than this.
>
> We tried suggesting, so we get responses like "this is bullshit".
> Rules apply even to the people that do the work.
>
> Supporting both J and non-J formats in an encoder doesn't require
> help, its as simple as keeping both as supported input formats for the
> encoders and filters, for the time being.
> Or if you want something more elaborate, just re-mapping of the J
> format to non-J + color_range in the generic code somewhere, still
> easy.

I do not plan to ditch J formats immediately from encoders.

I just want there exist both paths one without J and another one with J.

Do you want it in little small steps so everybody can understand problem?

Do you want adding new item(s) to AVCodec? I see no other reason how to proceed.

I would like to make anyone happy, but looks like nobody gives a shit about my
work and instead just want current status.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 24/29] avcodec/qsv: remove YUVJ pixel format usage

2017-12-12 Thread Bang He
hi, why need to remove this format?

On Sun, Dec 10, 2017 at 9:14 PM, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/qsv.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 250b4e61e3..6eee40a222 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -171,7 +171,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format,
> uint32_t *fourcc)
>  {
>  switch (format) {
>  case AV_PIX_FMT_YUV420P:
> -case AV_PIX_FMT_YUVJ420P:
>  case AV_PIX_FMT_NV12:
>  *fourcc = MFX_FOURCC_NV12;
>  return AV_PIX_FMT_NV12;
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/mjpeg: remove YUVJ mentions

2017-12-12 Thread Paul B Mahol
On 12/11/17, Michael Niedermayer  wrote:
> On Mon, Dec 11, 2017 at 10:58:41PM +0100, Paul B Mahol wrote:
>> On 12/11/17, Michael Niedermayer  wrote:
>> > On Mon, Dec 11, 2017 at 12:09:33PM -0500, Vittorio Giovara wrote:
>> >> >* On 12/8/17, Paul B Mahol http://gmail.com>>*
>> >> >> On 12/8/17, Vittorio Giovara > >> >> > wrote:
>> >> >*> If we were to break this feature, I'd suggest going the full route
>> >> > of
>> >> *>*> adding a PixelFormaton and work on a sws alternative (one is
>> >> allowed
>> >> to
>> >> *>*> dream no?).
>> >> *>
>> >> > This is step to right direction, why would adding yet another API be
>> >> > better
>> >> > solution?
>> >> >
>> >> > J formats are hack - misfeature - most obvious reason why nobody
>> >> > added
>> >> > 10bit J formats, or one of alpha. Calling it otherwise, points to
>> >> > severe
>> >> > lack of understanding of problem.
>> >>
>> >> I am perfectly aware that the J formats are a hack, that's why it
>> >> would
>> >> be
>> >> nice to avoid introducing more hacks to get rid of them.
>> >> As it has been pointed out in the other thread, simply adding
>> >> .color_range
>> >> does not properly solve this problem, it is a breaking change without
>> >> proper deprecation period, and in general it seems like not a good
>> >> idea
>> >> API-wise to add an endless number of fields to AVCodec.
>> >> Like I said, having dealt with the problem in the past, the only way I
>> >> suggest to go forward is decoupling codec/filter negotiation from
>> >> pixel
>> >> formats and use a different scaling/color conversion library.
>> >
>> > The problem is completely unrelated to the scaling/color conversion
>> > library. Its difficult to remove them from libavcodec and libavfilter.
>> > And i belive paul is doing good and hard work here.
>> >
>> > If there is a issue in swscale from spliting range out, iam happy to
>> > look into fixing that if someone gives me a reproduceable test case
>> >
>> > thx
>>
>> Just create separate pixel format for every color range, bitdepth,
>> colorspace, etc combination.
>>
>> Or you want pixel formats as objects?
>>
>
>> struct AVPixelFormatHax {
>> enum ColorMissingSpace color_space;
>> enum ColorFillRange color_range;
>> enum ColorPrimus  color_primaries;
>> int  nb_components;
>> int *bitdepths;
>> int  nb_planes;
>>
>> Copy big pixdesc struct and add more stuff here... (Can this be
>> done in pure C?)
>> }
>
> If you go for a struct, spliting this in 2 parts
> the first being the physical layout of the samples
> (plane numbers, depth packing variant)
> and the 2nd being the logical
> that is what the samples actually represent (colorspace, range, ...)
> might make sense
>
> struct AVPixelSoup {
> enum AVPixelFormat pix_fmt; // This describes the physical layout
> struct ColorWhateverDescriptor color_descriptor; // this described the
> logical content
> }
>
> struct ColorWhateverDescriptor{
> enum ColorMissingSpace color_space;
> enum ColorFillRange color_range;
> enum ColorPrimus  color_primaries;
> }
>
> Some advantages of this are
> pixel_formats as they are currently largly stay (YUVJ goes,
> planar RGB might be merged with planar YUV or may be left if its more
> practical, RGB might be merged with BGR or left)
>
> because pixel formats largly stay as they are alot of code and API
> related to it should not need to be changed.
>
> Code that cares just about physical layout (copy, crop, ...) can just
> work with the pixel_formats as it always did
>
> about putting everything in a single (large) enum, i wonder how
> large that would become
> But a struct similarly could be a problem here if we have lists of all
> supported variants that litterally contain an element for each specific
> variant.
>
>
> As far as iam concerned iam really happy with any API/implementation
> that works and is practical(maintainable / has someone wanting to
> implement it / ...)
> The current code has quite a few shortcommings as it cannot
> properly list or negotiate the support for colorspaces and others.
>
> Iam not sure i should mention it or not as it might confuse but its
> related
> if one takes a step back from this and looks, the issue goes beyond pixel
> formats.
> codecs can support some pixel formats in specific profiles only
> or with specific resolutions only.
> At that level merging things in a ever growing struct is not possible
> anymore and different solutions would need to be found
> I wrote av_opt_query_ranges / AVOptionRanges to allow "introspection"
> of such information from any object that supports AVOptions.
> But this system was AFAIK largly ignored by people
> Of course its also solving a different problem than YUVJ removial here.
> But maybe it or a similar system could be usefull for more complex
> cases where a encoder or filter wants to convey to the user app what
> ranges of fields it supports 

Re: [FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

2017-12-12 Thread wm4
On Tue, 12 Dec 2017 09:08:51 +0100
Hendrik Leppkes  wrote:

> On Tue, Dec 12, 2017 at 9:04 AM, wm4  wrote:
> > On Tue, 12 Dec 2017 08:50:01 +0100
> > Hendrik Leppkes  wrote:
> >  
> >> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
> >>  wrote:  
> >> > On 12/8/2017 2:27 AM, Michael Niedermayer wrote:  
> >> >>
> >> >> On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:  
> >> >>>
> >> >>> On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
> >> >>>  wrote:  
> >> 
> >>  Its already done by lockmgr.
> >> 
> >>  Signed-off-by: Rostislav Pehlivanov 
> >>  ---
> >>    libavcodec/utils.c | 6 --
> >>    1 file changed, 6 deletions(-)
> >> 
> >>  diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >>  index baf09119fe..796d24dcbb 100644
> >>  --- a/libavcodec/utils.c
> >>  +++ b/libavcodec/utils.c
> >>  @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum 
> >>  AVLockOp
> >>  op) = NULL;
> >>    #endif
> >> 
> >> 
> >>  -static atomic_bool ff_avcodec_locked;
> >>    static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
> >>    static void *codec_mutex;
> >>    static void *avformat_mutex;
> >>  @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex,
> >>  enum AVLockOp op))
> >> 
> >>    int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
> >>    {
> >>  -_Bool exp = 0;
> >>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>  !codec->init)
> >>    return 0;
> >> 
> >>  @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
> >>  const AVCodec *codec)
> >>   atomic_load(_thread_counter));
> >>    if (!lockmgr_cb)
> >>    av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set,
> >>  please see av_lockmgr_register()\n");
> >>  -atomic_store(_avcodec_locked, 1);
> >>    ff_unlock_avcodec(codec);
> >>    return AVERROR(EINVAL);
> >>    }
> >>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, 
> >>  ,
> >>  1));
> >>    return 0;
> >>    }
> >> 
> >>    int ff_unlock_avcodec(const AVCodec *codec)
> >>    {
> >>  -_Bool exp = 1;
> >>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> >>  !codec->init)
> >>    return 0;
> >> 
> >>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, 
> >>  ,
> >>  0));
> >>    atomic_fetch_add(_thread_counter, -1);
> >>    if (lockmgr_cb) {
> >>    if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
> >>  --
> >>  2.15.1.424.g9478a66081
> >>   
> >> >>>
> >> >>> These variables never performed any locking, they only existed as a
> >> >>> sanity check that lock/unlock is always called in pairs. If that is
> >> >>> really required is up for discussion.  
> >> >>
> >> >>
> >> >> They shuld be usefull to detect some bugs related to locking
> >> >>
> >> >> [...]  
> >> >
> >> >
> >> > I don't have the most recent response to this e-mail, from Hendrik, in my
> >> > inbox anymore, but I spent some time reviewing the patch, and I also 
> >> > don't
> >> > see any point to making access to ff_avcodec_locked atomic.
> >> >
> >> > Prior to patch
> >> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> >> > , ff_avcodec_locked was declared as volatile and also specified as an 
> >> > extern
> >> > in internal.h.  Neither the volatile declaration nor the global exposure 
> >> > of
> >> > ff_avcodec_locked are necessary.  The patch eliminated the global 
> >> > exposure,
> >> > but it replaced "volatile" with "atomic".
> >> >
> >> > Write access to ff_avcodec_locked is already protected via lockmgr_cb. 
> >> > If,
> >> > somehow, lockmgr_cb is NULL, which shouldn't happen in practice, the
> >> > entangled_thread_counter backup approach that immediately follows isn't
> >> > sufficient as currently implemented to protect writes to 
> >> > ff_avcodec_locked,
> >> > which makes me wonder why it is there in the first place.  It is 
> >> > possible to
> >> > use entangled_thread_counter in a way that protects access to
> >> > ff_avcodec_locked though, and I think that's the intention of the code.
> >> >
> >> > I think the correct approach is to mostly restore the code prior to patch
> >> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> >> > but to leave ff_avcodec_locked statically declared and eliminate the
> >> > volatile designation.  
> >>
> >> I've reverted the commit last night already.
> >>  
> >> >
> >> > On a separate note, this whole approach of using
> >> > ff_lock_avcodec/ff_unlock_avcodec seems a 

Re: [FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

2017-12-12 Thread Hendrik Leppkes
On Tue, Dec 12, 2017 at 9:04 AM, wm4  wrote:
> On Tue, 12 Dec 2017 08:50:01 +0100
> Hendrik Leppkes  wrote:
>
>> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
>>  wrote:
>> > On 12/8/2017 2:27 AM, Michael Niedermayer wrote:
>> >>
>> >> On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:
>> >>>
>> >>> On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
>> >>>  wrote:
>> 
>>  Its already done by lockmgr.
>> 
>>  Signed-off-by: Rostislav Pehlivanov 
>>  ---
>>    libavcodec/utils.c | 6 --
>>    1 file changed, 6 deletions(-)
>> 
>>  diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>  index baf09119fe..796d24dcbb 100644
>>  --- a/libavcodec/utils.c
>>  +++ b/libavcodec/utils.c
>>  @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp
>>  op) = NULL;
>>    #endif
>> 
>> 
>>  -static atomic_bool ff_avcodec_locked;
>>    static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
>>    static void *codec_mutex;
>>    static void *avformat_mutex;
>>  @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex,
>>  enum AVLockOp op))
>> 
>>    int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>    {
>>  -_Bool exp = 0;
>>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>  !codec->init)
>>    return 0;
>> 
>>  @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
>>  const AVCodec *codec)
>>   atomic_load(_thread_counter));
>>    if (!lockmgr_cb)
>>    av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set,
>>  please see av_lockmgr_register()\n");
>>  -atomic_store(_avcodec_locked, 1);
>>    ff_unlock_avcodec(codec);
>>    return AVERROR(EINVAL);
>>    }
>>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, ,
>>  1));
>>    return 0;
>>    }
>> 
>>    int ff_unlock_avcodec(const AVCodec *codec)
>>    {
>>  -_Bool exp = 1;
>>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>>  !codec->init)
>>    return 0;
>> 
>>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, ,
>>  0));
>>    atomic_fetch_add(_thread_counter, -1);
>>    if (lockmgr_cb) {
>>    if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
>>  --
>>  2.15.1.424.g9478a66081
>> 
>> >>>
>> >>> These variables never performed any locking, they only existed as a
>> >>> sanity check that lock/unlock is always called in pairs. If that is
>> >>> really required is up for discussion.
>> >>
>> >>
>> >> They shuld be usefull to detect some bugs related to locking
>> >>
>> >> [...]
>> >
>> >
>> > I don't have the most recent response to this e-mail, from Hendrik, in my
>> > inbox anymore, but I spent some time reviewing the patch, and I also don't
>> > see any point to making access to ff_avcodec_locked atomic.
>> >
>> > Prior to patch
>> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
>> > , ff_avcodec_locked was declared as volatile and also specified as an 
>> > extern
>> > in internal.h.  Neither the volatile declaration nor the global exposure of
>> > ff_avcodec_locked are necessary.  The patch eliminated the global exposure,
>> > but it replaced "volatile" with "atomic".
>> >
>> > Write access to ff_avcodec_locked is already protected via lockmgr_cb. If,
>> > somehow, lockmgr_cb is NULL, which shouldn't happen in practice, the
>> > entangled_thread_counter backup approach that immediately follows isn't
>> > sufficient as currently implemented to protect writes to ff_avcodec_locked,
>> > which makes me wonder why it is there in the first place.  It is possible 
>> > to
>> > use entangled_thread_counter in a way that protects access to
>> > ff_avcodec_locked though, and I think that's the intention of the code.
>> >
>> > I think the correct approach is to mostly restore the code prior to patch
>> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
>> > but to leave ff_avcodec_locked statically declared and eliminate the
>> > volatile designation.
>>
>> I've reverted the commit last night already.
>>
>> >
>> > On a separate note, this whole approach of using
>> > ff_lock_avcodec/ff_unlock_avcodec seems a little hokey to me.  It is
>> > effectively using a global lock (via lockmgr_cb) to control access to 
>> > avctx,
>> > which should be local to the calling thread.  As implemented, it prevents
>> > two concurrent calls to avcodec_open2() from proceeding simultaneously.  As
>> > far as I can tell, the implementation of avcodec_open2() doesn't modify any
>> > global structures and only modifies avctx. 

Re: [FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

2017-12-12 Thread wm4
On Tue, 12 Dec 2017 08:50:01 +0100
Hendrik Leppkes  wrote:

> On Tue, Dec 12, 2017 at 12:25 AM, Aaron Levinson
>  wrote:
> > On 12/8/2017 2:27 AM, Michael Niedermayer wrote:  
> >>
> >> On Fri, Dec 08, 2017 at 09:49:25AM +0100, Hendrik Leppkes wrote:  
> >>>
> >>> On Fri, Dec 8, 2017 at 6:09 AM, Rostislav Pehlivanov
> >>>  wrote:  
> 
>  Its already done by lockmgr.
> 
>  Signed-off-by: Rostislav Pehlivanov 
>  ---
>    libavcodec/utils.c | 6 --
>    1 file changed, 6 deletions(-)
> 
>  diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>  index baf09119fe..796d24dcbb 100644
>  --- a/libavcodec/utils.c
>  +++ b/libavcodec/utils.c
>  @@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp
>  op) = NULL;
>    #endif
> 
> 
>  -static atomic_bool ff_avcodec_locked;
>    static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
>    static void *codec_mutex;
>    static void *avformat_mutex;
>  @@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex,
>  enum AVLockOp op))
> 
>    int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>    {
>  -_Bool exp = 0;
>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>  !codec->init)
>    return 0;
> 
>  @@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
>  const AVCodec *codec)
>   atomic_load(_thread_counter));
>    if (!lockmgr_cb)
>    av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set,
>  please see av_lockmgr_register()\n");
>  -atomic_store(_avcodec_locked, 1);
>    ff_unlock_avcodec(codec);
>    return AVERROR(EINVAL);
>    }
>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, ,
>  1));
>    return 0;
>    }
> 
>    int ff_unlock_avcodec(const AVCodec *codec)
>    {
>  -_Bool exp = 1;
>    if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
>  !codec->init)
>    return 0;
> 
>  -av_assert0(atomic_compare_exchange_strong(_avcodec_locked, ,
>  0));
>    atomic_fetch_add(_thread_counter, -1);
>    if (lockmgr_cb) {
>    if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
>  --
>  2.15.1.424.g9478a66081
>   
> >>>
> >>> These variables never performed any locking, they only existed as a
> >>> sanity check that lock/unlock is always called in pairs. If that is
> >>> really required is up for discussion.  
> >>
> >>
> >> They shuld be usefull to detect some bugs related to locking
> >>
> >> [...]  
> >
> >
> > I don't have the most recent response to this e-mail, from Hendrik, in my
> > inbox anymore, but I spent some time reviewing the patch, and I also don't
> > see any point to making access to ff_avcodec_locked atomic.
> >
> > Prior to patch
> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> > , ff_avcodec_locked was declared as volatile and also specified as an extern
> > in internal.h.  Neither the volatile declaration nor the global exposure of
> > ff_avcodec_locked are necessary.  The patch eliminated the global exposure,
> > but it replaced "volatile" with "atomic".
> >
> > Write access to ff_avcodec_locked is already protected via lockmgr_cb. If,
> > somehow, lockmgr_cb is NULL, which shouldn't happen in practice, the
> > entangled_thread_counter backup approach that immediately follows isn't
> > sufficient as currently implemented to protect writes to ff_avcodec_locked,
> > which makes me wonder why it is there in the first place.  It is possible to
> > use entangled_thread_counter in a way that protects access to
> > ff_avcodec_locked though, and I think that's the intention of the code.
> >
> > I think the correct approach is to mostly restore the code prior to patch
> > https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
> > but to leave ff_avcodec_locked statically declared and eliminate the
> > volatile designation.  
> 
> I've reverted the commit last night already.
> 
> >
> > On a separate note, this whole approach of using
> > ff_lock_avcodec/ff_unlock_avcodec seems a little hokey to me.  It is
> > effectively using a global lock (via lockmgr_cb) to control access to avctx,
> > which should be local to the calling thread.  As implemented, it prevents
> > two concurrent calls to avcodec_open2() from proceeding simultaneously.  As
> > far as I can tell, the implementation of avcodec_open2() doesn't modify any
> > global structures and only modifies avctx.  I would think that a better
> > approach would be to use a lock that is specific to the avctx object,
> > perhaps one stored in avctx->internal. This approach would also eliminate
> > the