Re: [FFmpeg-devel] [PATCH] avutil/pixfmt: remove superfluous define

2017-05-30 Thread James Almer 
On 5/23/2017 7:07 PM, James Almer wrote:
> It's an AVColorSpace value since 82ad9cbd32c873bced9adf4a2bb67dcda7294c61.
> 
> Signed-off-by: James Almer 
> ---
>  libavutil/pixfmt.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 3c915c6421..6b7eea8c4e 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -467,8 +467,6 @@ enum AVColorSpace {
>  AVCOL_SPC_SMPTE2085   = 11, ///< SMPTE 2085, Y'D'zD'x
>  AVCOL_SPC_NB///< Not part of ABI
>  };
> -#define AVCOL_SPC_YCGCO AVCOL_SPC_YCOCG
> -
>  
>  /**
>   * MPEG vs JPEG YUV range.

Will push this tomorrow if nobody objects.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/audiotoolboxdec: always use a copy of the AVCodecContext extradata

2017-05-30 Thread James Almer 
Ping for set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] libavformat/http: Ignore expired cookies

2017-05-30 Thread Micah Galizia 
Signed-off-by: Micah Galizia 
Signed-off-by: Michael Niedermayer 
(cherry picked from commit 28b24670741e1de25bfc7b5ea7c1d6dbae1aef6f)
Signed-off-by: Micah Galizia 
---
 libavformat/http.c | 213 +++--
 1 file changed, 156 insertions(+), 57 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 293a8a7204..d06103ab6d 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -29,6 +29,7 @@
 #include "libavutil/avstring.h"
 #include "libavutil/opt.h"
 #include "libavutil/time.h"
+#include "libavutil/parseutils.h"
 
 #include "avformat.h"
 #include "http.h"
@@ -48,6 +49,8 @@
 #define MAX_REDIRECTS 8
 #define HTTP_SINGLE   1
 #define HTTP_MUTLI2
+#define MAX_EXPIRY19
+#define WHITESPACES " \n\t\r"
 typedef enum {
 LOWER_PROTO,
 READ_HEADERS,
@@ -680,10 +683,112 @@ static int parse_icy(HTTPContext *s, const char *tag, 
const char *p)
 return 0;
 }
 
+static int parse_set_cookie_expiry_time(const char *exp_str, struct tm *buf)
+{
+char exp_buf[MAX_EXPIRY];
+int i, j, exp_buf_len = MAX_EXPIRY-1;
+char *expiry;
+
+// strip off any punctuation or whitespace
+for (i = 0, j = 0; exp_str[i] != '\0' && j < exp_buf_len; i++) {
+if ((exp_str[i] >= '0' && exp_str[i] <= '9') ||
+(exp_str[i] >= 'A' && exp_str[i] <= 'Z') ||
+(exp_str[i] >= 'a' && exp_str[i] <= 'z')) {
+exp_buf[j] = exp_str[i];
+j++;
+}
+}
+exp_buf[j] = '\0';
+expiry = exp_buf;
+
+// move the string beyond the day of week
+while ((*expiry < '0' || *expiry > '9') && *expiry != '\0')
+expiry++;
+
+return av_small_strptime(expiry, "%d%b%Y%H%M%S", buf) ? 0 : 
AVERROR(EINVAL);
+}
+
+static int parse_set_cookie(const char *set_cookie, AVDictionary **dict)
+{
+char *param, *next_param, *cstr, *back;
+
+if (!(cstr = av_strdup(set_cookie)))
+return AVERROR(EINVAL);
+
+// strip any trailing whitespace
+back = &cstr[strlen(cstr)-1];
+while (strchr(WHITESPACES, *back)) {
+*back='\0';
+back--;
+}
+
+next_param = cstr;
+while ((param = av_strtok(next_param, ";", &next_param))) {
+char *name, *value;
+param += strspn(param, WHITESPACES);
+if ((name = av_strtok(param, "=", &value))) {
+if (av_dict_set(dict, name, value, 0) < 0) {
+av_free(cstr);
+return -1;
+}
+}
+}
+
+av_free(cstr);
+return 0;
+}
+
 static int parse_cookie(HTTPContext *s, const char *p, AVDictionary **cookies)
 {
+AVDictionary *new_params = NULL;
+AVDictionaryEntry *e, *cookie_entry;
 char *eql, *name;
 
+// ensure the cookie is parsable
+if (parse_set_cookie(p, &new_params))
+return -1;
+
+// if there is no cookie value there is nothing to parse
+cookie_entry = av_dict_get(new_params, "", NULL, AV_DICT_IGNORE_SUFFIX);
+if (!cookie_entry || !cookie_entry->value) {
+av_dict_free(&new_params);
+return -1;
+}
+
+// ensure the cookie is not expired or older than an existing value
+if ((e = av_dict_get(new_params, "expires", NULL, 0)) && e->value) {
+struct tm new_tm = {0};
+if (!parse_set_cookie_expiry_time(e->value, &new_tm)) {
+AVDictionaryEntry *e2;
+
+// if the cookie has already expired ignore it
+if (av_timegm(&new_tm) < av_gettime() / 100) {
+av_dict_free(&new_params);
+return -1;
+}
+
+// only replace an older cookie with the same name
+e2 = av_dict_get(*cookies, cookie_entry->key, NULL, 0);
+if (e2 && e2->value) {
+AVDictionary *old_params = NULL;
+if (!parse_set_cookie(p, &old_params)) {
+e2 = av_dict_get(old_params, "expires", NULL, 0);
+if (e2 && e2->value) {
+struct tm old_tm = {0};
+if (!parse_set_cookie_expiry_time(e->value, &old_tm)) {
+if (av_timegm(&new_tm) < av_timegm(&old_tm)) {
+av_dict_free(&new_params);
+av_dict_free(&old_params);
+return -1;
+}
+}
+}
+}
+av_dict_free(&old_params);
+}
+}
+}
+
 // duplicate the cookie name (dict will dupe the value)
 if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
 if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
@@ -868,7 +973,7 @@ static int get_cookies(HTTPContext *s, char **cookies, 
const char *path,
 // cookie strings will look like Set-Cookie header field values.  Multiple
 // Set-Cookie fields will result in multiple values delimited by a newline
 int ret = 0;
-char *next, *cookie, *set

[FFmpeg-devel] [PATCH 2/2] libavformat/hls: Observe Set-Cookie headers

2017-05-30 Thread Micah Galizia 
Signed-off-by: Micah Galizia 
Signed-off-by: Michael Niedermayer 
(cherry picked from commit c4c73020f4bbf261f0b263be82de575c17fa5a60)
Signed-off-by: Micah Galizia 
---
 libavformat/hls.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..42022690f1 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
 if (ret >= 0) {
 // update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(&c->cookies, "cookies", u);
+char *new_cookies = NULL;
+
+if (!(s->flags & AVFMT_FLAG_CUSTOM_IO))
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
(uint8_t**)&new_cookies);
+
+if (new_cookies) {
+av_free(c->cookies);
+c->cookies = new_cookies;
+}
+
 av_dict_set(&opts, "cookies", c->cookies, 0);
 }
 
-- 
2.11.0

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

[FFmpeg-devel] Backport HLS Cookie Authentication Fixes to 3.3

2017-05-30 Thread Micah Galizia 
Hello,

I'd like to backport the HLS cookie authentication fixes to 3.3 so that Kodi 18 
picks them up. Originally, this was a three patch set but the first fix (to 
av_small_strptime) is already in 3.3 and doesn't need to be backported.  The 
two that are still required are:

- c4c73020f4bbf261f0b263be82de575c17fa5a60 (hls)
- 28b24670741e1de25bfc7b5ea7c1d6dbae1aef6f (http)

Hopefully this is acceptable - let me know if anything is out of order.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] lavc/golomb: Fix UE golomb overwrite issue.

2017-05-30 Thread Jun Zhao 


On 2017/5/29 7:40, Michael Niedermayer wrote:
> On Fri, May 26, 2017 at 09:19:09AM +0800, Jun Zhao wrote:
>>  golomb.h |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> 228c7180856b65d095dd0b8d59f3d3ff4f65774a  
>> 0001-lavc-golomb-Fix-UE-golomb-overwrite-issue.patch
>> From eabcbf3d41e83f24623e6195d4a0ff86e4d95a80 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Fri, 26 May 2017 09:02:29 +0800
>> Subject: [PATCH] lavc/golomb: Fix UE golomb overwrite issue.
>>
>> put_bits just support write up to 31 bits, when write 32 bit in
>> put_bits, it's will overwrite the bit buffer, because the default
>> assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
>> in put_bits can not be trigger runtime.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavcodec/golomb.h | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
>> index 0833aff468..2c5a969ac1 100644
>> --- a/libavcodec/golomb.h
>> +++ b/libavcodec/golomb.h
>> @@ -468,7 +468,10 @@ static inline void set_ue_golomb(PutBitContext *pb, int 
>> i)
>>  put_bits(pb, ff_ue_golomb_len[i], i + 1);
>>  else {
>>  int e = av_log2(i + 1);
>> -put_bits(pb, 2 * e + 1, i + 1);
>> +if (e < 16)
>> +put_bits(pb, 2 * e + 1, i + 1);
>> +else
>> +put_bits32(pb, i + 1);
> 
> this is wrong
> 
> if e is 16 or larger the length is 33 bits or longer its never
> 32
> 

Yes, this is a wrong fix, how about add set_ue_golomb_long()/ 
set_ue_golomb_64() for this case ? 

> [...]
> 
> 
> 
> ___
> 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] libavformat/hls: Observe Set-Cookie headers

2017-05-30 Thread Micah Galizia 

On 2017-05-28 08:44 PM, Michael Niedermayer wrote:

On Fri, May 26, 2017 at 09:29:04PM -0400, Micah Galizia wrote:

On Sat, May 20, 2017 at 9:36 PM, Micah Galizia  wrote:

On 2017-05-17 05:23 AM, wm4 wrote:

On Sat, 6 May 2017 14:28:10 -0400
Micah Galizia  wrote:


On 2017-05-05 09:28 PM, wm4 wrote:

On Fri,  5 May 2017 20:55:05 -0400
Micah Galizia  wrote:


Signed-off-by: Micah Galizia 
---
libavformat/hls.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..bda9abecfa 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s,
AVIOContext **pb, const char *url,
ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
if (ret >= 0) {
// update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(&c->cookies, "cookies", u);
+char *new_cookies = NULL;
+
+if (s->flags ^ AVFMT_FLAG_CUSTOM_IO)
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN,
(uint8_t**)&new_cookies);

Did you mean & instead of ^?

No, the original code was structured to set *u to null (and thus did not
copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags.  So using ^
is logically equivalent -- cookies are copied only if
AVFMT_FLAG_CUSTOM_IO is not set.


Did you find out yet what difference AVFMT_FLAG_CUSTOM_IO is supposed
to make in the existing code?

Yes, I wrote back about it a day or two ago... here is the reference to
its original inclusion:
https://lists.ffmpeg.org/pipermail/ffmpeg-trac/2013-February/013020.html.
When the code was originally implemented we were using s->pb->opaque,
which in FFMPEG we could assume was a URLContext with options (one of
them possibly being "cookies").

Based on the email above, that wasn't true for other apps like mplayer,
and could cause crashes trying to treat opaque as a URLContext. So that
is the purpose of checking the AVFMT_FLAG_CUSTOM_IO flag (way back in
2013).

Now though, we don't seem to touch opaque at all. The options are stored
in AVIOContext's av_class, which does have options.  Based on this I
think both patches are safe: this version has less change, but the
original gets rid of the check against AVFMT_FLAG_CUSTOM_IO that I don't
think we need anymore.

I hope that clears things up.

Sorry, I missed that. I guess this code is an artifact of some severely
unclean hook up of the AVOPtion API to AVIOContext, that breaks with
custom I/O. I guess your patch is fine then.

I just wonder how an API user is supposed to pass along cookies then.
My code passes an AVDictionary via a "cookies" entry when opening the
HLS demuxer with custom I/O, so I was wondering whether the patch
changes behavior here.


I wouldn't have expected anyone to pass the cookies to the HLS demuxer
directly -- there is an http protocol AVOption that should pass it along to
the demuxer. But I guess thats the whole point of the custom IO, right? It'd
replace the http demuxer?

Even so, I don't think this is a good reason to hold up the the patch - it
corrects the problem for apps that use the http protocol and maintains the
existing behavior -- cookies are not (and were not) copied when the custom
flag is set because u was set to null. Am I wrong in that interpretation of
the existing behavior?

Hi,

What else do I need to do to get this fix checked in?

patch applied

thx


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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

2017-05-30 Thread Michael Niedermayer 
On Wed, May 31, 2017 at 01:14:58AM +0200, Hendrik Leppkes wrote:
> On Wed, May 31, 2017 at 12:52 AM, Michael Niedermayer
>  wrote:
> > This prevents an exploit leading to an information leak
> >
> > The existing exploit depends on a specific decoder as well.
> > It does appear though that the exploit should be possible with any decoder.
> > The problem is that as long as sensitive information gets into the decoder,
> > the output of the decoder becomes sensitive as well.
> > The only obvious solution is to prevent access to sensitive information. Or 
> > to
> > disable hls or possibly some of its feature. More complex solutions like
> > checking the path to limit access to only subdirectories of the hls path may
> > work as an alternative. But such solutions are fragile and tricky to 
> > implement
> > portably and would not stop every possible attack nor would they work with 
> > all
> > valid hls files.
> >
> > Found-by: Emil Lerner and Pavel Cheremushkin
> > Reported-by: Thierry Foucu 
> >
> >
> 

> I don't particularly like this. Being able to dump a HLS stream (ie.
> all its file) onto disk and simply open it again is a good thing.
> Maybe it should just be smarter and only allow using the same protocol
> for the segments then it already used for the m3u8 file, so that a
> local m3u8 allows opening a local file (plus http(s), in case I only
> saved the playlist), but a http HLS playlist only allows http
> segments?

we already prevent every protocol except file and crypto for local
hls files. We also already block http* in local hls files by default
thorugh default whitelists (file,crypto for local files)

This is not sufficient, the exploit there is successfully puts the
content of a readable file choosen by the attacker into the output
video, which if its given back to the attacker leaks this information.


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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

2017-05-30 Thread Hendrik Leppkes 
On Wed, May 31, 2017 at 12:52 AM, Michael Niedermayer
 wrote:
> This prevents an exploit leading to an information leak
>
> The existing exploit depends on a specific decoder as well.
> It does appear though that the exploit should be possible with any decoder.
> The problem is that as long as sensitive information gets into the decoder,
> the output of the decoder becomes sensitive as well.
> The only obvious solution is to prevent access to sensitive information. Or to
> disable hls or possibly some of its feature. More complex solutions like
> checking the path to limit access to only subdirectories of the hls path may
> work as an alternative. But such solutions are fragile and tricky to implement
> portably and would not stop every possible attack nor would they work with all
> valid hls files.
>
> Found-by: Emil Lerner and Pavel Cheremushkin
> Reported-by: Thierry Foucu 
>
>

I don't particularly like this. Being able to dump a HLS stream (ie.
all its file) onto disk and simply open it again is a good thing.
Maybe it should just be smarter and only allow using the same protocol
for the segments then it already used for the m3u8 file, so that a
local m3u8 allows opening a local file (plus http(s), in case I only
saved the playlist), but a http HLS playlist only allows http
segments?

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/x86: move simple_idct to external assembly

2017-05-30 Thread Michael Niedermayer 
On Mon, May 29, 2017 at 09:44:21PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, May 29, 2017 at 5:26 PM, Michael Niedermayer  > wrote:
> 
> > On Mon, May 29, 2017 at 09:40:49PM +0200, James Darnley wrote:
> > > On 2017-05-29 16:51, James Darnley wrote:
> > > > ---
> > > > Changes:
> > > >  - Changed type of d4 constant to dwords because it gets used as
> > dwords.
> > > >  - Changed or removed HAVE_MMX_INLINE preprocessor guards.
> > > >  - Added note about conversion from inline.
> > > >  - New file no longer has "2" suffix.
> > > >  - Whitespace (indentation and alignment).
> > > >
> > > >  libavcodec/tests/x86/dct.c |   2 +-
> > > >  libavcodec/x86/Makefile|   4 +-
> > > >  libavcodec/x86/idctdsp_init.c  |   4 -
> > > >  libavcodec/x86/simple_idct.asm | 889 ++
> > +
> > > >  libavcodec/x86/simple_idct.c   | 929 --
> > ---
> > > >  5 files changed, 892 insertions(+), 936 deletions(-)
> > > >  create mode 100644 libavcodec/x86/simple_idct.asm
> > > >  delete mode 100644 libavcodec/x86/simple_idct.c
> > >
> > > Ronald queried on IRC about the performance.  The libavcodec/tests/dct
> > > utility reports these numbers
> > >
> > > Yorkfield:
> > >  - inline:   IDCT SIMPLE-MMX: 15715.9 kdct/s
> > >  - external: IDCT SIMPLE-MMX: 15699.9 kdct/s
> > >
> > > Skylake-U:
> > >  - inline:   IDCT SIMPLE-MMX: 11193.3 kdct/s
> > >  - external: IDCT SIMPLE-MMX: 11189.7 kdct/s
> >
> > Its better to benchmark by decoding some videos as the sparsness of
> > the coeffs affects speed
> 
> 
> The vp9 checkasm idct test already tests this (for performance as well as
> coverage purposes), maybe dct-test should include a test for "sub-idcts"
> (including, but not limited to, dc-only) also?

I think dct-test supports dc only and sparse tests, not sure how
relevant these are though, i doubt that they match real world
statistics very well

hmm, but as you mention this, it looks from a quick glance that these
tests are not run in fate

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

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


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

[FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

2017-05-30 Thread Michael Niedermayer 
This prevents an exploit leading to an information leak

The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.

Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu 

Signed-off-by: Michael Niedermayer 
---
 libavformat/hls.c   | 13 -
 tests/fate/avformat.mak |  4 ++--
 tests/fate/filter-audio.mak |  4 ++--
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 4b8fb19a52..3a82855ab7 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -204,6 +204,7 @@ typedef struct HLSContext {
 char *http_proxy;///< holds the address of the HTTP 
proxy server
 AVDictionary *avio_opts;
 int strict_std_compliance;
+int allow_file;
 } HLSContext;
 
 static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
@@ -618,8 +619,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 return AVERROR_INVALIDDATA;
 
 // only http(s) & file are allowed
-if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, 
"file", NULL))
+if (av_strstart(proto_name, "http", NULL))
+;
+else if (av_strstart(proto_name, "file", NULL)) {
+if (!c->allow_file) {
+av_log(s, AV_LOG_ERROR, "Local file access is disabled by default 
for security reasons. To override this set hls_allow_file to 1\n");
+return AVERROR_INVALIDDATA;
+}
+} else
 return AVERROR_INVALIDDATA;
+
 if (!strncmp(proto_name, url, strlen(proto_name)) && 
url[strlen(proto_name)] == ':')
 ;
 else if (av_strstart(url, "crypto", NULL) && !strncmp(proto_name, url + 7, 
strlen(proto_name)) && url[7 + strlen(proto_name)] == ':')
@@ -2134,6 +2143,8 @@ static int hls_probe(AVProbeData *p)
 static const AVOption hls_options[] = {
 {"live_start_index", "segment index to start live streams at (negative 
values are from the end)",
 OFFSET(live_start_index), AV_OPT_TYPE_INT, {.i64 = -3}, INT_MIN, 
INT_MAX, FLAGS},
+{"hls_allow_file", "Allow to refer to files instead of http only",
+OFFSET(allow_file), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS},
 {NULL}
 };
 
diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 82a531c7a5..0ca907ab7f 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -119,12 +119,12 @@ tests/data/adts-to-mkv-cated-%.mkv: 
tests/data/adts-to-mkv-header.mkv tests/data
 
 FATE_SEGMENT += fate-segment-mp4-to-ts
 fate-segment-mp4-to-ts: tests/data/mp4-to-ts.m3u8
-fate-segment-mp4-to-ts: CMD = framecrc -flags +bitexact -i 
$(TARGET_PATH)/tests/data/mp4-to-ts.m3u8 -c copy
+fate-segment-mp4-to-ts: CMD = framecrc -flags +bitexact -hls_allow_file 1 -i 
$(TARGET_PATH)/tests/data/mp4-to-ts.m3u8 -c copy
 FATE_SEGMENT-$(call ALLYES, MOV_DEMUXER H264_MP4TOANNEXB_BSF MPEGTS_MUXER 
MATROSKA_DEMUXER SEGMENT_MUXER HLS_DEMUXER) += fate-segment-mp4-to-ts
 
 FATE_SEGMENT += fate-segment-adts-to-mkv
 fate-segment-adts-to-mkv: tests/data/adts-to-mkv.m3u8
-fate-segment-adts-to-mkv: CMD = framecrc -flags +bitexact -i 
$(TARGET_PATH)/tests/data/adts-to-mkv.m3u8 -c copy
+fate-segment-adts-to-mkv: CMD = framecrc -flags +bitexact -hls_allow_file 1 -i 
$(TARGET_PATH)/tests/data/adts-to-mkv.m3u8 -c copy
 fate-segment-adts-to-mkv: REF = 
$(SRC_PATH)/tests/ref/fate/segment-adts-to-mkv-header-all
 FATE_SEGMENT-$(call ALLYES, AAC_DEMUXER AAC_ADTSTOASC_BSF MATROSKA_MUXER 
MATROSKA_DEMUXER SEGMENT_MUXER HLS_DEMUXER) += fate-segment-adts-to-mkv
 
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 5d15b31e0b..0c229ccc51 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -150,7 +150,7 @@ tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | 
tests/data
 
 FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER 
AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-filter-hls
 fate-filter-hls: tests/data/hls-list.m3u8
-fate-filter-hls: CMD = framecrc -flags +bitexact -i 
$(TARGET_PATH)/tests/data/hls-list.m3u8
+fate-filter-hls: CMD = framecrc -flags +bitexact -hls_allow_file 1 -i 
$(TARGET_PATH)/tests/data/hls-list.m3u8
 
 tests/data/hls-list-append.m3u8: TAG = GEN
 tests/data/hls-list-append.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
@@ -164,7 +164,7 @@ tests/data/hls-list-append.m3u8: ffmpeg$(PROGSSUF)$(EXESUF)

Re: [FFmpeg-devel] [PATCH] lavf: consider codec timebase for framerate detection

2017-05-30 Thread wm4 
On Tue, 30 May 2017 18:46:36 -0300
James Almer  wrote:

> On 5/30/2017 9:07 AM, wm4 wrote:
> > On Tue, 23 May 2017 13:36:51 +0200
> > wm4  wrote:
> >   
> >> Fixes detection of some TV sample as 24.5 FPS. With the patch applied,
> >> it's detected as 25 FPS.
> >> ---
> >>  libavformat/utils.c | 22 ++
> >>  1 file changed, 22 insertions(+)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index fbd8b58ac2..778a82aeee 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -3903,6 +3903,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >>  st->info->codec_info_duration) {
> >>  int best_fps  = 0;
> >>  double best_error = 0.01;
> >> +AVRational codec_frame_rate = av_inv_q(avctx->time_base);
> >>  
> >>  if (st->info->codec_info_duration>= INT64_MAX / 
> >> st->time_base.num / 2||
> >>  st->info->codec_info_duration_fields >= INT64_MAX / 
> >> st->time_base.den ||
> >> @@ -3924,6 +3925,27 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >>  best_fps   = std_fps.num;
> >>  }
> >>  }
> >> +if (avctx->ticks_per_frame > 0)
> >> +codec_frame_rate.num /= avctx->ticks_per_frame;
> >> +for (j = 0; j < MAX_STD_TIMEBASES; j++) {
> >> +AVRational std_fps = { get_std_framerate(j), 12 * 
> >> 1001 };
> >> +double error   = fabs(av_q2d(st->avg_frame_rate) /
> >> +  av_q2d(std_fps) - 1);
> >> +
> >> +if (error < best_error) {
> >> +best_error = error;
> >> +best_fps   = std_fps.num;
> >> +}
> >> +
> >> +if (codec_frame_rate.num > 0 && codec_frame_rate.den 
> >> > 0) {
> >> +error   = fabs(av_q2d(codec_frame_rate) /
> >> +   av_q2d(std_fps) - 1);
> >> +if (error < best_error) {
> >> +best_error = error;
> >> +best_fps   = std_fps.num;
> >> +}
> >> +}
> >> +}
> >>  if (best_fps)
> >>  av_reduce(&st->avg_frame_rate.num, 
> >> &st->avg_frame_rate.den,
> >>best_fps, 12 * 1001, INT_MAX);  
> > 
> > Nobody wants to review this? It's pretty intrusive. I guess I'll push
> > tomorrow or so.  
> 
> According to the AVCodecContext->time_base doxy
> 
>  * - encoding: MUST be set by user.
>  * - decoding: the use of this field for decoding is deprecated.
>  * Use framerate instead.
> 
> And it's scheduled to be dropped in the next bump (libav already did it).
> It's still used for decoding elsewhere in avformat_find_stream_info(),
> though, and even in other places, so this is probably going in the wrong
> direction and the other cases should be fixed instead.
> ffmpeg.c is apparently not using it for decoding, so that's good.
> 
> You may be able to use avctx->framerate for this. Check how the
> deprecated code in in lavc/utils.c and lavc/decode.c uses it to set
> avctx->time_base.

Right, the h264 decoder even sets the framerate field directly. I'll
see whether using that works.

Btw. what I really want is setting this as the framerate for mpegts,
any tips how to achieve this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: consider codec timebase for framerate detection

2017-05-30 Thread James Almer 
On 5/30/2017 9:07 AM, wm4 wrote:
> On Tue, 23 May 2017 13:36:51 +0200
> wm4  wrote:
> 
>> Fixes detection of some TV sample as 24.5 FPS. With the patch applied,
>> it's detected as 25 FPS.
>> ---
>>  libavformat/utils.c | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index fbd8b58ac2..778a82aeee 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3903,6 +3903,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  st->info->codec_info_duration) {
>>  int best_fps  = 0;
>>  double best_error = 0.01;
>> +AVRational codec_frame_rate = av_inv_q(avctx->time_base);
>>  
>>  if (st->info->codec_info_duration>= INT64_MAX / 
>> st->time_base.num / 2||
>>  st->info->codec_info_duration_fields >= INT64_MAX / 
>> st->time_base.den ||
>> @@ -3924,6 +3925,27 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  best_fps   = std_fps.num;
>>  }
>>  }
>> +if (avctx->ticks_per_frame > 0)
>> +codec_frame_rate.num /= avctx->ticks_per_frame;
>> +for (j = 0; j < MAX_STD_TIMEBASES; j++) {
>> +AVRational std_fps = { get_std_framerate(j), 12 * 1001 
>> };
>> +double error   = fabs(av_q2d(st->avg_frame_rate) /
>> +  av_q2d(std_fps) - 1);
>> +
>> +if (error < best_error) {
>> +best_error = error;
>> +best_fps   = std_fps.num;
>> +}
>> +
>> +if (codec_frame_rate.num > 0 && codec_frame_rate.den > 
>> 0) {
>> +error   = fabs(av_q2d(codec_frame_rate) /
>> +   av_q2d(std_fps) - 1);
>> +if (error < best_error) {
>> +best_error = error;
>> +best_fps   = std_fps.num;
>> +}
>> +}
>> +}
>>  if (best_fps)
>>  av_reduce(&st->avg_frame_rate.num, 
>> &st->avg_frame_rate.den,
>>best_fps, 12 * 1001, INT_MAX);
> 
> Nobody wants to review this? It's pretty intrusive. I guess I'll push
> tomorrow or so.

According to the AVCodecContext->time_base doxy

 * - encoding: MUST be set by user.
 * - decoding: the use of this field for decoding is deprecated.
 * Use framerate instead.

And it's scheduled to be dropped in the next bump (libav already did it).
It's still used for decoding elsewhere in avformat_find_stream_info(),
though, and even in other places, so this is probably going in the wrong
direction and the other cases should be fixed instead.
ffmpeg.c is apparently not using it for decoding, so that's good.

You may be able to use avctx->framerate for this. Check how the
deprecated code in in lavc/utils.c and lavc/decode.c uses it to set
avctx->time_base.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

2017-05-30 Thread Kevin Mark 
Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.

Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.

To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:

 * main_w/main_h: width/height of the main input video
 * main_a: aspect ratio of the main input video
 * main_sar: sample aspect ratio of the main input video
 * main_dar: display aspect ratio of the main input video
 * main_hsub/main_vsub: horiz/vert chroma subsample vals of main
 * mdar: a shorthand alias of main_dar

Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.

So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:

scale2ref=iw/6:ow/mdar [main][ref]

This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.

I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.

var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.

This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.

The applicable documentation has also been updated.

Signed-off-by: Kevin Mark 
---
 doc/filters.texi| 26 ++-
 libavfilter/scale.c | 72 ++---
 2 files changed, 93 insertions(+), 5 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 107fe61447..2cea6b74e6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12429,7 +12429,31 @@ Supersampling
 Scale (resize) the input video, based on a reference video.
 
 See the scale filter for available options, scale2ref supports the same but
-uses the reference video instead of the main input as basis.
+uses the reference video instead of the main input as basis. scale2ref also
+supports the following additional constants for the @option{w} and
+@option{h} options:
+
+@table @var
+@item main_w
+@item main_h
+The main input video's width and height
+
+@item main_a
+The same as @var{main_w} / @var{main_h}
+
+@item main_sar
+The main input video's sample aspect ratio
+
+@item main_dar, mdar
+The main input video's display aspect ratio. Calculated from
+@code{(main_w / main_h) * main_sar}.
+
+@item main_hsub
+@item main_vsub
+The main input video's horizontal and vertical chroma subsample values.
+For example for the pixel format "yuv422p" @var{hsub} is 2 and @var{vsub}
+is 1.
+@end table
 
 @subsection Examples
 
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 50cd442849..e3a2fb5923 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -60,6 +60,49 @@ enum var_name {
 VARS_NB
 };
 
+/**
+ * This must be kept in sync with var_names so that it is always a
+ * complete list of var_names with the scale2ref specific names
+ * appended. scale2ref values must appear in the order they appear
+ * in the var_name_scale2ref enum but also be below all of the
+ * non-scale2ref specific values.
+ */
+static const char *const var_names_scale2ref[] = {
+"PI",
+"PHI",
+"E",
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow

[FFmpeg-devel] [PATCH 2/2] avcodec/vorbisenc: Use a bufqueue in encoding with smaller lengths

2017-05-30 Thread Tyler Jones 
Switching the vorbis encoder to use a buffer queue for input frames allows
saving lookahead samples more easily and safely for psychoacoustic systems,
requiring less pointer arithmetic in the case of transient windows.
---
 libavcodec/vorbisenc.c | 120 +++--
 1 file changed, 106 insertions(+), 14 deletions(-)

diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index fdce864..ea2b7f5 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vorbisenc.c
@@ -1024,20 +1024,117 @@ static int apply_window_and_mdct(vorbis_enc_context 
*venc,
 return 1;
 }
 
+/* Used for padding the last encoded packet */
+static AVFrame *spawn_empty_frame(AVCodecContext *avctx, int channels)
+{
+AVFrame *f = av_frame_alloc();
+
+if (!f)
+return NULL;
+
+f->format = avctx->sample_fmt;
+f->nb_samples = avctx->frame_size;
+f->channel_layout = avctx->channel_layout;
+
+if (av_frame_get_buffer(f, 4)) {
+av_frame_free(&f);
+return NULL;
+}
+
+for (int ch = 0; ch < channels; ch++) {
+size_t bps = av_get_bytes_per_sample(f->format);
+memset(f->extended_data[ch], 0, bps * f->nb_samples);
+}
+return f;
+}
+
+static float **alloc_audio_arrays(int channels, int frame_size)
+{
+float **audio = av_mallocz_array(channels, sizeof(float *));
+if (!audio)
+return NULL;
+
+for (int ch = 0; ch < channels; ch++) {
+audio[ch] = av_mallocz_array(frame_size, sizeof(float));
+if (!audio[ch]) {
+// alloc has failed, free everything allocated thus far
+for (ch--; ch >= 0; ch--)
+av_free(audio[ch]);
+av_free(audio);
+return NULL;
+}
+}
+
+return audio;
+}
+
+/* Concatenate audio frames into an appropriately sized array of samples */
+static void move_audio(vorbis_enc_context *venc, float **audio, int *samples, 
int sf_size)
+{
+AVFrame *cur = NULL;
+int frame_size = 1 << (venc->log2_blocksize[1] - 1);
+int subframes = frame_size / sf_size;
+
+for (int sf = 0; sf < subframes; sf++) {
+cur = ff_bufqueue_get(&venc->bufqueue);
+*samples += cur->nb_samples;
+
+for (int ch = 0; ch < venc->channels; ch++) {
+const float *input = (float *) cur->extended_data[ch];
+const size_t len  = cur->nb_samples * sizeof(float);
+memcpy(&audio[ch][sf*sf_size], input, len);
+}
+av_frame_free(&cur);
+}
+}
+
 static int vorbis_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
const AVFrame *frame, int *got_packet_ptr)
 {
 vorbis_enc_context *venc = avctx->priv_data;
-float **audio = frame ? (float **)frame->extended_data : NULL;
-int samples = frame ? frame->nb_samples : 0;
+float **audio = NULL;
+int i, ret, need_more;
+int samples = 0, frame_size = 1 << (venc->log2_blocksize[1] - 1);
 vorbis_enc_mode *mode;
 vorbis_enc_mapping *mapping;
 PutBitContext pb;
-int i, ret;
+
+if (frame) {
+if ((ret = ff_af_queue_add(&venc->afq, frame)) < 0)
+return ret;
+ff_bufqueue_add(avctx, &venc->bufqueue, av_frame_clone(frame));
+} else
+if (!venc->afq.remaining_samples)
+return 0;
+
+need_more = venc->bufqueue.available * avctx->frame_size < frame_size;
+need_more = frame && need_more;
+if (need_more)
+return 0;
+
+audio = alloc_audio_arrays(venc->channels, frame_size);
+if (!audio)
+return AVERROR(ENOMEM);
+
+/* Pad the bufqueue with empty frames for encoding the last packet. */
+if (!frame) {
+if (venc->bufqueue.available * avctx->frame_size < frame_size) {
+int frames_needed = (frame_size/avctx->frame_size) - 
venc->bufqueue.available;
+
+for (int i = 0; i < frames_needed; i++) {
+   AVFrame *empty = spawn_empty_frame(avctx, venc->channels);
+   if (!empty)
+   return AVERROR(ENOMEM);
+
+   ff_bufqueue_add(avctx, &venc->bufqueue, empty);
+}
+}
+}
+
+move_audio(venc, audio, &samples, avctx->frame_size);
 
 if (!apply_window_and_mdct(venc, audio, samples))
 return 0;
-samples = 1 << (venc->log2_blocksize[0] - 1);
 
 if ((ret = ff_alloc_packet2(avctx, avpkt, 8192, 0)) < 0)
 return ret;
@@ -1096,16 +1193,11 @@ static int vorbis_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 flush_put_bits(&pb);
 avpkt->size = put_bits_count(&pb) >> 3;
 
-avpkt->duration = ff_samples_to_time_base(avctx, avctx->frame_size);
-if (frame) {
-if (frame->pts != AV_NOPTS_VALUE)
-avpkt->pts = ff_samples_to_time_base(avctx, frame->pts);
-} else {
-avpkt->pts = venc->next_pts;
-}
-if (avpkt->pts != AV_NOPTS_VALUE)
-venc->next_pts = avpkt->pts + avpkt->duration;
+for (int ch = 0; ch < venc->channels; c

[FFmpeg-devel] [PATCH 1/2] avcodec/vorbisenc: Include bufqueue and afqueue

2017-05-30 Thread Tyler Jones 
---
 libavcodec/vorbisenc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index 2974ca2..fdce864 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vorbisenc.c
@@ -33,6 +33,9 @@
 #include "vorbis.h"
 #include "vorbis_enc_data.h"
 
+#include "audio_frame_queue.h"
+#include "libavfilter/bufferqueue.h"
+
 #define BITSTREAM_WRITER_LE
 #include "put_bits.h"
 
@@ -110,6 +113,9 @@ typedef struct vorbis_enc_context {
 float *coeffs; // also used for residue after floor
 float quality;
 
+AudioFrameQueue afq;
+struct FFBufQueue bufqueue;
+
 int ncodebooks;
 vorbis_enc_codebook *codebooks;
 
@@ -1158,6 +1164,8 @@ static av_cold int vorbis_encode_close(AVCodecContext 
*avctx)
 
 ff_mdct_end(&venc->mdct[0]);
 ff_mdct_end(&venc->mdct[1]);
+ff_af_queue_close(&venc->afq);
+ff_bufqueue_discard_all(&venc->bufqueue);
 
 av_freep(&avctx->extradata);
 
@@ -1190,6 +1198,8 @@ static av_cold int vorbis_encode_init(AVCodecContext 
*avctx)
 
 avctx->frame_size = 1 << (venc->log2_blocksize[0] - 1);
 
+ff_af_queue_init(avctx, &venc->afq);
+
 return 0;
 error:
 vorbis_encode_close(avctx);
-- 
2.7.4



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

Re: [FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

2017-05-30 Thread Kevin Mark 
On Tue, May 30, 2017 at 10:40 AM, Kevin Mark  wrote:
> +const AVFilterLink *main;

Unfortunately that line results in a warning on GCC (but not LLVM):

libavfilter/scale.c: In function ‘ff_scale_eval_dimensions’:
libavfilter/scale.c:121:25: warning: ‘main’ is usually a function [-Wmain]
 const AVFilterLink *main;
 ^

An updated patch is on the way to address this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/vorbisenc: Include fdsp

2017-05-30 Thread Tyler Jones 
Signed-off-by: Tyler Jones 
---
 libavcodec/vorbisenc.c | 31 +--
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index 2974ca2..7c3cd51 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vorbisenc.c
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include "libavutil/float_dsp.h"
 
 #include "avcodec.h"
 #include "internal.h"
@@ -126,6 +127,8 @@ typedef struct vorbis_enc_context {
 vorbis_enc_mode *modes;
 
 int64_t next_pts;
+
+AVFloatDSPContext *fdsp;
 } vorbis_enc_context;
 
 #define MAX_CHANNELS 2
@@ -236,6 +239,26 @@ static int ready_residue(vorbis_enc_residue *rc, 
vorbis_enc_context *venc)
 return 0;
 }
 
+static av_cold int dsp_init(AVCodecContext *avctx, vorbis_enc_context *venc)
+{
+int ret = 0;
+
+venc->fdsp = avpriv_float_dsp_alloc(avctx->flags & AV_CODEC_FLAG_BITEXACT);
+if (!venc->fdsp)
+return AVERROR(ENOMEM);
+
+// init windows
+venc->win[0] = ff_vorbis_vwin[venc->log2_blocksize[0] - 6];
+venc->win[1] = ff_vorbis_vwin[venc->log2_blocksize[1] - 6];
+
+if ((ret = ff_mdct_init(&venc->mdct[0], venc->log2_blocksize[0], 0, 1.0)) 
< 0)
+return ret;
+if ((ret = ff_mdct_init(&venc->mdct[1], venc->log2_blocksize[1], 0, 1.0)) 
< 0)
+return ret;
+
+return 0;
+}
+
 static int create_vorbis_context(vorbis_enc_context *venc,
  AVCodecContext *avctx)
 {
@@ -426,12 +449,7 @@ static int create_vorbis_context(vorbis_enc_context *venc,
 if (!venc->saved || !venc->samples || !venc->floor || !venc->coeffs)
 return AVERROR(ENOMEM);
 
-venc->win[0] = ff_vorbis_vwin[venc->log2_blocksize[0] - 6];
-venc->win[1] = ff_vorbis_vwin[venc->log2_blocksize[1] - 6];
-
-if ((ret = ff_mdct_init(&venc->mdct[0], venc->log2_blocksize[0], 0, 1.0)) 
< 0)
-return ret;
-if ((ret = ff_mdct_init(&venc->mdct[1], venc->log2_blocksize[1], 0, 1.0)) 
< 0)
+if ((ret = dsp_init(avctx, venc)) < 0)
 return ret;
 
 return 0;
@@ -1155,6 +1173,7 @@ static av_cold int vorbis_encode_close(AVCodecContext 
*avctx)
 av_freep(&venc->samples);
 av_freep(&venc->floor);
 av_freep(&venc->coeffs);
+av_freep(&venc->fdsp);
 
 ff_mdct_end(&venc->mdct[0]);
 ff_mdct_end(&venc->mdct[1]);
-- 
2.7.4



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

[FFmpeg-devel] [PATCH 2/2] avcodec/vorbisenc: Use fdsp for applying windows

2017-05-30 Thread Tyler Jones 
Using fdsp improves readability and allows using architecture-specific
optimizations.

Signed-off-by: Tyler Jones 
---
 libavcodec/vorbisenc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index 7c3cd51..1777a49 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vorbisenc.c
@@ -988,11 +988,11 @@ static int residue_encode(vorbis_enc_context *venc, 
vorbis_enc_residue *rc,
 static int apply_window_and_mdct(vorbis_enc_context *venc,
  float **audio, int samples)
 {
-int i, channel;
+int channel;
 const float * win = venc->win[0];
 int window_len = 1 << (venc->log2_blocksize[0] - 1);
 float n = (float)(1 << venc->log2_blocksize[0]) / 4.0;
-// FIXME use dsp
+AVFloatDSPContext *fdsp = venc->fdsp;
 
 if (!venc->have_saved && !samples)
 return 0;
@@ -1009,9 +1009,10 @@ static int apply_window_and_mdct(vorbis_enc_context 
*venc,
 
 if (samples) {
 for (channel = 0; channel < venc->channels; channel++) {
-float * offset = venc->samples + channel*window_len*2 + window_len;
-for (i = 0; i < samples; i++)
-offset[i] = audio[channel][i] / n * win[window_len - i - 1];
+float *offset = venc->samples + channel * window_len * 2 + 
window_len;
+
+fdsp->vector_fmul_reverse(offset, audio[channel], win, samples);
+fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
 }
 } else {
 for (channel = 0; channel < venc->channels; channel++)
@@ -1026,8 +1027,9 @@ static int apply_window_and_mdct(vorbis_enc_context *venc,
 if (samples) {
 for (channel = 0; channel < venc->channels; channel++) {
 float *offset = venc->saved + channel * window_len;
-for (i = 0; i < samples; i++)
-offset[i] = audio[channel][i] / n * win[i];
+
+fdsp->vector_fmul(offset, audio[channel], win, samples);
+fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
 }
 venc->have_saved = 1;
 } else {
-- 
2.7.4



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

Re: [FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

2017-05-30 Thread Kevin Mark 
I'm hoping this is the proper means of submitting an updated patch. I
used git send-email with the --in-reply-to option set to the
Message-Id of my original patch. It looks like it created a new patch
in Patchwork (instead of updating the old one) and I'm not sure if
that's what we want it to do. This workflow is all new to me so I'm
open to being told the proper way of doing things.

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

[FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

2017-05-30 Thread Kevin Mark 
Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.

Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.

To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:

 * main_w/main_h: width/height of the main input video
 * main_a: aspect ratio of the main input video
 * main_sar: sample aspect ratio of the main input video
 * main_dar: display aspect ratio of the main input video
 * main_hsub/main_vsub: horiz/vert chroma subsample vals of main
 * mdar: a shorthand alias of main_dar

Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.

So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:

scale2ref=iw/6:ow/mdar [main][ref]

This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.

I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.

var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.

This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.

The applicable documentation has also been updated.

Signed-off-by: Kevin Mark 
---
 doc/filters.texi| 26 ++-
 libavfilter/scale.c | 72 ++---
 2 files changed, 93 insertions(+), 5 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 107fe61447..2cea6b74e6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12429,7 +12429,31 @@ Supersampling
 Scale (resize) the input video, based on a reference video.
 
 See the scale filter for available options, scale2ref supports the same but
-uses the reference video instead of the main input as basis.
+uses the reference video instead of the main input as basis. scale2ref also
+supports the following additional constants for the @option{w} and
+@option{h} options:
+
+@table @var
+@item main_w
+@item main_h
+The main input video's width and height
+
+@item main_a
+The same as @var{main_w} / @var{main_h}
+
+@item main_sar
+The main input video's sample aspect ratio
+
+@item main_dar, mdar
+The main input video's display aspect ratio. Calculated from
+@code{(main_w / main_h) * main_sar}.
+
+@item main_hsub
+@item main_vsub
+The main input video's horizontal and vertical chroma subsample values.
+For example for the pixel format "yuv422p" @var{hsub} is 2 and @var{vsub}
+is 1.
+@end table
 
 @subsection Examples
 
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 50cd442849..552b7cbb04 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -60,6 +60,49 @@ enum var_name {
 VARS_NB
 };
 
+/**
+ * This must be kept in sync with var_names so that it is always a
+ * complete list of var_names with the scale2ref specific names
+ * appended. scale2ref values must appear in the order they appear
+ * in the var_name_scale2ref enum but also be below all of the
+ * non-scale2ref specific values.
+ */
+static const char *const var_names_scale2ref[] = {
+"PI",
+"PHI",
+"E",
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow

Re: [FFmpeg-devel] [PATCH] lavf: consider codec timebase for framerate detection

2017-05-30 Thread wm4 
On Tue, 23 May 2017 13:36:51 +0200
wm4  wrote:

> Fixes detection of some TV sample as 24.5 FPS. With the patch applied,
> it's detected as 25 FPS.
> ---
>  libavformat/utils.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index fbd8b58ac2..778a82aeee 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3903,6 +3903,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  st->info->codec_info_duration) {
>  int best_fps  = 0;
>  double best_error = 0.01;
> +AVRational codec_frame_rate = av_inv_q(avctx->time_base);
>  
>  if (st->info->codec_info_duration>= INT64_MAX / 
> st->time_base.num / 2||
>  st->info->codec_info_duration_fields >= INT64_MAX / 
> st->time_base.den ||
> @@ -3924,6 +3925,27 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  best_fps   = std_fps.num;
>  }
>  }
> +if (avctx->ticks_per_frame > 0)
> +codec_frame_rate.num /= avctx->ticks_per_frame;
> +for (j = 0; j < MAX_STD_TIMEBASES; j++) {
> +AVRational std_fps = { get_std_framerate(j), 12 * 1001 };
> +double error   = fabs(av_q2d(st->avg_frame_rate) /
> +  av_q2d(std_fps) - 1);
> +
> +if (error < best_error) {
> +best_error = error;
> +best_fps   = std_fps.num;
> +}
> +
> +if (codec_frame_rate.num > 0 && codec_frame_rate.den > 
> 0) {
> +error   = fabs(av_q2d(codec_frame_rate) /
> +   av_q2d(std_fps) - 1);
> +if (error < best_error) {
> +best_error = error;
> +best_fps   = std_fps.num;
> +}
> +}
> +}
>  if (best_fps)
>  av_reduce(&st->avg_frame_rate.num, 
> &st->avg_frame_rate.den,
>best_fps, 12 * 1001, INT_MAX);

Nobody wants to review this? It's pretty intrusive. I guess I'll push
tomorrow or so.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] reindent

2017-05-30 Thread Ronald S. Bultje 
Hi,

On May 30, 2017 6:44 AM, "James Darnley"  wrote:

On 2017-05-29 16:51, James Darnley wrote:
> Commit message: reindent

Is this acceptable?  Should I be more verbose?


Make it x86/idctdsp_init: reindent. Otherwise ok.

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

Re: [FFmpeg-devel] [PATCH 2/2] reindent

2017-05-30 Thread James Darnley 
On 2017-05-29 16:51, James Darnley wrote:
> Commit message: reindent

Is this acceptable?  Should I be more verbose?

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

[FFmpeg-devel] Freelancer wanted to work on ffmpeg integration

2017-05-30 Thread Daniel Walz 
Dear fellow developers,

For the integration of FFMPEG reading and writing video files we are
looking for a freelance worker.
The objectives are to create video files that play on the standard
players. We want to make as many formats/codecs as possible available
to our users, but will focus on the most used first, like mp4, AVI,
MOV, AVCHD, MTK.

We have already a POC and made it available as open source on github:
https://github.com/filmstro/filmstro_ffmpeg

Currently decoding and displaying works well for mp4 (H.264). But
there are situations, when the flow is interrupted, especially with
other formats.
Writing back is also implemented, however, the files are only readable
by VLC, but not in OSX preview etc. Here is probably a better
understanding of which codecs to use in what containers needed.

The workflow, where this will be needed is:
- reading from an existing video file, saving frames and audio into FIFO buffers
- mixing the audio with user generated music
- writing a new video file with the new audio and the original frames

Later it should also be possible to work on the video frames
(e.g. to add brandings/watermarks, create transitions from different
video clips)

If you are interested to work on that project, please get in touch with me:

dan...@filmstro.com

Please also write your usual daily rate and some references like
projects you worked on, github contributions or similar...

We are looking forward to hear from you.

Best,
Daniel

-- 
Daniel Walz | Software Developer

Filmstro | Music that Moves.

www.filmstro.com | twitter/filmstro | vimeo/filmstro
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/x86: move simple_idct to external assembly

2017-05-30 Thread James Darnley 
On 2017-05-29 23:26, Michael Niedermayer wrote:
> On Mon, May 29, 2017 at 09:40:49PM +0200, James Darnley wrote:
>> On 2017-05-29 16:51, James Darnley wrote:
>>> ---
>>> Changes:
>>>  - Changed type of d4 constant to dwords because it gets used as dwords.
>>>  - Changed or removed HAVE_MMX_INLINE preprocessor guards.
>>>  - Added note about conversion from inline.
>>>  - New file no longer has "2" suffix.
>>>  - Whitespace (indentation and alignment).
>>>
>>>  libavcodec/tests/x86/dct.c |   2 +-
>>>  libavcodec/x86/Makefile|   4 +-
>>>  libavcodec/x86/idctdsp_init.c  |   4 -
>>>  libavcodec/x86/simple_idct.asm | 889 
>>> +++
>>>  libavcodec/x86/simple_idct.c   | 929 
>>> -
>>>  5 files changed, 892 insertions(+), 936 deletions(-)
>>>  create mode 100644 libavcodec/x86/simple_idct.asm
>>>  delete mode 100644 libavcodec/x86/simple_idct.c
>>
>> Ronald queried on IRC about the performance.  The libavcodec/tests/dct
>> utility reports these numbers
>>
>> Yorkfield:
>>  - inline:   IDCT SIMPLE-MMX: 15715.9 kdct/s
>>  - external: IDCT SIMPLE-MMX: 15699.9 kdct/s
>>
>> Skylake-U:
>>  - inline:   IDCT SIMPLE-MMX: 11193.3 kdct/s
>>  - external: IDCT SIMPLE-MMX: 11189.7 kdct/s
> 
> Its better to benchmark by decoding some videos as the sparsness of
> the coeffs affects speed

Ah, quite true.

Decoding a large HD sample for many runs stays close around 220fps and
187s run time before and after the change.

I will push shortly.

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

Re: [FFmpeg-devel] [PATCH 1/3] libavfilter/scale2ref: Add constants for the non-ref input

2017-05-30 Thread Gyan 
On Tue, May 30, 2017 at 3:27 PM, Kevin Mark  wrote:


>
> Sounds good. If my understanding is correct, you would recommend changing
> the
> scale2ref=iw/6:iw/(6*main_a) [main][ref]
> example to
> scale2ref=iw/6:iw/(6*mdar) [main][ref]
> correct?
>

I prefer   scale2ref=iw/6:ow/mdar [main][ref] or
scale2ref=oh*mdar:ih/6 [main][ref]

This way, the expression complementary to the one specified remains fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavfilter/scale2ref: Add constants for the non-ref input

2017-05-30 Thread Kevin Mark 
On Sun, May 28, 2017 at 12:14 PM, Gyan  wrote:
> If you do, I suggest 'mdar' for main_dar which is the only one that ought
> to be required.
>
> The scale filter adjusts the SAR of the result so that the DAR is preserved
> i.e. when a 100x100 canvas w/ SAR of 2.0 is scaled to 50x100, the result
> will have SAR 4.0. In the scale2ref filter, this adjustment is made so that
> the ref's DAR is effected onto the scaled result. I don't believe your
> patch changes this behaviour. Now, the overlay filter does not respect the
> overlay input's SAR - a 100x100 canvas of SAR 2 is overlaid as a square -
> so having a shorthand for the main DAR and promoting its use will silently
> enforce a visually correct-looking input for overlays and other compositing
> uses.

Sounds good. If my understanding is correct, you would recommend changing the
scale2ref=iw/6:iw/(6*main_a) [main][ref]
example to
scale2ref=iw/6:iw/(6*mdar) [main][ref]
correct?

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacenc: Reduce loglevel of aac_encode_end() from INFO to VER

2017-05-30 Thread Rostislav Pehlivanov 
On 30 May 2017 at 08:43, Ingo Brückl  wrote:

> Rostislav Pehlivanov wrote on Mon, 29 May 2017 16:19:51 +0100:
>
> > On 29 May 2017 at 14:55, Ingo Brückl  wrote:
>
> >> AV_LOG_INFO is the default and meant for informational output.
> >> The information given by aac_encode_end() is rather technical
> >> and of less interest to a common user.
>
> > I like both the x264, x265 and this printing encoding statistics at the
> > end. If users want to silence them they can use -loglevel.
>
> If users reduce the loglevel to silence such messages, they will lose all
> informational messages as well. It seems that there are two kinds of INFO
> messages - technical ones for the advanced user and useful ones for the
> common user.
>
> Ingo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

By your logic everything should be silenced. Bitrate? Too technical.
Filesize? Too technical. Might as well put number of floppies you'll need,
since its simpler.
Point is, a user encoding should very well know everything there is to know
about the encoding process. How else would they know the encoding is bad?
When they send it somewhere seeking often is important and find seeking is
very slow or imprecise? Where bitrate matters and they forgot to enable
CBR? When the rate control system screwed up horribly and made the codec
intra-only? Every single one of the statistics is important to knowing how
good an encode is, regardless of how technical they are. If someone doesn't
care they can just ignore it. Its not a warning, its information.

>useful ones for the common user.
Most common users of ffmpeg (the command line tool) are power users seeing
this on a terminal, not someone who points and clicks to copy files
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacenc: Reduce loglevel of aac_encode_end() from INFO to VER

2017-05-30 Thread Ingo Brückl 
Rostislav Pehlivanov wrote on Mon, 29 May 2017 16:19:51 +0100:

> On 29 May 2017 at 14:55, Ingo Brückl  wrote:

>> AV_LOG_INFO is the default and meant for informational output.
>> The information given by aac_encode_end() is rather technical
>> and of less interest to a common user.

> I like both the x264, x265 and this printing encoding statistics at the
> end. If users want to silence them they can use -loglevel.

If users reduce the loglevel to silence such messages, they will lose all
informational messages as well. It seems that there are two kinds of INFO
messages - technical ones for the advanced user and useful ones for the
common user.

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