Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Davy Durham]

Presently do you not have to create an account on the devel mailing list to
contribute to ffmpeg?

So on the flip side, I (actually) find it just as annoying to have to
create such accounts at every project rather than my having one account at
GitHub (or a relatively few for other hosting sites) and can then
contribute to literally thousands of projects without any friction.

Moreover now being subscribed to that list I get 50 emails a day that I
have to wait through. Just so long as I want to contribute. Sure I can
create rules but it is pretty obnoxious.

As a casual contributor, I much prefer getting notifications about my
occasion contributions.  But one can opt to get notified of everything by
subscribing to the whole project.

On Mon, Apr 29, 2024, 11:44 AM Ondřej Fiala  wrote:

> On Mon Apr 29, 2024 at 8:03 AM CEST, Davy Durham wrote:
> > On 4/19/24 09:50, Niklas Haas wrote:
> > +1 from me too.  Please oh, please oh, /please/ modernize the patch
> > management.  I don't know what the opposition/inability to use github is
> > all about.  But gitlab should be a great improvement on the ML/patchwork
> > situation.
> I can give you my POV as someone who dislikes GitHub-like workflows. I
> have no idea if anyone's gonna read it, but anyway...
>
> To contribute with GitHub/GitLab, I have to create an account. This
> might sound trivial, but I find it really annoying to have to maintain
> an account on a bunch of code hosting platform just to contribute a single
> patch to a bunch of software projects. I guarantee you I wouldn't
> contribute
> to ffmpeg if I had to create an account to do so (though my patch wasn't
> incorporated anyway despite it being like 20 lines, so I guess it wouldn't
> change much).
>
> Another issue which is very important to me is the fact that neither GitHub
> nor GitLab work reliably with various privacy add-ons and browser settings.
> Gitea is the only GitHub-like software that is usable with these, so if you
> really have to use a GitHub-like workflow, please consider that over GitLab
> if you care at all about usability.GitLab is the worst in this respect
> because not a single thing about it works without JavaScript (I mean,
> I can't even read a project's README without it).
>
> I would really suggest you look at SourceHut. It keeps mailing list with
> patches workflow, but all the patches are tracked including whether they
> were incorporated, rejected, someone requested changes, etc. Other than
> that it has many features you find in other code hosting platforms,
> including an issue tracker, CI/CD, an equivalent for GitHub's "wiki"
> and "pages" features, etc. It's more accessible than all the platforms
> I've mentioned above, in particular it seems to work well even in limited
> browsers without JavaScript and the UI is faster (much faster than GitLab).
>
> It also does not require you to have an account to contribute. In fact,
> I don't have an account there either and want to make it clear that I am
> not connected to SourceHut in any way. I just really enjoy the experience
> of contributing like:
>
> $ git format-patch master
> $ git send-email ~username/project-de...@lists.sr.ht
>
> No need to sign up to a mailing list or a code hosting platform, no need
> to create a "fork" and a pull request, ...
>
> >
> > gitlab has a hosted edition for opensource projects
> > <https://about.gitlab.com/solutions/open-source/join/>.   (Or is the
> > opposition to github about trusting someone else to host it in general?)
> >
> > Automated CI/CD pipelines will change your /life/ if you've never used
> > them.  I was once opposed but wouldn't want to do it any other way for
> > any significant project anymore.
> >
> > Inline comments on MRs would be a great improvement for discussions and
> > requests from maintainers, and plus it's much easier to see/drill-into
> > those discussion from the blame view.
> >
> > my two cents
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Davy Durham]

On 4/19/24 09:50, Niklas Haas wrote:

So, rather than all of the above, what I think we should do is contract
somebody to set up, manage, host and maintain a GitLab instance for us.

This would probably be the single most cost effective boost to both
community growth and innovation I can think of, as it will remove
several of the major grievances and barriers to entry with the
ML+pingspam model.

We can use a system like VLC's auto-merge bot, where any MR that has at
least one developer approval, no unresolved issues, and no activity for
N days gets *automatically* merged.

I'm sure that if we try, we can find an interested party willing to fund
this. (Maybe SPI?)


+1 from me too.  Please oh, please oh, /please/ modernize the patch 
management.  I don't know what the opposition/inability to use github is 
all about.  But gitlab should be a great improvement on the ML/patchwork 
situation.


gitlab has a hosted edition for opensource projects 
.   (Or is the 
opposition to github about trusting someone else to host it in general?)


Automated CI/CD pipelines will change your /life/ if you've never used 
them.  I was once opposed but wouldn't want to do it any other way for 
any significant project anymore.


Inline comments on MRs would be a great improvement for discussions and 
requests from maintainers, and plus it's much easier to see/drill-into 
those discussion from the blame view.


my two cents

___
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] Status of Patches

[Davy Durham]

Hi group,

   How does one check on the status of a submitted patch?  I see many 
patches a day go into this list, but I have no idea if/when they have 
been incorporated.


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

[FFmpeg-devel] [PATCH] fftools/ffmpeg: Added ability to set a input burst time before readrate is enforced

[Davy Durham]

Implemented is the -irb  flag (i.e. "initial read burst") that
causes ffmpeg to read the specified number of seconds of input before a
given readrate starts to be enforced.  All inputs have to reach this
point before the readrate is enforced.  The reason for this change is,
in the scenario of live-streaming by transcoding from an pre-recorded or
delayed source to an HLS or DASH webroot, we can more quickly prime the
system of the first few seconds before the real-world read rate is
imposed.  Else, one must wait for an entire segment length before the
data can be fetched from the web server.

Signed-off-by: Davy Durham 
---
 doc/ffmpeg.texi  |  2 ++
 fftools/ffmpeg.c |  3 ++-
 fftools/ffmpeg.h |  2 ++
 fftools/ffmpeg_opt.c | 13 +
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 767df69b7f..16ab1a336f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1633,6 +1633,8 @@ it may cause packet loss.
 It is useful for when flow speed of output packets is important, such 
as live streaming.

 @item -re (@emph{input})
 Read input at native frame rate. This is equivalent to setting 
@code{-readrate 1}.

+@item -irb @var{seconds}
+Set an initial read burst time, in seconds, after which any specified 
readrate will be enforced.

 @item -vsync @var{parameter} (@emph{global})
 @itemx -fps_mode[:@var{stream_specifier}] @var{parameter} 
(@emph{output,per-stream})
 Set video sync method / framerate mode. vsync is applied to all output 
video streams

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..e4697c8772 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3768,6 +3768,7 @@ static int get_input_packet(InputFile *f, AVPacket 
**pkt)
   (f->start_time != AV_NOPTS_VALUE ? 
f->start_time : 0)

  );
 float scale = f->rate_emu ? 1.0 : f->readrate;
+int64_t burst_until = AV_TIME_BASE * f->initial_read_burst;
 for (i = 0; i < f->nb_streams; i++) {
 InputStream *ist = input_streams[f->ist_index + i];
 int64_t stream_ts_offset, pts, now;
@@ -3775,7 +3776,7 @@ static int get_input_packet(InputFile *f, AVPacket 
**pkt)
 stream_ts_offset = FFMAX(ist->first_dts != AV_NOPTS_VALUE 
? ist->first_dts : 0, file_start);

 pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
 now = (av_gettime_relative() - ist->start) * scale + 
stream_ts_offset;

-if (pts > now)
+if (pts - burst_until > now)
 return AVERROR(EAGAIN);
 }
 }
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 391a35cf50..aa079ab3e9 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -116,6 +116,7 @@ typedef struct OptionsContext {
 int loop;
 int rate_emu;
 float readrate;
+double initial_read_burst;
 int accurate_seek;
 int thread_queue_size;
 int input_sync_ref;
@@ -422,6 +423,7 @@ typedef struct InputFile {
 int nb_streams_warn;  /* number of streams that the user was 
warned of */

 int rate_emu;
 float readrate;
+double initial_read_burst;
 int accurate_seek;
  AVPacket *pkt;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 6e18a4a23e..57aa4929fa 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1378,6 +1378,16 @@ static int open_input_file(OptionsContext *o, 
const char *filename)

 f->rate_emu = 0;
 }
 +f->initial_read_burst = o->initial_read_burst ? 
o->initial_read_burst : 0.0;

+if (f->initial_read_burst < 0.0) {
+av_log(NULL, AV_LOG_ERROR, "Option -irb for Input #%d is %0.3f; 
it must be non-negative.\n", nb_input_files, f->initial_read_burst);

+exit_program(1);
+}
+if ((!f->readrate && !f->rate_emu) && f->initial_read_burst) {
+av_log(NULL, AV_LOG_WARNING, "Option -irb ignored since neither 
-readrate nor -re were given\n");

+f->initial_read_burst = 0;
+}
+
 f->pkt = av_packet_alloc();
 if (!f->pkt)
 exit_program(1);
@@ -3734,6 +3744,9 @@ const OptionDef options[] = {
 { "readrate",   HAS_ARG | OPT_FLOAT | OPT_OFFSET |
 OPT_EXPERT | OPT_INPUT,  { 
.off = OFFSET(readrate) },

 "read input at specified rate", "speed" },
+{ "irb",HAS_ARG | OPT_DOUBLE | OPT_OFFSET |
+OPT_EXPERT | OPT_INPUT,  { 
.off = OFFSET(initial_read_burst) },
+"The initial amount of input to burst read before imposing any 
readrate", "seconds" },
 { "target", HAS_ARG | OPT_PERFILE | OPT_OUTPUT,  { 
.func_arg = opt_target },
 "specify target file type (\"vcd\", \"

[FFmpeg-devel] [PATCH] dash metadata: Added other supported fields besides title only

[Davy Durham]

Now metadata fields for source, copyright, lang and moreInformationURL 
are supported too.  Evidence for the need of such support: 
https://docs.rs/dash-mpd/0.6.3/dash_mpd/struct.ProgramInformation.html 
and 
https://github.com/DroidFreak32/myjio_unrestrict/blob/805a8b48d02c5618608bf6fb2bfc2b450f1f057a/smali_classes2/com/google/android/exoplayer2/source/dash/manifest/ProgramInformation.smali#L19


Signed-off-by: Davy Durham 
---
 libavformat/dashenc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 295b01e225..e45eca3468 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1141,6 +1141,10 @@ static int write_manifest(AVFormatContext *s, int 
final)

 int use_rename = proto && !strcmp(proto, "file");
 static unsigned int warned_non_file = 0;
 AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
+AVDictionaryEntry *source = av_dict_get(s->metadata, "source", 
NULL, 0);
+AVDictionaryEntry *copyright = av_dict_get(s->metadata, 
"copyright", NULL, 0);

+AVDictionaryEntry *lang = av_dict_get(s->metadata, "lang", NULL, 0);
+AVDictionaryEntry *moreInformationURL = av_dict_get(s->metadata, 
"moreInformationURL", NULL, 0);

 AVDictionary *opts = NULL;
  if (!use_rename && !warned_non_file++)
@@ -1203,6 +1207,26 @@ static int write_manifest(AVFormatContext *s, int 
final)

 avio_printf(out, "\t\t%s\n", escaped);
 av_free(escaped);
 }
+if (source) {
+char *escaped = xmlescape(source->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (copyright) {
+char *escaped = xmlescape(copyright->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (lang) {
+char *escaped = xmlescape(lang->value);
+avio_printf(out, "\t\t%s\n", escaped);
+av_free(escaped);
+}
+if (moreInformationURL) {
+char *escaped = xmlescape(moreInformationURL->value);
+avio_printf(out, 
"\t\t%s\n", escaped);

+av_free(escaped);
+}
 avio_printf(out, "\t\n");
  avio_printf(out, "\t\n");
--
2.25.1

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

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