date:20240420

Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/network: add ff_neterrno2() for cases where we already have an errno

2024-04-20 Thread Stefano Sabatini

On date Friday 2024-04-19 20:07:59 +0100, Andrew Sayers wrote:
> For example, WSAStartup()'s documentation says:
> 
> "A call to the WSAGetLastError function is not needed and should not be 
> used"
> ---
>  libavformat/network.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

missing declaration in network.h?
___
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/3] doc: Explain what "context" means

2024-04-20 Thread Stefano Sabatini

On date Thursday 2024-04-18 16:06:12 +0100, Andrew Sayers wrote:
> Based largely on the explanation by Stefano Sabatini:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
> ---
>  doc/jargon.md | 96 +++
>  1 file changed, 96 insertions(+)
>  create mode 100644 doc/jargon.md
> 
> diff --git a/doc/jargon.md b/doc/jargon.md
> new file mode 100644
> index 00..3b78ffb61f

> --- /dev/null
> +++ b/doc/jargon.md

We currently have a single .md file in doc (for historical reason we
still stick to texinfo). Also how is this integrated into doxygen?


> @@ -0,0 +1,96 @@
> +# Jargon
> +
> +Terms used throughout the code that developers may need to know.
> +
> +@anchor context
> +
> +## Context
> +
> +A design pattern that stores the context (e.g. configuration) for a series
> +of operations in a "context" structure, and moves other information 
> elsewhere.
> +
> +Consider a trivial program to print uppercase text:
> +
> +```c

> +/*
> + * Contextual information about where to print a series of messages
> + */

Style:
/**
 * Contextual information about where to print a series of messages
 */

> +struct UpperCasePrinterContext {
> +FILE* out;

here and below, use:
VAR *out;

for overall consistency with the project style.

> +};
> +
> +/*
> + * Extra information about messages to print.
> + * This could be used multiple times in a single context,
> + * or reused several times across multiple contexts.
> + */
> +struct PrintInfo {
> +char* str;
> +};
> +
> +void print(
> +struct UpperCasePrinterContext * ctx,
> +struct PrintInfo * info
> +) {
> +for ( char* c = info->str; *c; ++c ) {
> +char C = toupper(*c);
> +fwrite( , 1, 1, ctx->out );
> +}
> +}
> +

> +int main()
> +{
> +struct PrintInfo hello, world;
> +struct UpperCasePrinterContext ctx;
> +
> +hello.str = "hello, ";
> +world.str = "world!\n";
> +
> +ctx.out = stdout;
> +
> +print( ,  );
> +print( ,  );
> +
> +return 0;
> +}

I'm not sure this is a fitting example. Usually the context is a
public structure and the internal context (which corresponds to the
PrintInfo struct) is private to the implementation. In this case the
API user is not interested at all at its implmentation.

You can think the context provides the "object"/instance where some
operations are done - this is alike in object oriented programming,
where the context corresponds to the self, so that you create/allocate
the object, initialize it, and invoke operations on the object.

So using this analogy, the example would be:

struct UpperCasePrinterContext {...};

// this corresponds to a "method" defined on the context/object
void uppercase_printer_print(UpperCasePrinterContext *ctx, const char *str);

Or maybe you want to define the property in the context itself, so you
do:
uppercase_ctx.str = "foobar";

then you have:
void uppercase_printer_print(UpperCasePrinterContext *ctx);

On a typical FFmpeg context you typically do (see
doc/examples/encode.c example):
// create the context
c = avcodec_alloc_context3(codec);

// set parameters, either in the context or by using the av_opt API
c->bit_rate = 40;
c->width = 352;
c->height = 288;
c->time_base = (AVRational){1, 25};
c->framerate = (AVRational){25, 1};
// ...

// invoke the methods defined in the context
ret = avcodec_send_frame(enc_ctx, frame);
if (ret < 0) {
fprintf(stderr, "Error sending a frame for encoding\n");
exit(1);
}

while (ret >= 0) {
ret = avcodec_receive_packet(enc_ctx, pkt);
if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
return;
else if (ret < 0) {
fprintf(stderr, "Error during encoding\n");
exit(1);
}
...
av_packet_unref(pkt);
}

[...]

Note also that "context" in the FFmpeg jargon is not very specific
because it might be different depending on the implementation, for
example it might not have an av_opt_* interface (for example
libavutil/hash.h).

> +```
> +

> +The `UpperCasePrinterContext` object contains the information that's about
> +the context of the current job (i.e. printing things to standard output).

I find this confusing, it is essentially saying that the context (the
"object") is the context of the current job.

> +Information with a lifetime different than that of the context is moved
> +to the `PrintInfo` object.
> +

> +FFmpeg's main context structures all happen to face some common problems:
> +
> +- querying, setting and getting options
> +- handling "private" internal context, including options for
> +  a particular instance of the generic context
> +- configuring log message verbosity and content
> +

> +FFmpeg gradually converged on the AVClass struct to store this information,
> +then converged on the @ref avoptions "AVOptions" system to manipulate it,
> +so modern code often uses the terms

Re: [FFmpeg-devel] [PATCH] tools: add target_enc_fuzzer.c

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 03:10:37 +0200, Michael Niedermayer wrote:
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  Makefile  |   3 +
>  tools/Makefile|   3 +
>  tools/target_enc_fuzzer.c | 213 ++
>  3 files changed, 219 insertions(+)
>  create mode 100644 tools/target_enc_fuzzer.c
> 
> diff --git a/Makefile b/Makefile
> index b309dbc4db9..de727cbe00e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -52,6 +52,9 @@ $(TOOLS): %$(EXESUF): %.o
>  target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS)
>   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) 
> $(LIBFUZZER_PATH)
>  
> +target_enc_%_fuzzer$(EXESUF): target_enc_%_fuzzer.o $(FF_DEP_LIBS)
> + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) 
> $(LIBFUZZER_PATH)
> +
>  tools/target_bsf_%_fuzzer$(EXESUF): tools/target_bsf_%_fuzzer.o 
> $(FF_DEP_LIBS)
>   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) 
> $(LIBFUZZER_PATH)
>  
> diff --git a/tools/Makefile b/tools/Makefile
> index 72e8e709a8d..2a11fa0ae62 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
>  tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
>   $(COMPILE_C) -DFFMPEG_DECODER=$*
>  
> +tools/target_enc_%_fuzzer.o: tools/target_enc_fuzzer.c
> + $(COMPILE_C) -DFFMPEG_ENCODER=$*
> +
>  tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
>   $(COMPILE_C) -DFFMPEG_BSF=$*
>  
> diff --git a/tools/target_enc_fuzzer.c b/tools/target_enc_fuzzer.c
> new file mode 100644
> index 000..bc9f98c1443
> --- /dev/null
> +++ b/tools/target_enc_fuzzer.c
> @@ -0,0 +1,213 @@
> +/*
> + * Copyright (c) 2024 Michael Niedermayer 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + *
> + * Based on target_dec_fuzzer
> + */
> +
> +#include "config.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "libavcodec/avcodec.h"
> +#include "libavcodec/bytestream.h"
> +#include "libavcodec/codec_internal.h"
> +#include "libavformat/avformat.h"
> +
> +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
> +
> +extern const FFCodec * codec_list[];
> +
> +static void error(const char *err)
> +{
> +fprintf(stderr, "%s", err);
> +exit(1);
> +}
> +
> +static const FFCodec *c = NULL;

> +static const FFCodec *AVCodecInitialize(enum AVCodecID codec_id)

nit: snake_case, also the function is used once and the code can be
embedded in the code

[...]
___
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 4/4] lavc/vvc/refs: Use dpb_max_num_reorder_pics to control output

2024-04-20 Thread myp...@gmail.com

Send it privately via email


On Sat, Apr 20, 2024 at 11:55 AM Nuo Mi  wrote:
>
> Hi Barry and Eliny,
> LGTM.
> Thank you for the patch.
> Is it possible to provide the clip so we can add it to our CI?
>
>  ci like https://github.com/ffvvc/FFmpeg/actions
>
>

> On Fri, Apr 19, 2024 at 9:48 PM Jun Zhao  wrote:
>
> > From: Jun Zhao 
> >
> > Use dpb_max_num_reorder_pics to control output instead of
> > dpb_max_dec_pic_buffering, when dpb_max_dec_pic_buffering
> > is much larger than dpb_max_num_reorder_pics, it may cause
> > dpb overflow error.
> >
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: elinyhuang 
> > ---
> >  libavcodec/vvc/refs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
> > index a5ee7338d6..6694bc4c51 100644
> > --- a/libavcodec/vvc/refs.c
> > +++ b/libavcodec/vvc/refs.c
> > @@ -226,7 +226,7 @@ int ff_vvc_output_frame(VVCContext *s, VVCFrameContext
> > *fc, AVFrame *out, const
> >
> >  /* wait for more frames before output */
> >  if (!flush && s->seq_output == s->seq_decode && sps &&
> > -nb_output <=
> > sps->r->sps_dpb_params.dpb_max_dec_pic_buffering_minus1[sps->r->sps_max_sublayers_minus1]
> > + 1)
> > +nb_output <=
> > sps->r->sps_dpb_params.dpb_max_num_reorder_pics[sps->r->sps_max_sublayers_minus1])
> >  return 0;
> >
> >  if (nb_output) {
> > --
> > 2.25.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/4] lavc/vvc_parser: Fixed the has_b_frames setting

2024-04-20 Thread myp...@gmail.com

On Sat, Apr 20, 2024 at 11:50 AM Nuo Mi  wrote:
>
> On Fri, Apr 19, 2024 at 9:55 PM Jun Zhao  wrote:
>
> > From: Jun Zhao 
> >
> > has_b_frames used in decoder for size of the frame reordering
> > buffer, setting this field from dpb_max_num_reorder_pics.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/vvc_parser.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
> > index a0e10e1a7c..5373875aae 100644
> > --- a/libavcodec/vvc_parser.c
> > +++ b/libavcodec/vvc_parser.c
> > @@ -185,8 +185,8 @@ static void set_parser_ctx(AVCodecParserContext *s,
> > AVCodecContext *avctx,
> >  avctx->color_range =
> >  sps->vui.vui_full_range_flag ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> >
> > -avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
> > -   sps->sps_max_sublayers_minus1;
> > +avctx->has_b_frames =
> > +
> > sps->sps_dpb_params.dpb_max_num_reorder_pics[sps->sps_max_sublayers_minus1];
> >
> Should we relocate this to the decoder? Other codecs typically set this
> parameter in the decoder.
>
I think the part that needs to be refactored is like the 264/265
decoder, but before the refactoring, we need to fix the issue first.
> thank you
>
> >
> >  if (sps->sps_ptl_dpb_hrd_params_present_flag &&
> >  sps->sps_timing_hrd_params_present_flag) {
> > --
> > 2.25.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] doc/muxers: add mkvtimestamp_v2

2024-04-20 Thread Stefano Sabatini

---
 doc/muxers.texi | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6340c8e54d..e1d6a0e557 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
 
 This muxer accepts a single @samp{microdvd} subtitles stream.
 
+@section mkvtimestamp_v2
+mkvtoolnix v2 timestamp format muxer.
+
+Write the PTS rawvideo frame to the output, as implemented by the
+@command{mkvextract} tool from the @command{mkvtoolnix} suite.
+
+This muxer accepts a single @samp{rawvideo} stream.
+
 @section mmf
 Synthetic music Mobile Application Format (SMAF) format muxer.
 
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH v2 3/3] all: Link to "context" from all contexts with documentation

2024-04-20 Thread Andrew Sayers

Some headings needed to be rewritten to accomodate the text,
(hopefully) without changing the meaning.
---
 libavcodec/aacdec.h  |  2 +-
 libavcodec/aacenc.h  |  2 +-
 libavcodec/ac3enc.h  |  2 +-
 libavcodec/amfenc.h  |  2 +-
 libavcodec/atrac.h   |  2 +-
 libavcodec/avcodec.h |  3 ++-
 libavcodec/bsf.h |  2 +-
 libavcodec/d3d11va.h |  3 +--
 libavcodec/mediacodec.h  |  2 +-
 libavcodec/qsv.h |  6 --
 libavcodec/sbr.h |  2 +-
 libavcodec/vdpau.h   |  3 ++-
 libavcodec/videotoolbox.h|  5 +++--
 libavfilter/avfilter.h   |  2 +-
 libavformat/avformat.h   |  3 ++-
 libavformat/avio.h   |  3 ++-
 libavutil/hwcontext.h| 21 -
 libavutil/hwcontext_cuda.h   |  2 +-
 libavutil/hwcontext_d3d11va.h|  4 ++--
 libavutil/hwcontext_d3d12va.h|  6 +++---
 libavutil/hwcontext_drm.h|  2 +-
 libavutil/hwcontext_dxva2.h  |  4 ++--
 libavutil/hwcontext_mediacodec.h |  2 +-
 libavutil/hwcontext_opencl.h |  4 ++--
 libavutil/hwcontext_qsv.h|  4 ++--
 libavutil/hwcontext_vaapi.h  |  6 +++---
 libavutil/hwcontext_vdpau.h  |  2 +-
 libavutil/hwcontext_vulkan.h |  4 ++--
 28 files changed, 57 insertions(+), 48 deletions(-)

diff --git a/libavcodec/aacdec.h b/libavcodec/aacdec.h
index 1b245f9258..3a5317cd54 100644
--- a/libavcodec/aacdec.h
+++ b/libavcodec/aacdec.h
@@ -181,7 +181,7 @@ typedef struct DynamicRangeControl {
 } DynamicRangeControl;
 
 /**
- * main AAC decoding context
+ * main AAC decoding @ref context "context"
  */
 typedef struct AACDecContext {
 const struct AVClass  *class;
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 8899f90ac7..c91f99bc6c 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -193,7 +193,7 @@ typedef struct AACPCEInfo {
 } AACPCEInfo;
 
 /**
- * AAC encoder context
+ * AAC encoder @ref context "context"
  */
 typedef struct AACEncContext {
 AVClass *av_class;
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index 30812617cc..4b6b3c222b 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -152,7 +152,7 @@ typedef struct AC3Block {
 } AC3Block;
 
 /**
- * AC-3 encoder private context.
+ * AC-3 encoder private @ref context "context"
  */
 typedef struct AC3EncodeContext {
 AVClass *av_class;  ///< AVClass used for AVOption
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..71138e7f76 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -43,7 +43,7 @@ typedef struct AmfTraceWriter {
 } AmfTraceWriter;
 
 /**
-* AMF encoder context
+* AMF encoder @ref context "context"
 */
 
 typedef struct AmfContext {
diff --git a/libavcodec/atrac.h b/libavcodec/atrac.h
index 05208bbee6..acdd0a741a 100644
--- a/libavcodec/atrac.h
+++ b/libavcodec/atrac.h
@@ -39,7 +39,7 @@ typedef struct AtracGainInfo {
 } AtracGainInfo;
 
 /**
- *  Gain compensation context structure.
+ *  Gain compensation @ref context "context"
  */
 typedef struct AtracGCContext {
 float   gain_tab1[16];  ///< gain compensation level table
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 968009a192..a1f1430dde 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -430,7 +430,8 @@ typedef struct RcOverride{
 #define AV_GET_ENCODE_BUFFER_FLAG_REF (1 << 0)
 
 /**
- * main external API structure.
+ * @ref context "Context" for an encode or decode session
+ *
  * New fields can be added to the end with minor version bumps.
  * Removal, reordering and changes to existing fields require a major
  * version bump.
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index a09c69f242..23c3cc87e4 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -56,7 +56,7 @@
  */
 
 /**
- * The bitstream filter state.
+ * Bitstream filter @ref context "context"
  *
  * This struct must be allocated with av_bsf_alloc() and freed with
  * av_bsf_free().
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 27f40e5519..087c99f161 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -46,8 +46,7 @@
  */
 
 /**
- * This structure is used to provides the necessary configurations and data
- * to the Direct3D11 FFmpeg HWAccel implementation.
+ * @ref context "Context" for the Direct3D11 FFmpeg HWAccel implementation
  *
  * The application must make it available as AVCodecContext.hwaccel_context.
  *
diff --git a/libavcodec/mediacodec.h b/libavcodec/mediacodec.h
index 4e9b56a618..d983e7ff1a 100644
--- a/libavcodec/mediacodec.h
+++ b/libavcodec/mediacodec.h
@@ -26,7 +26,7 @@
 #include "libavcodec/avcodec.h"
 
 /**
- * This structure holds a reference to a android/view/Surface object that will
+ * @ref context "Context" for the android/view/Surface object that will
  * be used as output by the decoder.
  *
  */
diff --git a/libavcodec/qsv.h b/libavcodec/qsv.h
index

[FFmpeg-devel] [PATCH v2 1/3] doc: Explain what "context" means

2024-04-20 Thread Andrew Sayers

Based largely on the explanation by Stefano Sabatini:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
---
 doc/jargon.md | 169 ++
 1 file changed, 169 insertions(+)
 create mode 100644 doc/jargon.md

diff --git a/doc/jargon.md b/doc/jargon.md
new file mode 100644
index 00..f967b5c8bc
--- /dev/null
+++ b/doc/jargon.md
@@ -0,0 +1,169 @@
+# Jargon
+
+Terms used throughout the code that developers may need to know.
+
+@anchor context
+
+## Context
+
+A design pattern that stores the context (e.g. configuration) for a series
+of operations in a "context" structure, and moves other information with
+a longer or shorter lifetime elsewhere.
+
+Consider a code snippet to modify text then print it:
+
+```c
+/**
+ * Contextual information about printing a series of messages
+ */
+struct ModifyThenPrintContext {
+
+/**
+ * Members of the context usually are usually part of its public API...
+ */
+FILE *out;
+
+/**
+ * ... but check the documentation just in case
+ */
+[[deprecated]]
+int no_longer_part_of_the_public_api;
+
+/**
+ * The "internal context" is private to the context itself.
+ *
+ * Unlike the members above, the private context is not guaranteed
+ * and can change arbitrarily between versions.
+ */
+void* priv_data;
+};
+
+/**
+ * Long-lifetime information, reused by many contexts
+ */
+enum ModifyThenPrintDialect {
+MODIFY_THEN_PRINT_PLAIN_TEXT,
+MODIFY_THEN_PRINT_REGEX,
+MODIFY_THEN_PRINT_REGEX_PCRE
+};
+
+/**
+ * Short-lifetime information, used repeatedly in a single context
+ */
+struct ModifyThenPrintMessage {
+char *str;
+char *replace_this;
+char *with_this;
+};
+
+/**
+ * Allocate and initialize a ModifyThenPrintContext
+ *
+ * This creates a new pointer, then fills in some sensible defaults.
+ *
+ * We can reasonably assume this function will initialise `priv_data`
+ * with a dialect-specific object, but shouldn't make any assumptions
+ * about what that object is.
+ *
+ */
+int ModifyThenPrintContext_alloc_context(struct ModifyThenPrintContext **ctx,
+ FILE *out,
+ enum ModifyThenPrintDialect dialect);
+
+/**
+ * Uninitialize and deallocate a ModifyThenPrintContext
+ *
+ * This does any work required by the private context in `priv_data`
+ * (e.g. deallocating it), then deallocates the main context itself.
+ *
+ */
+int ModifyThenPrintContext_free(struct ModifyThenPrintContext *ctx);
+
+/**
+ * Print a single message
+ */
+int ModifyThenPrintContext_print(struct ModifyThenPrintContext *ctx,
+ struct ModifyThenPrintMessage *msg);
+
+int print_hello_world()
+{
+
+int ret = 0;
+
+struct ModifyThenPrintContext *ctx;
+
+struct ModifyThenPrintMessage hello_world;
+
+if ( ModifyThenPrintContext_alloc_context( , stdout, 
MODIFY_THEN_PRINT_REGEX ) < 0 ) {
+ret = -1;
+goto EXIT_WITHOUT_CLEANUP;
+}
+
+hello_world.replace_this = "Hi|Hullo";
+hello_world.with_this= "Hello";
+
+hello_world.str = "Hi, world!\n";
+if ( ModifyThenPrintContext_print( ctx, _world ) < 0 ) {
+ret = -1;
+goto FINISH;
+}
+
+hello_world.str = "Hullo, world!\n";
+if ( ModifyThenPrintContext_print( ctx, _world ) < 0 ) {
+ret = -1;
+goto FINISH;
+}
+
+FINISH:
+if ( ModifyThenPrintContext_free( ctx ) ) {
+ret = -1;
+goto EXIT_WITHOUT_CLEANUP;
+}
+
+EXIT_WITHOUT_CLEANUP:
+return ret;
+
+}
+```
+
+In the example above, the `ModifyThenPrintContext` object contains information
+that's needed for exactly the lifetime of the current job (i.e. how to modify
+and where to print).  Information with a longer or shorter lifetime is moved
+to `ModifyThenPrintDialect` and `ModifyThenPrintMessage`.
+
+FFmpeg uses the context pattern to solve a variety of problems. But the most
+common contexts (AVCodecContext, AVFormatContext etc.) tend to have a lot of
+requirements in common:
+
+- need to query, set and get options
+  - including options whose implementation is not part of the public API
+- need to configure log message verbosity and content
+
+FFmpeg gradually converged on the AVClass struct to store that information,
+then converged on the @ref avoptions "AVOptions" system to manipulate it.
+So the terms "context", "AVClass context structure" and "AVOptions-enabled
+struct" are often used interchangeably when it's not important to emphasise
+the difference.  But for example, AVMediaCodecContext uses the context
+pattern, but is not an AVClass context structure, so cannot be manipulated
+with AVOptions.
+
+To understand AVClass context structures, consider the `libx264` encoder:
+
+- it has to support common encoder options like "bitrate"
+- it has to support encoder-specific options like "profile"
+  - the exact options could change quickly

[FFmpeg-devel] [PATCH v2 2/3] lavu: Clarify relationship between AVClass, AVOption and context

2024-04-20 Thread Andrew Sayers

---
 libavutil/log.h | 11 ---
 libavutil/opt.h |  7 ---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..b5c739dab1 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -59,9 +59,14 @@ typedef enum {
 struct AVOptionRanges;
 
 /**
- * Describe the class of an AVClass context structure. That is an
- * arbitrary struct of which the first field is a pointer to an
- * AVClass struct (e.g. AVCodecContext, AVFormatContext etc.).
+ * Metadata about an arbitrary data structure
+ *
+ * A @ref context "context struct" whose first member is a pointer
+ * to an AVClass object is called an "AVClass context structure"
+ * (e.g. AVCodecContext, AVFormatContext etc.).
+ *
+ * AVClass is often combined with @ref avoptions "AVOptions" to create
+ * "AVOptions-enabled structs" that can be easily configured by users.
  */
 typedef struct AVClass {
 /**
diff --git a/libavutil/opt.h b/libavutil/opt.h
index e6013662f6..b817d15554 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -39,9 +39,10 @@
  * @defgroup avoptions AVOptions
  * @ingroup lavu_data
  * @{
- * AVOptions provide a generic system to declare options on arbitrary structs
- * ("objects"). An option can have a help text, a type and a range of possible
- * values. Options may then be enumerated, read and written to.
+ * Builds on AVClass, adding a generic system to declare options.
+ *
+ * An option can have a help text, a type and a range of possible values.
+ * Options may then be enumerated, read and written to.
  *
  * There are two modes of access to members of AVOption and its child structs.
  * One is called 'native access', and refers to access from the code that
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH 1/3] lavf/mkvtimestamp_v2: use name in place of description in long name

2024-04-20 Thread Stefano Sabatini

---
 libavformat/mkvtimestamp_v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
index dde431ab7d..1eb2daf10a 100644
--- a/libavformat/mkvtimestamp_v2.c
+++ b/libavformat/mkvtimestamp_v2.c
@@ -43,7 +43,7 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 
 const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
 .p.name= "mkvtimestamp_v2",
-.p.long_name   = NULL_IF_CONFIG_SMALL("extract pts as timecode v2 format, 
as defined by mkvtoolnix"),
+.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
 .p.audio_codec = AV_CODEC_ID_NONE,
 .p.video_codec = AV_CODEC_ID_RAWVIDEO,
 .write_header = write_header,
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH v4 3/3] avformat/avformat: Document return codes for av_format_(de)init

2024-04-20 Thread Andrew Sayers

---
 libavformat/avformat.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 8afdcd9fd0..f624fb1e2e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1944,12 +1944,16 @@ const char *avformat_license(void);
  * This function will be deprecated once support for older GnuTLS and
  * OpenSSL libraries is removed, and this function has no purpose
  * anymore.
+ *
+ * @return 0 for success or AVERROR code
  */
 int avformat_network_init(void);
 
 /**
  * Undo the initialization done by avformat_network_init. Call it only
  * once for each time you called avformat_network_init.
+ *
+ * @return 0 for success or AVERROR code
  */
 int avformat_network_deinit(void);
 
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v4 1/3] avformat/network: add ff_neterrno2() for cases where we already have an errno

2024-04-20 Thread Andrew Sayers

For example, WSAStartup()'s documentation says:

"A call to the WSAGetLastError function is not needed and should not be 
used"
---
 libavformat/network.c | 5 -
 libavformat/network.h | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/network.c b/libavformat/network.c
index f752efc411..f295957aa5 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -123,7 +123,10 @@ void ff_network_close(void)
 #if HAVE_WINSOCK2_H
 int ff_neterrno(void)
 {
-int err = WSAGetLastError();
+return ff_neterrno2(WSAGetLastError());
+}
+int ff_neterrno2(int err)
+{
 switch (err) {
 case WSAEWOULDBLOCK:
 return AVERROR(EAGAIN);
diff --git a/libavformat/network.h b/libavformat/network.h
index ca214087fc..84348f52a4 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -58,6 +58,7 @@
 #define setsockopt(a, b, c, d, e) setsockopt(a, b, c, (const char*) d, e)
 
 int ff_neterrno(void);
+int ff_neterrno2(int err);
 #else
 #include 
 #include 
@@ -66,6 +67,7 @@ int ff_neterrno(void);
 #include 
 
 #define ff_neterrno() AVERROR(errno)
+#define ff_neterrno2(ERRNO) AVERROR(ERRNO)
 #endif /* HAVE_WINSOCK2_H */
 
 #if HAVE_ARPA_INET_H
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v4 2/3] avformat/network: Return 0/AVERROR from ff_network_init()

2024-04-20 Thread Andrew Sayers

---
 libavformat/avio.c|  4 ++--
 libavformat/network.c |  7 +++
 libavformat/rtsp.c| 12 ++--
 libavformat/rtspdec.c |  4 ++--
 libavformat/sapdec.c  |  4 ++--
 libavformat/sapenc.c  |  4 ++--
 6 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index d109f3adff..f82edec779 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -123,8 +123,8 @@ static int url_alloc_for_protocol(URLContext **puc, const 
URLProtocol *up,
 int err;
 
 #if CONFIG_NETWORK
-if (up->flags & URL_PROTOCOL_FLAG_NETWORK && !ff_network_init())
-return AVERROR(EIO);
+if (up->flags & URL_PROTOCOL_FLAG_NETWORK && (err=ff_network_init())<0)
+return err;
 #endif
 if ((flags & AVIO_FLAG_READ) && !up->url_read) {
 av_log(NULL, AV_LOG_ERROR,
diff --git a/libavformat/network.c b/libavformat/network.c
index f295957aa5..c1b0e69362 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -59,11 +59,10 @@ int ff_network_init(void)
 {
 #if HAVE_WINSOCK2_H
 WSADATA wsaData;
-
-if (WSAStartup(MAKEWORD(1,1), ))
-return 0;
+return ff_neterrno2(WSAStartup(MAKEWORD(1,1), ));
+#else
+return 0;
 #endif
-return 1;
 }
 
 int ff_network_wait_fd(int fd, int write)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index b0c61ee00a..3db4ed11c2 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1740,8 +1740,8 @@ int ff_rtsp_connect(AVFormatContext *s)
 return AVERROR(EINVAL);
 }
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((err = ff_network_init())<0)
+return err;
 
 if (s->max_delay < 0) /* Not set by the caller */
 s->max_delay = s->iformat ? DEFAULT_REORDERING_DELAY : 0;
@@ -2395,8 +2395,8 @@ static int sdp_read_header(AVFormatContext *s)
 char url[MAX_URL_SIZE];
 AVBPrint bp;
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((err = ff_network_init())<0)
+return err;
 
 if (s->max_delay < 0) /* Not set by the caller */
 s->max_delay = DEFAULT_REORDERING_DELAY;
@@ -2522,8 +2522,8 @@ static int rtp_read_header(AVFormatContext *s)
 AVBPrint sdp;
 AVDictionary *opts = NULL;
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
 
 opts = map_to_opts(rt);
 ret = ffurl_open_whitelist(, s->url, AVIO_FLAG_READ,
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 10078ce2fa..3b0829694e 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -663,8 +663,8 @@ static int rtsp_listen(AVFormatContext *s)
 int ret;
 enum RTSPMethod methodcode;
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
 
 /* extract hostname and port */
 av_url_split(proto, sizeof(proto), auth, sizeof(auth), host, sizeof(host),
diff --git a/libavformat/sapdec.c b/libavformat/sapdec.c
index 357c0dd514..719c26c6b8 100644
--- a/libavformat/sapdec.c
+++ b/libavformat/sapdec.c
@@ -70,8 +70,8 @@ static int sap_read_header(AVFormatContext *s)
 int port;
 int ret, i;
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
 
 av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
  path, sizeof(path), s->url);
diff --git a/libavformat/sapenc.c b/libavformat/sapenc.c
index 87a834a8d8..3305122524 100644
--- a/libavformat/sapenc.c
+++ b/libavformat/sapenc.c
@@ -80,8 +80,8 @@ static int sap_write_header(AVFormatContext *s)
 int udp_fd;
 AVDictionaryEntry* title = av_dict_get(s->metadata, "title", NULL, 0);
 
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
 
 /* extract hostname and port */
 av_url_split(NULL, 0, NULL, 0, host, sizeof(host), _port,
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH] Remove outdated comment about AVFrame and AVOptions

2024-04-20 Thread Andrew Sayers

---

I think this is out-of-date now avcodec_get_frame_class is gone.
Happy to add docs instead if I've missed something?

 libavutil/frame.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 60bb966f8b..7b8d9aee08 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -367,9 +367,6 @@ typedef struct AVRegionOfInterest {
  *
  * sizeof(AVFrame) is not a part of the public ABI, so new fields may be added
  * to the end with a minor bump.
- *
- * Fields can be accessed through AVOptions, the name string used, matches the
- * C structure field name for fields accessible through AVOptions.
  */
 typedef struct AVFrame {
 #define AV_NUM_DATA_POINTERS 8
-- 
2.43.0

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

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V loop_filter_simple

2024-04-20 Thread flow gg

github link: https://github.com/hleft/FFmpeg/tree/vp8vp9

flow gg  于2024年4月20日周六 23:55写道：

>
>
___
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/3] doc: Explain what "context" means

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 13:18:29 +0100, Andrew Sayers wrote:
> On 20/04/2024 08:25, Stefano Sabatini wrote:
> > On date Thursday 2024-04-18 16:06:12 +0100, Andrew Sayers wrote:
> > > Based largely on the explanation by Stefano Sabatini:
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
> > > ---
> > >   doc/jargon.md | 96 +++
> > >   1 file changed, 96 insertions(+)
> > >   create mode 100644 doc/jargon.md
> > > 
> > > diff --git a/doc/jargon.md b/doc/jargon.md
> > > new file mode 100644
> > > index 00..3b78ffb61f
> > > --- /dev/null
> > > +++ b/doc/jargon.md
> > We currently have a single .md file in doc (for historical reason we
> > still stick to texinfo). Also how is this integrated into doxygen?
> 

> Doxygen automatically renders all /*.md and /doc/*.md files to pages at [1]
> which is the only place I'd know to look for this sort of thing. it seems
> like texinfo is more for man pages etc., which would be hard to link from
> doxygen?  By the way, a file called "jargon" seemed like a better idea than
> e.g. a "design_patterns" file or a section in AVClass.  I've rewritten the
> document completely based on your feedback - same markdown file for now,
> but happy to move/reformat.

If this is the case, probably we should move the files to a dedicated
directory (doxygen?) to avoid to mix too many things in the same
bundle (can be done as a separated patch though since we might think
about what we really want to include in the doxygen docs).

> The points below should be addressed by the new patch, so I'll let that
> speak for itself.  But there's a general issue that's worth mentioning...
> 

> Technically, it sounds like a more accurate description would be "Context
> is an FFmpeg convention that has become fairly rigorous over the years".
> But IMHO readers would uncharitably read that as "Context is some weird
> FFmpeg thing they're stuck with because they picked a pre-OOP language".
> Arguing "Context is a design pattern that groups objects by lifespan"
> emphasises the lessons a newbie can take from FFmpeg and use elsewhere,
> so they get more value from the time they spent reading the document.
> I've tried to write the document to start with the more useful argument,
> then gradually ease in to the more accurate one.

But, I don't think this is really something very rigourous, because it
is used in different "contexts" with sligthly different features
(e.g. you can have a structure named "context" but without an AVClass
or options).

And it's not really about lifespan, and not really specific for
FFmpeg, in C programming this is used to provide a "context" for
several "methods" operating on a given struct - so basically a light
implementation of an object-oriented-based API.

[...]
___
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] lavc/videodsp: Remove emulated_edge_mc duplicate @param

2024-04-20 Thread Frank Plowman

emulated_edge_mc has no parameter called dst_stride.  The description is
a duplicate of the description for dst_linesize.

Signed-off-by: Frank Plowman 
---
 libavcodec/videodsp.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/videodsp.h b/libavcodec/videodsp.h
index e8960b609d..d30c98b9ae 100644
--- a/libavcodec/videodsp.h
+++ b/libavcodec/videodsp.h
@@ -43,8 +43,6 @@ typedef struct VideoDSPContext {
  * the border samples.
  *
  * @param dst destination buffer
- * @param dst_stride number of bytes between 2 vertically adjacent samples
- *   in destination buffer
  * @param src source buffer
  * @param dst_linesize number of bytes between 2 vertically adjacent
  * samples in the destination buffer
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH 3/3] doc/muxers: add mkvtimestamp_v2

2024-04-20 Thread Stefano Sabatini

---
 doc/muxers.texi | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6340c8e54d..4cd53a4449 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2933,14 +2933,13 @@ MicroDVD subtitle format muxer.
 
 This muxer accepts a single @samp{microdvd} subtitles stream.
 
-@section mmf
-Synthetic music Mobile Application Format (SMAF) format muxer.
+@section mkvtimestamp_v2
+mkvtoolnix v2 timestamp format muxer.
 
-SMAF is a music data format specified by Yamaha for portable
-electronic devices, such as mobile phones and personal digital
-assistants.
+Write the PTS rawvideo frame to the output, as implemented by the
+@command{mkvextract} tool from the @command{mkvtoolnix} suite.
 
-This muxer accepts a single @samp{adpcm_yamaha} audio stream.
+This muxer accepts a single @samp{rawvideo} stream.
 
 @section mp3
 
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 2/3] lavf/mkvtimestamp_v2: review implementation to match mkvextract behavior

2024-04-20 Thread Stefano Sabatini

Harmonize internal implementation with the mkvextract behavior:
- print PTS in place of DTS values
- ignore NOPTS values
- sort PTS values
---
 libavformat/mkvtimestamp_v2.c | 69 +--
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
index 1eb2daf10a..c6446ed489 100644
--- a/libavformat/mkvtimestamp_v2.c
+++ b/libavformat/mkvtimestamp_v2.c
@@ -22,30 +22,91 @@
 #include "avformat.h"
 #include "internal.h"
 #include "mux.h"
+#include "libavutil/qsort.h"
+
+#define PTSS_MAX_SIZE 128
+#define PTSS_HALF_SIZE (PTSS_MAX_SIZE >> 1)
+
+struct MkvTimestampContext {
+int64_t ptss[PTSS_MAX_SIZE];
+size_t ptss_size;
+};
 
 static int write_header(AVFormatContext *s)
 {
-static const char *header = "# timecode format v2\n";
+static const char *header = "# timestamp format v2\n";
 avio_write(s->pb, header, strlen(header));
 avpriv_set_pts_info(s->streams[0], 64, 1, 1000);
+
 return 0;
 }
 
+static int cmp_int64(const void *p1, const void *p2)
+{
+int64_t left  = *(const int64_t *)p1;
+int64_t right = *(const int64_t *)p2;
+return FFDIFFSIGN(left, right);
+}
+
 static int write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 char buf[256];
+int i;
+struct MkvTimestampContext *m = s->priv_data;
+
 if (pkt->stream_index)
 av_log(s, AV_LOG_WARNING, "More than one stream unsupported\n");
-snprintf(buf, sizeof(buf), "%" PRId64 "\n", pkt->dts);
-avio_write(s->pb, buf, strlen(buf));
+
+if (pkt->pts == AV_NOPTS_VALUE) {
+av_log(s, AV_LOG_WARNING, "Found PTS with no value, ignored\n");
+return 0;
+}
+
+if (m->ptss_size > PTSS_MAX_SIZE) {
+// sort all PTSs
+AV_QSORT(m->ptss, PTSS_MAX_SIZE, int64_t, cmp_int64);
+
+// write only the first half and copy the second half to the
+// beginning of the array
+for (i = 0; i < PTSS_HALF_SIZE; i++) {
+snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
+avio_write(s->pb, buf, strlen(buf));
+m->ptss[i] = m->ptss[i + PTSS_HALF_SIZE];
+}
+
+m->ptss_size = PTSS_HALF_SIZE;
+} else {
+m->ptss[m->ptss_size++] = pkt->pts;
+}
+
+return 0;
+}
+
+static int write_trailer(struct AVFormatContext *s)
+{
+struct MkvTimestampContext *m = s->priv_data;
+char buf[256];
+int i;
+
+// sort all PTSs
+AV_QSORT(m->ptss, m->ptss_size, int64_t, cmp_int64);
+
+/* flush remaining timestamps */
+for (i = 0; i < m->ptss_size; i++) {
+snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
+avio_write(s->pb, buf, strlen(buf));
+}
+
 return 0;
 }
 
 const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
 .p.name= "mkvtimestamp_v2",
-.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
+.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timestamp format"),
 .p.audio_codec = AV_CODEC_ID_NONE,
 .p.video_codec = AV_CODEC_ID_RAWVIDEO,
 .write_header = write_header,
 .write_packet = write_packet,
+.write_trailer = write_trailer,
+.priv_data_size = sizeof(struct MkvTimestampContext),
 };
-- 
2.34.1

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

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

[FFmpeg-devel] lavf/mkvtimestamp_v2: review mkvtimestamp_v2 implementation, add documentation

2024-04-20 Thread Stefano Sabatini

[PATCH 1/3] lavf/mkvtimestamp_v2: use name in place of description in
[PATCH 2/3] lavf/mkvtimestamp_v2: review implementation to match
[PATCH 3/3] doc/muxers: add mkvtimestamp_v2

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: Fix leak of coded side data

2024-04-20 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Happens in the mov-elst-ends-betn-b-and-i FATE test with
> frame-threading.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/pthread_frame.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index f19571f6f8..a984ff94d5 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -731,6 +731,8 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
> thread_count)
>  av_packet_free(>internal->last_pkt_props);
>  av_freep(>internal);
>  av_buffer_unref(>hw_frames_ctx);
> +av_frame_side_data_free(>decoded_side_data,
> +>nb_decoded_side_data);
>  }
>  
>  av_frame_free(>frame);

Will apply this patch tomorrow unless there are objections.

- Andreas

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

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

Re: [FFmpeg-devel] [PATCH 3/3] doc/muxers: add mkvtimestamp_v2

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 13:48:35 +0200, Stefano Sabatini wrote:
> ---
>  doc/muxers.texi | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)

Sorry, discard this in favor of the new patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: Fix leak of coded side data

2024-04-20 Thread James Almer


On 4/18/2024 6:30 PM, Andreas Rheinhardt wrote:

Happens in the mov-elst-ends-betn-b-and-i FATE test with
frame-threading.

Signed-off-by: Andreas Rheinhardt 
---
  libavcodec/pthread_frame.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index f19571f6f8..a984ff94d5 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -731,6 +731,8 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
thread_count)
  av_packet_free(>internal->last_pkt_props);
  av_freep(>internal);
  av_buffer_unref(>hw_frames_ctx);
+av_frame_side_data_free(>decoded_side_data,
+>nb_decoded_side_data);


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] Remove outdated comment about AVFrame and AVOptions

2024-04-20 Thread James Almer


On 4/20/2024 10:29 AM, Andrew Sayers wrote:

---

I think this is out-of-date now avcodec_get_frame_class is gone.


Yes, there's no AVClass as first element in the struct.


Happy to add docs instead if I've missed something?

  libavutil/frame.h | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 60bb966f8b..7b8d9aee08 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -367,9 +367,6 @@ typedef struct AVRegionOfInterest {
   *
   * sizeof(AVFrame) is not a part of the public ABI, so new fields may be added
   * to the end with a minor bump.
- *
- * Fields can be accessed through AVOptions, the name string used, matches the
- * C structure field name for fields accessible through AVOptions.
   */
  typedef struct AVFrame {
  #define AV_NUM_DATA_POINTERS 8


Will apply.
___
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 2/3] lavc/vp8dsp: R-V V loop_filter_inner

2024-04-20 Thread flow gg


From c033ab8d30135dc02b09b1747c0761baefdcbb4a Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sat, 20 Apr 2024 23:13:07 +0800
Subject: [PATCH 2/3] lavc/vp8dsp: R-V V loop_filter_inner

C908:
vp8_loop_filter8uv_inner_v_c: 738.2
vp8_loop_filter8uv_inner_v_rvv_i32: 455.2
vp8_loop_filter16y_inner_h_c: 685.0
vp8_loop_filter16y_inner_h_rvv_i32: 497.0
vp8_loop_filter16y_inner_v_c: 743.7
vp8_loop_filter16y_inner_v_rvv_i32: 295.7
---
 libavcodec/riscv/vp8dsp_init.c |   4 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 110 +
 2 files changed, 114 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 46ca71ed04..aa95021df5 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -123,6 +123,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
 
+c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv;
+c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv;
+c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv;
+
 c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv;
 c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv;
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 2eadfc5766..f10e269d9d 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -72,6 +72,13 @@ func ff_vp8_idct_dc_add4uv_rvv, zve32x
 ret
 endfunc
 
+.macro filter_abs dst diff fI
+vneg.v  v8, \diff
+vmax.vv \dst, v8, \diff
+vmsleu.vx   v8, \dst, \fI
+vmand.mmv27, v27, v8
+.endm
+
 .macro filter_fmin len a f1 p0f2 q0f1
 .ifc \len,16
 vsetvli zero, zero, e16, m2, ta, ma
@@ -101,6 +108,16 @@ endfunc
 vle8.v  v11, (t4)
 vle8.v  v17, (t1)
 vle8.v  v22, (\dst)
+.if \normal
+sub t3, t2, a6
+sub t0, t1, a6
+add t6, \dst, a6
+add a7, t4, a6
+vle8.v  v2, (t3)
+vle8.v  v15, (t0)
+vle8.v  v10, (t6)
+vle8.v  v14, (a7)
+.endif
 .else
 addit1, \dst, -1
 addia6, \dst, -2
@@ -109,9 +126,28 @@ endfunc
 vlse8.v v11, (t4), \stride
 vlse8.v v17, (t1), \stride
 vlse8.v v22, (\dst), \stride
+.if \normal
+addit5, \dst, -4
+addit0, \dst, -3
+addit6, \dst, 2
+addia7, \dst, 3
+vlse8.v v2, (t5), \stride
+vlse8.v v15, (t0), \stride
+vlse8.v v10, (t6), \stride
+vlse8.v v14, (a7), \stride
+.endif
 .endif
 vwsubu.vv   v12, v1, v11 // p1-q1
 vwsubu.vv   v24, v22, v17// q0-p0
+
+.if \normal
+vwsubu.vv   v30, v1, v17
+vwsubu.vv   v20, v11, v22
+vwsubu.vv   v28, v1, v15
+vwsubu.vv   v4, v2, v15
+vwsubu.vv   v6, v10, v11
+vwsubu.vv   v2, v14, v10
+.endif
 vnclip.wi   v23, v12, 0
 
 .ifc \len,16
@@ -130,6 +166,26 @@ endfunc
 vmacc.vxv18, a7, v8
 vmsleu.vx   v0, v18, \fE
 
+.if \normal
+vneg.v  v18, v30
+vmax.vv v30, v18, v30
+vmsleu.vx   v27, v30, \fI
+filter_abs  v18 v28 \fI
+filter_abs  v18 v4 \fI
+filter_abs  v18 v6 \fI
+filter_abs  v18 v2 \fI
+filter_abs  v20 v20 \fI
+vmand.mmv27, v0, v27 // vp8_simple_limit && normal
+
+vmsgtu.vx   v20, v20, \thresh// hev
+vmsgtu.vx   v3, v30, \thresh
+vmor.mm v3, v3, v20  // v3 = hev: > thresh
+vzext.vf2   v18, v1  // v18 = p1
+vmand.mmv0, v27, v3  // v0 = normal && hev
+vzext.vf2   v20, v11 // v12 = q1
+vmnot.m v3, v3   // v3 = !hv
+.endif
+
 li  t5, 3
 li  a7, 124
 li  t3, 123
@@ -163,8 +219,62 @@ endfunc
 vsse8.v v6, (\dst), \stride, v0.t
 .endif
 
+.if \normal
+vmand.mmv0, v27, v3  // vp8_normal_limit & !hv
+
+.if \inner
+vnclip.wi   v30, v30, 0
+filter_fmin \len v30 v24 v4 v6
+vadd.vi v24, v24, 1
+vsra.vi v24, v24, 1  // (f1 + 1) >> 1;
+vadd.vv v8, v18, v24
+vsub.vv v10, v20, v24
+.endif
+
+vmax.vx v8, v8, zero
+vmax.vx v10, v10, zero
+.ifc \len,16
+vsetvli zero,

[FFmpeg-devel] [PATCH 1/3] lavc/vp8dsp: R-V V loop_filter_simple

2024-04-20 Thread flow gg


From 2f516e0236bd84d78ce6fd7e55c4b1a3c9d99baa Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sat, 20 Apr 2024 23:32:10 +0800
Subject: [PATCH 1/3] lavc/vp8dsp: R-V V loop_filter_simple

C908:
vp8_loop_filter_simple_h_c: 416.0
vp8_loop_filter_simple_h_rvv_i32: 187.5
vp8_loop_filter_simple_v_c: 429.7
vp8_loop_filter_simple_v_rvv_i32: 104.0
---
 libavcodec/riscv/vp8dsp_init.c |   5 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 105 +
 2 files changed, 110 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 2dd583d079..46ca71ed04 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -38,6 +38,8 @@ VP8_BILIN(16, rvv);
 VP8_BILIN(8,  rvv);
 VP8_BILIN(4,  rvv);
 
+VP8_LF(rvv);
+
 av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 {
 #if HAVE_RVV
@@ -120,6 +122,9 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 if (flags & AV_CPU_FLAG_RVB_ADDR) {
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
+
+c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv;
+c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index ba644f0f47..2eadfc5766 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -72,6 +72,111 @@ func ff_vp8_idct_dc_add4uv_rvv, zve32x
 ret
 endfunc
 
+.macro filter_fmin len a f1 p0f2 q0f1
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+vsext.vf2   \q0f1, \a
+vmin.vx \p0f2, \q0f1, a7
+vmin.vx \q0f1, \q0f1, t3
+vadd.vi \p0f2, \p0f2, 3
+vadd.vi \q0f1, \q0f1, 4
+vsra.vi \p0f2, \p0f2, 3
+vsra.vi \f1,   \q0f1, 3
+vadd.vv \p0f2, \p0f2, v8
+vsub.vv \q0f1, v16, \f1
+vmax.vx \p0f2, \p0f2, zero
+vmax.vx \q0f1, \q0f1, zero
+.endm
+
+.macro filter len type normal inner dst stride fE fI thresh
+.ifc \type,v
+sllia6, \stride, 1
+sub t2, \dst, a6
+add t4, \dst, \stride
+sub t1, \dst, \stride
+vle8.v  v1, (t2)
+vle8.v  v11, (t4)
+vle8.v  v17, (t1)
+vle8.v  v22, (\dst)
+.else
+addit1, \dst, -1
+addia6, \dst, -2
+addit4, \dst, 1
+vlse8.v v1, (a6), \stride
+vlse8.v v11, (t4), \stride
+vlse8.v v17, (t1), \stride
+vlse8.v v22, (\dst), \stride
+.endif
+vwsubu.vv   v12, v1, v11 // p1-q1
+vwsubu.vv   v24, v22, v17// q0-p0
+vnclip.wi   v23, v12, 0
+
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+
+// vp8_simple_limit(dst + i, stride, flim)
+li  a7, 2
+vneg.v  v18, v12
+vmax.vv v18, v18, v12
+vneg.v  v8, v24
+vmax.vv v8, v8, v24
+vsrl.vi v18, v18, 1
+vmacc.vxv18, a7, v8
+vmsleu.vx   v0, v18, \fE
+
+li  t5, 3
+li  a7, 124
+li  t3, 123
+vsext.vf2   v4, v23
+vzext.vf2   v8, v17  // p0
+vzext.vf2   v16, v22 // q0
+vmul.vx v30, v24, t5
+vadd.vv v12, v30, v4
+
+.ifc \len,16
+vsetvli zero, zero, e8, m1, ta, ma
+.else
+vsetvli zero, zero, e8, mf2, ta, ma
+.endif
+vnclip.wi   v11, v12, 0
+filter_fmin \len v11 v24 v4 v6
+
+.ifc \len,16
+vsetvli zero, zero, e8, m1, ta, ma
+.else
+vsetvli zero, zero, e8, mf2, ta, ma
+.endif
+vnclipu.wi  v4, v4, 0
+vnclipu.wi  v6, v6, 0
+
+.ifc \type,v
+vse8.v  v4, (t1), v0.t
+vse8.v  v6, (\dst), v0.t
+.else
+vsse8.v v4, (t1), \stride, v0.t
+vsse8.v v6, (\dst), \stride, v0.t
+.endif
+
+.endm
+
+func ff_vp8_v_loop_filter16_simple_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 v 0 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_h_loop_filter16_simple_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 h 0 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
 .macro put_vp8_pixels
 1:
 addi  a4, a4, -1
-- 
2.44.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] [PATCH 3/3] lavc/vp8dsp: R-V V loop_filter

2024-04-20 Thread flow gg


From cff79c9500b94f4c0abdd9cd68c91cc736366c78 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sat, 20 Apr 2024 23:26:58 +0800
Subject: [PATCH 3/3] lavc/vp8dsp: R-V V loop_filter

C908:
vp8_loop_filter8uv_v_c: 745.5
vp8_loop_filter8uv_v_rvv_i32: 467.2
vp8_loop_filter16y_h_c: 674.2
vp8_loop_filter16y_h_rvv_i32: 553.0
vp8_loop_filter16y_v_c: 732.7
vp8_loop_filter16y_v_rvv_i32: 324.5
---
 libavcodec/riscv/vp8dsp_init.c |  4 +++
 libavcodec/riscv/vp8dsp_rvv.S  | 63 ++
 2 files changed, 67 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index aa95021df5..597e6acec8 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -123,6 +123,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
 
+c->vp8_v_loop_filter16y = ff_vp8_v_loop_filter16_rvv;
+c->vp8_h_loop_filter16y = ff_vp8_h_loop_filter16_rvv;
+c->vp8_v_loop_filter8uv = ff_vp8_v_loop_filter8uv_rvv;
+
 c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv;
 c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv;
 c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv;
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index f10e269d9d..af28ea5258 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -229,6 +229,39 @@ endfunc
 vsra.vi v24, v24, 1  // (f1 + 1) >> 1;
 vadd.vv v8, v18, v24
 vsub.vv v10, v20, v24
+.else
+li  t5, 27
+li  t3, 9
+li  a7, 18
+vwmul.vxv2, v11, t5
+vwmul.vxv6, v11, t3
+vwmul.vxv4, v11, a7
+
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+
+li  a7, 63
+vzext.vf2   v14, v15 // p2
+vzext.vf2   v24, v10 // q2
+vadd.vx v2, v2, a7
+vadd.vx v4, v4, a7
+vadd.vx v6, v6, a7
+vsra.vi v2, v2, 7// a0
+vsra.vi v12, v4, 7   // a1
+vsra.vi v6, v6, 7// a2
+vadd.vv v14, v14, v6 // p2 + a2
+vsub.vv v22, v24, v6 // q2 - a2
+vsub.vv v10, v20, v12// q1 - a1
+vadd.vv v4, v8, v2   // p0 + a0
+vsub.vv v6, v16, v2  // q0 - a0
+vadd.vv v8, v12, v18 // a1 + p1
+vmax.vx v4, v4, zero
+vmax.vx v6, v6, zero
+vmax.vx v14, v14, zero
+vmax.vx v16, v22, zero
 .endif
 
 vmax.vx v8, v8, zero
@@ -253,6 +286,17 @@ endfunc
 vsse8.v v6, (a6), \stride, v0.t
 vsse8.v v7, (t4), \stride, v0.t
 .endif
+.if !\inner
+vnclipu.wi  v14, v14, 0
+vnclipu.wi  v16, v16, 0
+.ifc \type,v
+vse8.v  v14, (t0), v0.t
+vse8.v  v16, (t6), v0.t
+.else
+vsse8.v v14, (t0), \stride, v0.t
+vsse8.v v16, (t6), \stride, v0.t
+.endif
+.endif
 .endif
 .endm
 
@@ -275,6 +319,25 @@ func ff_vp8_v_loop_filter8uv_inner_rvv, zve32x
 ret
 endfunc
 
+func ff_vp8_v_loop_filter16_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 v 1 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_h_loop_filter16_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 h 1 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_v_loop_filter8uv_rvv, zve32x
+vsetivlizero, 8, e8, mf2, ta, ma
+filter 8 v 1 0 a0 a2 a3 a4 a5
+filter 8 v 1 0 a1 a2 a3 a4 a5
+ret
+endfunc
+
 func ff_vp8_v_loop_filter16_simple_rvv, zve32x
 vsetivlizero, 16, e8, m1, ta, ma
 filter 16 v 0 0 a0 a1 a2 a3 a4
-- 
2.44.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 2/3] lavf/mkvtimestamp_v2: review implementation to match mkvextract behavior

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 18:47:58 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > On date Saturday 2024-04-20 15:18:39 +0200, Andreas Rheinhardt wrote:
> >> Stefano Sabatini:
> >>> Harmonize internal implementation with the mkvextract behavior:
> >>> - print PTS in place of DTS values
> >>> - ignore NOPTS values
> >>> - sort PTS values
> >>> ---
> >>>  libavformat/mkvtimestamp_v2.c | 69 +--
> >>>  1 file changed, 65 insertions(+), 4 deletions(-)
[...]
> >> 3. I still don't think that this muxer should exist at all.
> > 
> > I tend to agree. But:
> > 
> > We don't really know why this weird muxer was added, today we have
> > better tools for that (we could use ffprobe, or even a bitstream
> > filter similar to showinfo to get the same result), but if it was
> > added probably there was a reason. So my plan is to make the format a
> > bit more useful (DTS => PTS+sort), and possibly deprecate it and point
> > to better available tools and drop this in two major releses.
> > 
> > I don't think the point of the format was to really make the behavior
> > exactly equal to mkvextract, the thing with TimeScale is probably not
> > very important, at least for the original author that was not really
> > an issue, he was probably only looking for some way to dump timestamps
> > and took free inspiration from mkvtoolnix.
> > 
> 
> This thing has been added in 1c5670dbb204369477ee1b5d967f9e8b4f4a33b8. I
> can't find any discussion in the mailing list archives for this, but the
> file description was "extract pts as timecode v2, as defined by
> mkvtoolnix" at the time. Furthermore, its author is the one who started
> the Matroska muxer. So I think its aim was really to mimic mkvextract.
> (I am not certain wrt MKVToolNix handling of fractional millisecond; old
> versions of mkvextract may really have simply rounded/truncated to
> milliseconds.)
> 
> > If this is true, we might point that this format is not exactly
> > equivalent to timestamp_v2 in the doc.
> 
> Which makes this thing even more pointless.

I'm not against removing this muxer, but it is something we should do?
Removing a working component (even if suboptimal) even without
deprecation. Probably if there is agreement about this, especially
given that there are better alternatives at this time.

If not, I can fix the missing bits so we have a better implementation,
but we might want to deprecated and drop later.
___
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] lavf/mkvtimestamp_v2: review implementation to match mkvextract behavior

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 15:18:39 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > Harmonize internal implementation with the mkvextract behavior:
> > - print PTS in place of DTS values
> > - ignore NOPTS values
> > - sort PTS values
> > ---
> >  libavformat/mkvtimestamp_v2.c | 69 +--
> >  1 file changed, 65 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
> > index 1eb2daf10a..c6446ed489 100644
> > --- a/libavformat/mkvtimestamp_v2.c
> > +++ b/libavformat/mkvtimestamp_v2.c
> > @@ -22,30 +22,91 @@
> >  #include "avformat.h"
> >  #include "internal.h"
> >  #include "mux.h"
> > +#include "libavutil/qsort.h"
> > +
> > +#define PTSS_MAX_SIZE 128
> > +#define PTSS_HALF_SIZE (PTSS_MAX_SIZE >> 1)
> > +
> > +struct MkvTimestampContext {
> > +int64_t ptss[PTSS_MAX_SIZE];
> > +size_t ptss_size;
> > +};
> >  
> >  static int write_header(AVFormatContext *s)
> >  {
> > -static const char *header = "# timecode format v2\n";
> > +static const char *header = "# timestamp format v2\n";
> >  avio_write(s->pb, header, strlen(header));
> >  avpriv_set_pts_info(s->streams[0], 64, 1, 1000);
> > +
> >  return 0;
> >  }
> >  
> > +static int cmp_int64(const void *p1, const void *p2)
> > +{
> > +int64_t left  = *(const int64_t *)p1;
> > +int64_t right = *(const int64_t *)p2;
> > +return FFDIFFSIGN(left, right);
> > +}
> > +
> >  static int write_packet(AVFormatContext *s, AVPacket *pkt)
> >  {
> >  char buf[256];
> > +int i;
> > +struct MkvTimestampContext *m = s->priv_data;
> > +
> >  if (pkt->stream_index)
> >  av_log(s, AV_LOG_WARNING, "More than one stream unsupported\n");
> > -snprintf(buf, sizeof(buf), "%" PRId64 "\n", pkt->dts);
> > -avio_write(s->pb, buf, strlen(buf));
> > +
> > +if (pkt->pts == AV_NOPTS_VALUE) {
> > +av_log(s, AV_LOG_WARNING, "Found PTS with no value, ignored\n");
> > +return 0;
> > +}
> > +
> > +if (m->ptss_size > PTSS_MAX_SIZE) {
> > +// sort all PTSs
> > +AV_QSORT(m->ptss, PTSS_MAX_SIZE, int64_t, cmp_int64);
> > +
> > +// write only the first half and copy the second half to the
> > +// beginning of the array
> > +for (i = 0; i < PTSS_HALF_SIZE; i++) {
> > +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
> > +avio_write(s->pb, buf, strlen(buf));
> > +m->ptss[i] = m->ptss[i + PTSS_HALF_SIZE];
> > +}
> > +
> > +m->ptss_size = PTSS_HALF_SIZE;
> > +} else {
> > +m->ptss[m->ptss_size++] = pkt->pts;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static int write_trailer(struct AVFormatContext *s)
> > +{
> > +struct MkvTimestampContext *m = s->priv_data;
> > +char buf[256];
> > +int i;
> > +
> > +// sort all PTSs
> > +AV_QSORT(m->ptss, m->ptss_size, int64_t, cmp_int64);
> > +
> > +/* flush remaining timestamps */
> > +for (i = 0; i < m->ptss_size; i++) {
> > +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
> > +avio_write(s->pb, buf, strlen(buf));
> > +}
> > +
> >  return 0;
> >  }
> >  
> >  const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
> >  .p.name= "mkvtimestamp_v2",
> > -.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
> > +.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timestamp 
> > format"),
> >  .p.audio_codec = AV_CODEC_ID_NONE,
> >  .p.video_codec = AV_CODEC_ID_RAWVIDEO,
> >  .write_header = write_header,
> >  .write_packet = write_packet,
> > +.write_trailer = write_trailer,
> > +.priv_data_size = sizeof(struct MkvTimestampContext),
> >  };
> 

> 1. This does not match mkvextract behaviour. mkvextract does not force a
> 1ms timebase.

>From your past comment:
>The accuracy of the timestamps output by mkvextract is determined by the
>TimestampScale of the file in question; it is most often 1ms when the
>file has video.

Note that this is only used for video. I don't know how this
TimestampScale is computed, but I wonder what was the point of this
muxer. Probably it was only used to extract the timestamps with a
fixed timescale, and the fact that it was similar to mkvextract was
not really an important factor.

> 2. AV_QSORT should only be used in speed-critical code, which this here
> is definitely not.

Why? What should I use instead?

> 3. I still don't think that this muxer should exist at all.

I tend to agree. But:

We don't really know why this weird muxer was added, today we have
better tools for that (we could use ffprobe, or even a bitstream
filter similar to showinfo to get the same result), but if it was
added probably there was a reason. So my plan is to make the format a
bit more useful (DTS => PTS+sort), and possibly deprecate it and point
to better available tools and drop this in two major releses.

I don't think the point

Re: [FFmpeg-devel] [PATCH v2 1/3] doc: Explain what "context" means

2024-04-20 Thread Stefano Sabatini

On date Saturday 2024-04-20 13:19:41 +0100, Andrew Sayers wrote:
> Based largely on the explanation by Stefano Sabatini:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
> ---
>  doc/jargon.md | 169 ++
>  1 file changed, 169 insertions(+)
>  create mode 100644 doc/jargon.md
> 
> diff --git a/doc/jargon.md b/doc/jargon.md
> new file mode 100644
> index 00..f967b5c8bc
> --- /dev/null
> +++ b/doc/jargon.md
> @@ -0,0 +1,169 @@
> +# Jargon
> +
> +Terms used throughout the code that developers may need to know.
> +
> +@anchor context
> +

> +## Context
> +

> +A design pattern that stores the context (e.g. configuration) for a series
> +of operations in a "context" structure, and moves other information with
> +a longer or shorter lifetime elsewhere.

I'd skip the mention of a design pattern since this is about the
jargon.

So a simplified variant would be:

A "context" is a a structure used to store information
(e.g. configuration and/or internal state) for a series of operations
working on the same data.

> +
> +Consider a code snippet to modify text then print it:
> +
> +```c
> +/**
> + * Contextual information about printing a series of messages
> + */
> +struct ModifyThenPrintContext {
> +
> +/**
> + * Members of the context usually are usually part of its public API...
> + */
> +FILE *out;
> +
> +/**
> + * ... but check the documentation just in case
> + */
> +[[deprecated]]
> +int no_longer_part_of_the_public_api;
> +
> +/**
> + * The "internal context" is private to the context itself.
> + *
> + * Unlike the members above, the private context is not guaranteed
> + * and can change arbitrarily between versions.
> + */
> +void* priv_data;
> +};
> +
> +/**
> + * Long-lifetime information, reused by many contexts
> + */
> +enum ModifyThenPrintDialect {
> +MODIFY_THEN_PRINT_PLAIN_TEXT,
> +MODIFY_THEN_PRINT_REGEX,
> +MODIFY_THEN_PRINT_REGEX_PCRE
> +};
> +
> +/**
> + * Short-lifetime information, used repeatedly in a single context
> + */
> +struct ModifyThenPrintMessage {
> +char *str;
> +char *replace_this;
> +char *with_this;
> +};
> +
> +/**
> + * Allocate and initialize a ModifyThenPrintContext
> + *
> + * This creates a new pointer, then fills in some sensible defaults.
> + *
> + * We can reasonably assume this function will initialise `priv_data`
> + * with a dialect-specific object, but shouldn't make any assumptions
> + * about what that object is.
> + *
> + */
> +int ModifyThenPrintContext_alloc_context(struct ModifyThenPrintContext **ctx,
> + FILE *out,
> + enum ModifyThenPrintDialect 
> dialect);
> +
> +/**
> + * Uninitialize and deallocate a ModifyThenPrintContext
> + *
> + * This does any work required by the private context in `priv_data`
> + * (e.g. deallocating it), then deallocates the main context itself.
> + *
> + */
> +int ModifyThenPrintContext_free(struct ModifyThenPrintContext *ctx);
> +
> +/**
> + * Print a single message
> + */
> +int ModifyThenPrintContext_print(struct ModifyThenPrintContext *ctx,
> + struct ModifyThenPrintMessage *msg);
> +
> +int print_hello_world()
> +{
> +
> +int ret = 0;
> +
> +struct ModifyThenPrintContext *ctx;
> +
> +struct ModifyThenPrintMessage hello_world;
> +
> +if ( ModifyThenPrintContext_alloc_context( , stdout, 
> MODIFY_THEN_PRINT_REGEX ) < 0 ) {
> +ret = -1;
> +goto EXIT_WITHOUT_CLEANUP;
> +}
> +
> +hello_world.replace_this = "Hi|Hullo";
> +hello_world.with_this= "Hello";
> +
> +hello_world.str = "Hi, world!\n";
> +if ( ModifyThenPrintContext_print( ctx, _world ) < 0 ) {
> +ret = -1;
> +goto FINISH;
> +}
> +
> +hello_world.str = "Hullo, world!\n";
> +if ( ModifyThenPrintContext_print( ctx, _world ) < 0 ) {
> +ret = -1;
> +goto FINISH;
> +}
> +
> +FINISH:
> +if ( ModifyThenPrintContext_free( ctx ) ) {
> +ret = -1;
> +goto EXIT_WITHOUT_CLEANUP;
> +}
> +
> +EXIT_WITHOUT_CLEANUP:
> +return ret;
> +
> +}
> +```
> +

> +In the example above, the `ModifyThenPrintContext` object contains 
> information
> +that's needed for exactly the lifetime of the current job (i.e. how to modify
> +and where to print).  Information with a longer or shorter lifetime is moved
> +to `ModifyThenPrintDialect` and `ModifyThenPrintMessage`.

I still find this overly complex, I would rather use a typical example
of AVCodecContext for encoding or decoding or something even simpler
(for example md5.h).

About the internal "private" context, this is mostly relevant for
FFmpeg development, and not really useful for API users (basically
they don't even need to know about the private data).

For example all they need to know is that for AVCodecContext generic
options they can set

Re: [FFmpeg-devel] [PATCH 2/3] lavf/mkvtimestamp_v2: review implementation to match mkvextract behavior

2024-04-20 Thread Andreas Rheinhardt

Stefano Sabatini:
> On date Saturday 2024-04-20 15:18:39 +0200, Andreas Rheinhardt wrote:
>> Stefano Sabatini:
>>> Harmonize internal implementation with the mkvextract behavior:
>>> - print PTS in place of DTS values
>>> - ignore NOPTS values
>>> - sort PTS values
>>> ---
>>>  libavformat/mkvtimestamp_v2.c | 69 +--
>>>  1 file changed, 65 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
>>> index 1eb2daf10a..c6446ed489 100644
>>> --- a/libavformat/mkvtimestamp_v2.c
>>> +++ b/libavformat/mkvtimestamp_v2.c
>>> @@ -22,30 +22,91 @@
>>>  #include "avformat.h"
>>>  #include "internal.h"
>>>  #include "mux.h"
>>> +#include "libavutil/qsort.h"
>>> +
>>> +#define PTSS_MAX_SIZE 128
>>> +#define PTSS_HALF_SIZE (PTSS_MAX_SIZE >> 1)
>>> +
>>> +struct MkvTimestampContext {
>>> +int64_t ptss[PTSS_MAX_SIZE];
>>> +size_t ptss_size;
>>> +};
>>>  
>>>  static int write_header(AVFormatContext *s)
>>>  {
>>> -static const char *header = "# timecode format v2\n";
>>> +static const char *header = "# timestamp format v2\n";
>>>  avio_write(s->pb, header, strlen(header));
>>>  avpriv_set_pts_info(s->streams[0], 64, 1, 1000);
>>> +
>>>  return 0;
>>>  }
>>>  
>>> +static int cmp_int64(const void *p1, const void *p2)
>>> +{
>>> +int64_t left  = *(const int64_t *)p1;
>>> +int64_t right = *(const int64_t *)p2;
>>> +return FFDIFFSIGN(left, right);
>>> +}
>>> +
>>>  static int write_packet(AVFormatContext *s, AVPacket *pkt)
>>>  {
>>>  char buf[256];
>>> +int i;
>>> +struct MkvTimestampContext *m = s->priv_data;
>>> +
>>>  if (pkt->stream_index)
>>>  av_log(s, AV_LOG_WARNING, "More than one stream unsupported\n");
>>> -snprintf(buf, sizeof(buf), "%" PRId64 "\n", pkt->dts);
>>> -avio_write(s->pb, buf, strlen(buf));
>>> +
>>> +if (pkt->pts == AV_NOPTS_VALUE) {
>>> +av_log(s, AV_LOG_WARNING, "Found PTS with no value, ignored\n");
>>> +return 0;
>>> +}
>>> +
>>> +if (m->ptss_size > PTSS_MAX_SIZE) {
>>> +// sort all PTSs
>>> +AV_QSORT(m->ptss, PTSS_MAX_SIZE, int64_t, cmp_int64);
>>> +
>>> +// write only the first half and copy the second half to the
>>> +// beginning of the array
>>> +for (i = 0; i < PTSS_HALF_SIZE; i++) {
>>> +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
>>> +avio_write(s->pb, buf, strlen(buf));
>>> +m->ptss[i] = m->ptss[i + PTSS_HALF_SIZE];
>>> +}
>>> +
>>> +m->ptss_size = PTSS_HALF_SIZE;
>>> +} else {
>>> +m->ptss[m->ptss_size++] = pkt->pts;
>>> +}
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static int write_trailer(struct AVFormatContext *s)
>>> +{
>>> +struct MkvTimestampContext *m = s->priv_data;
>>> +char buf[256];
>>> +int i;
>>> +
>>> +// sort all PTSs
>>> +AV_QSORT(m->ptss, m->ptss_size, int64_t, cmp_int64);
>>> +
>>> +/* flush remaining timestamps */
>>> +for (i = 0; i < m->ptss_size; i++) {
>>> +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
>>> +avio_write(s->pb, buf, strlen(buf));
>>> +}
>>> +
>>>  return 0;
>>>  }
>>>  
>>>  const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
>>>  .p.name= "mkvtimestamp_v2",
>>> -.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
>>> +.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timestamp 
>>> format"),
>>>  .p.audio_codec = AV_CODEC_ID_NONE,
>>>  .p.video_codec = AV_CODEC_ID_RAWVIDEO,
>>>  .write_header = write_header,
>>>  .write_packet = write_packet,
>>> +.write_trailer = write_trailer,
>>> +.priv_data_size = sizeof(struct MkvTimestampContext),
>>>  };
>>
> 
>> 1. This does not match mkvextract behaviour. mkvextract does not force a
>> 1ms timebase.
> 
> From your past comment:
>> The accuracy of the timestamps output by mkvextract is determined by the
>> TimestampScale of the file in question; it is most often 1ms when the
>> file has video.
> 

"most often" != "force"

> Note that this is only used for video. I don't know how this
> TimestampScale is computed, but I wonder what was the point of this
> muxer. Probably it was only used to extract the timestamps with a
> fixed timescale, and the fact that it was similar to mkvextract was
> not really an important factor.
> 

mkvextract simply shows the timestamps as decimal number in ms (given
that the timebase of Matroska files is always a multiple of 1
nanosecond, at most six digits after the decimal point are necessary for
this). One would need to remove the avpriv_set_pts_info and convert the
numbers to fractional ms representation to do likewise.

>> 2. AV_QSORT should only be used in speed-critical code, which this here
>> is definitely not.
> 
> Why? What should I use instead?

qsort

> 
>> 3. I still don't think that this muxer should exist at all.
> 
> I tend to agree. But:

Re: [FFmpeg-devel] [PATCH 1/3] doc: Explain what "context" means

2024-04-20 Thread Andrew Sayers


On 20/04/2024 08:25, Stefano Sabatini wrote:

On date Thursday 2024-04-18 16:06:12 +0100, Andrew Sayers wrote:

Based largely on the explanation by Stefano Sabatini:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
---
  doc/jargon.md | 96 +++
  1 file changed, 96 insertions(+)
  create mode 100644 doc/jargon.md

diff --git a/doc/jargon.md b/doc/jargon.md
new file mode 100644
index 00..3b78ffb61f
--- /dev/null
+++ b/doc/jargon.md

We currently have a single .md file in doc (for historical reason we
still stick to texinfo). Also how is this integrated into doxygen?


Doxygen automatically renders all /*.md and /doc/*.md files to pages at [1]
which is the only place I'd know to look for this sort of thing. it seems
like texinfo is more for man pages etc., which would be hard to link from
doxygen?  By the way, a file called "jargon" seemed like a better idea than
e.g. a "design_patterns" file or a section in AVClass.  I've rewritten the
document completely based on your feedback - same markdown file for now,
but happy to move/reformat.

The points below should be addressed by the new patch, so I'll let that
speak for itself.  But there's a general issue that's worth mentioning...

Technically, it sounds like a more accurate description would be "Context
is an FFmpeg convention that has become fairly rigorous over the years".
But IMHO readers would uncharitably read that as "Context is some weird
FFmpeg thing they're stuck with because they picked a pre-OOP language".
Arguing "Context is a design pattern that groups objects by lifespan"
emphasises the lessons a newbie can take from FFmpeg and use elsewhere,
so they get more value from the time they spent reading the document.
I've tried to write the document to start with the more useful argument,
then gradually ease in to the more accurate one.

Note: I previously sent this from the wrong e-mail address - apologies for
spam if the other one makes it past moderation.

[1] https://ffmpeg.org/doxygen/trunk/pages.html




@@ -0,0 +1,96 @@
+# Jargon
+
+Terms used throughout the code that developers may need to know.
+
+@anchor context
+
+## Context
+
+A design pattern that stores the context (e.g. configuration) for a series
+of operations in a "context" structure, and moves other information elsewhere.
+
+Consider a trivial program to print uppercase text:
+
+```c
+/*
+ * Contextual information about where to print a series of messages
+ */

Style:
/**
  * Contextual information about where to print a series of messages
  */


+struct UpperCasePrinterContext {
+FILE* out;

here and below, use:
VAR *out;

for overall consistency with the project style.


+};
+
+/*
+ * Extra information about messages to print.
+ * This could be used multiple times in a single context,
+ * or reused several times across multiple contexts.
+ */
+struct PrintInfo {
+char* str;
+};
+
+void print(
+struct UpperCasePrinterContext * ctx,
+struct PrintInfo * info
+) {
+for ( char* c = info->str; *c; ++c ) {
+char C = toupper(*c);
+fwrite( , 1, 1, ctx->out );
+}
+}
+
+int main()
+{
+struct PrintInfo hello, world;
+struct UpperCasePrinterContext ctx;
+
+hello.str = "hello, ";
+world.str = "world!\n";
+
+ctx.out = stdout;
+
+print( ,  );
+print( ,  );
+
+return 0;
+}

I'm not sure this is a fitting example. Usually the context is a
public structure and the internal context (which corresponds to the
PrintInfo struct) is private to the implementation. In this case the
API user is not interested at all at its implmentation.

You can think the context provides the "object"/instance where some
operations are done - this is alike in object oriented programming,
where the context corresponds to the self, so that you create/allocate
the object, initialize it, and invoke operations on the object.

So using this analogy, the example would be:

struct UpperCasePrinterContext {...};

// this corresponds to a "method" defined on the context/object
void uppercase_printer_print(UpperCasePrinterContext *ctx, const char *str);

Or maybe you want to define the property in the context itself, so you
do:
uppercase_ctx.str = "foobar";

then you have:
void uppercase_printer_print(UpperCasePrinterContext *ctx);

On a typical FFmpeg context you typically do (see
doc/examples/encode.c example):
 // create the context
 c = avcodec_alloc_context3(codec);

 // set parameters, either in the context or by using the av_opt API
 c->bit_rate = 40;
 c->width = 352;
 c->height = 288;
 c->time_base = (AVRational){1, 25};
 c->framerate = (AVRational){25, 1};
 // ...

 // invoke the methods defined in the context
 ret = avcodec_send_frame(enc_ctx, frame);
 if (ret < 0) {
 fprintf(stderr, "Error sending a frame for encoding\n");
 exit(1);
 }

 while (ret >= 0) {
 ret = avcodec_receive_packet(enc_ctx,

Re: [FFmpeg-devel] [PATCH 2/3] lavf/mkvtimestamp_v2: review implementation to match mkvextract behavior

2024-04-20 Thread Andreas Rheinhardt

Stefano Sabatini:
> Harmonize internal implementation with the mkvextract behavior:
> - print PTS in place of DTS values
> - ignore NOPTS values
> - sort PTS values
> ---
>  libavformat/mkvtimestamp_v2.c | 69 +--
>  1 file changed, 65 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/mkvtimestamp_v2.c b/libavformat/mkvtimestamp_v2.c
> index 1eb2daf10a..c6446ed489 100644
> --- a/libavformat/mkvtimestamp_v2.c
> +++ b/libavformat/mkvtimestamp_v2.c
> @@ -22,30 +22,91 @@
>  #include "avformat.h"
>  #include "internal.h"
>  #include "mux.h"
> +#include "libavutil/qsort.h"
> +
> +#define PTSS_MAX_SIZE 128
> +#define PTSS_HALF_SIZE (PTSS_MAX_SIZE >> 1)
> +
> +struct MkvTimestampContext {
> +int64_t ptss[PTSS_MAX_SIZE];
> +size_t ptss_size;
> +};
>  
>  static int write_header(AVFormatContext *s)
>  {
> -static const char *header = "# timecode format v2\n";
> +static const char *header = "# timestamp format v2\n";
>  avio_write(s->pb, header, strlen(header));
>  avpriv_set_pts_info(s->streams[0], 64, 1, 1000);
> +
>  return 0;
>  }
>  
> +static int cmp_int64(const void *p1, const void *p2)
> +{
> +int64_t left  = *(const int64_t *)p1;
> +int64_t right = *(const int64_t *)p2;
> +return FFDIFFSIGN(left, right);
> +}
> +
>  static int write_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  char buf[256];
> +int i;
> +struct MkvTimestampContext *m = s->priv_data;
> +
>  if (pkt->stream_index)
>  av_log(s, AV_LOG_WARNING, "More than one stream unsupported\n");
> -snprintf(buf, sizeof(buf), "%" PRId64 "\n", pkt->dts);
> -avio_write(s->pb, buf, strlen(buf));
> +
> +if (pkt->pts == AV_NOPTS_VALUE) {
> +av_log(s, AV_LOG_WARNING, "Found PTS with no value, ignored\n");
> +return 0;
> +}
> +
> +if (m->ptss_size > PTSS_MAX_SIZE) {
> +// sort all PTSs
> +AV_QSORT(m->ptss, PTSS_MAX_SIZE, int64_t, cmp_int64);
> +
> +// write only the first half and copy the second half to the
> +// beginning of the array
> +for (i = 0; i < PTSS_HALF_SIZE; i++) {
> +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
> +avio_write(s->pb, buf, strlen(buf));
> +m->ptss[i] = m->ptss[i + PTSS_HALF_SIZE];
> +}
> +
> +m->ptss_size = PTSS_HALF_SIZE;
> +} else {
> +m->ptss[m->ptss_size++] = pkt->pts;
> +}
> +
> +return 0;
> +}
> +
> +static int write_trailer(struct AVFormatContext *s)
> +{
> +struct MkvTimestampContext *m = s->priv_data;
> +char buf[256];
> +int i;
> +
> +// sort all PTSs
> +AV_QSORT(m->ptss, m->ptss_size, int64_t, cmp_int64);
> +
> +/* flush remaining timestamps */
> +for (i = 0; i < m->ptss_size; i++) {
> +snprintf(buf, sizeof(buf), "%" PRId64 "\n", m->ptss[i]);
> +avio_write(s->pb, buf, strlen(buf));
> +}
> +
>  return 0;
>  }
>  
>  const FFOutputFormat ff_mkvtimestamp_v2_muxer = {
>  .p.name= "mkvtimestamp_v2",
> -.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timecode format"),
> +.p.long_name   = NULL_IF_CONFIG_SMALL("mkvtoolnix v2 timestamp format"),
>  .p.audio_codec = AV_CODEC_ID_NONE,
>  .p.video_codec = AV_CODEC_ID_RAWVIDEO,
>  .write_header = write_header,
>  .write_packet = write_packet,
> +.write_trailer = write_trailer,
> +.priv_data_size = sizeof(struct MkvTimestampContext),
>  };

1. This does not match mkvextract behaviour. mkvextract does not force a
1ms timebase.
2. AV_QSORT should only be used in speed-critical code, which this here
is definitely not.
3. I still don't think that this muxer should exist at all.

- Andreas

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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/x86/vvc/vvcdsp_init: add put prototypes

2024-04-20 Thread Nuo Mi

On Thu, Apr 18, 2024 at 2:30 AM Wu Jianhua  wrote:

> > 发件人: Nuo Mi 
> > 发送时间: 2024年4月17日 6:14
> > 收件人: FFmpeg development discussions and patches
> > 抄送: Wu Jianhua
> > 主题: Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/x86/vvc/vvcdsp_init: add
> put prototypes
> >
> > Hi Jianhua,
> > thank you for the patches.
> > could you add a log for each commit to explain why we need this commit?
>
> Sure. v3 sent.
>
Thank you. v3 applied.

>
> >
> > On Tue, Apr 16, 2024 at 1:36 AM  toq...@outlook.com>> wrote:
> > From: Wu Jianhua mailto:toq...@outlook.com>>
> >
> > Signed-off-by: Wu Jianhua mailto:toq...@outlook.com
> >>
> > ---
> >  libavcodec/x86/vvc/vvcdsp_init.c | 35 +++-
> > 1 file changed, 34 insertions(+), 1 deletion(-)
>
>
___
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 1/3] doc: Explain what "context" means

2024-04-20 Thread Andrew Sayers

On Sat, Apr 20, 2024 at 06:48:32PM +0200, Stefano Sabatini wrote:
> On date Saturday 2024-04-20 13:19:41 +0100, Andrew Sayers wrote:
> > Based largely on the explanation by Stefano Sabatini:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
> > ---
> >  doc/jargon.md | 169 ++
> >  1 file changed, 169 insertions(+)
> >  create mode 100644 doc/jargon.md
> > 
> > diff --git a/doc/jargon.md b/doc/jargon.md
> > new file mode 100644
> > index 00..f967b5c8bc
> > --- /dev/null
> > +++ b/doc/jargon.md
> > @@ -0,0 +1,169 @@
> > +# Jargon
> > +
> > +Terms used throughout the code that developers may need to know.
> > +
> > +@anchor context
> > +
> 
> > +## Context
> > +
> 
> > +A design pattern that stores the context (e.g. configuration) for a series
> > +of operations in a "context" structure, and moves other information with
> > +a longer or shorter lifetime elsewhere.
> 
> I'd skip the mention of a design pattern since this is about the
> jargon.
> 
> So a simplified variant would be:
> 
> A "context" is a a structure used to store information
> (e.g. configuration and/or internal state) for a series of operations
> working on the same data.

I think there's a pattern to the problems I'm having in this thread -
*anchoring effects*.

If you ask someone "is 5 a big number?" then "is 5 thousand a big number?",
they'll probably say "yes" to the second question.  But if you ask them
"is 5 billian a big number?" then "is 5 thousand a big number?", they'll
probably say "no".  In each case, their concept of "bigness" has been
anchored by the first question you asked.

When I originally tried to learn FFmpeg back in the day, I got nowhere with my
default OOP mindset.  It wasn't until I thought to read the examples with a
procedural mindset that it started making any sense, and I think that has
*anchored* my mental model of FFmpeg to a mindset that made it hard to think
deeply about its object-oriented bits.

Yesterday I would have agreed this was just one piece of jargon that needed
pinning down.  But if other people have similarly mis-anchored themselves,
this question might need to be a bit easier for them to find.

> 
> > +
> > +Consider a code snippet to modify text then print it:
> > +
> > +```c
> > +/**
> > + * Contextual information about printing a series of messages
> > + */
> > +struct ModifyThenPrintContext {
> > +
> > +/**
> > + * Members of the context usually are usually part of its public API...
> > + */
> > +FILE *out;
> > +
> > +/**
> > + * ... but check the documentation just in case
> > + */
> > +[[deprecated]]
> > +int no_longer_part_of_the_public_api;
> > +
> > +/**
> > + * The "internal context" is private to the context itself.
> > + *
> > + * Unlike the members above, the private context is not guaranteed
> > + * and can change arbitrarily between versions.
> > + */
> > +void* priv_data;
> > +};
> > +
> > +/**
> > + * Long-lifetime information, reused by many contexts
> > + */
> > +enum ModifyThenPrintDialect {
> > +MODIFY_THEN_PRINT_PLAIN_TEXT,
> > +MODIFY_THEN_PRINT_REGEX,
> > +MODIFY_THEN_PRINT_REGEX_PCRE
> > +};
> > +
> > +/**
> > + * Short-lifetime information, used repeatedly in a single context
> > + */
> > +struct ModifyThenPrintMessage {
> > +char *str;
> > +char *replace_this;
> > +char *with_this;
> > +};
> > +
> > +/**
> > + * Allocate and initialize a ModifyThenPrintContext
> > + *
> > + * This creates a new pointer, then fills in some sensible defaults.
> > + *
> > + * We can reasonably assume this function will initialise `priv_data`
> > + * with a dialect-specific object, but shouldn't make any assumptions
> > + * about what that object is.
> > + *
> > + */
> > +int ModifyThenPrintContext_alloc_context(struct ModifyThenPrintContext 
> > **ctx,
> > + FILE *out,
> > + enum ModifyThenPrintDialect 
> > dialect);
> > +
> > +/**
> > + * Uninitialize and deallocate a ModifyThenPrintContext
> > + *
> > + * This does any work required by the private context in `priv_data`
> > + * (e.g. deallocating it), then deallocates the main context itself.
> > + *
> > + */
> > +int ModifyThenPrintContext_free(struct ModifyThenPrintContext *ctx);
> > +
> > +/**
> > + * Print a single message
> > + */
> > +int ModifyThenPrintContext_print(struct ModifyThenPrintContext *ctx,
> > + struct ModifyThenPrintMessage *msg);
> > +
> > +int print_hello_world()
> > +{
> > +
> > +int ret = 0;
> > +
> > +struct ModifyThenPrintContext *ctx;
> > +
> > +struct ModifyThenPrintMessage hello_world;
> > +
> > +if ( ModifyThenPrintContext_alloc_context( , stdout, 
> > MODIFY_THEN_PRINT_REGEX ) < 0 ) {
> > +ret = -1;
> > +goto EXIT_WITHOUT_CLEANUP;
> > +}
> > +
> > +hello_world.replace_this = "Hi|Hullo";
> > +

[FFmpeg-devel] [PATCH 1/2] avcodec/codec_par: always clear extradata_size in avcodec_parameters_to_context()

2024-04-20 Thread James Almer

Missed in d383ae43c266b160348db04f2fd17ccf30286784.

Signed-off-by: James Almer 
---
 libavcodec/codec_par.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index 212cb97d77..790ea01d10 100644
--- a/libavcodec/codec_par.c
+++ b/libavcodec/codec_par.c
@@ -250,6 +250,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 }
 
 av_freep(>extradata);
+codec->extradata_size = 0;
 if (par->extradata) {
 codec->extradata = av_mallocz(par->extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!codec->extradata)
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH 2/2] avformat/demux: extract extradata from packets when context update is requested

2024-04-20 Thread James Almer

If the demuxer doesn't set extradata in the stream's codecpar, a
need_context_update request will delete the previously extracted extradata in
the stream's internal AVCodecContext.
As we can't ensure the old extradata is valid for the stream in its post
context update request state, try to get extradata from the new packet instead
of preserving the old in some form.

Signed-off-by: James Almer 
---
 libavformat/demux.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index abfd5fee7d..253a4783c4 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1319,6 +1319,8 @@ fail:
 return ret;
 }
 
+static int extract_extradata(FFFormatContext *si, AVStream *st, const AVPacket 
*pkt);
+
 static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
 {
 FFFormatContext *const si = ffformatcontext(s);
@@ -1373,6 +1375,11 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 return ret;
 }
 
+if (!sti->avctx->extradata &&
+(ret = extract_extradata(si, st, pkt)) < 0) {
+av_packet_unref(pkt);
+return ret;
+}
 sti->codec_desc = avcodec_descriptor_get(sti->avctx->codec_id);
 
 sti->need_context_update = 0;
@@ -2470,6 +2477,8 @@ static int extract_extradata(FFFormatContext *si, 
AVStream *st, const AVPacket *
 if (ret < 0)
 return ret;
 
+av_bsf_flush(sti->extract_extradata.bsf);
+
 ret = av_bsf_send_packet(sti->extract_extradata.bsf, pkt_ref);
 if (ret < 0) {
 av_packet_unref(pkt_ref);
-- 
2.44.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 3/5] avcodec/av1dec: Use ProgressFrames

2024-04-20 Thread James Almer


On 4/19/2024 1:07 PM, Andreas Rheinhardt wrote:

AV1 can put a frame into multiple reference slots;
up until now, this involved creating a new reference
to the underlying AVFrame; therefore av1_frame_ref()
could fail.
This commit changes this by using the ProgressFrame API
to share the underlying AVFrames.

(Hint: vaapi_av1_surface_id() checked whether the AV1Frames
contained in the AV1DecContext were NULL or not (of course
they were not); this has been changed to actually check for
whether said AV1Frame is blank or not.)

Signed-off-by: Andreas Rheinhardt 
---
1. The AV1 patches are basically untested (apart from FATE and
compilation). Could someone please test them?


I tested this and patch 4/5 with d3d11/12, cuda and vulkan. No issues.
Can't test vaapi.
___
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

2024-04-20 Thread Michael Niedermayer

On Thu, Apr 18, 2024 at 11:01:42PM +0100, Andrew Sayers wrote:
> On 18/04/2024 20:50, Michael Niedermayer wrote:
> 
> > [...]
> > > Without getting too far off-topic, I would also be interested in knowing 
> > > how
> > > docs are actually generated in practice. I've tried generating 
> > > documentation
> > its just running doxygen with a Doxyfile
> > the Doxyfile is not  doc/Doxyfile from git because that could be a security
> > issue. But its a very similar file
> > 
> > thx
> 
> Aha!  But it's running doxygen i386, right?  I've been building the docs
> with an x86_64 machine, and the links to most functions are different.
> Installing doxygen:i386 seems to fix it.
> 
> Assuming the security issue is just that people could inject arbitrary code
> into the Doxyfile, is it possible to upload that file somewhere, then
> link to it (and mention the architecture thing) from e.g. the README?
> 
> To be clear - it's definitely the right move to run a version of doxygen
> that generates links that are compatible with older releases,
> but it would have saved me some time if that was written somewhere :)

doxygen on the server is 1.8.17, amd64 architecture

The used Doxyfile is attached, someone probably should go over it and
reduce differences to what is in git master (and then send me a patch)
without breaking any past release branch
i dont have the time for that

thx

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
# Doxyfile 1.8.2

# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project.
#
# All text after a hash (#) is considered a comment and will be ignored.
# The format is:
#   TAG = value [value, ...]
# For lists items can also be appended using:
#   TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ").

#---
# Project related configuration options
#---

# This tag specifies the encoding used for all characters in the config file
# that follow. The default is UTF-8 which is also the encoding used for all
# text before the first occurrence of this tag. Doxygen uses libiconv (or the
# iconv built into libc) for the transcoding. See
# http://www.gnu.org/software/libiconv for the list of possible encodings.

DOXYFILE_ENCODING  = UTF-8

# The PROJECT_NAME tag is a single word (or sequence of words) that should
# identify the project. Note that if you do not use Doxywizard you need
# to put quotes around the project name if it contains spaces.

PROJECT_NAME   = FFmpeg

# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.

PROJECT_NUMBER =

# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer
# a quick idea about the purpose of the project. Keep the description short.

PROJECT_BRIEF  =

# With the PROJECT_LOGO tag one can specify an logo or icon that is
# included in the documentation. The maximum height of the logo should not
# exceed 55 pixels and the maximum width should not exceed 200 pixels.
# Doxygen will copy the logo to the output directory.

PROJECT_LOGO   =

# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.

OUTPUT_DIRECTORY   = doxy

# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.

CREATE_SUBDIRS = NO

# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
# Polish, Portuguese, Romanian,

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

2024-04-20 Thread Michael Niedermayer

On Fri, Apr 19, 2024 at 08:00:28PM +0200, Diederick C. Niehorster wrote:
> On Fri, Apr 19, 2024, 19:35 Zhao Zhili  wrote:
> 
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > Niklas Haas
> > > Sent: 2024年4月19日 22:50
> > > To: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> > >
> > > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> > > > A plugin system moves this patch-management to people who actually
> > > > care, that is the authors of the codecs and (de)muxers.
> > >
> > > A plugin system will only solve this insomuch as plugin authors will
> > > just host their plugin code on GitHub instead of bothering with the
> > > mailing list.
> > >
> > > I think it runs a good risk of basically killing the project.
> >
> > VLC is plugin based, gstreamer is plugin based too (which went t far
> > ),
> > I don't think plugin is that dangerous.
> >
> > Firstly, we can enable plugin interface only with enable-gpl.
> >
> > Secondly, we can have a less stable plugin interface than public API, for
> > our
> > development convenience, and encourage plugin authors to contribute to
> > upstream.
> >
> > >
> > > > Our productivity as is, is not good, many patches are ignored.
> > > > The people caring about these patches are their Authors and yet they
> > > > are powerless as they must sometimes wait many months for reviews
> > >
> > > So, rather than all of the above, what I think we should do is contract
> > > somebody to set up, manage, host and maintain a GitLab instance for us.
> > >
> > > This would probably be the single most cost effective boost to both
> > > community growth and innovation I can think of, as it will remove
> > > several of the major grievances and barriers to entry with the
> > > ML+pingspam model.
> >
> > +1.
> >
> > I can't remember how many patches I have ping. It's really frustration.
> > I ask for permission to commit mostly due to this.
> >
> > Now I can keep track of my own patches, but it's still not easy to filter
> > out
> > patches I'm interested to review (I can blame the email client, but blame
> > it
> > doesn't help). I'm sure I can review more patches with a new workflow.
> >
> 
> If i recall correctly, there was a conversation not too long ago about what
> to do with all the SPI money. This seems to be a perfect use for it.

> 1. Set up and manage a gitlab instance

I think we first need to understand what exact problem there is with the
ML/Patchwork workflow. Write this down. See if we all agree on that

Look at what workflow* people use
Look at what alternatives to ML/Patchwork there are
I think others than gitlab where suggested like gittea and forgejo

And then carefully evaluate each for cost vs benefit.

If we agree on one then its probably best to setup a small test environment
and have the whole team try to use that before we consider a switch


> 2. Move tickets from trac to there (possibly)

why ?


> 3. Move fate running to there

why ?


workflow*
For example, i go through patches on the ML with mutt and i have one key
to apply a patch and another to open an editor and write a reply. Also i 
have
my muttrc setup so it colorizes diffs nicely so patches are easy to review
I do test close to every patch posted on ffmpeg-devel, so being able
to quickly apply patches matters. If i had to use a GUI based browser
and click around with the mouse it would probably mean an end for me
testing all patches, simply as it would be too inconvenient and slow.

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

[FFmpeg-devel] Fix for [ffmpeg] spdif: Unusual frame timing 40 samples/frame is not implemented.

2024-04-20 Thread Adolfo Rodrigues

Hello.

I'm new at this so please bare with me. I have created a sample file that
produces an audio drop at the same time it produces the following message:

[ffmpeg] spdif: Unusual frame timing: 10248 => 12042, 40 samples/frame is
not implemented. Update your FFmpeg version to the newest one from Git. If
the problem still occurs, it means that your file has a feature which has
not been implemented.

sample file -> https://tregosacloud.duckdns.org/s/HRWxz7oX7HCSSpD

The same message shows up when I seek but with the added side effect of
audio rarely recovering, becoming silent.

I found out that by editing the file spdifenc.c and commenting out:

   /* sanity check */
//if (padding_remaining < 0 || padding_remaining >= MAT_FRAME_SIZE / 2)
{
//avpriv_request_sample(s, "Unusual frame timing: %"PRIu16" =>
%"PRIu16", %d samples/frame",
//  ctx->truehd_prev_time, input_timing,
ctx->truehd_samples_per_frame);
//padding_remaining = 0;
   // }

All my issues went away.

I have opened a ffmpeg trac ticket:  https://trac.ffmpeg.org/ticket/10948

I'm no developer, my knowledge is very limited but I since I have yet to
find any negative symptom of my change I'm leaving here my findings.

Thank you for your time.

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

41 matches

Mail list logo