Re: [FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations

[Matt Oliver]

On Fri, 28 Jul 2023 at 20:55, Nicolas George  wrote:

> Reimar Döffinger (12023-07-28):
> > I assume the issue is missing symbols during linking?
> > If you really want this, why not create a file that provides dummy
> > symbols for all that are missing, concentrating the #if mess in
> > a single place and avoiding affecting any of the regular code, and thus
> > having no impact at all when compiling with optimizations.
> > Yes, it's likely to be a good bit of maintenance effort for those who
> > want to use it, but at least anyone not caring about this feature can
> > ignore it, so at least I would not have a reason to be against it.
>
> This is an interesting idea. It would even be possible to include a tool
> that generate these stubs directly from the linker's errors, reducing
> the maintenance.
>
> Maybe even make the stubs static inline functions rather than actual
> linking symbols.
>

The issue with dead code elimination and msvc has been raised many times
over the years and the general response has been to not support it. The
last discussion was back in 2016 (
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) which
apparently was by me.
There was an attempt previously by someone to try and semi-manually add all
the missing symbols using dummy functions but it obviously didnt go
anywhere as if I remember correctly it was difficult to track them all down
for all possible configuration options and maintaining it was just too hard
and it never got completed. I dont have the link but if you crawl through
old mailing list posts it is in there somewhere.

About a decade ago I went the auto generation route and created a tool that
generated Visual Studio projects by scanning ffmpegs make/configure files
and as part of that the tool creates dummy files with all the missing
symbols for the requested configuration options (
https://github.com/ShiftMediaProject/FFVS-Project-Generator). Its not the
most readable code but it does work. Whats potentially more interesting is
over all the years that project has been used the number of dummy dce stubs
has decreased from what used to be there when some of those early attempts
I mentioned were made. However just checking it now shows that there are
still a good 1000 dummy functions created for avcodec alone, although
admittedly theres only about a dozen for all the other libs. So a
pre-processing tool can work nicely, the trick is to be able to get it to
work with different compilers as the command line options and output format
is slightly different and that only gives you the function name you still
need to then scan the code to work out the correct types for the functions
parameters and return types in order to make a dummy stub.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/Makefile: Dont compile unused files.

[Matt Oliver]

On Sun, 12 Feb 2023 at 04:00, Nicolas George  wrote:

> Hi.
>
> Matt Oliver (12023-01-15):
> >  vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
> > build them.
>
> Hi
>
> This sentence seems to be missing a few words.
>
>
Missed a space in there
" vf_nlmeans and vf_atadenoise dont contain any code on 32bit x86 so dont
build them."


>
> >
> > ---
> >  libavfilter/x86/Makefile | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
> > index e87481bd7a..9a68b9204b 100644
> > --- a/libavfilter/x86/Makefile
> > +++ b/libavfilter/x86/Makefile
> > @@ -44,7 +44,9 @@ X86ASM-OBJS-$(CONFIG_SCENE_SAD)  +=
> > x86/scene_sad.o
> >
> >  X86ASM-OBJS-$(CONFIG_AFIR_FILTER)+= x86/af_afir.o
> >  X86ASM-OBJS-$(CONFIG_ANLMDN_FILTER)  += x86/af_anlmdn.o
>
> > +ifdef ARCH_X86_64
> >  X86ASM-OBJS-$(CONFIG_ATADENOISE_FILTER)  += x86/vf_atadenoise.o
> > +endif
>
> Do you mean the file is useless yet configure set
> CONFIG_ATADENOISE_FILTER? That looks suspicious.
>

These are the assembly files, so yes the file is completely useless if not
compiling for 64bit x86, but CONFIG_ATADENOISE_FILTER is correctly set as
we still want to pull in the standard c files.
Basically inside these files is a chunk of code inside a ARCH_X86_64 idef
so when compiling for a different arch the files end up containing nothing.

So apart from just saving some compilation effort not compiling files that
dont contain any usable code, this also showed up as an issue under certain
circumstances as nasm in win64 would generate output for essentially empty
files like these that breaks the msvc linker. This patch also fixes that.


>
> The same goes for the other place and the other patch.
>
> >  X86ASM-OBJS-$(CONFIG_BLEND_FILTER)   += x86/vf_blend.o
> >  X86ASM-OBJS-$(CONFIG_BWDIF_FILTER)   += x86/vf_bwdif.o
> >  X86ASM-OBJS-$(CONFIG_COLORSPACE_FILTER)  += x86/colorspacedsp.o
> > @@ -62,7 +64,9 @@ X86ASM-OBJS-$(CONFIG_LIMITER_FILTER) +=
> > x86/vf_limiter.o
> >  X86ASM-OBJS-$(CONFIG_LUT3D_FILTER)   += x86/vf_lut3d.o
> >  X86ASM-OBJS-$(CONFIG_MASKEDCLAMP_FILTER) += x86/vf_maskedclamp.o
> >  X86ASM-OBJS-$(CONFIG_MASKEDMERGE_FILTER) += x86/vf_maskedmerge.o
> > +ifdef ARCH_X86_64
> >  X86ASM-OBJS-$(CONFIG_NLMEANS_FILTER) += x86/vf_nlmeans.o
> > +endif
> >  X86ASM-OBJS-$(CONFIG_OVERLAY_FILTER) += x86/vf_overlay.o
> >  X86ASM-OBJS-$(CONFIG_PP7_FILTER) += x86/vf_pp7.o
> >  X86ASM-OBJS-$(CONFIG_PSNR_FILTER)+= x86/vf_psnr.o
>
> Regards,
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/Makefile: Dont compile unused files.

[Matt Oliver]

On Sun, 15 Jan 2023 at 19:08, Matt Oliver  wrote:

> vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
> build them.
>
> ---
>  libavfilter/x86/Makefile | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
> index e87481bd7a..9a68b9204b 100644
> --- a/libavfilter/x86/Makefile
> +++ b/libavfilter/x86/Makefile
> @@ -44,7 +44,9 @@ X86ASM-OBJS-$(CONFIG_SCENE_SAD)  +=
> x86/scene_sad.o
>
>  X86ASM-OBJS-$(CONFIG_AFIR_FILTER)+= x86/af_afir.o
>  X86ASM-OBJS-$(CONFIG_ANLMDN_FILTER)  += x86/af_anlmdn.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_ATADENOISE_FILTER)  += x86/vf_atadenoise.o
> +endif
>  X86ASM-OBJS-$(CONFIG_BLEND_FILTER)   += x86/vf_blend.o
>  X86ASM-OBJS-$(CONFIG_BWDIF_FILTER)   += x86/vf_bwdif.o
>  X86ASM-OBJS-$(CONFIG_COLORSPACE_FILTER)  += x86/colorspacedsp.o
> @@ -62,7 +64,9 @@ X86ASM-OBJS-$(CONFIG_LIMITER_FILTER) +=
> x86/vf_limiter.o
>  X86ASM-OBJS-$(CONFIG_LUT3D_FILTER)   += x86/vf_lut3d.o
>  X86ASM-OBJS-$(CONFIG_MASKEDCLAMP_FILTER) += x86/vf_maskedclamp.o
>  X86ASM-OBJS-$(CONFIG_MASKEDMERGE_FILTER) += x86/vf_maskedmerge.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_NLMEANS_FILTER) += x86/vf_nlmeans.o
> +endif
>  X86ASM-OBJS-$(CONFIG_OVERLAY_FILTER) += x86/vf_overlay.o
>  X86ASM-OBJS-$(CONFIG_PP7_FILTER) += x86/vf_pp7.o
>  X86ASM-OBJS-$(CONFIG_PSNR_FILTER)+= x86/vf_psnr.o
> --
> 2.39.0.windows.2
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/Makefile: Dont compile unused files.

[Matt Oliver]

On Sun, 15 Jan 2023 at 19:09, Matt Oliver  wrote:

> Multiple asm files dont contain any valid code when compiled under 32bit
> x86 so they should be skipped.
>
> ---
>  libavcodec/x86/Makefile | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 118daca333..bafba207ca 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -157,7 +157,9 @@ X86ASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) +=
> x86/g722dsp.o
>  X86ASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
>  X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
>  X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_CFHD_ENCODER) += x86/cfhdencdsp.o
> +endif
>  X86ASM-OBJS-$(CONFIG_CFHD_DECODER) += x86/cfhddsp.o
>  X86ASM-OBJS-$(CONFIG_DCA_DECODER)  += x86/dcadsp.o x86/synth_filter.o
>  X86ASM-OBJS-$(CONFIG_DIRAC_DECODER)+= x86/diracdsp.o\
> @@ -176,16 +178,22 @@ X86ASM-OBJS-$(CONFIG_HEVC_DECODER) +=
> x86/hevc_add_res.o\
>x86/hevc_sao_10bit.o
>  X86ASM-OBJS-$(CONFIG_JPEG2000_DECODER) += x86/jpeg2000dsp.o
>  X86ASM-OBJS-$(CONFIG_LSCR_DECODER) += x86/pngdsp.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_MLP_DECODER)  += x86/mlpdsp.o
> +endif
>  X86ASM-OBJS-$(CONFIG_MPEG4_DECODER)+= x86/xvididct.o
>  X86ASM-OBJS-$(CONFIG_PNG_DECODER)  += x86/pngdsp.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_PRORES_DECODER)   += x86/proresdsp.o
>  X86ASM-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp.o
> +endif
>  X86ASM-OBJS-$(CONFIG_RV40_DECODER) += x86/rv40dsp.o
>  X86ASM-OBJS-$(CONFIG_SBC_ENCODER)  += x86/sbcdsp.o
>  X86ASM-OBJS-$(CONFIG_SVQ1_ENCODER) += x86/svq1enc.o
>  X86ASM-OBJS-$(CONFIG_TAK_DECODER)  += x86/takdsp.o
> +ifdef ARCH_X86_64
>  X86ASM-OBJS-$(CONFIG_TRUEHD_DECODER)   += x86/mlpdsp.o
> +endif
>  X86ASM-OBJS-$(CONFIG_TTA_DECODER)  += x86/ttadsp.o
>  X86ASM-OBJS-$(CONFIG_TTA_ENCODER)  += x86/ttaencdsp.o
>  X86ASM-OBJS-$(CONFIG_UTVIDEO_DECODER)  += x86/utvideodsp.o
> --
> 2.39.0.windows.2
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avcodec/Makefile: Dont compile unused files.

[Matt Oliver]

Multiple asm files dont contain any valid code when compiled under 32bit
x86 so they should be skipped.

---
 libavcodec/x86/Makefile | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 118daca333..bafba207ca 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -157,7 +157,9 @@ X86ASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) +=
x86/g722dsp.o
 X86ASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
 X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
 X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_CFHD_ENCODER) += x86/cfhdencdsp.o
+endif
 X86ASM-OBJS-$(CONFIG_CFHD_DECODER) += x86/cfhddsp.o
 X86ASM-OBJS-$(CONFIG_DCA_DECODER)  += x86/dcadsp.o x86/synth_filter.o
 X86ASM-OBJS-$(CONFIG_DIRAC_DECODER)+= x86/diracdsp.o\
@@ -176,16 +178,22 @@ X86ASM-OBJS-$(CONFIG_HEVC_DECODER) +=
x86/hevc_add_res.o\
   x86/hevc_sao_10bit.o
 X86ASM-OBJS-$(CONFIG_JPEG2000_DECODER) += x86/jpeg2000dsp.o
 X86ASM-OBJS-$(CONFIG_LSCR_DECODER) += x86/pngdsp.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_MLP_DECODER)  += x86/mlpdsp.o
+endif
 X86ASM-OBJS-$(CONFIG_MPEG4_DECODER)+= x86/xvididct.o
 X86ASM-OBJS-$(CONFIG_PNG_DECODER)  += x86/pngdsp.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_PRORES_DECODER)   += x86/proresdsp.o
 X86ASM-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp.o
+endif
 X86ASM-OBJS-$(CONFIG_RV40_DECODER) += x86/rv40dsp.o
 X86ASM-OBJS-$(CONFIG_SBC_ENCODER)  += x86/sbcdsp.o
 X86ASM-OBJS-$(CONFIG_SVQ1_ENCODER) += x86/svq1enc.o
 X86ASM-OBJS-$(CONFIG_TAK_DECODER)  += x86/takdsp.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_TRUEHD_DECODER)   += x86/mlpdsp.o
+endif
 X86ASM-OBJS-$(CONFIG_TTA_DECODER)  += x86/ttadsp.o
 X86ASM-OBJS-$(CONFIG_TTA_ENCODER)  += x86/ttaencdsp.o
 X86ASM-OBJS-$(CONFIG_UTVIDEO_DECODER)  += x86/utvideodsp.o
-- 
2.39.0.windows.2


0002-avcodec-Makefile-Dont-compile-unused-files.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] lavfi/Makefile: Dont compile unused files.

[Matt Oliver]

 vf_nlmeans and vf_atadenoisedont contain any code on 32bit x86 so dont
build them.

---
 libavfilter/x86/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
index e87481bd7a..9a68b9204b 100644
--- a/libavfilter/x86/Makefile
+++ b/libavfilter/x86/Makefile
@@ -44,7 +44,9 @@ X86ASM-OBJS-$(CONFIG_SCENE_SAD)  +=
x86/scene_sad.o

 X86ASM-OBJS-$(CONFIG_AFIR_FILTER)+= x86/af_afir.o
 X86ASM-OBJS-$(CONFIG_ANLMDN_FILTER)  += x86/af_anlmdn.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_ATADENOISE_FILTER)  += x86/vf_atadenoise.o
+endif
 X86ASM-OBJS-$(CONFIG_BLEND_FILTER)   += x86/vf_blend.o
 X86ASM-OBJS-$(CONFIG_BWDIF_FILTER)   += x86/vf_bwdif.o
 X86ASM-OBJS-$(CONFIG_COLORSPACE_FILTER)  += x86/colorspacedsp.o
@@ -62,7 +64,9 @@ X86ASM-OBJS-$(CONFIG_LIMITER_FILTER) +=
x86/vf_limiter.o
 X86ASM-OBJS-$(CONFIG_LUT3D_FILTER)   += x86/vf_lut3d.o
 X86ASM-OBJS-$(CONFIG_MASKEDCLAMP_FILTER) += x86/vf_maskedclamp.o
 X86ASM-OBJS-$(CONFIG_MASKEDMERGE_FILTER) += x86/vf_maskedmerge.o
+ifdef ARCH_X86_64
 X86ASM-OBJS-$(CONFIG_NLMEANS_FILTER) += x86/vf_nlmeans.o
+endif
 X86ASM-OBJS-$(CONFIG_OVERLAY_FILTER) += x86/vf_overlay.o
 X86ASM-OBJS-$(CONFIG_PP7_FILTER) += x86/vf_pp7.o
 X86ASM-OBJS-$(CONFIG_PSNR_FILTER)+= x86/vf_psnr.o
-- 
2.39.0.windows.2


0001-lavfi-Makefile-Dont-compile-unused-file.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v7] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The min version requirement of 158 is applied for msvc builds only.

This is also removing the check for 'libx264 without pkg-config'
which was left for compatibility reasons about 7 years ago when
the pkg-config check was introduced by commit
e06263ef1e0e172b2c76070b3dc739411af08e82.

Co-authored-by: softworkz 
Signed-off-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.

v2: restrict the version requirement to msvc builds
v3: fix unintended author change
v4: add missing braces
v5: fixed condition (again ;-)
v6: hope I got it now..
v7: add comment about dropping non-pkg-conf check, re-add libx262 check

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v7
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v7
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

Range-diff vs v6:

 1:  47843fb51e ! 1:  3baec48834 libx264: Set min build version to 158
 @@ Commit message
  So this patch updates configure to require a newer x264 build that
  correctly sets the imports flag.
  
 -The requirement for 158 is applied for msvc builds only,
 -no change is made for all other cases.
 +The min version requirement of 158 is applied for msvc builds only.
 +
 +This is also removing the check for 'libx264 without pkg-config'
 +which was left for compatibility reasons about 7 years ago when
 +the pkg-config check was introduced by commit
 +e06263ef1e0e172b2c76070b3dc739411af08e82.
  
  Co-authored-by: softworkz 
  Signed-off-by: softworkz 
 @@ configure: enabled libvpx&& {
  -   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
  - warn "using libx264 without 
pkg-config"; } } &&
  - require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" &&
 -- check_cpp_condition libx262 x264.h 
"X264_MPEG2"
  +enabled libx264   && check_pkg_config libx264 x264 "stdint.h 
x264.h" x264_encoder_encode &&
  + require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" && {
  + [ "$toolchain" != "msvc" ] ||
 -+ require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158"; }
 ++ require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158"; } &&
 +  check_cpp_condition libx262 x264.h 
"X264_MPEG2"
   enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
require_cpp_condition libx265 x265.h 
"X265_BUILD >= 70"
 - enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
  
   ## libavcodec/libx264.c ##
  @@


 configure| 8 
 libavcodec/libx264.c | 4 
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index 5a167613a4..3dca1c4bd3 100755
--- a/configure
+++ b/configure
@@ -6658,10 +6658,10 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn &qu

[FFmpeg-devel] [PATCH v6] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz 
Signed-off-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.

v2: restrict the version requirement to msvc builds
v3: fix unintended author change
v4: add missing braces
v5: fixed condition (again ;-)
v6: hope I got it now..

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v6
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v6
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

Range-diff vs v5:

 1:  8c4fe7ffc2 ! 1:  47843fb51e libx264: Set min build version to 158
 @@ configure: enabled libvpx&& {
  - check_cpp_condition libx262 x264.h 
"X264_MPEG2"
  +enabled libx264   && check_pkg_config libx264 x264 "stdint.h 
x264.h" x264_encoder_encode &&
  + require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" && {
 -+ "$toolchain" != msvc || 
require_cpp_condition libx264 x264.h "X264_BUILD >= 158"; }
 ++ [ "$toolchain" != "msvc" ] ||
 ++ require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158"; }
   enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
require_cpp_condition libx265 x265.h 
"X265_BUILD >= 70"
   enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"


 configure| 9 -
 libavcodec/libx264.c | 4 
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f115b21064..d17361f37f 100755
--- a/configure
+++ b/configure
@@ -6656,11 +6656,10 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } } 
&&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" &&
- check_cpp_condition libx262 x264.h "X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" && {
+ [ "$toolchain" != "msvc" ] ||
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 158"; }
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4ce3791ae8..14177b3016 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -37,10 +37,6 @@
 #include "atsc_a53.h"
 #include "sei.h"
 
-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 

base-commit: b033913d1c5998a29dfd13e9906dd707ff6eff12
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v5] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz 
Signed-off-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.

v2: restrict the version requirement to msvc builds
v3: fix unintended author change
v4: add missing braces
v5: fixed condition (again ;-)

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v5
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v5
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

Range-diff vs v4:

 1:  0d1bee35b0 ! 1:  8c4fe7ffc2 libx264: Set min build version to 158
 @@ configure: enabled libvpx&& {
  - require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" &&
  - check_cpp_condition libx262 x264.h 
"X264_MPEG2"
  +enabled libx264   && check_pkg_config libx264 x264 "stdint.h 
x264.h" x264_encoder_encode &&
 -+ { require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158" ||
 -+ { "$toolchain" != msvc && 
require_cpp_condition libx264 x264.h "X264_BUILD >= 118"; }; }
 ++ require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" && {
 ++ "$toolchain" != msvc || 
require_cpp_condition libx264 x264.h "X264_BUILD >= 158"; }
   enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
require_cpp_condition libx265 x265.h 
"X265_BUILD >= 70"
   enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"


 configure| 8 +++-
 libavcodec/libx264.c | 4 
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f115b21064..e46d362b04 100755
--- a/configure
+++ b/configure
@@ -6656,11 +6656,9 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } } 
&&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" &&
- check_cpp_condition libx262 x264.h "X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" && {
+ "$toolchain" != msvc || require_cpp_condition 
libx264 x264.h "X264_BUILD >= 158"; }
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4ce3791ae8..14177b3016 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -37,10 +37,6 @@
 #include "atsc_a53.h"
 #include "sei.h"
 
-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 

base-commit: b033913d1c5998a29dfd13e9906dd707ff6eff12
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz 
Signed-off-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.

v2: restrict the version requirement to msvc builds
v3: fix unintended author change
v4: add missing braces

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v4
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v4
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

Range-diff vs v3:

 1:  374130a09e ! 1:  0d1bee35b0 libx264: Set min build version to 158
 @@ configure: enabled libvpx&& {
  - require_cpp_condition libx264 x264.h 
"X264_BUILD >= 118" &&
  - check_cpp_condition libx262 x264.h 
"X264_MPEG2"
  +enabled libx264   && check_pkg_config libx264 x264 "stdint.h 
x264.h" x264_encoder_encode &&
 -+ require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158" ||
 -+ { "$toolchain" != msvc && 
require_cpp_condition libx264 x264.h "X264_BUILD >= 118"; }
 ++ { require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158" ||
 ++ { "$toolchain" != msvc && 
require_cpp_condition libx264 x264.h "X264_BUILD >= 118"; }; }
   enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
require_cpp_condition libx265 x265.h 
"X265_BUILD >= 70"
   enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"


 configure| 8 +++-
 libavcodec/libx264.c | 4 
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f115b21064..129473c75c 100755
--- a/configure
+++ b/configure
@@ -6656,11 +6656,9 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } } 
&&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" &&
- check_cpp_condition libx262 x264.h "X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
+ { require_cpp_condition libx264 x264.h 
"X264_BUILD >= 158" ||
+ { "$toolchain" != msvc && require_cpp_condition 
libx264 x264.h "X264_BUILD >= 118"; }; }
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4ce3791ae8..14177b3016 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -37,10 +37,6 @@
 #include "atsc_a53.h"
 #include "sei.h"
 
-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 

base-commit: b033913d1c5998a29dfd13e9906dd707ff6eff12
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

The requirement for 158 is applied for msvc builds only,
no change is made for all other cases.

Co-authored-by: softworkz 
Signed-off-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.

v2: restrict the version requirement to msvc builds
v3: fix unintended author change

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v3
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v3
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

Range-diff vs v2:

 1:  1696684de3 ! 1:  374130a09e libx264: Set min build version to 158
 @@
   ## Metadata ##
 -Author: softworkz 
 +Author: Matt Oliver 
  
   ## Commit message ##
  libx264: Set min build version to 158


 configure| 8 +++-
 libavcodec/libx264.c | 4 
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f115b21064..9de9b7763a 100755
--- a/configure
+++ b/configure
@@ -6656,11 +6656,9 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } } 
&&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" &&
- check_cpp_condition libx262 x264.h "X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 158" ||
+ { "$toolchain" != msvc && require_cpp_condition 
libx264 x264.h "X264_BUILD >= 118"; }
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4ce3791ae8..14177b3016 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -37,10 +37,6 @@
 #include "atsc_a53.h"
 #include "sei.h"
 
-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 

base-commit: b033913d1c5998a29dfd13e9906dd707ff6eff12
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libx264: Set min build version to 158

[Matt Oliver]

From: Matt Oliver 

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.

Alternatively we can detect the x264 build version in configure
and keep the fallback of manually setting the flag on older x264
builds that arent using pkgconfig (to keep the old behaviour) but
that requires some complex configure changes.

Submitted-by: softworkz 
Signed-off-by: Matt Oliver 
---
libx264: Set min build version to 158

I'm submitting this patch on behalf of Matt with his permission.

There seemed to be agreement that the 158 version limit should be
applied to MSVC builds only. For the latter I'd need some help, because
I can't test this and I'm not familiar enough with the configure script
logic to make a change with sufficient confidence.

Thanks, softworkz

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30

 configure| 7 ++-
 libavcodec/libx264.c | 4 
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f115b21064..d977a97397 100755
--- a/configure
+++ b/configure
@@ -6656,11 +6656,8 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h" 
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } } 
&&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 118" &&
- check_cpp_condition libx262 x264.h "X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 158"
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 4ce3791ae8..14177b3016 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -37,10 +37,6 @@
 #include "atsc_a53.h"
 #include "sei.h"
 
-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 

base-commit: 41a558fea06cc0a23b8d2d0dfb03ef6a25cf5100
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libx264: Set min build version to 158

[Matt Oliver]

On Wed, 29 Dec 2021 at 23:37, Michael Niedermayer 
wrote:

> On Wed, Dec 29, 2021 at 05:16:25PM +1100, Matt Oliver wrote:
> > Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
> >
> > Setting X264_API_IMPORTS only affects msvc builds and it breaks linking
> to
> > static builds (although is required for shared builds). This flag is set
> by
> > x264 in its pkgconfig as required since build 158
> > (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019. So this patch
> > updates configure to require a newer x264 build that correctly sets the
> > imports flag.
> >
> > Alternatively we can detect the x264 build version in configure and keep
> > the fallback of manually setting the flag on older x264 builds that arent
> > using pkgconfig (to keep the old behaviour) but that requires some
> complex
> > configure changes.
> >
> > Signed-off-by: Matt Oliver 
> > ---
> >  configure| 8 +++-
> >  libavcodec/libx264.c | 4 
> >  2 files changed, 3 insertions(+), 9 deletions(-)
>
> I think this would effectivly drop ubuntu LTS support which seem to
> ship older versions
>
> thx
>

As I mentioned in the patch comments, if dropping pre 158 is not suitable
then some changes to configure could be made to fallback to old behaviour
but I'm not familiar enough with configure to do it. The configure check
would then need to be updated to do a pkg_config check if build 158 or
newer and if not then fallback to setting X264_API_IMPORTS on the command
line. This fallback still wouldnt allow static linking with msvc but that
is the current behaviour so it's not changing anything there. So some help
on what the correct configure changes should be would be appreciated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libx264: Set min build version to 158

[Matt Oliver]

Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"

Setting X264_API_IMPORTS only affects msvc builds and it breaks linking to
static builds (although is required for shared builds). This flag is set by
x264 in its pkgconfig as required since build 158
(a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019. So this patch
updates configure to require a newer x264 build that correctly sets the
imports flag.

Alternatively we can detect the x264 build version in configure and keep
the fallback of manually setting the flag on older x264 builds that arent
using pkgconfig (to keep the old behaviour) but that requires some complex
configure changes.

Signed-off-by: Matt Oliver 
---
 configure| 8 +++-
 libavcodec/libx264.c | 4 
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index ede8f9777b..b35728aace 100755
--- a/configure
+++ b/configure
@@ -6535,11 +6535,8 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >=
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h
x264.h" x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h"
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config";
} } &&
- require_cpp_condition libx264 x264.h
"X264_BUILD >= 118" &&
- check_cpp_condition libx262 x264.h
"X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h
x264.h" x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h
"X264_BUILD >= 158"
 enabled libx265   && require_pkg_config libx265 x265 x265.h
x265_api_get &&
  require_cpp_condition libx265 x265.h
"X265_BUILD >= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 21f434d06d..efbc9608c7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -34,10 +34,6 @@
 #include "atsc_a53.h"
 #include "sei.h"

-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 
--


0001-libx264-Do-not-explicitly-set-X264_API_IMPORTS.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libx264: Do not explicitly set X264_API_IMPORTS

[Matt Oliver]

On Sat, 30 Oct 2021 at 14:16, Matt Oliver  wrote:

> Setting X264_API_IMPORTS only affects msvc builds and it breaks linking to
> static builds (although is required for shared builds). This flag is set by
> x264 in its pkgconfig as required since build 158
> (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019. So this patch
> updates configure to require a newer x264 build that correctly sets the
> imports flag.
>
> Alternatively we can detect the x264 build version in configure and keep
> the fallback of manually setting the flag on older x264 builds that aren't
> using pkgconfig (to keep the old behaviour) but that requires some complex
> configure changes that I'm not sure how best to do (assistance welcome).
>
> Signed-off-by: Matt Oliver 
> ---
>  configure| 8 +++-
>  libavcodec/libx264.c | 4 
>  2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/configure b/configure
> index ede8f9777b..b35728aace 100755
> --- a/configure
> +++ b/configure
> @@ -6535,11 +6535,9 @@ enabled libvpx&& {
>  enabled libwebp   && {
>  enabled libwebp_encoder  && require_pkg_config libwebp "libwebp
> >= 0.2.0" webp/encode.h WebPGetEncoderVersion
>  enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder
> "libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
> -enabled libx264   && { check_pkg_config libx264 x264 "stdint.h
> x264.h" x264_encoder_encode ||
> -   { require libx264 "stdint.h x264.h"
> x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
> - warn "using libx264 without pkg-config";
> } } &&
> - require_cpp_condition libx264 x264.h
> "X264_BUILD >= 118" &&
> - check_cpp_condition libx262 x264.h
> "X264_MPEG2"
> +enabled libx264   && check_pkg_config libx264 x264 "stdint.h
> x264.h" x264_encoder_encode &&
> + require_cpp_condition libx264 x264.h
> "X264_BUILD >= 158" &&
> + check_cpp_condition libx264 x264.h
> "X264_MPEG2"
>  enabled libx265   && require_pkg_config libx265 x265 x265.h
> x265_api_get &&
>   require_cpp_condition libx265 x265.h
> "X265_BUILD >= 70"
>  enabled libxavs   && require libxavs "stdint.h xavs.h"
> xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 21f434d06d..efbc9608c7 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -34,10 +34,6 @@
>  #include "atsc_a53.h"
>  #include "sei.h"
>
> -#if defined(_MSC_VER)
> -#define X264_API_IMPORTS 1
> -#endif
> -
>  #include 
>  #include 
>  #include 
> --
>

Ping for review. I'm pretty sure the change here to requiring x264 build
158 or newer might be an issue for some (although I could be wrong)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libvpxdec: Correct linking against variables.

[Matt Oliver]

On Thu, 4 Nov 2021 at 15:44, Matt Oliver  wrote:

> Instead link against the function that returns the correct variable. This
> fixes linking errors with dlls with msvc.
> ---
>  libavcodec/libvpxdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 42d1b8ab1c..b2aa205036 100644
> --- a/libavcodec/libvpxdec.c
> +++ b/libavcodec/libvpxdec.c
> @@ -242,11 +242,11 @@ static int vpx_decode(AVCodecContext *avctx,
> >decoder_alpha,
>  #if CONFIG_LIBVPX_VP8_DECODER && CONFIG_LIBVPX_VP9_DECODER
> (avctx->codec_id == AV_CODEC_ID_VP8) ?
> -   _codec_vp8_dx_algo :
> _codec_vp9_dx_algo
> +   vpx_codec_vp8_dx() : vpx_codec_vp9_dx()
>  #elif CONFIG_LIBVPX_VP8_DECODER
> -   _codec_vp8_dx_algo
> +   vpx_codec_vp8_dx()
>  #else
> -   _codec_vp9_dx_algo
> +   vpx_codec_vp9_dx()
>  #endif
> );
>  if (ret)
> @@ -350,7 +350,7 @@ static av_cold int vpx_free(AVCodecContext *avctx)
>  static av_cold int vp8_init(AVCodecContext *avctx)
>  {
>  VPxContext *ctx = avctx->priv_data;
> -return vpx_init(avctx, >decoder, _codec_vp8_dx_algo);
> +return vpx_init(avctx, >decoder, vpx_codec_vp8_dx());
>  }
>
>  const AVCodec ff_libvpx_vp8_decoder = {
> @@ -372,7 +372,7 @@ const AVCodec ff_libvpx_vp8_decoder = {
>  static av_cold int vp9_init(AVCodecContext *avctx)
>  {
>  VPxContext *ctx = avctx->priv_data;
> -return vpx_init(avctx, >decoder, _codec_vp9_dx_algo);
> +return vpx_init(avctx, >decoder, vpx_codec_vp9_dx());
>  }
>
>  AVCodec ff_libvpx_vp9_decoder = {
> --
>

If no one has any objections I'll push this soon.
I already got an OK from another thread with similar changes to libaom so
I'll assume that this one is good too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libvpxdec: Correct linking against variables.

[Matt Oliver]

Instead link against the function that returns the correct variable. This
fixes linking errors with dlls with msvc.
---
 libavcodec/libvpxdec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index 42d1b8ab1c..b2aa205036 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -242,11 +242,11 @@ static int vpx_decode(AVCodecContext *avctx,
>decoder_alpha,
 #if CONFIG_LIBVPX_VP8_DECODER && CONFIG_LIBVPX_VP9_DECODER
(avctx->codec_id == AV_CODEC_ID_VP8) ?
-   _codec_vp8_dx_algo :
_codec_vp9_dx_algo
+   vpx_codec_vp8_dx() : vpx_codec_vp9_dx()
 #elif CONFIG_LIBVPX_VP8_DECODER
-   _codec_vp8_dx_algo
+   vpx_codec_vp8_dx()
 #else
-   _codec_vp9_dx_algo
+   vpx_codec_vp9_dx()
 #endif
);
 if (ret)
@@ -350,7 +350,7 @@ static av_cold int vpx_free(AVCodecContext *avctx)
 static av_cold int vp8_init(AVCodecContext *avctx)
 {
 VPxContext *ctx = avctx->priv_data;
-return vpx_init(avctx, >decoder, _codec_vp8_dx_algo);
+return vpx_init(avctx, >decoder, vpx_codec_vp8_dx());
 }

 const AVCodec ff_libvpx_vp8_decoder = {
@@ -372,7 +372,7 @@ const AVCodec ff_libvpx_vp8_decoder = {
 static av_cold int vp9_init(AVCodecContext *avctx)
 {
 VPxContext *ctx = avctx->priv_data;
-return vpx_init(avctx, >decoder, _codec_vp9_dx_algo);
+return vpx_init(avctx, >decoder, vpx_codec_vp9_dx());
 }

 AVCodec ff_libvpx_vp9_decoder = {
--


0001-libvpxdec-Correct-linking-against-variables.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[Matt Oliver]

On Tue, 2 Nov 2021 at 04:41, James Zern 
wrote:

> On Fri, Oct 29, 2021 at 8:51 PM Matt Oliver  wrote:
> >
> > On Sat, 30 Oct 2021 at 14:13, Matt Oliver  wrote:
> >
> > > Does this compile and link with libaom 1.0.0? We unfortunately still
> > >> support that version (despite being unusable speed wise) because
> distros
> > >> like Debian still ship it.
> > >>
> > >
> > > Just looked it up and yes version 1.0.0 includes the required
> > > aom_codec_av1_dx() function (line 37 of aomdx.h for those interested).
> > >
> >
> > I also noticed that libvpx does the same thing as libaom where it uses
> the
> > direct variable instead of the function returning the variable. libvpx
> > doesnt currently support static compilation so it's not an issue that has
> > come up but was wondering whether it was worth submitting a patch
> > preemptively fixing that issue as well.
> >
>
> That would be fine. By static compilation do you mean generating an
> import lib for this scenario?
>

That was actually a typo, I meant libvpx doesnt support 'shared'
compilation on windows (the configure script only allows it to be specified
on ELF platforms). I'm not familiar with why libvpx doesnt currently allow
it but if it did then ffmpeg would have the same issues as with libaom that
was fixed with this patch. Which is why I was wondering if people were fine
with me preemptively fixing it by patching ffmpeg now instead of waiting
for it to be a potential issue down the line.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[Matt Oliver]

On Sat, 30 Oct 2021 at 14:13, Matt Oliver  wrote:

> Does this compile and link with libaom 1.0.0? We unfortunately still
>> support that version (despite being unusable speed wise) because distros
>> like Debian still ship it.
>>
>
> Just looked it up and yes version 1.0.0 includes the required
> aom_codec_av1_dx() function (line 37 of aomdx.h for those interested).
>

I also noticed that libvpx does the same thing as libaom where it uses the
direct variable instead of the function returning the variable. libvpx
doesnt currently support static compilation so it's not an issue that has
come up but was wondering whether it was worth submitting a patch
preemptively fixing that issue as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libx264: Do not explicitly set X264_API_IMPORTS

[Matt Oliver]

Setting X264_API_IMPORTS only affects msvc builds and it breaks linking to
static builds (although is required for shared builds). This flag is set by
x264 in its pkgconfig as required since build 158
(a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019. So this patch
updates configure to require a newer x264 build that correctly sets the
imports flag.

Alternatively we can detect the x264 build version in configure and keep
the fallback of manually setting the flag on older x264 builds that aren't
using pkgconfig (to keep the old behaviour) but that requires some complex
configure changes that I'm not sure how best to do (assistance welcome).

Signed-off-by: Matt Oliver 
---
 configure| 8 +++-
 libavcodec/libx264.c | 4 
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index ede8f9777b..b35728aace 100755
--- a/configure
+++ b/configure
@@ -6535,11 +6535,9 @@ enabled libvpx&& {
 enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >=
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264   && { check_pkg_config libx264 x264 "stdint.h
x264.h" x264_encoder_encode ||
-   { require libx264 "stdint.h x264.h"
x264_encoder_encode "-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config";
} } &&
- require_cpp_condition libx264 x264.h
"X264_BUILD >= 118" &&
- check_cpp_condition libx262 x264.h
"X264_MPEG2"
+enabled libx264   && check_pkg_config libx264 x264 "stdint.h
x264.h" x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h
"X264_BUILD >= 158" &&
+ check_cpp_condition libx264 x264.h
"X264_MPEG2"
 enabled libx265   && require_pkg_config libx265 x265 x265.h
x265_api_get &&
  require_cpp_condition libx265 x265.h
"X265_BUILD >= 70"
 enabled libxavs   && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 21f434d06d..efbc9608c7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -34,10 +34,6 @@
 #include "atsc_a53.h"
 #include "sei.h"

-#if defined(_MSC_VER)
-#define X264_API_IMPORTS 1
-#endif
-
 #include 
 #include 
 #include 
--


0001-libx264-Do-not-explicitly-set-X264_API_IMPORTS.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[Matt Oliver]

>
> Does this compile and link with libaom 1.0.0? We unfortunately still
> support that version (despite being unusable speed wise) because distros
> like Debian still ship it.
>

Just looked it up and yes version 1.0.0 includes the required
aom_codec_av1_dx() function (line 37 of aomdx.h for those interested).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[Matt Oliver]

>
> lgtm.
>

Thanks,
I will push this assuming no other comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libaom: Dont use aom_codec_av1_dx_algo.

[Matt Oliver]

This fixes linking errors where variables cannot be correctly linked in
from an external shared library such as with msvc (requires dllimport which
is not used by libaom). Instead just call the function that returns the
same variable.
---
 libavcodec/libaomdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 75ecc08970..d6b822fda2 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -241,7 +241,7 @@ static av_cold int aom_free(AVCodecContext *avctx)

 static av_cold int av1_init(AVCodecContext *avctx)
 {
-return aom_init(avctx, _codec_av1_dx_algo);
+return aom_init(avctx, aom_codec_av1_dx());
 }

 const AVCodec ff_libaom_av1_decoder = {
-- 
2.33.1.windows.1


0001-libaom-Dont-use-aom_codec_av1_dx_algo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] cuda_runtime.h: Correct ushort4 to use ushort.

[Matt Oliver]

---
 compat/cuda/cuda_runtime.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h
index 0bf3de85d3..c5450b2542 100644
--- a/compat/cuda/cuda_runtime.h
+++ b/compat/cuda/cuda_runtime.h
@@ -73,7 +73,7 @@ typedef struct __device_builtin__ __align__(4) uchar4

 typedef struct __device_builtin__ __align__(8) ushort4
 {
-unsigned char x, y, z, w;
+unsigned short x, y, z, w;
 } ushort4;

 typedef struct __device_builtin__ __align__(16) int4
-- 
2.30.0.windows.2


0001-cuda_runtime.h-Correct-ushort4-to-use-ushort.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] configure: Use no-narrowing for cuda_llvm compilation.

[Matt Oliver]

This fixes llvm compiler generating errors about narrowing conversion with
recent releases.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index df298b4b9b..e716f6f932 100755
--- a/configure
+++ b/configure
@@ -6242,7 +6242,7 @@ fi
 if enabled cuda_nvcc; then
 nvccflags="$nvccflags -ptx"
 else
-nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
-include ${source_link}/compat/cuda/cuda_runtime.h"
+nvccflags="$nvccflags -S -nocudalib -nocudainc --cuda-device-only
-Wno-c++11-narrowing -include ${source_link}/compat/cuda/cuda_runtime.h"
 check_nvcc cuda_llvm
 fi

-- 
2.30.0.windows.2


0002-configure-Use-no-narrowing-for-cuda_llvm-compilation.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_d3d11va: Use secure dlopen.

[Matt Oliver]

final ping. If no objections still ill apply this later.

On Sun, 12 Jan 2020 at 06:50, Matt Oliver  wrote:

> On Tue, 31 Dec 2019 at 03:37, Andriy Gelman 
> wrote:
>
>> On Mon, 30. Dec 11:31, Andriy Gelman wrote:
>> > On Tue, 31. Dec 03:02, Matt Oliver wrote:
>> > > dlopen contains additional security to prevent dll hijacking compared
>> to
>> > > standard LoadLibrary.
>> > > ---
>> > >  libavutil/hwcontext_d3d11va.c | 5 +++--
>> > >  1 file changed, 3 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/libavutil/hwcontext_d3d11va.c
>> b/libavutil/hwcontext_d3d11va.c
>> > > index 6670c47579..c8ae58f908 100644
>> > > --- a/libavutil/hwcontext_d3d11va.c
>> > > +++ b/libavutil/hwcontext_d3d11va.c
>> > > @@ -39,6 +39,7 @@
>> > >  #include "pixdesc.h"
>> > >  #include "pixfmt.h"
>> > >  #include "thread.h"
>> > > +#include "compat/w32dlfcn.h"
>> > >
>> > >  typedef HRESULT(WINAPI *PFN_CREATE_DXGI_FACTORY)(REFIID riid, void
>> > > **ppFactory);
>> > >
>> > > @@ -55,8 +56,8 @@ static av_cold void load_functions(void)
>> > >  // from too many LoadLibrary calls.
>> > >  HANDLE d3dlib, dxgilib;
>> > >
>> > > -d3dlib  = LoadLibrary("d3d11.dll");
>> > > -dxgilib = LoadLibrary("dxgi.dll");
>> > > +d3dlib  = dlopen("d3d11.dll", 0);
>> > > +dxgilib = dlopen("dxgi.dll", 0);
>> > >  if (!d3dlib || !dxgilib)
>> > >  return;
>> > >
>> > > --
>> >
>> > Hello Matt,
>> >
>> > This patch doesn't apply:
>> >
>> > error: corrupt patch at line 16
>> > Patch failed at 0001 avutil/hwcontext_d3d11va: Use secure dlopen.
>> >
>> >
>> https://unofficial.patchwork-ffmpeg.org/project/FFmpeg/patch/cahvn4mjopjag+jac9_n_inhjzl2p1_9z3fvhf91pr0lc-dv...@mail.gmail.com/
>> >
>>
>> sorry, my git am failed because the patch was sent as text and an
>> attachment.
>> Applying just one of them works.
>>
>> --
>> Andriy
>>
>
> ping
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/udp: do not use thread cancellation when receiving data

[Matt Oliver]

On Thu, 23 Jan 2020 at 08:12, Marton Balint  wrote:

>
>
> On Wed, 22 Jan 2020, Nicolas George wrote:
>
> > Marton Balint (12020-01-16):
> >> It is not supported by every threading implementation, and the only
> thing we
> >> gain with it is an immediate shutdown of receiving packets on close and
> >> avoiding the poll call before reading the data.
> >>
> >> I don't think it is a big issue if it takes 0.1 sec of delay to close
> an udp
> >> stream. Back when this was introduced the delay was 1 sec, which was
> indeed
> >> noticable.
> >
> > I don't like this. 0.1 s is less noticeable than 1 s for interactive
> > human users, but for applications it may be way too much.
>
> pthread_cancel is not implemented properly on Win32, also it is generally
> not considered a good practice. 0.1 sec delay is still the lesser evil
> than a lockup as shown in ticket #5717.
>
> An alternate approach might be to call shutdown() from the main thread and
> hope that this interrupts the recvfrom() call in the receiver thread. It
> tends to work for linux, I am not sure how other platforms would react,
> what do you think?


I actually had an old patch for that too. On Win32 the shutdown function
will cause any existing recv calls in other threads to instantly return
with an error code. I havnt tested the patch recently with current ffmpeg
master but it should serve as a proof of concept.


avformat-udp-Enable-FIFO-when-using-windows-sockets.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCHv2] avutil/thread: Add pthread_cond_timedwait function

[Matt Oliver]

On Mon, 20 Jan 2020 at 11:14, Marton Balint  wrote:

> From: Matt Oliver 
>
> v2: fix calculating milisecond times and use SleepConditionVariableSRW.
>
> Signed-off-by: Matt Oliver 
> ---
>  compat/os2threads.h  | 25 +
>  compat/w32pthreads.h | 18 ++
>  libavutil/thread.h   |  7 +++
>  3 files changed, 50 insertions(+)
>
> diff --git a/compat/os2threads.h b/compat/os2threads.h
> index 2177a033ec..eec6f40ae7 100644
> --- a/compat/os2threads.h
> +++ b/compat/os2threads.h
> @@ -31,11 +31,14 @@
>
>  #undef __STRICT_ANSI__  /* for _beginthread() */
>  #include 
> +#include 
>
>  #include 
>  #include 
>
>  #include "libavutil/attributes.h"
> +#include "libavutil/common.h"
> +#include "libavutil/time.h"
>
>  typedef struct {
>  TID tid;
> @@ -163,6 +166,28 @@ static av_always_inline int
> pthread_cond_broadcast(pthread_cond_t *cond)
>  return 0;
>  }
>
> +static av_always_inline int pthread_cond_timedwait(pthread_cond_t *cond,
> +   pthread_mutex_t *mutex,
> +   const struct timespec
> *abstime)
> +{
> +int64_t abs_milli = abstime->tv_sec * 1000LL + abstime->tv_nsec /
> 100;
> +ULONG t = av_clip64(abs_milli - av_gettime() / 1000, 0, ULONG_MAX);
> +
> +__atomic_increment(>wait_count);
> +
> +pthread_mutex_unlock(mutex);
> +
> +APIRET ret = DosWaitEventSem(cond->event_sem, t);
> +
> +__atomic_decrement(>wait_count);
> +
> +DosPostEventSem(cond->ack_sem);
> +
> +pthread_mutex_lock(mutex);
> +
> +return (ret == ERROR_TIMEOUT) ? ETIMEDOUT : 0;
> +}
> +
>  static av_always_inline int pthread_cond_wait(pthread_cond_t *cond,
>pthread_mutex_t *mutex)
>  {
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 21acfd2ba1..7df33b7da4 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -38,11 +38,13 @@
>  #define WIN32_LEAN_AND_MEAN
>  #include 
>  #include 
> +#include 
>
>  #include "libavutil/attributes.h"
>  #include "libavutil/common.h"
>  #include "libavutil/internal.h"
>  #include "libavutil/mem.h"
> +#include "libavutil/time.h"
>
>  typedef struct pthread_t {
>  void *handle;
> @@ -156,6 +158,22 @@ static inline int pthread_cond_wait(pthread_cond_t
> *cond, pthread_mutex_t *mutex
>  return 0;
>  }
>
> +static inline int pthread_cond_timedwait(pthread_cond_t *cond,
> pthread_mutex_t *mutex,
> + const struct timespec *abstime)
> +{
> +int64_t abs_milli = abstime->tv_sec * 1000LL + abstime->tv_nsec /
> 100;
> +DWORD t = av_clip64(abs_milli - av_gettime() / 1000, 0, UINT32_MAX);
> +
> +if (!SleepConditionVariableSRW(cond, mutex, t, 0)) {
> +DWORD err = GetLastError();
> +if (err == ERROR_TIMEOUT)
> +return ETIMEDOUT;
> +else
> +return EINVAL;
> +}
> +return 0;
> +}
> +
>  static inline int pthread_cond_signal(pthread_cond_t *cond)
>  {
>  WakeConditionVariable(cond);
> diff --git a/libavutil/thread.h b/libavutil/thread.h
> index cc5272d379..65b97ef303 100644
> --- a/libavutil/thread.h
> +++ b/libavutil/thread.h
> @@ -109,6 +109,12 @@ static inline int
> strict_pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t
>  ASSERT_PTHREAD(pthread_cond_wait, cond, mutex);
>  }
>
> +static inline int strict_pthread_cond_timedwait(pthread_cond_t *cond,
> pthread_mutex_t *mutex,
> +const struct timespec
> *abstime)
> +{
> +ASSERT_PTHREAD(pthread_cond_timedwait, cond, mutex, abstime);
> +}
> +
>  static inline int strict_pthread_once(pthread_once_t *once_control, void
> (*init_routine)(void))
>  {
>  ASSERT_PTHREAD(pthread_once, once_control, init_routine);
> @@ -124,6 +130,7 @@ static inline int strict_pthread_once(pthread_once_t
> *once_control, void (*init_
>  #define pthread_cond_signalstrict_pthread_cond_signal
>  #define pthread_cond_broadcast strict_pthread_cond_broadcast
>  #define pthread_cond_wait  strict_pthread_cond_wait
> +#define pthread_cond_timedwait strict_pthread_cond_timedwait
>  #define pthread_once   strict_pthread_once
>  #endif
>
> --
> 2.16.4
>
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/udp: do not use thread cancellation when receiving data

[Matt Oliver]

On Fri, 17 Jan 2020 at 18:44, Hendrik Leppkes  wrote:

> On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer
>  wrote:
> >
> > On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
> > > It is not supported by every threading implementation, and the only
> thing we
> > > gain with it is an immediate shutdown of receiving packets on close and
> > > avoiding the poll call before reading the data.
> > >
> > > I don't think it is a big issue if it takes 0.1 sec of delay to close
> an udp
> > > stream. Back when this was introduced the delay was 1 sec, which was
> indeed
> > > noticable.
> > >
> > > And anybody who needs performance sensitive UDP should not use the
> fifo buffer
> > > in the first place, because the kernel can buffer the data much more
> > > effectively.
> > >
> > > Signed-off-by: Marton Balint 
> > > ---
> > >  libavformat/udp.c | 57
> +--
> > >  1 file changed, 26 insertions(+), 31 deletions(-)
> >
> > this breaks build on mingw64
> >
> > src/libavformat/udp.c: In function ‘udp_read’:
> > src/libavformat/udp.c:980:17: error: implicit declaration of function
> ‘pthread_cond_timedwait’ [-Werror=implicit-function-declaration]
> >  int err = pthread_cond_timedwait(>cond, >mutex,
> );
> >  ^
>
> We could add that to our own w32 pthread wrapper, unfortunately
> whoever designed pthread_cond_timedwait was on drugs, the absolute
> timespec is just crazy, instead of a delay in
> (milli|micro|nano)seconds, so we'll practically undo the math that
> same function already does to add its timeout to current time. But oh
> well.
>
> - Hendrik


I had an old patch for adding  pthread_cond_timedwait wrapper for win32.
Haven't checked if it still applies but its attached if it is useful.


avutil-thread-Add-pthread_cond_timedwait-function.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_d3d11va: Use secure dlopen.

[Matt Oliver]

On Tue, 31 Dec 2019 at 03:37, Andriy Gelman  wrote:

> On Mon, 30. Dec 11:31, Andriy Gelman wrote:
> > On Tue, 31. Dec 03:02, Matt Oliver wrote:
> > > dlopen contains additional security to prevent dll hijacking compared
> to
> > > standard LoadLibrary.
> > > ---
> > >  libavutil/hwcontext_d3d11va.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavutil/hwcontext_d3d11va.c
> b/libavutil/hwcontext_d3d11va.c
> > > index 6670c47579..c8ae58f908 100644
> > > --- a/libavutil/hwcontext_d3d11va.c
> > > +++ b/libavutil/hwcontext_d3d11va.c
> > > @@ -39,6 +39,7 @@
> > >  #include "pixdesc.h"
> > >  #include "pixfmt.h"
> > >  #include "thread.h"
> > > +#include "compat/w32dlfcn.h"
> > >
> > >  typedef HRESULT(WINAPI *PFN_CREATE_DXGI_FACTORY)(REFIID riid, void
> > > **ppFactory);
> > >
> > > @@ -55,8 +56,8 @@ static av_cold void load_functions(void)
> > >  // from too many LoadLibrary calls.
> > >  HANDLE d3dlib, dxgilib;
> > >
> > > -d3dlib  = LoadLibrary("d3d11.dll");
> > > -dxgilib = LoadLibrary("dxgi.dll");
> > > +d3dlib  = dlopen("d3d11.dll", 0);
> > > +dxgilib = dlopen("dxgi.dll", 0);
> > >  if (!d3dlib || !dxgilib)
> > >  return;
> > >
> > > --
> >
> > Hello Matt,
> >
> > This patch doesn't apply:
> >
> > error: corrupt patch at line 16
> > Patch failed at 0001 avutil/hwcontext_d3d11va: Use secure dlopen.
> >
> >
> https://unofficial.patchwork-ffmpeg.org/project/FFmpeg/patch/cahvn4mjopjag+jac9_n_inhjzl2p1_9z3fvhf91pr0lc-dv...@mail.gmail.com/
> >
>
> sorry, my git am failed because the patch was sent as text and an
> attachment.
> Applying just one of them works.
>
> --
> Andriy
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] compat/avisynth: Fix unicode compilation.

[Matt Oliver]

On Tue, 31 Dec 2019 at 14:16, Stephen Hutchinson  wrote:

> On 12/30/2019 11:11 AM, Matt Oliver wrote:
> > ---
> >   compat/avisynth/avisynth_c.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
> > index 8d17125adc..9ff9321552 100644
> > --- a/compat/avisynth/avisynth_c.h
> > +++ b/compat/avisynth/avisynth_c.h
> > @@ -1096,7 +1096,7 @@ AVSC_INLINE AVS_Library * avs_load_library() {
> > AVS_Library *library = (AVS_Library *)malloc(sizeof(AVS_Library));
> > if (library == NULL)
> >   return NULL;
> > -  library->handle = LoadLibrary("avisynth");
> > +  library->handle = LoadLibraryA("avisynth");
> > if (library->handle == NULL)
> >   goto fail;
> >
> > --
>
> LGTM.  How are you compiling FFmpeg as unicode in order to expose the
> issue, though?
>
>
I was actually just searching for instances of LoadLibrary due to an
separate issue from another patch. Not specifying the 'A' is a common
source of issues ive had in other projects so i thought id preemptively fix
this one. Happens when another external compile pollutes cflags with
UNICODE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] compat/avisynth: Fix unicode compilation.

[Matt Oliver]

---
 compat/avisynth/avisynth_c.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 8d17125adc..9ff9321552 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -1096,7 +1096,7 @@ AVSC_INLINE AVS_Library * avs_load_library() {
   AVS_Library *library = (AVS_Library *)malloc(sizeof(AVS_Library));
   if (library == NULL)
 return NULL;
-  library->handle = LoadLibrary("avisynth");
+  library->handle = LoadLibraryA("avisynth");
   if (library->handle == NULL)
 goto fail;

--


0001-compat-avisynth-Fix-unicode-compilation.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avutil/hwcontext_d3d11va: Use secure dlopen.

[Matt Oliver]

dlopen contains additional security to prevent dll hijacking compared to
standard LoadLibrary.
---
 libavutil/hwcontext_d3d11va.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6670c47579..c8ae58f908 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -39,6 +39,7 @@
 #include "pixdesc.h"
 #include "pixfmt.h"
 #include "thread.h"
+#include "compat/w32dlfcn.h"

 typedef HRESULT(WINAPI *PFN_CREATE_DXGI_FACTORY)(REFIID riid, void
**ppFactory);

@@ -55,8 +56,8 @@ static av_cold void load_functions(void)
 // from too many LoadLibrary calls.
 HANDLE d3dlib, dxgilib;

-d3dlib  = LoadLibrary("d3d11.dll");
-dxgilib = LoadLibrary("dxgi.dll");
+d3dlib  = dlopen("d3d11.dll", 0);
+dxgilib = dlopen("dxgi.dll", 0);
 if (!d3dlib || !dxgilib)
 return;

--


0001-avutil-hwcontext_d3d11va-Use-secure-dlopen.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] ffplay: Fix realloc_texture when input texture is NULL.

[Matt Oliver]

SDL_QueryTexture and SDL_DestroyTexture require that the input texture
pointer be non-null. Debug builds of SDL will correctly check for this
and break program execution. This patch fixes this by checking the
status of the texture pointer.

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 fftools/ffplay.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index bc9ddb8885..dcca9c26d8 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -834,10 +834,11 @@ static int realloc_texture(SDL_Texture **texture,
Uint32 new_format, int new_wid
 {
 Uint32 format;
 int access, w, h;
-if (SDL_QueryTexture(*texture, , , , ) < 0 ||
new_width != w || new_height != h || new_format != format) {
+if (!*texture || SDL_QueryTexture(*texture, , , , )
< 0 || new_width != w || new_height != h || new_format != format) {
 void *pixels;
 int pitch;
-SDL_DestroyTexture(*texture);
+if (*texture)
+SDL_DestroyTexture(*texture);
 if (!(*texture = SDL_CreateTexture(renderer, new_format,
SDL_TEXTUREACCESS_STREAMING, new_width, new_height)))
 return -1;
 if (SDL_SetTextureBlendMode(*texture, blendmode) < 0)
--


ffplay-Fix-realloc_texture-when-input-texture-is-NUL.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: LibreSSL (libtls) support

[Matt Oliver]

On 5 November 2017 at 02:11, Stefan _  wrote:

> Attached patch adds support for LibreSSL. Instead of trying to implement
> support into the existing tls_openssl.c using lots of #ifdefs (which was
> rejected previously(?)) this adds a new TLS backend making use of the
> new libtls library.
>
> Things to note:
>
> - Haven't looked at LibreSSL's license closely, I assume that it has the
> same GPL licensing incompatibility as a derivative of OpenSSL (requires
> --enable-nonfree if --enable-gpl is used)
>

Yes LibreSSl has the same apache license as OpenSSL

- ffrtmpcrypt support is not implemented since the bignum functions are
> not part of libtls itself
>
> - Not sure why anyone would use libtls without pkg-config but supporting
> it probably doesn't hurt
>

pkg-config is generally preferred anyway

I have tested all features (client mode, listen mode, cert/hostname
> verification) on both Alpine and Arch Linux.
>
> Before michaelni asks again: Yes, the absence of my real name in git is
> intended.
>

OK I finally got around to looking through this (sorry for the delay I
previously hadnt had time) and everything looks good.
Since someone complains about LibreSSL not working with our OpenSSL support
every couple of months then this would be a welcome fix and in my opinion
this is the best way to support LibreSSL going forward. If Stefan is happy
to continue to support this in the future if needed then im on-board with
merging this.

If no one has any issues Ill merge this in a couple of days.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.

[Matt Oliver]

On 25 October 2017 at 07:15, Dale Curtis  wrote:

> Technically _tzcnt* intrinsics are only available when the BMI
> instruction set is present. However the instruction encoding
> degrades to "rep bsf" on older processors.
>
> Clang for Windows debatably restricts the _tzcnt* instrinics behind
> the __BMI__ architecture define, so check for its presence or
> exclude the usage of these intrinics when clang is present.
>
> See also:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html
> https://bugs.llvm.org/show_bug.cgi?id=30506
> http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html
>
> Signed-off-by: Dale Curtis 

[FFmpeg-devel] [PATCH] lavc/makefile: Add missing file dependencies.

[Matt Oliver]

ac3dsp.c uses tables from ac3.c
ac3.c uses tables from ac3tab.c
hevc_ps uses tables from hevc_data.c
intrax8.c uses tables from msmpeg4data.c
---
 libavcodec/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 357fa1a361..74de41ab0f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -53,7 +53,7 @@ OBJS =
allcodecs.o  \

 # subsystems
 OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
-OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o
+OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
 OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
 OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
 OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
@@ -79,7 +79,7 @@ OBJS-$(CONFIG_H264DSP) += h264dsp.o
h264idct.o
 OBJS-$(CONFIG_H264PARSE)   += h264_parse.o h2645_parse.o
h264_ps.o
 OBJS-$(CONFIG_H264PRED)+= h264pred.o
 OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
-OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o
hevc_ps.o hevc_sei.o
+OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o
hevc_ps.o hevc_sei.o hevc_data.o
 OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
 OBJS-$(CONFIG_HUFFMAN) += huffman.o
 OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
@@ -87,7 +87,7 @@ OBJS-$(CONFIG_HUFFYUVENCDSP)   += huffyuvencdsp.o
 OBJS-$(CONFIG_IDCTDSP) += idctdsp.o simple_idct.o jrevdct.o
 OBJS-$(CONFIG_IIRFILTER)   += iirfilter.o
 OBJS-$(CONFIG_MDCT15)  += mdct15.o
-OBJS-$(CONFIG_INTRAX8) += intrax8.o intrax8dsp.o
+OBJS-$(CONFIG_INTRAX8) += intrax8.o intrax8dsp.o
msmpeg4data.o
 OBJS-$(CONFIG_IVIDSP)  += ivi_dsp.o
 OBJS-$(CONFIG_JNI) += ffjni.o jni.o
 OBJS-$(CONFIG_JPEGTABLES)  += jpegtables.o
@@ -158,8 +158,8 @@ OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o
aaccoder.o aacenctab.o\
   aacenc_pred.o \
   psymodel.o mpeg4audio.o kbdwin.o
cbrt_data.o
 OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o
-OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o
ac3.o kbdwin.o
-OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o
ac3.o kbdwin.o
+OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o
ac3.o kbdwin.o ac3tab.o
+OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o
ac3.o kbdwin.o ac3tab.o
 OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o ac3enc.o ac3tab.o
\
   ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o
ac3.o
--


0001-lavc-makefile-Add-missing-file-dependencies.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add LIBVMAF filter

[Matt Oliver]

On 17 July 2017 at 01:12, Derek Buitenhuis <derek.buitenh...@gmail.com>
wrote:

> On 7/16/2017 3:15 PM, Matt Oliver wrote:
> > Im getting the same error. The patch had an error in it as this line is
> > wrong:
> > +vmaf_filter_deps="libvmaf"
> >
> > It should be:
> > +libvmaf_filter_deps="libvmaf"
> >
> > As the filter is registered as libvmaf_filter not vmaf_filter in
> > allfilters.cpp
>
> I've pushed this fixed, attributed to you.


thanks, all fixed now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add LIBVMAF filter

[Matt Oliver]

On 16 July 2017 at 23:01, Henrik Gramner  wrote:

> `./configure && make` results in "libavfilter/vf_libvmaf.c:29:21:
> fatal error: libvmaf.h: No such file or directory".
>
> I don't have libvmaf installed, but it configures it as enabled and
> detects it as installed anyway.


Im getting the same error. The patch had an error in it as this line is
wrong:
+vmaf_filter_deps="libvmaf"

It should be:
+libvmaf_filter_deps="libvmaf"

As the filter is registered as libvmaf_filter not vmaf_filter in
allfilters.cpp

Currently this is breaking for me until this gets fixed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] win32_dlfcn: Support WinRT/UWP.

[Matt Oliver]

On 12 July 2017 at 20:31, wm4 <nfx...@googlemail.com> wrote:

> On Sat, 1 Jul 2017 23:18:25 +1000
> Matt Oliver <protogo...@gmail.com> wrote:
>
> > This only enables dlls that are packaged with the application to be
> > loaded. Due to the limitations of WinRT/UWP it is not allowed to load
> > external/system dlls so this cannot be used as a complete replacement
> > for normal win32 dll loading.
> > ---
> >  compat/w32dlfcn.h | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
> > index bc9bb8c9f5..eeabfe4ee0 100644
> > --- a/compat/w32dlfcn.h
> > +++ b/compat/w32dlfcn.h
> > @@ -21,7 +21,7 @@
> >
> >  #ifdef _WIN32
> >  #include 
> > -#if _WIN32_WINNT < 0x0602
> > +#if (_WIN32_WINNT < 0x0602) || HAVE_WINRT
> >  #include "libavutil/wchar_filename.h"
> >  #endif
> >  /**
> > @@ -71,7 +71,14 @@ exit:
> >  #ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
> >  #   define LOAD_LIBRARY_SEARCH_SYSTEM320x0800
> >  #endif
> > +#if !HAVE_WINRT
>
> Why not remove the ! and swap the if/else?
>
> >  return LoadLibraryExA(name, NULL, LOAD_LIBRARY_SEARCH_
> APPLICATION_DIR
> > | LOAD_LIBRARY_SEARCH_SYSTEM32);
> > +#else
> > +wchar_t *name_w = NULL;
> > +if (utf8towchar(name, _w))
> > +return NULL;
> > +return LoadPackagedLibrary(name_w, 0);
>
> Leaks memory?


Your correct, thanks. New patch attached.


0001-win32_dlfcn-Support-WinRT-UWP.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Use existing WinRT config value.

[Matt Oliver]

On 12 July 2017 at 20:27, wm4 <nfx...@googlemail.com> wrote:

> On Wed, 12 Jul 2017 20:05:08 +1000
> Matt Oliver <protogo...@gmail.com> wrote:
>
> > ---
> >  libavformat/os_support.h | 14 +-
> >  1 file changed, 1 insertion(+), 13 deletions(-)
> >
> > diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> > index 6e245a88d8..91220e9716 100644
> > --- a/libavformat/os_support.h
> > +++ b/libavformat/os_support.h
> > @@ -146,18 +146,6 @@ int ff_poll(struct pollfd *fds, nfds_t numfds, int
> > timeout);
> >  #include 
> >  #include "libavutil/wchar_filename.h"
> >
> > -#ifdef WINAPI_FAMILY
> > -#include 
> > -// If a WINAPI_FAMILY is defined, check that the desktop API subset
> > -// is enabled
> > -#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
> > -#define USE_MOVEFILEEXA
> > -#endif
> > -#else
> > -// If no WINAPI_FAMILY is defined, assume the full API subset
> > -#define USE_MOVEFILEEXA
> > -#endif
> > -
> >  #define DEF_FS_FUNCTION(name, wfunc, afunc)   \
> >  static inline int win32_##name(const char *filename_utf8) \
> >  { \
> > @@ -232,7 +220,7 @@ static inline int win32_rename(const char *src_utf8,
> > const char *dest_utf8)
> >
> >  fallback:
> >  /* filename may be be in CP_ACP */
> > -#ifdef USE_MOVEFILEEXA
> > +#if !HAVE_WINRT
> >  ret = MoveFileExA(src_utf8, dest_utf8, MOVEFILE_REPLACE_EXISTING);
> >  if (ret)
> >  errno = EPERM;
> > --
>
> I think this would conflict with a similar commit in Libav, but not
> sure.
>

I think ive seen the commit your referring to. However libav adds a
HAVE_UWP value however we already have the HAVE_WINRT value thats used in
existing code to do the same thing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/os_support: Use existing WinRT config value.

[Matt Oliver]

---
 libavformat/os_support.h | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 6e245a88d8..91220e9716 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -146,18 +146,6 @@ int ff_poll(struct pollfd *fds, nfds_t numfds, int
timeout);
 #include 
 #include "libavutil/wchar_filename.h"

-#ifdef WINAPI_FAMILY
-#include 
-// If a WINAPI_FAMILY is defined, check that the desktop API subset
-// is enabled
-#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
-#define USE_MOVEFILEEXA
-#endif
-#else
-// If no WINAPI_FAMILY is defined, assume the full API subset
-#define USE_MOVEFILEEXA
-#endif
-
 #define DEF_FS_FUNCTION(name, wfunc, afunc)   \
 static inline int win32_##name(const char *filename_utf8) \
 { \
@@ -232,7 +220,7 @@ static inline int win32_rename(const char *src_utf8,
const char *dest_utf8)

 fallback:
 /* filename may be be in CP_ACP */
-#ifdef USE_MOVEFILEEXA
+#if !HAVE_WINRT
 ret = MoveFileExA(src_utf8, dest_utf8, MOVEFILE_REPLACE_EXISTING);
 if (ret)
 errno = EPERM;
--


0001-lavf-os_support-Use-existing-WinRT-config-value.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] win32_dlfcn: Support WinRT/UWP.

[Matt Oliver]

On 2 July 2017 at 00:29, Matt Oliver <protogo...@gmail.com> wrote:

> On 2 July 2017 at 00:14, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>
>> On Sat, Jul 1, 2017 at 3:18 PM, Matt Oliver <protogo...@gmail.com> wrote:
>> > This only enables dlls that are packaged with the application to be
>> > loaded. Due to the limitations of WinRT/UWP it is not allowed to load
>> > external/system dlls so this cannot be used as a complete replacement
>> > for normal win32 dll loading.
>>
>> Most of the things we do load are system libraries, so does it really
>> make sense to pretend it works?
>>
>
> No, but this was in response to a previous patch posted to the mailing
> list that just set the return to null. Its mainly just to prevent build
> errors when including the header and I figured that at least a function
> that works would be better than just returning null as this may be of use
> in the future.
> Of course all code we have wont work and should be handled specifically
> (like the recent dx lib linking) but i figured this was better than nothing.
>

Does anyone have any issue with me applying this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] win32_dlfcn: Support WinRT/UWP.

[Matt Oliver]

On 2 July 2017 at 00:14, Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Sat, Jul 1, 2017 at 3:18 PM, Matt Oliver <protogo...@gmail.com> wrote:
> > This only enables dlls that are packaged with the application to be
> > loaded. Due to the limitations of WinRT/UWP it is not allowed to load
> > external/system dlls so this cannot be used as a complete replacement
> > for normal win32 dll loading.
>
> Most of the things we do load are system libraries, so does it really
> make sense to pretend it works?
>

No, but this was in response to a previous patch posted to the mailing list
that just set the return to null. Its mainly just to prevent build errors
when including the header and I figured that at least a function that works
would be better than just returning null as this may be of use in the
future.
Of course all code we have wont work and should be handled specifically
(like the recent dx lib linking) but i figured this was better than nothing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] win32_dlfcn: Support WinRT/UWP.

[Matt Oliver]

This only enables dlls that are packaged with the application to be
loaded. Due to the limitations of WinRT/UWP it is not allowed to load
external/system dlls so this cannot be used as a complete replacement
for normal win32 dll loading.
---
 compat/w32dlfcn.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index bc9bb8c9f5..eeabfe4ee0 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -21,7 +21,7 @@

 #ifdef _WIN32
 #include 
-#if _WIN32_WINNT < 0x0602
+#if (_WIN32_WINNT < 0x0602) || HAVE_WINRT
 #include "libavutil/wchar_filename.h"
 #endif
 /**
@@ -71,7 +71,14 @@ exit:
 #ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
 #   define LOAD_LIBRARY_SEARCH_SYSTEM320x0800
 #endif
+#if !HAVE_WINRT
 return LoadLibraryExA(name, NULL, LOAD_LIBRARY_SEARCH_APPLICATION_DIR
| LOAD_LIBRARY_SEARCH_SYSTEM32);
+#else
+wchar_t *name_w = NULL;
+if (utf8towchar(name, _w))
+return NULL;
+return LoadPackagedLibrary(name_w, 0);
+#endif
 }
 #define dlopen(name, flags) win32_dlopen(name)
 #define dlclose FreeLibrary
--


0001-win32_dlfcn-Support-WinRT-UWP.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: Correct detection of pre-processor defines for configure _LISTS.

[Matt Oliver]

Currently the find_things configure function will scan a code file (e.g.
allfilters.c) and then create a list of pre-processor values to be added
to configure.
Unfortunately the way it currently does it is incorrect with what the
original c code expects. For example the following exists in
allfilters.c:
REGISTER_FILTER(FREI0R, frei0r_src, vsrc);

where REGISTER_FILTER is defined as:
#define REGISTER_FILTER(X, x, y)
{
extern AVFilter ff_##y##_##x;
if (CONFIG_##X##_FILTER)
avfilter_register(_##y##_##x);
}

In c code this will check a configuration pre-processor define called
CONFIG_FREI0R_FILTER and then register the filter if currently set.

The issue arises in that configure currently looks for REGISTER_FILTER
but when found it will use the second parameter in the macro to create
the configuration option. So it will actually return that the
pre-processor define is CONFIG_FREI0R_SRC_FILTER and not
CONFIG_FREI0R_FILTER as the source code actually expects.

This patch changes the behaviour to match what the c code expects by
using the first parameter in the macro to create configure values. Since
the first parameter is in upper case it needs to be converted to lower
case to be usable within configure (this may be why currently the
incorrect - although lower case 2nd parameter is currently used).
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index e6fe05a6ee..346dbc660b 100755
--- a/configure
+++ b/configure
@@ -3366,7 +3366,7 @@ find_things(){
 thing=$1
 pattern=$2
 file=$source_path/$3
-sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p"
"$file"
+sed -n "s/^[^#]*$pattern.*(\([^,]*\),
*\([^,]*\)\(,.*\)*).*/\1_$thing/p" "$file" | tr '[:upper:]' '[:lower:]'
 }

 ENCODER_LIST=$(find_things  encoder  ENC  libavcodec/allcodecs.c)
-- 
2.11.0.windows.3


0001-configure-Correct-detection-of-pre-processor-defines.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Correct detection of pre-processor defines for configure _LISTS.

[Matt Oliver]

On 22 April 2017 at 21:09, Matt Oliver <protogo...@gmail.com> wrote:

> Currently the find_things configure function will scan a code file (e.g.
> allfilters.c) and then create a list of pre-processor values to be added
> to configure.
> Unfortunately the way it currently does it is incorrect with what the
> original c code expects. For example the following exists in
> allfilters.c:
> REGISTER_FILTER(FREI0R, frei0r_src, vsrc);
>
> where REGISTER_FILTER is defined as:
> #define REGISTER_FILTER(X, x, y)
> {
> extern AVFilter ff_##y##_##x;
> if (CONFIG_##X##_FILTER)
> avfilter_register(_##y##_##x);
> }
>
> In c code this will check a configuration pre-processor define called
> CONFIG_FREI0R_FILTER and then register the filter if currently set.
>
> The issue arises in that configure currently looks for REGISTER_FILTER
> but when found it will use the second parameter in the macro to create
> the configuration option. So it will actually return that the
> pre-processor define is CONFIG_FREI0R_SRC_FILTER and not
> CONFIG_FREI0R_FILTER as the source code actually expects.
>
> This patch changes the behaviour to match what the c code expects by
> using the first parameter in the macro to create configure values. Since
> the first parameter is in upper case it needs to be converted to lower
> case to be usable within configure (this may be why currently the
> incorrect - although lower case 2nd parameter is currently used).
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e6fe05a6ee..346dbc660b 100755
> --- a/configure
> +++ b/configure
> @@ -3366,7 +3366,7 @@ find_things(){
>  thing=$1
>  pattern=$2
>  file=$source_path/$3
> -sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p"
> "$file"
> +sed -n "s/^[^#]*$pattern.*(\([^,]*\), *\([^,]*\)\(,.*\)*).*/\1_$thing/p"
> "$file" | tr '[:upper:]' '[:lower:]'
>  }
>
>  ENCODER_LIST=$(find_things  encoder  ENC  libavcodec/allcodecs.c)
> --
> 2.11.0.windows.3
>

Currently there are also some differences in what the makefiles expect for
the few options that have different values for the first and second macro
parameters. I can change these but i just wanted to get feedback as to
whether this is considered correct first.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues

[Matt Oliver]

On 14 April 2017 at 03:31, Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver <protogo...@gmail.com> wrote:
> > On 14 April 2017 at 02:11, Rostislav Pehlivanov <atomnu...@gmail.com>
> wrote:
> >
> >>
> >>
> >> On 13 April 2017 at 16:51, wm4 <nfx...@googlemail.com> wrote:
> >>
> >>> On Thu, 13 Apr 2017 17:39:57 +1000
> >>> Matt Oliver <protogo...@gmail.com> wrote:
> >>>
> >>> > On 13 April 2017 at 17:20, Aaron Levinson <alevi...@aracnet.com>
> wrote:
> >>> >
> >>> > > I wanted to build a debug build of ffmpeg using Visual C++ today,
> one
> >>> > > without any optimizations.  This implies the use of the -Od
> compiler
> >>> > > option.  Unfortunately, I quickly discovered that the build fails
> soon
> >>> > > after it starts because it can't find certain architecture-specific
> >>> > > references.  For example, in libavutil/cpu.c, there is the
> following:
> >>> > >
> >>> > > if (ARCH_AARCH64)
> >>> > > return ff_get_cpu_flags_aarch64();
> >>> > >
> >>> > > The linker couldn't find ff_get_cpu_flags_aarch64 (and other
> similar
> >>> > > references) and failed.  This isn't an issue when optimizations are
> >>> turned
> >>> > > on because the compiler notices that ARCH_AARCH64 is defined as 0
> and
> >>> > > eliminates the relevant code.
> >>> > >
> >>> > > Effectively, successful builds of ffmpeg depend on this compiler
> >>> > > optimization.  This appears to have been the standard practice in
> the
> >>> > > ffmpeg code base for at least the last few years, but it is unclear
> >>> to me
> >>> > > why this approach is being used, since, in addition to depending on
> >>> > > specific compiler behavior, it prevents fully debug builds from
> >>> succeeding,
> >>> > > at least with Visual C++.
> >>> > >
> >>> > > If people like the if (ARCH_...) syntax, while it wouldn't look
> quite
> >>> as
> >>> > > nice, what's wrong with doing the following:
> >>> > >
> >>> > > #if ARCH_AARCH64
> >>> > > if (ARCH_AARCH64)
> >>> > > return ff_get_cpu_flags_aarch64();
> >>> > > #endif
> >>> > >
> >>> > > Another, much less desirable option is to use #pragma optimize for
> the
> >>> > > relevant functions in ffmpeg to turn optimizations on for specific
> >>> > > functions.
> >>> > >
> >>> > > A third option would be to build only the relevant files with
> >>> > > optimizations turned on, but this will end up making the Makefiles
> >>> more
> >>> > > complicated, and the relative simplicity of the Makefiles is
> >>> appealing.
> >>> > >
> >>> > > For now, I'm using both -Od and -Og with Visual C++ (-Og turns on
> some
> >>> > > optimizations, but not as much as -O1 or -O2), but this isn't the
> >>> same as a
> >>> > > true debug build.
> >>> > >
> >>> >
> >>> > Similar patches have been submitted before. This is an issue with
> Dead
> >>> Code
> >>> > Elimination (DCE) within FFmpeg and the fact the MSVC doesn't support
> >>> > removing it in debug builds.
> >>> >
> >>> > There have been some discussions on the mailing list in the past
> about
> >>> > resolving this but nothing was ever decided.
> >>> >
> >>> > As a quick and dirty work around I have a tool that i wrote that
> scans
> >>> in
> >>> > the configure/makefile from a ffmpeg distro and generates a native
> >>> Visual
> >>> > Studio project file that can be used to just compile within Visual
> >>> Studio
> >>> > itself. You just pass it the desired configure options that you want
> to
> >>> use
> >>> > to build the project and it will make one for you. The main thing is
> >>> that
> >>> > it scans the source and automatically generates the missing DCE
> sections
> >>> > and adds them so that everything will compile correctly with Debug
> >>> builds
> >>> > and you can debug directly in VS. You can find the tool here
> >>> > http://shiftmediaproject.github.io/1-projects/ (normally i wouldn't
> put
> >>> > external references on the mailing list but this may be of use to
> you).
> >>>
> >>> Any chance you could revive your old patches to remove the DCE
> >>> requirement? (Not sure if there were any patches.)
> >>>
> >>> Before you do any real work, make a thread on the ML requesting
> >>> comments on this. Although I would very much welcome such patches, I'm
> >>> not fully sure about others.
> >>>
> >>> This DCE requirement is pretty painful, and affects debugging on Linux
> >>> as well.
> >>>
> >>
> > I put up a general discussion a while ago (
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) but
> > there were a few people who opposed a direct removal of DCE and no one
> > really came up with a consensus as to what the acceptable approach would
> be.
> >
>
> I wouldn't like any weird hacks in the source just to work-around the
> lack of DCE in debug builds, so we should decide to either keep using
> it or get rid of it.


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

Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues

[Matt Oliver]

On 14 April 2017 at 02:11, Rostislav Pehlivanov <atomnu...@gmail.com> wrote:

>
>
> On 13 April 2017 at 16:51, wm4 <nfx...@googlemail.com> wrote:
>
>> On Thu, 13 Apr 2017 17:39:57 +1000
>> Matt Oliver <protogo...@gmail.com> wrote:
>>
>> > On 13 April 2017 at 17:20, Aaron Levinson <alevi...@aracnet.com> wrote:
>> >
>> > > I wanted to build a debug build of ffmpeg using Visual C++ today, one
>> > > without any optimizations.  This implies the use of the -Od compiler
>> > > option.  Unfortunately, I quickly discovered that the build fails soon
>> > > after it starts because it can't find certain architecture-specific
>> > > references.  For example, in libavutil/cpu.c, there is the following:
>> > >
>> > > if (ARCH_AARCH64)
>> > > return ff_get_cpu_flags_aarch64();
>> > >
>> > > The linker couldn't find ff_get_cpu_flags_aarch64 (and other similar
>> > > references) and failed.  This isn't an issue when optimizations are
>> turned
>> > > on because the compiler notices that ARCH_AARCH64 is defined as 0 and
>> > > eliminates the relevant code.
>> > >
>> > > Effectively, successful builds of ffmpeg depend on this compiler
>> > > optimization.  This appears to have been the standard practice in the
>> > > ffmpeg code base for at least the last few years, but it is unclear
>> to me
>> > > why this approach is being used, since, in addition to depending on
>> > > specific compiler behavior, it prevents fully debug builds from
>> succeeding,
>> > > at least with Visual C++.
>> > >
>> > > If people like the if (ARCH_...) syntax, while it wouldn't look quite
>> as
>> > > nice, what's wrong with doing the following:
>> > >
>> > > #if ARCH_AARCH64
>> > > if (ARCH_AARCH64)
>> > > return ff_get_cpu_flags_aarch64();
>> > > #endif
>> > >
>> > > Another, much less desirable option is to use #pragma optimize for the
>> > > relevant functions in ffmpeg to turn optimizations on for specific
>> > > functions.
>> > >
>> > > A third option would be to build only the relevant files with
>> > > optimizations turned on, but this will end up making the Makefiles
>> more
>> > > complicated, and the relative simplicity of the Makefiles is
>> appealing.
>> > >
>> > > For now, I'm using both -Od and -Og with Visual C++ (-Og turns on some
>> > > optimizations, but not as much as -O1 or -O2), but this isn't the
>> same as a
>> > > true debug build.
>> > >
>> >
>> > Similar patches have been submitted before. This is an issue with Dead
>> Code
>> > Elimination (DCE) within FFmpeg and the fact the MSVC doesn't support
>> > removing it in debug builds.
>> >
>> > There have been some discussions on the mailing list in the past about
>> > resolving this but nothing was ever decided.
>> >
>> > As a quick and dirty work around I have a tool that i wrote that scans
>> in
>> > the configure/makefile from a ffmpeg distro and generates a native
>> Visual
>> > Studio project file that can be used to just compile within Visual
>> Studio
>> > itself. You just pass it the desired configure options that you want to
>> use
>> > to build the project and it will make one for you. The main thing is
>> that
>> > it scans the source and automatically generates the missing DCE sections
>> > and adds them so that everything will compile correctly with Debug
>> builds
>> > and you can debug directly in VS. You can find the tool here
>> > http://shiftmediaproject.github.io/1-projects/ (normally i wouldn't put
>> > external references on the mailing list but this may be of use to you).
>>
>> Any chance you could revive your old patches to remove the DCE
>> requirement? (Not sure if there were any patches.)
>>
>> Before you do any real work, make a thread on the ML requesting
>> comments on this. Although I would very much welcome such patches, I'm
>> not fully sure about others.
>>
>> This DCE requirement is pretty painful, and affects debugging on Linux
>> as well.
>>
>
I put up a general discussion a while ago (
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204530.html) but
there were a few people who opposed a direct removal of DCE and no one
really came up with a 

Re: [FFmpeg-devel] Debug builds and if (ARCH_...) linking issues

[Matt Oliver]

On 13 April 2017 at 17:20, Aaron Levinson  wrote:

> I wanted to build a debug build of ffmpeg using Visual C++ today, one
> without any optimizations.  This implies the use of the -Od compiler
> option.  Unfortunately, I quickly discovered that the build fails soon
> after it starts because it can't find certain architecture-specific
> references.  For example, in libavutil/cpu.c, there is the following:
>
> if (ARCH_AARCH64)
> return ff_get_cpu_flags_aarch64();
>
> The linker couldn't find ff_get_cpu_flags_aarch64 (and other similar
> references) and failed.  This isn't an issue when optimizations are turned
> on because the compiler notices that ARCH_AARCH64 is defined as 0 and
> eliminates the relevant code.
>
> Effectively, successful builds of ffmpeg depend on this compiler
> optimization.  This appears to have been the standard practice in the
> ffmpeg code base for at least the last few years, but it is unclear to me
> why this approach is being used, since, in addition to depending on
> specific compiler behavior, it prevents fully debug builds from succeeding,
> at least with Visual C++.
>
> If people like the if (ARCH_...) syntax, while it wouldn't look quite as
> nice, what's wrong with doing the following:
>
> #if ARCH_AARCH64
> if (ARCH_AARCH64)
> return ff_get_cpu_flags_aarch64();
> #endif
>
> Another, much less desirable option is to use #pragma optimize for the
> relevant functions in ffmpeg to turn optimizations on for specific
> functions.
>
> A third option would be to build only the relevant files with
> optimizations turned on, but this will end up making the Makefiles more
> complicated, and the relative simplicity of the Makefiles is appealing.
>
> For now, I'm using both -Od and -Og with Visual C++ (-Og turns on some
> optimizations, but not as much as -O1 or -O2), but this isn't the same as a
> true debug build.
>

Similar patches have been submitted before. This is an issue with Dead Code
Elimination (DCE) within FFmpeg and the fact the MSVC doesn't support
removing it in debug builds.

There have been some discussions on the mailing list in the past about
resolving this but nothing was ever decided.

As a quick and dirty work around I have a tool that i wrote that scans in
the configure/makefile from a ffmpeg distro and generates a native Visual
Studio project file that can be used to just compile within Visual Studio
itself. You just pass it the desired configure options that you want to use
to build the project and it will make one for you. The main thing is that
it scans the source and automatically generates the missing DCE sections
and adds them so that everything will compile correctly with Debug builds
and you can debug directly in VS. You can find the tool here
http://shiftmediaproject.github.io/1-projects/ (normally i wouldn't put
external references on the mailing list but this may be of use to you).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: instruct MSVC 2015 to properly process UTF-8 string literals

[Matt Oliver]

On 4 February 2017 at 21:23, Hendrik Leppkes  wrote:

> On Sat, Feb 4, 2017 at 10:29 AM, Carl Eugen Hoyos 
> wrote:
> > 2017-02-04 10:25 GMT+01:00 Hendrik Leppkes :
> >
> >> Another MSVC workaround is an undocumented compiler pragma, which
> >> works in 2013, but not in 2012 (#pragma
> >> execution_character_set("utf-8")), but adding pragmas to files is also
> >> not something you can just easily hide away without it becoming ugly.
> >
> > Is there a real disadvantage adding the pragma after your patch
> > gets applied?
> >
>
> Adding pragmas is ugly because you can't hide them away, but its
> independent of this patch either way, since it targets a different
> compiler version.
>
> Applied this patch in the meantime, as well as 1/2 from the set.
>

Well given that the pragma doesn't work in 2012 and we are still claiming
support for those older msvc versions then it wouldn't really be a suitable
fix anyway.

As far as I see it it the only way to cover all currently supported msvc
versions would be to convert the utf chars directly to binary. Which is a
bit ugly granted, but im not sure there is anyway around it. MSVC appears
to output a warning about characters that dont fit in the current code page
and at the moment only ccaption_dec.c is mentioned so it appears tat
luckily only 1 file needs to be changed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: instruct MSVC 2015 to properly process UTF-8 string literals

[Matt Oliver]

On 4 February 2017 at 02:32, Hendrik Leppkes  wrote:

> On Fri, Feb 3, 2017 at 3:05 PM, James Almer  wrote:
> > On 2/3/2017 5:41 AM, Hendrik Leppkes wrote:
> >> Without the /UTF-8 switch, the MSVC compiler treats all files as in the
> >> system codepage, instead of in UTF-8, which causes UTF-8 string literals
> >> to be interpreted wrong.
> >>
> >> This switch was only introduced in VS2015 Update 2, and any earlier
> >> versions do not have an equivalent solution.
> >>
> >> Fixes fate-sub-scc on MSVC 2015+
> >> ---
> >>  configure | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/configure b/configure
> >> index d3d652f0f4..231cc3eca7 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -6327,6 +6327,9 @@ EOF
> >>  # Issue has been fixed in MSVC v19.00.24218.
> >>  check_cpp_condition windows.h "_MSC_FULL_VER >= 190024218" ||
> >>  check_cflags -d2SSAOptimizer-
> >> +# enable utf-8 source processing on VS2015 U2 and newer
> >> +check_cpp_condition windows.h "_MSC_FULL_VER >= 190023918" &&
> >> +add_cflags -utf-8
> >
> > Probably better use check_cflags, just in case.
> >
>
> check_cflags doesn't work, since most wrong options just cause it to
> emit a warning but not error out (although confusingly some do error
> out, like the d2 option above, since the d2 prefix directly targets
> the c2 compiler stage, and unknown options there error instead of
> warn).
> Thats the whole reason I added a version check in the first place
> instead of solely using check_cflags with it.
>
> I mean, no real harm to use check_cflags together with the version
> check, but since it doesn't do anything, I figured I would save the
> extra check and a few forks.


Is there any possibility to also find a fix for this on older msvc
versions? If you direct me to the specific lines of code that are
mis-compiling/executing ill have a look.
In the mean time this patch looks good to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/tls_openssl: Support building with LibreSSL

[Matt Oliver]

On 29 January 2017 at 01:00, Marek Behun  wrote:

> On Sat, 28 Jan 2017 14:07:45 +0100
> wm4  wrote:
>
> > On Sat, 28 Jan 2017 13:01:54 +
> > Mark Thompson  wrote:
> >
> > > On 28/01/17 11:28, wm4 wrote:
> > > > On Fri, 27 Jan 2017 19:53:50 +
> > > > Mark Thompson  wrote:
> > > >
> > > >> On 27/01/17 19:15, Marek Behun wrote:
> > > >>> On Fri, 27 Jan 2017 18:41:09 +
> > > >>> Mark Thompson  wrote:
> > > >>>
> > >  On 27/01/17 17:31, Marek Behún wrote:
> > > > Use the LIBRESSL_VERSION_NUMBER macro to determine if
> > > > building with LibreSSL instead of OpenSSL. This is pretty
> > > > straightforward, since it is enough to add this check to
> > > > existing #if macros.
> > > >
> > > > Signed-off-by: Marek Behun 
> > > > ---
> > > >  libavformat/tls_openssl.c | 12 ++--
> > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/libavformat/tls_openssl.c
> > > > b/libavformat/tls_openssl.c index 3d9768a..cf1a62e 100644
> > > > --- a/libavformat/tls_openssl.c
> > > > +++ b/libavformat/tls_openssl.c
> > > > @@ -43,7 +43,7 @@ typedef struct TLSContext {
> > > >  TLSShared tls_shared;
> > > >  SSL_CTX *ctx;
> > > >  SSL *ssl;
> > > > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > > > +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > > > && !defined(LIBRESSL_VERSION_NUMBER)
> > > 
> > >  I don't understand what this is trying to do.
> > > 
> > >  Does LibreSSL support the OpenSSL 1.1.0 API:
> > > 
> > >  If yes, why would the additional check be needed?
> > > 
> > >  If no, isn't this doing nothing because the first check would
> > >  be false?
> > > >>>
> > > >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x200, thus
> > > >>> OPENSSL_VERSION_NUMBER is always greater than 0x101, but
> > > >>> LibreSSL does not support 1.1.0 API.
> > > >>
> > > >> Er, right, so it just lies and leaves it to user programs to
> > > >> sort it out.  How nice.
> > > >>
> > > >> Looking back, I can see this has been discussed before:
> > > >>  October/201960.html>
> > > >>  December/203998.html>
> > > >>
> > > >> That (beyond the disapprobation towards libressl for being
> > > >> naughty) looks like people would prefer the test to be in
> > > >> configure rather than copying the nontrivial #if condition
> > > >> everywhere?
> > > >
> > > > Maybe LibreSSL should fix this upstream.
> > > >
> > > > They're doing an extreme disservice to everyone by breaking every
> > > > single downstream program.
> > > >
> > > > I'd even go as far as saying we shouldn't bother with LibreSSL if
> > > > trying to keep compatibility is going to be a mess this huge.
> > >
> > > If it becomes more inconvenient to do so, yes.
> >
> > > (At that point probably just clone tls_openssl.c to tls_libressl.c
> > > and let them diverge if support is still wanted.)
>
> The support would be wanted, for sure. FreeBSD, OpenBSD and Gentoo want
> to support LibreSSL:
> - OpenBSD already removed openssl completely, since the security flaws
>   of openssl are unacceptable to them.
> - FreeBSD states that "Currently there are no binary distributions for
>   LibreSSL-in-base but this is to change with the release of FreeBSD
>   11."
> - Gentoo has a USE flag for libressl and Gentoo bug #561854, which
>   tracks LibreSSL incompatibilities, has majority of dependencies
>   solved.
>
> My guess is that the OpenBSD guys want the world to get rid of openssl
> completely (see for example http://opensslrampage.org/), and breaking
> API compatibility with openssl is their "strategy". Well, this strategy
> maybe is inconveniet for others, but having seen the code of openssl, I
> would rather inconveniet myself with porting to LibreSSL than use
> OpenSSL.
>

Well perhaps making a tls_libressl implementation would be the better way
to go as the APIs are only going to diverge further. So perhaps in order to
support LibreSSL there should be a separate implementation using LibreSSLs
independent libtls instead of the older openssl support interface. libtls
is the recommended and primarily supported interface when using LibreSSL so
that should be used going forward instead of further complication the
opensll code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 23 December 2016 at 19:40, Nicolas George  wrote:

> Le primidi 1er nivôse, an CCXXV, Michael Niedermayer a écrit :
> > how hard would it be to write a preprocessor like tool to convert
> > all if (ARCH/HAVE/CONFIG_SYMBOL ...)
> > to
> > #if
> > ?
>
> For a very general case, quite hard, but we do not need it.
>
> If we stick to a few reasonable cosmetic conventions on the affected
> blocks (at a guess: correct indentation of the braces, balanced
> parentheses in the condition; we want to do that anyway), then it should
> be quite easy to write a preprocessor like that.
>
> I do not know how to integrate that in the build system, though. That is
> the annoying part IMHO.
>

Looking at the code there are a couple (only small number admittedly) of
complex sections of code using DCE that would make a preprocessor tool
potentially rather complex and difficult to handle. I wouldn't like to
attempt to do it thats for sure.

I wouldn't mind a patch which did that, even if it meant adding a line for
> every file which did that.
> I'm not a preprocessor wizard but couldn't you hide all that in a macro,
> like:
>
> INIT_ARCH_CODEPATH(ARCH_X86, ff_aac_dsp_init_x86(s)))
>
> if you define the macro in config.h somehow such that the preprocessor
> doesn't evaluate whether ARCH_X86 is defined?


I think it would be possible to write a macro similar to that that can be
used to replace all the existing occurrences of things like:
if (ARCH_X86)
ff_aac_dsp_init_x86(s);

with
SELECT_DCE(ARCH_X86, ff_aac_dsp_init_x86(s));

although all those occurrences can just be easily replaced with:
#if ARCH_X86
ff_aac_dsp_init_x86(s);
#endif

Which one is chosen is simply a matter of preference, either one works fine
for me.

Its mainly for the more complicated sections of code where DCE is actually
used to test whether the code at least compiles correctly that a simple
macro wont suffice if you intend to wrap the whole block. However it is
only the function calls that cause errors so the rest of the code can be
left intact and only the function calls themselves get wrapped in some sort
of macro like above.

So any existing function call that causes linker errors can be wrapped in a
macro like SELECT_DCE (or whatever name you wish to give it) which would
fix all the current issues.

I have the time coming up to replace all the problem functions calls with
something like the above, so let me know whether that would be an
acceptable approach.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 23 December 2016 at 15:35, Matt Oliver <protogo...@gmail.com> wrote:

> On 21 December 2016 at 23:55, wm4 <nfx...@googlemail.com> wrote:
>
>> On Fri, 16 Dec 2016 13:48:16 +1100
>> Matt Oliver <protogo...@gmail.com> wrote:
>>
>> > Recently we have again received several patches that are trying to add
>> > workarounds for ffmpegs use of DCE. This is not the first time this has
>> > happened and wont be the last until a decision is made about the use of
>> > DCE. So I think its time that we made a official decision on the use of
>> > DCE. This is of course something that should be properly agreed upon by
>> > developers going forward as different people have different opinions on
>> the
>> > matter so to help assist this I will summaries all of the previously
>> made
>> > arguments from both sides of the discussion.
>> >
>> > For DCE:
>> > 1) Ends up with a horrible mess of ifdefs.
>> > 2) Disabled parts of code will not be checked for syntax.
>> >
>> > Against DCE:
>> > 3) DCE is not actually specified in the C specification. So compilers
>> are
>> > actually being 100% compliant by not supporting it and should not be
>> > expected to change just for ffmpegs use case.
>> > 4) Breaks debug and lto builds on msvc.
>> > 5) Breaks debug and lto builds on icl.
>> > 6) Issues with lto with Clang and Gold.
>> > 7) Other unspecified issues with debug builds
>> >
>> > Rebuttals against above arguments:
>> > 8) There are already 3961 #ifs(not including header guards) in the code
>> so
>> > there is already a lot of code that doesn't use DCE. (In response to #1
>> for
>> > DCE).
>> > 9) Avoiding #ifdefs is a personal opinion as to whether they are ugly or
>> > not (some prefer ifdefs as IDEs will correctly highlight disabled
>> > sections). Someones personal preference for what looks better should
>> not be
>> > justification to break supported configurations/compilers. (In response
>> to
>> > #1 for DCE).
>> > 10) There is --enable-random which is supposed to be used to find
>> > configurations that don't compile. (in response to #2 for DCE).
>> > 11) Just because something compiles does not mean that it actually
>> works,
>> > relying on just syntax checking is dangerous as it gives false security
>> as
>> > the code is not actually being tested. (in response to #2 for DCE)
>> > 12) There are numerous FATE tests that should find all the configuration
>> > errors. (in response to #2 for DCE)
>> > 12) MSVC is broken and we shouldn't support it so Microsoft are forced
>> to
>> > fix it (in response to #4 against DCE) - This point is countermanded by
>> #3
>> > against DCE and reported issues with other compilers as well.
>> >
>> >
>> > Most of the above points were taken from peoples posts in the following
>> > mailing list thread:
>> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html
>> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194115.html
>> >
>> > Its my personal opinion that DCE should be removed from the code but
>> this
>> > is something I am aware will require a developer consensus and perhaps
>> even
>> > a vote. Stating something is broken is one thing so I will also put
>> forward
>> > a solution in that if it is agreed upon to remove DCE usage then I will
>> > spend the time and effort to go through the existing code base and
>> replace
>> > DCE with appropriate #ifs.
>>
>> I was completely lost here, until I opened one of the link and realized
>> you're talking about Dead Code Elimination.
>>
>> Summary for those missing context: we rely on DCE to remove code that
>> would otherwise fail at link time.
>>
>> For example consider this code, which will be compiled on _all_
>> platforms:
>>
>>   void decode_something_x86();
>>
>>   if (HAVE_X86)
>>  function_ptr = decode_something_x86;
>>
>> Now if this is compiled on ARM, HAVE_X86 will be 0, and the
>> function_ptr assignment is dead code. DCE will remove this code, and
>> remove the decode_something_x86 reference. If DCE doesn't work, this
>> will fail to link, since decode_something_x86 will not be defined
>> anywhere on ARM.
>>
>> I still think this is a bad idea, because compilers are not required to
>> perform DCE. In fact, ffmpeg will fail to compile with many compilers

Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 21 December 2016 at 23:55, wm4 <nfx...@googlemail.com> wrote:

> On Fri, 16 Dec 2016 13:48:16 +1100
> Matt Oliver <protogo...@gmail.com> wrote:
>
> > Recently we have again received several patches that are trying to add
> > workarounds for ffmpegs use of DCE. This is not the first time this has
> > happened and wont be the last until a decision is made about the use of
> > DCE. So I think its time that we made a official decision on the use of
> > DCE. This is of course something that should be properly agreed upon by
> > developers going forward as different people have different opinions on
> the
> > matter so to help assist this I will summaries all of the previously made
> > arguments from both sides of the discussion.
> >
> > For DCE:
> > 1) Ends up with a horrible mess of ifdefs.
> > 2) Disabled parts of code will not be checked for syntax.
> >
> > Against DCE:
> > 3) DCE is not actually specified in the C specification. So compilers are
> > actually being 100% compliant by not supporting it and should not be
> > expected to change just for ffmpegs use case.
> > 4) Breaks debug and lto builds on msvc.
> > 5) Breaks debug and lto builds on icl.
> > 6) Issues with lto with Clang and Gold.
> > 7) Other unspecified issues with debug builds
> >
> > Rebuttals against above arguments:
> > 8) There are already 3961 #ifs(not including header guards) in the code
> so
> > there is already a lot of code that doesn't use DCE. (In response to #1
> for
> > DCE).
> > 9) Avoiding #ifdefs is a personal opinion as to whether they are ugly or
> > not (some prefer ifdefs as IDEs will correctly highlight disabled
> > sections). Someones personal preference for what looks better should not
> be
> > justification to break supported configurations/compilers. (In response
> to
> > #1 for DCE).
> > 10) There is --enable-random which is supposed to be used to find
> > configurations that don't compile. (in response to #2 for DCE).
> > 11) Just because something compiles does not mean that it actually works,
> > relying on just syntax checking is dangerous as it gives false security
> as
> > the code is not actually being tested. (in response to #2 for DCE)
> > 12) There are numerous FATE tests that should find all the configuration
> > errors. (in response to #2 for DCE)
> > 12) MSVC is broken and we shouldn't support it so Microsoft are forced to
> > fix it (in response to #4 against DCE) - This point is countermanded by
> #3
> > against DCE and reported issues with other compilers as well.
> >
> >
> > Most of the above points were taken from peoples posts in the following
> > mailing list thread:
> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194115.html
> >
> > Its my personal opinion that DCE should be removed from the code but this
> > is something I am aware will require a developer consensus and perhaps
> even
> > a vote. Stating something is broken is one thing so I will also put
> forward
> > a solution in that if it is agreed upon to remove DCE usage then I will
> > spend the time and effort to go through the existing code base and
> replace
> > DCE with appropriate #ifs.
>
> I was completely lost here, until I opened one of the link and realized
> you're talking about Dead Code Elimination.
>
> Summary for those missing context: we rely on DCE to remove code that
> would otherwise fail at link time.
>
> For example consider this code, which will be compiled on _all_
> platforms:
>
>   void decode_something_x86();
>
>   if (HAVE_X86)
>  function_ptr = decode_something_x86;
>
> Now if this is compiled on ARM, HAVE_X86 will be 0, and the
> function_ptr assignment is dead code. DCE will remove this code, and
> remove the decode_something_x86 reference. If DCE doesn't work, this
> will fail to link, since decode_something_x86 will not be defined
> anywhere on ARM.
>
> I still think this is a bad idea, because compilers are not required to
> perform DCE. In fact, ffmpeg will fail to compile with many compilers
> if optimizations are disabled. This can make debugging a pain. Beyond
> that, it could legitimately fail if the compiler just decides not to do
> DCE for whatever reasons. (The argument has always been that a compiler
> that fails to DCE such simple cases is not worth being used... strange
> argument, since we work around other compiler bugs in a regular
> fashion.)


Yes, so basically the discussion is about converting things that currently
look like the following (1):

Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 21 December 2016 at 19:26, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:

> 2016-12-16 3:48 GMT+01:00 Matt Oliver <protogo...@gmail.com>:
>
> > For DCE:
> > 1) Ends up with a horrible mess of ifdefs.
>
> This argument alone has often been sufficient to refuse patches here.
>

Hence the initial email as I think that this is a highly subjective point
(see #9), and point #8 was taken from one of wm4s responses (not to put him
on the spot or anything). So there are devs on either side of this. So the
point was to decide whether peoples subjective dislike of ifdefs is enough
to justify breaking compatibility in certain circumstances.

> 6) Issues with lto with Clang and Gold.
> > 7) Other unspecified issues with debug builds
>
> Could you elaborate on these two?
>

These were taken from previous email threads, so point 6) was from an email
by Derek Buitenhuis who basically stated exactly what was written. So for
more information youll have to ask him directly. I was just collating
points that have been previously made by others on the mailing list in
order to jump start a discussion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 16 December 2016 at 13:48, Matt Oliver <protogo...@gmail.com> wrote:

> Recently we have again received several patches that are trying to add
> workarounds for ffmpegs use of DCE. This is not the first time this has
> happened and wont be the last until a decision is made about the use of
> DCE. So I think its time that we made a official decision on the use of
> DCE. This is of course something that should be properly agreed upon by
> developers going forward as different people have different opinions on the
> matter so to help assist this I will summaries all of the previously made
> arguments from both sides of the discussion.
>
> For DCE:
> 1) Ends up with a horrible mess of ifdefs.
> 2) Disabled parts of code will not be checked for syntax.
>
> Against DCE:
> 3) DCE is not actually specified in the C specification. So compilers are
> actually being 100% compliant by not supporting it and should not be
> expected to change just for ffmpegs use case.
> 4) Breaks debug and lto builds on msvc.
> 5) Breaks debug and lto builds on icl.
> 6) Issues with lto with Clang and Gold.
> 7) Other unspecified issues with debug builds
>
> Rebuttals against above arguments:
> 8) There are already 3961 #ifs(not including header guards) in the code so
> there is already a lot of code that doesn't use DCE. (In response to #1 for
> DCE).
> 9) Avoiding #ifdefs is a personal opinion as to whether they are ugly or
> not (some prefer ifdefs as IDEs will correctly highlight disabled
> sections). Someones personal preference for what looks better should not be
> justification to break supported configurations/compilers. (In response to
> #1 for DCE).
> 10) There is --enable-random which is supposed to be used to find
> configurations that don't compile. (in response to #2 for DCE).
> 11) Just because something compiles does not mean that it actually works,
> relying on just syntax checking is dangerous as it gives false security as
> the code is not actually being tested. (in response to #2 for DCE)
> 12) There are numerous FATE tests that should find all the configuration
> errors. (in response to #2 for DCE)
> 12) MSVC is broken and we shouldn't support it so Microsoft are forced to
> fix it (in response to #4 against DCE) - This point is countermanded by #3
> against DCE and reported issues with other compilers as well.
>
>
> Most of the above points were taken from peoples posts in the following
> mailing list thread:
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194115.html
>
> Its my personal opinion that DCE should be removed from the code but this
> is something I am aware will require a developer consensus and perhaps even
> a vote. Stating something is broken is one thing so I will also put forward
> a solution in that if it is agreed upon to remove DCE usage then I will
> spend the time and effort to go through the existing code base and replace
> DCE with appropriate #ifs.
>
> Matt
>

Ok i thought I would at least get some response to this. Historically any
submitted patch to change the use of Dead Code Elimination has been met
with criticism. So I would prefer some sort of consensus before spending
any time writing patches to remove DCE and fix the previously mentioned
issues. This email was intended to get people discussing the issue so that
a decision could be reached so it would be nice if people (particularly
developers with voting rights) chimed in.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.

[Matt Oliver]

On 19 December 2016 at 18:58, Nicolas George  wrote:

> Le nonidi 29 frimaire, an CCXXV, Nicolas George a écrit :
> > Fix compilation on MSVC.
>
> Forgot to write in the comment beore sending: this is obviously
> untested.
>

tested and it fixes the issue. LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Removing DCE

[Matt Oliver]

Recently we have again received several patches that are trying to add
workarounds for ffmpegs use of DCE. This is not the first time this has
happened and wont be the last until a decision is made about the use of
DCE. So I think its time that we made a official decision on the use of
DCE. This is of course something that should be properly agreed upon by
developers going forward as different people have different opinions on the
matter so to help assist this I will summaries all of the previously made
arguments from both sides of the discussion.

For DCE:
1) Ends up with a horrible mess of ifdefs.
2) Disabled parts of code will not be checked for syntax.

Against DCE:
3) DCE is not actually specified in the C specification. So compilers are
actually being 100% compliant by not supporting it and should not be
expected to change just for ffmpegs use case.
4) Breaks debug and lto builds on msvc.
5) Breaks debug and lto builds on icl.
6) Issues with lto with Clang and Gold.
7) Other unspecified issues with debug builds

Rebuttals against above arguments:
8) There are already 3961 #ifs(not including header guards) in the code so
there is already a lot of code that doesn't use DCE. (In response to #1 for
DCE).
9) Avoiding #ifdefs is a personal opinion as to whether they are ugly or
not (some prefer ifdefs as IDEs will correctly highlight disabled
sections). Someones personal preference for what looks better should not be
justification to break supported configurations/compilers. (In response to
#1 for DCE).
10) There is --enable-random which is supposed to be used to find
configurations that don't compile. (in response to #2 for DCE).
11) Just because something compiles does not mean that it actually works,
relying on just syntax checking is dangerous as it gives false security as
the code is not actually being tested. (in response to #2 for DCE)
12) There are numerous FATE tests that should find all the configuration
errors. (in response to #2 for DCE)
12) MSVC is broken and we shouldn't support it so Microsoft are forced to
fix it (in response to #4 against DCE) - This point is countermanded by #3
against DCE and reported issues with other compilers as well.


Most of the above points were taken from peoples posts in the following
mailing list thread:
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194115.html

Its my personal opinion that DCE should be removed from the code but this
is something I am aware will require a developer consensus and perhaps even
a vote. Stating something is broken is one thing so I will also put forward
a solution in that if it is agreed upon to remove DCE usage then I will
spend the time and effort to go through the existing code base and replace
DCE with appropriate #ifs.

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Matt Oliver]

On 15 December 2016 at 21:42, Nicolas George <geo...@nsup.org> wrote:

> Le duodi 22 frimaire, an CCXXV, Matt Oliver a écrit :
> > ---
> >  libavformat/udp.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index f8c861d..3cafb32 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -64,6 +64,14 @@
> >  #define HAVE_PTHREAD_CANCEL 0
> >  #endif
> >
> > +#if HAVE_THREADS && HAVE_WINSOCK2_H
> > +/* Winsock2 recv function can be unblocked by shutting down the socket
> */
> > +#define pthread_setcancelstate(x, y)
> > +#define pthread_cancel
> > +#undef HAVE_PTHREAD_CANCEL
> > +#define HAVE_PTHREAD_CANCEL 1
> > +#endif
> > +
> >  #if HAVE_PTHREAD_CANCEL
> >  #include "libavutil/thread.h"
> >  #endif
> > @@ -526,6 +534,8 @@ static void *circular_buffer_task_rx( void
> *_URLContext)
> >  goto end;
> >  }
> >  continue;
>
> > +} else if (len == 0) {
> > +goto end;
>
> Unfortunately, UDP packets of size 0 exist and are returned to the
> application. If len == 0 is the only criterion to detect a read
> interrupted by shutdown(), it will not be usable for UDP.
>
> You can still combine with your original idea of an atomic flag, though.


On further reading it turns out the zero length check is not required (as
its not needed for connectionless sockets such as udp). So it turns out it
works without the addition of that check as instead it just returns an
error of WSAESHUTDOW. So ive updated the patch locally to remove then
len==0 check.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/wavdec.c: Fix unresolved symbols on Mac and VS2015 Update 3

[Matt Oliver]

On 16 December 2016 at 09:54, Hendrik Leppkes  wrote:

> On Thu, Dec 15, 2016 at 8:43 PM, Matthew Wolenetz 
> wrote:
> >>
> >> This seems like a rather odd issue to be toolchain specific. Can you
> >> please provide a configure command line that would result in a broken
> >> build?
> >
> >
> > I believe the link-time failures occurred with configs like these:
> >
> > IIRC, on Mac, Chromium build hit this with:
> >
> >-
> >https://cs.chromium.org/chromium/src/third_party/
> ffmpeg/chromium/config/Chromium/mac/x64/config.h?rcl=0=4
> >
> > On Windows, one or both of the following hit this:
> >
> >-
> >https://cs.chromium.org/chromium/src/third_party/
> ffmpeg/chromium/config/Chromium/win/ia32/config.h?rcl=0=4
> >-
> >https://cs.chromium.org/chromium/src/third_party/
> ffmpeg/chromium/config/Chromium/win/x64/config.h?rcl=0=4
> >
> > DCE is needed for FFmpeg compilation, this should get fixed by Steve
> >> Lhomme's
> >> configure patch.
> >> I find it hard to understand why wavdec.c would be the only file
> >> showing this issue...
> >
> >
> > Notably, windows still hit this (VS2015 Update 3 19.00.24213.1) *even
> with
> > -O2.*
> >
> >
>
> You are using a custom build system, there is no way to verify any
> issues for us unless you can provide a configure commandline that
> fails on our own build-system.
>
> The patches do look like they are trying to avoid the use of DCE - and
> as Carl already pointed out, quite a lot of our code relies on DCE
> being performed by the compiler/linker, so fixing it in one or two
> isolated spots wouldn't really fix anything but your own customized
> specific build, and make our code-base less consistent within itself.
> DCE generally works fine with Visual Studio, and I do not know of any
> configure setup that makes it fail - of course with the exception of
> using --disable-optimizations, as that turns everything of for MSVC
> right now, including DCE, which makes the build impossible.


Debug builds and lto still have issues with DCE with msvc and icl. Also in
an original email that mentioned a similar problem
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193454.html
people also mentioned issues with clang and gold compilers due to DCE. As
per the linked email thread though I dont think adding patches to fix 1 or
2 cases of DCE issues should be excepted, instead we need to work out a
global solution to the issues with DCE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix linking with MSVC when using --disable-optimizations

[Matt Oliver]

On 16 December 2016 at 11:20, Carl Eugen Hoyos  wrote:

> 2016-12-14 16:47 GMT+01:00 Steve Lhomme :
> > From: Steve Lhomme 
> >
> > Without any optimization flags, MSVC does no dead code elimination (DCE)
> at
> > all, even for the most trivial cases. DCE is a prerequisite for building
> ffmpeg
> > correctly, otherwise there are undefined references to functions for
> other
> > architectures and disabled components.
> >
> > -Os -Og is the minimal optimization flags for MSVC that does include DCE.
>
> The patch looks good to me if -Og alone doesn't help,
> thank you for the improved commit message.


Im not sure this is a good idea. It doesnt seem right to me that if the
user selects to disable optimizations that configure still performs some
anyway. As far as I see it if the user selects to have no optimizations
then there should be no optimizations. This seems like a slightly incorrect
hack to get around ffmpeg using DCE as opposed to tackling the broader
issue of DCE breaking builds, and not just with msvc and not just with no
optimizations enabled.

As a slightly more appropriate (although still hacky fix) you can instead
add /FORCE:UNRESOLVED to the linker command which will still result in a
large number off errors being generated however they will be ignored and an
output binary will still be generated. As the errors all relate to
functions that never get called the output binary is still perfectly
functional and i think importantly doesnt contain optimizations just as the
user requested. Also this fixes debug builds aswell.

I still think the best solution would be to apply a broader ranging fix to
the use of DCE but until a consensus is made on that then the above may be
of some help.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Matt Oliver]

---
 libavformat/udp.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index f8c861d..3cafb32 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -64,6 +64,14 @@
 #define HAVE_PTHREAD_CANCEL 0
 #endif

+#if HAVE_THREADS && HAVE_WINSOCK2_H
+/* Winsock2 recv function can be unblocked by shutting down the socket */
+#define pthread_setcancelstate(x, y)
+#define pthread_cancel
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
 #if HAVE_PTHREAD_CANCEL
 #include "libavutil/thread.h"
 #endif
@@ -526,6 +534,8 @@ static void *circular_buffer_task_rx( void *_URLContext)
 goto end;
 }
 continue;
+} else if (len == 0) {
+goto end;
 }
 AV_WL32(s->tmp, len);

@@ -1144,8 +1154,13 @@ static int udp_close(URLContext *h)
 if (s->thread_started) {
 int ret;
 // Cancel only read, as write has been signaled as success to the
user
-if (h->flags & AVIO_FLAG_READ)
+if (h->flags & AVIO_FLAG_READ) {
+#   if HAVE_THREADS && HAVE_WINSOCK2_H
+shutdown(s->udp_fd, SD_BOTH);
+#   else
 pthread_cancel(s->circular_buffer_thread);
+#   endif
+}
 ret = pthread_join(s->circular_buffer_thread, NULL);
 if (ret != 0)
 av_log(h, AV_LOG_ERROR, "pthread_join(): %s\n", strerror(ret));
--


0003-avformat-udp-Enable-FIFO-when-using-windows-sockets.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/udp: Use avutil compat pthread_cond_timedwait.

[Matt Oliver]

On 11 December 2016 at 00:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:

> 2016-12-07 7:04 GMT+01:00 Matt Oliver <protogo...@gmail.com>:
>
> > -#if HAVE_PTHREAD_CANCEL
> > -#include 
> > -#endif
> > -
>
> >  #ifndef HAVE_PTHREAD_CANCEL
> >  #define HAVE_PTHREAD_CANCEL 0
> >  #endif
>

I have no idea why that line is there as configure should set it to a
value, I just didnt remove it in case there was still some reason that I
couldnt see.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Matt Oliver]

On 8 December 2016 at 04:49, Nicolas George  wrote:

> Le septidi 17 frimaire, an CCXXV, Hendrik Leppkes a écrit :
> > I'm not sure you can safely avoid that in this design when dealing
> > with a fully generic library and no information or control whats going
> > on in other threads.
>
> You are right, I had not realized there was a race condition here.
>
> What happens if shutdown() is performed but not close()?


According to msdn using shutdown instead should work, so ill up a new patch
later today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Matt Oliver]

On 7 December 2016 at 21:19, Mark Thompson <s...@jkqxz.net> wrote:

> On 07/12/16 06:05, Matt Oliver wrote:
> > Signed-off-by: Matt Oliver <protogo...@gmail.com>
> > ---
> >  libavformat/udp.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index f8c861d..0e4766f 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -64,6 +64,14 @@
> >  #define HAVE_PTHREAD_CANCEL 0
> >  #endif
> >
> > +#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
> > +/* Winsock2 recv function can be unblocked by shutting down and closing
> > the socket */
>
> This seems dubious to me.  Can you explain how this can work reliably on
> Windows?
>
> To offer some context, the reason that POSIX states that close() at the
> same time as any other operation is undefined is because it is impossible
> to avoid the following race:
>
> Thread 1:
>   Load the file descriptor
>   Enter the recv() call in the standard library
>   Get preempted just before entering the system call
> Thread 2:
>   Call close() on the file descriptor
>   Finish closing, the file descriptor is now invalid and can be reused
> Thread 3 (could be thread 2 again, or a hidden part of the implementation):
>   Make a new file (with open() or similar)
>   Get given the same file descriptor, reused
> Thread 1:
>   Start running again
>   Actually make the recv() system call, which now refers to thread 3's file
>   Data loss/crash/other badness
>
> Since there is no way to determine that a thread is actually inside the
> system call rather than preempted immediately before it there is no way in
> POSIX to avoid the race.  An alternative implementation seeking to avoid
> this issue could perhaps supply such a function to determine the blocked
> state of another thread, or maybe file descriptors could be unique forever,
> but neither of these seems to apply in this case.
>

Well to be honest this patch is actually based on a suggestion from Hendrik
in another thread so he maybe the better person to ask about that. I can
however state that it is a commonly used Windows winsock programming
technique as closesocket behaves differently on windows than it does on
linux (the above is a very bad idea on linux). Calling closesocket on
windows causes any existing recv calls in other threads to instantly return
with an error code. But im not sure how it would handle the specific case
set above.
An alternative would be to then combine it with win32s ability to terminate
threads.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avutil/thread: Add pthread_cond_timedwait function.

[Matt Oliver]

On 7 December 2016 at 21:32, Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Wed, Dec 7, 2016 at 7:04 AM, Matt Oliver <protogo...@gmail.com> wrote:
> > Signed-off-by: Matt Oliver <protogo...@gmail.com>
> > ---
> >  compat/os2threads.h  | 24 
> >  compat/w32pthreads.h | 50
> > ++
> >  libavutil/thread.h   |  6 ++
> >  3 files changed, 80 insertions(+)
> >
> > diff --git a/compat/os2threads.h b/compat/os2threads.h
> > index 40a119f..a8b7824 100644
> > --- a/compat/os2threads.h
> > +++ b/compat/os2threads.h
> > @@ -31,11 +31,13 @@
> >
> >  #undef __STRICT_ANSI__  /* for _beginthread() */
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> >
> >  #include "libavutil/attributes.h"
> > +#include "libavutil/time.h"
> >
> >  typedef struct {
> >  TID tid;
> > @@ -161,6 +163,28 @@ static av_always_inline int
> > pthread_cond_broadcast(pthread_cond_t *cond)
> >  return 0;
> >  }
> >
> > +static av_always_inline int pthread_cond_timedwait(pthread_cond_t
> *cond,
> > +   pthread_mutex_t
> *mutex,
> > +   const struct timespec
> > *abstime)
> > +{
> > +int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
> > 1.0e6;
> > +ULONG t = FFMAX(abs_milli - av_gettime(), 0LL);
> > +
> > +__atomic_increment(>wait_count);
> > +
> > +pthread_mutex_unlock(mutex);
> > +
> > +APIRET ret = DosWaitEventSem(cond->event_sem, t);
> > +
> > +__atomic_decrement(>wait_count);
> > +
> > +DosPostEventSem(cond->ack_sem);
> > +
> > +pthread_mutex_lock(mutex);
> > +
> > +return (ret == ERROR_TIMEOUT) ? ETIMEDOUT : 0;
> > +}
> > +
> >  static av_always_inline int pthread_cond_wait(pthread_cond_t *cond,
> >pthread_mutex_t *mutex)
> >  {
> > diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> > index 4ac2a99..abd54b2 100644
> > --- a/compat/w32pthreads.h
> > +++ b/compat/w32pthreads.h
> > @@ -38,6 +38,7 @@
> >  #define WIN32_LEAN_AND_MEAN
> >  #include 
> >  #include 
> > +#include 
> >
> >  #if _WIN32_WINNT < 0x0600 && defined(__MINGW32__)
> >  #undef MemoryBarrier
> > @@ -48,6 +49,7 @@
> >  #include "libavutil/common.h"
> >  #include "libavutil/internal.h"
> >  #include "libavutil/mem.h"
> > +#include "libavutil/time.h"
> >
> >  typedef struct pthread_t {
> >  void *handle;
> > @@ -171,6 +173,17 @@ static inline int pthread_cond_wait(pthread_cond_t
> > *cond, pthread_mutex_t *mutex
> >  return 0;
> >  }
> >
> > +static inline int pthread_cond_timedwait(pthread_cond_t *cond,
> > pthread_mutex_t *mutex,
> > + const struct timespec *abstime)
> > +{
> > +int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
> > 1.0e6;
> > +DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
> > +
> > +if (SleepConditionVariableCS(cond, mutex, t) == WAIT_TIMEOUT)
> > +return ETIMEDOUT;
> > +return 0;
> > +}
> > +
> >  static inline int pthread_cond_signal(pthread_cond_t *cond)
> >  {
> >  WakeConditionVariable(cond);
> > @@ -367,6 +380,43 @@ static av_unused int pthread_cond_wait(pthread_
> cond_t
> > *cond, pthread_mutex_t *mu
> >  return pthread_mutex_lock(mutex);
> >  }
> >
> > +static inline int pthread_cond_timedwait(pthread_cond_t *cond,
> > pthread_mutex_t *mutex,
> > + const struct timespec *abstime)
> > +{
> > +win32_cond_t *win32_cond = cond->Ptr;
> > +int last_waiter;
> > +int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
> > 1.0e6;
> > +DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
> > +if (cond_wait) {
> > +cond_wait(cond, mutex, t);
> > +return 0;
>
> This does not return any error codes like the other implementations.
>

fixed locally be changing to:
+if (cond_wait) {
+if (cond_wait(cond, mutex, t) == WAIT_TIMEOUT)
+return ETIMEDOUT;
+return 0;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

On 4 December 2016 at 01:56, Matt Oliver <protogo...@gmail.com> wrote:

> Indeed, in theory that would work. I always forget about these options.
>> In my experience they do not work reliably, and I would argue against
>> their use in portable code. For example, starting there:
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
>> sys_socket.h.html
>> can you tell me the type of the arguments to SO_RCVTIMEO? I know Linux
>> man page tells us it is struct timeval, but that is not a portable
>> standard.
>>
>> Also, these options are just a band aid to implement polling.
>
>
> the same function on windows would take a int64 so the function would have
> to be wrapped internally to deal with platform differences. But your right
> in that polling is not the ideal answer. Using Hendriks solution would be
> the preferred option on Windows.
>
>
>> Directly defining pthread_cancel to this seems risky, as someone might
>> introduce such a call at another place at some point without
>> realizing.
>> I would probably feel better to directly see that code where its meant to
>> go.
>>
>
> Fair enough
>
> In general I agree with Nicolas, split the ifdef renames and the win32
>> compat into two patches, that way its much clearer whats actually
>> going on in the patch.
>>
>
> the ifdef changes arent necessary and it doesnt bother me if they were
> there or not. I just put them in incase someone in the future got confused
> as to how pthread_cancel was enabled on win32. So to be honest im happy
> leaving things without any ifdef changes unless someone else requests it.
>
> I hope the final version would get some cosmetic cleanup.
>>
>
> What would you like to see?
>
> Also, in this version you are closing the socket twice, once here in
>> pthread_cancel() and once in the code after the call to
>> pthread_cancel(). On Unix, that would be a big no. On windows I do not
>> know. I would prefer if the normal code path still calls close() only
>> after joining the thread, since concurrent uses of the same socket are
>> not well specified.
>>
>
> I was trying to find a suitable way to only call closesocket inplace of
> pthread_cancel on windows as for all other systems the closesocket still
> should be after the pthread_join, and to do that with minimal changes. This
> seems as clean and minimal as i can get it at the moment:
>
> ---
>  libavformat/udp.c | 31 +++
>  1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 3835f98..0e4766f 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -60,14 +60,22 @@
>  #define IPPROTO_UDPLITE  136
>  #endif
>
> -#if HAVE_PTHREAD_CANCEL
> -#include 
> -#endif
> -
>  #ifndef HAVE_PTHREAD_CANCEL
>  #define HAVE_PTHREAD_CANCEL 0
>  #endif
>
> +#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
> +/* Winsock2 recv function can be unblocked by shutting down and closing
> the socket */
> +#define pthread_setcancelstate(x, y)
> +#define pthread_cancel
> +#undef HAVE_PTHREAD_CANCEL
> +#define HAVE_PTHREAD_CANCEL 1
> +#endif
> +
> +#if HAVE_PTHREAD_CANCEL
> +#include "libavutil/thread.h"
> +#endif
> +
>  #ifndef IPV6_ADD_MEMBERSHIP
>  #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
>  #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
> @@ -1144,8 +1152,14 @@ static int udp_close(URLContext *h)
>  if (s->thread_started) {
>  int ret;
>  // Cancel only read, as write has been signaled as success to the
> user
> -if (h->flags & AVIO_FLAG_READ)
> +if (h->flags & AVIO_FLAG_READ) {
> +#   if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
> +closesocket(s->udp_fd);
> +s->udp_fd = INVALID_SOCKET;
> +#   else
>  pthread_cancel(s->circular_buffer_thread);
> +#   endif
> +}
>  ret = pthread_join(s->circular_buffer_thread, NULL);
>  if (ret != 0)
>  av_log(h, AV_LOG_ERROR, "pthread_join(): %s\n",
> strerror(ret));
> @@ -1153,7 +1167,8 @@ static int udp_close(URLContext *h)
>  pthread_cond_destroy(>cond);
>  }
>  #endif
> -closesocket(s->udp_fd);
> +if(s->udp_fd != INVALID_SOCKET)
> +closesocket(s->udp_fd);
>  av_fifo_freep(>fifo);
>  return 0;
>  }
> --
>

Ive reupped the current versions of each seperated patch for comment
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix build with LibreSSL

[Matt Oliver]

On 30 October 2016 at 17:57, Michael Forney <mfor...@mforney.org> wrote:

> On 10/29/16, Matt Oliver <protogo...@gmail.com> wrote:
> > This also seems a bit odd, why is libreSSL setting an openssl version
> > number of 1.1.0 or higher when it doesnt actually conform to the
> > corresponding openssl version. LibreSSl setting the openssl version
> number
> > to 2.0.0 seems to be problematic and causes problems not just for ffmpeg.
> > Of course theres not much we can do about that but perhaps an alternative
> > to Michaels suggestion would be to just add a single check near the top
> of
> > the file that checks for libressl and then redefines the openssl version
> to
> > the api libressl actually supports. i.e.
> >
> > #ifdef LIBRESSL_VERSION_NUMBER
> > #undef OPENSSL_VERSION_NUMBER
> > #define OPENSSL_VERSION_NUMBER 0x1000107fL
> > #endif
> >
> > This I believe is what some other projects have done to avoid this issue
> > and is rather simple to add and prevents further clutter in our
> configure.
> > I dont have any preference between this and the other suggestion, im just
> > providing some alternatives. The above is pretty simple so if it works
> for
> > you i can write up a patch for that pretty easily.
>
> I'm not sure why libressl sets OPENSSL_VERSION_NUMBER to 0x2000L.
> Maybe so that they can pick and choose which openssl APIs to implement
> (rather than everything up through some version)?
>
> I'm fine with any of the suggested approaches. I just went with
> !defined(LIBRESSL_VERSION_NUMBER) in my original patch because that's
> what I've seen projects like curl, wpa_supplicant, and openvpn do. It
> also seems to be what openbsd is doing itself with patches in its
> ports tree (xca, stunnel, postfix).
>

Something should actually be done about this. Im fine with the original
patch but the blocker seems to have been Michael. Im not such a huge fan of
cluttering configure and slowing it down more for a small issue (as there
could get progressively more and more difference between the 2 projects) so
as an inbetween what about creating HAVE_BIO_METHODS but do so only locally
in tls_openssl using something like:

#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
NUMBER)
#define HAVE_BIO_METHODS_WHATEVER 1
#else
#define HAVE_BIO_METHODS_WHATEVER 0
#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Matt Oliver]

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 libavformat/udp.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index f8c861d..0e4766f 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -64,6 +64,14 @@
 #define HAVE_PTHREAD_CANCEL 0
 #endif

+#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
+/* Winsock2 recv function can be unblocked by shutting down and closing
the socket */
+#define pthread_setcancelstate(x, y)
+#define pthread_cancel
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
 #if HAVE_PTHREAD_CANCEL
 #include "libavutil/thread.h"
 #endif
@@ -1144,8 +1152,14 @@ static int udp_close(URLContext *h)
 if (s->thread_started) {
 int ret;
 // Cancel only read, as write has been signaled as success to the
user
-if (h->flags & AVIO_FLAG_READ)
+if (h->flags & AVIO_FLAG_READ) {
+#   if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
+closesocket(s->udp_fd);
+s->udp_fd = INVALID_SOCKET;
+#   else
 pthread_cancel(s->circular_buffer_thread);
+#   endif
+}
 ret = pthread_join(s->circular_buffer_thread, NULL);
 if (ret != 0)
 av_log(h, AV_LOG_ERROR, "pthread_join(): %s\n", strerror(ret));
@@ -1153,7 +1167,8 @@ static int udp_close(URLContext *h)
 pthread_cond_destroy(>cond);
 }
 #endif
-closesocket(s->udp_fd);
+if(s->udp_fd != INVALID_SOCKET)
+closesocket(s->udp_fd);
 av_fifo_freep(>fifo);
 return 0;
 }
-- 
2.10.2.windows.1


0003-avformat-udp-Enable-FIFO-when-using-windows-sockets.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avformat/udp: Use avutil compat pthread_cond_timedwait.

[Matt Oliver]

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 libavformat/udp.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 3835f98..f8c861d 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -60,14 +60,14 @@
 #define IPPROTO_UDPLITE  136
 #endif

-#if HAVE_PTHREAD_CANCEL
-#include 
-#endif
-
 #ifndef HAVE_PTHREAD_CANCEL
 #define HAVE_PTHREAD_CANCEL 0
 #endif

+#if HAVE_PTHREAD_CANCEL
+#include "libavutil/thread.h"
+#endif
+
 #ifndef IPV6_ADD_MEMBERSHIP
 #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
 #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
@@ -1054,9 +1054,9 @@ static int udp_read(URLContext *h, uint8_t *buf, int
size)
 int64_t t = av_gettime() + 10;
 struct timespec tv = { .tv_sec  =  t / 100,
.tv_nsec = (t % 100) * 1000 };
-if (pthread_cond_timedwait(>cond, >mutex, ) < 0) {
+if (ret = pthread_cond_timedwait(>cond, >mutex, )
< 0) {
 pthread_mutex_unlock(>mutex);
-return AVERROR(errno == ETIMEDOUT ? EAGAIN : errno);
+return AVERROR(ret == ETIMEDOUT ? EAGAIN : ret);
 }
 nonblock = 1;
 }
-- 
2.10.2.windows.1


0002-avformat-udp-Use-avutil-compat-pthread_cond_timedwai.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] avutil/thread: Add pthread_cond_timedwait function.

[Matt Oliver]

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 compat/os2threads.h  | 24 
 compat/w32pthreads.h | 50
++
 libavutil/thread.h   |  6 ++
 3 files changed, 80 insertions(+)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index 40a119f..a8b7824 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -31,11 +31,13 @@

 #undef __STRICT_ANSI__  /* for _beginthread() */
 #include 
+#include 

 #include 
 #include 

 #include "libavutil/attributes.h"
+#include "libavutil/time.h"

 typedef struct {
 TID tid;
@@ -161,6 +163,28 @@ static av_always_inline int
pthread_cond_broadcast(pthread_cond_t *cond)
 return 0;
 }

+static av_always_inline int pthread_cond_timedwait(pthread_cond_t *cond,
+   pthread_mutex_t *mutex,
+   const struct timespec
*abstime)
+{
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+ULONG t = FFMAX(abs_milli - av_gettime(), 0LL);
+
+__atomic_increment(>wait_count);
+
+pthread_mutex_unlock(mutex);
+
+APIRET ret = DosWaitEventSem(cond->event_sem, t);
+
+__atomic_decrement(>wait_count);
+
+DosPostEventSem(cond->ack_sem);
+
+pthread_mutex_lock(mutex);
+
+return (ret == ERROR_TIMEOUT) ? ETIMEDOUT : 0;
+}
+
 static av_always_inline int pthread_cond_wait(pthread_cond_t *cond,
   pthread_mutex_t *mutex)
 {
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 4ac2a99..abd54b2 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -38,6 +38,7 @@
 #define WIN32_LEAN_AND_MEAN
 #include 
 #include 
+#include 

 #if _WIN32_WINNT < 0x0600 && defined(__MINGW32__)
 #undef MemoryBarrier
@@ -48,6 +49,7 @@
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
 #include "libavutil/mem.h"
+#include "libavutil/time.h"

 typedef struct pthread_t {
 void *handle;
@@ -171,6 +173,17 @@ static inline int pthread_cond_wait(pthread_cond_t
*cond, pthread_mutex_t *mutex
 return 0;
 }

+static inline int pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+ const struct timespec *abstime)
+{
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
+
+if (SleepConditionVariableCS(cond, mutex, t) == WAIT_TIMEOUT)
+return ETIMEDOUT;
+return 0;
+}
+
 static inline int pthread_cond_signal(pthread_cond_t *cond)
 {
 WakeConditionVariable(cond);
@@ -367,6 +380,43 @@ static av_unused int pthread_cond_wait(pthread_cond_t
*cond, pthread_mutex_t *mu
 return pthread_mutex_lock(mutex);
 }

+static inline int pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+ const struct timespec *abstime)
+{
+win32_cond_t *win32_cond = cond->Ptr;
+int last_waiter;
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
+if (cond_wait) {
+cond_wait(cond, mutex, t);
+return 0;
+}
+
+/* non native condition variables */
+pthread_mutex_lock(_cond->mtx_broadcast);
+pthread_mutex_lock(_cond->mtx_waiter_count);
+win32_cond->waiter_count++;
+pthread_mutex_unlock(_cond->mtx_waiter_count);
+pthread_mutex_unlock(_cond->mtx_broadcast);
+
+// unlock the external mutex
+pthread_mutex_unlock(mutex);
+DWORD ret = WaitForSingleObject(win32_cond->semaphore, t);
+
+pthread_mutex_lock(_cond->mtx_waiter_count);
+win32_cond->waiter_count--;
+last_waiter = !win32_cond->waiter_count || !win32_cond->is_broadcast;
+pthread_mutex_unlock(_cond->mtx_waiter_count);
+
+if (last_waiter)
+SetEvent(win32_cond->waiters_done);
+
+// lock the external mutex
+pthread_mutex_lock(mutex);
+
+return (ret == WAIT_TIMEOUT) ? ETIMEDOUT : 0;
+}
+
 static av_unused int pthread_cond_signal(pthread_cond_t *cond)
 {
 win32_cond_t *win32_cond = cond->Ptr;
diff --git a/libavutil/thread.h b/libavutil/thread.h
index 32ddf40..9d611f2 100644
--- a/libavutil/thread.h
+++ b/libavutil/thread.h
@@ -108,6 +108,12 @@ static inline int
strict_pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t
 ASSERT_PTHREAD(pthread_cond_wait, cond, mutex);
 }

+static inline int strict_pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+const struct timespec
*abstime)
+{
+ASSERT_PTHREAD(pthread_cond_timedwait, cond, mutex, abstime);
+}
+
 static inline int strict_pthread_once(pthread_once_t *once_control, void
(*init_routine)(void))
 {
 ASSERT_PTHREAD(pt

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

>
> Indeed, in theory that would work. I always forget about these options.
> In my experience they do not work reliably, and I would argue against
> their use in portable code. For example, starting there:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html
> can you tell me the type of the arguments to SO_RCVTIMEO? I know Linux
> man page tells us it is struct timeval, but that is not a portable
> standard.
>
> Also, these options are just a band aid to implement polling.


the same function on windows would take a int64 so the function would have
to be wrapped internally to deal with platform differences. But your right
in that polling is not the ideal answer. Using Hendriks solution would be
the preferred option on Windows.


> Directly defining pthread_cancel to this seems risky, as someone might
> introduce such a call at another place at some point without
> realizing.
> I would probably feel better to directly see that code where its meant to
> go.
>

Fair enough

In general I agree with Nicolas, split the ifdef renames and the win32
> compat into two patches, that way its much clearer whats actually
> going on in the patch.
>

the ifdef changes arent necessary and it doesnt bother me if they were
there or not. I just put them in incase someone in the future got confused
as to how pthread_cancel was enabled on win32. So to be honest im happy
leaving things without any ifdef changes unless someone else requests it.

I hope the final version would get some cosmetic cleanup.
>

What would you like to see?

Also, in this version you are closing the socket twice, once here in
> pthread_cancel() and once in the code after the call to
> pthread_cancel(). On Unix, that would be a big no. On windows I do not
> know. I would prefer if the normal code path still calls close() only
> after joining the thread, since concurrent uses of the same socket are
> not well specified.
>

I was trying to find a suitable way to only call closesocket inplace of
pthread_cancel on windows as for all other systems the closesocket still
should be after the pthread_join, and to do that with minimal changes. This
seems as clean and minimal as i can get it at the moment:

---
 libavformat/udp.c | 31 +++
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 3835f98..0e4766f 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -60,14 +60,22 @@
 #define IPPROTO_UDPLITE  136
 #endif

-#if HAVE_PTHREAD_CANCEL
-#include 
-#endif
-
 #ifndef HAVE_PTHREAD_CANCEL
 #define HAVE_PTHREAD_CANCEL 0
 #endif

+#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
+/* Winsock2 recv function can be unblocked by shutting down and closing
the socket */
+#define pthread_setcancelstate(x, y)
+#define pthread_cancel
+#undef HAVE_PTHREAD_CANCEL
+#define HAVE_PTHREAD_CANCEL 1
+#endif
+
+#if HAVE_PTHREAD_CANCEL
+#include "libavutil/thread.h"
+#endif
+
 #ifndef IPV6_ADD_MEMBERSHIP
 #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
 #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
@@ -1144,8 +1152,14 @@ static int udp_close(URLContext *h)
 if (s->thread_started) {
 int ret;
 // Cancel only read, as write has been signaled as success to the
user
-if (h->flags & AVIO_FLAG_READ)
+if (h->flags & AVIO_FLAG_READ) {
+#   if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
+closesocket(s->udp_fd);
+s->udp_fd = INVALID_SOCKET;
+#   else
 pthread_cancel(s->circular_buffer_thread);
+#   endif
+}
 ret = pthread_join(s->circular_buffer_thread, NULL);
 if (ret != 0)
 av_log(h, AV_LOG_ERROR, "pthread_join(): %s\n", strerror(ret));
@@ -1153,7 +1167,8 @@ static int udp_close(URLContext *h)
 pthread_cond_destroy(>cond);
 }
 #endif
-closesocket(s->udp_fd);
+if(s->udp_fd != INVALID_SOCKET)
+closesocket(s->udp_fd);
 av_fifo_freep(>fifo);
 return 0;
 }
--
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

On 3 December 2016 at 23:40, Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Sat, Dec 3, 2016 at 1:33 PM, Matt Oliver <protogo...@gmail.com> wrote:
> >
> > I havent fully tested Hendriks idea as the msdn docs dont recommend
> calling
> > multiple winsock functions at the same time from different threads so i
> > wasnt sure about how well received a patch that relies on closesocket to
> > unblock the recv function would be received (although i have seen it
> > extensively used without issuers). If Hendrik has tested this though with
> > his local patch without issues then I would accept that as a solution to
> > fixing my issue. ping Hendrik!
>
> I don't really use UDP streaming on a regular basis, but I did test
> this approach when I build it, and it works just fine.
> What I did was basically just define pthread_cancel/setcancelstate to
> empty in udp.c (and define HAVE_PTHREAD_CANCEL in that file to enable
> the code) and re-shuffle the udp_close code to close the socket to
> unblock the thread before waiting for it to exit.
>
> I don't have a clean and finished patch to go, because I had no real
> interest in it working on other platforms, so its rather ugly. But the
> approach is rather simple.


Would something like the following work for you:

---
 libavformat/udp.c | 46 +-
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 3835f98..a30918b 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -60,14 +60,26 @@
 #define IPPROTO_UDPLITE  136
 #endif

-#if HAVE_PTHREAD_CANCEL
-#include 
-#endif
-
 #ifndef HAVE_PTHREAD_CANCEL
 #define HAVE_PTHREAD_CANCEL 0
 #endif

+#if HAVE_PTHREAD_CANCEL || (HAVE_THREADS && HAVE_WINSOCK2_H)
+#define THREAD_RXRW 1
+#else
+#define THREAD_RXRW 0
+#endif
+
+#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
+/* Winsock2 recv function can be unblocked by shutting down and closing
the socket */
+#define pthread_setcancelstate(x, y)
+#define pthread_cancel {shutdown(s->udp_fd, SD_BOTH);
closesocket(s->udp_fd);}
+#endif
+
+#if THREAD_RXRW
+#include "libavutil/thread.h"
+#endif
+
 #ifndef IPV6_ADD_MEMBERSHIP
 #define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
 #define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
@@ -100,7 +112,7 @@ typedef struct UDPContext {
 int64_t bitrate; /* number of bits to send per second */
 int64_t burst_bits;
 int close_req;
-#if HAVE_PTHREAD_CANCEL
+#if THREAD_RXRW
 pthread_t circular_buffer_thread;
 pthread_mutex_t mutex;
 pthread_cond_t cond;
@@ -495,7 +507,7 @@ static int udp_get_file_handle(URLContext *h)
 return s->udp_fd;
 }

-#if HAVE_PTHREAD_CANCEL
+#if THREAD_RXRW
 static void *circular_buffer_task_rx( void *_URLContext)
 {
 URLContext *h = _URLContext;
@@ -730,7 +742,7 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
 /* assume if no digits were found it is a request to enable it
*/
 if (buf == endptr)
 s->overrun_nonfatal = 1;
-if (!HAVE_PTHREAD_CANCEL)
+if (!THREAD_RXRW)
 av_log(h, AV_LOG_WARNING,
"'overrun_nonfatal' option was set but it is not
supported "
"on this build (pthread support is required)\n");
@@ -758,14 +770,14 @@ static int udp_open(URLContext *h, const char *uri,
int flags)
 }
 if (av_find_info_tag(buf, sizeof(buf), "fifo_size", p)) {
 s->circular_buffer_size = strtol(buf, NULL, 10);
-if (!HAVE_PTHREAD_CANCEL)
+if (!THREAD_RXRW)
 av_log(h, AV_LOG_WARNING,
"'circular_buffer_size' option was set but it is
not supported "
"on this build (pthread support is required)\n");
 }
 if (av_find_info_tag(buf, sizeof(buf), "bitrate", p)) {
 s->bitrate = strtoll(buf, NULL, 10);
-if (!HAVE_PTHREAD_CANCEL)
+if (!THREAD_RXRW)
 av_log(h, AV_LOG_WARNING,
"'bitrate' option was set but it is not supported "
"on this build (pthread support is required)\n");
@@ -951,7 +963,7 @@ static int udp_open(URLContext *h, const char *uri, int
flags)

 s->udp_fd = udp_fd;

-#if HAVE_PTHREAD_CANCEL
+#if THREAD_RXRW
 /*
   Create thread in case of:
   1. Input and circular_buffer_size is set
@@ -988,7 +1000,7 @@ static int udp_open(URLContext *h, const char *uri,
int flags)
 #endif

 return 0;
-#if HAVE_PTHREAD_CANCEL
+#if THREAD_RXRW
  thread_fail:
 pthread_cond_destroy(>cond);
  cond_fail:
@@ -1019,7 +1031,7 @@ static int udp_read(URLContext *h, uint8_t *buf, i

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

On 3 December 2016 at 22:33, Nicolas George <geo...@nsup.org> wrote:

> Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit :
> > I was just writing an email to rephrase but you beet me to it (sorry i
> > wasnt faster)
>
> No problem.
>
> > I should rephrase this to "Why is polling with an acceptable
> timeout/sleep
> > not acceptable". Obviously a event based callback would be more efficient
> > but wouldnt setting an appropriate recv timeout then checking for thread
> > exit before looping the recv call be an acceptable compromise. The thread
> > exit check is minimal and if not set it would just go back into the
> > blocking recv until data is received or the timeout triggers again. Long
> > term callbacks would be better but would this be acceptable short term.
>
> What would you consider an appropriate timeout, more precisely?
>

Thats the trick, not to large that it results noticeable shutdown delays to
the user but not to quick that it polls to often, on a modern machine id
think something like 0.01s would be ok.


> First, I would like to remind you that you cannot block with a timeout,
> you would have to rework the code to use the ill-named poll(), which
> would bring it back to its state before the use of pthread_cancel().
>

I was thinking of just using setsockopt to set a value for SO_RCVTIMEO only
in circular_buffer_task_rx. That way recv will timeout at the specified
interval which will then use the existing code that checks the recv return.
In case of timeout that check will continue back to top of loop that will
have the s->close_req check to terminate the thread if needed.
something like:

+  setsockopt(s->udp_fd, SOL_SOCKET, SO_RCVTIMEO, ,
sizeof(timeout));
while(1) {
int len;
+  if (s->close_req)
+  goto end;
pthread_mutex_unlock(>mutex);
len = recv(s->udp_fd, s->tmp+4, sizeof(s->tmp)-4, 0);
pthread_mutex_lock(>mutex);
if (len < 0) {
if (ff_neterrno() != AVERROR(EAGAIN) && ff_neterrno() !=
AVERROR(EINTR)) {
s->circular_buffer_error = ff_neterrno();
goto end;
}
continue;
}

>
>
> You are right that it would take care of the latency problem of the
> network side, and allow a long timeout. But the latency is a problem too
> for the cancellation. We had a 3 seconds timeout, users did get
> impatient and interrupted it forcefully.
>
> Furthermore, the core of your argument is that "the thread exit check is
> minimal", but as I explained, it is not on embedded devices: anything
> except "block until the kernel wakes up" is too much because it prevents
> deep sleep states and drains the battery.
>

So perhaps keep the existing pthread_cancel functionality and add in the
changes only when pthread_cancel is not available. The user can always
choose not to use the thread stuff if they dont like it by not setting a
fifo_size option etc.

Modern operating systems allow multi-peer applications to work in a
> completely poll-free completely notification-based way. FFmpeg, based on
> very old code without global design, is quite far from achieving that.
> But moving away from that is definitely moving in the wrong direction.
>

Is anyone working on that as your right i definitely think an event system
for all protocols is the best option. Its just that has a larger scope than
i can handle so i was trying to get a simple shorter term fix for udp.

I assume you are not working just on a general distaste about
> pthread_cancel(): you have in mind a specific platform in mind where it
> is not available and you need the UDP thread, have you not?
>

Yep, although im not a huge fan of pthread_cancel, im mainly just trying to
improve functionality with msvc.

Then I suggest working for that platform: find a way of implementing a
> poll-free delay-free interruption mechanism. Maybe using non-portable
> properties of the platform (like closing on another thread like Hendrik
> evoked) or an entirely different API.
>

I havent fully tested Hendriks idea as the msdn docs dont recommend calling
multiple winsock functions at the same time from different threads so i
wasnt sure about how well received a patch that relies on closesocket to
unblock the recv function would be received (although i have seen it
extensively used without issuers). If Hendrik has tested this though with
his local patch without issues then I would accept that as a solution to
fixing my issue. ping Hendrik!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

On 3 December 2016 at 22:05, Nicolas George <geo...@nsup.org> wrote:

> Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit :
> > That was because the pthread wrappers dont set errno, so its a required
> > change to remove dependency on pthread.
>
> The pthread wrappers are supposed to match the pthread API, and it does
> not use errno: this change is needed by itself.
>
> > Your right i misread the use of ff_socket_nonblock so an extra change
> would
> > need to be added to set that to nonblocking instead. Theres already code
> > after the recv call that checks if any data was read back and just loops
> if
> > there wasnt any available which implements polling (should it be in
> > nonblocking mode). So thats why i assumed nonblocking was acceptable
>
> Looping is necessary in case of interrupted system calls; the code is
> overly careful by testing EAGAIN too.
>
> > Just out of curiosity why is polling considered unacceptable?
>
> It is awfully inefficient.
>
> If the polling interval is large, it adds latency to the processing. If
> it is short, it becomes a resource drain. Multimedia application often
> require low latency.
>
> You may think that a 100 Hz polling will have low latency enough for
> most uses and still be a negligible power drain, and thinking about PC
> applications you would probably be right. But think of a player on an
> embedded device reading a network stream that got interrupted. Since it
> is no longer playing, you do not pay attention to it, and you do not
> realize the player is still there, polling the network to see if it
> comes back. As a consequence, the CPU cannot enter deep-sleep state, and
> your battery in drained in a few hours.
>
> And of course, if someone were to just turn the socket non-blocking,
> since the loop does not have a timer in it, it becomes the ultimate form
> of polling evil: busy wait, and this is a terrible power drain even on
> huge PCs.
>
> FFmpeg uses polling all over the place, but fortunately, with just the
> UDP streams it can be entirely avoided. Eliminating all polling is
> amongst my long-term projects.
>

I was just writing an email to rephrase but you beet me to it (sorry i
wasnt faster)

I should rephrase this to "Why is polling with an acceptable timeout/sleep
not acceptable". Obviously a event based callback would be more efficient
but wouldnt setting an appropriate recv timeout then checking for thread
exit before looping the recv call be an acceptable compromise. The thread
exit check is minimal and if not set it would just go back into the
blocking recv until data is received or the timeout triggers again. Long
term callbacks would be better but would this be acceptable short term.


>
> >  As i understand it pthread_cancel implements polling internally anyway
> as
> > any blocking function performed in the rx thread has to periodically
> check
> > the status of pthread_cancel to see if it has been set from another
> thread.
>
> I believe you are wrong. The core property of pthread_cancel(), which
> you can not emulate portably with other functions, is that it interrupts
> blocking system calls like recv(). It is implemented internally with
> non-portable notification techniques: a specific signal on Linux if I
> read correctly.


Again i was about to correct myself but you beet me to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

On 2 December 2016 at 22:16, Nicolas George <geo...@nsup.org> wrote:

> Le duodi 12 frimaire, an CCXXV, Matt Oliver a écrit :
> > ---
> >  configure |  6 --
> >  libavformat/udp.c | 48 +++-
> >  2 files changed, 19 insertions(+), 35 deletions(-)
>
> It looks like there are unrelated changes in this patch.
>

Which changes would those be? all of them are just what is required to
enable threading on non posix systems with pthread_cancel


> Can you explain how it achieves the same result as pthread_cancel()? It
> looks to me it does not.
>

For one currently pthread_cancel is only called for the read thread which
uses the circular_buffer_task_rx function. pthread_cancel is never called
on the transmit thread so the pthread_setcancelstate calls in
circular_buffer_task_tx dont actually do anything. In fact the pthread
cancel state is only enabled in the rx function on either side of the recv
function. This function is already set as nonblocking and so it wont hold
up the thread which can then continue back to the s->close_req check and
terminate cleanly. So functionally I dont think the the pthread_cancel
functionality is even needed as I dont think there is any advantage to
having it and removing it allows the functionality to be enabled on more
systems.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avutil/thread: Add pthread_cond_timedwait function.

[Matt Oliver]

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 compat/os2threads.h  | 24 
 compat/w32pthreads.h | 50
++
 libavutil/thread.h   |  6 ++
 3 files changed, 80 insertions(+)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index 40a119f..a8b7824 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -31,11 +31,13 @@

 #undef __STRICT_ANSI__  /* for _beginthread() */
 #include 
+#include 

 #include 
 #include 

 #include "libavutil/attributes.h"
+#include "libavutil/time.h"

 typedef struct {
 TID tid;
@@ -161,6 +163,28 @@ static av_always_inline int
pthread_cond_broadcast(pthread_cond_t *cond)
 return 0;
 }

+static av_always_inline int pthread_cond_timedwait(pthread_cond_t *cond,
+   pthread_mutex_t *mutex,
+   const struct timespec
*abstime)
+{
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+ULONG t = FFMAX(abs_milli - av_gettime(), 0LL);
+
+__atomic_increment(>wait_count);
+
+pthread_mutex_unlock(mutex);
+
+APIRET ret = DosWaitEventSem(cond->event_sem, t);
+
+__atomic_decrement(>wait_count);
+
+DosPostEventSem(cond->ack_sem);
+
+pthread_mutex_lock(mutex);
+
+return (ret == ERROR_TIMEOUT) ? ETIMEDOUT : 0;
+}
+
 static av_always_inline int pthread_cond_wait(pthread_cond_t *cond,
   pthread_mutex_t *mutex)
 {
diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 4ac2a99..abd54b2 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -38,6 +38,7 @@
 #define WIN32_LEAN_AND_MEAN
 #include 
 #include 
+#include 

 #if _WIN32_WINNT < 0x0600 && defined(__MINGW32__)
 #undef MemoryBarrier
@@ -48,6 +49,7 @@
 #include "libavutil/common.h"
 #include "libavutil/internal.h"
 #include "libavutil/mem.h"
+#include "libavutil/time.h"

 typedef struct pthread_t {
 void *handle;
@@ -171,6 +173,17 @@ static inline int pthread_cond_wait(pthread_cond_t
*cond, pthread_mutex_t *mutex
 return 0;
 }

+static inline int pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+ const struct timespec *abstime)
+{
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
+
+if (SleepConditionVariableCS(cond, mutex, t) == WAIT_TIMEOUT)
+return ETIMEDOUT;
+return 0;
+}
+
 static inline int pthread_cond_signal(pthread_cond_t *cond)
 {
 WakeConditionVariable(cond);
@@ -367,6 +380,43 @@ static av_unused int pthread_cond_wait(pthread_cond_t
*cond, pthread_mutex_t *mu
 return pthread_mutex_lock(mutex);
 }

+static inline int pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+ const struct timespec *abstime)
+{
+win32_cond_t *win32_cond = cond->Ptr;
+int last_waiter;
+int64_t abs_milli = abstime->tv_nsec * 1000LL + abstime->tv_nsec /
1.0e6;
+DWORD t = FFMAX(abs_milli - av_gettime(), 0LL);
+if (cond_wait) {
+cond_wait(cond, mutex, t);
+return 0;
+}
+
+/* non native condition variables */
+pthread_mutex_lock(_cond->mtx_broadcast);
+pthread_mutex_lock(_cond->mtx_waiter_count);
+win32_cond->waiter_count++;
+pthread_mutex_unlock(_cond->mtx_waiter_count);
+pthread_mutex_unlock(_cond->mtx_broadcast);
+
+// unlock the external mutex
+pthread_mutex_unlock(mutex);
+DWORD ret = WaitForSingleObject(win32_cond->semaphore, t);
+
+pthread_mutex_lock(_cond->mtx_waiter_count);
+win32_cond->waiter_count--;
+last_waiter = !win32_cond->waiter_count || !win32_cond->is_broadcast;
+pthread_mutex_unlock(_cond->mtx_waiter_count);
+
+if (last_waiter)
+SetEvent(win32_cond->waiters_done);
+
+// lock the external mutex
+pthread_mutex_lock(mutex);
+
+return (ret == WAIT_TIMEOUT) ? ETIMEDOUT : 0;
+}
+
 static av_unused int pthread_cond_signal(pthread_cond_t *cond)
 {
 win32_cond_t *win32_cond = cond->Ptr;
diff --git a/libavutil/thread.h b/libavutil/thread.h
index 32ddf40..9d611f2 100644
--- a/libavutil/thread.h
+++ b/libavutil/thread.h
@@ -108,6 +108,12 @@ static inline int
strict_pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t
 ASSERT_PTHREAD(pthread_cond_wait, cond, mutex);
 }

+static inline int strict_pthread_cond_timedwait(pthread_cond_t *cond,
pthread_mutex_t *mutex,
+const struct timespec
*abstime)
+{
+ASSERT_PTHREAD(pthread_cond_timedwait, cond, mutex, abstime);
+}
+
 static inline int strict_pthread_once(pthread_once_t *once_control, void
(*init_routine)(void))
 {
 ASSERT_PTHREAD(pt

[FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Matt Oliver]

---
 configure |  6 --
 libavformat/udp.c | 48 +++-
 2 files changed, 19 insertions(+), 35 deletions(-)

diff --git a/configure b/configure
index b5bfad6..cec94c4 100755
--- a/configure
+++ b/configure
@@ -1934,7 +1934,6 @@ SYSTEM_FUNCS="
 nanosleep
 PeekNamedPipe
 posix_memalign
-pthread_cancel
 sched_getaffinity
 SetConsoleTextAttribute
 SetConsoleCtrlHandler
@@ -5623,11 +5622,6 @@ if ! disabled pthreads && ! enabled w32threads && !
enabled os2threads; then
 check_code cc "pthread.h" "static pthread_mutex_t atomic_lock =
PTHREAD_MUTEX_INITIALIZER" || disable pthreads
 fi

-
-if enabled pthreads; then
-  check_func pthread_cancel
-fi
-
 enabled pthreads &&
 check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0);
sem_timedwait(s,0); sem_destroy(s)"

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 3835f98..857a979 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -60,12 +60,8 @@
 #define IPPROTO_UDPLITE  136
 #endif

-#if HAVE_PTHREAD_CANCEL
-#include 
-#endif
-
-#ifndef HAVE_PTHREAD_CANCEL
-#define HAVE_PTHREAD_CANCEL 0
+#if HAVE_THREADS
+#include "libavutil/thread.h"
 #endif

 #ifndef IPV6_ADD_MEMBERSHIP
@@ -100,7 +96,7 @@ typedef struct UDPContext {
 int64_t bitrate; /* number of bits to send per second */
 int64_t burst_bits;
 int close_req;
-#if HAVE_PTHREAD_CANCEL
+#if HAVE_THREADS
 pthread_t circular_buffer_thread;
 pthread_mutex_t mutex;
 pthread_cond_t cond;
@@ -495,14 +491,13 @@ static int udp_get_file_handle(URLContext *h)
 return s->udp_fd;
 }

-#if HAVE_PTHREAD_CANCEL
+#if HAVE_THREADS
 static void *circular_buffer_task_rx( void *_URLContext)
 {
 URLContext *h = _URLContext;
 UDPContext *s = h->priv_data;
 int old_cancelstate;

-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
 pthread_mutex_lock(>mutex);
 if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
 av_log(h, AV_LOG_ERROR, "Failed to set blocking mode");
@@ -511,14 +506,11 @@ static void *circular_buffer_task_rx( void
*_URLContext)
 }
 while(1) {
 int len;
+if (s->close_req)
+goto end;

 pthread_mutex_unlock(>mutex);
-/* Blocking operations are always cancellation points;
-   see "General Information" / "Thread Cancelation Overview"
-   in Single Unix. */
-pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, _cancelstate);
 len = recv(s->udp_fd, s->tmp+4, sizeof(s->tmp)-4, 0);
-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
 pthread_mutex_lock(>mutex);
 if (len < 0) {
 if (ff_neterrno() != AVERROR(EAGAIN) && ff_neterrno() !=
AVERROR(EINTR)) {
@@ -564,7 +556,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
 int64_t burst_interval = s->bitrate ? (s->burst_bits * 100 /
s->bitrate) : 0;
 int64_t max_delay = s->bitrate ?  ((int64_t)h->max_packet_size * 8 *
100 / s->bitrate + 1) : 0;

-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
 pthread_mutex_lock(>mutex);

 if (ff_socket_nonblock(s->udp_fd, 0) < 0) {
@@ -599,7 +590,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
 av_fifo_generic_read(s->fifo, s->tmp, len, NULL);

 pthread_mutex_unlock(>mutex);
-pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, _cancelstate);

 if (s->bitrate) {
 timestamp = av_gettime_relative();
@@ -645,7 +635,6 @@ static void *circular_buffer_task_tx( void *_URLContext)
 }
 }

-pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
 pthread_mutex_lock(>mutex);
 }

@@ -730,7 +719,7 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
 /* assume if no digits were found it is a request to enable it
*/
 if (buf == endptr)
 s->overrun_nonfatal = 1;
-if (!HAVE_PTHREAD_CANCEL)
+if (!HAVE_THREADS)
 av_log(h, AV_LOG_WARNING,
"'overrun_nonfatal' option was set but it is not
supported "
"on this build (pthread support is required)\n");
@@ -758,14 +747,14 @@ static int udp_open(URLContext *h, const char *uri,
int flags)
 }
 if (av_find_info_tag(buf, sizeof(buf), "fifo_size", p)) {
 s->circular_buffer_size = strtol(buf, NULL, 10);
-if (!HAVE_PTHREAD_CANCEL)
+if (!HAVE_THREADS)
 av_log(h, AV_LOG_WARNING,
"'circular_buffer_size' option was set but it is
not supported "
"on this build (pthread support is required)\n");
 }
 if (av_find_info_tag(buf, sizeof(buf), "bitrate", p)) {
 s->bitrate = strtoll(buf, NULL, 10);
-if (!HAVE_PTHREAD_CANCEL)
+if (!HAVE_THREADS)
 

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

On 31 October 2016 at 05:30, James Almer <jamr...@gmail.com> wrote:

> On 10/30/2016 8:31 AM, Matt Oliver wrote:
> > From 1dc1f59158cfb12d9160ee47342f5742d67ad864 Mon Sep 17 00:00:00 2001
> > From: Matt Oliver <protogo...@gmail.com>
> > Date: Sun, 30 Oct 2016 15:13:47 +1100
> > Subject: [PATCH] avformat/avisynth.c: Use new safe dlopen code.
> >
> > ---
> >  configure  |  5 ++---
> >  libavformat/avisynth.c | 14 +-
> >  2 files changed, 7 insertions(+), 12 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 5993de5..9feb544 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2850,6 +2850,7 @@ asf_stream_muxer_select="asf_muxer"
> >  avi_demuxer_select="iso_media riffdec exif"
> >  avi_muxer_select="riffenc"
> >  avisynth_demuxer_deps="avisynth"
> > +avisynth_demuxer_deps_any="dlopen LoadLibrary"
> >  avisynth_demuxer_select="riffdec"
>
> With this change and the stuff removed below, avisynth (CONFIG_AVISYNTH)
> will always be enabled if you configure with --enable-avisynth, and only
> avisynth_demuxer will be disabled depending on the presence of dlopen and
> LoadLibrary.
> This is probably not intended, seeing how libavformat/Makefile checks for
> CONFIG_AVISYNTH and not CONFIG_AVISYNTH_DEMUXER in order to compile the
> source file, so you should make it avisynth_deps_any="dlopen LoadLibrary"
> since avisynth_demuxer already depends on avisynth.
>
> Also, consider changing libavformat/Makefile to check for the demuxer
> rather than the library/feature.
>

Changed, I also moved the avisynth stuff up to the external libraries
section of configure


>
> >  caf_demuxer_select="iso_media riffdec"
> >  dash_muxer_select="mp4_muxer"
> > @@ -5417,6 +5418,7 @@ elif check_func dlopen -ldl && check_func dlsym
> -ldl; then
> >  ldl=-ldl
> >  fi
> >
> > +avisynth_demuxer_extralibs='$ldl'
> >  decklink_outdev_extralibs="$decklink_outdev_extralibs $ldl"
> >  decklink_indev_extralibs="$decklink_indev_extralibs $ldl"
> >  frei0r_filter_extralibs='$ldl'
> > @@ -5664,9 +5666,6 @@ fi
> >  enabled avfoundation_indev && { check_header_objcc
> AVFoundation/AVFoundation.h || disable avfoundation_indev; }
> >  enabled avfoundation_indev && { check_lib2 CoreGraphics/CoreGraphics.h
> CGGetActiveDisplayList -framework CoreGraphics ||
> >  check_lib2 
> > ApplicationServices/ApplicationServices.h
> CGGetActiveDisplayList -framework ApplicationServices; }
> > -enabled avisynth  && { { check_lib2 "windows.h" LoadLibrary; }
> ||
> > -   { check_lib2 "dlfcn.h" dlopen -ldl; } ||
> > -   die "ERROR: LoadLibrary/dlopen not found
> for avisynth"; }
> >  enabled cuda  && { check_lib cuda.h cuInit -lcuda ||
> > die "ERROR: CUDA not found"; }
> >  enabled cuvid && { add_cflags -I$source_path;
> > diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> > index 1acc44f..514cb99 100644
> > --- a/libavformat/avisynth.c
> > +++ b/libavformat/avisynth.c
> > @@ -29,7 +29,7 @@
> >
> >  /* Platform-specific directives for AviSynth vs AvxSynth. */
> >  #ifdef _WIN32
> > -  #include 
> > +  #include "compat/w32dlfcn.h"
> >#undef EXTERN_C
> >#include "compat/avisynth/avisynth_c.h"
> >#define AVISYNTH_LIB "avisynth"
> > @@ -39,10 +39,6 @@
> >#include "compat/avisynth/avxsynth_c.h"
> >#define AVISYNTH_NAME "libavxsynth"
> >#define AVISYNTH_LIB AVISYNTH_NAME SLIBSUF
> > -
> > -  #define LoadLibrary(x) dlopen(x, RTLD_NOW | RTLD_LOCAL)
> > -  #define GetProcAddress dlsym
> > -  #define FreeLibrary dlclose
> >  #endif
> >
> >  typedef struct AviSynthLibrary {
> > @@ -118,13 +114,13 @@ static av_cold void avisynth_atexit_handler(void);
> >
> >  static av_cold int avisynth_load_library(void)
> >  {
> > -avs_library.library = LoadLibrary(AVISYNTH_LIB);
> > +avs_library.library = dlopen(AVISYNTH_LIB, RTLD_NOW | RTLD_LOCAL);
> >  if (!avs_library.library)
> >  return AVERROR_UNKNOWN;
> >
> >  #define LOAD_AVS_FUNC(name, continue_on_fail)  \
> >  avs_library.name =
>  \
> > -(void *)GetProcAddress(avs_lib

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

On 30 October 2016 at 20:21, Hendrik Leppkes <h.lepp...@gmail.com> wrote:

> On Sun, Oct 30, 2016 at 5:13 AM, Matt Oliver <protogo...@gmail.com> wrote:
> > On 30 October 2016 at 03:41, Stephen Hutchinson <qyo...@gmail.com>
> wrote:
> >
> >> On 10/29/2016 11:22 AM, Michael Niedermayer wrote:
> >>
> >>> On Sat, Oct 29, 2016 at 06:35:19PM +1100, Matt Oliver wrote:
> >>>
> >>>>  configure  |5 +
> >>>>  libavformat/avisynth.c |   14 +-
> >>>>  2 files changed, 6 insertions(+), 13 deletions(-)
> >>>> b1568f39504e5e14c924d27c8f11ba8f5816d68c
> 0003-avformat-avisynth.c-Use-n
> >>>> ew-safe-dlopen-code.patch
> >>>> From 633212cf1246b3fde61dd6515229e6a893005664 Mon Sep 17 00:00:00
> 2001
> >>>> From: Matt Oliver <protogo...@gmail.com>
> >>>> Date: Sat, 29 Oct 2016 18:25:25 +1100
> >>>> Subject: [PATCH 3/4] avformat/avisynth.c: Use new safe dlopen code.
> >>>>
> >>>
> >>> breaks --enable-avisynth on linux/ubuntu
> >>>
> >>> --- config.h2016-10-29 17:17:55.214014842 +0200
> >>> +++ delth/config.h  2016-10-29 17:15:41.906012034 +0200
> >>> @@ -1155,7 +1155,7 @@
> >>>  #define CONFIG_AST_DEMUXER 1
> >>>  #define CONFIG_AU_DEMUXER 1
> >>>  #define CONFIG_AVI_DEMUXER 1
> >>> -#define CONFIG_AVISYNTH_DEMUXER 1
> >>> +#define CONFIG_AVISYNTH_DEMUXER 0
> >>>  #define CONFIG_AVR_DEMUXER 1
> >>>  #define CONFIG_AVS_DEMUXER 1
> >>>  #define CONFIG_BETHSOFTVID_DEMUXER 1
> >>>
> >>> [...]
> >>>
> >>>
> >> Yeah, libdl needs to be linked to on non-Windows, and the
> >> check for it got removed with the rest of the 'enabled avisynth'
> >> case in configure. Just putting dlopen under avisynth_demuxer_deps
> doesn't
> >> seem to be sufficient for that to work.
> >
> >
> > Looks like I missed a line, my apologies. Updated version attached.
> >
>
> Looking at the configure changes - having a dependency on both dlopen
> and LoadLibrary sounds odd. Shouldn't it be either, not both?
>

Yes, unfortunately i was testing on mingw which has both. Fixed thanks.


0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

On 30 October 2016 at 03:41, Stephen Hutchinson <qyo...@gmail.com> wrote:

> On 10/29/2016 11:22 AM, Michael Niedermayer wrote:
>
>> On Sat, Oct 29, 2016 at 06:35:19PM +1100, Matt Oliver wrote:
>>
>>>  configure  |5 +
>>>  libavformat/avisynth.c |   14 +-
>>>  2 files changed, 6 insertions(+), 13 deletions(-)
>>> b1568f39504e5e14c924d27c8f11ba8f5816d68c  0003-avformat-avisynth.c-Use-n
>>> ew-safe-dlopen-code.patch
>>> From 633212cf1246b3fde61dd6515229e6a893005664 Mon Sep 17 00:00:00 2001
>>> From: Matt Oliver <protogo...@gmail.com>
>>> Date: Sat, 29 Oct 2016 18:25:25 +1100
>>> Subject: [PATCH 3/4] avformat/avisynth.c: Use new safe dlopen code.
>>>
>>
>> breaks --enable-avisynth on linux/ubuntu
>>
>> --- config.h2016-10-29 17:17:55.214014842 +0200
>> +++ delth/config.h  2016-10-29 17:15:41.906012034 +0200
>> @@ -1155,7 +1155,7 @@
>>  #define CONFIG_AST_DEMUXER 1
>>  #define CONFIG_AU_DEMUXER 1
>>  #define CONFIG_AVI_DEMUXER 1
>> -#define CONFIG_AVISYNTH_DEMUXER 1
>> +#define CONFIG_AVISYNTH_DEMUXER 0
>>  #define CONFIG_AVR_DEMUXER 1
>>  #define CONFIG_AVS_DEMUXER 1
>>  #define CONFIG_BETHSOFTVID_DEMUXER 1
>>
>> [...]
>>
>>
> Yeah, libdl needs to be linked to on non-Windows, and the
> check for it got removed with the rest of the 'enabled avisynth'
> case in configure. Just putting dlopen under avisynth_demuxer_deps doesn't
> seem to be sufficient for that to work.


Looks like I missed a line, my apologies. Updated version attached.


0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix build with LibreSSL

[Matt Oliver]

On 30 October 2016 at 09:39, Michael Niedermayer 
wrote:

> On Fri, Oct 28, 2016 at 12:47:08AM -0700, Michael Forney wrote:
> > Signed-off-by: Michael Forney 
> > ---
> >  libavformat/tls_openssl.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> > index c551ac7..9712856 100644
> > --- a/libavformat/tls_openssl.c
> > +++ b/libavformat/tls_openssl.c
> > @@ -43,7 +43,7 @@ typedef struct TLSContext {
> >  TLSShared tls_shared;
> >  SSL_CTX *ctx;
> >  SSL *ssl;
> > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
> NUMBER)
> >  BIO_METHOD* url_bio_method;
> >  #endif
> >  } TLSContext;
> > @@ -68,7 +68,7 @@ static unsigned long openssl_thread_id(void)
> >
> >  static int url_bio_create(BIO *b)
> >  {
> > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
> NUMBER)
> >  BIO_set_init(b, 1);
> >  BIO_set_data(b, NULL);
> >  BIO_set_flags(b, 0);
> > @@ -85,7 +85,7 @@ static int url_bio_destroy(BIO *b)
> >  return 1;
> >  }
> >
> > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
> NUMBER)
> >  #define GET_BIO_DATA(x) BIO_get_data(x);
> >  #else
> >  #define GET_BIO_DATA(x) (x)->ptr;
> > @@ -133,7 +133,7 @@ static int url_bio_bputs(BIO *b, const char *str)
> >  return url_bio_bwrite(b, str, strlen(str));
> >  }
> >
> > -#if OPENSSL_VERSION_NUMBER < 0x101fL
> > +#if OPENSSL_VERSION_NUMBER < 0x101fL || defined(LIBRESSL_VERSION_
> NUMBER)
> >  static BIO_METHOD url_bio_method = {
> >  .type = BIO_TYPE_SOURCE_SINK,
> >  .name = "urlprotocol bio",
> > @@ -212,7 +212,7 @@ static int tls_close(URLContext *h)
> >  SSL_CTX_free(c->ctx);
> >  if (c->tls_shared.tcp)
> >  ffurl_close(c->tls_shared.tcp);
> > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
> NUMBER)
> >  if (c->url_bio_method)
> >  BIO_meth_free(c->url_bio_method);
> >  #endif
> > @@ -265,7 +265,7 @@ static int tls_open(URLContext *h, const char *uri,
> int flags, AVDictionary **op
> >  ret = AVERROR(EIO);
> >  goto fail;
> >  }
> > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL && !defined(LIBRESSL_VERSION_
> NUMBER)
> >  p->url_bio_method = BIO_meth_new(BIO_TYPE_SOURCE_SINK,
> "urlprotocol bio");
> >  BIO_meth_set_write(p->url_bio_method, url_bio_bwrite);
> >  BIO_meth_set_read(p->url_bio_method, url_bio_bread);
>

This also seems a bit odd, why is libreSSL setting an openssl version
number of 1.1.0 or higher when it doesnt actually conform to the
corresponding openssl version. LibreSSl setting the openssl version number
to 2.0.0 seems to be problematic and causes problems not just for ffmpeg.
Of course theres not much we can do about that but perhaps an alternative
to Michaels suggestion would be to just add a single check near the top of
the file that checks for libressl and then redefines the openssl version to
the api libressl actually supports. i.e.

#ifdef LIBRESSL_VERSION_NUMBER
#undef OPENSSL_VERSION_NUMBER
#define OPENSSL_VERSION_NUMBER 0x1000107fL
#endif

This I believe is what some other projects have done to avoid this issue
and is rather simple to add and prevents further clutter in our configure.
I dont have any preference between this and the other suggestion, im just
providing some alternatives. The above is pretty simple so if it works for
you i can write up a patch for that pretty easily.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

On 29 October 2016 at 23:54, Moritz Barsnick <barsn...@gmx.net> wrote:

> On Sat, Oct 29, 2016 at 18:35:19 +1100, Matt Oliver wrote:
>
> > +#endif /* COMPAT_W32DLFCN_H */
> > \ No newline at end of file
>
> This shouldn't happen.


thanks, Ive fixed that locally
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

>
> FYI, last time i tried to include this file from libavcodec i was told
>> not to since it's libavformat specific.
>>
>> The proper place for these wrappers is probably the compat folder, in
>> a new file similar to w32threads.h
>>
>
OK finally updated the patch. it now adds the safe dll function into a new
file "compat/w32dlfcn.h" and each source file that needs this header has
been updated accordingly. Otherwise the code is the same as the last
version that was tested by Michael.

If there are no other outstanding objections then let me know so i can push
this.


0001-compat-w32dlfcn.h-Add-safe-win32-dlopen-dlclose-dlsy.patch
Description: Binary data


0002-avutil-hwcontext_dxva.c-Use-new-safe-dlopen-code.patch
Description: Binary data


0003-avformat-avisynth.c-Use-new-safe-dlopen-code.patch
Description: Binary data


0004-avcodec-nvenc.c-Use-new-safe-dlopen-code.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] openssl: Support version 1.1.0.

[Matt Oliver]

On 15 October 2016 at 14:22, Matt Oliver <protogo...@gmail.com> wrote:

> ---
>  configure |   3 +-
>  libavformat/tls_openssl.c | 163 --
> 
>  2 files changed, 102 insertions(+), 64 deletions(-)
>
> diff --git a/configure b/configure
> index e014615..3a92eb3 100755
> --- a/configure
> +++ b/configure
> @@ -5816,7 +5816,8 @@ enabled omx   && { check_header
> OMX_Core.h ||
>  add_cflags
> -isystem/opt/vc/include/IL ; }
>  check_header OMX_Core.h ; } ||
> die "ERROR: OpenMAX IL headers not
> found"; }
> -enabled openssl   && { use_pkg_config openssl openssl/ssl.h
> SSL_library_init ||
> +enabled openssl   && { use_pkg_config openssl openssl/ssl.h
> OPENSSL_init_ssl ||
> +   use_pkg_config openssl openssl/ssl.h
> SSL_library_init ||
> check_lib openssl/ssl.h SSL_library_init
> -lssl -lcrypto ||
> check_lib openssl/ssl.h SSL_library_init
> -lssl32 -leay32 ||
> check_lib openssl/ssl.h SSL_library_init
> -lssl -lcrypto -lws2_32 -lgdi32 ||
> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> index 46eb3e6..c551ac7 100644
> --- a/libavformat/tls_openssl.c
> +++ b/libavformat/tls_openssl.c
> @@ -43,6 +43,9 @@ typedef struct TLSContext {
>  TLSShared tls_shared;
>  SSL_CTX *ctx;
>  SSL *ssl;
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +BIO_METHOD* url_bio_method;
> +#endif
>  } TLSContext;
>
>  #if HAVE_THREADS
> @@ -63,6 +66,87 @@ static unsigned long openssl_thread_id(void)
>  #endif
>  #endif
>
> +static int url_bio_create(BIO *b)
> +{
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +BIO_set_init(b, 1);
> +BIO_set_data(b, NULL);
> +BIO_set_flags(b, 0);
> +#else
> +b->init = 1;
> +b->ptr = NULL;
> +b->flags = 0;
> +#endif
> +return 1;
> +}
> +
> +static int url_bio_destroy(BIO *b)
> +{
> +return 1;
> +}
> +
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +#define GET_BIO_DATA(x) BIO_get_data(x);
> +#else
> +#define GET_BIO_DATA(x) (x)->ptr;
> +#endif
> +
> +static int url_bio_bread(BIO *b, char *buf, int len)
> +{
> +URLContext *h;
> +int ret;
> +h = GET_BIO_DATA(b);
> +ret = ffurl_read(h, buf, len);
> +if (ret >= 0)
> +return ret;
> +BIO_clear_retry_flags(b);
> +if (ret == AVERROR_EXIT)
> +return 0;
> +return -1;
> +}
> +
> +static int url_bio_bwrite(BIO *b, const char *buf, int len)
> +{
> +URLContext *h;
> +int ret;
> +h = GET_BIO_DATA(b);
> +ret = ffurl_write(h, buf, len);
> +if (ret >= 0)
> +return ret;
> +BIO_clear_retry_flags(b);
> +if (ret == AVERROR_EXIT)
> +return 0;
> +return -1;
> +}
> +
> +static long url_bio_ctrl(BIO *b, int cmd, long num, void *ptr)
> +{
> +if (cmd == BIO_CTRL_FLUSH) {
> +BIO_clear_retry_flags(b);
> +return 1;
> +}
> +return 0;
> +}
> +
> +static int url_bio_bputs(BIO *b, const char *str)
> +{
> +return url_bio_bwrite(b, str, strlen(str));
> +}
> +
> +#if OPENSSL_VERSION_NUMBER < 0x101fL
> +static BIO_METHOD url_bio_method = {
> +.type = BIO_TYPE_SOURCE_SINK,
> +.name = "urlprotocol bio",
> +.bwrite = url_bio_bwrite,
> +.bread = url_bio_bread,
> +.bputs = url_bio_bputs,
> +.bgets = NULL,
> +.ctrl = url_bio_ctrl,
> +.create = url_bio_create,
> +.destroy = url_bio_destroy,
> +};
> +#endif
> +
>  int ff_openssl_init(void)
>  {
>  avpriv_lock_avformat();
> @@ -128,73 +212,14 @@ static int tls_close(URLContext *h)
>  SSL_CTX_free(c->ctx);
>  if (c->tls_shared.tcp)
>  ffurl_close(c->tls_shared.tcp);
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +if (c->url_bio_method)
> +BIO_meth_free(c->url_bio_method);
> +#endif
>  ff_openssl_deinit();
>
>  return 0;
>  }
>
> -static int url_bio_create(BIO *b)
> -{
> -b->init = 1;
> -b->ptr = NULL;
> -b->flags = 0;
> -return 1;
> -}
> -
> -static int url_bio_destroy(BIO *b)
> -{
> -return 1;
> -}
> -
> -static int url_bio_bread(BIO *b, char *buf, int len)
> -{
> -URLContext *h = b->ptr;
> -int ret = ffurl_read(h, buf, len);
> -if (ret >= 0)

Re: [FFmpeg-devel] [PATCH] openssl: Support version 1.1.0.

[Matt Oliver]

On 10 October 2016 at 05:48, Lou Logan <l...@lrcd.com> wrote:

> On Sun, Oct 9, 2016, at 07:39 AM, Matt Oliver wrote:
> > ---
> >  configure |   3 +-
> >  libavformat/tls_openssl.c | 159
> > --
> >  2 files changed, 98 insertions(+), 64 deletions(-)
>
> Does this fix ticket #5675? If it does you can mention that in the
> commit message.
>
> Yes it does, new patch incomming
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] openssl: Support version 1.1.0.

[Matt Oliver]

>From ad4d838ed6673c6d12aeaa7b00036b66371b4d63 Mon Sep 17 00:00:00 2001
From: Matt Oliver <protogo...@gmail.com>
Date: Mon, 10 Oct 2016 06:49:54 +1100
Subject: [PATCH] openssl: Support version 1.1.0.

Fixes #5675

Signed-off-by: Matt Oliver <protogo...@gmail.com>
---
 configure |   3 +-
 libavformat/tls_openssl.c | 163
--
 2 files changed, 102 insertions(+), 64 deletions(-)

diff --git a/configure b/configure
index e014615..3a92eb3 100755
--- a/configure
+++ b/configure
@@ -5816,7 +5816,8 @@ enabled omx   && { check_header
OMX_Core.h ||
 add_cflags -isystem/opt/vc/include/IL
; }
 check_header OMX_Core.h ; } ||
die "ERROR: OpenMAX IL headers not found"; }
-enabled openssl   && { use_pkg_config openssl openssl/ssl.h
SSL_library_init ||
+enabled openssl   && { use_pkg_config openssl openssl/ssl.h
OPENSSL_init_ssl ||
+   use_pkg_config openssl openssl/ssl.h
SSL_library_init ||
check_lib openssl/ssl.h SSL_library_init
-lssl -lcrypto ||
check_lib openssl/ssl.h SSL_library_init
-lssl32 -leay32 ||
check_lib openssl/ssl.h SSL_library_init
-lssl -lcrypto -lws2_32 -lgdi32 ||
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 46eb3e6..2206ab0 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -63,6 +63,89 @@ static unsigned long openssl_thread_id(void)
 #endif
 #endif

+static int url_bio_create(BIO *b)
+{
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+BIO_set_init(b, 1);
+BIO_set_data(b, NULL);
+BIO_set_flags(b, 0);
+#else
+b->init = 1;
+b->ptr = NULL;
+b->flags = 0;
+#endif
+return 1;
+}
+
+static int url_bio_destroy(BIO *b)
+{
+return 1;
+}
+
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#define BIO_GET_DATA(x) BIO_get_data(x);
+#else
+#define BIO_GET_DATA(x) (x)->ptr;
+#endif
+
+static int url_bio_bread(BIO *b, char *buf, int len)
+{
+URLContext *h;
+int ret;
+h = BIO_GET_DATA(b);
+ret = ffurl_read(h, buf, len);
+if (ret >= 0)
+return ret;
+BIO_clear_retry_flags(b);
+if (ret == AVERROR_EXIT)
+return 0;
+return -1;
+}
+
+static int url_bio_bwrite(BIO *b, const char *buf, int len)
+{
+URLContext *h;
+int ret;
+h = BIO_GET_DATA(b);
+ret = ffurl_write(h, buf, len);
+if (ret >= 0)
+return ret;
+BIO_clear_retry_flags(b);
+if (ret == AVERROR_EXIT)
+return 0;
+return -1;
+}
+
+static long url_bio_ctrl(BIO *b, int cmd, long num, void *ptr)
+{
+if (cmd == BIO_CTRL_FLUSH) {
+BIO_clear_retry_flags(b);
+return 1;
+}
+return 0;
+}
+
+static int url_bio_bputs(BIO *b, const char *str)
+{
+return url_bio_bwrite(b, str, strlen(str));
+}
+
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+static BIO_METHOD* url_bio_method;
+#else
+static BIO_METHOD url_bio_method = {
+.type = BIO_TYPE_SOURCE_SINK,
+.name = "urlprotocol bio",
+.bwrite = url_bio_bwrite,
+.bread = url_bio_bread,
+.bputs = url_bio_bputs,
+.bgets = NULL,
+.ctrl = url_bio_ctrl,
+.create = url_bio_create,
+.destroy = url_bio_destroy,
+};
+#endif
+
 int ff_openssl_init(void)
 {
 avpriv_lock_avformat();
@@ -86,6 +169,15 @@ int ff_openssl_init(void)
 #endif
 }
 #endif
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+url_bio_method = BIO_meth_new(BIO_TYPE_SOURCE_SINK, "urlprotocol
bio");
+BIO_meth_set_write(url_bio_method, url_bio_bwrite);
+BIO_meth_set_read(url_bio_method, url_bio_bread);
+BIO_meth_set_puts(url_bio_method, url_bio_bputs);
+BIO_meth_set_ctrl(url_bio_method, url_bio_ctrl);
+BIO_meth_set_create(url_bio_method, url_bio_create);
+BIO_meth_set_destroy(url_bio_method, url_bio_destroy);
+#endif
 }
 openssl_init++;
 avpriv_unlock_avformat();
@@ -107,6 +199,9 @@ void ff_openssl_deinit(void)
 av_free(openssl_mutexes);
 }
 #endif
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+BIO_meth_free(url_bio_method);
+#endif
 }
 avpriv_unlock_avformat();
 }
@@ -132,69 +227,6 @@ static int tls_close(URLContext *h)
 return 0;
 }

-static int url_bio_create(BIO *b)
-{
-b->init = 1;
-b->ptr = NULL;
-b->flags = 0;
-return 1;
-}
-
-static int url_bio_destroy(BIO *b)
-{
-return 1;
-}
-
-static int url_bio_bread(BIO *b, char *buf, int len)
-{
-URLContext *h = b->ptr;
-int ret = ffurl_read(h, buf, len);
-if (ret >= 0)
-return ret;
-BIO_clear_retry_flags(b);
-if (ret == AVERROR_EXIT)
-return 0;
-return -1;
-}
-
-static int url_bio_bwrite(BIO *b, const char *buf, int

Re: [FFmpeg-devel] [PATCH] openssl: Support version 1.1.0.

[Matt Oliver]

On 10 October 2016 at 03:18, Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Mon, Oct 10, 2016 at 02:39:51AM +1100, Matt Oliver wrote:
> > ---
> >  configure |   3 +-
> >  libavformat/tls_openssl.c | 159
> > --
> >  2 files changed, 98 insertions(+), 64 deletions(-)
> >
> > diff --git a/configure b/configure
> > index df6ffa2..750684a 100755
> > --- a/configure
> > +++ b/configure
> > @@ -5813,7 +5813,8 @@ enabled omx   && { check_header
> > OMX_Core.h ||
> >  add_cflags
> -isystem/opt/vc/include/IL
> > ; }
> >  check_header OMX_Core.h ; } ||
> > die "ERROR: OpenMAX IL headers not
> found"; }
> > -enabled openssl   && { use_pkg_config openssl openssl/ssl.h
> > SSL_library_init ||
> > +enabled openssl   && { use_pkg_config openssl openssl/ssl.h
> > OPENSSL_init_ssl ||
> > +   use_pkg_config openssl openssl/ssl.h
> > SSL_library_init ||
> > check_lib openssl/ssl.h SSL_library_init
> > -lssl -lcrypto ||
> > check_lib openssl/ssl.h SSL_library_init
> > -lssl32 -leay32 ||
> > check_lib openssl/ssl.h SSL_library_init
> > -lssl -lcrypto -lws2_32 -lgdi32 ||
> > diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> > index 46eb3e6..4effb39 100644
> > --- a/libavformat/tls_openssl.c
> > +++ b/libavformat/tls_openssl.c
> > @@ -63,6 +63,85 @@ static unsigned long openssl_thread_id(void)
> >  #endif
> >  #endif
> >
> > +static int url_bio_create(BIO *b)
> > +{
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +BIO_set_init(b, 1);
> > +BIO_set_data(b, NULL);
> > +BIO_set_flags(b, 0);
> > +#else
> > +b->init = 1;
> > +b->ptr = NULL;
> > +b->flags = 0;
> > +#endif
> > +return 1;
> > +}
> > +
> > +static int url_bio_destroy(BIO *b)
> > +{
> > +return 1;
> > +}
> > +
>
> > +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > +#define BIO_GET_DATA(x) BIO_get_data(x);
> > +#else
> > +#define BIO_GET_DATA(x) x->ptr;
> > +#endif
>
> this needs a () for protecting x
>

Fixed locally.


> also there are these new warnings:
>
> libavformat/tls_openssl.c: In function ‘url_bio_bread’:
> libavformat/tls_openssl.c:94:5: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
> libavformat/tls_openssl.c: In function ‘url_bio_bwrite’:
> libavformat/tls_openssl.c:106:5: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
>

I assume the above was with 1.1.0 (as prior versions result in identical
code to what was there). Ive locally modified both functions so that
URLContext *h is only declared before ret but initialised in a new line
added after ret.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] openssl: Support version 1.1.0.

[Matt Oliver]

---
 configure |   3 +-
 libavformat/tls_openssl.c | 159
--
 2 files changed, 98 insertions(+), 64 deletions(-)

diff --git a/configure b/configure
index df6ffa2..750684a 100755
--- a/configure
+++ b/configure
@@ -5813,7 +5813,8 @@ enabled omx   && { check_header
OMX_Core.h ||
 add_cflags -isystem/opt/vc/include/IL
; }
 check_header OMX_Core.h ; } ||
die "ERROR: OpenMAX IL headers not found"; }
-enabled openssl   && { use_pkg_config openssl openssl/ssl.h
SSL_library_init ||
+enabled openssl   && { use_pkg_config openssl openssl/ssl.h
OPENSSL_init_ssl ||
+   use_pkg_config openssl openssl/ssl.h
SSL_library_init ||
check_lib openssl/ssl.h SSL_library_init
-lssl -lcrypto ||
check_lib openssl/ssl.h SSL_library_init
-lssl32 -leay32 ||
check_lib openssl/ssl.h SSL_library_init
-lssl -lcrypto -lws2_32 -lgdi32 ||
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 46eb3e6..4effb39 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -63,6 +63,85 @@ static unsigned long openssl_thread_id(void)
 #endif
 #endif

+static int url_bio_create(BIO *b)
+{
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+BIO_set_init(b, 1);
+BIO_set_data(b, NULL);
+BIO_set_flags(b, 0);
+#else
+b->init = 1;
+b->ptr = NULL;
+b->flags = 0;
+#endif
+return 1;
+}
+
+static int url_bio_destroy(BIO *b)
+{
+return 1;
+}
+
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+#define BIO_GET_DATA(x) BIO_get_data(x);
+#else
+#define BIO_GET_DATA(x) x->ptr;
+#endif
+
+static int url_bio_bread(BIO *b, char *buf, int len)
+{
+URLContext *h = BIO_GET_DATA(b);
+int ret = ffurl_read(h, buf, len);
+if (ret >= 0)
+return ret;
+BIO_clear_retry_flags(b);
+if (ret == AVERROR_EXIT)
+return 0;
+return -1;
+}
+
+static int url_bio_bwrite(BIO *b, const char *buf, int len)
+{
+URLContext *h = BIO_GET_DATA(b);
+int ret = ffurl_write(h, buf, len);
+if (ret >= 0)
+return ret;
+BIO_clear_retry_flags(b);
+if (ret == AVERROR_EXIT)
+return 0;
+return -1;
+}
+
+static long url_bio_ctrl(BIO *b, int cmd, long num, void *ptr)
+{
+if (cmd == BIO_CTRL_FLUSH) {
+BIO_clear_retry_flags(b);
+return 1;
+}
+return 0;
+}
+
+static int url_bio_bputs(BIO *b, const char *str)
+{
+return url_bio_bwrite(b, str, strlen(str));
+}
+
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+static BIO_METHOD* url_bio_method;
+#else
+static BIO_METHOD url_bio_method = {
+.type = BIO_TYPE_SOURCE_SINK,
+.name = "urlprotocol bio",
+.bwrite = url_bio_bwrite,
+.bread = url_bio_bread,
+.bputs = url_bio_bputs,
+.bgets = NULL,
+.ctrl = url_bio_ctrl,
+.create = url_bio_create,
+.destroy = url_bio_destroy,
+};
+#endif
+
 int ff_openssl_init(void)
 {
 avpriv_lock_avformat();
@@ -86,6 +165,15 @@ int ff_openssl_init(void)
 #endif
 }
 #endif
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+url_bio_method = BIO_meth_new(BIO_TYPE_SOURCE_SINK, "urlprotocol
bio");
+BIO_meth_set_write(url_bio_method, url_bio_bwrite);
+BIO_meth_set_read(url_bio_method, url_bio_bread);
+BIO_meth_set_puts(url_bio_method, url_bio_bputs);
+BIO_meth_set_ctrl(url_bio_method, url_bio_ctrl);
+BIO_meth_set_create(url_bio_method, url_bio_create);
+BIO_meth_set_destroy(url_bio_method, url_bio_destroy);
+#endif
 }
 openssl_init++;
 avpriv_unlock_avformat();
@@ -107,6 +195,9 @@ void ff_openssl_deinit(void)
 av_free(openssl_mutexes);
 }
 #endif
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+BIO_meth_free(url_bio_method);
+#endif
 }
 avpriv_unlock_avformat();
 }
@@ -132,69 +223,6 @@ static int tls_close(URLContext *h)
 return 0;
 }

-static int url_bio_create(BIO *b)
-{
-b->init = 1;
-b->ptr = NULL;
-b->flags = 0;
-return 1;
-}
-
-static int url_bio_destroy(BIO *b)
-{
-return 1;
-}
-
-static int url_bio_bread(BIO *b, char *buf, int len)
-{
-URLContext *h = b->ptr;
-int ret = ffurl_read(h, buf, len);
-if (ret >= 0)
-return ret;
-BIO_clear_retry_flags(b);
-if (ret == AVERROR_EXIT)
-return 0;
-return -1;
-}
-
-static int url_bio_bwrite(BIO *b, const char *buf, int len)
-{
-URLContext *h = b->ptr;
-int ret = ffurl_write(h, buf, len);
-if (ret >= 0)
-return ret;
-BIO_clear_retry_flags(b);
-if (ret == AVERROR_EXIT)
-return 0;
-return -1;
-}
-
-static long url_bio_ctrl(BIO *b, int cmd, long num, void *ptr)
-{
-if (cmd == BIO_CTRL_FLUSH) {
-BIO_clear_retry_flags(b);
-return 1;
-}
-return 0;
-}
-
-static int 

Re: [FFmpeg-devel] [PATCH 0/3] Include headers for cuvid

[Matt Oliver]

On 21 September 2016 at 15:28, Philip Langdale <phil...@overt.org> wrote:

> On Wed, 21 Sep 2016 15:09:36 +1000
> Matt Oliver <protogo...@gmail.com> wrote:
>
> > On 21 September 2016 at 14:38, Philip Langdale <phil...@overt.org>
> > wrote:
> >
> > > The cuvid header situation is a mess - the only feature-complete
> > > headers are
> > > in the Video SDK and not in the cuda header collection. The headers
> > > in the Video SDK are MIT licenced, and so we can bundle them like
> > > we do the nvenc header.
> > >
> > > Once bundled, we do need to tweak them to remove the use of a
> > > dynlink system that's specific to the Video SDK samples, which we
> > > don't need and don't really want.
> > >
> >
> > Does using the MIT headers instead effect the current licensing
> > constraints on cuvid (as its nonfree at present). I was just
> > wondering if keeping in the dynlink_cuda stuff could be used to
> > remove the cuda compile dependency and actually allow cuvid compiles
> > to be distributed. ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> Unfortunately not. the dynlink_cuda.h is not MIT licenced so you still
> end up with that as an external dependency.
>
> For our nvenc usage, the cuda function prototypes are redeclared to
> avoid a dependency on cuda.h. I guess you could do the same for cuvid,
> but the set of functions is much more extensive.
>
> On the library side, the story is fine as libcuda and libnvcuvid are
> distributed with the driver like libnvidia-encoder which we decided
> was acceptable to link/dlopen.
>
> I feel I'm missing something in the overall picture - how did we end up
> in a situation where we decided that a proprietary library was an
> acceptable dependency but the header for that library is not. For all I
> know, maybe we're actually ok with using cuda.h at build time and still
> being gpl compliant.
>
> In general I've not read any discussion of the cuda runtime licence
> being GPL incompatible. IANAL etc.
>
> --phil
>

Well its just that both cuvid and cuda are both currently flagged as
nonfree in FFmpeg which limits there availability. So I was just wondering
what needed to be done to make them gpl compatible as I would like to see
cuvid be more available.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] Include headers for cuvid

[Matt Oliver]

On 21 September 2016 at 14:38, Philip Langdale  wrote:

> The cuvid header situation is a mess - the only feature-complete headers
> are
> in the Video SDK and not in the cuda header collection. The headers in the
> Video SDK are MIT licenced, and so we can bundle them like we do the nvenc
> header.
>
> Once bundled, we do need to tweak them to remove the use of a dynlink
> system that's specific to the Video SDK samples, which we don't need and
> don't really want.
>

Does using the MIT headers instead effect the current licensing constraints
on cuvid (as its nonfree at present). I was just wondering if keeping in
the dynlink_cuda stuff could be used to remove the cuda compile dependency
and actually allow cuvid compiles to be distributed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools

[Matt Oliver]

On 14 September 2016 at 20:22, Yogender Kumar Gupta <
yogender.gu...@gmail.com> wrote:

> Currently libavcodec.c/nvenc.c is not compilable using MSVC tools. I am
> attaching a patch that fixes this issue.
>
> Thanks,
> Yogender
>

What version of msvc are you using? 2015 and 2013 all work fine currently
so I assume this is with an older version. Since nvenc is currently enabled
by default then this should have been picked up by FATE (which currently
has not had this issue) and older versions of msvc rely on the c99
converter which i would have thought should have properly handled that kind
of code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

>
> FYI, last time i tried to include this file from libavcodec i was told
> not to since it's libavformat specific.
>
> The proper place for these wrappers is probably the compat folder, in
> a new file similar to w32threads.h
>

It occurred to me as well that this should be a common header perhaps
supplied in libavutil. Currently os_support has many similar functions that
provide win32 specific implementations of missing functionality so adding
this patch to the existing list of functions supplied in that header seemed
the most suitable place to include it as it keeps all the similar functions
together. Which to me makes the issue that most of the code in os_support
should probably not be in an avformat specific header and in fact should be
moved. So for simplicity I added it to the existing code, but if it is
decided that this os specific header should be moved to a more central
location then Ill write up a second patch after this one get applied that
will move all the shared code from os_support (as opposed to putting this
patches code in a different location and ending up with similar code spread
out in different locations throughout the code base).

On 30 August 2016 at 02:26, Jean-Baptiste Kempf <j...@videolan.org> wrote:

> On 28 Aug, Matt Oliver wrote :
> > The dlopen function is modified to prevent loading dll's from the current
> > directory for improved program security for library users. This extends
> > similar functionality from the recently applied  SetDllDirectory patch
> > except that it adds additional security for library users as well (as
> > opposed to just program users).
>
> Why allowing it to open the local folder?
>
> Said differently, what are you allowing to open, and why?


So this is for opening of dynamic link libraries which under normal
circumstances the function to load a dll will search multiple different
directories in order to find the requested dll. This patch is a result of a
discussion on the ffmpeg-security mailing list about the ability for
hackers to create a fake dll that gets picked during the dll search and
loaded instead. So this patch adds code to limit the search for a dll to
the applications install directory and the system directory only. Initially
I was just going to limit it to the system folder (which would be the most
secure) but others requested the application directory also be included as
they use that functionality during testing by adding their own test
versions of dlls to the application dir. Also given that although the
application dir may be less secure but if someone can modify dlls in that
folder then they can modify the application itself anyway so allowing it
doesnt really make things any worse.
So the main thing is that this patch limits where dll's can be loaded from
to limit the ability for someone to inject insecure code into a program. It
does this by limiting the standard searched locations to just a subset that
only includes the application directory (searched first in case the app
requires specific version of dlls that differ from the system version) and
then the system directory.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

[Matt Oliver]

On 29 August 2016 at 17:28, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:

> Hi!
>
> 2016-08-29 9:00 GMT+02:00 Matt Oliver <protogo...@gmail.com>:
> > On 29 August 2016 at 16:43, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> >
> >> How did you test this?
> >> (How can I test?)
> >
> > There is a FATE test already added for the fifo muxer. I used that to
> test
> > for mingw and msvc.
>
> What I meant is:
> If I remove pthreads from my system, fifo compilation fails, which imo
> implies that the patch is wrong.
> But I may miss something.
>

The second version is the correct one. You need w32threads/os2threads
enabled if not using pthreads.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

[Matt Oliver]

On 29 August 2016 at 16:43, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:

> Hi!
>
> 2016-08-29 8:17 GMT+02:00 Matt Oliver <protogo...@gmail.com>:
> > The fifo muxer works without pthreads due to the existing pthread
> > wrappers already available within ffmpeg for other platforms.
>
> It should probably still depend on "threads" at least, assuming the
> thread-wrapper we have provides enough threading features for the
> muxer.
>

You are correct updated patch is attached.


> How did you test this?
> (How can I test?)
>

There is a FATE test already added for the fifo muxer. I used that to test
for mingw and msvc.


0001-configure-Remove-fifo-muxers-dependency-on-pthreads.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

On 28 August 2016 at 19:58, Michael Niedermayer <mich...@niedermayer.cc>
wrote:

> On Sun, Aug 28, 2016 at 06:50:58PM +1000, Matt Oliver wrote:
> > The dlopen function is modified to prevent loading dll's from the current
> > directory for improved program security for library users. This extends
> > similar functionality from the recently applied  SetDllDirectory patch
> > except that it adds additional security for library users as well (as
> > opposed to just program users).
>
> >  os_support.h |   49 +
> >  1 file changed, 49 insertions(+)
> > 89c775ecc8ac03d001131dd50e043ba57ffe5420  0001-lavf-os_support-Add-safe-
> win32-dlopen-dlclose-dlsym-.patch
> > From 666ab2f7d64cfa94984881aca83035993365 Mon Sep 17 00:00:00 2001
> > From: Matt Oliver <protogo...@gmail.com>
> > Date: Sun, 21 Aug 2016 16:06:59 +1000
> > Subject: [PATCH 1/2] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym
> >  functions.
>
> breaks mingw32
>
> In file included from src/libavformat/internal.h:28:0,
>  from src/libavdevice/lavfi.c:44:
> src/libavformat/os_support.h: In function ‘win32_dlopen’:
> src/libavformat/os_support.h:303:46: error: 
> ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’
> undeclared (first use in this function)
> src/libavformat/os_support.h:303:46: note: each undeclared identifier is
> reported only once for each function it appears in
> src/libavformat/os_support.h:303:84: error:
> ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function)
> In file included from src/libavformat/internal.h:28:0,
>  from src/libavdevice/gdigrab.c:32:
> src/libavformat/os_support.h: In function ‘win32_dlopen’:
> src/libavformat/os_support.h:303:46: error: 
> ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’
> undeclared (first use in this function)
> src/libavformat/os_support.h:303:46: note: each undeclared identifier is
> reported only once for each function it appears in
> src/libavformat/os_support.h:303:84: error:
> ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function)
> make: *** [libavdevice/lavfi.o] Error 1
>

It appears older versions of mingw must not have the appropriate defines
(as the version i tested against worked fine).
Anyway updated patch attached which corrects the issue.


0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch
Description: Binary data


0002-Modify-existing-dll-loading-to-use-new-safe-dlopen.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.

[Matt Oliver]

The fifo muxer works without pthreads due to the existing pthread wrappers
already available within ffmpeg for other platforms.

---
 configure | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure b/configure
index 5c11040..e225b7d 100755
--- a/configure
+++ b/configure
@@ -2834,7 +2834,6 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
-fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
--


0001-configure-Remove-fifo-muxers-dependency-on-pthreads.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.

[Matt Oliver]

The dlopen function is modified to prevent loading dll's from the current
directory for improved program security for library users. This extends
similar functionality from the recently applied  SetDllDirectory patch
except that it adds additional security for library users as well (as
opposed to just program users).


0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch
Description: Binary data


0002-Modify-existing-dll-loading-to-use-new-safe-dlopen-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel