Re: [FFmpeg-devel] [PATCH 3/8] libavformat/flacdec: Export samples md5 as metadata

[Tomas Härdin]

tor 2025-02-06 klockan 16:07 +0100 skrev Michael Niedermayer:
> Hi Tomas
> 
> On Wed, Feb 05, 2025 at 03:20:09PM +0100, Tomas Härdin wrote:
> > 
> 
> >  libavformat/flacdec.c |    6 ++
> >  tests/ref/fate/cover-art-aiff-id3v2-remux |    5 +++--
> >  tests/ref/fate/cover-art-flac-remux   |    1 +
> >  tests/ref/fate/id3v2-utf16-bom    |    5 +++--
> >  4 files changed, 13 insertions(+), 4 deletions(-)
> > 685b0c4be452dc7138f993a3cbeb85320a045545  0003-libavformat-flacdec-
> > Export-samples-md5-as-metadata.patch
> > From e1c4dfa4cc7a574f6fac76c11591547d3cd90ad2 Mon Sep 17 00:00:00
> > 2001
> > From: Mattias Wadman 
> > Date: Mon, 11 Oct 2021 15:38:13 +0200
> > Subject: [PATCH 3/8] libavformat/flacdec: Export samples md5 as
> > metadata
> > 
> > Will be used by mal to compare metadat md5 with decoded samples
> > md5.
> > 
> > Part of fixing https://jira.spotify.net/browse/GOL-681
> > ---
> >  libavformat/flacdec.c | 6 ++
> >  tests/ref/fate/cover-art-aiff-id3v2-remux | 5 +++--
> >  tests/ref/fate/cover-art-flac-remux   | 1 +
> >  tests/ref/fate/id3v2-utf16-bom    | 5 +++--
> >  4 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> > index 3c317acaee..9f65c25864 100644
> > --- a/libavformat/flacdec.c
> > +++ b/libavformat/flacdec.c
> > @@ -33,6 +33,7 @@
> >  #include "replaygain.h"
> >  
> >  #define SEEKPOINT_SIZE 18
> > +#define MD5_BYTE_SIZE 16
> >  
> >  typedef struct FLACDecContext {
> >  FFRawDemuxerContext rawctx;
> > @@ -109,6 +110,7 @@ static int flac_read_header(AVFormatContext *s)
> >  if (metadata_type == FLAC_METADATA_TYPE_STREAMINFO) {
> >  uint32_t samplerate;
> >  uint64_t samples;
> > +    char md5hex[MD5_BYTE_SIZE*2+1]; // hex representation
> > plus null terminator
> >  
> >  /* STREAMINFO can only occur once */
> >  if (found_streaminfo) {
> > @@ -133,6 +135,10 @@ static int flac_read_header(AVFormatContext
> > *s)
> >  if (samples > 0)
> >  st->duration = samples;
> >  }
> > +
> > +    ff_data_to_hex(md5hex, st->codecpar->extradata+18,
> > MD5_BYTE_SIZE, 1 /* lowercase */);
> > +    md5hex[sizeof(md5hex)-1] = '\0';
> > +    av_dict_set(&s->metadata, "samples_md5", md5hex, 0);
> 
> I think "samples_md5" should be documented, so that other decoders
> can use
> the same
> i also see a verify_md5() in hevc
> and crc seems frequently used in decoders

Documented where? doc/metadata.texi doesn't seem like the place for it.
doc/demuxers.texi maybe?

/Tomas
___
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] GSoC 2025 SDR Cleanup

[Vittorio Giovara]

On Wed, Feb 12, 2025 at 2:21 AM Michael Niedermayer 
wrote:

> Hi all
>
> Ive added SDR to our GSoC 2025 page as there was just a single project
> on that page and the page needs to be more complete yesterday
>
> If people are against this say this NOW do not wait until we have accepted
> a student and then start some drama
> It can be removed now easily but not once someone is working on it
>
> What is this project about ?
> It is about YOU, the community, you disliked how libavradio is interfaced.
> It bascially was just a demuxer/input device
>
> So this Project is about someone within GSoC re structuring libavradio
> and interfacing with a demuxer/input device as was previously suggested.
>
> Please clearly list all requirements you have for this to get into git
> master
>
> thx


Thanks for making a separate thread for this proposal, although I would
have expected the idea to be discussed before putting it on the wiki.
This idea for me is a no.
Best Regards
-- 
Vittorio
___
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 8/8] Make mime-type award a bonus probe score

[Tomas Härdin]

tor 2025-02-06 klockan 15:58 +0100 skrev Michael Niedermayer:
> Hi Tomas
> 
> On Wed, Feb 05, 2025 at 03:24:24PM +0100, Tomas Härdin wrote:
> > Seems reasonable to me and passes FATE
> > 
> > /Tomas
> 
> >  avformat.h   |    2 +-
> >  format.c |    8 
> >  libopenmpt.c |    2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 01f04f79202640330d6be91b0215f92f14d1845a  0008-Make-mime-type-
> > award-a-bonus-probe-score.patch
> > From ecc3459990f2871fd907f96fe66362b8fea41bd8 Mon Sep 17 00:00:00
> > 2001
> > From: =?UTF-8?q?Peter=20Zeb=C3=BChr?= 
> > Date: Tue, 21 Nov 2023 14:16:49 +0100
> > Subject: [PATCH 8/8] Make mime-type award a bonus probe score
> > 
> > This changes the default behaviour of ffmpeg where content-type
> > headers
> > on an input gives an absolut probe score (of 75) to instead give a
> > bonus
> > score (of 30). This gives the probe a better chance to arrive at
> > the
> > correct format by (hopefully) giving a large enough bonus to push
> > edge
> > cases in the right direction (MPEG-PS vs MP3, I am looking at you)
> > while
> > also not adversly punishing clearer cases (raw ADTS marked as
> > "audio/mpeg" for example).
> > 
> > This patch was regression tested against 20 million recent podcast
> > submissions (after content-type propagation was added to
> > original-storage), and 50k Juno vodcasts submissions (dito). No
> > adverse
> > effects observed (but the bonus may still need tweaking if other
> > edge
> > cases are detected in production).
> > ---
> >  libavformat/avformat.h   | 2 +-
> >  libavformat/format.c | 8 
> >  libavformat/libopenmpt.c | 2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> what is the score ?
> a higher score means more likely but how much more ?
> maybe we should come up with a more formal definition
> like that score is the number of bits of entropy that where checked
> or
> something like that.
> in such a framework, adding 30 for a mime type match would probably
> make sense
> 
> without such a framework, adding 30 to a abstract score is hard to
> review
> beyond that, i dont see anything breaking from this but then i
> dont think we have real tests for mime types

We don't really have tests for the probe scores at all, which is a
problem. Perhaps if we collected some tricky samples we could construct
a test that demands a certain ordering of probe scores for them? For
now scores are tested indirectly by the fact that most tests rely on
correct probing

Also you can't really "formalize" social relations. The reason why
certain files probe as one thing and not another is down to certain
workflows that demand such behavior, which also entails some workflows
being rejected, or at least requiring explicit -f. 

/Tomas
___
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 6/8] GOL-1361: Remove invalid CTTS sample_offset check

[Tomas Härdin]

ons 2025-02-05 klockan 15:22 +0100 skrev Tomas Härdin:
> I trust that ticket #385 has a FATE test these days

Just tested the file in said ticket and it transcodes fine with this
patch applied.

/Tomas
___
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/8] libavformat/flacdec: Export samples md5 as metadata

[Andreas Rheinhardt]

Tomas Härdin:
> 
> 
> ___
> 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".

This will forward wrong/outdated metadata if only part of a file is
copied. Apart from that, is it really necessary to export the md5 as
metadata given that it is very easily obtainable from the extradata?

- Andreas

___
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] GSoC 2025 SDR Cleanup

[Tomas Härdin]

ons 2025-02-12 klockan 02:21 +0100 skrev Michael Niedermayer:
> Hi all
> 
> Ive added SDR to our GSoC 2025 page as there was just a single
> project
> on that page and the page needs to be more complete yesterday
> 
> If people are against this say this NOW do not wait until we have
> accepted
> a student and then start some drama
> It can be removed now easily but not once someone is working on it
> 
> What is this project about ?
> It is about YOU, the community, you disliked how libavradio is
> interfaced.
> It bascially was just a demuxer/input device
> 
> So this Project is about someone within GSoC re structuring
> libavradio
> and interfacing with a demuxer/input device as was previously
> suggested.
> 
> Please clearly list all requirements you have for this to get into
> git master

This is still vastly out of scope for this project. Not everything has
to be in ffmpeg.

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

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

Re: [FFmpeg-devel] GSoC 2025

[Vittorio Giovara]

On Wed, Feb 12, 2025 at 2:17 AM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> On Wed, 12 Feb 2025, 00:20 Michael Niedermayer, 
> wrote:
>
> > Hi everyone
> >
> > On Wed, Feb 12, 2025 at 06:30:11AM +0800, Steven Liu wrote:
> > > Michael Niedermayer 于2025年1月28日 周二10:21写道：
> > >
> > > > Hi
> > > >
> > > > Everyone interested in mentoring a project in 2025, please add your
> > > > idea(s) to [1].
> > > >
> > > > during February 11 - 26 "Google program administrators review
> > organization
> > > > applications"
> > > > That means that by February 11th the list of ideas must be completed
> > > >
> >
> > > Deadline 11th Feb reminder :)
> >
> > Yeah, i thought the other admins would take care of this like last years
> > Noone said they would ignore the page
> >
> > So this is a bit an "emergency", can people please help bring this
> > in shape ASAP. It already should be
> >
> > Steven, do you have time to help ?
> > If so please add some projects, ask people who mentored previously
> > to add some projects
> >
> > same question for everyone else
> >
> > thx
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Freedom in capitalist society always remains about the same as it was in
> > ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
> >
>
> Sneaking in your pet SDR project is unacceptable.


SDR was not on my 2025 FFmpeg bingo card. Of course I agree with Kieran and
I'm adding this incident to the list of "why people are mean to me".
This is equivalent to adding "Remove postproc" except the work has already
been done, again.
Micheal let me know if you need me to repost the bullet points as it seems
a refresher is in order!
-- 
Vittorio
___
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] swscale/aarch64/rgb2rgb_neon: Implemented {yuyv, uyvy}toyuv{420, 422}

[Martin Storsjö]

On Tue, 11 Feb 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:


---
libswscale/aarch64/rgb2rgb.c  |  16 ++
libswscale/aarch64/rgb2rgb_neon.S | 262 ++
2 files changed, 278 insertions(+)

diff --git a/libswscale/aarch64/rgb2rgb.c b/libswscale/aarch64/rgb2rgb.c
index 7e1dba572d..f474228298 100644
--- a/libswscale/aarch64/rgb2rgb.c
+++ b/libswscale/aarch64/rgb2rgb.c
@@ -67,6 +67,18 @@ void ff_shuffle_bytes_2013_neon(const uint8_t *src, uint8_t 
*dst, int src_size);
void ff_shuffle_bytes_2130_neon(const uint8_t *src, uint8_t *dst, int src_size);
void ff_shuffle_bytes_1203_neon(const uint8_t *src, uint8_t *dst, int src_size);

+void ff_uyvytoyuv422_neon(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+  const uint8_t *src, int width, int height,
+  int lumStride, int chromStride, int srcStride);
+void ff_uyvytoyuv420_neon(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+  const uint8_t *src, int width, int height,
+  int lumStride, int chromStride, int srcStride);
+void ff_yuyvtoyuv420_neon(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+  const uint8_t *src, int width, int height,
+  int lumStride, int chromStride, int srcStride);
+void ff_yuyvtoyuv422_neon(uint8_t *ydst, uint8_t *udst, uint8_t *vdst,
+  const uint8_t *src, int width, int height,
+  int lumStride, int chromStride, int srcStride);
av_cold void rgb2rgb_init_aarch64(void)
{
int cpu_flags = av_get_cpu_flags();
@@ -84,5 +96,9 @@ av_cold void rgb2rgb_init_aarch64(void)
shuffle_bytes_2013 = ff_shuffle_bytes_2013_neon;
shuffle_bytes_2130 = ff_shuffle_bytes_2130_neon;
shuffle_bytes_1203 = ff_shuffle_bytes_1203_neon;
+uyvytoyuv422   = ff_uyvytoyuv422_neon;
+uyvytoyuv420   = ff_uyvytoyuv420_neon;
+yuyvtoyuv422   = ff_yuyvtoyuv422_neon;
+yuyvtoyuv420   = ff_yuyvtoyuv420_neon;
}
}
diff --git a/libswscale/aarch64/rgb2rgb_neon.S 
b/libswscale/aarch64/rgb2rgb_neon.S
index 22ecdf7ac8..9002aa028f 100644
--- a/libswscale/aarch64/rgb2rgb_neon.S
+++ b/libswscale/aarch64/rgb2rgb_neon.S
@@ -427,3 +427,265 @@ neon_shuf 2013
neon_shuf 1203
neon_shuf 2130
neon_shuf 3210
+
+/*
+v0-v7 - two consecutive lines
+x0 - upper Y destination
+x1 - U destination
+x2 - V destination
+x3 - upper src line
+w5 - width/iteration counter - count of line pairs for yuv420, of single lines 
for 422
+x6 - lum padding
+x7 - chrom padding
+x8 - src padding
+w9 - number of bytes remaining in the tail
+x10 - lower Y destination
+w12 - tmp
+x13 - lower src line
+w14 - tmp
+w17 - set to 1 if last line has to be handled separately (odd height)
+*/
+
+// one fast path iteration processes 16 uyvy tuples
+// is_line_tail is set to 1 when final 16 tuples are being processed
+// skip_storing_chroma is set to 1 when final line is processed and the height 
is odd
+.macro fastpath_iteration src_fmt, dst_fmt, is_line_tail, skip_storing_chroma
+ld4 {v0.16b - v3.16b}, [x3], #64
+.if ! \is_line_tail
+subsw14, w14, #32
+.endif
+
+.if ! \skip_storing_chroma
+.if \dst_fmt == yuv420


This doesn't work as you want it to across all supported tools; .if 
conditionals are meant for pure numerical comparisons, and yuv420 isn't a 
numerical constant. In practice it does seem to work with binutils though, 
but not with Clang (or with gas-preprocessor).


You can use .ifc for string comparisons, see 
https://sourceware.org/binutils/docs/as/If.html for more references.


Also see 
https://github.com/mstorsjo/FFmpeg/actions/runs/13282469154/job/37083639139 
for the fallout from trying to build this patch with various tool setups.


Please do consider trying the aarch64 assembly testset from 
https://github.com/mstorsjo/FFmpeg/commits/gha-aarch64 on your commits.


// Martin

___
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/8] libavformat/flacdec: Export samples md5 as metadata

[Andreas Rheinhardt]

Tomas Härdin:
> ons 2025-02-12 klockan 12:14 +0100 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>>
>>>
>>> ___
>>> 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".
>>
>> This will forward wrong/outdated metadata if only part of a file is
>> copied.
> 
> No? lavc/flacenc computes md5 from the actual samples and puts it in
> the extradata. If you mean incomplete file copy (cp) rather then ffmpeg
> -acodec copy then this will output what the user is likely interested
> in: the MD5 of the original data. This allows them to check that the
> file decodes correctly. This also applies to incomplete remuxing, which
> also won't recompute the MD5 as it is, AFAICT. But, this patch concerns
> the demuxer side, not transcoding or remuxing.
> 

I mean e.g. -c copy -t . And even without the -t, this mostly
pointless metadata will be forwarded by default with your patch and may
get embedded into other files (as the aiff FATE reference file changes
show).
And given that the md5 is wrong for an incomplete file, it does not
allow the user to check that the file decodes correctly.

>> Apart from that, is it really necessary to export the md5 as
>> metadata given that it is very easily obtainable from the extradata?
> 
> I'm not sure if our users know that. But yes metadata can be dumped and
> then cut can be used to extract the MD5. But as Michael points out,
> flac isn't the only codec with MD5 hashes.
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] tests/checkasm/sw_rgb: Added {yuyv, uyvy}toyuv{420, 422} test cases

[Martin Storsjö]

On Tue, 11 Feb 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:


Splitting the previous patch into two.
I noticed that on my x86 box, one of the newly added tests fail:

MMXEXT:
  uyvytoyuv420_mmxext (sw_rgb.c:126)
  yuyvtoyuv420_mmxext (sw_rgb.c:126)
- sw_rgb.uyvytoyuv  [FAILED]

SSE2, AVX and AVX2 are passing, though.


Hmm, that's problematic - we need to sort that out before we can push this 
test.


It's possible that this is a bug in the mmxext implementation. It's also 
possible that it is a case where the test is overly strict about something 
where we legitimately are allowed to deviate a little. (E.g. for cases 
where we know we have aligned/padded line sizes, it may be acceptable to 
overwrite the payload area by a couple of bytes.)


For failures in mmx tests, it's also possible that the declare_func 
should be a declare_func_emms instead.


We'd need to check exactly what differs in the output.

// Martin

___
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] GSoC 2025 SDR Cleanup

[Michael Niedermayer]

Hi Frank

On Wed, Feb 12, 2025 at 08:20:43AM +, Frank Plowman wrote:
> On 12/02/2025 01:21, Michael Niedermayer wrote:
> > Hi all
> > 
> > Ive added SDR to our GSoC 2025 page as there was just a single project
> > on that page and the page needs to be more complete yesterday
> > 
> > If people are against this say this NOW do not wait until we have accepted
> > a student and then start some drama
> > It can be removed now easily but not once someone is working on it
> > 
> > What is this project about ?
> > It is about YOU, the community, you disliked how libavradio is interfaced.
> > It bascially was just a demuxer/input device
> > 
> > So this Project is about someone within GSoC re structuring libavradio
> > and interfacing with a demuxer/input device as was previously suggested.
> > 
> > Please clearly list all requirements you have for this to get into git 
> > master
> > 
> 
> I don't think this is a good idea.  Regardless of one's opinion
> regarding SDR, it is evidently a contentious project.  It is unlikely
> that the collective community arrive at a unambiguous set of criteria
> for adoption before the project list goes live.  As such, I think it is
> likely that SDR would continue to be the subject of critique if it were
> a GSoC project.  Having a (potentially unsuspecting) student inserted
> right in the middle of this messy situation seems very unfair.

Yeah, i agree, i am thinking the same after sleeping over it.
It could be very bad for the student to be drawn into this

I will remove SDR from the page before accepted
organizations are announced, that way no student can start
working on it or even pick the task

thx

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

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


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

Re: [FFmpeg-devel] Democratization work in progress draft v2

[Tomas Härdin]

ons 2025-02-12 klockan 12:49 +0100 skrev Nicolas George:
> Tomas Härdin (HE12025-02-12):
> > This is aristocracy, not democracy.
> 
> Why do you believe democracy would be a good model for a Libre
> Software
> project?

The title of the thread includes the word "democratization"..

Plenty of free software projects operate on a BDFL principle and do not
bother claiming to be democratic. But that also implies a bus factor of
one. Such orgs are not stable in the long run.

If Michael is serious about democratizing the project then he should
actually do so.

> Why do you believe the opinion of people should matter
> irregardless of the quality and merit of their contribution to the
> project?

I never said such a thing. What I am saying is that you can't have it
both ways. Michael's fear of "takeover" is just the age-old critique of
democracy going at least as far back as Socrates. If you want my actual
opinion, I think that users should also have a say, not just
developers.

/Tomas
___
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] Democratization work in progress draft v2

[Nicolas George]

Tomas Härdin (HE12025-02-12):
> This is aristocracy, not democracy.

Why do you believe democracy would be a good model for a Libre Software
project? Why do you believe the opinion of people should matter
irregardless of the quality and merit of their contribution to the
project?

(There is an obvious answer, of course…)

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

Re: [FFmpeg-devel] [PATCH 3/8] libavformat/flacdec: Export samples md5 as metadata

[Tomas Härdin]

ons 2025-02-12 klockan 13:27 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > ons 2025-02-12 klockan 12:14 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > 
> > > > 
> > > > ___
> > > > 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".
> > > 
> > > This will forward wrong/outdated metadata if only part of a file is
> > > copied.
> > 
> > No? lavc/flacenc computes md5 from the actual samples and puts it in
> > the extradata. If you mean incomplete file copy (cp) rather then ffmpeg
> > -acodec copy then this will output what the user is likely interested
> > in: the MD5 of the original data. This allows them to check that the
> > file decodes correctly. This also applies to incomplete remuxing, which
> > also won't recompute the MD5 as it is, AFAICT. But, this patch concerns
> > the demuxer side, not transcoding or remuxing.
> > 
> 
> I mean e.g. -c copy -t . And even without the -t, this mostly
> pointless metadata will be forwarded by default with your patch and may
> get embedded into other files (as the aiff FATE reference file changes
> show).

Oh yeah good point. But also the incorrect extradata will be carried
over as it is at the moment. That could be fixed of course, but would
involve decoding the copied samples. The nastiness of doing that feels
similar to closed captions in H.26*

> And given that the md5 is wrong for an incomplete file, it does not
> allow the user to check that the file decodes correctly.

Yeah we shouldn't write incorrect data. I think I'll drop this patch
for now and have a back-and-forth with Spotify about it.

/Tomas
___
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] GSoC 2025 SDR Cleanup

[Michael Niedermayer]

Hi Nicolas

On Wed, Feb 12, 2025 at 02:16:01PM +0100, Nicolas George wrote:
> Michael Niedermayer (HE12025-02-12):
> > I will remove SDR from the page before accepted
> > organizations are announced
> 
> This kind of bait-and-switch could be very detrimental to the project
> for future editions of the program.
> 
> I think: either remove it right now or leave it and promise to kick out

ok, removed it


> anybody who makes trouble for the potential student.

I think its safer for the gsoc contributors to only list
things where there is no disagreement.

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [RFC] GSoC 2025 SDR Cleanup

[Nicolas George]

Michael Niedermayer (HE12025-02-12):
> I will remove SDR from the page before accepted
> organizations are announced

This kind of bait-and-switch could be very detrimental to the project
for future editions of the program.

I think: either remove it right now or leave it and promise to kick out
anybody who makes trouble for the potential student.

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

Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Martin Storsjö]

On Wed, 12 Feb 2025, Michael Niedermayer wrote:


On Mon, Feb 10, 2025 at 03:54:51PM +0200, Martin Storsjö wrote:

On Sun, 9 Feb 2025, Michael Niedermayer wrote:


Hi Martin

On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsjö wrote:

On Thu, 6 Feb 2025, Michael Niedermayer wrote:


On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsjö wrote:

On Thu, 6 Feb 2025, Michael Niedermayer wrote:


+// If the timer resolution is high, and we get the same timer
+// value multiple times, use variances in the number of repeats
+// of each timer value as entropy. If the number of repeats 
changed,
+// proceed to the next index.


Does it still work if you check against the last 2 ?
or does this become too slow ?
What iam thinking of is this

7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,... and a 9 or 6 or further distant 
would trigger it

I assume both the CPU clock and the wall time are quite precisse so if we
just compare them the entropy could be low even with 2 alternating values


Yes, that still works for making it terminate in a reasonable amount of
time. I updated the patch to keep track of 3 numbers of repeats, and we
consider that we got valid entropy once the new number of repeats is
different from the last two.

So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the last
one, we have old repeats 8 and 8, and the new repeat count 7, which in that
context looks unique.


I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used
values not 8,8


Sure, that's probably doable too.


that is, something like:

if (old2 == new) {
   FFSWAP(old,old2);


I don't see why we'd need to check this if clause at all, it seems to me
that it's enough to have the "if (old != new)" case.



If we have old2 == new,
we'd just end up with old2 = old, and old = (previous old2 value) anyway.


It was intended to be a least recent used check with 2 entries

If we have a clock running and sample that in precise intervalls
lets say the clock runs at 1.9hz and we sample at 10hz we would get

clock:0  0  0  0  0  0  1  1  1  1  1  2  2  2  2  2  3  3  3  3  3  3  4  
4  4  4  4  5  5  5  5  5  6  6  6  6  6  7  7  7  7  7  7  8  8  8  8  8  9  9
difference:  0  0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  
0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  0  0  0  0  1  0

Above adds no entropy after the initial entropy, this can be read forever
it will not improve randomness

here we have runs of repeated clock reads of 5,4,4,5,4,4,4,5,4
again we can read this as long as we want there is no entropy gained
so after a 5,4,4,4 if a 5 happens thats not breaking the pattern and should
not be counted as new entropy (if possible)


Yes, I get that intent.

It's just that your suggested pseudocode seems unnecessarily complex, or I'm
missing something:

if (old2 == new) {
FFSWAP(old,old2);
} else if (old != new) {
old2 = old;
old = new;
}

If we have the sequence "5, 4, 4, 4, 4", followed by another "5", we have
old2 == 5, old == 4, new == 5. Then we get the same end result (old2 == 4,
old == 5) both if we execute the code you suggest above, and if we just
execute this:

if (old != new) {
old2 = old;
old = new;
}

Or is there something I'm missing? I don't see the need for the FFSWAP case.

As long as we check (new != old && new != old2) we should pick up actual
deviation from the steady state but not the variance between two values.


Heres an example where the SWAP is needed:
noswap swap
5 -> [x 5]  [x 5]
4 -> [5 4]  [5 4]
5 -> [5 4]  [4 5]
6 -> [4 6]  [5 6]
5 -> [6 5]  [6 5]

In the last case the 5 is in the old* when the swap was used but not
when it was not used


Sorry, but your examples do not make sense or do not contain enough 
context (it does not include the initial states of the two old values, and 
it requires guesswork which ones of the two [x y] values is old and which 
one is old2).


But to be clear:

Please specify the initial values of the variables new, old and old2, for 
a case where



if (old2 == new) {
FFSWAP(old,old2);
} else if (old != new) {
old2 = old;
old = new;
}


produces a different end result than


if (old != new) {
old2 = old;
old = new;
}


I claim that for any values of these variables, the end result is the 
same.


In any case, I'll send an update of the whole patchset - please do review 
it; I believe that it works as you want it to, and I would like to move 
forward with it.


// Martin
___
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 v4 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Martin Storsjö]

On a Zen 5, on Ubuntu 24.04 (with CLOCKS_PER_SEC 100), the
value of clock() in this loop increments by 0 most of the time,
and when it does increment, it usually increments by 1 compared
to the previous round.

Due to the "last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) >= t"
expression, we only manage to take one step forward in this loop
(incrementing i) if clock() increments by 2, while it incremented
by 0 in the previous iteration (last_td).

This is similar to the change done in
c4152fc42e480c41efb7f761b1bbe5f0bc43d5bc, to speed it up on
systems with very small CLOCKS_PER_SEC. However in this case,
CLOCKS_PER_SEC is still very large, but the machine is fast enough
to hit every clock increment repeatedly.

For this case, use the number of repetitions of each timer value
as entropy source; require a change in the number of repetitions
in order to proceed to the next buffer index.

This helps the fate-random-seed test to actually terminate within
a reasonable time on such a system (where it previously could hang,
running for many minutes).
---
v4: Keep a history of 2 old unique repeat counts, and require the
new count of repeats to differ from the previous 2 unique values
in order to count it as new entropy.
---
 libavutil/random_seed.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
index ca084b40da..e08ab7b12e 100644
--- a/libavutil/random_seed.c
+++ b/libavutil/random_seed.c
@@ -83,6 +83,7 @@ static uint32_t get_generic_seed(void)
 static uint32_t buffer[512] = { 0 };
 unsigned char digest[20];
 uint64_t last_i = i;
+int repeats[3] = { 0 };
 
 av_assert0(sizeof(tmp) >= av_sha_size);
 
@@ -101,8 +102,23 @@ static uint32_t get_generic_seed(void)
 int incremented_i = 0;
 int cur_td = t - last_t;
 if (last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) < t) {
+// If the timer incremented by more than 2*last_td at once,
+// we may e.g. have had a context switch. If the timer resolution
+// is high (CLOCKS_PER_SEC > 1000), require that the timer
+// incremented by more than 1. If the timer resolution is low,
+// it is enough that the timer incremented at all.
 buffer[++i & 511] += cur_td % 3294638521U;
 incremented_i = 1;
+} else if (t != last_t && repeats[0] > 0 && repeats[1] > 0 &&
+   repeats[2] > 0 && repeats[0] != repeats[1] &&
+   repeats[0] != repeats[2]) {
+// If the timer resolution is high, and we get the same timer
+// value multiple times, use variances in the number of repeats
+// of each timer value as entropy. If we get a different number of
+// repeats than the last two unique cases, count that as entropy
+// and proceed to the next index.
+buffer[++i & 511] += (repeats[0] + repeats[1] + repeats[2]) % 
3294638521U;
+incremented_i = 1;
 } else {
 buffer[i & 511] = 1664525*buffer[i & 511] + 1013904223 + (cur_td % 
3294638521U);
 }
@@ -110,6 +126,16 @@ static uint32_t get_generic_seed(void)
 if (last_i && i - last_i > 4 || i - last_i > 64 || TEST && i - 
last_i > 8)
 break;
 }
+if (t == last_t) {
+repeats[0]++;
+} else {
+// If we got a new unique number of repeats, update the history.
+if (repeats[0] != repeats[1]) {
+repeats[2] = repeats[1];
+repeats[1] = repeats[0];
+}
+repeats[0] = 0;
+}
 last_t = t;
 last_td = cur_td;
 if (!init_t)
-- 
2.43.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] [PATCH v4 1/2] random_seed: Reorder if clauses for gathering entropy

[Martin Storsjö]

Make it easier to add more cases.

This should be a pure refactoring, with no functional changes.
---
 libavutil/random_seed.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
index 8a4e4f1fc0..ca084b40da 100644
--- a/libavutil/random_seed.c
+++ b/libavutil/random_seed.c
@@ -98,17 +98,20 @@ static uint32_t get_generic_seed(void)
 
 for (;;) {
 clock_t t = clock();
-if (last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) >= t) {
-last_td = t - last_t;
-buffer[i & 511] = 1664525*buffer[i & 511] + 1013904223 + (last_td 
% 3294638521U);
+int incremented_i = 0;
+int cur_td = t - last_t;
+if (last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) < t) {
+buffer[++i & 511] += cur_td % 3294638521U;
+incremented_i = 1;
 } else {
-last_td = t - last_t;
-buffer[++i & 511] += last_td % 3294638521U;
-if ((t - init_t) >= CLOCKS_PER_SEC>>5)
-if (last_i && i - last_i > 4 || i - last_i > 64 || TEST && i - 
last_i > 8)
-break;
+buffer[i & 511] = 1664525*buffer[i & 511] + 1013904223 + (cur_td % 
3294638521U);
+}
+if (incremented_i && (t - init_t) >= CLOCKS_PER_SEC>>5) {
+if (last_i && i - last_i > 4 || i - last_i > 64 || TEST && i - 
last_i > 8)
+break;
 }
 last_t = t;
+last_td = cur_td;
 if (!init_t)
 init_t = t;
 }
-- 
2.43.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".

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/riffdec: warn on invalid sample rate

[Viraaj Raulgaonkar]

On Mon, Feb 3, 2025 at 9:55 AM Viraaj Raulgaonkar
 wrote:
>
> If strict_std_compliance < FF_COMPLIANCE_STRICT, warn the user of the
> invalid sample rate instead of returning an error. In certain cases the
> sample rate can get decoded later on.
>
> Fixes Trac Ticket #11361.
> ---
>  libavformat/riffdec.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
> index 2b269b1682..a3eee43a41 100644
> --- a/libavformat/riffdec.c
> +++ b/libavformat/riffdec.c
> @@ -180,9 +180,12 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext 
> *pb,
>  par->bit_rate = bitrate;
>
>  if (par->sample_rate <= 0) {
> -av_log(s, AV_LOG_ERROR,
> +int strict = s->strict_std_compliance >= FF_COMPLIANCE_STRICT;
> +av_log(s, strict ? AV_LOG_ERROR : AV_LOG_WARNING,
> "Invalid sample rate: %d\n", par->sample_rate);
> -return AVERROR_INVALIDDATA;
> +if (strict)
> +return AVERROR_INVALIDDATA;
> +par->sample_rate = 0;
>  }
>  if (par->codec_id == AV_CODEC_ID_AAC_LATM) {
>  /* Channels and sample_rate values are those prior to applying SBR
> --
> 2.39.5
>

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] [PATCH 3/8] libavformat/flacdec: Export samples md5 as metadata

[Tomas Härdin]

ons 2025-02-12 klockan 12:14 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > 
> > 
> > ___
> > 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".
> 
> This will forward wrong/outdated metadata if only part of a file is
> copied.

No? lavc/flacenc computes md5 from the actual samples and puts it in
the extradata. If you mean incomplete file copy (cp) rather then ffmpeg
-acodec copy then this will output what the user is likely interested
in: the MD5 of the original data. This allows them to check that the
file decodes correctly. This also applies to incomplete remuxing, which
also won't recompute the MD5 as it is, AFAICT. But, this patch concerns
the demuxer side, not transcoding or remuxing.

> Apart from that, is it really necessary to export the md5 as
> metadata given that it is very easily obtainable from the extradata?

I'm not sure if our users know that. But yes metadata can be dumped and
then cut can be used to extract the MD5. But as Michael points out,
flac isn't the only codec with MD5 hashes.

/Tomas
___
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] Democratization work in progress draft v2

[Tomas Härdin]

ons 2025-01-29 klockan 21:33 +0100 skrev Michael Niedermayer:
>     Make Voting Power Proportional to Contributions
>     Fair Representation: Allocate voting power based on
> contributions, ensuring that those who dedicate substantial time and
> effort to the project have a stronger voice than those with minimal
> involvement. This creates a system where contribution equals
> influence.

This is aristocracy, not democracy. Just set up a non-profit with
appropriate bylaws. This is a solved problem.

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

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

Re: [FFmpeg-devel] GSoC 2025

[Marth64]

Hi Nicolas,

I’ll be clear: my decision to funnel the conversation into a more
isolated (but project-official) channel was based on experience and
best practices, not guesswork. I have over a decade of real-world
experience and training managing teams, resolving conflict, and
guiding projects to success. If you’d like to understand the
reasoning, I suggest looking into the 5 C’s of Conflict Management,
which emphasizes the importance of clear communication and
collaboration in conflict resolution. I did not see that potential in
a wide-open thread like this.

In cases of conflict, especially during sensitive moments, it’s a
well-established leadership practice to reduce surface area and shift
discussions to a focused group where they can be resolved more
productively.

If you have constructive feedback, I’m happy to hear it, but I won’t
engage in unproductive criticism of the CC’s role.

Respectfully,
Marth64
___
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] Experiment: enable github pull requests

[Lynne]

On 13/02/2025 03:59, Soft Works wrote:



-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Donnerstag, 13. Februar 2025 02:52
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 13.02.2025 01:40, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of
Romain Beauxis
Sent: Donnerstag, 13. Februar 2025 01:25
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

Le mer. 12 févr. 2025 à 18:17, Soft Works
 a écrit :





-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Donnerstag, 13. Februar 2025 00:34
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull

requests


On 13.02.2025 00:07, Soft Works wrote:



-Original Message-
From: ffmpeg-devel  On Behalf

Of

Timo

Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull

requests


On 12.02.2025 22:22, Stephen Hutchinson wrote:

Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/


For those who are too lazy to look it up:

The "Agit workflow" requires you to use non-standard Git "push-

options"

(either -o or --push-options):

git push origin HEAD:refs/for/master -o topic="topic-branch" \
 -o title="Title of the PR" \
 -o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"

This means essentially that our attempt to move away from the e-mail-

based

submission procedure to something easy and user-friendly, would end

up

in

replacing the current rarely-known mechanism with another even more

rare

and obscure procedure which would (again) force everybody to use the

Git

command line because it's (again) not supported by any tooling except

Git

CLI.


I'm afraid, but from my point of view, this doesn't match the objective.


The only alternative is to completely lock down the instance, and not
allow new users at all without manual approval of each and every one.

People can just ask to be allowed to fork, but by default, allowing it
is not feasible.


Hm, please help me understand what kind of spam we're talking about

here.

I can't imagine somebody would take the effort for selling some pills to

ffmpeg

developers. When it's about advertising anything, that's not the kind of

reach

those people are typically looking for.


Or is it about misusing repos for storage of illegal content? The largest file

currently is just 953kB, so we could enforce a limit small enough to make it
unattractive for this purpose (unlike GitHub with 100MB per file).


We could also disallow repos with custom content (i.e. only forks of

ffmpeg

are allowed as repo content).


Then I wonder, where would be the harm? Some thousand unused forks

of

ffmpeg shouldn't be a problem - but maybe I'm overseeing something?

There are all sorts of copyrightable material that can be embedded
into a git repo.


That's why I mentioned that a file size limit could prevent this. With a 2 MB

limit per file, it becomes totally unattractive for this kind of abuse.

That doesn't seem feasible to implement, given it's git.
Not even sure how to implement such a limit at all with git.
Some hook would need to check every file on push, which I don't think is
something that readily exists.


GitHub does it. I think a pre-receive hook can do it. AI spits out a 10 line
Bash script. Might be wrong as usual, but the principle should work.



AFAIK, you are only responsible to take stuff down once you get notified,

you don't need to actively look for anything.

I still wouldn't want to be the one hosting who knows what of illegal
shit on our servers.


The nature of illegal shit these days involves a certain size - as said, I 
don't believe that it's attractive for anybody when you can store max 2 MB 
files. Splitting it into a RAR set like in earlier days is also not something 
worth the effort, give that so many better alternatives exist.
  

Also keep in mind that if they fork the FFmpeg repo, and then push
something big and bad into that fork,


^^ File size limit


it ends up in the same backing storage of git objects.
So it's not even trivial to just delete it again, and bar access to it.


If these are just branches, why would it be non-trivial to delete them?
I would expect that from forgejo to be handled when a forked repo gets deleted, 
don't you think they would do so?



Also, I wonder how this would be different from attachments on

https

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[martin schitter]

On 2/12/25 23:05, Timo Rothenpieler wrote:

PRs are not restricted. Creating repos is.
And there is no way to NOT restrict it, unless you want to pay several 
hundred Euros a month in hosting fees extra, and constantly be on the 
lookout for hosting illegal/harmful things.


Hosting tons of forks can be done very efficiently if you storage 
solution provides adequate *deduplication* support. That's only one of 
the typical issues that you'll have to face, if you try to imitate the 
big ones by using utterly inadequate means. Tools which only look 
similar on their outer surface.


Fighting notification spam, which plagued codeberg (=forgejo) users the 
last days in a very unpleasant way, are a similar problem. Ignoring the 
importance of these less obvious maintenance requirements looks to me 
like setting up an email server resp. gateway without any mature spam 
protection facilities these days.


But I also wouldn't be happy if GitHub would be simply chosen at the end 
because of all this challenging troubles and dangers.


Anyway -- CI workflow, automatic PR checks and satisfying comment and 
documentation support are IMHO much more important aspects than just 
hosting a git repo on the web.


martin
___
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] avformat/mov: Fix get_eia608_packet c608 caption reformatting

[Andreas Rheinhardt]

Pavel Koshevoy:
> ---
>  libavformat/mov.c | 40 +++-
>  1 file changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 85aef33b19..422e515fe8 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -10790,22 +10790,44 @@ static int mov_change_extradata(AVStream *st, 
> AVPacket *pkt)
>  
>  static int get_eia608_packet(AVIOContext *pb, AVPacket *pkt, int size)
>  {
> -int new_size, ret;
> -
> +/* We can't make assumptions about the structure of the payload,
> +   because it may include multiple cdat and cdt2 samples. */
> +int ret, out_size = 0;
>  if (size <= 8)
>  return AVERROR_INVALIDDATA;
> -new_size = ((size - 8) / 2) * 3;
> -ret = av_new_packet(pkt, new_size);
> +
> +/* Allocate 3 times the required buffer size to give us enough space
> +   to store the original c608 packet and (potentially 3/2 times larger)
> +   reformatted data, safely. */
> +ret = av_new_packet(pkt, size * 3);
>  if (ret < 0)
>  return ret;
>  
> -avio_skip(pb, 8);
> -for (int j = 0; j < new_size; j += 3) {
> -pkt->data[j] = 0xFC;
> -pkt->data[j+1] = avio_r8(pb);
> -pkt->data[j+2] = avio_r8(pb);
> +/* Load the original c608 payload into the last 3rd of the buffer. */
> +if (avio_read(pb, pkt->data + size * 2, size) != size)
> +return AVERROR_EOF;
> +
> +/* parse and re-format the c608 payload in one pass */
> +for (uint8_t *out = pkt->data, *src = out + size * 2, *end = src + size; 
> src + 8 <= end; ) {
> +uint32_t atom_size = AV_RB32(src);
> +uint8_t cc_field =
> +memcmp(src + 4, "cdat", 4) == 0 ? 1 :
> +memcmp(src + 4, "cdt2", 4) == 0 ? 2 :
> +0;
> +
> +if (cc_field != 0) {
> +for (uint8_t *cc = src + 8, *cc_end = src + atom_size; cc < 
> cc_end; cc += 2) {
> +out[0] = (0x1F << 3) | (1 << 2) | (cc_field - 1);
> +out[1] = cc[0];
> +out[2] = cc[1];
> +out_size += 3;
> +out += 3;
> +}
> +}
> +src += atom_size;
>  }
>  
> +pkt->size = out_size;
>  return 0;
>  }
>  

1. You are trusting atom_size, although it may be insanely large. This
may lead to segfaults.
2. 3 * size might overflow.
3. You overallocate a lot here. Wouldn't it be enough to allocate size +
size / 2? You would then read into pkt->data + size / 2 and reformat the
data from the start.
4. You need to shrink the packet to zero the padding.
5. You don't need to keep track of out_size; you can get it via out -
pkt->data.

- Andreas

___
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] Experiment: enable github pull requests

[martin schitter]

On 2/13/25 07:14, Lynne wrote:
Finally, with federation, there's are no restriction. If users have an 
account on another Forgejo instance, such as codeberg, they can clone 
and submit PRs to FFmpeg without having to register, and without needing 
to use agit.


This will not work very well together with more advanced CI based PR 
checks and feedback if the used software platform doesn't provide mature 
support for these kinds of distributed setups. Ignoring this limitation 
you'll quickly face inconsistent repository-states and chaos as 
consequence. Until now none of the well known software options is able 
to play well in federated mode.


Using the other "federated" instances just as old fashioned identity 
providers isn't a very convincing solution to solve any of the real 
challenges of setting up a more efficient and somehow future-proof 
collaborative development workflow.


martin
___
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] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Lynne
> Sent: Donnerstag, 13. Februar 2025 07:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13/02/2025 03:59, Soft Works wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Donnerstag, 13. Februar 2025 02:52
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 13.02.2025 01:40, Soft Works wrote:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
>  Romain Beauxis
>  Sent: Donnerstag, 13. Februar 2025 01:25
>  To: FFmpeg development discussions and patches   de...@ffmpeg.org>
>  Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> 
>  Le mer. 12 févr. 2025 à 18:17, Soft Works
>   a écrit :
> >
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf
> Of
>  Timo
> >> Rothenpieler
> >> Sent: Donnerstag, 13. Februar 2025 00:34
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>
> >> On 13.02.2025 00:07, Soft Works wrote:
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On
> Behalf
> >> Of
> >> Timo
>  Rothenpieler
>  Sent: Mittwoch, 12. Februar 2025 22:33
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
>  requests
> 
>  On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > Are all accounts restricted to owning a maximum of 0 repositories
> by
> > default, or is it set to 0 only for those that sign up through one 
> > of
> > the external logins?
> 
>  It's set to 0 by default, to avoid spammers uploading junk, or just
>  people (ab)using it for non-ffmpeg things.
> 
>  You can open issues and comment on existing PRs.
>  And also create PRs using the AGit workflow:
>  https://forgejo.org/docs/latest/user/agit-support/
> >>>
> >>> For those who are too lazy to look it up:
> >>>
> >>> The "Agit workflow" requires you to use non-standard Git "push-
>  options"
> >>> (either -o or --push-options):
> >>>
> >>> git push origin HEAD:refs/for/master -o topic="topic-branch" \
> >>>  -o title="Title of the PR" \
> >>>  -o description="# The PR Description
> >>> This can be **any** markdown content.\n
> >>> - [x] Ok"
> >>>
> >>> This means essentially that our attempt to move away from the e-
> mail-
>  based
> >> submission procedure to something easy and user-friendly, would end
> >> up
>  in
> >> replacing the current rarely-known mechanism with another even
> more
>  rare
> >> and obscure procedure which would (again) force everybody to use
> the
> >> Git
> >> command line because it's (again) not supported by any tooling except
> >> Git
>  CLI.
> >>>
> >>> I'm afraid, but from my point of view, this doesn't match the
> objective.
> >>
> >> The only alternative is to completely lock down the instance, and not
> >> allow new users at all without manual approval of each and every one.
> >>
> >> People can just ask to be allowed to fork, but by default, allowing it
> >> is not feasible.
> >
> > Hm, please help me understand what kind of spam we're talking about
> >> here.
>  I can't imagine somebody would take the effort for selling some pills to
> >> ffmpeg
>  developers. When it's about advertising anything, that's not the kind of
> >> reach
>  those people are typically looking for.
> >
> > Or is it about misusing repos for storage of illegal content? The 
> > largest
> file
>  currently is just 953kB, so we could enforce a limit small enough to make
> it
>  unattractive for this purpose (unlike GitHub with 100MB per file).
> >
> > We could also disallow repos with custom content (i.e. only forks of
> >> ffmpeg
>  are allowed as repo content).
> >
> > Then I wonder, where would be the harm? Some thousand unused
> forks
> >> of
>  ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> 
>  There are all sorts of copyrightable material that can be embedded
>  into a git repo.
> >>>
> >>> That's why I mentioned that a file size limit could prevent this. With a 
> >>> 2 MB
> >> limit per file, it becomes totally unattractive for this kind of abuse.
> >>
> >> That doesn't seem feasible to implement, given it's git.
> >> Not even sure how to implement such a limit at all with git.
> >> Some hook would need to check every file on push, which I don't think is
> >> something that readily exists.
> >
>

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Donnerstag, 13. Februar 2025 02:52
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13.02.2025 01:40, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Romain Beauxis
> >> Sent: Donnerstag, 13. Februar 2025 01:25
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> Le mer. 12 févr. 2025 à 18:17, Soft Works
> >>  a écrit :
> >>>
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
> >> Timo
>  Rothenpieler
>  Sent: Donnerstag, 13. Februar 2025 00:34
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> 
>  On 13.02.2025 00:07, Soft Works wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf
> Of
>  Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>> default, or is it set to 0 only for those that sign up through one of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >
> > For those who are too lazy to look it up:
> >
> > The "Agit workflow" requires you to use non-standard Git "push-
> >> options"
> > (either -o or --push-options):
> >
> > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> > -o title="Title of the PR" \
> > -o description="# The PR Description
> > This can be **any** markdown content.\n
> > - [x] Ok"
> >
> > This means essentially that our attempt to move away from the e-mail-
> >> based
>  submission procedure to something easy and user-friendly, would end
> up
> >> in
>  replacing the current rarely-known mechanism with another even more
> >> rare
>  and obscure procedure which would (again) force everybody to use the
> Git
>  command line because it's (again) not supported by any tooling except
> Git
> >> CLI.
> >
> > I'm afraid, but from my point of view, this doesn't match the objective.
> 
>  The only alternative is to completely lock down the instance, and not
>  allow new users at all without manual approval of each and every one.
> 
>  People can just ask to be allowed to fork, but by default, allowing it
>  is not feasible.
> >>>
> >>> Hm, please help me understand what kind of spam we're talking about
> here.
> >> I can't imagine somebody would take the effort for selling some pills to
> ffmpeg
> >> developers. When it's about advertising anything, that's not the kind of
> reach
> >> those people are typically looking for.
> >>>
> >>> Or is it about misusing repos for storage of illegal content? The largest 
> >>> file
> >> currently is just 953kB, so we could enforce a limit small enough to make 
> >> it
> >> unattractive for this purpose (unlike GitHub with 100MB per file).
> >>>
> >>> We could also disallow repos with custom content (i.e. only forks of
> ffmpeg
> >> are allowed as repo content).
> >>>
> >>> Then I wonder, where would be the harm? Some thousand unused forks
> of
> >> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> >>
> >> There are all sorts of copyrightable material that can be embedded
> >> into a git repo.
> >
> > That's why I mentioned that a file size limit could prevent this. With a 2 
> > MB
> limit per file, it becomes totally unattractive for this kind of abuse.
> 
> That doesn't seem feasible to implement, given it's git.
> Not even sure how to implement such a limit at all with git.
> Some hook would need to check every file on push, which I don't think is
> something that readily exists.

GitHub does it. I think a pre-receive hook can do it. AI spits out a 10 line
Bash script. Might be wrong as usual, but the principle should work.


> > AFAIK, you are only responsible to take stuff down once you get notified,
> you don't need to actively look for anything.
> 
> I still wouldn't want to be the one hosting who knows what of illegal
> shit on our servers.

The nature of illegal shit these days involves a certain size - as said, I 
don't believe that it's attractive for anybody when you can store max 2 MB 
files. Splitting it into a RAR set like in earl

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Lynne
> Sent: Donnerstag, 13. Februar 2025 07:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13/02/2025 03:59, Soft Works wrote:
> >
> Finally, with federation, there's are no restriction. If users have an
> account on another Forgejo instance, such as codeberg, they can clone
> and submit PRs to FFmpeg without having to register, and without needing
> to use agit.

Two more thoughts:

I'm a bit surprised to hear that Spammers would be such a big problem. On 
GitHub, I'm subscribed to dozens of repos and surely more than a thousand 
conversations, but over the past 10 years I have received less than 5 spam 
messages in total. That makes we wonder how GH is doing it, because 
notifications are sent out instantly and I would have seen those in the inbox 
even when they would have been cleaned up later.
What's their recipe?


And regarding Codeberg: When spam is such a big concern that we must require 
user to apply even for creating a fork (unlike almost any other open-source 
software project in the world) - why then even bother with self-hosting? If we 
think it causes too much trouble, why do it in the first place? There are other 
organizations for which hosting Git repos is their daily and primary business. 
Maybe it's better to have it professionally hosted and call it a day... 
Why not Codeberg actually?

Best
sw 



 
___
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] GSoC 2025 SDR Cleanup

[Marth64]

Michael,
> I think its safer for the gsoc contributors to only list
> things where there is no disagreement.

Thank you for pondering this and taking the best interest of the
students into account.
___
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 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Martin Storsjö]

On Wed, 12 Feb 2025, Michael Niedermayer wrote:


Hi Martin

On Wed, Feb 12, 2025 at 11:25:03AM +0200, Martin Storsjö wrote:
[...]

Heres an example where the SWAP is needed:
noswap swap
5 -> [x 5]  [x 5]
4 -> [5 4]  [5 4]
5 -> [5 4]  [4 5]
6 -> [4 6]  [5 6]
5 -> [6 5]  [6 5]

In the last case the 5 is in the old* when the swap was used but not
when it was not used


Sorry, but your examples do not make sense or do not contain enough context
(it does not include the initial states of the two old values, and it
requires guesswork which ones of the two [x y] values is old and which one
is old2).

But to be clear:

Please specify the initial values of the variables new, old and old2, for a
case where


if (old2 == new) {
FFSWAP(old,old2);
} else if (old != new) {
old2 = old;
old = new;
}


produces a different end result than


if (old != new) {
old2 = old;
old = new;
}


I claim that for any values of these variables, the end result is the same.


yes, you are correct, i thought you intended to run the old2/old update only if
new differs from both old and old2.

The actual code you wrote is fine and nicely optimizes the swap out


Thanks, then I'll push it soon. And after some delay, I'd also backport it 
to a couple branches if that's ok; without this, "make fate" hangs on my 
machine.


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

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

Re: [FFmpeg-devel] GSoC 2025

[Marth64]

Hi Nicolas,

Thank you for the feedback.

I understand that some have concerns about the CC, and I don’t expect
that to change overnight. My goal was not to create secrecy but to
strike a balance—ensuring privacy for sensitive discussions,
especially a peer-to-peer complaint, while directing them to the
appropriate official channel.

These situations are complex, and I’m committed to learning and
improving. I can assure you that the CoC was carefully considered in
this case, and I’ll leave it at that.

Best,
Marth64
___
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] Experiment: enable github pull requests

[Michael Niedermayer]

On Wed, Feb 12, 2025 at 07:49:20PM +0100, Lynne wrote:
> On 12/02/2025 19:06, Michael Niedermayer wrote:
> > Hi all
> > 
> > I propose, that we enable github pull requests
> > 
> > github is the most widely used development platform and has the lowest 
> > barrier
> > of entry.
> > 
> > after ~1-3 Month, we then evaluate how many new developers this attracted,
> > how many new contributions it attracted.
> > What the ratios of reviewed vs ignored vs applied vs rejected patches are 
> > compared to the ML
> 
> Those are rather arbitrary statistics.

Some people claimed these statistics would improve. I do think we should
compare some statistics (obviously not limited to these)


[...]

> Users can already login to the instance with their github accounts, so
> there's no barrier to entry.

Thats cool, then forgejo is probably better for this experiment (if we do it)

thx


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

[FFmpeg-devel] [PATCH v3] libavformat/mov: fix seek issues for fragmented mp4 files

[Srikanth Kiran Kotagiri]

From: Srikanth Kiran Kotagiri 

For Fragmented MP4 files where the audio and video streams are written to 
seperate fragments,
the -ss option will cause the file pointer to be set to the first available 
fragment. This
is due to an interaction in search_frag_timestamp() function and 
get_frag_time() functions.

With this change, we first verify that the fragment being checked does not 
actually contain
the requested stream before just sending AV_NOPTS_VALUE.
---
 libavformat/mov.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 85aef33b19..8e89f6f934 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -87,6 +87,7 @@ typedef struct MOVParseTableEntry {
 static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom);
 static int mov_read_mfra(MOVContext *c, AVIOContext *f);
 static void mov_free_stream_context(AVFormatContext *s, AVStream *st);
+static int mov_switch_root(AVFormatContext *s, int64_t target, int index);
 
 static int mov_metadata_track_or_disc_number(MOVContext *c, AVIOContext *pb,
  unsigned len, const char *key)
@@ -1672,6 +1673,7 @@ static int64_t get_frag_time(AVFormatContext *s, AVStream 
*dst_st,
 MOVStreamContext *sc = dst_st->priv_data;
 int64_t timestamp;
 int i, j;
+int stream_present;
 
 // If the stream is referenced by any sidx, limit the search
 // to fragments that referenced this stream in the sidx
@@ -1686,6 +1688,27 @@ static int64_t get_frag_time(AVFormatContext *s, 
AVStream *dst_st,
 return frag_stream_info->sidx_pts;
 }
 
+
+// Check if the requested stream is present in the fragment
+stream_present = 0;
+for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
+if (dst_st->id != frag_index->item[index].stream_info[i].id)
+continue;
+if ( get_stream_info_time(&frag_index->item[index].stream_info[i]) != 
AV_NOPTS_VALUE) {
+stream_present = 1;
+break;
+}
+if ( mov_switch_root(s,-1,index) < 0)
+return AV_NOPTS_VALUE;
+if ( get_stream_info_time(&frag_index->item[index].stream_info[i]) != 
AV_NOPTS_VALUE) {
+stream_present = 1;
+break;
+}
+}
+if (!stream_present)
+return AV_NOPTS_VALUE;
+
+
 for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
 AVStream *frag_stream = NULL;
 frag_stream_info = &frag_index->item[index].stream_info[i];
-- 
2.39.5 (Apple Git-154)

___
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] [RFC] Experiment: enable github pull requests

[Michael Niedermayer]

Hi all

I propose, that we enable github pull requests

github is the most widely used development platform and has the lowest barrier
of entry.

after ~1-3 Month, we then evaluate how many new developers this attracted,
how many new contributions it attracted.
What the ratios of reviewed vs ignored vs applied vs rejected patches are 
compared to the ML

This information should help the community make decissions about the use of
web based git development vs the mailing list.

Thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 15:32, Timo Rothenpieler  a
écrit :
>
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > On 2/12/25 2:23 PM, Lynne wrote:
> >>
> >>
> >> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>> Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> 
>  Users can already login to the instance with their github accounts,
so
>  there's no barrier to entry.
> >>>
> >>> Would you mind sharing the url? A quick search didn't reveal anything.
> >>
> >> Sure
> >> https://code.ffmpeg.org/
> >>
> >
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
>
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
>
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/
>
> The repo limit can manually be lifted per user. I preferred that
> approach vs. the Videolan approach of completely locking down the
> instance, and requiring admin approval for every single new user, which
> imo is more detrimental to new contributors than a ML.

I totally understand the concern.

The procedure for creating PRs using AGit is a bit arcane but I'll give it
a try.

It would be nice to have this document big and bold when users register, I
was quite lost after registration seeing I couldn't fork.

I'm gonna try to think about how to split patches from the ML perspective
to a PR perspective.

Is there any opinion on this? Typically the series I have has a section for
flac and one for opus, do y'all think one general PR for the base work then
one PR for flac and one PR for opus or one single PR with the patch series
like in the ML?

Thanks,
-- romain
___
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] GSoC 2025 SDR Cleanup

[Frank Plowman]

On 12/02/2025 01:21, Michael Niedermayer wrote:
> Hi all
> 
> Ive added SDR to our GSoC 2025 page as there was just a single project
> on that page and the page needs to be more complete yesterday
> 
> If people are against this say this NOW do not wait until we have accepted
> a student and then start some drama
> It can be removed now easily but not once someone is working on it
> 
> What is this project about ?
> It is about YOU, the community, you disliked how libavradio is interfaced.
> It bascially was just a demuxer/input device
> 
> So this Project is about someone within GSoC re structuring libavradio
> and interfacing with a demuxer/input device as was previously suggested.
> 
> Please clearly list all requirements you have for this to get into git master
> 

I don't think this is a good idea.  Regardless of one's opinion
regarding SDR, it is evidently a contentious project.  It is unlikely
that the collective community arrive at a unambiguous set of criteria
for adoption before the project list goes live.  As such, I think it is
likely that SDR would continue to be the subject of critique if it were
a GSoC project.  Having a (potentially unsuspecting) student inserted
right in the middle of this messy situation seems very unfair.

-- 
Frank

___
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] avformat/mov: Fix get_eia608_packet c608 caption reformatting

[Pavel Koshevoy]

---
 libavformat/mov.c | 40 +++-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 85aef33b19..422e515fe8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -10790,22 +10790,44 @@ static int mov_change_extradata(AVStream *st, 
AVPacket *pkt)
 
 static int get_eia608_packet(AVIOContext *pb, AVPacket *pkt, int size)
 {
-int new_size, ret;
-
+/* We can't make assumptions about the structure of the payload,
+   because it may include multiple cdat and cdt2 samples. */
+int ret, out_size = 0;
 if (size <= 8)
 return AVERROR_INVALIDDATA;
-new_size = ((size - 8) / 2) * 3;
-ret = av_new_packet(pkt, new_size);
+
+/* Allocate 3 times the required buffer size to give us enough space
+   to store the original c608 packet and (potentially 3/2 times larger)
+   reformatted data, safely. */
+ret = av_new_packet(pkt, size * 3);
 if (ret < 0)
 return ret;
 
-avio_skip(pb, 8);
-for (int j = 0; j < new_size; j += 3) {
-pkt->data[j] = 0xFC;
-pkt->data[j+1] = avio_r8(pb);
-pkt->data[j+2] = avio_r8(pb);
+/* Load the original c608 payload into the last 3rd of the buffer. */
+if (avio_read(pb, pkt->data + size * 2, size) != size)
+return AVERROR_EOF;
+
+/* parse and re-format the c608 payload in one pass */
+for (uint8_t *out = pkt->data, *src = out + size * 2, *end = src + size; 
src + 8 <= end; ) {
+uint32_t atom_size = AV_RB32(src);
+uint8_t cc_field =
+memcmp(src + 4, "cdat", 4) == 0 ? 1 :
+memcmp(src + 4, "cdt2", 4) == 0 ? 2 :
+0;
+
+if (cc_field != 0) {
+for (uint8_t *cc = src + 8, *cc_end = src + atom_size; cc < 
cc_end; cc += 2) {
+out[0] = (0x1F << 3) | (1 << 2) | (cc_field - 1);
+out[1] = cc[0];
+out[2] = cc[1];
+out_size += 3;
+out += 3;
+}
+}
+src += atom_size;
 }
 
+pkt->size = out_size;
 return 0;
 }
 
-- 
2.43.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".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 01:40, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of
Romain Beauxis
Sent: Donnerstag, 13. Februar 2025 01:25
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

Le mer. 12 févr. 2025 à 18:17, Soft Works
 a écrit :





-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Donnerstag, 13. Februar 2025 00:34
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 13.02.2025 00:07, Soft Works wrote:



-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull

requests


On 12.02.2025 22:22, Stephen Hutchinson wrote:

Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/


For those who are too lazy to look it up:

The "Agit workflow" requires you to use non-standard Git "push-

options"

(either -o or --push-options):

git push origin HEAD:refs/for/master -o topic="topic-branch" \
-o title="Title of the PR" \
-o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"

This means essentially that our attempt to move away from the e-mail-

based

submission procedure to something easy and user-friendly, would end up

in

replacing the current rarely-known mechanism with another even more

rare

and obscure procedure which would (again) force everybody to use the Git
command line because it's (again) not supported by any tooling except Git

CLI.


I'm afraid, but from my point of view, this doesn't match the objective.


The only alternative is to completely lock down the instance, and not
allow new users at all without manual approval of each and every one.

People can just ask to be allowed to fork, but by default, allowing it
is not feasible.


Hm, please help me understand what kind of spam we're talking about here.

I can't imagine somebody would take the effort for selling some pills to ffmpeg
developers. When it's about advertising anything, that's not the kind of reach
those people are typically looking for.


Or is it about misusing repos for storage of illegal content? The largest file

currently is just 953kB, so we could enforce a limit small enough to make it
unattractive for this purpose (unlike GitHub with 100MB per file).


We could also disallow repos with custom content (i.e. only forks of ffmpeg

are allowed as repo content).


Then I wonder, where would be the harm? Some thousand unused forks of

ffmpeg shouldn't be a problem - but maybe I'm overseeing something?

There are all sorts of copyrightable material that can be embedded
into a git repo.


That's why I mentioned that a file size limit could prevent this. With a 2 MB 
limit per file, it becomes totally unattractive for this kind of abuse.


That doesn't seem feasible to implement, given it's git.
Not even sure how to implement such a limit at all with git.
Some hook would need to check every file on push, which I don't think is 
something that readily exists.


And even then, there will be ways around it if someone is motivated enough.


Given that this all amounts to manpower from the operator


AFAIK, you are only responsible to take stuff down once you get notified, you 
don't need to actively look for anything.


I still wouldn't want to be the one hosting who knows what of illegal 
shit on our servers.


Also keep in mind that if they fork the FFmpeg repo, and then push 
something big and bad into that fork, it ends up in the same backing 
storage of git objects.

So it's not even trivial to just delete it again, and bar access to it.

You can ask Videolan about how a fully open Gitlab instance went for them.


Also payloads for malicious software.



Okay, but when it's in a repo, what happens next? I mean why would somebody 
store that in a repo? What would be the goal?

Also, I wonder how this would be different from attachments on https://trac.ffmpeg.org ? 
There's no requirement for user "approval" as well..


We're just relatively lucky that trac is pretty uncommon and spambots 
targetting are more rare.

Also, our custom-baked captcha for trac has so far remained undefeated.

Before it was implemented, trac also had a lot of spambots.



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

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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Donnerstag, 13. Februar 2025 00:34
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 13.02.2025 00:07, Soft Works wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>> default, or is it set to 0 only for those that sign up through one of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >
> > For those who are too lazy to look it up:
> >
> > The "Agit workflow" requires you to use non-standard Git "push-options"
> > (either -o or --push-options):
> >
> > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> >-o title="Title of the PR" \
> >-o description="# The PR Description
> > This can be **any** markdown content.\n
> > - [x] Ok"
> >
> > This means essentially that our attempt to move away from the e-mail-based
> submission procedure to something easy and user-friendly, would end up in
> replacing the current rarely-known mechanism with another even more rare
> and obscure procedure which would (again) force everybody to use the Git
> command line because it's (again) not supported by any tooling except Git CLI.
> >
> > I'm afraid, but from my point of view, this doesn't match the objective.
> 
> The only alternative is to completely lock down the instance, and not
> allow new users at all without manual approval of each and every one.
> 
> People can just ask to be allowed to fork, but by default, allowing it
> is not feasible.

Hm, please help me understand what kind of spam we're talking about here. I 
can't imagine somebody would take the effort for selling some pills to ffmpeg 
developers. When it's about advertising anything, that's not the kind of reach 
those people are typically looking for.

Or is it about misusing repos for storage of illegal content? The largest file 
currently is just 953kB, so we could enforce a limit small enough to make it 
unattractive for this purpose (unlike GitHub with 100MB per file).

We could also disallow repos with custom content (i.e. only forks of ffmpeg are 
allowed as repo content).

Then I wonder, where would be the harm? Some thousand unused forks of ffmpeg 
shouldn't be a problem - but maybe I'm overseeing something?

Thanks
sw



___
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] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 18:17, Soft Works
 a écrit :
>
>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Timo
> > Rothenpieler
> > Sent: Donnerstag, 13. Februar 2025 00:34
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >
> > On 13.02.2025 00:07, Soft Works wrote:
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel  On Behalf Of
> > Timo
> > >> Rothenpieler
> > >> Sent: Mittwoch, 12. Februar 2025 22:33
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> > >>
> > >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > >>> Are all accounts restricted to owning a maximum of 0 repositories by
> > >>> default, or is it set to 0 only for those that sign up through one of
> > >>> the external logins?
> > >>
> > >> It's set to 0 by default, to avoid spammers uploading junk, or just
> > >> people (ab)using it for non-ffmpeg things.
> > >>
> > >> You can open issues and comment on existing PRs.
> > >> And also create PRs using the AGit workflow:
> > >> https://forgejo.org/docs/latest/user/agit-support/
> > >
> > > For those who are too lazy to look it up:
> > >
> > > The "Agit workflow" requires you to use non-standard Git "push-options"
> > > (either -o or --push-options):
> > >
> > > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> > >-o title="Title of the PR" \
> > >-o description="# The PR Description
> > > This can be **any** markdown content.\n
> > > - [x] Ok"
> > >
> > > This means essentially that our attempt to move away from the e-mail-based
> > submission procedure to something easy and user-friendly, would end up in
> > replacing the current rarely-known mechanism with another even more rare
> > and obscure procedure which would (again) force everybody to use the Git
> > command line because it's (again) not supported by any tooling except Git 
> > CLI.
> > >
> > > I'm afraid, but from my point of view, this doesn't match the objective.
> >
> > The only alternative is to completely lock down the instance, and not
> > allow new users at all without manual approval of each and every one.
> >
> > People can just ask to be allowed to fork, but by default, allowing it
> > is not feasible.
>
> Hm, please help me understand what kind of spam we're talking about here. I 
> can't imagine somebody would take the effort for selling some pills to ffmpeg 
> developers. When it's about advertising anything, that's not the kind of 
> reach those people are typically looking for.
>
> Or is it about misusing repos for storage of illegal content? The largest 
> file currently is just 953kB, so we could enforce a limit small enough to 
> make it unattractive for this purpose (unlike GitHub with 100MB per file).
>
> We could also disallow repos with custom content (i.e. only forks of ffmpeg 
> are allowed as repo content).
>
> Then I wonder, where would be the harm? Some thousand unused forks of ffmpeg 
> shouldn't be a problem - but maybe I'm overseeing something?

There are all sorts of copyrightable material that can be embedded
into a git repo.

Also payloads for malicious software.

etc.

Given that this all amounts to manpower from the operator, it's
totally understandable that they would like to be conservative about
opening it up.

-- Romain
___
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] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 00:34, Kieran Kunhya via ffmpeg-devel wrote:

Yes but surely if users do a simple clone of the main repository, they will
get all the branches of hundred of different pull requests?


No, why would they?
That's all abstracted away. Pretty much just an optimization on storage, 
making all forks share the actual git object files.
Which has the side-effect that even on Github you can fork the FFmpeg 
repo, push something, and then link to the hash of what you pushed on 
the actual FFmpeg repo:

https://github.com/FFmpeg/FFmpeg/commit/4904c8861b1b52c50199e83620fbabfad4733a2b


This commit is only on a branch of mine, not on any FFmpeg branch.
Github warns about that these days, but Gitlab/Gitea/Forgejo/... don't 
for what I'm aware.

___
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] [REFUND-REQUEST] FOSDEM '25 Expenses

[Stefano Sabatini]

In date Monday 2025-02-10 17:29:49 +0100, Lynne wrote:
> Hi,
> 
> I am requesting reimbursement for the following expenses made attending
> FOSDEM 2025, where I attended the meeting and discussed development topics
> with fellow developers.
> 
> Eurostar tickets: 178.33 GBP
> Hotel: 97.04 GBP

Looks good to me, pending Michael's ACK.

To generate a refund request, follow the instructions linked here:
https://www.spi-inc.org/treasurer/reimbursement-form/

Then email the refund request to:
treasu...@rt.spi-inc.org

putting me and Michael in CC:, and adding the thread link from:
http://ffmpeg.org/pipermail/ffmpeg-devel/

Thanks.
___
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] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
> 
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
> 
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/

For those who are too lazy to look it up:

The "Agit workflow" requires you to use non-standard Git "push-options"
(either -o or --push-options):

git push origin HEAD:refs/for/master -o topic="topic-branch" \
  -o title="Title of the PR" \
  -o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"

This means essentially that our attempt to move away from the e-mail-based 
submission procedure to something easy and user-friendly, would end up in 
replacing the current rarely-known mechanism with another even more rare and 
obscure procedure which would (again) force everybody to use the Git command 
line because it's (again) not supported by any tooling except Git CLI.

I'm afraid, but from my point of view, this doesn't match the objective.

Best
sw




___
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] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Romain Beauxis
> Sent: Donnerstag, 13. Februar 2025 01:25
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> Le mer. 12 févr. 2025 à 18:17, Soft Works
>  a écrit :
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> Timo
> > > Rothenpieler
> > > Sent: Donnerstag, 13. Februar 2025 00:34
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> > >
> > > On 13.02.2025 00:07, Soft Works wrote:
> > > >
> > > >> -Original Message-
> > > >> From: ffmpeg-devel  On Behalf Of
> > > Timo
> > > >> Rothenpieler
> > > >> Sent: Mittwoch, 12. Februar 2025 22:33
> > > >> To: ffmpeg-devel@ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> > > >>
> > > >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > > >>> Are all accounts restricted to owning a maximum of 0 repositories by
> > > >>> default, or is it set to 0 only for those that sign up through one of
> > > >>> the external logins?
> > > >>
> > > >> It's set to 0 by default, to avoid spammers uploading junk, or just
> > > >> people (ab)using it for non-ffmpeg things.
> > > >>
> > > >> You can open issues and comment on existing PRs.
> > > >> And also create PRs using the AGit workflow:
> > > >> https://forgejo.org/docs/latest/user/agit-support/
> > > >
> > > > For those who are too lazy to look it up:
> > > >
> > > > The "Agit workflow" requires you to use non-standard Git "push-
> options"
> > > > (either -o or --push-options):
> > > >
> > > > git push origin HEAD:refs/for/master -o topic="topic-branch" \
> > > >-o title="Title of the PR" \
> > > >-o description="# The PR Description
> > > > This can be **any** markdown content.\n
> > > > - [x] Ok"
> > > >
> > > > This means essentially that our attempt to move away from the e-mail-
> based
> > > submission procedure to something easy and user-friendly, would end up
> in
> > > replacing the current rarely-known mechanism with another even more
> rare
> > > and obscure procedure which would (again) force everybody to use the Git
> > > command line because it's (again) not supported by any tooling except Git
> CLI.
> > > >
> > > > I'm afraid, but from my point of view, this doesn't match the objective.
> > >
> > > The only alternative is to completely lock down the instance, and not
> > > allow new users at all without manual approval of each and every one.
> > >
> > > People can just ask to be allowed to fork, but by default, allowing it
> > > is not feasible.
> >
> > Hm, please help me understand what kind of spam we're talking about here.
> I can't imagine somebody would take the effort for selling some pills to 
> ffmpeg
> developers. When it's about advertising anything, that's not the kind of reach
> those people are typically looking for.
> >
> > Or is it about misusing repos for storage of illegal content? The largest 
> > file
> currently is just 953kB, so we could enforce a limit small enough to make it
> unattractive for this purpose (unlike GitHub with 100MB per file).
> >
> > We could also disallow repos with custom content (i.e. only forks of ffmpeg
> are allowed as repo content).
> >
> > Then I wonder, where would be the harm? Some thousand unused forks of
> ffmpeg shouldn't be a problem - but maybe I'm overseeing something?
> 
> There are all sorts of copyrightable material that can be embedded
> into a git repo.

That's why I mentioned that a file size limit could prevent this. With a 2 MB 
limit per file, it becomes totally unattractive for this kind of abuse.

> Given that this all amounts to manpower from the operator

AFAIK, you are only responsible to take stuff down once you get notified, you 
don't need to actively look for anything.

> Also payloads for malicious software.

Okay, but when it's in a repo, what happens next? I mean why would somebody 
store that in a repo? What would be the goal?

Also, I wonder how this would be different from attachments on 
https://trac.ffmpeg.org ? There's no requirement for user "approval" as well..

sw
___
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] Experiment: enable github pull requests

[Lynne]

On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


On 12/02/2025 19:06, Michael Niedermayer wrote:

Hi all


Hi!




I propose, that we enable github pull requests

github is the most widely used development platform and has the lowest barrier
of entry.

after ~1-3 Month, we then evaluate how many new developers this attracted,
how many new contributions it attracted.
What the ratios of reviewed vs ignored vs applied vs rejected patches are 
compared to the ML


Those are rather arbitrary statistics.


This information should help the community make decissions about the use of
web based git development vs the mailing list.


Every one of us is already familiar with the benefits of having a platform.
This is just slowing down and delaying what we ought to do, which is to
switch as soon as possible.
Finally, without CI, it doesn't really show the potential.

We all know that github will not be the platform we move to, so instead
of getting used to a temporary workflow, I'd rather we test a likely
final workflow that we could potentially be using.

Instead of github, I want to use the current test Forgejo instance. It
already has CI working and over 10 developers have registered.
Some have doubts about whether it would slow down with more users, or
bugs would appear, and it would be good to demonstrate the platform can
handle our workflow, and fix any remaining issues.

Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal anything.


Sure
https://code.ffmpeg.org/


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Stephen Hutchinson]

On 2/12/25 2:23 PM, Lynne wrote:



On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal anything.


Sure
https://code.ffmpeg.org/



Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?
___
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] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 22:22, Stephen Hutchinson wrote:

On 2/12/25 2:23 PM, Lynne wrote:



On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal anything.


Sure
https://code.ffmpeg.org/



Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just 
people (ab)using it for non-ffmpeg things.


You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/

The repo limit can manually be lifted per user. I preferred that 
approach vs. the Videolan approach of completely locking down the 
instance, and requiring admin approval for every single new user, which 
imo is more detrimental to new contributors than a ML.





Timo
___
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] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > On 2/12/25 2:23 PM, Lynne wrote:
> >>
> >>
> >> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>> Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> 
>  Users can already login to the instance with their github accounts, so
>  there's no barrier to entry.
> >>>
> >>> Would you mind sharing the url? A quick search didn't reveal anything.
> >>
> >> Sure
> >> https://code.ffmpeg.org/
> >>
> >
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
> 
> It's set to 0 by default, to avoid spammers uploading junk, or just
> people (ab)using it for non-ffmpeg things.
> 
> You can open issues and comment on existing PRs.
> And also create PRs using the AGit workflow:
> https://forgejo.org/docs/latest/user/agit-support/
> 
> The repo limit can manually be lifted per user. I preferred that
> approach vs. the Videolan approach of completely locking down the
> instance, and requiring admin approval for every single new user, which
> imo is more detrimental to new contributors than a ML.

Hi Timo,

Does that mean that you cannot create forks and create PRs from that forked 
repo like on GitHub?

sw
___
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 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Michael Niedermayer]

Hi Martin

On Wed, Feb 12, 2025 at 09:52:35PM +0200, Martin Storsjö wrote:
> On Wed, 12 Feb 2025, Michael Niedermayer wrote:
[...]
> > The actual code you wrote is fine and nicely optimizes the swap out
> 
> Thanks, then I'll push it soon. And after some delay, I'd also backport it
> to a couple branches if that's ok; without this, "make fate" hangs on my
> machine.

ok, backporting ok

thx

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

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


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

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

Re: [FFmpeg-devel] GSoC 2025

[Nicolas George]

Marth64 (HE12025-02-12):
> Hi Nicolas,
> 
> I’ll be clear: my decision to funnel the conversation into a more
> isolated (but project-official) channel was based on experience and
> best practices, not guesswork. I have over a decade of real-world
> experience and training managing teams, resolving conflict, and
> guiding projects to success. If you’d like to understand the
> reasoning, I suggest looking into the 5 C’s of Conflict Management,
> which emphasizes the importance of clear communication and
> collaboration in conflict resolution. I did not see that potential in
> a wide-open thread like this.
> 
> In cases of conflict, especially during sensitive moments, it’s a
> well-established leadership practice to reduce surface area and shift
> discussions to a focused group where they can be resolved more
> productively.
> 
> If you have constructive feedback, I’m happy to hear it, but I won’t
> engage in unproductive criticism of the CC’s role.

You neglect that part of the conflict is that the CC itself is not seen
as trustworthy by several members of the project, suspected of bias and
overreach. Your mere presence in it will help, but it is not enough to
make all that go away immediately.

Therefore, my constructive feedback is:

First: do not shroud your activities in secrecy, it feeds the suspicion
on bias.

Second: promptly and public reject and condemn anything that would be
overreach and strictly limit yourself to things directly related to the
code of conduct.

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] [PATCH] avformat/mov: read and write additional iTunes style metadata

[Damiano Galassi]

---
 libavformat/mov.c   | 67 +++-
 libavformat/movenc.c| 69 +++--
 tests/ref/fate/caf-alac-remux   |  5 ++-
 tests/ref/fate/cover-art-flac-remux |  5 ++-
 tests/ref/fate/matroska-alac-remux  |  5 ++-
 tests/ref/fate/mov-cover-image  |  4 +-
 6 files changed, 142 insertions(+), 13 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 85aef33b19..f70a04c37d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -131,6 +131,33 @@ static int mov_metadata_int8_no_padding(MOVContext *c, 
AVIOContext *pb,
 return 0;
 }
 
+static int mov_metadata_int16_no_padding(MOVContext *c, AVIOContext *pb,
+ unsigned len, const char *key)
+{
+c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
+av_dict_set_int(&c->fc->metadata, key, avio_rb16(pb), 0);
+
+return 0;
+}
+
+static int mov_metadata_int32_no_padding(MOVContext *c, AVIOContext *pb,
+ unsigned len, const char *key)
+{
+c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
+av_dict_set_int(&c->fc->metadata, key, avio_rb32(pb), 0);
+
+return 0;
+}
+
+static int mov_metadata_int64_no_padding(MOVContext *c, AVIOContext *pb,
+ unsigned len, const char *key)
+{
+c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
+av_dict_set_int(&c->fc->metadata, key, avio_rb64(pb), 0);
+
+return 0;
+}
+
 static int mov_metadata_gnre(MOVContext *c, AVIOContext *pb,
  unsigned len, const char *key)
 {
@@ -370,7 +397,13 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 case MKTAG( 'a','k','I','D'): key = "account_type";
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'a','p','I','D'): key = "account_id"; break;
+case MKTAG( 'a','t','I','D'): key = "artist_id";
+parse = mov_metadata_int32_no_padding; break;
 case MKTAG( 'c','a','t','g'): key = "category"; break;
+case MKTAG( 'c','m','I','D'): key = "composer_id";
+parse = mov_metadata_int32_no_padding; break;
+case MKTAG( 'c','n','I','D'): key = "content_id";
+parse = mov_metadata_int32_no_padding; break;
 case MKTAG( 'c','p','i','l'): key = "compilation";
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'c','p','r','t'): key = "copyright"; break;
@@ -380,12 +413,16 @@ static int mov_read_udta_string(MOVContext *c, 
AVIOContext *pb, MOVAtom atom)
 case MKTAG( 'e','g','i','d'): key = "episode_uid";
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'F','I','R','M'): key = "firmware"; raw = 1; break;
+case MKTAG( 'g','e','I','D'): key = "genre_id";
+parse = mov_metadata_int32_no_padding; break;
 case MKTAG( 'g','n','r','e'): key = "genre";
 parse = mov_metadata_gnre; break;
 case MKTAG( 'h','d','v','d'): key = "hd_video";
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'H','M','M','T'):
 return mov_metadata_hmmt(c, pb, atom.size);
+case MKTAG( 'i','t','n','u'): key = "itunes_u";
+parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'k','e','y','w'): key = "keywords";  break;
 case MKTAG( 'l','d','e','s'): key = "synopsis";  break;
 case MKTAG( 'l','o','c','i'):
@@ -396,9 +433,16 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 'p','g','a','p'): key = "gapless_playback";
 parse = mov_metadata_int8_no_padding; break;
+case MKTAG( 'p','l','I','D'): key = "playlist_id";
+parse = mov_metadata_int64_no_padding; break;
 case MKTAG( 'p','u','r','d'): key = "purchase_date"; break;
 case MKTAG( 'r','t','n','g'): key = "rating";
 parse = mov_metadata_int8_no_padding; break;
+case MKTAG( 's','f','I','D'): key = "itunes_country";
+parse = mov_metadata_int32_no_padding; break;
+case MKTAG( 's','d','e','s'): key = "series_description"; break;
+case MKTAG( 's','h','w','m'): key = "show_work_and_movement";
+parse = mov_metadata_int8_no_padding; break;
 case MKTAG( 's','o','a','a'): key = "sort_album_artist"; break;
 case MKTAG( 's','o','a','l'): key = "sort_album";   break;
 case MKTAG( 's','o','a','r'): key = "sort_artist";  break;
@@ -407,6 +451,8 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 case MKTAG( 's','o','s','n'): key = "sort_show";break;
 case MKTAG( 's','t','i','k'): key = "media_type";
 parse = mov_metadata_int8_no_padding; break;
+case MKTAG( 't','m','p','o'): key = "tmpo";
+parse = mov_metadata_int16_no_padding; break;
 case MKTAG( 't','r','k','n'): key = "track";
 parse = mov_metadata_track_or_disc_number; break;
 case MKTAG( 't','v','e','n'): key

Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

[Michael Niedermayer]

Hi Martin

On Wed, Feb 12, 2025 at 11:25:03AM +0200, Martin Storsjö wrote:
[...]
> > Heres an example where the SWAP is needed:
> > noswap swap
> > 5 -> [x 5]  [x 5]
> > 4 -> [5 4]  [5 4]
> > 5 -> [5 4]  [4 5]
> > 6 -> [4 6]  [5 6]
> > 5 -> [6 5]  [6 5]
> > 
> > In the last case the 5 is in the old* when the swap was used but not
> > when it was not used
> 
> Sorry, but your examples do not make sense or do not contain enough context
> (it does not include the initial states of the two old values, and it
> requires guesswork which ones of the two [x y] values is old and which one
> is old2).
> 
> But to be clear:
> 
> Please specify the initial values of the variables new, old and old2, for a
> case where
> 
> > > if (old2 == new) {
> > > FFSWAP(old,old2);
> > > } else if (old != new) {
> > > old2 = old;
> > > old = new;
> > > }
> 
> produces a different end result than
> 
> > > if (old != new) {
> > > old2 = old;
> > > old = new;
> > > }
> 
> I claim that for any values of these variables, the end result is the same.

yes, you are correct, i thought you intended to run the old2/old update only if
new differs from both old and old2.

The actual code you wrote is fine and nicely optimizes the swap out

thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 23:01, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:51
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 22:37, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 22:22, Stephen Hutchinson wrote:

On 2/12/25 2:23 PM, Lynne wrote:



On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal anything.


Sure
https://code.ffmpeg.org/



Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/

The repo limit can manually be lifted per user. I preferred that
approach vs. the Videolan approach of completely locking down the
instance, and requiring admin approval for every single new user, which
imo is more detrimental to new contributors than a ML.


Hi Timo,

Does that mean that you cannot create forks and create PRs from that forked

repo like on GitHub?



Not sure what you mean, you need "admin approval" to be allowed to
create repos, including forks.


I don't think it's a good idea to build such entry bars.


Just to avoid abuse. Obviously you can then PR from that fork once you
got one.
Or you can submit PRs without a fork as stated above.


That's a workflow I've never heard about - same like most other contributors. 
Again, that is building an entry bar.

I think people should be able to use a procedure they are familiar with.
Is it possible to create PRs from a fork on GitHub?


I'm really not sure what you're asking.
PRs are not restricted. Creating repos is.
And there is no way to NOT restrict it, unless you want to pay several 
hundred Euros a month in hosting fees extra, and constantly be on the 
lookout for hosting illegal/harmful things.

___
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] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 23:05
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 23:01, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:51
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:37, Soft Works wrote:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
> >> Timo
>  Rothenpieler
>  Sent: Mittwoch, 12. Februar 2025 22:33
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> 
>  On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > On 2/12/25 2:23 PM, Lynne wrote:
> >>
> >>
> >> On 12/02/2025 19:53, Romain Beauxis wrote:
> >>> Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> 
>  Users can already login to the instance with their github accounts, 
>  so
>  there's no barrier to entry.
> >>>
> >>> Would you mind sharing the url? A quick search didn't reveal
> anything.
> >>
> >> Sure
> >> https://code.ffmpeg.org/
> >>
> >
> > Are all accounts restricted to owning a maximum of 0 repositories by
> > default, or is it set to 0 only for those that sign up through one of
> > the external logins?
> 
>  It's set to 0 by default, to avoid spammers uploading junk, or just
>  people (ab)using it for non-ffmpeg things.
> 
>  You can open issues and comment on existing PRs.
>  And also create PRs using the AGit workflow:
>  https://forgejo.org/docs/latest/user/agit-support/
> 
>  The repo limit can manually be lifted per user. I preferred that
>  approach vs. the Videolan approach of completely locking down the
>  instance, and requiring admin approval for every single new user, which
>  imo is more detrimental to new contributors than a ML.
> >>>
> >>> Hi Timo,
> >>>
> >>> Does that mean that you cannot create forks and create PRs from that
> forked
> >> repo like on GitHub?
> >>>
> >> Not sure what you mean, you need "admin approval" to be allowed to
> >> create repos, including forks.
> >
> > I don't think it's a good idea to build such entry bars.
> >
> >> Just to avoid abuse. Obviously you can then PR from that fork once you
> >> got one.
> >> Or you can submit PRs without a fork as stated above.
> >
> > That's a workflow I've never heard about - same like most other
> contributors. Again, that is building an entry bar.
> >
> > I think people should be able to use a procedure they are familiar with.
> > Is it possible to create PRs from a fork on GitHub?
> >
> I'm really not sure what you're asking.
> PRs are not restricted. Creating repos is.
> And there is no way to NOT restrict it, unless you want to pay several
> hundred Euros a month in hosting fees extra, and constantly be on the
> lookout for hosting illegal/harmful things.

I wasn't asking, I'm stating that not being able to use an established workflow 
like 

fork >> clone >> develop >> push >> PR

...would be an entry-bar for new contributors.

But here comes a question: I've read that the "AGit flow" work by creating a 
branch for each submission in the original repo. Doesn't the repo get 
"polluted" over time this way? In case of merged PRs, the branch might get 
deleted, but what about unmerged ones?
And when one clones the whole repo, don't they get all those branches 
downloaded locally as well? (as long as one doesn’t specify which branches to 
download)

Thanks
sw
___
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] Experiment: enable github pull requests

[Lynne]

On 12/02/2025 19:06, Michael Niedermayer wrote:

Hi all

I propose, that we enable github pull requests

github is the most widely used development platform and has the lowest barrier
of entry.

after ~1-3 Month, we then evaluate how many new developers this attracted,
how many new contributions it attracted.
What the ratios of reviewed vs ignored vs applied vs rejected patches are 
compared to the ML


Those are rather arbitrary statistics.


This information should help the community make decissions about the use of
web based git development vs the mailing list.


Every one of us is already familiar with the benefits of having a platform.
This is just slowing down and delaying what we ought to do, which is to 
switch as soon as possible.

Finally, without CI, it doesn't really show the potential.

We all know that github will not be the platform we move to, so instead 
of getting used to a temporary workflow, I'd rather we test a likely 
final workflow that we could potentially be using.


Instead of github, I want to use the current test Forgejo instance. It 
already has CI working and over 10 developers have registered.
Some have doubts about whether it would slow down with more users, or 
bugs would appear, and it would be good to demonstrate the platform can 
handle our workflow, and fix any remaining issues.


Users can already login to the instance with their github accounts, so 
there's no barrier to entry.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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".

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Romain Beauxis]

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
>
> On 12/02/2025 19:06, Michael Niedermayer wrote:
> > Hi all

Hi!

>
> > I propose, that we enable github pull requests
> >
> > github is the most widely used development platform and has the lowest 
> > barrier
> > of entry.
> >
> > after ~1-3 Month, we then evaluate how many new developers this attracted,
> > how many new contributions it attracted.
> > What the ratios of reviewed vs ignored vs applied vs rejected patches are 
> > compared to the ML
>
> Those are rather arbitrary statistics.
>
> > This information should help the community make decissions about the use of
> > web based git development vs the mailing list.
>
> Every one of us is already familiar with the benefits of having a platform.
> This is just slowing down and delaying what we ought to do, which is to
> switch as soon as possible.
> Finally, without CI, it doesn't really show the potential.
>
> We all know that github will not be the platform we move to, so instead
> of getting used to a temporary workflow, I'd rather we test a likely
> final workflow that we could potentially be using.
>
> Instead of github, I want to use the current test Forgejo instance. It
> already has CI working and over 10 developers have registered.
> Some have doubts about whether it would slow down with more users, or
> bugs would appear, and it would be good to demonstrate the platform can
> handle our workflow, and fix any remaining issues.
>
> Users can already login to the instance with their github accounts, so
> there's no barrier to entry.

Would you mind sharing the url? A quick search didn't reveal anything.

Thanks,
-- Romain
___
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] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 22:37, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 22:22, Stephen Hutchinson wrote:

On 2/12/25 2:23 PM, Lynne wrote:



On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal anything.


Sure
https://code.ffmpeg.org/



Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/

The repo limit can manually be lifted per user. I preferred that
approach vs. the Videolan approach of completely locking down the
instance, and requiring admin approval for every single new user, which
imo is more detrimental to new contributors than a ML.


Hi Timo,

Does that mean that you cannot create forks and create PRs from that forked 
repo like on GitHub?

Not sure what you mean, you need "admin approval" to be allowed to 
create repos, including forks.
Just to avoid abuse. Obviously you can then PR from that fork once you 
got one.

Or you can submit PRs without a fork as stated above.
___
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/hevc_mp4toannexb: prepend extradata before the leading PS for an IRAP

[James Almer]

On 2/7/2025 12:21 PM, James Almer wrote:

Parameter sets may be coded in the packet before an IRAP (as is the case for
the hev1 ISO-BMFF brand), and they should have priority as they may override
the extradata ones.
As such, prepend the extradata PS NALUs to the packet PS NALUs if they are
present before an IRAP, instead of prepending them to the IRAP slice.

Should fix ticket #11458.

Signed-off-by: James Almer 
---
  libavcodec/bsf/hevc_mp4toannexb.c | 34 +--
  1 file changed, 32 insertions(+), 2 deletions(-)


Will apply.



OpenPGP_signature.asc
Description: OpenPGP digital 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".

Re: [FFmpeg-devel] [PATCH 3/8] libavformat/flacdec: Export samples md5 as metadata

[Michael Niedermayer]

Hi
On Wed, Feb 12, 2025 at 11:56:16AM +0100, Tomas Härdin wrote:
> tor 2025-02-06 klockan 16:07 +0100 skrev Michael Niedermayer:
> > Hi Tomas
> > 
> > On Wed, Feb 05, 2025 at 03:20:09PM +0100, Tomas Härdin wrote:
[...]
> > > diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> > > index 3c317acaee..9f65c25864 100644
> > > --- a/libavformat/flacdec.c
> > > +++ b/libavformat/flacdec.c
> > > @@ -33,6 +33,7 @@
> > >  #include "replaygain.h"
> > >  
> > >  #define SEEKPOINT_SIZE 18
> > > +#define MD5_BYTE_SIZE 16
> > >  
> > >  typedef struct FLACDecContext {
> > >  FFRawDemuxerContext rawctx;
> > > @@ -109,6 +110,7 @@ static int flac_read_header(AVFormatContext *s)
> > >  if (metadata_type == FLAC_METADATA_TYPE_STREAMINFO) {
> > >  uint32_t samplerate;
> > >  uint64_t samples;
> > > +    char md5hex[MD5_BYTE_SIZE*2+1]; // hex representation
> > > plus null terminator
> > >  
> > >  /* STREAMINFO can only occur once */
> > >  if (found_streaminfo) {
> > > @@ -133,6 +135,10 @@ static int flac_read_header(AVFormatContext
> > > *s)
> > >  if (samples > 0)
> > >  st->duration = samples;
> > >  }
> > > +
> > > +    ff_data_to_hex(md5hex, st->codecpar->extradata+18,
> > > MD5_BYTE_SIZE, 1 /* lowercase */);
> > > +    md5hex[sizeof(md5hex)-1] = '\0';
> > > +    av_dict_set(&s->metadata, "samples_md5", md5hex, 0);
> > 
> > I think "samples_md5" should be documented, so that other decoders
> > can use
> > the same
> > i also see a verify_md5() in hevc
> > and crc seems frequently used in decoders
> 
> Documented where? doc/metadata.texi doesn't seem like the place for it.
> doc/demuxers.texi maybe?

honestly, i didnt think about "where", just that it should be documented
somewhere

thx

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Mittwoch, 12. Februar 2025 22:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> On 12.02.2025 22:37, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> On 2/12/25 2:23 PM, Lynne wrote:
> 
> 
>  On 12/02/2025 19:53, Romain Beauxis wrote:
> > Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> >>
> >> Users can already login to the instance with their github accounts, so
> >> there's no barrier to entry.
> >
> > Would you mind sharing the url? A quick search didn't reveal anything.
> 
>  Sure
>  https://code.ffmpeg.org/
> 
> >>>
> >>> Are all accounts restricted to owning a maximum of 0 repositories by
> >>> default, or is it set to 0 only for those that sign up through one of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >>
> >> The repo limit can manually be lifted per user. I preferred that
> >> approach vs. the Videolan approach of completely locking down the
> >> instance, and requiring admin approval for every single new user, which
> >> imo is more detrimental to new contributors than a ML.
> >
> > Hi Timo,
> >
> > Does that mean that you cannot create forks and create PRs from that forked
> repo like on GitHub?
> >
> Not sure what you mean, you need "admin approval" to be allowed to
> create repos, including forks.

I don't think it's a good idea to build such entry bars. 

> Just to avoid abuse. Obviously you can then PR from that fork once you
> got one.
> Or you can submit PRs without a fork as stated above.

That's a workflow I've never heard about - same like most other contributors. 
Again, that is building an entry bar.

I think people should be able to use a procedure they are familiar with.
Is it possible to create PRs from a fork on GitHub?

Thanks
sw



___
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 8/8] Make mime-type award a bonus probe score

[Michael Niedermayer]

On Wed, Feb 12, 2025 at 12:03:37PM +0100, Tomas Härdin wrote:
> tor 2025-02-06 klockan 15:58 +0100 skrev Michael Niedermayer:
> > Hi Tomas
> > 
> > On Wed, Feb 05, 2025 at 03:24:24PM +0100, Tomas Härdin wrote:
> > > Seems reasonable to me and passes FATE
> > > 
> > > /Tomas
> > 
> > >  avformat.h   |    2 +-
> > >  format.c |    8 
> > >  libopenmpt.c |    2 +-
> > >  3 files changed, 6 insertions(+), 6 deletions(-)
> > > 01f04f79202640330d6be91b0215f92f14d1845a  0008-Make-mime-type-
> > > award-a-bonus-probe-score.patch
> > > From ecc3459990f2871fd907f96fe66362b8fea41bd8 Mon Sep 17 00:00:00
> > > 2001
> > > From: =?UTF-8?q?Peter=20Zeb=C3=BChr?= 
> > > Date: Tue, 21 Nov 2023 14:16:49 +0100
> > > Subject: [PATCH 8/8] Make mime-type award a bonus probe score
> > > 
> > > This changes the default behaviour of ffmpeg where content-type
> > > headers
> > > on an input gives an absolut probe score (of 75) to instead give a
> > > bonus
> > > score (of 30). This gives the probe a better chance to arrive at
> > > the
> > > correct format by (hopefully) giving a large enough bonus to push
> > > edge
> > > cases in the right direction (MPEG-PS vs MP3, I am looking at you)
> > > while
> > > also not adversly punishing clearer cases (raw ADTS marked as
> > > "audio/mpeg" for example).
> > > 
> > > This patch was regression tested against 20 million recent podcast
> > > submissions (after content-type propagation was added to
> > > original-storage), and 50k Juno vodcasts submissions (dito). No
> > > adverse
> > > effects observed (but the bonus may still need tweaking if other
> > > edge
> > > cases are detected in production).
> > > ---
> > >  libavformat/avformat.h   | 2 +-
> > >  libavformat/format.c | 8 
> > >  libavformat/libopenmpt.c | 2 +-
> > >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > what is the score ?
> > a higher score means more likely but how much more ?
> > maybe we should come up with a more formal definition
> > like that score is the number of bits of entropy that where checked
> > or
> > something like that.
> > in such a framework, adding 30 for a mime type match would probably
> > make sense
> > 
> > without such a framework, adding 30 to a abstract score is hard to
> > review
> > beyond that, i dont see anything breaking from this but then i
> > dont think we have real tests for mime types
> 
> We don't really have tests for the probe scores at all, which is a
> problem. Perhaps if we collected some tricky samples we could construct
> a test that demands a certain ordering of probe scores for them? For
> now scores are tested indirectly by the fact that most tests rely on
> correct probing

we have
tools/probetest

probetest [-f ] [ []]


> 
> Also you can't really "formalize" social relations. The reason why
> certain files probe as one thing and not another is down to certain
> workflows that demand such behavior, which also entails some workflows
> being rejected, or at least requiring explicit -f. 

[...]
-- 
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.


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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Timo Rothenpieler]

On 12.02.2025 23:16, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Mittwoch, 12. Februar 2025 23:05
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 23:01, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:51
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 22:37, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of

Timo

Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull

requests


On 12.02.2025 22:22, Stephen Hutchinson wrote:

On 2/12/25 2:23 PM, Lynne wrote:



On 12/02/2025 19:53, Romain Beauxis wrote:

Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :


Users can already login to the instance with their github accounts, so
there's no barrier to entry.


Would you mind sharing the url? A quick search didn't reveal

anything.


Sure
https://code.ffmpeg.org/



Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/

The repo limit can manually be lifted per user. I preferred that
approach vs. the Videolan approach of completely locking down the
instance, and requiring admin approval for every single new user, which
imo is more detrimental to new contributors than a ML.


Hi Timo,

Does that mean that you cannot create forks and create PRs from that

forked

repo like on GitHub?



Not sure what you mean, you need "admin approval" to be allowed to
create repos, including forks.


I don't think it's a good idea to build such entry bars.


Just to avoid abuse. Obviously you can then PR from that fork once you
got one.
Or you can submit PRs without a fork as stated above.


That's a workflow I've never heard about - same like most other

contributors. Again, that is building an entry bar.


I think people should be able to use a procedure they are familiar with.
Is it possible to create PRs from a fork on GitHub?


I'm really not sure what you're asking.
PRs are not restricted. Creating repos is.
And there is no way to NOT restrict it, unless you want to pay several
hundred Euros a month in hosting fees extra, and constantly be on the
lookout for hosting illegal/harmful things.


I wasn't asking, I'm stating that not being able to use an established workflow 
like

fork >> clone >> develop >> push >> PR

...would be an entry-bar for new contributors.

But here comes a question: I've read that the "AGit flow" work by creating a branch for 
each submission in the original repo. Doesn't the repo get "polluted" over time this way? 
In case of merged PRs, the branch might get deleted, but what about unmerged ones?
And when one clones the whole repo, don't they get all those branches 
downloaded locally as well? (as long as one doesn’t specify which branches to 
download)


So do forks, cause they all live in the same underlying repo as well.
Unless a user deltes the repo/branch/PR, stuff pushed there will hang 
around forever.

___
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] Experiment: enable github pull requests

[Timo Rothenpieler]

On 13.02.2025 00:07, Soft Works wrote:



-Original Message-
From: ffmpeg-devel  On Behalf Of Timo
Rothenpieler
Sent: Mittwoch, 12. Februar 2025 22:33
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

On 12.02.2025 22:22, Stephen Hutchinson wrote:

Are all accounts restricted to owning a maximum of 0 repositories by
default, or is it set to 0 only for those that sign up through one of
the external logins?


It's set to 0 by default, to avoid spammers uploading junk, or just
people (ab)using it for non-ffmpeg things.

You can open issues and comment on existing PRs.
And also create PRs using the AGit workflow:
https://forgejo.org/docs/latest/user/agit-support/


For those who are too lazy to look it up:

The "Agit workflow" requires you to use non-standard Git "push-options"
(either -o or --push-options):

git push origin HEAD:refs/for/master -o topic="topic-branch" \
   -o title="Title of the PR" \
   -o description="# The PR Description
This can be **any** markdown content.\n
- [x] Ok"

This means essentially that our attempt to move away from the e-mail-based 
submission procedure to something easy and user-friendly, would end up in 
replacing the current rarely-known mechanism with another even more rare and 
obscure procedure which would (again) force everybody to use the Git command 
line because it's (again) not supported by any tooling except Git CLI.

I'm afraid, but from my point of view, this doesn't match the objective.


The only alternative is to completely lock down the instance, and not 
allow new users at all without manual approval of each and every one.


People can just ask to be allowed to fork, but by default, allowing it 
is not feasible.


Videolan apparently even went away from the current approach on our 
instance, cause there was still too much spam. So they're 
manual-approval-only now.

___
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] Experiment: enable github pull requests

[Kieran Kunhya via ffmpeg-devel]

On Wed, 12 Feb 2025, 23:29 Timo Rothenpieler,  wrote:

> On 12.02.2025 23:16, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 23:05
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> >>
> >> On 12.02.2025 23:01, Soft Works wrote:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
> >> Timo
>  Rothenpieler
>  Sent: Mittwoch, 12. Februar 2025 22:51
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> requests
> 
>  On 12.02.2025 22:37, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
>  Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 22:33
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull
> >> requests
> >>
> >> On 12.02.2025 22:22, Stephen Hutchinson wrote:
> >>> On 2/12/25 2:23 PM, Lynne wrote:
> 
> 
>  On 12/02/2025 19:53, Romain Beauxis wrote:
> > Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> >>
> >> Users can already login to the instance with their github
> accounts, so
> >> there's no barrier to entry.
> >
> > Would you mind sharing the url? A quick search didn't reveal
> >> anything.
> 
>  Sure
>  https://code.ffmpeg.org/
> 
> >>>
> >>> Are all accounts restricted to owning a maximum of 0 repositories
> by
> >>> default, or is it set to 0 only for those that sign up through one
> of
> >>> the external logins?
> >>
> >> It's set to 0 by default, to avoid spammers uploading junk, or just
> >> people (ab)using it for non-ffmpeg things.
> >>
> >> You can open issues and comment on existing PRs.
> >> And also create PRs using the AGit workflow:
> >> https://forgejo.org/docs/latest/user/agit-support/
> >>
> >> The repo limit can manually be lifted per user. I preferred that
> >> approach vs. the Videolan approach of completely locking down the
> >> instance, and requiring admin approval for every single new user,
> which
> >> imo is more detrimental to new contributors than a ML.
> >
> > Hi Timo,
> >
> > Does that mean that you cannot create forks and create PRs from that
> >> forked
>  repo like on GitHub?
> >
>  Not sure what you mean, you need "admin approval" to be allowed to
>  create repos, including forks.
> >>>
> >>> I don't think it's a good idea to build such entry bars.
> >>>
>  Just to avoid abuse. Obviously you can then PR from that fork once you
>  got one.
>  Or you can submit PRs without a fork as stated above.
> >>>
> >>> That's a workflow I've never heard about - same like most other
> >> contributors. Again, that is building an entry bar.
> >>>
> >>> I think people should be able to use a procedure they are familiar
> with.
> >>> Is it possible to create PRs from a fork on GitHub?
> >>>
> >> I'm really not sure what you're asking.
> >> PRs are not restricted. Creating repos is.
> >> And there is no way to NOT restrict it, unless you want to pay several
> >> hundred Euros a month in hosting fees extra, and constantly be on the
> >> lookout for hosting illegal/harmful things.
> >
> > I wasn't asking, I'm stating that not being able to use an established
> workflow like
> >
> > fork >> clone >> develop >> push >> PR
> >
> > ...would be an entry-bar for new contributors.
> >
> > But here comes a question: I've read that the "AGit flow" work by
> creating a branch for each submission in the original repo. Doesn't the
> repo get "polluted" over time this way? In case of merged PRs, the branch
> might get deleted, but what about unmerged ones?
> > And when one clones the whole repo, don't they get all those branches
> downloaded locally as well? (as long as one doesn’t specify which branches
> to download)
>
> So do forks, cause they all live in the same underlying repo as well.
> Unless a user deltes the repo/branch/PR, stuff pushed there will hang
> around forever.
>

Yes but surely if users do a simple clone of the main repository, they will
get all the branches of hundred of different pull requests?

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

Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Romain Beauxis
> Sent: Mittwoch, 12. Februar 2025 23:13
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Experiment: enable github pull requests
> 
> Le mer. 12 févr. 2025 à 15:32, Timo Rothenpieler  a
> écrit :
> >
> > On 12.02.2025 22:22, Stephen Hutchinson wrote:
> > > On 2/12/25 2:23 PM, Lynne wrote:
> > >>
> > >>
> > >> On 12/02/2025 19:53, Romain Beauxis wrote:
> > >>> Le mer. 12 févr. 2025 à 12:49, Lynne  a écrit :
> > 
> >  Users can already login to the instance with their github accounts,
> so
> >  there's no barrier to entry.
> > >>>
> > >>> Would you mind sharing the url? A quick search didn't reveal anything.
> > >>
> > >> Sure
> > >> https://code.ffmpeg.org/
> > >>
> > >
> > > Are all accounts restricted to owning a maximum of 0 repositories by
> > > default, or is it set to 0 only for those that sign up through one of
> > > the external logins?
> >
> > It's set to 0 by default, to avoid spammers uploading junk, or just
> > people (ab)using it for non-ffmpeg things.
> >
> > You can open issues and comment on existing PRs.
> > And also create PRs using the AGit workflow:
> > https://forgejo.org/docs/latest/user/agit-support/
> >
> > The repo limit can manually be lifted per user. I preferred that
> > approach vs. the Videolan approach of completely locking down the
> > instance, and requiring admin approval for every single new user, which
> > imo is more detrimental to new contributors than a ML.
> 
> I totally understand the concern.

Thinking about it, I do not quite understand.

When I had the choice between whether spammers can create their own repos or 
create branches in my original repo (AGit flow), I would surely prefer the 
former.

I hope I didn't misunderstand anything (apologies in that case).

 sw


___
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] avformat/mov: Fix get_eia608_packet c608 caption reformatting

[Pavel Koshevoy]

BTW, the problem is reproducible with "Test for Quicktime 608 CC file.mov"
from https://samples.ffmpeg.org/MPEG2/subcc/

Pavel.
___
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".