Re: [FFmpeg-devel] trac spam
IIRC each regex give -10 so multiple matches give more. Let's assume we have a long keyword like "concretevictoria". Nobody uses this keyword in a normal text. A false positive is almost impossible. I could search for "concretevictoria", "concretevictori." and "concretevictor.." and get -30 points. Or possibly it would also work if I search for "concretevictoria" three times? The idea is to give long keywords a higher weight. I'm not sure if this idea is acceptable, that's why I'd like to ask for your opinions before I do it. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] trac spam
On 19 Oct 2023, at 21:05, Michael Koch wrote: >> IIRC each regex give -10 so multiple matches give more. > > So far, the search strings contain only combinations of keywords, for example > "concretevictoria". > False positives are almost impossible. > > I could add shorter keywords, for example "concrete" and "victoria". > Then we would get multiple matches, but also a few false positives. > Especially for people from Canada. Keywords would be: > "ottawa", "halifax", "victoria", "moncton", "nanaimo", "vancouver", > "concrete", "excavating", "fabricators", "lawncare", "landscapedesign", > "retainingwalls" > Shall I do that? > > I agree with you that the problem is not trivial. > >> I think the captcha works as intended. It adds cost to the spammer > I doubt its economic for spammers to solve a captcha for having some spam > up for a few hours. > >From my experience looking over Xiph infrastructure, we had a lot of spammers in the past able to solve captchas to post spam on our various services. Captcha only really helped for low-effort automated spam. > It's not only for a few hours. We have the spammer's links in our archives > forever. > http://ffmpeg.org/pipermail/ffmpeg-trac/2023-October/067523.html > Search engines can find the links, and that's what the spammer probably wants. > > Michael > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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] trac spam
IIRC each regex give -10 so multiple matches give more. So far, the search strings contain only combinations of keywords, for example "concretevictoria". False positives are almost impossible. I could add shorter keywords, for example "concrete" and "victoria". Then we would get multiple matches, but also a few false positives. Especially for people from Canada. Keywords would be: "ottawa", "halifax", "victoria", "moncton", "nanaimo", "vancouver", "concrete", "excavating", "fabricators", "lawncare", "landscapedesign", "retainingwalls" Shall I do that? I agree with you that the problem is not trivial. I think the captcha works as intended. It adds cost to the spammer I doubt its economic for spammers to solve a captcha for having some spam up for a few hours. It's not only for a few hours. We have the spammer's links in our archives forever. http://ffmpeg.org/pipermail/ffmpeg-trac/2023-October/067523.html Search engines can find the links, and that's what the spammer probably wants. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: The iloc test is not redundant
On Thu, Oct 19, 2023 at 07:42:30PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-19 18:33:13) > > On Thu, Oct 19, 2023 at 01:10:18PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-10-15 02:13:23) > > > > Fixes: Assertion failure > > > > Fixes: > > > > 62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > > > The commit message is useless. > > > > This comment is also not that usefull > > What would you like to see in the commit message ? > > > > The 2 checks are not redundant. Should the message detail how > > the assertion failure occured ? > > At least two people previously thought that the condition is redundant, > so it seems clear to me that an explanation is in order. > > I actually find it quite baffling that this is not obvious to you. Do > you really think that "Fixes: Assertion failure" is sufficient > explanation for anyone reading this patch? let me ask this from the other direction (and i should probably have done so sooner) why would this be redundant ? the failed check checks the number of streams, why should a random atom not occur after x streams for thf irst time ? what code was supposed to prevent this ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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] trac spam
On Thu, Oct 19, 2023 at 07:49:10PM +0200, Michael Koch wrote: > > > You would have to read the trac source probably and maybe do local tests > tracing through the code what happens > but a non spammer posting spam > setting up trac locally is easy, it comes with its own deamon you dont > even need a webserver > > That sounds too complicated for me. > > What about my other question? Can it be changed that the spammer gets +20 > points from successful captcha? > The regex filter is useless if a pattern match gives only -10 points, but 20 > seconds later the spammer gets +20 points from captcha. IIRC each regex give -10 so multiple matches give more. The problem is more fundamental do we allow users to override spam mis identification ? we can reduce the captcha score but then someone will hit a case where she cannot post valid content That means we then need a method to catch these and do something about them Its not as if 20 fails and 18 is going to work, the captcha score would have to be dropped to 8 for this one case you talk about here. I think the captcha works as intended. It adds cost to the spammer I doubt its economic for spammers to solve a captcha for having some spam up for a few hours. Again we can change all these scores but theres a minimum where its least work and deleting spam is work as much as dealing with users who cannot post So if you have some argument that a change in scores would reduce spam with no valid users lost in the last 12months thats a much stronger argument Another way would be to try a change and monitor what happens, do you want to monitor all failed submissions for a few months ? either way tuning these numbers requires some form of feedback mechanism otherwise we would not truly know if we did something smart or stupid thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. 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] trac spam
You would have to read the trac source probably and maybe do local tests tracing through the code what happens but a non spammer posting spam setting up trac locally is easy, it comes with its own deamon you dont even need a webserver That sounds too complicated for me. What about my other question? Can it be changed that the spammer gets +20 points from successful captcha? The regex filter is useless if a pattern match gives only -10 points, but 20 seconds later the spammer gets +20 points from captcha. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] trac spam
On Wed, Oct 18, 2023 at 07:28:33PM +0200, Michael Koch wrote: > please delete: > comment 14 in ticket 2104 > comment 6 in ticket 2776 > user "bristleback" done thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator 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/mov: The iloc test is not redundant
Quoting Michael Niedermayer (2023-10-19 18:33:13) > On Thu, Oct 19, 2023 at 01:10:18PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-10-15 02:13:23) > > > Fixes: Assertion failure > > > Fixes: > > > 62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > > The commit message is useless. > > This comment is also not that usefull > What would you like to see in the commit message ? > > The 2 checks are not redundant. Should the message detail how > the assertion failure occured ? At least two people previously thought that the condition is redundant, so it seems clear to me that an explanation is in order. I actually find it quite baffling that this is not obvious to you. Do you really think that "Fixes: Assertion failure" is sufficient explanation for anyone reading this patch? > Would you prefer if the 2nd condition produces an error instead of return 0 ? Maybe. Depending on the conditions under which this happens. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@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] trac spam
On Thu, Oct 19, 2023 at 07:05:28PM +0200, Michael Koch wrote: > > > Iam not aware of any delay, did you see a delay ? > > I did change the search string (2nd from end of list) and 19 minutes later I > made a test posting in ticket 2776. > I have no idea why the pattern wasn't found. You would have to read the trac source probably and maybe do local tests tracing through the code what happens but a non spammer posting spam setting up trac locally is easy, it comes with its own deamon you dont even need a webserver thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott 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] avformat/mxfdec: Check klv offset
On Wed, Oct 18, 2023 at 08:29:16PM +0200, Tomas Härdin wrote:
> ons 2023-10-18 klockan 02:49 +0200 skrev Michael Niedermayer:
> > Fixes: Assertion klv_offset >= mxf->run_in failed at
> > libavformat/mxfdec.c:736
> > Fixes: 62936/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> > 5778404366221312.fuzz
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxfdec.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 68939091e6..f2ec508b72 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -458,12 +458,15 @@ static int mxf_read_sync(AVIOContext *pb, const
> > uint8_t *key, unsigned size)
> > return i == size;
> > }
> >
> > -static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
> > +static int klv_read_packet(MXFContext *mxf, KLVPacket *klv,
> > AVIOContext *pb)
> > {
> > int64_t length, pos;
> > if (!mxf_read_sync(pb, mxf_klv_key, 4))
> > return AVERROR_INVALIDDATA;
> > klv->offset = avio_tell(pb) - 4;
> > + if (klv->offset < mxf->run_in)
>
> One stray space in there which of course can be fixed when pushing
>
> Looks OK
will apply with this change
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued
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] trac spam
Iam not aware of any delay, did you see a delay ? I did change the search string (2nd from end of list) and 19 minutes later I made a test posting in ticket 2776. I have no idea why the pattern wasn't found. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] avcodec/hevc_ps: Dont leave invalid cpb_cnt_minus1 in the context
On Wed, Oct 18, 2023 at 03:17:41PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: index 32 out of bounds for type 'uint32_t [32]'
> > Fixes:
> > 63003/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4685160840560640
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevc_ps.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index a6b64b92e3..f4365ef5b5 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -421,6 +421,7 @@ static int decode_hrd(GetBitContext *gb, int
> > common_inf_present,
> > if (hdr->cpb_cnt_minus1[i] > 31) {
> > av_log(NULL, AV_LOG_ERROR, "nb_cpb %d invalid\n",
> > hdr->cpb_cnt_minus1[i]);
> > +hdr->cpb_cnt_minus1[i] = 0;
> > return AVERROR_INVALIDDATA;
> > }
> > }
>
> There is a second issue here: There can be truncation during the
> previous assignment, because cpb_cnt_minus1 is uint8_t. So this should
> be fixed by properly checking the value and only putting it in the
> parameter set after it has been validated (which also avoids having to
> reset it).
ok, will apply with that
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
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] trac spam
On Thu, Oct 19, 2023 at 04:21:44PM +0200, Michael Koch wrote: > When I edit the BadContent list, do the new search strings immediately > become effective, or must I wait some time? Iam not aware of any delay, did you see a delay ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] amfenc: Use a blocking call instead of sleeping and polling
On Wed, Oct 18, 2023 at 10:36 PM Mark Thompson wrote:
> ---
> On 17/10/2023 18:11, Evgeny Pavlov wrote:
> > The reason for using av_usleep() here is that AMF API doesn’t provide an
> > API for explicit wait. There are two modes to get output from encoder:
> >
> > 1. Polling with some sleep to avoid CPU thrashing – currently used in
> FFmpeg
> >
> > 2. Set timeout parameter on AMF encoder and QueryOutput call will block
> > till output is available or the timeout happens.
> >
> > #2 is the preferable way but it is designed more to be used with a
> separate
> > polling thread. With a single-thread approach in FFmpeg, the use of
> timeout
> > can block input submission making things slower. This is even more
> > pronounced when B-frames are enabled and several inputs are needed to
> produce
> > the first output.
>
> This approach seems like it should work here? Run non-blocking until the
> queue is full, then switch to blocking when you need to wait for some
> output.
>
> I tried the patch enclosing (H.264 only, different proprties needed for
> other codecs), but it doesn't seem to work - the test assert always hits
> immediately and timing shows that QueryOutput didn't block even though the
> timeout should be set? I'm probably doing something incorrect, maybe you
> would know how to fix it.
>
> > The condition of this sleep is in special events (primarily when amf
> input
> > queue is full), not the core loop part. During the experiments the cpu
> > increasing is about 2-4% or so, not a burst.
>
> What cases are you experimenting with?
>
> The most problematic case I can think of is multiple encodes running
> simultaneously sharing the same instance so that each one has to wait for
> others to complete and therefore all queues fill up.
>
> The busy wait will end up being the only place where it can block (since
> everything else runs asynchronously), so you will peg one CPU at close to
> 100% per encode running.
>
> Thanks,
>
> - Mark
>
> libavcodec/amfenc.c | 22 +++---
> libavcodec/amfenc.h | 1 +
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 061859f85c..db7ddbb083 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -713,13 +713,22 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> AVPacket *avpkt)
> }
> }
>
> -
> +block_and_wait = 0;
> do {
> -block_and_wait = 0;
> // poll data
> if (!avpkt->data && !avpkt->buf) {
> +int64_t timeout = block_and_wait ? 100 : 0;
> +if (timeout != ctx->output_query_timeout) {
> +av_log(avctx, AV_LOG_INFO, "Set output query timeout to
> %"PRId64"\n", timeout);
> +AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
> AMF_VIDEO_ENCODER_QUERY_TIMEOUT, timeout);
> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
> "Failed to set output query timeout\n");
> +ctx->output_query_timeout = timeout;
> +}
> +
> res_query = ctx->encoder->pVtbl->QueryOutput(ctx->encoder,
> &data);
> if (data) {
> +av_log(avctx, AV_LOG_INFO, "QueryOutput returned with
> data\n");
> +
> // copy data to packet
> AMFBuffer *buffer;
> AMFGuid guid = IID_AMFBuffer();
> @@ -740,7 +749,13 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> AVPacket *avpkt)
> data->pVtbl->Release(data);
>
> AMF_RETURN_IF_FALSE(ctx, ret >= 0, ret,
> "amf_copy_buffer() failed with error %d\n", ret);
> +} else {
> +av_log(avctx, AV_LOG_INFO, "QueryOutput returned with
> nothing (%d)\n", res_query);
> +// For testing, shouldn't hit this unless machine is
> otherwise very loaded.
> +av_assert0(!block_and_wait);
> }
> +
> +block_and_wait = 0;
> }
> res_resubmit = AMF_OK;
> if (ctx->delayed_surface != NULL) { // try to resubmit frame
> @@ -769,8 +784,9 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> AVPacket *avpkt)
>
> if (query_output_data_flag == 0) {
> if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain ||
> (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >=
> ctx->hwsurfaces_in_queue_max)) {
> +av_log(avctx, AV_LOG_INFO, "Need to wait for output\n");
> block_and_wait = 1;
> -av_usleep(1000);
> +//av_usleep(1000);
> }
> }
> } while (block_and_wait);
> diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
> index 2dbd378ef8..64c77115b6 100644
> --- a/libavcodec/amfenc.h
> +++ b/libavcodec/amfenc.h
> @@ -72,6 +72,7 @@ typedef struct AmfContext {
> int delayed_drain;
> AMFSurface *delayed_surface;
> AVFrame*delayed_frame;
Re: [FFmpeg-devel] [PATCH] avformat/mov: The iloc test is not redundant
On Thu, Oct 19, 2023 at 01:10:18PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-15 02:13:23) > > Fixes: Assertion failure > > Fixes: > > 62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > The commit message is useless. This comment is also not that usefull What would you like to see in the commit message ? The 2 checks are not redundant. Should the message detail how the assertion failure occured ? Would you prefer if the 2nd condition produces an error instead of return 0 ? Is there something else ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand 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] lavc/internal: add skip_samples2 field
Quoting Lynne (2023-10-19 14:49:46) > Oct 19, 2023, 10:39 by an...@khirnov.net: > > > Current interaction between AV_FRAME_DATA_SKIP_SAMPLES and > > AVCodecContext.skip_samples seems unncecessarily complicated to me and > > you're just making it worse. > > > > Is there any reason we can't drop AVCodecContext.skip_samples entirely > > and signal it purely through side data? Then decoders could fully > > control everything they wish by modifying side data on output frames. > > > > You mean let the decoder parse skip samples side data, > strip it from the packet, and attach a new side data to the frame? Not from the packet - that should be const for decoders. The generic code currently translates AV_PKT_DATA_SKIP_SAMPLES from the packet to the frame in ff_get_buffer(). The decoder can then override that in the frame. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@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] aacdec: padding skip improvements
Quoting Lynne (2023-10-19 14:48:06)
> Oct 19, 2023, 10:40 by an...@khirnov.net:
>
> > Quoting Lynne (2023-10-19 04:38:51)
> >
> >> @@ -3471,6 +3478,9 @@ static const AVOption options[] = {
> >> { "coded","order in which the channels are coded in the bitstream",
> >> 0, AV_OPT_TYPE_CONST, { .i64 = CHANNEL_ORDER_CODED }, .flags =
> >> AACDEC_FLAGS, "channel_order" },
> >>
> >> +{ "padding", "Override the padding at the start of a stream.\n",
> >> +offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 =
> >> 1024 }, 1024, 8192, AACDEC_FLAGS },
> >>
> >
> > Why should this be a decoder option when the caller can already control
> > it by inserting AV_PKT_DATA_SKIP_SAMPLES?
> >
>
> CLI, sadly, mainly.
So add a CLI option to override this side data along the lines of
display_rotation.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] trac spam
When I edit the BadContent list, do the new search strings immediately become effective, or must I wait some time? Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] trac spam
I've just tested the regex filter with a posting in ticket 2776. This
test was not successful.
I thought that the second entry from the end of the list should have
matched:
(?i)regards.{0,5}http
In words: Switch to case insensitive, search for "regards" followed by 0
to 5 of any characters, followed by "http".
What's wrong with the search string?
Michael
P.S. please delete comment 7 in ticket 2776
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/internal: add skip_samples2 field
On 10/19/2023 5:39 AM, Anton Khirnov wrote: Current interaction between AV_FRAME_DATA_SKIP_SAMPLES and AVCodecContext.skip_samples seems unncecessarily complicated to me and you're just making it worse. Is there any reason we can't drop AVCodecContext.skip_samples entirely and signal it purely through side data? Then decoders could fully control everything they wish by modifying side data on output frames. Given that now coded_side_data is fully implemented for decoding and encoding, including getting elements from the container, it's probably a good idea to do that. ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavc/internal: add skip_samples2 field
Oct 19, 2023, 10:39 by an...@khirnov.net: > Current interaction between AV_FRAME_DATA_SKIP_SAMPLES and > AVCodecContext.skip_samples seems unncecessarily complicated to me and > you're just making it worse. > > Is there any reason we can't drop AVCodecContext.skip_samples entirely > and signal it purely through side data? Then decoders could fully > control everything they wish by modifying side data on output frames. > You mean let the decoder parse skip samples side data, strip it from the packet, and attach a new side data to the frame? ___ ffmpeg-devel mailing list ffmpeg-devel@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] aacdec: padding skip improvements
Oct 19, 2023, 10:40 by an...@khirnov.net:
> Quoting Lynne (2023-10-19 04:38:51)
>
>> @@ -3471,6 +3478,9 @@ static const AVOption options[] = {
>> { "coded","order in which the channels are coded in the bitstream",
>> 0, AV_OPT_TYPE_CONST, { .i64 = CHANNEL_ORDER_CODED }, .flags =
>> AACDEC_FLAGS, "channel_order" },
>>
>> +{ "padding", "Override the padding at the start of a stream.\n",
>> +offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 =
>> 1024 }, 1024, 8192, AACDEC_FLAGS },
>>
>
> Why should this be a decoder option when the caller can already control
> it by inserting AV_PKT_DATA_SKIP_SAMPLES?
>
CLI, sadly, mainly.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavc/libx264: add support to propagate SSE values through encoder stats
Quoting Carotti, Elias via ffmpeg-devel (2023-10-13 18:35:14) > I see. Wouldn't not outputting the SSE values when csp_to_pixfmt() > returns AV_PIX_FMT_NONE work better? > That wouldn't be worse than it is today (meaning that right now we > don't get those values for any pix_fmt). It would work in strictly fewer cases than this patch, so I don't see why you'd want to go that way. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavc/libx264: add support to propagate SSE values through encoder stats
Quoting Carotti, Elias via ffmpeg-devel (2023-09-23 12:04:28) > Hi, > please find attached a patch to propagate the SSE for a frame into the > encoder stats. > Since libx264 already provides PSNR values, this is done by basically > inverting the formula to recover the SSE values. Thanks, pushed. > Would it be possible to also append other values to the errors vector? > E.g., libx264 also computes SSIM but other values could be provided. It is certainly conceivable, but it's a nontrivial question whether it should be added to this side data or to a new one. Ideally the same type of data should be produced both by this and the various metrics-computing filters. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
On Wed, Oct 18, 2023 at 01:18:54PM -0400, Sean McGovern wrote:
> On Sat, Oct 14, 2023, 23:27 Sean McGovern wrote:
>
> > It was not introduced until glibc 2.18.
> > ---
> > This should fix the ppc32 FATE node.
> > ---
> > libavutil/ppc/cpu.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> > index 96b491c716..bc8bb5f47c 100644
> > --- a/libavutil/ppc/cpu.c
> > +++ b/libavutil/ppc/cpu.c
> > @@ -95,12 +95,15 @@ int ff_get_cpu_flags_ppc(void)
> > #endif
> > if (ret & AV_CPU_FLAG_VSX)
> > av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
> > -} else if (buf[i] == AT_HWCAP2) {
> > +}
> > +#ifdef AT_HWCAP2 /* not introduced until glibc 2.18 */
> > +else if (buf[i] == AT_HWCAP2) {
> > #ifdef PPC_FEATURE2_ARCH_2_07
> > if (buf[i + 1] & PPC_FEATURE2_ARCH_2_07)
> > ret |= AV_CPU_FLAG_POWER8;
> > #endif
> > }
> > +#endif /* AT_HWCAP2 */
> > }
> > }
> >
> > --
> > 2.39.2
> >
>
> Ping review.
will apply with my next push to master
>
> Alternatively, can the ppc32 FATE nodes be upgraded to a distribution
> release with glibc 2.18 or higher?
> Can I assist with that somehow?
If you want, you can run a fate client to replace or augment the old one.
for this sent the public ssh key the cleint will use to fate-admin (email addr
should be in the docs)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
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/mov: The iloc test is not redundant
Quoting Michael Niedermayer (2023-10-15 02:13:23) > Fixes: Assertion failure > Fixes: > 62866/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5282997370486784 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- The commit message is useless. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@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] trac spam
Please have a look at the Spam Filtering / Monitoring page. One of the spammer's postings was rejected, because it contained a blacklisted pattern in Regex filter and got -10 points. But 20 seconds later the same posting was accepted, because the spammer was successfully verified by Captcha and got +20 points. Does that make sense? Can we change that a successful capcha gives +20 points? Michael ___ ffmpeg-devel mailing list ffmpeg-devel@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] [PATCHv2 1/2] avcodec: LEAD MCMP decoder
LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] aacdec: padding skip improvements
Quoting Lynne (2023-10-19 04:38:51)
> @@ -3471,6 +3478,9 @@ static const AVOption options[] = {
>{ "coded","order in which the channels are coded in the bitstream",
> 0, AV_OPT_TYPE_CONST, { .i64 = CHANNEL_ORDER_CODED }, .flags =
> AACDEC_FLAGS, "channel_order" },
>
> +{ "padding", "Override the padding at the start of a stream.\n",
> +offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 =
> 1024 }, 1024, 8192, AACDEC_FLAGS },
Why should this be a decoder option when the caller can already control
it by inserting AV_PKT_DATA_SKIP_SAMPLES?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/internal: add skip_samples2 field
Current interaction between AV_FRAME_DATA_SKIP_SAMPLES and AVCodecContext.skip_samples seems unncecessarily complicated to me and you're just making it worse. Is there any reason we can't drop AVCodecContext.skip_samples entirely and signal it purely through side data? Then decoders could fully control everything they wish by modifying side data on output frames. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
