Michael Niedermayer (12021-07-20):
> hmm, i guess in this case as it required root mailing root at ffmpeg
> directly would work
I will keep it mind.
> fixed
Thanks.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@f
in FFmpeg as bitstream filters: porting or
re-implementing (check the license!) jpegtran's code would be an useful
task.
Unfortunately, I know nothing about JPEG, so I cannot easily help /
mentor. I am just suggesting.
Regards,
--
Nicolas George
signature.asc
Description: PGP sign
Signed-off-by: Nicolas George
---
libavutil/internal.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavutil/internal.h b/libavutil/internal.h
index a33e8700c3..2011813932 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -103,6 +103,11 @@
#define FF_PTR_ADD(ptr
It makes the code clearer and will allow adding new stages
of negotiation easier.
Signed-off-by: Nicolas George
---
libavfilter/avfiltergraph.c | 96 +-
libavfilter/formats.c | 114
libavfilter/formats.h | 41
Signed-off-by: Nicolas George
---
libavfilter/avfiltergraph.c | 45 ++---
libavfilter/formats.c | 4
libavfilter/formats.h | 2 ++
3 files changed, 18 insertions(+), 33 deletions(-)
Obviously to be applied on top of the last two patches.
The
cat->cur_idx + i], which is now used twice, and re-affect pts
in the line before rather than inlining the computation.
> }
> if (!cat->nb_in_active) {
> ret = flush_segment(ctx);
--
Nicolas George
signature.asc
Descriptio
->time_base,
ctx->outputs[i]->time_base);
pts += cat->delta_ts;
would be much nicer.
> }
> if (!cat->nb_in_active) {
> ret = flush_segment(ctx);
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
on states:
* The string buffer grows as necessary and is always 0-terminated.
And I checked: there is no obvious bug in the avio_read_to_bprint() code
path, it ends with av_bprint_grow() adding the final 0.
Regards,
--
Nicolas George
signature.asc
Description: PGP
lavf/hls: treat fs: the same way as file:.
[PATCH 08/10] lavf/avio: use fs: by default instead of file:.
[PATCH 09/10] lavf/file: handle standard file:// URLs.
[PATCH 10/10] doc: document fs: and file: changes.
Regards,
--
Nicolas George
___
ffmpeg-
Signed-off-by: Nicolas George
---
libavutil/internal.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavutil/internal.h b/libavutil/internal.h
index a33e8700c3..ba221438ed 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -291,4 +291,38
Signed-off-by: Nicolas George
---
libavutil/opt.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 41284d4ecd..c7844d6241 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -167,16 +167,6 @@ static int write_number
Signed-off-by: Nicolas George
---
libavformat/file.c | 47 -
libavformat/protocols.c | 1 +
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/libavformat/file.c b/libavformat/file.c
index 8303436be0..2fb93c23fd 100644
--- a/libavformat
Signed-off-by: Nicolas George
---
libavformat/concat.c | 2 +-
libavformat/subfile.c | 2 +-
libavformat/teeproto.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index aec1f52d8e..66ee792b20 100644
--- a/libavformat/concat.c
Signed-off-by: Nicolas George
---
libavformat/avio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 4846bbd8c6..13bba52e73 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -217,7 +217,9 @@ int ffurl_connect
Signed-off-by: Nicolas George
---
fftools/ffmpeg_opt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 1b43bab9fc..23b4e981c7 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1004,7 +1004,9 @@ static void
Signed-off-by: Nicolas George
---
libavformat/hls.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3c1b80f60c..e1928b6db3 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -646,7 +646,7 @@ static int open_url
Signed-off-by: Nicolas George
---
libavformat/avio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 13bba52e73..ebfecac893 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -260,7 +260,7 @@ static const struct
Signed-off-by: Nicolas George
---
libavformat/file.c | 54 +-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/libavformat/file.c b/libavformat/file.c
index 2fb93c23fd..82d9e7bab4 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
Signed-off-by: Nicolas George
---
doc/protocols.texi | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 726e5f1c44..d341d93914 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
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".
x->outputs[i], status, eof_pts);
> }
> if (!cat->nb_in_active) {
> ret = flush_segment(ctx);
LGTM.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-de
That would require including avstring.h from internal.h. I do not think
these simple functions are worth it.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
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".
the question of relative resolution comes to mind, there is some code
> in libavformat/url.c which also handles file path specially, that should
> also be updated, right?
Good catch. I added this patch in the series. It passes FATE.
I will re-send the full series after giving more time fo
Nicolas George (12021-07-24):
> Signed-off-by: Nicolas George
> ---
> libavutil/internal.h | 5 +
> 1 file changed, 5 insertions(+)
Will push soon unless somebody wants to comment.
Regards,
--
Nicolas George
signature.asc
Description: P
Nicolas George (12021-07-24):
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfiltergraph.c | 45 ++---
> libavfilter/formats.c | 4
> libavfilter/formats.h | 2 ++
> 3 files changed, 18 insertions(+), 33 deletions(-)
&g
It only makes sense as the default value,
but it is not the default since 689211d5727231c3fe92762d224dbadebdbf4e30.
Signed-off-by: Nicolas George
---
doc/demuxers.texi | 9 +++--
libavformat/concatdec.c | 6 ++
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/doc
Signed-off-by: Nicolas George
---
doc/demuxers.texi | 4
libavformat/concatdec.c | 37 -
2 files changed, 40 insertions(+), 1 deletion(-)
I intend to refactor the parser some time later.
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index
Signed-off-by: Nicolas George
---
tools/dvd2concat | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/dvd2concat b/tools/dvd2concat
index 8effee86b9..0280838a6b 100755
--- a/tools/dvd2concat
+++ b/tools/dvd2concat
@@ -37,7 +37,8 @@ normally contains a directory named B
subfile,,start,X,end,Y,,: is ugly and will be gone.
Signed-off-by: Nicolas George
---
tools/dvd2concat | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/dvd2concat b/tools/dvd2concat
index 0280838a6b..ef04a87d05 100755
--- a/tools/dvd2concat
+++ b/tools/dvd2concat
It was only still supported for subfile and only used by dvd2concat.
Signed-off-by: Nicolas George
---
libavformat/avio.c| 34 +-
libavformat/dashdec.c | 2 +-
libavformat/hls.c | 2 +-
3 files changed, 3 insertions(+), 35 deletions(-)
diff --git a
Gyan Doshi (12021-07-28):
>
>
> On 2021-07-28 17:45, Nicolas George wrote:
> > It was only still supported for subfile and only used by dvd2concat.
>
> Examples at http://www.ffmpeg.org/ffmpeg-protocols.html#subfile should be
> updated.
Good catch, thanks.
Locally com
ng.h.
I can add a comment, no problem. Good idea.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
tenating subfiles is useful?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
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,
--
Linjie Fu (12021-08-01):
> From: Linjie Fu
>
> Currently the default swscale flags for simple filter graph is bicubic,
> however for complex filter graph it uses bilinear as decleared in scale
> filter.
Why does ffmpeg set a default different from swscale?
Regards,
--
710f55e490d0c3cf7348b3ca91c8c0fe4274be2.
"The default is left at bicubic until someone has compared the scalers
properly speed and quality wise."
But eight years later nobody did.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpegandmahanstreamer@e.email (12021-08-01):
> LGTM, as always.
Who are you? What qualifications do you have to review patches?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
be timesplit. Or segment.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel
ffmpegandmahanstreamer@e.email (12021-08-01):
> Seperate is best word
No, it is not, I have explained why. Chemists separate. Do you have
arguments?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffm
f 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.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_
(0)"
And if you make that change, you will get a warning about a semicolon
after a braced block.
I suggest to change the definition to
#define emms_c() do { } while (0)
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
__
Paul B Mahol (2018-12-17):
> Yes, it is poc - patch of crap.
Please refrain from using that language.
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mail
ful answer. Human interactions would work much
better that way. Please give it a try.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listi
Paul B Mahol (2018-12-20):
> It is an obvious attack.
It was a technical comment wrapped in very polite and welcoming
language. Maybe it was an obvious mistake (but if it is obvious, I
cannot see it), but it certainly was not an attack.
Regards,
--
Nicolas George
signature.asc
Descript
opinion in favor of it either; it is useful in principle, but I do not
know if it is worth the extra maintenance for a use case like this
project. I will leave the judgement to others.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_
Paul B Mahol (2018-12-21):
> I will ignore your comments as there is misunderstanding from your side.
Unacceptable. If somebody has misunderstood something you wrote, then
you need to explain better.
--
Nicolas George
signature.asc
Description: Digital signat
annel_layout,
> +enum AVChannel channel);
> +
> +/**
> + * Find out what channels from a given set are present in a channel layout,
> + * without regard for their positions.
> + *
> + * @param channel_layout input channel layout
> + * @param mask a combination of AV_CH_* representing a set of channels
> + * @return a bitfield representing all the channels from mask that are
> present
> + * in channel_layout
> + */
> +uint64_t av_channel_layout_subset(const AVChannelLayout *channel_layout,
> + uint64_t mask);
> +
> +/**
> + * Check whether a channel layout is valid, i.e. can possibly describe audio
> + * data.
> + *
> + * @param channel_layout input channel layout
> + * @return 1 if channel_layout is valid, 0 otherwise.
> + */
> +int av_channel_layout_check(const AVChannelLayout *channel_layout);
> +
> +/**
> + * Check whether two channel layouts are semantically the same, i.e. the same
> + * channels are present on the same positions in both.
> + *
> + * If one of the channel layouts is AV_CHANNEL_ORDER_UNSPEC, while the other
> is
> + * not, they are considered to be unequal. If both are
> AV_CHANNEL_ORDER_UNSPEC,
> + * they are considered equal iff the channel counts are the same in both.
> + *
> + * @param chl input channel layout
> + * @param chl1 input channel layout
> + * @return 0 if chl and chl1 are equal, 1 if they are not equal. A negative
> + * AVERROR code if one or both are invalid.
> + */
> +int av_channel_layout_compare(const AVChannelLayout *chl, const
> AVChannelLayout *chl1);
> +
> /**
> * @}
> * @}
No more remarks for the first round of review.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
tive endeavour governed by consensus. This patch cannot go in
until consensus is reached, and consensus cannot be reached unless you
take reviews into account.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel
hile juggling with the indentation
commit can be annoying, you can wait until the patch is in its final
form to even bother about the re-indent. You can flag the places where
it is needed with /* TODO reindent */ if you find it useful.
Regards,
--
Nicolas George
___
AGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_AUDIO_PARAM |
> AV_OPT_FLAG_FILTERING_PARAM
> static const AVOption options[] = {
> { "limit", "sleep time limit", OFFSET(limit), AV_OPT_TYPE_DURATION, {
> .i64 = 200 }, 0, INT64_MAX, FLAGS },
> +{ "speed", "speed factor", OFFSET(speed), AV_OPT_TYPE_DOUBLE, { .dbl =
> 1.0 }, DBL_MIN, DBL_MAX, FLAGS },
> { NULL }
> };
>
LGTM apart from these nitpicks.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> +s->uglarmweightsum[plane] =
> +(double*)av_malloc((logo_w - 2) * (logo_h - 2) *
> sizeof(double));
> +
> +if (!s->uglarmweightsum[plane]) {
> +return AVERROR(ENOMEM);
> +}
Same as above, of
Marton Balint (2018-12-23):
> Signed-off-by: Marton Balint
> ---
> libavformat/concatdec.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Looks good to me, thanks.
Regards,
--
Nicolas George
signature.asc
Description: P
I can do so. Who decides whether the hunks stays or goes? I'm
> indecisive.
I think since you made the effort of implementing this, you get to
decide that kind of fine details. The preference I have expressed is
very minor, both solutions are ok with me.
Regards,
--
Nicolas Geor
he /2.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Paul B Mahol (2018-12-30):
> On 12/26/18, Nicolas George wrote:
> >> + * The input string can be represented by:
> >> + * - the formal channel layout name (returned by
> >> av_channel_layout_describe())
> >> + * - single or multiple channel names (retur
Paul B Mahol (2018-12-30):
> >> > av_get_channel_layout() used to use '+' instead of '|', and I think it
> >> > is better. For once, '+' is not a special character for shells.
> >>
> >> Can not work if user wants to define custom channel layout from
> >> already available channels.
> >
> > Please e
what is being done.
And if + is not possible, | is still a bad choice. Use a character that
is not special for standard shells, I am sure we can find some; maybe /.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Paul B Mahol (2018-12-30):
> Please no, | is used in bunch of scripts.
What scripts? How can they use an API that is still in early discussion?
Also, discussing this is moot until you rephrase the documentation.
--
Nicolas George
signature.asc
Description: PGP signat
wn time like that as well as the time of everybody
else.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
xample: that shows that | cannot be used in
channel layout descriptions, since aformat splits on |. You have to use
another character, there is no choice about it.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel m
Paul B Mahol (2018-12-30):
> I will use +.
That was my suggestion in the beginning, so I am obviously for. But what
happened to your reasons for rejecting it?
(Once again, too little information in your mail => wasted time for both
of us.)
--
Nicolas George
signature.asc
Descriptio
, 6 insertions(+)
Sorry, it slipped my mind. LGTM, but I do not maintain that file.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
someone who wanted to see the
> patch, because i dont know that ...
Better submit a trivial patch than have a mistake creep in.
We had quite a few patches pushed without review in the last few weeks
that caused Coverity regressions. Maybe let us take that as lessons.
Regards,
--
e more like this
> is not checked by mistake.
This is the usual way this project does things: free everything
unconditionally. The rationale is that it is less likely to lead to
leaks in case of code change.
> Hope that the code is correct like this?
>
> s->uglarmtable[plane] =
>
not lost.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Nicolas George (2019-01-02):
> Uwe Freese (2019-01-01):
> > > This can be optimized, and since it is the inner loop of the filter, I
> > > think it is worth it. You can declare a pointer that will stay the same
> > > for the whole y loop:
> > >
> > >
e that without freeing, and even without providing an API to
free it. Including internal components.
This is not a leak, it is short-sightedness by leak detectors.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
constants.
There are a few cases
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
n that case, the only correct type is the same as AVFrame.width and
AVFrame.height.
> Use an AVRational with a denum set to the max quantizer
Can you explain "set to the max quantizer"? For decoders it makes sense,
but what should the encoders do? Return EINVAL? Scale
to be either. There is no point in being able to express ROI coordinates
in the quadrillion when the size of the frame is bounded by much less.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg
ddresses
another concern I have: this feature conflicts with the (net yet
implemented) option of keeping the files open, as a LRU-style
optimization for when much seeking is expected.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
ave default value) in an
encoder-agnostic way.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Rostislav Pehlivanov (12019-01-04):
> Hence an AVRational is appropriate as you can have fractions between 0 and
> 1, the encoder can adjust it and it'll be agnostic.
Yes, AVRational is fine. Producing warnings for an unexpected
denominator would be a bad idea.
Regards,
--
Nic
at important, and anyway it would require changing other
parts of the code, since they already use ints.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
r me, the definite argument is: All the rest of the code uses int for
frame size and coordinate, so new code should use int too unless there
is a very good and specific reason.
Note that while we disagree on the reasons, I think we agree on the
conclusion, which is what matter.
Regards,
--
erent resolution limits on 32
and 64 bits systems, as long as the data fits in memory.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
*/
> +bp = strchr(p, '#');
> +if (bp)
> +*bp = '\0';
> ls = strchr(p, '/');
> ls2 = strchr(p, '?');
> if (!ls)
This invalid: p points either to url, which is const, or to NULL.
Also, I do not think the fix its
on in the first place, was it not?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Liu Steven (12019-01-10):
> Ok, I get that mean, let me think how to fix that.
Do you know why the fragment was there in the first place and what its
role was?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-de
Paul B Mahol (12019-01-11):
> No, pay me first.
That actually explains a lot of things...
But I wonder: were you not payed by somebody for this unfinished
demuxer?
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-de
r,
amount, identity of the recipient(s).
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos (12019-01-11):
> I believe amount is never published (so far at least afair).
I think it should. I wonder what other people think.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing l
iew comments, etc. A mandatory disclosure would make
these bad behaviours obvious.
I will produce a patch on the developer policy to start a real
discussion.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing l
aybe you have thicker skin.
> I suspect the replies will not reflect what you think they will, but
> if it is the only way... so be it.
That is possible. Let us see.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg
: Nicolas George
---
doc/developer.texi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index 5c342c9106..1d77250083 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -420,6 +420,13 @@ your name after it.
If at some point you no
;witch hunt", I only advocate for transparency and honesty.
Are you against transparency and honesty?
On the other hand, I have observed in the past patches that were of poor
quality and suspected they were the result of sponsorships. I would like
to know. Would you not?
Regards,
n pushed, and some committers have explicitly stated they would
bypass technical objections to their patches. And now it appears that
was the result of sponsorships...
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel ma
lly important for
people who have commit rights, but it would be unjust to apply to only
us.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
t and under what terms are they willing to submit a patch.
Thanks, I had not thought of that. I added this in the commit message:
* This information is sometimes necessary to determine exactly who
owns the copyright for the new code.
Regards,
--
Nicolas George
e commit message, almost none of them were
addressed and the dissenting arguments were feeble at best.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ng it in.
Then I will ask you, and everybody who objects, this:
How do you propose to address the conflict of interest of a sponsored
contributor pushing a patch without review?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
f
> times.
And who will do the challenging, since we already do not have enough
time to review the patches in the first place?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-dev
Derek Buitenhuis (12019-01-13):
> This is a policy change, not a techncal change.
Policy changes need to be motivated too.
Any unmotivated objection can be interpreted as "I push bad code for a
quick buck and do not intend to stop", do you not think?
Regards,
--
N
that the reason is rather bad.
Therefore, I ask reasons: if you do not want to disclose your
sponsorships, please explain why?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel
this attachment is only the result of propaganda and detrimental to
yourself.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
with, and then it can be discussed.
Re-read the rationale in the proposed patch: copyright is only one of
them.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Derek Buitenhuis (12019-01-13):
> On 13/01/2019 14:52, Nicolas George wrote:
> > Therefore, I ask reasons: if you do not want to disclose your
> > sponsorships, please explain why?
>
> https://en.wikipedia.org/wiki/Nothing_to_hide_argument
Exactly: the "nothing
w, then I would support you totally, and possibly drop this
proposal. Is it?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ibly ignore the
comments, (4) as a result from that rudeness receive even less reviews,
and (5) all this seems to be motivated by sponsorship, can you tell what
course of action you propose?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
surprised to see technical types ignoring sociological
evidence, but it is saddening.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
1101 - 1200 of 5137 matches
Mail list logo
