Re: [FFmpeg-devel] [BROKEN] apad causes infinite hang
Paul B Mahol (12024-06-17): > And once you close all buffersinks the EOF will and must propagate backward > to all not-closed filters and their in/out pads. Your analysis here is right, obviously. Closing a source for this bug makes no sense. 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] [RFC] 5 year plan & Inovation
Michael Niedermayer (12024-06-17): > also if you look at google trends, even today more people search for ffserver > than txproto. In fact at every point in time more people searched for ffserver > than txproto. > > https://trends.google.com/trends/explore?date=all&q=txproto,ffserver > > So even though ffserver is dead, removed and unmaintained, it has more > users > > And this comes back to what i said many times. We should use the name > FFmpeg, our domain and NOT push every bit of new inovation out into > sub projects. > > We should put a newly developed ffserver into the main ffmpeg git. > We should put wasm build support into the main ffmpeg git. > We should turn ffplay into a fully competetive player. > ... Hear! Hear! I would add, as general guiding principles: We should provide both low- and high-level APIs. Ideally, the fftools should be just user interface around the high-level APIs provided by the libraries. 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 3/3] avfilter/formats: Avoid reallocations for video in ff_all_formats()
Andreas Rheinhardt (12021-09-26): > Up until now, the list of pixfmts is reallocated every time an entry > is added to it; there are currently 196 pixel formats, so this matters: > It causes 5541704 calls to av_realloc_array() in a typical FATE run, > which is the majority for said function (8095768 calls) and even > a large chunk of the calls to av_realloc() itself (12589508 calls). > > Fix this by using ff_formats_pixdesc_filter() instead. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) All three look good to me, but I have not looked that carefully at each individual change in the second patch. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/frames: Ensure frames are writable when processing in-place
Soft Works (12021-09-27): > With the introduction of subtitle filtering, subsequent video frames > which are sharing the same data won't be as rare as this happened > to occur yet. > Ensuring per-frame uniqueness when data is modified is not only important > to avoid issues in the future, but a common API requirement anyway. > > Signed-off-by: softworkz > --- NAK, redundant. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/avfilter: Make ff_tlog_ref() static
Andreas Rheinhardt (12021-10-02): > It allows compilers to inline the one and only call to this function > in its callers or even to optimize it away completely (this function > is empty in case TRACE is not defined). > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/avfilter.c | 4 ++-- > libavfilter/internal.h | 2 -- > 2 files changed, 2 insertions(+), 4 deletions(-) LGTM to both. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 003/218] avfilter/formats: Add function to create AVFilterFormats with one entry
Andreas Rheinhardt (12021-09-30): > Most instances ff_add_formats() actually only ever add one format; > this function can be used to simplify those callers. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/formats.c | 6 ++ > libavfilter/formats.h | 6 ++ > 2 files changed, 12 insertions(+) Even if there is only one, it is still a formats list, and the name of the function should reflect it; "make_format", singular, is not clear. ff_make_formats_list_single() maybe? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 004/218] avfilter: Replace query_formats callback with union of list and callback
Andreas Rheinhardt (12021-09-30): > If one looks at the many query_formats callbacks in existence, > one will immediately recognize that there is one type of default > callback for video and a slightly different default callback for > audio: It is "return ff_set_common_formats_from_list(ctx, pix_fmts);" > for video with a filter-specific pix_fmts list. For audio, it is > the same with a filter-specific sample_fmts list together with > ff_set_common_all_samplerates() and ff_set_common_all_channel_counts(). > > This commit allows to remove the boilerplate query_formats callbacks > by replacing said callback with a union consisting the old callback > and pointers for pixel and sample format arrays. For the not uncommon > case in which these lists only contain a single entry (besides the > sentinel) enum AVPixelFormat and enum AVSampleFormat fields are also > added to the union to store them directly in the AVFilter, > thereby avoiding a relocation. > > The state of said union will be contained in a new, dedicated AVFilter > field (the nb_inputs and nb_outputs fields have been shrunk to uint8_t > in order to create a hole for this new field; this is no problem, as > the maximum of all the nb_inputs is four; for nb_outputs it is only > two). > > The state's default value coincides with the earlier default of > query_formats being unset, namely that the filter accepts all formats > (and also sample rates and channel counts/layouts for audio) > provided that these properties agree coincide for all inputs and > outputs. > > By using different union members for audio and video filters > the type-unsafety of using the same functions for audio and video > lists will furthermore be more confined to formats.c than before. > > When the new fields are used, they will also avoid allocations: > Currently something nearly equivalent to ff_default_query_formats() > is called after every successful call to a query_formats callback; > yet in the common case that the newly allocated AVFilterFormats > are not used at all (namely if there are no free links) these newly > allocated AVFilterFormats are freed again without ever being used. > Filters no longer using the callback will not exhibit this any more. > > Signed-off-by: Andreas Rheinhardt > --- > This patchset here aims to remove boilerplate code from the > query-formats API. Despite touching lots of filters, there should be > only very few conflicts (if at all) with Nicolas' earlier patch [1]. > The reason for this is that the filters touched here typically only > use ff_set_common_* functions, which are unaffected by his change. I do not like the aesthetics of this very much, but it is a useful change. I have not looked at each individual filter change, but they are straightforward. So ok for my part. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/avfilter: Add AVFILTER_FLAG_SUPPORT_COMMANDS
Andreas Rheinhardt (12021-10-09): > Currently an API user has no easy way that always works to know > whether an AVFilter supports commands. One can check for whether > the filter has any AVOption with AV_OPT_FLAG_RUNTIME_PARAM set, > but this is a bit of extra work and more importantly it doesn't > work for all filters: anequalizer, ladspa, drawtext, overlay, pp, > concat and (a)movie accept commands, but have no AVOptions of this > type. Tellingly ffprobe/cmdutils.c has to abuse the API and check > for AVFilter.process_command to know whether a filter accepts commands. > > This commit fixes this by adding a new AVFilter flag. I do not like it: it requires redundant changes in all the filters. It would be more elegant to add avfilter_can_process_commands() that can check for the process_command callback. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/avfilter: Add AVFILTER_FLAG_SUPPORT_COMMANDS
Andreas Rheinhardt (12021-10-09): > Quite a lot of these process_command callbacks are actually quite > boilerplate; lots of them are just ff_filter_process_command(). I > actually intended to factor out this common part in a subsequent patch: > https://github.com/mkver/FFmpeg/commits/process_command This would make > the flag non-redundant, because then quite a lot of filters supporting > commands would no longer have a process_command callback at all. If they are just ff_filter_process_command(), then the best course of action is to just make them ff_filter_process_command(), directly in the callback. No flag required. > And adding a getter for something that is essentially a flag is IMO very > inelegant. Maintaining an information manually when it can be derived from a more authoritative source is worse. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit application when decoding returns AVERROR_EXIT
Soft Works (12021-10-18): > Introduce a way for decoders to request application exit via error return > > Signed-off-by: softworkz > --- > fftools/ffmpeg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 9d4f9d7a2b..dbbe670a0a 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2727,7 +2727,7 @@ static int process_input_packet(InputStream *ist, const > AVPacket *pkt, int no_eo > av_log(NULL, AV_LOG_FATAL, "Error while processing the > decoded " > "data for stream #%d:%d\n", ist->file_index, > ist->st->index); > } > -if (!decode_failed || exit_on_error) > +if (!decode_failed || exit_on_error || ret == AVERROR_EXIT) > exit_program(1); > break; > } On top of everything else that has been said about it, this is not the semantic of AVERROR_EXIT, which is meant for communication within a library. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add option to end filtering on first EOF in filter sink
Paul B Mahol (12021-10-31): > Signed-off-by: Paul B Mahol > --- > fftools/ffmpeg.h| 1 + > fftools/ffmpeg_filter.c | 1 + > fftools/ffmpeg_opt.c| 3 +++ > libavfilter/avfilter.h | 1 + > libavfilter/avfiltergraph.c | 7 +-- > 5 files changed, 11 insertions(+), 2 deletions(-) No objection for the lavfi part, but please split into two commits. I do not maintain the fftools part. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/concatdec: fix NEEDS_UNSAFE flag value
Googleplex (12021-11-12): > NEEDS_UNSAFE has the same value as NEEDS_FILE, > causing "duration not allowed if safe" error > while duration directive doesn't require unsafe mode. > > Signed-off-by: Googleplex > --- > libavformat/concatdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Good catch, thanks. Applied. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v15 00/16] *** SUBJECT HERE ***
James Almer (12021-11-25): > Have all the concerns people had been addressed? I'm also certain the > design itself wasn't well received. Indeed. The whole libavfilter part is nowhere near anything acceptable. It should not be applied at all. 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 v15 01/16] global: Prepare AVFrame for subtitle handling
Andreas Rheinhardt (12021-11-27): > I actually > had one more patchset that breaks the avpriv-ABI (i.e. it would not > force user apps linking to our libs to be rebuilt; rebuilding the ffmpeg > libs is enough). Will see how that fares. We should lock the library versions together so that we do not have to worry about the internal ABI. This is a problem we force on ourselves that brings very little benefit, probably benefit nobody actually cares about. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v15 01/16] global: Prepare AVFrame for subtitle handling
Anton Khirnov (12021-11-27): > > We should lock the library versions together so that we do not have to > > worry about the internal ABI. This is a problem we force on ourselves > > that brings very little benefit, probably benefit nobody actually cares > > about. > I disagree, as I'm sure you know. I wish you stopped bringing this up in > unrelated discussions all the time. I know, this is one of the reasons I have not bothered writing patches for that. The other reason is that the ambience on this mailing list is so toxic I find it emotionally draining to even consider working on FFmpeg; I had hoped that having committees would help, but it did not happen. But I would like to point that I have yet to see you see practical arguments against it. For now, the only arguments I have seen hinted more at a misunderstanding on how linking works, but the people defending them have refused to discuss. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] all: Use av_memdup() where appropriate
Andreas Rheinhardt (12021-11-27): > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/decode.c | 4 +--- > libavcodec/dvbsubdec.c | 8 ++-- > libavcodec/g723_1enc.c | 3 +-- > libavformat/hdsenc.c | 6 ++ > libavformat/mpegts.c | 3 +-- > libavformat/oggparsevorbis.c | 3 +-- > libavformat/rtsp.c | 3 +-- > libavutil/bprint.c | 6 ++ > 8 files changed, 11 insertions(+), 25 deletions(-) Ok for the bprint part. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avfilter: add AVFILTER_FLAG_META
Anton Khirnov (12021-11-24): > Maybe. I named it FLAG_METADATA first, but then started wondering > whether people wouldn't associate it with just AVFrame.metadata rather > than all other 'meta' fields. > More opinions on this (and also the exact definition of this flag) > welcome. I usually name these filters "utility filters". Note that there are also "information filters" that modify neither the frame data nor the metadata and just extract and prints information. (We still need a framework to let users reliably extract that information, just printing in the log is not sustainable, and neither is each filter inventing it own solution. But that would require an unified efficient string API.) Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avdevice/lavfi: Properly free an AVDictionary
Andreas Rheinhardt (12021-12-02): > It is not documented that freeing the last (and only) entry of > an AVDictionary frees the dictionary. > > Signed-off-by: Andreas Rheinhardt > --- > libavdevice/lavfi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Ok to the whole series. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
James Almer (12023-10-10): > The email was sent from ffc...@gmx.de, a domain that some email providers > apparently dislike? Google at least is fine with it. I do not know if I am on the voting list, but I can attest that no mail with that origin address reached the MX for my address. 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] [RFC] A file format to store generic raw image/video files
Chema Gonzalez via ffmpeg-devel (12023-10-17): > # RFC: A file format to store generic raw image/video files > > Context: Developers and researchers often want to use raw image/video > files, as they avoid the effects of encoding. Dealing with raw Looks like a XY problem. > We propose a new raw image/video format, R4M, that extends Y4M to support: Please explain why you think storing raw video or any other lossless codec into a standard container format like Matroska or Nut does not satisfy your needs. > * (a) every `pix_fmt` that ffmpeg supports. The implementation would > support generic AVPixFmtDescriptor's, so any new pixel format based on > it will be automatically supported. This includes > planar/packed/semiplanar, yuv/rgb/bayer, and others. This does not make any sense. Please mediate on the fundamental difference between in-memory representations and permanent storage representations. PS: do not Cc me. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avfilter/drawutils: simplify xyz format check
Niklas Haas (12023-10-26): > From: Niklas Haas > > --- > libavfilter/drawutils.c | 3 --- > 1 file changed, 3 deletions(-) Please merge this with patch 1. 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 3/5] avfilter/drawutils: simplify xyz format check
James Almer (12023-10-26): > This patch reverts patch 1, so merging is basically just dropping both. > I assume the reason he did things this way is to prevent patch 2 (an avutil > patch adding new API) from changing the output filter-pixfmts-pad. Oh, I read the commit message while your read the actual patch. Niklas: patch 3 is incorrect, please fix it and drop patch 1. 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Subject: [PATCH 1/2] avfilter/buffersrc: switch to activate > > Signed-off-by: Paul B Mahol > --- > libavfilter/buffersrc.c | 25 - > 1 file changed, 16 insertions(+), 9 deletions(-) What would be the benefit? > if (s->eof) > -return AVERROR(EINVAL); > +return AVERROR_EOF; > AVERROR_EOF does not have a semantic for writing, only for reading, so no. 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Both patches are required to fix out of memory scenario with this use case: Then please attach an analysis of the fix in the commit messages. Bugs that just disappear when you rework the code completely are not fixed. 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > As OOM scenarios are bad, will apply this fix soon. This bug, if it is a bug, has been here for quite some time already, a few days more will not change anything. I want to analyze this properly, do not push before please. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-10-28): > It was just that jb told me > "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-28): > I did proper analysis already. Pushed. Thanks for the precedent, I will gladly do the same to you in the future. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > > Unsubstantiated opinion, let us ignore it. > Again, a personal attack, from you. YOU are not an OPINION, so, no, this is not a personal attack, this is a lie. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Because instead of doing the polite and normal thing which would be: Politeness or not does not make it a personal attack. Moving goalposts much? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Being not polite to someone is a personal attack. No. -- 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] [RFC] financial sustainability Plan A (SPI)
Rémi Denis-Courmont (12023-10-29): > And unfortunately, I do believe that Ronald is correct in pointing out > that big companies will want oversight in exchange for money. And this is why the only acceptable answer is: to hell with them and anybody who supports them. That might make less money in donations and that more of us will have to keep a day job, but it is the price of freedom. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > We'll have to agree to disagree. So you disagree that ffmpeg is not a corporate project where developers can be forced to have fixed work hours. Interesting. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > IRC has logs That are good to know what has been said, not for participating in the decision making. Therefore IRC is unacceptable for making decisions. > and many people having fixed work hours are on IRC. The problem is the people who cannot be. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Ronald S. Bultje (12023-10-29): > *You* may well end up not accepting their offered help, and that's your > call to make. But if others in our community end up accepting their offered > help, there's nothing you can do against it. Other in the community are free to do as they choose on their own, of course. But the project itself should never accept obligations to a corporate entity. Never. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Rémi Denis-Courmont (12023-10-29): > Be careful what you wish for. Michael started this thread, so I suppose that > he wants funding for himself and/or for some other key developers. They are It would be hypocritical of me to take this into considerations. Corporate sponsorships with strings attached are dangerous and should be refused, whoever they are offered to. > who you are opposing here, rather than bottom feeders such as myself. Please refrain from insinuating that I have insulted you like that. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/hls: use av_strlcopy instead of strncpy
Leo Izen (12023-10-29): > But it will be nul-terminated in either case, so > there's no real difference between the old and new code, other than the > warning. No real difference = you are not fixing the bug. There should be a difference: user data should not be silently truncated. 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] avformat/hls: use av_strlcopy instead of strncpy
Leo Izen (12023-10-30): > > difference: user data should not be silently truncated. > There isn't really a bug here, just an extraneous compiler warning. Truncating user data silently is a bug. The warning is right and needs proper fix. 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] avformat/hls: use av_strlcopy instead of strncpy
Leo Izen (12023-10-30): > Also, fwiw, info->assoc_language is the name of a language. It shouldn't > actually ever be 63 characters long for real streams in the wild, and > truncating it is just a memory-safety precaution. It's not a bug. It SHOULD not, but it CAN be, and properly reporting the error to the user is important. It is just about adding an if and return error. 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Both patches are required to fix out of memory scenario with this use case: I checked. The OOM still happens with these two patches => they do not fix the issue => rejected. > This was a test. That you failed. Are you sure you are mature enough to go on the Internet unsupervised? -- 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] avfillter/buffersrc: activate and EOF fix
Jan Ekström (12023-11-01): > So my question is: Does this test case not improve for you after you > have applied these patches? Or are you speaking of a separate problem > which is bad both in master as well as after these patches have been > applied? This is the test case Paul posted yesterday (except you had the politeness to de-script it) and I used to see that it does not fix the issue. Anyway, except in the simplest of cases, if a change does not include an analysis of why the problem happens and how the change prevents it from happening the simplest way, then it is not a bug fix, it is just dumb luck. And most likely, the bug is not really gone, it just shifted to not be triggered by the test case. There is no such analysis in Paul's patches. If he can submit such an analysis these patches can move forward. But based on my knowledge of the activate code (I wrote it…) I am pretty certain this kind of bug does not need a source with a single output to be switched to activate. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-31): > Huh? I fixed this, and you need to give proof that this does not fixes it. It is you wou have to prove that your patches fix anything or are in any way useful. > Because You can be mistaken and/or evil and simply lie. Seriously, get a grip. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
57c9a833f00] Terminating decoder thread [out#0/mp4 @ 0x557c9b07e000] All streams finished [out#0/mp4 @ 0x557c9b07e000] Terminating muxer thread [AVIOContext @ 0x557c9b0c] Statistics: 83790919 bytes written, 2 seeks, 323 writeouts [out#0/mp4 @ 0x557c9b07e000] Output file #0 (../test_clip.mp4_copy.mp4): [out#0/mp4 @ 0x557c9b07e000] Output stream #0:0 (video): 10511 packets muxed (83686326 bytes); [out#0/mp4 @ 0x557c9b07e000] Total: 10511 packets (83686326 bytes) muxed [out#0/mp4 @ 0x557c9b07e000] video:81725kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.124977% [out#1/image2 @ 0x557c9b0c1640] Nothing was written into output file, because at least one of its streams received no packets. frame=0 fps=0.0 q=0.0 Lsize= 81827kB time=00:07:00.32 bitrate=1594.8kbits/s dup=10500 drop=0 speed= 142x [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x557c9a7e72c0] Terminating demuxer thread [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x557c9a7e72c0] Input file #0 (../test_clip.mp4): [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x557c9a7e72c0] Input stream #0:0 (video): 10513 packets read (83701450 bytes); 10511 frames decoded; 0 decode errors; [in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x557c9a7e72c0] Total: 10513 packets (83701450 bytes) demuxed [AVIOContext @ 0x557c9a7e5d40] Statistics: 83871773 bytes read, 2 seeks Conversion failed! -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
James Almer (12023-11-01): > Can you be more specific? Do you not see the result Jan described? Do you > see something different? Or is it that you do see what he described, but > it's not a proper fix in your opinion as Paul's patch simply prevents the > leak from being triggered in his specific testcase? I posted my console output in the last mail. And even if it did make the bug go away, such an important change is not acceptable without the proof that it is necessary in the commit message. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-11-02): > You applied both patches? At correct order? Duh. > I probably should merge patches into single one. You need to analyze the bug and produce a proof that it is correct. A change to activate is not acceptable without a proof that it is necessary. The proof should be detailed and in the commit message. -- 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-11-02): > I analyzed it already, It is very sorry state of libavfilter that buffersrc > keeps sending frames to EOF filtergraph. So, Paul, I will explain this to you one last time. Remember high school, when you had math test, and if you just gave the result you got almost no points even if the result was correct? That was because solving a math exercise is not just about finding the result, it is about showing how you reach the result and proving that the result is correct. The same goes here. On your own projects, you can change randomly the code until a bug is no longer triggered and call it fixed. But in FFmpeg, you are not alone, and when a change is not trivial you have to prove to your fellow developers that it is correct and necessary. So get to work, produce that proof, re-submit the patch with the proof in the commit message, and then we can talk. As it is, the need to switch buffersrc to activate is not established, and therefore it should not be done. -- 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] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-11-02): > I do not understand. What proof you need? That the patch is correct and necessary. First, explain how the current triggers the problem. In the commit message. -- 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 1/1] tools/general_assembly.pl - print names with emails
Cosmin Stejerean via ffmpeg-devel (12023-11-03):
> Update GA script to print names in addition to emails since emails
> should not be shared in all contexts, this makes it easier to publish
> the current GA membership.
>
> Signed-off-by: Cosmin Stejerean
> ---
> tools/general_assembly.pl | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
> index 898a6262ef..aa467ba34a 100644
> --- a/tools/general_assembly.pl
> +++ b/tools/general_assembly.pl
> @@ -7,6 +7,8 @@ use POSIX qw(strftime);
> use Encode qw(decode);
> use Data::Dumper;
>
> +binmode(STDOUT, ":utf8");
> +
> sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
>
> my @shortlog = split /\n/, decode('UTF-8', `git log --pretty=format:"%aN
> <%aE>" --since="last 36 months" | sort | uniq -c | sort -r`,
> Encode::FB_CROAK);
> @@ -35,6 +37,7 @@ foreach my $line (@shortlog) {
> }
>
> printf("# %s %s", strftime("%Y-%m-%d", localtime), decode('UTF-8', `git
> rev-parse HEAD`, Encode::FB_CROAK));
> -foreach my $email (sort values %assembly) {
> -printf("%s\n", $email);
> +foreach my $name (sort keys %assembly) {
This is also changing the sort order. It might be acceptable but it
might also not be.
> +my $email = $assembly{$name};
> +printf("%s <%s>\n", $name, $email);
> }
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Tristan Matthews (12023-11-02): > Just to confirm that I can reproduce JEEB's test, before the patches: Just to be clear: I never doubted that Paul's patches do make the bug go away in your test case. That would imply accusing Paul of lying about simple technical facts, that would be both stupid and uncivil. What you need to understand is that is barely relevant: “I churned the code a lot and now the bug does not happen in my test case” is not an acceptable way of leading development. What Paul needs to provide (or you, or anybody else; no idea who “JEEB” is) is a proof that the changes are both correct and necessary. Correct: you need to prove that this bug is fixed in all cases, not just the one you were testing on. Necessary: you need to establish that the bug cannot be fixed with fewer changes, because each change is chance for introducing a new bug. Such a proof would certainly start with with an analysis of how the bug gets triggered by the current code. The “necessary” point is especially important: it is a well-established principle that filters with no more than one input and one output do not need to use the activate framework directly (and therefore should not, as it makes the code more complex). If Paul thinks he found an exception to that well-established law, he needs to present strong evidence. But if no such exception exist (which is the most likely: the law is true), then it is entirely possible that what Paul found is a bug in the code that implements the activate mechanism for simple filters. And in that case, we need to fix that bug. Or maybe the actual problem is somewhere in the fftools an error check is skipped. We need to know what is happening before any fix can be devised. We need an analysis of the bug. Any effort going into this that is not first analyzing what is going on is a waste of time. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avfilter/buffersink: cuddle () closer around =
Michael Niedermayer (12023-11-03): > Signed-off-by: Michael Niedermayer > --- > libavfilter/buffersink.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patches 1 and 2 look good to me. Good catch. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
Anton Khirnov (12023-11-04): > It only seems to produce duplicate frames. Yes it does, that is the point of it. Without the duplicated frame, a filter with synchronized inputs (like overlay) will accumulate video frames while waiting for the next sub2video frame. It is actually super easy to test: any file with both video and bitmap subtitles will cause a huge memory consumption if there is a long enough time without subtitles. Since I am feeling super helpful, here is how I just tested: ./ffmpeg_g -lavfi testsrc2=s=720x480:d=150 -preset ultrafast -y /tmp/dummy.mkv mkvmerge -o /tmp/dummy_with_sub.mkv /tmp/dummy.mkv $ffmpeg_fate/sub/vobsub.idx limit addressspace 2G ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi '[0:v][0:s]overlay' -y /tmp/dummy_with_hardsub.mkv mplayer /tmp/dummy_with_hardsub.mkv -ss 2:05 The limit addressspace 2G is there so that the huge memory consumption will hit something. Another way is to log the number of queued frames: --- a/libavfilter/framequeue.c +++ b/libavfilter/framequeue.c @@ -90,2 +90,3 @@ int ff_framequeue_add(FFFrameQueue *fq, AVFrame *frame) fq->queued++; +av_log(0, 16, "queued = %zd\n", fq->queued); fq->total_frames_head++; ffmpeg version N-112710-g86e0dea620 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13 (Debian 13.2.0-5) configuration: --enable-shared --disable-static --enable-gpl --enable-libx264 --enable-libopus --enable-libass --enable-libfreetype --enable-opengl --assert-level=2 libavutil 58. 31.100 / 58. 31.100 libavcodec 60. 32.102 / 60. 32.102 libavformat60. 17.100 / 60. 17.100 libavdevice60. 4.100 / 60. 4.100 libavfilter 9. 13.100 / 9. 13.100 libswscale 7. 6.100 / 7. 6.100 libswresample 4. 13.100 / 4. 13.100 libpostproc57. 4.100 / 57. 4.100 Input #0, matroska,webm, from '/tmp/dummy_with_sub.mkv': […] queued = 2210 queued = 2211 queued = 2212 queued = 2213 [h264 @ 0x562874ac4f40] get_buffer() failed [h264 @ 0x562874ac4f40] thread_get_buffer() failed [h264 @ 0x562874ac4f40] decode_slice_header error [h264 @ 0x562874ac4f40] no frame! […] -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-11-03): > Also I think that forward and/or backward EOF direction status checking is > not correctly handled at all for any filters not using .activate(), and I'm > not aware that it was ever working correctly in all cases. Could you not start with that?!? If you are right, that means there is a bug in the framework code. Then the patch forward is to fix that bug, not needlessly single every simple filter to activate. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-04): > From 31a6a78ebc3a3f8785ec7c8e5ffd4257c7eadec3 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Fri, 27 Oct 2023 14:26:50 +0200 > Subject: [PATCH] avfilter/buffersrc: switch to activate > > Fixes error when caller keeps adding frames into filtergraph > that reached EOF by other means, for example EOF is signalled > by other filter in filtergraph or by buffersink. Filters with no more than one input and one output do not need to implement activate. If it seems they need, that indicates a bug in the framework. Then that bug needs to be found and fixed. This patch just adds code to work around it, it is not acceptable. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-06): > Gonna apply soon. No you are not. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > Nicolas, have you thought of providing a patch to the bug Paul is > describing? Why do you not ask Paul if he have thought of giving me time to have a chance to do so? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > You gave no indication you were willing to, and I thought he gave you time Bullshit. Please do not intervene in a thread when you do not know what is going on at all. Paul has been repeatedly rude and threatened to push before review, yet it is towards me you address your criticism. > on the other thread for a related bug and you used it for mind games. > Anyway, usually code trumps words, so the course I'd suggest is agreeing on > a feasible time window, and if you can get a better patch out, then submit > it, otherwise Paul's can go in. No. I will review this issue when I have the time and Paul will wait. This is how it works. Invalid patches do not go in just because the maintainer is busy or sick. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > world, please make a minimum of effort to keep communication polite Please realize that politeness resides not only in which words we use, like “bullshit”, but also in what we say, even if it is with very mild words. For example: > while you insisted it wasn't there Pretending I said something when I said precisely the opposite is extremely rude from you. Or: > That is not how it works, you cannot indefinitely veto a patch Pretending that I try to veto a patch when I am just demanding the time to properly review it is extremely rude from you. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > Nice try but pointing out your logical fallacies is not being rude, but > rather is just showing you how easily your message can be misinterpreted, You have done nothing of the sort. You have just misrepresented my words, showing that you decided to barge into a conversation without knowing its details. > And yes, asking for time when you yourself do not provide a > timeline is equivalent to vetoing a patch (indefinitely too, since you > yourself say you "will review this issue when [you] have the time", which > could very well be never). And now you are accusing me of outright dishonesty. Better and better. > I feel like, once again, we've exhausted this topic You have exhausted because you barged in without knowing the first thing about it. > Please justify your objections to the proposed solution, I have already done so, but again you neglected to read it: if there is a bug, it is in the framework code. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > I'm not misrepresenting anybody's words, Me: “I never doubted that Paul's patches do make the bug go away in your test case.” You: “you insisted it wasn't there” This is precisely misrepresenting my words. So stop lying and present excuses. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > Stop twisting people's words and implying things they never said :) This is not you presenting excuses. > And thank you for ignoring my request to stay on topic There is no topic to stay on: I will review this bug when time permits, and you do not know anything about lavfi's scheduling so you cannot help. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-06): > Correct, it's you trying to win arguments with aggressive communication No. You came into an argument without knowing the first thing about it and you decided to side with the guy who wants to violate the project's policy about review. Your behavior in this thread was toxic from your very first post. -- 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] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-07): > To better explain the case at hand, there is no developer policy that lets > you request an indefinite amount of review time with a single "No, you are > not" message. There is a policy that maintainers review patches and patches are not pushed when somebody wants to review. > A good way to ask for an extension would be a message like > "Please let me have a few days to review this and debug it. I know last > time I used the same request only to test you and spread more toxicity > around me, but this time I really mean it". ( > https://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316297.html)... Hm I > wonder why your request is being ignored now. Thanks for pointing this e-mail, anybody reading this honestly will realize Paul's “I did proper analysis already. Pushed.” was the problem in the first place, even more so since it was purely trolling. -- 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] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-07): > Will apply in next 48h. So, you are again threatening to violate the project's policy. > Libavfilter code is not so complex to need so big time interval for review > from experienced C developer. First, the issue is not only analyzing the code but first finding time to do so. Realize that some of us have a job distinct from FFmpeg. And a life. And that does not make us second class citizens of the project. Second, yes, the scheduling of libavfilter is quite complex, and the fact that you believe it is not shows how little qualified you are to judge your own patch. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Sean McGovern (12023-11-07): > This is really unfair to Paul to let this drag on for so long. What does fair have to do with this? If there is a bug, it has been there for years, it can be there for a few more months without any drawback. Plus, Paul has the patch that makes the bug disappear in his test case, he can use it if he want. Some reviews have dragged for weeks before somebody even looked at the patch. It has been just three days since Paul deigned giving some kind of analysis. > If you are genuinely this busy, is there really no one else on the list who > you can delegate to review this piece? This is a public mailing-list, have you seen somebody volunteering? The scheduling in libavfilter is tricky, and I am not aware of anybody else having manifested interest about the subtle details. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
I have now been able to set up a reasonable test case with limit memoryuse 600M. Next step is to simplify the test case. (I cannot understand how you can pretend you analyzed the bug when your test case contains unrelated filters like hqdn3d or setsar.) -- 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] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-08): > I did. I simplified it right from start. But I kept it for myself as It is > not really relevant. It is very relevant for reproducing the problem and reviewing the patch. Please show what you have, it will save time. > With this pace of your debugging it can be expected that universe will > froze first before you manage to came to any conclusion about the > "framework". Then work on something else. There is no urgency here. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
Anton Khirnov (12023-11-09): > The problem with that code (and the reason this patch exists), is that > it depends on the order in which the frames arrive on filtergraph > inputs, which is not meaningful (and becomes non-deterministic with > threading). I can understand that. We will have to find a solution, won't we? (I hope you do not consider removing a feature that people have been using for years an option.) I can suggest this: have demuxer code emit virtual subtitles packets to trigger the sending of the heartbeat frames. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-11): > 1) As far as was communicated, the total of alleged discrepancies in the > voter > list could not affect the result. That makes the vote valid in my book, and > also in the legal or predecential standards in democracies: if elections were > overturned for every inconsequential irregularities, they would practically > never be valid. Except in democracies, it is not the same electoral commission that will both make the mistakes that can be suspected to be fraud and declare these mistakes are unimportant. I must say, my trust in some of the people running this thing is sinking rapidly. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Michael Niedermayer (12023-11-11): > Also iam not sure resending mails to different addressed when they bounce is > safe > Lets just consider i receive a mail at niedermayer.cc, i could construct a > bounce and > send it back while still voting with the token in it. If i now get a mail at > gmx.at > i could vote twice. I am confused: you would get the same token in the second mail, you would not be able to use it twice. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-11): > I waited enough, applied, now for 100% true statement. Your teacher called, you forgot your pacifier in class yesterday. I am still expecting you to share the test cases you have so that the bug can be properly fixed. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-11): > No, bad Nicolas, stop this language, it's unacceptable and unbecoming. You > can ask for more time in a kinder manner. > No, don't reply to me with insults or excuses, just take a walk outside and > reflect on your mistakes. Address your reproaches to the person who started the “unacceptable and unbecoming” behavior. You just shown that you are biassed against me. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC/CC elections
Michael Niedermayer (12023-11-11): > Forming a new CC doesnt prevent teh old one from doing its job > there is no relation. The previous CC had lost its mandate two years before. Also, I cannot easily find the list of members (which is a problem in itself), but I remember observing that several members were in fact very biassed. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-11): > I said don't reply to me! Fortunately you have no authority over me. > I'm not biased, You are. In this message again. > reread what you wrote and think > if "pacifier" belongs on a technical mailing list. I agree. > The other person's behavior can be right or wrong depending on the > interpretation, but using the language you insist on using makes you wrong > right away. “I don't know what the other did, what you did is obviously wrong” is the discourse of adults empowering bullies everywhere by punishing the victims who try to defend themselves. > Please just stop, you cannot have a bad day on the ml every day, it's bad > for your mental health. Oh, so “pacifier” is inappropriate but this is? I hope your are only engaging in a comedy act. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-12): > So all this time you play arrogant moves and expect something out of > nothing but just posting cryptic text. “Out of nothing”? What does that even mean? It is a collaboration: you do not share because I want it but because it helps your own goal. > The case can be simplified by just using single filter, "trim=.." with same > parameters as in script. Please show the exact command so that we do not talk at cross-purposes. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-11): > Nice victimization, but "i'm behaving poorly because the other person is a > meanie" is a childish argument Mock all your want, the fact that you attacked me even though I was just replying and not even told Paul to stop his childish games proves you are biassed beyond all credibility. > I am genuinely concerned for whatever reason is pushing you to use such an > alienating and toxic language, yes. Yeah, right. You mocking somebody's mental health was way more inappropriate than anything that I or Paul ever wrote. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Poll: Repeat vote: GA voters list updates
Anton Khirnov (12023-11-12): > So you have started this vote that at least 6 developers were against, > and zero people beside you were in favor of. I did not take the time to write it, but given the irregularities of the vote and the public attitude of the organizers about it, I think it is necessary. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Michael Niedermayer (12023-11-13): > dear patch iam ashamed but iam not actually blocking you. What was blocking this patch is that the bug had not been properly analyzed and a review process was in progress, slowed down by Paul's own refusal of providing the info his has (most likely because that info does not exist). But Paul pushed anyway, violating deliberately the project's policy. Out of courtesy to everybody else I will not revert immediately as I should, but I will revert with extreme prejudice if I find a simpler fix. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-14): > The French (XIXth century) Empire used notoriously public ballots, and the > results were skewed to say the least. There is a good reason why ballots are > supposed to be confidential. > > And I don't think FFmpeg is immune to the same sort of issues. Consider the > case of developers with any kind of corporate affiliation or financial > dependency. What's to prevent their boss from telling them how to vote if the > ballots are public? Nothing prevents their boss from telling them how to vote, even if the ballots are secret. The kind of secrecy a remote voting software can give us is “urn-style” secrecy: once the ballot is in the box, now way of knowing whose ballot it is. But to prevent bosses from interfering, we would need “voting-booth-style” secrecy: secrecy as the ballot is being cast and no way for the person who cast it to prove what they voted for. Vote-from-home systems cannot provide voting-booth-style secrecy: somebody can hover behind your back while you cast your ballot, or even demand you surrender your secret token. Urn-style secrecy, the only kind we can have, only protects from casual interference, like a kind in a conservative family not daring vote liberal, or an elected official voting against the interests of their biggest campaign donors. This is obviously not a problem for a libre software projects where contributors are all over the world and barely know each others. Now that the question has been raised and I had a chance to reflect on it, I think votes should probably be public. For votes about technical questions, it seems to me quite obvious. For votes about people, like the one now, it is more doubtful because it can lead to more personal polarization, but I am rather in favor too. Also, I will say it here instead of sending a separate mail: I find the strategy of legal intimidation about the GDPR disgusting. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Ronald S. Bultje (12023-11-14): > > Nothing prevents their boss from telling them how to vote, even if the > > ballots are secret. > How is this not just unsubstantiated FUD? Because it is just plain logical truth: somebody's boss CAN do what I described in the part of my mail that you just snipped. That is a simple fact. (Try arguing against it…) Whether any particular somebody's WOULD actually do it… depends on the boss. Some are definitely not above that at all, but nobody here knows if they are around the FFmpeg project. I hope you can grasp the difference between CAN and WOULD. That would be better than calling somebody's logical arguments “FUD”. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-14): > Like for example, people could give votes to associates of the leading > contracting company of FFmpeg at the given time in hope of looking good to > get > subcontracted later. Or all legal VideoLAN members feeling morally obliged to > vote for other VideoLAN members (and they are quite of us in the FFmpeg GA). Hum. This is an angle I had neglected, thanks for bringing it up. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
Anton Khirnov (12023-11-09): > I am obviously not proposing that, given the amount of patches I sent so > far to keep sub2video working. Ok, sorry. > > > I can suggest this: have demuxer code emit virtual subtitles packets to > > trigger the sending of the heartbeat frames. > > That's what already happens, unless I misunderstand what you mean. Right now, the heartbeat code path is: demuxer → heartbeat → filter But the normal frame code path is: demuxer → decode frame → filter And it causes a problem because decode frame is in a different thread, so there is a race condition between the heartbeat frames and the normal frames. Instead, if you make the demuxer generate a dummy packet instead of a heartbeat frame, you get these code paths: demuxer → real sub packet → decode frame → filter demuxer → dummy hb packet → decode frame → filter There is no race condition between the real sub packet and the dummy hb packet because they both happen in the demuxer thread, and after that they follow the same code path so there is no race condition either. > > Another possibility is to make the call independently of the state of > the graph, like this > --- a/fftools/ffmpeg_filter.c > +++ b/fftools/ffmpeg_filter.c > @@ -2274,8 +2274,7 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter, > int64_t pts, AVRational t > or if we need to initialize the system, update the > overlayed subpicture and its start/end times */ > sub2video_update(ifp, pts2 + 1, NULL); > - > -if (av_buffersrc_get_nb_failed_requests(ifp->filter)) > +else > sub2video_push_ref(ifp, pts2); > } Sending frames when they are not wanted can have bad consequences. I do not have the time to look for a test case right now, but I have already delayed replying to this mail too much. I think a situation where subtitles are delayed with the setpts filter would trigger a problem with this change: the heartbeat frames will accumulate in the input of the overlay filter while without this patch only the real subtitles frames accumulate. For a medium delay, normal frames would be in the dozens while heartbeat frames would be in the thousands. > This actually seems to improve filter-overlay-dvdsub-2397, where > the first subtitle appears two frames later, which more closely matches > the subtitles timestamp stored in the file. I would need to look into it. Does it improve it with your changes or also with the precedent non-threaded code? 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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust
Anton Khirnov (12023-11-23): > Avoid making decisions based on current graph input state, which makes > the output dependent on the order in which the frames from different > inputs are interleaved. > > Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the > subtitle appears two frames later, which is closer to its PTS as stored > in the file. > --- > fftools/ffmpeg_filter.c | 3 +-- > tests/ref/fate/filter-overlay-dvdsub-2397 | 4 ++-- > tests/ref/fate/sub2video | 8 +--- > 3 files changed, 8 insertions(+), 7 deletions(-) Just as I warned you, it breaks the test case I suggested: ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv (/tmp/dummy_with_sub.mkv is created like I told a few days ago) thousands of frame queued, eventually failing on OOM. 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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust
Nicolas George (12023-11-27): > Just as I warned you, it breaks the test case I suggested: > > ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi > '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv > > (/tmp/dummy_with_sub.mkv is created like I told a few days ago) > thousands of frame queued, eventually failing on OOM. … And it fails with just this patch but also with the whole patch series. -- 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 01/13] lavfi/buffersink: avoid leaking peeked_frame on uninit
Anton Khirnov (12023-11-23): > --- > libavfilter/buffersink.c | 9 + > 1 file changed, 9 insertions(+) LGTM, thanks. 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 0/6] WebRTC sub-second live streaming support
Michael Riedl (12023-11-27): > Regardless, this will only test the implementation against itself. If that > makes > sense and sounds reasonable, I will add the server support to this patch > series. Thanks. It will not be enough in a perfect world, but it still is a very good start and much better than no testing at all. 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 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust
Paul B Mahol (12023-11-27): > Looks unrelated issue I just fixed, and sent patch to ML. No, it does not change anything, still “queued = 1081”. You could have tested. -- 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] avfilter/framesync: fix OOM case
Paul B Mahol (12023-11-28): > Gonna apply soon. 24 hours is not enough. -- 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] avfilter/framesync: fix OOM case
Paul B Mahol (12023-11-28): > Will wait max 24 hours. You will wait until I post a review, and if you think I am taking too much time in… let us say… ten days you can politely ask me where I am. -- 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] avfilter/framesync: fix OOM case
Paul B Mahol (12023-11-27): > Attached. > From 8ce6bd0090666ef94b0455b7f8f4d3c05e273093 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Mon, 27 Nov 2023 13:04:16 +0100 > Subject: [PATCH] avfilter/framesync: fix OOM case > > Fixes OOM when caller keeps adding frames into filtergraph > that reached EOF by other means, for example EOF is signalled > by other filter in filtergraph or by buffersink. > > Signed-off-by: Paul B Mahol > --- > libavfilter/framesync.c | 3 +++ > 1 file changed, 3 insertions(+) LGTM, good catch. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POC][PATCHSET] Add qrencodesrc source
Tomas Härdin (12023-11-30): > Why? Why not? -- 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] lavfi/af_pan: fix sscanf return value check
sscanf() can return -1 when it reach the end of the string.
Fix track ticket #10677.
Signed-off-by: Nicolas George
---
libavfilter/af_pan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index cfed9f146a..9ab827b396 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -69,7 +69,7 @@ static int parse_channel_name(char **arg, int *rchannel, int
*rnamed)
skip_spaces(arg);
/* try to parse a channel name, e.g. "FL" */
-if (sscanf(*arg, "%7[A-Z]%n", buf, &len)) {
+if (sscanf(*arg, "%7[A-Z]%n", buf, &len) >= 1) {
channel_id = av_channel_from_string(buf);
if (channel_id < 0)
return channel_id;
@@ -80,7 +80,7 @@ static int parse_channel_name(char **arg, int *rchannel, int
*rnamed)
return 0;
}
/* try to parse a channel number, e.g. "c2" */
-if (sscanf(*arg, "c%d%n", &channel_id, &len) &&
+if (sscanf(*arg, "c%d%n", &channel_id, &len) >= 1 &&
channel_id >= 0 && channel_id < MAX_CHANNELS) {
*rchannel = channel_id;
*rnamed = 0;
@@ -165,7 +165,7 @@ static av_cold int init(AVFilterContext *ctx)
sign = 1;
while (1) {
gain = 1;
-if (sscanf(arg, "%lf%n *%n", &gain, &len, &len))
+if (sscanf(arg, "%lf%n *%n", &gain, &len, &len) >= 1)
arg += len;
if (parse_channel_name(&arg, &in_ch_id, &named)){
av_log(ctx, AV_LOG_ERROR,
--
2.42.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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-01): > Change the main loop and every component (demuxers, decoders, filters, > encoders, muxers) to use the previously added transcode scheduler. Every > instance of every such component was already running in a separate > thread, but now they can actually run in parallel. > > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by > JEEB to be more correct and deterministic. > --- > Fixed the hang. Also updated the public branch. Still breaking sub2video with time shift, see the test case I already sent twice. -- 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-01): > See my email from wednesday, it's not actually broken. I do not have a mail from you from Wednesday. When something succeeds with the current code and fails with “Error while add the frame to buffer source(Cannot allocate memory)”, that is broken. -- 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-01): > > When something succeeds with the current code and fails with “Error > > while add the frame to buffer source(Cannot allocate memory)”, that is > > broken. > Not necessarily, when the current code is broken (which you agreed with > in the last thread). I do not know what you are talking about, I agreed to no such thing. The test case I gave you is correct and with the current code it works. Your changes breaks it, removing an important features for users. Please include it in your testing routine and only submit again when you have fixed it. -- 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-01): > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316787.html So not Wednesday but Tursday three weeks ago. I did not agree that the current code was broken. > The current code is broken because its output depends on the order in > which the frames from different inputs arrive at the filtergraph. It > just so happens that it is deterministically broken currently. After > this patchset it becomes non-deterministically broken, which forces me > to do something about it. That is not true. The current code works and gives correct result if the file is properly muxed: it cannot be said to be broken. > Your testcase offsets two streams by 60 seconds. Indeed. > That implies 60 seconds > of buffering. You would get this same amount of bufering in the muxer if > you did the same offsetting with transcoding or remuxing two streams > from the same source. > One can also avoid this buffering entirely by simply opening the file > twice. You are wrong. You would be right if the offset had been in the opposite direction. But in the case I chose, it is the subtitles stream that is delayed, and 60 seconds of subtitles means a few dozens frames at most, not many hundreds. Your change to the sub2video hearbeat makes it continuous, and turns the few dozens frames into many hundreds: this is what is breaking. So I say it again: this test case is useful and currently works, include it in your test case so that your patch series keeps the feature working. I can consider sending a patch to add it to FATE, but not before Monday. Also, note that in the grand-parent message from the one you quoted above, I gave you a solution to make it work. You told that it was already what you did, but obviously it is not, so let us resolve this misunderstanding. -- 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] avfilter/avfilter: fix OOM case for default activate
Paul B Mahol (12023-12-03): > Will apply soon. Must you really act like an asshole each time? You will wait for review. -- 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] avfilter/avfilter: fix OOM case for default activate
Paul B Mahol (12023-12-03): > ffmpeg | branch: master | Paul B Mahol | Fri Dec 1 > 16:59:07 2023 +0100| [d9e41ead82263e96ebd14d4d88d6e7f858dd944c] | committer: > Paul B Mahol > > avfilter/avfilter: fix OOM case for default activate > > Fixes OOM when caller keeps adding frames into filtergraph > that reached EOF by other means, for example EOF is signalled > by other filter in filtergraph or by buffersink. > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d9e41ead82263e96ebd14d4d88d6e7f858dd944c > --- > > libavfilter/avfilter.c | 10 ++ > 1 file changed, 10 insertions(+) You pushed without review, I will revert this without a second thought if I have the slightest doubt about the validity of this commit. -- 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-01): > I can definitely say it is broken and I already told you why. But if you > want something more specific: > * the output of your example with the current master changes depending > on the number of decoder frame threads; my patch fixes that > * in fate-filter-overlay-dvdsub-2397 subtitles appear two frames too > early; again, my patch fixes that Ok, some cases are broken. Fine, this is a hard task, some cases are impossible. That does not allow you to break cases that are currently working. > IIUC your suggestion was to send heartbeat packets from demuxer to > decoder, then have the decoder forward them to filtergraph. > > That is EXACTLY what I'm doing in the final patch, see [1]. It also does > not address this problem at all, because it is caused by the heartbeat > processing code making decisions based on > av_buffersrc_get_nb_failed_requests(), which fundamentally depends on > what frames previously arrived on the video input. Then fix it. I have given you a command that currently works and produces valid output: make sure it still works with your changes. And that will require sending heartbeat frames only when they are needed, keeping the current logic in place. -- 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-04): > broken. If that extra buffering is an actual problem for someone, it can > be easily avoided by opening the file twice. Not a solution if the file is streamed or generated. > As I said before, your command does NOT work. Its output changes > unpredictably depending on unrelated parameters. It still produces correct output in most of the cases, which is what matters to users. > I maintain that your demand to "fix" your testcase (i.e. reduce its > memory consumption) is highly unreasonable – My demand is not that you REDUCE the memory consumption, my demand is that you DO NOT INCREASE IT HUNDREDFOLD. That is a perfectly reasonable demand. > unless you specify how > exactly that is supposed to be accomplished while preserving > determinism. Fixing the bugs introduced by threading is the job of the person who wants to introduce threading. I can offer the help of my expertise about lavfi and subtitles, of course. But your attitude to just pretend the problem does not exist is unacceptable. -- 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] lavc: remove the QOA decoder
Anton Khirnov (12023-12-02): > Its author not only failed to add any tests, as is required by the > development rules, but continues to actively refuse to do so. > > Untested decoders are worse than useless, so remove it. Only tested manually ≠ untested. A code that works is better than no code at all. We are not libav, we do not remove code just because the Great Dictator says so. If you really really want this decoder to have a test, you can write add it yourself. Rejected. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
