Re: [FFmpeg-devel] [PATCH] fate: add tests/fate/hlsenc.mak for hls FATE

2019-01-03 Thread Steven Liu 
Michael Niedermayer  于2019年1月3日周四 下午8:32写道：
>
> On Mon, Dec 24, 2018 at 05:44:56PM +0800, Steven Liu wrote:
> > init add three test examples:
> > 1. check no endlist at the end
> > 2. check endlist at the end
> > 3. check hls_list_size 0 full list
> >
> > Signed-off-by: Steven Liu 
> > ---
> >  tests/Makefile|  1 +
> >  tests/fate/hlsenc.mak | 43 +++
> >  2 files changed, 44 insertions(+)
> >  create mode 100644 tests/fate/hlsenc.mak
>
> tested on x86-32 & 64 linux, mingw32 & 64, arm and mips qemu
Pushed


Thanks

>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Freedom in capitalist society always remains about the same as it was in
> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avcodec/fft_template: improve performance of the ff_fft_init in fft_template

2019-01-03 Thread Steven Liu 
Michael Niedermayer  于2019年1月4日周五 上午3:01写道：
>
> On Wed, Dec 26, 2018 at 04:15:27PM +0800, Steven Liu wrote:
> > Before patch:
> > init nbits = 17, get 1 samples, average cost: 16175 us
> > After patch:
> > init nbits = 17, get 1 samples, average cost: 14989 us
> >
> > Signed-off-by: Steven Liu 
> > ---
> >  libavcodec/fft_template.c | 46 
> > +++---
> >  1 file changed, 35 insertions(+), 11 deletions(-)
>
> should be ok

Pushed


Thanks
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
> ___
> 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] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

2019-01-03 Thread Michael Niedermayer 
Found-by: jamrial
Signed-off-by: Michael Niedermayer 
---
 libavcodec/tests/rangecoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
index b6edc1493f..d6cf9ec380 100644
--- a/libavcodec/tests/rangecoder.c
+++ b/libavcodec/tests/rangecoder.c
@@ -29,7 +29,7 @@
 int main(void)
 {
 RangeCoder c;
-uint8_t b[9 * SIZE];
+uint8_t b[9 * SIZE] = {0};
 uint8_t r[9 * SIZE];
 int i, p, actual_length, version;
 uint8_t state[10];
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

2019-01-03 Thread James Almer 
On 1/3/2019 10:07 PM, Rostislav Pehlivanov wrote:
> On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi  wrote:
> 
>>
>>  /**
>> @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
>>  uint32_t min_luminance;
>>  } HEVCSEIMasteringDisplay;
>>
>> +typedef struct HEVCSEIDynamicHDRPlus{
>> +int present;
>> +uint8_t itu_t_t35_country_code;
>> +uint8_t application_version;
>> +uint8_t num_windows;
>> +struct {
>> +AVRational window_upper_left_corner_x;
>> +AVRational window_upper_left_corner_y;
>> +AVRational window_lower_right_corner_x;
>> +AVRational window_lower_right_corner_y;
>> +uint16_t center_of_ellipse_x;
>> +uint16_t center_of_ellipse_y;
>> +uint8_t rotation_angle;
>> +uint16_t semimajor_axis_internal_ellipse;
>> +uint16_t semimajor_axis_external_ellipse;
>> +uint16_t semiminor_axis_external_ellipse;
>> +uint8_t overlap_process_option;
>> +AVRational maxscl[3];
>> +AVRational average_maxrgb;
>> +uint8_t num_distribution_maxrgb_percentiles;
>> +struct {
>> +uint8_t percentage;
>> +AVRational percentile;
>> +} distribution_maxrgb[15];
>> +AVRational fraction_bright_pixels;
>> +uint8_t tone_mapping_flag;
>> +AVRational knee_point_x;
>> +AVRational knee_point_y;
>> +uint8_t num_bezier_curve_anchors;
>> +AVRational bezier_curve_anchors[15];
>> +uint8_t color_saturation_mapping_flag;
>> +AVRational color_saturation_weight;
>> +} params[3];
>> +AVRational targeted_system_display_maximum_luminance;
>> +uint8_t targeted_system_display_actual_peak_luminance_flag;
>> +uint8_t num_rows_targeted_system_display_actual_peak_luminance;
>> +uint8_t num_cols_targeted_system_display_actual_peak_luminance;
>> +AVRational targeted_system_display_actual_peak_luminance[25][25];
>> +uint8_t mastering_display_actual_peak_luminance_flag;
>> +uint8_t num_rows_mastering_display_actual_peak_luminance;
>> +uint8_t num_cols_mastering_display_actual_peak_luminance;
>> +AVRational mastering_display_actual_peak_luminance[25][25];
>> +} HEVCSEIDynamicHDRPlus;
>> +
>>
> 
> There's no reason to create a new struct for this if all you're going to do
> is to copy it over and over to new frames.

It was my suggestion, as that's what's done for mastering metadata.

> What you can do is this: on every SEI containing this thing just allocate a
> AVDynamicHDRPlus struct via av_dynamic_hdr_plus_alloc, wrap it as an
> AVBufferRef via av_buffer_create, populate it, put it as a pointer in
> HEVCSEIContentLight and then on every frame just add it to the frame via
> av_frame_new_side_data_from_buf. If a new SEI is received unref your
> pointer in HEVCSEIDynamicHDRPlus and repeat by allocating a new struct,
> wrapping it as a buffer, populating it, etc.

You're right, that does sound simpler. Is this SEI valid for every frame
after it shows up? If so, it's definitely a better solution.

> I figure the only reason this wasn't done with other metadata was because
> they were much smaller and because av_frame_new_side_data_from_buf didn't
> exist until recently.
> 
> 
> +av_log(s->avctx, AV_LOG_DEBUG, ")");
>> +if (metadata->params[w].color_saturation_mapping_flag) {
>> +av_log(s->avctx, AV_LOG_DEBUG,
>> +   " color_saturation_weight=%5.4f",
>> +
>>  av_q2d(metadata->params[w].color_saturation_weight));
>> +}
>> +av_log(s->avctx, AV_LOG_DEBUG, "}\n");
>> +}
>> +av_log(s->avctx, AV_LOG_DEBUG,
>> +   "} End of HDR10+ (SMPTE 2094-40)\n");
>> +}
>>
> 
> Don't spam stuff like than in the debug log, especially not on every single
> frame. Tools exist to print side data so just don't.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

2019-01-03 Thread Rostislav Pehlivanov 
On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi  wrote:

>
>  /**
> @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
>  uint32_t min_luminance;
>  } HEVCSEIMasteringDisplay;
>
> +typedef struct HEVCSEIDynamicHDRPlus{
> +int present;
> +uint8_t itu_t_t35_country_code;
> +uint8_t application_version;
> +uint8_t num_windows;
> +struct {
> +AVRational window_upper_left_corner_x;
> +AVRational window_upper_left_corner_y;
> +AVRational window_lower_right_corner_x;
> +AVRational window_lower_right_corner_y;
> +uint16_t center_of_ellipse_x;
> +uint16_t center_of_ellipse_y;
> +uint8_t rotation_angle;
> +uint16_t semimajor_axis_internal_ellipse;
> +uint16_t semimajor_axis_external_ellipse;
> +uint16_t semiminor_axis_external_ellipse;
> +uint8_t overlap_process_option;
> +AVRational maxscl[3];
> +AVRational average_maxrgb;
> +uint8_t num_distribution_maxrgb_percentiles;
> +struct {
> +uint8_t percentage;
> +AVRational percentile;
> +} distribution_maxrgb[15];
> +AVRational fraction_bright_pixels;
> +uint8_t tone_mapping_flag;
> +AVRational knee_point_x;
> +AVRational knee_point_y;
> +uint8_t num_bezier_curve_anchors;
> +AVRational bezier_curve_anchors[15];
> +uint8_t color_saturation_mapping_flag;
> +AVRational color_saturation_weight;
> +} params[3];
> +AVRational targeted_system_display_maximum_luminance;
> +uint8_t targeted_system_display_actual_peak_luminance_flag;
> +uint8_t num_rows_targeted_system_display_actual_peak_luminance;
> +uint8_t num_cols_targeted_system_display_actual_peak_luminance;
> +AVRational targeted_system_display_actual_peak_luminance[25][25];
> +uint8_t mastering_display_actual_peak_luminance_flag;
> +uint8_t num_rows_mastering_display_actual_peak_luminance;
> +uint8_t num_cols_mastering_display_actual_peak_luminance;
> +AVRational mastering_display_actual_peak_luminance[25][25];
> +} HEVCSEIDynamicHDRPlus;
> +
>

There's no reason to create a new struct for this if all you're going to do
is to copy it over and over to new frames.
What you can do is this: on every SEI containing this thing just allocate a
AVDynamicHDRPlus struct via av_dynamic_hdr_plus_alloc, wrap it as an
AVBufferRef via av_buffer_create, populate it, put it as a pointer in
HEVCSEIContentLight and then on every frame just add it to the frame via
av_frame_new_side_data_from_buf. If a new SEI is received unref your
pointer in HEVCSEIDynamicHDRPlus and repeat by allocating a new struct,
wrapping it as a buffer, populating it, etc.
I figure the only reason this wasn't done with other metadata was because
they were much smaller and because av_frame_new_side_data_from_buf didn't
exist until recently.


+av_log(s->avctx, AV_LOG_DEBUG, ")");
> +if (metadata->params[w].color_saturation_mapping_flag) {
> +av_log(s->avctx, AV_LOG_DEBUG,
> +   " color_saturation_weight=%5.4f",
> +
>  av_q2d(metadata->params[w].color_saturation_weight));
> +}
> +av_log(s->avctx, AV_LOG_DEBUG, "}\n");
> +}
> +av_log(s->avctx, AV_LOG_DEBUG,
> +   "} End of HDR10+ (SMPTE 2094-40)\n");
> +}
>

Don't spam stuff like than in the debug log, especially not on every single
frame. Tools exist to print side data so just don't.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/vapoursynth: properly initialize err variable in read_header_vs()

2019-01-03 Thread nu774 
The variable "err" is not initialized, and set only when something went wrong.
When everything is OK, nobody sets it, so using it result in UB.
---
 libavformat/vapoursynth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/vapoursynth.c b/libavformat/vapoursynth.c
index f3ad6910e5..69fde1a806 100644
--- a/libavformat/vapoursynth.c
+++ b/libavformat/vapoursynth.c
@@ -177,7 +177,7 @@ static av_cold int read_header_vs(AVFormatContext *s)
 char dummy;
 const VSVideoInfo *info;
 struct VSState *vss_state;
-int err;
+int err = 0;
 
 vss_state = av_mallocz(sizeof(*vss_state));
 if (!vss_state) {
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH] libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S

2019-01-03 Thread Michael Niedermayer 
On Wed, Jan 02, 2019 at 06:29:22PM -0800, Manoj Gupta wrote:
> On Wed, Jan 2, 2019 at 2:33 PM Michael Niedermayer
>  wrote:
> >
> > On Wed, Jan 02, 2019 at 10:12:33AM -0800, Manoj Gupta wrote:
> > > On Mon, Dec 31, 2018 at 8:31 AM Michael Niedermayer
> > >  wrote:
> > > >
> > > > On Fri, Dec 28, 2018 at 03:12:53PM -0800, Manoj Gupta wrote:
> > > > > Hi All,
> > > > >
> > > > > I recently had a problem building ffmpeg for AArch64 where lld linker
> > > > > complained about text relocations in readonly segment. The following
> > > > > patch fixes the linker complains by referring to a local label instead
> > > > > of function name.
> > > > >
> > > > > This is similar in nature as the following previous commits:
> > > > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34290.html
> > > > > https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg34419.html
> > > > >
> > > > > Thanks,
> > > > > Manoj
> > > > >
> > > > > Patch:
> > > > >
> > > > > libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S
> > > > >
> > > > > Some of the assembly functions e.g. ff_h264_idct_dc_add_neon
> > > > > has code like:
> > > > > movrel  x14, X(ff_h264_idct_add_neon)
> > > > >
> > > > > Linker cannot resolve them fully at link time and emits dynamic
> > > > > relocations.
> > > > > Use explicit labels instead so that no dynamic relocations are
> > > > > needed at all.
> > > > >
> > > > > This avoids lld complains about text relocations.
> > > > >
> > > > > For background, see https://crbug.com/917919
> > > > >
> > > > > Signed-off-by: Manoj Gupta 
> > > > > ---
> > > > >  libavcodec/aarch64/h264idct_neon.S | 20 
> > > > >  1 file changed, 12 insertions(+), 8 deletions(-)
> > > >
> > > > Has this been tested on all common aarch64 platforms ?
> > > >
> > > I have tested this on Chromium with clang+lld linker and Debian
> > > aarch64 cross compiler gcc + bfd linker.
> > > Please let me know if more testing is needed.
> >
> > it would be good to test on apple too
> >
> 
> Thanks, tested on my macbook compiling to aarch64 and the build itself was 
> fine.
> 
> Use the following configure (+ make) command, hopefully I did it the right 
> way.
> 
>  ./configure --cc=$HOME/ffmpeg/my-clang --cxx=$HOME/ffmpeg/my-clang++
> --prefix=$HOME/ffmpeg/ffmpeg_out --enable-cross-compile --arch=aarch64
> --target-os=darwin
> --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk
> --sysinclude=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk
> 
> my-clang and my-clang++ are wrapper scripts passing the iphone SDK
> headers to clang.
> 
> $ cat my-clang
> #! /bin/bash
> clang -isysroot $(xcrun --sdk iphoneos --show-sdk-path) -arch arm64 "$@"

thanks, will apply

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

2019-01-03 Thread Mohammad Izadi 
---
 libavcodec/hevc_sei.c | 219 --
 libavcodec/hevc_sei.h |  46 +
 libavcodec/hevcdec.c  | 195 +
 3 files changed, 454 insertions(+), 6 deletions(-)

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..da6f8257b8 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -206,10 +206,207 @@ static int 
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
 return 0;
 }
 
-static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, 
GetBitContext *gb,
+static int decode_registered_user_data_dynamic_hdr_plus(HEVCSEIDynamicHDRPlus 
*s, GetBitContext *gb,
+void *logctx, int size)
+{
+const int luminance_den = 1;
+const int peak_luminance_den = 15;
+const int rgb_den = 10;
+const int fraction_pixel_den = 1000;
+const int knee_point_den = 4095;
+const int bezier_anchor_den = 1023;
+const int saturation_weight_den = 8;
+
+int bits_left = size * 8;
+int w, i, j;
+
+if (bits_left < 2)
+return AVERROR_INVALIDDATA;
+
+s->num_windows = get_bits(gb, 2);
+bits_left -= 2;
+if (s->num_windows < 1 || s->num_windows > 3) {
+av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
+   s->num_windows);
+return AVERROR_INVALIDDATA;
+}
+
+if (bits_left < ((19 * 8 + 1) * (s->num_windows - 1)))
+return AVERROR(EINVAL);
+for (w = 1; w < s->num_windows; w++) {
+s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
+s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
+// The corners are set to absolute coordinates here. They should be
+// converted to the relative coordinates (in [0, 1]) in the decoder.
+s->params[w].window_upper_left_corner_x.den = 1;
+s->params[w].window_upper_left_corner_y.den = 1;
+s->params[w].window_lower_right_corner_x.den = 1;
+s->params[w].window_lower_right_corner_y.den = 1;
+
+s->params[w].center_of_ellipse_x = get_bits(gb, 16);
+s->params[w].center_of_ellipse_y = get_bits(gb, 16);
+s->params[w].rotation_angle = get_bits(gb, 8);
+s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
+s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].overlap_process_option = get_bits(gb, 1);
+bits_left -= 19 * 8 + 1;
+}
+
+if (bits_left < 28)
+return AVERROR(EINVAL);
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
+s->targeted_system_display_maximum_luminance.den = luminance_den;
+s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
+bits_left -= 28;
+
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+int rows, cols;
+if (bits_left < 10)
+return AVERROR(EINVAL);
+rows = get_bits(gb, 5);
+cols = get_bits(gb, 5);
+if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
+av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they must "
+   "be in [2, 25] for "
+   "targeted_system_display_actual_peak_luminance\n",
+   rows, cols);
+return AVERROR_INVALIDDATA;
+}
+s->num_rows_targeted_system_display_actual_peak_luminance = rows;
+s->num_cols_targeted_system_display_actual_peak_luminance = cols;
+bits_left -= 10;
+
+if (bits_left < (rows * cols * 4))
+return AVERROR(EINVAL);
+
+for (i = 0; i < rows; i++) {
+for (j = 0; j < cols; j++) {
+s->targeted_system_display_actual_peak_luminance[i][j].num =
+get_bits(gb, 4);
+s->targeted_system_display_actual_peak_luminance[i][j].den =
+peak_luminance_den;
+}
+}
+bits_left -= (rows * cols * 4);
+}
+for (w = 0; w < s->num_windows; w++) {
+if (bits_left < (3 * 17 + 17 + 4))
+return AVERROR(EINVAL);
+for (i = 0; i < 3; i++) {
+s->params[w].maxscl[i].num = get_bits(gb, 17);
+s->params[w].maxscl[i].den = rgb_den;
+}
+s->params[w].average_maxrgb.num = get_bits(gb, 17);
+s->params[w].average_maxrgb.den = rgb_den;
+s->params[w].num_distribution_maxrgb_percentiles = get_bits(gb, 4);
+bits_left -= (3 * 17 + 17 + 4);
+
+if (bits_left <
+(s->params[w].num_distribution_maxrgb_percentiles * 24))
+return AVERROR(EINVAL);
+for (i = 0; i <

[FFmpeg-devel] [PATCH 2/2] Pass through HDR dynamic metdata (HDR10+) to AV packet side data.

2019-01-03 Thread Mohammad Izadi 
---
 libavcodec/avcodec.h  | 8 
 libavcodec/avpacket.c | 1 +
 libavcodec/decode.c   | 1 +
 libavcodec/version.h  | 2 +-
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 92567ec6d0..75fd44d74c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1361,6 +1361,14 @@ enum AVPacketSideDataType {
  */
 AV_PKT_DATA_A53_CC,
 
+/**
+ * HDR10+ dynamic metadata associated with a video frame. The metadata is 
in
+ * the form of the AVDynamicHDRPlus struct and contains
+ * information for color volume transform - application 4 of
+ * SPMTE 2094-40:2016 standard.
+ */
+AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS,
+
 /**
  * This side data is encryption initialization data.
  * The format is not part of ABI, use av_encryption_init_info_* methods to
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 11ac4e80cd..48f3857fc2 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -391,6 +391,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
+case AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS:   return "HDR10+ Dynamic 
Metadata (SMPTE 2094-40)";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a32ff2fcd3..c6bc48567a 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1706,6 +1706,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 { AV_PKT_DATA_MASTERING_DISPLAY_METADATA, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
 { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
 { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS,   
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
 };
 
 if (pkt) {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index ed56a1ece5..e72168affb 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  43
+#define LIBAVCODEC_VERSION_MINOR  44
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.20.1.415.g653613c723-goog

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

[FFmpeg-devel] logo detection

2019-01-03 Thread Uwe Freese 

Hello,


By the way, you would not be interested in developing a logo-detection
filter, per chance? Something that detects is a certain rectangle is
likely to contain a logo and computes its bounding box.


Currently, I don't need it so much, but nonetheless I though a bit about it:

1)

Is there an "average" filter (or some filter that can be used like 
this)? I mean, a filter which creates the average of every one pixel for 
the whole video? (The last picture would then be the average of the 
whole video.)


I assume that the average value is "some grey", with some noise in it. 
The logo should be visible.


Then use "edgedetect" and we have the logo. Afterwards, some "eq" to 
make everything else black. Then "cropdetect". :)


Could this work? I would play a bit with this, but don't know how to 
calculate the "average" easy. Any ideas?


2)

If something like this would work, is it intended to reuse existing 
ffmpeg filters in other ffmpeg filters? Do other filters combine logic 
from existing filters (making them available with one filter string in 
the filter graph)?


3)

Playing around with edgedetection a bit (I wanted to mask edges and use 
a denoiser only in the remaining areas), I saw there seems no filter to 
convert a grey-level picture into pure black and white and no "and", 
"or", "invert" etc. filters, right? Or didn't I find them?


4)

What should be the result of the filter? A text file with coordinates of 
the most likely position, or a list of positions and likelihood in 
percentage? I mean, the user has to check manually afterwards if the 
detection worked and call ffmpeg again with removing the logo at the 
given coordinates, right?


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

Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

2019-01-03 Thread Mohammad Izadi 
Hi James,

Thank you for your comments. I applied all your notes and will sent you two
patches in reply to your email.

--
Best,
Mohammad


On Wed, Dec 26, 2018 at 12:11 PM James Almer  wrote:

> On 12/26/2018 4:40 PM, Mohammad Izadi wrote:
> > Decode HDR10+ metadata from SEI message and propagate it to side data.
> > ---
> >  libavcodec/avcodec.h  |  10 +-
> >  libavcodec/avpacket.c |   1 +
> >  libavcodec/decode.c   |   2 +-
> >  libavcodec/hevc_sei.c | 234 --
> >  libavcodec/hevc_sei.h |   7 ++
> >  libavcodec/hevcdec.c  |  79 ++
> >  6 files changed, 322 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index fd7f60bf4a..044aa447ab 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1328,7 +1328,7 @@ enum AVPacketSideDataType {
> >  AV_PKT_DATA_METADATA_UPDATE,
> >
> >  /**
> > - * MPEGTS stream ID as uint8_t, this is required to pass the stream
> ID
> > + * MPEGTS stream ID, this is required to pass the stream ID
>
> This looks like an unrelated change.
>
> >   * information from the demuxer to the corresponding muxer.
> >   */
> >  AV_PKT_DATA_MPEGTS_STREAM_ID,
> > @@ -1360,6 +1360,14 @@ enum AVPacketSideDataType {
> >   */
> >  AV_PKT_DATA_A53_CC,
> >
> > +/**
> > + * HDR10+ dynamic metadata associated with a video frame. The
> metadata is in
> > + * the form of the AVDynamicHDRPlus struct and contains
> > + * information for color volume transform - application 4 of
> > + * SPMTE 2094-40:2016 standard.
> > + */
> > +AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS,
>
> Adding this value should be its own commit, with a minor avcodec version
> bump.
>
> > +
> >  /**
> >   * This side data is encryption initialization data.
> >   * The format is not part of ABI, use av_encryption_init_info_*
> methods to
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index e160ad3033..137a0489d4 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -391,6 +391,7 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> >  case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light
> level metadata";
> >  case AV_PKT_DATA_SPHERICAL:  return "Spherical
> Mapping";
> >  case AV_PKT_DATA_A53_CC: return "A53 Closed
> Captions";
> > +case AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS: return "HDR10+ Dynamic
> Metadata (SMPTE 2094-40)";
>
> Vertical alignment.
>
> >  case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption
> initialization data";
> >  case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption
> info";
> >  case AV_PKT_DATA_AFD:return "Active Format
> Description data";
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index a32ff2fcd3..a2d6ec4f18 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1378,7 +1378,6 @@ int ff_get_format(AVCodecContext *avctx, const
> enum AVPixelFormat *fmt)
> >  if (i == n) {
> >  av_log(avctx, AV_LOG_ERROR, "Invalid return from
> get_format(): "
> > "%s not in possible list.\n", desc->name);
> > -ret = AV_PIX_FMT_NONE;
>
> Also unrelated.
>
> >  break;
> >  }
> >
> > @@ -1706,6 +1705,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> >  { AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
> >  { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
> >  { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC
> },
> > +{ AV_PKT_DATA_HDR_DYNAMIC_HDR_PLUS,
> AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
>
> Vertical alignment again.
>
> >  };
> >
> >  if (pkt) {
> > diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> > index c59bd4321e..e261c038c3 100644
> > --- a/libavcodec/hevc_sei.c
> > +++ b/libavcodec/hevc_sei.c
> > @@ -206,10 +206,209 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
> >  return 0;
> >  }
> >
> > -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> > +static int decode_registered_user_data_dynamic_hdr_plus(
> > +HEVCSEIDynamicHDRPlus *s, GetBitContext *gb,
> > +void *logctx, int size)
>
> Same.
>
> > +{
> > +const int luminance_den = 1;
> > +const int peak_luminance_den = 15;
> > +const int rgb_den = 10;
> > +const int fraction_pixel_den = 1000;
> > +const int knee_point_den = 4095;
> > +const int bezier_anchor_den = 1023;
> > +const int saturation_weight_den = 8;
> > +
> > +AVDynamicHDRPlus* info = s->info;
> > +int bits_left = size * 8;
> > +int w, i, j;
> > +
> > +if (bits_left < 2)
> > +return AVERROR(EINVAL);
>
> AVERROR_INVALIDDATA. We use

Re: [FFmpeg-devel] [PATCH v3] avcodec/fft_template: improve performance of the ff_fft_init in fft_template

2019-01-03 Thread Michael Niedermayer 
On Wed, Dec 26, 2018 at 04:15:27PM +0800, Steven Liu wrote:
> Before patch:
> init nbits = 17, get 1 samples, average cost: 16175 us
> After patch:
> init nbits = 17, get 1 samples, average cost: 14989 us
> 
> Signed-off-by: Steven Liu 
> ---
>  libavcodec/fft_template.c | 46 +++---
>  1 file changed, 35 insertions(+), 11 deletions(-)

should be ok

thx

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

2019-01-03 Thread James Almer 
On 1/3/2019 1:12 PM, Oliver Collyer wrote:
> Version created using git format-patch.

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

2019-01-03 Thread Derek Buitenhuis 
On 03/01/2019 01:33, Michael Niedermayer wrote:
> The file looks like 2 files concatenated, even with FLV main header between 
> them. 

Yes, they all seem to be. I was under the impression FLV didn't have a header to
check against like this. Seems I was wrong.

> the patch below should make this work with sequential demuxing assuming the
> 2 files dont change streams somehow with the normal demuxer.
> 
> not sure this is the best way to do it ...

[...]

> also trying a random other flv related tool, FLVTool2 1.0.6 does not seem to
> demux the 2nd file of the 2 correctly. Which makes me suspect more that the
> file is invalid. Not that this would fundamentally change anything

Some do, some don't. Classic multimedia.

I would also be OK with a patch that simply stops demuxing like many programs
seem to do, instead of outputting the packets. Up to you which you prefer; I 
have
no strong opinion between the two.

> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 4b9f46902b..c9423da31c 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c

[...]

>  static int probe(AVProbeData *p, int live)
> @@ -917,6 +919,17 @@ static int resync(AVFormatContext *s)
>  flv->resync_buffer[j ] =
>  flv->resync_buffer[j1] = avio_r8(s->pb);
>  
> +if (i >= 8) {
> +uint8_t *d = flv->resync_buffer + j1 - 8;
> +if (d[0] == 'F' &&
> +d[1] == 'L' &&
> +d[2] == 'V' &&
> +d[3] < 5 && d[5] == 0) {
> +av_log(s, AV_LOG_WARNING, "Concatenated FLV detected, might 
> fail to demux, decode and seek %Ld\n", flv->last_ts);
> +flv->time_offset = flv->last_ts + 1;
> +}
> +}

How does this affect seeking? That is, is it safe? If it beaks seeking,
it may be better to not output the concatenated packets at all.

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

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

2019-01-03 Thread Oliver Collyer 
Version created using git format-patch.



0001-Fixed-some-minor-memory-leaks.patch
Description: Binary data

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

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

2019-01-03 Thread Oliver Collyer 
It was the file that was produced after a commit using git format-patch -n 
HEAD^1

I’m not all that familiar with these tools but that is what I typed and I 
attached the file it produced. This was using Windows.

>> On 3 Jan 2019, at 18:42, James Almer  wrote:
>> 
>> On 1/3/2019 4:59 AM, Oliver Collyer wrote:
>> 
>> 
>>> On 2 Jan 2019, at 17:52, Oliver Collyer  wrote:
>>> 
>>> 
>>> 
 On 2 Jan 2019, at 11:30, Oliver Collyer  wrote:
 
 
 
> On 1 Jan 2019, at 23:58, James Almer  wrote:
> 
> On 1/1/2019 5:01 PM, Oliver Collyer wrote:
>> -- Block 26224 at 0x74240F70: 151 bytes --
>> Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes
>> Call Stack (TID 55752):
>> ucrtbased.dll!aligned_malloc()
>> c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>> + 0x10 bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
>> emu-server.exe!libAVPin_Setup() + 0xA bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
>> emu-server.exe!libAVPin_Create() + 0x9B bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
>> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
>> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
>> emu-server.exe!dshow_open_device() + 0x1C bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1150): 
>> emu-server.exe!dshow_read_header() + 0x18 bytes
>> c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
>> emu-server.exe!avformat_open_input() + 0x11 bytes
>> c:\users\oliver\perforce\non-si\emu\shared\dsdevice_streaming_session.cpp
>>  (1142): 
>> emu-server.exe!DSDEVICE_STREAMING_SESSION::CAPTURE_THREAD::thread_run() 
>> + 0x23 bytes
>> c:\users\oliver\perforce\non-si\emu\shared\thread_base.cpp (241): 
>> emu-server.exe!THREAD_BASE::thread_func() + 0xE bytes
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>> (16707566): emu-server.exe!std::_Invoker_functor::_Call> (__cdecl*)(void *),void *>() + 0x2B bytes
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
>> (16707566): emu-server.exe!std::invoke() 
>> + 0x31 bytes
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
>> (239): emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Execute<0,1>()
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
>> (245): emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Run() + 0x19 bytes
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
>> (231): emu-server.exe!std::_LaunchPad> (__cdecl*)(void *),void *>,std::default_delete> (__cdecl*)(void *),void *> > > >::_Go()
>> c:\program files (x86)\microsoft visual 
>> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
>> (209): emu-server.exe!std::_Pad::_Call_func()
>> ucrtbased.dll!register_onexit_function() + 0x4A8 bytes
>> ucrtbased.dll!register_onexit_function() + 0xE1 bytes
>> KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>> ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>> Data:
>> 70 0F 24 7446 02 00 00ED ED ED EDED ED ED ED p.$tF... 
>> 
>> 36 DE C8 49F7 7F 00 0068 F0 CA 49F7 7F 00 00 6..I 
>> h..I
>> 8D 99 CA 49F7 7F 00 001F D6 C9 49F7 7F 00 00 ...I 
>> ...I
>> C9 9E CA 49F7 7F 00 00B7 FD C8 49F7 7F 00 00 ...I 
>> ...I
>> 22 EC C9 49F7 7F 00 007E E1 C8 49F7 7F 00 00 "..I 
>> ~..I
>> 3B 82 CA 49F7 7F 00 00CD CD CD CDCD CD CD CD ;..I 
>> 
>> CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>> CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>> CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
>> 
>> CD CD CD CDCD CD CD   
>> 
>> 
>> 
>> -- Block 26879 at 0x74242E10: 151 bytes --
>> Leak Hash: 0xA886255F, Count: 1, Total 151 bytes
>> Call Stack (TID 55752):
>> ucrtbased.dll!aligned_malloc()
>> c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
>> + 0x10 bytes
>> c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

2019-01-03 Thread James Almer 
On 1/3/2019 4:59 AM, Oliver Collyer wrote:
> 
> 
>> On 2 Jan 2019, at 17:52, Oliver Collyer  wrote:
>>
>>
>>
>>> On 2 Jan 2019, at 11:30, Oliver Collyer  wrote:
>>>
>>>
>>>
 On 1 Jan 2019, at 23:58, James Almer  wrote:

 On 1/1/2019 5:01 PM, Oliver Collyer wrote:
> -- Block 26224 at 0x74240F70: 151 bytes --
> Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes
> Call Stack (TID 55752):
>  ucrtbased.dll!aligned_malloc()
>  c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
> + 0x10 bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
> emu-server.exe!libAVPin_Setup() + 0xA bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
> emu-server.exe!libAVPin_Create() + 0x9B bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
> emu-server.exe!libAVFilter_Create() + 0xA8 bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
> emu-server.exe!dshow_open_device() + 0x1C bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1150): 
> emu-server.exe!dshow_read_header() + 0x18 bytes
>  c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
> emu-server.exe!avformat_open_input() + 0x11 bytes
>  
> c:\users\oliver\perforce\non-si\emu\shared\dsdevice_streaming_session.cpp 
> (1142): 
> emu-server.exe!DSDEVICE_STREAMING_SESSION::CAPTURE_THREAD::thread_run() + 
> 0x23 bytes
>  c:\users\oliver\perforce\non-si\emu\shared\thread_base.cpp (241): 
> emu-server.exe!THREAD_BASE::thread_func() + 0xE bytes
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
> (16707566): emu-server.exe!std::_Invoker_functor::_Call (__cdecl*)(void *),void *>() + 0x2B bytes
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
> (16707566): emu-server.exe!std::invoke() + 
> 0x31 bytes
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
> (239): emu-server.exe!std::_LaunchPad (__cdecl*)(void *),void *>,std::default_delete (__cdecl*)(void *),void *> > > >::_Execute<0,1>()
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
> (245): emu-server.exe!std::_LaunchPad (__cdecl*)(void *),void *>,std::default_delete (__cdecl*)(void *),void *> > > >::_Run() + 0x19 bytes
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
> (231): emu-server.exe!std::_LaunchPad (__cdecl*)(void *),void *>,std::default_delete (__cdecl*)(void *),void *> > > >::_Go()
>  c:\program files (x86)\microsoft visual 
> studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread 
> (209): emu-server.exe!std::_Pad::_Call_func()
>  ucrtbased.dll!register_onexit_function() + 0x4A8 bytes
>  ucrtbased.dll!register_onexit_function() + 0xE1 bytes
>  KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>  ntdll.dll!RtlUserThreadStart() + 0x21 bytes
> Data:
>  70 0F 24 7446 02 00 00ED ED ED EDED ED ED ED p.$tF... 
> 
>  36 DE C8 49F7 7F 00 0068 F0 CA 49F7 7F 00 00 6..I 
> h..I
>  8D 99 CA 49F7 7F 00 001F D6 C9 49F7 7F 00 00 ...I 
> ...I
>  C9 9E CA 49F7 7F 00 00B7 FD C8 49F7 7F 00 00 ...I 
> ...I
>  22 EC C9 49F7 7F 00 007E E1 C8 49F7 7F 00 00 "..I 
> ~..I
>  3B 82 CA 49F7 7F 00 00CD CD CD CDCD CD CD CD ;..I 
> 
>  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
> 
>  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
> 
>  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
> 
>  CD CD CD CDCD CD CD   
> 
>
>
> -- Block 26879 at 0x74242E10: 151 bytes --
> Leak Hash: 0xA886255F, Count: 1, Total 151 bytes
> Call Stack (TID 55752):
>  ucrtbased.dll!aligned_malloc()
>  c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
> + 0x10 bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
> emu-server.exe!libAVPin_Setup() + 0xA bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
> emu-server.exe!libAVPin_Create() + 0x9B bytes
>  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
> emu-server.exe!libAVFilter_Setup() + 0xA bytes
>

Re: [FFmpeg-devel] [PATCH 4/4] x86/af_afir: add ff_fcmul_add_avx()

2019-01-03 Thread James Almer 
On 1/3/2019 5:47 AM, Paul B Mahol wrote:
> On 1/3/19, James Almer  wrote:
>> fcmul_add_c: 1228.8
>> fcmul_add_sse3: 334.3
>> fcmul_add_avx: 186.3
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/x86/af_afir.asm| 8 +++-
>>  libavfilter/x86/af_afir_init.c | 5 +
>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
>> index fcc1f426db..8054ac5f10 100644
>> --- a/libavfilter/x86/af_afir.asm
>> +++ b/libavfilter/x86/af_afir.asm
>> @@ -27,7 +27,7 @@ SECTION .text
>>  ; void ff_fcmul_add(float *sum, const float *t, const float *c, int len)
>> ;--
>>
>> -INIT_XMM sse3
>> +%macro FCMUL_ADD 0
>>  cglobal fcmul_add, 4,4,6, sum, t, c, len
>>  shl   lend, 3
>>  add tq, lenq
>> @@ -61,3 +61,9 @@ ALIGN 16
>>  addss xm0, [sumq + lenq]
>>  movss [sumq + lenq], xm0
>>  RET
>> +%endmacro
>> +
>> +INIT_XMM sse3
>> +FCMUL_ADD
>> +INIT_YMM avx
>> +FCMUL_ADD
>> diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
>> index 29e6f976b2..c37212c381 100644
>> --- a/libavfilter/x86/af_afir_init.c
>> +++ b/libavfilter/x86/af_afir_init.c
>> @@ -24,6 +24,8 @@
>>
>>  void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
>> ptrdiff_t len);
>> +void ff_fcmul_add_avx(float *sum, const float *t, const float *c,
>> +  ptrdiff_t len);
>>
>>  av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
>>  {
>> @@ -32,4 +34,7 @@ av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
>>  if (EXTERNAL_SSE3(cpu_flags)) {
>>  s->fcmul_add = ff_fcmul_add_sse3;
>>  }
>> +if (EXTERNAL_AVX_FAST(cpu_flags)) {
>> +s->fcmul_add = ff_fcmul_add_avx;
>> +}
>>  }
>> --
>> 2.20.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> OK
> 
> Also write CPU on which you tested it.

Set pushed with that addition.

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

Re: [FFmpeg-devel] [PATCH] fate: add tests/fate/hlsenc.mak for hls FATE

2019-01-03 Thread Michael Niedermayer 
On Mon, Dec 24, 2018 at 05:44:56PM +0800, Steven Liu wrote:
> init add three test examples:
> 1. check no endlist at the end
> 2. check endlist at the end
> 3. check hls_list_size 0 full list
> 
> Signed-off-by: Steven Liu 
> ---
>  tests/Makefile|  1 +
>  tests/fate/hlsenc.mak | 43 +++
>  2 files changed, 44 insertions(+)
>  create mode 100644 tests/fate/hlsenc.mak

tested on x86-32 & 64 linux, mingw32 & 64, arm and mips qemu

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: allow disabling streams by type for inputs

2019-01-03 Thread Gyan 


On 03-01-2019 03:37 PM, Michael Niedermayer wrote:

ffmpeg_opt.c | 7 +++

  1 file changed, 7 insertions(+)
80740bd4538cc641b429476a77cb3b98f16cc41d  
0002-ffmpeg-allow-disabling-streams-by-type-for-inputs.patch
 From b6efe47010cda7b9d53d7464d68f5c63d0df7ff7 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 29 Dec 2018 16:19:09 +0530
Subject: [PATCH 2/2] ffmpeg: allow disabling streams by type for inputs

-vn/-an/-sn/-dn now works for input. Streams are still registered in
input_streams but they can't be automatically selected or mapped or
filtered.
---
  fftools/ffmpeg_opt.c | 7 +++
  1 file changed, 7 insertions(+)

LGTM


Pushed as 3ba5eef2c7b21a1af48d8d9ccb58f2ed4ebc874a

Thanks,
Gyan

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

Re: [FFmpeg-devel] patch for failing on WavPack DSD files

2019-01-03 Thread Michael Niedermayer 
On Wed, Jan 02, 2019 at 09:19:30PM -0800, David Bryant wrote:
> On 12/28/18 3:56 AM, Paul B Mahol wrote:
> > On 12/24/18, Derek Buitenhuis  wrote:
> >> On 24/12/2018 17:47, David Bryant wrote:
> >>> I want to do that, but am swamped at work right now, so it will probably
> >>> be a few months before I can get to that.
> >>>
> >>> In the meantime, I think this patch would be a safe stopgap (and prevent
> >>> the Kodi crash).
> >> I think it's OK for the meantime (my opinion).
> > Applied.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Thanks!
> 
> The guys at Kodi asked me to request that this patch be backported to 4.0.
> 
> I don't really know if that's a thing, but if it is then that would be great.

locally backported, should be part of my next push to release/4.0

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: allow disabling streams by type for inputs

2019-01-03 Thread Michael Niedermayer 
On Sat, Dec 29, 2018 at 04:40:34PM +0530, Gyan wrote:
> -vn/-an/-sn/-dn now work for inputs
> 
> Gyan.
> 

>  ffmpeg_opt.c |7 +++
>  1 file changed, 7 insertions(+)
> 80740bd4538cc641b429476a77cb3b98f16cc41d  
> 0002-ffmpeg-allow-disabling-streams-by-type-for-inputs.patch
> From b6efe47010cda7b9d53d7464d68f5c63d0df7ff7 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sat, 29 Dec 2018 16:19:09 +0530
> Subject: [PATCH 2/2] ffmpeg: allow disabling streams by type for inputs
> 
> -vn/-an/-sn/-dn now works for input. Streams are still registered in
> input_streams but they can't be automatically selected or mapped or
> filtered.
> ---
>  fftools/ffmpeg_opt.c | 7 +++
>  1 file changed, 7 insertions(+)

LGTM

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH 1/4] x86/af_afir: fix processing the last element

2019-01-03 Thread Paul B Mahol 
On 1/3/19, James Almer  wrote:
> ff_fcmul_add_sse3() is now identical to the C version.
>
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/af_afir.asm | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
> index 849d85e70f..fcc1f426db 100644
> --- a/libavfilter/x86/af_afir.asm
> +++ b/libavfilter/x86/af_afir.asm
> @@ -30,7 +30,6 @@ SECTION .text
>  INIT_XMM sse3
>  cglobal fcmul_add, 4,4,6, sum, t, c, len
>  shl   lend, 3
> -add   lend, mmsize*2
>  add tq, lenq
>  add cq, lenq
>  add   sumq, lenq
> @@ -57,4 +56,8 @@ ALIGN 16
>  movaps[sumq + lenq+mmsize], m3
>  add   lenq, mmsize*2
>  jl .loop
> -REP_RET
> +movss xm0, [tq + lenq]
> +mulss xm0, [cq + lenq]
> +addss xm0, [sumq + lenq]
> +movss [sumq + lenq], xm0
> +RET
> --
> 2.20.1

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

Re: [FFmpeg-devel] [PATCH 3/4] checkasm: add an af_afir test

2019-01-03 Thread Paul B Mahol 
On 1/3/19, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/Makefile   |  1 +
>  tests/checkasm/af_afir.c  | 83 +++
>  tests/checkasm/checkasm.c |  3 ++
>  tests/checkasm/checkasm.h |  1 +
>  tests/fate/checkasm.mak   |  1 +
>  5 files changed, 89 insertions(+)
>  create mode 100644 tests/checkasm/af_afir.c
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 9484acbbd7..47b7b06d28 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -31,6 +31,7 @@ AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
>  CHECKASMOBJS-$(CONFIG_AVCODEC)  += $(AVCODECOBJS-yes)
>
>  # libavfilter tests
> +AVFILTEROBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
>  AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
>  AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
>  AVFILTEROBJS-$(CONFIG_HFLIP_FILTER)  += vf_hflip.o
> diff --git a/tests/checkasm/af_afir.c b/tests/checkasm/af_afir.c
> new file mode 100644
> index 00..54e2f68d6c
> --- /dev/null
> +++ b/tests/checkasm/af_afir.c
> @@ -0,0 +1,83 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include "config.h"
> +
> +#include 
> +#include 
> +
> +#include "libavfilter/af_afir.h"
> +#include "libavutil/internal.h"
> +#include "checkasm.h"
> +
> +#define LEN 256
> +
> +#define randomize_buffer(buf) \
> +do {  \
> +int i;\
> +double bmg[2], stddev = 10.0, mean = 0.0; \
> +  \
> +for (i = 0; i < LEN*2+8; i += 2) {\
> +av_bmg_get(_lfg, bmg);   \
> +buf[i] = bmg[0] * stddev + mean;  \
> +buf[i + 1] = bmg[1] * stddev + mean;  \
> +} \
> +} while(0);
> +
> +static void test_fcmul_add(const float *src0, const float *src1, const
> float *src2)
> +{
> +LOCAL_ALIGNED_32(float, cdst, [LEN*2+8]);
> +LOCAL_ALIGNED_32(float, odst, [LEN*2+8]);
> +int i;
> +
> +declare_func(void, float *sum, const float *t, const float *c,
> + ptrdiff_t len);
> +
> +memcpy(cdst, src0, (LEN*2+8) * sizeof(float));
> +memcpy(odst, src0, (LEN*2+8) * sizeof(float));
> +call_ref(cdst, src1, src2, LEN);
> +call_new(odst, src1, src2, LEN);
> +for (i = 0; i <= LEN*2; i++) {
> +if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
> +fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
> +i, cdst[i], odst[i], cdst[i] - odst[i]);
> +fail();
> +break;
> +}
> +}
> +memcpy(odst, src0, (LEN*2+8) * sizeof(float));
> +bench_new(odst, src1, src2, LEN);
> +}
> +
> +void checkasm_check_afir(void)
> +{
> +LOCAL_ALIGNED_32(float, src0, [LEN*2+8]);
> +LOCAL_ALIGNED_32(float, src1, [LEN*2+8]);
> +LOCAL_ALIGNED_32(float, src2, [LEN*2+8]);
> +AudioFIRDSPContext fir = { 0 };
> +
> +ff_afir_init();
> +
> +randomize_buffer(src0);
> +randomize_buffer(src1);
> +randomize_buffer(src2);
> +
> +if (check_func(fir.fcmul_add, "fcmul_add"))
> +test_fcmul_add(src0, src1, src2);
> +report("fcmul_add");
> +}
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 721a0912fb..c3f5160132 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -150,6 +150,9 @@ static const struct {
>  #endif
>  #endif
>  #if CONFIG_AVFILTER
> +#if CONFIG_AFIR_FILTER
> +{ "af_afir", checkasm_check_afir },
> +#endif
>  #if CONFIG_BLEND_FILTER
>  { "vf_blend", checkasm_check_blend },
>  #endif
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index c45cfb46f8..9e8e879fd3 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -40,6 +40,7 @@
>  #include "libavutil/timer.h"
>
>  void checkasm_check_aacpsdsp(void);
> +void checkasm_check_afir(void);
>  void checkasm_check_alacdsp(void);
>  void checkasm_check_audiodsp(void);
>  void checkasm_check_blend(void);
> diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
> index a722b4a917..d59e9d293a 100644
> ---

Re: [FFmpeg-devel] [PATCH 4/4] x86/af_afir: add ff_fcmul_add_avx()

2019-01-03 Thread Paul B Mahol 
On 1/3/19, James Almer  wrote:
> fcmul_add_c: 1228.8
> fcmul_add_sse3: 334.3
> fcmul_add_avx: 186.3
>
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/af_afir.asm| 8 +++-
>  libavfilter/x86/af_afir_init.c | 5 +
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
> index fcc1f426db..8054ac5f10 100644
> --- a/libavfilter/x86/af_afir.asm
> +++ b/libavfilter/x86/af_afir.asm
> @@ -27,7 +27,7 @@ SECTION .text
>  ; void ff_fcmul_add(float *sum, const float *t, const float *c, int len)
> ;--
>
> -INIT_XMM sse3
> +%macro FCMUL_ADD 0
>  cglobal fcmul_add, 4,4,6, sum, t, c, len
>  shl   lend, 3
>  add tq, lenq
> @@ -61,3 +61,9 @@ ALIGN 16
>  addss xm0, [sumq + lenq]
>  movss [sumq + lenq], xm0
>  RET
> +%endmacro
> +
> +INIT_XMM sse3
> +FCMUL_ADD
> +INIT_YMM avx
> +FCMUL_ADD
> diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
> index 29e6f976b2..c37212c381 100644
> --- a/libavfilter/x86/af_afir_init.c
> +++ b/libavfilter/x86/af_afir_init.c
> @@ -24,6 +24,8 @@
>
>  void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
> ptrdiff_t len);
> +void ff_fcmul_add_avx(float *sum, const float *t, const float *c,
> +  ptrdiff_t len);
>
>  av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
>  {
> @@ -32,4 +34,7 @@ av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
>  if (EXTERNAL_SSE3(cpu_flags)) {
>  s->fcmul_add = ff_fcmul_add_sse3;
>  }
> +if (EXTERNAL_AVX_FAST(cpu_flags)) {
> +s->fcmul_add = ff_fcmul_add_avx;
> +}
>  }
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

OK

Also write CPU on which you tested it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avfilter/af_afir: split off fcmul_add into a DSP context

2019-01-03 Thread Paul B Mahol 
On 1/3/19, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/af_afir.c  | 15 ++-
>  libavfilter/af_afir.h  | 12 +---
>  libavfilter/x86/af_afir_init.c |  2 +-
>  3 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
> index c4baf63c02..c755dc1f6f 100644
> --- a/libavfilter/af_afir.c
> +++ b/libavfilter/af_afir.c
> @@ -103,7 +103,7 @@ static int fir_quantum(AVFilterContext *ctx, AVFrame
> *out, int ch, int offset)
>  const float *block = (const float
> *)seg->block->extended_data[ch] + i * seg->block_size;
>  const FFTComplex *coeff = (const FFTComplex
> *)seg->coeff->extended_data[ch * !s->one2many] + coffset;
>
> -s->fcmul_add(sum, block, (const float *)coeff, seg->part_size);
> +s->afirdsp.fcmul_add(sum, block, (const float *)coeff,
> seg->part_size);
>
>  if (j == 0)
>  j = seg->nb_partitions;
> @@ -753,6 +753,14 @@ static int config_video(AVFilterLink *outlink)
>  return 0;
>  }
>
> +void ff_afir_init(AudioFIRDSPContext *dsp)
> +{
> +dsp->fcmul_add = fcmul_add_c;
> +
> +if (ARCH_X86)
> +ff_afir_init_x86(dsp);
> +}
> +
>  static av_cold int init(AVFilterContext *ctx)
>  {
>  AudioFIRContext *s = ctx->priv;
> @@ -792,14 +800,11 @@ static av_cold int init(AVFilterContext *ctx)
>  }
>  }
>
> -s->fcmul_add = fcmul_add_c;
> -
>  s->fdsp = avpriv_float_dsp_alloc(0);
>  if (!s->fdsp)
>  return AVERROR(ENOMEM);
>
> -if (ARCH_X86)
> -ff_afir_init_x86(s);
> +ff_afir_init(>afirdsp);
>
>  return 0;
>  }
> diff --git a/libavfilter/af_afir.h b/libavfilter/af_afir.h
> index f9bec54b8c..f665c0ef80 100644
> --- a/libavfilter/af_afir.h
> +++ b/libavfilter/af_afir.h
> @@ -53,6 +53,11 @@ typedef struct AudioFIRSegment {
>  RDFTContext **rdft, **irdft;
>  } AudioFIRSegment;
>
> +typedef struct AudioFIRDSPContext {
> +void (*fcmul_add)(float *sum, const float *t, const float *c,
> +  ptrdiff_t len);
> +} AudioFIRDSPContext;
> +
>  typedef struct AudioFIRContext {
>  const AVClass *class;
>
> @@ -87,11 +92,12 @@ typedef struct AudioFIRContext {
>  int min_part_size;
>  int64_t pts;
>
> +AudioFIRDSPContext afirdsp;
>  AVFloatDSPContext *fdsp;
> -void (*fcmul_add)(float *sum, const float *t, const float *c,
> -  ptrdiff_t len);
> +
>  } AudioFIRContext;
>
> -void ff_afir_init_x86(AudioFIRContext *s);
> +void ff_afir_init(AudioFIRDSPContext *s);
> +void ff_afir_init_x86(AudioFIRDSPContext *s);
>
>  #endif /* AVFILTER_AFIR_H */
> diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
> index 6a652b9b83..29e6f976b2 100644
> --- a/libavfilter/x86/af_afir_init.c
> +++ b/libavfilter/x86/af_afir_init.c
> @@ -25,7 +25,7 @@
>  void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
> ptrdiff_t len);
>
> -av_cold void ff_afir_init_x86(AudioFIRContext *s)
> +av_cold void ff_afir_init_x86(AudioFIRDSPContext *s)
>  {
>  int cpu_flags = av_get_cpu_flags();
>
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH V5 2/2] avcodec/libx264: add support for ROI-based encoding

2019-01-03 Thread Guo, Yejun 
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.

Signed-off-by: Guo, Yejun 
---
 libavcodec/libx264.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a68d0a7..5085d13 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -40,6 +40,10 @@
 #include 
 #include 
 
+// from x264.h, for quant_offsets, Macroblocks are 16x16
+// blocks of pixels (with respect to the luma plane)
+#define MB_SIZE 16
+
 typedef struct X264Context {
 AVClass*class;
 x264_param_tparams;
@@ -282,6 +286,7 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 x264_picture_t pic_out = {0};
 int pict_type;
 int64_t *out_opaque;
+AVFrameSideData *sd;
 
 x264_picture_init( >pic );
 x4->pic.img.i_csp   = x4->params.i_csp;
@@ -345,6 +350,50 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 }
 }
 }
+
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
+if (sd) {
+if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
+av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must be 
enabled to use ROI encoding, skipping ROI.\n");
+} else {
+if (frame->interlaced_frame == 0) {
+size_t mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
+size_t mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
+size_t nb_rois;
+AVRegionOfInterest* roi;
+float* qoffsets;
+qoffsets = (float*)av_mallocz_array(mbx * mby, 
sizeof(*qoffsets));
+if (!qoffsets)
+return AVERROR(ENOMEM);
+
+nb_rois = sd->size / sizeof(AVRegionOfInterest);
+roi = (AVRegionOfInterest*)sd->data;
+for (size_t count = 0; count < nb_rois; count++) {
+int starty = FFMIN(mby, roi->top / MB_SIZE);
+int endy = FFMIN(mby, (roi->bottom + MB_SIZE - 1)/ 
MB_SIZE);
+int startx = FFMIN(mbx, roi->left / MB_SIZE);
+int endx = FFMIN(mbx, (roi->right + MB_SIZE - 1)/ 
MB_SIZE);
+for (int y = starty; y < endy; y++) {
+for (int x = startx; x < endx; x++) {
+qoffsets[x + y*mbx] = roi->qoffset;
+}
+}
+
+if (roi->self_size == 0) {
+av_free(qoffsets);
+av_log(ctx, AV_LOG_ERROR, 
"AVRegionOfInterest.self_size should be set to sizeof(AVRegionOfInterest).\n");
+return AVERROR(EINVAL);
+}
+roi = (AVRegionOfInterest*)((char*)roi + 
roi->self_size);
+}
+
+x4->pic.prop.quant_offsets = qoffsets;
+x4->pic.prop.quant_offsets_free = av_free;
+} else {
+av_log(ctx, AV_LOG_WARNING, "interlaced_frame not 
supported for ROI encoding yet, skipping ROI.\n");
+}
+}
+}
 }
 
 do {
-- 
2.7.4

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

[FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

2019-01-03 Thread Guo, Yejun 
The encoders such as libx264 support different QPs offset for different MBs,
it makes possible for ROI-based encoding. It makes sense to add support
within ffmpeg to generate/accept ROI infos and pass into encoders.

Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
generates ROI info for that frame, and the encoder finally does the
ROI-based encoding.

The ROI info is maintained as side data of AVFrame.

Signed-off-by: Guo, Yejun 
---
 libavutil/frame.c   |  1 +
 libavutil/frame.h   | 29 +
 libavutil/version.h |  2 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 34a6210..dcf1fc3 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type)
 case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table data";
 #endif
 case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata 
SMPTE2094-40 (HDR10+)";
+case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
 }
 return NULL;
 }
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 582ac47..7887391 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -173,6 +173,12 @@ enum AVFrameSideDataType {
  * volume transform - application 4 of SMPTE 2094-40:2016 standard.
  */
 AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
+
+/**
+ * Regions Of Interest, the data is an array of AVRegionOfInterest type, 
the number of
+ * array element is implied by AVFrameSideData.size / 
AVRegionOfInterest.self_size.
+ */
+AV_FRAME_DATA_REGIONS_OF_INTEREST,
 };
 
 enum AVActiveFormatDescription {
@@ -201,6 +207,29 @@ typedef struct AVFrameSideData {
 } AVFrameSideData;
 
 /**
+ * Structure to hold Region Of Interest.
+ *
+ * self_size specifies the size of this data structure. This value
+ * should be set to sizeof(AVRegionOfInterest).
+ *
+ * Number of pixels to discard from the top/bottom/left/right border of
+ * the frame to obtain the region of interest of the frame.
+ * They are encoder dependent and will be extended internally
+ * if the codec requires an alignment.
+ * If the regions overlap, the last value in the list will be used.
+ *
+ * qoffset is quant offset, it is encoder dependent.
+ */
+typedef struct AVRegionOfInterest {
+size_t self_size;
+size_t top;
+size_t bottom;
+size_t left;
+size_t right;
+float qoffset;
+} AVRegionOfInterest;
+
+/**
  * This structure describes decoded (raw) audio or video data.
  *
  * AVFrame must be allocated using av_frame_alloc(). Note that this only
diff --git a/libavutil/version.h b/libavutil/version.h
index f997615..1fcdea9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  25
+#define LIBAVUTIL_VERSION_MINOR  26
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH V3] avfilter: Add tonemap vaapi filter

2019-01-03 Thread Zhou, Zachary 


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, December 31, 2018 3:39 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3] avfilter: Add tonemap vaapi filter
> 
> On 29/12/2018 07:02, Zachary Zhou wrote:
> > It supports ICL platform.
> 
> When will this hardware be available?

currently, I am not sure about it, but I will keep watching it.

> 
> Is this a new fixed-function feature, or will it be available on current 
> hardware
> as well?

As I know, different platform may use different HW feature, some platform uses 
EUs, some use VEBOX.
The driver team may make this filter works on other platform in future, like 
KBL, CFL etc.

> 
> > H2H (HDR to HDR): P010 -> RGB10
> > H2S (HDR to SDR): P010 -> RGB8
> >
> > libva commit for HDR10
> >
> https://github.com/intel/libva/commit/cf11abe5e1b9c93ee75cf97407695716
> > 2c1605b9
> >
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure  |   2 +
> >  doc/filters.texi   |  63 
> >  libavfilter/Makefile   |   1 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/vaapi_vpp.c|  29 ++
> >  libavfilter/vaapi_vpp.h|   8 +
> >  libavfilter/vf_tonemap_vaapi.c | 542
> +
> >  libavutil/hwcontext_vaapi.c|   3 +
> >  8 files changed, 649 insertions(+)
> >  create mode 100644 libavfilter/vf_tonemap_vaapi.c
> >
> > diff --git a/configure b/configure
> > index be49c19b88..baf70d03fc 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3480,6 +3480,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
> >  tinterlace_pad_test_deps="tinterlace_filter"
> >  tonemap_filter_deps="const_nan"
> >  tonemap_opencl_filter_deps="opencl const_nan"
> > +tonemap_vaapi_filter_deps="vaapi
> VAProcFilterParameterBufferHDRToneMapping"
> >  transpose_opencl_filter_deps="opencl"
> >  unsharp_opencl_filter_deps="opencl"
> >  uspp_filter_deps="gpl avcodec"
> > @@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h"
> > DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
> >
> >  check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> >  check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > +check_type "va/va.h va/va_vpp.h"
> "VAProcFilterParameterBufferHDRToneMapping"
> >  check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> >  check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> >  check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> > diff --git a/doc/filters.texi b/doc/filters.texi index
> > ac4c9b44d8..9ed53a1008 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -19130,6 +19130,69 @@ Convert HDR(PQ/HLG) video to
> > bt2020-transfer-characteristic p010 format using li  @end example
> > @end itemize
> >
> > +@section tonemap_vappi
> > +
> > +Perform HDR(High Dynamic Range) to HDR and HDR to SDR conversion
> with tone-mapping.
> > +
> > +It accepts the following parameters:
> > +
> > +@table @option
> > +@item type
> > +Specify the tone-mapping operator to be used.
> > +
> > +Possible values are:
> > +@table @var
> > +@item h2h
> > +Perform H2H(HDR to HDR), convert from p010 to rgb10 @item h2s Perform
> > +H2S(HDR to SDR), convert from p010 to rgb8 @end table
> 
> What are RGB10 and RGB8?

RGB10 is R10G10B10A2
RGB8 is ARGB

I will add more to the document.

> 
> > +
> > +@item display
> > +Set mastering display metadata for H2H
> > +
> > +Can assume the following values:
> > +@table @var
> > +@item G
> > +Green primary G(x|y)
> > +@item B
> > +Blue primary B(x|y)
> > +@item R
> > +Red primary R(x|y)
> > +@item WP
> > +White point WP(x|y)
> > +@item L
> > +Display mastering luminance L(max|min) @end table
> > +
> > +@item light
> > +Set content light level for H2H
> > +
> > +Can assume the following values:
> > +@table @var
> > +@item CLL
> > +Max content light level
> > +@item FALL
> > +Max average light level per frame
> > +@end table
> 
> What units are all of these values in?

I will add units to document.

> 
> > +
> > +@end table
> > +
> > +@subsection Example
> > +
> > +@itemize
> > +@item
> > +Convert HDR video to HDR video from p010 format to rgb10 format.
> > +@example
> > +-i INPUT -vf
> >
> +"tonemap_vaapi=h2h:display=G(13250|34500)B(7500|3000)R(34000|16000)
> WP
> > +(15635|16450)L(2000|2000):light=CLL(1)FALL(1000)" OUTPUT @end
> > +example @item Convert HDR video to SDR video from p010 format to rgb8
> format.
> > +@example
> > +-i INPUT -vf "tonemap_vaapi=h2s" OUTPUT @end example @end itemize
> > +
> >  @section unsharp_opencl
> >
> >  Sharpen or blur the input video.
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > 6e2658186d..f6894209d1 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -390,6 +390,7 @@ OBJS-$(CONFIG_TMIX_FILTER)   += vf_mix.o
> framesync.o
> >  OBJS-$(CONFIG_TONEMAP_FILTER)

Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and bump version

2019-01-03 Thread Guo, Yejun 


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Thursday, January 03, 2019 6:07 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V4 1/2] avutil: add ROI data struct and
> bump version
> 
> On Wed, Jan 02, 2019 at 09:50:24PM +0100, Vittorio Giovara wrote:
> > On Wed, Jan 2, 2019 at 6:45 PM James Almer  wrote:
> >
> > > On 1/2/2019 2:18 PM, Vittorio Giovara wrote:
> > > > On Wed, Jan 2, 2019 at 4:13 PM Vittorio Giovara <
> > > vittorio.giov...@gmail.com>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Fri, Dec 28, 2018 at 3:17 AM Guo, Yejun 
> wrote:
> > > >>
> > > >
> > > > AVRegionOfInterest {
> > > >  size_t top/left/right/bottom
> > > > }
> > > >
> > > > AVRegionOfInterestSet {
> > > >  int rois_nb;
> > > >  AVRegionOfInterest *rois;
> > >
> > > This will go south as soon as you start copying, referencing and
> > > freeing frames and/or frame side data.
> > >
> > > All side data types need to be a contiguous array of bytes in memory
> > > with no pointers.
> > >
> >
> > Hmm you're right, but embedding an entire array is pretty bad too,
> > especially because it locks the struct size...
> > Do you have any alternative ideas for this?
> 
> the array element size could be added in addition to the number of entries.
> that way elements can be added after the array and also the individual
> elements can be extended
> 
> int rois_nb;
> int roi_size;
> AVRegionOfInterest rois[rois_nb];

nice direction, and I just have a little adjustment.

From user's perspective, the buffer size in this method is not straightforward 
when it calls
av_frame_new_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST, size) to 
prepare for ROI buffer.

the size calculation looks like:
size =  sizeof(rois_nb) + sizeof(roi_size) + rois_nb * 
sizeof(AVRegionOfInterest).

and, the ROI array starts from:  AVFrameSideData.data + sizeof(rois_nb) + 
sizeof(roi_size).


My change is to move roi_size into struct AVRegionOfInterest as self_size, 
and remove rois_nb (can be calculated with AVFrameSideData.size / 
AVRegionOfInterest.self_size).

From user's perspective, the code looks like:
size_t nb_rois = 2;
AVFrameSideData *sd = av_frame_new_side_data(in, 
AV_FRAME_DATA_REGIONS_OF_INTEREST, nb_rois * sizeof(AVRegionOfInterest));
if (!sd) {
av_frame_free();
return AVERROR(ENOMEM);
}
AVRegionOfInterest* rois = (AVRegionOfInterest*)sd->data;
rois[0].self_size = sizeof(*rois);
rois[0].top = 0;
rois[0].left = 0;
rois[0].bottom = in->height;
rois[0].right = in->width/4;
rois[0].qoffset = -15;
rois[1].self_size = sizeof(*rois);
rois[1].top = 0;
rois[1].left = in->width*3/4;
rois[1].bottom = in->height;
rois[1].right = in->width;
rois[1].qoffset = -15;

The advantage is the code is straightforward.
The disadvantage is that we have to always do 'rois[i].self_size = 
sizeof(*rois);' and there is a little memory waste. 

I personally prefer this method, will send out the new patch.

> 
> Alternativly some "int version" could be used but we dont use that style
> elsewhere
> 
> 
> [...]
> --
> Michael GnuPG fingerprint:
> 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible memory leaks in dshow capture

2019-01-03 Thread Oliver Collyer 


> On 2 Jan 2019, at 17:52, Oliver Collyer  wrote:
> 
> 
> 
>> On 2 Jan 2019, at 11:30, Oliver Collyer  wrote:
>> 
>> 
>> 
>>> On 1 Jan 2019, at 23:58, James Almer  wrote:
>>> 
>>> On 1/1/2019 5:01 PM, Oliver Collyer wrote:
 -- Block 26224 at 0x74240F70: 151 bytes --
 Leak Hash: 0x357CD5AF, Count: 1, Total 151 bytes
 Call Stack (TID 55752):
  ucrtbased.dll!aligned_malloc()
  c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
 + 0x10 bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
 emu-server.exe!libAVPin_Setup() + 0xA bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
 emu-server.exe!libAVPin_Create() + 0x9B bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
 emu-server.exe!libAVFilter_Setup() + 0xA bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
 emu-server.exe!libAVFilter_Create() + 0xA8 bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809): 
 emu-server.exe!dshow_open_device() + 0x1C bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (1150): 
 emu-server.exe!dshow_read_header() + 0x18 bytes
  c:\ffmpeg\source\ffmpeg\libavformat\utils.c (631): 
 emu-server.exe!avformat_open_input() + 0x11 bytes
  c:\users\oliver\perforce\non-si\emu\shared\dsdevice_streaming_session.cpp 
 (1142): 
 emu-server.exe!DSDEVICE_STREAMING_SESSION::CAPTURE_THREAD::thread_run() + 
 0x23 bytes
  c:\users\oliver\perforce\non-si\emu\shared\thread_base.cpp (241): 
 emu-server.exe!THREAD_BASE::thread_func() + 0xE bytes
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
 (16707566): emu-server.exe!std::_Invoker_functor::_Call>>> (__cdecl*)(void *),void *>() + 0x2B bytes
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\type_traits 
 (16707566): emu-server.exe!std::invoke() + 
 0x31 bytes
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (239): 
 emu-server.exe!std::_LaunchPad>>> (__cdecl*)(void *),void *>,std::default_delete>>> (__cdecl*)(void *),void *> > > >::_Execute<0,1>()
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (245): 
 emu-server.exe!std::_LaunchPad>>> (__cdecl*)(void *),void *>,std::default_delete>>> (__cdecl*)(void *),void *> > > >::_Run() + 0x19 bytes
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (231): 
 emu-server.exe!std::_LaunchPad>>> (__cdecl*)(void *),void *>,std::default_delete>>> (__cdecl*)(void *),void *> > > >::_Go()
  c:\program files (x86)\microsoft visual 
 studio\2017\community\vc\tools\msvc\14.16.27023\include\thr\xthread (209): 
 emu-server.exe!std::_Pad::_Call_func()
  ucrtbased.dll!register_onexit_function() + 0x4A8 bytes
  ucrtbased.dll!register_onexit_function() + 0xE1 bytes
  KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
  ntdll.dll!RtlUserThreadStart() + 0x21 bytes
 Data:
  70 0F 24 7446 02 00 00ED ED ED EDED ED ED ED p.$tF... 
 
  36 DE C8 49F7 7F 00 0068 F0 CA 49F7 7F 00 00 6..I 
 h..I
  8D 99 CA 49F7 7F 00 001F D6 C9 49F7 7F 00 00 ...I 
 ...I
  C9 9E CA 49F7 7F 00 00B7 FD C8 49F7 7F 00 00 ...I 
 ...I
  22 EC C9 49F7 7F 00 007E E1 C8 49F7 7F 00 00 "..I 
 ~..I
  3B 82 CA 49F7 7F 00 00CD CD CD CDCD CD CD CD ;..I 
 
  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
 
  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
 
  CD CD CD CDCD CD CD CDCD CD CD CDCD CD CD CD  
 
  CD CD CD CDCD CD CD   
 
 
 
 -- Block 26879 at 0x74242E10: 151 bytes --
 Leak Hash: 0xA886255F, Count: 1, Total 151 bytes
 Call Stack (TID 55752):
  ucrtbased.dll!aligned_malloc()
  c:\ffmpeg\source\ffmpeg\libavutil\mem.c (90): emu-server.exe!av_malloc() 
 + 0x10 bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (213): 
 emu-server.exe!libAVPin_Setup() + 0xA bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_pin.c (252): 
 emu-server.exe!libAVPin_Create() + 0x9B bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (184): 
 emu-server.exe!libAVFilter_Setup() + 0xA bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow_filter.c (198): 
 emu-server.exe!libAVFilter_Create() + 0xA8 bytes
  c:\ffmpeg\source\ffmpeg\libavdevice\dshow.c (809):