[FFmpeg-devel] [PATCH v2] libavfilter/dnn: fix openvino async mode
Bugfix: The OpenVino DNN backend in the 'async' mode sets
'task->inference_done' to 'complete' prior to data copy from
OpenVino output buffer to task's output frame.
This order causes task destroy in ff_dnn_get_result_common()
prior to model output processing.
Signed-off-by: Rafik Saliev
---
libavfilter/dnn/dnn_backend_openvino.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index b494f26f55..b67f288336 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -244,7 +244,6 @@ static void infer_completion_callback(void *args)
av_assert0(request->lltask_count >= 1);
for (int i = 0; i < request->lltask_count; ++i) {
task = request->lltasks[i]->task;
-task->inference_done++;
switch (ov_model->model->func_type) {
case DFT_PROCESS_FRAME:
@@ -278,6 +277,7 @@ static void infer_completion_callback(void *args)
break;
}
+task->inference_done++;
av_freep(&request->lltasks[i]);
output.data = (uint8_t *)output.data
+ output.width * output.height * output.channels *
get_datatype_size(output.dt);
--
2.31.1.windows.1
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
___
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] Fwd: Changing scan type (progressive<->interlaced) without reencoding.
Hi, Did not get any response in the user list so trying here... As the title says, is this at all possible? My concern is mostly with mpeg2 and h264 that have content of one type but encoded/marked as another. Most notably content that has progressive video but stored interlaced. So I'm probably talking about a bit stream filter here because just setting the "field_order", "top" etc. flags when rewrapping does nothing.But I have not found anything in the official docs that suggest this is currently possible so it would be nice if some of you developers could shed some light on this. Thanks, Steinar Apalnes ___ 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] Fwd: Changing scan type (progressive<->interlaced) without reencoding.
Steinar Apalnes (12022-12-16): > Did not get any response in the user list so trying here... Yes, you did. And even if you did not, that would not be an excuse to ask the question here. -- 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 v2] libavfilter/dnn: fix openvino async mode
Bugfix: The OpenVino DNN backend in the 'async' mode sets
'task->inference_done' to 'complete' prior to data copy from
OpenVino output buffer to task's output frame.
This order causes task destroy in ff_dnn_get_result_common()
prior to model output processing.
Signed-off-by: Rafik Saliev
---
libavfilter/dnn/dnn_backend_openvino.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index b494f26f55..b67f288336 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -244,7 +244,6 @@ static void infer_completion_callback(void *args)
av_assert0(request->lltask_count >= 1);
for (int i = 0; i < request->lltask_count; ++i) {
task = request->lltasks[i]->task;
-task->inference_done++;
switch (ov_model->model->func_type) {
case DFT_PROCESS_FRAME:
@@ -278,6 +277,7 @@ static void infer_completion_callback(void *args)
break;
}
+task->inference_done++;
av_freep(&request->lltasks[i]);
output.data = (uint8_t *)output.data
+ output.width * output.height * output.channels *
get_datatype_size(output.dt);
--
2.31.1.windows.1
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach
handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by others
is strictly prohibited.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [REFUND-REQUEST] Travel to Developer Meeting
On Wed, Dec 14, 2022 at 02:06:09PM +, Derek Buitenhuis wrote: > Hello, > > I travelled to Barcelona for the developer meeting. > > I am only requesting for my flight, as I chose to stay in non-VideoLAN hotel. > > Flight: £111.98 - receipt available, of course. LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire 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] [REFUND-REQUEST] Dec 2 developer meeting
On Thu, Dec 15, 2022 at 08:11:34PM +0100, Niklas Haas wrote: > As alluded to by my previous email: > > Flight: 180.32 EUR > Hotel (3 nights + breakfast): 287.40 EUR > Shuttle bus: 5.90 EUR > > I unfortunately can't find receipts for the metro tickets and second bus > ride back to the airport, so I've had to remove them from my refund > request. That brings the total down to 473.62 EUR. LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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] libavfilter/dnn/dnn_backend_openvino.c: fix openvino async mode
yejun@intel.com: > There's a warning at > https://patchwork.ffmpeg.org/project/ffmpeg/patch/ph7pr11mb5887f1a68c19249217a6c09eda...@ph7pr11mb5887.namprd11.prod.outlook.com/, > > please fix and send v2 patch, thanks. The warning was reported against the 'context' field in the patch subject. As a context I provided the path to the source file was changed - in the same way as it was done in these patches: * https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210613144304.3258-1-yejun@intel.com/ * https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210529132419.18027-1-yejun@intel.com/ Unfortunately, I am not enought familiar with patch's subject parsing rules and could not find any detailed documentation with explanation of prohibited characters in the 'context' field. Regards Rafik - Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. ___ 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] libavfilter/dnn: fix openvino async mode
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Saliev, Rafik F
> Sent: Friday, December 16, 2022 6:35 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] libavfilter/dnn: fix openvino async mode
>
> Bugfix: The OpenVino DNN backend in the 'async' mode sets 'task-
> >inference_done' to 'complete' prior to data copy from OpenVino output
> buffer to task's output frame.
> This order causes task destroy in ff_dnn_get_result_common() prior to model
> output processing.
>
> Signed-off-by: Rafik Saliev
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> index b494f26f55..b67f288336 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -244,7 +244,6 @@ static void infer_completion_callback(void *args)
> av_assert0(request->lltask_count >= 1);
> for (int i = 0; i < request->lltask_count; ++i) {
> task = request->lltasks[i]->task;
> -task->inference_done++;
>
> switch (ov_model->model->func_type) {
> case DFT_PROCESS_FRAME:
> @@ -278,6 +277,7 @@ static void infer_completion_callback(void *args)
> break;
> }
>
> +task->inference_done++;
> av_freep(&request->lltasks[i]);
> output.data = (uint8_t *)output.data
>+ output.width * output.height * output.channels *
> get_datatype_size(output.dt);
> --
LGTM, will push soon, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/7] MediaCodec encoder: Fix width/height alignment issue and add more options
> On Dec 15, 2022, at 23:25, Zhao Zhili wrote: > > On Wed, 2022-12-07 at 17:31 +0800, Zhao Zhili wrote: >> From: Zhao Zhili >> >> v2: >> Reorder 1/7 and 2/7. >> >> Zhao Zhili (7): >> avcodec/mediacodecenc: make each encoder has its own option >> avcodec/mediacodecenc: add bitrate_mode option >> avcodec/mediacodecenc: add level option >> avcodec/mediacodecenc: use bsf to handle crop >> avcodec/mediacodecenc: remove the strategy to create DTS >> avcodec/mediacodecenc: add max-bframes support >> avcodec/mediacodecenc: add pts_as_dts option >> >> configure | 2 + >> libavcodec/mediacodecenc.c | 294 +++-- >> >> libavcodec/version.h | 2 +- >> 3 files changed, 256 insertions(+), 42 deletions(-) >> > > Will apply tomorrow. Pushed. > > ___ > 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] [PATCH 2/2] avcodec/jpeg2000dec: Add support for High Throughput HTJ2K decoding.
Hi Andreas, thanks for the review,
> Use "" instead of <>.
Will do
> I really don't like that you are adding a new bitreader here. Can you
explain why this is supposed to be necessary?
The reasons are:
1. The spec has some byte streams read from back to front,I didn't see that
functionality present in get_bits.h(which I assumed contained the bit
reading API).
2. It doesn't handle unstuffing correctly.
3. Doesn't handle EOB correctly, the spec has some arrays when there are no
more bytes, the bit-reader should be filled with 0, others with 0xFF.
> Generally, it is not ok to read array[-1] even if the result is that is
> vmasked away later. It is ok if array actually points into the middle of
> a buffer, so that array[-1] and the other bytes accessed are actually
> part of the buffer. Your remark about MEL bytestream indicates that this
> might be the case here, but I'm not sure.
Hi that is the case, the stream in question is a backward read array, hence
array[-1] would point to the last byte in the MEL
byte stream which is forward read, the paper on HTJ2K @
https://www.htj2k.com/wp-content/uploads/white-paper.pdf on page 20 shows
an image description
of how the bytes are arranged.
> Branchlessly? I see four branches below.
Sorry stray comment, will remove
> In case buffer->pos + 1 < 4, position + 1 < 0 and therefore the next
> lines will read array[-1]. And given that you are using FFMIN, there is
> an implicit branch anyway. I suggest you use AV_RB32 to read only from a
> position that is known to be in the buffer and then shift unwanted bytes
> away.
This array[-1] covered by the MEL bytestream, but a solution would be to
have a check to see if we are close to the end
Didn't know about AV_RB32, replaced the manual shifts with it.
> Are you sure you want to have <= instead of < here? This could read
> length + 1 bytes of array.
Yes, this is that way because of a bug Tomas Hardin found in the first
iteration of the patches.
> Why is this av_noinline? It is normally good, to inline functions only
> called once.
Will change.
> Why does a function called jpeg2000_decode_ht_cleanup perform
> allocations? And why all the other stuff below?
It decodes the cleanup segment, it's not a cleanup function.
> Could use a smaller scope.
Hi what exactly ? the whole code below that?
> This is inconsistent with our naming conventions.
Hi, what section of the naming conventions?
> jpeg2000dec.c seems to be the only intended user of this function, so
> one could make a header/template out of jpeg2000htdec.c and include this
> in jpeg2000dec.c. This would allow to make this function static and
> would avoid exposing the jpeg2000dec.c structures via a header.
Sounds like a good idea,
On Fri, Dec 16, 2022 at 3:29 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> etemesica...@gmail.com:
> > From: caleb
> >
> > This is a revised patch with suggested changes from earlier and
> satisfies the Google Summer of
> > Code 2022 FFmpeg project to add a HTJ2K decoder to FFmpeg.
> >
> > ---
> > libavcodec/Makefile|2 +-
> > libavcodec/jpeg2000.h |3 +
> > libavcodec/jpeg2000dec.c | 69 +-
> > libavcodec/jpeg2000dec.h |2 +
> > libavcodec/jpeg2000htdec.c | 1441
> > libavcodec/jpeg2000htdec.h | 28 +
> > 6 files changed, 1529 insertions(+), 16 deletions(-)
> > create mode 100644 libavcodec/jpeg2000htdec.c
> > create mode 100644 libavcodec/jpeg2000htdec.h
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 98841ed07c..1ba9e09528 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -464,7 +464,7 @@ OBJS-$(CONFIG_JACOSUB_DECODER) +=
> jacosubdec.o ass.o
> > OBJS-$(CONFIG_JPEG2000_ENCODER)+= j2kenc.o mqcenc.o mqc.o
> jpeg2000.o \
> >jpeg2000dwt.o
> > OBJS-$(CONFIG_JPEG2000_DECODER)+= jpeg2000dec.o jpeg2000.o
> jpeg2000dsp.o \
> > - jpeg2000dwt.o mqcdec.o mqc.o
> > + jpeg2000dwt.o mqcdec.o mqc.o
> jpeg2000htdec.o
> > OBJS-$(CONFIG_JPEGLS_DECODER) += jpeglsdec.o jpegls.o
> > OBJS-$(CONFIG_JPEGLS_ENCODER) += jpeglsenc.o jpegls.o
> > OBJS-$(CONFIG_JV_DECODER) += jvdec.o
> > diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> > index e5ecb4cbf9..b2a8e13244 100644
> > --- a/libavcodec/jpeg2000.h
> > +++ b/libavcodec/jpeg2000.h
> > @@ -189,6 +189,9 @@ typedef struct Jpeg2000Cblk {
> > Jpeg2000Pass *passes;
> > Jpeg2000Layer *layers;
> > int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}}
> > +/*HTJ2K settings */
> > +int zbp;
> > +int pass_lengths[2];
> > } Jpeg2000Cblk; // code block
> >
> > typedef struct Jpeg2000Prec {
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 7fc09cb558..5c92baa88e 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_tinterlace: support full-range YUV
Am Fr., 9. Dez. 2022 um 01:28 Uhr schrieb Niklas Haas :
> From: Niklas Haas
>
> This filter, when used in the "pad" mode, currently makes the
> distinction between limited and full range solely by testing for YUVJ
> pixel formats at link setup time. This is deprecated and should be
> improved to perform the detection based on the per-frame metadata.
>
> In order to make this distinction based on color range metadata, which
> is only known at the time of filtering frames, for simplicity, we simply
> allocate two copies of the "black" frame - one for limited range and the
> other for full range metadata. This could be done more dynamically (e.g.
> as-needed or simply by blitting the appropriate pixel value directly),
> but this change is relatively simple and preserves the structure of the
> existing code.
>
> This commit actually fixes a bug in FATE - the new output is correct for
> the first time. The previous md5 ref was of a frame that incorrectly
> combined full-range pixel data with limited-range black fields. The
> corresponding result has been updated.
>
> Signed-off-by: Niklas Haas
> ---
> libavfilter/tinterlace.h | 2 +-
> libavfilter/vf_tinterlace.c | 26 ++--
> tests/ref/fate/filter-pixfmts-tinterlace_pad | 2 +-
> 3 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> index 4059ebf81a..37b6c10c08 100644
> --- a/libavfilter/tinterlace.h
> +++ b/libavfilter/tinterlace.h
> @@ -70,7 +70,7 @@ typedef struct TInterlaceContext {
> int vsub; ///< chroma vertical subsampling
> AVFrame *cur;
> AVFrame *next;
> -uint8_t *black_data[4]; ///< buffer used to fill padded lines
> +uint8_t *black_data[2][4]; ///< buffer used to fill padded lines
> (limited/full)
> int black_linesize[4];
> FFDrawContext draw;
> FFDrawColor color;
> diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
> index 7c54861de4..032629279a 100644
> --- a/libavfilter/vf_tinterlace.c
> +++ b/libavfilter/vf_tinterlace.c
> @@ -201,7 +201,8 @@ static av_cold void uninit(AVFilterContext *ctx)
>
> av_frame_free(&tinterlace->cur );
> av_frame_free(&tinterlace->next);
> -av_freep(&tinterlace->black_data[0]);
> +av_freep(&tinterlace->black_data[0][0]);
> +av_freep(&tinterlace->black_data[1][0]);
> }
>
> static int config_out_props(AVFilterLink *outlink)
> @@ -225,14 +226,22 @@ static int config_out_props(AVFilterLink *outlink)
> int ret;
> ff_draw_init(&tinterlace->draw, outlink->format, 0);
> ff_draw_color(&tinterlace->draw, &tinterlace->color, black);
> -if (ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts))
> -tinterlace->color.comp[0].u8[0] = 0;
> -ret = av_image_alloc(tinterlace->black_data,
> tinterlace->black_linesize,
> +/* limited range */
> +if (!ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts)) {
> +ret = av_image_alloc(tinterlace->black_data[0],
> tinterlace->black_linesize,
> + outlink->w, outlink->h, outlink->format,
> 16);
> +if (ret < 0)
> +return ret;
> +ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
> tinterlace->black_data[0],
> + tinterlace->black_linesize, 0, 0,
> outlink->w, outlink->h);
> +}
> +/* full range */
> +tinterlace->color.comp[0].u8[0] = 0;
> +ret = av_image_alloc(tinterlace->black_data[1],
> tinterlace->black_linesize,
> outlink->w, outlink->h, outlink->format, 16);
> if (ret < 0)
> return ret;
> -
> -ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
> tinterlace->black_data,
> +ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
> tinterlace->black_data[1],
>tinterlace->black_linesize, 0, 0, outlink->w,
> outlink->h);
> }
> if (tinterlace->flags & (TINTERLACE_FLAG_VLPF | TINTERLACE_FLAG_CVLPF)
> @@ -360,7 +369,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
> AVFilterLink *outlink = ctx->outputs[0];
> TInterlaceContext *tinterlace = ctx->priv;
> AVFrame *cur, *next, *out;
> -int field, tff, ret;
> +int field, tff, full, ret;
>
> av_frame_free(&tinterlace->cur);
> tinterlace->cur = tinterlace->next;
> @@ -418,6 +427,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *picref)
> out->sample_aspect_ratio = av_mul_q(cur->sample_aspect_ratio,
> av_make_q(2, 1));
>
> field = (1 + outlink->frame_count_in) & 1 ? FIELD_UPPER :
> FIELD_LOWER;
> +full = out->color_range == AVCOL_RANGE_JPEG ||
> ff_fmt_is_in(out->format, full_scale_yuvj_pix_fmts);
> /* copy upper and lower fields */
> copy_picture_field(tinterlace, out->data, out->linesize,
>
[FFmpeg-devel] fate-admin email address
Hello, I have not received a reply from "fate-ad...@ffmpeg.org" and would like to know which individuals are behind this email address? Regards, Kieran Kunhya ___ 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] MAINTAINERS: add a separate list for those with push access
On Fri, Dec 16, 2022 at 12:26:58AM +0100, Lynne wrote: > Dec 15, 2022, 20:34 by mich...@niedermayer.cc: > > > On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote: > > > >> This list is incomplete, and just contains those I could see > >> while looking at the recent git log. If it looks like I've forgotten you, > >> I definitely haven't! > >> We may complete the list at a later date. > >> > >> This makes it such that those who add themselves to MAINTAINERS do not > >> get push access by default, but rather, they have to request it > >> explicitly in a different commit. This used to be the situation > >> before it was changed at the start of this year and is pretty much what > >> everyone expects. > >> > >> Patch attached. > >> > >> MAINTAINERS | 15 +++ > >> 1 file changed, 15 insertions(+) > >> 6a083061d75f6655771bde377f96aadad19b21c6 > >> 0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch > >> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001 > >> From: Lynne > >> Date: Thu, 15 Dec 2022 02:05:00 +0100 > >> Subject: [PATCH] MAINTAINERS: add a separate list for those with push > >> access > >> > >> This list is incomplete, and just contains those I could remember > >> while looking at the recent git log. > >> We may complete the list at a later date. > >> > >> This makes it such that those who add themselves to MAINTAINERS do not > >> get push access by default, but rather, they have to request it > >> explicitly in a different commit. > >> > >> This used to be the situation > >> before it was changed at the start of this year. > >> > > > > I remember no such change. > > What i do remember is really long ago trying to push people toward pushing > > in > > their own repository and sending pull requests similar to the kernel. But > > this > > was not popular so i droped the idea. > > > > Whereever code is maintained teh maintainer should have write access to that > > place other things become inconvenient quickly. > > > > maintainers who cannot change the code they maintain should stay an > > exception > > > > This is exactly what changed. Before, maintainers who didn't get push > access was the norm, not the standard. > > Regardless, if you agree with the patch, I see no reason to continue > discussing this. I see the need to reach some approximate consensus on the past because making decissions should not be based on misremembering things. I see that in 2015 the GSOC students who got added to MAINTAINERs also got write access in 2015. and IIRC x264 had a similar policy at the time where students would be treated like any other developer and have equal access. I use this as an example because several of these students came and left after their project and still got write access. Maybe all our memories are not 100% exact after so many years but I think you misremember if you think we had alot of maintainers who did not have the same acccess there where some exceptions but they where few. Also some people like the students in the example above, left they did not use their write access so maybe people forgot they had write access Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire 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] fate-admin email address
Hi On Fri, Dec 16, 2022 at 06:49:58PM +, Kieran Kunhya wrote: > Hello, > > I have not received a reply from "fate-ad...@ffmpeg.org" and would like to > know which individuals are behind this email address? ATM there are 3: baptiste michael timothygu99 I did miss your mail in my inbox between 100s mails it seems, but i think i would have noticed it at some point as they wheer still marked unread ill add your key ASAP thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg_ffplay_ffprobe_cmdutils: add -safe to replace the user name and password in the protocol address
The Protocol address may contain the user name and password. The ps -ef command
may expose the plaintext.
The -safe parameter option is added to replace the user name and password in
the command line with the asterisk (*).
Signed-off-by: wujian_nanjing
---
doc/ffmpeg.texi| 7 +++
doc/ffplay.texi| 8
doc/ffprobe.texi | 7 +++
fftools/cmdutils.c | 47 +++
fftools/cmdutils.h | 15 +++
fftools/ffmpeg.c | 16 +---
fftools/ffplay.c | 15 +--
fftools/ffprobe.c | 18 ++
8 files changed, 120 insertions(+), 13 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 0367930..e905542 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -50,6 +50,13 @@ output files. Also do not mix options which belong to
different files. All
options apply ONLY to the next input or output file and are reset between
files.
@itemize
+@item -safe
+The Protocol address may contain the user name and password. The ps -ef
command may expose the plaintext.
+The -safe parameter option is added to replace the user name and password in
the command line with the asterisk (*).
+@example
+ffmpeg -safe -i rtsp://usern...@password..com
+@end example
+
@item
To set the video bitrate of the output file to 64 kbit/s:
@example
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 5dd860b..f46ca91 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -122,6 +122,14 @@ Read @var{input_url}.
@section Advanced options
@table @option
+
+@item -safe
+The Protocol address may contain the user name and password. The ps -ef
command may expose the plaintext.
+The -safe parameter option is added to replace the user name and password in
the command line with the asterisk (*).
+@example
+ffplay -safe -i rtsp://usern...@password..com
+@end example
+
@item -stats
Print several playback statistics, in particular show the stream
duration, the codec parameters, the current position in the stream and
diff --git a/doc/ffprobe.texi b/doc/ffprobe.texi
index 4dc9f57..92b13cf 100644
--- a/doc/ffprobe.texi
+++ b/doc/ffprobe.texi
@@ -89,6 +89,13 @@ Set the output printing format.
@var{writer_name} specifies the name of the writer, and
@var{writer_options} specifies the options to be passed to the writer.
+@item -safe
+The Protocol address may contain the user name and password. The ps -ef
command may expose the plaintext.
+The -safe parameter option is added to replace the user name and password in
the command line with the asterisk (*).
+@example
+ffprobe -safe -i rtsp://usern...@password..com
+@end example
+
For example for printing the output in JSON format, specify:
@example
-print_format json
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index a1de621..22407f8 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -61,6 +61,40 @@ AVDictionary *format_opts, *codec_opts;
int hide_banner = 0;
+void param_masking(int argc, char **argv) {
+int i, j;
+for (i = 1; i < argc; i++) {
+char *match = strstr(argv[i], "://");
+if (match) {
+int total = strlen(argv[i]);
+for (j = 0; j < total; j++) {
+argv[i][j] = '*';
+}
+}
+}
+}
+
+char **copy_argv(int argc, char **argv) {
+char **argv2;
+argv2 = av_mallocz(argc * sizeof(char *));
+if (!argv2)
+exit_program(1);
+
+for (int i = 0; i < argc; i++) {
+int length = strlen(argv[i]) + 1;
+argv2[i] = av_mallocz(length * sizeof(char *));
+if (!argv2[i])
+exit_program(1);
+memcpy(argv2[i], argv[i], length - 1);
+}
+return argv2;
+}
+
+void free_pp(int argc, char **argv) {
+for (int i = 0; i < argc; i++)
+av_free(argv[i]);
+av_free(argv);
+}
void uninit_opts(void)
{
av_dict_free(&swr_opts);
@@ -215,13 +249,13 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
if (win32_argv_utf8) {
*argc_ptr = win32_argc;
*argv_ptr = win32_argv_utf8;
-return;
+goto end;
}
win32_argc = 0;
argv_w = CommandLineToArgvW(GetCommandLineW(), &win32_argc);
if (win32_argc <= 0 || !argv_w)
-return;
+goto end;
/* determine the UTF-8 buffer size (including NULL-termination symbols) */
for (i = 0; i < win32_argc; i++)
@@ -232,7 +266,7 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
argstr_flat = (char *)win32_argv_utf8 + sizeof(char *) * (win32_argc +
1);
if (!win32_argv_utf8) {
LocalFree(argv_w);
-return;
+goto end;
}
for (i = 0; i < win32_argc; i++) {
@@ -243,9 +277,14 @@ static void prepare_app_arguments(int *argc_ptr, char
***argv_ptr)
}
win32_argv_utf8[i] = NULL;
LocalFree(argv_w);
-
*argc_ptr = win32_argc;
*argv_ptr = win32_argv_utf8;
+end:
+if (*argc_ptr > 1 && !strcmp((*argv_pt
