Re: [FFmpeg-devel] [PATCH 1/2] avformat/http: Added a library-internal API for signalling end of chunk

2017-12-21 Thread wm4
On Fri, 22 Dec 2017 12:34:41 +0530
Karthick J  wrote:

> From: Karthick Jeyapal 
> 
> Right now there is no explicit way to signal end of chunk, when http_multiple 
> is set.
> ff_http_do_new_request() function implicitly signals end of chunk. But that 
> could be too late for certain applications.
> Hence added a new function ff_http_signal_end_of_chunk() which could be used 
> internally within libavformat.
> ---
>  libavformat/http.c | 17 ++---
>  libavformat/http.h |  9 +
>  2 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index cf86adc..d8224de 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -307,9 +307,11 @@ int ff_http_do_new_request(URLContext *h, const char 
> *uri)
>  AVDictionary *options = NULL;
>  int ret;
>  
> -ret = http_shutdown(h, h->flags);
> -if (ret < 0)
> -return ret;
> +if (!s->end_chunked_post) {
> +ret = http_shutdown(h, h->flags);
> +if (ret < 0)
> +return ret;
> +}
>  
>  s->end_chunked_post = 0;
>  s->chunkend  = 0;
> @@ -325,6 +327,15 @@ int ff_http_do_new_request(URLContext *h, const char 
> *uri)
>  return ret;
>  }
>  
> +int ff_http_signal_end_of_chunk(URLContext *h) {
> +HTTPContext *s = h->priv_data;
> +int ret = 0;
> +if (!s->end_chunked_post) {
> +ret = http_shutdown(h, h->flags);
> +}
> +return ret;
> +}
> +
>  int ff_http_averror(int status_code, int default_averror)
>  {
>  switch (status_code) {
> diff --git a/libavformat/http.h b/libavformat/http.h
> index 7d02713..0eaeb48 100644
> --- a/libavformat/http.h
> +++ b/libavformat/http.h
> @@ -47,6 +47,15 @@ void ff_http_init_auth_state(URLContext *dest, const 
> URLContext *src);
>   */
>  int ff_http_do_new_request(URLContext *h, const char *uri);
>  
> +/**
> + * Send a end of chunk signal(sends a string "0\r\n\r\n"), if applicable.
> + *
> + * @param h pointer to the resource
> + * @return a negative value if an error condition occurred, 0
> + * otherwise
> + */
> +int ff_http_signal_end_of_chunk(URLContext *h);
> +
>  int ff_http_averror(int status_code, int default_averror);
>  
>  #endif /* AVFORMAT_HTTP_H */

I'd really prefer if this HTTP stuff would be added in a much cleaner
way, such as making it part of the AVIO API, or at least the
URLContext API. (Why are there 2 APIs anyway...)

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


[FFmpeg-devel] [PATCH 1/2] avformat/http: Added a library-internal API for signalling end of chunk

2017-12-21 Thread Karthick J
From: Karthick Jeyapal 

Right now there is no explicit way to signal end of chunk, when http_multiple 
is set.
ff_http_do_new_request() function implicitly signals end of chunk. But that 
could be too late for certain applications.
Hence added a new function ff_http_signal_end_of_chunk() which could be used 
internally within libavformat.
---
 libavformat/http.c | 17 ++---
 libavformat/http.h |  9 +
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index cf86adc..d8224de 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -307,9 +307,11 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 AVDictionary *options = NULL;
 int ret;
 
-ret = http_shutdown(h, h->flags);
-if (ret < 0)
-return ret;
+if (!s->end_chunked_post) {
+ret = http_shutdown(h, h->flags);
+if (ret < 0)
+return ret;
+}
 
 s->end_chunked_post = 0;
 s->chunkend  = 0;
@@ -325,6 +327,15 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 return ret;
 }
 
+int ff_http_signal_end_of_chunk(URLContext *h) {
+HTTPContext *s = h->priv_data;
+int ret = 0;
+if (!s->end_chunked_post) {
+ret = http_shutdown(h, h->flags);
+}
+return ret;
+}
+
 int ff_http_averror(int status_code, int default_averror)
 {
 switch (status_code) {
diff --git a/libavformat/http.h b/libavformat/http.h
index 7d02713..0eaeb48 100644
--- a/libavformat/http.h
+++ b/libavformat/http.h
@@ -47,6 +47,15 @@ void ff_http_init_auth_state(URLContext *dest, const 
URLContext *src);
  */
 int ff_http_do_new_request(URLContext *h, const char *uri);
 
+/**
+ * Send a end of chunk signal(sends a string "0\r\n\r\n"), if applicable.
+ *
+ * @param h pointer to the resource
+ * @return a negative value if an error condition occurred, 0
+ * otherwise
+ */
+int ff_http_signal_end_of_chunk(URLContext *h);
+
 int ff_http_averror(int status_code, int default_averror);
 
 #endif /* AVFORMAT_HTTP_H */
-- 
1.9.1

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


[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: Signal http end of chunk explicitly during hlsenc_io_close()

2017-12-21 Thread Karthick J
From: Karthick Jeyapal 

Currently http end of chunk is called implicitly in hlsenc_io_open().
This mean playlists http writes would have to wait upto a segment duration to 
signal end of chunk causing delays.
This patch will fix that problem and improve performance.
---
 libavformat/hlsenc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 0095ca4..65182c5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -268,8 +268,13 @@ static void hlsenc_io_close(AVFormatContext *s, 
AVIOContext **pb, char *filename
 
 if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
 ff_format_io_close(s, pb);
+#if CONFIG_HTTP_PROTOCOL
 } else {
+URLContext *http_url_context = ffio_geturlcontext(*pb);
+av_assert0(http_url_context);
 avio_flush(*pb);
+ff_http_signal_end_of_chunk(http_url_context);
+#endif
 }
 }
 
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Jeyapal, Karthick

On 12/22/17, 5:08 AM, "Steven Liu"  wrote:
>
>2017-12-21 18:09 GMT+08:00 Karthick J :
>> From: Karthick Jeyapal 
>>
>> The HLS specification states the following about EXT-X-TARGETDURATION
>> […]
>
>LGTM, I have checked from HLS Team, Set the EXT-X-TARGETDURATION by
>print(EXTINF).
Oh, I am glad we are finally in agreement! 
I appreciate you for following it up with Apple’s HLS author for the 
confirmation.

Thanks and regards,
Karthick
>
>
>Thanks


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


[FFmpeg-devel] [PATCH 2/2] avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant)

2017-12-21 Thread Michael Niedermayer
Fixes: runtime error: left shift of negative value -180
Fixes: 4626/clusterfuzz-testcase-minimized-5647837887987712

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/hevcdsp_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 4017af8eb0..903aa3fe95 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -121,7 +121,7 @@ static void FUNC(dequant)(int16_t *coeffs, int16_t 
log2_size)
 } else {
 for (y = 0; y < size; y++) {
 for (x = 0; x < size; x++) {
-*coeffs = *coeffs << -shift;
+*coeffs = *(uint16_t*)coeffs << -shift;
 coeffs++;
 }
 }
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 1/2] avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0()

2017-12-21 Thread Michael Niedermayer
Fixes: runtime error: signed integer overflow: 2147483646 + 33554433 cannot be 
represented in type 'int'
Fixes: 4563/clusterfuzz-testcase-minimized-5438979567517696

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dirac_dwt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index 50c8b1e394..f9828d95a4 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -99,10 +99,10 @@ void ff_spatial_idwt_slice2(DWTContext *d, int y);
 (b1 + ((int)(b0 + (unsigned)(b2) + 1) >> 1))
 
 #define COMPOSE_DD97iH0(b0, b1, b2, b3, b4)\
-(b2 + ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 8) >> 4))
+(int)(((unsigned)(b2) + ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 8) >> 4)))
 
 #define COMPOSE_DD137iL0(b0, b1, b2, b3, b4)\
-(b2 - ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 16) >> 5))
+(int)(((unsigned)(b2) - ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 16) >> 5)))
 
 #define COMPOSE_HAARiL0(b0, b1)\
 (b0 - ((b1 + 1) >> 1))
-- 
2.15.1

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


Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread wm4
On Thu, 21 Dec 2017 22:57:42 -0300
James Almer  wrote:

> On 12/21/2017 10:49 PM, wm4 wrote:
> > On Thu, 21 Dec 2017 22:05:11 -0300
> > James Almer  wrote:
> >   
> >> On 12/21/2017 9:40 PM, wm4 wrote:  
> >>> On Thu, 21 Dec 2017 21:31:37 -0300
> >>> James Almer  wrote:
> >>> 
>  On 12/21/2017 7:22 PM, wm4 wrote:
> > This removes the XP compatibility code, and switches entirely to SWR
> > locks, which are available starting at Windows Vista.
> >
> > This removes CRITICAL_SECTION use, which allows us to add
> > PTHREAD_MUTEX_INITIALIZER, which will be useful later.
> >
> > Windows XP is hereby not a supported build target anymore. It was
> > decided in a project vote that this is OK. (Technically, it could still
> > be built for Windows XP using an external pthread lib as of this
> > commit.)
> >
> > Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
> > we raise the Windows API level globally when enabling w32threads, we
> > need to move it before configure checks for struct pollfd to avoid that
> > the compatibility ifdef mess redefines it.
> > ---
> > Not sure if there's a better way to do the things configure does.
> > ---
> >  Changelog  |   2 +
> >  compat/w32pthreads.h   | 269 
> > ++---
> >  configure  |  93 
> >  libavcodec/pthread_frame.c |   4 -
> >  libavcodec/pthread_slice.c |   4 -
> >  libavfilter/pthread.c  |   4 -
> >  libavutil/slicethread.c|   4 -
> >  7 files changed, 60 insertions(+), 320 deletions(-)  
> 
>  [...]
> 
> > --- a/configure
> > +++ b/configure
> > @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
> >  "
> >  
> >  TYPES_LIST="
> > -CONDITION_VARIABLE_Ptr
> >  kCMVideoCodecType_HEVC
> >  socklen_t
> >  struct_addrinfo
> > @@ -5163,8 +5162,8 @@ probe_libc(){
> >  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
> >  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 
> > 0x0700" &&
> >  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
> > -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> > _WIN32_WINNT < 0x0502" &&
> > -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
> > +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> > _WIN32_WINNT < 0x0600" &&
> > +add_${pfx}cppflags -D_WIN32_WINNT=0x0600  
> 
>  This same check should now also be added to the mingw-w64 part of this
>  function.
>  Until now, this was done this way because mingw32 defaults to Win98,
>  whereas mingw-w64 to WinXP. Now we need Vista in both.
> >>>
> >>> Oh, I didn't even notice that was mingw32 only.
> >>> 
>  It would be a good idea for that matter to make sure all the required
>  Vista API is actually supported by Mingw32 3.15, or if we need to bump
>  that (or just drop mingw32 support, which wouldn't really hurt).
> >>>
> >>> The code already checks for CONDITION_VARIABLE. Any other things I
> >>> should check for? Maybe a representative function? (I don't think I'm
> >>> going to add checks for _all_ the symbols.)
> >>
> >> Didn't realize that was checked, so no, should be good then.
> >>  
> >>> 
> >  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
> > @@ -5184,14 +5183,14 @@ probe_libc(){
> >  # 0x601 by default unless something else is set by the user.
> >  # This can easily lead to us detecting functions only present
> >  # in such new versions and producing binaries requiring 
> > windows 7.0.
> > -# Therefore explicitly set the default to XP unless the user 
> > has
> > +# Therefore explicitly set the default to Vista unless the 
> > user has
> >  # set something else on the command line.
> >  # Don't do this if WINAPI_FAMILY is set and is set to a 
> > non-desktop
> >  # family. For these cases, configure is free to use any 
> > functions
> >  # found in the SDK headers by default. (Alternatively, we 
> > could force
> >  # _WIN32_WINNT to 0x0602 in that case.)
> >  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
> > -{ check_${pfx}cpp < > -D_WIN32_WINNT=0x0502; }
> > +{ check_${pfx}cpp < > -D_WIN32_WINNT=0x0600; }
> >  #ifdef WINAPI_FAMILY
> >  #include 
> >  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> > @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 

Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread James Almer
On 12/21/2017 10:49 PM, wm4 wrote:
> On Thu, 21 Dec 2017 22:05:11 -0300
> James Almer  wrote:
> 
>> On 12/21/2017 9:40 PM, wm4 wrote:
>>> On Thu, 21 Dec 2017 21:31:37 -0300
>>> James Almer  wrote:
>>>   
 On 12/21/2017 7:22 PM, wm4 wrote:  
> This removes the XP compatibility code, and switches entirely to SWR
> locks, which are available starting at Windows Vista.
>
> This removes CRITICAL_SECTION use, which allows us to add
> PTHREAD_MUTEX_INITIALIZER, which will be useful later.
>
> Windows XP is hereby not a supported build target anymore. It was
> decided in a project vote that this is OK. (Technically, it could still
> be built for Windows XP using an external pthread lib as of this
> commit.)
>
> Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
> we raise the Windows API level globally when enabling w32threads, we
> need to move it before configure checks for struct pollfd to avoid that
> the compatibility ifdef mess redefines it.
> ---
> Not sure if there's a better way to do the things configure does.
> ---
>  Changelog  |   2 +
>  compat/w32pthreads.h   | 269 
> ++---
>  configure  |  93 
>  libavcodec/pthread_frame.c |   4 -
>  libavcodec/pthread_slice.c |   4 -
>  libavfilter/pthread.c  |   4 -
>  libavutil/slicethread.c|   4 -
>  7 files changed, 60 insertions(+), 320 deletions(-)

 [...]
  
> --- a/configure
> +++ b/configure
> @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
>  "
>  
>  TYPES_LIST="
> -CONDITION_VARIABLE_Ptr
>  kCMVideoCodecType_HEVC
>  socklen_t
>  struct_addrinfo
> @@ -5163,8 +5162,8 @@ probe_libc(){
>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 0x0700" 
> &&
>  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
> -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> _WIN32_WINNT < 0x0502" &&
> -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
> +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> _WIN32_WINNT < 0x0600" &&
> +add_${pfx}cppflags -D_WIN32_WINNT=0x0600

 This same check should now also be added to the mingw-w64 part of this
 function.
 Until now, this was done this way because mingw32 defaults to Win98,
 whereas mingw-w64 to WinXP. Now we need Vista in both.  
>>>
>>> Oh, I didn't even notice that was mingw32 only.
>>>   
 It would be a good idea for that matter to make sure all the required
 Vista API is actually supported by Mingw32 3.15, or if we need to bump
 that (or just drop mingw32 support, which wouldn't really hurt).  
>>>
>>> The code already checks for CONDITION_VARIABLE. Any other things I
>>> should check for? Maybe a representative function? (I don't think I'm
>>> going to add checks for _all_ the symbols.)  
>>
>> Didn't realize that was checked, so no, should be good then.
>>
>>>   
>  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
> @@ -5184,14 +5183,14 @@ probe_libc(){
>  # 0x601 by default unless something else is set by the user.
>  # This can easily lead to us detecting functions only present
>  # in such new versions and producing binaries requiring windows 
> 7.0.
> -# Therefore explicitly set the default to XP unless the user has
> +# Therefore explicitly set the default to Vista unless the user 
> has
>  # set something else on the command line.
>  # Don't do this if WINAPI_FAMILY is set and is set to a 
> non-desktop
>  # family. For these cases, configure is free to use any functions
>  # found in the SDK headers by default. (Alternatively, we could 
> force
>  # _WIN32_WINNT to 0x0602 in that case.)
>  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
> -{ check_${pfx}cpp < -D_WIN32_WINNT=0x0502; }
> +{ check_${pfx}cpp < -D_WIN32_WINNT=0x0600; }
>  #ifdef WINAPI_FAMILY
>  #include 
>  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 
> vdupq_n_s16(0)" && enable intrinsics_
>  check_ldflags -Wl,--as-needed
>  check_ldflags -Wl,-z,noexecstack
>  
> +if ! disabled w32threads && ! enabled pthreads; then
> +check_func_headers "windows.h process.h" _beginthreadex &&
> +check_type "windows.h" CONDITION_VARIABL

Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread wm4
On Thu, 21 Dec 2017 22:05:11 -0300
James Almer  wrote:

> On 12/21/2017 9:40 PM, wm4 wrote:
> > On Thu, 21 Dec 2017 21:31:37 -0300
> > James Almer  wrote:
> >   
> >> On 12/21/2017 7:22 PM, wm4 wrote:  
> >>> This removes the XP compatibility code, and switches entirely to SWR
> >>> locks, which are available starting at Windows Vista.
> >>>
> >>> This removes CRITICAL_SECTION use, which allows us to add
> >>> PTHREAD_MUTEX_INITIALIZER, which will be useful later.
> >>>
> >>> Windows XP is hereby not a supported build target anymore. It was
> >>> decided in a project vote that this is OK. (Technically, it could still
> >>> be built for Windows XP using an external pthread lib as of this
> >>> commit.)
> >>>
> >>> Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
> >>> we raise the Windows API level globally when enabling w32threads, we
> >>> need to move it before configure checks for struct pollfd to avoid that
> >>> the compatibility ifdef mess redefines it.
> >>> ---
> >>> Not sure if there's a better way to do the things configure does.
> >>> ---
> >>>  Changelog  |   2 +
> >>>  compat/w32pthreads.h   | 269 
> >>> ++---
> >>>  configure  |  93 
> >>>  libavcodec/pthread_frame.c |   4 -
> >>>  libavcodec/pthread_slice.c |   4 -
> >>>  libavfilter/pthread.c  |   4 -
> >>>  libavutil/slicethread.c|   4 -
> >>>  7 files changed, 60 insertions(+), 320 deletions(-)
> >>
> >> [...]
> >>  
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
> >>>  "
> >>>  
> >>>  TYPES_LIST="
> >>> -CONDITION_VARIABLE_Ptr
> >>>  kCMVideoCodecType_HEVC
> >>>  socklen_t
> >>>  struct_addrinfo
> >>> @@ -5163,8 +5162,8 @@ probe_libc(){
> >>>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
> >>>  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 0x0700" 
> >>> &&
> >>>  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
> >>> -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> >>> _WIN32_WINNT < 0x0502" &&
> >>> -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
> >>> +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> >>> _WIN32_WINNT < 0x0600" &&
> >>> +add_${pfx}cppflags -D_WIN32_WINNT=0x0600
> >>
> >> This same check should now also be added to the mingw-w64 part of this
> >> function.
> >> Until now, this was done this way because mingw32 defaults to Win98,
> >> whereas mingw-w64 to WinXP. Now we need Vista in both.  
> > 
> > Oh, I didn't even notice that was mingw32 only.
> >   
> >> It would be a good idea for that matter to make sure all the required
> >> Vista API is actually supported by Mingw32 3.15, or if we need to bump
> >> that (or just drop mingw32 support, which wouldn't really hurt).  
> > 
> > The code already checks for CONDITION_VARIABLE. Any other things I
> > should check for? Maybe a representative function? (I don't think I'm
> > going to add checks for _all_ the symbols.)  
> 
> Didn't realize that was checked, so no, should be good then.
> 
> >   
> >>>  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
> >>> @@ -5184,14 +5183,14 @@ probe_libc(){
> >>>  # 0x601 by default unless something else is set by the user.
> >>>  # This can easily lead to us detecting functions only present
> >>>  # in such new versions and producing binaries requiring windows 
> >>> 7.0.
> >>> -# Therefore explicitly set the default to XP unless the user has
> >>> +# Therefore explicitly set the default to Vista unless the user 
> >>> has
> >>>  # set something else on the command line.
> >>>  # Don't do this if WINAPI_FAMILY is set and is set to a 
> >>> non-desktop
> >>>  # family. For these cases, configure is free to use any functions
> >>>  # found in the SDK headers by default. (Alternatively, we could 
> >>> force
> >>>  # _WIN32_WINNT to 0x0602 in that case.)
> >>>  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
> >>> -{ check_${pfx}cpp < >>> -D_WIN32_WINNT=0x0502; }
> >>> +{ check_${pfx}cpp < >>> -D_WIN32_WINNT=0x0600; }
> >>>  #ifdef WINAPI_FAMILY
> >>>  #include 
> >>>  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> >>> @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 
> >>> vdupq_n_s16(0)" && enable intrinsics_
> >>>  check_ldflags -Wl,--as-needed
> >>>  check_ldflags -Wl,-z,noexecstack
> >>>  
> >>> +if ! disabled w32threads && ! enabled pthreads; then
> >>> +check_func_headers "windows.h process.h" _beginthreadex &&
> >>> +check_type "windows.h" CONDITION_VARIABLE &&
> >>> +enable w32threads || 

Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread James Almer
On 12/21/2017 9:40 PM, wm4 wrote:
> On Thu, 21 Dec 2017 21:31:37 -0300
> James Almer  wrote:
> 
>> On 12/21/2017 7:22 PM, wm4 wrote:
>>> This removes the XP compatibility code, and switches entirely to SWR
>>> locks, which are available starting at Windows Vista.
>>>
>>> This removes CRITICAL_SECTION use, which allows us to add
>>> PTHREAD_MUTEX_INITIALIZER, which will be useful later.
>>>
>>> Windows XP is hereby not a supported build target anymore. It was
>>> decided in a project vote that this is OK. (Technically, it could still
>>> be built for Windows XP using an external pthread lib as of this
>>> commit.)
>>>
>>> Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
>>> we raise the Windows API level globally when enabling w32threads, we
>>> need to move it before configure checks for struct pollfd to avoid that
>>> the compatibility ifdef mess redefines it.
>>> ---
>>> Not sure if there's a better way to do the things configure does.
>>> ---
>>>  Changelog  |   2 +
>>>  compat/w32pthreads.h   | 269 
>>> ++---
>>>  configure  |  93 
>>>  libavcodec/pthread_frame.c |   4 -
>>>  libavcodec/pthread_slice.c |   4 -
>>>  libavfilter/pthread.c  |   4 -
>>>  libavutil/slicethread.c|   4 -
>>>  7 files changed, 60 insertions(+), 320 deletions(-)  
>>
>> [...]
>>
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
>>>  "
>>>  
>>>  TYPES_LIST="
>>> -CONDITION_VARIABLE_Ptr
>>>  kCMVideoCodecType_HEVC
>>>  socklen_t
>>>  struct_addrinfo
>>> @@ -5163,8 +5162,8 @@ probe_libc(){
>>>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>>>  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 0x0700" &&
>>>  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
>>> -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
>>> _WIN32_WINNT < 0x0502" &&
>>> -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
>>> +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
>>> _WIN32_WINNT < 0x0600" &&
>>> +add_${pfx}cppflags -D_WIN32_WINNT=0x0600  
>>
>> This same check should now also be added to the mingw-w64 part of this
>> function.
>> Until now, this was done this way because mingw32 defaults to Win98,
>> whereas mingw-w64 to WinXP. Now we need Vista in both.
> 
> Oh, I didn't even notice that was mingw32 only.
> 
>> It would be a good idea for that matter to make sure all the required
>> Vista API is actually supported by Mingw32 3.15, or if we need to bump
>> that (or just drop mingw32 support, which wouldn't really hurt).
> 
> The code already checks for CONDITION_VARIABLE. Any other things I
> should check for? Maybe a representative function? (I don't think I'm
> going to add checks for _all_ the symbols.)

Didn't realize that was checked, so no, should be good then.

> 
>>>  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
>>> @@ -5184,14 +5183,14 @@ probe_libc(){
>>>  # 0x601 by default unless something else is set by the user.
>>>  # This can easily lead to us detecting functions only present
>>>  # in such new versions and producing binaries requiring windows 
>>> 7.0.
>>> -# Therefore explicitly set the default to XP unless the user has
>>> +# Therefore explicitly set the default to Vista unless the user has
>>>  # set something else on the command line.
>>>  # Don't do this if WINAPI_FAMILY is set and is set to a non-desktop
>>>  # family. For these cases, configure is free to use any functions
>>>  # found in the SDK headers by default. (Alternatively, we could 
>>> force
>>>  # _WIN32_WINNT to 0x0602 in that case.)
>>>  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
>>> -{ check_${pfx}cpp <>> -D_WIN32_WINNT=0x0502; }
>>> +{ check_${pfx}cpp <>> -D_WIN32_WINNT=0x0600; }
>>>  #ifdef WINAPI_FAMILY
>>>  #include 
>>>  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
>>> @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 
>>> vdupq_n_s16(0)" && enable intrinsics_
>>>  check_ldflags -Wl,--as-needed
>>>  check_ldflags -Wl,-z,noexecstack
>>>  
>>> +if ! disabled w32threads && ! enabled pthreads; then
>>> +check_func_headers "windows.h process.h" _beginthreadex &&
>>> +check_type "windows.h" CONDITION_VARIABLE &&
>>> +enable w32threads || disable w32threads
>>> +if ! enabled w32threads && enabled winrt; then
>>> +check_func_headers "windows.h" CreateThread &&
>>> +enable w32threads || disable w32threads
>>> +fi
>>> +fi
>>> +
>>> +if enabled w32threads; then
>>> +if check_cpp_condition windows.h "!defined(_WIN32_WIN

Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread wm4
On Thu, 21 Dec 2017 21:31:37 -0300
James Almer  wrote:

> On 12/21/2017 7:22 PM, wm4 wrote:
> > This removes the XP compatibility code, and switches entirely to SWR
> > locks, which are available starting at Windows Vista.
> > 
> > This removes CRITICAL_SECTION use, which allows us to add
> > PTHREAD_MUTEX_INITIALIZER, which will be useful later.
> > 
> > Windows XP is hereby not a supported build target anymore. It was
> > decided in a project vote that this is OK. (Technically, it could still
> > be built for Windows XP using an external pthread lib as of this
> > commit.)
> > 
> > Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
> > we raise the Windows API level globally when enabling w32threads, we
> > need to move it before configure checks for struct pollfd to avoid that
> > the compatibility ifdef mess redefines it.
> > ---
> > Not sure if there's a better way to do the things configure does.
> > ---
> >  Changelog  |   2 +
> >  compat/w32pthreads.h   | 269 
> > ++---
> >  configure  |  93 
> >  libavcodec/pthread_frame.c |   4 -
> >  libavcodec/pthread_slice.c |   4 -
> >  libavfilter/pthread.c  |   4 -
> >  libavutil/slicethread.c|   4 -
> >  7 files changed, 60 insertions(+), 320 deletions(-)  
> 
> [...]
> 
> > --- a/configure
> > +++ b/configure
> > @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
> >  "
> >  
> >  TYPES_LIST="
> > -CONDITION_VARIABLE_Ptr
> >  kCMVideoCodecType_HEVC
> >  socklen_t
> >  struct_addrinfo
> > @@ -5163,8 +5162,8 @@ probe_libc(){
> >  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
> >  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 0x0700" &&
> >  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
> > -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> > _WIN32_WINNT < 0x0502" &&
> > -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
> > +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> > _WIN32_WINNT < 0x0600" &&
> > +add_${pfx}cppflags -D_WIN32_WINNT=0x0600  
> 
> This same check should now also be added to the mingw-w64 part of this
> function.
> Until now, this was done this way because mingw32 defaults to Win98,
> whereas mingw-w64 to WinXP. Now we need Vista in both.

Oh, I didn't even notice that was mingw32 only.

> It would be a good idea for that matter to make sure all the required
> Vista API is actually supported by Mingw32 3.15, or if we need to bump
> that (or just drop mingw32 support, which wouldn't really hurt).

The code already checks for CONDITION_VARIABLE. Any other things I
should check for? Maybe a representative function? (I don't think I'm
going to add checks for _all_ the symbols.)

> >  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
> > @@ -5184,14 +5183,14 @@ probe_libc(){
> >  # 0x601 by default unless something else is set by the user.
> >  # This can easily lead to us detecting functions only present
> >  # in such new versions and producing binaries requiring windows 
> > 7.0.
> > -# Therefore explicitly set the default to XP unless the user has
> > +# Therefore explicitly set the default to Vista unless the user has
> >  # set something else on the command line.
> >  # Don't do this if WINAPI_FAMILY is set and is set to a non-desktop
> >  # family. For these cases, configure is free to use any functions
> >  # found in the SDK headers by default. (Alternatively, we could 
> > force
> >  # _WIN32_WINNT to 0x0602 in that case.)
> >  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
> > -{ check_${pfx}cpp < > -D_WIN32_WINNT=0x0502; }
> > +{ check_${pfx}cpp < > -D_WIN32_WINNT=0x0600; }
> >  #ifdef WINAPI_FAMILY
> >  #include 
> >  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> > @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 
> > vdupq_n_s16(0)" && enable intrinsics_
> >  check_ldflags -Wl,--as-needed
> >  check_ldflags -Wl,-z,noexecstack
> >  
> > +if ! disabled w32threads && ! enabled pthreads; then
> > +check_func_headers "windows.h process.h" _beginthreadex &&
> > +check_type "windows.h" CONDITION_VARIABLE &&
> > +enable w32threads || disable w32threads
> > +if ! enabled w32threads && enabled winrt; then
> > +check_func_headers "windows.h" CreateThread &&
> > +enable w32threads || disable w32threads
> > +fi
> > +fi
> > +
> > +if enabled w32threads; then
> > +if check_cpp_condition windows.h "!defined(_WIN32_WINNT) || 
> > _WIN32_WINNT < 0x0600" ; then
> > +add_cppflags -D_WIN32_WINNT=0x0600  
> 
> Win Vista should be forced r

Re: [FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread James Almer
On 12/21/2017 7:22 PM, wm4 wrote:
> This removes the XP compatibility code, and switches entirely to SWR
> locks, which are available starting at Windows Vista.
> 
> This removes CRITICAL_SECTION use, which allows us to add
> PTHREAD_MUTEX_INITIALIZER, which will be useful later.
> 
> Windows XP is hereby not a supported build target anymore. It was
> decided in a project vote that this is OK. (Technically, it could still
> be built for Windows XP using an external pthread lib as of this
> commit.)
> 
> Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
> we raise the Windows API level globally when enabling w32threads, we
> need to move it before configure checks for struct pollfd to avoid that
> the compatibility ifdef mess redefines it.
> ---
> Not sure if there's a better way to do the things configure does.
> ---
>  Changelog  |   2 +
>  compat/w32pthreads.h   | 269 
> ++---
>  configure  |  93 
>  libavcodec/pthread_frame.c |   4 -
>  libavcodec/pthread_slice.c |   4 -
>  libavfilter/pthread.c  |   4 -
>  libavutil/slicethread.c|   4 -
>  7 files changed, 60 insertions(+), 320 deletions(-)

[...]

> --- a/configure
> +++ b/configure
> @@ -2089,7 +2089,6 @@ TOOLCHAIN_FEATURES="
>  "
>  
>  TYPES_LIST="
> -CONDITION_VARIABLE_Ptr
>  kCMVideoCodecType_HEVC
>  socklen_t
>  struct_addrinfo
> @@ -5163,8 +5162,8 @@ probe_libc(){
>  add_${pfx}cppflags -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1
>  check_${pfx}cpp_condition _mingw.h "__MSVCRT_VERSION__ < 0x0700" &&
>  add_${pfx}cppflags -D__MSVCRT_VERSION__=0x0700
> -check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> _WIN32_WINNT < 0x0502" &&
> -add_${pfx}cppflags -D_WIN32_WINNT=0x0502
> +check_${pfx}cpp_condition windows.h "defined(_WIN32_WINNT) && 
> _WIN32_WINNT < 0x0600" &&
> +add_${pfx}cppflags -D_WIN32_WINNT=0x0600

This same check should now also be added to the mingw-w64 part of this
function.
Until now, this was done this way because mingw32 defaults to Win98,
whereas mingw-w64 to WinXP. Now we need Vista in both.

It would be a good idea for that matter to make sure all the required
Vista API is actually supported by Mingw32 3.15, or if we need to bump
that (or just drop mingw32 support, which wouldn't really hurt).

>  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
> @@ -5184,14 +5183,14 @@ probe_libc(){
>  # 0x601 by default unless something else is set by the user.
>  # This can easily lead to us detecting functions only present
>  # in such new versions and producing binaries requiring windows 7.0.
> -# Therefore explicitly set the default to XP unless the user has
> +# Therefore explicitly set the default to Vista unless the user has
>  # set something else on the command line.
>  # Don't do this if WINAPI_FAMILY is set and is set to a non-desktop
>  # family. For these cases, configure is free to use any functions
>  # found in the SDK headers by default. (Alternatively, we could force
>  # _WIN32_WINNT to 0x0602 in that case.)
>  check_${pfx}cpp_condition stdlib.h "defined(_WIN32_WINNT)" ||
> -{ check_${pfx}cpp < -D_WIN32_WINNT=0x0502; }
> +{ check_${pfx}cpp < -D_WIN32_WINNT=0x0600; }
>  #ifdef WINAPI_FAMILY
>  #include 
>  #if !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> @@ -5564,6 +5563,51 @@ check_code cc arm_neon.h "int16x8_t test = 
> vdupq_n_s16(0)" && enable intrinsics_
>  check_ldflags -Wl,--as-needed
>  check_ldflags -Wl,-z,noexecstack
>  
> +if ! disabled w32threads && ! enabled pthreads; then
> +check_func_headers "windows.h process.h" _beginthreadex &&
> +check_type "windows.h" CONDITION_VARIABLE &&
> +enable w32threads || disable w32threads
> +if ! enabled w32threads && enabled winrt; then
> +check_func_headers "windows.h" CreateThread &&
> +enable w32threads || disable w32threads
> +fi
> +fi
> +
> +if enabled w32threads; then
> +if check_cpp_condition windows.h "!defined(_WIN32_WINNT) || _WIN32_WINNT 
> < 0x0600" ; then
> +add_cppflags -D_WIN32_WINNT=0x0600

Win Vista should be forced regardless of w32threads being enabled or
not, so this should be done in probe_libc().

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


Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Steven Liu
2017-12-22 7:37 GMT+08:00 Steven Liu :
> 2017-12-21 18:09 GMT+08:00 Karthick J :
>> From: Karthick Jeyapal 
>>
>> The HLS specification states the following about EXT-X-TARGETDURATION
>>
>> 4.3.3.1.  EXT-X-TARGETDURATION
>>
>>The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>>duration.  The EXTINF duration of each Media Segment in the Playlist
>>file, when rounded to the nearest integer, MUST be less than or equal
>>to the target duration; longer segments can trigger playback stalls
>>or other errors.  It applies to the entire Playlist file.  Its format
>>is:
>>
>>#EXT-X-TARGETDURATION:
>>
>>where s is a decimal-integer indicating the target duration in
>>seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>>
>> Currently the dashenc rounds the duration to the next integer,
>> rather than rounding the duration to the nearest integer.
>> ---
>>  libavformat/dashenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 5687530..5368a23 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
>> AVIOContext *out, DASHContext
>>  Segment *seg = os->segments[i];
>>  double duration = (double) seg->duration / timescale;
>>  if (target_duration <= duration)
>> -target_duration = hls_get_int_from_double(duration);
>> +target_duration = lrint(duration);
>>  }
>>
>>  ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
>> --
>> 1.9.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
> LGTM, I have checked from HLS Team, Set the EXT-X-TARGETDURATION by
> print(EXTINF).

And will apply the old version modify hlsenc patch,


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


Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Steven Liu
2017-12-21 18:09 GMT+08:00 Karthick J :
> From: Karthick Jeyapal 
>
> The HLS specification states the following about EXT-X-TARGETDURATION
>
> 4.3.3.1.  EXT-X-TARGETDURATION
>
>The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>duration.  The EXTINF duration of each Media Segment in the Playlist
>file, when rounded to the nearest integer, MUST be less than or equal
>to the target duration; longer segments can trigger playback stalls
>or other errors.  It applies to the entire Playlist file.  Its format
>is:
>
>#EXT-X-TARGETDURATION:
>
>where s is a decimal-integer indicating the target duration in
>seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>
> Currently the dashenc rounds the duration to the next integer,
> rather than rounding the duration to the nearest integer.
> ---
>  libavformat/dashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5687530..5368a23 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
> AVIOContext *out, DASHContext
>  Segment *seg = os->segments[i];
>  double duration = (double) seg->duration / timescale;
>  if (target_duration <= duration)
> -target_duration = hls_get_int_from_double(duration);
> +target_duration = lrint(duration);
>  }
>
>  ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
> --
> 1.9.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM, I have checked from HLS Team, Set the EXT-X-TARGETDURATION by
print(EXTINF).


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


[FFmpeg-devel] [PATCH 4/5] lavc, lavf: move avformat static mutex from avcodec to avformat

2017-12-21 Thread wm4
It's completely absurd that libavcodec would care about libavformat
locking, but it was there because the lock manager was in libavcodec.

This is more stright forward. Changes ABI, but we don't require ABI
compatibility currently.
---
openssl, avisynth, chromaprint build untested
---
 libavcodec/internal.h |  3 ---
 libavcodec/utils.c| 11 ---
 libavformat/avisynth.c| 10 +-
 libavformat/chromaprint.c |  9 +
 libavformat/internal.h|  4 
 libavformat/tls_gnutls.c  |  8 
 libavformat/tls_openssl.c | 10 +-
 libavformat/utils.c   | 13 +
 8 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 30cb9a0de1..bf58f36ad3 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -245,9 +245,6 @@ extern volatile int ff_avcodec_locked;
 int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec);
 int ff_unlock_avcodec(const AVCodec *codec);
 
-int avpriv_lock_avformat(void);
-int avpriv_unlock_avformat(void);
-
 /**
  * Maximum size in bytes of extradata.
  * This value was chosen such that every bit of the buffer is
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c7f8cdf08f..718063f1a1 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -70,7 +70,6 @@ const char av_codec_ffversion[] = "FFmpeg version " 
FFMPEG_VERSION;
 volatile int ff_avcodec_locked;
 static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
 static pthread_mutex_t codec_mutex = PTHREAD_MUTEX_INITIALIZER;
-static pthread_mutex_t avformat_mutex = PTHREAD_MUTEX_INITIALIZER;
 
 void av_fast_padded_malloc(void *ptr, unsigned int *size, size_t min_size)
 {
@@ -1904,16 +1903,6 @@ int ff_unlock_avcodec(const AVCodec *codec)
 return 0;
 }
 
-int avpriv_lock_avformat(void)
-{
-return pthread_mutex_lock(&avformat_mutex) ? -1 : 0;
-}
-
-int avpriv_unlock_avformat(void)
-{
-return pthread_mutex_unlock(&avformat_mutex) ? -1 : 0;
-}
-
 unsigned int avpriv_toupper4(unsigned int x)
 {
 return av_toupper(x & 0xFF) +
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 56700288f7..250a489321 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -774,15 +774,15 @@ static av_cold int avisynth_read_header(AVFormatContext 
*s)
 int ret;
 
 // Calling library must implement a lock for thread-safe opens.
-if (ret = avpriv_lock_avformat())
+if (ret = ff_lock_avformat())
 return ret;
 
 if (ret = avisynth_open_file(s)) {
-avpriv_unlock_avformat();
+ff_unlock_avformat();
 return ret;
 }
 
-avpriv_unlock_avformat();
+ff_unlock_avformat();
 return 0;
 }
 
@@ -818,11 +818,11 @@ static int avisynth_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 
 static av_cold int avisynth_read_close(AVFormatContext *s)
 {
-if (avpriv_lock_avformat())
+if (ff_lock_avformat())
 return AVERROR_UNKNOWN;
 
 avisynth_context_destroy(s->priv_data);
-avpriv_unlock_avformat();
+ff_unlock_avformat();
 return 0;
 }
 
diff --git a/libavformat/chromaprint.c b/libavformat/chromaprint.c
index 4da02bef76..f39c09ddb9 100644
--- a/libavformat/chromaprint.c
+++ b/libavformat/chromaprint.c
@@ -20,6 +20,7 @@
  */
 
 #include "avformat.h"
+#include "internal.h"
 #include "libavutil/opt.h"
 #include "libavcodec/internal.h"
 #include 
@@ -49,9 +50,9 @@ typedef struct ChromaprintMuxContext {
 static void cleanup(ChromaprintMuxContext *cpr)
 {
 if (cpr->ctx) {
-avpriv_lock_avformat();
+ff_lock_avformat();
 chromaprint_free(cpr->ctx);
-avpriv_unlock_avformat();
+ff_unlock_avformat();
 }
 }
 
@@ -60,9 +61,9 @@ static int write_header(AVFormatContext *s)
 ChromaprintMuxContext *cpr = s->priv_data;
 AVStream *st;
 
-avpriv_lock_avformat();
+ff_lock_avformat();
 cpr->ctx = chromaprint_new(cpr->algorithm);
-avpriv_unlock_avformat();
+ff_unlock_avformat();
 
 if (!cpr->ctx) {
 av_log(s, AV_LOG_ERROR, "Failed to create chromaprint context.\n");
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 36a57214ce..26738f80e2 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -681,4 +681,8 @@ int ff_bprint_to_codecpar_extradata(AVCodecParameters *par, 
struct AVBPrint *buf
 int ff_interleaved_peek(AVFormatContext *s, int stream,
 AVPacket *pkt, int add_offset);
 
+
+int ff_lock_avformat(void);
+int ff_unlock_avformat(void);
+
 #endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 0cef9575ec..e3c43683be 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -55,20 +55,20 @@ typedef struct TLSContext {
 
 void ff_gnutls_init(void)
 {
-avpriv_lock_avformat();
+ff_lock_avformat();
 #if HAVE_THREADS && GNUTLS_VERSION_NUMBER < 0x020b00
 if (gcry_control(GCRYCTL_ANY_INITIALIZATION_P) == 0)
 gcry

[FFmpeg-devel] [PATCH 3/5] ffplay: drop lock manager use

2017-12-21 Thread wm4
Deprecated and useless.
---
 fftools/ffplay.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 10a917194d..9bfa3e6cea 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1284,7 +1284,6 @@ static void do_exit(VideoState *is)
 SDL_DestroyRenderer(renderer);
 if (window)
 SDL_DestroyWindow(window);
-av_lockmgr_register(NULL);
 uninit_opts();
 #if CONFIG_AVFILTER
 av_freep(&vfilters_list);
@@ -3641,27 +3640,6 @@ void show_help_default(const char *opt, const char *arg)
);
 }
 
-static int lockmgr(void **mtx, enum AVLockOp op)
-{
-   switch(op) {
-  case AV_LOCK_CREATE:
-  *mtx = SDL_CreateMutex();
-  if(!*mtx) {
-  av_log(NULL, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", 
SDL_GetError());
-  return 1;
-  }
-  return 0;
-  case AV_LOCK_OBTAIN:
-  return !!SDL_LockMutex(*mtx);
-  case AV_LOCK_RELEASE:
-  return !!SDL_UnlockMutex(*mtx);
-  case AV_LOCK_DESTROY:
-  SDL_DestroyMutex(*mtx);
-  return 0;
-   }
-   return 1;
-}
-
 /* Called from the main */
 int main(int argc, char **argv)
 {
@@ -3723,11 +3701,6 @@ int main(int argc, char **argv)
 SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
 SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
 
-if (av_lockmgr_register(lockmgr)) {
-av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
-do_exit(NULL);
-}
-
 av_init_packet(&flush_pkt);
 flush_pkt.data = (uint8_t *)&flush_pkt;
 
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 2/5] lavc: replace and deprecate the lock manager

2017-12-21 Thread wm4
Use static mutexes instead of requiring a lock manager. The behavior
should be roughly the same before and after this change for API users
which did not set the lock manager at all (except that a minor memory
leak disappears).
---
 doc/APIchanges   |   5 +++
 libavcodec/avcodec.h |   8 +++-
 libavcodec/utils.c   | 107 +--
 libavcodec/version.h |   5 ++-
 4 files changed, 26 insertions(+), 99 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index da444ffb7c..df1391d83a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavc 58.9.100 - avcodec.h
+  Deprecate av_lockmgr_register(). You need to build FFmpeg with threading
+  support enabled to get basic thread-safety (which is the default build
+  configuration).
+
 2017-xx-xx - xxx - lavc 58.8.100 - avcodec.h
   The MediaCodec decoders now support AVCodecContext.hw_device_ctx.
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ce089b7c4a..a9182a9e3d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5930,10 +5930,11 @@ attribute_deprecated
 AVHWAccel *av_hwaccel_next(const AVHWAccel *hwaccel);
 #endif
 
-
+#if FF_API_LOCKMGR
 /**
  * Lock operation used by lockmgr
  */
+attribute_deprecated
 enum AVLockOp {
   AV_LOCK_CREATE,  ///< Create a mutex
   AV_LOCK_OBTAIN,  ///< Lock the mutex
@@ -5963,8 +5964,13 @@ enum AVLockOp {
  *   mechanism (i.e. do not use a single static object to
  *   implement your lock manager). If cb is set to NULL the
  *   lockmgr will be unregistered.
+ *
+ * @deprecated This function does nothing, and always returns 0. Be sure to
+ * build with thread support to get basic thread safety.
  */
+attribute_deprecated
 int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op));
+#endif
 
 /**
  * Get the type of the given codec.
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 873f39f9bd..c7f8cdf08f 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -67,58 +67,10 @@
 #include "libavutil/ffversion.h"
 const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
 
-#if HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS
-static int default_lockmgr_cb(void **arg, enum AVLockOp op)
-{
-void * volatile * mutex = arg;
-int err;
-
-switch (op) {
-case AV_LOCK_CREATE:
-return 0;
-case AV_LOCK_OBTAIN:
-if (!*mutex) {
-pthread_mutex_t *tmp = av_malloc(sizeof(pthread_mutex_t));
-if (!tmp)
-return AVERROR(ENOMEM);
-if ((err = pthread_mutex_init(tmp, NULL))) {
-av_free(tmp);
-return AVERROR(err);
-}
-if (avpriv_atomic_ptr_cas(mutex, NULL, tmp)) {
-pthread_mutex_destroy(tmp);
-av_free(tmp);
-}
-}
-
-if ((err = pthread_mutex_lock(*mutex)))
-return AVERROR(err);
-
-return 0;
-case AV_LOCK_RELEASE:
-if ((err = pthread_mutex_unlock(*mutex)))
-return AVERROR(err);
-
-return 0;
-case AV_LOCK_DESTROY:
-if (*mutex)
-pthread_mutex_destroy(*mutex);
-av_free(*mutex);
-avpriv_atomic_ptr_cas(mutex, *mutex, NULL);
-return 0;
-}
-return 1;
-}
-static int (*lockmgr_cb)(void **mutex, enum AVLockOp op) = default_lockmgr_cb;
-#else
-static int (*lockmgr_cb)(void **mutex, enum AVLockOp op) = NULL;
-#endif
-
-
 volatile int ff_avcodec_locked;
 static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
-static void *codec_mutex;
-static void *avformat_mutex;
+static pthread_mutex_t codec_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t avformat_mutex = PTHREAD_MUTEX_INITIALIZER;
 
 void av_fast_padded_malloc(void *ptr, unsigned int *size, size_t min_size)
 {
@@ -1909,55 +1861,26 @@ void av_register_hwaccel(AVHWAccel *hwaccel)
 }
 #endif
 
+#if FF_API_LOCKMGR
 int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
 {
-if (lockmgr_cb) {
-// There is no good way to rollback a failure to destroy the
-// mutex, so we ignore failures.
-lockmgr_cb(&codec_mutex,AV_LOCK_DESTROY);
-lockmgr_cb(&avformat_mutex, AV_LOCK_DESTROY);
-lockmgr_cb = NULL;
-codec_mutex= NULL;
-avformat_mutex = NULL;
-}
-
-if (cb) {
-void *new_codec_mutex= NULL;
-void *new_avformat_mutex = NULL;
-int err;
-if (err = cb(&new_codec_mutex, AV_LOCK_CREATE)) {
-return err > 0 ? AVERROR_UNKNOWN : err;
-}
-if (err = cb(&new_avformat_mutex, AV_LOCK_CREATE)) {
-// Ignore failures to destroy the newly created mutex.
-cb(&new_codec_mutex, AV_LOCK_DESTROY);
-return err > 0 ? AVERROR_UNKNOWN : err;
-}
-lockmgr_cb = cb;
-co

[FFmpeg-devel] [PATCH 5/5] lavc: remove weird debug code around avcodec init locking

2017-12-21 Thread wm4
This is just a lot of complicated and confusing code that does nothing.
Also, the functions return values were checked only sometimes. Locking
shouldn't fail anyway, so remove the return values. Barely any other
pthread lock calls check the return value (including more important code
that is more likely to fail horribly if locking fails).

It could be argued that it might be helpful in some debugging
situations, or when the user built FFmpeg without thread support against
all good advice.

But there are dummy atomics too, so the atomic check won't help with
ensuring correctness absolutely. You gain very little.

Also, for debugging, you can just raise the ASSERT_LEVEL, and then
libavutil/thread.h will redefine the locking functions to explicitly
check the return values.
---
 libavcodec/internal.h |  4 
 libavcodec/utils.c| 55 +--
 2 files changed, 14 insertions(+), 45 deletions(-)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index bf58f36ad3..1c901a7cbc 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -241,10 +241,6 @@ int ff_init_buffer_info(AVCodecContext *s, AVFrame *frame);
 
 void ff_color_frame(AVFrame *frame, const int color[4]);
 
-extern volatile int ff_avcodec_locked;
-int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec);
-int ff_unlock_avcodec(const AVCodec *codec);
-
 /**
  * Maximum size in bytes of extradata.
  * This value was chosen such that every bit of the buffer is
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 718063f1a1..7432bb78a6 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -67,8 +67,6 @@
 #include "libavutil/ffversion.h"
 const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
 
-volatile int ff_avcodec_locked;
-static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
 static pthread_mutex_t codec_mutex = PTHREAD_MUTEX_INITIALIZER;
 
 void av_fast_padded_malloc(void *ptr, unsigned int *size, size_t min_size)
@@ -550,6 +548,19 @@ static int64_t get_bit_rate(AVCodecContext *ctx)
 return bit_rate;
 }
 
+
+static void ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
+{
+if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) && codec->init)
+pthread_mutex_lock(&codec_mutex);
+}
+
+static void ff_unlock_avcodec(const AVCodec *codec)
+{
+if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) && codec->init)
+pthread_mutex_unlock(&codec_mutex);
+}
+
 int attribute_align_arg ff_codec_open2_recursive(AVCodecContext *avctx, const 
AVCodec *codec, AVDictionary **options)
 {
 int ret = 0;
@@ -589,9 +600,7 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 if (options)
 av_dict_copy(&tmp, *options, 0);
 
-ret = ff_lock_avcodec(avctx, codec);
-if (ret < 0)
-return ret;
+ff_lock_avcodec(avctx, codec);
 
 avctx->internal = av_mallocz(sizeof(AVCodecInternal));
 if (!avctx->internal) {
@@ -1867,42 +1876,6 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
AVLockOp op))
 }
 #endif
 
-int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
-{
-if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
-return 0;
-
-if (pthread_mutex_lock(&codec_mutex))
-return -1;
-
-if (atomic_fetch_add(&entangled_thread_counter, 1)) {
-av_log(log_ctx, AV_LOG_ERROR,
-   "Insufficient thread locking. At least %d threads are "
-   "calling avcodec_open2() at the same time right now.\n",
-   atomic_load(&entangled_thread_counter));
-ff_avcodec_locked = 1;
-ff_unlock_avcodec(codec);
-return AVERROR(EINVAL);
-}
-av_assert0(!ff_avcodec_locked);
-ff_avcodec_locked = 1;
-return 0;
-}
-
-int ff_unlock_avcodec(const AVCodec *codec)
-{
-if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
-return 0;
-
-av_assert0(ff_avcodec_locked);
-ff_avcodec_locked = 0;
-atomic_fetch_add(&entangled_thread_counter, -1);
-if (pthread_mutex_unlock(&codec_mutex))
-return -1;
-
-return 0;
-}
-
 unsigned int avpriv_toupper4(unsigned int x)
 {
 return av_toupper(x & 0xFF) +
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 1/5] w32pthreads: always use Vista+ API, drop XP support

2017-12-21 Thread wm4
This removes the XP compatibility code, and switches entirely to SWR
locks, which are available starting at Windows Vista.

This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.

Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK. (Technically, it could still
be built for Windows XP using an external pthread lib as of this
commit.)

Windows Vista adds WSAPoll(), and for some reason struct pollfd. Since
we raise the Windows API level globally when enabling w32threads, we
need to move it before configure checks for struct pollfd to avoid that
the compatibility ifdef mess redefines it.
---
Not sure if there's a better way to do the things configure does.
---
 Changelog  |   2 +
 compat/w32pthreads.h   | 269 ++---
 configure  |  93 
 libavcodec/pthread_frame.c |   4 -
 libavcodec/pthread_slice.c |   4 -
 libavfilter/pthread.c  |   4 -
 libavutil/slicethread.c|   4 -
 7 files changed, 60 insertions(+), 320 deletions(-)

diff --git a/Changelog b/Changelog
index ee48876128..decd6c712a 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,8 @@ version :
 - video setrange filter
 - nsp demuxer
 - support LibreSSL (via libtls)
+- Dropped support for building for Windows XP. The minimum supported Windows
+  version is Windows Vista.
 
 
 version 3.4:
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index eeead6051f..9c7e0f574d 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -56,24 +56,12 @@ typedef struct pthread_t {
 void *ret;
 } pthread_t;
 
-/* the conditional variable api for windows 6.0+ uses critical sections and
- * not mutexes */
-typedef CRITICAL_SECTION pthread_mutex_t;
-
-/* This is the CONDITION_VARIABLE typedef for using Windows' native
- * conditional variables on kernels 6.0+. */
-#if HAVE_CONDITION_VARIABLE_PTR
+/* use light weight mutex/condition variable API for Windows Vista and later */
+typedef SRWLOCK pthread_mutex_t;
 typedef CONDITION_VARIABLE pthread_cond_t;
-#else
-typedef struct pthread_cond_t {
-void *Ptr;
-} pthread_cond_t;
-#endif
 
-#if _WIN32_WINNT >= 0x0600
-#define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)
-#define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
-#endif
+#define PTHREAD_MUTEX_INITIALIZER SRWLOCK_INIT
+#define PTHREAD_COND_INITIALIZER CONDITION_VARIABLE_INIT
 
 static av_unused unsigned __stdcall attribute_align_arg 
win32thread_worker(void *arg)
 {
@@ -114,26 +102,25 @@ static av_unused int pthread_join(pthread_t thread, void 
**value_ptr)
 
 static inline int pthread_mutex_init(pthread_mutex_t *m, void* attr)
 {
-InitializeCriticalSection(m);
+InitializeSRWLock(m);
 return 0;
 }
 static inline int pthread_mutex_destroy(pthread_mutex_t *m)
 {
-DeleteCriticalSection(m);
+/* Unlocked SWR locks use no resources */
 return 0;
 }
 static inline int pthread_mutex_lock(pthread_mutex_t *m)
 {
-EnterCriticalSection(m);
+AcquireSRWLockExclusive(m);
 return 0;
 }
 static inline int pthread_mutex_unlock(pthread_mutex_t *m)
 {
-LeaveCriticalSection(m);
+ReleaseSRWLockExclusive(m);
 return 0;
 }
 
-#if _WIN32_WINNT >= 0x0600
 typedef INIT_ONCE pthread_once_t;
 #define PTHREAD_ONCE_INIT INIT_ONCE_STATIC_INIT
 
@@ -167,7 +154,7 @@ static inline int pthread_cond_broadcast(pthread_cond_t 
*cond)
 
 static inline int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t 
*mutex)
 {
-SleepConditionVariableCS(cond, mutex, INFINITE);
+SleepConditionVariableSRW(cond, mutex, INFINITE, 0);
 return 0;
 }
 
@@ -177,242 +164,4 @@ static inline int pthread_cond_signal(pthread_cond_t 
*cond)
 return 0;
 }
 
-#else // _WIN32_WINNT < 0x0600
-
-/* atomic init state of dynamically loaded functions */
-static LONG w32thread_init_state = 0;
-static av_unused void w32thread_init(void);
-
-/* for pre-Windows 6.0 platforms, define INIT_ONCE struct,
- * compatible to the one used in the native API */
-
-typedef union pthread_once_t  {
-void * Ptr;///< For the Windows 6.0+ native functions
-LONG state;///< For the pre-Windows 6.0 compat code
-} pthread_once_t;
-
-#define PTHREAD_ONCE_INIT {0}
-
-/* function pointers to init once API on windows 6.0+ kernels */
-static BOOL (WINAPI *initonce_begin)(pthread_once_t *lpInitOnce, DWORD 
dwFlags, BOOL *fPending, void **lpContext);
-static BOOL (WINAPI *initonce_complete)(pthread_once_t *lpInitOnce, DWORD 
dwFlags, void *lpContext);
-
-/* pre-Windows 6.0 compat using a spin-lock */
-static inline void w32thread_once_fallback(LONG volatile *state, void 
(*init_routine)(void))
-{
-switch (InterlockedCompareExchange(state, 1, 0)) {
-/* Initial run */
-case 0:
-init_routine();
-InterlockedExchange(state, 2);
-break;
-/* Another thread is running init */
-case 1:
-   

Re: [FFmpeg-devel] [PATCH 1/7] fate: add 12 bit framerate filter tests

2017-12-21 Thread Marton Balint



On Mon, 18 Dec 2017, Paul B Mahol wrote:


On 12/10/17, Marton Balint  wrote:

Signed-off-by: Marton Balint 
---
 tests/fate/filter-video.mak|  4 ++
 tests/ref/fate/filter-framerate-12bit-down | 55 +
 tests/ref/fate/filter-framerate-12bit-up   | 64
++
 3 files changed, 123 insertions(+)
 create mode 100644 tests/ref/fate/filter-framerate-12bit-down
 create mode 100644 tests/ref/fate/filter-framerate-12bit-up



lgtm


Thanks, pushed the whole series.

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


[FFmpeg-devel] a little bug

2017-12-21 Thread Lenge
Hi all,
I compile ffmpeg for android, some bugs as below:


MACRO B0
bionic/libc/kernel/uapi/asm-generic/termbits.h:142:#define B0 000
src/libavcodec/aaccoder.c:803:25: error: expected identifier or '(' before 
numeric constant
 int B0 = 0, B1 = 0;



atomic_int
src/libavcodec/h264_slice.c:2757:36: error: incompatible types when assigning 
to type 'atomic_int' from type 'int'
 sl->er.error_count = 0;
^
src/libavcodec/h264_slice.c:2782:48: error: invalid operands to binary + (have 
'atomic_int' and 'atomic_int')
 h->slice_ctx[0].er.error_count += 
h->slice_ctx[i].er.error_count;



I change it as below, compile ok.
+#undef B0


-sl->er.error_count = 0;
+   atomic_store(&sl->er.error_count, 0);
-h->slice_ctx[0].er.error_count += 
h->slice_ctx[i].er.error_count;
+   atomic_fetch_add(&h->slice_ctx[0].er.error_count, 
atomic_load(&h->slice_ctx[i].er.error_count));




--
good luck to you.
 lenge
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] mpeg4videodec: Fix unused variable warning

2017-12-21 Thread Mark Thompson
video_format is not used.
---
Introduced by 4b2a186ef02c1fbe7f7cae30a2bdfff72bcc75f7:

src/libavcodec/mpeg4videodec.c: In function ‘mpeg4_decode_visual_object’:
src/libavcodec/mpeg4videodec.c:1771:17: warning: unused variable ‘video_format’ 
[-Wunused-variable]
 int video_format = get_bits(gb, 3);
 ^~~~

 libavcodec/mpeg4videodec.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index e9cba25dd0..12755b5e8a 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -1768,9 +1768,10 @@ static int mpeg4_decode_visual_object(MpegEncContext *s, 
GetBitContext *gb)
 visual_object_type == VOT_STILL_TEXTURE_ID) {
 int video_signal_type = get_bits1(gb);
 if (video_signal_type) {
-int video_format = get_bits(gb, 3);
-int video_range = get_bits1(gb);
-int color_description = get_bits1(gb);
+int video_range, color_description;
+skip_bits(gb, 3); // video_format
+video_range = get_bits1(gb);
+color_description = get_bits1(gb);
 
 s->avctx->color_range = video_range ? AVCOL_RANGE_JPEG : 
AVCOL_RANGE_MPEG;
 
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 979b3a6 web/contact: note that no discussions occur on cvslog and trac mailing lists

2017-12-21 Thread Nicolas George
Lou Logan (2017-12-21):
> * All messages on ffmpeg-cvslog now have a reply-to header set to 
> ffmpeg-devel.

Oh, good. I was actually about to suggest just that. Thank you.

Regards,

-- 
  Nicolas George


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


Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 979b3a6 web/contact: note that no discussions occur on cvslog and trac mailing lists

2017-12-21 Thread Lou Logan
On Thu, Dec 21, 2017, at 4:07 AM, Carl Eugen Hoyos wrote:
> Where was this agreed upon?
> 
> Carl Eugen

As a mailing list maintainer I made this decision based on the reality of the 
situation and due to developer feedback in the following three threads:

[FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)
[FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] 
Refactor Developer Docs, update dev list section (v2)]
[FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] 
Refactor Developer Docs, update dev list section (v2)]

Rationale:
* ffmpeg-cvslog is a log (in addition to git log and gitweb). ffmpeg-devel is 
the mailing list for development discussions. Development discussions should 
occur in one mailing list.
* There are at least 10x fewer subscribed users on ffmpeg-cvslog compared to 
ffmpeg-devel.
* Many (most?) developers do not subscribe to ffmpeg-cvslog.
* Attempts to discuss commits on ffmpeg-cvslog were often ineffectual because 
they were often missed or unread by those they were directed towards (refer to 
previous point).
* Developers that did reply to ffmpeg-cvslog often manually included 
ffmpeg-devel in the reply.

Additionally:
* All messages on ffmpeg-cvslog now have a reply-to header set to ffmpeg-devel.
* All non-log messages are now held in the queue by default.

I did not assume further discussion was required for this subject, but I am 
confident that the vast majority of developers will support this, in my opinion 
minor, decision.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Jeyapal, Karthick


>On 12/21/17, 10:15 PM, "Steven Liu"  wrote:
>
>2017-12-22 0:37 GMT+08:00 Jeyapal, Karthick :
>>
>>
>>>On 12/21/17, 9:47 PM, "Steven Liu"  wrote:
>>>
>>>I cannot sure if this patch can fix the problem playlist target
>>>duration not same.
>>>
>>>MacBook:xxx StevenLiu$ ./ffmpeg -hide_banner -i
>>>~/bbb_sunflower_1080p_30fps_normal.mp4 -g 150 -r 100 -x264opts
>>>"scenecut=-1" -f dash -min_seg_duration 100 -window_size 9 -t
>>>5 -hls_playlist 1 output_Steven.mpd
>> That is because the key frames are not getting inserted at the 1 second 
>> segment duration.
>Maybe you didn't get the point, i want to say, that is not
>EXT-X-TARGETDURATION and EXTINF's problem, it's just need align in
>multi playlist.
I understand your point. Maybe I am not giving the answer to your point.
But nevertheless, here is my defence :)
In this patch, I am only fixing the issue of target duration not matching with 
the configured HLS segment duration. That is when configured segment duration 
is 1 second and the actual segment duration varies from 0.9 sec to 1.1 seconds, 
then it makes more sense to have target duration as 1 second instead of 2 
seconds. And spec allows both 1 seconds and 2 seconds as valid values. But 
having 1 second as target duration is better as it is the user configured value 
and is closer to the average duration. That is the reason I submitted 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215630.html in first 
place.
Now as a side effect this also fixes TARGET-DURATION alignment problem of 
multiplaylist scenario, when the segment duration is an integral multiple of 
seconds. Even otherwise it works for most cases except for x.5 second segment 
durations, and the user doesn’t configure the I frames properly.
1) Theoretically audio duration will not match exactly with the video duration 
at every segment level, but it will average out in the long run. In your 
command instead of ‘-t 5’ if you give ‘-t 10’, then target duration is proper 
as segment durations has got averaged out. 
2) Also, most of the real use-cases is to have segment duration as integer 
multiple of seconds. Even in hlsenc the segment duration value is configurable 
only in seconds. So, a segment duration of 1.5 seconds, 2.5 seconds etc., is 
not yet used by everybody.

So my argument is that this patch fixes target duration issue for audio-only 
streams and the multiplaylists for majority of the real world use-cases. Some 
other corner cases for multiplaylist issue is still not handled, which could be 
handled in a different patch if someone has a real use-case for it. Anyways 
this patch is required to solve my original issue of “target duration for 
audio-only streams not matching the configured segment duration”.

>BTW, user not need use  -force_key_frames, just looks like  ffmpeg -i
>input -c copy -f dash xxx.output, then where is the keyframe we don't
>know, the keyframe's interval cannot control by user, just copy from
>source media file.
>
>
>Thanks




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


Re: [FFmpeg-devel] [PATCH 0/7] AVX-512 support (v.3)

2017-12-21 Thread James Darnley
On 2017-12-21 15:06, Carl Eugen Hoyos wrote:
> 2017-12-21 14:40 GMT+01:00 James Darnley :
>> I have addressed all the comments raised in the previous threads.
>> While some patches were okayed last time I am still sending them
>> as part of these to give everyone a final change to see them again
>> and to object if they wish.
> 
> Does any of the patches change the output of existing asm code?

If you mean the assembly generated rather than video/audio output,
because it passes fate, then no I don't think so.  New functionality
should only be seen when giving an avx512 argument to the INIT_* macros.
 You would have to ask Henrik Gramner on that specific point.  Basically
I just cherry-picked his x264asm commit.

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


Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Steven Liu
2017-12-22 0:37 GMT+08:00 Jeyapal, Karthick :
>
>
>>On 12/21/17, 9:47 PM, "Steven Liu"  wrote:
>>
>>I cannot sure if this patch can fix the problem playlist target
>>duration not same.
>>
>>MacBook:xxx StevenLiu$ ./ffmpeg -hide_banner -i
>>~/bbb_sunflower_1080p_30fps_normal.mp4 -g 150 -r 100 -x264opts
>>"scenecut=-1" -f dash -min_seg_duration 100 -window_size 9 -t
>>5 -hls_playlist 1 output_Steven.mpd
> That is because the key frames are not getting inserted at the 1 second 
> segment duration.
Maybe you didn't get the point, i want to say, that is not
EXT-X-TARGETDURATION and EXTINF's problem, it's just need align in
multi playlist.
BTW, user not need use  -force_key_frames, just looks like  ffmpeg -i
input -c copy -f dash xxx.output, then where is the keyframe we don't
know, the keyframe's interval cannot control by user, just copy from
source media file.


Thanks



> Please add the option -force_key_frames “expr:gte(t,n_forced*1)” in order to 
> generate segments with exact 1 second duration.
>
> akamai@akamai-VirtualBox:~/ffmpeg$ ./ffmpeg -hide_banner -i 
> ~/Downloads/big_buck_bunny_1080p_stereo.avi -g 150 -r 100 -force_key_frames 
> "expr:gte(t,n_forced*1)" -x264opts "scenecut=-1" -f dash -min_seg_duration 
> 100 -window_size 9 -t 5 -hls_playlist 1 /tmp/output_Steven.mpd
> Input #0, avi, from '/home/akamai/Downloads/big_buck_bunny_1080p_stereo.avi':
>   Metadata:
> encoder : MEncoder 2:1.0~rc2-0ubuntu13
>   Duration: 00:09:56.46, start: 0.00, bitrate: 9586 kb/s
> Stream #0:0: Video: msmpeg4v2 (MP42 / 0x3234504D), yuv420p, 1920x1080, 
> 9328 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc
> Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 
> 245 kb/s
> Stream mapping:
>   Stream #0:0 -> #0:0 (msmpeg4v2 (native) -> h264 (libx264))
>   Stream #0:1 -> #0:1 (mp3 (native) -> aac (native))
> Press [q] to stop, [?] for help
> [libx264 @ 0xe513c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
> [libx264 @ 0xe513c0] profile High, level 5.1
> [libx264 @ 0xe513c0] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - 
> Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 
> ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 
> mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 
> fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 
> sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 
> constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 
> weightb=1 open_gop=0 weightp=2 keyint=150 keyint_min=15 scenecut=0 
> intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 
> qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
> [dash @ 0xe4dc60] No bit rate set for stream 0
> [dash @ 0xe4dc60] Opening '/tmp/init-stream0.m4s' for writing
> [dash @ 0xe4dc60] Opening '/tmp/init-stream1.m4s' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> Bandwidth info not available, set audio and video bitrates
> Output #0, dash, to '/tmp/output_Steven.mpd':
>   Metadata:
> encoder : Lavf58.3.100
> Stream #0:0: Video: h264 (libx264), yuv420p, 1920x1080, q=-1--1, 100 fps, 
> 12800 tbn, 100 tbc
> Metadata:
>   encoder : Lavc58.8.100 libx264
> Side data:
>   cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
> Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
> Metadata:
>   encoder : Lavc58.8.100 aac
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-1.m4s.tmp' for writing 
> drop=0 speed=0.67x
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-1.m4s.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-2.m4s.tmp' for writing 
> drop=0 speed=0.55x
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-2.m4s.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-3.m4s.tmp' for writing 
> drop=0 speed=0.552x
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-3.m4s.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-4.m4s.tmp' for writing 
> drop=0 speed=0.543x
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-4.m4s.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-5.m4s.tmp' for writing 
> drop=0 speed=0.507x
> [dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-5.m4s.tmp' for writing
> [dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
> frame=  500 fps= 46 q=-1.0 Lsize=N/A time=00:00:05.01 bitrate=N/A dup=380 
> drop=0 speed=0.462x
> video:1902kB audio:78kB subtitle:0kB other streams:0kB global headers:0kB 
> muxing overhead: unknown
> [libx264 @ 0xe513c0] frame I:5 Avg QP:16.48  size: 61803
>

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Jeyapal, Karthick


>On 12/21/17, 9:47 PM, "Steven Liu"  wrote:
>
>I cannot sure if this patch can fix the problem playlist target
>duration not same.
>
>MacBook:xxx StevenLiu$ ./ffmpeg -hide_banner -i
>~/bbb_sunflower_1080p_30fps_normal.mp4 -g 150 -r 100 -x264opts
>"scenecut=-1" -f dash -min_seg_duration 100 -window_size 9 -t
>5 -hls_playlist 1 output_Steven.mpd
That is because the key frames are not getting inserted at the 1 second segment 
duration. 
Please add the option -force_key_frames “expr:gte(t,n_forced*1)” in order to 
generate segments with exact 1 second duration.

akamai@akamai-VirtualBox:~/ffmpeg$ ./ffmpeg -hide_banner -i 
~/Downloads/big_buck_bunny_1080p_stereo.avi -g 150 -r 100 -force_key_frames 
"expr:gte(t,n_forced*1)" -x264opts "scenecut=-1" -f dash -min_seg_duration 
100 -window_size 9 -t 5 -hls_playlist 1 /tmp/output_Steven.mpd
Input #0, avi, from '/home/akamai/Downloads/big_buck_bunny_1080p_stereo.avi':
  Metadata:
encoder : MEncoder 2:1.0~rc2-0ubuntu13
  Duration: 00:09:56.46, start: 0.00, bitrate: 9586 kb/s
Stream #0:0: Video: msmpeg4v2 (MP42 / 0x3234504D), yuv420p, 1920x1080, 9328 
kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 245 
kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (msmpeg4v2 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (mp3 (native) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0xe513c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 0xe513c0] profile High, level 5.1
[libx264 @ 0xe513c0] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - 
Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 
deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 
mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 
fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 
nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 
b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 
keyint=150 keyint_min=15 scenecut=0 intra_refresh=0 rc_lookahead=40 rc=crf 
mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[dash @ 0xe4dc60] No bit rate set for stream 0
[dash @ 0xe4dc60] Opening '/tmp/init-stream0.m4s' for writing
[dash @ 0xe4dc60] Opening '/tmp/init-stream1.m4s' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
Bandwidth info not available, set audio and video bitrates
Output #0, dash, to '/tmp/output_Steven.mpd':
  Metadata:
encoder : Lavf58.3.100
Stream #0:0: Video: h264 (libx264), yuv420p, 1920x1080, q=-1--1, 100 fps, 
12800 tbn, 100 tbc
Metadata:
  encoder : Lavc58.8.100 libx264
Side data:
  cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s
Metadata:
  encoder : Lavc58.8.100 aac
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-1.m4s.tmp' for writing drop=0 
speed=0.67x
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-1.m4s.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-2.m4s.tmp' for writing drop=0 
speed=0.55x 
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-2.m4s.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-3.m4s.tmp' for writing drop=0 
speed=0.552x
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-3.m4s.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-4.m4s.tmp' for writing drop=0 
speed=0.543x
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-4.m4s.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream0-5.m4s.tmp' for writing drop=0 
speed=0.507x
[dash @ 0xe4dc60] Opening '/tmp/chunk-stream1-5.m4s.tmp' for writing
[dash @ 0xe4dc60] Opening '/tmp/output_Steven.mpd.tmp' for writing
frame=  500 fps= 46 q=-1.0 Lsize=N/A time=00:00:05.01 bitrate=N/A dup=380 
drop=0 speed=0.462x
video:1902kB audio:78kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: unknown
[libx264 @ 0xe513c0] frame I:5 Avg QP:16.48  size: 61803
[libx264 @ 0xe513c0] frame P:177   Avg QP:20.84  size:  8582
[libx264 @ 0xe513c0] frame B:318   Avg QP:20.45  size:   376
[libx264 @ 0xe513c0] consecutive B-frames: 12.2%  0.8% 24.6% 62.4%
[libx264 @ 0xe513c0] mb I  I16..4: 37.3% 59.0%  3.7%
[libx264 @ 0xe513c0] mb P  I16..4:  2.8% 13.1%  0.1%  P16..4: 12.0%  2.3%  1.8% 
 0.0%  0.0%skip:67.9%
[libx264 @ 0xe513c0] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  4.8%  0.0%  0.0% 
 direct: 0.1%  skip:95.1%  L0:76.2% L1:23.6% BI: 0.3%
[libx264 @ 0xe513c0] 8x8 transform intra:78.6% inter:67.3%
[libx264 @ 0xe513c0] 

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Steven Liu
2017-12-21 23:41 GMT+08:00 Karthick J :
> From: Karthick Jeyapal 
>
> The HLS specification states the following about EXT-X-TARGETDURATION
>
> 4.3.3.1.  EXT-X-TARGETDURATION
>
>The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>duration.  The EXTINF duration of each Media Segment in the Playlist
>file, when rounded to the nearest integer, MUST be less than or equal
>to the target duration; longer segments can trigger playback stalls
>or other errors.  It applies to the entire Playlist file.  Its format
>is:
>
>#EXT-X-TARGETDURATION:
>
>where s is a decimal-integer indicating the target duration in
>seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>
> Currently the dashenc rounds the duration to the next integer,
> rather than rounding the duration to the nearest integer.
> ---
>  libavformat/dashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5687530..5368a23 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
> AVIOContext *out, DASHContext
>  Segment *seg = os->segments[i];
>  double duration = (double) seg->duration / timescale;
>  if (target_duration <= duration)
> -target_duration = hls_get_int_from_double(duration);
> +target_duration = lrint(duration);
>  }
>
>  ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
> --
> 1.9.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I cannot sure if this patch can fix the problem playlist target
duration not same.

MacBook:xxx StevenLiu$ ./ffmpeg -hide_banner -i
~/bbb_sunflower_1080p_30fps_normal.mp4 -g 150 -r 100 -x264opts
"scenecut=-1" -f dash -min_seg_duration 100 -window_size 9 -t
5 -hls_playlist 1 output_Steven.mpd
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/Users/StevenLiu/bbb_sunflower_1080p_30fps_normal.mp4':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isomavc1
creation_time   : 2013-12-16T17:44:39.00Z
title   : Big Buck Bunny, Sunflower version
artist  : Blender Foundation 2008, Janus Bager Kristensen 2013
comment : Creative Commons Attribution 3.0 -
http://bbb3d.renderfarming.net
genre   : Animation
composer: Sacha Goedegebure
  Duration: 00:10:34.53, start: 0.00, bitrate: 3481 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
1920x1080 [SAR 1:1 DAR 16:9], 2998 kb/s, 30 fps, 30 tbr, 30k tbn, 60
tbc (default)
Metadata:
  creation_time   : 2013-12-16T17:44:39.00Z
  handler_name: GPAC ISO Video Handler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz,
stereo, s16p, 160 kb/s (default)
Metadata:
  creation_time   : 2013-12-16T17:44:42.00Z
  handler_name: GPAC ISO Audio Handler
Stream #0:2(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz,
5.1(side), fltp, 320 kb/s (default)
Metadata:
  creation_time   : 2013-12-16T17:44:42.00Z
  handler_name: GPAC ISO Audio Handler
Side data:
  audio service type: main
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:2 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0x7f7fa5085200] using SAR=1/1
[libx264 @ 0x7f7fa5085200] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
[libx264 @ 0x7f7fa5085200] profile High, level 5.1
[libx264 @ 0x7f7fa5085200] 264 - core 133 r2334M a3ac64b -
H.264/MPEG-4 AVC codec - Copyleft 2003-2013 -
http://www.videolan.org/x264.html - options: cabac=1 ref=3
deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00
mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0
deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6
lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0
bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=150
keyint_min=15 scenecut=0 intra_refresh=0 rc_lookahead=40 rc=crf
mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40
aq=1:1.00
[aac @ 0x7f7fa5086a00] Using a PCE to encode channel layout
[dash @ 0x7f7fa6087400] No bit rate set for stream 0
[dash @ 0x7f7fa6087400] Opening 'init-stream0.m4s' for writing
[dash @ 0x7f7fa6087400] Opening 'init-stream1.m4s' for writing
[dash @ 0x7f7fa6087400] Opening 'output_Steven.mpd.tmp' for writing
Bandwidth info not available, set audio and video bitrates
Output #0, dash, to 'output_Steven.mpd':
  Metadata:
major_brand : isom
minor_version   : 1
compatible_brands: isomavc1
composer: Sacha Goedegebure
title   : Big Buck Bunny, Sunflower ver

[FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Karthick J
From: Karthick Jeyapal 

The HLS specification states the following about EXT-X-TARGETDURATION

4.3.3.1.  EXT-X-TARGETDURATION

   The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
   duration.  The EXTINF duration of each Media Segment in the Playlist
   file, when rounded to the nearest integer, MUST be less than or equal
   to the target duration; longer segments can trigger playback stalls
   or other errors.  It applies to the entire Playlist file.  Its format
   is:

   #EXT-X-TARGETDURATION:

   where s is a decimal-integer indicating the target duration in
   seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.

Currently the dashenc rounds the duration to the next integer,
rather than rounding the duration to the nearest integer.
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5687530..5368a23 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 Segment *seg = os->segments[i];
 double duration = (double) seg->duration / timescale;
 if (target_duration <= duration)
-target_duration = hls_get_int_from_double(duration);
+target_duration = lrint(duration);
 }
 
 ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
-- 
1.9.1

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


[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: Moved hls_get_int_from_double() function locally to hlsenc.c

2017-12-21 Thread Karthick J
From: Karthick Jeyapal 

dashenc no longer needs this function.
---
 libavformat/hlsenc.c  | 5 +
 libavformat/hlsplaylist.h | 5 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 29fc1d4..14a9a12 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -240,6 +240,11 @@ static int mkdir_p(const char *path) {
 return ret;
 }
 
+static int hls_get_int_from_double(double val)
+{
+return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
+}
+
 static int is_http_proto(char *filename) {
 const char *proto = avio_find_protocol_name(filename);
 return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
"https")) : 0;
diff --git a/libavformat/hlsplaylist.h b/libavformat/hlsplaylist.h
index 48d71b7..fe19f34 100644
--- a/libavformat/hlsplaylist.h
+++ b/libavformat/hlsplaylist.h
@@ -36,11 +36,6 @@ typedef enum {
 PLAYLIST_TYPE_NB,
 } PlaylistType;
 
-static inline int hls_get_int_from_double(double val)
-{
-return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
-}
-
 void ff_hls_write_playlist_version(AVIOContext *out, int version);
 void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
   int bandwidth, char *filename);
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Karthick Jeyapal



On 12/21/17 7:45 PM, Carl Eugen Hoyos wrote:

2017-12-21 11:09 GMT+01:00 Karthick J :


  if (target_duration <= duration)
-target_duration = hls_get_int_from_double(duration);
+target_duration = lrint(duration);

If this patch gets committed, please move the function
into dashenc.c.
I am confused. Which function? Could you please clarify? Did you mean 
lrint() function?


Carl Eugen
___
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] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Carl Eugen Hoyos
2017-12-21 11:09 GMT+01:00 Karthick J :

>  if (target_duration <= duration)
> -target_duration = hls_get_int_from_double(duration);
> +target_duration = lrint(duration);

If this patch gets committed, please move the function
into dashenc.c.

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


Re: [FFmpeg-devel] [PATCH 0/7] AVX-512 support (v.3)

2017-12-21 Thread Carl Eugen Hoyos
2017-12-21 14:40 GMT+01:00 James Darnley :
> I have addressed all the comments raised in the previous threads.
> While some patches were okayed last time I am still sending them
> as part of these to give everyone a final change to see them again
> and to object if they wish.

Does any of the patches change the output of existing asm code?

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


[FFmpeg-devel] [PATCH 4/7] avutil: add alignment needed for AVX-512

2017-12-21 Thread James Darnley
---
 libavutil/mem.c | 2 +-
 libavutil/x86/cpu.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 6ad409daf4..79e8b597f1 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -61,7 +61,7 @@ void  free(void *ptr);
 
 #include "mem_internal.h"
 
-#define ALIGN (HAVE_AVX ? 32 : 16)
+#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
 
 /* NOTE: if you want to override these functions with your own
  * implementations (not recommended) you have to link libav* as
diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index 696f47b3bf..7cf673a7d7 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -246,6 +246,8 @@ size_t ff_get_cpu_max_align_x86(void)
 {
 int flags = av_get_cpu_flags();
 
+if (flags & AV_CPU_FLAG_AVX512)
+return 64;
 if (flags & (AV_CPU_FLAG_AVX2  |
  AV_CPU_FLAG_AVX   |
  AV_CPU_FLAG_XOP   |
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 0/7] AVX-512 support (v.3)

2017-12-21 Thread James Darnley
I have addressed all the comments raised in the previous threads.  While some
patches were okayed last time I am still sending them as part of these to give
everyone a final change to see them again and to object if they wish.

Henrik Gramner (1):
  x86inc: AVX-512 support

James Darnley (6):
  configure: test whether x86 assembler supports AVX-512
  avutil: add AVX-512 flags
  avutil: detect when AVX-512 is available
  avutil: add alignment needed for AVX-512
  avcodec: add stride alignment needed for AVX-512
  checkasm: support for AVX-512 functions

 Changelog |   1 +
 configure |   7 ++
 doc/APIchanges|   3 +
 libavcodec/internal.h |   4 +-
 libavutil/cpu.c   |   6 +-
 libavutil/cpu.h   |   1 +
 libavutil/mem.c   |   2 +-
 libavutil/tests/cpu.c |   1 +
 libavutil/version.h   |   2 +-
 libavutil/x86/cpu.c   |  14 +++-
 libavutil/x86/cpu.h   |   2 +
 libavutil/x86/x86inc.asm  | 172 +-
 tests/checkasm/checkasm.c |   1 +
 13 files changed, 177 insertions(+), 39 deletions(-)

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


[FFmpeg-devel] [PATCH 2/7] avutil: add AVX-512 flags

2017-12-21 Thread James Darnley
---
 Changelog | 1 +
 doc/APIchanges| 3 +++
 libavutil/cpu.c   | 6 +-
 libavutil/cpu.h   | 1 +
 libavutil/tests/cpu.c | 1 +
 libavutil/version.h   | 2 +-
 libavutil/x86/cpu.h   | 2 ++
 7 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Changelog b/Changelog
index ee48876128..f44cec679f 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
 - video setrange filter
 - nsp demuxer
 - support LibreSSL (via libtls)
+- AVX-512/ZMM support added
 
 
 version 3.4:
diff --git a/doc/APIchanges b/doc/APIchanges
index da444ffb7c..df79758e86 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-12-xx - xxx - lavu 56.7.100 - cpu.h
+  AVX-512 flags added.
+
 2017-xx-xx - xxx - lavc 58.8.100 - avcodec.h
   The MediaCodec decoders now support AVCodecContext.hw_device_ctx.
 
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index c8401b8258..6548cc3042 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -80,7 +80,8 @@ void av_force_cpu_flags(int arg){
 AV_CPU_FLAG_XOP  |
 AV_CPU_FLAG_FMA3 |
 AV_CPU_FLAG_FMA4 |
-AV_CPU_FLAG_AVX2 ))
+AV_CPU_FLAG_AVX2 |
+AV_CPU_FLAG_AVX512   ))
 && !(arg & AV_CPU_FLAG_MMX)) {
 av_log(NULL, AV_LOG_WARNING, "MMX implied by specified flags\n");
 arg |= AV_CPU_FLAG_MMX;
@@ -126,6 +127,7 @@ int av_parse_cpu_flags(const char *s)
 #define CPUFLAG_AVX2 (AV_CPU_FLAG_AVX2 | CPUFLAG_AVX)
 #define CPUFLAG_BMI2 (AV_CPU_FLAG_BMI2 | AV_CPU_FLAG_BMI1)
 #define CPUFLAG_AESNI(AV_CPU_FLAG_AESNI| CPUFLAG_SSE42)
+#define CPUFLAG_AVX512   (AV_CPU_FLAG_AVX512   | CPUFLAG_AVX2)
 static const AVOption cpuflags_opts[] = {
 { "flags"   , NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 }, INT64_MIN, 
INT64_MAX, .unit = "flags" },
 #if   ARCH_PPC
@@ -154,6 +156,7 @@ int av_parse_cpu_flags(const char *s)
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_3DNOWEXT
 },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
 { "aesni"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AESNI   
 },.unit = "flags" },
+{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = CPUFLAG_AVX512  
 },.unit = "flags" },
 #elif ARCH_ARM
 { "armv5te",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV5TE 
 },.unit = "flags" },
 { "armv6",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV6   
 },.unit = "flags" },
@@ -216,6 +219,7 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
 { "3dnowext", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_CPU_FLAG_3DNOWEXT },.unit = "flags" },
 { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_CMOV
 },.unit = "flags" },
 { "aesni",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AESNI   
 },.unit = "flags" },
+{ "avx512"  , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_AVX512  
 },.unit = "flags" },
 
 #define CPU_FLAG_P2 AV_CPU_FLAG_CMOV | AV_CPU_FLAG_MMX
 #define CPU_FLAG_P3 CPU_FLAG_P2 | AV_CPU_FLAG_MMX2 | AV_CPU_FLAG_SSE
diff --git a/libavutil/cpu.h b/libavutil/cpu.h
index 9e5d40affe..8bb9eb606b 100644
--- a/libavutil/cpu.h
+++ b/libavutil/cpu.h
@@ -55,6 +55,7 @@
 #define AV_CPU_FLAG_FMA30x1 ///< Haswell FMA3 functions
 #define AV_CPU_FLAG_BMI10x2 ///< Bit Manipulation Instruction Set 1
 #define AV_CPU_FLAG_BMI20x4 ///< Bit Manipulation Instruction Set 2
+#define AV_CPU_FLAG_AVX512 0x10 ///< AVX-512 functions: requires OS 
support even if YMM/ZMM registers aren't used
 
 #define AV_CPU_FLAG_ALTIVEC  0x0001 ///< standard
 #define AV_CPU_FLAG_VSX  0x0002 ///< ISA 2.06
diff --git a/libavutil/tests/cpu.c b/libavutil/tests/cpu.c
index f02a54cbbb..ce45b715a0 100644
--- a/libavutil/tests/cpu.c
+++ b/libavutil/tests/cpu.c
@@ -73,6 +73,7 @@ static const struct {
 { AV_CPU_FLAG_BMI1,  "bmi1"   },
 { AV_CPU_FLAG_BMI2,  "bmi2"   },
 { AV_CPU_FLAG_AESNI, "aesni"  },
+{ AV_CPU_FLAG_AVX512,"avx512" },
 #endif
 { 0 }
 };
diff --git a/libavutil/version.h b/libavutil/version.h
index 9ae9768d4d..d81ec6fa7b 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR   6
+#define LIBAVUTIL_VERSION_MINOR   7
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/libavutil/x86/cpu.h b/libavutil/x86/cpu.h
index 309b8e746c..7f4e5d08bb 100644
--- a/libavutil/x86/cpu.h
+++ b/libavutil/x86/cpu.h
@@ -50,6 +50,7 @@
 #define X86_FMA4(flags) CPUEXT(flags, FMA4)
 #define X86_AVX2(flags)   

[FFmpeg-devel] [PATCH 7/7] checkasm: support for AVX-512 functions

2017-12-21 Thread James Darnley
---
 tests/checkasm/checkasm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 45a70aa87f..ff0ca5b68d 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -204,6 +204,7 @@ static const struct {
 { "FMA3", "fma3", AV_CPU_FLAG_FMA3 },
 { "FMA4", "fma4", AV_CPU_FLAG_FMA4 },
 { "AVX2", "avx2", AV_CPU_FLAG_AVX2 },
+{ "AVX-512",  "avx512",   AV_CPU_FLAG_AVX512 },
 #endif
 { NULL }
 };
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 1/7] configure: test whether x86 assembler supports AVX-512

2017-12-21 Thread James Darnley
---
 configure | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure b/configure
index d09eec4155..07fb825f91 100755
--- a/configure
+++ b/configure
@@ -411,6 +411,7 @@ Optimization options (experts only):
   --disable-fma3   disable FMA3 optimizations
   --disable-fma4   disable FMA4 optimizations
   --disable-avx2   disable AVX2 optimizations
+  --disable-avx512 disable AVX-512 optimizations
   --disable-aesni  disable AESNI optimizations
   --disable-armv5tedisable armv5te optimizations
   --disable-armv6  disable armv6 optimizations
@@ -1846,6 +1847,7 @@ ARCH_EXT_LIST_X86_SIMD="
 amd3dnowext
 avx
 avx2
+avx512
 fma3
 fma4
 mmx
@@ -2373,6 +2375,7 @@ xop_deps="avx"
 fma3_deps="avx"
 fma4_deps="avx"
 avx2_deps="avx"
+avx512_deps="avx2"
 
 mmx_external_deps="x86asm"
 mmx_inline_deps="inline_asm x86"
@@ -5545,6 +5548,7 @@ EOF
 elf*) enabled debug && append X86ASMFLAGS $x86asm_debug ;;
 esac
 
+check_x86asm "vmovdqa32 [eax]{k1}{z}, zmm0"|| disable 
avx512_external
 check_x86asm "vextracti128 xmm0, ymm0, 0"  || disable avx2_external
 check_x86asm "vpmacsdd xmm0, xmm1, xmm2, xmm3" || disable xop_external
 check_x86asm "vfmaddps ymm0, ymm1, ymm2, ymm3" || disable fma4_external
@@ -6690,6 +6694,7 @@ if enabled x86; then
 echo "AESNI enabled ${aesni-no}"
 echo "AVX enabled   ${avx-no}"
 echo "AVX2 enabled  ${avx2-no}"
+echo "AVX-512 enabled   ${avx512-no}"
 echo "XOP enabled   ${xop-no}"
 echo "FMA3 enabled  ${fma3-no}"
 echo "FMA4 enabled  ${fma4-no}"
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 3/7] avutil: detect when AVX-512 is available

2017-12-21 Thread James Darnley
---
 libavutil/x86/cpu.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index f33088c8c7..696f47b3bf 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -97,6 +97,7 @@ int ff_get_cpu_flags_x86(void)
 int max_std_level, max_ext_level, std_caps = 0, ext_caps = 0;
 int family = 0, model = 0;
 union { int i[3]; char c[12]; } vendor;
+int xcr0_lo = 0, xcr0_hi = 0;
 
 if (!cpuid_test())
 return 0; /* CPUID not supported */
@@ -132,8 +133,8 @@ int ff_get_cpu_flags_x86(void)
 /* Check OXSAVE and AVX bits */
 if ((ecx & 0x1800) == 0x1800) {
 /* Check for OS support */
-xgetbv(0, eax, edx);
-if ((eax & 0x6) == 0x6) {
+xgetbv(0, xcr0_lo, xcr0_hi);
+if ((xcr0_lo & 0x6) == 0x6) {
 rval |= AV_CPU_FLAG_AVX;
 if (ecx & 0x1000)
 rval |= AV_CPU_FLAG_FMA3;
@@ -147,6 +148,13 @@ int ff_get_cpu_flags_x86(void)
 #if HAVE_AVX2
 if ((rval & AV_CPU_FLAG_AVX) && (ebx & 0x0020))
 rval |= AV_CPU_FLAG_AVX2;
+#if HAVE_AVX512 /* F, CD, BW, DQ, VL */
+if ((xcr0_lo & 0xe0) == 0xe0) { /* OPMASK/ZMM state */
+if ((ebx & 0xd003) == 0xd003)
+rval |= AV_CPU_FLAG_AVX512;
+
+}
+#endif /* HAVE_AVX512 */
 #endif /* HAVE_AVX2 */
 /* BMI1/2 don't need OS support */
 if (ebx & 0x0008) {
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 5/7] avcodec: add stride alignment needed for AVX-512

2017-12-21 Thread James Darnley
---
 configure | 2 ++
 libavcodec/internal.h | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 07fb825f91..d3187d71ed 100755
--- a/configure
+++ b/configure
@@ -1892,6 +1892,7 @@ ARCH_FEATURES="
 local_aligned
 simd_align_16
 simd_align_32
+simd_align_64
 "
 
 BUILTIN_LIST="
@@ -2394,6 +2395,7 @@ fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
 fast_unaligned_if_any="aarch64 ppc x86"
 simd_align_16_if_any="altivec neon sse"
 simd_align_32_if_any="avx"
+simd_align_64_if_any="avx512"
 
 # system capabilities
 symver_if_any="symver_asm_label symver_gnu_asm"
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 30cb9a0de1..fcbdb6c04d 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -87,7 +87,9 @@
 
 #define FF_SIGNBIT(x) ((x) >> CHAR_BIT * sizeof(x) - 1)
 
-#if HAVE_SIMD_ALIGN_32
+#if HAVE_SIMD_ALIGN_64
+#   define STRIDE_ALIGN 64 /* AVX-512 */
+#elif HAVE_SIMD_ALIGN_32
 #   define STRIDE_ALIGN 32
 #elif HAVE_SIMD_ALIGN_16
 #   define STRIDE_ALIGN 16
-- 
2.15.1

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


[FFmpeg-devel] [PATCH 6/7] x86inc: AVX-512 support

2017-12-21 Thread James Darnley
From: Henrik Gramner 

AVX-512 consists of a plethora of different extensions, but in order to keep
things a bit more manageable we group together the following extensions
under a single baseline cpu flag which should cover SKL-X and future CPUs:
 * AVX-512 Foundation (F)
 * AVX-512 Conflict Detection Instructions (CD)
 * AVX-512 Byte and Word Instructions (BW)
 * AVX-512 Doubleword and Quadword Instructions (DQ)
 * AVX-512 Vector Length Extensions (VL)

On x86-64 AVX-512 provides 16 additional vector registers, prefer using
those over existing ones since it allows us to avoid using `vzeroupper`
unless more than 16 vector registers are required. They also happen to
be volatile on Windows which means that we don't need to save and restore
existing xmm register contents unless more than 22 vector registers are
required.

Big thanks to Intel for their support.
---
 libavutil/x86/x86inc.asm | 172 ++-
 1 file changed, 139 insertions(+), 33 deletions(-)

diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 6a054a3e09..f3dd2b788a 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -337,6 +337,8 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
 %endmacro
 
 %define required_stack_alignment ((mmsize + 15) & ~15)
+%define vzeroupper_required (mmsize > 16 && (ARCH_X86_64 == 0 || xmm_regs_used 
> 16 || notcpuflag(avx512)))
+%define high_mm_regs (16*cpuflag(avx512))
 
 %macro ALLOC_STACK 1-2 0 ; stack_size, n_xmm_regs (for win64 only)
 %ifnum %1
@@ -450,15 +452,16 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_PUSH_XMM 0
 ; Use the shadow space to store XMM6 and XMM7, the rest needs stack space 
allocated.
-%if xmm_regs_used > 6
+%if xmm_regs_used > 6 + high_mm_regs
 movaps [rstk + stack_offset +  8], xmm6
 %endif
-%if xmm_regs_used > 7
+%if xmm_regs_used > 7 + high_mm_regs
 movaps [rstk + stack_offset + 24], xmm7
 %endif
-%if xmm_regs_used > 8
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
 %assign %%i 8
-%rep xmm_regs_used-8
+%rep %%xmm_regs_on_stack
 movaps [rsp + (%%i-8)*16 + stack_size + 32], xmm %+ %%i
 %assign %%i %%i+1
 %endrep
@@ -467,10 +470,11 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_SPILL_XMM 1
 %assign xmm_regs_used %1
-ASSERT xmm_regs_used <= 16
-%if xmm_regs_used > 8
+ASSERT xmm_regs_used <= 16 + high_mm_regs
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
 ; Allocate stack space for callee-saved xmm registers plus shadow 
space and align the stack.
-%assign %%pad (xmm_regs_used-8)*16 + 32
+%assign %%pad %%xmm_regs_on_stack*16 + 32
 %assign stack_size_padded %%pad + ((-%%pad-stack_offset-gprsize) & 
(STACK_ALIGNMENT-1))
 SUB rsp, stack_size_padded
 %endif
@@ -479,9 +483,10 @@ DECLARE_REG 14, R13, 120
 
 %macro WIN64_RESTORE_XMM_INTERNAL 0
 %assign %%pad_size 0
-%if xmm_regs_used > 8
-%assign %%i xmm_regs_used
-%rep xmm_regs_used-8
+%assign %%xmm_regs_on_stack xmm_regs_used - high_mm_regs - 8
+%if %%xmm_regs_on_stack > 0
+%assign %%i xmm_regs_used - high_mm_regs
+%rep %%xmm_regs_on_stack
 %assign %%i %%i-1
 movaps xmm %+ %%i, [rsp + (%%i-8)*16 + stack_size + 32]
 %endrep
@@ -494,10 +499,10 @@ DECLARE_REG 14, R13, 120
 %assign %%pad_size stack_size_padded
 %endif
 %endif
-%if xmm_regs_used > 7
+%if xmm_regs_used > 7 + high_mm_regs
 movaps xmm7, [rsp + stack_offset - %%pad_size + 24]
 %endif
-%if xmm_regs_used > 6
+%if xmm_regs_used > 6 + high_mm_regs
 movaps xmm6, [rsp + stack_offset - %%pad_size +  8]
 %endif
 %endmacro
@@ -509,12 +514,12 @@ DECLARE_REG 14, R13, 120
 %assign xmm_regs_used 0
 %endmacro
 
-%define has_epilogue regs_used > 7 || xmm_regs_used > 6 || mmsize == 32 || 
stack_size > 0
+%define has_epilogue regs_used > 7 || stack_size > 0 || vzeroupper_required || 
xmm_regs_used > 6+high_mm_regs
 
 %macro RET 0
 WIN64_RESTORE_XMM_INTERNAL
 POP_IF_USED 14, 13, 12, 11, 10, 9, 8, 7
-%if mmsize == 32
+%if vzeroupper_required
 vzeroupper
 %endif
 AUTO_REP_RET
@@ -538,9 +543,10 @@ DECLARE_REG 12, R15, 56
 DECLARE_REG 13, R12, 64
 DECLARE_REG 14, R13, 72
 
-%macro PROLOGUE 2-5+ ; #args, #regs, #xmm_regs, [stack_size,] arg_names...
+%macro PROLOGUE 2-5+ 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names...
 %assign num_args %1
 %assign regs_used %2
+%assign xmm_regs_used %3
 ASSERT regs_used >= num_args
 SETUP_STACK_POINTER %4
 ASSERT regs_used <= 15
@@ -550,7 +556,7 @@ DECLARE_REG 14, R13, 72
 DEFINE_ARGS_INTERNAL %0, %4, %5
 %endmacro
 
-%define has_epilogue regs_used > 9 || mmsize == 32 || stack_size > 0
+%define has_epilogue regs_used > 9 

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Add support for parsing and exporting video_range

2017-12-21 Thread Michael Niedermayer
On Sun, Dec 10, 2017 at 10:19:30PM +, Mark Thompson wrote:
> On 10/12/17 21:49, Michael Niedermayer wrote:
> > On Sun, Dec 10, 2017 at 07:56:49PM +, Mark Thompson wrote:
> >> On 10/12/17 15:20, Michael Niedermayer wrote:
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>>  libavcodec/mpeg4video.h|  3 +++
> >>>  libavcodec/mpeg4videodec.c | 32 
> >>>  2 files changed, 35 insertions(+)
> >>>
> >>> diff --git a/libavcodec/mpeg4video.h b/libavcodec/mpeg4video.h
> >>> index 515b008ae4..0ba502d50b 100644
> >>> --- a/libavcodec/mpeg4video.h
> >>> +++ b/libavcodec/mpeg4video.h
> >>> @@ -43,6 +43,9 @@
> >>>  #define ACE_VO_TYPE 12
> >>>  #define ADV_SIMPLE_VO_TYPE  17
> >>>  
> >>> +#define VOT_VIDEO_ID 1
> >>> +#define VOT_STILL_TEXTURE_ID 2
> >>> +
> >>>  // aspect_ratio_info
> >>>  #define EXTENDED_PAR 15
> >>>  
> >>> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> >>> index cdd7077f01..852f73f02c 100644
> >>> --- a/libavcodec/mpeg4videodec.c
> >>> +++ b/libavcodec/mpeg4videodec.c
> >>> @@ -1751,6 +1751,36 @@ static int 
> >>> mpeg4_decode_profile_level(MpegEncContext *s, GetBitContext *gb)
> >>>  s->avctx->level = 0;
> >>>  }
> >>>  
> >>> +return 0;
> >>> +
> >>
> >> Stray newline.
> >>
> >>> +}
> >>> +
> >>> +static int mpeg4_decode_visual_object(MpegEncContext *s, GetBitContext 
> >>> *gb)
> >>> +{
> >>> +int visual_object_type;
> >>> +int is_visual_object_identifier = get_bits1(gb);
> >>> +
> >>> +if (is_visual_object_identifier) {
> >>> +skip_bits(gb, 4+3);
> >>> +}
> >>> +visual_object_type = get_bits(gb, 4);
> >>> +
> >>> +if (visual_object_type == VOT_VIDEO_ID ||
> >>> +visual_object_type == VOT_STILL_TEXTURE_ID) {
> >>> +int video_signal_type = get_bits1(gb);
> >>> +if (video_signal_type) {
> >>> +int video_format = get_bits(gb, 3);
> >>> +int video_range = get_bits1(gb);
> >>> +int color_description = get_bits1(gb);
> >>> +
> >>> +s->avctx->color_range = video_range ? AVCOL_RANGE_JPEG : 
> >>> AVCOL_RANGE_MPEG;
> >>> +
> >>> +if (color_description) {
> >>> +skip_bits(gb, 8+8+8);
> >>
> >> Might be nice to extract the colour information as well?  (Should be able 
> >> to set color_primaries/color_trc/colorspace directly, I think.)
> > 
> > will look into this
> > btw, iam a bit short on samples that use this
> > i had found just one sample after a quick look
> > more samples would be welcome, if someone has some.
> 
> From a quick look around (run over some MPEG-4 samples with an abort in the 
> above code) I can't find any examples of video_signal_type being set at all.  
> Minor thing I noticed in doing that - video_format is unused so you get a 
> warning from the compiler: since it's not useful to anyone maybe replace it 
> with skip_bits(3) and move the other stuff around to match that?
> 
> Don't block this because of the colour part if you don't have a sample of 
> that - I just thought from reading the relevant part of the standard that it 
> should be easy, but if noone has ever used it then whatever.

will push with color part support.
I sadly have not found much to test it seems to be the same as mpeg2

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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


Re: [FFmpeg-devel] [FFmpeg-cvslog] [ffmpeg-web] branch master updated. 979b3a6 web/contact: note that no discussions occur on cvslog and trac mailing lists

2017-12-21 Thread Carl Eugen Hoyos
2017-12-21 2:07 GMT+01:00  :
> The branch, master has been updated
>via  979b3a6608b30683dc1d722e0304315a44f86cf7 (commit)
>   from  73341e6d38818f9723926b58715e751463771d45 (commit)
>
>
> - Log -
> commit 979b3a6608b30683dc1d722e0304315a44f86cf7
> Author: Lou Logan 
> AuthorDate: Wed Dec 20 15:55:45 2017 -0900
> Commit: Lou Logan 
> CommitDate: Wed Dec 20 16:06:47 2017 -0900
>
> web/contact: note that no discussions occur on cvslog and trac mailing 
> lists
>
> Excluding discussions that occur on trac itself of course.
>
> All other postings will be moderated by default.
>
> Signed-off-by: Lou Logan 
>
> diff --git a/src/contact b/src/contact
> index fb2e4eb..945e664 100644
> --- a/src/contact
> +++ b/src/contact
> @@ -54,11 +54,14 @@
>  
>   href="https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-cvslog/";>
>ffmpeg-cvslog
> -  A log of all changes and updates made to the FFmpeg source.
> +  A log of all changes and updates made to the FFmpeg source. No 
> discussion occurs on this
> +  mailing list.

Where was this agreed upon?

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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000dec: Free lengthinc earlier

2017-12-21 Thread Michael Niedermayer
On Sun, Dec 17, 2017 at 11:35:26PM +0100, Michael Niedermayer wrote:
> Reduces memory needed
> ---
>  libavcodec/jpeg2000dec.c | 3 +++
>  1 file changed, 3 insertions(+)

applied

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

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


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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Allocate lengthinc and data_start arrays as needed

2017-12-21 Thread Michael Niedermayer
On Sun, Dec 17, 2017 at 11:35:25PM +0100, Michael Niedermayer wrote:
> Decreases memory requirements
> Fixes: OOM
> Fixes: 4525/clusterfuzz-testcase-minimized-6400713073623040
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 

applied

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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


Re: [FFmpeg-devel] [PATCH 02/10] crc: add av_crc_bits() to compute CRC on block with bit boundary

2017-12-21 Thread Rostislav Pehlivanov
On 20 December 2017 at 19:58, Aurelien Jacobs  wrote:

> ---
>  libavutil/crc.c | 20 
>  libavutil/crc.h | 12 
>  2 files changed, 32 insertions(+)
>
> diff --git a/libavutil/crc.c b/libavutil/crc.c
> index 8e44a76ec8..cb26a09a20 100644
> --- a/libavutil/crc.c
> +++ b/libavutil/crc.c
> @@ -413,3 +413,23 @@ uint32_t av_crc(const AVCRC *ctx, uint32_t crc,
>
>  return crc;
>  }
> +
> +uint32_t av_crc_bits(const AVCRC *ctx, uint32_t crc,
> + const uint8_t *buffer, size_t length)
> +{
> +size_t byte_length = length >> 3;
> +int bit_length = length & 7;
> +
> +crc = av_crc(ctx, crc, buffer, byte_length);
> +
> +if (bit_length) {
> +uint8_t bits = buffer[byte_length];
> +while (bit_length--) {
> +int8_t mask = (bits ^ crc);
> +crc = (crc << 1) ^ (ctx[1] & (mask >> 7));
> +bits <<= 1;
> +}
> +}
> +
> +return crc;
> +}
> diff --git a/libavutil/crc.h b/libavutil/crc.h
> index e57a1af903..bde31f858a 100644
> --- a/libavutil/crc.h
> +++ b/libavutil/crc.h
> @@ -86,6 +86,7 @@ const AVCRC *av_crc_get_table(AVCRCId crc_id);
>  /**
>   * Calculate the CRC of a block.
>   * @param crc CRC of previous blocks if any or initial value for CRC
> + * @param length number of bytes in the given block
>   * @return CRC updated with the data from the given block
>   *
>   * @see av_crc_init() "le" parameter
> @@ -93,6 +94,17 @@ const AVCRC *av_crc_get_table(AVCRCId crc_id);
>  uint32_t av_crc(const AVCRC *ctx, uint32_t crc,
>  const uint8_t *buffer, size_t length) av_pure;
>
> +/**
> + * Calculate the CRC of a block with bits boundary.
> + * @param crc CRC of previous blocks if any or initial value for CRC
> + * @param length number of bits in the given block
> + * @return CRC updated with the data from the given block
> + *
> + * @see av_crc_init() "le" parameter
> + */
> +uint32_t av_crc_bits(const AVCRC *ctx, uint32_t crc,
> + const uint8_t *buffer, size_t length) av_pure;
> +
>  /**
>   * @}
>   */
> --
> 2.15.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Sorry, I didn't see that sbc does fucked up crc on 7 bits.
In that case could you submit a new version of just the sbc patch which
adds this back in the decoder?
If you can point out another CRC, even a non-multimedia one, which does
calculations on a non-byte aligned (but continuous, without skipping bits)
buffer I'd accept this patch though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification

2017-12-21 Thread Karthick J
From: Karthick Jeyapal 

The HLS specification states the following about EXT-X-TARGETDURATION

4.3.3.1.  EXT-X-TARGETDURATION

   The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
   duration.  The EXTINF duration of each Media Segment in the Playlist
   file, when rounded to the nearest integer, MUST be less than or equal
   to the target duration; longer segments can trigger playback stalls
   or other errors.  It applies to the entire Playlist file.  Its format
   is:

   #EXT-X-TARGETDURATION:

   where s is a decimal-integer indicating the target duration in
   seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.

Currently the dashenc rounds the duration to the next integer,
rather than rounding the duration to the nearest integer.
---
 libavformat/dashenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5687530..5368a23 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 Segment *seg = os->segments[i];
 double duration = (double) seg->duration / timescale;
 if (target_duration <= duration)
-target_duration = hls_get_int_from_double(duration);
+target_duration = lrint(duration);
 }
 
 ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH 1/2] v4l_m2m: add missing AV_CODEC_CAP_DELAY flags

2017-12-21 Thread Jorge Ramirez

On 12/21/2017 09:54 AM, wm4 wrote:

On Fri, 15 Dec 2017 12:46:10 +0100
Jorge Ramirez  wrote:


On 12/14/2017 07:54 PM, Jorge Ramirez wrote:

On 12/14/2017 07:48 PM, wm4 wrote:

This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially could lead to issues
like missing frames at the end of a stream.
---
Untested.

ok you can add tested-by me if needed.
is all ok.

thanks!

Just checking: so I can apply the patch without further modifications?


yes


___
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 1/2] v4l_m2m: add missing AV_CODEC_CAP_DELAY flags

2017-12-21 Thread wm4
On Fri, 15 Dec 2017 12:46:10 +0100
Jorge Ramirez  wrote:

> On 12/14/2017 07:54 PM, Jorge Ramirez wrote:
> > On 12/14/2017 07:48 PM, wm4 wrote:  
> >> This is pretty much a requirement for any codec that handles modern
> >> codecs like h264, but it was missing. Potentially could lead to issues
> >> like missing frames at the end of a stream.
> >> ---
> >> Untested.  
> 
> ok you can add tested-by me if needed.
> is all ok.
> 
> thanks!

Just checking: so I can apply the patch without further modifications?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel