Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function

[Carl Eugen Hoyos]

2017-04-13 9:51 GMT+02:00 Rostislav Pehlivanov :
> On 13 April 2017 at 07:13, Carl Eugen Hoyos  wrote:
>
>> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov :
>> > On 12 April 2017 at 23:50, Carl Eugen Hoyos  wrote:
>> >
>> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov :
>> >>
>> >> > +/* Undo the sample reorganization going from time
>> >> > order to frequency order */
>> >> > +if (B0 > 1)
>> >> > +celt_interleave_hadamard(f->scratch, X,
>> >> > N_B >> recombine,
>> >> > + B0<> >>
>> >> Is this the same code as in opus/celt/bands.c?
>> >> Who wrote it?
>> >
>> > This exact line is also on line 1206 of the same file for PVQ decoding .
>> > Most of the PVQ encoder is copied from our decoder since they're very
>> > similar. This commit just copies more.
>>
>> > The reason why you can find the same string in libopus is because that
>> > decoder was cut down, modified and ported as our native decoder.
>>
>> Then I suggest you add the missing copyright notices to the decoder
>> and the encoder.

> There's nothing to do:
>> * Copyright (c) 2012 Andrew D'Addesio
>> * Copyright (c) 2013-2014 Mozilla Corporation
>> * Copyright (c) 2017 Rostislav Pehlivanov 
>
> Mozilla relicensed the decoder to LGPL when it was ported.

Sorry, I don't understand:
You write above that FFmpeg's opus decoder is based on libopus,
this also explains the similar code I saw (above). libopus is - afaict -
copyright Xiph.Org Foundation.
I suggested to add this copyright to our codec and your answer
is that there is nothing to do but I don't see Xiph mentioned: What
am I missing?
You then continue that the code was relicensed to LGPL: How is
that related to the missing copyright notice?

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

[FFmpeg-devel] [PATCH] doc/encoders.texi: document libvpxenc's -row-mt

[James Zern]

added in:
734d760e2f lavc/libvpxenc: add -row-mt option

Signed-off-by: James Zern 
---
 doc/encoders.texi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612b5a..7f4754d160 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1679,6 +1679,8 @@ colorspaces:
 @item @samp{smpte240m} @emph{smpte240}
 @item @samp{bt2020_ncl} @emph{bt2020}
 @end table
+@item row-mt @var{boolean}
+Enable row based multi-threading.
 @end table
 
 @end table
-- 
2.12.2.762.g0e3151a226-goog

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

[FFmpeg-devel] [PATCH] libvpxenc: allow aq-mode 4 (equator360)

[James Zern]

this was added in 1.6.0

Signed-off-by: James Zern 
---
 doc/encoders.texi  | 2 +-
 libavcodec/libvpxenc.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612b5a..f8f187664c 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1666,7 +1666,7 @@ option to 2.
 Enable frame parallel decodability features.
 @item aq-mode
 Set adaptive quantization mode (0: off (default), 1: variance 2: complexity, 3:
-cyclic refresh).
+cyclic refresh, 4: equator360).
 @item colorspace @emph{color-space}
 Set input color space. The VP9 bitstream supports signaling the following
 colorspaces:
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index b8e8d3a87b..4ae0918c69 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1142,11 +1142,12 @@ static const AVOption vp9_options[] = {
 { "tile-columns","Number of tile columns to use, log2", 
OFFSET(tile_columns),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
 { "tile-rows",   "Number of tile rows to use, log2",
OFFSET(tile_rows),   AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
 { "frame-parallel",  "Enable frame parallel decodability features", 
OFFSET(frame_parallel),  AV_OPT_TYPE_BOOL,{.i64 = -1}, -1, 1, VE},
-{ "aq-mode", "adaptive quantization mode",  
OFFSET(aq_mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 3, VE, "aq_mode"},
+{ "aq-mode", "adaptive quantization mode",  
OFFSET(aq_mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 4, VE, "aq_mode"},
 { "none","Aq not used", 0, AV_OPT_TYPE_CONST, {.i64 = 
0}, 0, 0, VE, "aq_mode" },
 { "variance","Variance based Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
1}, 0, 0, VE, "aq_mode" },
 { "complexity",  "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 = 
2}, 0, 0, VE, "aq_mode" },
 { "cyclic",  "Cyclic Refresh Aq",   0, AV_OPT_TYPE_CONST, {.i64 = 
3}, 0, 0, VE, "aq_mode" },
+{ "equator360",  "360 video Aq",0, AV_OPT_TYPE_CONST, {.i64 = 
4}, 0, 0, VE, "aq_mode" },
 #if VPX_ENCODER_ABI_VERSION >= 12
 {"level", "Specify level", OFFSET(level), AV_OPT_TYPE_FLOAT, {.dbl=-1}, 
-1, 6.2, VE},
 #endif
-- 
2.12.2.762.g0e3151a226-goog

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'

[Michael Niedermayer]

On Thu, Apr 13, 2017 at 09:11:41PM -0300, James Almer wrote:
> On 4/13/2017 8:43 PM, Michael Niedermayer wrote:
> > On Thu, Apr 13, 2017 at 08:18:56PM +, James Almer wrote:
> >> ffmpeg | branch: master | James Almer  | Thu Apr 13 
> >> 17:09:52 2017 -0300| [5dba808064e7879c04d3e2fb4f10e709bedf51c2] | 
> >> committer: James Almer
> >>
> >> Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'
> >>
> >> * commit '3e105d08848162b90d886bde59c010d4b0362a4b':
> >>   build: Move entries related to building TOOLS to a subdirectory Makefile
> >>
> >> Merged-by: James Almer 
> >>
> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5dba808064e7879c04d3e2fb4f10e709bedf51c2
> >> ---
> > 
> > This breaks dependancies
> > 
> > for example
> > 
> > make distclean ; ./configure  --arch=x86_32 --target-os=linux 
> > --extra-cflags=-m32 --extra-ldflags=-m32  --enable-cross-compile  && make 
> > -j12 alltools
> > 
> > fails to build as libs dont get build before tools
> > 
> > 
> > LD  tools/uncoded_frame
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.so when 
> > searching for -lavdevice
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.a when 
> > searching for -lavdevice
> > /usr/bin/ld: cannot find -lavdevice
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.so when 
> > searching for -lavfilter
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.a when 
> > searching for -lavfilter
> > /usr/bin/ld: cannot find -lavfilter
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.so when 
> > searching for -lavformat
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.a when 
> > searching for -lavformat
> > /usr/bin/ld: cannot find -lavformat
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.so when 
> > searching for -lavcodec
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.a when 
> > searching for -lavcodec
> > /usr/bin/ld: cannot find -lavcodec
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.so when 
> > searching for -lswresample
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.a when 
> > searching for -lswresample
> > /usr/bin/ld: cannot find -lswresample
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.so when 
> > searching for -lswscale
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.a when 
> > searching for -lswscale
> > /usr/bin/ld: cannot find -lswscale
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.so when 
> > searching for -lavutil
> > /usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.a when 
> > searching for -lavutil
> > /usr/bin/ld: cannot find -lavutil
> > collect2: ld returned 1 exit status
> > make: *** [tools/uncoded_frame] Error 1
> > 
> > make -j12 ffmpeg
> > ...
> > make -j12 tools/uncoded_frame
> > succeeds now
> 
> Should be fixed, although a proper refactoring of the build system may
> be in order.

thanks!

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] webm_dash_manifest: Add option to specify bandwidth

[James Zern]

On Tue, Apr 11, 2017 at 9:33 PM, Vignesh Venkatasubramanian
 wrote:
> Add an option to webm_dash_manifest demuxer to specify a value for
> "bandwidth" field in the DASH manifest. The value is then used by
> the muxer. Fixes an existing FIXME in the code.
>
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavformat/matroskadec.c| 19 ++-
>  libavformat/webmdashenc.c| 11 ---
>  tests/fate/vpx.mak   |  3 +++
>  tests/ref/fate/webm-dash-manifest-live-bandwidth | 24 
> 
>  4 files changed, 53 insertions(+), 4 deletions(-)
>  create mode 100644 tests/ref/fate/webm-dash-manifest-live-bandwidth
>

lgtm. I'll submit this soon if there aren't any comments.

> [...]
> -// FIXME: For live, This should be obtained from the input file or as an 
> AVOption.
> -avio_printf(s->pb, " bandwidth=\"%s\"",
> -w->is_live ? (stream->codecpar->codec_type == 
> AVMEDIA_TYPE_AUDIO ? "128000" : "100") : bandwidth->value);
> +// if bandwidth for live was not provied, use a default

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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Aaron Levinson]

On 4/13/2017 3:40 PM, Marton Balint wrote:
> 
> On Thu, 13 Apr 2017, Aaron Levinson wrote:
> 
>> On 4/13/2017 2:12 AM, Hendrik Leppkes wrote:
>>> On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson  
>> wrote:
>>> Give it some time for the other changes to be reviewed by the people
>>> that actually know decklink itself, you can include that in any new
>>> versions of the patch then, no need to send one for that right now.
>>>
>>> - Hendrik
>>
>> Actually, the coding changes made to the decklink source files in this
>> patch have pretty much nothing to do with decklink itself, and anyone
>> with familiarity with semaphores and pthread could review those changes.
>>  In fact, all I really did was use already existing approaches for
>> replacing a semaphore with the combination of a condition variable,
>> mutex, and counter, and there are plenty of examples of how to do this
>> on the Web.
>>
> 
> Yeah, the changes look fine, please send an updated patch, I will apply
> it after some final testing.
> 
> Thanks,
> Marton

Here's a new version of the patch with the pthreads dependency replaced with 
threads.

Thanks,
Aaron

---


From 7ecc4c280f2185dc1c19131a1dbf9f833ebb42b3 Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 18:08:17 -0700
Subject: [PATCH] avdevice/decklink: Removed pthread dependency

Purpose: avdevice/decklink: Removed pthread dependency by replacing
semaphore used in code appropriately.  Doing so makes it easier to
build ffmpeg using Visual C++ on Windows.  This is a contination of
Kyle Schwarz's "avdevice/decklink: Remove pthread dependency" patch
that is available at https://patchwork.ffmpeg.org/patch/2654/ .  This
patch wasn't accepted, and as far as I can tell, there was no
follow-up after it was rejected.

Notes: Used Visual Studio 2015 (with update 3) for this.

Comments:

-- configure: Eliminated pthreads dependency for decklink_indev_deps
   and decklink_outdev_deps and replaced with threads dependency

-- libavdevice/decklink_common.cpp / .h:
a) Eliminated semaphore and replaced with a combination of a mutex,
   condition variable, and a counter (frames_buffer_available_spots).
b) Removed include of pthread.h and semaphore.h and now using
   libavutil/thread.h instead.

-- libavdevice/decklink_dec.cpp: Eliminated include of pthread.h and
   semaphore.h.

-- libavdevice/decklink_enc.cpp:
a) Eliminated include of pthread.h and semaphore.h.
b) Replaced use of semaphore with the equivalent using a combination
   of a mutex, condition variable, and a counter
   (frames_buffer_available_spots).  In theory, libavutil/thread.h and
   the associated code could have been modified instead to add
   cross-platform implementations of the sem_ functions, but an
   inspection of the ffmpeg source base indicates that there are only
   two cases in which semaphores are used (including this one that was
   replaced), so it was deemed to not be worth the effort.
---
 configure   |  4 ++--
 libavdevice/decklink_common.cpp |  3 ---
 libavdevice/decklink_common.h   |  5 -
 libavdevice/decklink_dec.cpp|  3 ---
 libavdevice/decklink_enc.cpp| 23 +++
 5 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/configure b/configure
index 0af4a29..18d79ab 100755
--- a/configure
+++ b/configure
@@ -3000,9 +3000,9 @@ avfoundation_indev_deps="pthreads"
 avfoundation_indev_extralibs="-framework Foundation -framework AVFoundation 
-framework CoreVideo -framework CoreMedia"
 bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h 
dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
 caca_outdev_deps="libcaca"
-decklink_indev_deps="decklink pthreads"
+decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
-decklink_outdev_deps="decklink pthreads"
+decklink_outdev_deps="decklink threads"
 decklink_outdev_extralibs="-lstdc++"
 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 587a321..523217c 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -35,9 +35,6 @@ extern "C" {
 #include 
 #endif
 
-#include 
-#include 
-
 extern "C" {
 #include "libavformat/avformat.h"
 #include "libavutil/imgutils.h"
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 4753287..c12cf18 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -24,6 +24,7 @@
 
 #include 
 
+#include "libavutil/thread.h"
 #include "decklink_common_c.h"
 
 class decklink_output_callback;
@@ -89,7 +90,9 @@ struct decklink_ctx {
 int frames_preroll;
 int frames_buffer;
 
-sem_t semaphore;
+pthread_mutex_t mutex;
+pthread_cond_t cond;
+int frames_buffer_available_spots;
 
 int channels;
 };
diff 

Re: [FFmpeg-devel] [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata setting error.

[Jun Zhao]

On 2017/4/13 22:05, Mark Thompson wrote:
> On 13/04/17 13:34, Jun Zhao wrote:
>> From 1fa48b45fe962d8c342d158d9c16ce24139ffd84 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Thu, 13 Apr 2017 20:07:10 +0800
>> Subject: [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata
>>  setting error.
>>
>> before this fix, mediainfo check the bit rate control mode metadata info
>> is wrong.
>>
>> Reproduce step:
>> encode with CBR or VBR mode like this:
>> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
>> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
>> -maxrate 5M -b:v 5M output_cbr.mp4
>>
>> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
>> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
>> -maxrate 6M -b:v 5M output_cbr.mp4
>>
>> then use the mediainfo check the bit rate control mode.
>>
>> Signed-off-by: Jun Zhao 
> 
> Not yet generating the HRD and timing information in VBR mode was deliberate, 
> because I don't know enough about the conformance properties of the new 
> proprietary rate controller which the Intel driver has switched to.  The old 
> CBR mode was straightforward to verify from the source code, and it seemed 
> reasonable to assume that the new CBR mode would be too given the constraints 
> on it (and also because existing versions of lavc couldn't be modified).
> 
> Can you say anything about the HRD conformance of the Intel driver here, or 
> was this patch purely for the metadata output (which may not actually match 
> the stream, hence my concern)?
> 
> Only the Intel driver is relevant to this as far as I know - the Mesa driver 
> does not support the packed headers necessary for this information to be 
> included in the stream.
> 
> 

I don't know the details about Intel driver's HRD conformance model, this patch 
just want to correct the bit rate mode metadata information.

>> ---
>>  libavcodec/vaapi_encode_h264.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 92e2955..47d0c94 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -760,7 +760,7 @@ static int 
>> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>>  char tmp[256];
>>  size_t header_len;
>>  
>> -if (index == 0 && ctx->va_rc_mode == VA_RC_CBR) {
>> +if (index == 0 && (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == 
>> VA_RC_VBR)) {
>>  *type = VAEncPackedHeaderH264_SEI;
>>  
>>  init_put_bits(, tmp, sizeof(tmp));
>> @@ -868,7 +868,7 @@ static int 
>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>  mseq->fixed_frame_rate_flag = 0;
>>  }
>>  
>> -if (ctx->va_rc_mode == VA_RC_CBR) {
>> +if (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == VA_RC_VBR) {
>>  priv->send_timing_sei = 1;
>>  mseq->nal_hrd_parameters_present_flag = 1;
>>  
>> @@ -886,8 +886,7 @@ static int 
>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>>  mseq->cpb_size_value_minus1[0] =
>>  (ctx->hrd_params.hrd.buffer_size >> mseq->cpb_size_scale + 
>> 4) - 1;
>>  
>> -// CBR mode isn't actually available here, despite naming.
>> -mseq->cbr_flag[0] = 0;
>> +mseq->cbr_flag[0] = (ctx->va_rc_mode == VA_RC_CBR ? 1 : 0);
> 
> As the comment notes, the necessary CBR mode isn't actually available.  
> Drivers only offer "soft" CBR, which can result in HRD overflow; this 
> specifies "hard" CBR, so if you want to set this flag you would need to 
> insert filler NAL units as well.
> 

In 1.8.0 release driver 
(https://lists.01.org/pipermail/intel-vaapi-media/2017-March/16.html), 
I can't reproduce the overflow issue with CBR mode. So I guess the new driver 
fix the HRD overflow
issue (I don't dig in the 1.8.0 driver) .

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

[FFmpeg-devel] [PATCH] Enhanced require_pkg_config() in configure to fallback to require() if pkg-config is missing

[Aaron Levinson]

From 48f7daba16e0fcdb83d9abd254800c7b9f4ab684 Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 17:30:47 -0700
Subject: [PATCH] Enhanced require_pkg_config() in configure to fallback to 
require() if pkg-config is missing

Purpose: Enhanced require_pkg_config() in configure to
fallback to require() if pkg-config is missing

Notes: This is likely mainly of relevance when building with MSVC on
Windows.  In my case, I used this approach to get libmfx when invoking
configure with --enable-libmfx, which is used for QuickSync (QSV).

Comments:

-- configure: Enhanced require_pkg_config() function to first check if
   $pkg_config is not false.  If not false, it goes through the
   standard steps of calling use_pkg_config(), but if false, it issues
   a log message and then calls require() with all the inputted
   arguments and an additional argument: -l$1.  So, for something like
   "require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit", this becomes
   "require libmfx "mfx/mfxvideo.h" MFXInit -llibmfx".  This is not a
   perfect solution, but the previous approach didn't work at all
   before when require_pkg_config() is used.
---
 configure | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 7f2b653..ad08b82 100755
--- a/configure
+++ b/configure
@@ -1347,7 +1347,12 @@ use_pkg_config(){
 }
 
 require_pkg_config(){
-use_pkg_config "$@" || die "ERROR: $pkg not found using 
pkg-config$pkg_config_fail_message"
+if test $pkg_config != false; then
+use_pkg_config "$@" || die "ERROR: $pkg not found using 
pkg-config$pkg_config_fail_message"
+else
+log require_pkg_config "No pkg-config, using require for $@"
+require "$@ -l$1"
+fi
 }
 
 require_libfreetype(){
-- 
2.10.1.windows.1

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'

[James Almer]

On 4/13/2017 8:43 PM, Michael Niedermayer wrote:
> On Thu, Apr 13, 2017 at 08:18:56PM +, James Almer wrote:
>> ffmpeg | branch: master | James Almer  | Thu Apr 13 
>> 17:09:52 2017 -0300| [5dba808064e7879c04d3e2fb4f10e709bedf51c2] | committer: 
>> James Almer
>>
>> Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'
>>
>> * commit '3e105d08848162b90d886bde59c010d4b0362a4b':
>>   build: Move entries related to building TOOLS to a subdirectory Makefile
>>
>> Merged-by: James Almer 
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5dba808064e7879c04d3e2fb4f10e709bedf51c2
>> ---
> 
> This breaks dependancies
> 
> for example
> 
> make distclean ; ./configure  --arch=x86_32 --target-os=linux 
> --extra-cflags=-m32 --extra-ldflags=-m32  --enable-cross-compile  && make 
> -j12 alltools
> 
> fails to build as libs dont get build before tools
> 
> 
> LD  tools/uncoded_frame
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.so when 
> searching for -lavdevice
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.a when 
> searching for -lavdevice
> /usr/bin/ld: cannot find -lavdevice
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.so when 
> searching for -lavfilter
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.a when 
> searching for -lavfilter
> /usr/bin/ld: cannot find -lavfilter
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.so when 
> searching for -lavformat
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.a when 
> searching for -lavformat
> /usr/bin/ld: cannot find -lavformat
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.so when 
> searching for -lavcodec
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.a when searching 
> for -lavcodec
> /usr/bin/ld: cannot find -lavcodec
> /usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.so when 
> searching for -lswresample
> /usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.a when 
> searching for -lswresample
> /usr/bin/ld: cannot find -lswresample
> /usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.so when 
> searching for -lswscale
> /usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.a when searching 
> for -lswscale
> /usr/bin/ld: cannot find -lswscale
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.so when searching 
> for -lavutil
> /usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.a when searching 
> for -lavutil
> /usr/bin/ld: cannot find -lavutil
> collect2: ld returned 1 exit status
> make: *** [tools/uncoded_frame] Error 1
> 
> make -j12 ffmpeg
> ...
> make -j12 tools/uncoded_frame
> succeeds now

Should be fixed, although a proper refactoring of the build system may
be in order.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Enhanced configure to improve compiler options associated with debugging with Visual C++ (MSVC)

[Aaron Levinson]

From 558b957eb85a669899750b2e150eba7cdee8dcd9 Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 16:46:59 -0700
Subject: [PATCH] Enhanced configure to improve compiler options associated with 
debugging with Visual C++ (MSVC) 

Purpose: Enhanced configure to improve compiler options
associated with debugging with Visual C++ (MSVC)

Comments:

-- configure:
a) In msvc_common_flags() function, replaced the use of -Z7 with -Zi.
   Effectively, there was no point to using -Z7 anymore given than
   -debug is passed to the linker already (per the line "enabled debug
   && add_ldflags -debug" elsewhere in the file), which causes a .pdb
   to be generated anyway.  -Z7 causes Codeview debug info to be
   placed in .obj files, while -Zi causes debug info to be placed in
   .pdb files.  As a result of switching from -Z7 to -Zi, this may
   result in slightly faster builds with MSVC, since it is apparently
   slower to process Codeview debug info.
b) In probe_cc() function, added _cflags_noopt declaration for MSVC.
   This is set to the following: "-Od -Og -MTd".  See comments for
   more details.  This is exposed when --disable-optimizations is used
   with configure.  In addition, now adding -Zo (or -d2Zi+, depending
   on the compiler version) to all the different _cflags_ variables to
   make it easier to debug optimized builds.  See changes and comments
   for further details.
---
 configure | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 684650a..7f2b653 100755
--- a/configure
+++ b/configure
@@ -3841,7 +3841,7 @@ msvc_common_flags(){
 -std=c99) ;;
 # Common flags
 -fomit-frame-pointer) ;;
--g)   echo -Z7 ;;
+-g)   echo -Zi ;;
 -fno-math-errno)  ;;
 -fno-common)  ;;
 -fno-signed-zeros);;
@@ -4150,6 +4150,37 @@ probe_cc(){
 _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
 _cflags_speed="-O2"
 _cflags_size="-O1"
+# Need to use -Og with -Od because otherwise has link issues with
+# "if (ARCH_...)" code.  Unfortunately, this isn't quite the same as
+# a fully debug build.  If the Dead Code Elimination (DCE) compiler
+# optimization requirement is ever removed, this can be replaced
+# with just -Od.  Note that the use of -Og results in a compiler
+# deprecation warning.
+# Also added -MTd to use the multithread, static, debug version of
+# the run-time library.  -MT appears to be the default otherwise.
+# Possible TODO:  revisit and potentially use -MD and -MDd for
+# smaller binaries.
+_cflags_noopt="-Od -Og -MTd"
+cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version 
\([[:digit:]]\{1,\}\)\..*/\1/p')
+
+# Make it easier to debug release builds.
+# See https://msdn.microsoft.com/en-us/library/dn785163.aspx for more
+# details.
+# It may not be necessary to add -Zo to _cflags_noopt due to the use
+# of -Od, but because -Og is also added currently, it is best to
+# add -Zo for now to make sure the best debugging experience is
+# possible.  If the DCE compiler optimization requirement is ever
+# removed, the _cflags_noopt lines can be removed.
+if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
+_cflags_speed="${_cflags_speed} -Zo"
+_cflags_size="${_cflags_size} -Zo"
+_cflags_noopt="${_cflags_noopt} -Zo"
+else
+_cflags_speed="${_cflags_speed} -d2Zi+"
+_cflags_size="${_cflags_size} -d2Zi+"
+_cflags_noopt="${_cflags_noopt} -d2Zi+"
+fi
+
 if $_cc -nologo- 2>&1 | grep -q Linker; then
 _ld_o='-out:$@'
 else
-- 
2.10.1.windows.1

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'

[Michael Niedermayer]

On Thu, Apr 13, 2017 at 08:18:56PM +, James Almer wrote:
> ffmpeg | branch: master | James Almer  | Thu Apr 13 
> 17:09:52 2017 -0300| [5dba808064e7879c04d3e2fb4f10e709bedf51c2] | committer: 
> James Almer
> 
> Merge commit '3e105d08848162b90d886bde59c010d4b0362a4b'
> 
> * commit '3e105d08848162b90d886bde59c010d4b0362a4b':
>   build: Move entries related to building TOOLS to a subdirectory Makefile
> 
> Merged-by: James Almer 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5dba808064e7879c04d3e2fb4f10e709bedf51c2
> ---

This breaks dependancies

for example

make distclean ; ./configure  --arch=x86_32 --target-os=linux 
--extra-cflags=-m32 --extra-ldflags=-m32  --enable-cross-compile  && make -j12 
alltools

fails to build as libs dont get build before tools


LD  tools/uncoded_frame
/usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.so when searching 
for -lavdevice
/usr/bin/ld: skipping incompatible /usr/local/lib/libavdevice.a when searching 
for -lavdevice
/usr/bin/ld: cannot find -lavdevice
/usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.so when searching 
for -lavfilter
/usr/bin/ld: skipping incompatible /usr/local/lib/libavfilter.a when searching 
for -lavfilter
/usr/bin/ld: cannot find -lavfilter
/usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.so when searching 
for -lavformat
/usr/bin/ld: skipping incompatible /usr/local/lib/libavformat.a when searching 
for -lavformat
/usr/bin/ld: cannot find -lavformat
/usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.so when searching 
for -lavcodec
/usr/bin/ld: skipping incompatible /usr/local/lib/libavcodec.a when searching 
for -lavcodec
/usr/bin/ld: cannot find -lavcodec
/usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.so when 
searching for -lswresample
/usr/bin/ld: skipping incompatible /usr/local/lib/libswresample.a when 
searching for -lswresample
/usr/bin/ld: cannot find -lswresample
/usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.so when searching 
for -lswscale
/usr/bin/ld: skipping incompatible /usr/local/lib/libswscale.a when searching 
for -lswscale
/usr/bin/ld: cannot find -lswscale
/usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.so when searching 
for -lavutil
/usr/bin/ld: skipping incompatible /usr/local/lib/libavutil.a when searching 
for -lavutil
/usr/bin/ld: cannot find -lavutil
collect2: ld returned 1 exit status
make: *** [tools/uncoded_frame] Error 1

make -j12 ffmpeg
...
make -j12 tools/uncoded_frame
succeeds now

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Marton Balint]

On Thu, 13 Apr 2017, Aaron Levinson wrote:


On 4/13/2017 2:12 AM, Hendrik Leppkes wrote:
On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson  

wrote:

Give it some time for the other changes to be reviewed by the people
that actually know decklink itself, you can include that in any new
versions of the patch then, no need to send one for that right now.

- Hendrik


Actually, the coding changes made to the decklink source files in this 
patch have pretty much nothing to do with decklink itself, and anyone 
with familiarity with semaphores and pthread could review those changes.
 In fact, all I really did was use already existing approaches for 
replacing a semaphore with the combination of a condition variable, 
mutex, and counter, and there are plenty of examples of how to do this 
on the Web.




Yeah, the changes look fine, please send an updated patch, I will apply it 
after some final testing.


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

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 2:36 PM, wm4  wrote:
> On Thu, 13 Apr 2017 02:47:39 -0700
> Aaron Levinson  wrote:
>
>> On 4/13/2017 2:10 AM, Hendrik Leppkes wrote:
>> > On Thu, Apr 13, 2017 at 11:04 AM, Aaron Levinson  
>> > wrote:
>> >>  static av_unused int pthread_cond_signal(pthread_cond_t *cond)
>> >>  {
>> >> -win32_cond_t *win32_cond = cond->Ptr;
>> >> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>> >>  int have_waiter;
>> >>  if (cond_signal) {
>> >>  cond_signal(cond);
>> >> @@ -400,17 +400,17 @@ static av_unused void w32thread_init(void)
>> >>  HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll"));
>> >>  /* if one is available, then they should all be available */
>> >>  cond_init  = (void (WINAPI*)(pthread_cond_t *))
>> >> -GetProcAddress(kernel_dll, "InitializeConditionVariable");
>> >> +GetProcAddress((HMODULE)kernel_dll, 
>> >> "InitializeConditionVariable");
>> >>  cond_broadcast = (void (WINAPI*)(pthread_cond_t *))
>> >> -GetProcAddress(kernel_dll, "WakeAllConditionVariable");
>> >> +GetProcAddress((HMODULE)kernel_dll, "WakeAllConditionVariable");
>> >>  cond_signal= (void (WINAPI*)(pthread_cond_t *))
>> >> -GetProcAddress(kernel_dll, "WakeConditionVariable");
>> >> +GetProcAddress((HMODULE)kernel_dll, "WakeConditionVariable");
>> >>  cond_wait  = (BOOL (WINAPI*)(pthread_cond_t *, pthread_mutex_t 
>> >> *, DWORD))
>> >> -GetProcAddress(kernel_dll, "SleepConditionVariableCS");
>> >> +GetProcAddress((HMODULE)kernel_dll, "SleepConditionVariableCS");
>> >>  initonce_begin = (BOOL (WINAPI*)(pthread_once_t *, DWORD, BOOL *, 
>> >> void **))
>> >> -GetProcAddress(kernel_dll, "InitOnceBeginInitialize");
>> >> +GetProcAddress((HMODULE)kernel_dll, "InitOnceBeginInitialize");
>> >>  initonce_complete = (BOOL (WINAPI*)(pthread_once_t *, DWORD, void *))
>> >> -GetProcAddress(kernel_dll, "InitOnceComplete");
>> >> +GetProcAddress((HMODULE)kernel_dll, "InitOnceComplete");
>> >>  #endif
>> >
>> > One more comment that I missed earlier (sorry), GetModuleHandle
>> > returns the type HMODULE, can't you just change the type of kernel_dll
>> > to match that, and avoid the casts here?
>> >
>> > - Hendrik
>>
>> Yes, it is simpler and cleaner to properly set the return value of 
>> GetModuleHandle() to an HMODULE.  Here is what is hopefully the final 
>> version of the patch, which is also much cleaner and simplified from the 
>> original version.
>>
>> Thanks,
>> Aaron
>>
>> --
>>
>> From 56f9a4b6c281a0d9382d2b4ec2e29aff5ab69fbc Mon Sep 17 00:00:00 2001
>> From: Aaron Levinson 
>> Date: Thu, 13 Apr 2017 02:38:02 -0700
>> Subject: [PATCH] Made appropriate changes to be able to successfully build 
>> C++ files using a Visual C++ build on Windows
>>
>> Purpose: Made appropriate changes to be able to successfully
>> build C++ files using a Visual C++ build on Windows.  Note that this is a
>> continuation of the "fixes w32pthreads to support C++" aspect of Kyle
>> Schwarz's "Remove pthread dependency" patch that is available at
>> https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
>> as far as I can tell, there was no follow-up after it was rejected.
>>
>> Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
>> approach for specifying -Fo$@ in configure based on code review from
>> Hendrik Leppkes for first version of patch.  Also simplified changes
>> to w32pthreads.h per Hendrik's review.
>>
>> Comments:
>>
>> -- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
>>get it to build when it is being included in a C++ file and built
>>with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
>>described above.
>>
>> -- configure:
>> a) Now calling set_ccvars CXX to cause the various CXX_ variables to
>>be setup properly.  For example, with MSVC (Microsoft Visual C++),
>>this causes CXX_O to be set to -Fo$@ instead of using the default
>>value.  The default value does not work with Visual C++.  This
>>change will also have the impact of correcting CXX_O (and possibly
>>CXX_C) for other compilers, although this is really only relevant
>>for the Intel compiler, in addition to MSVC.
>> b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
>>currently only relevant for building the
>>Blackmagic/Decklink-related files under avdevice.
>> ---
>>  compat/w32pthreads.h | 14 +++---
>>  configure|  3 +++
>>  2 files changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
>> index 0c9a7fa..eeead60 100644
>> --- a/compat/w32pthreads.h
>> +++ b/compat/w32pthreads.h
>> @@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
>>
>>  

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

[Hendrik Leppkes]

On Fri, Apr 14, 2017 at 12:00 AM, Ronald S. Bultje  wrote:
> Hi Aaron,
>
> On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson 
> wrote:
>
>> #if ARCH_AARCH64
>> if (ARCH_AARCH64)
>> return ff_get_cpu_flags_aarch64();
>> #endif
>>
>
> If you add #if, at least replace the if with it. #if + if is redundant.
>
>
>> Such a script could be reviewed and checked into the source base, then
>> applied to the source base, and possibly reused in the future as necessary.
>
>
> Why not use the script as a preprocessor during compilation? We did that
> for pre-2013 MSVC compilation and that worked """fine""".
>
> Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE but
> otherwise disabling optimizations? All other compilers seem capable of
> this, so it's odd to see that big Microsoft is incompetent whereas a bunch
> of opensource hippies could do the same 10+ yrs ago.
>

Its not a MSVC-exclusive problem. Many compilers don't perform DCE in
full debug builds, which are as such not possible with ffmpeg, making
debuging sometimes a bit annoying when a bunch of variables are
optimized out and stuff gets inlined.

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

[Ronald S. Bultje]

Hi Aaron,

On Thu, Apr 13, 2017 at 4:47 PM, Aaron Levinson 
wrote:

> #if ARCH_AARCH64
> if (ARCH_AARCH64)
> return ff_get_cpu_flags_aarch64();
> #endif
>

If you add #if, at least replace the if with it. #if + if is redundant.


> Such a script could be reviewed and checked into the source base, then
> applied to the source base, and possibly reused in the future as necessary.


Why not use the script as a preprocessor during compilation? We did that
for pre-2013 MSVC compilation and that worked """fine""".

Or why not ask Microsoft to add a CLI option to cl.exe for enabling DCE but
otherwise disabling optimizations? All other compilers seem capable of
this, so it's odd to see that big Microsoft is incompetent whereas a bunch
of opensource hippies could do the same 10+ yrs ago.

I have no opinion on #if vs. if, but I generally prefer to keep things as
they are. I'll follow whatever the rest of the code uses, and right now we
use if+DCE so I'll continue to use that.

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

Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++

[Aaron Levinson]

On 4/13/2017 1:23 PM, Hendrik Leppkes wrote:
> On Thu, Apr 13, 2017 at 10:09 PM, Aaron Levinson  wrote:
>> On 4/13/2017 3:55 AM, Hendrik Leppkes wrote:
>>>
>>> On Thu, Apr 13, 2017 at 12:39 PM, Aaron Levinson 
>>> wrote:

 On 4/13/2017 12:36 AM, Hendrik Leppkes wrote:
 diff --git a/configure b/configure
 index a383bf2..9a06437 100755
 --- a/configure
 +++ b/configure
 @@ -4843,8 +4843,6 @@ case $target_os in
  else
  target_os=mingw32
  fi
 -decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32
 -loleaut32"
 -decklink_indev_extralibs="$decklink_indev_extralibs -lole32
 -loleaut32"
  LIBTARGET=i386
  if enabled x86_64; then
  LIBTARGET="i386:x86-64"
 @@ -5946,6 +5944,19 @@ if ! disabled sdl2; then
  fi
  enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs
 $sdl2_libs

 +if enabled decklink; then
 +case $target_os in
 +mingw32*|mingw64*)
 +decklink_outdev_extralibs="$decklink_outdev_extralibs
 -lole32 -loleaut32"
 +decklink_indev_extralibs="$decklink_indev_extralibs -lole32
 -loleaut32"
 +;;
 +win32|win64)
 +decklink_outdev_extralibs="-lole32 -loleaut32"
 +decklink_indev_extralibs="-lole32 -loleaut32"
 +;;
 +esac
 +fi
 +
>>>
>>>
>>> Whats in the extralibs before this block that you need to clear out in
>>> the msvc case?
>>> Maybe that part should just be set conditionally so we can unify this,
>>> and don't set something we need to strip out again after.
>>>
>>> - Hendrik
>>
>>
>> decklink_outdev_extralibs and decklink_indev_extralibs are declared as
>> follows earlier in configure:
>>
>> decklink_indev_extralibs="-lstdc++"
>> decklink_outdev_extralibs="-lstdc++"
>>
>> This is done in the standard section where
>> __ can be found.
>>
>> libstdc++ is needed when building the Decklink source files with gcc/g++
>> because of, at a minimum, the use of STL in one of the .cpp files.
>>
>> For builds targeting Windows, -lole32 and -loleaut32 are also needed because
>> of the use of COM.  So, that explains why -lole32 and -loleaut32 are added
>> for both mingw and Windows.
>>
>> Finally, when building with the Microsoft compiler (cl.exe), libstdc++ is
>> not needed and actually can't be found.  The C/C++ run-time is included by
>> default in some form when building with cl.exe unless the -nodefaultlib
>> linker option is used.  So, that explains why it replaces the extralibs
>> variables with just -lole32 and -loleaut32 for Windows builds.  Note that
>> win32 to specified as the target_os when an msvc build is done, and it may
>> be the only case when target_os is set to win32 unless the user manually
>> sets it as an option when invoking configure.
>>
>> -lole32 and -loleaut32 is likely relevant for both cygwin and the Intel
>> compiler, but it should be a simple matter to add those later if anyone uses
>> those for building.  The elimination of -lstdc++ may also be relevant for
>> the Intel compiler but probably only when using the Intel compiler on
>> Windows.
>>
>> Anyway, I don't think an approach that moves -lstdc++ into the above if
>> block is any better or worse than the patch in its current form, and the
>> patch in its current form results in fewer changes to configure than a patch
>> that moves -lstdc++ around.
>>
> 
> You could add -lstdc++ to the msvc flag filter (ie.
> msvc_common_flags), since its never needed, and may be added by more
> things in the future, that would solve all of those neatly.
> 
> - Hendrik

That's a good idea and is cleaner and more general than the approach I had 
used.  Here's a new version of the patch, although it is my understanding that 
you may push the -lstdc++ change in msvc_common_flags() as part of another 
patch, but regardless, a new patch for this is needed.



From 00fdc9d15414a92a155eb7d1394bac3736dc9405 Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 14:22:19 -0700
Subject: [PATCH] Made minor changes to get the decklink avdevice code to build 
using Visual C++.

Purpose: Made minor changes to get the decklink avdevice code
to build using Visual C++.

Notes: Used Visual Studio 2015 (with update 3) for this.  Also made
changes to configure per Hendrik Leppkes's review of first and second
versions of patch.

Comments:

-- configure:
a) Added replacement of -lstdc++ with nothing in msvc_common_flags()
   since the C++ standard library is included by default for MSVC
   builds as part of the C/C++ run-time.  Also, MSVC builds will fail
   when -lstdc++ is used.
b) Added if enabled decklink section and setting
   

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

[Aaron Levinson]

On 4/13/2017 11:04 AM, Matt Oliver wrote:

On 14 April 2017 at 03:31, Hendrik Leppkes  wrote:


On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:

On 14 April 2017 at 02:11, Rostislav Pehlivanov 

wrote:





On 13 April 2017 at 16:51, wm4  wrote:


On Thu, 13 Apr 2017 17:39:57 +1000
Matt Oliver  wrote:


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


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.


It seems that the DCE requirement affects debug builds in general, and 
not just with Windows builds.  And, because of the DCE requirement, it 
is necessary to introduce some level of optimization in debug builds, 
which makes it harder to debug.  Sure, I can use -Zo with MSVC on 
Windows (see https://msdn.microsoft.com/en-us/library/dn785163.aspx for 
more details) to make it easier to debug release builds, but that's not 
the same as debugging a fully debug build, and something similar may not 
exist with other compilers.


I reviewed the thread mentioned by Matt Oliver above, and one of the 
arguments against removing DCE was that it may make some people less 
likely to work on the project.  Nicolas George wrote:


"Someone's personal preferences affect their willingness to work on the
project. Since the project is perpetually 

Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 10:09 PM, Aaron Levinson  wrote:
> On 4/13/2017 3:55 AM, Hendrik Leppkes wrote:
>>
>> On Thu, Apr 13, 2017 at 12:39 PM, Aaron Levinson 
>> wrote:
>>>
>>> On 4/13/2017 12:36 AM, Hendrik Leppkes wrote:
>>> diff --git a/configure b/configure
>>> index a383bf2..9a06437 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -4843,8 +4843,6 @@ case $target_os in
>>>  else
>>>  target_os=mingw32
>>>  fi
>>> -decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32
>>> -loleaut32"
>>> -decklink_indev_extralibs="$decklink_indev_extralibs -lole32
>>> -loleaut32"
>>>  LIBTARGET=i386
>>>  if enabled x86_64; then
>>>  LIBTARGET="i386:x86-64"
>>> @@ -5946,6 +5944,19 @@ if ! disabled sdl2; then
>>>  fi
>>>  enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs
>>> $sdl2_libs
>>>
>>> +if enabled decklink; then
>>> +case $target_os in
>>> +mingw32*|mingw64*)
>>> +decklink_outdev_extralibs="$decklink_outdev_extralibs
>>> -lole32 -loleaut32"
>>> +decklink_indev_extralibs="$decklink_indev_extralibs -lole32
>>> -loleaut32"
>>> +;;
>>> +win32|win64)
>>> +decklink_outdev_extralibs="-lole32 -loleaut32"
>>> +decklink_indev_extralibs="-lole32 -loleaut32"
>>> +;;
>>> +esac
>>> +fi
>>> +
>>
>>
>> Whats in the extralibs before this block that you need to clear out in
>> the msvc case?
>> Maybe that part should just be set conditionally so we can unify this,
>> and don't set something we need to strip out again after.
>>
>> - Hendrik
>
>
> decklink_outdev_extralibs and decklink_indev_extralibs are declared as
> follows earlier in configure:
>
> decklink_indev_extralibs="-lstdc++"
> decklink_outdev_extralibs="-lstdc++"
>
> This is done in the standard section where
> __ can be found.
>
> libstdc++ is needed when building the Decklink source files with gcc/g++
> because of, at a minimum, the use of STL in one of the .cpp files.
>
> For builds targeting Windows, -lole32 and -loleaut32 are also needed because
> of the use of COM.  So, that explains why -lole32 and -loleaut32 are added
> for both mingw and Windows.
>
> Finally, when building with the Microsoft compiler (cl.exe), libstdc++ is
> not needed and actually can't be found.  The C/C++ run-time is included by
> default in some form when building with cl.exe unless the -nodefaultlib
> linker option is used.  So, that explains why it replaces the extralibs
> variables with just -lole32 and -loleaut32 for Windows builds.  Note that
> win32 to specified as the target_os when an msvc build is done, and it may
> be the only case when target_os is set to win32 unless the user manually
> sets it as an option when invoking configure.
>
> -lole32 and -loleaut32 is likely relevant for both cygwin and the Intel
> compiler, but it should be a simple matter to add those later if anyone uses
> those for building.  The elimination of -lstdc++ may also be relevant for
> the Intel compiler but probably only when using the Intel compiler on
> Windows.
>
> Anyway, I don't think an approach that moves -lstdc++ into the above if
> block is any better or worse than the patch in its current form, and the
> patch in its current form results in fewer changes to configure than a patch
> that moves -lstdc++ around.
>

You could add -lstdc++ to the msvc flag filter (ie.
msvc_common_flags), since its never needed, and may be added by more
things in the future, that would solve all of those neatly.

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

Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++

[Aaron Levinson]

On 4/13/2017 3:55 AM, Hendrik Leppkes wrote:

On Thu, Apr 13, 2017 at 12:39 PM, Aaron Levinson  wrote:

On 4/13/2017 12:36 AM, Hendrik Leppkes wrote:
diff --git a/configure b/configure
index a383bf2..9a06437 100755
--- a/configure
+++ b/configure
@@ -4843,8 +4843,6 @@ case $target_os in
 else
 target_os=mingw32
 fi
-decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
-loleaut32"
-decklink_indev_extralibs="$decklink_indev_extralibs -lole32 -loleaut32"
 LIBTARGET=i386
 if enabled x86_64; then
 LIBTARGET="i386:x86-64"
@@ -5946,6 +5944,19 @@ if ! disabled sdl2; then
 fi
 enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs 
$sdl2_libs

+if enabled decklink; then
+case $target_os in
+mingw32*|mingw64*)
+decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
-loleaut32"
+decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
-loleaut32"
+;;
+win32|win64)
+decklink_outdev_extralibs="-lole32 -loleaut32"
+decklink_indev_extralibs="-lole32 -loleaut32"
+;;
+esac
+fi
+


Whats in the extralibs before this block that you need to clear out in
the msvc case?
Maybe that part should just be set conditionally so we can unify this,
and don't set something we need to strip out again after.

- Hendrik


decklink_outdev_extralibs and decklink_indev_extralibs are declared as 
follows earlier in configure:


decklink_indev_extralibs="-lstdc++"
decklink_outdev_extralibs="-lstdc++"

This is done in the standard section where 
__ can be found.


libstdc++ is needed when building the Decklink source files with gcc/g++ 
because of, at a minimum, the use of STL in one of the .cpp files.


For builds targeting Windows, -lole32 and -loleaut32 are also needed 
because of the use of COM.  So, that explains why -lole32 and -loleaut32 
are added for both mingw and Windows.


Finally, when building with the Microsoft compiler (cl.exe), libstdc++ 
is not needed and actually can't be found.  The C/C++ run-time is 
included by default in some form when building with cl.exe unless the 
-nodefaultlib linker option is used.  So, that explains why it replaces 
the extralibs variables with just -lole32 and -loleaut32 for Windows 
builds.  Note that win32 to specified as the target_os when an msvc 
build is done, and it may be the only case when target_os is set to 
win32 unless the user manually sets it as an option when invoking configure.


-lole32 and -loleaut32 is likely relevant for both cygwin and the Intel 
compiler, but it should be a simple matter to add those later if anyone 
uses those for building.  The elimination of -lstdc++ may also be 
relevant for the Intel compiler but probably only when using the Intel 
compiler on Windows.


Anyway, I don't think an approach that moves -lstdc++ into the above if 
block is any better or worse than the patch in its current form, and the 
patch in its current form results in fewer changes to configure than a 
patch that moves -lstdc++ around.


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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Aaron Levinson]

On 4/13/2017 2:12 AM, Hendrik Leppkes wrote:

On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson  wrote:
Give it some time for the other changes to be reviewed by the people
that actually know decklink itself, you can include that in any new
versions of the patch then, no need to send one for that right now.

- Hendrik


Actually, the coding changes made to the decklink source files in this 
patch have pretty much nothing to do with decklink itself, and anyone 
with familiarity with semaphores and pthread could review those changes. 
 In fact, all I really did was use already existing approaches for 
replacing a semaphore with the combination of a condition variable, 
mutex, and counter, and there are plenty of examples of how to do this 
on the Web.


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

[FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 src/index | 53 +
 1 file changed, 53 insertions(+)

diff --git a/src/index b/src/index
index c203676..1b8a037 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,59 @@
 News
   
 
+  April 13th, 2017, FFmpeg 3.3 "Hilbert"
+  
+FFmpeg 3.3 "Hilbert", a new
+major release, is now available! Some of the highlights:
+  
+  
+
+  Apple Pixlet decoder
+  NewTek SpeedHQ decoder
+  QDMC audio decoder
+  PSD (Photoshop Document) decoder
+  FM Screen Capture decoder
+  ScreenPressor decoder
+  XPM decoder
+  DNxHR decoder fixes for HQX and high resolution videos
+  ClearVideo decoder (partial)
+  16.8 and 24.0 floating point PCM decoder
+  Intel QSV-accelerated VP8 video decoding
+
+
+  native Opus encoder
+  DNxHR 444 and HQX encoding
+  Quality improvements for the (M)JPEG encoder
+  VAAPI-accelerated MPEG-2 and VP8 encoding
+
+
+  premultiply video filter
+  abitscope multimedia filter
+  readeia608 filter
+  threshold filter
+  midequalizer filter
+  MPEG-7 Video Signature filter
+  add internal ebur128 library, remove external libebur128 
dependency
+  Intel QSV video scaling and deinterlacing filters
+
+
+  Sample Dump eXchange demuxer
+  MIDI Sample Dump Standard demuxer
+  Scenarist Closed Captions demuxer and muxer
+  Support MOV with multiple sample description tables
+  Pro-MPEG CoP #3-R2 FEC protocol
+  Support for spherical videos
+
+
+  CrystalHD decoder moved to new decode API
+  configure now fails if autodetect-libraries are requested but not 
found
+
+  
+  
+We strongly recommend users, distributors, and system integrators to
+upgrade unless they use current git master.
+  
+
   October 30th, 2016, Results: Summer Of Code 
2016.
   
 This has been a long time coming but we wanted to give a proper closure to 
our participation in this run of the program and it takes time. Sometimes it's 
just to get the final report for each project trimmed down, others, is 
finalizing whatever was still in progress when the program finished: final 
patches need to be merged, TODO lists stabilized, future plans agreed; you name 
it.
-- 
2.12.2.762.g0e3151a226

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

[FFmpeg-devel] [PATCH 6/6] ffmpeg: remove bsf extradata propagation hack

[James Almer]

The offending bitstream filter was fixed, so this is no longer needed.

Signed-off-by: James Almer 
---
 ffmpeg.c | 19 ---
 ffmpeg.h |  1 -
 ffmpeg_opt.c |  7 ---
 3 files changed, 27 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e4b94b2fa0..1a0f6a57f1 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -536,7 +536,6 @@ static void ffmpeg_cleanup(int ret)
 for (j = 0; j < ost->nb_bitstream_filters; j++)
 av_bsf_free(>bsf_ctx[j]);
 av_freep(>bsf_ctx);
-av_freep(>bsf_extradata_updated);
 
 av_frame_free(>filtered_frame);
 av_frame_free(>last_frame);
@@ -835,27 +834,9 @@ static void output_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost)
 continue;
 } else if (ret < 0)
 goto finish;
-/* HACK! - aac_adtstoasc updates extradata after filtering the 
first frame when
- * the api states this shouldn't happen after init(). Propagate it 
here to the
- * muxer and to the next filters in the chain to workaround this.
- * TODO/FIXME - Make aac_adtstoasc use new packet side data 
instead of changing
- * par_out->extradata and adapt muxers accordingly to get rid of 
this. */
-if (!(ost->bsf_extradata_updated[idx - 1] & 1)) {
-ret = avcodec_parameters_copy(ost->st->codecpar, 
ost->bsf_ctx[idx - 1]->par_out);
-if (ret < 0)
-goto finish;
-ost->bsf_extradata_updated[idx - 1] |= 1;
-}
 
 /* send it to the next filter down the chain or to the muxer */
 if (idx < ost->nb_bitstream_filters) {
-/* HACK/FIXME! - See above */
-if (!(ost->bsf_extradata_updated[idx] & 2)) {
-ret = avcodec_parameters_copy(ost->bsf_ctx[idx]->par_out, 
ost->bsf_ctx[idx - 1]->par_out);
-if (ret < 0)
-goto finish;
-ost->bsf_extradata_updated[idx] |= 2;
-}
 ret = av_bsf_send_packet(ost->bsf_ctx[idx], pkt);
 if (ret < 0)
 goto finish;
diff --git a/ffmpeg.h b/ffmpeg.h
index 4d0456c1fb..1a381aa345 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -455,7 +455,6 @@ typedef struct OutputStream {
 AVRational mux_timebase;
 
 intnb_bitstream_filters;
-uint8_t  *bsf_extradata_updated;
 AVBSFContext**bsf_ctx;
 
 AVCodecContext *enc_ctx;
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index d1fe8742ff..08e03c4ef9 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1374,13 +1374,6 @@ static OutputStream *new_output_stream(OptionsContext 
*o, AVFormatContext *oc, e
 if (*bsfs)
 bsfs++;
 }
-if (ost->nb_bitstream_filters) {
-ost->bsf_extradata_updated = 
av_mallocz_array(ost->nb_bitstream_filters, 
sizeof(*ost->bsf_extradata_updated));
-if (!ost->bsf_extradata_updated) {
-av_log(NULL, AV_LOG_FATAL, "Bitstream filter memory allocation 
failed\n");
-exit_program(1);
-}
-}
 
 MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, oc, st);
 if (codec_tag) {
-- 
2.12.1

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

[FFmpeg-devel] [PATCH 5/6] avformat/mux: remove autobsf extradata propagation hack

[James Almer]

The offending bitstream filter was fixed, so this is no longer needed.

Signed-off-by: James Almer 
---
 libavformat/mux.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 3a5e876913..033e359ca2 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -893,13 +893,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 for (i = 0; i < st->internal->nb_bsfcs; i++) {
 AVBSFContext *ctx = st->internal->bsfcs[i];
-if (i > 0) {
-AVBSFContext* prev_ctx = st->internal->bsfcs[i - 1];
-if (prev_ctx->par_out->extradata_size != 
ctx->par_in->extradata_size) {
-if ((ret = avcodec_parameters_copy(ctx->par_in, 
prev_ctx->par_out)) < 0)
-return ret;
-}
-}
 // TODO: when any bitstream filter requires flushing at EOF, we'll 
need to
 // flush each stream's BSF chain on write_trailer.
 if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
@@ -919,12 +912,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 ctx->filter->name, pkt->stream_index);
 return ret;
 }
-if (i == st->internal->nb_bsfcs - 1) {
-if (ctx->par_out->extradata_size != st->codecpar->extradata_size) {
-if ((ret = avcodec_parameters_copy(st->codecpar, 
ctx->par_out)) < 0)
-return ret;
-}
-}
 }
 return 1;
 }
-- 
2.12.1

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

[FFmpeg-devel] [PATCH 1/6] avformat/movenc: always check for new extradata on a packet

[James Almer]

Don't just look at zero sized packets, and also check for AAC extradata
updates, in preparation for the following patches.

Signed-off-by: James Almer 
---
 libavformat/movenc.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e6e2313c53..d4fa60b029 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5303,6 +5303,24 @@ static int mov_write_single_packet(AVFormatContext *s, 
AVPacket *pkt)
 mov->flags &= ~FF_MOV_FLAG_FRAG_DISCONT;
 }
 
+if (trk->par->codec_id == AV_CODEC_ID_MP4ALS ||
+trk->par->codec_id == AV_CODEC_ID_AAC ||
+trk->par->codec_id == AV_CODEC_ID_FLAC) {
+int side_size = 0;
+uint8_t *side = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, _size);
+if (side && side_size > 0 && (side_size != par->extradata_size || 
memcmp(side, par->extradata, side_size))) {
+void *newextra = av_mallocz(side_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!newextra)
+return AVERROR(ENOMEM);
+av_free(par->extradata);
+par->extradata = newextra;
+memcpy(par->extradata, side, side_size);
+par->extradata_size = side_size;
+if (!pkt->size) // Flush packet
+mov->need_rewrite_extradata = 1;
+}
+}
+
 if (!pkt->size) {
 if (trk->start_dts == AV_NOPTS_VALUE && trk->frag_discont) {
 trk->start_dts = pkt->dts;
@@ -5312,22 +5330,6 @@ static int mov_write_single_packet(AVFormatContext *s, 
AVPacket *pkt)
 trk->start_cts = 0;
 }
 
-if (trk->par->codec_id == AV_CODEC_ID_MP4ALS ||
-trk->par->codec_id == AV_CODEC_ID_FLAC) {
-int side_size = 0;
-uint8_t *side = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, _size);
-if (side && side_size > 0 && (side_size != par->extradata_size 
|| memcmp(side, par->extradata, side_size))) {
-void *newextra = av_mallocz(side_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!newextra)
-return AVERROR(ENOMEM);
-av_free(par->extradata);
-par->extradata = newextra;
-memcpy(par->extradata, side, side_size);
-par->extradata_size = side_size;
-mov->need_rewrite_extradata = 1;
-}
-}
-
 return 0; /* Discard 0 sized packets */
 }
 
-- 
2.12.1

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

[FFmpeg-devel] [PATCH 4/6] avcodec/aac_adtstoasc: propagate new extradata using packet side data

[James Almer]

This removes the current API violating behavior of overwritting the stream's
extradata during packet filtering, something that should not happen after the
av_bsf_init() call.

The bitstream filter generated extradata is no longer available during
write_header(), and as such not usable with non seekable output. The FATE
tests are updated to reflect this.

Signed-off-by: James Almer 
---
 libavcodec/aac_adtstoasc_bsf.c   |  5 ++---
 tests/fate/aac.mak   |  5 ++---
 tests/fate/avformat.mak  |  4 ++--
 tests/ref/fate/aac-autobsf-adtstoasc | 43 
 4 files changed, 49 insertions(+), 8 deletions(-)
 create mode 100644 tests/ref/fate/aac-autobsf-adtstoasc

diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
index 1067160559..0e4767d424 100644
--- a/libavcodec/aac_adtstoasc_bsf.c
+++ b/libavcodec/aac_adtstoasc_bsf.c
@@ -97,7 +97,8 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket 
*out)
 in->data += get_bits_count()/8;
 }
 
-extradata = av_mallocz(2 + pce_size + AV_INPUT_BUFFER_PADDING_SIZE);
+extradata = av_packet_new_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
+2 + pce_size);
 if (!extradata) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -115,8 +116,6 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
AVPacket *out)
 memcpy(extradata + 2, pce_data, pce_size);
 }
 
-bsfc->par_out->extradata = extradata;
-bsfc->par_out->extradata_size = 2 + pce_size;
 ctx->first_frame_done = 1;
 }
 
diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 2af66c2b23..74d3e96efe 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -241,9 +241,8 @@ FATE_AAC_LATM += fate-aac-latm_stereo_to_51
 fate-aac-latm_stereo_to_51: CMD = pcm -i 
$(TARGET_SAMPLES)/aac/latm_stereo_to_51.ts -channel_layout 5.1
 fate-aac-latm_stereo_to_51: REF = $(SAMPLES)/aac/latm_stereo_to_51_ref.s16
 
-fate-aac-autobsf-adtstoasc: CMD = md5 -i 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts -acodec 
copy -fflags +bitexact -f matroska
-fate-aac-autobsf-adtstoasc: CMP = oneline
-fate-aac-autobsf-adtstoasc: REF = 8c76732bd04d9eb3468f9f842439774d
+fate-aac-autobsf-adtstoasc: CMD = transcode "aac" 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts \
+matroska "-c:a copy" "-c:a copy"
 
 FATE_AAC-$(call  DEMDEC, AAC,AAC)  += $(FATE_AAC_CT_RAW)
 FATE_AAC-$(call  DEMDEC, MOV,AAC)  += $(FATE_AAC)
diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index 10702ec8e2..82a531c7a5 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -93,14 +93,14 @@ tests/data/mp4-to-ts.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | 
tests/data
 tests/data/adts-to-mkv.m3u8: TAG = GEN
 tests/data/adts-to-mkv.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
--i $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts 
\
+-i $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.m4a \
 -f segment -segment_time 1 -map 0 -flags +bitexact -codec copy 
-segment_format_options live=1 \
 -segment_list $(TARGET_PATH)/$@ -y 
$(TARGET_PATH)/tests/data/adts-to-mkv-%03d.mkv 2>/dev/null
 
 tests/data/adts-to-mkv-header.mkv: TAG = GEN
 tests/data/adts-to-mkv-header.mkv: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
--i $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts 
\
+-i $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.m4a \
 -f segment -segment_time 1 -map 0 -flags +bitexact -codec copy 
-segment_format_options live=1 \
 -segment_header_filename 
$(TARGET_PATH)/tests/data/adts-to-mkv-header.mkv \
 -y $(TARGET_PATH)/tests/data/adts-to-mkv-header-%03d.mkv 2>/dev/null
diff --git a/tests/ref/fate/aac-autobsf-adtstoasc 
b/tests/ref/fate/aac-autobsf-adtstoasc
new file mode 100644
index 00..9ca8e7ed9e
--- /dev/null
+++ b/tests/ref/fate/aac-autobsf-adtstoasc
@@ -0,0 +1,43 @@
+b0375ba00bcbd55023a176255b8d4ba2 
*tests/data/fate/aac-autobsf-adtstoasc.matroska
+6728 tests/data/fate/aac-autobsf-adtstoasc.matroska
+#extradata 0:2, 0x0030001c
+#tb 0: 1/1000
+#media_type 0: audio
+#codec_id 0: aac
+#sample_rate 0: 16000
+#channel_layout 0: 4
+#channel_layout_name 0: mono
+0,  0,  0,   64,4, 0x02f70117
+0, 64, 64,   64,  163, 0xd5f85007
+0,128,128,   64,  127, 0x66484065
+0,192,192,   64,   94, 0x55222bd6
+0,256,256,   64,  314, 0x3c7e923a
+0,320,320,   64,  207, 0x1efc5d1b
+0,384,384,   64,  119, 0xb2a13601
+0,448, 

[FFmpeg-devel] [PATCH 3/6] avformat/latmenc: check packet side data for AAC extradata updates

[James Almer]

This is in preparation for the following patch.

Signed-off-by: James Almer 
---
 libavformat/latmenc.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index 43ca4821cb..c919976d49 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -146,20 +146,34 @@ static void latm_write_frame_header(AVFormatContext *s, 
PutBitContext *bs)
 static int latm_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 LATMContext *ctx = s->priv_data;
+AVCodecParameters *par = s->streams[0]->codecpar;
 AVIOContext *pb = s->pb;
 PutBitContext bs;
 int i, len;
 uint8_t loas_header[] = "\x56\xe0\x00";
 
-if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_AAC_LATM)
+if (par->codec_id == AV_CODEC_ID_AAC_LATM)
 return ff_raw_write_packet(s, pkt);
 
-if (!s->streams[0]->codecpar->extradata) {
+if (!par->extradata) {
 if(pkt->size > 2 && pkt->data[0] == 0x56 && (pkt->data[1] >> 4) == 0xe 
&&
 (AV_RB16(pkt->data + 1) & 0x1FFF) + 3 == pkt->size)
 return ff_raw_write_packet(s, pkt);
-else
-return AVERROR_INVALIDDATA;
+else {
+uint8_t *side_data;
+int side_data_size = 0, ret;
+
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+_data_size);
+if (side_data_size) {
+if (latm_decode_extradata(ctx, side_data, side_data_size) < 0)
+return AVERROR_INVALIDDATA;
+ret = ff_alloc_extradata(par, side_data_size);
+if (ret < 0)
+return ret;
+memcpy(par->extradata, side_data, side_data_size);
+}
+}
 }
 
 if (pkt->size > 0x1fff)
-- 
2.12.1

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

[FFmpeg-devel] [PATCH 2/6] avformat/matroskaenc: check packet side data for AAC extradata updates

[James Almer]

This adapts and merges commit f4bf236338f6001736a4784b9c23de863057a583
from libav, originally skipped in 13a211e6320d061d9e8c29354c81239324b2db03
as it was not necessary back then.

Is's applied now in preparation for the following patches, where the
aac_adtstoasc bitstream filter will start to correctly propagate the new
extradata through packet side data.

Signed-off-by: James Almer 
---
 libavformat/matroskaenc.c | 74 ++-
 1 file changed, 66 insertions(+), 8 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 9c7a213db9..44c53e06b7 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -93,6 +93,8 @@ typedef struct mkv_cues {
 typedef struct mkv_track {
 int write_dts;
 int has_cue;
+int sample_rate;
+int64_t sample_rate_offset;
 int64_t codecpriv_offset;
 int64_t ts_offset;
 } mkv_track;
@@ -715,24 +717,40 @@ static int put_flac_codecpriv(AVFormatContext *s,
 return 0;
 }
 
-static int get_aac_sample_rates(AVFormatContext *s, AVCodecParameters *par,
+static int get_aac_sample_rates(AVFormatContext *s, uint8_t *extradata, int 
extradata_size,
 int *sample_rate, int *output_sample_rate)
 {
 MPEG4AudioConfig mp4ac;
+int ret;
 
-if (avpriv_mpeg4audio_get_config(, par->extradata,
- par->extradata_size * 8, 1) < 0) {
+ret = avpriv_mpeg4audio_get_config(, extradata,
+   extradata_size * 8, 1);
+/* Don't abort if the failure is because of missing extradata. Assume in 
that
+ * case a bitstream filter will provide the muxer with the extradata in the
+ * first packet.
+ * Abort however if s->pb is not seekable, as we would not be able to seek 
back
+ * to write the sample rate elements once the extradata shows up, anyway. 
*/
+if (ret < 0 && (extradata_size || !(s->pb->seekable & 
AVIO_SEEKABLE_NORMAL))) {
 av_log(s, AV_LOG_ERROR,
"Error parsing AAC extradata, unable to determine 
samplerate.\n");
 return AVERROR(EINVAL);
 }
 
-*sample_rate= mp4ac.sample_rate;
-*output_sample_rate = mp4ac.ext_sample_rate;
+if (ret < 0) {
+/* This will only happen when this function is called while writing the
+ * header and no extradata is available. The space for this element has
+ * to be reserved for when this function is called again after the
+ * extradata shows up in the first packet, as there's no way to know if
+ * output_sample_rate will be different than sample_rate or not. */
+*output_sample_rate = *sample_rate;
+} else {
+*sample_rate= mp4ac.sample_rate;
+*output_sample_rate = mp4ac.ext_sample_rate;
+}
 return 0;
 }
 
-static int mkv_write_native_codecprivate(AVFormatContext *s,
+static int mkv_write_native_codecprivate(AVFormatContext *s, AVIOContext *pb,
  AVCodecParameters *par,
  AVIOContext *dyn_cp)
 {
@@ -761,6 +779,12 @@ static int mkv_write_native_codecprivate(AVFormatContext 
*s,
 avio_write(dyn_cp, par->extradata + 12,
par->extradata_size - 12);
 break;
+case AV_CODEC_ID_AAC:
+if (par->extradata_size)
+avio_write(dyn_cp, par->extradata, par->extradata_size);
+else
+put_ebml_void(pb, MAX_PCE_SIZE + 2 + 4);
+break;
 default:
 if (par->codec_id == AV_CODEC_ID_PRORES &&
 ff_codec_get_id(ff_codec_movvideo_tags, par->codec_tag) == 
AV_CODEC_ID_PRORES) {
@@ -785,7 +809,7 @@ static int mkv_write_codecprivate(AVFormatContext *s, 
AVIOContext *pb,
 return ret;
 
 if (native_id) {
-ret = mkv_write_native_codecprivate(s, par, dyn_cp);
+ret = mkv_write_native_codecprivate(s, pb, par, dyn_cp);
 } else if (par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (qt_id) {
 if (!par->codec_tag)
@@ -1164,7 +1188,8 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 }
 
 if (par->codec_id == AV_CODEC_ID_AAC) {
-ret = get_aac_sample_rates(s, par, _rate, _sample_rate);
+ret = get_aac_sample_rates(s, par->extradata, par->extradata_size, 
_rate,
+   _sample_rate);
 if (ret < 0)
 return ret;
 }
@@ -1359,6 +1384,8 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 
 subinfo = start_ebml_master(pb, MATROSKA_ID_TRACKAUDIO, 0);
 put_ebml_uint  (pb, MATROSKA_ID_AUDIOCHANNELS, par->channels);
+
+mkv->tracks[i].sample_rate_offset = avio_tell(pb);
 put_ebml_float (pb, MATROSKA_ID_AUDIOSAMPLINGFREQ, sample_rate);
 if (output_sample_rate)
 

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

[Matt Oliver]

On 14 April 2017 at 03:31, Hendrik Leppkes  wrote:

> On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:
> > On 14 April 2017 at 02:11, Rostislav Pehlivanov 
> wrote:
> >
> >>
> >>
> >> On 13 April 2017 at 16:51, wm4  wrote:
> >>
> >>> On Thu, 13 Apr 2017 17:39:57 +1000
> >>> Matt Oliver  wrote:
> >>>
> >>> > 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).
> >>>
> >>> 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

[FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 src/index | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/src/index b/src/index
index c203676..f7f9ea2 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,57 @@
 News
   
 
+  April 13th, 2017, FFmpeg 3.3 "Hilbert"
+  
+FFmpeg 3.3 "Hilbert", a new
+major release, is now available! Some of the highlights:
+  
+  
+
+  Apple Pixlet decoder
+  NewTek SpeedHQ decoder
+  QDMC audio decoder
+  PSD (Photoshop Document) decoder
+  FM Screen Capture decoder
+  ScreenPressor decoder
+  XPM decoder
+  ClearVideo decoder (partial)
+  Intel QSV-accelerated VP8 video decoding
+
+
+  native Opus encoder
+  Quality improvements for the (M)JPEG encoder
+  VAAPI-accelerated MPEG-2 and VP8 encoding
+
+
+  premultiply video filter
+  abitscope multimedia filter
+  readeia608 filter
+  threshold filter
+  midequalizer filter
+  MPEG-7 Video Signature filter
+  add internal ebur128 library, remove external libebur128 
dependency
+  Intel QSV video scaling and deinterlacing filters
+
+
+  Sample Dump eXchange demuxer
+  MIDI Sample Dump Standard demuxer
+  Scenarist Closed Captions demuxer and muxer
+  Support MOV with multiple sample description tables
+  Pro-MPEG CoP #3-R2 FEC protocol
+  Support for spherical videos
+
+
+  CrystalHD decoder moved to new decode API
+  Removed the legacy X11 screen grabber, use XCB instead
+  configure now fails if autodetect-libraries are requested but not 
found
+
+  
+  
+We strongly recommend users, distributors, and system integrators to
+upgrade unless they use current git master.
+  
+
   October 30th, 2016, Results: Summer Of Code 
2016.
   
 This has been a long time coming but we wanted to give a proper closure to 
our participation in this run of the program and it takes time. Sometimes it's 
just to get the final report for each project trimmed down, others, is 
finalizing whatever was still in progress when the program finished: final 
patches need to be merged, TODO lists stabilized, future plans agreed; you name 
it.
-- 
2.12.2.762.g0e3151a226

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

Re: [FFmpeg-devel] FFplay: progress bar feature proposal

[Raymond Pierce]

13.04.2017, 09:40, "Steven Liu" :
> 2017-04-13 20:48 GMT+08:00 Raymond Pierce :
>
>>  Hi. Currently FFplay has no visible progress bar and it is hard to tell
>>  where a stream is currently positioned. So if one wants, for example, to
>>  rewind
>>  a little back relative to current position using right mouse click it is
>>  always
>>  guessing and trying.
>>
>>  I propose very simple 1-pixel progress bar which can be turned on or off
>>  during
>>  playback by pressing a button (I use 'L', from 'line'). By default the bar
>>  is off.
>>
>>  I choose bright green color (#00ff00) for the part to the left of a current
>>  position and pure black for the part to the right.
>>
>>  You can see how it looks on the attached image.
>>
>>  Draft patch is applied. One global variable ('static int
>>  show_progress_line')
>>  and one function ('static void video_progress_line_display(VideoState
>>  *is)')
>>  have been added. Also the existing 'video_display()' function has been
>>  moved
>>  below 'get_master_clock()' as the latter is used in the new function.
>>
>>  What do you think?
>>  ___
>>  ffmpeg-devel mailing list
>>  ffmpeg-devel@ffmpeg.org
>>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> git commit -a
> git format-patch -s -1
>
> You should use the command looks like the above git command to make patch
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hello, Steven. Thank you for the advice. New patch in the attachment.
Should I post a new message with the patch to ffmpeg-devel@ffmpeg.org list?
From e780cfa4330ae87cd4506ec2ccfe39ea045f2134 Mon Sep 17 00:00:00 2001
From: Ray Pierce 
Date: Thu, 13 Apr 2017 20:41:59 +0500
Subject: [PATCH] Add FFplay progress bar feature

Signed-off-by: Ray Pierce 
---
 ffplay.c | 52 +---
 1 file changed, 37 insertions(+), 15 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index cf138dc515..a73699475b 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -344,6 +344,7 @@ static const char *video_codec_name;
 double rdftspeed = 0.02;
 static int64_t cursor_last_shown;
 static int cursor_hidden = 0;
+static int show_progress_line = 0;
 #if CONFIG_AVFILTER
 static const char **vfilters_list = NULL;
 static int nb_vfilters = 0;
@@ -1299,21 +1300,6 @@ static int video_open(VideoState *is)
 return 0;
 }
 
-/* display the current picture, if any */
-static void video_display(VideoState *is)
-{
-if (!window)
-video_open(is);
-
-SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
-SDL_RenderClear(renderer);
-if (is->audio_st && is->show_mode != SHOW_MODE_VIDEO)
-video_audio_display(is);
-else if (is->video_st)
-video_image_display(is);
-SDL_RenderPresent(renderer);
-}
-
 static double get_clock(Clock *c)
 {
 if (*c->queue_serial != c->serial)
@@ -1513,6 +1499,37 @@ static void update_video_pts(VideoState *is, double pts, int64_t pos, int serial
 sync_clock_to_slave(>extclk, >vidclk);
 }
 
+static void video_progress_line_display(VideoState *is) {
+double d = is->ic->duration / 1.0e6;
+if (d > 0) {
+double t = get_master_clock(is);
+int w = is->width * t / d;
+SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
+fill_rectangle(0, is->height-1, w, 1);
+SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
+fill_rectangle(w, is->height-1, is->width-w, 1);
+} else {
+show_progress_line = 0;
+}
+}
+
+/* display the current picture, if any */
+static void video_display(VideoState *is)
+{
+if (!window)
+video_open(is);
+
+SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
+SDL_RenderClear(renderer);
+if (is->audio_st && is->show_mode != SHOW_MODE_VIDEO)
+video_audio_display(is);
+else if (is->video_st)
+video_image_display(is);
+if (show_progress_line)
+video_progress_line_display(is);
+SDL_RenderPresent(renderer);
+}
+
 /* called to display each frame */
 static void video_refresh(void *opaque, double *remaining_time)
 {
@@ -3265,6 +3282,9 @@ static void event_loop(VideoState *cur_stream)
 toggle_audio_display(cur_stream);
 #endif
 break;
+case SDLK_l:
+show_progress_line = !show_progress_line;
+break;
 case SDLK_PAGEUP:
 if (cur_stream->ic->nb_chapters <= 1) {
 incr = 600.0;
@@ -3543,6 +3563,7 @@ static const OptionDef options[] = {
 #endif
 { "rdftspeed", OPT_INT | HAS_ARG| OPT_AUDIO | OPT_EXPERT, {  }, "rdft speed", "msecs" },
 { "showmode", HAS_ARG, { .func_arg = opt_show_mode}, "select show mode (0 = video, 1 = waves, 2 = RDFT)", "mode" },
+{ "progress", OPT_BOOL, { _progress_line}, "show progress 

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

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 7:16 PM, Matt Oliver  wrote:
> On 14 April 2017 at 02:11, Rostislav Pehlivanov  wrote:
>
>>
>>
>> On 13 April 2017 at 16:51, wm4  wrote:
>>
>>> On Thu, 13 Apr 2017 17:39:57 +1000
>>> Matt Oliver  wrote:
>>>
>>> > 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).
>>>
>>> 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.

- Hendrik
___
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  wrote:

>
>
> On 13 April 2017 at 16:51, wm4  wrote:
>
>> On Thu, 13 Apr 2017 17:39:57 +1000
>> Matt Oliver  wrote:
>>
>> > 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).
>>
>> 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.

It also needed to be decided whether there would be a complete removal of
DCE or just removing the occurrences that caused linker errors (see
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/204811.html for my
previous example). Either approach can be done but there are a lot of
changes that would result so i didn't write up any patches until some sort
of decision could be made as to what the accepted approach would be (which
never happened).

So instead i wrote the previously mentioned tool that scans the source code
and generates empty function definitions and variable definitions for
anything used in a DCE block and spits them out to a code file. The output
from this may be of some use but the program is windows only (it uses msvc
to pass the files) and has to be manually run so after the initial output

Re: [FFmpeg-devel] [PATCH] avformat/hls allow playback when some variant streams are unavailable

[Tim Hunt]

Not sure if it was email formatting or editor setting. Is this patch ok?

On Thu, Apr 13, 2017 at 5:24 PM, Michael Niedermayer  wrote:

> On Thu, Apr 13, 2017 at 04:14:46PM +0100, Tim Hunt wrote:
> > My last patch was slightly convoluted and really dumb.
> >
> > I suspect it impacts on a couple of checks for
> > variants[0]->playlists[0]->finished and the problem will be when a non
> live
> > stream has two variants using EXT-X-ENDLIST and the first stream in the
> > playlist is down? Not sure how to approach this, will look into it more
> > later.
> >
> > ---
> >  libavformat/hls.c | 17 +++--
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index bac53a4..26b8751 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1611,7 +1611,7 @@ static int hls_read_header(AVFormatContext *s)
> >  void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> >  HLSContext *c = s->priv_data;
> >  int ret = 0, i;
> > -int highest_cur_seq_no = 0;
> > +int highest_cur_seq_no = 0, found_segments;
> >
> >  c->ctx= s;
> >  c->interrupt_callback = >interrupt_callback;
> > @@ -1652,14 +1652,20 @@ static int hls_read_header(AVFormatContext *s)
> >  /* If the playlist only contained playlists (Master Playlist),
> >   * parse each individual playlist. */
> >  if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
> > +found_segments = -1;
> > +
>
> >  for (i = 0; i < c->n_playlists; i++) {
> >  struct playlist *pls = c->playlists[i];
> > -if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
> > -goto fail;
> > +if (parse_playlist(c, pls->url, pls, NULL) == 0 &&
> > pls->n_segments > 0)
> > +found_segments = 1;
>
> this patch is corrupted by newlines
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
> conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
> can solve the problem without the user falling asleep waiting.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From cc20762ec30e3021b4593fb89c681f5000ddb1fe Mon Sep 17 00:00:00 2001
From: Tim Hunt 
Date: Thu, 13 Apr 2017 15:35:07 +0100
Subject: [PATCH] avformat/hls allow playback of variant streams when some
 missing

ticket #2617
---
 libavformat/hls.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4..26b8751 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1611,7 +1611,7 @@ static int hls_read_header(AVFormatContext *s)
 void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
 HLSContext *c = s->priv_data;
 int ret = 0, i;
-int highest_cur_seq_no = 0;
+int highest_cur_seq_no = 0, found_segments;
 
 c->ctx= s;
 c->interrupt_callback = >interrupt_callback;
@@ -1652,14 +1652,20 @@ static int hls_read_header(AVFormatContext *s)
 /* If the playlist only contained playlists (Master Playlist),
  * parse each individual playlist. */
 if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
+found_segments = -1;
+
 for (i = 0; i < c->n_playlists; i++) {
 struct playlist *pls = c->playlists[i];
-if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
-goto fail;
+if (parse_playlist(c, pls->url, pls, NULL) == 0 && pls->n_segments > 0)
+found_segments = 1;
 }
-}
 
-if (c->variants[0]->playlists[0]->n_segments == 0) {
+if(found_segments == -1) {
+av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
+ret = AVERROR_EOF;
+goto fail;
+}
+} else if (c->variants[0]->playlists[0]->n_segments == 0) {
 av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
 ret = AVERROR_EOF;
 goto fail;
@@ -1805,7 +1811,6 @@ static int hls_read_header(AVFormatContext *s)
 }
 
 update_noheader_flag(s);
-
 return 0;
 fail:
 hls_close(s);
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avformat/hls allow playback when some variant streams are unavailable

[Michael Niedermayer]

On Thu, Apr 13, 2017 at 04:14:46PM +0100, Tim Hunt wrote:
> My last patch was slightly convoluted and really dumb.
> 
> I suspect it impacts on a couple of checks for
> variants[0]->playlists[0]->finished and the problem will be when a non live
> stream has two variants using EXT-X-ENDLIST and the first stream in the
> playlist is down? Not sure how to approach this, will look into it more
> later.
> 
> ---
>  libavformat/hls.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4..26b8751 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1611,7 +1611,7 @@ static int hls_read_header(AVFormatContext *s)
>  void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
>  HLSContext *c = s->priv_data;
>  int ret = 0, i;
> -int highest_cur_seq_no = 0;
> +int highest_cur_seq_no = 0, found_segments;
> 
>  c->ctx= s;
>  c->interrupt_callback = >interrupt_callback;
> @@ -1652,14 +1652,20 @@ static int hls_read_header(AVFormatContext *s)
>  /* If the playlist only contained playlists (Master Playlist),
>   * parse each individual playlist. */
>  if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
> +found_segments = -1;
> +

>  for (i = 0; i < c->n_playlists; i++) {
>  struct playlist *pls = c->playlists[i];
> -if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
> -goto fail;
> +if (parse_playlist(c, pls->url, pls, NULL) == 0 &&
> pls->n_segments > 0)
> +found_segments = 1;

this patch is corrupted by newlines

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


signature.asc
Description: Digital signature
___
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

[Rostislav Pehlivanov]

On 13 April 2017 at 16:51, wm4  wrote:

> On Thu, 13 Apr 2017 17:39:57 +1000
> Matt Oliver  wrote:
>
> > 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).
>
> 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.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

CCing him because its been 4 months

btw how would the GCC pragma approach work?
___
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

[wm4]

On Thu, 13 Apr 2017 17:39:57 +1000
Matt Oliver  wrote:

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

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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls allow playback when some variant streams are unavailable

[Tim Hunt]

My last patch was slightly convoluted and really dumb.

I suspect it impacts on a couple of checks for
variants[0]->playlists[0]->finished and the problem will be when a non live
stream has two variants using EXT-X-ENDLIST and the first stream in the
playlist is down? Not sure how to approach this, will look into it more
later.

---
 libavformat/hls.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4..26b8751 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1611,7 +1611,7 @@ static int hls_read_header(AVFormatContext *s)
 void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
 HLSContext *c = s->priv_data;
 int ret = 0, i;
-int highest_cur_seq_no = 0;
+int highest_cur_seq_no = 0, found_segments;

 c->ctx= s;
 c->interrupt_callback = >interrupt_callback;
@@ -1652,14 +1652,20 @@ static int hls_read_header(AVFormatContext *s)
 /* If the playlist only contained playlists (Master Playlist),
  * parse each individual playlist. */
 if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
+found_segments = -1;
+
 for (i = 0; i < c->n_playlists; i++) {
 struct playlist *pls = c->playlists[i];
-if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
-goto fail;
+if (parse_playlist(c, pls->url, pls, NULL) == 0 &&
pls->n_segments > 0)
+found_segments = 1;
 }
-}

-if (c->variants[0]->playlists[0]->n_segments == 0) {
+if(found_segments == -1) {
+av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
+ret = AVERROR_EOF;
+goto fail;
+}
+} else if (c->variants[0]->playlists[0]->n_segments == 0) {
 av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
 ret = AVERROR_EOF;
 goto fail;
@@ -1805,7 +1811,6 @@ static int hls_read_header(AVFormatContext *s)
 }

 update_noheader_flag(s);
-
 return 0;
 fail:
 hls_close(s);
-- 
2.7.4


On Thu, Apr 13, 2017 at 12:43 AM, Tim Hunt  wrote:

> addresses ticket #2617
>
> The test url given in the bug report is now working and has been playing
> for a couple of hours.
>
> http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8
>
> ---
>  libavformat/hls.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4..87e0c71 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1610,8 +1610,8 @@ static int hls_read_header(AVFormatContext *s)
>  {
>  void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
>  HLSContext *c = s->priv_data;
> -int ret = 0, i;
> -int highest_cur_seq_no = 0;
> +int ret = 0, i, j;
> +int highest_cur_seq_no = 0, found_segments;
>
>  c->ctx= s;
>  c->interrupt_callback = >interrupt_callback;
> @@ -1655,11 +1655,26 @@ static int hls_read_header(AVFormatContext *s)
>  for (i = 0; i < c->n_playlists; i++) {
>  struct playlist *pls = c->playlists[i];
>  if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
> -goto fail;
> +continue;
>  }
> -}
>
> -if (c->variants[0]->playlists[0]->n_segments == 0) {
> +found_segments = -1;
> +for(i = 0; i < c->n_variants && found_segments == -1; i++) {
> +struct variant *var = c->variants[i];
> +for(j = 0; j < var->n_playlists; j++) {
> +if(var->playlists[j]->n_segments > 0) {
> +found_segments = 1;
> +break;
> +}
> +}
> +}
> +
> +if(found_segments == -1) {
> +av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
> +ret = AVERROR_EOF;
> +goto fail;
> +}
> +} else if (c->variants[0]->playlists[0]->n_segments == 0) {
>  av_log(NULL, AV_LOG_WARNING, "Empty playlist\n");
>  ret = AVERROR_EOF;
>  goto fail;
> @@ -1805,7 +1820,6 @@ static int hls_read_header(AVFormatContext *s)
>  }
>
>  update_noheader_flag(s);
> -
>  return 0;
>  fail:
>  hls_close(s);
> --
> 2.7.4
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFplay: progress bar feature proposal

[Raymond Pierce]

Hi. Currently FFplay has no visible progress bar and it is hard to tell 
where a stream is currently positioned. So if one wants, for example, to rewind 
a little back relative to current position using right mouse click it is always 
guessing and trying.

I propose very simple 1-pixel progress bar which can be turned on or off during 
playback by pressing a button (I use 'L', from 'line'). By default the bar 
is off.

I choose bright green color (#00ff00) for the part to the left of a current
position and pure black for the part to the right.

You can see how it looks on the attached image.

Draft patch is applied. One global variable ('static int show_progress_line') 
and one function ('static void video_progress_line_display(VideoState *is)') 
have been added. Also the existing 'video_display()' function has been moved
below 'get_master_clock()' as the latter is used in the new function.

What do you think?--- ffplay.c	2017-04-12 11:46:21.543322000 +0500
+++ ffplay.c	2017-04-12 14:26:47.693278504 +0500
@@ -344,6 +344,7 @@ static const char *video_codec_name;
 double rdftspeed = 0.02;
 static int64_t cursor_last_shown;
 static int cursor_hidden = 0;
+static int show_progress_line = 0;
 #if CONFIG_AVFILTER
 static const char **vfilters_list = NULL;
 static int nb_vfilters = 0;
@@ -1299,21 +1300,6 @@ static int video_open(VideoState *is)
 return 0;
 }
 
-/* display the current picture, if any */
-static void video_display(VideoState *is)
-{
-if (!window)
-video_open(is);
-
-SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
-SDL_RenderClear(renderer);
-if (is->audio_st && is->show_mode != SHOW_MODE_VIDEO)
-video_audio_display(is);
-else if (is->video_st)
-video_image_display(is);
-SDL_RenderPresent(renderer);
-}
-
 static double get_clock(Clock *c)
 {
 if (*c->queue_serial != c->serial)
@@ -1513,6 +1499,37 @@ static void update_video_pts(VideoState
 sync_clock_to_slave(>extclk, >vidclk);
 }
 
+static void video_progress_line_display(VideoState *is) {
+double d = is->ic->duration / 1.0e6;
+if (d > 0) {
+double t = get_master_clock(is);
+int w = is->width * t / d;
+SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
+fill_rectangle(0, is->height-1, w, 1);
+SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
+fill_rectangle(w, is->height-1, is->width-w, 1);
+} else {
+show_progress_line = 0;
+}
+}
+
+/* display the current picture, if any */
+static void video_display(VideoState *is)
+{
+if (!window)
+video_open(is);
+
+SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
+SDL_RenderClear(renderer);
+if (is->audio_st && is->show_mode != SHOW_MODE_VIDEO)
+video_audio_display(is);
+else if (is->video_st)
+video_image_display(is);
+if (show_progress_line)
+video_progress_line_display(is);
+SDL_RenderPresent(renderer);
+}
+
 /* called to display each frame */
 static void video_refresh(void *opaque, double *remaining_time)
 {
@@ -3265,6 +3282,9 @@ static void event_loop(VideoState *cur_s
 toggle_audio_display(cur_stream);
 #endif
 break;
+case SDLK_l:
+show_progress_line = !show_progress_line;
+break;
 case SDLK_PAGEUP:
 if (cur_stream->ic->nb_chapters <= 1) {
 incr = 600.0;
@@ -3543,6 +3563,7 @@ static const OptionDef options[] = {
 #endif
 { "rdftspeed", OPT_INT | HAS_ARG| OPT_AUDIO | OPT_EXPERT, {  }, "rdft speed", "msecs" },
 { "showmode", HAS_ARG, { .func_arg = opt_show_mode}, "select show mode (0 = video, 1 = waves, 2 = RDFT)", "mode" },
+{ "progress", OPT_BOOL, { _progress_line}, "show progress line at the bottom", ""},
 { "default", HAS_ARG | OPT_AUDIO | OPT_VIDEO | OPT_EXPERT, { .func_arg = opt_default }, "generic catch all option", "" },
 { "i", OPT_BOOL, { }, "read specified file", "input_file"},
 { "codec", HAS_ARG, { .func_arg = opt_codec}, "force decoder", "decoder_name" },
@@ -3587,6 +3608,7 @@ void show_help_default(const char *opt,
"c   cycle program\n"
"w   cycle video filters or show modes\n"
"s   activate frame-step mode\n"
+   "l   toggle progress line at the bottom\n"
"left/right  seek backward/forward 10 seconds\n"
"down/up seek backward/forward 1 minute\n"
"page down/page up   seek backward/forward 10 minutes\n"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFplay: progress bar feature proposal

[Steven Liu]

2017-04-13 20:48 GMT+08:00 Raymond Pierce :

> Hi. Currently FFplay has no visible progress bar and it is hard to tell
> where a stream is currently positioned. So if one wants, for example, to
> rewind
> a little back relative to current position using right mouse click it is
> always
> guessing and trying.
>
> I propose very simple 1-pixel progress bar which can be turned on or off
> during
> playback by pressing a button (I use 'L', from 'line'). By default the bar
> is off.
>
> I choose bright green color (#00ff00) for the part to the left of a current
> position and pure black for the part to the right.
>
> You can see how it looks on the attached image.
>
> Draft patch is applied. One global variable ('static int
> show_progress_line')
> and one function ('static void video_progress_line_display(VideoState
> *is)')
> have been added. Also the existing 'video_display()' function has been
> moved
> below 'get_master_clock()' as the latter is used in the new function.
>
> What do you think?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
git commit -a
git format-patch -s -1

You should use the command looks like the above git command to make patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v14] avformat/dashdec: add dash demuxer base version

[Steven Liu]

2017-04-11 23:29 GMT+08:00 Andy Furniss :

> Steven Liu wrote:
>
>> 2017-04-11 22:27 GMT+08:00 Andy Furniss :
>>
>> Steven Liu wrote:
>>>
>>> ffmpeg need a dash demuxer for demux the dash formats base on
 https://github.com/samsamsam-iptvplayer/exteplayer3/blob/mas
 ter/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

 TODO: 1. support multi bitrate dash


>>> v14 fixed: 1. fix bug: TLS connection was non-properly terminated
>>> 2.
>>>
 fix bug: No trailing CRLF found in HTTP header


>>> Thanks.
>>>
>>> They are pretty much gone now, though I did see one TLS out of
>>> about 3 hours running (3.84s chunks)
>>>
>>> Another user who is testing the same live stream saw eight TLS @
>>> 0xae75700" referring to TLS packets of unexpected length. over a 3
>>> hour run.
>>>
>>> One issue that I guess is not really a bug, but on a live stream
>>> you really need to have your clock either spot on or slow.
>>>
>>> Ok, so maybe I should run ntpd "properly" - though not running it
>>> does offer a workaround of setting clock back a bit (the stream mpd
>>> below has a 10 minute buffer).
>>>
>>> This issue = even if set my clock with ntpd -q only a small amount
>>> of too fast drift will lead to (after a couple of hours)
>>>
>>> [https @ 0x365e580] HTTP error 404 Not Found [dash @ 0x3657360]
>>> Failed to open fragment of playlist 0
>>>
>>> ntpd -q showed I was 0.2 sec fast at that point - for the purpose
>>> of testing just setting one sec fast will quickly start getting
>>> 404s which are not retried, so break the stream.
>>>
>>> I notice there is a time url in the mpd - but even if that were
>>> used initially vs clock, I still think drift would break things.
>>>
>>>
>>> Here's the .mpd (same as link I gave before - pasting as I suspect
>>> it's geo restricted).
>>>
>>>
>> The result is: you want to say: use the UTCTimeing's value, if it
>> show in mpd file, do i misunderstand you?
>>
>
> Not really - though it seems to be what firefox does.
>
> As things stand it could be bad in the sense that I couldn't work around
> clock drift if that were used vs system time.
>
> Whatever clock is used to calculate initial filename, maybe it would be
> safer if ffmpeg either backed away a bit from getting the very latest
> chunk, or if it could react to getting a 404 on a live stream in a way
> that didn't loose the chunk - which in this case would likely be there a
> fraction of a second later.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Thanks Andy, let me try to fix it. i'm moving house these days, maybe some
days later update a new patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v14] avformat/dashdec: add dash demuxer base version

[Steven Liu]

2017-04-12 14:13 GMT+08:00 Rodger Combs :

>
> > On Apr 9, 2017, at 09:08, Steven Liu  wrote:
> >
> > ffmpeg need a dash demuxer for demux the dash formats
> > base on
> > https://github.com/samsamsam-iptvplayer/exteplayer3/blob/
> master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
> >
> > TODO:
> > 1. support multi bitrate dash
> >
> > v2 fixed:
> > 1. from autodetect to disabled
> > 2. from camelCase code style to ffmpeg code style
> > 3. from RepType to AVMediaType
> > 4. fix variable typo
> > 5. change time value from uint32_t to uint64_t
> > 6. removed be used once API
> > 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and
> av_timegm
> > 8. merge complex free operation to free_fragment
> > 9. use API from snprintf to av_asprintf
> >
> > v3 fixed:
> > 1. fix typo from --enabled-xml2 to --enable-xml2
> >
> > v4 fixed:
> > 1. from --enable-xml2 to --enable-libxml2
> > 2. move system includes to top
> > 3. remove nouse includes
> > 4. rename enum name
> > 5. add a trailing comma for the last entry enum
> > 6. fix comment typo
> > 7. add const to DASHContext class front
> > 8. check sscanf if return arguments and give warning message when error
> > 9. check validity before free seg->url and seg
> > 10. check if the val is null, before use atoll
> >
> > v5 fixed:
> > 1. fix typo from mainifest to manifest
> >
> > v6 fixed:
> > 1. from realloc to av_realloc
> > 2. from free to av_free
> >
> > v7 fixed:
> > 1. remove the -lxml2 from configure when require_pkg_config
> >
> > v8 fixed:
> > 1. fix replace filename template by av_asprintf secure problem
> >
> > v9 modified:
> > 1. make manifest parser clearly
> >
> > v10 fixed:
> > 1. fix function API name code style
> > 2. remove redundant strreplace call
> > 3. remove redundant memory operation and check return value from
> get_content_url()
> > 4. add space between ) and {
> > 5. remove no need to log the value for print
> >
> > v11 fixed:
> > 1. from atoll to strtoll
> >
> > v12 fixed:
> > 1. remove strreplace and instead by av_strreplace
> >
> > v13 fixed:
> > 1. fix bug: cannot play:
> > http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
> >
> > v14 fixed:
> > 1. fix bug: TLS connection was non-properly terminated
> > 2. fix bug: No trailing CRLF found in HTTP header
> >
> > Reviewed-by: Clément Bœsch 
> > Reviewed-by: Michael Niedermayer 
> > Reviewed-by: Carl Eugen Hoyos 
> > Reviewed-by: Rodger Combs 
> > Reviewed-by: Moritz Barsnick 
> > Reviewed-by: Nicolas George 
> > Reviewed-by: Ricardo Constantino 
> > Reviewed-by: wm4 
> > Tested-by: Andy Furniss 
> > Reported-by: Andy Furniss 
> > Signed-off-by: Steven Liu 
> > ---
> > configure|4 +
> > libavformat/Makefile |1 +
> > libavformat/allformats.c |2 +-
> > libavformat/dashdec.c| 1800 ++
> 
> > 4 files changed, 1806 insertions(+), 1 deletion(-)
> > create mode 100644 libavformat/dashdec.c
> >
> > diff --git a/configure b/configure
> > index 6dc0b7aad3..5a63240096 100755
> > --- a/configure
> > +++ b/configure
> > @@ -274,6 +274,7 @@ External library support:
> >   --enable-libxcb-shapeenable X11 grabbing shape rendering
> [autodetect]
> >   --enable-libxvid enable Xvid encoding via xvidcore,
> >native MPEG-4/Xvid encoder exists [no]
> > +  --enable-libxml2enable XML parsing using the C library
> libxml2 [no]
>
> Misaligned.
>
> >   --enable-libzimg enable z.lib, needed for zscale filter [no]
> >   --enable-libzmq  enable message passing via libzmq [no]
> >   --enable-libzvbi enable teletext support via libzvbi [no]
> > @@ -1581,6 +1582,7 @@ EXTERNAL_LIBRARY_LIST="
> > libvpx
> > libwavpack
> > libwebp
> > +libxml2
> > libzimg
> > libzmq
> > libzvbi
> > @@ -2916,6 +2918,7 @@ avi_muxer_select="riffenc"
> > caf_demuxer_select="iso_media riffdec"
> > caf_muxer_select="iso_media"
> > dash_muxer_select="mp4_muxer"
> > +dash_demuxer_deps="libxml2"
> > dirac_demuxer_select="dirac_parser"
> > dts_demuxer_select="dca_parser"
> > dtshd_demuxer_select="dca_parser"
> > @@ -5921,6 +5924,7 @@ enabled openssl   && { use_pkg_config
> openssl openssl/ssl.h OPENSSL_init
> >check_lib openssl/ssl.h SSL_library_init
> -lssl -lcrypto -lws2_32 -lgdi32 ||
> >die "ERROR: openssl not found"; }
> > enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h ||
> disable qtkit_indev; }
> > +enabled libxml2 && require_pkg_config libxml-2.0
> libxml2/libxml/xmlversion.h xmlCheckVersion
>
> Misaligned (though the previous line also is).
>
> >
> > # libdc1394 check
> > if 

Re: [FFmpeg-devel] [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata setting error.

[Mark Thompson]

On 13/04/17 13:34, Jun Zhao wrote:
> From 1fa48b45fe962d8c342d158d9c16ce24139ffd84 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 13 Apr 2017 20:07:10 +0800
> Subject: [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata
>  setting error.
> 
> before this fix, mediainfo check the bit rate control mode metadata info
> is wrong.
> 
> Reproduce step:
> encode with CBR or VBR mode like this:
> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
> -maxrate 5M -b:v 5M output_cbr.mp4
> 
> ./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
> -hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
> -maxrate 6M -b:v 5M output_cbr.mp4
> 
> then use the mediainfo check the bit rate control mode.
> 
> Signed-off-by: Jun Zhao 

Not yet generating the HRD and timing information in VBR mode was deliberate, 
because I don't know enough about the conformance properties of the new 
proprietary rate controller which the Intel driver has switched to.  The old 
CBR mode was straightforward to verify from the source code, and it seemed 
reasonable to assume that the new CBR mode would be too given the constraints 
on it (and also because existing versions of lavc couldn't be modified).

Can you say anything about the HRD conformance of the Intel driver here, or was 
this patch purely for the metadata output (which may not actually match the 
stream, hence my concern)?

Only the Intel driver is relevant to this as far as I know - the Mesa driver 
does not support the packed headers necessary for this information to be 
included in the stream.


> ---
>  libavcodec/vaapi_encode_h264.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 92e2955..47d0c94 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -760,7 +760,7 @@ static int 
> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>  char tmp[256];
>  size_t header_len;
>  
> -if (index == 0 && ctx->va_rc_mode == VA_RC_CBR) {
> +if (index == 0 && (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == 
> VA_RC_VBR)) {
>  *type = VAEncPackedHeaderH264_SEI;
>  
>  init_put_bits(, tmp, sizeof(tmp));
> @@ -868,7 +868,7 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  mseq->fixed_frame_rate_flag = 0;
>  }
>  
> -if (ctx->va_rc_mode == VA_RC_CBR) {
> +if (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == VA_RC_VBR) {
>  priv->send_timing_sei = 1;
>  mseq->nal_hrd_parameters_present_flag = 1;
>  
> @@ -886,8 +886,7 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  mseq->cpb_size_value_minus1[0] =
>  (ctx->hrd_params.hrd.buffer_size >> mseq->cpb_size_scale + 
> 4) - 1;
>  
> -// CBR mode isn't actually available here, despite naming.
> -mseq->cbr_flag[0] = 0;
> +mseq->cbr_flag[0] = (ctx->va_rc_mode == VA_RC_CBR ? 1 : 0);

As the comment notes, the necessary CBR mode isn't actually available.  Drivers 
only offer "soft" CBR, which can result in HRD overflow; this specifies "hard" 
CBR, so if you want to set this flag you would need to insert filler NAL units 
as well.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] make libavformat more tolerant (fixes #2617)

[wm4]

On Thu, 13 Apr 2017 14:11:05 +0200
denim2x  wrote:

> Ticket #2617 reports playback issues involving HLS - running this command:
> > ffplay 
> > http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8]
> >  -loglevel debug  
> 
> results in this final line being printed:
> > http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8]:
> >  Server returned 403 Forbidden (access denied)  
>  
> This is caused by libavformat terminating on faulty HTTP headers and, 
> subsequently,
> upon finding #EXTM3U lines.
>  
> The attached patch solves this by employing two new compilation flags:
>  - FORBID_EXTM3U_LINES - causes termination when '#EXTM3U' is found;
>  - FORBID_FAULTY_HTTP_HEADERS - causes termination upon faulty HTTP headers.

Your patch violates multiple conventions. We don't do random global
defines which change behavior, we don't do compile time options which
subtly change behavior of a component, and global identifiers starting
with _ are implementation reserved by the C standard.

> The rationale is that - while parsing HTTP headers and M3U playlists - errors
> shouldn't abort the program execution; instead any usable data should be 
> recovered as mush as possible, much like a HTML parser would do; also these 
> flags operate upon compilation since users shouldn't normally be burdened 
> with 
> this kind of details - browsers don't prompt for loose HTML parsing either.
>  
> One immediate advantage of this is that the user will be able to play any 
> M3U playlist without being burdened with minor parsing errors; and there's
> no visible disadvantage.

In my code, I rely on HLS not grabbing "normal" playlists in order to
distinguish between playlists and HLS.

> Verification is done simply by recompiling ffplay upon applying the patch - 
> those flags will just be undefined and so these parsing errors will be ignored
> at runtime.

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

[FFmpeg-devel] [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata setting error.

[Jun Zhao]

From 1fa48b45fe962d8c342d158d9c16ce24139ffd84 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 13 Apr 2017 20:07:10 +0800
Subject: [PATCH] vaapi_encode: Fix the vaapi h264 encoder VBR/CBR metadata
 setting error.

before this fix, mediainfo check the bit rate control mode metadata info
is wrong.

Reproduce step:
encode with CBR or VBR mode like this:
./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
-maxrate 5M -b:v 5M output_cbr.mp4

./ffmpeg -y -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.mp4 -an -c:v h264_vaapi \
-maxrate 6M -b:v 5M output_cbr.mp4

then use the mediainfo check the bit rate control mode.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h264.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 92e2955..47d0c94 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -760,7 +760,7 @@ static int 
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
 char tmp[256];
 size_t header_len;
 
-if (index == 0 && ctx->va_rc_mode == VA_RC_CBR) {
+if (index == 0 && (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == 
VA_RC_VBR)) {
 *type = VAEncPackedHeaderH264_SEI;
 
 init_put_bits(, tmp, sizeof(tmp));
@@ -868,7 +868,7 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 mseq->fixed_frame_rate_flag = 0;
 }
 
-if (ctx->va_rc_mode == VA_RC_CBR) {
+if (ctx->va_rc_mode == VA_RC_CBR || ctx->va_rc_mode == VA_RC_VBR) {
 priv->send_timing_sei = 1;
 mseq->nal_hrd_parameters_present_flag = 1;
 
@@ -886,8 +886,7 @@ static int 
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
 mseq->cpb_size_value_minus1[0] =
 (ctx->hrd_params.hrd.buffer_size >> mseq->cpb_size_scale + 4) 
- 1;
 
-// CBR mode isn't actually available here, despite naming.
-mseq->cbr_flag[0] = 0;
+mseq->cbr_flag[0] = (ctx->va_rc_mode == VA_RC_CBR ? 1 : 0);
 
 mseq->initial_cpb_removal_delay_length_minus1 = 23;
 mseq->cpb_removal_delay_length_minus1 = 23;
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[wm4]

On Thu, 13 Apr 2017 02:47:39 -0700
Aaron Levinson  wrote:

> On 4/13/2017 2:10 AM, Hendrik Leppkes wrote:
> > On Thu, Apr 13, 2017 at 11:04 AM, Aaron Levinson  
> > wrote:  
> >>  static av_unused int pthread_cond_signal(pthread_cond_t *cond)
> >>  {
> >> -win32_cond_t *win32_cond = cond->Ptr;
> >> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
> >>  int have_waiter;
> >>  if (cond_signal) {
> >>  cond_signal(cond);
> >> @@ -400,17 +400,17 @@ static av_unused void w32thread_init(void)
> >>  HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll"));
> >>  /* if one is available, then they should all be available */
> >>  cond_init  = (void (WINAPI*)(pthread_cond_t *))
> >> -GetProcAddress(kernel_dll, "InitializeConditionVariable");
> >> +GetProcAddress((HMODULE)kernel_dll, 
> >> "InitializeConditionVariable");
> >>  cond_broadcast = (void (WINAPI*)(pthread_cond_t *))
> >> -GetProcAddress(kernel_dll, "WakeAllConditionVariable");
> >> +GetProcAddress((HMODULE)kernel_dll, "WakeAllConditionVariable");
> >>  cond_signal= (void (WINAPI*)(pthread_cond_t *))
> >> -GetProcAddress(kernel_dll, "WakeConditionVariable");
> >> +GetProcAddress((HMODULE)kernel_dll, "WakeConditionVariable");
> >>  cond_wait  = (BOOL (WINAPI*)(pthread_cond_t *, pthread_mutex_t *, 
> >> DWORD))
> >> -GetProcAddress(kernel_dll, "SleepConditionVariableCS");
> >> +GetProcAddress((HMODULE)kernel_dll, "SleepConditionVariableCS");
> >>  initonce_begin = (BOOL (WINAPI*)(pthread_once_t *, DWORD, BOOL *, 
> >> void **))
> >> -GetProcAddress(kernel_dll, "InitOnceBeginInitialize");
> >> +GetProcAddress((HMODULE)kernel_dll, "InitOnceBeginInitialize");
> >>  initonce_complete = (BOOL (WINAPI*)(pthread_once_t *, DWORD, void *))
> >> -GetProcAddress(kernel_dll, "InitOnceComplete");
> >> +GetProcAddress((HMODULE)kernel_dll, "InitOnceComplete");
> >>  #endif  
> > 
> > One more comment that I missed earlier (sorry), GetModuleHandle
> > returns the type HMODULE, can't you just change the type of kernel_dll
> > to match that, and avoid the casts here?
> > 
> > - Hendrik  
> 
> Yes, it is simpler and cleaner to properly set the return value of 
> GetModuleHandle() to an HMODULE.  Here is what is hopefully the final version 
> of the patch, which is also much cleaner and simplified from the original 
> version.
> 
> Thanks,
> Aaron
> 
> --
> 
> From 56f9a4b6c281a0d9382d2b4ec2e29aff5ab69fbc Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Thu, 13 Apr 2017 02:38:02 -0700
> Subject: [PATCH] Made appropriate changes to be able to successfully build 
> C++ files using a Visual C++ build on Windows
> 
> Purpose: Made appropriate changes to be able to successfully
> build C++ files using a Visual C++ build on Windows.  Note that this is a
> continuation of the "fixes w32pthreads to support C++" aspect of Kyle
> Schwarz's "Remove pthread dependency" patch that is available at
> https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
> as far as I can tell, there was no follow-up after it was rejected.
> 
> Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
> approach for specifying -Fo$@ in configure based on code review from
> Hendrik Leppkes for first version of patch.  Also simplified changes
> to w32pthreads.h per Hendrik's review.
> 
> Comments:
> 
> -- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
>get it to build when it is being included in a C++ file and built
>with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
>described above.
> 
> -- configure:
> a) Now calling set_ccvars CXX to cause the various CXX_ variables to
>be setup properly.  For example, with MSVC (Microsoft Visual C++),
>this causes CXX_O to be set to -Fo$@ instead of using the default
>value.  The default value does not work with Visual C++.  This
>change will also have the impact of correcting CXX_O (and possibly
>CXX_C) for other compilers, although this is really only relevant
>for the Intel compiler, in addition to MSVC.
> b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
>currently only relevant for building the
>Blackmagic/Decklink-related files under avdevice.
> ---
>  compat/w32pthreads.h | 14 +++---
>  configure|  3 +++
>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 0c9a7fa..eeead60 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
>  
>  static av_unused unsigned __stdcall attribute_align_arg 
> win32thread_worker(void *arg)
>  {
> -pthread_t *h = arg;
> +pthread_t *h = 

[FFmpeg-devel] [PATCH] make libavformat more tolerant (fixes #2617)

[denim2x]

Ticket #2617 reports playback issues involving HLS - running this command:
> ffplay 
> http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8]
>  -loglevel debug

results in this final line being printed:
> http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8[http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8]:
>  Server returned 403 Forbidden (access denied)
 
This is caused by libavformat terminating on faulty HTTP headers and, 
subsequently,
upon finding #EXTM3U lines.
 
The attached patch solves this by employing two new compilation flags:
 - FORBID_EXTM3U_LINES - causes termination when '#EXTM3U' is found;
 - FORBID_FAULTY_HTTP_HEADERS - causes termination upon faulty HTTP headers.
 
The rationale is that - while parsing HTTP headers and M3U playlists - errors
shouldn't abort the program execution; instead any usable data should be 
recovered as mush as possible, much like a HTML parser would do; also these 
flags operate upon compilation since users shouldn't normally be burdened with 
this kind of details - browsers don't prompt for loose HTML parsing either.
 
One immediate advantage of this is that the user will be able to play any 
M3U playlist without being burdened with minor parsing errors; and there's
no visible disadvantage.
 
Verification is done simply by recompiling ffplay upon applying the patch - 
those flags will just be undefined and so these parsing errors will be ignored
at runtime.

0001-make-libavformat-more-tolerant-fixes-2617.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] FFmpeg 3.3

[Michael Niedermayer]

On Sun, Apr 02, 2017 at 09:15:00PM +0200, Michael Niedermayer wrote:
> On Sat, Apr 01, 2017 at 09:17:00PM +0200, Marton Balint wrote:
> > 
> > On Fri, 31 Mar 2017, James Almer wrote:
> > 
> > >Now, regarding merges, we're like 10 commits away from the massive
> > >bitstream reader batch, which is more or less the only thing committed
> > >to libav for a whole week. So how about we re-cut from master (should be
> > >a matter of merging master into release/3.3, which will be
> > >straight-forward as nothing has been cherry-picked) once we have reached
> > >that exact point?.
> > >Give Google and Kierank a couple days to make sure h264 fuzzing didn't
> > >find anything outstanding, and go ahead with tagging the release.
> > 
> > I prefer this as well.
> 
> ok, it seems noone on IRC or ML objected to this so i updated
> release/3.3 to master with ver bumps
> 
> i intend to make 3.3 from this branch within a few days
> testing, release notes, bugfixes very welcome
> 
> ive done some quick testing and it seems to be working
> 
> thanks everyone

release made

ill make 3.3.1 in a week or 2, backported bugfixes welcome !

also anyone wants to write a news entry ?

thanks


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

[FFmpeg-devel] [PATCH] make libavformat more tolerant (fixes #2617)

[denim2x]

0001-make-libavformat-more-tolerant-fixes-2617.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 12:39 PM, Aaron Levinson  wrote:
> On 4/13/2017 12:36 AM, Hendrik Leppkes wrote:
>> On Thu, Apr 13, 2017 at 5:34 AM, Aaron Levinson  wrote:
>>> diff --git a/configure b/configure
>>> index adb0060..5b76a33 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3646,6 +3646,8 @@ case "$toolchain" in
>>>  ld_default="$source_path/compat/windows/mslink"
>>>  nm_default="dumpbin -symbols"
>>>  ar_default="lib"
>>> +decklink_indev_extralibs=""
>>> +decklink_outdev_extralibs=""
>>>  case "$arch" in
>>>  arm*)
>>>  as_default="armasm"
>>
>> As in the other patch before, the toolchain handling section has no
>> business setting these.
>>
>>> @@ -4902,6 +4904,8 @@ case $target_os in
>>>  fi
>>>  enabled x86_32 && check_ldflags -LARGEADDRESSAWARE
>>>  shlibdir_default="$bindir_default"
>>> +decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
>>> -loleaut32"
>>> +decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
>>> -loleaut32"
>>>  SLIBPREF=""
>>>  SLIBSUF=".dll"
>>>  
>>> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
>>
>> I really don't like having these decklink specific things in the OS
>> sections. I know its already there in one section, but I would greatly
>> prefer if this would also be moved into a dedicated decklink section
>> somewhere, instead of littering the msvc/mingw sections.
>> In fact, its now set for both mingw and msvc, so setting it centrally
>> in one place would be even better to avoid duplicating it.
>
> I believe that I've addressed both of these issues with the following new 
> version of the patch.
>
> Thanks,
> Aaron
>
> --
>
> From 2e87ce15e9fb27b81b11b88a0660581549cfcfaf Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Thu, 13 Apr 2017 03:28:40 -0700
> Subject: [PATCH] Made minor changes to get the decklink avdevice code to 
> build using Visual C++.
>
> Purpose: Made minor changes to get the decklink avdevice code
> to build using Visual C++.
>
> Notes: Used Visual Studio 2015 (with update 3) for this.  Also made
> changes to configure per Hendrik Leppkes's review of first version of
> patch.
>
> Comments:
>
> -- configure: Added if enabled decklink section and setting
>decklink_indev_extralibs and decklink_outdev_extralibs here for
>both mingw and Windows.  In the case of Windows, the new value,
>-lole32 and -loleaut32 overwrites the default value.  In the case
>of mingw, -lole32 and -loleaut32 is added to the default value.
>Also eliminated the setting of these variables in the mingw section
>earlier in the file.
>
> -- libavdevice/decklink_common.cpp: Switched the order of the include
>of libavformat/internal.h to workaround build issues with Visual
>C++.  See comment in file for more details.
>
> -- libavdevice/decklink_dec.cpp:
> a) Rearranged the include of libavformat/internal.h (for reasons as
>described above).
> b) Made slight alteration to an argument for call to av_rescale_q() to
>workaround a compiler error with Visual C++.  This appears to only
>be an issue when building C++ files with Visual C++.  See comments
>in code for more details.
>
> -- libavdevice/decklink_enc.cpp: Rearranged the include of
>libavformat/internal.h (for reasons as described above).
> ---
>  configure   | 15 +--
>  libavdevice/decklink_common.cpp | 10 +-
>  libavdevice/decklink_dec.cpp| 17 +++--
>  libavdevice/decklink_enc.cpp|  5 -
>  4 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/configure b/configure
> index a383bf2..9a06437 100755
> --- a/configure
> +++ b/configure
> @@ -4843,8 +4843,6 @@ case $target_os in
>  else
>  target_os=mingw32
>  fi
> -decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
> -loleaut32"
> -decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
> -loleaut32"
>  LIBTARGET=i386
>  if enabled x86_64; then
>  LIBTARGET="i386:x86-64"
> @@ -5946,6 +5944,19 @@ if ! disabled sdl2; then
>  fi
>  enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs 
> $sdl2_libs
>
> +if enabled decklink; then
> +case $target_os in
> +mingw32*|mingw64*)
> +decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
> -loleaut32"
> +decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
> -loleaut32"
> +;;
> +win32|win64)
> +decklink_outdev_extralibs="-lole32 -loleaut32"
> +decklink_indev_extralibs="-lole32 -loleaut32"
> +;;
> +esac
> +fi
> +

Whats in the extralibs before this block that you need to 

Re: [FFmpeg-devel] [PATCH] Made minor changes to get the decklink avdevice code to build using Visual C++

[Aaron Levinson]

On 4/13/2017 12:36 AM, Hendrik Leppkes wrote:
> On Thu, Apr 13, 2017 at 5:34 AM, Aaron Levinson  wrote:
>> diff --git a/configure b/configure
>> index adb0060..5b76a33 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3646,6 +3646,8 @@ case "$toolchain" in
>>  ld_default="$source_path/compat/windows/mslink"
>>  nm_default="dumpbin -symbols"
>>  ar_default="lib"
>> +decklink_indev_extralibs=""
>> +decklink_outdev_extralibs=""
>>  case "$arch" in
>>  arm*)
>>  as_default="armasm"
> 
> As in the other patch before, the toolchain handling section has no
> business setting these.
> 
>> @@ -4902,6 +4904,8 @@ case $target_os in
>>  fi
>>  enabled x86_32 && check_ldflags -LARGEADDRESSAWARE
>>  shlibdir_default="$bindir_default"
>> +decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
>> -loleaut32"
>> +decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
>> -loleaut32"
>>  SLIBPREF=""
>>  SLIBSUF=".dll"
>>  
>> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'
> 
> I really don't like having these decklink specific things in the OS
> sections. I know its already there in one section, but I would greatly
> prefer if this would also be moved into a dedicated decklink section
> somewhere, instead of littering the msvc/mingw sections.
> In fact, its now set for both mingw and msvc, so setting it centrally
> in one place would be even better to avoid duplicating it.

I believe that I've addressed both of these issues with the following new 
version of the patch.

Thanks,
Aaron

--

From 2e87ce15e9fb27b81b11b88a0660581549cfcfaf Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 03:28:40 -0700
Subject: [PATCH] Made minor changes to get the decklink avdevice code to build 
using Visual C++.

Purpose: Made minor changes to get the decklink avdevice code
to build using Visual C++.

Notes: Used Visual Studio 2015 (with update 3) for this.  Also made
changes to configure per Hendrik Leppkes's review of first version of
patch.

Comments:

-- configure: Added if enabled decklink section and setting
   decklink_indev_extralibs and decklink_outdev_extralibs here for
   both mingw and Windows.  In the case of Windows, the new value,
   -lole32 and -loleaut32 overwrites the default value.  In the case
   of mingw, -lole32 and -loleaut32 is added to the default value.
   Also eliminated the setting of these variables in the mingw section
   earlier in the file.

-- libavdevice/decklink_common.cpp: Switched the order of the include
   of libavformat/internal.h to workaround build issues with Visual
   C++.  See comment in file for more details.

-- libavdevice/decklink_dec.cpp:
a) Rearranged the include of libavformat/internal.h (for reasons as
   described above).
b) Made slight alteration to an argument for call to av_rescale_q() to
   workaround a compiler error with Visual C++.  This appears to only
   be an issue when building C++ files with Visual C++.  See comments
   in code for more details.

-- libavdevice/decklink_enc.cpp: Rearranged the include of
   libavformat/internal.h (for reasons as described above).
---
 configure   | 15 +--
 libavdevice/decklink_common.cpp | 10 +-
 libavdevice/decklink_dec.cpp| 17 +++--
 libavdevice/decklink_enc.cpp|  5 -
 4 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index a383bf2..9a06437 100755
--- a/configure
+++ b/configure
@@ -4843,8 +4843,6 @@ case $target_os in
 else
 target_os=mingw32
 fi
-decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
-loleaut32"
-decklink_indev_extralibs="$decklink_indev_extralibs -lole32 -loleaut32"
 LIBTARGET=i386
 if enabled x86_64; then
 LIBTARGET="i386:x86-64"
@@ -5946,6 +5944,19 @@ if ! disabled sdl2; then
 fi
 enabled sdl2 && enable sdl && add_cflags $sdl2_cflags && add_extralibs 
$sdl2_libs
 
+if enabled decklink; then
+case $target_os in
+mingw32*|mingw64*)
+decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
-loleaut32"
+decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
-loleaut32"
+;;
+win32|win64)
+decklink_outdev_extralibs="-lole32 -loleaut32"
+decklink_indev_extralibs="-lole32 -loleaut32"
+;;
+esac
+fi
+
 disabled securetransport || { check_func SecIdentityCreate 
"-Wl,-framework,CoreFoundation -Wl,-framework,Security" &&
 check_lib "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" &&
 enable securetransport; }
diff --git 

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Aaron Levinson]

On 4/13/2017 2:10 AM, Hendrik Leppkes wrote:
> On Thu, Apr 13, 2017 at 11:04 AM, Aaron Levinson  wrote:
>>  static av_unused int pthread_cond_signal(pthread_cond_t *cond)
>>  {
>> -win32_cond_t *win32_cond = cond->Ptr;
>> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>>  int have_waiter;
>>  if (cond_signal) {
>>  cond_signal(cond);
>> @@ -400,17 +400,17 @@ static av_unused void w32thread_init(void)
>>  HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll"));
>>  /* if one is available, then they should all be available */
>>  cond_init  = (void (WINAPI*)(pthread_cond_t *))
>> -GetProcAddress(kernel_dll, "InitializeConditionVariable");
>> +GetProcAddress((HMODULE)kernel_dll, "InitializeConditionVariable");
>>  cond_broadcast = (void (WINAPI*)(pthread_cond_t *))
>> -GetProcAddress(kernel_dll, "WakeAllConditionVariable");
>> +GetProcAddress((HMODULE)kernel_dll, "WakeAllConditionVariable");
>>  cond_signal= (void (WINAPI*)(pthread_cond_t *))
>> -GetProcAddress(kernel_dll, "WakeConditionVariable");
>> +GetProcAddress((HMODULE)kernel_dll, "WakeConditionVariable");
>>  cond_wait  = (BOOL (WINAPI*)(pthread_cond_t *, pthread_mutex_t *, 
>> DWORD))
>> -GetProcAddress(kernel_dll, "SleepConditionVariableCS");
>> +GetProcAddress((HMODULE)kernel_dll, "SleepConditionVariableCS");
>>  initonce_begin = (BOOL (WINAPI*)(pthread_once_t *, DWORD, BOOL *, void 
>> **))
>> -GetProcAddress(kernel_dll, "InitOnceBeginInitialize");
>> +GetProcAddress((HMODULE)kernel_dll, "InitOnceBeginInitialize");
>>  initonce_complete = (BOOL (WINAPI*)(pthread_once_t *, DWORD, void *))
>> -GetProcAddress(kernel_dll, "InitOnceComplete");
>> +GetProcAddress((HMODULE)kernel_dll, "InitOnceComplete");
>>  #endif
> 
> One more comment that I missed earlier (sorry), GetModuleHandle
> returns the type HMODULE, can't you just change the type of kernel_dll
> to match that, and avoid the casts here?
> 
> - Hendrik

Yes, it is simpler and cleaner to properly set the return value of 
GetModuleHandle() to an HMODULE.  Here is what is hopefully the final version 
of the patch, which is also much cleaner and simplified from the original 
version.

Thanks,
Aaron

--

From 56f9a4b6c281a0d9382d2b4ec2e29aff5ab69fbc Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 02:38:02 -0700
Subject: [PATCH] Made appropriate changes to be able to successfully build C++ 
files using a Visual C++ build on Windows

Purpose: Made appropriate changes to be able to successfully
build C++ files using a Visual C++ build on Windows.  Note that this is a
continuation of the "fixes w32pthreads to support C++" aspect of Kyle
Schwarz's "Remove pthread dependency" patch that is available at
https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
as far as I can tell, there was no follow-up after it was rejected.

Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
approach for specifying -Fo$@ in configure based on code review from
Hendrik Leppkes for first version of patch.  Also simplified changes
to w32pthreads.h per Hendrik's review.

Comments:

-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
   get it to build when it is being included in a C++ file and built
   with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
   described above.

-- configure:
a) Now calling set_ccvars CXX to cause the various CXX_ variables to
   be setup properly.  For example, with MSVC (Microsoft Visual C++),
   this causes CXX_O to be set to -Fo$@ instead of using the default
   value.  The default value does not work with Visual C++.  This
   change will also have the impact of correcting CXX_O (and possibly
   CXX_C) for other compilers, although this is really only relevant
   for the Intel compiler, in addition to MSVC.
b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
   currently only relevant for building the
   Blackmagic/Decklink-related files under avdevice.
---
 compat/w32pthreads.h | 14 +++---
 configure|  3 +++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 0c9a7fa..eeead60 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
 
 static av_unused unsigned __stdcall attribute_align_arg 
win32thread_worker(void *arg)
 {
-pthread_t *h = arg;
+pthread_t *h = (pthread_t*)arg;
 h->ret = h->func(h->arg);
 return 0;
 }
@@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
*cond, const void *unused_
 }
 
 /* non native condition variables */
-win32_cond = av_mallocz(sizeof(win32_cond_t));
+win32_cond = 

Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/interlace: add complex vertical low-pass filter

[Thomas Mundt]

>>>James Almer  schrieb am Do, 13.4.2017:
On 4/12/2017 9:39 PM, Thomas Mundt wrote:
>> 
>> James Almer suggested to change the function prototype. Which was easy in c, 
>> but for simd this is the best I can do.
>
> I didn't check, but I think the reason i told you to change the prototype here
> was to share the function pointer with lowpass_line_complex, so you can do
> something like
> 
> if (tinterlace->flags & TINTERLACE_FLAG_VLPF)
> tinterlace->lowpass_line = lowpass_line_c;
> else if (tinterlace->flags & TINTERLACE_FLAG_CVLPF)
> tinterlace->lowpass_line = lowpass_line_complex_c;
> 
> instead of adding a new one to InterlaceContext and TInterlaceContext.
> Otherwise you wouldn't really gain much changing the prototype for linear 
> here.

Okay, I will change that when I´m back from vacation in a week.

>> I asked for help a month ago but get no reply. Can you tell me how to avoid 
>> this?
> 
> Yes, sorry, i kinda lost track of this since for some reason your emails start
> a new thread each instead of showing up as a reply.

Yes, the yahoo web cient is buggy. I will change this also.

> You just need to turn mref and pref into the equivalent of the old srcp_above
> and srcp_below pointers, like so:
> 
> diff --git a/libavfilter/x86/vf_interlace.asm 
> b/libavfilter/x86/vf_interlace.asm
> index f70c700965..8a0dd3bdea 100644
> --- a/libavfilter/x86/vf_interlace.asm
> +++ b/libavfilter/x86/vf_interlace.asm
> @@ -28,32 +28,32 @@ SECTION_RODATA
>  SECTION .text
>  
>  %macro LOWPASS_LINE 0
> -cglobal lowpass_line, 5, 5, 7
> -add r0, r1
> -add r2, r1
> -add r3, r1
> -add r4, r1
> -neg r1
> +cglobal lowpass_line, 5, 5, 7, dst, h, src, mref, pref
> +add dstq, hq
> +add srcq, hq
> +add mrefq, srcq
> +add prefq, srcq
> +neg hq

Thanks a lot!

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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 10:36 AM, Aaron Levinson  wrote:
> On 4/13/2017 1:21 AM, Hendrik Leppkes wrote:
>>
>> On Thu, Apr 13, 2017 at 5:32 AM, Aaron Levinson 
>> wrote:
>>>
>>> diff --git a/configure b/configure
>>> index b0f7b1a..adb0060 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2992,9 +2992,9 @@ avfoundation_indev_deps="pthreads"
>>>  avfoundation_indev_extralibs="-framework Foundation -framework
>>> AVFoundation -framework CoreVideo -framework CoreMedia"
>>>  bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h
>>> dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
>>>  caca_outdev_deps="libcaca"
>>> -decklink_indev_deps="decklink pthreads"
>>> +decklink_indev_deps="decklink"
>>>  decklink_indev_extralibs="-lstdc++"
>>> -decklink_outdev_deps="decklink pthreads"
>>> +decklink_outdev_deps="decklink"
>>
>>
>> You should probably still have a dependency on "threads" (a combined
>> dep for any threading support), or does the device work without any
>> threading support now?
>
>
> That makes sense, and I think I follow how the threads dependency is
> generated in configure.  Should I generate an entirely new patch?  The only
> difference would be the following, assuming all is okay with the actual code
> changes:
>

Give it some time for the other changes to be reviewed by the people
that actually know decklink itself, you can include that in any new
versions of the patch then, no need to send one for that right now.

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

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 11:04 AM, Aaron Levinson  wrote:
> On 4/13/2017 1:27 AM, Hendrik Leppkes wrote:
>> On Thu, Apr 13, 2017 at 10:23 AM, Aaron Levinson  
>> wrote:
>>> diff --git a/configure b/configure
>>> index b2fc781..6112b9b 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3637,8 +3637,10 @@ case "$toolchain" in
>>>  cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version 
>>> \([[:digit:]]\{1,\}\)\..*/\1/p')
>>>  if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
>>>  cc_default="cl"
>>> +cxx_default="cl"
>>>  else
>>>  cc_default="c99wrap cl"
>>> +cxx_default="c99wrap cl"
>>>  fi
>>>  ld_default="$source_path/compat/windows/mslink"
>>>  nm_default="dumpbin -symbols"
>>> @@ -3983,7 +3985,7 @@ probe_cc(){
>>>  _cc=$2
>>>  first=$3
>>>
>>> -unset _type _ident _cc_c _cc_e _cc_o _flags _cflags
>>> +unset _type _ident _cc_c _cc_e _cc_o _cxx_o _flags _cflags
>>>  unset _ld_o _ldflags _ld_lib _ld_path
>>>  unset _depflags _DEPCMD _DEPFLAGS
>>>  _flags_filter=echo
>>> @@ -4156,6 +4158,7 @@ probe_cc(){
>>>  fi
>>>  _cc_o='-Fo$@'
>>>  _cc_e='-P -Fi$@'
>>> +_cxx_o='-Fo$@'
>>>  _flags_filter=msvc_flags
>>>  _ld_lib='lib%.a'
>>>  _ld_path='-libpath:'
>>> @@ -4196,6 +4199,7 @@ cflags_noopt=$_cflags_noopt
>>>  add_cflags $_flags $_cflags
>>>  cc_ldflags=$_ldflags
>>>  set_ccvars CC
>>> +set_ccvars CXX
>>>
>>>  probe_cc hostcc "$host_cc"
>>>  host_cflags_filter=$_flags_filter
>>
>> Technically this just happens to work by accident because CC_O and
>> CXX_O get the same value, which is probably fine for all C++ compilers
>> we currently support.
>> set_ccvars always uses the _cc_o variable to set whatever namespace
>> you requested (_cxx_o is never used), so you could remove the _cxx_o
>> handling from probe_cc entirely and it would still work.
>>
>> Full CXX probing through probe_cc would be the most complete solution,
>> but probably overkill?
>>
>> - Hendrik
>
> Yes, I realize now that my use of _cxx_o had no effect, and it was simply the 
> use of set_ccvars CXX that caused the CXX_ variables to be updated.  I would 
> tend to agree that full CXX probing is probably overkill given that there are 
> only are few C++ files in ffmpeg, and those files have to do with Decklink, 
> which is only supported on a few operating systems as well.
>
> I also realize now that this patch is more general than one that just applies 
> to MSVC, although, in practice, the change will only benefit the Intel 
> compiler, in addition to MSVC.  Hopefully, I won't be asked to separate out 
> the set_ccvars CXX line into a separate patch :-)
>
> Here is hopefully the final version of the patch with updated comments to 
> reflect the more general nature of the patch.
>
> Thanks,
> Aaron Levinson
>
> --
>
> From 415f1f233eb963318d436fe272c3b80dda9d2d4d Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Thu, 13 Apr 2017 01:45:23 -0700
> Subject: [PATCH] Made appropriate changes to be able to successfully build 
> C++ files using a Visual C++ build on Windows
>
> Purpose: Made appropriate changes to be able to successfully
> build C++ files using a Visual C++ build on Windows.  Note that this is a
> continuation of the "fixes w32pthreads to support C++" aspect of Kyle
> Schwarz's "Remove pthread dependency" patch that is available at
> https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
> as far as I can tell, there was no follow-up after it was rejected.
>
> Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
> approach for specifying -Fo$@ in configure based on code review from
> Hendrik Leppkes for first version of patch.
>
> Comments:
>
> -- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
>get it to build when it is being included in a C++ file and built
>with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
>described above.
>
> -- configure:
> a) Now calling set_ccvars CXX to cause the various CXX_ variables to
>be setup properly.  For example, with MSVC (Microsoft Visual C++),
>this causes CXX_O to be set to -Fo$@ instead of using the default
>value.  The default value does not work with Visual C++.  This
>change will also have the impact of correcting CXX_O (and possibly
>CXX_C) for other compilers, although this is really only relevant
>for the Intel compiler, in addition to MSVC.
> b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
>currently only relevant for building the
>Blackmagic/Decklink-related files under avdevice.
> ---
>  compat/w32pthreads.h | 24 
>  configure|  3 +++
>  2 files changed, 15 insertions(+), 12 deletions(-)
>
> diff 

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Aaron Levinson]

On 4/13/2017 1:27 AM, Hendrik Leppkes wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Aaron Levinson  wrote:
>> diff --git a/configure b/configure
>> index b2fc781..6112b9b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3637,8 +3637,10 @@ case "$toolchain" in
>>  cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version 
>> \([[:digit:]]\{1,\}\)\..*/\1/p')
>>  if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
>>  cc_default="cl"
>> +cxx_default="cl"
>>  else
>>  cc_default="c99wrap cl"
>> +cxx_default="c99wrap cl"
>>  fi
>>  ld_default="$source_path/compat/windows/mslink"
>>  nm_default="dumpbin -symbols"
>> @@ -3983,7 +3985,7 @@ probe_cc(){
>>  _cc=$2
>>  first=$3
>>
>> -unset _type _ident _cc_c _cc_e _cc_o _flags _cflags
>> +unset _type _ident _cc_c _cc_e _cc_o _cxx_o _flags _cflags
>>  unset _ld_o _ldflags _ld_lib _ld_path
>>  unset _depflags _DEPCMD _DEPFLAGS
>>  _flags_filter=echo
>> @@ -4156,6 +4158,7 @@ probe_cc(){
>>  fi
>>  _cc_o='-Fo$@'
>>  _cc_e='-P -Fi$@'
>> +_cxx_o='-Fo$@'
>>  _flags_filter=msvc_flags
>>  _ld_lib='lib%.a'
>>  _ld_path='-libpath:'
>> @@ -4196,6 +4199,7 @@ cflags_noopt=$_cflags_noopt
>>  add_cflags $_flags $_cflags
>>  cc_ldflags=$_ldflags
>>  set_ccvars CC
>> +set_ccvars CXX
>>
>>  probe_cc hostcc "$host_cc"
>>  host_cflags_filter=$_flags_filter
> 
> Technically this just happens to work by accident because CC_O and
> CXX_O get the same value, which is probably fine for all C++ compilers
> we currently support.
> set_ccvars always uses the _cc_o variable to set whatever namespace
> you requested (_cxx_o is never used), so you could remove the _cxx_o
> handling from probe_cc entirely and it would still work.
> 
> Full CXX probing through probe_cc would be the most complete solution,
> but probably overkill?
> 
> - Hendrik

Yes, I realize now that my use of _cxx_o had no effect, and it was simply the 
use of set_ccvars CXX that caused the CXX_ variables to be updated.  I would 
tend to agree that full CXX probing is probably overkill given that there are 
only are few C++ files in ffmpeg, and those files have to do with Decklink, 
which is only supported on a few operating systems as well.

I also realize now that this patch is more general than one that just applies 
to MSVC, although, in practice, the change will only benefit the Intel 
compiler, in addition to MSVC.  Hopefully, I won't be asked to separate out the 
set_ccvars CXX line into a separate patch :-)

Here is hopefully the final version of the patch with updated comments to 
reflect the more general nature of the patch.

Thanks,
Aaron Levinson

--

From 415f1f233eb963318d436fe272c3b80dda9d2d4d Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 01:45:23 -0700
Subject: [PATCH] Made appropriate changes to be able to successfully build C++ 
files using a Visual C++ build on Windows

Purpose: Made appropriate changes to be able to successfully
build C++ files using a Visual C++ build on Windows.  Note that this is a
continuation of the "fixes w32pthreads to support C++" aspect of Kyle
Schwarz's "Remove pthread dependency" patch that is available at
https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
as far as I can tell, there was no follow-up after it was rejected.

Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
approach for specifying -Fo$@ in configure based on code review from
Hendrik Leppkes for first version of patch.

Comments:

-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
   get it to build when it is being included in a C++ file and built
   with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
   described above.

-- configure:
a) Now calling set_ccvars CXX to cause the various CXX_ variables to
   be setup properly.  For example, with MSVC (Microsoft Visual C++),
   this causes CXX_O to be set to -Fo$@ instead of using the default
   value.  The default value does not work with Visual C++.  This
   change will also have the impact of correcting CXX_O (and possibly
   CXX_C) for other compilers, although this is really only relevant
   for the Intel compiler, in addition to MSVC.
b) Now using cl for the C++ compiler for the MSVC toolchain.  This is
   currently only relevant for building the
   Blackmagic/Decklink-related files under avdevice.
---
 compat/w32pthreads.h | 24 
 configure|  3 +++
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 0c9a7fa..a6c699b 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
 
 static av_unused unsigned __stdcall attribute_align_arg 

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Aaron Levinson]

On 4/13/2017 1:21 AM, Hendrik Leppkes wrote:

On Thu, Apr 13, 2017 at 5:32 AM, Aaron Levinson  wrote:

diff --git a/configure b/configure
index b0f7b1a..adb0060 100755
--- a/configure
+++ b/configure
@@ -2992,9 +2992,9 @@ avfoundation_indev_deps="pthreads"
 avfoundation_indev_extralibs="-framework Foundation -framework AVFoundation 
-framework CoreVideo -framework CoreMedia"
 bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h 
dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
 caca_outdev_deps="libcaca"
-decklink_indev_deps="decklink pthreads"
+decklink_indev_deps="decklink"
 decklink_indev_extralibs="-lstdc++"
-decklink_outdev_deps="decklink pthreads"
+decklink_outdev_deps="decklink"


You should probably still have a dependency on "threads" (a combined
dep for any threading support), or does the device work without any
threading support now?


That makes sense, and I think I follow how the threads dependency is 
generated in configure.  Should I generate an entirely new patch?  The 
only difference would be the following, assuming all is okay with the 
actual code changes:


diff --git a/configure b/configure
index b0f7b1a..adb0060 100755
--- a/configure
+++ b/configure
@@ -2992,9 +2992,9 @@ avfoundation_indev_deps="pthreads"
 avfoundation_indev_extralibs="-framework Foundation -framework 
AVFoundation -framework CoreVideo -framework CoreMedia"
 bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h 
dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"

 caca_outdev_deps="libcaca"
-decklink_indev_deps="decklink pthreads"
+decklink_indev_deps="decklink threads"
 decklink_indev_extralibs="-lstdc++"
-decklink_outdev_deps="decklink pthreads"
+decklink_outdev_deps="decklink threads"
 decklink_outdev_extralibs="-lstdc++"
 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 
-lshlwapi"


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

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 10:23 AM, Aaron Levinson  wrote:
> On 4/13/2017 12:21 AM, Hendrik Leppkes wrote:
>> On Thu, Apr 13, 2017 at 2:16 AM, Aaron Levinson  wrote:
>>> diff --git a/configure b/configure
>>> index d13d60b..b0f7b1a 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3635,10 +3635,13 @@ case "$toolchain" in
>>>  # successfully parses the version number of existing supported
>>>  # versions that require the converter (MSVC 2010 and 2012).
>>>  cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version 
>>> \([[:digit:]]\{1,\}\)\..*/\1/p')
>>> +CXX_O='-Fo$@'
>>>  if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
>>>  cc_default="cl"
>>> +cxx_default="cl"
>>>  else
>>>  cc_default="c99wrap cl"
>>> +cxx_default="c99wrap cl"
>>>  fi
>>>  ld_default="$source_path/compat/windows/mslink"
>>>  nm_default="dumpbin -symbols"
>>
>> CXX_O is in the wrong spot, it should be set at the same place where
>> CC_O is beint set, and not here.
>>
>> - Hendrik
>
> I believe that I've addressed your comment, and a new version of the patch 
> can be found below.
>
> Thanks,
> Aaron Levinson
>
> -
>
> From 764aed11d179fd42d1aa8c1c507d7660386cfde6 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Thu, 13 Apr 2017 01:13:07 -0700
> Subject: [PATCH] Made appropriate changes to be able to successfully build 
> C++ files using a Visual C++ build on Windows
>
> Purpose: Made appropriate changes to be able to successfully
>  build C++ files using a Visual C++ build on Windows.  Note that this is a
>  continuation of the "fixes w32pthreads to support C++" aspect of Kyle
>  Schwarz's "Remove pthread dependency" patch that is available at
>  https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
>  as far as I can tell, there was no follow-up after it was rejected.
>
> Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
> approach for specifying -Fo$@ in configure based on code review from
> Hendrik Leppkes for first version of patch.
>
> Comments:
>
> -- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
>get it to build when it is being included in a C++ file and built
>with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
>described above.
>
> -- configure: Made minor modifications to MSVC (Microsoft Visual C++)
>toolchain section to make sure that -Fo$@ is used when building
>object files but when the C++ compiler is used and also to use cl
>for the default C++ compiler.  This is currently only relevant for
>building the Blackmagic/Decklink-related files under avdevice.
> ---
>  compat/w32pthreads.h | 24 
>  configure|  6 +-
>  2 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 0c9a7fa..a6c699b 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
>
>  static av_unused unsigned __stdcall attribute_align_arg 
> win32thread_worker(void *arg)
>  {
> -pthread_t *h = arg;
> +pthread_t *h = (pthread_t*)arg;
>  h->ret = h->func(h->arg);
>  return 0;
>  }
> @@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
> *cond, const void *unused_
>  }
>
>  /* non native condition variables */
> -win32_cond = av_mallocz(sizeof(win32_cond_t));
> +win32_cond = (win32_cond_t*)av_mallocz(sizeof(win32_cond_t));
>  if (!win32_cond)
>  return ENOMEM;
>  cond->Ptr = win32_cond;
> @@ -288,7 +288,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
> *cond, const void *unused_
>
>  static av_unused int pthread_cond_destroy(pthread_cond_t *cond)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  /* native condition variables do not destroy */
>  if (cond_init)
>  return 0;
> @@ -305,7 +305,7 @@ static av_unused int pthread_cond_destroy(pthread_cond_t 
> *cond)
>
>  static av_unused int pthread_cond_broadcast(pthread_cond_t *cond)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  int have_waiter;
>
>  if (cond_broadcast) {
> @@ -337,7 +337,7 @@ static av_unused int 
> pthread_cond_broadcast(pthread_cond_t *cond)
>
>  static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t 
> *mutex)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  int last_waiter;
>  if (cond_wait) {
>  cond_wait(cond, mutex, INFINITE);
> @@ -369,7 +369,7 @@ static av_unused int pthread_cond_wait(pthread_cond_t 
> *cond, 

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Aaron Levinson]

On 4/13/2017 12:21 AM, Hendrik Leppkes wrote:
> On Thu, Apr 13, 2017 at 2:16 AM, Aaron Levinson  wrote:
>> diff --git a/configure b/configure
>> index d13d60b..b0f7b1a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3635,10 +3635,13 @@ case "$toolchain" in
>>  # successfully parses the version number of existing supported
>>  # versions that require the converter (MSVC 2010 and 2012).
>>  cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version 
>> \([[:digit:]]\{1,\}\)\..*/\1/p')
>> +CXX_O='-Fo$@'
>>  if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then
>>  cc_default="cl"
>> +cxx_default="cl"
>>  else
>>  cc_default="c99wrap cl"
>> +cxx_default="c99wrap cl"
>>  fi
>>  ld_default="$source_path/compat/windows/mslink"
>>  nm_default="dumpbin -symbols"
> 
> CXX_O is in the wrong spot, it should be set at the same place where
> CC_O is beint set, and not here.
> 
> - Hendrik

I believe that I've addressed your comment, and a new version of the patch can 
be found below.

Thanks,
Aaron Levinson

-

From 764aed11d179fd42d1aa8c1c507d7660386cfde6 Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 13 Apr 2017 01:13:07 -0700
Subject: [PATCH] Made appropriate changes to be able to successfully build C++ 
files using a Visual C++ build on Windows

Purpose: Made appropriate changes to be able to successfully
 build C++ files using a Visual C++ build on Windows.  Note that this is a 
 continuation of the "fixes w32pthreads to support C++" aspect of Kyle 
 Schwarz's "Remove pthread dependency" patch that is available at 
 https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
 as far as I can tell, there was no follow-up after it was rejected.

Notes: Used Visual Studio 2015 (with update 3) for this.  Altered
approach for specifying -Fo$@ in configure based on code review from
Hendrik Leppkes for first version of patch.

Comments:

-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
   get it to build when it is being included in a C++ file and built
   with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
   described above.

-- configure: Made minor modifications to MSVC (Microsoft Visual C++)
   toolchain section to make sure that -Fo$@ is used when building
   object files but when the C++ compiler is used and also to use cl
   for the default C++ compiler.  This is currently only relevant for
   building the Blackmagic/Decklink-related files under avdevice.
---
 compat/w32pthreads.h | 24 
 configure|  6 +-
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index 0c9a7fa..a6c699b 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
 
 static av_unused unsigned __stdcall attribute_align_arg 
win32thread_worker(void *arg)
 {
-pthread_t *h = arg;
+pthread_t *h = (pthread_t*)arg;
 h->ret = h->func(h->arg);
 return 0;
 }
@@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
*cond, const void *unused_
 }
 
 /* non native condition variables */
-win32_cond = av_mallocz(sizeof(win32_cond_t));
+win32_cond = (win32_cond_t*)av_mallocz(sizeof(win32_cond_t));
 if (!win32_cond)
 return ENOMEM;
 cond->Ptr = win32_cond;
@@ -288,7 +288,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
*cond, const void *unused_
 
 static av_unused int pthread_cond_destroy(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 /* native condition variables do not destroy */
 if (cond_init)
 return 0;
@@ -305,7 +305,7 @@ static av_unused int pthread_cond_destroy(pthread_cond_t 
*cond)
 
 static av_unused int pthread_cond_broadcast(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int have_waiter;
 
 if (cond_broadcast) {
@@ -337,7 +337,7 @@ static av_unused int pthread_cond_broadcast(pthread_cond_t 
*cond)
 
 static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t 
*mutex)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int last_waiter;
 if (cond_wait) {
 cond_wait(cond, mutex, INFINITE);
@@ -369,7 +369,7 @@ static av_unused int pthread_cond_wait(pthread_cond_t 
*cond, pthread_mutex_t *mu
 
 static av_unused int pthread_cond_signal(pthread_cond_t *cond)
 {
-win32_cond_t *win32_cond = cond->Ptr;
+win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
 int have_waiter;
 if (cond_signal) {
 cond_signal(cond);
@@ -400,17 +400,17 @@ 

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Removed pthread dependency

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 5:32 AM, Aaron Levinson  wrote:
> From d175e7fc94a2efc4f0bad021c118e4f907832c9c Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Wed, 12 Apr 2017 20:12:11 -0700
> Subject: [PATCH] avdevice/decklink: Removed pthread dependency
>
> Purpose: avdevice/decklink: Removed pthread dependency by
>  replacing semaphore used in code appropriately.  Doing so makes it easier to
>   build ffmpeg using Visual C++ on Windows.  This is a contination of Kyle
>  Schwarz's "avdevice/decklink: Remove pthread dependency" patch that is
>  available at https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't
>  accepted, and as far as I can tell, there was no follow-up after it was
>  rejected.
>
> Notes: Used Visual Studio 2015 (with update 3) for this.
>
> Comments:
>
> -- configure: Eliminated pthreads dependency for decklink_indev_deps
>and decklink_outdev_deps
>
> -- libavdevice/decklink_common.cpp / .h:
> a) Eliminated semaphore and replaced with a combination of a mutex,
>condition variable, and a counter (frames_buffer_available_spots).
> b) Removed include of pthread.h and semaphore.h and now using
>libavutil/thread.h instead.
>
> -- libavdevice/decklink_dec.cpp: Eliminated include of pthread.h and
>semaphore.h.
>
> -- libavdevice/decklink_enc.cpp:
> a) Eliminated include of pthread.h and semaphore.h.
> b) Replaced use of semaphore with the equivalent using a combination
>of a mutex, condition variable, and a counter
>(frames_buffer_available_spots).  In theory, libavutil/thread.h and
>the associated code could have been modified instead to add
>cross-platform implementations of the sem_ functions, but an
>inspection of the ffmpeg source base indicates that there are only
>two cases in which semaphores are used (including this one that was
>replaced), so it was deemed to not be worth the effort.
> ---
>  configure   |  4 ++--
>  libavdevice/decklink_common.cpp |  3 ---
>  libavdevice/decklink_common.h   |  5 -
>  libavdevice/decklink_dec.cpp|  3 ---
>  libavdevice/decklink_enc.cpp| 23 +++
>  5 files changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/configure b/configure
> index b0f7b1a..adb0060 100755
> --- a/configure
> +++ b/configure
> @@ -2992,9 +2992,9 @@ avfoundation_indev_deps="pthreads"
>  avfoundation_indev_extralibs="-framework Foundation -framework AVFoundation 
> -framework CoreVideo -framework CoreMedia"
>  bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h 
> dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
>  caca_outdev_deps="libcaca"
> -decklink_indev_deps="decklink pthreads"
> +decklink_indev_deps="decklink"
>  decklink_indev_extralibs="-lstdc++"
> -decklink_outdev_deps="decklink pthreads"
> +decklink_outdev_deps="decklink"

You should probably still have a dependency on "threads" (a combined
dep for any threading support), or does the device work without any
threading support now?

>  decklink_outdev_extralibs="-lstdc++"
>  dshow_indev_deps="IBaseFilter"
>  dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 
> -lshlwapi"
> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
> index c9107c0..f01fba9 100644
> --- a/libavdevice/decklink_common.cpp
> +++ b/libavdevice/decklink_common.cpp
> @@ -26,9 +26,6 @@
>  #include 
>  #endif
>
> -#include 
> -#include 
> -
>  extern "C" {
>  #include "libavformat/avformat.h"
>  #include "libavformat/internal.h"
> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
> index 4753287..c12cf18 100644
> --- a/libavdevice/decklink_common.h
> +++ b/libavdevice/decklink_common.h
> @@ -24,6 +24,7 @@
>
>  #include 
>
> +#include "libavutil/thread.h"
>  #include "decklink_common_c.h"
>
>  class decklink_output_callback;
> @@ -89,7 +90,9 @@ struct decklink_ctx {
>  int frames_preroll;
>  int frames_buffer;
>
> -sem_t semaphore;
> +pthread_mutex_t mutex;
> +pthread_cond_t cond;
> +int frames_buffer_available_spots;
>
>  int channels;
>  };
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 8cc1bdf..67eaf97 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -21,9 +21,6 @@
>
>  #include 
>
> -#include 
> -#include 
> -
>  extern "C" {
>  #include "config.h"
>  #include "libavformat/avformat.h"
> diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
> index 18ef905..5105967 100644
> --- a/libavdevice/decklink_enc.cpp
> +++ b/libavdevice/decklink_enc.cpp
> @@ -24,9 +24,6 @@ using std::atomic;
>
>  #include 
>
> -#include 
> -#include 
> -
>  extern "C" {
>  #include "libavformat/avformat.h"
>  #include "libavformat/internal.h"
> @@ -91,7 +88,10 @@ public:
>
>  av_frame_unref(avframe);
>
> -sem_post(>semaphore);
> +pthread_mutex_lock(>mutex);
> +ctx->frames_buffer_available_spots++;

Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function

[Rostislav Pehlivanov]

On 13 April 2017 at 07:13, Carl Eugen Hoyos  wrote:

> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov :
> > On 12 April 2017 at 23:50, Carl Eugen Hoyos  wrote:
> >
> >> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov :
> >>
> >> > +/* Undo the sample reorganization going from time order to
> >> > frequency order */
> >> > +if (B0 > 1)
> >> > +celt_interleave_hadamard(f->scratch, X, N_B >>
> recombine,
> >> > + B0< >>
> >> Is this the same code as in opus/celt/bands.c?
> >> Who wrote it?
> >
> > This exact line is also on line 1206 of the same file for PVQ decoding .
> > Most of the PVQ encoder is copied from our decoder since they're very
> > similar. This commit just copies more.
>
> > The reason why you can find the same string in libopus is because that
> > decoder was cut down, modified and ported as our native decoder.
>
> Then I suggest you add the missing copyright notices to the decoder
> and the encoder.
>
> Thank you for the explanation, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

There's nothing to do:
> * Copyright (c) 2012 Andrew D'Addesio
> * Copyright (c) 2013-2014 Mozilla Corporation
> * Copyright (c) 2017 Rostislav Pehlivanov 

Mozilla relicensed the decoder to LGPL when it was ported.
___
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 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] Made minor changes to get the decklink avdevice code to build using Visual C++

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 5:34 AM, Aaron Levinson  wrote:
> From aa549cf1c463f4a37bda44b934e17811986f11d9 Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Wed, 12 Apr 2017 20:21:41 -0700
> Subject: [PATCH] Made minor changes to get the decklink avdevice code to 
> build using Visual C++
>
> Purpose: Made minor changes to get the decklink avdevice
>  code to build using Visual C++.
>
> Notes: Used Visual Studio 2015 (with update 3) for this.
>
> Comments:
>
> -- configure: For MSVC (Microsoft Visual C++) builds, now reinitializing
>decklink_indev_extralibs and decklink_outdev_extralibs to empty and
>then later, following the similar procedure used for mingw by
>adding -lole32 and -loleaut32.  This is necessary in order for it
>to link properly when building with Visual C++.
>
> -- libavdevice/decklink_common.cpp: Switched the order of the include
>of libavformat/internal.h to workaround build issues with Visual
>C++.  See comment in file for more details.
>
> -- libavdevice/decklink_dec.cpp:
> a) Rearranged the include of libavformat/internal.h (for reasons as
>described above).
> b) Made slight alteration to an argument for call to av_rescale_q() to
>workaround a compiler error with Visual C++.  This appears to only
>be an issue when building C++ files with Visual C++.  See comments
>in code for more details.
>
> -- libavdevice/decklink_enc.cpp: Rearranged the include of
>libavformat/internal.h (for reasons as described above).
> ---
>  configure   |  4 
>  libavdevice/decklink_common.cpp | 10 +-
>  libavdevice/decklink_dec.cpp| 17 +++--
>  libavdevice/decklink_enc.cpp|  5 -
>  4 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index adb0060..5b76a33 100755
> --- a/configure
> +++ b/configure
> @@ -3646,6 +3646,8 @@ case "$toolchain" in
>  ld_default="$source_path/compat/windows/mslink"
>  nm_default="dumpbin -symbols"
>  ar_default="lib"
> +decklink_indev_extralibs=""
> +decklink_outdev_extralibs=""
>  case "$arch" in
>  arm*)
>  as_default="armasm"

As in the other patch before, the toolchain handling section has no
business setting these.

> @@ -4902,6 +4904,8 @@ case $target_os in
>  fi
>  enabled x86_32 && check_ldflags -LARGEADDRESSAWARE
>  shlibdir_default="$bindir_default"
> +decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 
> -loleaut32"
> +decklink_indev_extralibs="$decklink_indev_extralibs -lole32 
> -loleaut32"
>  SLIBPREF=""
>  SLIBSUF=".dll"
>  
> SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)'

I really don't like having these decklink specific things in the OS
sections. I know its already there in one section, but I would greatly
prefer if this would also be moved into a dedicated decklink section
somewhere, instead of littering the msvc/mingw sections.
In fact, its now set for both mingw and msvc, so setting it centrally
in one place would be even better to avoid duplicating it.

> diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
> index f01fba9..523217c 100644
> --- a/libavdevice/decklink_common.cpp
> +++ b/libavdevice/decklink_common.cpp
> @@ -19,6 +19,15 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>
> +// Moved inclusion of internal.h here in order to get it to build 
> successfully
> +// when using Visual C++ to build--otherwise, compilation errors result
> +// due to winsock.h (which is included indirectly by DeckLinkAPI.h and
> +// DeckLinkAPI_i.c) conflicting with winsock2.h, which is included by
> +// internal.h.  If winsock2.h is included first, then the conflict is 
> resolved.
> +extern "C" {
> +#include "libavformat/internal.h"
> +}
> +
>  #include 
>  #ifdef _WIN32
>  #include 
> @@ -28,7 +37,6 @@
>
>  extern "C" {
>  #include "libavformat/avformat.h"
> -#include "libavformat/internal.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/intreadwrite.h"
>  #include "libavutil/bswap.h"
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 67eaf97..a663029 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -19,12 +19,15 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>
> +extern "C" {
> +#include "libavformat/internal.h"
> +}
> +
>  #include 
>
>  extern "C" {
>  #include "config.h"
>  #include "libavformat/avformat.h"
> -#include "libavformat/internal.h"
>  #include "libavutil/avutil.h"
>  #include "libavutil/common.h"
>  #include "libavutil/imgutils.h"
> @@ -262,8 +265,18 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame 
> *videoFrame,
>  res = 
> videoFrame->GetHardwareReferenceTimestamp(time_base.den, 

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

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 9:20 AM, 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.
>

We require Dead-Code-Eliminiation to be performed at all times in a
FFmpeg build, so your compiler needs to do this for a build to
succeed.
You can find the reasonings and discussions about this in the Mailing
List archives, it comes up once in a while.

If you are actually working on some code, I can only recommend to use
the pragma in the files you are working on. Its not that bad, really.

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

Re: [FFmpeg-devel] [PATCH] Made appropriate changes to be able to successfully build C++ files using a Visual C++ build on Windows

[Hendrik Leppkes]

On Thu, Apr 13, 2017 at 2:16 AM, Aaron Levinson  wrote:
> From 722cbb5f6544323430d883212ac2e38c4eb94e5f Mon Sep 17 00:00:00 2001
> From: Aaron Levinson 
> Date: Wed, 12 Apr 2017 16:33:39 -0700
> Subject: [PATCH] Made appropriate changes to be able to successfully build 
> C++ files using a Visual C++ build on Windows.
>
> Purpose:  Made appropriate changes to be able to
>  successfully build C++ files using a Visual C++ build on Windows.  Note that
>  this is a continuation of the "fixes w32pthreads to support C++" aspect of
>  Kyle Schwarz's "Remove pthread dependency" patch that is available at
>  https://patchwork.ffmpeg.org/patch/2654/ .  This patch wasn't accepted, and
>  as far as I can tell, there was no follow-up after it was rejected.
>
> Notes:  Used Visual Studio 2015 (with update 3) for this.
>
> Comments:
>
> -- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
>get it to build when it is being included in a C++ file and built
>with Visual C++.  This is mostly a copy of Kyle Schwarz's patch as
>described above.
>
> -- configure: Made minor modifications to MSVC (Microsoft Visual C++)
>toolchain section to make sure that -Fo$@ is used when building
>object files but when the C++ compiler is used and also to use cl
>for the default C++ compiler.  This is currently only relevant for
>building the Blackmagic/Decklink-related files under avdevice.
> ---
>  compat/w32pthreads.h | 24 
>  configure|  3 +++
>  2 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
> index 0c9a7fa..a6c699b 100644
> --- a/compat/w32pthreads.h
> +++ b/compat/w32pthreads.h
> @@ -77,7 +77,7 @@ typedef struct pthread_cond_t {
>
>  static av_unused unsigned __stdcall attribute_align_arg 
> win32thread_worker(void *arg)
>  {
> -pthread_t *h = arg;
> +pthread_t *h = (pthread_t*)arg;
>  h->ret = h->func(h->arg);
>  return 0;
>  }
> @@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
> *cond, const void *unused_
>  }
>
>  /* non native condition variables */
> -win32_cond = av_mallocz(sizeof(win32_cond_t));
> +win32_cond = (win32_cond_t*)av_mallocz(sizeof(win32_cond_t));
>  if (!win32_cond)
>  return ENOMEM;
>  cond->Ptr = win32_cond;
> @@ -288,7 +288,7 @@ static av_unused int pthread_cond_init(pthread_cond_t 
> *cond, const void *unused_
>
>  static av_unused int pthread_cond_destroy(pthread_cond_t *cond)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  /* native condition variables do not destroy */
>  if (cond_init)
>  return 0;
> @@ -305,7 +305,7 @@ static av_unused int pthread_cond_destroy(pthread_cond_t 
> *cond)
>
>  static av_unused int pthread_cond_broadcast(pthread_cond_t *cond)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  int have_waiter;
>
>  if (cond_broadcast) {
> @@ -337,7 +337,7 @@ static av_unused int 
> pthread_cond_broadcast(pthread_cond_t *cond)
>
>  static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t 
> *mutex)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  int last_waiter;
>  if (cond_wait) {
>  cond_wait(cond, mutex, INFINITE);
> @@ -369,7 +369,7 @@ static av_unused int pthread_cond_wait(pthread_cond_t 
> *cond, pthread_mutex_t *mu
>
>  static av_unused int pthread_cond_signal(pthread_cond_t *cond)
>  {
> -win32_cond_t *win32_cond = cond->Ptr;
> +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr;
>  int have_waiter;
>  if (cond_signal) {
>  cond_signal(cond);
> @@ -400,17 +400,17 @@ static av_unused void w32thread_init(void)
>  HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll"));
>  /* if one is available, then they should all be available */
>  cond_init  = (void (WINAPI*)(pthread_cond_t *))
> -GetProcAddress(kernel_dll, "InitializeConditionVariable");
> +GetProcAddress((HMODULE)kernel_dll, "InitializeConditionVariable");
>  cond_broadcast = (void (WINAPI*)(pthread_cond_t *))
> -GetProcAddress(kernel_dll, "WakeAllConditionVariable");
> +GetProcAddress((HMODULE)kernel_dll, "WakeAllConditionVariable");
>  cond_signal= (void (WINAPI*)(pthread_cond_t *))
> -GetProcAddress(kernel_dll, "WakeConditionVariable");
> +GetProcAddress((HMODULE)kernel_dll, "WakeConditionVariable");
>  cond_wait  = (BOOL (WINAPI*)(pthread_cond_t *, pthread_mutex_t *, 
> DWORD))
> -GetProcAddress(kernel_dll, "SleepConditionVariableCS");
> +GetProcAddress((HMODULE)kernel_dll, "SleepConditionVariableCS");
>  initonce_begin = (BOOL (WINAPI*)(pthread_once_t *, DWORD, BOOL *, void 
> **))
> -

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

[Aaron Levinson]

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.


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

Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function

[Carl Eugen Hoyos]

2017-04-13 8:44 GMT+02:00 Paul B Mahol :
> On 4/13/17, Carl Eugen Hoyos  wrote:
>> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov :
>>> On 12 April 2017 at 23:50, Carl Eugen Hoyos  wrote:
>>>
 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov :

 > +/* Undo the sample reorganization going from time order to
 > frequency order */
 > +if (B0 > 1)
 > +celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
 > + B0<>>
>>> This exact line is also on line 1206 of the same file for PVQ decoding .
>>> Most of the PVQ encoder is copied from our decoder since they're very
>>> similar. This commit just copies more.
>>
>>> The reason why you can find the same string in libopus is because that
>>> decoder was cut down, modified and ported as our native decoder.
>>
>> Then I suggest you add the missing copyright notices to the decoder
>> and the encoder.
>
> Your suggestions should always be ignored.

Would you like to elaborate or are you just trolling?

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

Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function

[Paul B Mahol]

On 4/13/17, Carl Eugen Hoyos  wrote:
> 2017-04-13 4:02 GMT+02:00 Rostislav Pehlivanov :
>> On 12 April 2017 at 23:50, Carl Eugen Hoyos  wrote:
>>
>>> 2017-04-13 0:26 GMT+02:00 Rostislav Pehlivanov :
>>>
>>> > +/* Undo the sample reorganization going from time order to
>>> > frequency order */
>>> > +if (B0 > 1)
>>> > +celt_interleave_hadamard(f->scratch, X, N_B >> recombine,
>>> > + B0<>>
>>> Is this the same code as in opus/celt/bands.c?
>>> Who wrote it?
>>
>> This exact line is also on line 1206 of the same file for PVQ decoding .
>> Most of the PVQ encoder is copied from our decoder since they're very
>> similar. This commit just copies more.
>
>> The reason why you can find the same string in libopus is because that
>> decoder was cut down, modified and ported as our native decoder.
>
> Then I suggest you add the missing copyright notices to the decoder
> and the encoder.

Your suggestions should always be ignored.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lsws/utils: Make gray10 and gray12 full-scale like gray8 and gray16

[Carl Eugen Hoyos]

2017-04-13 3:53 GMT+02:00 James Almer :
> On 4/12/2017 6:01 PM, Carl Eugen Hoyos wrote:
>> 2017-04-04 14:01 GMT+02:00 Ronald S. Bultje :
>>> Hi,
>>>
>>> On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos  wrote:
>>>
 Hi!

 I believe attached patch makes FFmpeg a little more consistent with itself.
>>>
>>>
>>> Looks like it, yes.
>>
>> Patch applied.
>>
>> Thank you for the analysis, Carl Eugen
>
> This broke gray10/12 on every filter-pixdesc and filter-pixfmts test.
> You should update the refs, assuming the changes are intended.

Done, they are.

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