Re: [FFmpeg-devel] [PATCH] avfilter/window_func: use a constant instead of acosh()

2016-08-19 Thread Paul B Mahol 
On Saturday, August 20, 2016, James Almer  wrote:

> Should fix compilation with non C99 compilers like msvc 2012, where
> acosh() is not available.
>
> Signed-off-by: James Almer >
> ---
> A fallback function like
>
> static av_always_inline double acosh(double x)
> {
> return log(x + sqrt((x * x) - 1.0));
> }
>
> could be added to libm.h if acosh() is needed sometime in the
> future for values that can't be computed at compile time.
> The above example doesn't take into account things like x == NaN
> and x < 1.0, though.
>
>  libavfilter/window_func.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/window_func.c b/libavfilter/window_func.c
> index fcdf6ea..acf1b20 100644
> --- a/libavfilter/window_func.c
> +++ b/libavfilter/window_func.c
> @@ -117,7 +117,7 @@ void ff_generate_window_func(float *lut, int N, int
> win_func, float *overlap)
>  *overlap = 0.33;
>  break;
>  case WFUNC_DOLPH: {
> -double b = cosh(acosh(pow(10., 3)) / (N-1)), sum, t, c, norm = 0;
> +double b = cosh(7.6009022095419887 / (N-1)), sum, t, c, norm = 0;
>  int j;
>  for (c = 1 - 1 / (b*b), n = (N-1) / 2; n >= 0; --n) {
>  for (sum = !n, b = t = j = 1; j <= n && sum != t; b *= (n-j)
> * (1./j), ++j)


>



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

[FFmpeg-devel] [PATCH] avfilter/window_func: use a constant instead of acosh()

2016-08-19 Thread James Almer 
Should fix compilation with non C99 compilers like msvc 2012, where
acosh() is not available.

Signed-off-by: James Almer 
---
A fallback function like

static av_always_inline double acosh(double x)
{
return log(x + sqrt((x * x) - 1.0));
}

could be added to libm.h if acosh() is needed sometime in the
future for values that can't be computed at compile time.
The above example doesn't take into account things like x == NaN
and x < 1.0, though.

 libavfilter/window_func.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/window_func.c b/libavfilter/window_func.c
index fcdf6ea..acf1b20 100644
--- a/libavfilter/window_func.c
+++ b/libavfilter/window_func.c
@@ -117,7 +117,7 @@ void ff_generate_window_func(float *lut, int N, int 
win_func, float *overlap)
 *overlap = 0.33;
 break;
 case WFUNC_DOLPH: {
-double b = cosh(acosh(pow(10., 3)) / (N-1)), sum, t, c, norm = 0;
+double b = cosh(7.6009022095419887 / (N-1)), sum, t, c, norm = 0;
 int j;
 for (c = 1 - 1 / (b*b), n = (N-1) / 2; n >= 0; --n) {
 for (sum = !n, b = t = j = 1; j <= n && sum != t; b *= (n-j) * 
(1./j), ++j)
-- 
2.9.1

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

Re: [FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread Michael Niedermayer 
On Fri, Aug 19, 2016 at 03:39:58PM -0300, James Almer wrote:
> Windows versions earlier than XP are not supported.
> 
> Should fix compilation of command line tools.
> 
> Signed-off-by: James Almer 
> ---
>  configure | 2 ++
>  1 file changed, 2 insertions(+)

Tested-by: michael
seems to fix build on freebsd mingw32

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread James Almer 
On 8/19/2016 6:13 PM, Hendrik Leppkes wrote:
> On Fri, Aug 19, 2016 at 10:24 PM, James Almer  wrote:
>> On 8/19/2016 5:11 PM, Hendrik Leppkes wrote:
>>> On Fri, Aug 19, 2016 at 8:39 PM, James Almer  wrote:
 Windows versions earlier than XP are not supported.

 Should fix compilation of command line tools.

 Signed-off-by: James Almer 
 ---
  configure | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/configure b/configure
 index 9b92426..2a2c06e 100755
 --- a/configure
 +++ b/configure
 @@ -4919,6 +4919,8 @@ probe_libc(){
  (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 
 15)" ||
  die "ERROR: MinGW32 runtime version must be >= 3.15."
  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
 +check_${pfx}cpp_condition _mingw.h "defined(_WIN32_WINNT) && 
 _WIN32_WINNT >= 0x0502" ||
 +add_${pfx}cppflags -D_WIN32_WINNT=0x0502
  eval test \$${pfx_no_}cc_type = "gcc" &&
  add_${pfx}cppflags -D__printf__=__gnu_printf__
  elif check_${pfx}cpp_condition crtversion.h "defined 
 _VC_CRT_MAJOR_VERSION"; then
 --
 2.9.1
>>>
>>> Does that actually work? libav suggested such a patch, but they
>>> defined another variable to unlock new functions.
>>>
>>> - Hendrik
>>
>> I can't test, i don't have a mingw32 toolchain around. I know it
>> will add the extra define to the command line which in theory
>> should expose SetDllDirectory().
>>
>> What did they define? I can't find anything already in configure.
> 
> https://lists.libav.org/pipermail/libav-devel/2016-August/078670.html
> 
> No clue if its only for things that are CRT features or Windows
> features. can't test either.

According to 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx
_WIN32_WINNT == 0x0502 is enough to expose this function.

Michael, the FATE client seems to be yours. Could you test this patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread Hendrik Leppkes 
On Fri, Aug 19, 2016 at 10:24 PM, James Almer  wrote:
> On 8/19/2016 5:11 PM, Hendrik Leppkes wrote:
>> On Fri, Aug 19, 2016 at 8:39 PM, James Almer  wrote:
>>> Windows versions earlier than XP are not supported.
>>>
>>> Should fix compilation of command line tools.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  configure | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index 9b92426..2a2c06e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -4919,6 +4919,8 @@ probe_libc(){
>>>  (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 
>>> 15)" ||
>>>  die "ERROR: MinGW32 runtime version must be >= 3.15."
>>>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>>> +check_${pfx}cpp_condition _mingw.h "defined(_WIN32_WINNT) && 
>>> _WIN32_WINNT >= 0x0502" ||
>>> +add_${pfx}cppflags -D_WIN32_WINNT=0x0502
>>>  eval test \$${pfx_no_}cc_type = "gcc" &&
>>>  add_${pfx}cppflags -D__printf__=__gnu_printf__
>>>  elif check_${pfx}cpp_condition crtversion.h "defined 
>>> _VC_CRT_MAJOR_VERSION"; then
>>> --
>>> 2.9.1
>>
>> Does that actually work? libav suggested such a patch, but they
>> defined another variable to unlock new functions.
>>
>> - Hendrik
>
> I can't test, i don't have a mingw32 toolchain around. I know it
> will add the extra define to the command line which in theory
> should expose SetDllDirectory().
>
> What did they define? I can't find anything already in configure.

https://lists.libav.org/pipermail/libav-devel/2016-August/078670.html

No clue if its only for things that are CRT features or Windows
features. can't test either.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread James Almer 
On 8/19/2016 5:11 PM, Hendrik Leppkes wrote:
> On Fri, Aug 19, 2016 at 8:39 PM, James Almer  wrote:
>> Windows versions earlier than XP are not supported.
>>
>> Should fix compilation of command line tools.
>>
>> Signed-off-by: James Almer 
>> ---
>>  configure | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 9b92426..2a2c06e 100755
>> --- a/configure
>> +++ b/configure
>> @@ -4919,6 +4919,8 @@ probe_libc(){
>>  (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 
>> 15)" ||
>>  die "ERROR: MinGW32 runtime version must be >= 3.15."
>>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>> +check_${pfx}cpp_condition _mingw.h "defined(_WIN32_WINNT) && 
>> _WIN32_WINNT >= 0x0502" ||
>> +add_${pfx}cppflags -D_WIN32_WINNT=0x0502
>>  eval test \$${pfx_no_}cc_type = "gcc" &&
>>  add_${pfx}cppflags -D__printf__=__gnu_printf__
>>  elif check_${pfx}cpp_condition crtversion.h "defined 
>> _VC_CRT_MAJOR_VERSION"; then
>> --
>> 2.9.1
> 
> Does that actually work? libav suggested such a patch, but they
> defined another variable to unlock new functions.
> 
> - Hendrik

I can't test, i don't have a mingw32 toolchain around. I know it
will add the extra define to the command line which in theory
should expose SetDllDirectory().

What did they define? I can't find anything already in configure.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread Hendrik Leppkes 
On Fri, Aug 19, 2016 at 8:39 PM, James Almer  wrote:
> Windows versions earlier than XP are not supported.
>
> Should fix compilation of command line tools.
>
> Signed-off-by: James Almer 
> ---
>  configure | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/configure b/configure
> index 9b92426..2a2c06e 100755
> --- a/configure
> +++ b/configure
> @@ -4919,6 +4919,8 @@ probe_libc(){
>  (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 15)" 
> ||
>  die "ERROR: MinGW32 runtime version must be >= 3.15."
>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
> +check_${pfx}cpp_condition _mingw.h "defined(_WIN32_WINNT) && 
> _WIN32_WINNT >= 0x0502" ||
> +add_${pfx}cppflags -D_WIN32_WINNT=0x0502
>  eval test \$${pfx_no_}cc_type = "gcc" &&
>  add_${pfx}cppflags -D__printf__=__gnu_printf__
>  elif check_${pfx}cpp_condition crtversion.h "defined 
> _VC_CRT_MAJOR_VERSION"; then
> --
> 2.9.1

Does that actually work? libav suggested such a patch, but they
defined another variable to unlock new functions.

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

Re: [FFmpeg-devel] [PATCH 1/4] V7 - Adding SCTE-35 CUI codec

2016-08-19 Thread Michael Niedermayer 
On Fri, Aug 19, 2016 at 10:45:27AM -0700, Carlos Fernandez Sanz wrote:
> From: Carlos Fernandez 
> 
> Signed-off-by: Carlos Fernandez 
> ---
>  libavcodec/avcodec.h| 1 +
>  libavcodec/codec_desc.c | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 6ac6646..6cdb579 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -630,6 +630,7 @@ enum AVCodecID {
>  /* other specific kind of codecs (generally used for attachments) */
>  AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing 
> at the start of various fake codecs.
>  AV_CODEC_ID_TTF = 0x18000,

> +AV_CODEC_ID_SCTE_35,

can you document in a comment briefly what is in the AVPackets
for most codecs that is clear, SCTE-35 is maybe a bit special
also what the dts/pts values of teh AVPackets mean

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

[FFmpeg-devel] [PATCH] configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets

2016-08-19 Thread James Almer 
Windows versions earlier than XP are not supported.

Should fix compilation of command line tools.

Signed-off-by: James Almer 
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 9b92426..2a2c06e 100755
--- a/configure
+++ b/configure
@@ -4919,6 +4919,8 @@ probe_libc(){
 (__MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 15)" ||
 die "ERROR: MinGW32 runtime version must be >= 3.15."
 add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
+check_${pfx}cpp_condition _mingw.h "defined(_WIN32_WINNT) && 
_WIN32_WINNT >= 0x0502" ||
+add_${pfx}cppflags -D_WIN32_WINNT=0x0502
 eval test \$${pfx_no_}cc_type = "gcc" &&
 add_${pfx}cppflags -D__printf__=__gnu_printf__
 elif check_${pfx}cpp_condition crtversion.h "defined 
_VC_CRT_MAJOR_VERSION"; then
-- 
2.9.1

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

Re: [FFmpeg-devel] Outreachy 2016 december

2016-08-19 Thread Michael Niedermayer 
On Fri, Aug 19, 2016 at 11:12:20AM +0200, Paul B Mahol wrote:
> On 8/18/16, Michael Niedermayer  wrote:
> > On Thu, Aug 18, 2016 at 11:27:49PM +0530, Umair Khan wrote:
> >> On Wed, Aug 17, 2016 at 9:54 PM, Michael Niedermayer
> >>  wrote:
> >> > On Wed, Aug 17, 2016 at 09:16:16PM +0530, Umair Khan wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, Aug 17, 2016 at 5:33 PM, Michael Niedermayer
> >> >>  wrote:
> >> >> > On Fri, Jul 22, 2016 at 07:18:13PM +0200, Michael Niedermayer wrote:
> >> >> >> On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer
> >> >> >> wrote:
> >> >> >> > Hi all
> >> >> >> >
> >> >> >> > The next Outreachy round starts soon
> >> >> >> > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/)
> >> >> >> > to express interrest to participate.
> >> >> >> >
> >> >> >> > We need an admin and backup admins.
> >> >> >>
> >> >> >> ping!
> >> >> >
> >> >> > ping2
> >> >> >
> >> >> > so far the only person doing anything was compn
> >> >> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12?action=history
> >> >> >
> >> >> > I think there are 2 questions that the community needs to awnser
> >> >> >
> >> >> > first, should FFmpeg be participating in the december 2016 round
> >> >> > of Outreachy ?
> >> >> >
> >> >> > If so, some people need to come forth with projects to mentor.
> >> >> > Ive previously asked people privatly one by one i wont do that this
> >> >> > time its a surprissingly large amount of work and anyone else, even
> >> >> > a non programer could ask / organize this and probably better than i
> >> >> > can, asking people is not by strong side ...
> >> >> > And someone needs to come forth as "Admin"
> >> >> >
> >> >> > Second is the question, which project ideas the community wants and
> >> >> > which we do not want.
> >> >> > To me it appeard that there was a disparity between objections to
> >> >> > proojects and suggestions for projects. I think we need more people
> >> >> > suggesting projects and volunteering to mentor than objections
> >> >> > against
> >> >> > project ideas
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > PS: keep in mind august 22 is the official deadline for FFmpeg to
> >> >> > join IIUC. We need some project idea with a mentor first before any
> >> >> > potential admin would contact the Outreachy admins for joining i
> >> >> > suspect ...
> >> >>
> >> >> I'd love to mentor some *easy* project in the Outreachy program
> >> >> definitely. May be I can even get some students to apply to the
> >> >> program.
> >> >
> >> > that would be great, do you have any specific ideas for a easy
> >> > project ?
> >>
> >> I currently have no ideas in mind.
> >> I myself have a lot of experience with AOSP (Android Open Source), may
> >> be something related to that?
> >
> > android or AOSP related projects surely would be interresting
> >
> 
> I added relatively simple task to the page I will mentor, If nobody
> wants to be an admin,
> I can, but I need to know what boring paperwork I need to do _before_
> I apply for the admin.

IIRC outreachy has no true concept of "admin" everyone is just a mentor
The need for an admin is more a need from our side as some tasks
(which no mentor tends to feel responsible for) need to be done by
someone

mentor agreement information is at:
https://wiki.gnome.org/Outreachy/Agreements

i can probably co admin if wanted, but i do not want to be the primary
admin

[...]

-- 
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

[FFmpeg-devel] [PATCH 3/4] V7 - SCTE-35 support in hlsenc

2016-08-19 Thread Carlos Fernandez Sanz 
From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 107 --
 libavformat/scte_35.c | 527 ++
 libavformat/scte_35.h |  86 
 4 files changed, 700 insertions(+), 22 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index fda1e17..7d47465 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -204,7 +204,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
-OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
+OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o scte_35.o
 OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
 OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
 OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9f076ba..7c90157 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1,4 +1,4 @@
-/*
+ /*
  * Apple HTTP Live Streaming segmenter
  * Copyright (c) 2012, Luca Barbato
  *
@@ -38,6 +38,7 @@
 #include "avio_internal.h"
 #include "internal.h"
 #include "os_support.h"
+#include "scte_35.h"
 
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
@@ -48,6 +49,10 @@ typedef struct HLSSegment {
 double duration; /* in seconds */
 int64_t pos;
 int64_t size;
+struct scte_35_event *event;
+int out;
+int adv_count;
+int64_t start_pts;
 
 char key_uri[LINE_BUFFER_SIZE + 1];
 char iv_string[KEYSIZE*2 + 1];
@@ -89,6 +94,8 @@ typedef struct HLSContext {
 uint32_t flags;// enum HLSFlags
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
+char *adv_filename;
+char *adv_subfilename;
 
 int use_localtime;  ///< flag to expand filename with localtime
 int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
@@ -104,6 +111,8 @@ typedef struct HLSContext {
 int nb_entries;
 int discontinuity_set;
 
+int adv_count;
+struct scte_35_interface *scte_iface;
 HLSSegment *segments;
 HLSSegment *last_segment;
 HLSSegment *old_segments;
@@ -203,6 +212,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
 av_freep();
 previous_segment = segment;
 segment = previous_segment->next;
+if (hls->scte_iface)
+hls->scte_iface->unref_scte35_event(_segment->event);
 av_free(previous_segment);
 }
 
@@ -314,8 +325,8 @@ static int hls_mux_init(AVFormatContext *s)
 }
 
 /* Create a new segment and append it to the segment list */
-static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration,
-  int64_t pos, int64_t size)
+static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
double duration, int64_t pos,
+  int64_t start_pts, struct scte_35_event *event, 
int64_t size)
 {
 HLSSegment *en = av_malloc(sizeof(*en));
 char *tmp, *p;
@@ -351,9 +362,23 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 
 en->duration = duration;
 en->pos  = pos;
+en->event= event;
 en->size = size;
+en->start_pts  = start_pts;
 en->next = NULL;
 
+if (hls->scte_iface) {
+if (hls->scte_iface->event_state == EVENT_OUT_CONT) {
+en->adv_count = hls->adv_count;;
+hls->adv_count++;
+en->out = hls->scte_iface->event_state;
+} else {
+hls->adv_count = 0;
+en->out = hls->scte_iface->event_state;
+}
+}
+
+
 if (hls->key_info_file) {
 av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
 av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
@@ -475,9 +500,23 @@ static int hls_window(AVFormatContext *s, int last)
 if (hls->flags & HLS_SINGLE_FILE)
  avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
  en->size, en->pos);
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
+if (hls->scte_iface && (en->event || en->out) ) {
+char *str;
+char fname[1024] = "";
+if (hls->adv_filename) {
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, hls->adv_filename, en->out, en->adv_count, en->start_pts);
+} else {
+if (hls->baseurl)
+strncat(fname, hls->baseurl, 1024);
+strncat(fname, en->filename, 1024);
+str = hls->scte_iface->get_hls_string(hls->scte_iface,

[FFmpeg-devel] [PATCH 2/4] V7 - SCTE-35 extraction from mpegts

2016-08-19 Thread Carlos Fernandez Sanz 
From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/mpegts.c | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..4185af0 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -57,6 +57,7 @@ enum MpegTSFilterType {
 MPEGTS_PES,
 MPEGTS_SECTION,
 MPEGTS_PCR,
+MPEGTS_DATA,
 };
 
 typedef struct MpegTSFilter MpegTSFilter;
@@ -510,6 +511,11 @@ static MpegTSFilter *mpegts_open_pcr_filter(MpegTSContext 
*ts, unsigned int pid)
 return mpegts_open_filter(ts, pid, MPEGTS_PCR);
 }
 
+static MpegTSFilter *mpegts_open_data_filter(MpegTSContext *ts, unsigned int 
pid)
+{
+return mpegts_open_filter(ts, pid, MPEGTS_DATA);
+}
+
 static void mpegts_close_filter(MpegTSContext *ts, MpegTSFilter *filter)
 {
 int pid;
@@ -725,6 +731,12 @@ static const StreamType HDMV_types[] = {
 { 0 },
 };
 
+/* SCTE types */
+static const StreamType SCTE_types[] = {
+{ 0x86, AVMEDIA_TYPE_DATA,  AV_CODEC_ID_SCTE_35},
+{ 0 },
+};
+
 /* ATSC ? */
 static const StreamType MISC_types[] = {
 { 0x81, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AC3 },
@@ -872,6 +884,13 @@ static void reset_pes_packet_state(PESContext *pes)
 av_buffer_unref(>buffer);
 }
 
+static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
+{
+av_init_packet(pkt);
+pkt->data = buffer;
+pkt->size = len;
+}
+
 static int new_pes_packet(PESContext *pes, AVPacket *pkt)
 {
 char *sd;
@@ -1975,6 +1994,19 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 pes->st->id = pes->pid;
 }
 st = pes->st;
+} else if (stream_type == 0x86 && prog_reg_desc ==  AV_RL32("CUEI")) {
+int idx = ff_find_stream_index(ts->stream, pid);
+if (idx >= 0) {
+st = ts->stream->streams[idx];
+} else {
+st = avformat_new_stream(ts->stream, NULL);
+if (!st)
+goto out;
+st->id = pid;
+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
+mpegts_find_stream_type(st, stream_type, SCTE_types);
+mpegts_open_data_filter(ts, pid);
+}
 } else if (stream_type != 0x13) {
 if (ts->pids[pid])
 mpegts_close_filter(ts, ts->pids[pid]); // wrongly added sdt 
filter probably
@@ -2317,7 +2349,14 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 }
-
+} else if (tss->type == MPEGTS_DATA) {
+int idx = ff_find_stream_index(ts->stream, pid);
+p++;
+new_data_packet(p,p_end - p, ts->pkt);
+if (idx >= 0) {
+ts->pkt->stream_index = idx;
+}
+ts->stop_parse = 1;
 } else {
 int ret;
 // Note: The position here points actually behind the current packet.
@@ -2730,6 +2769,8 @@ static int mpegts_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 ret = 0;
 break;
 }
+} else if (ts->pids[i] && ts->pids[i]->type == MPEGTS_DATA) {
+return ret;
 }
 }
 
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 4/4] V7 - Correct Indentation

2016-08-19 Thread Carlos Fernandez Sanz 
From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavformat/hlsenc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7c90157..a73c50d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -360,12 +360,12 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 else
 en->sub_filename[0] = '\0';
 
-en->duration = duration;
-en->pos  = pos;
-en->event= event;
-en->size = size;
+en->duration   = duration;
+en->pos= pos;
+en->event  = event;
+en->size   = size;
 en->start_pts  = start_pts;
-en->next = NULL;
+en->next   = NULL;
 
 if (hls->scte_iface) {
 if (hls->scte_iface->event_state == EVENT_OUT_CONT) {
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/4] V7 - Adding SCTE-35 CUI codec

2016-08-19 Thread Carlos Fernandez Sanz 
From: Carlos Fernandez 

Signed-off-by: Carlos Fernandez 
---
 libavcodec/avcodec.h| 1 +
 libavcodec/codec_desc.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 6ac6646..6cdb579 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -630,6 +630,7 @@ enum AVCodecID {
 /* other specific kind of codecs (generally used for attachments) */
 AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing at 
the start of various fake codecs.
 AV_CODEC_ID_TTF = 0x18000,
+AV_CODEC_ID_SCTE_35,
 
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 24948ca..2612215 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2964,6 +2964,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("binary data"),
 .mime_types= MT("application/octet-stream"),
 },
+{
+.id= AV_CODEC_ID_SCTE_35,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_35",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
+},
 
 /* deprecated codec ids */
 };
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 0/4] v7 - SCTE-35

2016-08-19 Thread Carlos Fernandez Sanz 
* Corrects bug that caused crash on file matrixbench_mpeg2.mpg

Carlos Fernandez (4):
  Adding SCTE-35 CUI codec
  SCTE-35 extraction from mpegts
  SCTE-35 support in hlsenc
  Correct Indentation

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavformat/Makefile|   2 +-
 libavformat/hlsenc.c| 115 ---
 libavformat/mpegts.c|  43 +++-
 libavformat/scte_35.c   | 527 
 libavformat/scte_35.h   |  86 
 7 files changed, 753 insertions(+), 27 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

2016-08-19 Thread Sasi Inguva 
I don't know who the owner of MOV demuxer is. If somebody could do a deeper
review of this patch and approve it that would be great.

Thanks,
Sasi

On Wed, Aug 17, 2016 at 8:59 AM, Sasi Inguva  wrote:

> Thanks
>
> On Aug 17, 2016 6:25 AM, "Clément Bœsch"  wrote:
>
>> On Mon, Aug 15, 2016 at 07:04:56PM -0700, Sasi Inguva wrote:
>> > Changes done. Also commented in the code about the differences between
>> the add_index_entry function and teh ff_add_index_entry function.
>> >
>> > About stream copy, yes there will be a big behavior difference when
>> doing "-c copy" for files with edit lists.
>> > Currently, ignoring edit lists we will copy all packets from input to
>> output. So for videos with edit lists the current way of stream copy is
>> already semantically wrong. In summary these will be the changes with this
>> patch
>> > i) For videos with no edit lists - no change.
>> > ii) For videos with one edit list in their streams
>> >   - Only portion of the video from the closest keyframe before
>> the edit list begins, to the closest keyframe after the edit list ends will
>> be copied.
>> >   - All audio from the start of the audio stream to the end of
>> the edit will be copied.
>> >
>> > iii) For videos with multiple edit lists in their streams
>> >   - For video, the timestamps can be non-monotonocially
>> increasing. Keyframe packets might be repeated. etc.
>> >   - For audio too, timestamps can be non-monotonically
>> increasing. For each edit list we will output packets from the start of the
>> audio stream, so audio will be repeated.
>> >
>> > Though points (ii) and (iii) might look dangerous, we should keep in
>> mind that it is very hard, and maybe impossible to implement proper stream
>> copy of only those portions of streams which are inside edit lists. We need
>> a way to mark some frames as decode-and-discard, and maybe writing edit
>> lists in case of MOV container is a way but if we are doing  -c copy to
>> some other container, it won't be possible mostly. If (ii) and (iii) sound
>> unacceptable I can gate the mov_fix_index function behind a no-stream-copy
>> condition, if there is a way to do so.
>> >
>>
>> OK.
>>
>> So. I've made some test with a bunch of personal samples from different
>> different sources and it fixes the playback for all of them. I don't have
>> much more comment as it seems to work well. I'm not the maintainer of the
>> MOV demuxer though, so don't take this as a OK.
>>
>> Someone should probably do a deeper review (hint: look at mov_fix_index()
>> in particular)
>>
>> Thanks
>>
>> --
>> Clément B.
>>
>> ___
>> 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] [GSoC] Motion Interpolation

2016-08-19 Thread Robert Krüger 
On Fri, Aug 19, 2016 at 4:17 PM, Paul B Mahol  wrote:

> On 8/19/16, Davinder Singh  wrote:
> > On Fri, Aug 19, 2016 at 3:27 AM Paul B Mahol  wrote:
> >
> >> On 8/18/16, Paul B Mahol  wrote:
> >> > On 8/18/16, Davinder Singh  wrote:
> >> >> On Thu, Aug 18, 2016 at 11:52 PM Paul B Mahol 
> wrote:
> >> >>
> >> >>> [...]
> >> >>>
> >> >>
> >> >> i tried to modify EPZS. i removed the early termination threshold
> which
> >> >> skip some predictors :-/
> >> >> new score:
> >> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
> >> >> stddev: 1.02 PSNR: 47.94 MAXDIFF: 186 bytes:476928000/474163200
> >> >>
> >> >> original epzs:
> >> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
> >> >> stddev: 1.07 PSNR: 47.51 MAXDIFF: 186 bytes:476928000/474163200
> >> >>
> >> >> epzs uses small diamond pattern. a new pattern could also help.
> >> >>
> >> >> Please post patch like last time.
> >> >>>
> >> >>
> >> >> latest patch attached.
> >> >>
> >> >
> >> > UMH ME is still somehow buggy.
> >> >
> >> > EPZS seems good, great work!
> >>
> >
> > what epzs did that i couldn't be able to do with umh is, it fixed lot of
> > artifacts that require bigger search window. if i increase search param
> > with umh it increase the artifacts. same happen with esa.
> > i guess umh uses less predictors but a better search pattern. if we
> combine
> > both epzs and uhm, it should increase the quality further.
> >
> >
> >> Actually after second look EPZS is not much better than UMH here.
> >>
>
> 720p parkjoy sample looks fine with EPZS it seems.
>
> >
> > please give me link to the video that you tested.
>
> http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg
>
> Too much dark scenes.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Impressive results, great job!

I just tried  minterpolate=fps=250:mc_mode=aobmc:me=epzs and did have some
artefacts in one of my slowmo samples but overall the quality is very, very
nice! If you're interested in more samples or in more testing, let me know.

Is the command line I used the one best for reducing artefacts or are there
options known to be better in terms of artefact reduction?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: check for SetDllDirectory() availability

2016-08-19 Thread James Almer 
On 8/19/2016 5:55 AM, Hendrik Leppkes wrote:
> On Fri, Aug 19, 2016 at 7:01 AM, James Almer  wrote:
>> It's only available on Windows XP or newer.
> 
> We don't support anything older.
> 
> - Hendrik

Then why aren't we forcing -D_WIN32_WINNT=0x0502 as a minimum during
configure for mingw32 targets, like we're doing for MSVC?
Right now a simple ./configure for that target is broken, as you can
see in FATE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-19 Thread Paul B Mahol 
On 8/19/16, Davinder Singh  wrote:
> On Fri, Aug 19, 2016 at 3:27 AM Paul B Mahol  wrote:
>
>> On 8/18/16, Paul B Mahol  wrote:
>> > On 8/18/16, Davinder Singh  wrote:
>> >> On Thu, Aug 18, 2016 at 11:52 PM Paul B Mahol  wrote:
>> >>
>> >>> [...]
>> >>>
>> >>
>> >> i tried to modify EPZS. i removed the early termination threshold which
>> >> skip some predictors :-/
>> >> new score:
>> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
>> >> stddev: 1.02 PSNR: 47.94 MAXDIFF: 186 bytes:476928000/474163200
>> >>
>> >> original epzs:
>> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
>> >> stddev: 1.07 PSNR: 47.51 MAXDIFF: 186 bytes:476928000/474163200
>> >>
>> >> epzs uses small diamond pattern. a new pattern could also help.
>> >>
>> >> Please post patch like last time.
>> >>>
>> >>
>> >> latest patch attached.
>> >>
>> >
>> > UMH ME is still somehow buggy.
>> >
>> > EPZS seems good, great work!
>>
>
> what epzs did that i couldn't be able to do with umh is, it fixed lot of
> artifacts that require bigger search window. if i increase search param
> with umh it increase the artifacts. same happen with esa.
> i guess umh uses less predictors but a better search pattern. if we combine
> both epzs and uhm, it should increase the quality further.
>
>
>> Actually after second look EPZS is not much better than UMH here.
>>

720p parkjoy sample looks fine with EPZS it seems.

>
> please give me link to the video that you tested.

http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg

Too much dark scenes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames

2016-08-19 Thread Станислав Долганов 
Fix some problems.

2016-08-18 21:50 GMT+03:00 Moritz Barsnick :

> On Thu, Aug 18, 2016 at 14:49:28 +0300, Станислав Долганов wrote:
>
> > +static int decode_q_branch(FFV1Context *f, int level, int x, int y){
> > +RangeCoder *const c = >slice_context[0]->c;
> > +OBMCContext *s = >obmc;
> > +const int w= s->b_width << s->block_max_depth;
>
> This whole function breaks ffmpeg style (wrt brackets and whitespace)
> throughout. How come style is so different here from the rest of the
> patch?
>
> > @@ -409,6 +554,7 @@ static int read_extra_header(FFV1Context *f)
> >  ff_build_rac_states(c, 0.05 * (1LL << 32), 256 - 8);
> >
> >  f->version = get_symbol(c, state, 0);
> > +
> >  if (f->version < 2) {
>
> This is still a stray change.
>
> >  if ((ret = read_header(f)) < 0)
> >  return ret;
> >  f->key_frame_ok = 1;
> > +
> >  } else {
>
> This is still a stray change.
>
> > +for(plane_index=0; plane_index < f->obmc.nb_planes;
> plane_index++){
> > +PlaneObmc *pc= >obmc.plane[plane_index];
> > +int w= pc->width;
> > +int h= pc->height;
> > +
> > +if(!p->key_frame){
>
> Whitespace style.
>
> > @@ -906,6 +1153,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame, AVPac
> >  if (f->last_picture.f)
> >  ff_thread_release_buffer(avctx, >last_picture);
> >  f->cur = NULL;
> > +
> >  if ((ret = av_frame_ref(data, f->picture.f)) < 0)
> >  return ret;
>
> Yet another stray change.
>
> > @@ -917,15 +1165,24 @@ static int decode_frame(AVCodecContext *avctx,
> void *data, int *got_frame, AVPac
> >  #if HAVE_THREADS
> >  static int init_thread_copy(AVCodecContext *avctx)
> >  {
> > +
> >  FFV1Context *f = avctx->priv_data;
> >  int i, ret;
>
> Ditto.
>
>
> > -ThreadFrame picture = fdst->picture, last_picture =
> fdst->last_picture;
> > +ThreadFrame picture = fdst->picture, last_picture =
> fdst->last_picture, residual = fdst->residual;
> > +uint16_t *c_image_line_buf = fdst->c_image_line_buf,
> *p_image_line_buf = fdst->p_image_line_buf;
>
> I personally find comma-separated declarations with assignments very
> hard to read, but I don't know whether there's a policy on that. (And
> you may be mixing declarations and assignments, which will give
> warnings.)
>
> > +for (i = 0; i < MAX_REF_FRAMES; i++)
> > +last_pictures[i] = fdst->obmc.last_pictures[i];
>
> memcpy()? (Not sure.)
> This occurs a few times.
>
> > @@ -1003,13 +1322,41 @@ static int update_thread_context(AVCodecContext
> *dst, const AVCodecContext *src)
> >
> >  av_assert1(fdst->max_slice_count == fsrc->max_slice_count);
> >
> > -
> >  ff_thread_release_buffer(dst, >picture);
>
> Another stray change.
>
> > +for(j=0; j<9; j++) {
> > +int is_chroma= !!(j%3);
> > +int h= is_chroma ? AV_CEIL_RSHIFT(fsrc->avctx->height,
> fsrc->chroma_v_shift) : fsrc->avctx->height;
> > +int ls= fdst->obmc.last_pictures[i]->linesize[j%3];
>
> Whitespace style.
>
> > +uint8_t state[128 + 32*128];
>
> I saw that same number somewhere above. Could it be defined as a
> constant?
>
> > +rc = >c; state = coder->state;
>
> Putting these on the same line is not necessary.
>
> > +coder->c.bytestream_start = coder->c.bytestream = coder->buffer;
> //FIXME end/start? and at the other stoo
>
> Do the FIXMEs need to get fixed before the patch is ready for
> inclusion?
>
> > +if (c->priv_data) {
> > +av_freep(>priv_data);
>
> I thought Michael had explained that the NULL check is not necessary?
>
> > +static void put_block_type  (struct ObmcCoderContext *c, int ctx, int
> type)
>
> Stray whitespace. Are you trying to align the brackets in this group of
> functions?
>
> > +if (!f->key_frame) { //FIXME update_mc
>
> Fix this?
>
> > +for(plane_index=0; plane_indexobmc.nb_planes, 2);
> plane_index++){
> > +PlaneObmc *p= >obmc.plane[plane_index];
>
> Again, whitespace.
>
> > +const int width= f->avctx->width;
> > +const int height= f->avctx->height;
>
> Whitespace.
>
> > +for(i=0; i < f->obmc.nb_planes; i++)
> > +{
> > +int hshift= i ? f->chroma_h_shift : 0;
> > +int vshift= i ? f->chroma_v_shift : 0;
>
> Ditto.
>
> > +for(plane_index=0; plane_index < f->obmc.nb_planes;
> plane_index++){
> > +PlaneObmc *p= >obmc.plane[plane_index];
> > +int w= p->width;
> > +int h= p->height;
> > +
> > +if(pic->pict_type == AV_PICTURE_TYPE_I) {
>
> Ditto.
>
> Functionally, I have no understanding of the code though. ;-)
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



-- 
Станислав Долганов


0002-FFV1-p-frames.patch
Description: Binary data

Re: [FFmpeg-devel] avformat/movenc: allow rewriting extradata

2016-08-19 Thread Michael Niedermayer 
On Fri, Aug 19, 2016 at 04:35:59PM +0530, Umair Khan wrote:
> Hi,
> 
> On Fri, Aug 19, 2016 at 4:46 AM, Michael Niedermayer
>  wrote:
> > On Thu, Aug 18, 2016 at 11:21:00AM +0530, Umair Khan wrote:
> >> Hi,
> >>
> >> On Thu, Aug 18, 2016 at 2:10 AM, Umair Khan  wrote:
> >> > On Thu, Aug 18, 2016 at 1:28 AM, James Almer  wrote:
> >> >> On 8/17/2016 3:59 PM, Umair Khan wrote:
> >> >>> Hi,
> >> >>>
> >> >>> Patch attached.
> >> >>>
> >> >>> I hope this is the cleanest solution. :)
> >> >>>
> >> >>> - Umair
> >> >>>
> >> >>>
> >> >>> patch.diff
> >> >>>
> >> >>>
> >> >>> From be04357d54897173b1776ed92ab8347b3cdffd46 Mon Sep 17 00:00:00 2001
> >> >>> From: Umair Khan 
> >> >>> Date: Thu, 18 Aug 2016 00:27:42 +0530
> >> >>> Subject: [PATCH] avformat/movenc: allow rewriting extradata
> >> >>>
> >> >>> Signed-off-by: Umair Khan 
> >> >>> ---
> >> >>>  libavformat/movenc.c | 30 ++
> >> >>>  libavformat/movenc.h |  2 ++
> >> >>>  2 files changed, 32 insertions(+)
> >> >>>
> >> >>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> >>> index 14db880..b33f24c 100644
> >> >>> --- a/libavformat/movenc.c
> >> >>> +++ b/libavformat/movenc.c
> >> >>> @@ -4919,6 +4919,19 @@ static int 
> >> >>> mov_write_single_packet(AVFormatContext *s, AVPacket *pkt)
> >> >>>  trk->start_cts = pkt->pts - pkt->dts;
> >> >>>  else
> >> >>>  trk->start_cts = 0;
> >> >>> +}
> >> >>> +
> >> >>> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
> >> >>> +int side_size = 0;
> >> >>> +uint8_t *side = av_packet_get_side_data(pkt, 
> >> >>> AV_PKT_DATA_NEW_EXTRADATA, _size);
> >> >>> +av_log(s, AV_LOG_ERROR, "side_size = %d\n", 
> >> >>> side_size);
> >> >>
> >> >> I'm not sure this is useful at all, but if you think it is
> >> >> then make it either AV_ERROR_VERBOSE or AV_ERROR_DEBUG.
> >> >
> >> > Sorry for this. I overlooked it.
> >> > I'll resend the patch.
> >>
> >> Updated patch attached.
> >>
> >> - Umair
> >
> >>  movenc.c |   28 
> >>  movenc.h |2 ++
> >>  2 files changed, 30 insertions(+)
> >> 0b95f020ea5f06493a88680a686398eddcd954de  patch.diff
> >> From 3bda0c5d727e7b1f45e8fddc8c0022c0a1d5e66a Mon Sep 17 00:00:00 2001
> >> From: Umair Khan 
> >> Date: Thu, 18 Aug 2016 00:27:42 +0530
> >> Subject: [PATCH] avformat/movenc: allow rewriting extradata
> >>
> >> Signed-off-by: Umair Khan 
> >> ---
> >>  libavformat/movenc.c | 28 
> >>  libavformat/movenc.h |  2 ++
> >>  2 files changed, 30 insertions(+)
> >>
> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> index 14db880..1235b37 100644
> >> --- a/libavformat/movenc.c
> >> +++ b/libavformat/movenc.c
> >> @@ -4919,6 +4919,18 @@ static int mov_write_single_packet(AVFormatContext 
> >> *s, AVPacket *pkt)
> >>  trk->start_cts = pkt->pts - pkt->dts;
> >>  else
> >>  trk->start_cts = 0;
> >> +}
> >> +
> >> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
> >> +int side_size = 0;
> >> +uint8_t *side = av_packet_get_side_data(pkt, 
> >> AV_PKT_DATA_NEW_EXTRADATA, _size);
> >> +if (side && side_size > 0 && (side_size != 
> >> par->extradata_size || memcmp(side, par->extradata, side_size))) {
> >> +av_free(par->extradata);
> >
> >> +par->extradata = av_mallocz(side_size + 
> >> AV_INPUT_BUFFER_PADDING_SIZE);
> >> +memcpy(par->extradata, side, side_size);
> >
> > missing check for malloc failure
> 
> Updated patch attached.
> 
> - Umair

>  movenc.c |   31 +++
>  movenc.h |2 ++
>  2 files changed, 33 insertions(+)
> 9a062ecc1177d22c09112776a9079c86e9c71cb3  patch.diff
> From 57cf341487672f60e0304ebc863f6cae5e55e676 Mon Sep 17 00:00:00 2001
> From: Umair Khan 
> Date: Thu, 18 Aug 2016 00:27:42 +0530
> Subject: [PATCH] avformat/movenc: allow rewriting extradata
> 
> Signed-off-by: Umair Khan 
> ---
>  libavformat/movenc.c | 31 +++
>  libavformat/movenc.h |  2 ++
>  2 files changed, 33 insertions(+)

applied

ill change this slightly to be more robust in the error case (it
doesnt clear extradata_size i think if extradata is freed in the error
case

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: dshow prevent some windows 10 anniv. ed crashes

2016-08-19 Thread Roger Pack 
No complaints, would someone please push it for me? Sorry still
haven't figured out the key thing yet.

On 8/16/16, Roger Pack  wrote:
> Windows 10 anniversary edition screwed with how dshow video capture works.
> This patch "helps" in some instances, though it still crashes with
> rgb24 input (still working on that), at least now it works with yuvp
> etc.
> Thanks.
> -Roger (a dshow maintainer)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-19 Thread Moritz Barsnick 
On Fri, Aug 19, 2016 at 11:19:22 +, Davinder Singh wrote:
> > Same here and many other places. "!=" is a valid operator. ;)
> 
> yes, that would be in case of == operator, not = operator, no?

D'uh, stupid me, I missed that. Sorry!

> will do. can you tell which is faster?

I *believe* switch/case is faster (IIRC):
- The code doesn't need to check a chain of if() cases to get to the
  later ones.
- The compiler can create a look-up table and jump through to the
  correct code block.

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

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-19 Thread Davinder Singh 
On Fri, Aug 19, 2016 at 3:27 AM Paul B Mahol  wrote:

> On 8/18/16, Paul B Mahol  wrote:
> > On 8/18/16, Davinder Singh  wrote:
> >> On Thu, Aug 18, 2016 at 11:52 PM Paul B Mahol  wrote:
> >>
> >>> [...]
> >>>
> >>
> >> i tried to modify EPZS. i removed the early termination threshold which
> >> skip some predictors :-/
> >> new score:
> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
> >> stddev: 1.02 PSNR: 47.94 MAXDIFF: 186 bytes:476928000/474163200
> >>
> >> original epzs:
> >> $ tiny_psnr 60_source_2.yuv 60_bbb.yuv
> >> stddev: 1.07 PSNR: 47.51 MAXDIFF: 186 bytes:476928000/474163200
> >>
> >> epzs uses small diamond pattern. a new pattern could also help.
> >>
> >> Please post patch like last time.
> >>>
> >>
> >> latest patch attached.
> >>
> >
> > UMH ME is still somehow buggy.
> >
> > EPZS seems good, great work!
>

what epzs did that i couldn't be able to do with umh is, it fixed lot of
artifacts that require bigger search window. if i increase search param
with umh it increase the artifacts. same happen with esa.
i guess umh uses less predictors but a better search pattern. if we combine
both epzs and uhm, it should increase the quality further.


> Actually after second look EPZS is not much better than UMH here.
>

please give me link to the video that you tested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

2016-08-19 Thread Davinder Singh 
On Fri, Aug 19, 2016 at 1:50 AM Moritz Barsnick  wrote:

> On Thu, Aug 18, 2016 at 19:26:39 +, Davinder Singh wrote:
>
> > +@table @option
> > +@item algo
> > +Set the algorithm to be used. Accepts one of the following values:
> > +
> > +@table @samp
> > +@item ebma
> > +Exhaustive block matching algorithm.
> > +@end table
> > +Default value is @samp{ebma}.
> [...]
> > +{ "method", "specify motion estimation method", OFFSET(method),
> AV_OPT_TYPE_INT, {.i64 = ME_METHOD_ESA}, ME_METHOD_ESA, ME_METHOD_UMH,
> FLAGS, "method" },
> > +CONST("esa",   "exhaustive search",
> ME_METHOD_ESA,   "method"),
> > +CONST("tss",   "three step search",
> ME_METHOD_TSS,   "method"),
> > +CONST("tdls",  "two dimensional logarithmic search",
> ME_METHOD_TDLS,  "method"),
> > +CONST("ntss",  "new three step search",
> ME_METHOD_NTSS,  "method"),
> > +CONST("fss",   "four step search",
>  ME_METHOD_FSS,   "method"),
> > +CONST("ds","diamond search",
>  ME_METHOD_DS,"method"),
> > +CONST("hexbs", "hexagon-based search",
>  ME_METHOD_HEXBS, "method"),
> > +CONST("epzs",  "enhanced predictive zonal search",
>  ME_METHOD_EPZS,  "method"),
> > +CONST("umh",   "uneven multi-hexagon search",
> ME_METHOD_UMH,   "method"),
>
> Documentation mismatches implementation. I think you forgot to adapt
> the former to your modifications.
> a) It's not "algo", it's "method".
> b) Default is "esa", not the non-existent "ebma".
> c) You should actually list all possible values.
>
> Furthermore, documentation for minterpolate is missing.
>

docs are yet to be updated.


> > +#define COST_MV(x, y)\
> > +{\
> > +cost = me_ctx->get_cost(me_ctx, x_mb, y_mb, x, y);\
> > +if (cost < cost_min) {\
> > +cost_min = cost;\
> > +mv[0] = x;\
> > +mv[1] = y;\
> > +}\
> > +}
>
> The recommendation for function macros is to wrap the definition into a
> "do { } while (0)". You do do that in other places.
>

will do.


>
> > +if (!(cost_min = me_ctx->get_cost(me_ctx, x_mb, y_mb, x_mb, y_mb)))
>
> Why not
>if (cost_min != me_ctx->get_cost(me_ctx, x_mb, y_mb, x_mb, y_mb))
> ??
>
> > +if (!(cost_min = me_ctx->get_cost(me_ctx, x_mb, y_mb, x_mb, y_mb)))
> > +return cost_min;
>
> Same here and many other places. "!=" is a valid operator. ;)
>

yes, that would be in case of == operator, not = operator, no?


> > +#if 1
> > +for (i = 0; i < 8; i++)
> > +COST_P_MV(x + dia[i][0], y + dia[i][1]);
> > +#else
>
> These checks will disappear in the final version?
>
>
yes.


>
> > +{ "fps", "specify the frame rate", OFFSET(frame_rate),
> AV_OPT_TYPE_RATIONAL, {.dbl = 60}, 0, INT_MAX, FLAGS },
>
> Could you handle this with an AV_OPT_TYPE_VIDEO_RATE, made specially
> for cases such as this?
>

ok, will look into it.


>
> > +{ "mb_size", "specify the macroblock size", OFFSET(mb_size),
> AV_OPT_TYPE_INT, {.i64 = 16}, 4, 16, FLAGS },
> > +{ "search_param", "specify search parameter", OFFSET(search_param),
> AV_OPT_TYPE_INT, {.i64 = 32}, 4, INT_MAX, FLAGS },
>
> You can drop the "specify the" part. Every option lets you specify
> something. ;-)
>

sure. i thought of doing that while updating docs.


>
> > +//int term = (mv_x * mv_x + mv_y * mv_y);
> > +//int term = (FFABS(mv_x - me_ctx->pred_x) + FFABS(mv_y -
> me_ctx->pred_y));
> > +//fprintf(stdout, "sbad: %llu, term: %d\n", sbad, term);
> > +return sbad;// + term;
>
> Needs to be fixed?


> > +avcodec_get_chroma_sub_sample(inlink->format,
> _ctx->chroma_h_shift, _ctx->chroma_v_shift); //TODO remove
>
> To do.
>
> > +if (!(mi_ctx->int_blocks =
> av_mallocz_array(mi_ctx->b_count, sizeof(Block
>
> !=
>
> > +if (mi_ctx->me_method == ME_METHOD_ESA)
> > +ff_me_search_esa(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_TSS)
> > +ff_me_search_tss(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_TDLS)
> > +ff_me_search_tdls(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_NTSS)
> > +ff_me_search_ntss(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_FSS)
> > +ff_me_search_fss(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_DS)
> > +ff_me_search_ds(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_HEXBS)
> > +ff_me_search_hexbs(me_ctx, x_mb, y_mb, mv);
> > +else if (mi_ctx->me_method == ME_METHOD_EPZS) {
>
> This calls for a switch/case. (There was another place in the code
> which I haven't quoted.) Readability wouldn't improve significantly,
> but the advantage is that the compiler can check whether you forgot to
> add code for certain values.
>

will do. can you tell which is faster?


>
> > +#if CACHE_MVS
> Will this stay in?
>

it will be removed.


>
> > +#if !CACHE_MVS
> Ditto.
>
> Sorry if

Re: [FFmpeg-devel] [PATCHv5] af_hdcd: Extract generic HDCD decoder, wrap for ffmpeg

2016-08-19 Thread Burt P. 
I've reconsidered and I think this change may not be a good idea at this time.

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

Re: [FFmpeg-devel] avformat/movenc: allow rewriting extradata

2016-08-19 Thread Umair Khan 
Hi,

On Fri, Aug 19, 2016 at 4:46 AM, Michael Niedermayer
 wrote:
> On Thu, Aug 18, 2016 at 11:21:00AM +0530, Umair Khan wrote:
>> Hi,
>>
>> On Thu, Aug 18, 2016 at 2:10 AM, Umair Khan  wrote:
>> > On Thu, Aug 18, 2016 at 1:28 AM, James Almer  wrote:
>> >> On 8/17/2016 3:59 PM, Umair Khan wrote:
>> >>> Hi,
>> >>>
>> >>> Patch attached.
>> >>>
>> >>> I hope this is the cleanest solution. :)
>> >>>
>> >>> - Umair
>> >>>
>> >>>
>> >>> patch.diff
>> >>>
>> >>>
>> >>> From be04357d54897173b1776ed92ab8347b3cdffd46 Mon Sep 17 00:00:00 2001
>> >>> From: Umair Khan 
>> >>> Date: Thu, 18 Aug 2016 00:27:42 +0530
>> >>> Subject: [PATCH] avformat/movenc: allow rewriting extradata
>> >>>
>> >>> Signed-off-by: Umair Khan 
>> >>> ---
>> >>>  libavformat/movenc.c | 30 ++
>> >>>  libavformat/movenc.h |  2 ++
>> >>>  2 files changed, 32 insertions(+)
>> >>>
>> >>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> >>> index 14db880..b33f24c 100644
>> >>> --- a/libavformat/movenc.c
>> >>> +++ b/libavformat/movenc.c
>> >>> @@ -4919,6 +4919,19 @@ static int 
>> >>> mov_write_single_packet(AVFormatContext *s, AVPacket *pkt)
>> >>>  trk->start_cts = pkt->pts - pkt->dts;
>> >>>  else
>> >>>  trk->start_cts = 0;
>> >>> +}
>> >>> +
>> >>> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
>> >>> +int side_size = 0;
>> >>> +uint8_t *side = av_packet_get_side_data(pkt, 
>> >>> AV_PKT_DATA_NEW_EXTRADATA, _size);
>> >>> +av_log(s, AV_LOG_ERROR, "side_size = %d\n", side_size);
>> >>
>> >> I'm not sure this is useful at all, but if you think it is
>> >> then make it either AV_ERROR_VERBOSE or AV_ERROR_DEBUG.
>> >
>> > Sorry for this. I overlooked it.
>> > I'll resend the patch.
>>
>> Updated patch attached.
>>
>> - Umair
>
>>  movenc.c |   28 
>>  movenc.h |2 ++
>>  2 files changed, 30 insertions(+)
>> 0b95f020ea5f06493a88680a686398eddcd954de  patch.diff
>> From 3bda0c5d727e7b1f45e8fddc8c0022c0a1d5e66a Mon Sep 17 00:00:00 2001
>> From: Umair Khan 
>> Date: Thu, 18 Aug 2016 00:27:42 +0530
>> Subject: [PATCH] avformat/movenc: allow rewriting extradata
>>
>> Signed-off-by: Umair Khan 
>> ---
>>  libavformat/movenc.c | 28 
>>  libavformat/movenc.h |  2 ++
>>  2 files changed, 30 insertions(+)
>>
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index 14db880..1235b37 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -4919,6 +4919,18 @@ static int mov_write_single_packet(AVFormatContext 
>> *s, AVPacket *pkt)
>>  trk->start_cts = pkt->pts - pkt->dts;
>>  else
>>  trk->start_cts = 0;
>> +}
>> +
>> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
>> +int side_size = 0;
>> +uint8_t *side = av_packet_get_side_data(pkt, 
>> AV_PKT_DATA_NEW_EXTRADATA, _size);
>> +if (side && side_size > 0 && (side_size != 
>> par->extradata_size || memcmp(side, par->extradata, side_size))) {
>> +av_free(par->extradata);
>
>> +par->extradata = av_mallocz(side_size + 
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> +memcpy(par->extradata, side, side_size);
>
> missing check for malloc failure

Updated patch attached.

- Umair
From 57cf341487672f60e0304ebc863f6cae5e55e676 Mon Sep 17 00:00:00 2001
From: Umair Khan 
Date: Thu, 18 Aug 2016 00:27:42 +0530
Subject: [PATCH] avformat/movenc: allow rewriting extradata

Signed-off-by: Umair Khan 
---
 libavformat/movenc.c | 31 +++
 libavformat/movenc.h |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 14db880..137f437 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4919,6 +4919,21 @@ static int mov_write_single_packet(AVFormatContext *s, 
AVPacket *pkt)
 trk->start_cts = pkt->pts - pkt->dts;
 else
 trk->start_cts = 0;
+}   
+
+if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
+int side_size = 0;
+uint8_t *side = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, _size);
+if (side && side_size > 0 && (side_size != par->extradata_size 
|| memcmp(side, par->extradata, side_size))) {
+av_free(par->extradata);
+par->extradata = av_mallocz(side_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!par->extradata) {
+return AVERROR(ENOMEM);
+}
+memcpy(par->extradata, side,

Re: [FFmpeg-devel] Outreachy 2016 december

2016-08-19 Thread Paul B Mahol 
On 8/18/16, Michael Niedermayer  wrote:
> On Thu, Aug 18, 2016 at 11:27:49PM +0530, Umair Khan wrote:
>> On Wed, Aug 17, 2016 at 9:54 PM, Michael Niedermayer
>>  wrote:
>> > On Wed, Aug 17, 2016 at 09:16:16PM +0530, Umair Khan wrote:
>> >> Hi,
>> >>
>> >> On Wed, Aug 17, 2016 at 5:33 PM, Michael Niedermayer
>> >>  wrote:
>> >> > On Fri, Jul 22, 2016 at 07:18:13PM +0200, Michael Niedermayer wrote:
>> >> >> On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer
>> >> >> wrote:
>> >> >> > Hi all
>> >> >> >
>> >> >> > The next Outreachy round starts soon
>> >> >> > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/)
>> >> >> > to express interrest to participate.
>> >> >> >
>> >> >> > We need an admin and backup admins.
>> >> >>
>> >> >> ping!
>> >> >
>> >> > ping2
>> >> >
>> >> > so far the only person doing anything was compn
>> >> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12?action=history
>> >> >
>> >> > I think there are 2 questions that the community needs to awnser
>> >> >
>> >> > first, should FFmpeg be participating in the december 2016 round
>> >> > of Outreachy ?
>> >> >
>> >> > If so, some people need to come forth with projects to mentor.
>> >> > Ive previously asked people privatly one by one i wont do that this
>> >> > time its a surprissingly large amount of work and anyone else, even
>> >> > a non programer could ask / organize this and probably better than i
>> >> > can, asking people is not by strong side ...
>> >> > And someone needs to come forth as "Admin"
>> >> >
>> >> > Second is the question, which project ideas the community wants and
>> >> > which we do not want.
>> >> > To me it appeard that there was a disparity between objections to
>> >> > proojects and suggestions for projects. I think we need more people
>> >> > suggesting projects and volunteering to mentor than objections
>> >> > against
>> >> > project ideas
>> >> >
>> >> > Thanks
>> >> >
>> >> > PS: keep in mind august 22 is the official deadline for FFmpeg to
>> >> > join IIUC. We need some project idea with a mentor first before any
>> >> > potential admin would contact the Outreachy admins for joining i
>> >> > suspect ...
>> >>
>> >> I'd love to mentor some *easy* project in the Outreachy program
>> >> definitely. May be I can even get some students to apply to the
>> >> program.
>> >
>> > that would be great, do you have any specific ideas for a easy
>> > project ?
>>
>> I currently have no ideas in mind.
>> I myself have a lot of experience with AOSP (Android Open Source), may
>> be something related to that?
>
> android or AOSP related projects surely would be interresting
>

I added relatively simple task to the page I will mentor, If nobody
wants to be an admin,
I can, but I need to know what boring paperwork I need to do _before_
I apply for the admin.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: check for SetDllDirectory() availability

2016-08-19 Thread Hendrik Leppkes 
On Fri, Aug 19, 2016 at 7:01 AM, James Almer  wrote:
> It's only available on Windows XP or newer.

We don't support anything older.

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

Re: [FFmpeg-devel] [PATCH]lavf/pcmdec: Map mime_type audio/L16 to the s16le demuxer

2016-08-19 Thread Carl Eugen Hoyos 
Hi James!

> Am 18.08.2016 um 06:47 schrieb James Almer :
> 
>> On 8/17/2016 1:14 PM, Carl Eugen Hoyos wrote:
>> Hi!
>> 
>> 2016-08-17 17:32 GMT+02:00 Michael Niedermayer :
 +av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, _type);
 +if (mime_type && s->iformat->mime_type) {
 +int rate = 0, channels = 0;
 +size_t len = strlen(s->iformat->mime_type);
 +if (!strncmp(s->iformat->mime_type, mime_type, len)) {
 +uint8_t *options = mime_type + len;
 +len = strlen(mime_type);
 +while (options < mime_type + len) {
 +options = strstr(options, ";");
 +if (!options++)
 +break;
 +if (!rate)
 +sscanf(options, " rate=%d", );
 +if (!channels)
 +sscanf(options, " channels=%d", );
 +}
>>> 
>>> rate and channels probably should be subject to some sanity checks
>>> like < 0
>> 
>> Sanity checks for <0 added, INT_MAX is also possible with the current
>> code.
>> 
>> Patch applied, Carl Eugen
> 
> This broke msvc
> http://fate.ffmpeg.org/log.cgi?time=20160817230315=compile=x86_64-msvc12-windows-native
> 
> Moving __VA_ARGS__ to the end of the macro may be enough to fix this,
> but i can't test.

I pushed this change yesterday and fate is happy again.
Thank you!

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