Re: [FFmpeg-devel] [PATCH 7/8] avfilter/vf_scale: tag output color space
On Fri, Oct 27, 2023 at 10:06 AM Niklas Haas wrote: > From: Niklas Haas > > When using vf_scale to force a specific output color space, also tag > this on the AVFrame. (Mirroring existing logic for output range) > --- > libavfilter/vf_scale.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c > index 4a2f0bd1f1..d79d67c413 100644 > --- a/libavfilter/vf_scale.c > +++ b/libavfilter/vf_scale.c > @@ -821,6 +821,9 @@ scale: > out->width = outlink->w; > out->height = outlink->h; > out->color_range = out_full ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG; > +if (scale->out_color_matrix >= 0 && > +scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED) > +out->colorspace = scale->out_color_matrix; > what about the other color properties? -- Vittorio ___ 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/8] avfilter/vf_extractplanes: tag alpha plane as full range
On Fri, Oct 27, 2023 at 10:05 AM Niklas Haas wrote: > From: Niklas Haas > > Alpha planes are explicitly full range, even for limited range YUVA > formats. Mark them as such. > --- > libavfilter/vf_extractplanes.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavfilter/vf_extractplanes.c > b/libavfilter/vf_extractplanes.c > index 7b7149ab24..ca406ff323 100644 > --- a/libavfilter/vf_extractplanes.c > +++ b/libavfilter/vf_extractplanes.c > @@ -312,6 +312,8 @@ static int extract_plane(AVFilterLink *outlink, > AVFrame *frame) > if (!out) > return AVERROR(ENOMEM); > av_frame_copy_props(out, frame); > +if (idx == 3 /* alpha */) > +out->color_range = AVCOL_RANGE_JPEG; > this might be overkill, but do you think the check here should be made more generic, in case the alpha plane is not in position #3? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Fri, Oct 27, 2023 at 7:54 PM Nicolas George wrote: > Paul B Mahol (12023-10-27): > > As OOM scenarios are bad, will apply this fix soon. > > This bug, if it is a bug, has been here for quite some time already, a > few days more will not change anything. I want to analyze this properly, > do not push before please. > I did proper analysis already. Pushed. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/libvmaf: fix broken cuda build
On Tue, Oct 24, 2023 at 1:56 PM Kyle Swanson wrote: > I broke the libvmaf_cuda build after > 6028728bb829c04cc68c66c846c75a70bf4c0613. Fix is attached. I will > merge this patch soon. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] swscale: fix sws_setColorspaceDetails after sws_init_context
On Fri, Oct 27, 2023 at 07:04:39PM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> More commonly, this fixes the case of sws_setColorspaceDetails after
> sws_getContext, since the latter implies sws_init_context.
>
> The problem here is that sws_init_context sets up the range conversion
> and fast path tables based on the values of srcRange/dstRange at init
> time. This may result in locking in a "wrong" path (either using
> unscaled fast path when range conversion later required, or using
> scaled slow path when range conversion becomes no longer required).
>
> There are two way outs:
>
> 1. Always initialize range conversion and unscaled converters, even if
>they will be unused, and extend the runtime check.
> 2. Re-do initialization if the values change after
>sws_setColorspaceDetails.
>
> I opted for approach 1 because it was simpler and easier to reason
> about.
> ---
> libswscale/swscale.c | 2 +-
> libswscale/utils.c | 5 +
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/libswscale/swscale.c b/libswscale/swscale.c
> index 90e5b299ab..46ba68fe6a 100644
> --- a/libswscale/swscale.c
> +++ b/libswscale/swscale.c
> @@ -1016,7 +1016,7 @@ static int scale_internal(SwsContext *c,
> reset_ptr(src2, c->srcFormat);
> reset_ptr((void*)dst2, c->dstFormat);
>
> -if (c->convert_unscaled) {
> +if (c->convert_unscaled && !c->lumConvertRange && !c->chrConvertRange) {
> int offset = srcSliceY_internal;
> int slice_h = srcSliceH;
>
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index e1ad685972..455955e907 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -1728,9 +1728,7 @@ static av_cold int sws_init_single_context(SwsContext
> *c, SwsFilter *srcFilter,
> }
>
> /* unscaled special cases */
> -if (unscaled && !usesHFilter && !usesVFilter &&
> -(c->srcRange == c->dstRange || isAnyRGB(dstFormat) ||
> - isFloat(srcFormat) || isFloat(dstFormat))){
> +if (unscaled && !usesHFilter && !usesVFilter) {
> ff_get_unscaled_swscale(c);
>
> if (c->convert_unscaled) {
> @@ -1738,7 +1736,6 @@ static av_cold int sws_init_single_context(SwsContext
> *c, SwsFilter *srcFilter,
> av_log(c, AV_LOG_INFO,
> "using unscaled %s -> %s special converter\n",
> av_get_pix_fmt_name(srcFormat),
> av_get_pix_fmt_name(dstFormat));
> -return 0;
> }
> }
the av_log() message will be wrong if this path is unused
also this ties convert_unscaled to never do range conversion, if thats
intended, i guess thats ok. Otherwise that maybe is a restriction
we dont want to add.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: Move lrint outside of loop
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..e59a38b497 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1538,7 +1538,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
{
HLSContext *hls = s->priv_data;
HLSSegment *en;
-int target_duration = 0;
+double target_duration = 0;
int ret = 0;
char temp_filename[MAX_URL_SIZE];
char temp_vtt_filename[MAX_URL_SIZE];
@@ -1589,12 +1589,12 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
for (en = vs->segments; en; en = en->next) {
if (target_duration <= en->duration)
-target_duration = lrint(en->duration);
+target_duration = en->duration;
}
vs->discontinuity_set = 0;
ff_hls_write_playlist_header(byterange_mode ? hls->m3u8_out : vs->out,
hls->version, hls->allowcache,
- target_duration, sequence, hls->pl_type,
hls->flags & HLS_I_FRAMES_ONLY);
+ lrint(target_duration), sequence,
hls->pl_type, hls->flags & HLS_I_FRAMES_ONLY);
if ((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence &&
vs->discontinuity_set==0) {
avio_printf(byterange_mode ? hls->m3u8_out : vs->out,
"#EXT-X-DISCONTINUITY\n");
@@ -1643,7 +1643,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
goto fail;
}
ff_hls_write_playlist_header(hls->sub_m3u8_out, hls->version,
hls->allowcache,
- target_duration, sequence,
PLAYLIST_TYPE_NONE, 0);
+ lrint(target_duration), sequence,
PLAYLIST_TYPE_NONE, 0);
for (en = vs->segments; en; en = en->next) {
ret = ff_hls_write_file_entry(hls->sub_m3u8_out, 0, byterange_mode,
en->duration, 0, en->size, en->pos,
--
2.39.2 (Apple Git-143)
___
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/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On Fri, Oct 27, 2023 at 4:58 AM wrote:
> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> > @item second_level_segment_index
> > Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> > besides date/time values when strftime is on.
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 4ef84c05c1..5dfff6b2b6 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -212,6 +212,8 @@ typedef struct HLSContext {
> > int64_t recording_time;
> > int64_t max_seg_size; // every segment file max size
> >
> > +char *init_program_date_time;
> > +
> > char *baseurl;
> > char *vtt_format_options_str;
> > char *subtitle_filename;
> > @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct
> AVFormatContext *s, HLSContext *hls,
> > return 0;
> > }
> >
> > +static double parse_iso8601(const char *ptr) {
> > +struct tm program_date_time;
> > +int y,M,d,h,m,s;
> > +double ms;
> > +if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", , , , , , ,
> ) != 7) {
> > +return -1;
> > +}
> > +
> > +program_date_time.tm_year = y - 1900;
> > +program_date_time.tm_mon = M - 1;
> > +program_date_time.tm_mday = d;
> > +program_date_time.tm_hour = h;
> > +program_date_time.tm_min = m;
> > +program_date_time.tm_sec = s;
> > +program_date_time.tm_isdst = -1;
> > +
> > +return mktime(_date_time) + (double)(ms / 1000);
> > +}
> > +
> > static int parse_playlist(AVFormatContext *s, const char *url,
> VariantStream *vs)
> > {
> > HLSContext *hls = s->priv_data;
> > @@ -1257,24 +1278,11 @@ static int parse_playlist(AVFormatContext *s,
> const char *url, VariantStream *vs
> > }
> > }
> > } else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:",
> )) {
> > -struct tm program_date_time;
> > -int y,M,d,h,m,s;
> > -double ms;
> > -if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", , , , ,
> , , ) != 7) {
> > +discont_program_date_time = parse_iso8601(ptr);
> > +if (discont_program_date_time < 0) {
> > ret = AVERROR_INVALIDDATA;
> > goto fail;
> > }
> > -
> > -program_date_time.tm_year = y - 1900;
> > -program_date_time.tm_mon = M - 1;
> > -program_date_time.tm_mday = d;
> > -program_date_time.tm_hour = h;
> > -program_date_time.tm_min = m;
> > -program_date_time.tm_sec = s;
> > -program_date_time.tm_isdst = -1;
> > -
> > -discont_program_date_time = mktime(_date_time);
> > -discont_program_date_time += (double)(ms / 1000);
> > } else if (av_strstart(line, "#", NULL)) {
> > continue;
> > } else if (line[0]) {
> > @@ -2867,7 +2875,7 @@ static int hls_init(AVFormatContext *s)
> > char *p = NULL;
> > int http_base_proto = ff_is_http_proto(s->url);
> > int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> > -double initial_program_date_time = av_gettime() / 100.0;
> > +double initial_program_date_time = hls->init_program_date_time ?
> parse_iso8601(hls->init_program_date_time) : av_gettime() / 100.0;
>
> As parse_iso8601 parsing user input can fail, it should properly report
> the error and fail. Especially given that it does not accept all variations
> of ISO-8601 date/time IIUC.
>
> It might be confusing if the user specifies a time, forgets the
> milliseconds and it will just silently not use the option at all?
>
I added improved parsing and error reporting. I sent in the patch, but is
there a way for me to tie it to this patchset in the future?
___
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/8] avfilter/vf_alphamerge: warn if input not full range
On Fri, Oct 27, 2023 at 07:04:41PM +0200, Niklas Haas wrote: > From: Niklas Haas > > Alpha planes must always be full range, so complain loudly if fed > limited range grayscale input. > --- > libavfilter/vf_alphamerge.c | 6 ++ > 1 file changed, 6 insertions(+) should be ok [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: Handle when fractional seconds not set and error out when init_program_date_time can't be parsed
---
libavformat/hlsenc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f613e35984..e1714d4eed 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1253,9 +1253,11 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls,
static double parse_iso8601(const char *ptr) {
struct tm program_date_time;
-int y,M,d,h,m,s;
-double ms;
-if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", , , , , , , ) !=
7) {
+int y,M,d,h,m;
+double s;
+int num_scanned = sscanf(ptr, "%d-%d-%dT%d:%d:%lf", , , , , ,
);
+
+if (num_scanned < 6) {
return -1;
}
@@ -1264,10 +1266,10 @@ static double parse_iso8601(const char *ptr) {
program_date_time.tm_mday = d;
program_date_time.tm_hour = h;
program_date_time.tm_min = m;
-program_date_time.tm_sec = s;
+program_date_time.tm_sec = 0;
program_date_time.tm_isdst = -1;
-return mktime(_date_time) + (double)(ms / 1000);
+return mktime(_date_time) + s;
}
static int parse_playlist(AVFormatContext *s, const char *url, VariantStream
*vs)
@@ -2937,7 +2939,17 @@ static int hls_init(AVFormatContext *s)
char *p = NULL;
int http_base_proto = ff_is_http_proto(s->url);
int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
-double initial_program_date_time = hls->init_program_date_time ?
parse_iso8601(hls->init_program_date_time) : av_gettime() / 100.0;
+double initial_program_date_time;
+
+if (hls->init_program_date_time) {
+initial_program_date_time = parse_iso8601(hls->init_program_date_time);
+if (initial_program_date_time < 0) {
+av_log(s, AV_LOG_ERROR, "Invalid init_program_date_time\n");
+return AVERROR(EINVAL);
+}
+} else {
+initial_program_date_time = av_gettime() / 100.0;
+}
if (hls->use_localtime) {
pattern = get_default_pattern_localtime_fmt(s);
@@ -3216,7 +3228,7 @@ static const AVOption options[] = {
{"split_by_time", "split the hls segment by time which user set by
hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX, E,
"flags"},
{"append_list", "append the new segments into old hls segment list", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
{"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0, AV_OPT_TYPE_CONST,
{.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E, "flags"},
-{"init_program_date_time", "Time to start program date time at",
OFFSET(init_program_date_time), AV_OPT_TYPE_STRING, .flags = E},
+{"init_program_date_time", "Time to start program date time at (must be
%Y-%m-%dT%H:%M:%S and timezone is ignored)", OFFSET(init_program_date_time),
AV_OPT_TYPE_STRING, .flags = E},
{"second_level_segment_index", "include segment index in segment filenames
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX, E, "flags"},
{"second_level_segment_duration", "include segment duration in segment
filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX, E, "flags"},
{"second_level_segment_size", "include segment size in segment filenames
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX, E, "flags"},
--
2.39.2 (Apple Git-143)
___
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/8] avfilter/vf_scale: properly respect to input colorimetry
On Fri, Oct 27, 2023 at 07:04:42PM +0200, Niklas Haas wrote: > From: Niklas Haas > > This code, as written, skips sws_init_context if scale->in_range was not > set, even if scale->in_frame_range is set to something. So this would > hit the 'no sws context' fast path in scale_frame and skip color range > conversion even where technically required. This had the effect of, in > practice, effectively applying limited/full range conversion if and only > if you set e.g. a nonzero yuv color matrix, which is obviously > undesirable behavior. > > Second, the assignment of out->color_range inside the branch would fail > to properly propagate tags for any actually applied conversion, for > example on conversion to a forced full range format. > > Solve both of these problems and make the code much easier to understand > and follow by doing the following: > > 1. Always initialize sws context on get_props > 2. Always use sws_getColorspaceDetails + sws_setColorspaceDetails to >fix the conversion matrices per-frame. > 3. Rather than testing if the context exists, do the no-op test after >settling the above values and deciding what conversion to actually >perform. > --- > libavfilter/vf_scale.c | 186 + > 1 file changed, 76 insertions(+), 110 deletions(-) This breaks tickets/2939/lena.jpg (color looks slightly wrong compared to reference lena image) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v4: overwrite + note about vaMapBuffer libva fallback
libavutil/hwcontext_vaapi.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..435f10a7f3 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ)
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
instead.
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote: > David Johansen 于2023年10月27日周五 12:03写道： > > > > > > > > LGTM > > > > > > > > > Thanks > > > Steven > > > > > > > I'm new to ffmpeg development so what's the process for this to be > merged? > > Do I need to do something or is it taken care of by a different > > process/someone else? > > Nothing, just leave enough time for more developers review, and will > push this if no more comments. > Don't worry David, this is valuable patch, you did a great job. > Great! Just wanted to make sure I was doing everything needed to get it merged in. Thanks, Dave ___ 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] avcodec/evc_parse: remove pow() and log2()
On Fri, Oct 27, 2023 at 10:15:49AM +0200, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: czwartek, 5 października 2023 00:59
> > To: FFmpeg development discussions and patches
> > Subject: [FFmpeg-devel] [PATCH 3/4] avcodec/evc_parse: remove pow() and
> > log2()
> >
> > The use of float based functions is both unneeded and wrong due to
> > unpredictable rounding
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/evc_parse.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> > 5ab33166cf3..20b6849041a 100644
> > --- a/libavcodec/evc_parse.c
> > +++ b/libavcodec/evc_parse.c
> > @@ -176,7 +176,8 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> > EVCParserSliceHeader *sh,
> > poc->PicOrderCntVal = 0;
> > poc->DocOffset = -1;
> > } else {
> > -int SubGopLength = (int)pow(2.0, sps->log2_sub_gop_length);
> > +int SubGopLength = 1 << sps->log2_sub_gop_length;
> > +
> > if (tid == 0) {
> > poc->PicOrderCntVal = poc->prevPicOrderCntVal +
> SubGopLength;
> > poc->DocOffset = 0;
> > @@ -191,15 +192,16 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> > EVCParserSliceHeader *sh,
> > poc->prevPicOrderCntVal += SubGopLength;
> > ExpectedTemporalId = 0;
> > } else
> > -ExpectedTemporalId = 1 + (int)log2(poc->DocOffset);
> > +ExpectedTemporalId = 1 + av_log2(poc->DocOffset);
> > +
> > while (tid != ExpectedTemporalId) {
> > poc->DocOffset = (poc->DocOffset + 1) % SubGopLength;
> > if (poc->DocOffset == 0)
> > ExpectedTemporalId = 0;
> > else
> > -ExpectedTemporalId = 1 +
> (int)log2(poc->DocOffset);
> > +ExpectedTemporalId = 1 +
> > + av_log2(poc->DocOffset);
> > }
> > -PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset +
> 1) /
> > (int)pow(2.0, tid) - 2));
> > +PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset
> > + + 1) / (1 << tid) - 2));
> > poc->PicOrderCntVal = poc->prevPicOrderCntVal +
> PocOffset;
> > }
> > }
> > --
> > 2.17.1
> >
> Reviewed. Looks good. It can be merged.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check num_remaining_tiles_in_slice_minus1
On Fri, Oct 27, 2023 at 10:07:38AM +0200, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: czwartek, 5 października 2023 00:59
> > To: FFmpeg development discussions and patches
> > Subject: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check
> > num_remaining_tiles_in_slice_minus1
> >
> > Fixes: out of array access
> > Fixes: 62467/clusterfuzz-testcase-minimized-
> > ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688
> >
> > Found-by: continuous fuzzing process
> > https://protect2.fireeye.com/v1/url?k=10fdc12a-701f5c77-10fc4a65-
> > 000babd9f1ba-c93ee30773aca891=1=409cddd0-bda7-445c-b76b-
> > 1caf069ec3f8=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> > fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/evc_parse.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> > bd3a4416f2d..5ab33166cf3 100644
> > --- a/libavcodec/evc_parse.c
> > +++ b/libavcodec/evc_parse.c
> > @@ -58,8 +58,12 @@ int ff_evc_parse_slice_header(GetBitContext *gb,
> > EVCParserSliceHeader *sh,
> > if (!sh->arbitrary_slice_flag)
> > sh->last_tile_id = get_bits(gb, pps->tile_id_len_minus1 + 1);
> > else {
> > -sh->num_remaining_tiles_in_slice_minus1 =
> get_ue_golomb_long(gb);
> > -num_tiles_in_slice = sh->num_remaining_tiles_in_slice_minus1
> + 2;
> > +unsigned num_remaining_tiles_in_slice_minus1 =
> > get_ue_golomb_long(gb);
> > +if (num_remaining_tiles_in_slice_minus1 > EVC_MAX_TILE_ROWS *
> > EVC_MAX_TILE_COLUMNS - 2)
> > +return AVERROR_INVALIDDATA;
> > +
> > +num_tiles_in_slice = num_remaining_tiles_in_slice_minus1 + 2;
> > +sh->num_remaining_tiles_in_slice_minus1 =
> > + num_remaining_tiles_in_slice_minus1;
> > for (int i = 0; i < num_tiles_in_slice - 1; ++i)
> > sh->delta_tile_id_minus1[i] = get_ue_golomb_long(gb);
> > }
> > --
> > 2.17.1
> >
>
> Reviewed and tested. It can be merged.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] lavc/idctdsp: improve R-V V put_pixels_clamped
--- libavcodec/riscv/idctdsp_rvv.S | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/libavcodec/riscv/idctdsp_rvv.S b/libavcodec/riscv/idctdsp_rvv.S index fafdddb174..e93e6b5e7a 100644 --- a/libavcodec/riscv/idctdsp_rvv.S +++ b/libavcodec/riscv/idctdsp_rvv.S @@ -20,24 +20,17 @@ #include "libavutil/riscv/asm.S" -func ff_put_pixels_clamped_rvv, zve32x -vsetivlizero, 8, e16, m1, ta, ma -vlseg8e16.v v24, (a0) +func ff_put_pixels_clamped_rvv, zve64x +li t0, 8 * 8 +vsetvli zero, t0, e16, m8, ta, ma +vle16.v v24, (a0) /* RVV only has signed-signed and unsigned-unsigned clipping. * We need two steps for signed-to-unsigned clipping. */ -vsetvli t0, zero, e16, m8, ta, ma -vmax.vx v24, v24, zero - -vsetivlizero, 8, e8, mf2, ta, ma -vnclipu.wi v16, v24, 0 -vnclipu.wi v17, v25, 0 -vnclipu.wi v18, v26, 0 -vnclipu.wi v19, v27, 0 -vnclipu.wi v20, v28, 0 -vnclipu.wi v21, v29, 0 -vnclipu.wi v22, v30, 0 -vnclipu.wi v23, v31, 0 -vssseg8e8.v v16, (a1), a2 +vmax.vx v24, v24, zero +vsetvli zero, zero, e8, m4, ta, ma +vnclipu.wi v16, v24, 0 +vsetivli zero, 8, e8, mf2, ta, ma +vsse64.v v16, (a1), a2 ret endfunc -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] lavc/idctdsp: improve R-V V add_pixels_clamped
--- libavcodec/riscv/idctdsp_rvv.S | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/libavcodec/riscv/idctdsp_rvv.S b/libavcodec/riscv/idctdsp_rvv.S index 4ff72f48d2..fafdddb174 100644 --- a/libavcodec/riscv/idctdsp_rvv.S +++ b/libavcodec/riscv/idctdsp_rvv.S @@ -23,7 +23,6 @@ func ff_put_pixels_clamped_rvv, zve32x vsetivlizero, 8, e16, m1, ta, ma vlseg8e16.v v24, (a0) -1: /* RVV only has signed-signed and unsigned-unsigned clipping. * We need two steps for signed-to-unsigned clipping. */ vsetvli t0, zero, e16, m8, ta, ma @@ -54,17 +53,18 @@ func ff_put_signed_pixels_clamped_rvv, zve64x ret endfunc -func ff_add_pixels_clamped_rvv, zve32x -vsetivlizero, 8, e8, mf2, ta, ma -vlseg8e16.v v24, (a0) -vlsseg8e8.v v16, (a1), a2 -vwaddu.wv v24, v24, v16 -vwaddu.wv v25, v25, v17 -vwaddu.wv v26, v26, v18 -vwaddu.wv v27, v27, v19 -vwaddu.wv v28, v28, v20 -vwaddu.wv v29, v29, v21 -vwaddu.wv v30, v30, v22 -vwaddu.wv v31, v31, v23 -j 1b +func ff_add_pixels_clamped_rvv, zve64x +vsetivli zero, 8, e8, mf2, ta, ma +li t0, 8 * 8 +vlse64.v v16, (a1), a2 +vsetvli zero, t0, e8, m4, ta, ma +vle16.v v24, (a0) +vwaddu.wv v24, v24, v16 +vsetvli zero, zero, e16, m8, ta, ma +vmax.vx v24, v24, zero +vsetvli zero, zero, e8, m4, ta, ma +vnclipu.wi v16, v24, 0 +vsetivli zero, 8, e8, mf2, ta, ma +vsse64.v v16, (a1), a2 +ret endfunc -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] lavc/idctdsp: improve R-V V put_signed_pixels_clamped
This follows the same idea as with pixblockdsp, but applied at the other end, whilst writing data at the end of the function. --- libavcodec/riscv/idctdsp_rvv.S | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/libavcodec/riscv/idctdsp_rvv.S b/libavcodec/riscv/idctdsp_rvv.S index 06e64e6529..4ff72f48d2 100644 --- a/libavcodec/riscv/idctdsp_rvv.S +++ b/libavcodec/riscv/idctdsp_rvv.S @@ -42,24 +42,15 @@ func ff_put_pixels_clamped_rvv, zve32x ret endfunc -func ff_put_signed_pixels_clamped_rvv, zve32x -vsetivlizero, 8, e16, m1, ta, ma -vlseg8e16.v v24, (a0) - -li t1, 128 -vsetivlizero, 8, e8, mf2, ta, ma -vnclip.wi v16, v24, 0 -vnclip.wi v17, v25, 0 -vnclip.wi v18, v26, 0 -vnclip.wi v19, v27, 0 -vnclip.wi v20, v28, 0 -vnclip.wi v21, v29, 0 -vnclip.wi v22, v30, 0 -vnclip.wi v23, v31, 0 -vsetvli t0, zero, e8, m8, ta, ma -vadd.vx v16, v16, t1 -vsetivlizero, 8, e8, mf2, ta, ma -vssseg8e8.v v16, (a1), a2 +func ff_put_signed_pixels_clamped_rvv, zve64x +li t0, 8 * 8 +vsetvli zero, t0, e8, m4, ta, ma +vle16.v v24, (a0) +li t1, 128 +vnclip.wi v16, v24, 0 +vadd.vx v16, v16, t1 +vsetivli zero, 8, e8, mf2, ta, ma +vsse64.v v16, (a1), a2 ret endfunc -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] lavc/idctdsp: require Zve64x for R-V V functions
This will be required for the following changesets.
---
libavcodec/riscv/idctdsp_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/riscv/idctdsp_init.c b/libavcodec/riscv/idctdsp_init.c
index e6e616a555..4106d90c55 100644
--- a/libavcodec/riscv/idctdsp_init.c
+++ b/libavcodec/riscv/idctdsp_init.c
@@ -39,7 +39,7 @@ av_cold void ff_idctdsp_init_riscv(IDCTDSPContext *c,
AVCodecContext *avctx,
#if HAVE_RVV
int flags = av_get_cpu_flags();
-if ((flags & AV_CPU_FLAG_RVV_I32) && ff_get_rv_vlenb() >= 16) {
+if ((flags & AV_CPU_FLAG_RVV_I64) && ff_get_rv_vlenb() >= 16) {
c->put_pixels_clamped = ff_put_pixels_clamped_rvv;
c->put_signed_pixels_clamped = ff_put_signed_pixels_clamped_rvv;
c->add_pixels_clamped = ff_add_pixels_clamped_rvv;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/6] lavc/pixblockdsp: rename unaligned R-V V functions
---
libavcodec/riscv/pixblockdsp_init.c | 26 +++---
libavcodec/riscv/pixblockdsp_rvv.S | 6 +++---
2 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/libavcodec/riscv/pixblockdsp_init.c
b/libavcodec/riscv/pixblockdsp_init.c
index aa39a8a665..8f24281217 100644
--- a/libavcodec/riscv/pixblockdsp_init.c
+++ b/libavcodec/riscv/pixblockdsp_init.c
@@ -32,12 +32,12 @@ void ff_get_pixels_8_rvi(int16_t *block, const uint8_t
*pixels,
void ff_get_pixels_16_rvi(int16_t *block, const uint8_t *pixels,
ptrdiff_t stride);
-void ff_get_pixels_8_rvv(int16_t *block, const uint8_t *pixels,
- ptrdiff_t stride);
-void ff_get_pixels_16_rvv(int16_t *block, const uint8_t *pixels,
- ptrdiff_t stride);
-void ff_diff_pixels_rvv(int16_t *block, const uint8_t *s1, const uint8_t *s2,
-ptrdiff_t stride);
+void ff_get_pixels_unaligned_8_rvv(int16_t *block, const uint8_t *pixels,
+ ptrdiff_t stride);
+void ff_get_pixels_unaligned_16_rvv(int16_t *block, const uint8_t *pixels,
+ptrdiff_t stride);
+void ff_diff_pixels_unaligned_rvv(int16_t *block, const uint8_t *s1,
+ const uint8_t *s2, ptrdiff_t stride);
av_cold void ff_pixblockdsp_init_riscv(PixblockDSPContext *c,
AVCodecContext *avctx,
@@ -54,12 +54,16 @@ av_cold void ff_pixblockdsp_init_riscv(PixblockDSPContext
*c,
#if HAVE_RVV
if ((cpu_flags & AV_CPU_FLAG_RVV_I32) && ff_get_rv_vlenb() >= 16) {
-if (high_bit_depth)
-c->get_pixels_unaligned = c->get_pixels = ff_get_pixels_16_rvv;
-else
-c->get_pixels_unaligned = c->get_pixels = ff_get_pixels_8_rvv;
+if (high_bit_depth) {
+c->get_pixels = ff_get_pixels_unaligned_16_rvv;
+c->get_pixels_unaligned = ff_get_pixels_unaligned_16_rvv;
+} else {
+c->get_pixels = ff_get_pixels_unaligned_8_rvv;
+c->get_pixels_unaligned = ff_get_pixels_unaligned_8_rvv;
+}
-c->diff_pixels_unaligned = c->diff_pixels = ff_diff_pixels_rvv;
+c->diff_pixels = ff_diff_pixels_unaligned_rvv;
+c->diff_pixels_unaligned = ff_diff_pixels_unaligned_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/pixblockdsp_rvv.S
b/libavcodec/riscv/pixblockdsp_rvv.S
index 1a364e6dab..e3a2fcc6ef 100644
--- a/libavcodec/riscv/pixblockdsp_rvv.S
+++ b/libavcodec/riscv/pixblockdsp_rvv.S
@@ -20,7 +20,7 @@
#include "libavutil/riscv/asm.S"
-func ff_get_pixels_8_rvv, zve32x
+func ff_get_pixels_unaligned_8_rvv, zve32x
vsetivli zero, 8, e8, mf2, ta, ma
vlsseg8e8.v v16, (a1), a2
vwcvtu.x.x.v v8, v16
@@ -35,14 +35,14 @@ func ff_get_pixels_8_rvv, zve32x
ret
endfunc
-func ff_get_pixels_16_rvv, zve32x
+func ff_get_pixels_unaligned_16_rvv, zve32x
vsetivli zero, 8, e16, m1, ta, ma
vlsseg8e16.v v0, (a1), a2
vsseg8e16.v v0, (a0)
ret
endfunc
-func ff_diff_pixels_rvv, zve32x
+func ff_diff_pixels_unaligned_rvv, zve32x
vsetivlizero, 8, e8, mf2, ta, ma
vlsseg8e8.v v16, (a1), a3
vlsseg8e8.v v24, (a2), a3
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] lavc/pixblockdsp: aligned R-V V 8-bit functions
If the scan lines are aligned, we can load each row as a 64-bit value,
thus avoiding segmentation. And then we can factor the conversion or
subtraction.
In principle, the same optimisation should be possible for high depth,
but would require 128-bit elements, for which no FFmpeg CPU flag
exists.
---
libavcodec/riscv/pixblockdsp_init.c | 11 +++
libavcodec/riscv/pixblockdsp_rvv.S | 21 +
2 files changed, 32 insertions(+)
diff --git a/libavcodec/riscv/pixblockdsp_init.c
b/libavcodec/riscv/pixblockdsp_init.c
index 8f24281217..7d259a032f 100644
--- a/libavcodec/riscv/pixblockdsp_init.c
+++ b/libavcodec/riscv/pixblockdsp_init.c
@@ -32,10 +32,14 @@ void ff_get_pixels_8_rvi(int16_t *block, const uint8_t
*pixels,
void ff_get_pixels_16_rvi(int16_t *block, const uint8_t *pixels,
ptrdiff_t stride);
+void ff_get_pixels_8_rvv(int16_t *block, const uint8_t *pixels,
+ ptrdiff_t stride);
void ff_get_pixels_unaligned_8_rvv(int16_t *block, const uint8_t *pixels,
ptrdiff_t stride);
void ff_get_pixels_unaligned_16_rvv(int16_t *block, const uint8_t *pixels,
ptrdiff_t stride);
+void ff_diff_pixels_rvv(int16_t *block, const uint8_t *s1,
+const uint8_t *s2, ptrdiff_t stride);
void ff_diff_pixels_unaligned_rvv(int16_t *block, const uint8_t *s1,
const uint8_t *s2, ptrdiff_t stride);
@@ -64,6 +68,13 @@ av_cold void ff_pixblockdsp_init_riscv(PixblockDSPContext *c,
c->diff_pixels = ff_diff_pixels_unaligned_rvv;
c->diff_pixels_unaligned = ff_diff_pixels_unaligned_rvv;
+
+if (cpu_flags & AV_CPU_FLAG_RVV_I64) {
+if (!high_bit_depth)
+c->get_pixels = ff_get_pixels_8_rvv;
+
+c->diff_pixels = ff_diff_pixels_rvv;
+}
}
#endif
}
diff --git a/libavcodec/riscv/pixblockdsp_rvv.S
b/libavcodec/riscv/pixblockdsp_rvv.S
index e3a2fcc6ef..80c7415acf 100644
--- a/libavcodec/riscv/pixblockdsp_rvv.S
+++ b/libavcodec/riscv/pixblockdsp_rvv.S
@@ -20,6 +20,16 @@
#include "libavutil/riscv/asm.S"
+func ff_get_pixels_8_rvv, zve64x
+vsetivli zero, 8, e8, mf2, ta, ma
+li t0, 8 * 8
+vlse64.v v16, (a1), a2
+vsetvli zero, t0, e8, m4, ta, ma
+vwcvtu.x.x.v v8, v16
+vse16.v v8, (a0)
+ret
+endfunc
+
func ff_get_pixels_unaligned_8_rvv, zve32x
vsetivli zero, 8, e8, mf2, ta, ma
vlsseg8e8.v v16, (a1), a2
@@ -42,6 +52,17 @@ func ff_get_pixels_unaligned_16_rvv, zve32x
ret
endfunc
+func ff_diff_pixels_rvv, zve64x
+vsetivli zero, 8, e8, mf2, ta, ma
+li t0, 8 * 8
+vlse64.v v16, (a1), a3
+vlse64.v v24, (a2), a3
+vsetvli zero, t0, e8, m4, ta, ma
+vwsubu.vv v8, v16, v24
+vse16.v v8, (a0)
+ret
+endfunc
+
func ff_diff_pixels_unaligned_rvv, zve32x
vsetivlizero, 8, e8, mf2, ta, ma
vlsseg8e8.v v16, (a1), a3
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On 27/10/2023 19:46, David Rosca wrote:
On Fri, Oct 27, 2023 at 7:14 PM Mark Thompson wrote:
On 27/10/2023 11:00, David Rosca wrote:
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..86b0852c12 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
I don't understand where the !overwrite has come from in this condition?
This logic is a couple lines ahead in the vaCreateImage path. If
AV_HWFRAME_MAP_OVERWRITE isn't set, it will call vaGetImage to read
the image data. And as vaDeriveImage + vaMapBuffer is read+write
mapping, I think the same logic needs to be applied to vaMapBuffer2
too.
The case is not the same as the one earlier, because ...
If the user requested write-only but not overwrite then they're expecting to
write some pixels within the image (such as adding an overlay), but don't want
to read anything.
Exactly for this case the read is needed. If the user writes only some
(not all) pixels of the image, then the rest of the image will be
invalid if a driver implements the mapping using staging texture
(which is what Mesa does).
... that is not what the documentation says the function has to do:
"""
/**
* Map data store of the buffer into the client's address space
* this interface could be used to convey the operation hint
* backend driver could use these hint to optimize the implementations
*/
/** \brief VA_MAPBUFFER_FLAG_DEFAULT is used when there are no flag specified
* same as VA_MAPBUFFER_FLAG_READ | VA_MAPBUFFER_FLAG_WRITE.
*/
/** \brief application will read the surface after map */
#define VA_MAPBUFFER_FLAG_READ1
/** \brief application will write the surface after map */
#define VA_MAPBUFFER_FLAG_WRITE 2
VAStatus vaMapBuffer2(
VADisplay dpy,
VABufferID buf_id, /* in */
void **pbuf,/* out */
uint32_t flags /* in */
);
"""
There is no suggestion here that setting WRITE & !READ implies that the user
has to completely overwrite the surface.
A user reading this would reasonably set write-only in the case where they want
to add an overlay, but your interpretation would make the driver discard the
rest of the image and give an unexpected result.
If you believe the function is intended to work this way then can you submit a
patch to libva to update the documentation to say what you expect? (Which can
also be seen by other driver implementers, so that they can comment on whether
the additional meaning you assign to the flags is something they would support
as well.)
Alternatively, it sounds like you would want to add an OVERWRITE flag to libva,
for exactly the same reasons that it exists already in ffmpeg.
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
Please add a note that there is a compatibility layer in libva so that
MapBuffer2 calls MapBuffer if the driver doesn't expose it directly, so this
does work with older drivers. (The patch looked wrong before I realised that.)
Thanks,
- Mark
___
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] lavf/smacker: export sample_aspect_ratio
Fixes #10617
---
libavformat/smacker.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/smacker.c b/libavformat/smacker.c
index 1d54e8e917..d04c8b91a6 100644
--- a/libavformat/smacker.c
+++ b/libavformat/smacker.c
@@ -34,6 +34,8 @@
#define SMACKER_PAL 0x01
#define SMACKER_FLAG_RING_FRAME 0x01
+#define SMACKER_FLAG_Y_INTERLACE (1 << 1)
+#define SMACKER_FLAG_Y_DOUBLE(1 << 2)
enum SAudFlags {
SMK_AUD_PACKED = 0x80,
@@ -144,6 +146,9 @@ static int smacker_read_header(AVFormatContext *s)
avpriv_set_pts_info(st, 33, pts_inc, tbase);
st->duration = smk->frames;
+st->sample_aspect_ratio = (AVRational){ 1, 1 +
+!!(flags & (SMACKER_FLAG_Y_INTERLACE | SMACKER_FLAG_Y_DOUBLE)) };
+
/* init video codec */
par = st->codecpar;
par->width = width;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
> On Oct 27, 2023, at 12:00 PM, Rémi Denis-Courmont wrote: > > Le perjantaina 27. lokakuuta 2023, 21.52.51 EEST Cosmin Stejerean via ffmpeg- > devel a écrit : >> With a list of FFLabs consultants the "what they work on" can be extracted >> from the git log or mailing list patches. Not who is paying for the work or >> how much is being paid, but certainly the what can be inferred with a >> reasonable degree of accuracy. > > In other words, we know neither what the statement of work is, nor how much > FFlabs is paid for or passes on to the consultants. We just guess that maybe > what the people listed as consultants are paid to do what they do. > > Then that is nowhere near the level of labour-intensive (for the GA) and > privacy-intrusive (for the consultants) that SPI funding would involve, more > or less making my point. Sure, work done via FFLabs has more privacy than work funded with non-profit SPI donations. It's not clear what the problem is though, nobody is forced to accept work via the SPI route, presumably folks can continue to work via FFLabs or via other commercial contracts exclusively if they so prefer. Having more transparency for work funded from donations seems like a good thing. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le perjantaina 27. lokakuuta 2023, 21.52.51 EEST Cosmin Stejerean via ffmpeg- devel a écrit : > With a list of FFLabs consultants the "what they work on" can be extracted > from the git log or mailing list patches. Not who is paying for the work or > how much is being paid, but certainly the what can be inferred with a > reasonable degree of accuracy. In other words, we know neither what the statement of work is, nor how much FFlabs is paid for or passes on to the consultants. We just guess that maybe what the people listed as consultants are paid to do what they do. Then that is nowhere near the level of labour-intensive (for the GA) and privacy-intrusive (for the consultants) that SPI funding would involve, more or less making my point. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
> On Oct 27, 2023, at 9:14 AM, Rémi Denis-Courmont wrote: > >> Consider FFlabs, you can look at who is being paid by FFlabs, its being >> mentioned in various places. >> Then look at what these people do, so you know what they are paid for. > > I don't know if FFlabs publishes the payments it makes to its consultants, so > I can't answer your question. But it sounds odd, as I would expect that that > would violate privacy laws. All FFlabs seems to publish is who their > consultants are, not what they work on or for. With a list of FFLabs consultants the "what they work on" can be extracted from the git log or mailing list patches. Not who is paying for the work or how much is being paid, but certainly the what can be inferred with a reasonable degree of accuracy. - Cosmin ___ 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 v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Oct 27, 2023 at 7:14 PM Mark Thompson wrote:
>
> On 27/10/2023 11:00, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v3: Fix another warning
> >
> > libavutil/hwcontext_vaapi.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..86b0852c12 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
>
> I don't understand where the !overwrite has come from in this condition?
This logic is a couple lines ahead in the vaCreateImage path. If
AV_HWFRAME_MAP_OVERWRITE isn't set, it will call vaGetImage to read
the image data. And as vaDeriveImage + vaMapBuffer is read+write
mapping, I think the same logic needs to be applied to vaMapBuffer2
too.
>
> If the user requested write-only but not overwrite then they're expecting to
> write some pixels within the image (such as adding an overlay), but don't
> want to read anything.
Exactly for this case the read is needed. If the user writes only some
(not all) pixels of the image, then the rest of the image will be
invalid if a driver implements the mapping using staging texture
(which is what Mesa does).
>
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, );
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> Please add a note that there is a compatibility layer in libva so that
> MapBuffer2 calls MapBuffer if the driver doesn't expose it directly, so this
> does work with older drivers. (The patch looked wrong before I realised
> that.)
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/get_bits: Avoid 2nd bitstream read in GET_VLC() if bits are known at build and small
On Fri, Oct 27, 2023 at 05:10:32AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/get_bits.h | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
> > index cfcf97c021c..86cea00494a 100644
> > --- a/libavcodec/get_bits.h
> > +++ b/libavcodec/get_bits.h
> > @@ -581,8 +581,12 @@ static inline const uint8_t
> > *align_get_bits(GetBitContext *s)
> > n = table[index].len; \
> > \
> > if (max_depth > 1 && n < 0) { \
> > -LAST_SKIP_BITS(name, gb, bits); \
> > -UPDATE_CACHE(name, gb); \
> > +if (av_builtin_constant_p(bits <= MIN_CACHE_BITS/2) && bits <=
> > MIN_CACHE_BITS/2) { \
> > +SKIP_BITS(name, gb, bits); \
> > +} else {\
> > +LAST_SKIP_BITS(name, gb, bits); \
> > +UPDATE_CACHE(name, gb); \
> > +} \
> > \
> > nb_bits = -n; \
> > \
>
> This is problematic: The GET_VLC macro does not presume that
> MIN_CACHE_BITS are available; there is code that directly uses GET_VLC
> instead of get_vlc2().
>
> I had the same idea when I made my VLC patchset, yet I wanted to first
> apply it (which I forgot). While investigating the above issue, I found
> out that all users of GET_VLC always call UPDATE_CACHE immediately
> before GET_VLC, so UPDATE_CACHE should be moved into GET_VLC;
> furthermore, no user of GET_VLC relies on the reloads inside of GET_VLC.
> The patches for this are here:
> https://github.com/mkver/FFmpeg/commits/vlc Shall I send them?
>
> Notice that making GET_VLC more standalone enables improvements over the
> current approach; yet it will not lead to optimal code: E.g. the VLCs in
> decode_alpha_block() in speedhqdec.c are so short that one could read
> both VLCs with only one UPDATE_CACHE(); another example is mjpegdec.c
> which currently does this:
>
> GET_VLC(code, re, >gb, s->vlcs[1][ac_index].table, 9, 2);
>
> i += ((unsigned)code) >> 4;
> code &= 0xf;
> if (code) {
> if (code > MIN_CACHE_BITS - 16)
> UPDATE_CACHE(re, >gb);
>
> {
> int cache = GET_CACHE(re, >gb);
> int sign = (~cache) >> 31;
> level = (NEG_USR32(sign ^ cache,code) ^ sign) - sign;
> }
>
> LAST_SKIP_BITS(re, >gb, code);
>
> Because of the reloads in GET_VLC, there will always be at least
> MIN_CACHE_BITS - 9 (= 16) bits available after GET_VLC, so one can read
> code (<= 15) bits without updating the cache at all (16 in
> MIN_CACHE_BITS - 16 is the maximum length of a VLC code used here); this
> will no longer be possible with this optimization.
> Btw: I am surprised that there is a branch before UPDATE_CACHE instead
> of an unconditional UPDATE_CACHE. I also do not really see why this uses
> these macros directly and not the functions.
>
> Given my objection to your patch #1, magicyuv will not benefit from
> this; a different approach (see
> https://github.com/mkver/FFmpeg/commit/9b5a977957968c0718dea55a5b15f060ef6201dc)
> is to add a get_vlc() that uses the nb of bits used to create the VLC
> and a compile-time upper bound for the maximum length of a VLC code as
> parameters instead of the maximum depth of the VLC.
>
> Reading VLCs for the cached bitstream reader can btw also be improved:
> https://github.com/mkver/FFmpeg/commit/fba57506a9cf6be2f4aa57b10d54729fd92a
speaking of that, i was wondering if the alternatives we had in get_bits.h
A32_BITSTREAM_READER wouldnt be worth reinvestigating
especially when extended to 64bit some of these readers might perform better
There are then just more bits available and fewer reads and fewer mispredicted
branches for cached ones
It would be somewhat nice if we could avoid having 2 different APIs as we have
now with the cached and normal reader.
Also the normal one with 64bit would be interresting, more available bits
so fewer reads
also i was wondering about a vlc reader thats entirely free of conditional
branches. Just a loop that in each iteration would step by 0-n symbols
forward and update a pointer to which table to use next
but i dont think i will have the time to try to implement this.
I have alot more ideas than i have time to try sadly, if you wan/can/or did
try any of above that would be interresting
thx
[...]
--
Michael GnuPG
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel > wrote: > >> I'll try to post a patch today either inverting their order (which >> hopefully outputs my community member e-mail), or - since this e-mail >> is never supposed to apply to any committer cases - removing it. > > Andreas might be in the same boat. If necessary, we could have a seperate > .mailmap_voting file only used in the GA script. Patches welcome, I guess. I think the script works correctly. According to the mailmap documentation the order is supposed to be I'd expect the first email in the mailmap to be the proper email to send things like GA votes to, whereas the second one can be one of potentially multiple other emails that commits could be under. So multiple second emails would be used to aggregate commits to a single proper email address to be used for GA purposes. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
> On Oct 27, 2023, at 5:39 AM, Thilo Borgmann via ffmpeg-devel > wrote: > >> I'll try to post a patch today either inverting their order (which >> hopefully outputs my community member e-mail), or - since this e-mail >> is never supposed to apply to any committer cases - removing it. > > Andreas might be in the same boat. If necessary, we could have a seperate > .mailmap_voting file only used in the GA script. Patches welcome, I guess. I think the script works correctly. According to the mailmap documentation the order is supposed to be I'd expect the first email in the mailmap to be the proper email to send things like GA votes to, whereas the second one can be one of potentially multiple other emails that commits could be under. So multiple second emails would be used to aggregate commits to a single proper email address to be used for GA purposes. - Cosmin ___ 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 8/8] avcodec/pnm: explicitly tag color range
On Fri, Oct 27, 2023 at 10:06 AM Niklas Haas wrote: > From: Niklas Haas > > PGMYUV seems to be always limited range. This was a format originally > invented by FFmpeg at a time when YUVJ distinguished limited from full > range YUV, and this codec never appeared to output YUVJ in any > circumstance, so hard-coding limited range preserves the status quo. > > The other formats are explicitly documented to be full range RGB/gray > formats. That said, don't tag them yet, due to outstanding bugs w.r.t > grayscale formats and color range handling. > > This change in behavior updates a bunch of FATE tests in trivial ways > (added tagging being the only difference). > --- > libavcodec/pnm.c | 5 > tests/ref/lavf/mkv| 4 ++-- > tests/ref/lavf/mkv_attachment | 4 ++-- > tests/ref/lavf/mxf| 6 ++--- > tests/ref/lavf/y4m| 4 ++-- > tests/ref/seek/lavf-mkv | 44 +-- > tests/ref/seek/lavf-y4m | 22 +- > 7 files changed, 47 insertions(+), 42 deletions(-) > > diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c > index 77d24eeaf7..bc51f94b1c 100644 > --- a/libavcodec/pnm.c > +++ b/libavcodec/pnm.c > @@ -240,5 +240,10 @@ int ff_pnm_decode_header(AVCodecContext *avctx, > PNMContext * const s) > h /= 3; > avctx->height = h; > } > + > +/* PGMYUV is always limited range */ > +if (avctx->codec_id == AV_CODEC_ID_PGMYUV) > +avctx->color_range = AVCOL_RANGE_MPEG; > Why does this check for the codec_id? -- Vittorio ___ 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 v3] avcodec/dovi_rpu: verify RPU data CRC32
On Fri, Oct 27, 2023 at 07:46:31AM -0400, quietvoid wrote:
>
> On 26/10/2023 17.44, Michael Niedermayer wrote:
> > On Wed, Aug 09, 2023 at 01:46:57PM -0400, quietvoid wrote:
> > > The Dolby Vision RPU contains a CRC32 to validate the payload against.
> > > The implementation is CRC32/MPEG-2.
> > >
[...]
> > > -/* FIXME: verify CRC32, requires implementation of AV_CRC_32_MPEG_2
> > > */
> > > +if (!(err_recognition & AV_EF_CRCCHECK))
> > > +return 0;
> > > +
> > > +/* Skip unsupported until CRC32 */
> > > +skip_bits_long(gb, get_bits_left(gb) - 32);
> > > +
> > > +rpu_data_crc32 = get_bits_long(gb, 32);
> > > +
> > > +/* Verify CRC32, buffer excludes the prefix, CRC32 and trailing byte
> > > */
> > > +computed_crc32 = av_bswap32(av_crc(av_crc_get_table(AV_CRC_32_IEEE),
> > > + -1, rpu + 1, actual_rpu_size -
> > > 6));
> > > +
> > > +if (rpu_data_crc32 != computed_crc32) {
> > > +av_log(s->logctx, AV_LOG_ERROR,
> > > + "RPU CRC mismatch! Expected %"PRIu32", received
> > > %"PRIu32"\n",
> > > + rpu_data_crc32, computed_crc32);
> > > +
> > > +if (err_recognition & AV_EF_EXPLODE)
> > > +goto fail;
> > > +}
> > (correctly designed) CRCs have the beautifull symmetry that you can merge
> > the crc32 value into the crc computation and then a 0 means no CRC missmatch
> > (there are many other cool properties but this one allows to simplify the
> > code)
> >
> > This works too: (and is simpler)
> >
> > /* Skip unsupported until CRC32 */
> > skip_bits_long(gb, get_bits_left(gb));
> >
> > /* Verify CRC32, buffer excludes the prefix, CRC32 and trailing byte */
> > computed_crc32 = av_bswap32(av_crc(av_crc_get_table(AV_CRC_32_IEEE),
> > -1, rpu + 1, actual_rpu_size - 2));
> >
> > if (computed_crc32) {
> > av_log(s->logctx, AV_LOG_ERROR, "RPU CRC mismatch! %"PRIX32"\n",
> > computed_crc32);
> >
> > if (err_recognition & AV_EF_EXPLODE)
> > goto fail;
> > }
>
> Hi Michael. I like the idea and it's a cool property.
>
> However the then printed CRC on mismatch is not a useful value, so I'm
> unsure if it's better to simplify here.
teh value printed is the syndrome
(https://en.wikipedia.org/wiki/Decoding_methods#Syndrome_decoding)
Its not a useless value.
What is it usefull for? well
take 2 pieces of different and random data
add a correct CRC at the end of each
now both will give a 0 of course on CRC checking
now flip the same bits in both blocks (whichever and howmany you want)
after that very likely the CRC check will not give 0
but it will give the same value for both blocks
the syndrome only depends on the damage not the data, which
is kind of cool.
> I like having the expected CRC logged here.
how do you know that expected CRC ?
i mean if theres a missmatch you _know_ there is some damage but you do
not know how much or where the damage is, the "expected CRC" stored there
can be the damaged and in fact even the only damaged part or maybe
everything is damaged.
the syndrome can be used for correcting an error if you can narrow the
possible errors down enough
but the CRC itself iam not so sure. Maybe one could google it in hopes
to find a undamaged file but for this to work the CRC would need to be
printed on undamaged files and long enough.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > As OOM scenarios are bad, will apply this fix soon. This bug, if it is a bug, has been here for quite some time already, a few days more will not change anything. I want to analyze this properly, do not push before please. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] trac spam
On Fri, Oct 27, 2023 at 02:44:10PM +0200, Michael Koch wrote: > Is it possible to make the "Bad Content" page invisible? It would be better > if the spammer can't see the filtering rules. everything is possible but its not a standard feature of trac that i know of. you would have to change trac, do a trac plugin or something else i guess thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Fri, Oct 27, 2023 at 3:18 PM Paul B Mahol wrote: > > > On Fri, Oct 27, 2023 at 3:02 PM Nicolas George wrote: > >> Paul B Mahol (12023-10-27): >> > Both patches are required to fix out of memory scenario with this use >> case: >> >> Then please attach an analysis of the fix in the commit messages. Bugs >> that just disappear when you rework the code completely are not fixed. >> > > It is log of 2nd patch. > > Basically what happens: buffersrc keeps feeding filtergraph with more > frames after trim filter in that same filtergraph signals EOF. > As OOM scenarios are bad, will apply this fix soon. > > >> >> Regards, >> >> -- >> Nicolas George >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > ___ 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 v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On 27/10/2023 11:00, David Rosca wrote:
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..86b0852c12 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
I don't understand where the !overwrite has come from in this condition?
If the user requested write-only but not overwrite then they're expecting to
write some pixels within the image (such as adding an overlay), but don't want
to read anything.
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
Please add a note that there is a compatibility layer in libva so that
MapBuffer2 calls MapBuffer if the driver doesn't expose it directly, so this
does work with older drivers. (The patch looked wrong before I realised that.)
Thanks,
- Mark
___
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 8/8] avcodec/pnm: explicitly tag color range
From: Niklas Haas PGMYUV seems to be always limited range. This was a format originally invented by FFmpeg at a time when YUVJ distinguished limited from full range YUV, and this codec never appeared to output YUVJ in any circumstance, so hard-coding limited range preserves the status quo. The other formats are explicitly documented to be full range RGB/gray formats. That said, don't tag them yet, due to outstanding bugs w.r.t grayscale formats and color range handling. This change in behavior updates a bunch of FATE tests in trivial ways (added tagging being the only difference). --- libavcodec/pnm.c | 5 tests/ref/lavf/mkv| 4 ++-- tests/ref/lavf/mkv_attachment | 4 ++-- tests/ref/lavf/mxf| 6 ++--- tests/ref/lavf/y4m| 4 ++-- tests/ref/seek/lavf-mkv | 44 +-- tests/ref/seek/lavf-y4m | 22 +- 7 files changed, 47 insertions(+), 42 deletions(-) diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c index 77d24eeaf7..bc51f94b1c 100644 --- a/libavcodec/pnm.c +++ b/libavcodec/pnm.c @@ -240,5 +240,10 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext * const s) h /= 3; avctx->height = h; } + +/* PGMYUV is always limited range */ +if (avctx->codec_id == AV_CODEC_ID_PGMYUV) +avctx->color_range = AVCOL_RANGE_MPEG; + return 0; } diff --git a/tests/ref/lavf/mkv b/tests/ref/lavf/mkv index a8c3fd13e8..5a3c3b931e 100644 --- a/tests/ref/lavf/mkv +++ b/tests/ref/lavf/mkv @@ -1,3 +1,3 @@ -6224bc0893bd0bb8a789e74bbd38c9c7 *tests/data/lavf/lavf.mkv -320440 tests/data/lavf/lavf.mkv +dd709c2b5e173eaca39cdd4a10aac3ec *tests/data/lavf/lavf.mkv +320447 tests/data/lavf/lavf.mkv tests/data/lavf/lavf.mkv CRC=0xec6c3c68 diff --git a/tests/ref/lavf/mkv_attachment b/tests/ref/lavf/mkv_attachment index 4c958af162..1a086a4f24 100644 --- a/tests/ref/lavf/mkv_attachment +++ b/tests/ref/lavf/mkv_attachment @@ -1,3 +1,3 @@ -05132b99d16128e552c1a6f1619be8b7 *tests/data/lavf/lavf.mkv_attachment -472590 tests/data/lavf/lavf.mkv_attachment +7cd7b06892b74d66da217c8dda90bfac *tests/data/lavf/lavf.mkv_attachment +472597 tests/data/lavf/lavf.mkv_attachment tests/data/lavf/lavf.mkv_attachment CRC=0xec6c3c68 diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf index fdd1ef5c9c..4cf3388afa 100644 --- a/tests/ref/lavf/mxf +++ b/tests/ref/lavf/mxf @@ -1,9 +1,9 @@ -9ec1ad83b3400de11ca2f70b3b2d4c4d *tests/data/lavf/lavf.mxf +fac1fb467168a374e96ea1278869 *tests/data/lavf/lavf.mxf 526393 tests/data/lavf/lavf.mxf tests/data/lavf/lavf.mxf CRC=0x8dddfaab -3edfabe839a29f5902969c15ebac6d8d *tests/data/lavf/lavf.mxf +d711481c4f81f6466fd92bdc7ed6c968 *tests/data/lavf/lavf.mxf 551481 tests/data/lavf/lavf.mxf tests/data/lavf/lavf.mxf CRC=0xf091e687 -5bd0ce691510e6fae969886c32ad7a14 *tests/data/lavf/lavf.mxf +7f4f8048c4f2d714e45947d4f39b8ea3 *tests/data/lavf/lavf.mxf 526393 tests/data/lavf/lavf.mxf tests/data/lavf/lavf.mxf CRC=0x8dddfaab diff --git a/tests/ref/lavf/y4m b/tests/ref/lavf/y4m index 82c7087673..3c3fa830ad 100644 --- a/tests/ref/lavf/y4m +++ b/tests/ref/lavf/y4m @@ -1,3 +1,3 @@ -ec8178cb152f9cdbfd9cb724d977db2e *tests/data/lavf/lavf.y4m -3801808 tests/data/lavf/lavf.y4m +54f4ebcffedc886835444bb9d6aba3fb *tests/data/lavf/lavf.y4m +3801828 tests/data/lavf/lavf.y4m tests/data/lavf/lavf.y4m CRC=0x0a941f26 diff --git a/tests/ref/seek/lavf-mkv b/tests/ref/seek/lavf-mkv index b8028dd075..e327959058 100644 --- a/tests/ref/seek/lavf-mkv +++ b/tests/ref/seek/lavf-mkv @@ -1,48 +1,48 @@ -ret: 0 st: 1 flags:1 dts:-0.011000 pts:-0.011000 pos:682 size: 208 +ret: 0 st: 1 flags:1 dts:-0.011000 pts:-0.011000 pos:689 size: 208 ret: 0 st:-1 flags:0 ts:-1.00 -ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:898 size: 27837 +ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:905 size: 27837 ret: 0 st:-1 flags:1 ts: 1.894167 -ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292314 size: 27834 +ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292321 size: 27834 ret: 0 st: 0 flags:0 ts: 0.788000 -ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292314 size: 27834 +ret: 0 st: 0 flags:1 dts: 0.96 pts: 0.96 pos: 292321 size: 27834 ret: 0 st: 0 flags:1 ts:-0.317000 -ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:898 size: 27837 +ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:905 size: 27837 ret:-1 st: 1 flags:0 ts: 2.577000 ret: 0 st: 1 flags:1 ts: 1.471000 -ret: 0 st: 1 flags:1 dts: 0.982000 pts: 0.982000 pos: 320158 size: 209 +ret: 0 st: 1 flags:1 dts: 0.982000 pts: 0.982000 pos: 320165 size: 209 ret: 0 st:-1 flags:0 ts: 0.365002 -ret: 0 st: 0 flags:1 dts: 0.48 pts: 0.48 pos: 146866 size: 27925 +ret: 0 st: 0 flags:1
[FFmpeg-devel] [PATCH 6/8] avfilter/vf_scale: simplify color matrix parsing logic
From: Niklas Haas
No need to write a custom string parser when we can just use an integer
option with preset values. The various bits of fallback logic are wholly
redundant with equivalent logic already inside sws_getCoefficients.
---
libavfilter/vf_scale.c | 60 +-
1 file changed, 19 insertions(+), 41 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f9b0746072..4a2f0bd1f1 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -139,8 +139,8 @@ typedef struct ScaleContext {
char *flags_str;
-char *in_color_matrix;
-char *out_color_matrix;
+int in_color_matrix;
+int out_color_matrix;
int in_range;
int out_range;
@@ -407,30 +407,6 @@ static int query_formats(AVFilterContext *ctx)
return 0;
}
-static const int *parse_yuv_type(const char *s, enum AVColorSpace colorspace)
-{
-if (!s)
-s = "bt601";
-
-if (s && strstr(s, "bt709")) {
-colorspace = AVCOL_SPC_BT709;
-} else if (s && strstr(s, "fcc")) {
-colorspace = AVCOL_SPC_FCC;
-} else if (s && strstr(s, "smpte240m")) {
-colorspace = AVCOL_SPC_SMPTE240M;
-} else if (s && (strstr(s, "bt601") || strstr(s, "bt470") || strstr(s,
"smpte170m"))) {
-colorspace = AVCOL_SPC_BT470BG;
-} else if (s && strstr(s, "bt2020")) {
-colorspace = AVCOL_SPC_BT2020_NCL;
-}
-
-if (colorspace < 1 || colorspace > 10 || colorspace == 8) {
-colorspace = AVCOL_SPC_BT470BG;
-}
-
-return sws_getCoefficients(colorspace);
-}
-
static int scale_eval_dimensions(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
@@ -803,11 +779,13 @@ scale:
(int **), _full,
, , );
-if (scale->in_color_matrix)
-inv_table = parse_yuv_type(scale->in_color_matrix, in->colorspace);
-if (scale->out_color_matrix)
-table = parse_yuv_type(scale->out_color_matrix,
AVCOL_SPC_UNSPECIFIED);
-else if (scale->in_color_matrix)
+if (scale->in_color_matrix == -1 /* auto */)
+inv_table = sws_getCoefficients(in->colorspace);
+else if (scale->in_color_matrix != AVCOL_SPC_UNSPECIFIED)
+inv_table = sws_getCoefficients(scale->in_color_matrix);
+if (scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED)
+table = sws_getCoefficients(scale->out_color_matrix);
+else if (scale->in_color_matrix != AVCOL_SPC_UNSPECIFIED)
table = inv_table;
if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
@@ -993,16 +971,16 @@ static const AVOption scale_options[] = {
{ "interl", "set interlacing", OFFSET(interlaced), AV_OPT_TYPE_BOOL, {.i64
= 0 }, -1, 1, FLAGS },
{ "size", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
-{ "in_color_matrix", "set input YCbCr type", OFFSET(in_color_matrix),
AV_OPT_TYPE_STRING, { .str = "auto" }, .flags = FLAGS, "color" },
-{ "out_color_matrix", "set output YCbCr type", OFFSET(out_color_matrix),
AV_OPT_TYPE_STRING, { .str = NULL }, .flags = FLAGS, "color"},
-{ "auto",NULL, 0, AV_OPT_TYPE_CONST, { .str = "auto" },
0, 0, FLAGS, "color" },
-{ "bt601", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt601" },
0, 0, FLAGS, "color" },
-{ "bt470", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt470" },
0, 0, FLAGS, "color" },
-{ "smpte170m", NULL, 0, AV_OPT_TYPE_CONST, { .str = "smpte170m" },
0, 0, FLAGS, "color" },
-{ "bt709", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt709" },
0, 0, FLAGS, "color" },
-{ "fcc", NULL, 0, AV_OPT_TYPE_CONST, { .str = "fcc" },
0, 0, FLAGS, "color" },
-{ "smpte240m", NULL, 0, AV_OPT_TYPE_CONST, { .str = "smpte240m" },
0, 0, FLAGS, "color" },
-{ "bt2020", NULL, 0, AV_OPT_TYPE_CONST, { .str = "bt2020" },
0, 0, FLAGS, "color" },
+{ "in_color_matrix", "set input YCbCr type", OFFSET(in_color_matrix),
AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED }, 0, AVCOL_SPC_NB-1, .flags =
FLAGS, "color" },
+{ "out_color_matrix", "set output YCbCr type", OFFSET(out_color_matrix),
AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED }, 0, AVCOL_SPC_NB-1, .flags =
FLAGS, "color"},
+{ "auto",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = -1 },
0, 0, FLAGS, "color" },
+{ "bt601", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, "color" },
+{ "bt470", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, "color" },
+{ "smpte170m", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AVCOL_SPC_BT470BG }, 0, 0, FLAGS, "color" },
+{ "bt709", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_SPC_BT709
},0, 0, FLAGS, "color"
[FFmpeg-devel] [PATCH 7/8] avfilter/vf_scale: tag output color space
From: Niklas Haas When using vf_scale to force a specific output color space, also tag this on the AVFrame. (Mirroring existing logic for output range) --- libavfilter/vf_scale.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index 4a2f0bd1f1..d79d67c413 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -821,6 +821,9 @@ scale: out->width = outlink->w; out->height = outlink->h; out->color_range = out_full ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG; +if (scale->out_color_matrix >= 0 && +scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED) +out->colorspace = scale->out_color_matrix; // Sanity checks: // 1. If the output is RGB, set the matrix coefficients to RGB. -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/8] avfilter/vf_scale: preserve YUV range by default
From: Niklas Haas
YUV->YUV conversions should preserve input range, if the output range is
unspecified. Ensures full-range YUV input comes out as full-range YUV
output by default, even through YUV->YUV pixel format conversions.
---
libavfilter/vf_scale.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 19c91cb86e..f9b0746072 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -687,6 +687,28 @@ static int scale_field(ScaleContext *scale, AVFrame *dst,
AVFrame *src,
return 0;
}
+static int is_regular_yuv(enum AVPixelFormat fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+if (desc->flags & (AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_PAL))
+return 0;
+if (desc->name && av_strstart(desc->name, "xyz", NULL))
+return 0;
+if (desc->nb_components < 3)
+return 0; /* grayscale is forced full range inside libswscale */
+switch (fmt) {
+case AV_PIX_FMT_YUVJ420P:
+case AV_PIX_FMT_YUVJ422P:
+case AV_PIX_FMT_YUVJ444P:
+case AV_PIX_FMT_YUVJ440P:
+case AV_PIX_FMT_YUVJ411P:
+return 0;
+default:
+return 1;
+}
+}
+
+
static int scale_frame(AVFilterLink *link, AVFrame *in, AVFrame **frame_out)
{
AVFilterContext *ctx = link->dst;
@@ -794,6 +816,8 @@ scale:
in_full = in->color_range == AVCOL_RANGE_JPEG;
if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
out_full = scale->out_range == AVCOL_RANGE_JPEG;
+else if (is_regular_yuv(in->format) && is_regular_yuv(outlink->format))
+out_full = in_full; /* preserve pixel range by default */
if (in->width == outlink->w &&
in->height == outlink->h &&
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8] avfilter/vf_scale: properly respect to input colorimetry
From: Niklas Haas
This code, as written, skips sws_init_context if scale->in_range was not
set, even if scale->in_frame_range is set to something. So this would
hit the 'no sws context' fast path in scale_frame and skip color range
conversion even where technically required. This had the effect of, in
practice, effectively applying limited/full range conversion if and only
if you set e.g. a nonzero yuv color matrix, which is obviously
undesirable behavior.
Second, the assignment of out->color_range inside the branch would fail
to properly propagate tags for any actually applied conversion, for
example on conversion to a forced full range format.
Solve both of these problems and make the code much easier to understand
and follow by doing the following:
1. Always initialize sws context on get_props
2. Always use sws_getColorspaceDetails + sws_setColorspaceDetails to
fix the conversion matrices per-frame.
3. Rather than testing if the context exists, do the no-op test after
settling the above values and deciding what conversion to actually
perform.
---
libavfilter/vf_scale.c | 186 +
1 file changed, 76 insertions(+), 110 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 23335cef4b..19c91cb86e 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -143,7 +143,6 @@ typedef struct ScaleContext {
char *out_color_matrix;
int in_range;
-int in_frame_range;
int out_range;
int out_h_chr_pos;
@@ -356,8 +355,6 @@ static av_cold int init(AVFilterContext *ctx)
if (!threads)
av_opt_set_int(scale->sws_opts, "threads",
ff_filter_get_nb_threads(ctx), 0);
-scale->in_frame_range = AVCOL_RANGE_UNSPECIFIED;
-
return 0;
}
@@ -520,6 +517,7 @@ static int config_props(AVFilterLink *outlink)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
const AVPixFmtDescriptor *outdesc = av_pix_fmt_desc_get(outfmt);
ScaleContext *scale = ctx->priv;
+struct SwsContext **swscs[3] = {>sws, >isws[0],
>isws[1]};
uint8_t *flags_val = NULL;
int ret;
@@ -552,65 +550,46 @@ static int config_props(AVFilterLink *outlink)
if (scale->isws[1])
sws_freeContext(scale->isws[1]);
scale->isws[0] = scale->isws[1] = scale->sws = NULL;
-if (inlink0->w == outlink->w &&
-inlink0->h == outlink->h &&
-!scale->out_color_matrix &&
-scale->in_range == scale->out_range &&
-inlink0->format == outlink->format)
-;
-else {
-struct SwsContext **swscs[3] = {>sws, >isws[0],
>isws[1]};
-int i;
-
-for (i = 0; i < 3; i++) {
-int in_v_chr_pos = scale->in_v_chr_pos, out_v_chr_pos =
scale->out_v_chr_pos;
-struct SwsContext *const s = sws_alloc_context();
-if (!s)
-return AVERROR(ENOMEM);
-*swscs[i] = s;
-
-ret = av_opt_copy(s, scale->sws_opts);
-if (ret < 0)
-return ret;
-av_opt_set_int(s, "srcw", inlink0 ->w, 0);
-av_opt_set_int(s, "srch", inlink0 ->h >> !!i, 0);
-av_opt_set_int(s, "src_format", inlink0->format, 0);
-av_opt_set_int(s, "dstw", outlink->w, 0);
-av_opt_set_int(s, "dsth", outlink->h >> !!i, 0);
-av_opt_set_int(s, "dst_format", outfmt, 0);
-if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
-av_opt_set_int(s, "src_range",
- scale->in_range == AVCOL_RANGE_JPEG, 0);
-else if (scale->in_frame_range != AVCOL_RANGE_UNSPECIFIED)
-av_opt_set_int(s, "src_range",
- scale->in_frame_range == AVCOL_RANGE_JPEG, 0);
-if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
-av_opt_set_int(s, "dst_range",
- scale->out_range == AVCOL_RANGE_JPEG, 0);
-
-/* Override chroma location default settings to have the correct
- * chroma positions. MPEG chroma positions are used by convention.
- * Note that this works for both MPEG-1/JPEG and MPEG-2/4 chroma
- * locations, since they share a vertical alignment */
-if (desc->log2_chroma_h == 1 && scale->in_v_chr_pos == -513) {
-in_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
-}
-
-if (outdesc->log2_chroma_h == 1 && scale->out_v_chr_pos == -513) {
-out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
-}
-
-av_opt_set_int(s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
-av_opt_set_int(s, "src_v_chr_pos", in_v_chr_pos, 0);
-av_opt_set_int(s, "dst_h_chr_pos", scale->out_h_chr_pos, 0);
-av_opt_set_int(s, "dst_v_chr_pos", out_v_chr_pos, 0);
-
-if ((ret = sws_init_context(s, NULL, NULL)) < 0)
-return ret;
-if
[FFmpeg-devel] [PATCH 3/8] avfilter/vf_alphamerge: warn if input not full range
From: Niklas Haas
Alpha planes must always be full range, so complain loudly if fed
limited range grayscale input.
---
libavfilter/vf_alphamerge.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_alphamerge.c b/libavfilter/vf_alphamerge.c
index 4bbc06da36..b814aa64f0 100644
--- a/libavfilter/vf_alphamerge.c
+++ b/libavfilter/vf_alphamerge.c
@@ -60,6 +60,12 @@ static int do_alphamerge(FFFrameSync *fs)
if (!alpha_buf)
return ff_filter_frame(ctx->outputs[0], main_buf);
+if (alpha_buf->color_range == AVCOL_RANGE_MPEG) {
+av_log(ctx, AV_LOG_WARNING, "alpha plane color range tagged as %s, "
+ "output will be wrong!",
+ av_color_range_name(alpha_buf->color_range));
+}
+
if (s->is_packed_rgb) {
int x, y;
uint8_t *pin, *pout;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/8] avfilter/vf_extractplanes: tag alpha plane as full range
From: Niklas Haas
Alpha planes are explicitly full range, even for limited range YUVA
formats. Mark them as such.
---
libavfilter/vf_extractplanes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index 7b7149ab24..ca406ff323 100644
--- a/libavfilter/vf_extractplanes.c
+++ b/libavfilter/vf_extractplanes.c
@@ -312,6 +312,8 @@ static int extract_plane(AVFilterLink *outlink, AVFrame
*frame)
if (!out)
return AVERROR(ENOMEM);
av_frame_copy_props(out, frame);
+if (idx == 3 /* alpha */)
+out->color_range = AVCOL_RANGE_JPEG;
if (s->is_packed) {
extract_from_packed(out->data[0], out->linesize[0],
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/8] swscale: fix sws_setColorspaceDetails after sws_init_context
From: Niklas Haas
More commonly, this fixes the case of sws_setColorspaceDetails after
sws_getContext, since the latter implies sws_init_context.
The problem here is that sws_init_context sets up the range conversion
and fast path tables based on the values of srcRange/dstRange at init
time. This may result in locking in a "wrong" path (either using
unscaled fast path when range conversion later required, or using
scaled slow path when range conversion becomes no longer required).
There are two way outs:
1. Always initialize range conversion and unscaled converters, even if
they will be unused, and extend the runtime check.
2. Re-do initialization if the values change after
sws_setColorspaceDetails.
I opted for approach 1 because it was simpler and easier to reason
about.
---
libswscale/swscale.c | 2 +-
libswscale/utils.c | 5 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 90e5b299ab..46ba68fe6a 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1016,7 +1016,7 @@ static int scale_internal(SwsContext *c,
reset_ptr(src2, c->srcFormat);
reset_ptr((void*)dst2, c->dstFormat);
-if (c->convert_unscaled) {
+if (c->convert_unscaled && !c->lumConvertRange && !c->chrConvertRange) {
int offset = srcSliceY_internal;
int slice_h = srcSliceH;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index e1ad685972..455955e907 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1728,9 +1728,7 @@ static av_cold int sws_init_single_context(SwsContext *c,
SwsFilter *srcFilter,
}
/* unscaled special cases */
-if (unscaled && !usesHFilter && !usesVFilter &&
-(c->srcRange == c->dstRange || isAnyRGB(dstFormat) ||
- isFloat(srcFormat) || isFloat(dstFormat))){
+if (unscaled && !usesHFilter && !usesVFilter) {
ff_get_unscaled_swscale(c);
if (c->convert_unscaled) {
@@ -1738,7 +1736,6 @@ static av_cold int sws_init_single_context(SwsContext *c,
SwsFilter *srcFilter,
av_log(c, AV_LOG_INFO,
"using unscaled %s -> %s special converter\n",
av_get_pix_fmt_name(srcFormat),
av_get_pix_fmt_name(dstFormat));
-return 0;
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avutil/hwcontext_vaapi: return ENOSYS for unsupported operation
On 27/10/2023 16:37, Zhao Zhili wrote:
From: Zhao Zhili
av_hwframe_transfer_data try with src_ctx first. If the operation
failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
AVERROR(EINVAL) makes the second step being skipped.
---
libavutil/hwcontext_vaapi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..bb28bcf588 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -217,7 +217,7 @@ static int vaapi_get_image_format(AVHWDeviceContext *hwdev,
return 0;
}
}
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
}
static int vaapi_frames_get_constraints(AVHWDeviceContext *hwdev,
@@ -805,19 +805,19 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
if (!ctx->derive_works && (flags & AV_HWFRAME_MAP_DIRECT)) {
// Requested direct mapping but it is not possible.
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
}
if (dst->format == AV_PIX_FMT_NONE)
dst->format = hwfc->sw_format;
if (dst->format != hwfc->sw_format && (flags & AV_HWFRAME_MAP_DIRECT)) {
// Requested direct mapping but the formats do not match.
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
This one seems wrong? The user requested that (say) a YUV surface is directly
mapped to an RGB frame. That's an invalid request from the user, not an
unsupported feature.
If you're changing the return values then this test and the previous one
probably want to therefore be in the opposite order as well.
}
err = vaapi_get_image_format(hwfc->device_ctx, dst->format, _format);
if (err < 0) {
// Requested format is not a valid output format.
-return AVERROR(EINVAL);
+return err;
}
map = av_malloc(sizeof(*map));
@@ -992,7 +992,7 @@ static int vaapi_map_to_memory(AVHWFramesContext *hwfc,
AVFrame *dst,
if (dst->format != AV_PIX_FMT_NONE) {
err = vaapi_get_image_format(hwfc->device_ctx, dst->format, NULL);
if (err < 0)
-return AVERROR(ENOSYS);
+return err;
}
err = vaapi_map_frame(hwfc, dst, src, flags);
- Mark
___
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 v3] avformat/mov: Add support for demuxing still HEIC images
Thank you. I have emailed the samples to samples-requ...@ffmpeg.org. I will ping this thread once they are uploaded. Could somebody please help upload the sample files sent to samples-requ...@ffmpeg.org so that this patch can be merged? Thank you! Done, sorry for delay. Same for the avif samples. -Thilo ___ 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 v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, 27 Oct 2023 12:00:10 +0200
David Rosca wrote:
> This allows some optimizations in driver, such as not having to read
> back the data if write-only mapping is requested.
> ---
> v3: Fix another warning
>
> libavutil/hwcontext_vaapi.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 558fed94c6..86b0852c12 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc, VAStatus vas;
> void *address = NULL;
> int err, i;
> +#if VA_CHECK_VERSION(1, 21, 0)
> +uint32_t vaflags = 0;
> +#endif
>
> surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> @@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc, }
> }
>
> +#if VA_CHECK_VERSION(1, 21, 0)
> +if (flags & AV_HWFRAME_MAP_READ || !(flags &
> AV_HWFRAME_MAP_OVERWRITE))
> +vaflags |= VA_MAPBUFFER_FLAG_READ;
> +if (flags & AV_HWFRAME_MAP_WRITE)
> +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> +vas = vaMapBuffer2(hwctx->display, map->image.buf, ,
> vaflags); +#else
> vas = vaMapBuffer(hwctx->display, map->image.buf, );
> +#endif
> if (vas != VA_STATUS_SUCCESS) {
> av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface
> " "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
LGTM. Thanks.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avutil/hwcontext_vaapi: return ENOSYS for unsupported operation
On Fri, 27 Oct 2023 23:37:01 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> av_hwframe_transfer_data try with src_ctx first. If the operation
> failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
> AVERROR(EINVAL) makes the second step being skipped.
> ---
> libavutil/hwcontext_vaapi.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 558fed94c6..bb28bcf588 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -217,7 +217,7 @@ static int
> vaapi_get_image_format(AVHWDeviceContext *hwdev, return 0;
> }
> }
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
>
> static int vaapi_frames_get_constraints(AVHWDeviceContext *hwdev,
> @@ -805,19 +805,19 @@ static int vaapi_map_frame(AVHWFramesContext
> *hwfc,
> if (!ctx->derive_works && (flags & AV_HWFRAME_MAP_DIRECT)) {
> // Requested direct mapping but it is not possible.
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
> if (dst->format == AV_PIX_FMT_NONE)
> dst->format = hwfc->sw_format;
> if (dst->format != hwfc->sw_format && (flags &
> AV_HWFRAME_MAP_DIRECT)) { // Requested direct mapping but the formats
> do not match.
> -return AVERROR(EINVAL);
> +return AVERROR(ENOSYS);
> }
>
> err = vaapi_get_image_format(hwfc->device_ctx, dst->format,
> _format); if (err < 0) {
> // Requested format is not a valid output format.
> -return AVERROR(EINVAL);
> +return err;
> }
>
> map = av_malloc(sizeof(*map));
> @@ -992,7 +992,7 @@ static int vaapi_map_to_memory(AVHWFramesContext
> *hwfc, AVFrame *dst, if (dst->format != AV_PIX_FMT_NONE) {
> err = vaapi_get_image_format(hwfc->device_ctx, dst->format,
> NULL); if (err < 0)
> -return AVERROR(ENOSYS);
> +return err;
> }
>
> err = vaapi_map_frame(hwfc, dst, src, flags);
LGTM.
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/hwcontext_vulkan: cuda doesn't belong to valid_sw_formats
On Fri, 27 Oct 2023 23:37:00 +0800
Zhao Zhili wrote:
> From: Zhao Zhili
>
> Move it to transfer_get_formats.
> ---
> libavutil/hwcontext_vulkan.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c
> b/libavutil/hwcontext_vulkan.c index 8dd40cb66f..8481427b42 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -1664,11 +1664,6 @@ static int
> vulkan_frames_get_constraints(AVHWDeviceContext *ctx, NULL, NULL,
> NULL, NULL, 0, 0) >= 0; }
>
> -#if CONFIG_CUDA
> -if (p->dev_is_nvidia)
> -count++;
> -#endif
> -
> constraints->valid_sw_formats = av_malloc_array(count + 1,
> sizeof(enum
> AVPixelFormat)); if (!constraints->valid_sw_formats)
> @@ -1684,10 +1679,6 @@ static int
> vulkan_frames_get_constraints(AVHWDeviceContext *ctx, }
> }
>
> -#if CONFIG_CUDA
> -if (p->dev_is_nvidia)
> -constraints->valid_sw_formats[count++] = AV_PIX_FMT_CUDA;
> -#endif
> constraints->valid_sw_formats[count++] = AV_PIX_FMT_NONE;
>
> constraints->min_width = 1;
> @@ -2416,12 +2407,22 @@ static int
> vulkan_transfer_get_formats(AVHWFramesContext *hwfc, enum
> AVHWFrameTransferDirection dir, enum AVPixelFormat **formats)
> {
> -enum AVPixelFormat *fmts = av_malloc_array(2, sizeof(*fmts));
> +enum AVPixelFormat *fmts;
> +int n = 2;
> +
> +#if CONFIG_CUDA
> +n++;
> +#endif
> +fmts = av_malloc_array(n, sizeof(*fmts));
> if (!fmts)
> return AVERROR(ENOMEM);
>
> -fmts[0] = hwfc->sw_format;
> -fmts[1] = AV_PIX_FMT_NONE;
> +n = 0;
> +fmts[n++] = hwfc->sw_format;
> +#if CONFIG_CUDA
> +fmts[n++] = AV_PIX_FMT_CUDA;
> +#endif
> +fmts[n++] = AV_PIX_FMT_NONE;
>
> *formats = fmts;
> return 0;
LGTM. Thanks!
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le perjantaina 27. lokakuuta 2023, 19.05.51 EEST Michael Niedermayer a écrit : > > This is about the funding organisation(s) and the recipient developer(s) > > in > > need of sustainable funding. While my income is public (if you know where > > to look), I sincerely doubt that many people *here* would want theirs > > published. I rather think that they would see it as a major intrusion to > > their privacy. > > > > I too prefer standard specifications and source code open, but this is > > about people's personal information, not source code. Whether you like it > > or not, that really is a *downside* of going through the mailing list or > > the GA, simply because it is a major turn-off. > > Isnt this the same for all options of full time payment we have ? > Consider FFlabs, you can look at who is being paid by FFlabs, its being > mentioned in various places. > Then look at what these people do, so you know what they are paid for. I don't know if FFlabs publishes the payments it makes to its consultants, so I can't answer your question. But it sounds odd, as I would expect that that would violate privacy laws. All FFlabs seems to publish is who their consultants are, not what they work on or for. > It may give the impression of more privacy but iam not sure it really > is that much more private. In most countries, individual income is more or less confidential while business contracts have business secrecy. Even here, I know at least one of my colleagues has applied to have their taxable income delisted on the basis of GDPR. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] FFmpeg - Winner of The 2nd ZEISS FOSS Funding Award
Hi, FFmpeg is the winner of the 2nd ZEISS FOSS Funding Award [1]! We have received $1,001.40 that comes with this award in our SPI account. -Thilo [1] https://blogs.zeiss.com/digital-innovation/en/zeiss-strengthens-engagement-in-foss-community/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, Oct 27, 2023 at 06:24:58PM +0300, Rémi Denis-Courmont wrote: >Hi, > > Le perjantaina 27. lokakuuta 2023, 15.24.38 EEST Thilo Borgmann via ffmpeg- > devel a écrit : > > >>> Why should it be via SPI? What's the benefit of that hypothetical > > >>> future > additional funding going via SPI, as opposed to: > > >> obviously transparency and community control. None of which is given by > > >> the options you list.> > > > Do you want transparency there? This is *not* about having open source > > > code and the public code review. > > > Yes, absolutely. We are an *open* project. > > This is about the funding organisation(s) and the recipient developer(s) in > need of sustainable funding. While my income is public (if you know where to > look), I sincerely doubt that many people *here* would want theirs published. > I rather think that they would see it as a major intrusion to their privacy. > > I too prefer standard specifications and source code open, but this is about > people's personal information, not source code. Whether you like it or not, > that really is a *downside* of going through the mailing list or the GA, > simply because it is a major turn-off. Isnt this the same for all options of full time payment we have ? Consider FFlabs, you can look at who is being paid by FFlabs, its being mentioned in various places. Then look at what these people do, so you know what they are paid for. It may give the impression of more privacy but iam not sure it really is that much more private. the list of contractors and employees for such a company would have to be kept secret and people would need to use a pseudonym. use TOR and so on. That said, using a pseudonym is possible with SPI too to some extend. One can just use a pseudonym, seperate mail address, TOR to post a proposal. And if one likes, privately tell interrested parties who they are. SPI will need their real name i think and this will IIUC be known to the banks and government and so on. So its not full anonymity but maybe its similar to the light privacy other companies provide thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le perjantaina 27. lokakuuta 2023, 18.08.54 EEST Thilo Borgmann via ffmpeg- devel a écrit : > > Do you seriously think this project will have a sudden outbreak of > > professionalism and suddenly start producing detailed contracts and > > statements of work? > > The current level appear appealing enough to try and see. So I have been working in 3 different large tech multinationals in the past two decades, and recently I have been in the technical role on the purchasing end. And I can only agree with Kieran. What I have seen so far is exactly that: > > It'll end up being a few lines on the mailing list. > Just your pessimistic assumption. You can call it pessimistic. But it is not realistic to expect people here to even bother to write or review a proper statement of work. This is really tedious and boring. And that's not even going into the obvious risk of bikesheding or flamewar if people do actually decide to participate in the drafting or reviewing. Now if SPI had 1M$ in the bank for FFmpeg, then I admit that it could make sense to just bite the bullet and go through that tedious process. But it does not, it does not look like it will have any time soon. Frankly, if you and Michael want to pitch that approach, I would advise against it, but you have every rights to do so anyway (and I hope nobody here actively undermines you). However, also hope that the GA would reject spending what little SPI money has for the wishful thinking that it would kickstart sustainable financing for FFmpeg development. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Hi, Le perjantaina 27. lokakuuta 2023, 15.24.38 EEST Thilo Borgmann via ffmpeg- devel a écrit : > >>> Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: > >> obviously transparency and community control. None of which is given by > >> the options you list.> > > Do you want transparency there? This is *not* about having open source > > code and the public code review. > Yes, absolutely. We are an *open* project. This is about the funding organisation(s) and the recipient developer(s) in need of sustainable funding. While my income is public (if you know where to look), I sincerely doubt that many people *here* would want theirs published. I rather think that they would see it as a major intrusion to their privacy. I too prefer standard specifications and source code open, but this is about people's personal information, not source code. Whether you like it or not, that really is a *downside* of going through the mailing list or the GA, simply because it is a major turn-off. If SPI requires going through the mailing list, then that is also a downside of going through SPI. > > Using SPI money would hypothetically be an option if there was enough > > money. Currently there is not. > There is enough budget to fund several of the smaller tasks Michael > proposed. But that has nothing to do with building a sustainable OSS development ecosystem. Funding small tasks is great to get students to work their summer on FFmpeg rather than writing proprietary business code at a local web company (at least if you have willing mentors). But Michael specifically framed this "financial sustainability plan" for grown- up adult "developers [who] no longer live with their parents". It is *not* sustainable to fund them with 5000€ bounties. At that point in our lives, most people would need somewhat stable income, both for financial and psychological well-being. If you have a credible plan for SPI to get enough income to provide that kind of stable income to even one developer, then by all mean, lets see that plan. But I don't see it. Offering bounties is a complete waste of time and money in this regard (it might be a good idea for other purposes, but that's a different discussion). > >>> That's the part that you'd need to clarify first. What relevant flashy > >>> cool development will attract those donations? Why should they be > >>> funded by donations rather than more traditional business transactions? > >> Hen & egg. > > > > What? Why do you need to start spending money before you can have ideas of > > cool projects? That makes zero sense to me. > What? Michael asked specifically to propose cool projects. And I asked why it would be better to fund those hypothetical projects through SPI rather than privately and directly. -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Am 27.10.23 um 15:38 schrieb Kieran Kunhya: On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Am 27.10.23 um 03:28 schrieb Kieran Kunhya: Hi, On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Of course. FFmpeg has a donations account. So the money is already there and already used for the reimbursement requests. Whatever we spent it for needs to be decided by the community. Spending more money instead of just watch it growing is a good thing. That this will lead to more "disaster" is an assumption without basis. Even if this does happen and fails, its still better than not having even tried. Reimbursement requests for clearly defined things like travel costs with receipts, or hardware that the project owns is in no way comparable to consulting work, contracts, statements of work etc. And the current swscale proposal is far from this too. Yes, of course they are different. Most importantly sponsored development needs to be agreed upon beforehand. That does not imply sponsored work is not clearly defined. I miss your argument about why it can't be done in this. Do you seriously think this project will have a sudden outbreak of professionalism and suddenly start producing detailed contracts and statements of work? The current level appear appealing enough to try and see. It'll end up being a few lines on the mailing list. Just your pessimistic assumption. Also, you just advertised FFmpeg and asked for more financial support in your talk at Demuxed [1] - so I figure your prefered way of doing that would be to channel money into some company without the community being involved? Actually if you watched the presentation, I said big companies need to support maintenance (not the same as bounties) of FFmpeg by hiring employees to work full time as they do with Linux Kernel maintainers. Or failing that they can donate to the community - but as you know well the numbers we have are not enough to hire full time maintainers. I'm totally fine with you asking big companies to hire devs for FFmpeg maintenance. That does not relate to my question, though. Do I assume correctly that your prefered way of doing that would be to channel money into some company without the community being involved? Contractually yes, this is a better solution. It allows the company to be in charge of delivery of the maintenance work with a contract behind it. Do you seriously think big companies will suddenly hand over money to the community that's got weekly drama around it? This point was raised to me by a big company that shall remain nameless at Demuxed. There is no need for a company to put money in before they are happy with the community response. If there is no history of such a procedure, uncertainty will remain. Just another reason to try implementing it. And companies not liking the procedure in general have several other options left. Agreement via mailing list for money is a recipe for disaster. What we need are clear statements of work that are voted on by TC. That's not the purpose of the TC. We of course need to have a good way of approving or disapproving proposals and of course we need these to be clearly defined. I again miss to see your argument why that shall not be possible on the ML - everyone on this list knows where your suspicion comes from but again, without even having tried, it's just your assumption and should IMHO not stopping us from trying to implement such a procedure. The mailing list isn't the be all and end all of all communications and decision making in the world. History shows it's atrocious for making decisions. Many people make valid and succinct points that are outright ignored, whoever writes the longest wall of text (often with conspiratorial ramblings that I'm sure go down well with potential donors) seems to get the most attention (i.e quantity vs quality). Don't blame mailing lists. It's just the tool we currently use, if we switch to s.th. else, than it is that. The problem will always exist no matter the tool - except you want no public access to it. The point is that it goes over FFmpeg's channel of communication where all project-wide things are discussed and eventually decided. Lots of people have left the project (e.g Derek) because of the toxicity of this mailing list. Even the Linux Kernel realised their mailing list was toxic and changed. It's again not the mailing list why they left, but the toxic behaviour from people using it. Nothing changes in that regard, no matter the tool. We can't even agree on patch reviews, throwing money into the mix is throwing gasoline into the fire. Being in conflict about a patch is completely different to conflict about some feature we might want. And no, not everything is as controversial as SDR or gets controversial just because it would be sponsored. You think there would have been real
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, Oct 27, 2023 at 06:46:42AM -0700, Kieran Kunhya wrote: > On Fri, 27 Oct 2023 at 05:32, Michael Niedermayer > wrote: > > > On Fri, Oct 27, 2023 at 01:43:34PM +0300, Rémi Denis-Courmont wrote: > > > > > > > > > Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer < > > mich...@niedermayer.cc> a écrit : > > [...] > > > >* If you have some flashy FFmpeg project you want to work on with a > > cost of > > > > between 5-15k $ then propose it on the mailing list, make yourself > > ready for > > > > some paperwork complexities and some public debate as thats the first > > time we > > > > try this, there will be extra issues likely. > > > > > > I don't think that code bounties count toward OSS "sustainability". It's > > condoning the so-called jig economy, which is the opposite, IMO. > > > > This is just a first step. > > If we can attract the financial resources to pay people in a repeated > > fashion > > "each month" then thats absolutely what id like to do with SPI > > > > The thing we need for "sustainability" is someone to work full-time on > maintenance work yes, I think we all know and agree on that > like YUVJ removal iam not sure thats a good example, but anyway > that doesn't get done otherwise yes > (literally we have talked about this for the last five or more years). And thats great, but you know "talk" isnt good enough > Nor > would any company fund it as a bounty as it provides no benefit to them. now ive seen contracts and such but there are NDAs so i cannot give anything specific but this is wrong. Companies do care and fund some things that do not give an immedeate benefit to them but are rather things for the long term of the project (which will beneift the company only over time) > This is the complete opposite of "some flashy FFmpeg project". yes, let me spell my plan out again (which is bassed in fact on previous suggestions from others) 1. fund some flashy FFmpeg projects 2. seek more donations (explain its for sustainability and full time payments if possible and smaller but important areas (flashy projects) when its not enough for full time payments) do 1+2 in parallel, 1. helps 2. 3. if we manage to receive a steady stream of donations that can support part time or full time development, use it for that. The flashy stuff is to get started, we cannot pay people full time with a one time budget of 150k$. we can pay several people with that if we can get that in donations per year. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, 27 Oct 2023 at 05:32, Michael Niedermayer wrote: > On Fri, Oct 27, 2023 at 01:43:34PM +0300, Rémi Denis-Courmont wrote: > > > > > > Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer < > mich...@niedermayer.cc> a écrit : > [...] > > >* If you have some flashy FFmpeg project you want to work on with a > cost of > > > between 5-15k $ then propose it on the mailing list, make yourself > ready for > > > some paperwork complexities and some public debate as thats the first > time we > > > try this, there will be extra issues likely. > > > > I don't think that code bounties count toward OSS "sustainability". It's > condoning the so-called jig economy, which is the opposite, IMO. > > This is just a first step. > If we can attract the financial resources to pay people in a repeated > fashion > "each month" then thats absolutely what id like to do with SPI > The thing we need for "sustainability" is someone to work full-time on maintenance work like YUVJ removal that doesn't get done otherwise (literally we have talked about this for the last five or more years). Nor would any company fund it as a bounty as it provides no benefit to them. This is the complete opposite of "some flashy FFmpeg project". Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Am 27.10.23 um 03:28 schrieb Kieran Kunhya: > > Hi, > > > > On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < > > ffmpeg-devel@ffmpeg.org> wrote: > > > >> Of course. FFmpeg has a donations account. So the money is already there > >> and > >> already used for the reimbursement requests. Whatever we spent it for > >> needs to > >> be decided by the community. Spending more money instead of just watch > it > >> growing is a good thing. That this will lead to more "disaster" is an > >> assumption > >> without basis. Even if this does happen and fails, its still better than > >> not > >> having even tried. > >> > > > > Reimbursement requests for clearly defined things like travel costs with > > receipts, or hardware that the project owns is in no way comparable to > > consulting work, contracts, statements of work etc. And the current > swscale > > proposal is far from this too. > > Yes, of course they are different. Most importantly sponsored development > needs > to be agreed upon beforehand. That does not imply sponsored work is not > clearly > defined. I miss your argument about why it can't be done in this. > Do you seriously think this project will have a sudden outbreak of professionalism and suddenly start producing detailed contracts and statements of work? It'll end up being a few lines on the mailing list. >> Also, you just advertised FFmpeg and asked for more financial support in > >> your > >> talk at Demuxed [1] - so I figure your prefered way of doing that would > be > >> to > >> channel money into some company without the community being involved? > >> > > > > Actually if you watched the presentation, I said big companies need to > > support maintenance (not the same as bounties) of FFmpeg by hiring > > employees to work full time as they do with Linux Kernel maintainers. Or > > failing that they can donate to the community - but as you know well the > > numbers we have are not enough to hire full time maintainers. > > I'm totally fine with you asking big companies to hire devs for FFmpeg > maintenance. That does not relate to my question, though. Do I assume > correctly > that your prefered way of doing that would be to channel money into some > company > without the community being involved? > Contractually yes, this is a better solution. It allows the company to be in charge of delivery of the maintenance work with a contract behind it. Do you seriously think big companies will suddenly hand over money to the community that's got weekly drama around it? This point was raised to me by a big company that shall remain nameless at Demuxed. > Agreement via mailing list for money is a recipe for disaster. What we > need > > are clear statements of work that are voted on by TC. > > That's not the purpose of the TC. We of course need to have a good way of > approving or disapproving proposals and of course we need these to be > clearly > defined. I again miss to see your argument why that shall not be possible > on the > ML - everyone on this list knows where your suspicion comes from but > again, > without even having tried, it's just your assumption and should IMHO not > stopping us from trying to implement such a procedure. > The mailing list isn't the be all and end all of all communications and decision making in the world. History shows it's atrocious for making decisions. Many people make valid and succinct points that are outright ignored, whoever writes the longest wall of text (often with conspiratorial ramblings that I'm sure go down well with potential donors) seems to get the most attention (i.e quantity vs quality). Lots of people have left the project (e.g Derek) because of the toxicity of this mailing list. Even the Linux Kernel realised their mailing list was toxic and changed. > > We can't even agree on patch reviews, throwing money into the mix is > > throwing gasoline into the fire. > > Being in conflict about a patch is completely different to conflict about > some > feature we might want. And no, not everything is as controversial as SDR > or gets > controversial just because it would be sponsored. You think there would > have > been real and non-resolvable opposition against bringing multi-threading > into > ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such > opposition? > However, since I agree with you that there will be different oppinions, > why > would you think that a e.g. a vote/committee or whatever we will choose > could > not resolve how we deal with these cases? > A conflict over a patch would lead to lack of payment which would enflame the situation more. I don't see why this is difficult to understand. Yes, I would say a proposed AV2 decoder would be a bad idea since it would be better to build one on top of dav1d. AV2 will likely have a lot of similarities to AV1. The introduction of money into the voting process isn't
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Fri, Oct 27, 2023 at 3:02 PM Nicolas George wrote: > Paul B Mahol (12023-10-27): > > Both patches are required to fix out of memory scenario with this use > case: > > Then please attach an analysis of the fix in the commit messages. Bugs > that just disappear when you rework the code completely are not fixed. > It is log of 2nd patch. Basically what happens: buffersrc keeps feeding filtergraph with more frames after trim filter in that same filtergraph signals EOF. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ 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] avcodec/evc_parse: Check tid
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: piątek, 13 października 2023 01:28
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 3/3] avcodec/evc_parse: Check tid
>
> The check is based on not infinite looping. It is likely a more strict
check can be
> done
>
> Fixes: Infinite loop
> Fixes: 62473/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
> Fixes: 62765/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-
> 6448531252314112
>
> Found-by: continuous fuzzing process
> https://protect2.fireeye.com/v1/url?k=06e4faf3-676fefea-06e571bc-
> 74fe485cbfec-11816a289a0e9c00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> 255706ce61..43b8dabf8b 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -174,6 +174,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> } else {
> int SubGopLength = 1 << sps->log2_sub_gop_length;
>
> +if (tid > (SubGopLength > 1 ? 1 + av_log2(SubGopLength - 1) :
0))
> +return AVERROR_INVALIDDATA;
> +
> if (tid == 0) {
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
SubGopLength;
> poc->DocOffset = 0;
> --
Looks good
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=63dfcc8a-0254d993-63de47c5-
> 74fe485cbfec-e9d44b0bcc16ae00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Both patches are required to fix out of memory scenario with this use case: Then please attach an analysis of the fix in the commit messages. Bugs that just disappear when you rework the code completely are not fixed. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/evc_parse: Check tid
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: czwartek, 5 października 2023 00:59
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 4/4] avcodec/evc_parse: Check tid
>
> The check is based on not infinite looping. It is likely a more strict
check can be
> done
>
> Fixes: Infinite loop
> Fixes: 62473/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
>
> Found-by: continuous fuzzing process
> https://protect2.fireeye.com/v1/url?k=a44f565e-c532bcdd-a44edd11-
> 74fe48600158-625c91e4183f7607=1=5e707773-ad1c-4987-a095-
> 2350d52c5cd3=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> 20b6849041a..8c0ef16f3ad 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -178,6 +178,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> } else {
> int SubGopLength = 1 << sps->log2_sub_gop_length;
>
> +if (tid > 1 + av_log2(SubGopLength - 1))
> +return AVERROR_INVALIDDATA;
> +
> if (tid == 0) {
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
SubGopLength;
> poc->DocOffset = 0;
int SubGopLength = 1 << sps->log2_sub_gop_length; if (tid > 1 +
av_log2(SubGopLength - 1))
return AVERROR_INVALIDDATA;
For the value of SubGopLength = 1 ( if sps->log2_sub_gop_length = 0; "The
value of log2_sub_gop_length shall be in the range of 0 to 5, inclusive" -
ISO_IEC_23094-1-2020 7.4.3.1), we have av_log2(0). The value of the
logarithm of 0 with any base (in this case, log2) is minus infinity (-inf)
Perhaps we should consider changing the condition to:
if (tid < 0 || tid > av_log2(SubGopLength))
return AVERROR_INVALIDDATA;
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=30e716c0-519afc43-30e69d8f-
> 74fe48600158-4965ec93628418ff=1=5e707773-ad1c-4987-a095-
> 2350d52c5cd3=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
On Fri, Oct 27, 2023 at 2:54 PM Nicolas George wrote:
> Paul B Mahol (12023-10-27):
> > Subject: [PATCH 1/2] avfilter/buffersrc: switch to activate
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > libavfilter/buffersrc.c | 25 -
> > 1 file changed, 16 insertions(+), 9 deletions(-)
>
> What would be the benefit?
>
> > if (s->eof)
> > -return AVERROR(EINVAL);
> > +return AVERROR_EOF;
> >
>
> AVERROR_EOF does not have a semantic for writing, only for reading, so
> no.
>
Both patches are required to fix out of memory scenario with this use case:
#!/usr/bin/env bash
which ffmpeg
if [ $# -lt 1 ] ; then
echo "Usage: ${0} INPUT"
echo "Example input can be generated with: "
echo " ffmpeg -v verbose -filter_complex
'testsrc2=r=25:s=640x480:d=470[out]' -map '[out]' -c:v libx264 -preset
superfast test_clip.mp4"
exit 1
fi
INPUT="${1}"
COPY_OUTPUT="${INPUT}_copy.mp4"
IMG2_OUTPUT="${INPUT}_img2.jpg"
echo "Input: ${INPUT}"
# if you get ooms, feel free to utilize ulimit
# (ulimit -v 500 && )
valgrind --tool=massif --massif-out-file="massif.out.$(date -Iseconds)" \
ffmpeg \
-y -ignore_unknown \
-v verbose \
-i "${INPUT}" \
-c copy -map 0 \
-t 470 \
"${COPY_OUTPUT}" \
-filter_complex
'[0:0]split=1[thumb_in];[thumb_in]trim=start=420:end=421,scale=720:-2:threads=1,setsar=1/1,hqdn3d,unsharp[thumb_out]'
\
-map "[thumb_out]" \
-vframes 1 \
-f image2 \
"${IMG2_OUTPUT}"
>
> Regards,
>
> --
> Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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] avcodec/evc_parse: Check tid
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: piątek, 13 października 2023 01:28
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 3/3] avcodec/evc_parse: Check tid
>
> The check is based on not infinite looping. It is likely a more strict
check can be
> done
>
> Fixes: Infinite loop
> Fixes: 62473/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
> Fixes: 62765/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-
> 6448531252314112
>
> Found-by: continuous fuzzing process
> https://protect2.fireeye.com/v1/url?k=06e4faf3-676fefea-06e571bc-
> 74fe485cbfec-11816a289a0e9c00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> 255706ce61..43b8dabf8b 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -174,6 +174,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> } else {
> int SubGopLength = 1 << sps->log2_sub_gop_length;
>
> +if (tid > (SubGopLength > 1 ? 1 + av_log2(SubGopLength - 1) :
0))
> +return AVERROR_INVALIDDATA;
> +
> if (tid == 0) {
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
SubGopLength;
> poc->DocOffset = 0;
> --
> 2.17.1
>
My previous comment was related to a different patchset ([FFmpeg-devel,4/4]
avcodec/evc_parse: Check tid)
I apologize for the mistake
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=63dfcc8a-0254d993-63de47c5-
> 74fe485cbfec-e9d44b0bcc16ae00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Paul B Mahol (12023-10-27): > Subject: [PATCH 1/2] avfilter/buffersrc: switch to activate > > Signed-off-by: Paul B Mahol > --- > libavfilter/buffersrc.c | 25 - > 1 file changed, 16 insertions(+), 9 deletions(-) What would be the benefit? > if (s->eof) > -return AVERROR(EINVAL); > +return AVERROR_EOF; > AVERROR_EOF does not have a semantic for writing, only for reading, so no. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] trac spam
Is it possible to make the "Bad Content" page invisible? It would be better if the spammer can't see the filtering rules. Michael ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Am 27.10.23 um 13:24 schrieb Jan Ekström: On Wed, Oct 25, 2023 at 4:14 PM Thilo Borgmann via ffmpeg-devel wrote: Hi, Am 24.10.23 um 23:15 schrieb Anton Khirnov: Hi all, as discussed at the dev meeting at VDD, we need to have a series of votes, the first of which concerns defining when is the GA voter list to be updated. As the previous attempt to vote on this was hampered by email delivery issues, and also criticized due to inadequate advance announcement, the vote was closed and we are going to try again. This time, to avoid any confusion, let me clearly state that this is a declaration of intent to initiate a GA vote next Monday (2023-10-30), unless there are substantial objections. The vote question will be: How do we update the list of active members of the general assembly? Proposed possibilities so far are: * twice a year (1st Jan & 1st July) (suggested at VDD) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each jan/july (suggested by Michael on the ML) Feel welcome to propose additional possibilities until Friday 2023-10-27. Other constructive comments also welcome. To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: andreas.rheinha...@gmail.com andriy.gel...@gmail.com an...@khirnov.net barryjz...@tencent.com ceffm...@gmail.com c...@passwd.hu dcni...@gmail.com derek.buitenh...@gmail.com d...@lynne.ee devin.heitmuel...@ltnglobal.com epira...@gmail.com ffm...@gyani.pro geo...@nsup.org g...@haasn.dev haihao.xi...@intel.com jamr...@gmail.com jan.ekst...@24i.com I have received the e-mail this time, which is great. But it seems like my worry about the mail map being the wrong way around was not unfounded. This e-mail is not the "community member Jan" me, and should never have any committer cases as I generally attempt to air gap the two sides. I'll try to post a patch today either inverting their order (which hopefully outputs my community member e-mail), or - since this e-mail is never supposed to apply to any committer cases - removing it. Andreas might be in the same boat. If necessary, we could have a seperate .mailmap_voting file only used in the GA script. Patches welcome, I guess. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, Oct 27, 2023 at 01:43:34PM +0300, Rémi Denis-Courmont wrote: > > > Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer > a écrit : [...] > >* If you have some flashy FFmpeg project you want to work on with a cost of > > between 5-15k $ then propose it on the mailing list, make yourself ready > > for > > some paperwork complexities and some public debate as thats the first time > > we > > try this, there will be extra issues likely. > > I don't think that code bounties count toward OSS "sustainability". It's > condoning the so-called jig economy, which is the opposite, IMO. This is just a first step. If we can attract the financial resources to pay people in a repeated fashion "each month" then thats absolutely what id like to do with SPI thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix
Patches attached.
From 8cbfb1beddcdede7c50a0879ac21654cba02f6b5 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 27 Oct 2023 14:26:50 +0200
Subject: [PATCH 1/2] avfilter/buffersrc: switch to activate
Signed-off-by: Paul B Mahol
---
libavfilter/buffersrc.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 453fc0fd5c..1216904721 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -36,6 +36,7 @@
#include "audio.h"
#include "avfilter.h"
#include "buffersrc.h"
+#include "filters.h"
#include "formats.h"
#include "internal.h"
#include "video.h"
@@ -484,21 +485,28 @@ static int config_props(AVFilterLink *link)
return 0;
}
-static int request_frame(AVFilterLink *link)
+static int activate(AVFilterContext *ctx)
{
-BufferSourceContext *c = link->src->priv;
+AVFilterLink *outlink = ctx->outputs[0];
+BufferSourceContext *c = ctx->priv;
+
+if (!c->eof && ff_outlink_get_status(outlink)) {
+c->eof = 1;
+return 0;
+}
-if (c->eof)
-return AVERROR_EOF;
+if (c->eof) {
+ff_outlink_set_status(outlink, AVERROR_EOF, c->last_pts);
+return 0;
+}
c->nb_failed_requests++;
-return AVERROR(EAGAIN);
+return FFERROR_NOT_READY;
}
static const AVFilterPad avfilter_vsrc_buffer_outputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
-.request_frame = request_frame,
.config_props = config_props,
},
};
@@ -507,7 +515,7 @@ const AVFilter ff_vsrc_buffer = {
.name = "buffer",
.description = NULL_IF_CONFIG_SMALL("Buffer video frames, and make them accessible to the filterchain."),
.priv_size = sizeof(BufferSourceContext),
-
+.activate = activate,
.init = init_video,
.uninit= uninit,
@@ -521,7 +529,6 @@ static const AVFilterPad avfilter_asrc_abuffer_outputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_AUDIO,
-.request_frame = request_frame,
.config_props = config_props,
},
};
@@ -530,7 +537,7 @@ const AVFilter ff_asrc_abuffer = {
.name = "abuffer",
.description = NULL_IF_CONFIG_SMALL("Buffer audio frames, and make them accessible to the filterchain."),
.priv_size = sizeof(BufferSourceContext),
-
+.activate = activate,
.init = init_audio,
.uninit= uninit,
--
2.42.0
From 6bb41a6d27800825610d6dc77c8c0d7cf5c3a8e8 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 27 Oct 2023 14:33:00 +0200
Subject: [PATCH 2/2] avfilter/buffersrc: return AVERROR_EOF on EOF
Fixes error when user keeps adding frames into filtergraph
that reached EOF by other means, for example EOF is signalled
by other filter in filtergraph or by buffersink.
Signed-off-by: Paul B Mahol
---
libavfilter/buffersrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 1216904721..b0a905d455 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -195,7 +195,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!frame)
return av_buffersrc_close(ctx, s->last_pts, flags);
if (s->eof)
-return AVERROR(EINVAL);
+return AVERROR_EOF;
s->last_pts = frame->pts + frame->duration;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Fri, Oct 27, 2023 at 01:10:15PM +0200, Thilo Borgmann via ffmpeg-devel wrote: > Hi, > > Am 27.10.23 um 12:43 schrieb Rémi Denis-Courmont: > > > > > > Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer > > a écrit : > > > This is financial sustainability Plan A (SPI) > > > ATM SPI has like 150k $, we do not activly seek donations, we do not > > > currently > > > use SPI money to fund any development. SPI money is ultimately controlled > > > by > > > the FFmpeg community and everything is transparent and public. > > > > > 1. We should fund some FFmpeg development with SPI-FFmpeg money > > > > Why should it be via SPI? What's the benefit of that hypothetical future > > additional funding going via SPI, as opposed to: > > obviously transparency and community control. None of which is given by the > options you list. SPI is also tax exempt, so depending on the exact financial details of everything, the cost for the company donating might be lower in relation to how much money ends with the developer after all taxes > > > - via FFlabs or any other reputable OSS multimedia consulting company, > > - a consortium of large companies, or > > - directly to a salaried or freelance developer. > > Also, it is not that these shall cease to be done. Using SPI money is one > more option. yes, exactly! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Am 27.10.23 um 13:30 schrieb Rémi Denis-Courmont: Hi, Le 27 octobre 2023 14:10:15 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer a écrit : This is financial sustainability Plan A (SPI) ATM SPI has like 150k $, we do not activly seek donations, we do not currently use SPI money to fund any development. SPI money is ultimately controlled by the FFmpeg community and everything is transparent and public. 1. We should fund some FFmpeg development with SPI-FFmpeg money Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: obviously transparency and community control. None of which is given by the options you list. Do you want transparency there? This is *not* about having open source code and the public code review. Yes, absolutely. We are an *open* project. And no, we of course don't talk about the review part. This is about people's work commitments and compensation. Martin and I are about the only people here whose taxable income is public information. It doesn't seem to me that people typically want that sort of information public. If s.o. is not fine with receiving these funds in public, than this is not our public money's problem. This cuts off this individual from receiving SPI money in the first place but not cutting anyone off the other options you listed. We don't refund in private for travel & hardware, same must be true for SPI sponsored development. And then that means more non-technical work for the unpaid *other* members of the community in managing the paid developers' work. This is also unlikely to ve welcome to most. - via FFlabs or any other reputable OSS multimedia consulting company, - a consortium of large companies, or - directly to a salaried or freelance developer. Also, it is not that these shall cease to be done. Using SPI money is one more option. Using SPI money would hypothetically be an option if there was enough money. Currently there is not. There is enough budget to fund several of the smaller tasks Michael proposed. That's the part that you'd need to clarify first. What relevant flashy cool development will attract those donations? Why should they be funded by donations rather than more traditional business transactions? Hen & egg. What? Why do you need to start spending money before you can have ideas of cool projects? That makes zero sense to me. What? Michael asked specifically to propose cool projects. * If you have some flashy FFmpeg project you want to work on with a cost of between 5-15k $ then propose it on the mailing list, make yourself ready for some paperwork complexities and some public debate as thats the first time we try this, there will be extra issues likely. I don't think that code bounties count toward OSS "sustainability". It's condoning the so-called jig economy, which is the opposite, IMO. Code bounties sustain a/the developer(s) working on it and that way they stay active with the project. No they don't. They make up a precarious insecure and unstable financial situation. That's the literal opposite of sustainability. It's fine to take a bounty as a bit of extra income, or as an internship, but that is about it. That might be true for you and not for others. You deleted history here where I said there are more reliable ways but they don't void bounties and that even if this thread is about bounties, we are not limited to them. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
On Thu, Oct 26, 2023 at 06:28:25PM -0700, Kieran Kunhya wrote: > Hi, > > On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > Of course. FFmpeg has a donations account. So the money is already there > > and > > already used for the reimbursement requests. Whatever we spent it for > > needs to > > be decided by the community. Spending more money instead of just watch it > > growing is a good thing. That this will lead to more "disaster" is an > > assumption > > without basis. Even if this does happen and fails, its still better than > > not > > having even tried. > > > > Reimbursement requests for clearly defined things like travel costs with > receipts, or hardware that the project owns is in no way comparable to > consulting work, contracts, statements of work etc. And the current swscale > proposal is far from this too. [...] > Agreement via mailing list for money is a recipe for disaster. What we need > are clear statements of work that are voted on by TC. > We can't even agree on patch reviews, throwing money into the mix is > throwing gasoline into the fire. GSoC pays about 5000USD for each individual over the summer. The proposals for such projects where discussed and agreed upon with very little if any disagreement. We needed no formal votes, we needed no comittees and also for patches, you can pick out the 10 most controversal ones in a year and these are highly vissible, but there are thousands that are reviewed and applied by consensus with noone objecting. You seem to pick the most controversal things as reference, and argue that it cant work. 1 of a 100 patches got stuck in fights so 90 of 100 funding proposals would get stuck ? Now we still have no proposals for SPI money, but assume we do. either we all agree or theres someone who publically objects, in the later case we will first try to reach an agreement if that fails. We can vote, its not a big deal. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec/dovi_rpu: verify RPU data CRC32
On 26/10/2023 17.44, Michael Niedermayer wrote:
On Wed, Aug 09, 2023 at 01:46:57PM -0400, quietvoid wrote:
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Signed-off-by: quietvoid
---
libavcodec/dovi_rpu.c | 46 ---
libavcodec/dovi_rpu.h | 3 ++-
libavcodec/hevcdec.c | 3 ++-
3 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index dd38936552..1dfeee7564 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -22,6 +22,7 @@
*/
#include "libavutil/buffer.h"
+#include "libavutil/crc.h"
#include "dovi_rpu.h"
#include "golomb.h"
@@ -191,13 +192,17 @@ static inline int64_t get_se_coef(GetBitContext *gb,
const AVDOVIRpuDataHeader *
}
\
} while (0)
-int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size)
+int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
+ int err_recognition)
{
AVDOVIRpuDataHeader *hdr = >header;
GetBitContext *gb = &(GetBitContext){0};
DOVIVdrRef *vdr;
int ret;
+size_t actual_rpu_size;
+uint8_t trailing_zeroes = 0;
+
uint8_t nal_prefix;
uint8_t rpu_type;
uint8_t vdr_seq_info_present;
@@ -205,7 +210,22 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu,
size_t rpu_size)
uint8_t use_prev_vdr_rpu;
uint8_t use_nlq;
uint8_t profile;
-if ((ret = init_get_bits8(gb, rpu, rpu_size)) < 0)
+
+uint32_t rpu_data_crc32;
+uint32_t computed_crc32;
+
+for (int i = rpu_size - 1; i > 0; i--) {
+if (!rpu[i]) {
+trailing_zeroes++;
+} else {
+break;
+}
+}
+
+actual_rpu_size = rpu_size - trailing_zeroes;
+
+/* Exclude trailing byte (0x80) from reader */
+if ((ret = init_get_bits8(gb, rpu, actual_rpu_size - 1)) < 0)
return ret;
/* RPU header, common values */
@@ -440,7 +460,27 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu,
size_t rpu_size)
color->source_diagonal = get_bits(gb, 10);
}
-/* FIXME: verify CRC32, requires implementation of AV_CRC_32_MPEG_2 */
+if (!(err_recognition & AV_EF_CRCCHECK))
+return 0;
+
+/* Skip unsupported until CRC32 */
+skip_bits_long(gb, get_bits_left(gb) - 32);
+
+rpu_data_crc32 = get_bits_long(gb, 32);
+
+/* Verify CRC32, buffer excludes the prefix, CRC32 and trailing byte */
+computed_crc32 = av_bswap32(av_crc(av_crc_get_table(AV_CRC_32_IEEE),
+ -1, rpu + 1, actual_rpu_size - 6));
+
+if (rpu_data_crc32 != computed_crc32) {
+av_log(s->logctx, AV_LOG_ERROR,
+ "RPU CRC mismatch! Expected %"PRIu32", received %"PRIu32"\n",
+ rpu_data_crc32, computed_crc32);
+
+if (err_recognition & AV_EF_EXPLODE)
+goto fail;
+}
(correctly designed) CRCs have the beautifull symmetry that you can merge
the crc32 value into the crc computation and then a 0 means no CRC missmatch
(there are many other cool properties but this one allows to simplify the code)
This works too: (and is simpler)
/* Skip unsupported until CRC32 */
skip_bits_long(gb, get_bits_left(gb));
/* Verify CRC32, buffer excludes the prefix, CRC32 and trailing byte */
computed_crc32 = av_bswap32(av_crc(av_crc_get_table(AV_CRC_32_IEEE),
-1, rpu + 1, actual_rpu_size - 2));
if (computed_crc32) {
av_log(s->logctx, AV_LOG_ERROR, "RPU CRC mismatch! %"PRIX32"\n",
computed_crc32);
if (err_recognition & AV_EF_EXPLODE)
goto fail;
}
Hi Michael. I like the idea and it's a cool property.
However the then printed CRC on mismatch is not a useful value, so I'm
unsure if it's better to simplify here.
I like having the expected CRC logged here.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Hi, Le 27 octobre 2023 14:10:15 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : >> Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer >> a écrit : >>> This is financial sustainability Plan A (SPI) >>> ATM SPI has like 150k $, we do not activly seek donations, we do not >>> currently >>> use SPI money to fund any development. SPI money is ultimately controlled by >>> the FFmpeg community and everything is transparent and public. >> >>> 1. We should fund some FFmpeg development with SPI-FFmpeg money >> >> Why should it be via SPI? What's the benefit of that hypothetical future >> additional funding going via SPI, as opposed to: > >obviously transparency and community control. None of which is given by the >options you list. Do you want transparency there? This is *not* about having open source code and the public code review. This is about people's work commitments and compensation. Martin and I are about the only people here whose taxable income is public information. It doesn't seem to me that people typically want that sort of information public. And then that means more non-technical work for the unpaid *other* members of the community in managing the paid developers' work. This is also unlikely to ve welcome to most. >> - via FFlabs or any other reputable OSS multimedia consulting company, >> - a consortium of large companies, or >> - directly to a salaried or freelance developer. > >Also, it is not that these shall cease to be done. Using SPI money is one more >option. Using SPI money would hypothetically be an option if there was enough money. Currently there is not. >> That's the part that you'd need to clarify first. What relevant flashy cool >> development will attract those donations? Why should they be funded by >> donations rather than more traditional business transactions? > >Hen & egg. What? Why do you need to start spending money before you can have ideas of cool projects? That makes zero sense to me. >>> * If you have some flashy FFmpeg project you want to work on with a cost of >>> between 5-15k $ then propose it on the mailing list, make yourself ready >>> for >>> some paperwork complexities and some public debate as thats the first >>> time we >>> try this, there will be extra issues likely. >> >> I don't think that code bounties count toward OSS "sustainability". It's >> condoning the so-called jig economy, which is the opposite, IMO. > >Code bounties sustain a/the developer(s) working on it and that way they stay >active with the project. No they don't. They make up a precarious insecure and unstable financial situation. That's the literal opposite of sustainability. It's fine to take a bounty as a bit of extra income, or as an internship, but that is about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
On Wed, Oct 25, 2023 at 4:14 PM Thilo Borgmann via ffmpeg-devel wrote: > > Hi, > > Am 24.10.23 um 23:15 schrieb Anton Khirnov: > > Hi all, > > as discussed at the dev meeting at VDD, we need to have a series of > > votes, the first of which concerns defining when is the GA voter list to > > be updated. > > > > As the previous attempt to vote on this was hampered by email delivery > > issues, and also criticized due to inadequate advance announcement, the > > vote was closed and we are going to try again. > > > > This time, to avoid any confusion, let me clearly state that this is a > > declaration of intent to initiate a GA vote next Monday (2023-10-30), > > unless there are substantial objections. > > > > The vote question will be: > > How do we update the list of active members of the general assembly? > > > > Proposed possibilities so far are: > > * twice a year (1st Jan & 1st July) > >(suggested at VDD) > > * before each vote > >(suggested at VDD) > > * never (keep the 2020 version) > >(suggested at VDD) > > * keep everyone who had vote rights but add active developers each jan/july > >(suggested by Michael on the ML) > > > > Feel welcome to propose additional possibilities until Friday > > 2023-10-27. > > > > Other constructive comments also welcome. > > > > To test the voting beforehand this time, I created a test vote with a fake-GA > member list. All of the following people should have received a corresponding > mail. If you are part of this list, but did not receive an email, check your > spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you > didn't > get the mail. > > The list is as follows: > > andreas.rheinha...@gmail.com > andriy.gel...@gmail.com > an...@khirnov.net > barryjz...@tencent.com > ceffm...@gmail.com > c...@passwd.hu > dcni...@gmail.com > derek.buitenh...@gmail.com > d...@lynne.ee > devin.heitmuel...@ltnglobal.com > epira...@gmail.com > ffm...@gyani.pro > geo...@nsup.org > g...@haasn.dev > haihao.xi...@intel.com > jamr...@gmail.com > jan.ekst...@24i.com I have received the e-mail this time, which is great. But it seems like my worry about the mail map being the wrong way around was not unfounded. This e-mail is not the "community member Jan" me, and should never have any committer cases as I generally attempt to air gap the two sides. I'll try to post a patch today either inverting their order (which hopefully outputs my community member e-mail), or - since this e-mail is never supposed to apply to any committer cases - removing it. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Hi, Am 27.10.23 um 12:43 schrieb Rémi Denis-Courmont: Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer a écrit : This is financial sustainability Plan A (SPI) ATM SPI has like 150k $, we do not activly seek donations, we do not currently use SPI money to fund any development. SPI money is ultimately controlled by the FFmpeg community and everything is transparent and public. 1. We should fund some FFmpeg development with SPI-FFmpeg money Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: obviously transparency and community control. None of which is given by the options you list. - via FFlabs or any other reputable OSS multimedia consulting company, - a consortium of large companies, or - directly to a salaried or freelance developer. Also, it is not that these shall cease to be done. Using SPI money is one more option. It seems the sole benefit is that SPI can solicit donations. So then you are putting the cart before the horses. Secure that extra funding first. To help 2. we should favor flashy, cool development that can bring in more donations That's the part that you'd need to clarify first. What relevant flashy cool development will attract those donations? Why should they be funded by donations rather than more traditional business transactions? Hen & egg. Fortunately, as Michael suggests, we have a starting budget already and 5-10 K seem totally worth exploring this possibility for us. * If you have some flashy FFmpeg project you want to work on with a cost of between 5-15k $ then propose it on the mailing list, make yourself ready for some paperwork complexities and some public debate as thats the first time we try this, there will be extra issues likely. I don't think that code bounties count toward OSS "sustainability". It's condoning the so-called jig economy, which is the opposite, IMO. Code bounties sustain a/the developer(s) working on it and that way they stay active with the project. Of course there are more reliable ways but that does not void bounties. Also, even if Michael just proposed code bounties - nothing stops us from sponsoring non-code-bounties to sustain FFmpeg. For SPI, their limitations are our limitations and they are not limited to code bounties. -Thilo ___ 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] avcodec/evc_parse: Check tid
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: piątek, 13 października 2023 01:28
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 3/3] avcodec/evc_parse: Check tid
>
> The check is based on not infinite looping. It is likely a more strict
check can be
> done
>
> Fixes: Infinite loop
> Fixes: 62473/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
> Fixes: 62765/clusterfuzz-testcase-minimized-ffmpeg_dem_EVC_fuzzer-
> 6448531252314112
>
> Found-by: continuous fuzzing process
> https://protect2.fireeye.com/v1/url?k=06e4faf3-676fefea-06e571bc-
> 74fe485cbfec-11816a289a0e9c00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> 255706ce61..43b8dabf8b 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -174,6 +174,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> } else {
> int SubGopLength = 1 << sps->log2_sub_gop_length;
>
> +if (tid > (SubGopLength > 1 ? 1 + av_log2(SubGopLength - 1) :
0))
> +return AVERROR_INVALIDDATA;
> +
> if (tid == 0) {
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
SubGopLength;
> poc->DocOffset = 0;
> --
> 2.17.1
>
int SubGopLength = 1 << sps->log2_sub_gop_length;
if (tid > 1 + av_log2(SubGopLength - 1))
return AVERROR_INVALIDDATA;
For the value of SubGopLength = 1 ( if sps->log2_sub_gop_length = 0; "The
value of log2_sub_gop_length shall be in the range of 0 to 5, inclusive" -
ISO_IEC_23094-1-2020 7.4.3.1), we have av_log2(0). The value of the
logarithm of 0 with any base (in this case, log2) is minus infinity (-inf)
Perhaps we should consider changing the condition to:
if (tid < 0 || tid > av_log2(SubGopLength))
return AVERROR_INVALIDDATA;
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=63dfcc8a-0254d993-63de47c5-
> 74fe485cbfec-e9d44b0bcc16ae00=1=16696cd9-38c1-42d0-9196-
> 8ad7c6d1d0d6=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 41 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
>
Thanks for the revised patch!
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f6071484ff..87c19a5cb9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> @item program_date_time
> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>
> +@item init_program_date_time
> +Time to start program date time at.
> +
Probably would help to mention the expected format here.
> @item second_level_segment_index
> Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> besides date/time values when strftime is on.
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 4ef84c05c1..5dfff6b2b6 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -212,6 +212,8 @@ typedef struct HLSContext {
> int64_t recording_time;
> int64_t max_seg_size; // every segment file max size
>
> +char *init_program_date_time;
> +
> char *baseurl;
> char *vtt_format_options_str;
> char *subtitle_filename;
> @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls,
> return 0;
> }
>
> +static double parse_iso8601(const char *ptr) {
> +struct tm program_date_time;
> +int y,M,d,h,m,s;
> +double ms;
> +if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", , , , , , , ) !=
> 7) {
> +return -1;
> +}
> +
> +program_date_time.tm_year = y - 1900;
> +program_date_time.tm_mon = M - 1;
> +program_date_time.tm_mday = d;
> +program_date_time.tm_hour = h;
> +program_date_time.tm_min = m;
> +program_date_time.tm_sec = s;
> +program_date_time.tm_isdst = -1;
> +
> +return mktime(_date_time) + (double)(ms / 1000);
> +}
> +
> static int parse_playlist(AVFormatContext *s, const char *url, VariantStream
> *vs)
> {
> HLSContext *hls = s->priv_data;
> @@ -1257,24 +1278,11 @@ static int parse_playlist(AVFormatContext *s, const
> char *url, VariantStream *vs
> }
> }
> } else if (av_strstart(line, "#EXT-X-PROGRAM-DATE-TIME:", )) {
> -struct tm program_date_time;
> -int y,M,d,h,m,s;
> -double ms;
> -if (sscanf(ptr, "%d-%d-%dT%d:%d:%d.%lf", , , , , , ,
> ) != 7) {
> +discont_program_date_time = parse_iso8601(ptr);
> +if (discont_program_date_time < 0) {
> ret = AVERROR_INVALIDDATA;
> goto fail;
> }
> -
> -program_date_time.tm_year = y - 1900;
> -program_date_time.tm_mon = M - 1;
> -program_date_time.tm_mday = d;
> -program_date_time.tm_hour = h;
> -program_date_time.tm_min = m;
> -program_date_time.tm_sec = s;
> -program_date_time.tm_isdst = -1;
> -
> -discont_program_date_time = mktime(_date_time);
> -discont_program_date_time += (double)(ms / 1000);
> } else if (av_strstart(line, "#", NULL)) {
> continue;
> } else if (line[0]) {
> @@ -2867,7 +2875,7 @@ static int hls_init(AVFormatContext *s)
> char *p = NULL;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> -double initial_program_date_time = av_gettime() / 100.0;
> +double initial_program_date_time = hls->init_program_date_time ?
> parse_iso8601(hls->init_program_date_time) : av_gettime() / 100.0;
As parse_iso8601 parsing user input can fail, it should properly report the
error and fail. Especially given that it does not accept all variations
of ISO-8601 date/time IIUC.
It might be confusing if the user specifies a time, forgets the milliseconds
and it will just silently not use the option at all?
>
> if (hls->use_localtime) {
> pattern = get_default_pattern_localtime_fmt(s);
> @@ -3141,6 +3149,7 @@ static const AVOption options[] = {
> {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> {"append_list", "append the new segments into old hls segment list", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_STRING, .flags = E},
> {"second_level_segment_index", "include segment index in segment
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
>
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Le 26 octobre 2023 18:45:23 GMT+03:00, Michael Niedermayer a écrit : >This is financial sustainability Plan A (SPI) >ATM SPI has like 150k $, we do not activly seek donations, we do not currently >use SPI money to fund any development. SPI money is ultimately controlled by >the FFmpeg community and everything is transparent and public. >1. We should fund some FFmpeg development with SPI-FFmpeg money Why should it be via SPI? What's the benefit of that hypothetical future additional funding going via SPI, as opposed to: - via FFlabs or any other reputable OSS multimedia consulting company, - a consortium of large companies, or - directly to a salaried or freelance developer. It seems the sole benefit is that SPI can solicit donations. So then you are putting the cart before the horses. Secure that extra funding first. >To help 2. we should favor flashy, cool development that can bring in more >donations That's the part that you'd need to clarify first. What relevant flashy cool development will attract those donations? Why should they be funded by donations rather than more traditional business transactions? >* If you have some flashy FFmpeg project you want to work on with a cost of > between 5-15k $ then propose it on the mailing list, make yourself ready for > some paperwork complexities and some public debate as thats the first time we > try this, there will be extra issues likely. I don't think that code bounties count toward OSS "sustainability". It's condoning the so-called jig economy, which is the opposite, IMO. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] financial sustainability Plan A (SPI)
Am 27.10.23 um 03:28 schrieb Kieran Kunhya: Hi, On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: Of course. FFmpeg has a donations account. So the money is already there and already used for the reimbursement requests. Whatever we spent it for needs to be decided by the community. Spending more money instead of just watch it growing is a good thing. That this will lead to more "disaster" is an assumption without basis. Even if this does happen and fails, its still better than not having even tried. Reimbursement requests for clearly defined things like travel costs with receipts, or hardware that the project owns is in no way comparable to consulting work, contracts, statements of work etc. And the current swscale proposal is far from this too. Yes, of course they are different. Most importantly sponsored development needs to be agreed upon beforehand. That does not imply sponsored work is not clearly defined. I miss your argument about why it can't be done in this. Also, you just advertised FFmpeg and asked for more financial support in your talk at Demuxed [1] - so I figure your prefered way of doing that would be to channel money into some company without the community being involved? Actually if you watched the presentation, I said big companies need to support maintenance (not the same as bounties) of FFmpeg by hiring employees to work full time as they do with Linux Kernel maintainers. Or failing that they can donate to the community - but as you know well the numbers we have are not enough to hire full time maintainers. I'm totally fine with you asking big companies to hire devs for FFmpeg maintenance. That does not relate to my question, though. Do I assume correctly that your prefered way of doing that would be to channel money into some company without the community being involved? Agreement via mailing list for money is a recipe for disaster. What we need are clear statements of work that are voted on by TC. That's not the purpose of the TC. We of course need to have a good way of approving or disapproving proposals and of course we need these to be clearly defined. I again miss to see your argument why that shall not be possible on the ML - everyone on this list knows where your suspicion comes from but again, without even having tried, it's just your assumption and should IMHO not stopping us from trying to implement such a procedure. We can't even agree on patch reviews, throwing money into the mix is throwing gasoline into the fire. Being in conflict about a patch is completely different to conflict about some feature we might want. And no, not everything is as controversial as SDR or gets controversial just because it would be sponsored. You think there would have been real and non-resolvable opposition against bringing multi-threading into ffmpeg.c? You assume a proposed sponsored AV2 decoder will raise such opposition? However, since I agree with you that there will be different oppinions, why would you think that a e.g. a vote/committee or whatever we will choose could not resolve how we deal with these cases? And since you also advertised explicitly for FFlabs - what is your relation to FFlabs? I own 25% of that company and I am not aware of any relationship. You just did advertise FFlabs because... FFlabs exists? FFlabs is a company co-owned by some FFmpeg developers, it's not FFmpeg nor can it represent it or act on its behalf. I linked to the consulting page and also to FFlabs which as far as I know is the only company offering an SLA on FFmpeg. If others existed I would have included them. Nothing wrong about bringing attention to ff.org/consulting or FFlabs. My question is what your relationship with FFlabs is? As soon as we pay developers via SPI it can become a good zero-trust environment for donators to offer tasks & money to FFmpeg and handle the money flow via SPI. The donators can be sure that their issues are handled properly in the project (on the ML) and do not flow away into some other sink and the developers can be sure to get their money from SPI because the offer is public and backed by the FFmpeg SPI account. Sounds like a quite trustworthy and most importantyl transparent way to handle things and build up trust in potential donators that the money they spent actually end up with FFmpeg. Do you really think the way SPI funding is managed currently matches your description? That's exactly the point, to find a procedure that works for sponsored work. Stefano approves by saying "Approved on my side, pending Michael's approval." That won't change because SPI demands it. Done. We can change the names Stefano and Michael into whatever, but that's it. > This is not at all a community driven process where one person can veto > everything. What needs to be setup, is a procedure to find FFmpeg's decision about it. Who transports it to and approves it towards
[FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..86b0852c12 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
It has also occurred to me that in case that the first or last option wins, the lists would not get updated until January. That means we would either need to postpone TC/CC elections until then, or vote using the old lists, both of which seem suboptimal to me. We could add wording to options 1 and 4, stating that the voter lists will be exceptionally updated immediately after this vote. Or we could keep them as they are, and add two new options with the exception (though I fear so many options might confuse people). Does anyone feel particularly strongly about either of those? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v2: Fix warning
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..0d16699f66 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+uint32_t vaflags = 0;
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +883,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Quoting Michael Niedermayer (2023-10-25 21:30:10) > Hi Anton > > first let me say, this looks much better setup than the previous attempt by jb > > On Tue, Oct 24, 2023 at 11:15:19PM +0200, Anton Khirnov wrote: > > Hi all, > > as discussed at the dev meeting at VDD, we need to have a series of > > votes, the first of which concerns defining when is the GA voter list to > > be updated. > > > > As the previous attempt to vote on this was hampered by email delivery > > issues, and also criticized due to inadequate advance announcement, the > > vote was closed and we are going to try again. > > > > This time, to avoid any confusion, let me clearly state that this is a > > declaration of intent to initiate a GA vote next Monday (2023-10-30), > > unless there are substantial objections. > > > > The vote question will be: > >How do we update the list of active members of the general assembly? > > > > Proposed possibilities so far are: > > * twice a year (1st Jan & 1st July) > > (suggested at VDD) > > * before each vote > > (suggested at VDD) > > * never (keep the 2020 version) > > (suggested at VDD) > > * keep everyone who had vote rights but add active developers each jan/july > > (suggested by Michael on the ML) > > > > Feel welcome to propose additional possibilities until Friday > > 2023-10-27. > > > > Other constructive comments also welcome. > > First i suggest s#jan/july#1st Jan & 1st July# > > Second i suggest to pick a time too, like 0:00 UTC Both of these sound reasonable to me, I'll reword first and last possibility to state it's 1st of that month 0:00 UTC. > Third, for future votes i suggest to lengthen the period of > proposing of additional possibilities. Here we all maybe have seen this > already > but. If this was new than 2-3 days really is too short. That period needs > to include discussion and thinking for a person who might be working 8 hour > a day on something unrelated to FFmpeg. I agree in general that it would be good to have at least two weeks, but in this case this has been proposed and discussed a month ago already. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..c3ecd90077 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -882,7 +882,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, , vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, );
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/evc_parse: remove pow() and log2()
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: czwartek, 5 października 2023 00:59
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 3/4] avcodec/evc_parse: remove pow() and
> log2()
>
> The use of float based functions is both unneeded and wrong due to
> unpredictable rounding
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> 5ab33166cf3..20b6849041a 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -176,7 +176,8 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> poc->PicOrderCntVal = 0;
> poc->DocOffset = -1;
> } else {
> -int SubGopLength = (int)pow(2.0, sps->log2_sub_gop_length);
> +int SubGopLength = 1 << sps->log2_sub_gop_length;
> +
> if (tid == 0) {
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
SubGopLength;
> poc->DocOffset = 0;
> @@ -191,15 +192,16 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
> EVCParserSliceHeader *sh,
> poc->prevPicOrderCntVal += SubGopLength;
> ExpectedTemporalId = 0;
> } else
> -ExpectedTemporalId = 1 + (int)log2(poc->DocOffset);
> +ExpectedTemporalId = 1 + av_log2(poc->DocOffset);
> +
> while (tid != ExpectedTemporalId) {
> poc->DocOffset = (poc->DocOffset + 1) % SubGopLength;
> if (poc->DocOffset == 0)
> ExpectedTemporalId = 0;
> else
> -ExpectedTemporalId = 1 +
(int)log2(poc->DocOffset);
> +ExpectedTemporalId = 1 +
> + av_log2(poc->DocOffset);
> }
> -PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset +
1) /
> (int)pow(2.0, tid) - 2));
> +PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset
> + + 1) / (1 << tid) - 2));
> poc->PicOrderCntVal = poc->prevPicOrderCntVal +
PocOffset;
> }
> }
> --
> 2.17.1
>
Reviewed. Looks good. It can be merged.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=b3e7a91c-d29c0395-b3e62253-
> 74fe48600034-766db145edef46dd=1=130227c8-f092-4124-aef7-
> bcb9009528da=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check num_remaining_tiles_in_slice_minus1
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: czwartek, 5 października 2023 00:59
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check
> num_remaining_tiles_in_slice_minus1
>
> Fixes: out of array access
> Fixes: 62467/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688
>
> Found-by: continuous fuzzing process
> https://protect2.fireeye.com/v1/url?k=10fdc12a-701f5c77-10fc4a65-
> 000babd9f1ba-c93ee30773aca891=1=409cddd0-bda7-445c-b76b-
> 1caf069ec3f8=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/evc_parse.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> bd3a4416f2d..5ab33166cf3 100644
> --- a/libavcodec/evc_parse.c
> +++ b/libavcodec/evc_parse.c
> @@ -58,8 +58,12 @@ int ff_evc_parse_slice_header(GetBitContext *gb,
> EVCParserSliceHeader *sh,
> if (!sh->arbitrary_slice_flag)
> sh->last_tile_id = get_bits(gb, pps->tile_id_len_minus1 + 1);
> else {
> -sh->num_remaining_tiles_in_slice_minus1 =
get_ue_golomb_long(gb);
> -num_tiles_in_slice = sh->num_remaining_tiles_in_slice_minus1
+ 2;
> +unsigned num_remaining_tiles_in_slice_minus1 =
> get_ue_golomb_long(gb);
> +if (num_remaining_tiles_in_slice_minus1 > EVC_MAX_TILE_ROWS *
> EVC_MAX_TILE_COLUMNS - 2)
> +return AVERROR_INVALIDDATA;
> +
> +num_tiles_in_slice = num_remaining_tiles_in_slice_minus1 + 2;
> +sh->num_remaining_tiles_in_slice_minus1 =
> + num_remaining_tiles_in_slice_minus1;
> for (int i = 0; i < num_tiles_in_slice - 1; ++i)
> sh->delta_tile_id_minus1[i] = get_ue_golomb_long(gb);
> }
> --
> 2.17.1
>
Reviewed and tested. It can be merged.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=91e63ba2-f104a6ff-91e7b0ed-
> 000babd9f1ba-bd82db9b8a752a77=1=409cddd0-bda7-445c-b76b-
> 1caf069ec3f8=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] avformat/hlsenc: Fix name of flag in error message
Dave Johansen 于2023年10月27日周五 12:00写道：
>
> ---
> libavformat/hlsenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 24a0304f78..93c47b631b 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1013,7 +1013,7 @@ static int sls_flags_filename_process(struct
> AVFormatContext *s, HLSContext *hls
> 't', (int64_t)round(duration *
> HLS_MICROSECOND_UNIT)) < 1) {
> av_log(hls, AV_LOG_ERROR,
> "Invalid second level segment filename template '%s',
> "
> - "you can try to remove second_level_segment_time
> flag\n",
> + "you can try to remove second_level_segment_duration
> flag\n",
> vs->avf->url);
> av_freep();
> return AVERROR(EINVAL);
> @@ -1106,7 +1106,7 @@ static int
> sls_flag_use_localtime_filename(AVFormatContext *oc, HLSContext *c, V
> char *filename = NULL;
> if (replace_int_data_in_filename(, oc->url, 't', 0) <
> 1) {
> av_log(c, AV_LOG_ERROR, "Invalid second level segment
> filename template '%s', "
> -"you can try to remove second_level_segment_time
> flag\n",
> +"you can try to remove second_level_segment_duration
> flag\n",
> oc->url);
> av_freep();
> return AVERROR(EINVAL);
> --
> 2.39.2 (Apple Git-143)
>
> ___
> 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".
LGTM
Good catch
Thanks
Steven
___
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] avutil/hwcontext_vaapi: return ENOSYS for unsupported operation
From: Zhao Zhili
av_hwframe_transfer_data try with src_ctx first. If the operation
failed with AVERROR(ENOSYS), it will try again with dst_ctx. Return
AVERROR(EINVAL) makes the second step being skipped.
---
libavutil/hwcontext_vaapi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..bb28bcf588 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -217,7 +217,7 @@ static int vaapi_get_image_format(AVHWDeviceContext *hwdev,
return 0;
}
}
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
}
static int vaapi_frames_get_constraints(AVHWDeviceContext *hwdev,
@@ -805,19 +805,19 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
if (!ctx->derive_works && (flags & AV_HWFRAME_MAP_DIRECT)) {
// Requested direct mapping but it is not possible.
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
}
if (dst->format == AV_PIX_FMT_NONE)
dst->format = hwfc->sw_format;
if (dst->format != hwfc->sw_format && (flags & AV_HWFRAME_MAP_DIRECT)) {
// Requested direct mapping but the formats do not match.
-return AVERROR(EINVAL);
+return AVERROR(ENOSYS);
}
err = vaapi_get_image_format(hwfc->device_ctx, dst->format, _format);
if (err < 0) {
// Requested format is not a valid output format.
-return AVERROR(EINVAL);
+return err;
}
map = av_malloc(sizeof(*map));
@@ -992,7 +992,7 @@ static int vaapi_map_to_memory(AVHWFramesContext *hwfc,
AVFrame *dst,
if (dst->format != AV_PIX_FMT_NONE) {
err = vaapi_get_image_format(hwfc->device_ctx, dst->format, NULL);
if (err < 0)
-return AVERROR(ENOSYS);
+return err;
}
err = vaapi_map_frame(hwfc, dst, src, flags);
--
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 1/2] avutil/hwcontext_vulkan: cuda doesn't belong to valid_sw_formats
From: Zhao Zhili
Move it to transfer_get_formats.
---
libavutil/hwcontext_vulkan.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 8dd40cb66f..8481427b42 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -1664,11 +1664,6 @@ static int
vulkan_frames_get_constraints(AVHWDeviceContext *ctx,
NULL, NULL, NULL, NULL, 0, 0) >= 0;
}
-#if CONFIG_CUDA
-if (p->dev_is_nvidia)
-count++;
-#endif
-
constraints->valid_sw_formats = av_malloc_array(count + 1,
sizeof(enum
AVPixelFormat));
if (!constraints->valid_sw_formats)
@@ -1684,10 +1679,6 @@ static int
vulkan_frames_get_constraints(AVHWDeviceContext *ctx,
}
}
-#if CONFIG_CUDA
-if (p->dev_is_nvidia)
-constraints->valid_sw_formats[count++] = AV_PIX_FMT_CUDA;
-#endif
constraints->valid_sw_formats[count++] = AV_PIX_FMT_NONE;
constraints->min_width = 1;
@@ -2416,12 +2407,22 @@ static int
vulkan_transfer_get_formats(AVHWFramesContext *hwfc,
enum AVHWFrameTransferDirection dir,
enum AVPixelFormat **formats)
{
-enum AVPixelFormat *fmts = av_malloc_array(2, sizeof(*fmts));
+enum AVPixelFormat *fmts;
+int n = 2;
+
+#if CONFIG_CUDA
+n++;
+#endif
+fmts = av_malloc_array(n, sizeof(*fmts));
if (!fmts)
return AVERROR(ENOMEM);
-fmts[0] = hwfc->sw_format;
-fmts[1] = AV_PIX_FMT_NONE;
+n = 0;
+fmts[n++] = hwfc->sw_format;
+#if CONFIG_CUDA
+fmts[n++] = AV_PIX_FMT_CUDA;
+#endif
+fmts[n++] = AV_PIX_FMT_NONE;
*formats = fmts;
return 0;
--
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] avformat/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
David Johansen 于2023年10月27日周五 12:03写道： > > > > > LGTM > > > > > > Thanks > > Steven > > > > I'm new to ffmpeg development so what's the process for this to be merged? > Do I need to do something or is it taken care of by a different > process/someone else? Nothing, just leave enough time for more developers review, and will push this if no more comments. Don't worry David, this is valuable patch, you did a great job. > > Thanks, > Dave > ___ > 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". Thanks Steven ___ 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".
