Re: [FFmpeg-devel] [PATCH] avfilter: add limitdiff video filter

[Thilo Borgmann]

On 7 Oct 2021, at 14:13, Paul B Mahol wrote:


Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_limitdiff.c | 370 
+

 3 files changed, 372 insertions(+)
 create mode 100644 libavfilter/vf_limitdiff.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index db9a67b92e..fca1665eac 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -326,6 +326,7 @@ OBJS-$(CONFIG_LATENCY_FILTER)+= 
f_latency.o

 OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
 OBJS-$(CONFIG_LENSFUN_FILTER)+= vf_lensfun.o
 OBJS-$(CONFIG_LIBVMAF_FILTER)+= vf_libvmaf.o 
framesync.o

+OBJS-$(CONFIG_LIMITDIFF_FILTER)  += vf_limitdiff.o


Shouldn’t this also depend on framesync.o?

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

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

Re: [FFmpeg-devel] ARM Hardware Request

[Thilo Borgmann]

Hi,

On 8 Oct 2021, at 1:21, J. Dekker wrote:


Hi,

I'm writing ARM64 ASM and testing on Apple M1 and Graviton2 N1 
devices. This, however, is not a good spread of micro-architectures 
among commonly used ARM64 devices. Additional micro-architectures 
which I would like to test are 'High Efficiency' A53 and A55; 'high 
performance' A72, A73, and A77, and 'Prime' X1.


I’m in favor of buying some ARM hardware for that as well as for FATE 
maybe.



I've identified the following devices along with the 
micro-architectures they use and a price estimate:


- NanoPi M4B, Rockchip RK3399 (A53/A72) - 99 EUR
  & Extras (~23 EUR)
- ODROID-N2+, Amlogic S922x (A53/A73) - 71 EUR


The above should be totally ok,


- OnePlus 9, Snapdragon 888 (A55/A77/X1) - 799 EUR


for this well it’s not cheap, maybe someone has an alternative idea or 
even some hardware to donate that covers some of the cores?



As a note, the cheapest Snapdragon 888 devices were phones rather than 
development boards (with the 'official' development board being more 
than double the example given here). I don't think the OnePlus is the 
cheapest, but seems like it would be the most reasonable to test 
(unlocked boot-loader, etc).


I am preemptively requesting reimbursement for these devices, 
suggestions welcome.


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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add positive video filter

[Thilo Borgmann]

Am 31.10.21 um 10:29 schrieb Paul B Mahol:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_positive.c | 337 ++
>  3 files changed, 339 insertions(+)
>  create mode 100644 libavfilter/vf_positive.c

Missing docs?

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

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

[FFmpeg-devel] [PATCH] lavf/mov: Always prefer tfdt over sidx

[Thilo Borgmann]

Hi,

this effectively reverts 071930de724166bfb90fc6d368c748771188fd94 and fixes the 
underlying issue by always preferring TFDT.

Furthermore, the current solution fails if the -use_tfdt flag is given but no 
TFDT box is found in the stream.

-Thilo
From 1ae6d7f213d0ba2360b9b1cf7fde2e3d0adde70d Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 2 Nov 2021 22:49:37 +0100
Subject: [PATCH] lavf/mov: Always prefer tfdt over sidx

---
 doc/demuxers.texi  |  6 --
 libavformat/isom.h |  1 -
 libavformat/mov.c  | 12 +---
 3 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 1c9575b2e8..fa669f88fe 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -689,12 +689,6 @@ Set mfra timestamps as PTS
 Don't use mfra box to set timestamps
 @end table
 
-@item use_tfdt
-For fragmented input, set fragment's starting timestamp to 
@code{baseMediaDecodeTime} from the @code{tfdt} box.
-Default is disabled, which will preferentially use the 
@code{earliest_presentation_time} from the @code{sidx} box.
-In either case, the timestamp from the @code{mfra} box will be used if it's 
available and @code{use_mfra_for} is
-set to pts or dts.
-
 @item export_all
 Export unrecognized boxes within the @var{udta} box as metadata entries. The 
first four
 characters of the box type are set as the key. Default is false.
diff --git a/libavformat/isom.h b/libavformat/isom.h
index f3c18c95be..55e5fa7b23 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -279,7 +279,6 @@ typedef struct MOVContext {
 int moov_retry;
 int use_mfra_for;
 int has_looked_for_mfra;
-int use_tfdt;
 MOVFragmentIndex frag_index;
 int atom_depth;
 unsigned int aax_mode;  ///< 'aax' file has been detected
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3fcb1dc908..00205bb1be 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4828,16 +4828,16 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 dts = frag_stream_info->first_tfra_pts;
 av_log(c->fc, AV_LOG_DEBUG, "found mfra time %"PRId64
 ", using it for dts\n", pts);
-} else if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE && 
!c->use_tfdt) {
+} else if (frag_stream_info->tfdt_dts != AV_NOPTS_VALUE) {
+dts = frag_stream_info->tfdt_dts - sc->time_offset;
+av_log(c->fc, AV_LOG_DEBUG, "found tfdt time %"PRId64
+", using it for dts\n", dts);
+} else if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE) {
 // FIXME: sidx earliest_presentation_time is *PTS*, s.b.
 // pts = frag_stream_info->sidx_pts;
 dts = frag_stream_info->sidx_pts - sc->time_offset;
 av_log(c->fc, AV_LOG_DEBUG, "found sidx time %"PRId64
 ", using it for pts\n", pts);
-} else if (frag_stream_info->tfdt_dts != AV_NOPTS_VALUE) {
-dts = frag_stream_info->tfdt_dts - sc->time_offset;
-av_log(c->fc, AV_LOG_DEBUG, "found tfdt time %"PRId64
-", using it for dts\n", dts);
 } else {
 dts = sc->track_end - sc->time_offset;
 av_log(c->fc, AV_LOG_DEBUG, "found track end time %"PRId64
@@ -8533,8 +8533,6 @@ static const AVOption mov_options[] = {
 FLAGS, "use_mfra_for" },
 {"pts", "pts", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_MFRA_PTS}, 0, 0,
 FLAGS, "use_mfra_for" },
-{"use_tfdt", "use tfdt for fragment timestamps", OFFSET(use_tfdt), 
AV_OPT_TYPE_BOOL, {.i64 = 0},
-0, 1, FLAGS},
 { "export_all", "Export unrecognized metadata entries", OFFSET(export_all),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS },
 { "export_xmp", "Export full XMP metadata", OFFSET(export_xmp),
-- 
2.20.1 (Apple Git-117)

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

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: Always prefer tfdt over sidx

[Thilo Borgmann]

Am 03.11.21 um 17:41 schrieb Gyan Doshi:
> 
> 
> On 2021-11-03 03:16 pm, Thilo Borgmann wrote:
>> Hi,
>>
>> this effectively reverts 071930de724166bfb90fc6d368c748771188fd94 and fixes 
>> the underlying issue by always preferring TFDT.
>>
>> Furthermore, the current solution fails if the -use_tfdt flag is given but 
>> no TFDT box is found in the stream.
> 
> Thanks for the heads-up.
> 
> The original impetus for my patch was a client's sample file which had 
> rubbish sidx values but sane tfdt ones, likely due to a buggy muxer.
> The motivation for an option was to give the user control.
> 
> I think hardcoding a reversed preference can lead to the same impasse. How 
> about change the default value of use_tfdt and check for tfdt presence when 
> enabled?

Changed the default to use TFDT and add warnings about fallback to SIDX or TFDT 
where useful.
Looks better?

Thanks,
Thilo
From 435196bbb406ed7d4311f327d96664cb140af048 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 4 Nov 2021 12:00:07 +0100
Subject: [PATCH] lavf/mov: Change default to prefer TFDT time and allow for
 fallback to SIDX or TFDT

---
 doc/demuxers.texi |  2 +-
 libavformat/mov.c | 42 --
 2 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 1c9575b2e8..cab8a7072c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -691,7 +691,7 @@ Don't use mfra box to set timestamps
 
 @item use_tfdt
 For fragmented input, set fragment's starting timestamp to 
@code{baseMediaDecodeTime} from the @code{tfdt} box.
-Default is disabled, which will preferentially use the 
@code{earliest_presentation_time} from the @code{sidx} box.
+Default is enabled, which will prefer to use the @code{tfdt} box to set DTS. 
Disable to use the @code{earliest_presentation_time} from the @code{sidx} box.
 In either case, the timestamp from the @code{mfra} box will be used if it's 
available and @code{use_mfra_for} is
 set to pts or dts.
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3fcb1dc908..8a910a3165 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4828,20 +4828,34 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 dts = frag_stream_info->first_tfra_pts;
 av_log(c->fc, AV_LOG_DEBUG, "found mfra time %"PRId64
 ", using it for dts\n", pts);
-} else if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE && 
!c->use_tfdt) {
-// FIXME: sidx earliest_presentation_time is *PTS*, s.b.
-// pts = frag_stream_info->sidx_pts;
-dts = frag_stream_info->sidx_pts - sc->time_offset;
-av_log(c->fc, AV_LOG_DEBUG, "found sidx time %"PRId64
-", using it for pts\n", pts);
-} else if (frag_stream_info->tfdt_dts != AV_NOPTS_VALUE) {
-dts = frag_stream_info->tfdt_dts - sc->time_offset;
-av_log(c->fc, AV_LOG_DEBUG, "found tfdt time %"PRId64
-", using it for dts\n", dts);
 } else {
-dts = sc->track_end - sc->time_offset;
-av_log(c->fc, AV_LOG_DEBUG, "found track end time %"PRId64
-", using it for dts\n", dts);
+int has_tfdt = frag_stream_info->tfdt_dts != AV_NOPTS_VALUE;
+int has_sidx = frag_stream_info->sidx_pts != AV_NOPTS_VALUE;
+int fallback_tfdt = !c->use_tfdt && !has_sidx && has_tfdt;
+int fallback_sidx =  c->use_tfdt && !has_tfdt && has_sidx;
+
+if (fallback_sidx) {
+av_log(c->fc, AV_LOG_DEBUG, "use_tfdt set but no tfdt found, 
using sidx instead\n");
+}
+if (fallback_tfdt) {
+av_log(c->fc, AV_LOG_DEBUG, "use_tfdt not set but no sidx 
found, using tfdt instead\n");
+}
+
+if (has_tfdt && c->use_tfdt || fallback_tfdt) {
+dts = frag_stream_info->tfdt_dts - sc->time_offset;
+av_log(c->fc, AV_LOG_DEBUG, "found tfdt time %"PRId64
+", using it for dts\n", dts);
+} else if (has_sidx && !c->use_tfdt || fallback_sidx) {
+// FIXME: sidx earliest_presentation_time is *PTS*, s.b.
+// pts = frag_stream_info->sidx_pts;
+dts = frag_stream_info->sidx_pts - sc->time_offset;
+av_log(c->fc, AV_LOG_DEBUG, "found sidx time %"PRId64
+", using it for pts\n", pts);
+} else {
+dts = sc->track_end - sc->time_offset;
+  

Re: [FFmpeg-devel] [PATCH] lavf/mov: Always prefer tfdt over sidx

[Thilo Borgmann]

Am 05.11.21 um 04:52 schrieb Gyan Doshi:
> 
> 
> On 2021-11-04 04:33 pm, Thilo Borgmann wrote:
>> Am 03.11.21 um 17:41 schrieb Gyan Doshi:
>>>
>>> On 2021-11-03 03:16 pm, Thilo Borgmann wrote:
>>>> Hi,
>>>>
>>>> this effectively reverts 071930de724166bfb90fc6d368c748771188fd94 and 
>>>> fixes the underlying issue by always preferring TFDT.
>>>>
>>>> Furthermore, the current solution fails if the -use_tfdt flag is given but 
>>>> no TFDT box is found in the stream.
>>> Thanks for the heads-up.
>>>
>>> The original impetus for my patch was a client's sample file which had 
>>> rubbish sidx values but sane tfdt ones, likely due to a buggy muxer.
>>> The motivation for an option was to give the user control.
>>>
>>> I think hardcoding a reversed preference can lead to the same impasse. How 
>>> about change the default value of use_tfdt and check for tfdt presence when 
>>> enabled?
>> Changed the default to use TFDT and add warnings about fallback to SIDX or 
>> TFDT where useful.
>> Looks better?
> 
> LGTM.

Pushed with updated reference for tests/ref/seek/extra-mp4.

Thanks!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] lafi/vf_edgedetect: Move some functions to lavu/imgutils

[Thilo Borgmann]

Hi,

shared code with vf_blurriness.c in patch 2/2.
RFC: is there a better place to put these?

-Thilo
From b4e3701b2ed034b8d60aeff5d5ed75e4d4332a9f Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 16 Nov 2021 13:35:02 +0100
Subject: [PATCH 1/2] lafi/vf_edgedetect: Move some functions to lavu/imgutils

---
 libavfilter/vf_edgedetect.c | 127 +---
 libavutil/imgutils.c| 120 ++
 libavutil/imgutils.h|  63 ++
 3 files changed, 186 insertions(+), 124 deletions(-)

diff --git a/libavfilter/vf_edgedetect.c b/libavfilter/vf_edgedetect.c
index 3eea34e325..9750ba5f98 100644
--- a/libavfilter/vf_edgedetect.c
+++ b/libavfilter/vf_edgedetect.c
@@ -188,127 +188,6 @@ static void gaussian_blur(AVFilterContext *ctx, int w, 
int h,
 memcpy(dst, src, w);
 }
 
-enum {
-DIRECTION_45UP,
-DIRECTION_45DOWN,
-DIRECTION_HORIZONTAL,
-DIRECTION_VERTICAL,
-};
-
-static int get_rounded_direction(int gx, int gy)
-{
-/* reference angles:
- *   tan( pi/8) = sqrt(2)-1
- *   tan(3pi/8) = sqrt(2)+1
- * Gy/Gx is the tangent of the angle (theta), so Gy/Gx is compared against
- * , or more simply Gy against *Gx
- *
- * Gx and Gy bounds = [-1020;1020], using 16-bit arithmetic:
- *   round((sqrt(2)-1) * (1<<16)) =  27146
- *   round((sqrt(2)+1) * (1<<16)) = 158218
- */
-if (gx) {
-int tanpi8gx, tan3pi8gx;
-
-if (gx < 0)
-gx = -gx, gy = -gy;
-gy *= (1 << 16);
-tanpi8gx  =  27146 * gx;
-tan3pi8gx = 158218 * gx;
-if (gy > -tan3pi8gx && gy < -tanpi8gx)  return DIRECTION_45UP;
-if (gy > -tanpi8gx  && gy <  tanpi8gx)  return DIRECTION_HORIZONTAL;
-if (gy >  tanpi8gx  && gy <  tan3pi8gx) return DIRECTION_45DOWN;
-}
-return DIRECTION_VERTICAL;
-}
-
-static void sobel(int w, int h,
-   uint16_t *dst, int dst_linesize,
- int8_t *dir, int dir_linesize,
-  const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-for (j = 1; j < h - 1; j++) {
-dst += dst_linesize;
-dir += dir_linesize;
-src += src_linesize;
-for (i = 1; i < w - 1; i++) {
-const int gx =
--1*src[-src_linesize + i-1] + 1*src[-src_linesize + i+1]
--2*src[i-1] + 2*src[i+1]
--1*src[ src_linesize + i-1] + 1*src[ src_linesize + i+1];
-const int gy =
--1*src[-src_linesize + i-1] + 1*src[ src_linesize + i-1]
--2*src[-src_linesize + i  ] + 2*src[ src_linesize + i  ]
--1*src[-src_linesize + i+1] + 1*src[ src_linesize + i+1];
-
-dst[i] = FFABS(gx) + FFABS(gy);
-dir[i] = get_rounded_direction(gx, gy);
-}
-}
-}
-
-static void non_maximum_suppression(int w, int h,
-  uint8_t  *dst, int dst_linesize,
-const  int8_t  *dir, int dir_linesize,
-const uint16_t *src, int src_linesize)
-{
-int i, j;
-
-#define COPY_MAXIMA(ay, ax, by, bx) do {\
-if (src[i] > src[(ay)*src_linesize + i+(ax)] && \
-src[i] > src[(by)*src_linesize + i+(bx)])   \
-dst[i] = av_clip_uint8(src[i]); \
-} while (0)
-
-for (j = 1; j < h - 1; j++) {
-dst += dst_linesize;
-dir += dir_linesize;
-src += src_linesize;
-for (i = 1; i < w - 1; i++) {
-switch (dir[i]) {
-case DIRECTION_45UP:COPY_MAXIMA( 1, -1, -1,  1); break;
-case DIRECTION_45DOWN:  COPY_MAXIMA(-1, -1,  1,  1); break;
-case DIRECTION_HORIZONTAL:  COPY_MAXIMA( 0, -1,  0,  1); break;
-case DIRECTION_VERTICAL:COPY_MAXIMA(-1,  0,  1,  0); break;
-}
-}
-}
-}
-
-static void double_threshold(int low, int high, int w, int h,
-   uint8_t *dst, int dst_linesize,
- const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-for (j = 0; j < h; j++) {
-for (i = 0; i < w; i++) {
-if (src[i] > high) {
-dst[i] = src[i];
-continue;
-}
-
-if (!(!i || i == w - 1 || !j || j == h - 1) &&
-src[i] > low &&
-(src[-src_linesize + i-1] > high ||
- src[-src_linesize + i  ] > high ||
- src[-src_linesize + i+1] > high ||
- src[i-1] > high ||
- src[i+1] > high ||
- src[ src_linesize + i-1] > high ||
- src[ src_linesize + i  ] > h

[FFmpeg-devel] [PATCH 2/2] lavfi: Add blurriness filter

[Thilo Borgmann]

Hi,

RFC: gaussian_blur() has fixed 5x5 kernel with sigma 1.4. Should this also go 
into a common place with patch 1/2 or somewhere else?

-Thilo
From cb9f4caee52f74942606c733308f11e51bbca649 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 16 Nov 2021 13:37:58 +0100
Subject: [PATCH 2/2] lavfi: Add blurriness filter

---
 doc/filters.texi|  55 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_blurriness.c | 435 
 4 files changed, 492 insertions(+)
 create mode 100644 libavfilter/vf_blurriness.c

diff --git a/doc/filters.texi b/doc/filters.texi
index b4f888c14d..d066041e21 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7712,6 +7712,61 @@ tblend=all_mode=grainextract
 @subsection Commands
 This filter supports same @ref{commands} as options.
 
+@anchor{blurriness}
+@section blurriness
+
+Determines blurriness of frames without altering the input frames.
+
+Based on Marziliano, Pina, et al. "A no-reference perceptual blur metric."
+Allows for a block-based abbreviation.
+
+The filter accepts the following options:
+
+@table @option
+@item low
+@item high
+Set low and high threshold values used by the Canny thresholding
+algorithm.
+
+The high threshold selects the "strong" edge pixels, which are then
+connected through 8-connectivity with the "weak" edge pixels selected
+by the low threshold.
+
+@var{low} and @var{high} threshold values must be chosen in the range
+[0,1], and @var{low} should be lesser or equal to @var{high}.
+
+Default value for @var{low} is @code{20/255}, and default value for @var{high}
+is @code{50/255}.
+
+@item radius
+Define the radius to search around an edge pixel for local maxima.
+
+@item block_pct
+Determine blurriness only for the most significant blocks, given in percentage.
+
+@item block_width
+Determine blurriness for blocks of width @var{block_width}. If set to any 
value smaller 1, no blocks are used and the whole image is processed as one no 
matter of @var{block_height}.
+
+@item block_height
+Determine blurriness for blocks of height @var{block_height}. If set to any 
value smaller 1, no blocks are used and the whole image is processed as one no 
matter of @var{block_width}.
+
+@item stats_file, f
+If specified the filter will use the named file to save the PSNR of
+each individual frame. When filename equals "-" the data is sent to
+standard output.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Determine blurriness for 80% of most significant 32x32 blocks and write to 
stdout:
+@example
+blurriness=block_width=32:block_height=32:block_pct=80:f=-
+@end example
+@end itemize
+
+
 @section bm3d
 
 Denoise frames using Block-Matching 3D algorithm.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 08edc92d8c..be70635c82 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -188,6 +188,7 @@ OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += 
vf_bitplanenoise.o
 OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
 OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
 OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o framesync.o
+OBJS-$(CONFIG_BLURRINESS_FILTER) += vf_blurriness.o
 OBJS-$(CONFIG_BM3D_FILTER)   += vf_bm3d.o framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o boxblur.o
 OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f250020159..121e37391d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -180,6 +180,7 @@ extern const AVFilter ff_vf_bitplanenoise;
 extern const AVFilter ff_vf_blackdetect;
 extern const AVFilter ff_vf_blackframe;
 extern const AVFilter ff_vf_blend;
+extern const AVFilter ff_vf_blurriness;
 extern const AVFilter ff_vf_bm3d;
 extern const AVFilter ff_vf_boxblur;
 extern const AVFilter ff_vf_boxblur_opencl;
diff --git a/libavfilter/vf_blurriness.c b/libavfilter/vf_blurriness.c
new file mode 100644
index 00..19cd2675f6
--- /dev/null
+++ b/libavfilter/vf_blurriness.c
@@ -0,0 +1,435 @@
+/*
+ * Copyright (c) 2021 Thilo Borgmann 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street

[FFmpeg-devel] [PATCH 1/2] lafi/vf_edgedetect: Move some common functions into seperate file

[Thilo Borgmann]

Hi,

v2, common functions moved into lavfi/edge_common.{c,h}. Also moved 
gaussian_blur() into the same.

-Thilo
From 0599b15e109cd6d0e1452663eb45b8b70b428444 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 30 Nov 2021 00:16:52 +0100
Subject: [PATCH 1/2] lafi/vf_edgedetect: Move some common functions into
 seperate file

---
 libavfilter/Makefile|   2 +-
 libavfilter/edge_common.c   | 181 +++
 libavfilter/edge_common.h   | 107 +
 libavfilter/vf_edgedetect.c | 183 ++--
 4 files changed, 296 insertions(+), 177 deletions(-)
 create mode 100644 libavfilter/edge_common.c
 create mode 100644 libavfilter/edge_common.h

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 08edc92d8c..1b559539ba 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -258,7 +258,7 @@ OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
 OBJS-$(CONFIG_DRAWGRAPH_FILTER)  += f_drawgraph.o
 OBJS-$(CONFIG_DRAWGRID_FILTER)   += vf_drawbox.o
 OBJS-$(CONFIG_DRAWTEXT_FILTER)   += vf_drawtext.o
-OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o
+OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o edge_common.o
 OBJS-$(CONFIG_ELBG_FILTER)   += vf_elbg.o
 OBJS-$(CONFIG_ENTROPY_FILTER)+= vf_entropy.o
 OBJS-$(CONFIG_EPX_FILTER)+= vf_epx.o
diff --git a/libavfilter/edge_common.c b/libavfilter/edge_common.c
new file mode 100644
index 00..d72e8521cd
--- /dev/null
+++ b/libavfilter/edge_common.c
@@ -0,0 +1,181 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser 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 "edge_common.h"
+
+// Internal helper for ff_sobel()
+static int get_rounded_direction(int gx, int gy)
+{
+/* reference angles:
+ *   tan( pi/8) = sqrt(2)-1
+ *   tan(3pi/8) = sqrt(2)+1
+ * Gy/Gx is the tangent of the angle (theta), so Gy/Gx is compared against
+ * , or more simply Gy against *Gx
+ *
+ * Gx and Gy bounds = [-1020;1020], using 16-bit arithmetic:
+ *   round((sqrt(2)-1) * (1<<16)) =  27146
+ *   round((sqrt(2)+1) * (1<<16)) = 158218
+ */
+if (gx) {
+int tanpi8gx, tan3pi8gx;
+
+if (gx < 0)
+gx = -gx, gy = -gy;
+gy *= (1 << 16);
+tanpi8gx  =  27146 * gx;
+tan3pi8gx = 158218 * gx;
+if (gy > -tan3pi8gx && gy < -tanpi8gx)  return DIRECTION_45UP;
+if (gy > -tanpi8gx  && gy <  tanpi8gx)  return DIRECTION_HORIZONTAL;
+if (gy >  tanpi8gx  && gy <  tan3pi8gx) return DIRECTION_45DOWN;
+}
+return DIRECTION_VERTICAL;
+}
+
+// Simple sobel operator to get rounded gradients
+void ff_sobel(int w, int h,
+uint16_t *dst, int dst_linesize,
+int8_t *dir, int dir_linesize,
+const uint8_t *src, int src_linesize)
+{
+int i, j;
+
+for (j = 1; j < h - 1; j++) {
+dst += dst_linesize;
+dir += dir_linesize;
+src += src_linesize;
+for (i = 1; i < w - 1; i++) {
+const int gx =
+-1*src[-src_linesize + i-1] + 1*src[-src_linesize + i+1]
+-2*src[i-1] + 2*src[i+1]
+-1*src[ src_linesize + i-1] + 1*src[ src_linesize + i+1];
+const int gy =
+-1*src[-src_linesize + i-1] + 1*src[ src_linesize + i-1]
+-2*src[-src_linesize + i  ] + 2*src[ src_linesize + i  ]
+-1*src[-src_linesize + i+1] + 1*src[ src_linesize + i+1];
+
+dst[i] = FFABS(gx) + FFABS(gy);
+dir[i] = get_rounded_direction(gx, gy);
+}
+}
+}
+
+// Filters rounded gradients to drop all non-maxima
+// Expects gradients generated by ff_sobel()
+// Expects zero's destination buffer
+void ff_non_maximum_suppression(int w, int h,
+  uint8_t *dst, int dst_linesize,
+  const int8_t *dir, int dir_linesize,
+  const uint16_t *src, int src_linesize)
+{
+int i, j;
+
+#define COPY_MAXIMA(a

[FFmpeg-devel] [PATCH 2/2] lavfi: Add blurriness filter

[Thilo Borgmann]

Hi,

$subject

-Thilo
From 0fa76024cf921df8a6df77a3860faab9669d0a2e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 30 Nov 2021 00:17:44 +0100
Subject: [PATCH 2/2] lavfi: Add blurriness filter

---
 doc/filters.texi|  55 ++
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_blurriness.c | 366 
 4 files changed, 423 insertions(+)
 create mode 100644 libavfilter/vf_blurriness.c

diff --git a/doc/filters.texi b/doc/filters.texi
index b4f888c14d..d066041e21 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7712,6 +7712,61 @@ tblend=all_mode=grainextract
 @subsection Commands
 This filter supports same @ref{commands} as options.
 
+@anchor{blurriness}
+@section blurriness
+
+Determines blurriness of frames without altering the input frames.
+
+Based on Marziliano, Pina, et al. "A no-reference perceptual blur metric."
+Allows for a block-based abbreviation.
+
+The filter accepts the following options:
+
+@table @option
+@item low
+@item high
+Set low and high threshold values used by the Canny thresholding
+algorithm.
+
+The high threshold selects the "strong" edge pixels, which are then
+connected through 8-connectivity with the "weak" edge pixels selected
+by the low threshold.
+
+@var{low} and @var{high} threshold values must be chosen in the range
+[0,1], and @var{low} should be lesser or equal to @var{high}.
+
+Default value for @var{low} is @code{20/255}, and default value for @var{high}
+is @code{50/255}.
+
+@item radius
+Define the radius to search around an edge pixel for local maxima.
+
+@item block_pct
+Determine blurriness only for the most significant blocks, given in percentage.
+
+@item block_width
+Determine blurriness for blocks of width @var{block_width}. If set to any 
value smaller 1, no blocks are used and the whole image is processed as one no 
matter of @var{block_height}.
+
+@item block_height
+Determine blurriness for blocks of height @var{block_height}. If set to any 
value smaller 1, no blocks are used and the whole image is processed as one no 
matter of @var{block_width}.
+
+@item stats_file, f
+If specified the filter will use the named file to save the PSNR of
+each individual frame. When filename equals "-" the data is sent to
+standard output.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Determine blurriness for 80% of most significant 32x32 blocks and write to 
stdout:
+@example
+blurriness=block_width=32:block_height=32:block_pct=80:f=-
+@end example
+@end itemize
+
+
 @section bm3d
 
 Denoise frames using Block-Matching 3D algorithm.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1b559539ba..8dd1b2a947 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -188,6 +188,7 @@ OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += 
vf_bitplanenoise.o
 OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
 OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
 OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o framesync.o
+OBJS-$(CONFIG_BLURRINESS_FILTER) += vf_blurriness.o edge_common.o
 OBJS-$(CONFIG_BM3D_FILTER)   += vf_bm3d.o framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o boxblur.o
 OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f250020159..121e37391d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -180,6 +180,7 @@ extern const AVFilter ff_vf_bitplanenoise;
 extern const AVFilter ff_vf_blackdetect;
 extern const AVFilter ff_vf_blackframe;
 extern const AVFilter ff_vf_blend;
+extern const AVFilter ff_vf_blurriness;
 extern const AVFilter ff_vf_bm3d;
 extern const AVFilter ff_vf_boxblur;
 extern const AVFilter ff_vf_boxblur_opencl;
diff --git a/libavfilter/vf_blurriness.c b/libavfilter/vf_blurriness.c
new file mode 100644
index 00..71b72d7211
--- /dev/null
+++ b/libavfilter/vf_blurriness.c
@@ -0,0 +1,366 @@
+/*
+ * Copyright (c) 2021 Thilo Borgmann 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser 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
+ */
+
+/**
+ * @file
+ * No-reference blurriness metric filter
+ *
+ * Implemen

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: Add blurriness filter

[Thilo Borgmann]

Am 30.11.21 um 17:11 schrieb Marton Balint:
> 
> 
> On Tue, 30 Nov 2021, Thilo Borgmann wrote:
> 
>> Hi,
>>
>> $subject
> 
> Can you name this blurdetect to be more in line with existing similar 
> filters? (blackdetect, freezedetect)

Totally will in the next version.

Thanks,
Thilo

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

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

Re: [FFmpeg-devel] [CLT2019] FFmpeg at Chemnitzer Linux-Tage

[Thilo Borgmann]

Am 23.03.19 um 16:11 schrieb Thilo Borgmann:
> Hi,
> 
>> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany!
>> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March.
>> You can find more details on their homepage:
>>
>> https://chemnitzer.linux-tage.de/2019/en/
> 
> we returned from last weekends CLT. We again had a great time there with a 
> lot of interested users and even some involvement in the capturing and 
> streaming of the talks.
> 
> We presented the usual demos showing filters and capturing. We could acquire 
> new hardware for the project during the fair, so we'll be ablte to 
> significantly update our presentation for the next conference to run on that 
> hardware.
> 
> Hotel and transportation has been handled like in the years before, so there 
> will be some requests about that soon.

For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from 
Berlin to Chemnitz.
Lost 1/2 receipts, which makes it cheaper this year.

Sending the receipt to Stefano.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [CLT2019] FFmpeg at Chemnitzer Linux-Tage

[Thilo Borgmann]

Am 30.03.19 um 16:04 schrieb Thilo Borgmann:
> Am 23.03.19 um 16:11 schrieb Thilo Borgmann:
>> Hi,
>>
>>> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany!
>>> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March.
>>> You can find more details on their homepage:
>>>
>>> https://chemnitzer.linux-tage.de/2019/en/
>>
>> we returned from last weekends CLT. We again had a great time there with a 
>> lot of interested users and even some involvement in the capturing and 
>> streaming of the talks.
>>
>> We presented the usual demos showing filters and capturing. We could acquire 
>> new hardware for the project during the fair, so we'll be ablte to 
>> significantly update our presentation for the next conference to run on that 
>> hardware.
>>
>> Hotel and transportation has been handled like in the years before, so there 
>> will be some requests about that soon.
> 
> For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me from 
> Berlin to Chemnitz.
> Lost 1/2 receipts, which makes it cheaper this year.

Correction, it is actually just 55,89 EUR.

-Thilo


> Sending the receipt to Stefano.
> 
> Thanks,
> Thilo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

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

Re: [FFmpeg-devel] [CLT2019] FFmpeg at Chemnitzer Linux-Tage

[Thilo Borgmann]

Am 30.03.19 um 17:41 schrieb Stefano Sabatini:
> On date Saturday 2019-03-30 11:19:11 -0400, Ronald S. Bultje encoded:
>> Hi,
>>
>> On Sat, Mar 30, 2019 at 11:04 AM Thilo Borgmann 
>> wrote:
> [...]
>>> For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me
>>> from Berlin to Chemnitz.
>>> Lost 1/2 receipts, which makes it cheaper this year.
>>
>>
> 
>> Can't the foundation just reimburse you anyway for the
>> expense-with-no-receipt? This feels kind of silly. (I don't know if this is
>> a foundation rule or not.)
> 
> Yes it can (and in the past we got refund even in case there was a
> missing receipt), even though it's recommended to provide them.
> 
> For the return travel we can account the same amount as for the
> outward one.

Sounds fair to me. Though, if Stefano encounters any burdon doing so, I'm fine 
with receipt-only refunding. I'll leave it to you, Stefano.

Thanks!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

[Thilo Borgmann]

$Subject

Tested compilation only, sanity test actually using it appreciated.

Thanks,
Thilo
From 104b26ca0eab116dcd49b5f2090067b76b5bfc70 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Tue, 14 May 2019 15:11:38 +0200
Subject: [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX
 < 10.13.

Prior OS versions are missing the 10bpp formats.
---
 libavcodec/videotoolboxenc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 3665581..24e0b62 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -762,12 +762,17 @@ static int get_cv_pixel_format(AVCodecContext* avctx,
 *av_pixel_format = range == AVCOL_RANGE_JPEG ?
 
kCVPixelFormatType_420YpCbCr8PlanarFullRange :
 kCVPixelFormatType_420YpCbCr8Planar;
-} else if (fmt == AV_PIX_FMT_P010LE) {
+}
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
+else if (fmt == AV_PIX_FMT_P010LE) {
 *av_pixel_format = range == AVCOL_RANGE_JPEG ?
 
kCVPixelFormatType_420YpCbCr10BiPlanarFullRange :
 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
 *av_pixel_format = kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
-} else {
+}
+#endif
+else {
 return AVERROR(EINVAL);
 }
 
@@ -1991,6 +1996,8 @@ static int get_cv_pixel_info(
 strides[2] = frame ? frame->linesize[2] : (avctx->width + 1) / 2;
 break;
 
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
 case AV_PIX_FMT_P010LE:
 *plane_count = 2;
 widths[0] = avctx->width;
@@ -2001,6 +2008,7 @@ static int get_cv_pixel_info(
 heights[1] = (avctx->height + 1) / 2;
 strides[1] = frame ? frame->linesize[1] : ((avctx->width + 1) / 2 + 
63) & -64;
 break;
+#endif
 
 default:
 av_log(
@@ -2488,7 +2496,10 @@ static const enum AVPixelFormat hevc_pix_fmts[] = {
 AV_PIX_FMT_VIDEOTOOLBOX,
 AV_PIX_FMT_NV12,
 AV_PIX_FMT_YUV420P,
+#if ((!TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 101300) || \
+ (TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MIN_REQUIRED >= 11))
 AV_PIX_FMT_P010LE,
+#endif
 AV_PIX_FMT_NONE
 };
 
-- 
1.8.3.2

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

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

[Thilo Borgmann]

Am 22.05.19 um 01:41 schrieb Jan Ekström:
> Hi,
> 
> On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann  wrote:
>>
>> $Subject
>>
>> Tested compilation only, sanity test actually using it appreciated.
>>
> 
> Thanks for the patch. To be completely fair, this is not to fix
> compilation for specific target systems, but rather to fix compilation
> on older SDKs (building with newer SDKs you can still build aiming for
> macOS starting from 10.9, for example).
> 
> I didn't notice a patch landed on the encoder side that utilized the
> defines without further checking/ifdefs. Too bad. I think I
> specifically didn't yet merge the full/limited range patch on the
> decoder side due to related reasons.
> 
> I did notice that VLC just re-defined these enum values themselves to
> stop needing to have ifdefs depending on which SDK is being utilized
> (https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735).
> I wonder if we should have a helper header that would re-define these
> enum values with their name. That way the code would look correct, and
> the resulting binary has the same features independent of the SDK it
> had been built under.
> 
> What would be the opinion of people on a solution like this?

Tested with a local definition of the symbols (like a would be header would do).
Seems to work for building with -macosx-version-min=XXX.

Also checked with VLC, they do these checks via thinks like:

#ifndef MAC_OS_X_VERSION_10_13
...
#endif

Wich might be a better alternative to what I suggested.

Thus I would be fine with a helping header.

-Thilo


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

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

[Thilo Borgmann]

Am 22.05.19 um 14:27 schrieb Thilo Borgmann:
> Am 22.05.19 um 01:41 schrieb Jan Ekström:
>> Hi,
>>
>> On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann  
>> wrote:
>>>
>>> $Subject
>>>
>>> Tested compilation only, sanity test actually using it appreciated.
>>>
>>
>> Thanks for the patch. To be completely fair, this is not to fix
>> compilation for specific target systems, but rather to fix compilation
>> on older SDKs (building with newer SDKs you can still build aiming for
>> macOS starting from 10.9, for example).
>>
>> I didn't notice a patch landed on the encoder side that utilized the
>> defines without further checking/ifdefs. Too bad. I think I
>> specifically didn't yet merge the full/limited range patch on the
>> decoder side due to related reasons.
>>
>> I did notice that VLC just re-defined these enum values themselves to
>> stop needing to have ifdefs depending on which SDK is being utilized
>> (https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735).
>> I wonder if we should have a helper header that would re-define these
>> enum values with their name. That way the code would look correct, and
>> the resulting binary has the same features independent of the SDK it
>> had been built under.
>>
>> What would be the opinion of people on a solution like this?
> 
> Tested with a local definition of the symbols (like a would be header would 
> do).
> Seems to work for building with -macosx-version-min=XXX.
> 
> Also checked with VLC, they do these checks via thinks like:
> 
> #ifndef MAC_OS_X_VERSION_10_13
>   ...
> #endif
> 
> Wich might be a better alternative to what I suggested.
> 
> Thus I would be fine with a helping header.

If nobody else cares, should I try to come up with something like this? Or do 
you want to?

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolboxenc: Fix for the compiler error for my old mac pro

[Thilo Borgmann]

Am 07.06.19 um 17:21 schrieb Lance Wang:
> On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz  wrote:
> 
>> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
>>
>>> From: Limin Wang 
>>>
>>> Signed-off-by: Limin Wang 
>>
>> This looks like a different approach to a similar patch sent before
>> by Thilo.

It is. We'd discussed a possible solution in the corresponding thread:
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244049.html

I guess I'll implement it next week like said in there - feel free to implement 
that approach beofre I'll get to it.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: Consider frame_size in ra_block handling

[Thilo Borgmann]

Am 20.06.19 um 16:17 schrieb Michael Niedermayer:
> Fixes: out of array access
> Fixes: 
> 15277/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5184853437317120
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/alsdec.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
> index e50a287f19..f94086efcb 100644
> --- a/libavcodec/alsdec.c
> +++ b/libavcodec/alsdec.c
> @@ -789,14 +789,15 @@ static int read_var_block_data(ALSDecContext *ctx, 
> ALSBlockData *bd)
>  
>  // read first value and residuals in case of a random access block
>  if (bd->ra_block) {
> -if (opt_order)

pls add a comment here like:

// limit possibly corrupted opt_order

and push if tested.

> +int len = FFMIN(opt_order, sconf->frame_length);
> +if (len)
>  bd->raw_samples[0] = decode_rice(gb, avctx->bits_per_raw_sample 
> - 4);
> -if (opt_order > 1)
> +if (len > 1)
>  bd->raw_samples[1] = decode_rice(gb, FFMIN(s[0] + 3, 
> ctx->s_max));
> -if (opt_order > 2)
> +if (len > 2)
>  bd->raw_samples[2] = decode_rice(gb, FFMIN(s[0] + 1, 
> ctx->s_max));
>  
> -start = FFMIN(opt_order, 3);
> +start = FFMIN(len, 3);
>  }
>  
>  // read all residuals
> 

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

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

[FFmpeg-devel] [PATCH 0/4] lavd/avfoundation: Support muxed device types

[Thilo Borgmann]

Hi,

some cleanup and $SUBJECT.

Documentation and reindent follows afterwards.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/4] lavd/avfoundation: Remove useless index increment.

[Thilo Borgmann]

$SUBJECT

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

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

Re: [FFmpeg-devel] [PATCH 1/4] lavd/avfoundation: Remove useless index increment.

[Thilo Borgmann]

including patch...
From 4b85b80cdbf3c5e041eab3b5d1171c0ff3f913ad Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 30 Jun 2019 13:56:08 +0200
Subject: [PATCH 1/4] lavd/avfoundation: Remove useless index increment.

---
 libavdevice/avfoundation.m | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 98552ac..88fe050 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -690,7 +690,6 @@ static int avf_read_header(AVFormatContext *s)
 const char *name = [[device localizedName] UTF8String];
 index= [devices indexOfObject:device];
 av_log(ctx, AV_LOG_INFO, "[%d] %s\n", index, name);
-index++;
 }
 #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 if (num_screens > 0) {
-- 
1.8.3.2

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

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

[FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.

[Thilo Borgmann]

$SUBJECT

-Thilo
From 4e39cb25ac2dd75899989d87ac48cc55293db515 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 30 Jun 2019 13:57:54 +0200
Subject: [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.

---
 libavdevice/avfoundation.m | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 88fe050..0ce0a37 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -1064,8 +1064,12 @@ static const AVOption options[] = {
 { "pixel_format", "set pixel format", offsetof(AVFContext, pixel_format), 
AV_OPT_TYPE_PIXEL_FMT, {.i64 = AV_PIX_FMT_YUV420P}, 0, INT_MAX, 
AV_OPT_FLAG_DECODING_PARAM},
 { "framerate", "set frame rate", offsetof(AVFContext, framerate), 
AV_OPT_TYPE_VIDEO_RATE, {.str = "ntsc"}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM 
},
 { "video_size", "set video size", offsetof(AVFContext, width), 
AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },
-{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
-{ "capture_mouse_clicks", "capture the screen mouse clicks", 
offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
AV_OPT_FLAG_DECODING_PARAM },
+{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM, 
"capture_cursor" },
+{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
+{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
+{ "capture_mouse_clicks", "capture the screen mouse clicks", 
offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
+{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
+{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
 
 { NULL },
 };
-- 
1.8.3.2

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

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

[FFmpeg-devel] [PATCH 3/4] lavd/avfoundation: Refine some log messages.

[Thilo Borgmann]

$SUBJECT

-Thilo
From 312df3342b98fd805c3bda584de88b261a59329e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 30 Jun 2019 14:00:42 +0200
Subject: [PATCH 3/4] lavd/avfoundation: Refine some log messages.

---
 libavdevice/avfoundation.m | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 0ce0a37..5dd6ea5 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -316,13 +316,13 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 }
 
 if (!selected_format) {
-av_log(s, AV_LOG_ERROR, "Selected video size (%dx%d) is not supported 
by the device\n",
+av_log(s, AV_LOG_ERROR, "Selected video size (%dx%d) is not supported 
by the device.\n",
 ctx->width, ctx->height);
 goto unsupported_format;
 }
 
 if (!selected_range) {
-av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by 
the device\n",
+av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by 
the device.\n",
 framerate);
 goto unsupported_format;
 }
@@ -334,7 +334,7 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMinFrameDuration"];
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMaxFrameDuration"];
 } else {
-av_log(s, AV_LOG_ERROR, "Could not lock device for configuration");
+av_log(s, AV_LOG_ERROR, "Could not lock device for configuration.\n");
 return AVERROR(EINVAL);
 }
 
@@ -908,7 +908,7 @@ static int copy_cvpixelbuffer(AVFormatContext *s,
 
 status = CVPixelBufferLockBaseAddress(image_buffer, 0);
 if (status != kCVReturnSuccess) {
-av_log(s, AV_LOG_ERROR, "Could not lock base address: %d\n", status);
+av_log(s, AV_LOG_ERROR, "Could not lock base address: %d (%dx%d)\n", 
status, width, height);
 return AVERROR_EXTERNAL;
 }
 
-- 
1.8.3.2

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

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

[FFmpeg-devel] [PATCH 4/4] lavd/avfoundation: Support muxed type of devices

[Thilo Borgmann]

$SUBJECT

-Thilo
From 3287fbbcbf625a8eebf3aac17871836a6f28c824 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 30 Jun 2019 14:01:56 +0200
Subject: [PATCH 4/4] lavd/avfoundation: Support muxed type of devices
 including raw muxed data capture.

---
 libavdevice/avfoundation.m | 91 +-
 1 file changed, 82 insertions(+), 9 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 5dd6ea5..715b7b3 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -97,6 +97,8 @@ typedef struct
 
 int capture_cursor;
 int capture_mouse_clicks;
+int capture_raw_data;
+int video_is_muxed;
 
 int list_devices;
 int video_device_index;
@@ -291,6 +293,10 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 NSObject *selected_range = nil;
 NSObject *selected_format = nil;
 
+// try to configure format by formats list
+// might raise an exception if no format list is given
+// (then fallback to default, no configuration)
+@try {
 for (format in [video_device valueForKey:@"formats"]) {
 CMFormatDescriptionRef formatDescription;
 CMVideoDimensions dimensions;
@@ -324,19 +330,29 @@ static int configure_video_device(AVFormatContext *s, 
AVCaptureDevice *video_dev
 if (!selected_range) {
 av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by 
the device.\n",
 framerate);
+if (ctx->video_is_muxed) {
+av_log(s, AV_LOG_ERROR, "Falling back to default.\n");
+} else {
 goto unsupported_format;
+}
 }
 
 if ([video_device lockForConfiguration:NULL] == YES) {
+if (selected_format) {
+[video_device setValue:selected_format forKey:@"activeFormat"];
+}
+if (selected_range) {
 NSValue *min_frame_duration = [selected_range 
valueForKey:@"minFrameDuration"];
-
-[video_device setValue:selected_format forKey:@"activeFormat"];
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMinFrameDuration"];
 [video_device setValue:min_frame_duration 
forKey:@"activeVideoMaxFrameDuration"];
+}
 } else {
 av_log(s, AV_LOG_ERROR, "Could not lock device for configuration.\n");
 return AVERROR(EINVAL);
 }
+} @catch(NSException *e) {
+av_log(ctx, AV_LOG_WARNING, "Configuration of video device failed, 
falling back to default.\n");
+}
 
 return 0;
 
@@ -468,12 +484,18 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 }
 
+// set videoSettings to an empty dict for receiving raw data of muxed 
devices
+if (ctx->capture_raw_data) {
+ctx->pixel_format  = pxl_fmt_spec.ff_id;
+ctx->video_output.videoSettings = @{ };
+} else {
 ctx->pixel_format  = pxl_fmt_spec.ff_id;
 pixel_format = [NSNumber numberWithUnsignedInt:pxl_fmt_spec.avf_id];
 capture_dict = [NSDictionary dictionaryWithObject:pixel_format

forKey:(id)kCVPixelBufferPixelFormatTypeKey];
 
 [ctx->video_output setVideoSettings:capture_dict];
+}
 [ctx->video_output setAlwaysDiscardsLateVideoFrames:YES];
 
 ctx->avf_delegate = [[AVFFrameReceiver alloc] initWithContext:ctx];
@@ -540,6 +562,7 @@ static int get_video_config(AVFormatContext *s)
 {
 AVFContext *ctx = (AVFContext*)s->priv_data;
 CVImageBufferRef image_buffer;
+CMBlockBufferRef block_buffer;
 CGSize image_buffer_size;
 AVStream* stream = avformat_new_stream(s, NULL);
 
@@ -558,14 +581,22 @@ static int get_video_config(AVFormatContext *s)
 
 avpriv_set_pts_info(stream, 64, 1, avf_time_base);
 
-image_buffer  = CMSampleBufferGetImageBuffer(ctx->current_frame);
-image_buffer_size = CVImageBufferGetEncodedSize(image_buffer);
+image_buffer = CMSampleBufferGetImageBuffer(ctx->current_frame);
+block_buffer = CMSampleBufferGetDataBuffer(ctx->current_frame);
+
+if (image_buffer) {
+image_buffer_size = CVImageBufferGetEncodedSize(image_buffer);
 
 stream->codecpar->codec_id   = AV_CODEC_ID_RAWVIDEO;
 stream->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
 stream->codecpar->width  = (int)image_buffer_size.width;
 stream->codecpar->height = (int)image_buffer_size.height;
 stream->codecpar->format = ctx->pixel_format;
+} else {
+stream->codecpar->codec_id   = AV_CODEC_ID_DVVIDEO;
+stream->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+stream->codecpar->format = ctx->pixel_format;
+}
 
 CFRelease(ctx->current_fram

Re: [FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.

[Thilo Borgmann]

Am 30.06.19 um 19:17 schrieb Moritz Barsnick:
> On Sun, Jun 30, 2019 at 14:14:13 +0200, Thilo Borgmann wrote:
>> -{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM 
>> },
>> -{ "capture_mouse_clicks", "capture the screen mouse clicks", 
>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
>> AV_OPT_FLAG_DECODING_PARAM },
>> +{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "capture_mouse_clicks", "capture the screen mouse clicks", 
>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
> 
> Can't you just make the options AV_OPT_TYPE_BOOL? No additional consts
> requires.

Yes. Changed locally.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.

[Thilo Borgmann]

Am 30.06.19 um 21:40 schrieb Thilo Borgmann:
> Am 30.06.19 um 19:17 schrieb Moritz Barsnick:
>> On Sun, Jun 30, 2019 at 14:14:13 +0200, Thilo Borgmann wrote:
>>> -{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
>>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> -{ "capture_mouse_clicks", "capture the screen mouse clicks", 
>>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 
>>> 1, AV_OPT_FLAG_DECODING_PARAM },
>>> +{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
>>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "capture_mouse_clicks", "capture the screen mouse clicks", 
>>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 
>>> 1, AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, 
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, 
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>
>> Can't you just make the options AV_OPT_TYPE_BOOL? No additional consts
>> requires.
> 
> Yes. Changed locally.

Also changed for the new option in patch 4/4, of course.

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

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

Re: [FFmpeg-devel] [PATCH 0/4] lavd/avfoundation: Support muxed device types

[Thilo Borgmann]

Am 30.06.19 um 14:11 schrieb Thilo Borgmann:
> Hi,
> 
> some cleanup and $SUBJECT.
> 
> Documentation and reindent follows afterwards.

Will add docs and push with remarks from Moritz soonish - if there are no more 
comments coming in.

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

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

Re: [FFmpeg-devel] [PATCH 3/7] avcodec/alsdec: Fix integer overflow with buffer number

[Thilo Borgmann]

Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
> 
> 
> On 21.06.2019, at 00:47, Michael Niedermayer  wrote:
> 
>> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type 
>> 'int'
>> Fixes: 
>> 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600
>>
>> Found-by: continuous fuzzing process 
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by: Michael Niedermayer 
>> ---
>> libavcodec/alsdec.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
>> index 79d22b7c2b..8e0d3e5f83 100644
>> --- a/libavcodec/alsdec.c
>> +++ b/libavcodec/alsdec.c
>> @@ -1990,6 +1990,8 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>
>> // allocate quantized parcor coefficient buffer
>> num_buffers = sconf->mc_coding ? avctx->channels : 1;
>> +if (num_buffers * (uint64_t)num_buffers > INT_MAX)
>> +return AVERROR_INVALIDDATA;
> 
> It would be nice if it was clear which code this check protects, i.e. some 
> connection between the check and the code that overflows.
> I guess one might also ask if > 30 000 channels might not be something to 
> catch and disallow earlier and generally...

AFAICT the specs allow all 16 bit aka 65536 (+1) channels. For the case that 
remark from Raimar had been addressed..

The rest lgtm. I would appreciate s.o. bumping me if I miss something about ALS 
on devel, pls 0:-)

-Thilo



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

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

Re: [FFmpeg-devel] [PATCH 3/7] avcodec/alsdec: Fix integer overflow with buffer number

[Thilo Borgmann]

Am 06.07.19 um 22:10 schrieb Michael Niedermayer:
> On Sat, Jul 06, 2019 at 09:39:32PM +0200, Thilo Borgmann wrote:
>> Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
>>>
>>>
>>> On 21.06.2019, at 00:47, Michael Niedermayer  wrote:
>>>
>>>> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in 
>>>> type 'int'
>>>> Fixes: 
>>>> 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600
>>>>
>>>> Found-by: continuous fuzzing process 
>>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>>> Signed-off-by: Michael Niedermayer 
>>>> ---
>>>> libavcodec/alsdec.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
>>>> index 79d22b7c2b..8e0d3e5f83 100644
>>>> --- a/libavcodec/alsdec.c
>>>> +++ b/libavcodec/alsdec.c
>>>> @@ -1990,6 +1990,8 @@ static av_cold int decode_init(AVCodecContext *avctx)
>>>>
>>>> // allocate quantized parcor coefficient buffer
>>>> num_buffers = sconf->mc_coding ? avctx->channels : 1;
>>>> +if (num_buffers * (uint64_t)num_buffers > INT_MAX)
>>>> +return AVERROR_INVALIDDATA;
>>>
>>> It would be nice if it was clear which code this check protects, i.e. some 
>>> connection between the check and the code that overflows.
>>> I guess one might also ask if > 30 000 channels might not be something to 
>>> catch and disallow earlier and generally...
>>
>> AFAICT the specs allow all 16 bit aka 65536 (+1) channels. For the case that 
>> remark from Raimar had been addressed..
> 
> its the chan_data_buffer allocation. Ill add a comment
> 
> 
>>
>> The rest lgtm. I would appreciate s.o. bumping me if I miss something about 
>> ALS on devel, pls 0:-)
> 
> not sure i understand the abbreviation but i will apply the patchset as it
> seems, thats the consensus and ill try to ping you in the future of als 
> patches unless
> i forget ... sadly i tend to forget these things ...

"Someone".

Do apply. The rest is just in regard of redundance, I'll not miss every patch ^^

Thanks,
Thilo

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

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

Re: [FFmpeg-devel] [PATCH 0/4] lavd/avfoundation: Support muxed device types

[Thilo Borgmann]

Am 04.07.19 um 16:28 schrieb Thilo Borgmann:
> Am 30.06.19 um 14:11 schrieb Thilo Borgmann:
>> Hi,
>>
>> some cleanup and $SUBJECT.
>>
>> Documentation and reindent follows afterwards.
> 
> Will add docs and push with remarks from Moritz soonish - if there are no 
> more comments coming in.

Pushed.

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

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Thilo Borgmann]

Am 05.08.19 um 17:57 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
> wrote:
> 
>> On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
>>> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
>> 
>>> wrote:
>>>
 On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> Of Michael Niedermayer
>> Sent: Monday, August 5, 2019 3:45 AM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
>>
>> On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
>>> On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
>>> 
>>> wrote:
>>>
 Hi all

 It seems we do not have a list of people volunteering to do
>> uploads
 to samples. And no place to send such requests to except here,
 where
 they sometimes get ignored.

>>>
>>> Just give everyone with push access right to upload.
>>
>> Upload currently requires an account on the server, giving
>> everyone an
>> account is a security risk.
>> It also doesnt really make sense to give someone access who doesnt
>> need
>> access.
>> If someone wants to take care of uploads (s)he can have access.
>>
>> Of course if theres a majority wanting everyone with push access to
 have an
>> account on the server, sure we will do that but i dont think its a
 good idea.
>> IMHO its always better (aka more secure) if access is kept at a
 minimum.
>>
>> besides, it would be a bit of work to keep the list of who has push
 access and
>> who has sampeles access synchronized. Its different servers and
 different
>> types of "accounts"
>> and the whole point from my point of view is that id like to spend
>> my
 time on
>> other areas on FFmpeg While keeping accounts synchronized would be
>> probably more work than doing the uploads myself
>>
>> Thanks
>

> My suggestions would be:
> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
 how to apply and update the FATE MAINTAINERS list.

 Iam not sure if there is someone, but if so (s)he should send an email
>> to
 root or to ffmpeg-devel (again in case he did long ago already)

>>>
>>> You are not sure that you gave someone upload access to fate samples?
>>> Perhaps you forgot?
>>
>> iam not sure if someone volunteered and did not receive access as at a
>> similar time other people suggested that the existing people with access
>> could handle it and no new uploaders where needed.
>>
>> So yeah, short form: i forgot the name from an email months or years ago.
>>
>>
> Can you check now who have access?

Would it make sense to create a samp...@ffmpeg.org address and put the people 
in charge behind that address?

How much work does one expect from that? Do we upload several a day?

I would volunteer to take at least part of the burden.

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

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

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

[Thilo Borgmann]

Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
> Signed-off-by: Eugene Lyapustin 
> ---
>  doc/filters.texi |  137 +++
>  libavfilter/Makefile |1 +
>  libavfilter/allfilters.c |1 +
>  libavfilter/vf_vr360.c   | 1847 ++


> +AVFilter ff_vf_vr360 = {
> +.name  = "vr360",
> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of 
> video."),

"vr360" does not make any sense to me. VR and 360 degree are two different 
things.

And since VR-related filters may very well emerge in the future, we should be 
as clear as possible about these.

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

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

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

[Thilo Borgmann]

Am 05.08.19 um 21:00 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
>>> Signed-off-by: Eugene Lyapustin 
>>> ---
>>>  doc/filters.texi |  137 +++
>>>  libavfilter/Makefile |1 +
>>>  libavfilter/allfilters.c |1 +
>>>  libavfilter/vf_vr360.c   | 1847 ++
>>
>>
>>> +AVFilter ff_vf_vr360 = {
>>> +.name  = "vr360",
>>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>> video."),
>>
>> "vr360" does not make any sense to me. VR and 360 degree are two different
>> things.
>>
>> And since VR-related filters may very well emerge in the future, we should
>> be as clear as possible about these.
>>
> 
> Isnt VR just 360 but for each eye?

That would be stereoscopic 360.

What makes it VR is that the camera can move within space, not only change 
viewing direction.

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

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

Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org

[Thilo Borgmann]

Am 05.08.19 um 21:02 schrieb Michael Niedermayer:
> On Mon, Aug 05, 2019 at 08:48:03PM +0200, Thilo Borgmann wrote:
>> Am 05.08.19 um 17:57 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 5:45 PM Michael Niedermayer 
>>> wrote:
>>>
>>>> On Mon, Aug 05, 2019 at 05:24:31PM +0200, Paul B Mahol wrote:
>>>>> On Mon, Aug 5, 2019 at 5:21 PM Michael Niedermayer
>>>> 
>>>>> wrote:
>>>>>
>>>>>> On Mon, Aug 05, 2019 at 02:44:29AM +, Li, Zhong wrote:
>>>>>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>>>> Behalf
>>>>>>>> Of Michael Niedermayer
>>>>>>>> Sent: Monday, August 5, 2019 3:45 AM
>>>>>>>> To: FFmpeg development discussions and patches
>>>>>>>> 
>>>>>>>> Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
>>>>>>>>
>>>>>>>> On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote:
>>>>>>>>> On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
>>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all
>>>>>>>>>>
>>>>>>>>>> It seems we do not have a list of people volunteering to do
>>>> uploads
>>>>>>>>>> to samples. And no place to send such requests to except here,
>>>>>> where
>>>>>>>>>> they sometimes get ignored.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just give everyone with push access right to upload.
>>>>>>>>
>>>>>>>> Upload currently requires an account on the server, giving
>>>> everyone an
>>>>>>>> account is a security risk.
>>>>>>>> It also doesnt really make sense to give someone access who doesnt
>>>> need
>>>>>>>> access.
>>>>>>>> If someone wants to take care of uploads (s)he can have access.
>>>>>>>>
>>>>>>>> Of course if theres a majority wanting everyone with push access to
>>>>>> have an
>>>>>>>> account on the server, sure we will do that but i dont think its a
>>>>>> good idea.
>>>>>>>> IMHO its always better (aka more secure) if access is kept at a
>>>>>> minimum.
>>>>>>>>
>>>>>>>> besides, it would be a bit of work to keep the list of who has push
>>>>>> access and
>>>>>>>> who has sampeles access synchronized. Its different servers and
>>>>>> different
>>>>>>>> types of "accounts"
>>>>>>>> and the whole point from my point of view is that id like to spend
>>>> my
>>>>>> time on
>>>>>>>> other areas on FFmpeg While keeping accounts synchronized would be
>>>>>>>> probably more work than doing the uploads myself
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>>> My suggestions would be:
>>>>>>> 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him
>>>>>> how to apply and update the FATE MAINTAINERS list.
>>>>>>
>>>>>> Iam not sure if there is someone, but if so (s)he should send an email
>>>> to
>>>>>> root or to ffmpeg-devel (again in case he did long ago already)
>>>>>>
>>>>>
>>>>> You are not sure that you gave someone upload access to fate samples?
>>>>> Perhaps you forgot?
>>>>
>>>> iam not sure if someone volunteered and did not receive access as at a
>>>> similar time other people suggested that the existing people with access
>>>> could handle it and no new uploaders where needed.
>>>>
>>>> So yeah, short form: i forgot the name from an email months or years ago.
>>>>
>>>>
>>> Can you check now who have access?
>>
>> Would it make sense to create a samp...@ffmpeg.org address and put the 
>> people in charge behind that address?
> 
> samp...@ffmpeg.org already exists and some daily debug messages from cronjobs
> end there. I am reluctant to just add people to this as they have not
> agreed to receive such cronjob "spam"
> but i can trivially add anyone who wants to be added
> or create a different alias with everyone who has currently access

If it already exists, we need another name for it as it is not for the server 
side of things but to give the user a common and hopefully static place to send 
requests to... sampleupload@, samples-request@... whatever but both might 
independently change, especially the debug alias.

>>
>> How much work does one expect from that? Do we upload several a day?
> 
> uploads to fate are relativly rare counting them "per month" would make
> more sense than per day

So that means we should be quite safe finding two volunteers for that.


>>
>> I would volunteer to take at least part of the burden.
> 
> thanks

-Thilo

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

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

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

[Thilo Borgmann]

Am 05.08.19 um 21:07 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 21:00 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
>>> wrote:
>>>
>>>> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
>>>>> Signed-off-by: Eugene Lyapustin 
>>>>> ---
>>>>>  doc/filters.texi |  137 +++
>>>>>  libavfilter/Makefile |1 +
>>>>>  libavfilter/allfilters.c |1 +
>>>>>  libavfilter/vf_vr360.c   | 1847 ++
>>>>
>>>>
>>>>> +AVFilter ff_vf_vr360 = {
>>>>> +.name  = "vr360",
>>>>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>>>> video."),
>>>>
>>>> "vr360" does not make any sense to me. VR and 360 degree are two
>> different
>>>> things.
>>>>
>>>> And since VR-related filters may very well emerge in the future, we
>> should
>>>> be as clear as possible about these.
>>>>
>>>
>>> Isnt VR just 360 but for each eye?
>>
>> That would be stereoscopic 360.
>>
>> What makes it VR is that the camera can move within space, not only change
>> viewing direction.
>>
> 
> Ah, than vr360 stands for Video processoR 360.
> What name should be instead?

"mono360" could make sense if a "stereo360" would process two inputs (that are 
not L-R or T-B coded)

Or just "video360"... but we really should save us "vr" for the future.

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

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

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

[Thilo Borgmann]

Am 05.08.19 um 21:16 schrieb Paul B Mahol:
> On Mon, Aug 5, 2019 at 9:12 PM Thilo Borgmann 
> wrote:
> 
>> Am 05.08.19 um 21:07 schrieb Paul B Mahol:
>>> On Mon, Aug 5, 2019 at 9:01 PM Thilo Borgmann 
>>> wrote:
>>>
>>>> Am 05.08.19 um 21:00 schrieb Paul B Mahol:
>>>>> On Mon, Aug 5, 2019 at 8:57 PM Thilo Borgmann 
>>>>> wrote:
>>>>>
>>>>>> Am 05.08.19 um 20:46 schrieb Eugene Lyapustin:
>>>>>>> Signed-off-by: Eugene Lyapustin 
>>>>>>> ---
>>>>>>>  doc/filters.texi |  137 +++
>>>>>>>  libavfilter/Makefile |1 +
>>>>>>>  libavfilter/allfilters.c |1 +
>>>>>>>  libavfilter/vf_vr360.c   | 1847
>> ++
>>>>>>
>>>>>>
>>>>>>> +AVFilter ff_vf_vr360 = {
>>>>>>> +.name  = "vr360",
>>>>>>> +.description   = NULL_IF_CONFIG_SMALL("Convert 360 projection of
>>>>>> video."),
>>>>>>
>>>>>> "vr360" does not make any sense to me. VR and 360 degree are two
>>>> different
>>>>>> things.
>>>>>>
>>>>>> And since VR-related filters may very well emerge in the future, we
>>>> should
>>>>>> be as clear as possible about these.
>>>>>>
>>>>>
>>>>> Isnt VR just 360 but for each eye?
>>>>
>>>> That would be stereoscopic 360.
>>>>
>>>> What makes it VR is that the camera can move within space, not only
>> change
>>>> viewing direction.
>>>>
>>>
>>> Ah, than vr360 stands for Video processoR 360.
>>> What name should be instead?
>>
>> "mono360" could make sense if a "stereo360" would process two inputs (that
>> are not L-R or T-B coded)
>>
>> Or just "video360"... but we really should save us "vr" for the future.
>>
> 
> v360 then?

Works for me.

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

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

Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to request samples upload access

[Thilo Borgmann]

Am 05.08.19 um 19:06 schrieb Michael Niedermayer:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/fate.texi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 2be61d639c..e04fbfbe43 100644
> --- a/doc/fate.texi
> +++ b/doc/fate.texi
> @@ -157,6 +157,9 @@ practice generally do not replace, remove or overwrite 
> files as it likely would
>  break older checkouts or releases.
>  Also all needed samples for a commit should be uploaded, ideally 24
>  hours, before the push.

> +If you need an account for frequently uploading samples or you wish to help
> +others do so send mail to ffmpeg-devel. Also please state if you are 
> available
> +to help others upload samples if you request access.

Might be better grammar:

If you need an account for frequently uploading samples or you wish to help
others by doing that send a mail to ffmpeg-devel.

-Thilo


>  
>  @example
>  #First update your local samples copy:
> 

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

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

Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to request samples upload access

[Thilo Borgmann]

Am 07.08.19 um 16:57 schrieb Li, Zhong:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Michael Niedermayer
>> Sent: Tuesday, August 6, 2019 1:07 AM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: [FFmpeg-devel] [PATCH] doc/fate: Document how to request
>> samples upload access
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  doc/fate.texi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/doc/fate.texi b/doc/fate.texi index 2be61d639c..e04fbfbe43
>> 100644
>> --- a/doc/fate.texi
>> +++ b/doc/fate.texi
>> @@ -157,6 +157,9 @@ practice generally do not replace, remove or
>> overwrite files as it likely would  break older checkouts or releases.
>>  Also all needed samples for a commit should be uploaded, ideally 24
>> hours, before the push.
>> +If you need an account for frequently uploading samples or you wish to
>> +help others do so send mail to ffmpeg-devel. Also please state if you
>> +are available to help others upload samples if you request access.
> 
> Probably I miss something.
> 
> It is still not clear for someone need to help to upload a sample: who is the 
> contact person?
> Should we update a new section with the name who can help others to upload, 
> or set-up/public a new mail list channel?

The new samples-request@ mail alias should be mentioned somewhere, and maybe 
added to MAINTAINERS.

Not sure if that is the right place to put it, though.

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

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

Re: [FFmpeg-devel] [PATCH] doc/fate: Document how to request samples upload access

[Thilo Borgmann]

Am 07.08.19 um 21:18 schrieb Michael Niedermayer:
> The awnser which most people will seek is put first
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/fate.texi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 2be61d639c..c3550785a1 100644
> --- a/doc/fate.texi
> +++ b/doc/fate.texi
> @@ -149,6 +149,8 @@ the synchronisation of the samples directory.
>  
>  @chapter Uploading new samples to the fate suite
>  
> +If you need a sample uploaded send a mail to samples-request.
> +
>  This is for developers who have an account on the fate suite server.
>  If you upload new samples, please make sure they are as small as possible,
>  space on each client, network bandwidth and so on benefit from smaller test 
> cases.
> @@ -157,6 +159,8 @@ practice generally do not replace, remove or overwrite 
> files as it likely would
>  break older checkouts or releases.
>  Also all needed samples for a commit should be uploaded, ideally 24
>  hours, before the push.
> +If you need an account for frequently uploading samples or you wish to help
> +others by doing that send a mail to ffmpeg-devel.

LGTM

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

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

Re: [FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229

[Thilo Borgmann]

Am 12.08.19 um 08:13 schrieb Zhong Li:
> Signed-off-by: Zhong Li 
> ---
> https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but not 
> found by fate, so add it.
> Test clip produced by:
> ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy 
> /fate-suite/mjpeg/mjpeg_field_order.avi
> 
>  tests/fate/video.mak| 3 +++
>  tests/ref/fate/mjpeg-ticket3229 | 8 
>  2 files changed, 11 insertions(+)
>  create mode 100644 tests/ref/fate/mjpeg-ticket3229
> [...]

LGTM & sample uploaded.

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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter

[Thilo Borgmann]

[...]

>>> +static int config_output(AVFilterLink *outlink)
>>> +{
>>> +AVFilterContext *ctx = outlink->src;
>>> +AVFilterLink *inlink = ctx->inputs[0];
>>> +V360Context *s = ctx->priv;
>>> +const AVPixFmtDescriptor *desc =
>>> av_pix_fmt_desc_get(inlink->format);
>>> +const int depth = desc->comp[0].depth;
>>> +float remap_data_size = 0.f;
>>> +int sizeof_remap;
>>> +int err;
>>> +int p, h, w;
>>> +float hf, wf;
>>> +float mirror_modifier[3];
>>> +void (*in_transform)(const V360Context *s,
>>> + const float *vec, int width, int height,
>>> + uint16_t us[4][4], uint16_t vs[4][4], float
>>> *du, float *dv);
>>> +void (*out_transform)(const V360Context *s,
>>> +  int i, int j, int width, int height,
>>> +  float *vec);
>>> +void (*calculate_kernel)(float du, float dv, int shift, const
>> XYRemap4
>>> *r_tmp, void *r);
>>> +float rot_mat[3][3];
>>> +
>>> +switch (s->interp) {
>>> +case NEAREST:
>>> +calculate_kernel = nearest_kernel;
>>> +s->remap_slice = depth <= 8 ? remap1_8bit_slice :
>>> remap1_16bit_slice;
>>> +sizeof_remap = sizeof(XYRemap1);
>>> +break;
>>> +case BILINEAR:
>>> +calculate_kernel = bilinear_kernel;
>>> +s->remap_slice = depth <= 8 ? remap2_8bit_slice :
>>> remap2_16bit_slice;
>>> +sizeof_remap = sizeof(XYRemap2);
>>> +break;
>>> +case BICUBIC:
>>> +calculate_kernel = bicubic_kernel;
>>> +s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>> remap4_16bit_slice;
>>> +sizeof_remap = sizeof(XYRemap4);
>>> +break;
>>> +case LANCZOS:
>>> +calculate_kernel = lanczos_kernel;
>>> +s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>> remap4_16bit_slice;
>>> +sizeof_remap = sizeof(XYRemap4);
>>> +break;
>>> +}
>>> +
>>> +switch (s->in) {
>>> +case EQUIRECTANGULAR:
>>> +in_transform = xyz_to_equirect;
>>> +err = 0;
>>> +wf = inlink->w;
>>> +hf = inlink->h;
>>> +break;
>>> +case CUBEMAP_3_2:
>>> +in_transform = xyz_to_cube3x2;
>>> +err = prepare_cube_in(ctx);
>>> +wf = inlink->w / 3.f * 4.f;
>>> +hf = inlink->h;
>>> +break;
>>> +case CUBEMAP_6_1:
>>> +in_transform = xyz_to_cube6x1;
>>> +err = prepare_cube_in(ctx);
>>> +wf = inlink->w / 3.f * 2.f;
>>> +hf = inlink->h * 2.f;
>>> +break;
>>> +case EQUIANGULAR:
>>> +in_transform = xyz_to_eac;
>>> +err = prepare_eac_in(ctx);
>>> +wf = inlink->w;
>>> +hf = inlink->h / 9.f * 8.f;
>>> +break;
>>> +case FLAT:
>>> +av_log(ctx, AV_LOG_ERROR, "Flat format is not accepted as
>>> input.\n");
>>> +return AVERROR(EINVAL);
>>> +}
>>> +
>>> +if (err != 0) {
>>> +return err;
>>> +}
>>> +
>>> +switch (s->out) {
>>> +case EQUIRECTANGULAR:
>>> +out_transform = equirect_to_xyz;
>>> +err = 0;
>>> +w = roundf(wf);
>>> +h = roundf(hf);
>>> +break;
>>> +case CUBEMAP_3_2:
>>> +out_transform = cube3x2_to_xyz;
>>> +err = prepare_cube_out(ctx);
>>> +w = roundf(wf / 4.f * 3.f);
>>> +h = roundf(hf);
>>> +break;
>>> +case CUBEMAP_6_1:
>>> +out_transform = cube6x1_to_xyz;
>>> +err = prepare_cube_out(ctx);
>>> +w = roundf(wf / 2.f * 3.f);
>>> +h = roundf(hf / 2.f);
>>> +break;
>>> +case EQUIANGULAR:
>>> +out_transform = eac_to_xyz;
>>> +err = prepare_eac_out(ctx);
>>> +w = roundf(wf);
>>> +h = roundf(hf / 8.f * 9.f);
>>> +break;
>>> +case FLAT:
>>> +out_transform = flat_to_xyz;
>>> +err = prepare_flat_out(ctx);
>>> +w = roundf(wf * s->flat_range[0] / s->flat_range[1] / 2.f);
>>> +h = roundf(hf);
>>> +break;
>>> +}
>>> +
>>> +if (err != 0) {
>>> +return err;
>>> +}
>>> +
>>> +if (s->width > 0 && s->height > 0) {
>>> +w = s->width;
>>> +h = s->height;
>>> +}
>>
>> If s->width/height are checked, should handle the case of no ture,
>> Else w/h may be used but not initialized.
>>
> 
> Please try more hard to write english. I do not understand what is typed
> above.

If w and h don't have initial values at declaration. So they might never get 
set if that last if statement evaluates to false.

So he suggests to add an else case like

if (s->width > 0 && s->height > 0) {
 w = s->width;
 h = s->height;
} else {
 w = 0;
 h = 0;
}

or whatever values might make sense.

Thilo


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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter

[Thilo Borgmann]

Am 14.08.19 um 15:14 schrieb Eugene:
> On 14.08.2019 13:06, Paul B Mahol wrote:
> 
>> On Wed, Aug 14, 2019 at 11:56 AM Thilo Borgmann 
>> wrote:
>>
>>> [...]
>>>
>>>>>> +static int config_output(AVFilterLink *outlink)
>>>>>> +{
>>>>>> +    AVFilterContext *ctx = outlink->src;
>>>>>> +    AVFilterLink *inlink = ctx->inputs[0];
>>>>>> +    V360Context *s = ctx->priv;
>>>>>> +    const AVPixFmtDescriptor *desc =
>>>>>> av_pix_fmt_desc_get(inlink->format);
>>>>>> +    const int depth = desc->comp[0].depth;
>>>>>> +    float remap_data_size = 0.f;
>>>>>> +    int sizeof_remap;
>>>>>> +    int err;
>>>>>> +    int p, h, w;
>>>>>> +    float hf, wf;
>>>>>> +    float mirror_modifier[3];
>>>>>> +    void (*in_transform)(const V360Context *s,
>>>>>> + const float *vec, int width, int height,
>>>>>> + uint16_t us[4][4], uint16_t vs[4][4], float
>>>>>> *du, float *dv);
>>>>>> +    void (*out_transform)(const V360Context *s,
>>>>>> +  int i, int j, int width, int height,
>>>>>> +  float *vec);
>>>>>> +    void (*calculate_kernel)(float du, float dv, int shift, const
>>>>> XYRemap4
>>>>>> *r_tmp, void *r);
>>>>>> +    float rot_mat[3][3];
>>>>>> +
>>>>>> +    switch (s->interp) {
>>>>>> +    case NEAREST:
>>>>>> +    calculate_kernel = nearest_kernel;
>>>>>> +    s->remap_slice = depth <= 8 ? remap1_8bit_slice :
>>>>>> remap1_16bit_slice;
>>>>>> +    sizeof_remap = sizeof(XYRemap1);
>>>>>> +    break;
>>>>>> +    case BILINEAR:
>>>>>> +    calculate_kernel = bilinear_kernel;
>>>>>> +    s->remap_slice = depth <= 8 ? remap2_8bit_slice :
>>>>>> remap2_16bit_slice;
>>>>>> +    sizeof_remap = sizeof(XYRemap2);
>>>>>> +    break;
>>>>>> +    case BICUBIC:
>>>>>> +    calculate_kernel = bicubic_kernel;
>>>>>> +    s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>>>>> remap4_16bit_slice;
>>>>>> +    sizeof_remap = sizeof(XYRemap4);
>>>>>> +    break;
>>>>>> +    case LANCZOS:
>>>>>> +    calculate_kernel = lanczos_kernel;
>>>>>> +    s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>>>>> remap4_16bit_slice;
>>>>>> +    sizeof_remap = sizeof(XYRemap4);
>>>>>> +    break;
>>>>>> +    }
>>>>>> +
>>>>>> +    switch (s->in) {
>>>>>> +    case EQUIRECTANGULAR:
>>>>>> +    in_transform = xyz_to_equirect;
>>>>>> +    err = 0;
>>>>>> +    wf = inlink->w;
>>>>>> +    hf = inlink->h;
>>>>>> +    break;
>>>>>> +    case CUBEMAP_3_2:
>>>>>> +    in_transform = xyz_to_cube3x2;
>>>>>> +    err = prepare_cube_in(ctx);
>>>>>> +    wf = inlink->w / 3.f * 4.f;
>>>>>> +    hf = inlink->h;
>>>>>> +    break;
>>>>>> +    case CUBEMAP_6_1:
>>>>>> +    in_transform = xyz_to_cube6x1;
>>>>>> +    err = prepare_cube_in(ctx);
>>>>>> +    wf = inlink->w / 3.f * 2.f;
>>>>>> +    hf = inlink->h * 2.f;
>>>>>> +    break;
>>>>>> +    case EQUIANGULAR:
>>>>>> +    in_transform = xyz_to_eac;
>>>>>> +    err = prepare_eac_in(ctx);
>>>>>> +    wf = inlink->w;
>>>>>> +    hf = inlink->h / 9.f * 8.f;
>>>>>> +    break;
>>>>>> +    case FLAT:
>>>>>> +    av_log(ctx, AV_LOG_ERROR, "Flat format is not accepted as
>>>>>> input.\n");
>>>>>> +    return AVERROR(EINVAL);
>>>>>> +    }
>>>>>> +
>>>>>> +

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter

[Thilo Borgmann]

Am 14.08.19 um 16:09 schrieb Paul B Mahol:
> On Wed, Aug 14, 2019 at 4:06 PM Thilo Borgmann 
> wrote:
> 
>> Am 14.08.19 um 15:14 schrieb Eugene:
>>> On 14.08.2019 13:06, Paul B Mahol wrote:
>>>
>>>> On Wed, Aug 14, 2019 at 11:56 AM Thilo Borgmann >>
>>>> wrote:
>>>>
>>>>> [...]
>>>>>
>>>>>>>> +static int config_output(AVFilterLink *outlink)
>>>>>>>> +{
>>>>>>>> +AVFilterContext *ctx = outlink->src;
>>>>>>>> +AVFilterLink *inlink = ctx->inputs[0];
>>>>>>>> +V360Context *s = ctx->priv;
>>>>>>>> +const AVPixFmtDescriptor *desc =
>>>>>>>> av_pix_fmt_desc_get(inlink->format);
>>>>>>>> +const int depth = desc->comp[0].depth;
>>>>>>>> +float remap_data_size = 0.f;
>>>>>>>> +int sizeof_remap;
>>>>>>>> +int err;
>>>>>>>> +int p, h, w;
>>>>>>>> +float hf, wf;
>>>>>>>> +float mirror_modifier[3];
>>>>>>>> +void (*in_transform)(const V360Context *s,
>>>>>>>> + const float *vec, int width, int height,
>>>>>>>> + uint16_t us[4][4], uint16_t vs[4][4],
>> float
>>>>>>>> *du, float *dv);
>>>>>>>> +void (*out_transform)(const V360Context *s,
>>>>>>>> +  int i, int j, int width, int height,
>>>>>>>> +  float *vec);
>>>>>>>> +void (*calculate_kernel)(float du, float dv, int shift, const
>>>>>>> XYRemap4
>>>>>>>> *r_tmp, void *r);
>>>>>>>> +float rot_mat[3][3];
>>>>>>>> +
>>>>>>>> +switch (s->interp) {
>>>>>>>> +case NEAREST:
>>>>>>>> +calculate_kernel = nearest_kernel;
>>>>>>>> +s->remap_slice = depth <= 8 ? remap1_8bit_slice :
>>>>>>>> remap1_16bit_slice;
>>>>>>>> +sizeof_remap = sizeof(XYRemap1);
>>>>>>>> +break;
>>>>>>>> +case BILINEAR:
>>>>>>>> +calculate_kernel = bilinear_kernel;
>>>>>>>> +s->remap_slice = depth <= 8 ? remap2_8bit_slice :
>>>>>>>> remap2_16bit_slice;
>>>>>>>> +sizeof_remap = sizeof(XYRemap2);
>>>>>>>> +break;
>>>>>>>> +case BICUBIC:
>>>>>>>> +calculate_kernel = bicubic_kernel;
>>>>>>>> +s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>>>>>>> remap4_16bit_slice;
>>>>>>>> +sizeof_remap = sizeof(XYRemap4);
>>>>>>>> +break;
>>>>>>>> +case LANCZOS:
>>>>>>>> +calculate_kernel = lanczos_kernel;
>>>>>>>> +s->remap_slice = depth <= 8 ? remap4_8bit_slice :
>>>>>>>> remap4_16bit_slice;
>>>>>>>> +sizeof_remap = sizeof(XYRemap4);
>>>>>>>> +break;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +switch (s->in) {
>>>>>>>> +case EQUIRECTANGULAR:
>>>>>>>> +in_transform = xyz_to_equirect;
>>>>>>>> +err = 0;
>>>>>>>> +wf = inlink->w;
>>>>>>>> +hf = inlink->h;
>>>>>>>> +break;
>>>>>>>> +case CUBEMAP_3_2:
>>>>>>>> +in_transform = xyz_to_cube3x2;
>>>>>>>> +err = prepare_cube_in(ctx);
>>>>>>>> +wf = inlink->w / 3.f * 4.f;
>>>>>>>> +hf = inlink->h;
>>>>>>>> +break;
>>>>>>>> +case CUBEMAP_6_1:
>>>>>>>> +in_transform = xyz_to_cube6x1;
>>>>>>>> +err = prepare_cube_in(ctx);
>>>>>>>> +wf = inlink->w / 3.f * 2.f;
&

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Thilo Borgmann]

Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> There seems to be no limit in the specification and upto 64k could be stored
> 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> can handle
> 
> An alternative to this patch would be a max_channels variable

There's a conformance file containing 512 channels, that should be the default 
max value.

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

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/alsdec: Fix integer overflow in decode_var_block_data()

[Thilo Borgmann]

Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> Fixes: signed integer overflow: 1927975249 - -514719744 cannot be represented 
> in type 'int'
> Fixes: 
> 16413/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5651206856245248
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/alsdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
> index 425cf73be9..4794556aad 100644
> --- a/libavcodec/alsdec.c
> +++ b/libavcodec/alsdec.c
> @@ -953,7 +953,7 @@ static int decode_var_block_data(ALSDecContext *ctx, 
> ALSBlockData *bd)
>  
>  // reconstruct difference signal for prediction (joint-stereo)
>  if (bd->js_blocks && bd->raw_other) {
> -int32_t *left, *right;
> +uint32_t *left, *right;
>  
>  if (bd->raw_other > raw_samples) {  // D = R - L
>  left  = raw_samples;
> 

LGTM

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Thilo Borgmann]

Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
> On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
>> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
>>> There seems to be no limit in the specification and upto 64k could be stored
>>> 64 is chooses as limit as thats also used for AAC and is what a int64 mask
>>> can handle
>>>
>>> An alternative to this patch would be a max_channels variable
>>
>> There's a conformance file containing 512 channels, that should be the 
>> default max value.
> 
> will apply with that value later

Decoding of that is already stopped via FF_SANE_NB_CHANNELS in lavc/internal.h.
That is currently set to 256U. I guess pushing that to 512U might already be 
enough without any change to single decoders?

Once fixed, I will add a FATE test for the 512 channel conformance file.

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Thilo Borgmann]

Am 19.08.19 um 23:22 schrieb Michael Niedermayer:
> On Mon, Aug 19, 2019 at 05:09:37PM +0200, Thilo Borgmann wrote:
>> Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
>>> On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
>>>> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
>>>>> There seems to be no limit in the specification and upto 64k could be 
>>>>> stored
>>>>> 64 is chooses as limit as thats also used for AAC and is what a int64 mask
>>>>> can handle
>>>>>
>>>>> An alternative to this patch would be a max_channels variable
>>>>
>>>> There's a conformance file containing 512 channels, that should be the 
>>>> default max value.
>>>
>>> will apply with that value later
>>
>> Decoding of that is already stopped via FF_SANE_NB_CHANNELS in 
>> lavc/internal.h.
>> That is currently set to 256U. I guess pushing that to 512U might already be 
>> enough without any change to single decoders?
> 
> the problem of out of memory is that the als decoder allocates some pretty
> large things per channel. A check on channels needs to happen before
> this.
> The existing checks didnt achieve that.
> 
> I can of course post a patchset that uses FF_SANE_NB_CHANNELS in als and
> bump it to the next number if people prefer this ?
> 
> Note though that increasing FF_SANE_NB_CHANNELS may also increase timeouts
> in other decoders.

I see the problem.
However, right now alsdec is fine with any number of channels and the CLI 
prevents decoding anything above FF_SANE_NB_CHANNELS (checks are in 
lavc/decoding.c and lavc/utils.c; this would also stop any FATE test on 512 
channels file).

So having alsdec check for a value higher than FF_SANE_NB_CHANNELS (like 512) 
would have no effect for CLI users, right?

-Thilo

>> Once fixed, I will add a FATE test for the 512 channel conformance file.
> 
> thx
> 
>>
>> -Thilo
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/alsdec: Limit maximum channels to 512

[Thilo Borgmann]

Am 20.08.19 um 16:52 schrieb Michael Niedermayer:
> There seems to be no limit in the specification and upto 64k could be stored
> 512 is choosen as limit as thats the maximum in a conformance sample
> 
> An alternative to this patch would be a max_channels variable
> 
> Fixes: OOM
> Fixes: 
> 16200/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5764788793114624
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Suggested-by: Thilo Borgmann 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/alsdec.c | 5 +
>  1 file changed, 5 insertions(+)

Patch 1 & 2 LGTM.

Will send a patch for FATE soonish after commit.

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

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

[FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2019 in Prague

[Thilo Borgmann]

Hi all,

FFmpeg has been accepted again for a booth at the LinuxDays 2019 in Prague, 
Czech Republic from October 5th to 6th!

Like last year, we hope to have a great conference with many users and fellow 
open-source projects attending! Find detailed information here:

https://www.linuxdays.cz/2019/en/

As of now, just me will attend for sure - any FFmpeg developer is welcome to 
join in and help with the booth duty!
We'll be provided free accomodation, so don't hesitate if you've interest in 
coming.

For all our users attending, we're always happy to collect your problematic 
samples (if you can find any ;) )!

Hope to meet you there!

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

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

[FFmpeg-devel] [PATCH] fate/als: Add test for conformance file with 512 channels.

[Thilo Borgmann]

Hi,

new fate test for many channels in ALS, like requested.

I already uploaded the corresponding file into fate-suite.
If there are no objections, I'll commit this in a day or two.

Thanks,
Thilo
From 5ed096ab3eac956f235e7924d52810b5ec9e8203 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 22 Aug 2019 21:21:12 +0200
Subject: [PATCH] fate/als: Add test for conformance file with 512 channels.

---
 tests/fate/als.mak  | 4 
 tests/ref/fate/mpeg4-als-conformance-09 | 1 +
 2 files changed, 5 insertions(+)
 create mode 100644 tests/ref/fate/mpeg4-als-conformance-09

diff --git a/tests/fate/als.mak b/tests/fate/als.mak
index ff2badf5ed..c7287dee86 100644
--- a/tests/fate/als.mak
+++ b/tests/fate/als.mak
@@ -7,5 +7,9 @@ endef
 
 $(foreach N,$(ALS_SUITE),$(eval $(call FATE_ALS_SUITE,$(N
 
+FATE_ALS += fate-mpeg4-als-conformance-09
+
+fate-mpeg4-als-conformance-09: CMD = crc -i 
$(TARGET_SAMPLES)/lossless-audio/als_09_512ch2k16b.mp4
+
 FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, ALS) += $(FATE_ALS)
 fate-als: $(FATE_ALS)
diff --git a/tests/ref/fate/mpeg4-als-conformance-09 
b/tests/ref/fate/mpeg4-als-conformance-09
new file mode 100644
index 00..b26276da91
--- /dev/null
+++ b/tests/ref/fate/mpeg4-als-conformance-09
@@ -0,0 +1 @@
+CRC=0xbf3e7189
-- 
2.17.2 (Apple Git-113)

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

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

Re: [FFmpeg-devel] [CALL] New FFmpeg developers meeting

[Thilo Borgmann]

Hi,

> Because of current overall toxic situation in FFmpeg, meeting will not be
> held until situation improves considerably.

in spite of that, Paul is fine with having a developer meeting as said on IRC. 

Therefore I propose to do a developer meeting in Zagreb, Croatia.
The location is well connected via flights within Europe and internationally, 
so I think it is good for a majority of developers.
Transportation expenses will be reimbursed and accommodation will be free, 
including shoulder nights.

I've setup a doodle-like thing to find a good common date for the meeting 
between IBC and VDD.
If you want to attend, fill in all the dates that comfort you here:

https://framadate.org/gwOce8QtcJPbz4hs

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] fate/als: Add test for conformance file with 512 channels.

[Thilo Borgmann]

Am 23.08.19 um 21:54 schrieb Michael Niedermayer:
> On Thu, Aug 22, 2019 at 09:23:49PM +0200, Thilo Borgmann wrote:
>> Hi,
>>
>> new fate test for many channels in ALS, like requested.
>>
>> I already uploaded the corresponding file into fate-suite.
>> If there are no objections, I'll commit this in a day or two.
>>
>> Thanks,
>> Thilo
> 
>>  fate/als.mak  |4 
>>  ref/fate/mpeg4-als-conformance-09 |1 +
>>  2 files changed, 5 insertions(+)
>> c64a085f51b0c6492247146b0386400b26f039e3  
>> 0001-fate-als-Add-test-for-conformance-file-with-512-chan.patch
>> From 5ed096ab3eac956f235e7924d52810b5ec9e8203 Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann 
>> Date: Thu, 22 Aug 2019 21:21:12 +0200
>> Subject: [PATCH] fate/als: Add test for conformance file with 512 channels.
> 
> Tested on linux x86-32 & 64, mingw32/64, qemu arm/mips

Pushed.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

[Thilo Borgmann]

Hi all,

FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
Republic during October 6th to 7th!

We've made contact during this years CLT. This is our first attendance to this 
end-user conference that has a similar program like the Linux Days in Chemnitz 
- means mainly booths and talks as well as a lot of users and fellow 
open-source projects. Find detailed information here:

https://www.linuxdays.cz/2018/en/

Currently, I'm the only staff member registered - any other developer is 
welcome to join in! Prague is quite affordable regarding travel & accomodation, 
so don't hesitate if you've interest in coming.

Hope to meet you there!

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

Re: [FFmpeg-devel] [PATCH] libavdevice: allow cropping avfoundation screen capture

[Thilo Borgmann]

Am 03.10.18 um 17:05 schrieb alan.birt...@sony.com:
>> I've developed  a patch to add an option to allow cropping of the
> 
>> avfoundation screen capture.
> 
>> Note that if the captured width is not a multiple of 16 then
> 
>> https://trac.ffmpeg.org/ticket/5654 will be triggered.
> 
> Is there anything more I need to do to get this patch applied?

Sorry for delay I'm quite busy right now. Will have a look during the weekend!

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

Re: [FFmpeg-devel] [PATCH] libavdevice: allow cropping avfoundation screen capture

[Thilo Borgmann]

Hi,

Am 17.09.18 um 05:53 schrieb alan.birt...@sony.com:
> 2018-09-13 17:52 GMT+02:00,
> alan.birt...@sony.com
> mailto:alan.birt...@sony.com>>:
> 
> 
> 
>> I've developed  a patch to add an option to allow cropping of the
> 
>> avfoundation screen capture.
> 
>> Note that if the captured width is not a multiple of 16 then
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ffmpeg.org_ticket_5654&d=DwIGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=DZ-pOCz_nOIJfdxhe1zNBFwbfB1WJzA5E9fM05n7yCs&m=KjmPPiSi2W239ebqa6B1xWjvn3F0kSW7fSlmVx4n70s&s=1a0Z8KLo3pYG0TjLl0zZzlF3E68mO58ssmKjXnW9yYg&e=
>> will be triggered.

This had been fixed in a259501e5a6ed07d76ce5d615123148b9b68d9f8.


> From 96b9cd33022bb6f3147174085c9ff2417cd006bc Mon Sep 17 00:00:00 2001
> From: Alan Birtles 
> Date: Thu, 13 Sep 2018 15:56:55 +0100
> Subject: [PATCH] allow specifying "cropRect" for avfoundation screen capture
> 
> ---
>  libavdevice/avfoundation.m | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index fc6428a..c285984 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -97,6 +97,10 @@
>  
>  int capture_cursor;
>  int capture_mouse_clicks;

> +int capture_crop_x;
> +int capture_crop_y;
> +int capture_crop_width;
> +int capture_crop_height;

Please remove the "capture_" prefix - if you see it fit, please use something
like "screen_".


>  int list_devices;
>  int video_device_index;
> @@ -750,6 +754,13 @@ static int avf_read_header(AVFormatContext *s)
>  capture_screen_input.capturesMouseClicks = NO;
>  }
>  
> +if (ctx->capture_crop_x != 0 ||
> +ctx->capture_crop_y != 0 ||
> +ctx->capture_crop_width != 0 ||
> +ctx->capture_crop_height != 0) {
> +capture_screen_input.cropRect = 
> CGRectMake(ctx->capture_crop_x, ctx->capture_crop_y, ctx->capture_crop_width, 
> ctx->capture_crop_height);
> +}
> +

Unfortunately, AVFoundation does not allow for easily retrieving the screen
resolution before the capture session starts... So please add a warning if
crop_width or crop_height are 0 / unspecified. Also the if should check for >=1
in width and height, as well as >= 0 for x and y to avoid invalid cropping 
regions.

>  video_device = (AVCaptureDevice*) capture_screen_input;
>  capture_screen = 1;
>  #endif
> @@ -799,6 +810,13 @@ static int avf_read_header(AVFormatContext *s)
>  } else {
>  capture_screen_input.capturesMouseClicks = NO;
>  }
> +
> +if (ctx->capture_crop_x != 0 ||
> +ctx->capture_crop_y != 0 ||
> +ctx->capture_crop_width != 0 ||
> +ctx->capture_crop_height != 0) {
> +capture_screen_input.cropRect = 
> CGRectMake(ctx->capture_crop_x, ctx->capture_crop_y, ctx->capture_crop_width, 
> ctx->capture_crop_height);
> +}

Same here.

>  }
>  }
>  #endif
> @@ -1069,6 +1087,9 @@ static int avf_close(AVFormatContext *s)
>  { "video_size", "set video size", offsetof(AVFContext, width), 
> AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },
>  { "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM 
> },
>  { "capture_mouse_clicks", "capture the screen mouse clicks", 
> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
> AV_OPT_FLAG_DECODING_PARAM },

> +{ "capture_crop_x", "crop the screen capture to the specified x offset", 
> offsetof(AVFContext, capture_crop_x), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "capture_crop_y", "crop the screen capture to the specified y offset", 
> offsetof(AVFContext, capture_crop_y), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "capture_crop_size", "crop the screen capture to the specified size", 
> offsetof(AVFContext, capture_crop_width), AV_OPT_TYPE_IMAGE_SIZE,  {.str = 
> NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },

See naming suggestions from above. Also, please change to:

"crop the screen capture starting at the specified x offset"

for x and y. Also, please add a description of the new parameters to
doc/indevs.texi. Please add a warning in the code that these options are without
effect whenever a non-screen device is selected but these options are set
(results in unexpected output). You might suggest in the message to apply an
additional non-avfoundation crop filter in the filter chain.

Thanks,
Thilo
___
ffmpeg-devel ma

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

[Thilo Borgmann]

Hi again,

> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
> Republic during October 6th to 7th!
> 
> [...] Find detailed information here:
> 
> https://www.linuxdays.cz/2018/en/


about two weeks ago the Linux Days Prague took place. For limited space and 
luggage, I could only show one version of our usual demos. However, even in a 
low resolution and low framerate, the motion vector overlay attracted a lot of 
people.

The conference is quite similar to the Chemnitzer LinuxTage, however I met some 
more professional users there like we are used to in Chemnitz. There were also 
a lot of users quite familiar with FFmpeg already so both groups gave me a lot 
of quite interesting conversations.

Being the only booth staff this time, I could not attend any talks, though. 
Therefore I cannot comment on their quality but many of them were given in 
English. They are, however, live streamed in 4K and later stored on a YouTube 
channel. I visited the streaming team and they got their FFmpeg CLI usage well 
done (works & no problems).

We are more than welcome to give talks / workshops there next year. In contrast 
to Chemnitz, even the accomodation for me was free in a nearby hotel! Which 
will significantly reduce my reimbursement request later to something like 30€ 
in total.

Also, I've met a very friendly guy who has sponsored a Raspberry Pi 3 (Model 
B+).
If anyone wants to have it for some specific purpose related to FFmpeg 
development, I'm happy to ship it to any other FFmpeg developer! Who want to do 
something useful with it?
Otherwise I'll set it up as a new demo machine for conferences to come - It was 
actually sponsored because my Intel-based IoT board performed so badly, which 
was however based on my lazyness to setup HW capabilities accordingly - so 
anyway we'll make the kind sponsor more happy with a better hardware setup next 
time.

Finally, I would very much like to have more company at the booth next year! :)

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

[FFmpeg-devel] GSoC 2018 mentor summit review

[Thilo Borgmann]

Hi folks,

last weekend we attended the annual GSoC mentor summit. This time, it was Pedro 
Arthur and myself going there. As usual, there have been a huge amount of 
interesting fellow open-source projects around and we've met a lot of 
interesting people.

There have been a lot of interesting sessions like last year. Of course, many 
topics have been quite similar and development/progress in some areas are not 
too fast. The usual suspects have been in the general audio/video/multimedia 
session (VideoLAN, Kodi, Mixxx, MuseScore, Apertus, and others). Apart from the 
usual chat, we ha a general discussion about multimedia apps in the future - in 
general about moving away from a bare desktop application to a more web and/or 
service based application. More of interest for the front-end applications than 
for us being a library, of course.

There has been a session about OSS licences again, I can't remember a severe 
change of information given compared to last year, so [1] should still be an 
excellent resource of more information.

The team from ScummVM is interested in improving one of the gaming codecs and 
maybe someone will be into this fun :) They should provide us some samples 
containing yet ignored side-data, used for sprite-like animation of decoded 
sprite content onto the output image/canvas (if I understood correctly, what 
they were explaining).

We also have an open offer for cooperation/support by Red Hen Lab [2]. They are 
recording and transcoding a massiva amount of TV broadcastsa around the world 
including more rare formats like DTMB (chineese TV) and ISDB (JP and southern 
american TV). They would be able to provide us with any samples we might find 
interesting. If anyone is interested, send me a mail.

There has been an announcement about an upcoming new Google program from 
Google's OSPO. There will be a "Season of Docs", aiming to reach out for 
technical writers to enhance documentation of open source programs. In contrast 
to GSoC, this shall not be a sponsored work but pro bono. More details yet to 
be disclosed!

Finally, a community driven overview of the sessions given and notes taken per 
session can be found here [3], for anyone interested in specifics of that or 
the corresponding notes.

It was my pleasure to come to know Pedro in person - maybe he has some more 
comments about the summit and hin impressions.

Cheers,
Thilo

[1] https://opensource.org/licenses/

[2] http://www.redhenlab.org/

[3] 
https://docs.google.com/document/d/1nNSud67RB_39HERpPdn-r6U3ANiC31VWHiFkKAoENBI/edit?ts=5bc91932#heading=h.lbox8n3en4ka
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

[Thilo Borgmann]

Am 20.10.18 um 17:49 schrieb Thomas Volkert:
> 
> On 20.10.2018 17:15, Thilo Borgmann wrote:
>> Hi again,
>>
>>> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
>>> Republic during October 6th to 7th!
>>>
>>> [...] Find detailed information here:
>>>
>>> https://www.linuxdays.cz/2018/en/
>> [..]
>>
>> Being the only booth staff this time, I could not attend any talks, though. 
>> Therefore I cannot comment on their quality but many of them were given in 
>> English. They are, however, live streamed in 4K and later stored on a 
>> YouTube channel. I visited the streaming team and they got their FFmpeg CLI 
>> usage well done (works & no problems). [..]
> 
> It seems that all videos got already removed from Youtube so far.

AFAICT the live streams had been don and some more time would be needed to 
upload them to a normal channel.
I don't have any further information.

-Thilo


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

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

[Thilo Borgmann]

Am 21.10.18 um 19:59 schrieb Thilo Borgmann:
> Am 20.10.18 um 17:49 schrieb Thomas Volkert:
>>
>> On 20.10.2018 17:15, Thilo Borgmann wrote:
>>> Hi again,
>>>
>>>> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech 
>>>> Republic during October 6th to 7th!
>>>>
>>>> [...] Find detailed information here:
>>>>
>>>> https://www.linuxdays.cz/2018/en/
>>> [..]
>>>
>>> Being the only booth staff this time, I could not attend any talks, though. 
>>> Therefore I cannot comment on their quality but many of them were given in 
>>> English. They are, however, live streamed in 4K and later stored on a 
>>> YouTube channel. I visited the streaming team and they got their FFmpeg CLI 
>>> usage well done (works & no problems). [..]
>>
>> It seems that all videos got already removed from Youtube so far.
> 
> AFAICT the live streams had been don and some more time would be needed to 
> upload them to a normal channel.
> I don't have any further information.

The 57 videos given in the playlist at

https://www.linuxdays.cz/2018/video/

seem to work for me.

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

[FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Thilo Borgmann]

Hi all,

I'm very sorry that it took me so long to send this to the list, finally.
Since this is an everlasting topic for years, I wanted to deal
thoroughly with it to have a chance to actually influence the situation.

Like in many previous years/sessions about FFmpeg development, the topic of
hostility at the ML and IRC channel was discussed yet another time. There
have been several voices at this year's session that are still unhappy
with the current hostility in the FFmpeg community. So this point has been
discussed in the audience for a while. However, there has also been a voice
claiming that the current situation and regulation by our CoC is ok and working.

According to my experience, these discussions lead to two ends. First,
is considering the FFmpeg community to be a hostile environment shared by a
majority of the community so that any further thoughts to try to change this are
valid or not? Second, assuming it is a majority that dislikes current hostility,
what to do about it to improve the situation?

Long ago, JB made a proposal to overcome this by getting a community committee
to act upon hostile behavior in our environment and sanction the respective
authors. This proposal has been brought up again regarding the question of how
to proceed and like in the previous years, this proposal raised no rejections
from anybody present (this and in the previous years).

In the end, the outcome of this VDDs FFmpeg session has been that I bring this
proposal to the mailing list, finally. Therefore, I took the time to talk to
several people not only about the proposal itself but also about the experience
of other communities having such a committee driven mechanism of dealing with
CoC conflicts. From that the idea emerged to get an overview of the actual 
community
opinion of things is to conduct a simple survey about this question. So this is
exactly what I'd like to do next to giving the mere proposal.

The proposal of a community committee summarized:

- A committee is to be created consisting of community members that are voted
into it
- This committee can (upon request) sanction violations of our CoC by its given
powers
- The committee is object to reelection every year

A more detailed possible implementation of the proposal is attached as a patch 
to
our developers documentation. The survey is done to get an idea of what the 
community
thinks about that matter and its proposed solution.

The survey shall be conducted for everyone to participate freely, so a simple
thread on the mailing list would hardly be suitable and will most likely end in
endless discussions. To help with that, we've set up a survey that can be done 
completely
anonymously by sending out private tokens to all possible participants. Even 
the survey
admins cannot map given survey answers to a person/token.

Please note that this survey is _not_ meant to be a vote about the proposal. It 
is to
determine if we should actually have a refinement/vote on instantiating such a
community committee - depending on the community's point of view.

I will start this survey and sending out tokens directly to every subscriber of
the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to
participate in the survey, you can send me a private mail before that data to
exclude your mail address from the participants lists. Afterwards you can click
the link in the mails to opt out of the survey yourself. The survey will end on
Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the 
results
of the survey here in this thread. 

I'd really appreciate participation in the survey from everyone. I'd like to 
ask to file
just one survey for every mail address you might have registered here - you can 
opt-out
or just ignore additional mails. I'm sorry for spam for everyone not reading 
this thread.
Many thanks to the KDE community and Lydia in particular for discussion and 
supporting us
with the survey infrastructure.

Thanks,
Thilo
From 777631a9181ccb549170409b7cf9c5934ab6aeb8 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 22 Nov 2018 19:49:18 +0100
Subject: [PATCH] doc/developers: Add Community Committee

---
 doc/developer.texi | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 5c342c9106..5c4014b7de 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -451,6 +451,70 @@ instead and point them in the right direction.
 Finally, keep in mind the immortal words of Bill and Ted,
 "Be excellent to each other."
 
+@chapter Community Committee
+
+The objective of the community committee is to sustain an environment as 
described
+by the code of conduct. It is to protect the dignity of each member of the 
community
+and to stop personal harassment of any kind. It is not to interfere with any 
other
+aspects of the development process.
+
+Further on it is to im

Re: [FFmpeg-devel] Budding developer

[Thilo Borgmann]

Am 22.11.18 um 21:17 schrieb Tomas Härdin:
> fre 2018-11-23 klockan 00:58 +0530 skrev Sid Sharma:
>> So I am currently pursuing my degree in computer science but I believe I
>> have a pretty good foundation in C and also know my way around assembly and
>> was wondering if the GSoC is the right place for me or am I aiming too
>> high.
> 
> C + asm are certainly very relevant skills

Indeed. There is an easy way to figure out if your knowledge is sufficient -
just pic a topic/patch/whatever and try to submit a fixing patch for the issue.
You will find some ideas at the links Tomas had written.

You can always ask for guidance if in doubt, in the bugtracker or the ML.


>> I am currenty in first year but a super geek. So can you guide me how
>> this  works as I am new to opensource and would like to have a project
>> under my belt. Please let me know if I also have to create a CV for the
>> same.

Nothing alike will be needed. You are just welcome to contribute.


> I don't know how far along the plans for GSoC 2019 are, but if you have
> a project idea you could pitch it. There's also some useful information
> and ideas on the wiki(s):
> 
> https://trac.ffmpeg.org/wiki/WikiStart
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
> https://wiki.multimedia.cx/index.php/FFmpeg_Summer_Of_Code
> https://wiki.multimedia.cx/index.php/Small_FFmpeg_Tasks
> 
> Not all of this may be up to date, and it might not be all of it, but
> it should give an idea at least.

Well all we know is that there will be a GSoC 2019. Nobody knows if FFmpeg gets 
selected as an org again.
As Tomas said, you can absolutely create your own project proposal like the 
ones you will find on trac.
Makes little sense before knowing if FFmpeg will participate again, though.

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

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Thilo Borgmann]

Am 22.11.18 um 22:58 schrieb Rostislav Pehlivanov:
> On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann  wrote:
> 
>>
>> Please note that this survey is _not_ meant to be a vote about the
>> proposal. It is to
>> determine if we should actually have a refinement/vote on instantiating
>> such a
>> community committee - depending on the community's point of view.
>>
> 
> Spamming (which this would certainly be a textbook definition of) every
> subscriber ever (including those who forgot) is unacceptable.

All subscribers are per definition interested in FFmpeg development. 
I don't see how this should be spam in general to this audience.


> +Further on it is to impose any sanctions related to violations of the code of
>> +conduct only if these incidents are brought up to its attention from 
>> directly
>> +involved parties of such an incident.
>>
>> Violations should be limited to publicly logged IRC channels or the ML.
> Otherwise without proof this will end up as a "but they said" situation.

Agree.


> ++ at subheading <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> Committee members
>> +
>> +The community committee consists of three elected individuals. Committee 
>> members are
>> +elected for a period of one year and are automatically removed from the 
>> committee after
>> +that period. Reelection of committee members for the following period is 
>> possible.
>>
>> Three members is far too low and would be prone to bias. 5 or 7 would be
> better.

A question I discussed with many others. I don't have a strong opinion, 3/5/7 
have always been the options. Feel free to put that to discussion again.


>> +
>> +If for any reason a current member of the committee wishes to leave the 
>> committee, the
>> +whole committee is to be reelected. No former committee members having left 
>> the committee
>> +on their own wish can be a candidate for the successor committee.
>>
>> That last sentence is random.

Not quite. It prevents "blocking" attempts by stepping back and getting elected 
again. The whole committee is to be voted upon again to prevent biasing 
attempts within the committee. Or I might see why you think this could not 
happen.


> +The vote has to implement a direct, free, equal and secret election.
>> +The results are to be publicly available.
>> +The election should be completed not later than the end of the ongoing 
>> period.
>> +Any community member can call on itself or any other person to be a 
>> candidate for an election.
>>
>> What if a majority of the committee is biased and bans everyone they
> disagree with to take over the project? They certainly could.
> What if the committee's decision is something the majority of the
> developers disagree with?

Nothing prevents the community to release the committee it instantiated. A 
community vote on (this or whatever) is not object to the powers of the 
committee.


> This is why I'm against formalizing such prodecures. They're too inflexible
> and absolute, and end up being abused or overused (like videolan's weekly
> temporary bannings I've heard of).

Didn't heard of these by now. However, in discussing with people, it revealed 
there are two ways to go with that. Either, you give a set of rules and define 
everything in these and can't handle anything else. Or, you set one rule to be 
 and have each thing in relation to that.

Experience says, the first possibility comes with people navigating on the 
bleeding edge of the rules exploiting every grey zone there might be. The 
second comes with people having an other interpretation of the "one rule" in 
contrast to the committee.
Well, I prefer the second way. But this question you can also put to discussion 
again.



> Furthermore why do you bring this up now at all? We haven't had accidents
> of this nature in quite some time. In fact the last time it was the ML
> admin's random incorrect decision to block a discussion which ended up
> being a problem that everyone disagreed with. And that was 11 months ago.

You have been at VDD, Rostislav. We had this session, people made this a topic, 
I agreed on summing up and sending it to the list. I've not stumbled across 
such incidents lately, too. However, I by far do not read every mail here or do 
watch IRC at all - people still having this impression are a good enough reason 
for me.

Personally, even if these accidents would have ceased to happen - history tells 
us we might use a better way of dealing with it, since CoC violations are an 
ever repeating thing to happen.

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

Re: [FFmpeg-devel] [PATCH v2] lavfi/vf_colorconstancy: add weighted_greyedge

[Thilo Borgmann]

>> V2 changes:
>> - fixed some spelling mistakes in filters.texi
>> - fixed some text format error in filters.texi

Will apply soon if there are no further comments.

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

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Thilo Borgmann]

Hi again,

> I'm very sorry that it took me so long to send this to the list, finally.
> Since this is an everlasting topic for years, I wanted to deal
> thoroughly with it to have a chance to actually influence the situation.
> 
> Like in many previous years/sessions about FFmpeg development, the topic of
> hostility at the ML and IRC channel was discussed yet another time. There
> have been several voices at this year's session that are still unhappy
> with the current hostility in the FFmpeg community. So this point has been
> discussed in the audience for a while. However, there has also been a voice
> claiming that the current situation and regulation by our CoC is ok and 
> working.
> 
> According to my experience, these discussions lead to two ends. First,
> is considering the FFmpeg community to be a hostile environment shared by a
> majority of the community so that any further thoughts to try to change this 
> are
> valid or not? Second, assuming it is a majority that dislikes current 
> hostility,
> what to do about it to improve the situation?
> 
> Long ago, JB made a proposal to overcome this by getting a community committee
> to act upon hostile behavior in our environment and sanction the respective
> authors. This proposal has been brought up again regarding the question of how
> to proceed and like in the previous years, this proposal raised no rejections
> from anybody present (this and in the previous years).
> 
> In the end, the outcome of this VDDs FFmpeg session has been that I bring this
> proposal to the mailing list, finally. Therefore, I took the time to talk to
> several people not only about the proposal itself but also about the 
> experience
> of other communities having such a committee driven mechanism of dealing with
> CoC conflicts. From that the idea emerged to get an overview of the actual 
> community
> opinion of things is to conduct a simple survey about this question. So this 
> is
> exactly what I'd like to do next to giving the mere proposal.
> 
> The proposal of a community committee summarized:
> 
> - A committee is to be created consisting of community members that are voted
> into it
> - This committee can (upon request) sanction violations of our CoC by its 
> given
> powers
> - The committee is object to reelection every year
> 
> A more detailed possible implementation of the proposal is attached as a 
> patch to
> our developers documentation. The survey is done to get an idea of what the 
> community
> thinks about that matter and its proposed solution.
> 
> The survey shall be conducted for everyone to participate freely, so a simple
> thread on the mailing list would hardly be suitable and will most likely end 
> in
> endless discussions. To help with that, we've set up a survey that can be 
> done completely
> anonymously by sending out private tokens to all possible participants. Even 
> the survey
> admins cannot map given survey answers to a person/token.
> 
> Please note that this survey is _not_ meant to be a vote about the proposal. 
> It is to
> determine if we should actually have a refinement/vote on instantiating such a
> community committee - depending on the community's point of view.
> 
> I will start this survey and sending out tokens directly to every subscriber 
> of
> the ffmpeg-devel mailing list on this Friday, Nov 23rd. If you don't want to
> participate in the survey, you can send me a private mail before that data to
> exclude your mail address from the participants lists. Afterwards you can 
> click
> the link in the mails to opt out of the survey yourself. The survey will end 
> on
> Mondday, Dez 3nd (a little more than a week). Afterwards, I will post the 
> results
> of the survey here in this thread. 
> 
> I'd really appreciate participation in the survey from everyone. I'd like to 
> ask to file
> just one survey for every mail address you might have registered here - you 
> can opt-out
> or just ignore additional mails. I'm sorry for spam for everyone not reading 
> this thread.
> Many thanks to the KDE community and Lydia in particular for discussion and 
> supporting us
> with the survey infrastructure.


the survey ended on Monday, results are given below.

It has been criticized that the survey does not cover more detailed questions 
about the folks who do not think that the community is currently hostile. 
Several people thought about the survey design and yet that part was not 
covered. We might go for another survey on that part if people really want it - 
I guess we can run another one on the KDE infrastructure. Not to perceive the 
community to be hostile does not mean to reject a community committee (or 
changes to the CoC or other related actions), though. Also, that Q2 to Q4 only 
appeared if the previous answer was yes (in the sense of a hostile environment) 
has been criticized. Well, the assumption was that if you feel no to be your 
answer to a question, all follow-ups would not fit into that - why to ask if 

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

[Thilo Borgmann]

Am 24.02.20 um 22:41 schrieb Lou Logan:
> On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
>> It fundamentally depends on an API that has been deprecated for five
>> years, has seen no commits since that time and is of highly dubious
>> usefulness.
>> ---
>>  doc/filters.texi|  32 ---
>>  libavfilter/Makefile|   1 -
>>  libavfilter/allfilters.c|   1 -
>>  libavfilter/vf_qp.c | 183 
>>  tests/fate/filter-video.mak |   7 +-
>>  tests/ref/fate/filter-pp2   |   1 -
>>  tests/ref/fate/filter-pp3   |   1 -
>>  7 files changed, 1 insertion(+), 225 deletions(-)
>>  delete mode 100644 libavfilter/vf_qp.c
>>  delete mode 100644 tests/ref/fate/filter-pp2
>>  delete mode 100644 tests/ref/fate/filter-pp3
> 
> Fine with me. I've never seen it used by anyone.

I'm not fine with it. Declaring it's {use | use case} not existent is no 
arguments whatsoever in reality.

Also, removing some functionality needs an argument - it is not keeping some 
functionality needs an argument.

Nobody technically elaborates Paul's statement that it should go into side 
data. WTF? The compromise isn't even considered?

Let's dig some trenches, shall we?

And how come some obvious "use cases" / "needs" like [1] come into play? Or do 
we declare not continued discussions non-existent now, too?

And how comes, if Michael's investigation, that all of this is based on use of 
_a function_ that is deprecated instead of direct access of AVFrame's fields is 
the cause of all of this?

Shame on all of us.

-Thilo

[1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247401.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

[Thilo Borgmann]

Am 25.02.20 um 11:28 schrieb Anton Khirnov:
> Quoting Thilo Borgmann (2020-02-24 23:07:48)
>> Am 24.02.20 um 22:41 schrieb Lou Logan:
>>> On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
>>>> It fundamentally depends on an API that has been deprecated for five
>>>> years, has seen no commits since that time and is of highly dubious
>>>> usefulness.
>>>> ---
>>>>  doc/filters.texi|  32 ---
>>>>  libavfilter/Makefile|   1 -
>>>>  libavfilter/allfilters.c|   1 -
>>>>  libavfilter/vf_qp.c | 183 
>>>>  tests/fate/filter-video.mak |   7 +-
>>>>  tests/ref/fate/filter-pp2   |   1 -
>>>>  tests/ref/fate/filter-pp3   |   1 -
>>>>  7 files changed, 1 insertion(+), 225 deletions(-)
>>>>  delete mode 100644 libavfilter/vf_qp.c
>>>>  delete mode 100644 tests/ref/fate/filter-pp2
>>>>  delete mode 100644 tests/ref/fate/filter-pp3
>>>
>>> Fine with me. I've never seen it used by anyone.
>>
>> I'm not fine with it. Declaring it's {use | use case} not existent is
>> no arguments whatsoever in reality.
>>
>> Also, removing some functionality needs an argument - it is not
>> keeping some functionality needs an argument.
> 
> I disagree with that. Keeping code around is not free, as Vittorio
> already said - it is a burden in many ways. So I believe all code needs
> continued justification for its existence - not just "it was added in
> the past so it stays in forever". Note that I'm not saying it needs to
> be mainstream or very popular - I am fine with obscure features that
> are only useful to a few people in highly special cases (given they are
> not unduly intrusive and those people are willing to maintain them). But
> so far in this thread, there has been no actual use presented for
> exporting and passing around QP tables. None whatsoever.
> 
> Most objections here are like yours - it's a) a feature and b) someone
> somewhere sometime might conceivably want to use it, so it must not be
> removed. Michael's reponse is the only one that comes close to having a
> use case, but even he says that he's unsure of the usefulness of the
> actual QP tables and that it's largely theoretical.
> 
> I believe I did more structural changes to the libraries than most
> people and in my experience these obsolete features from mplayer days
> are a MASSIVE maintenance pain. The amount of effort required to keep
> them working is simply not justified when essentially nobody uses them.
> 
> IMO these demands that they all be preserved forever is endangering the
> project. If making changes becomes too hard, people stop making them.
> They move to other places that are less hostile to change. We are at
> risk of turning into a repository of obscure old codecs and filters and
> getting overtaken by leaner projects like dav1d (yes it's supposed to be
> AV1-only, but that can change).
> 
>>
>> Nobody technically elaborates Paul's statement that it should go into side 
>> data. WTF? The compromise isn't even considered?
>>
>> Let's dig some trenches, shall we?
>>
>> And how come some obvious "use cases" / "needs" like [1] come into play? Or 
>> do we declare not continued discussions non-existent now, too?
> 
> The patch in your link is not using this API. Precisely because this API
> is inadequate for anything newer than MPEG4 ASP. If anything, it's an
> additional argument in favor of my patches.

My actual point about that patch was that there is a use case to extract QP 
tables for more current codecs. Suggests this use case is also there for less 
current ones which says we should not just remove this possibility.

If that patch is avoiding the deprecated things, could it be applied to the 
older codes and supersede vf_qp? (And I have no clue whether or not)
And would that not go into the direction Paul suggested?


>> And how comes, if Michael's investigation, that all of this is based on use 
>> of _a function_ that is deprecated instead of direct access of AVFrame's 
>> fields is the cause of all of this?
>>
>> Shame on all of us.
> 
> WTF? What shame?

I am ashamed that I do read most arguments here as merely black-and-white 
statements.
That might be considered, as I admit, as an overreaction and I probably should 
not have written.
However, that is also why I suggested to dig trenches.


> I am sending patches, in good faith, that I believe will improve the
> project. People may (and do) object to them. As long as the 

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

[Thilo Borgmann]

Am 26.02.20 um 16:26 schrieb Jean-Baptiste Kempf:
> On Wed, Feb 26, 2020, at 15:46, Paul B Mahol wrote:
>> On 2/26/20, Jean-Baptiste Kempf  wrote:
>>> Yo,
>>>
>>> On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote:
>>>>> The patch in your link is not using this API. Precisely because this API
>>>>> is inadequate for anything newer than MPEG4 ASP. If anything, it's an
>>>>> additional argument in favor of my patches.
>>>>
>>>> My actual point about that patch was that there is a use case to
>>>> extract QP tables for more current codecs. Suggests this use case is
>>>> also there for less current ones which says we should not just remove
>>>> this possibility.
>>>
>>> I think this is the right question:
>>> "Are there actual valid use cases to do it?"
>>>
>>> I remember that last year, there was an extractqp for h264 patches from
>>> Google, for example.

That should be the patch I linked to.

-Thilo

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

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

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

[Thilo Borgmann]

Am 27.02.20 um 11:56 schrieb Lynne:
> Feb 27, 2020, 09:09 by agho...@teknik.io:
> 
>> February 26, 2020 12:27 PM, "Anamitra Ghorui"  wrote:
>>
>>> c. I have been looking at the decoder/encoder/parser of the BMP format
>>> (which is one of the simplest image formats), the actual decoding work
>>> (according to me), i.e. Finding the magic numbers, seeing the various
>>> segments is being done by the decoder function and not the parser.
>>>
>>
>> I meant to say, "the actual 'parsing' work, according to me, is
>> being done by the decoder"
>>
>> I'm sorry if I had come off as rude in my post. It wasn't my intention.
>>
> 
> AFAIK, flif isn't stable (no spec, bitstream may change) and is kind of dead 
> since the author
> moved on to work on JPEG XL to my knowledge.
> 
> I don't think we should be implementing this decoder.

We had have this discussion before creating a project out of it.
They proclaimed it stable themselves. What do we care if their author now works 
on something else?

Anamitra, please don't get confused about that.

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

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

Re: [FFmpeg-devel] Regarding GSoC 2020 project proposal

[Thilo Borgmann]

Hi,

Am 04.03.20 um 13:56 schrieb YATENDRA SINGH:
> Thank you for explaining the procedure.
> I have posted my own project proposal on the page you had instructed me to.
> Looking forward to the feedback.

I moved that to the "Your own project idea" section.
I also added a 'proposed by:' field to it, please update that with your contact 
information (mail & IRC nickname, if you have both). Make it easy for 
potentially interested mentors to contact you.

You should also not wait for anyone contacting you about that matter. You can 
search through the relevant code in the FFmpeg codebase looking for authors of 
code related to your project. You might consider getting in touch with them 
asking for mentoring you during the summer. You can also do a query for mentors 
on IRC. Don't get spam-like though ;)

-Thilo



> On Tue, Mar 3, 2020 at 10:19 PM Pedro Arthur  wrote:
> 
>> Hi
>>
>> Em ter., 3 de mar. de 2020 às 09:24, YATENDRA SINGH
>>  escreveu:
>>>
>>> Hi,
>>> I am a third year CSE student at the Indian Institute of Technology
>> Bhilai,
>>> and would like to contribute to ffmpeg this year. I have
>>> relevant experience with Machine Learning and would like to work on
>>> improving the video frame interpolation already implemented. With such a
>>> plethora of great Machine Learning Algorithms being published every year
>> at
>>> prestigious conferences I would aim to read the relevant academic papers
>>> and implement the best suited technique for the task. For example, Depth
>>> Aware Video Frame Interpolation (DAIN CVPR-2019) is supposedly the state
>> of
>>> the art method on Vimeo90k and MiddleBury
>>>  but at the
>> same
>>> time Frame Interpolation with Generative Adversarial Network(FIGAN), uses
>>> not CNN but multi-scale synthesis( MS ) to get higher speeds.
>>> Looking forward to hearing from you soon.
>>>
>>> Yatendra SIngh
>>> Frame Interpolation with Multi-Scale Deep Loss Functions and Generative
>>> Adversarial NetworksFrame Interpolation with Multi-Scale Deep Loss
>>> Functions and Generative Adversarial NetworksFrame Interpolation with
>>> Multi-Scale Deep Loss Functions and Generative Adversarial Networks
>>
>> I suppose this project is your own idea as it is not listed in the
>> projects page, right?
>>
>> I think it would be good to add you idea under "Your Own Project Idea"
>> section in [1] adding as much information as possible so that we can
>> evaluate your idea and possible assign a mentor / backup mentor.
>> A few things I think are important to evaluate your project are:
>> *have a well defined "expected result", will it be a filter? or
>> something else? we already have a dnn module and a dnn_processing
>> filter, will your project be using it?
>>
>> *what is the amount of work that will be done during the project, more
>> or less this is related to above "expected result"
>>
>> *define a qualification task, we can discuss it after the above is define
>>
>> *sell your idea (not strictly necessary but may help evaluating your
>> project), why is it useful feature to have, what improvements it
>> brings, etc
>>
>> [1] -
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020#YourOwnProjectIdea
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

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

[FFmpeg-devel] [PATCH] lavd/avfoundation: Add basic transport control observation, for capable devices.

[Thilo Borgmann]

Hi,

fixes infinite loop waiting for input using e.g. tape devices that suport 
transport control.

-Thilo
From 656f1fe2a91bda6099d0ed3848dce9aec55c8932 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 5 Mar 2020 12:32:49 +0100
Subject: [PATCH] lavd/avfoundation: Add basic transport control observation
 for capable devices.

---
 libavdevice/avfoundation.m | 67 --
 1 file changed, 59 insertions(+), 8 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 0d854a1..43b2edb 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -88,7 +88,6 @@ typedef struct
 int64_t first_pts;
 int64_t first_audio_pts;
 pthread_mutex_t frame_lock;
-pthread_cond_t  frame_wait_cond;
 id  avf_delegate;
 id  avf_audio_delegate;
 
@@ -130,6 +129,10 @@ typedef struct
 AVCaptureAudioDataOutput *audio_output;
 CMSampleBufferRef current_frame;
 CMSampleBufferRef current_audio_frame;
+
+AVCaptureDevice  *observed_device;
+AVCaptureDeviceTransportControlsPlaybackMode observed_mode;
+int  observed_quit;
 } AVFContext;
 
 static void lock_frames(AVFContext* ctx)
@@ -163,10 +166,50 @@ static void unlock_frames(AVFContext* ctx)
 {
 if (self = [super init]) {
 _context = context;
+
+// start observing if a device is set for it
+if (_context->observed_device) {
+NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
+NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew;
+
+[_context->observed_device addObserver: self
+forKeyPath: keyPath
+   options: options
+   context: _context];
+}
 }
 return self;
 }
 
+- (void)dealloc {
+// stop observing if a device is set for it
+NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
+[_context->observed_device removeObserver: self forKeyPath: keyPath];
+[super dealloc];
+}
+
+- (void)observeValueForKeyPath:(NSString *)keyPath
+  ofObject:(id)object
+change:(NSDictionary *)change
+   context:(void *)context {
+if (context == _context) {
+AVCaptureDeviceTransportControlsPlaybackMode mode =
+[change[NSKeyValueChangeNewKey] integerValue];
+
+if (mode != _context->observed_mode) {
+if (mode == AVCaptureDeviceTransportControlsNotPlayingMode) {
+_context->observed_quit = 1;
+}
+_context->observed_mode = mode;
+}
+} else {
+[super observeValueForKeyPath: keyPath
+ ofObject: object
+   change: change
+  context: context];
+}
+}
+
 - (void)  captureOutput:(AVCaptureOutput *)captureOutput
   didOutputSampleBuffer:(CMSampleBufferRef)videoFrame
  fromConnection:(AVCaptureConnection *)connection
@@ -179,8 +222,6 @@ static void unlock_frames(AVFContext* ctx)
 
 _context->current_frame = (CMSampleBufferRef)CFRetain(videoFrame);
 
-pthread_cond_signal(&_context->frame_wait_cond);
-
 unlock_frames(_context);
 
 ++_context->frames_captured;
@@ -225,8 +266,6 @@ static void unlock_frames(AVFContext* ctx)
 
 _context->current_audio_frame = (CMSampleBufferRef)CFRetain(audioFrame);
 
-pthread_cond_signal(&_context->frame_wait_cond);
-
 unlock_frames(_context);
 
 ++_context->audio_frames_captured;
@@ -253,7 +292,6 @@ static void destroy_context(AVFContext* ctx)
 av_freep(&ctx->audio_buffer);
 
 pthread_mutex_destroy(&ctx->frame_lock);
-pthread_cond_destroy(&ctx->frame_wait_cond);
 
 if (ctx->current_frame) {
 CFRelease(ctx->current_frame);
@@ -499,6 +537,15 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 [ctx->video_output setAlwaysDiscardsLateVideoFrames:ctx->drop_late_frames];
 
+// check for transport control support and set observer device if supported
+int trans_ctrl = [video_device transportControlsSupported];
+AVCaptureDeviceTransportControlsPlaybackMode trans_mode = [video_device 
transportControlsPlaybackMode];
+
+if (trans_ctrl) {
+ctx->observed_mode   = trans_mode;
+ctx->observed_device = video_device;
+}
+
 ctx->avf_delegate = [[AVFFrameReceiver alloc] initWithContext:ctx];
 
 queue = dispatch_queue_create("avf_queue", NULL);
@@ -709,7 +756,6 @@ static int avf_read_header(AVFormatContext *s)
 ctx->first_audio_pts= av_gettime();
 
 pthread_mutex_init(&am

Re: [FFmpeg-devel] [CLT2020] FFmpeg at Chemnitzer Linux-Tage

[Thilo Borgmann]

Hi,

> FFmpeg has been accepted again for CLT 2020 in Chemnitz, Germany!
> This "Chemnitzer Linux Tage" will take place on 14th and 15th of March.
> You can find more details on their homepage:
> 
> https://chemnitzer.linux-tage.de/2020/en/
> 
> We will man a booth with our staff and are happily waiting for
> our users to get in touch with us! 

unfortunately the conference was cancelled due to CUVID-19.

The organizers evaluate the possiblity to have the conference at a later date 
this year or skip this years gathering altogether. Anyway, it is not happening 
as planned.

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

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

Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: Add basic transport control observation, for capable devices.

[Thilo Borgmann]

Hi,

> fixes infinite loop waiting for input using e.g. tape devices that suport 
> transport control.

will apply soon.

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

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

Re: [FFmpeg-devel] Reimbursement request

[Thilo Borgmann]

Am 12.03.20 um 11:56 schrieb Paul B Mahol:
> On 3/11/20, Carl Eugen Hoyos  wrote:
>> Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan :
>>>
>>> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote:
>>
 The Chemnitzer Linuxtage were canceled yesterday because of the
 Coronavirus.
 I request reimbursement of €138,86 for the flight to Germany I had
 booked last month.
>>>
>>> Some airlines are providing a more generous refund policy lately.
>>> Is your purchase covered by something like that?
>>
>> I tried to find out today but failed because the airline
>> telephone contact (canceling is only possible via
>> telephone) on multiple tries was either busy immediately
>> or went busy after I waited for some time.
>>
>> If nobody objects I will send the usual paperwork to Stefano.
> 
> I object.

Don't feed the troll and send the paperwork.

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

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

Re: [FFmpeg-devel] Reimbursement request

[Thilo Borgmann]

Am 12.03.20 um 12:08 schrieb Paul B Mahol:
> On 3/12/20, Thilo Borgmann  wrote:
>> Am 12.03.20 um 11:56 schrieb Paul B Mahol:
>>> On 3/11/20, Carl Eugen Hoyos  wrote:
>>>> Am Di., 10. März 2020 um 02:45 Uhr schrieb Lou Logan :
>>>>>
>>>>> On Mon, Mar 9, 2020, at 4:59 PM, Carl Eugen Hoyos wrote:
>>>>
>>>>>> The Chemnitzer Linuxtage were canceled yesterday because of the
>>>>>> Coronavirus.
>>>>>> I request reimbursement of €138,86 for the flight to Germany I had
>>>>>> booked last month.
>>>>>
>>>>> Some airlines are providing a more generous refund policy lately.
>>>>> Is your purchase covered by something like that?
>>>>
>>>> I tried to find out today but failed because the airline
>>>> telephone contact (canceling is only possible via
>>>> telephone) on multiple tries was either busy immediately
>>>> or went busy after I waited for some time.
>>>>
>>>> If nobody objects I will send the usual paperwork to Stefano.
>>>
>>> I object.
>>
>> Don't feed the troll and send the paperwork.
> 
> This is outrageous and uncalled vilification!
> 
> Lets's all buy something and than ask somebody else to pay for us instead.

> Instead person should try to cancel it several times, only if it fails
> then ask for money.

Totally agree. Therefore, "...on multiple tries...", see above.

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

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

Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: Add basic transport control observation, for capable devices.

[Thilo Borgmann]

Am 12.03.20 um 11:26 schrieb Thilo Borgmann:
> Hi,
> 
>> fixes infinite loop waiting for input using e.g. tape devices that suport 
>> transport control.
> 
> will apply soon.

Applied.

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 11:24 schrieb Nicolas George:
> Paul B Mahol (12020-03-26):
>> Apparently you are talking about completely different and irrelevant stuff
>> for this task.
> 
> Apparently, you did not read my previous mails very carefully, because I
> already explained.

Please let's stop here, we're loosing the connection to the subject.

-Thilo

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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 10:48 schrieb Paul B Mahol:
> On 3/26/20, Nicolas George  wrote:
>> Ashutosh Pradhan (12020-03-26):
>>> I was trying to random tones using cellular automata (it won't sound good
>>> if the tones are too random so I used a scale) for the GSoC audio tones
>>> filter project.
>>
>> Yes, that's already in the doc. What I ask is what good you expect from
>> it.
> 
> What kind of insinuation is this?
> This is qualification task for GSoC project, if you have something against it,
> ask me directly instead.

Let's look at this. There are two things here:

a) Is it a good enough solution of the qualfification task Paul has given to 
Ashutosh?

b) Is it unsuitable to apply? Well that might be but we need to get clear about 
a) for the sake of GSoC.

Also, a) & b) might be a reoccuring problem this year, as IIRC Jai also gave a 
qualification tasks that might be on its own useless to apply to git HEAD. But 
AFAIKT this is not on devel by now. So please let's concentrate on these two 
questions. Any thoughts appreciated.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 11:58 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Let's look at this. There are two things here:
>>
>> a) Is it a good enough solution of the qualfification task Paul has
>> given to Ashutosh?
>>
>> b) Is it unsuitable to apply? Well that might be but we need to get
>> clear about a) for the sake of GSoC.
>>
>> Also, a) & b) might be a reoccuring problem this year, as IIRC Jai
>> also gave a qualification tasks that might be on its own useless to
>> apply to git HEAD. But AFAIKT this is not on devel by now. So please
>> let's concentrate on these two questions. Any thoughts appreciated.
> 
> The original proposal for a tone audio source was from me, more than a
> year ago. It was for testing purposes: to be able to feed filters and
> codecs realistic input without relying on external files. For that, it
> would have been completely internal and bit-exact.
> 
> Now, there is a new proposal. Without looking into it closer, I supposed
> it was based on the same goal: testing. Apparently not. But I have not
> seen that discussed on the list.
> 
> I have no objection to the task if it serves a purpose. But it has
> nothing to do with my original proposal and this version, using an
> external library, would be worthless for testing.

Ok. So if I understand all of this correctly, the overall goal of the tones 
project is already redundant to your old proposal (or at least partially, 
Paul?).

Has there been any reason why it never made it into git HEAD?

So for this patch as-is, AFAICT Paul wanted the external lib as qualification 
task only and finally get things natively implemented during GSoC?

If so, we can first review this patch as RFC to give Ashutosh feedback to his 
coding & things. And wether or not he'll pass qualification, gets selected for 
a probably available slot etc, reads as if he's doing the GSoC project finally, 
we can have Ashutosh work on an implementation of the audio tones project. 
Assuming there haven't been any fundamental objections to Nicolas old proposal 
about such a thing already.

And then, it would of course only make sense to do this project based on what 
Nicolas old proposal was. Assuming it served the same goal.

Nicolas, can you please give a link here to your proposal for Ashutosh to find 
it easily?

-Thilo



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

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

Re: [FFmpeg-devel] [PATCHv2][GSoC]audio filter-use cellular automata to generate tones

[Thilo Borgmann]

Am 26.03.20 um 12:18 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Ok. So if I understand all of this correctly, the overall goal of the
>> tones project is already redundant to your old proposal (or at least
>> partially, Paul?).
> 
> I do not know what the overall goal of the tones project is: I have not
> seen it discussed on the list.

I strongly agree we should more thoroughly review future project proposals. The 
questions about validity/usefullness raised here should have been settled 
before it goes online for students to select.


>> Has there been any reason why it never made it into git HEAD?
> 
> It was just a vague proposal, not actual code.
> 
>> So for this patch as-is, AFAICT Paul wanted the external lib as
>> qualification task only and finally get things natively implemented
>> during GSoC?
> 
> I don't know what Paul wanted, I have not seen it discussed on the list.
> 
>> And then, it would of course only make sense to do this project based
>> on what Nicolas old proposal was. Assuming it served the same goal.

That was basically my misunderstanding of the topic. Paul wants a tone/music 
generator utilizing fluidsynth, not just as part of qualification as I 
understood it. And after talking to Nicolas, he is fine continuing that GSoC 
project as intended.

@Ashutosh: So please continue working on your project/application with Paul as 
planned. 

Time to give some actual feedback on the code / review, please.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 0/2] lavd/avfoundation: Fix build on iOS and fix screen capture

[Thilo Borgmann]

Hi,

fixing two bugs revealed after last patch to avfoundation.

Will apply soon if there are no objections.

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

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

[FFmpeg-devel] [PATCH 2/2] lavd/avfoundation.m: Do not use transport controls for screen capture devices.

[Thilo Borgmann]

$Subject

-Thilo
From a754bd117b6eff1e7c9468a76e236d3f062eb580 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 4 Apr 2020 13:51:17 +0200
Subject: [PATCH 2/2] lavd/avfoundation.m: Do not use transport controls for
 screen capture devices.

---
 libavdevice/avfoundation.m | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 9f8186b4d7..0b1888693f 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -99,6 +99,7 @@
 int capture_raw_data;
 int drop_late_frames;
 int video_is_muxed;
+int video_is_screen;
 
 int list_devices;
 int video_device_index;
@@ -545,12 +546,14 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 
 #if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 // check for transport control support and set observer device if supported
-int trans_ctrl = [video_device transportControlsSupported];
-AVCaptureDeviceTransportControlsPlaybackMode trans_mode = [video_device 
transportControlsPlaybackMode];
+if (!ctx->video_is_screen) {
+int trans_ctrl = [video_device transportControlsSupported];
+AVCaptureDeviceTransportControlsPlaybackMode trans_mode = 
[video_device transportControlsPlaybackMode];
 
-if (trans_ctrl) {
-ctx->observed_mode   = trans_mode;
-ctx->observed_device = video_device;
+if (trans_ctrl) {
+ctx->observed_mode   = trans_mode;
+ctx->observed_device = video_device;
+}
 }
 #endif
 
@@ -750,7 +753,6 @@ static int get_audio_config(AVFormatContext *s)
 static int avf_read_header(AVFormatContext *s)
 {
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
-int capture_screen  = 0;
 uint32_t num_screens= 0;
 AVFContext *ctx = (AVFContext*)s->priv_data;
 AVCaptureDevice *video_device = nil;
@@ -847,7 +849,7 @@ static int avf_read_header(AVFormatContext *s)
 }
 
 video_device = (AVCaptureDevice*) capture_screen_input;
-capture_screen = 1;
+ctx->video_is_screen = 1;
 #endif
  } else {
 av_log(ctx, AV_LOG_ERROR, "Invalid device index\n");
@@ -884,7 +886,7 @@ static int avf_read_header(AVFormatContext *s)
 AVCaptureScreenInput* capture_screen_input = 
[[[AVCaptureScreenInput alloc] initWithDisplayID:screens[idx]] autorelease];
 video_device = (AVCaptureDevice*) capture_screen_input;
 ctx->video_device_index = ctx->num_video_devices + idx;
-capture_screen = 1;
+ctx->video_is_screen = 1;
 
 if (ctx->framerate.num > 0) {
 capture_screen_input.minFrameDuration = 
CMTimeMake(ctx->framerate.den, ctx->framerate.num);
@@ -975,7 +977,7 @@ static int avf_read_header(AVFormatContext *s)
 
 /* Unlock device configuration only after the session is started so it
  * does not reset the capture formats */
-if (!capture_screen) {
+if (!ctx->video_is_screen) {
 [video_device unlockForConfiguration];
 }
 
-- 
2.20.1 (Apple Git-117)

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

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

[FFmpeg-devel] [PATCH 1/2] lavd/avfoundation.m: Remove transport controls for iOS.

[Thilo Borgmann]

$Subject

-Thilo
From 20f16ed1ef9f99b847798a28fff46812246a8039 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sat, 4 Apr 2020 13:49:46 +0200
Subject: [PATCH 1/2] lavd/avfoundation.m: Remove transport controls for iOS.

---
 libavdevice/avfoundation.m | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 43b2edb44d..9f8186b4d7 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -168,6 +168,7 @@ - (id)initWithContext:(AVFContext*)context
 _context = context;
 
 // start observing if a device is set for it
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 if (_context->observed_device) {
 NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
 NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew;
@@ -177,14 +178,19 @@ - (id)initWithContext:(AVFContext*)context
options: options
context: _context];
 }
+#endif
 }
 return self;
 }
 
 - (void)dealloc {
 // stop observing if a device is set for it
-NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
-[_context->observed_device removeObserver: self forKeyPath: keyPath];
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+if (_context->observed_device) {
+NSString *keyPath = 
NSStringFromSelector(@selector(transportControlsPlaybackMode));
+[_context->observed_device removeObserver: self forKeyPath: keyPath];
+}
+#endif
 [super dealloc];
 }
 
@@ -537,6 +543,7 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 }
 [ctx->video_output setAlwaysDiscardsLateVideoFrames:ctx->drop_late_frames];
 
+#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
 // check for transport control support and set observer device if supported
 int trans_ctrl = [video_device transportControlsSupported];
 AVCaptureDeviceTransportControlsPlaybackMode trans_mode = [video_device 
transportControlsPlaybackMode];
@@ -545,6 +552,7 @@ static int add_video_device(AVFormatContext *s, 
AVCaptureDevice *video_device)
 ctx->observed_mode   = trans_mode;
 ctx->observed_device = video_device;
 }
+#endif
 
 ctx->avf_delegate = [[AVFFrameReceiver alloc] initWithContext:ctx];
 
-- 
2.20.1 (Apple Git-117)

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

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

Re: [FFmpeg-devel] [PATCH 0/2] lavd/avfoundation: Fix build on iOS and fix screen capture

[Thilo Borgmann]

Am 04.04.20 um 13:55 schrieb Thilo Borgmann:
> Hi,
> 
> fixing two bugs revealed after last patch to avfoundation.
> 
> Will apply soon if there are no objections.

Applied.

Thx,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 0/2] lavd/avfoundation: Fix build on iOS and fix screen capture

[Thilo Borgmann]

Am 22.04.20 um 23:54 schrieb Carl Eugen Hoyos:
> Am Mi., 22. Apr. 2020 um 17:06 Uhr schrieb Thilo Borgmann
> :
>>
>> Am 04.04.20 um 13:55 schrieb Thilo Borgmann:
>>> Hi,
>>>
>>> fixing two bugs revealed after last patch to avfoundation.
>>>
>>> Will apply soon if there are no objections.
>>
>> Applied.
> 
> Does one of the patches fix ticket #8615?

No, seems also unrelated (videotoolbox?).

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

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

Re: [FFmpeg-devel] GSoC 2021

[Thilo Borgmann]

Hi,

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Michael Niedermayer
>> Sent: 2021年2月2日 17:48
>> To: FFmpeg development discussions and patches 
>> Subject: [FFmpeg-devel] GSoC 2021
>>
>> Hi all
>>
>> Most people probably already know but just to be sure everyone knows GSoC
>> 2021 is 175h not 350h
>> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ
>> ?pli=1
>>
>> Some project ideas may need to be adjusted accordingly
> 
> hi, for your information.
> 
> just like last year, to get more chances for GSoC project, I proposed my idea 
> at https://01.org/linuxmedia/news/gsoc-2021-ideas, and also copy here for 
> your convenience.
> 
> Async support for TensorFlow backend in FFmpeg
> Description: FFmpeg DNN (deep neural network) module is to enable deep 
> learning based FFmpeg filters with OpenVINO, TensorFlow and Native as its 
> backends. The OpenVINO backend has supported async+batch execution for model 
> inference with commit e67b5d and 64ea15 etc, it shows good performance gain. 
> This project focuses on the async support for TensorFlow backend which 
> invokes TensorFlow C library for model loading and inference. The main 
> difference between the two backends is that OpenVINO API has async execution 
> function while TensorFlow C API does not expose async function, so we need to 
> support async execution by multiple threads within TensorFlow backend with 
> sync function TF_SessionRun. (it is a plus if batch mode is also supported.)
> Difficulty: Medium
> Skill Required: C, multiple threads, DNN knowledge, git

Thanks, see my other mail to have it on the ideas page!

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

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

Re: [FFmpeg-devel] GSoC 2021

[Thilo Borgmann]

Hi,


> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

we've started registering as an Org and I put up the project ideas page for 
everyone to propose a project:

https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021

We're still looking for mentors/projects, please feel free to propose a project 
(175 working hours in size this year)

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] [Code format dependent] : [Adjust the format of code blocks]

[Thilo Borgmann]

Hi,

Am 19.02.21 um 13:43 schrieb hou...@uniontech.com:
> From: Hou Lei 
> 
> Signed-off-by: Hou Lei 
> ---
>  fftools/ffmpeg.c |  8 
>  libavcodec/h264_loopfilter.c | 22 --
>  2 files changed, 12 insertions(+), 18 deletions(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index add5a3e505..ed20bd3a25 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> [...]
>  if( edge & mask_edge ) {
while you're on it, you might get these right, too.
"if (cond) {"
removing exta " " in (), too.

LGTM otherwise.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Please provide the FFMPEG public key (GPG/PGP)

[Thilo Borgmann]

Hi,

Am 23.02.21 um 12:37 schrieb Zane van Iperen:
> On 23/2/21 5:30 pm, Michael Witten wrote:
>> Please send to this mailing list an email that embeds the PGP/GPG
>> public key used to sign files provided by the FFMPEG project.
>>
> 
> It doesn't account for trust, but you can just import the key yourself in the 
> meantime:

 
> $ gpg --verify ffmpeg-4.3.2.tar.xz.asc ffmpeg-4.3.2.tar.xz
> gpg: Signature made Sun 21 Feb 2021 06:35:15 AEST
> gpg:    using RSA key FCF986EA15E6E293A5644F10B4322F04D67658D8
> gpg:    issuer "ffmpeg-devel@ffmpeg.org"
> gpg: Can't check signature: No public key
>
> $ gpg --keyserver pool.sks-keyservers.net --search-key 
> FCF986EA15E6E293A5644F10B4322F04D67658D8
> gpg: data source: http://87.118.94.9:11371
> (1)    FFmpeg release signing key 
>   2048 bit RSA key B4322F04D67658D8, created: 2011-04-26
> Keys 1-1 of 1 for "FCF986EA15E6E293A5644F10B4322F04D67658D8".  Enter 
> number(s), N)ext, or Q)uit >

we should really add this instruction to the Download page!
Zane, could you send a patch for ffmpeg-web about this pls?

Thanks,
Thilo

>> Please also include on your website a link to download your public
>> key, and place it in a prominent place, perhaps alongside the
>> various download links.
>>
>> Thanks!
>>
>> Sincerely,
>> Michael Witten
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Thilo Borgmann]

Am 24.02.21 um 05:06 schrieb Zane van Iperen:
> As per discussion at [1]. Patches attached.
> 
> Patch 1/3 adds /node_modules/ to .gitignore
> 
> Patch 2/3 adds the actual key and verification instructions
> 
> Patch 3/3 adds a prominent download link for the public key.
> This might be bit obnoxious, but it was suggested in the original discussion.
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276752.html

As in [1] above I like that idea. However, I can't really comment on the 
technical side of keys and signatures. So proper someones opinion with actual 
knowledge would be appreciated.

Thanks!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Proposal of two projects for GSoC

[Thilo Borgmann]

Hi,

> Please find the proposal for the following two projects for GSoC this year.
> 
> The FATE project had been proposed earlier already but I don't know why it
> didn't happen.
> 
> I previously got the feedback from Thilo Borgmann and would be happy to get
> feedback from the community as well.

according to the replies I figure this project seems ok, I added it to the gsoc 
page.

Anyone wants to comment about the FATE proposal?


> """""""""""""""""
> 
> 
> 
> FATE tests for HW acceleration
> 
> 
> 
> Description: FFmpeg's FATE regression test system do not include validation
> of hardware acceleration. This project is about to include these
> hardware-specific regression tests to the FATE system. Since this project
> requires access to corresponding hardware, it is not expected to cover the
> whole range of hardware accelerators there are but to initialize some
> useful tests for available hardware, most likely to include CPU
> acceleration on Intel or AMD at least. Access to other hardware can also be
> provided during the project, depending on the students requirements.
> 
> 
> 
> Expected results: Implement tests for the different hardware decoding,
> encoding and transcoding capabilities there are.
> 
> 
> 
> Prerequisites: Good C and Makefile coding skills, basic familiarity with
> Git.
> 
> 
> 
> Qualification Task: TBD
> 
> 
> 
> Mentor: Artem G (artem.galin [at] intel [dot] com)
> 
> 
> 
> Backup Mentor: TBD


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

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

Re: [FFmpeg-devel] Apple M1 Mac Mini Access

[Thilo Borgmann]

Am 28.02.21 um 13:30 schrieb Kieran Kunhya:
> Hi,
> 
> Please email me privately with your ssh public key and desired username if
> you would like access to the second Apple M1 Mac Mini which we bought for
> development purposes.

Done, thanks for setting these things up!

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

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

[FFmpeg-devel] [PATCH] lavc/alsdec: Add NEON optimizations

[Thilo Borgmann]

Hi,

it's my first attempt to do some assembly, it might still includes some dont's 
of the asm world...
Tested with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Speed-wise, it sees a drop for small prediction orders until around 10 or 11.
Well, the maximum prediction order is 1023.
I therefore checked with the "real-world" samples from the fate-suite, which 
suggests low prediction orders are non-dominant:



pred_order = 9, gain: -6%

als_reconstruct_all_c: 15898.2
als_reconstruct_all_neon: 16460.0


pred_order = 15,gain:  35%

als_reconstruct_all_c: 34843.7
als_reconstruct_all_neon: 22840.5


pred_order = {7..17}, gain: 23%

als_reconstruct_all_c: 26645.2
als_reconstruct_all_neon: 20635.2




patched: 

TESTmpeg4-als-conformance-00
TESTmpeg4-als-conformance-01
TESTmpeg4-als-conformance-02
TESTmpeg4-als-conformance-03
TESTmpeg4-als-conformance-04
TESTmpeg4-als-conformance-05
TESTmpeg4-als-conformance-09

real0m1.006s
user0m0.903s
sys 0m0.112s


real0m1.007s
user0m0.889s
sys 0m0.127s

real0m1.005s
user0m0.897s
sys 0m0.117s


unpatched:

TESTmpeg4-als-conformance-00
TESTmpeg4-als-conformance-01
TESTmpeg4-als-conformance-02
TESTmpeg4-als-conformance-03
TESTmpeg4-als-conformance-04
TESTmpeg4-als-conformance-05
TESTmpeg4-als-conformance-09

real0m1.204s
user0m1.122s
sys 0m0.091s

real0m1.204s
user0m1.098s
sys 0m0.115s

real0m1.205s
user0m1.077s
sys 0m0.137s


-Thilo
From 42a4d5f581570b0d292b63bb193e3e8da9645fcd Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Sun, 28 Feb 2021 14:13:32 +
Subject: [PATCH] lavc/alsdec: Add NEON optimizations

---
 configure|   3 +-
 libavcodec/Makefile  |   1 +
 libavcodec/aarch64/Makefile  |   2 +
 libavcodec/aarch64/alsdsp_init_aarch64.c |  35 +
 libavcodec/aarch64/alsdsp_neon.S | 155 +++
 libavcodec/alsdec.c  |  13 +-
 libavcodec/alsdsp.c  |  49 +++
 libavcodec/alsdsp.h  |  35 +
 tests/checkasm/Makefile  |   1 +
 tests/checkasm/alsdsp.c  |  81 
 tests/checkasm/checkasm.c|   3 +
 tests/checkasm/checkasm.h|   1 +
 12 files changed, 370 insertions(+), 9 deletions(-)
 create mode 100644 libavcodec/aarch64/alsdsp_init_aarch64.c
 create mode 100644 libavcodec/aarch64/alsdsp_neon.S
 create mode 100644 libavcodec/alsdsp.c
 create mode 100644 libavcodec/alsdsp.h
 create mode 100644 tests/checkasm/alsdsp.c

diff --git a/configure b/configure
index 900505756b..30875f87f2 100755
--- a/configure
+++ b/configure
@@ -2345,6 +2345,7 @@ CONFIG_EXTRA="
 aandcttables
 ac3dsp
 adts_header
+alsdsp
 atsc_a53
 audio_frame_queue
 audiodsp
@@ -2664,7 +2665,7 @@ adpcm_g722_decoder_select="g722dsp"
 adpcm_g722_encoder_select="g722dsp"
 aic_decoder_select="golomb idctdsp"
 alac_encoder_select="lpc"
-als_decoder_select="bswapdsp"
+als_decoder_select="bswapdsp alsdsp"
 amrnb_decoder_select="lsp"
 amrwb_decoder_select="lsp"
 amv_decoder_select="sp5x_decoder exif"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 35318f4f4d..8a23ab8ea0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -62,6 +62,7 @@ OBJS = ac3_parser.o   
  \
 OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
 OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
 OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o mpeg4audio.o
+OBJS-$(CONFIG_ALSDSP)  += alsdsp.o
 OBJS-$(CONFIG_AMF) += amfenc.o
 OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
 OBJS-$(CONFIG_ATSC_A53)+= atsc_a53.o
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index f6434e40da..a7493c7c2b 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -1,4 +1,5 @@
 # subsystems
+OBJS-$(CONFIG_ALSDSP)   += aarch64/alsdsp_init_aarch64.o
 OBJS-$(CONFIG_FFT)  += aarch64/fft_init_aarch64.o
 OBJS-$(CONFIG_FMTCONVERT)   += aarch64/fmtconvert_init.o
 OBJS-$(CONFIG_H264CHROMA)   += aarch64/h264chroma_init_aarch64.o
@@ -52,6 +53,7 @@ NEON-OBJS-$(CONFIG_VP8DSP)  += 
aarch64/vp8dsp_neon.o
 
 # decoders/encoders
 NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
+NEON-OBJS-$(CONFIG_ALS_DECODER) += aarch64/alsdsp_neon.o
 NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
 NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
 NEON-OBJS-$(CONFIG_VORBIS_DECODER)  += aarch64/vorbisdsp_neon.o
diff --git a/libavcodec/aarch64/alsdsp_init_aarch64.c 
b/libavcodec/aar

Re: [FFmpeg-devel] [PATCH] lavc/alsdec: Add NEON optimizations

[Thilo Borgmann]

Hi Martin,

>> it's my first attempt to do some assembly, it might still includes some 
>> dont's of the asm world...
>> Tested with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
>>
>> Speed-wise, it sees a drop for small prediction orders until around 10 or 11.
>> Well, the maximum prediction order is 1023.
>> I therefore checked with the "real-world" samples from the fate-suite, which 
>> suggests low prediction orders are non-dominant:
>>
>> pred_order = {7..17}, gain: 23%
>>
>> als_reconstruct_all_c: 26645.2
>> als_reconstruct_all_neon: 20635.2
> 
> This is the combination that the patch actually tests by default, if I read 
> the code correctly - right?

exactly.


> You didn't write what CPU you tested this on - do note that the actual 
> peformance of the assembly is pretty heavily dependent on the CPU.
> 
> I get roughly similar numbers if I build with GCC:
> 
>  Cortex A53  A72  A73
> als_reconstruct_all_c: 107708.2  44044.5  57427.7
> als_reconstruct_all_neon:   78895.7  38464.7  34065.5

Was a remote one, don't know exactly, yet. Will find out for v2.


> However - if I build with Clang, where vectorization isn't disabled by 
> configure, the C code beats the handwritten assembly:
> 
>    Cortex A53
> als_reconstruct_all_c:    69145.7
> als_reconstruct_all_neon: 78895.7
> 
> Even if I only test order 17, the C code still is faster. So clearly we can 
> do better - if nothing else, we could copy the assembly code that Clang 
> outputs :-)

Narf. Well maybe thoughts about the code itself will get more speed manually...


> First a couple technical details about the patch...
> [...]

I very much appreciate your excessive feedback, I will need quite some time to 
work through it! :)

Thanks!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Thilo Borgmann]

Am 24.02.21 um 17:53 schrieb Thilo Borgmann:
> Am 24.02.21 um 05:06 schrieb Zane van Iperen:
>> As per discussion at [1]. Patches attached.
>>
>> Patch 1/3 adds /node_modules/ to .gitignore
>>
>> Patch 2/3 adds the actual key and verification instructions
>>
>> Patch 3/3 adds a prominent download link for the public key.
>> This might be bit obnoxious, but it was suggested in the original discussion.
>>
>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276752.html
> 
> As in [1] above I like that idea. However, I can't really comment on the 
> technical side of keys and signatures. So proper someones opinion with actual 
> knowledge would be appreciated.

If there are no complains, I'll push that soon (tm).

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

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

Re: [FFmpeg-devel] [PATCH] mailmap: add entry for myself

[Thilo Borgmann]

Hi,

Am 08.03.21 um 16:12 schrieb Linjie Fu:
> Signed-off-by: Linjie Fu 
> ---
>  .mailmap | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/.mailmap b/.mailmap
> index 3bd1a85c3c..ba072f38c8 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -10,7 +10,8 @@
>   
>   
>   
> - 
> + 
> + 
>   
>   
>   

LGTM, you are listed as one of the libopenh264enc maintainers, please push.

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/amfenc_hevc: Recommend values for min and max video quantizer scale.

[Thilo Borgmann]

Hi,

Am 09.03.21 um 16:57 schrieb Ovchinnikov Dmitrii:
> Current settings makes bitrate large, than expected, more information:
> https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736

I agree to the comments on your issue tracker[1], that it would be better to 
solve this by setting qmin/qmax explicitly in handbrake (or whatever 
application) than by changing their defaults.

[1] https://github.com/HandBrake/HandBrake/issues/3447#issuecomment-790178099

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

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

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Thilo Borgmann]

Am 10.03.21 um 09:25 schrieb Zane van Iperen:
> Before you do, just give it a crack locally.
> 
> I couldn't get the cloned version of the site to look identical to what's 
> already published (something to do with incorrect CSS symlinks iirc). It's 
> probably fine, but for something like this I'd rather err on the side of 
> caution.

I know this problem and I'm happily ignoring it - because the style thingys are 
living happily on the server and look like intended.

So I don't expect any problems. If so, its the website being a bit more ugly 
for maybe some short time...
Not doing it today anyway, so you can still test on if you feel the desire to 
get a 1:1 website locally.

-Thilo

> 
> On 8/3/21 11:24 pm, Thilo Borgmann wrote:
>> Am 24.02.21 um 17:53 schrieb Thilo Borgmann:
>>> Am 24.02.21 um 05:06 schrieb Zane van Iperen:
>>>> As per discussion at [1]. Patches attached.
>>>>
>>>> Patch 1/3 adds /node_modules/ to .gitignore
>>>>
>>>> Patch 2/3 adds the actual key and verification instructions
>>>>
>>>> Patch 3/3 adds a prominent download link for the public key.
>>>> This might be bit obnoxious, but it was suggested in the original 
>>>> discussion.
>>>>
>>>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276752.html
>>>
>>> As in [1] above I like that idea. However, I can't really comment on the 
>>> technical side of keys and signatures. So proper someones opinion with 
>>> actual knowledge would be appreciated.
>>
>> If there are no complains, I'll push that soon (tm).
>>
>> -Thilo
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

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

Re: [FFmpeg-devel] GSoC 2021

[Thilo Borgmann]

Hi!

> Most people probably already know but just to be sure everyone knows
> GSoC 2021 is 175h not 350h
> https://groups.google.com/g/google-summer-of-code-discuss/c/GgvbLrFBcUQ?pli=1
> 
> Some project ideas may need to be adjusted accordingly

FFmpeg has been accepted for GSoC this year [1]!

Thanks to everyone who proposed a project! 
Please direct anyone interested to the ideas page [2].

Thanks,
Thilo

[1] https://summerofcode.withgoogle.com/organizations
[2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Thilo Borgmann]

Am 10.03.21 um 18:19 schrieb Thilo Borgmann:
> Am 10.03.21 um 09:25 schrieb Zane van Iperen:
>> Before you do, just give it a crack locally.
>>
>> I couldn't get the cloned version of the site to look identical to what's 
>> already published (something to do with incorrect CSS symlinks iirc). It's 
>> probably fine, but for something like this I'd rather err on the side of 
>> caution.
> 
> I know this problem and I'm happily ignoring it - because the style thingys 
> are living happily on the server and look like intended.
> 
> So I don't expect any problems. If so, its the website being a bit more ugly 
> for maybe some short time...
> Not doing it today anyway, so you can still test on if you feel the desire to 
> get a 1:1 website locally.

Pushed. I don't see any bad thing on ffmpeg.org, please check.

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

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