Re: [FFmpeg-devel] [PATCH] fate/checkasm: add missing tests to FATE

[ffmpegandmahanstreamer]

September 27, 2021 9:04 PM, "James Almer"  wrote:

> Signed-off-by: James Almer 
> ---
> tests/fate/checkasm.mak | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
> index cec6d28286..6e7edbe655 100644
> --- a/tests/fate/checkasm.mak
> +++ b/tests/fate/checkasm.mak
> @@ -18,6 +18,7 @@ FATE_CHECKASM = fate-checkasm-aacpsdsp \
> fate-checkasm-hevc_idct \
> fate-checkasm-hevc_pel \
> fate-checkasm-hevc_sao \
> + fate-checkasm-huffyuvdsp \
> fate-checkasm-jpeg2000dsp \
> fate-checkasm-llviddsp \
> fate-checkasm-llviddspenc \
> @@ -27,6 +28,7 @@ FATE_CHECKASM = fate-checkasm-aacpsdsp \
> fate-checkasm-synth_filter \
> fate-checkasm-sw_rgb \
> fate-checkasm-sw_scale \
> + fate-checkasm-utvideodsp \
> fate-checkasm-v210dec \
> fate-checkasm-v210enc \
> fate-checkasm-vf_blend \
> @@ -34,6 +36,7 @@ FATE_CHECKASM = fate-checkasm-aacpsdsp \
> fate-checkasm-vf_eq \
> fate-checkasm-vf_gblur \
> fate-checkasm-vf_hflip \
> + fate-checkasm-vf_nlmeans \
> fate-checkasm-vf_threshold \
> fate-checkasm-videodsp \
> fate-checkasm-vp8dsp \
> -- 
> 2.33.0
> 
> ___
> 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".

Doesn't look good to me.

|
|
|

Just kidding, it does. ;)
___
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] [Discussion] Releases schedules

[ffmpegandmahanstreamer]

September 12, 2021 1:15 PM, "Jean-Baptiste Kempf"  wrote:

> Hello folks,
> 
> This is a topic that has come regularly on the table, in various discussions 
> in the community, in
> IRL, on IRC and on the mailing list; but also when talking with downstreams 
> applications and
> distributions...
> 

> Currently, it's quite difficult to know when is coming the next release, 
> which branch is going to
> be maintained for how long, so it's a bit of guess/luck to know which version 
> to use, and many
> people use a random sha1. Even for distributions that have LTS this is 
> difficult. It's also
> annoying for downstreams, that might have some patches above the top of line, 
> or backporting some
> patches. And a few other drawbacks, including security...
> 
> And finally, the maintenance of a branch belongs mostly to the goodwill of a 
> few of us, and it
> could be tiring for them...
> 
> (And for exemple, which branch today has all the security fixes, besides 
> 4.4.x?, without looking at
> the git repo)
> 
> Clarity would help a lot the FFmpeg direct and indirect users.
> So I'd love to start a discussion here, about this topic.
> 
> --- 
> Here is my opinion, depending on what I heard from the downstreams 
> requirements.
> 
> It would be nice to have:
> - one major release per year, allowing to break library API/ABI/behavior, 
> (probably in December to
> fit Ubuntu release schedule),

Yes, definetly. This is in line with gstreamer release schedule, i think they 
have like 2 major releases a year. 

> - one or two or three small releases per year, adding features, without 
> deprecation nor ABI
> changes, during the year,
Actually, i think the dev/release repo thingy as of right now is great. Maybe 
just one smalller release at the beginning of the year.

> - mark the major release as LTS every two year, and maintained it for 
> security for a longer time (2
> years, for example) than the usual main release.

Also a great idea. 

> 
> This would allow to only have to maintain the LTS branch and the last release 
> (which can be the
> same) in addition with the development branch.
> And as a downstream dev, you also know when you need to care about API 
> changes and which version is
> supported.
> This would be also quite simple to explain to the users/downstreams of FFmpeg.
> 
Yes, good idea.
> Thoughts?

Excellent thoughts like this makes me glad you are involved with the FFmpeg 
community. Thanks for single handedly putting forth this amazing proposal. 
FFmpeg will be better for it once there are enacted.
> 
> -- 
> Jean-Baptiste Kempf - President
> +33 672 704 734
> ___
> 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][libavcodec] Duckduckgo Truemotion 1 - some code cleanup and preparation for addition of sprite support

[ffmpegandmahanstreamer]

These are some cosmetic changes and also priming the decoder for sprite 
support (which i plan on adding). This patch was mainly for me to get 
used to the git email patch flow, if anything. Of course the decoder 
still works as it was before (i tested it).

---
 libavcodec/truemotion1.c | 41 +---
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..80946a405f 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -23,10 +23,10 @@
  * @file
  * Duck TrueMotion v1 Video Decoder by
  * Alex Beregszaszi and
- * Mike Melanson (melan...@pcisys.net)
+ * Mike Melanson (m...@multimedia.cx)
  *
  * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
- * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported 
yet.

+ * outputs RGB555 (or RGB565) data.
  */

 #include 
@@ -360,8 +360,12 @@ static int 
truemotion1_decode_header(TrueMotion1Context *s)

 s->flags = FLAG_KEYFRAME;

 if (s->flags & FLAG_SPRITE) {
+// https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
+header.xoffset = AV_RL16(&header_buffer[13]);
+header.yoffset = AV_RL16(&header_buffer[15]);
+header.width = AV_RL16(&header_buffer[17]);
+header.height = AV_RL16(&header_buffer[19]);
 avpriv_request_sample(s->avctx, "Frame with sprite");
-/* FIXME header.width, height, xoffset and yoffset aren't 
initialized */

 return AVERROR_PATCHWELCOME;
 } else {
 s->w = header.xsize;
@@ -660,20 +664,15 @@ static void 
truemotion1_decode_16bit(TrueMotion1Context *s)

 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
 OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 break;

 case 1:
@@ -786,20 +785,14 @@ static void 
truemotion1_decode_24bit(TrueMotion1Context *s)

 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 break;

 case 1:
--
___
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] cafenc: fill in avg. packet size later if unknown

[ffmpegandmahanstreamer]

On 2021-07-10 03:42, Lynne wrote:
This doesn't move the pointer back to the file end if par->block_align 
is set.
I think that's fine though, since the function writes the trailer, 
which should

mean that nothing more needs to be written.
Patch LGTM. But please, someone yell at Apple to support Opus in MP4,
WebM and OGG, as terrible as that is.


Doesn't apple already support webm and opus?

___
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] avfilter: add afwtdn filter

[ffmpegandmahanstreamer]

On 2021-07-10 15:20, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |   60 ++
 libavfilter/Makefile |1 +
 libavfilter/af_afwtdn.c  | 1349 ++
 libavfilter/allfilters.c |1 +
 4 files changed, 1411 insertions(+)
 create mode 100644 libavfilter/af_afwtdn.c

diff --git a/doc/filters.texi b/doc/filters.texi
index d991c06628..8c91d49ced 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1493,6 +1493,66 @@ Default value is 1.0.

 This filter supports the all above options as @ref{commands}.

+@section afwtdn
+Reduce broadband noise from input samples using Wavelets.
+
+A description of the accepted options follows.
+
+@table @option
+@item sigma
+Set the noise sigma, allowed range is from 0 to 1.
+Default value is 0.
+This option controls strength of denoising applied to input samples.
+Most useful way to set this option is via decibels, eg. -45dB.
+
+@item levels
+Set the number of wavelet levels of decomposition.
+Allowed range is from 1 to 12.
+Default value is 10.
+Setting this too low make denoising performance very poor.
+
+@item wavet
+Set wavelet type for decomposition of input frame.
+They are sorted by number of coefficients, from lowest to highest.
+More coefficients means worse filtering speed, but overall better 
quality.

+Available wavelets are:
+
+@table @samp
+@item sym2
+@item sym4
+@item rbior68
+@item deb10
+@item sym10
+@item coif5
+@item bl3
+@end table
+
+@item percent
+Set percent of full denoising. Allowed range is from 0 to 100 percent.
+Default value is 85 percent or partial denoising.
+
+@item profile
+If enabled, first input frame will be used as noise profile.
+If first frame samples contain non-noise performance will be very 
poor.

+
+@item adaptive
+If enabled, input frames are analyzed for presence of noise.
+If noise is detected with high possibility then input frame profile 
will be
+used for processing following frames, until new noise frame is 
detected.

+
+@item samples
+Set size of single frame in number of samples. Allowed range is from 
512 to

+65536. Default frame size is 8192 samples.
+
+@item softness
+Set softness applied inside thresholding function. Allowed range is 
from 0 to

+10. Default softness is 1.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
 @section agate

 A gate is mainly used to reduce lower parts of a signal. This kind of 
signal

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 62ee3d7b67..49c0c8342b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -53,6 +53,7 @@ OBJS-$(CONFIG_AFFTFILT_FILTER)   += 
af_afftfilt.o

 OBJS-$(CONFIG_AFIR_FILTER)   += af_afir.o
 OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
 OBJS-$(CONFIG_AFREQSHIFT_FILTER) += af_afreqshift.o
+OBJS-$(CONFIG_AFWTDN_FILTER) += af_afwtdn.o
 OBJS-$(CONFIG_AGATE_FILTER)  += af_agate.o
 OBJS-$(CONFIG_AIIR_FILTER)   += af_aiir.o
 OBJS-$(CONFIG_AINTEGRAL_FILTER)  += af_aderivative.o
diff --git a/libavfilter/af_afwtdn.c b/libavfilter/af_afwtdn.c
new file mode 100644
index 00..16195776b4
--- /dev/null
+++ b/libavfilter/af_afwtdn.c
@@ -0,0 +1,1349 @@
+/*
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * 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 
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "filters.h"
+#include "formats.h"
+
+enum WaveletTypes {
+SYM2,
+SYM4,
+RBIOR68,
+DEB10,
+SYM10,
+COIF5,
+BL3,
+NB_WAVELET_TYPES,
+};
+
+/*
+ * All wavelets coefficients are taken from: 
http://wavelets.pybytes.com/

+ */
+
+static const double bl3_lp[42] = {
+0.000146098, -0.000232304, -0.000285414, 0.000462093, 0.000559952,
+-0.000927187, -0.001103748, 0.00188212, 0.002186714, -0.003882426,
+-0.00435384, 0.008201477, 0.008685294, -0.017982291, -0.017176331,
+0.042068328, 0.032080869, -0.110036987, -0.050201753, 0.433923147,
+0.766130398, 0.433923147, -0.050201753, -0.110036987, 0.032080869,
+0.042068328, -0.017176331, -0.017982291, 0.00868

Re: [FFmpeg-devel] [PATCH][libavcodec] Duckduckgo Truemotion 1 - some code cleanup and preparation for addition of sprite support

[ffmpegandmahanstreamer]

On 2021-07-04 17:58, ffmpegandmahanstreamer@lolcow.email wrote:

These are some cosmetic changes and also priming the decoder for
sprite support (which i plan on adding). This patch was mainly for me
to get used to the git email patch flow, if anything. Of course the
decoder still works as it was before (i tested it).
---
 libavcodec/truemotion1.c | 41 +---
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..80946a405f 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -23,10 +23,10 @@
  * @file
  * Duck TrueMotion v1 Video Decoder by
  * Alex Beregszaszi and
- * Mike Melanson (melan...@pcisys.net)
+ * Mike Melanson (m...@multimedia.cx)
  *
  * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data 
and
- * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported 
yet.

+ * outputs RGB555 (or RGB565) data.
  */

 #include 
@@ -360,8 +360,12 @@ static int 
truemotion1_decode_header(TrueMotion1Context *s)

 s->flags = FLAG_KEYFRAME;

 if (s->flags & FLAG_SPRITE) {
+// https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
+header.xoffset = AV_RL16(&header_buffer[13]);
+header.yoffset = AV_RL16(&header_buffer[15]);
+header.width = AV_RL16(&header_buffer[17]);
+header.height = AV_RL16(&header_buffer[19]);
 avpriv_request_sample(s->avctx, "Frame with sprite");
-/* FIXME header.width, height, xoffset and yoffset aren't
initialized */
 return AVERROR_PATCHWELCOME;
 } else {
 s->w = header.xsize;
@@ -660,20 +664,15 @@ static void
truemotion1_decode_16bit(TrueMotion1Context *s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
 OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 break;

 case 1:
@@ -786,20 +785,14 @@ static void
truemotion1_decode_24bit(TrueMotion1Context *s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 break;

 case 1:

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

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

Re: [FFmpeg-devel] Mailing List Delay

[ffmpegandmahanstreamer]

On 2021-07-14 09:17, Derek Buitenhuis wrote:

On 7/14/2021 12:27 PM, Nicolas George wrote:
Looking at the headers, it looks like the delay happens at Google 
before

the mail arrives to the mailing-list.

Yours arrived quickly. Mine will too, I guess.


Sending from GMail, I have had anywhere from instantly, to 1.5 hours 
delay
ever since moving to the "new" (Hungarian?) mailing list host. 
Especially

when sending via git-send-email.



Oh, that's strange. All my emails always send instantly. Even when i was 
on cock.li which wasn't very reliable (read below).



I have been bringing this up consstently for years, and been told it's
a "non-issue", but it is incredibly annoying.

I am not sure if it's due to Google having issues (trust?) sending to
out host, or the host having trouble receiving.

That's why i use this email provider and not my main Gmail for mailing 
lists.


I used to use cock.li but they shut down signups. Plus the one i'm using 
(lolcow.email) has a nice threading interface on the web.  I have a 
special email for every mailing list im in (FFmpeg, llvm, qemu, 
gstreamer, freebsd/linux etc..). The nice thing is that you can put them 
in the Gmail or Apple/Android mail app on your phone for easy reading. 
And it also helps stop SPAM mails which i have gotten by posting on 
mailing lists.


It may be a good stopgap solution for some.


I have also noticed, since switching to this 'new' mysertious mailing
list host a few years back that a chunk of ffmpeg-devel traffic gets
filed into spam consistently. Also very annoying - I have missed 
several

patches this way. This is not specific to GMail, for me, so far.



That's because mail from "unknown" hosts might get into spam frequently. 
You may have to explicitly whitelist the mailing list in your settings.


If it's a trust thing, sure, we can blame Google or whoever, but I 
think

we should have a less cruddy experience for users of the largest email
provider in the world, by default, rather just shrugging and saying 
"sucks

to be you, don't use GMail".

- Derek
___
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] Mailing List Delay

[ffmpegandmahanstreamer]

On 2021-07-14 09:43, Derek Buitenhuis wrote:

On 7/14/2021 2:35 PM, ffmpegandmahanstreamer@lolcow.email wrote:
I have been bringing this up consstently for years, and been told 
it's

a "non-issue", but it is incredibly annoying.

I am not sure if it's due to Google having issues (trust?) sending to
out host, or the host having trouble receiving.


That's why i use this email provider and not my main Gmail for mailing
lists.


Saying "don't use the largest email provider in the world because our
list is janky" isn't a goo solution.

I'm not against fixing the mailing list. No, not at all. It need to be 
fixed. But Google is big company and trying to figure out how to make 
their mail deliver successfully might be a problem.


I think this was the reasoning behind alot of the major open source 
projects switching to Nongnu.org and Google Groups along with Github 
discussions. IIRC even the Alliance of Open Media has their patch 
mailing list on Groups.io and Google Groups now. But I'm not saying 
FFMPEG should. Just saying that other projects have been facing similar 
issues and fixed it by moving to a large mailing list hub. And libvpx 
uses Google mail servers for their patches as well.


At the very least though, a mailign list manager with the ability to 
send posts via the web could also be useful. This i what Python does:

https://mail.python.org/archives/list/python-...@python.org/



It may be a good stopgap solution for some.


I have also noticed, since switching to this 'new' mysertious mailing
list host a few years back that a chunk of ffmpeg-devel traffic gets
filed into spam consistently. Also very annoying - I have missed
several
patches this way. This is not specific to GMail, for me, so far.



That's because mail from "unknown" hosts might get into spam 
frequently.
You may have to explicitly whitelist the mailing list in your 
settings.


Also not really an acceptable solution to tell every single person 
this,

in my opinion.

You can have a banner on the mailing list subscribe page to whitelist 
the domain along with instructions maybe?

- Derek
___
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] Mailing List Delay

[ffmpegandmahanstreamer]

On 2021-07-14 14:55, Nicolas George wrote:

ffmpegandmahanstreamer@lolcow.email (12021-07-14):

I'm not against fixing the mailing list. No, not at all. It need to be
fixed. But Google is big company and trying to figure out how to make 
their

mail deliver successfully might be a problem.

I think this was the reasoning behind alot of the major open source 
projects
switching to Nongnu.org and Google Groups along with Github 
discussions.

IIRC even the Alliance of Open Media has their patch mailing list on
Groups.io and Google Groups now. But I'm not saying FFMPEG should. 
Just
saying that other projects have been facing similar issues and fixed 
it by
moving to a large mailing list hub. And libvpx uses Google mail 
servers for

their patches as well.


This discussion would be incomplete without reminding that Google and
these large actors have, under the excuse of fighting spam, 
unilaterally

changed the protocols they implement in ways that makes it harder for
small actors to stay in the game.

Therefore, the terms of the alternative are between choosing a solution
that is seamless even for the clueless but at the same time that 
enables

the monopolists and strengthen their position, or resisting the
monopolists and bearing a few technical hurdles for people who use 
their

services.

While this is true, the goal of the FFmpeg project is to further 
multimedia.
Not to fight against "the man", big corporations, or solve other 
problems.
We've seen firsthand how "external influences" can creep up on a 
project,
removing it from its goals. Just look at what happened with Gnome and 
Linux Foundation.


The solution picked should be easy for even the "clueless" so they too 
can contribute and

further the goals of the project.


Since FFmpeg is a major Libre Software project, and one that is quite
technical at that, I think it should be obvious our side is the one of
freedom and against the monopolists.

And the AOM/Python/other projects I mentioned aren't major and technical 
projects? They have chosen the "other" side.

Furthermore, FFmpeg has some importance for Google itself, which could
give us weight in asking they fix their shit if they want their users 
to

be able to contribute without hassle. That would benefit all projects
who want to self-host their mailing-lists.

Also, it is worth remembering that if lkml can self-host, so should we.

Linux kernel is 100x bigger than ffmpeg in terms of contributors, 
resources, and "clout". They can afford to self host.



And, in the wake of the GitHub Copilot scandal, I think it is pretty
obvious we should definitely not choose solutions that are under
singular private control.

The mailing list right now is under private control right now as well. 
Its just that the private control isn't Google or a big company. Rather, 
it is Fabrice Bellard.
I do think something needs to be done about it, I just don't think this 
is the right place to do it.

Regards,

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

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

___
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] ffmpeg-web/robots.txt: attempt to keep spiders out of dynamically generated git content

[ffmpegandmahanstreamer]

On 2021-07-14 14:51, Michael Niedermayer wrote:

Signed-off-by: Michael Niedermayer 
---
 htdocs/robots.txt | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index eb05362..4bbc395 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -1,2 +1,13 @@
 User-agent: *
-Disallow:
+Crawl-delay: 10
+Disallow: /gitweb/
+Disallow: /*a=search*
+Disallow: /*/search/*
+Disallow: /*a=blobdiff*
+Disallow: /*/blobdiff/*
+Disallow: /*a=commitdiff*
+Disallow: /*/commitdiff/*
+Disallow: /*a=snapshot*
+Disallow: /*/snapshot/*
+Disallow: /*a=blame*
+Disallow: /*/blame/*
LGTM based on my own personal experiences. But the robots.txt has to be 
applied for git.ffmpeg.org as well, and not just ffmpeg.org. Or else 
they will just do the same for git.ffmpeg since there are treated 
separately.

___
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][ffmpeg-web] Add Reddit fourm

[ffmpegandmahanstreamer]

This adds the Reddit subreddit to the forum section. It has over 7000 
participants. Many of the developers on here, like Gyan and Paul, 
participate on there already. I also think Gyan is the moderator of that 
subreddit as well. And reddit is more popular than superuser.

---
 src/contact | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/contact b/src/contact
index 4f75655..786 100644
--- a/src/contact
+++ b/src/contact
@@ -159,4 +159,7 @@
   
 href="https://superuser.com/questions/tagged/ffmpeg";>FFmpeg at 
SuperUser

   
+
+href="https://reddit.com/r/ffmpeg";>FFmpeg at Reddit

+  
  
--
___
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] Mailing List Delay

[ffmpegandmahanstreamer]

For what it's worth, I'm moving to e.email. I will see how the delay 
dynamic works over there as well. So far it also seems like a good 
option that I would recommend.


I do know that Yandex has a very long delay (if its even sent at all) 
because I tried that and it didn't even get the confirmation.


I was recommended the lolcow email service I am using by a fellow video 
editor and enthusiast i've known for a while. However, due to it 
constantly being unable to read mails due to an interface bug (the email 
is there, but doesn't show up until I hit "reply to"), I have decided to 
make the switch. I also looked into the person behind the cow service 
and he has been involved in some  less than trustworthy  things 
that's beyond the scope of this mailing list.


On 2021-07-14 14:55, Nicolas George wrote:

ffmpegandmahanstreamer@lolcow.email (12021-07-14):

I'm not against fixing the mailing list. No, not at all. It need to be
fixed. But Google is big company and trying to figure out how to make 
their

mail deliver successfully might be a problem.

I think this was the reasoning behind alot of the major open source 
projects
switching to Nongnu.org and Google Groups along with Github 
discussions.

IIRC even the Alliance of Open Media has their patch mailing list on
Groups.io and Google Groups now. But I'm not saying FFMPEG should. 
Just
saying that other projects have been facing similar issues and fixed 
it by
moving to a large mailing list hub. And libvpx uses Google mail 
servers for

their patches as well.


This discussion would be incomplete without reminding that Google and
these large actors have, under the excuse of fighting spam, 
unilaterally

changed the protocols they implement in ways that makes it harder for
small actors to stay in the game.

Therefore, the terms of the alternative are between choosing a solution
that is seamless even for the clueless but at the same time that 
enables

the monopolists and strengthen their position, or resisting the
monopolists and bearing a few technical hurdles for people who use 
their

services.

Since FFmpeg is a major Libre Software project, and one that is quite
technical at that, I think it should be obvious our side is the one of
freedom and against the monopolists.

Furthermore, FFmpeg has some importance for Google itself, which could
give us weight in asking they fix their shit if they want their users 
to

be able to contribute without hassle. That would benefit all projects
who want to self-host their mailing-lists.

Also, it is worth remembering that if lkml can self-host, so should we.

And, in the wake of the GitHub Copilot scandal, I think it is pretty
obvious we should definitely not choose solutions that are under
singular private control.

Regards,

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

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

___
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] ffmpeg: add option readrate

[ffmpegandmahanstreamer]

Put the fact that -re is equivalent to -readrate 1 in the deprecated message so 
people know what to switch to.

Other than that looks good to me.
___
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][libavcodec] Adding sprite support to duck truemotion1

[ffmpegandmahanstreamer]

Overrides previous patch i submitted regarding this as the old patch I 
submitted had a bug that is fixed in this one.

---
 libavcodec/truemotion1.c | 206 +--
 1 file changed, 174 insertions(+), 32 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..b8e8379c74 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -23,10 +23,11 @@
  * @file
  * Duck TrueMotion v1 Video Decoder by
  * Alex Beregszaszi and
- * Mike Melanson (melan...@pcisys.net)
+ * Mike Melanson (m...@multimedia.cx)
  *
- * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
- * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported yet.
+ * The TrueMotion v1 decoder presently decodes 16-bit/24-bit TM1 data and
+ * outputs RGB555 (or RGB565) data.
+ * ffmpegandmahanstreamer@e.email: added sprite support 7/22/21
  */
 
 #include 
@@ -56,9 +57,15 @@ typedef struct TrueMotion1Context {
 
 int flags;
 int x, y, w, h;
+
+int xoffset;
+int yoffset;
+int spritew;
+int spriteh;
 
 uint32_t y_predictor_table[1024];
 uint32_t c_predictor_table[1024];
+uint32_t a_predictor_table[1024];
 uint32_t fat_y_predictor_table[1024];
 uint32_t fat_c_predictor_table[1024];
 
@@ -66,6 +73,7 @@ typedef struct TrueMotion1Context {
 int block_type;
 int block_width;
 int block_height;
+
 
 int16_t ydt[8];
 int16_t cdt[8];
@@ -217,7 +225,10 @@ static int make_cdt16_entry(int p1, int p2, int16_t *cdt)
 lo = b + r;
 return (lo + (lo * (1 << 16))) * 2;
 }
-
+static int make_adt_entry(int p1, int p2) {
+int a = p1 + (p2 * 5);
+return ((a << 16) << 1);
+}
 static int make_ydt24_entry(int p1, int p2, int16_t *ydt)
 {
 int lo, hi;
@@ -251,9 +262,12 @@ static void gen_vector_table15(TrueMotion1Context *s, 
const uint8_t *sel_vector_
 make_ydt15_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
 s->c_predictor_table[i+j] = 0xfffe &
 make_cdt15_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
+s->a_predictor_table[i+j] = 0xfffe &
+make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
 }
 s->y_predictor_table[i+(j-1)] |= 1;
 s->c_predictor_table[i+(j-1)] |= 1;
+s->a_predictor_table[i+(j-1)] |= 1;
 }
 }
 
@@ -272,9 +286,12 @@ static void gen_vector_table16(TrueMotion1Context *s, 
const uint8_t *sel_vector_
 make_ydt16_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
 s->c_predictor_table[i+j] = 0xfffe &
 make_cdt16_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
+s->a_predictor_table[i+j] = 0xfffe &
+make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
 }
 s->y_predictor_table[i+(j-1)] |= 1;
 s->c_predictor_table[i+(j-1)] |= 1;
+s->a_predictor_table[i+(j-1)] |= 1;
 }
 }
 
@@ -360,9 +377,19 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
 s->flags = FLAG_KEYFRAME;
 
 if (s->flags & FLAG_SPRITE) {
-avpriv_request_sample(s->avctx, "Frame with sprite");
-/* FIXME header.width, height, xoffset and yoffset aren't initialized 
*/
-return AVERROR_PATCHWELCOME;
+// https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
+header.xoffset = AV_RL16(&header_buffer[13]);
+header.yoffset = AV_RL16(&header_buffer[15]);
+header.width = AV_RL16(&header_buffer[17]);
+header.height = AV_RL16(&header_buffer[19]);
+s->w = header.xsize;
+s->h = header.ysize;
+s->spritew = header.width;
+s->spriteh = header.height;
+s->xoffset = header.xoffset;
+s->yoffset = header.yoffset;
+  //  avpriv_request_sample(s->avctx, "Frame with sprite");
+  //  return AVERROR_PATCHWELCOME;
 } else {
 s->w = header.xsize;
 s->h = header.ysize;
@@ -427,6 +454,9 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
  * 32 pixels; divide width by 4 to obtain the number of change bits and
  * then round up to the nearest byte. */
 s->mb_change_bits_row_size = ((s->avctx->width >> (2 - width_shift)) + 7) 
>> 3;
+if (s->flags & FLAG_SPRITE) {
+s->mb_change_bits_row_size = ((s->spritew >>  2) + 3) >> 2;
+}
 
 if ((header.deltaset != s->last_deltaset) || (header.vectable != 
s->last_vectable))
 {
@@ -441,7 +471,7 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
 
 /* set up pointers to the other key data chunks */
 s->mb_change_bits = s->buf + header.header_size;
-if (

Re: [FFmpeg-devel] [PATCH][libavcodec] Adding sprite support to duck truemotion1

[ffmpegandmahanstreamer]

Yes, i have them, obviously.

>From the mahanstreamer maintainer: 
>https://drive.google.com/drive/folders/1L0b4h3sYc_fWFTdndtRO5vGSNmLW3pGD?usp=sharing

The file you are looking for is "buttons.avi"

(I am not committer so can't upload to ffmpeg sample server)

July 22, 2021 4:30 PM, "Paul B Mahol"  wrote:

> Samples to test this?
> 
> On Thu, Jul 22, 2021 at 10:27 PM  wrote:
> 
>> Overrides previous patch i submitted regarding this as the old patch I
>> submitted had a bug that is fixed in this one.
>> 
>> ---
>> libavcodec/truemotion1.c | 206 +--
>> 1 file changed, 174 insertions(+), 32 deletions(-)
>> 
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..b8e8379c74 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -23,10 +23,11 @@
>> * @file
>> * Duck TrueMotion v1 Video Decoder by
>> * Alex Beregszaszi and
>> - * Mike Melanson (melan...@pcisys.net)
>> + * Mike Melanson (m...@multimedia.cx)
>> *
>> - * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
>> - * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported yet.
>> + * The TrueMotion v1 decoder presently decodes 16-bit/24-bit TM1 data and
>> + * outputs RGB555 (or RGB565) data.
>> + * ffmpegandmahanstreamer@e.email: added sprite support 7/22/21
>> */
>> 
>> #include 
>> @@ -56,9 +57,15 @@ typedef struct TrueMotion1Context {
>> 
>> int flags;
>> int x, y, w, h;
>> +
>> + int xoffset;
>> + int yoffset;
>> + int spritew;
>> + int spriteh;
>> 
>> uint32_t y_predictor_table[1024];
>> uint32_t c_predictor_table[1024];
>> + uint32_t a_predictor_table[1024];
>> uint32_t fat_y_predictor_table[1024];
>> uint32_t fat_c_predictor_table[1024];
>> 
>> @@ -66,6 +73,7 @@ typedef struct TrueMotion1Context {
>> int block_type;
>> int block_width;
>> int block_height;
>> +
>> 
>> int16_t ydt[8];
>> int16_t cdt[8];
>> @@ -217,7 +225,10 @@ static int make_cdt16_entry(int p1, int p2, int16_t
>> *cdt)
>> lo = b + r;
>> return (lo + (lo * (1 << 16))) * 2;
>> }
>> -
>> +static int make_adt_entry(int p1, int p2) {
>> + int a = p1 + (p2 * 5);
>> + return ((a << 16) << 1);
>> +}
>> static int make_ydt24_entry(int p1, int p2, int16_t *ydt)
>> {
>> int lo, hi;
>> @@ -251,9 +262,12 @@ static void gen_vector_table15(TrueMotion1Context *s,
>> const uint8_t *sel_vector_
>> make_ydt15_entry(delta_pair >> 4, delta_pair & 0xf,
>> s->ydt);
>> s->c_predictor_table[i+j] = 0xfffe &
>> make_cdt15_entry(delta_pair >> 4, delta_pair & 0xf,
>> s->cdt);
>> + s->a_predictor_table[i+j] = 0xfffe &
>> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
>> }
>> s->y_predictor_table[i+(j-1)] |= 1;
>> s->c_predictor_table[i+(j-1)] |= 1;
>> + s->a_predictor_table[i+(j-1)] |= 1;
>> }
>> }
>> 
>> @@ -272,9 +286,12 @@ static void gen_vector_table16(TrueMotion1Context *s,
>> const uint8_t *sel_vector_
>> make_ydt16_entry(delta_pair >> 4, delta_pair & 0xf,
>> s->ydt);
>> s->c_predictor_table[i+j] = 0xfffe &
>> make_cdt16_entry(delta_pair >> 4, delta_pair & 0xf,
>> s->cdt);
>> + s->a_predictor_table[i+j] = 0xfffe &
>> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
>> }
>> s->y_predictor_table[i+(j-1)] |= 1;
>> s->c_predictor_table[i+(j-1)] |= 1;
>> + s->a_predictor_table[i+(j-1)] |= 1;
>> }
>> }
>> 
>> @@ -360,9 +377,19 @@ static int
>> truemotion1_decode_header(TrueMotion1Context *s)
>> s->flags = FLAG_KEYFRAME;
>> 
>> if (s->flags & FLAG_SPRITE) {
>> - avpriv_request_sample(s->avctx, "Frame with sprite");
>> - /* FIXME header.width, height, xoffset and yoffset aren't
>> initialized */
>> - return AVERROR_PATCHWELCOME;
>> + // https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
>> + header.xoffset = AV_RL16(&header_buffer[13]);
>> + header.yoffset = AV_RL16(&header_buffer[15]);
>> + header.width = AV_RL16(&header_buffer[17]);
>> + header.height = AV_RL16(&header_buffer[19]);
>> + s->w = header.xsize;
>> + s->h = header.ysize;
>> + s->spritew = header.width;
>> + s->spriteh = header.height;
>> + s->xoffset = header.xoffset;
>> + s->yo

Re: [FFmpeg-devel] Hardware purchase request

[ffmpegandmahanstreamer]

Well obviously i'm not committer yet or responsible for this but I think its a 
good idea for Lynne to get the hardware she needs. Price looks reasonable, I 
would give the goahead.

July 28, 2021 7:07 PM, "Lynne"  wrote:

> 9 Jul 2021, 12:59 by d...@lynne.ee:
> 
>> 8 Jul 2021, 22:32 by stefa...@gmail.com:
>> 
>>> On Mon, Jun 28, 2021 at 2:50 AM Lynne  wrote:
>> 
>> 27 Jun 2021, 19:33 by kier...@obe.tv:
>> 
 
 I'm thinking of getting a:
 LG UltraGear 27GN950-B
 
>>> 
>>> Can I ask why you need a ~£1000 monitor? What does it do that others can't?
>>> 
>> 
>> It's 850, with occasional dips to 770 euros. It's the only choice for a 4k 
>> monitor
>> with a refresh rate of over 60Hz, it's got good color compliance, freesync,
>> and it has HDR with a >10bit mode.
>> 
>>> Hi,
>>> Lynne please send the expected refund total amount and the item list.
>>> I think we agreed with a total expense around 4K EUR and I volunteer
>>> to pay in advance (assuming SPI will accept, which is most likely),
>>> let's try to get around the discussion of the fine details.
>> 
>> Fractal Design Ion+ 860 W
>> Fractal Design Define 7 Compact
>> XFX Speedster MERC 319 Radeon RX 6900 XT
>> Samsung 980 PRO 2TB
>> LG UltraGear 27GN950-B
>> All of this comes to just under 3000 euros, using the current prices on 
>> geizhals.eu.
>> 
>> If 4000 euros is what we agreed, add:
>> AMD Ryzen 9 5900X
>> Corsair Vengeance RGB Pro 32GB 3600Mhz
>> Asus TUF GAMING X570-PLUS (WI-FI)
>> Which adds up to just under 1000 euros, making it 4000 euros.
>> 
>> Components have gotten cheaper since I last checked.
> 
> Ping (I pinged Stefano 2 weeks ago as well, no response).
> ___
> 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 2/2] avformat/movenc: parse h264 packets to build Sync Sample and Recovery Point tables

[ffmpegandmahanstreamer]

I always meant to ask what is meaning of your profile picture?

July 28, 2021 6:51 PM, "Derek Buitenhuis"  wrote:

> On 7/27/2021 2:08 PM, James Almer wrote:
> 
>> Since we can't blindly trust the keyframe flag in packets and assume its
>> contents are a valid Sync Sample, do some basic bitstream parsing to build 
>> the
>> Sync Sample table in addition to a Random Access Recovery Point table.
>> 
>> Suggested-by: ffm...@fb.com
>> Signed-off-by: James Almer 
>> ---
>> libavformat/movenc.c | 125 +--
>> libavformat/movenc.h | 1 +
>> tests/ref/lavf-fate/h264.mp4 | 6 +-
>> 3 files changed, 123 insertions(+), 9 deletions(-)
> 
> This problem (due to insufficient API) exists for a lot more codecs
> than H.264 - are we going to fill movenc.c with parsers for HEVC,
> AV1, MPEG-4 ASP, etc., or just make only on codec behave this way?
> 
> - Derek
> ___
> 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][libavcodec] Adding sprite support to duck truemotion1

[ffmpegandmahanstreamer]

B
  U
M
  P
so i can submit new patches

July 22, 2021 4:27 PM, ffmpegandmahanstreamer@e.email wrote:

> Overrides previous patch i submitted regarding this as the old patch I 
> submitted had a bug that is
> fixed in this one.
> 
> ---
> libavcodec/truemotion1.c | 206 +--
> 1 file changed, 174 insertions(+), 32 deletions(-)
> 
> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
> index 32d8fb4005..b8e8379c74 100644
> --- a/libavcodec/truemotion1.c
> +++ b/libavcodec/truemotion1.c
> @@ -23,10 +23,11 @@
> * @file
> * Duck TrueMotion v1 Video Decoder by
> * Alex Beregszaszi and
> - * Mike Melanson (melan...@pcisys.net)
> + * Mike Melanson (m...@multimedia.cx)
> *
> - * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
> - * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported yet.
> + * The TrueMotion v1 decoder presently decodes 16-bit/24-bit TM1 data and
> + * outputs RGB555 (or RGB565) data.
> + * ffmpegandmahanstreamer@e.email: added sprite support 7/22/21
> */
> 
> #include 
> @@ -56,9 +57,15 @@ typedef struct TrueMotion1Context {
> 
> int flags;
> int x, y, w, h;
> + 
> + int xoffset;
> + int yoffset;
> + int spritew;
> + int spriteh;
> 
> uint32_t y_predictor_table[1024];
> uint32_t c_predictor_table[1024];
> + uint32_t a_predictor_table[1024];
> uint32_t fat_y_predictor_table[1024];
> uint32_t fat_c_predictor_table[1024];
> 
> @@ -66,6 +73,7 @@ typedef struct TrueMotion1Context {
> int block_type;
> int block_width;
> int block_height;
> + 
> 
> int16_t ydt[8];
> int16_t cdt[8];
> @@ -217,7 +225,10 @@ static int make_cdt16_entry(int p1, int p2, int16_t *cdt)
> lo = b + r;
> return (lo + (lo * (1 << 16))) * 2;
> }
> -
> +static int make_adt_entry(int p1, int p2) {
> + int a = p1 + (p2 * 5);
> + return ((a << 16) << 1);
> +}
> static int make_ydt24_entry(int p1, int p2, int16_t *ydt)
> {
> int lo, hi;
> @@ -251,9 +262,12 @@ static void gen_vector_table15(TrueMotion1Context *s, 
> const uint8_t
> *sel_vector_
> make_ydt15_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
> s->c_predictor_table[i+j] = 0xfffe &
> make_cdt15_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
> + s->a_predictor_table[i+j] = 0xfffe &
> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
> }
> s->y_predictor_table[i+(j-1)] |= 1;
> s->c_predictor_table[i+(j-1)] |= 1;
> + s->a_predictor_table[i+(j-1)] |= 1;
> }
> }
> 
> @@ -272,9 +286,12 @@ static void gen_vector_table16(TrueMotion1Context *s, 
> const uint8_t
> *sel_vector_
> make_ydt16_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
> s->c_predictor_table[i+j] = 0xfffe &
> make_cdt16_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
> + s->a_predictor_table[i+j] = 0xfffe &
> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
> }
> s->y_predictor_table[i+(j-1)] |= 1;
> s->c_predictor_table[i+(j-1)] |= 1;
> + s->a_predictor_table[i+(j-1)] |= 1;
> }
> }
> 
> @@ -360,9 +377,19 @@ static int truemotion1_decode_header(TrueMotion1Context 
> *s)
> s->flags = FLAG_KEYFRAME;
> 
> if (s->flags & FLAG_SPRITE) {
> - avpriv_request_sample(s->avctx, "Frame with sprite");
> - /* FIXME header.width, height, xoffset and yoffset aren't initialized */
> - return AVERROR_PATCHWELCOME;
> + // https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
> + header.xoffset = AV_RL16(&header_buffer[13]);
> + header.yoffset = AV_RL16(&header_buffer[15]);
> + header.width = AV_RL16(&header_buffer[17]);
> + header.height = AV_RL16(&header_buffer[19]);
> + s->w = header.xsize;
> + s->h = header.ysize;
> + s->spritew = header.width;
> + s->spriteh = header.height;
> + s->xoffset = header.xoffset;
> + s->yoffset = header.yoffset;
> + // avpriv_request_sample(s->avctx, "Frame with sprite");
> + // return AVERROR_PATCHWELCOME;
> } else {
> s->w = header.xsize;
> s->h = header.ysize;
> @@ -427,6 +454,9 @@ static int truemotion1_decode_header(TrueMotion1Context 
> *s)
> * 32 pixels; divide width by 4 to obtain the number of change bits and
> * then round up to the nearest byte. */
> s->mb_change_bits_row_size = ((s->avctx->width >> (2 - width_shift)) + 7) >> 
> 3;
> + if (s->flags & FLAG_SPRITE) {
> + s->mb_change_bits_row_size = ((s->spritew >> 2) + 3) >> 2;
> + }
> 
> if ((header.deltaset != s->last_deltaset) || (header.vectable != 
> s->last_vectable))
&

Re: [FFmpeg-devel] [PATCH][libavcodec] Adding sprite support to duck truemotion1

[ffmpegandmahanstreamer]

July 31, 2021 8:25 AM, "Andreas Rheinhardt"  
wrote:

> ffmpegandmahanstreamer@e.email:
> 
>> Overrides previous patch i submitted regarding this as the old patch I 
>> submitted had a bug that is
>> fixed in this one.
> 
> This is not an acceptable commit message: You are supposed to actually
> describe the patch here and not the evolution of your patch. Such a
> comment belongs immediately below the --- below.
> 
In my next patch how about "This patch adds sprite support to the Duck 
TrueMotion1 decoder."
I thought it was above the three lines not below?
>> ---
>> libavcodec/truemotion1.c | 206 +--
>> 1 file changed, 174 insertions(+), 32 deletions(-)
>> 
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..b8e8379c74 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -23,10 +23,11 @@
>> * @file
>> * Duck TrueMotion v1 Video Decoder by
>> * Alex Beregszaszi and
>> - * Mike Melanson (melan...@pcisys.net)
>> + * Mike Melanson (m...@multimedia.cx)
>> *
>> - * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
>> - * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported yet.
>> + * The TrueMotion v1 decoder presently decodes 16-bit/24-bit TM1 data and
>> + * outputs RGB555 (or RGB565) data.
>> + * ffmpegandmahanstreamer@e.email: added sprite support 7/22/21
>> */
>> 
>> #include 
>> @@ -56,9 +57,15 @@ typedef struct TrueMotion1Context {
>> 
>> int flags;
>> int x, y, w, h;
>> +
>> + int xoffset;
>> + int yoffset;
>> + int spritew;
>> + int spriteh;
>> 
>> uint32_t y_predictor_table[1024];
>> uint32_t c_predictor_table[1024];
>> + uint32_t a_predictor_table[1024];
>> uint32_t fat_y_predictor_table[1024];
>> uint32_t fat_c_predictor_table[1024];
>> 
>> @@ -66,6 +73,7 @@ typedef struct TrueMotion1Context {
>> int block_type;
>> int block_width;
>> int block_height;
>> +
> 
> Spurious change.
Must have been mistake on my patch generator. Will fix in updated patch.
> 
>> int16_t ydt[8];
>> int16_t cdt[8];
>> @@ -217,7 +225,10 @@ static int make_cdt16_entry(int p1, int p2, int16_t 
>> *cdt)
>> lo = b + r;
>> return (lo + (lo * (1 << 16))) * 2;
>> }
>> -
>> +static int make_adt_entry(int p1, int p2) {
>> + int a = p1 + (p2 * 5);
>> + return ((a << 16) << 1);
>> +}
>> static int make_ydt24_entry(int p1, int p2, int16_t *ydt)
>> {
>> int lo, hi;
>> @@ -251,9 +262,12 @@ static void gen_vector_table15(TrueMotion1Context *s, 
>> const uint8_t
>> *sel_vector_
>> make_ydt15_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
>> s->c_predictor_table[i+j] = 0xfffe &
>> make_cdt15_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
>> + s->a_predictor_table[i+j] = 0xfffe &
>> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
>> }
>> s->y_predictor_table[i+(j-1)] |= 1;
>> s->c_predictor_table[i+(j-1)] |= 1;
>> + s->a_predictor_table[i+(j-1)] |= 1;
>> }
>> }
>> 
>> @@ -272,9 +286,12 @@ static void gen_vector_table16(TrueMotion1Context *s, 
>> const uint8_t
>> *sel_vector_
>> make_ydt16_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
>> s->c_predictor_table[i+j] = 0xfffe &
>> make_cdt16_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
>> + s->a_predictor_table[i+j] = 0xfffe &
>> + make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
>> }
>> s->y_predictor_table[i+(j-1)] |= 1;
>> s->c_predictor_table[i+(j-1)] |= 1;
>> + s->a_predictor_table[i+(j-1)] |= 1;
>> }
>> }
>> 
>> @@ -360,9 +377,19 @@ static int truemotion1_decode_header(TrueMotion1Context 
>> *s)
>> s->flags = FLAG_KEYFRAME;
>> 
>> if (s->flags & FLAG_SPRITE) {
>> - avpriv_request_sample(s->avctx, "Frame with sprite");
>> - /* FIXME header.width, height, xoffset and yoffset aren't initialized */
>> - return AVERROR_PATCHWELCOME;
>> + // https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
>> + header.xoffset = AV_RL16(&header_buffer[13]);
>> + header.yoffset = AV_RL16(&header_buffer[15]);
>> + header.width = AV_RL16(&header_buffer[17]);
>> + header.height = AV_RL16(&header_buffer[19]);
>> + s->w = header.xsize;
>> + s->h = header.ysize;
>> + s->sprite

Re: [FFmpeg-devel] [PATCH][libavcodec] Adding sprite support to duck truemotion1

[ffmpegandmahanstreamer]

Hello GEORGE.

"avfilter/avf_showfreqs: switch to TX FFT from avutil"
"avfilter/af_silenceremove: make window also depends on input sample format"
And from Andreas himself: "postproc/postprocess: Remove legacy cruft"
are some examples, so i should be good. Some have a two or three sentences 
while others just have one sentence.
How much do you want me to write? There's not much to it.


July 31, 2021 10:01 AM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer@e.email (12021-07-31):
> 
>> In my next patch how about "This patch adds sprite support to the Duck 
>> TrueMotion1 decoder."
> 
> Have you considered looking at what other people do, especially regular
> developers?
> 
> https://git.ffmpeg.org/ffmpeg.git
> 
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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] Subject: [PATCH] Cleanup code in truemotion1 decoder

[ffmpegandmahanstreamer]

Per Andreas Rheinhardt request i'm splitting the working patches in two.
---
This cleans up the code in the decode24bit and decode16bit functions by putting 
it in way that expresses the true intent while making it easier to read.
 libavcodec/truemotion1.c | 36 
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..50c90e732d 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -655,25 +655,19 @@ static void truemotion1_decode_16bit(TrueMotion1Context 
*s)
 while (pixels_left > 0) {
 
 if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
-
+
 switch (y & 3) {
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 break;
 
 case 1:
@@ -781,25 +775,19 @@ static void truemotion1_decode_24bit(TrueMotion1Context 
*s)
 while (pixels_left > 0) {
 
 if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
-
+
 switch (y & 3) {
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 break;
 
 case 1:
-- 
2.24.3
___
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] adds sprite support to truemotion1 codec

[ffmpegandmahanstreamer]

request of Andreas again. Samples with sprites can be found where i posted link.
---
This adds sprite support to the truemotion1 codec, which was a feature in this 
codec.
 libavcodec/truemotion1.c | 165 ---
 1 file changed, 155 insertions(+), 10 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..a3ffa15702 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -23,10 +23,11 @@
  * @file
  * Duck TrueMotion v1 Video Decoder by
  * Alex Beregszaszi and
- * Mike Melanson (melan...@pcisys.net)
+ * Mike Melanson (m...@multimedia.cx)
  *
- * The TrueMotion v1 decoder presently only decodes 16-bit TM1 data and
- * outputs RGB555 (or RGB565) data. 24-bit TM1 data is not supported yet.
+ * The TrueMotion v1 decoder presently decodes 16-bit/24-bit TM1 data and
+ * outputs RGB555 (or RGB565) data.
+ * ffmpegandmahanstreamer@e.email: added sprite support 7/22/21
  */
 
 #include 
@@ -56,9 +57,15 @@ typedef struct TrueMotion1Context {
 
 int flags;
 int x, y, w, h;
+
+int xoffset;
+int yoffset;
+int spritew;
+int spriteh;
 
 uint32_t y_predictor_table[1024];
 uint32_t c_predictor_table[1024];
+uint32_t a_predictor_table[1024];
 uint32_t fat_y_predictor_table[1024];
 uint32_t fat_c_predictor_table[1024];
 
@@ -217,7 +224,10 @@ static int make_cdt16_entry(int p1, int p2, int16_t *cdt)
 lo = b + r;
 return (lo + (lo * (1 << 16))) * 2;
 }
-
+static int make_adt_entry(int p1, int p2) {
+int a = p1 + (p2 * 5);
+return ((a << 16) << 1);
+}
 static int make_ydt24_entry(int p1, int p2, int16_t *ydt)
 {
 int lo, hi;
@@ -251,9 +261,12 @@ static void gen_vector_table15(TrueMotion1Context *s, 
const uint8_t *sel_vector_
 make_ydt15_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
 s->c_predictor_table[i+j] = 0xfffe &
 make_cdt15_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
+s->a_predictor_table[i+j] = 0xfffe &
+make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
 }
 s->y_predictor_table[i+(j-1)] |= 1;
 s->c_predictor_table[i+(j-1)] |= 1;
+s->a_predictor_table[i+(j-1)] |= 1;
 }
 }
 
@@ -272,9 +285,12 @@ static void gen_vector_table16(TrueMotion1Context *s, 
const uint8_t *sel_vector_
 make_ydt16_entry(delta_pair >> 4, delta_pair & 0xf, s->ydt);
 s->c_predictor_table[i+j] = 0xfffe &
 make_cdt16_entry(delta_pair >> 4, delta_pair & 0xf, s->cdt);
+s->a_predictor_table[i+j] = 0xfffe &
+make_adt_entry(delta_pair >> 4, delta_pair & 0xf);
 }
 s->y_predictor_table[i+(j-1)] |= 1;
 s->c_predictor_table[i+(j-1)] |= 1;
+s->a_predictor_table[i+(j-1)] |= 1;
 }
 }
 
@@ -360,9 +376,17 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
 s->flags = FLAG_KEYFRAME;
 
 if (s->flags & FLAG_SPRITE) {
-avpriv_request_sample(s->avctx, "Frame with sprite");
-/* FIXME header.width, height, xoffset and yoffset aren't initialized 
*/
-return AVERROR_PATCHWELCOME;
+// https://wiki.multimedia.cx/index.php/Duck_TrueMotion_1
+header.xoffset = AV_RL16(&header_buffer[13]);
+header.yoffset = AV_RL16(&header_buffer[15]);
+header.width = AV_RL16(&header_buffer[17]);
+header.height = AV_RL16(&header_buffer[19]);
+s->w = header.xsize;
+s->h = header.ysize;
+s->spritew = header.width;
+s->spriteh = header.height;
+s->xoffset = header.xoffset;
+s->yoffset = header.yoffset;
 } else {
 s->w = header.xsize;
 s->h = header.ysize;
@@ -427,6 +451,9 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
  * 32 pixels; divide width by 4 to obtain the number of change bits and
  * then round up to the nearest byte. */
 s->mb_change_bits_row_size = ((s->avctx->width >> (2 - width_shift)) + 7) 
>> 3;
+if (s->flags & FLAG_SPRITE) {
+s->mb_change_bits_row_size = ((s->spritew >>  2) + 3) >> 2;
+}
 
 if ((header.deltaset != s->last_deltaset) || (header.vectable != 
s->last_vectable))
 {
@@ -441,7 +468,7 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
 
 /* set up pointers to the other key data chunks */
 s->mb_change_bits = s->buf + header.header_size;
-if (s->flags & FLAG_KEYFRAME) {
+if ((s->flags & FLAG_KEYFRAME) && ((s->flags & FLAG_SPRITE) == 0)) {
 /* no change bits specified for a keyframe; only index bytes */
 s->index_stream = s->mb_change_bits;
  

Re: [FFmpeg-devel] [PATCH 3/4] libavformat/hls: add support for decryption of HLS media segments encrypted using SAMPLE-AES encryption method

[ffmpegandmahanstreamer]

lgtm after you fix nitpick about if statements in my opinon

August 1, 2021 10:54 AM, "Nachiket Tarate"  
wrote:

> Apple HTTP Live Streaming Sample Encryption:
> 
> https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
> 
> Signed-off-by: Nachiket Tarate 
> ---
> libavformat/Makefile | 2 +-
> libavformat/hls.c | 128 +++--
> libavformat/hls_sample_encryption.c | 389 
> libavformat/hls_sample_encryption.h | 65 +
> libavformat/mpegts.c | 11 +
> 5 files changed, 576 insertions(+), 19 deletions(-)
> create mode 100644 libavformat/hls_sample_encryption.c
> create mode 100644 libavformat/hls_sample_encryption.h
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 813ddd3c20..7e3c9c23c6 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -238,7 +238,7 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o pcm.o
> OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
> OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
> OBJS-$(CONFIG_HEVC_MUXER) += rawenc.o
> -OBJS-$(CONFIG_HLS_DEMUXER) += hls.o
> +OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_encryption.o
> OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
> OBJS-$(CONFIG_HNM_DEMUXER) += hnm.o
> OBJS-$(CONFIG_ICO_DEMUXER) += icodec.o
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3c1b80f60c..022dae0391 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2,6 +2,7 @@
> * Apple HTTP Live Streaming demuxer
> * Copyright (c) 2010 Martin Storsjo
> * Copyright (c) 2013 Anssi Hannula
> + * Copyright (c) 2021 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -39,6 +40,8 @@
> #include "avio_internal.h"
> #include "id3v2.h"
> 
> +#include "hls_sample_encryption.h"
> +
> #define INITIAL_BUFFER_SIZE 32768
> 
> #define MAX_FIELD_LEN 64
> @@ -145,6 +148,8 @@ struct playlist {
> int id3_changed; /* ID3 tag data has changed at some point */
> ID3v2ExtraMeta *id3_deferred_extra; /* stored here until subdemuxer is opened 
> */
> 
> + HLSAudioSetupInfo audio_setup_info;
> +
> int64_t seek_timestamp;
> int seek_flags;
> int seek_stream_index; /* into subdemuxer stream array */
> @@ -214,6 +219,7 @@ typedef struct HLSContext {
> int http_multiple;
> int http_seekable;
> AVIOContext *playlist_pb;
> + HLSCryptoContext crypto_ctx;
> } HLSContext;
> 
> static void free_segment_dynarray(struct segment **segments, int n_segments)
> @@ -1006,7 +1012,10 @@ fail:
> 
> static struct segment *current_segment(struct playlist *pls)
> {
> - return pls->segments[pls->cur_seq_no - pls->start_seq_no];
> + int64_t n = pls->cur_seq_no - pls->start_seq_no;
> + if (n >= pls->n_segments)
> + return NULL;
> + return pls->segments[n];
> }
> 
> static struct segment *next_segment(struct playlist *pls)
> @@ -1035,17 +1044,18 @@ static int read_from_url(struct playlist *pls, struct 
> segment *seg,
> 
> /* Parse the raw ID3 data and pass contents to caller */
> static void parse_id3(AVFormatContext *s, AVIOContext *pb,
> - AVDictionary **metadata, int64_t *dts,
> + AVDictionary **metadata, int64_t *dts, HLSAudioSetupInfo *audio_setup_info,
> ID3v2ExtraMetaAPIC **apic, ID3v2ExtraMeta **extra_meta)
> {
> static const char id3_priv_owner_ts[] = 
> "com.apple.streaming.transportStreamTimestamp";
> + static const char id3_priv_owner_audio_setup[] = 
> "com.apple.streaming.audioDescription";
> ID3v2ExtraMeta *meta;
> 
> ff_id3v2_read_dict(pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
> for (meta = *extra_meta; meta; meta = meta->next) {
> if (!strcmp(meta->tag, "PRIV")) {
> ID3v2ExtraMetaPRIV *priv = &meta->data.priv;
> - if (priv->datasize == 8 && !strcmp(priv->owner, id3_priv_owner_ts)) {
> + if (priv->datasize == 8 && !av_strncasecmp(priv->owner, id3_priv_owner_ts, 
> 44)) {
> /* 33-bit MPEG timestamp */
> int64_t ts = AV_RB64(priv->data);
> av_log(s, AV_LOG_DEBUG, "HLS ID3 audio timestamp %"PRId64"\n", ts);
> @@ -1053,6 +1063,8 @@ static void parse_id3(AVFormatContext *s, AVIOContext 
> *pb,
> *dts = ts;
> else
> av_log(s, AV_LOG_ERROR, "Invalid HLS ID3 audio timestamp %"PRId64"\n", ts);
> + } else if (priv->datasize >= 8 && !av_strncasecmp(priv->owner, 
> id3_priv_owner_audio_setup, 36)) {
> + ff_hls_senc_read_audio_setup_info(audio_setup_info, priv->data, 
> priv->datasize);
> }
> } else if (!strcmp(meta->tag, "APIC") && apic)
> *apic = &meta->data.apic;
> @@ -1096,7 +1108,7 @@ static void handle_id3(AVIOContext *pb, struct playlist 
> *pls)
> ID3v2ExtraMeta *extra_meta = NULL;
> int64_t timestamp = AV_NOPTS_VALUE;
> 
> - parse_id3(pls->ctx, pb, &metadata, ×tamp, &apic, &extra_meta);
> + parse_id3(pls->ctx, pb, &metadata, ×tamp, &pls->audio_setup_info, 
> &apic, &extra_meta);
> 
> if (timestamp != AV_NOPTS_VALUE) {
> pls->id3_mpegts_timestamp = timestamp;
> @@ -1250,10 +1262,7 @@ static int open_input(HLSContext *c, struct playlist 
> *pls, struct segment
> *seg,
> av_log(pls->parent, AV_LOG_VERBOSE, "HLS request for url '%s', offset 
> %"PRId64", playlist %d\n",
> seg->url, seg->

Re: [FFmpeg-devel] [PATCH] avfilter: add (a)separate filters

[ffmpegandmahanstreamer]

hello PAUL.

August 1, 2021 10:21 AM, "Paul B Mahol"  wrote:

> Signed-off-by: Paul B Mahol 
> ---
> doc/filters.texi | 31 
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> libavfilter/f_separate.c | 346 +++
> 4 files changed, 381 insertions(+)
> create mode 100644 libavfilter/f_separate.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 635179edb9..e40322417b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -26067,6 +26067,37 @@ 
> sendcmd=f=test.cmd,drawtext=fontfile=FreeSerif.ttf:text='',hue
> @end example
> @end itemize
> 
> +@section separate, aseparate
> +
> +Separate single input stream into multiple streams.
> +
> +@code{separate} works on video frames, @code{aseparate} on audio samples.
> +
> +This filter accepts the following options:
> +
> +@table @option
> +@item durations
> +Durations of input at which to separate input. Each duration point is 
> separated by '|'.
> +
> +@item frames, samples
> +Exact frame/sample at which to do separations of input video/audio stream. 
> Each point
> +is separated by '|'.
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +
> +@item
> +Separate input audio stream into three output audio streams, starting at 
> start of input audio
> stream
> +and storing that in 1st output audio stream, then following at 60th second 
> and storing than in 2nd
> +output audio stream, and last after 120th second of input audio stream store 
> in 3rd output audio
> stream:
> +@example
> +aseparate=durations="60 | 120"
> +@end example
> +
> +@end itemize
> +
> @anchor{setpts}
> @section setpts, asetpts
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 772971521c..73c26f4870 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -80,6 +80,7 @@ OBJS-$(CONFIG_AREVERSE_FILTER) += f_reverse.o
> OBJS-$(CONFIG_ARNNDN_FILTER) += af_arnndn.o
> OBJS-$(CONFIG_ASELECT_FILTER) += f_select.o
> OBJS-$(CONFIG_ASENDCMD_FILTER) += f_sendcmd.o
> +OBJS-$(CONFIG_ASEPARATE_FILTER) += f_separate.o
> OBJS-$(CONFIG_ASETNSAMPLES_FILTER) += af_asetnsamples.o
> OBJS-$(CONFIG_ASETPTS_FILTER) += setpts.o
> OBJS-$(CONFIG_ASETRATE_FILTER) += af_asetrate.o
> @@ -408,6 +409,7 @@ OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
> OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
> OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
> OBJS-$(CONFIG_SENDCMD_FILTER) += f_sendcmd.o
> +OBJS-$(CONFIG_SEPARATE_FILTER) += f_separate.o
> OBJS-$(CONFIG_SEPARATEFIELDS_FILTER) += vf_separatefields.o
> OBJS-$(CONFIG_SETDAR_FILTER) += vf_aspect.o
> OBJS-$(CONFIG_SETFIELD_FILTER) += vf_setparams.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index e0276eb98c..c11c680564 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -73,6 +73,7 @@ extern const AVFilter ff_af_areverse;
> extern const AVFilter ff_af_arnndn;
> extern const AVFilter ff_af_aselect;
> extern const AVFilter ff_af_asendcmd;
> +extern const AVFilter ff_af_aseparate;
> extern const AVFilter ff_af_asetnsamples;
> extern const AVFilter ff_af_asetpts;
> extern const AVFilter ff_af_asetrate;
> @@ -389,6 +390,7 @@ extern const AVFilter ff_vf_scroll;
> extern const AVFilter ff_vf_select;
> extern const AVFilter ff_vf_selectivecolor;
> extern const AVFilter ff_vf_sendcmd;
> +extern const AVFilter ff_vf_separate;
> extern const AVFilter ff_vf_separatefields;
> extern const AVFilter ff_vf_setdar;
> extern const AVFilter ff_vf_setfield;
> diff --git a/libavfilter/f_separate.c b/libavfilter/f_separate.c
> new file mode 100644
> index 00..46f8871c8a
> --- /dev/null
> +++ b/libavfilter/f_separate.c
> @@ -0,0 +1,346 @@
> +/*
> + * 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 
> +
> +#include "libavutil/avstring.h"
> +#include "libavutil/channel_layout.h"
> +#include "libavutil/common.h"
> +#include "libavutil/log.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/parseutils.h"
> +#include "libavutil/samplefmt.h"
> +
> +#include "audio.h"
> +#include "avfilter.h"
> +#include "filters.h"
> +#include "internal.h"
> +
> +typedef struct SeparateContext {
> + const AVClass *class;
> +
> + char *durations_str;

Re: [FFmpeg-devel] [PATCH] avfilter: add (a)separate filters

[ffmpegandmahanstreamer]

August 1, 2021 1:01 PM, "Nicolas George"  wrote:

> Paul B Mahol (12021-08-01):
> 
>> Signed-off-by: Paul B Mahol 
>> ---
>> doc/filters.texi | 31 
>> libavfilter/Makefile | 2 +
>> libavfilter/allfilters.c | 2 +
>> libavfilter/f_separate.c | 346 +++
>> 4 files changed, 381 insertions(+)
>> create mode 100644 libavfilter/f_separate.c
> 
> Did not review the code.
> 
> Separate seems the wrong word: afaik, it is to be used when things of
> different nature have gotten mixed together.
> 
> Split would be the best choice, and in line with mkvmerge options, but
> it is already used.
> 
> Maybe timesplit. Or segment.
> 
I thought too for a bit.
Seperate is best word, but split would also work. Its like tomato vs tomato 
pronunciation. The point is clear in the description so i don't think it 
matters.

> --
> Nicolas George
> 
> ___
> 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] avfilter: add (a)separate filters

[ffmpegandmahanstreamer]

August 1, 2021 1:06 PM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer@e.email (12021-08-01):
> 
>> Seperate is best word
> 
> No, it is not, I have explained why. Chemists separate. Do you have
> arguments?
> 
https://www.merriam-webster.com/dictionary/separateDefinition of separate 
(Entry 1 of 3)
transitive verb

1a: to set or keep apart : DISCONNECT, SEVER

d: to disperse in space or time : SCATTER

> --
> Nicolas George
> 
> ___
> 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] avfilter: add (a)separate filters

[ffmpegandmahanstreamer]

August 1, 2021 1:11 PM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer@e.email (12021-08-01):
> 
>> https://www.merriam-webster.com/dictionary/separateDefinition of separate 
>> (Entry 1 of 3)
>> transitive verb
>> 
>> 1a: to set or keep apart : DISCONNECT, SEVER
>> 
>> d: to disperse in space or time : SCATTER
> 
> It is not a matter of definition, it is a matter of connotations. You do
> not find those in a dictionary.
> 
> You are even less a native speaker than me, are you not?
> 
> Let us have the opinion from a native speaker.
> 
English is my first language.
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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] Mailing List Delay

[ffmpegandmahanstreamer]

Have you checked the mailing list archives? Maybe its slow to get to others but 
fast to get on the ML.

Regardless, maybe its just a gmail problem. The multiple (non Gmail) providers 
ive been using/have used all work even faster than gmail. I think Nicolas Lynne 
and Niedermayer along with Kieran and Radsl and Peter Ross all have their own 
mail server. So its definitely problem with gmail i think. 

You could use the other mail providers in the meantime i guess?
August 2, 2021 4:59 PM, "Derek Buitenhuis"  wrote:

> On 7/14/2021 8:05 PM, Nicolas George wrote:
> 
>> Therefore, the information we need now to debug is what the logs of
>> ffbox0-bg.mplayerhq.hu contains immediately after 20 Feb 2021 11:47:04
>> -0800.
>> 
>> If it happens to you again, you can ask for the logs immediately, it will
>> be more likely the admins can find what went wrong.
> 
> It is happening at this very moment as a type this, with a patch:
> 
> From: Derek Buitenhuis 
> To: ffmpeg-devel@ffmpeg.org
> Subject: [PATCH] ffprobe: Rename Audio Service Type 'type' field to 
> 'service_type'
> Date: Mon, 2 Aug 2021 21:55:01 +0100
> 
> Which has not appeared.
> 
> I do not know who has admin access? Michael? The mailing list admin list, 
> access
> list and infra is entirely opaque... which is not amazing for an open source 
> project.
> 
> - Derek
> ___
> 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] Mailing List Delay

[ffmpegandmahanstreamer]

August 2, 2021 5:57 PM, "Derek Buitenhuis"  wrote:

> On 8/2/2021 10:48 PM, ffmpegandmahanstreamer@e.email wrote:
> 
>> Have you checked the mailing list archives? Maybe its slow to get to others 
>> but fast to get on the
>> ML.
> 
> No, it is not. It's the same issue as we looked at above. I suspect Soft Work 
> has
> the correct interpretation of the issue.
> 
>> Regardless, maybe its just a gmail problem. The multiple (non Gmail) 
>> providers ive been using/have
>> used all work even faster than gmail. I think Nicolas Lynne and Niedermayer 
>> along with Kieran and
>> Radsl and Peter Ross all have their own mail server. So its definitely 
>> problem with gmail i think.
> 
> This is incorrect. Specifically Kieran has had delay issues, and also j-b,
> who also does not use GMail.
> 
Kieran's domain (obe.tv) uses G suite so its Google.
j-b would be the intresting one as his mailserver is not google.
Mahol uses Gmail so it would be interesting to see if he is also having some of 
the same issues.
> I believe the problem is likely mplayer.hu, as I alluded to above.
> 
It could be, I think that Google is sending to one of the MX records for 
ffmpeg.org that is slower than the rest, while other mail providers send to a 
faster mx record. So you could be correct, your theory sounds plausible.
>> You could use the other mail providers in the meantime i guess?
> 
> This is not a useful nor reasonable suggestion, nor is it a good UX for
> potential contributors. Also given the above, it's not clear it would
> even fix the issue.
> 
I agree. I think the issue should be fixed, not trying to divert that or 
anything. But it takes 5 seconds to create even a outlook account, which works 
fine for Andreas. It could be merely temporary in the mean time.

Someone with root access (Mahol or Niedermayer) should be able to go in and 
retrieve logs.
> Also, stop top posting.

I only top post when i am not going to dissect response like im doing now. 
Bottomposting without responding to each line(s) is worse than topposting, or 
at least I've heard.

> 
> - Derek
> ___
> 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] Fix for PES packets with too much padding

[ffmpegandmahanstreamer]

August 3, 2021 10:07 AM, "Sergio M. Ammirata, Ph.D."  
wrote:

> PES packet with too much padding trigger unlimited error
> messages "PES packet size mismatch" because the code that
> corrects the length is wrong.
> Here is a sample file: http://99.93.62.129/smpte2038.ts
> PID 300 is the one triggering the errors.
> I am attaching a patch that fixes the problem.
> 
On the if statement right above your change,  are you sure that the condition 
should still be buf_size > pes->total_size? Especially if the old change was 
just buf_size = pes->total_size (so clipping according to condition); and the 
new one is setting it to something different. 

thx for patch.
> ___
> 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] Mailing List Delay

[ffmpegandmahanstreamer]

August 4, 2021 11:17 AM, "Derek Buitenhuis"  wrote:

> On 8/3/2021 11:59 PM, Michael Niedermayer wrote:
> 
>> somehow this reads a bit offensive to me, iam not sure its meant to
> 
> It's not meant as an attack towards you pesonally, but rather to point out
> the absurdity of the situation:
> 
> * There is no public documentation on:
> * Who owns the physical infra.
> * Where it is located or who hosts it.
host.io/ffmpeg.org
https://telepoint.bg/
> * Who has admin access and how to contact them.
> * Any way to audit admin access.
> * Who to contact in case of issues.
listed in maintainers file
> 
> * There is no monitoring of infra at all. Stuff does down for hours and it
> doensn't get fixed until somene figures out who to poke so they can manually
> fix it.
> 
> * There is no auto-restat after crashes.
> 

what's your plan on fixing it? its simple devops anyone can set up. I believe 
you have root access, so come with a plan i guess and submit here?

> * Nobody is forthcoming with logs to help debug the issue, if there even are
> logs, and if we even know who has access. See point one. We are totally 
> reliant
> on what the admin thinks it may be.
> 
I think lynne has root access as well, ask her?

> I find the total opaqueness and 0 auditability or accountability to be rather
> counter to the ideals of an open source project. For all we know, the 
> mysterious
> host is MITMing us, or accessing the machines and doing sketchy things. Do I
> /think/ this is happening? No. But there is literally zero insight available.
> 
The host is not the problem. 
Besides, email is not necessarily supposed to be instant. Read the RFCs i think 
thats what they call them and it will tell you a email doesnt have to be 
instant.

I gave you suggestion to try different provider. Try that maybe? How about you 
see if the problem is you because it works for me instant on the four email 
providers ive been on. And you seem to be only one complaining. Mahol uses 
gmail and i think his emails come in fine. So maybe your email is in spam 
database or something.

> This also makes reliablity issues extra frustrating. It seems very slapdash 
> for
> such a large project, to be honest. I do not mean to invalidate the efforts 
> put
> in here to keep stuff running, etc., but there has got to be a better way. 
> VideoLAN
> does not have any of these problems, for example.
> 
Theres the maintainers file, as Michael mentioned. If its outdated submit patch.

Doesn't videolan use gitlab anyway?


> - Derek
> ___
> 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] Mailing List Delay

[ffmpegandmahanstreamer]

August 6, 2021 7:20 AM, "Michael Niedermayer"  wrote:

> On Wed, Aug 04, 2021 at 11:28:19PM +0100, Derek Buitenhuis wrote:
> 
>> On 8/4/2021 11:03 PM, Michael Niedermayer wrote:
>> 
>> * There is no public documentation on:
>> * Who owns the physical infra.
>> 
>> its all donated one way or another IIRC,
>> I am a bit hesitant to post a names who provide the servers in public
>> for the main server i think its all on the mailing list. Our fate
>> machiene is seperate and provided and payed for by a FFmpeg developer
>> Theres also a server hosting backups, that reminds me that the backups
>> should be tested. That requirres a volunteer probably
>> 
>> I don't think we need to post people's names, but we genrally do
>> keep things open here, so I assumed the intent should be the same.
>> Reimbursements, funds, hardware, etc. are all posted here.
>> 
>> It does seem somewhat suspicious to me that people providing servers
>> to us for free would not want others to know who they are. Maybe I am
>> paranoid...
> 
> We do credit them
> src/template_footer1: Hosting provided by  href="https://telepoint.bg";>telepoint.bg
> 
> also i belive i heared somewhere that they wanted more traffic for some
> peering stuff or something. This is outside my area of knowledge but it
> might shift the cost of providing the server to us.
> 
Sounds about right. Back in my networking days I heard that more traffic means 
that more companies willing to peer with you for free.
>> * Where it is located or who hosts it.
>> 
>> traceroute ffmpeg.org points to telepoint.bg
>> 
>> OK.
>> 
>> I hope the admins have a direct contact there in case of issue.
> 
> I have one contact, i will check and see if we can get some redundant one
> 
>> * Who has admin access and how to contact them.
>> 
>> project server line in MAINTAINERS file, not everyone is active but even 
>> inactive
>> ones can help in an emergency potentially
>> 
>> I more meant: Is that list an exhaustive / complete list of who has
>> access on the servers? If so, apologies. It is not clear to me if it is.
>> Honestly, mostly due to it being unclea who the owners / hosters are and
>> if they have access.
> 
> I checked the list of keys and i believe ubitux, Tim Nicholson and Roberto 
> Togni
> have access too
> Tim IIRC did some work on the mail stuff longer ago but ive not heared from
> him since a long time. ubitux provided a server to us for a while
> There are no other keys on the main host server or main virtual one, i didnt
> check the other virtual machienes
> The hoster would of course have physical access
> 
> That said, if anyone of the people having admin access currently would want
> to help maintain anything like the mail stuff, iam certainly not unhappy about
> that.
> 
>> * Any way to audit admin access.
>> 
>> What do you mean by "audit admin access" ?
>> 
>> A way to know accessed the server and when, should anything bad happen and
>> who has access - that cannot be deleted locally by someone with root. 
>> Especially
>> on the git server.
>> 
>> I may have made a bad assumption here if this is already in place. Apologies 
>> if so.
>> To my knowledge, it isn't, though.
> 
> Iam not aware of something like that being in place.
> but developer git is provided by videolan. We just provide the webpage git
> and mirror the ffmpeg git for public access with matching SSL certificates
> which videolan would not be able to do as they have no SSL certs for 
> ffmpeg.org
> we could also "easily" move the developer git to our server but there was no
> reason to do that and "if it aint broken ..."
> 
> That said, is there something specific you would suggest should be done/put
> in place for "audit admin access" ?

Maybe have a program which tells which users/IP logged in and what they did. A 
log file that tracks which files are being edited and opened, etc.. so if 
something goes wrong it can be traced back.

> [...]
> 
>> All this said, the truth with open source projects probably is as long as
>> it works well enough noone volunteers to help.
>> 
>> This is true. You can consider this me volunteering to help if you need it
>> somewhere.
> 
> ok, this is good to know
> 
> thx

good luck Derek. I know you can do it.
> 
> [...]
> 
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Avoid a single point of failure, be that a person or equipment.
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 10, 2021 10:37 AM, "Soft Works"  wrote:

> Hi,
> 
> A while ago there was a discussion about moving forward and 
> migrating the ffmpeg development process from the mailing list to 
> another platform (like GitLab).
> That discussion had died without further results and an important 
> takeaway for me was that there are just too many that love this way 
> of interaction and operation and would argue till the end of time 
> against such changes. That’s not meant as a kind of criticism, just 
> an assessment. There a those and those people with different 
> preferences and no doubt that others, who are preferring a more 
> modern and integrated approach like GitHub provides, would be as 
> much rejective when told about having to switch to a mailing list 
> based process.

I do think that if it moves it should move to something self hosted. However 
people have strong opinions about code forges (Github sucks because of "x", 
while someone else says gitlab sucks because of "y", and then gitea sucks 
because of "z", and so on)

> 
> But without doubt, a lot more developers could be attracted to 
> participate in ffmpeg development when it would be accessible in a 
> way like many developers are used to work these days. The ffmpeg 
> mirror on GitHub has 354 PR’s (25k stars, 8k forks!) even though 
> that there’s a big and clear warning shown that PRs won’t be 
> accepted this way. I wonder how many PRs might get submitted once we 
> could actually accept PRs from there.
> 
Anyone who wanted to contribute would send a patch t
> My conclusion from the recent discussion was, that the only way to 
> make a change that could find a larger base of agreement would be a 
> solution that doesn’t make a change at all. What I mean by that is: 
> no moving of the repository, no migration to another platform, no 
> replacement of the mailing-list and leaving everything working 
> as-is. Instead, just add something on-top of it that will allow all 
> those “others” to better accommodate with ffmpeg development.
> I had the idea to build some synchronization between Patchwork and 
> GitHub in a way that it would mirror submitted patches as GitHub 
> pull requests, I didn’t have the time to get on it.
> 

> Just recently, I discovered a very interesting project: 
> https://gitgitgadget.github.io
> 
> This is all about the development of Git itself, which is done via 
> mailing list and they had the same problem, namely developers that 
> could never be convinced of using GitHub instead of the mailing 
> list. That’s how GitGitGadget came to life: 
> https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
> 
> Now my suggestion – obviously – is: Adapt the GitGitGadget 
> implementation and employ it for ffmpeg development.

This is a wonderful idea, if it works side in side by the mailing list. I have 
actually been thinking about this at the back of my head.

But FFMpeg, gstreamer, linux kernel, llvm, qemu, wine, etc... all require a 
level of technical skill thats higher than most open source projects (like 
webapps). So if someone can code at that level but cant submit a email patch 
then the patches you would be getting through web will most likely be "minor" 
patches that don't really need anything. Sometimes this isn't true however, for 
example on the page on github there are many patches where theres something non 
trival fixed but they dont have the time to submit patch to mailing list.

However, with this idea, will people still submit more patches? One of the 
benefits about github is that you don't need to create a new account and do all 
that extra stuff. If someone was going to sign up for gitgitgaget already and 
is going the extra mile, they are the same ones most likely to be willing to 
sumbit to the mailing list as well.

Nevertheless, I would be excited to see something like this. Hopefully it 
brings in more patches.
The best approach still in my opinion is what you mentioned earlier: have 
something that integrates directly with Github and Gitlab as those are the two 
largest code forges. 
> 
> Please let me know what you think about it.
> 
> softworkz 
> 
> ___
> 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] Mail quoting (was: 1/2] libavutil/log: Add capability to prefix loglines with current time or current date+time)

[ffmpegandmahanstreamer]

E.email comes with this capability built in.

August 10, 2021 10:02 AM, "Michael Niedermayer"  wrote:

> On Tue, Aug 10, 2021 at 09:47:31AM +, Soft Works wrote:
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Nicolas George
>> Sent: Tuesday, 10 August 2021 11:16
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: [FFmpeg-devel] Mail quoting (was: 1/2] libavutil/log: Add capability
>> to prefix loglines with current time or current date+time)
>> 
>> Soft Works (12021-08-10):
>>> I meant the e-mail body of the previous conversation.
>> 
>> Well, it is my mail, I put what I want in it, and you do what you want with
>> yours.
>> 
>> But ask yourself: which one do you find easier to read: one where you have
>> to scroll half a dozen pages of old mail just to get to the new bits, or one
>> where you have enough quoted context to remember what the discussion is
>> about but not too much?
>> 
>> For me, the answer is the second, and since I prefer this for myself
>> 
>> Totally agree.
>> 
>> I have toe
>> courtesy to do the same for the mails I send, even if it takes a few more
>> keystrokes. A lot of people do not bother,
>> 
>> Yes, that made me wonder whether shortening would be against any rule or
>> guideline.
>> 
>> One of the most annoying things with that mailing-list-style development
>> is the requirement to scroll through every single message of concern
>> while trying to spot all lines that do not have a '> ' prefix. As some do not
>> even put a blank line before and after a comment, you cannot rely on that,
>> meaning that you have to look very carefully while scrolling.
> 
> if your MUA doesnt color the text to make it easy,
> maybe you should consider a different MUA
> for example mutt can color code text based on how many ">" are there at the 
> begin
> in fact mutt lets you write your own rules for how to color the mails
> I would assume any half decent MUA should be able to do something similar
> 
> Thanks
> 
> [...]
> 
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 11, 2021 9:44 AM, "Soft Works"  wrote:

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> ffmpegandmahanstreamer@e.email
>> Sent: Wednesday, 11 August 2021 15:01
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
>> with GitHub
>> 
>> August 10, 2021 10:37 AM, "Soft Works"  wrote:
> 
> [..]
> 
>> Just recently, I discovered a very interesting project:
>> https://gitgitgadget.github.io
>> 
>> This is all about the development of Git itself, which is done via
>> mailing list and they had the same problem, namely developers that
>> could never be convinced of using GitHub instead of the mailing
>> list. That’s how GitGitGadget came to life:
>> https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
>> 
>> Now my suggestion – obviously – is: Adapt the GitGitGadget
>> implementation and employ it for ffmpeg development.
>> 
>> This is a wonderful idea, if it works side in side by the mailing
>> list. I have actually been thinking about this at the back of my
>> head.
> 
> [..]
> 
>> However, with this idea, will people still submit more patches? One
>> of the benefits about github is that you don't need to create a new
>> account and do all that extra stuff.
> 
> On GitHub you _do_ need to create an account to submit pull requests
> (which are like patchsets and can contain multiple commits/patches).
But the changes of someone having a github account is higher than gitea, so to 
speak.
> 
>> If someone was going to sign up
>> for gitgitgaget already and is going the extra mile, they are the
>> same ones most likely to be willing to sumbit to the mailing list as
>> well.
> 
> It doesn't work like that. In fact giggitgadget just works in the
> background invisibly. The procedure is:
> 
> - [optional] a GitHub user might need to get accredited to be
> allowed to submit PRs(to reduce unnecessary noise)
> In case of GIT, it is sufficient when a new developer gets
> approved by any other already participating developer
> 
> - A developer submits a PR at github.com/ffmpeg/ffmpeg
> 
> - The automation performs some automatic validation checks whether
> the submission is acceptable
> 
> - The developer adds a comment containing "/submit"
> 
> - The ggg automation automatically sends the PR as patchset
> to the mailing list
> 
> - Comments in the mailing list are mapped back to the GitHub PR
> 
> - When a developer make changes to PR and "/submit"s again,
> a vN patchset is sent to the mailing list
> 
> What also works is the other direction: patchsets that are submitted
> to the mailing list are automatically mirrored as PR in the
> GitHub repo.
> 
Oh, ok i understand now.
This is a genius idea. I think it's a gamechanger. Thanks for bringing it to 
our attention.

> As said, the really good thing is: nobody would need to change
> the way he is working.
> 
> softworkz
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 12, 2021 8:39 AM, "Kieran Kunhya"  wrote:

> On Thu, 12 Aug 2021, 13:35 Nicolas George,  wrote:
> 
>> Kieran Kunhya (12021-08-12):
>> And how do the 1.5 billion Gmail users use SMTP without disabling
>> security
>> features?
>> 
>> Do I need to do tech support for Google too?
>> 
>> https://support.google.com/mail/answer/7126229?hl=en
>> https://support.google.com/accounts/answer/185833?hl=en
> 
> Thank you for confirming security features must be disabled. As you know
> email is quite important for societal records such as vaccination
> certificates and so I (and many others) will not be disabling security on
> my email account.
> 
> And I won't make another one nor setup a mail server in order to comply
> with your ideal world.
> 

To resonate with Nicolas, the "enable access for less secure apps" is just a 
Google euphemism. IMAP and gitsend email are really not less secure but Google 
just makes them seem that way in their wording because they want you to use the 
gmail web app instead of custom clients. You're not really disabling security 
when you tick off that box. 

> Kieran
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 12, 2021 5:11 AM, "Soft Works"  wrote:

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Nicolas George
>> Sent: Thursday, 12 August 2021 10:51
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
>> with GitHub
>> 
>> TL;DR: Do not make posting patches on the mailing-list easier, make a
>> two-tiered system where beginners learn to make high-quality patches
>> before submitting them for review to the experienced developers.
>> 
>> You all seem to assume that attracting more developers is always a
>> good
>> thing.
>> 
>> It is if it attracts promising developers, i.e. if it widens the
>> horizon.
>> But more developers is not a good thing if it is done by lowering the
>> bar, because the more developers will be mediocre and as such a drain
>> on
>> the time of core developers.
> 
> Assuming that developers who submit patches via GitHub would be less
> skilled than those who work with a mailing list is arrogant and
> far away from reality.
> 
> I have my opinion about mailing-list development in the year 2021
> and I could express that in a strong way and with a similar kind
> of arrogance.
> 
> But it makes much more sense to accept that there are some who
> prefer to view patches in e-mail clients with hundreds of plus/minus
> lines and others that prefer to view diffs in context and with
> a decent graphical representation.
> That has nothing to do with skills. It's just a preference.
> Right now, you are excluding all those that do not like to
> work "your way".
> 

I agree with softworkz here. There are skilled programmers who like mailing 
lists, and ones that don't. Same goes with unskilled prorammers as well. The 
times are changing and the project needs to be ready for that. Not everyone 
even likes mailing lists in the first place, so why not accomodate both? 

These days kids are rasied up with github and web interfaces instead of mailing 
lists. Its like forcing people to use a slide rule when they were never taught 
to use them because of calculators. 
> IMO there's one thing you really do not need to be concerned
> about: getting rid of unskilled developers.
> You all need to just continue like usual and this will happen
> all the way without effort and without needing a rejection
> form. :-)
> 
> Lastly - what I'm suggesting appears to work for GIT development.
> Why shouldn't it work for ffmpeg then?
> 
Exactly.
> softworkz
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 12, 2021 4:51 AM, "Nicolas George"  wrote:

> Paul Buxton (12021-08-12):
> 
>> From the point of view of someone who is currently developing a filter for
>> ffmpeg and will be submitting a patch to the list for the first time, I
>> think this is a great idea.Whilst following simple instructions to prepare
>> and submit a patch should't be outside the ability of anyone who is capable
>> of contributing. Using something like github allows a more automated
>> workflow that can make the process smoother and even make lives easier for
>> the maintainers as it is possible for the automations to catch issues
>> before they get sent on to you.
> 
> Have you wondered why these periodical threads "we/you should make
> FFmpeg more attractive" usually end up a discussion between disgruntled
> newbies congratulating each other for their great ideas, with only the
> occasional bored experienced developer stepping in?
> 
You have no idea their experience level, or any possible past/present/future 
contributions to the project.
Judge the ideas, not the person.
> TL;DR: Do not make posting patches on the mailing-list easier, make a
> two-tiered system where beginners learn to make high-quality patches
> before submitting them for review to the experienced developers.
> 
> You all seem to assume that attracting more developers is always a good
> thing.
> 
> It is if it attracts promising developers, i.e. if it widens the
> horizon.
> 
> That requires probably making sure the project is seen as alive and
> progressing, with governance and direction, withe people capable of
> making decisions on the direction of the progress, to accept or clearly
> reject original ideas coming from nobodies. Right now, the project is
> adrift, changes are being "accepted" more based on who happens to have
> commit rights and neglects to seek approval from peers.
> 
you have a point here. But nothing to do with what softworkz is sugessting.
> But more developers is not a good thing if it is done by lowering the
> bar, because the more developers will be mediocre and as such a drain on
> the time of core developers.
> 
I don't think you should generalize an entire group of developers because they 
like something you don't.

> Patches from newbies will require review. The more clueless the newbies,
> the more time required turn the patch into something acceptable. And of
> course, patches will be discusses by core developers on the mailing
> list, so people who do not bother to optimize their mails for reading
> (see https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283402.html )
> are especially obnoxious.
> 
Everyone starts as "newbies". Even you started off as one. Imagine if Bellard 
or Michael had this attitude in the beginning of ffmpeg.

> I will gladly concede that the entry bar of subscribing to a
> mailing-list is hardly adequate to achieve the objective of winnowing
> mediocre candidates. But if your proposal is to just discard the bar,
> you are entirely missing the point.
> 
> I wonder if a scheme where clueless developers are rejected in a polite
> but concise and semi-final standardized way:
> 
> # Thanks for your proposal. Your input will not be considered because it
> # contains obvious and easily avoided flaws:
> # [x] not following mailing-list rules;
> # [x] not following coding style conventions;
> # [ ] mangled or misformatted patch;
> # [ ] problems of code hygiene;
> # [x] bad commit message.
> # For details, see . If you can fix
> # these flaws by yourself, you may become a valued contributor to this
> # project. If you cannot, then please go grok some PHP or something.
> 
Could be useful.
> Then feel free to set-up a Discourse or Discord or whatever kids use
> these days to help each other pass the bar. As long as what we get on
> the mailing-list are patches that are already in good shape for review,
> it is all good.
> 
So you agree with softworkz?
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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] Consulting request video pre-processing for media project involving machine learning

[ffmpegandmahanstreamer]

August 13, 2021 11:10 AM, "Mario Winkler"  wrote:

> Dear Developers
> 
> I direct a media project involving a huge variety of online available videos. 
> We will analyse these
> videos with available and state of the art machine learning tools, but need 
> to pre-process the
> videos and bring them to a certain standard.
> 
More detail needed, whats end goal?
> We are looking for somebody to consult to automated pre-process the videos.
> 
> The videos we have collected by now:
> 3 videos downloaded from different sources (YouTube, IG, Tiktok) and with 
> a huge variety in
> quality, length, size, bitrate and format. 300GB total size.
> 
Are they of a specific type or 3 completely different videos?
> Goal of the preprocessing (TBD):
> - remove black bars
Black vertical or horizontal bars? Need more info. Should be a filter that can 
handle this already though.

> - remove items added to the video by 3rd parties (like ’this is my YouTube 
> channel’ before the
> actual video starts) etc.
Delogo filter might help you here.

But if its determining like the sponsorship things and the intros thats way way 
out of scope of ffmpeg. 

> - similar framerate
> - similar codec
> - similar bitrate
> 
If this is for what I think its for, none of this stuff will help you. All 
codecs are "different" but ffmpeg can help you determine which codec a video 
is, along with framerate and bitrate.

> I just learned from your software, but feel like you might be the right fit 
> to help us with this.
> If you are interested, please contact me and I will setup a call.
> 
It certainly is intresting, please let me know where the project goes. Most of 
the stuff may be filter related, but for the most part it looks like its out of 
scope. Good luck.

> Best,
> Mario
> ___
> Mario Winkler Company LLC is specialised for Project Management of 
> International Contemporary Art
> Projects. We are closing the gaps and and sometimes buffer to make any artist 
> visions reality. 
> 
> Mario Winkler Company GmbH
> Bernerstrasse Nord 180 CH-8064 Zürich
> office +41 55 552 03 00 / m...@mariowinkler.ch
> direct +41 76 566 36 27 / ma...@mariowinkler.ch
> Instagram 
> 

> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient of this email, you must neither
> take any action based upon its contents, nor copy or show it to anyone.
> Please contact the sender if you have received this email in error

Put these things off when posting on public mailing list. Sometimes Nicolas 
does have a point with his ramblings.
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 13, 2021 9:30 PM, "Soft Works"  wrote:

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of Lynne
>> Sent: Saturday, 14 August 2021 03:08
>> To: FFmpeg development discussions and patches 
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with
>> GitHub
>> 
>> The situation is far from perfect. In my opinion, mirroring will just
>> result in such an incredible amount of noise on the ML, the ML
>> will turn useless anyway, and due to needing to maintain both,
>> one will fall out of favour with developers and will break, while
>> limiting the integration for the other.
> 
> I'm don't think it would create much noise, please see my reply to
> Michael from 1.5h ago.
> 
> There's no need to maintain both, because what happens on GitHub is
> automated and the ML remains the core instrument.
> 
> Should it turn out over time that activity would converge away
> from the ML, then this would be a natural and democratic evolvement.
> Then, it would be time to reconsider the organization, obviously.
> 
>> I'd rather move to either a self-hosted Gitea or Gogs instance,
>> or failing that, Github. IMO Gitea is pretty good and fast. As bad
>> as that could be, it'll be better than what we have now or could have
>> with Gitlab.
> 
> These kinds of proposals have been talked down too often, that's
> why I'm suggesting something with a more realistic chance for acceptance
> and that won't hurt or affect anybody in his work if he doesn't want.
> 
> Also, the stakes are much lower than with a full migration.
> If it wouldn't work out well, it can be abandoned easily, while a
> migration is usually a way of no return.

Agreed. I mean if anything goes wrong, we just switch it off. There's nothing 
wrong with trying new things. Trying new things is how ffmpeg, nihav, and all 
great new software comes into existence. People need to be able to challenge 
things when they don't make sense in order to be competitive.

By the people against softworkz appeal's logic they should never submit a patch 
to ffmpeg that includes something new or improved, since then there is a very 
small chance the commit isn't good and has to be reverted.
> 
> softworkz
> 
> ___
> 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] Fwd: Re: Subject: [PATCH] Cleanup code in truemotion1 decoder

[ffmpegandmahanstreamer]

Mike, i was told you can push this?

August 11, 2021 9:04 AM, ffmpegandmahanstreamer@e.email wrote:

> ping
> 
> August 1, 2021 12:22 PM, ffmpegandmahanstreamer@e.email wrote:
> 
>> Per Andreas Rheinhardt request i'm splitting the working patches in two.
>> ---
>> This cleans up the code in the decode24bit and decode16bit functions by 
>> putting it in way that
>> expresses the true intent while making it easier to read.
>> libavcodec/truemotion1.c | 36 
>> 1 file changed, 12 insertions(+), 24 deletions(-)
>> 
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..50c90e732d 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -655,25 +655,19 @@ static void 
>> truemotion1_decode_16bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>> 
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
>> case 0:
>> /* if macroblock width is 2, apply C-Y-C-Y; else
>> * apply C-Y-Y */
>> + APPLY_C_PREDICTOR();
>> + APPLY_Y_PREDICTOR();
>> + OUTPUT_PIXEL_PAIR();
>> if (s->block_width == 2) {
>> APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - } else {
>> - APPLY_C_PREDICTOR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_Y_PREDICTOR();
>> - OUTPUT_PIXEL_PAIR();
>> }
>> + APPLY_Y_PREDICTOR();
>> + OUTPUT_PIXEL_PAIR();
>> break;
>> 
>> case 1:
>> @@ -781,25 +775,19 @@ static void 
>> truemotion1_decode_24bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>> 
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
>> case 0:
>> /* if macroblock width is 2, apply C-Y-C-Y; else
>> * apply C-Y-Y */
>> + APPLY_C_PREDICTOR_24();
>> + APPLY_Y_PREDICTOR_24();
>> + OUTPUT_PIXEL_PAIR();
>> if (s->block_width == 2) {
>> APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - } else {
>> - APPLY_C_PREDICTOR_24();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> - APPLY_Y_PREDICTOR_24();
>> - OUTPUT_PIXEL_PAIR();
>> }
>> + APPLY_Y_PREDICTOR_24();
>> + OUTPUT_PIXEL_PAIR();
>> break;
>> 
>> case 1:
>> --
>> 2.24.3
___
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/libaomenc: use ctx->usage to get default cfg

[ffmpegandmahanstreamer]

August 13, 2021 10:11 PM, "James Zern"  wrote:

> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
> 
> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [libaom-av1 @ ...] Additional information: g_lag_in_frames out of
> range [..0]
> ---
> libavcodec/libaomenc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9c0317f3b2..800fda0591 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
> av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
> 
> - if ((res = aom_codec_enc_config_default(iface, &enccfg, 0)) != 
> AOM_CODEC_OK) {
> + if ((res = aom_codec_enc_config_default(iface, &enccfg, ctx->usage)) != 
> AOM_CODEC_OK) {
> av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
> aom_codec_err_to_string(res));
> return AVERROR(EINVAL);
> @@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
> enccfg.g_threads =
> FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 64);
> 
> - enccfg.g_usage = ctx->usage;
> -
> if (ctx->lag_in_frames >= 0)
> enccfg.g_lag_in_frames = ctx->lag_in_frames;
> 
LGTM, first email appears not to have sent.
> -- 
> 2.33.0.rc1.237.g0d66db33f3-goog
> 
> ___
> 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] avcodec/libaomenc: use ctx->usage to get default cfg

[ffmpegandmahanstreamer]

August 13, 2021 10:11 PM, "James Zern"  wrote:

> this prevents some mismatches in config values for realtime and all
> intra modes, avoiding failures like:
> 
> [libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
> [libaom-av1 @ ...] Additional information: g_lag_in_frames out of
> range [..0]
> ---
> libavcodec/libaomenc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9c0317f3b2..800fda0591 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -599,7 +599,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_INFO, "%s\n", aom_codec_version_str());
> av_log(avctx, AV_LOG_VERBOSE, "%s\n", aom_codec_build_config());
> 
> - if ((res = aom_codec_enc_config_default(iface, &enccfg, 0)) != 
> AOM_CODEC_OK) {
> + if ((res = aom_codec_enc_config_default(iface, &enccfg, ctx->usage)) != 
> AOM_CODEC_OK) {
> av_log(avctx, AV_LOG_ERROR, "Failed to get config: %s\n",
> aom_codec_err_to_string(res));
> return AVERROR(EINVAL);
> @@ -623,8 +623,6 @@ static av_cold int aom_init(AVCodecContext *avctx,
> enccfg.g_threads =
> FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 64);
> 
> - enccfg.g_usage = ctx->usage;
> -
> if (ctx->lag_in_frames >= 0)
> enccfg.g_lag_in_frames = ctx->lag_in_frames;
> 

LGTM

> -- 
> 2.33.0.rc1.237.g0d66db33f3-goog
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 13, 2021 8:42 PM, "Ronald S. Bultje"  wrote:

> Hi,
> 
> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:
> 
>> Paul Buxton (12021-08-12):
>> From the point of view of someone who is currently developing a filter
>> for
>> ffmpeg and will be submitting a patch to the list for the first time, I
>> think this is a great idea.Whilst following simple instructions to
>> prepare
>> and submit a patch should't be outside the ability of anyone who is
>> capable
>> of contributing. Using something like github allows a more automated
>> workflow that can make the process smoother and even make lives easier
>> for
>> the maintainers as it is possible for the automations to catch issues
>> before they get sent on to you.
>> 
>> Have you wondered why these periodical threads "we/you should make
>> FFmpeg more attractive" usually end up a discussion between disgruntled
>> newbies congratulating each other for their great ideas, with only the
>> occasional bored experienced developer stepping in?
> 
> Experienced dev speaking here: I absolutely 100% disagree with this
> statement. I would be much happier to actively contribute to FFmpeg if it
> used gitlab/hub. I find this mailinglist environment beyond horrendous. I
> can't understand why anyone would be OK with our current approach. I only
> grudgingly use it when I need to because I'm assuming I'm the minority and
> I'm willing to accept the majority consensus, but not because I support it
> or think it's a good idea.

This reminds me: dav1d, gstreamer, nihav, VLC, x265, rav1e, svt-vp9, etc. and 
other major
multimedia projects are now all on Github/Gitlab/some graphical platform. Its' 
ffmpeg that's mostly
stuck in the past. Everyone's moving on. To be fair, all the projects (except 
gstreamer and vlc)
started off that way, but it shows where the general trend it still.

Its not just multimedia, major projects from all over the OSS sphere are moving 
to these graphical
platforms. Even webkit and clang, some of the largest codebases.

If people loved mailing lists all those projects would start off with those and 
still use them.

Again, why use a slide rule when there are calculators?

Again, there are many platforms that are not full blown github/gitlab like 
gitea, codeberg, gogs,
gitbucket etc. that are very nice.

To be honest, i do think the mailing list should be eventually phased out. And 
i think it will be,
as fresh blood comes in from younger kids who have been using the graphical 
platforms for their
entire programming career. It may happen next month, it may happen in one year, 
it may happen in 5
years. But it will happen.

> Ronald
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 14, 2021 12:34 AM, "zhilizhao(赵志立)"  wrote:

>> On Aug 14, 2021, at 11:27 AM, ffmpegandmahanstreamer@e.email wrote:
>> 
>> August 13, 2021 8:42 PM, "Ronald S. Bultje"  wrote:
>> 
>>> Hi,
>>> 
>>> On Thu, Aug 12, 2021 at 4:51 AM Nicolas George  wrote:
>> 
>> Paul Buxton (12021-08-12):
>> From the point of view of someone who is currently developing a filter
>> for
>> ffmpeg and will be submitting a patch to the list for the first time, I
>> think this is a great idea.Whilst following simple instructions to
>> prepare
>> and submit a patch should't be outside the ability of anyone who is
>> capable
>> of contributing. Using something like github allows a more automated
>> workflow that can make the process smoother and even make lives easier
>> for
>> the maintainers as it is possible for the automations to catch issues
>> before they get sent on to you.
>> 
>> Have you wondered why these periodical threads "we/you should make
>> FFmpeg more attractive" usually end up a discussion between disgruntled
>> newbies congratulating each other for their great ideas, with only the
>> occasional bored experienced developer stepping in?
>>> Experienced dev speaking here: I absolutely 100% disagree with this
>>> statement. I would be much happier to actively contribute to FFmpeg if it
>>> used gitlab/hub. I find this mailinglist environment beyond horrendous. I
>>> can't understand why anyone would be OK with our current approach. I only
>>> grudgingly use it when I need to because I'm assuming I'm the minority and
>>> I'm willing to accept the majority consensus, but not because I support it
>>> or think it's a good idea.
>> 
>> This reminds me: dav1d, gstreamer, nihav, VLC, x265, rav1e, svt-vp9, etc. 
>> and other major
>> multimedia projects are now all on Github/Gitlab/some graphical platform. 
>> Its' ffmpeg that's mostly
>> stuck in the past. Everyone's moving on. To be fair, all the projects 
>> (except gstreamer and vlc)
>> started off that way, but it shows where the general trend it still.
> 
I even forgot to add mpv and OBS to that list. 
> I’m glad VLC development has transfer from mailing list to self hosted 
> Gitlab, although it’s not
> perfect, e.g., gitlab is slow for large patch set.
> 
> I have spent a lot of time on finding a email service provider for mailing 
> list based development:
You can try the two mail providers i've been/or have used. They all work great. 
But i assume yours is also good, i'll have to try it.


> 
> - All patches are treated as spam by 163.com, I can't sent a single email 
> (well, patch doesn’t look
> like normal conversation…)
> - Email backend developer or client developer don’t know about the use case 
> of mailing list, they
> don’t understand my bug report, or don’t care.
> - gmail is blocked by GFW, that’s another story…
> 
> I’ve helped my friends to setup email for sending patch. It’s like DIY shoes 
> before jogging. DIY is
> interesting, but definitely time consuming. Coding is a necessary skill for 
> contributing, debugging
> is a necessary skill for contributing, but vim is not, no matter how I like 
> it.
> 
Exactly. Different times, different people.
> Maybe there are some details which are overlooked on the GitGitGadget 
> solution, but “easy to
> contributing and more contributor will lower the patch quality” is not a good 
> reason to reject the
> solution.
> 
>> Its not just multimedia, major projects from all over the OSS sphere are 
>> moving to these graphical
>> platforms. Even webkit and clang, some of the largest codebases.
>> 
>> If people loved mailing lists all those projects would start off with those 
>> and still use them.
>> 
>> Again, why use a slide rule when there are calculators?
>> 
>> Again, there are many platforms that are not full blown github/gitlab like 
>> gitea, codeberg, gogs,
>> gitbucket etc. that are very nice.
>> 
>> To be honest, i do think the mailing list should be eventually phased out. 
>> And i think it will be,
>> as fresh blood comes in from younger kids who have been using the graphical 
>> platforms for their
>> entire programming career. It may happen next month, it may happen in one 
>> year, it may happen in 5
>> years. But it will happen.
>> 
>>> Ronald
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mai

[FFmpeg-devel] [PATCH] Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit of truemotion1 decoder

[ffmpegandmahanstreamer]

This cleans up the code in the decode24bit and decode16bit functions by putting 
it in way that expresses the true intent while making it easier to read.
---
 libavcodec/truemotion1.c | 35 ---
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..3f13de0ff8 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context 
*s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
+   APPLY_C_PREDICTOR();
 }
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 break;
 
 case 1:
@@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context 
*s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 break;
 
+
 case 1:
 case 3:
 /* always apply 2 Y predictors on these iterations */
-- 
2.24.3
___
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] Subject: [PATCH] Cleanup code in truemotion1 decoder

[ffmpegandmahanstreamer]

Sent new patch.
Once again this proves the superioity of the graphical stuff. The whole host of 
issues in the first set of this email would have been avoided, and i wouldnt 
have to create the patch all over again to fix something.

August 14, 2021 4:23 AM, "Michael Niedermayer"  wrote:

> On Sun, Aug 01, 2021 at 04:22:28PM +, ffmpegandmahanstreamer@e.email 
> wrote:
> 
>> Per Andreas Rheinhardt request i'm splitting the working patches in two.
> 
> And this results in a commit message like this:
> Author: ffmpegandmahanstreamer@e.email 
> Date: Sun Aug 1 16:22:28 2021 +
> 
> Subject: [PATCH] Cleanup code in truemotion1 decoder
> 
> Per Andreas Rheinhardt request i'm splitting the working patches in two.
> 
> Thats not good
> "Subject: [PATCH]" doesnt belong in it
> "Cleanup code in truemotion1 decoder" is too terse, what is cleaned upo why 
> and how
> 
> Your Author name is also missing, is that intended ?
> 
>> ---
>> This cleans up the code in the decode24bit and decode16bit functions by 
>> putting it in way that
>> expresses the true intent while making it easier to read.
>> libavcodec/truemotion1.c | 36 
>> 1 file changed, 12 insertions(+), 24 deletions(-)
>> 
>> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
>> index 32d8fb4005..50c90e732d 100644
>> --- a/libavcodec/truemotion1.c
>> +++ b/libavcodec/truemotion1.c
>> @@ -655,25 +655,19 @@ static void 
>> truemotion1_decode_16bit(TrueMotion1Context *s)
>> while (pixels_left > 0) {
>> 
>> if (keyframe || ((mb_change_byte & mb_change_byte_mask) == 0)) {
>> -
>> +
>> switch (y & 3) {
> 
> unrelated
> trailing whitespace
> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Nations do behave wisely once they have exhausted all other alternatives.
> -- Abba Eban
> 
> ___
> 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] avcodec/truemotion1: Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit

[ffmpegandmahanstreamer]

This cleans up the code in the decode24bit and decode16bit functions by putting 
it in way that expresses the true intent while making it easier to read.
---
 libavcodec/truemotion1.c | 35 ---
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 32d8fb4005..3f13de0ff8 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context 
*s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR();
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR();
-OUTPUT_PIXEL_PAIR();
+   APPLY_C_PREDICTOR();
 }
+APPLY_Y_PREDICTOR();
+OUTPUT_PIXEL_PAIR();
 break;
 
 case 1:
@@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context 
*s)
 case 0:
 /* if macroblock width is 2, apply C-Y-C-Y; else
  * apply C-Y-Y */
+APPLY_C_PREDICTOR_24();
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 if (s->block_width == 2) {
 APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-} else {
-APPLY_C_PREDICTOR_24();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
-APPLY_Y_PREDICTOR_24();
-OUTPUT_PIXEL_PAIR();
 }
+APPLY_Y_PREDICTOR_24();
+OUTPUT_PIXEL_PAIR();
 break;
 
+
 case 1:
 case 3:
 /* always apply 2 Y predictors on these iterations */
-- 
2.24.3
___
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] Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit of truemotion1 decoder

[ffmpegandmahanstreamer]

The other patch has more subject line aligned to other devs, go to that one 
instead.

August 14, 2021 7:24 AM, "ffmpegandmahanstreamer" 
 wrote:

> This cleans up the code in the decode24bit and decode16bit functions by 
> putting it in way that
> expresses the true intent while making it easier to read.
> ---
> libavcodec/truemotion1.c | 35 ---
> 1 file changed, 12 insertions(+), 23 deletions(-)
> 
> diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
> index 32d8fb4005..3f13de0ff8 100644
> --- a/libavcodec/truemotion1.c
> +++ b/libavcodec/truemotion1.c
> @@ -660,20 +660,14 @@ static void truemotion1_decode_16bit(TrueMotion1Context 
> *s)
> case 0:
> /* if macroblock width is 2, apply C-Y-C-Y; else
> * apply C-Y-Y */
> + APPLY_C_PREDICTOR();
> + APPLY_Y_PREDICTOR();
> + OUTPUT_PIXEL_PAIR();
> if (s->block_width == 2) {
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - } else {
> - APPLY_C_PREDICTOR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_Y_PREDICTOR();
> - OUTPUT_PIXEL_PAIR();
> + APPLY_C_PREDICTOR();
> }
> + APPLY_Y_PREDICTOR();
> + OUTPUT_PIXEL_PAIR();
> break;
> 
> case 1:
> @@ -786,22 +780,17 @@ static void truemotion1_decode_24bit(TrueMotion1Context 
> *s)
> case 0:
> /* if macroblock width is 2, apply C-Y-C-Y; else
> * apply C-Y-Y */
> + APPLY_C_PREDICTOR_24();
> + APPLY_Y_PREDICTOR_24();
> + OUTPUT_PIXEL_PAIR();
> if (s->block_width == 2) {
> APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - } else {
> - APPLY_C_PREDICTOR_24();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> - APPLY_Y_PREDICTOR_24();
> - OUTPUT_PIXEL_PAIR();
> }
> + APPLY_Y_PREDICTOR_24();
> + OUTPUT_PIXEL_PAIR();
> break;
> 
> +
> case 1:
> case 3:
> /* always apply 2 Y predictors on these iterations */
> -- 
> 2.24.3
> ___
> 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] Subject: [PATCH] Cleanup code in truemotion1 decoder

[ffmpegandmahanstreamer]

August 14, 2021 7:43 AM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer (12021-08-14):
> 
>> Once again this proves the superioity of the graphical stuff.
> 
> Start with not top-posting and we may take your opinion on the
> superiority of stuff seriously.
I top post only when i want to reply to the message as a whole.
Here, im bottom posting because im responding to your specific part.
Bottom (literally, like way bottom) posting is worse than top posting, because 
then you need to scroll all the way down.
Hence why top-posting was invented
> 
> --
> Nicolas George
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 14, 2021 12:40 PM, "Jean-Baptiste Kempf"  wrote:

> On Sat, 14 Aug 2021, at 03:13, Soft Works wrote:
> 
>> The continuing attempt to declare developers who are favoring modern
>> workflows and tooling as newbies and unexperienced is a really disgusting
>> rhetoric.
> 
> I agree.
> 
> Very complex projects, more complex than FFmpeg are on GitHub and Gitlab and 
> survive very well.
> It is a question of preference, absolutely not of skillz nor seniority.

Exactly. Like i said, game engines and web browsers (most complex projects out 
there in my opinion) are all hosted on these platforms and are doing well.

> 
> For your data point, dav1d is developed without mailing list, and has managed 
> to ship a ton of code
> in 2years. VLC moved from mailing lists (used for 20 years) to Gitlab and 
> it’s mostly doing fine.
> 

I mentioned dav1d as one example of  multimedia software using gitlab and doing 
well
> All options are fine, but are unrelated to skills.
> 

That's what everyone here has been trying to say.
> --
> Jean-Baptiste Kempf - President
> +33 672 704 734
> ___
> 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] Subject: [PATCH] Cleanup code in truemotion1 decoder

[ffmpegandmahanstreamer]

August 14, 2021 7:56 AM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer (12021-08-14):
> 
>> I top post only when i want to reply to the message as a whole.
> 
> The rules of the list are clear: DO NOT TOP-POST
The rules of the list also say you should be mean to others.
> 
>> Bottom (literally, like way bottom) posting is worse than top posting, 
>> because then you need to
>> scroll all the way down.
> 
> Then be extra-respectful of your peers and trim your quote, just like I
> did.
> 
Why does it matter to you so much anyway?
I don't really care about it, if the rules say dont top post, i wont, but again 
if i do it once in a while it doesnt make big difference.

>> Hence why top-posting was invented
> 
> Top-posting was not invented, it originally was just laziness and
> ignorance by people discovering e-mail without being taught.
> 
Not true. 
> --
> Nicolas George
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 14, 2021 12:47 PM, "Nicolas George"  wrote:

> Jean-Baptiste Kempf (12021-08-14):
> 
>> The continuing attempt to declare developers who are favoring modern
>> workflows and tooling as newbies and unexperienced is a really disgusting
>> rhetoric.
>> I agree.
> 
> Good thing it is not what I wrote, then. I am a little disappointed that
> you would make a judgement like that without reading carefully and
> realizing that Soft Works has turned my position on its head.

The real person winning here is Soft Works. He must be laughing right now.
> 
> My statement is: newbies ⇒ like newfangled tools.
> 
> My statement never was: like newfangled tools ⇒ newbies.
> 
Ah, your math degree coming into work here - "if and only if" ;) 
Dont make broad generalizations however.
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 14, 2021 12:53 PM, "Nicolas George"  wrote:

> Diederick C. Niehorster (12021-08-14):
> 
>> Is there a mechanism to trigger such a vote? I hope the core developers
>> have one soon so the project can get moving on this.
> 
> There is a mechanism. But as I explained there:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283705.html
> 
> for this kind of question a simple one person = one vote system would be
> a grave mistake. This kind of decision has to be taken by weighing
> opinions by how much developers are impacted.
> 
Careful there. Don't you remember anything about the libav split?
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

[ffmpegandmahanstreamer]

August 14, 2021 1:01 PM, "Nicolas George"  wrote:

> ffmpegandmahanstreamer (12021-08-14):
> 
>> The real person winning here is Soft Works. He must be laughing right now.
>> 
>> Ah, your math degree coming into work here - "if and only if" ;)
>> Dont make broad generalizations however.
>> 
>> Careful there. Don't you remember anything about the libav split?
> 
> Do you have a point, or are you just trying to make the discussion more
> unpleasant than it already is?
> 
I've made my point. The people have spoken. Some multiple times.
The point is you are the only one against the change, the consensus all seems 
to be in favor of Soft's proposal.
And instead of trying to attack his approach on the method, you attack the 
people behind it (calling them newbies and
unexperienced).

We need to focus our efforts on development. Bug fixes, new codecs, etc... are 
what is truly important. While we're arguing, Gstreamer is developing. So lets 
stop with the arguments and get back to what we know to do best: make one of 
the best multimedia frameworks in the world. If we can bring new people in by 
adding this, thats great.  It will only help FFMpeg in the long term. People 
that find the ML culture hard just won't contribute to ffmpeg, they'll 
contribute to something else like dav1d or vlc or even mpv which are similar 
overlaps with ffmpeg and are all on gitlab/hub/graphical platforms. 
> --
> Nicolas George
> 
> ___
> 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] [WIP] Event loop

[ffmpegandmahanstreamer]

August 17, 2021 3:58 AM, "Nicolas George"  wrote:

> Xiang Xiao (12021-08-17):
> 
>> Nicolas, do you have any more progress? I am very interested in your
>> proposal and want to test your change in our special device.
> 
> Sorry. I have been focusing on other projects while looking for a good
> way to avoid dynamic allocations in the thread-aware scheduler.
> 
> Since I could not find one, I will try to start again on this soon.
> 
> Do you have an opinion on the low-level single-thread API?

Not him, obvisouly, but i think the API idea is great
> 
> Can you share some details about the needs your special device? I would
> consider them when writing the API.
> 
> Regards,
> 
> --
> Nicolas George
> 
> ___
> 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 3/3] lavfi/formats: document the negotiation process

[ffmpegandmahanstreamer]

lgtm

August 19, 2021 11:30 AM, "Nicolas George"  wrote:

> Signed-off-by: Nicolas George 
> ---
> libavfilter/formats.h | 85 +++
> 1 file changed, 85 insertions(+)
> 
> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
> index d94977a3aa..7c8258ed08 100644
> --- a/libavfilter/formats.h
> +++ b/libavfilter/formats.h
> @@ -321,6 +321,91 @@ typedef struct AVFilterFormatMerger {
> int (*can_merge)(const void *a, const void *b);
> } AVFilterFormatsMerger;
> 
> +/**
> + * Callbacks and properties to describe the steps of a format negotiation.
> + *
> + * The steps are:
> + *
> + * 1. query_formats(): call the callbacks on all filter to set lists of
> + * supported formats.
> + * When links on a filter must eventually have the same
> + * format, the lists of supported formats are the same
> + * object in memory.
> + * See:
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#12
> + *
> + *
> + * 2. query_formats(): merge lists of supported formats or insert automatic
> + * conversion filters.
> + * Compute the intersection of the lists of supported
> + * formats on the ends of links. If it succeeds, replace
> + * both objects with the intersection everywhere they
> + * are referenced.
> + * If the intersection is empty, insert an automatic
> + * conversion filter.
> + * If several formats are negotiated at once (format,
> + * rate, layout), only merge if all three can be, since
> + * the conversion filter can convert all three at once.
> + * This process goes on as long as progress is made.
> + * See:
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#14
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#29
> + *
> + * 3. reduce_formats(): try to reduce format conversion within filters.
> + * For each link where there is only one supported
> + * formats on output, for each output of the connected
> + * filter, if the media type is the same and said
> + * format is supported, keep only this one.
> + * This process goes on as long as progress is made.
> + * Rationale: conversion filters will set a large list
> + * of supported formats on outputs but users will
> + * expect the output to be as close as possible as the
> + * input (examples: scale without changing the pixel
> + * format, resample without changint the layout).
> + * FIXME: this can probably be done by merging the
> + * input and output lists instead of re-implementing
> + * the logic.
> + *
> + * 4. swap_sample_fmts():
> + * swap_samplerates():
> + * swap_channel_layouts(): For each filter with an input with only one
> + * supported format, when outputs have several
> + * supported formats, put the best one with
> + * reference to the input at the beginning of the
> + * list, to prepare it for being picked up by
> + * pick_formats().
> + * The best format is the one that is most
> + * similar to the input while not losing too much
> + * information.
> + * This process need to run only once.
> + * FIXME: reduce_formats() operates on all inputs
> + * with a single format, swap_*() operates on the
> + * first one only: check if the difference makes
> + * sense.
> + * TODO: the swapping done for one filter can
> + * override the swapping done for another filter
> + * connected to the same list of formats, maybe
> + * it would be better to compute a total score
> + * for all connected filters and use the score to
> + * pick the format instead of just swapping.
> + * TODO: make the similarity logic available as
> + * public functions in libavutil.
> + *
> + * 5. pick_formats(): Choose one format from the lists of supported formats,
> + * use it for the link and reduce the list to a single
> + * element to force other filters connected to the same
> + * list to use it.
> + * First process all links where there is a single format
> + * and the output links of all filters with an input,
> + * trying to preserve similarity between input and
> + * outputs.
> + * Repeat as long as process is made.
> + * Then do a final run for the remaining filters.
> + * FIXME: the similarity logic (the ref argument to
> + * pick_format()) added in FFmpeg duplicates and
> + * overrides the swapping logic added in libav. Better
> + * merge them into a score system.
> + */
> typedef struct AVFilterNegotiation {
> unsigned nb_mergers;
> const AVFilterFormatsMerger *mergers;
> -- 
> 2.32.0
> 
> ___
> 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] lavfi/formats: document the negotiation process.

[ffmpegandmahanstreamer]

August 19, 2021 10:53 AM, "Nicolas George"  wrote:

> Signed-off-by: Nicolas George 
> ---
> libavfilter/formats.h | 85 +++
> 1 file changed, 85 insertions(+)
> 
> diff --git a/libavfilter/formats.h b/libavfilter/formats.h
> index ed513c265a..b3e780a41d 100644
> --- a/libavfilter/formats.h
> +++ b/libavfilter/formats.h
> @@ -75,6 +75,91 @@ typedef struct AVFilterFormatMerger {
> int (*can_merge)(const void *a, const void *b);
> } AVFilterFormatsMerger;
> 
> +/**
> + * Callbacks and properties to describe the steps of a format negotiation.
> + *
> + * The steps are:
> + *
> + * 1. query_formats(): call the callbacks on all filter to set lists of
> + * supported formats.
> + * When links on a filter must eventually have the same
> + * format, the lists of supported formats are the same
> + * object in memory.
> + * See:
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#12
> + *
> + *
> + * 2. query_formats(): merge lists of supported formats or insert automatic
> + * conversion filters.
> + * Compute the intersection of the lists of supported
> + * formats on the ends of links. If it succeeds, replace
> + * both objects with the intersection everywhere they
> + * are referenced.
> + * If the intersection is empty, insert an automatic
> + * conversion filter.
> + * If several formats are negotiated at once (format,
> + * rate, layout), only merge if all three can be, since
> + * the conversion filter can convert all three at once.
> + * This process goes on as long as progress is made.
> + * See:
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#14
> + * 
> http://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#29
> + *
> + * 3. reduce_formats(): try to reduce format conversion within filters.
> + * For each link where there is only one supported
> + * formats on output, for each output of the connected
> + * filter, if the media type is the same and said
> + * format is supported, keep only this one.
> + * This process goes on as long as progress is made.
> + * Rationale: conversion filters will set a large list
> + * of supported formats on outputs but users will
> + * expect the output to be as close as possible as the
> + * input (examples: scale without changing the pixel
> + * format, resample without changint the layout).
> + * FIXME: this can probably be done by merging the
> + * input and output lists instead of re-implementing
> + * the logic.
> + *
> + * 4. swap_sample_fmts():
> + * swap_samplerates():
> + * swap_channel_layouts(): For each filter with an input with only one
> + * supported format, when outputs have several
> + * supported formats, put the best one with
> + * reference to the input at the beginning of the
> + * list, to prepare it for being picked up by
> + * pick_formats().
> + * The best format is the one that is most
> + * similar to the input while not losing too much
> + * information.
> + * This process need to run only once.
> + * FIXME: reduce_formats() operates on all inputs
> + * with a single format, swap_*() operates on the
> + * first one only: check if the difference makes
> + * sense.
> + * TODO: the swapping done for one filter can
> + * override the swapping done for another filter
> + * connected to the same list of formats, maybe
> + * it would be better to compute a total score
> + * for all connected filters and use the score to
> + * pick the format instead of just swapping.
> + * TODO: make the similarity logic available as
> + * public functions in libavutil.
> + *
> + * 5. pick_formats(): Choose one format from the lists of supported formats,
> + * use it for the link and reduce the list to a single
> + * element to force other filters connected to the same
> + * list to use it.
> + * First process all links where there is a single format
> + * and the output links of all filters with an input,
> + * trying to preserve similarity between input and
> + * outputs.
> + * Repeat as long as process is made.
> + * Then do a final run for the remaining filters.
> + * FIXME: the similarity logic (the ref argument to
> + * pick_format()) added in FFmpeg duplicates and
> + * overrides the swapping logic added in libav. Better
> + * merge them into a score system.
> + */
> typedef struct AVFilterNegotiation {
> unsigned nb;
> const AVFilterFormatsMerger *mergers;
> -- 
> 2.32.0
> 
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2] doc/general_contents: Fix dead links

[ffmpegandmahanstreamer]

August 24, 2021 9:49 AM, "Mapul Bhola"  wrote:

> The x265 configuration and installation guide has moved to Bitbucket so the 
> updated link reflects
> that one.
> 
> As the openCV site currently only has docs for opencv3 and the filter in 
> libavfilter is an opencv2
> an alternative link is provided.
> ---
> doc/filters.texi | 2 +-
> doc/general_contents.texi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index eaf23e3736..4db7e4f25b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -15484,7 +15484,7 @@ values are assumed.
> 
> Refer to the official libopencv documentation for more precise
> information:
> -@url{http://docs.opencv.org/master/modules/imgproc/doc/filtering.html}
> +@url{http://www.opencv.org.cn/opencvdoc/2.3.2/html/modules/imgproc/doc/filtering.html}
> 
> Several libopencv filters are supported; see the following subsections.
> 
> diff --git a/doc/general_contents.texi b/doc/general_contents.texi
> index 354899ad17..ca39a9d718 100644
> --- a/doc/general_contents.texi
> +++ b/doc/general_contents.texi
> @@ -304,7 +304,7 @@ details), you must upgrade FFmpeg's license to GPL in 
> order to use it.
> 
> FFmpeg can make use of the x265 library for HEVC encoding.
> 
> -Go to @url{http://x265.org/developers.html} and follow the instructions
> +Go to 
> @url{https://bitbucket.org/multicoreware/x265_git/src/master/build/README.txt}
>  and follow
> the instructions
> for installing the library. Then pass @code{--enable-libx265} to configure
> to enable it.
> 
> -- 
> 2.24.3

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

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