Re: [FFmpeg-devel] [PATCH] libavcodec/h264dec: avoid arithmetic on null pointers
Quoting Jeremy Dorfman (2023-03-01 19:50:08)
> null pointer arithmetic is undefined behavior in C.
> ---
> libavcodec/h264dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 2d691731c5..ef698f2630 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -912,8 +912,8 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
> H264Picture *out, int *g
> av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill
> missing\n", field);
>
> for (p = 0; p<4; p++) {
> -dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
> -src_data[p] = f->data[p] + field *f->linesize[p];
> +dst_data[p] = f->data[p] ? f->data[p] +
> (field^1)*f->linesize[p] : NULL;
> +src_data[p] = f->data[p] ? f->data[p] + field
> *f->linesize[p] : NULL;
Why would that be NULL? Seems like something that should not happen.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/ac3: Remove unused fields
Quoting Nicolas Gaullier (2023-02-21 11:12:32) > Signed-off-by: Nicolas Gaullier > --- > libavcodec/ac3dec.h | 2 -- > 1 file changed, 2 deletions(-) Looks ok, will push. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/4] Add hevc alpha layer decoding basic support
Quoting zhilizhao(赵志立) (2023-02-28 10:00:15) > > > On Jan 6, 2023, at 23:52, Zhao Zhili wrote: > > > > From: Zhao Zhili > > > > v2: > > 1. Check vps_max_layers and vps_max_layer_id inside hevc decoder > > 2. Add hevc_extract_layer bsf to do the job rather than modifing > > hevc_metadata, > > 3. Check vps_max_layers_minus1 and vps_max_layer_id inside bsf > > 4. Update vps_max_layers_minus1 and vps_max_layer_id when rewrite as base > > layer > > 5. vps_extension should be updated rather than drop entirely, add a TODO > > Will push soon if there's no objections. Can't we do this without weird bitstream filtes and obscure options leaking to the user? It's all signalled in the bitstream in a rather straightforward way. Just extend hevcdec to decode it. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/4] Add hevc alpha layer decoding basic support
> On Mar 2, 2023, at 18:11, Anton Khirnov wrote: > > Quoting zhilizhao(赵志立) (2023-02-28 10:00:15) >> >>> On Jan 6, 2023, at 23:52, Zhao Zhili wrote: >>> >>> From: Zhao Zhili >>> >>> v2: >>> 1. Check vps_max_layers and vps_max_layer_id inside hevc decoder >>> 2. Add hevc_extract_layer bsf to do the job rather than modifing >>> hevc_metadata, >>> 3. Check vps_max_layers_minus1 and vps_max_layer_id inside bsf >>> 4. Update vps_max_layers_minus1 and vps_max_layer_id when rewrite as base >>> layer >>> 5. vps_extension should be updated rather than drop entirely, add a TODO >> >> Will push soon if there's no objections. > > Can't we do this without weird bitstream filtes and obscure options > leaking to the user? It's all signalled in the bitstream in a rather > straightforward way. Just extend hevcdec to decode it. Yes we could. 1. Add support to our software decoder is possible, with a big refactor. 2. Add support to hwaccel decoders like videotoolbox requires a refactor of hevcdec too. I have asked in the RFC: "Is there any plan/interesting to add fullly support inside our hevc decoder? If the answer is yes, then the patchset is less useful." http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305342.html I indeed tried to refactor hevcdec first. But the mixing of long term states and temporary states inside HEVCContext makes it not easy to do. I’m glad to work on it (together) if someone has a clear idea. By the way, other decoders which doesn’t support layered decoding could still benefit from the 'weird bitstream filter'. > > -- > 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 mailing list ffmpeg-devel@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] libavcodec/h264dec: avoid arithmetic on null pointers
On 3/2/2023 6:05 AM, Anton Khirnov wrote:
Quoting Jeremy Dorfman (2023-03-01 19:50:08)
null pointer arithmetic is undefined behavior in C.
---
libavcodec/h264dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 2d691731c5..ef698f2630 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -912,8 +912,8 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
H264Picture *out, int *g
av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill
missing\n", field);
for (p = 0; p<4; p++) {
-dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
-src_data[p] = f->data[p] + field *f->linesize[p];
+dst_data[p] = f->data[p] ? f->data[p] +
(field^1)*f->linesize[p] : NULL;
+src_data[p] = f->data[p] ? f->data[p] + field
*f->linesize[p] : NULL;
Why would that be NULL? Seems like something that should not happen.
None of the supported pixel formats in this decoder use four planes, so
at least the last one will always be NULL. FF_PTR_ADD() is what we did
in similar situations, like in sws_receive_slice(), when we don't use
some helper to get the exact number of used planes from the pixfmt
descriptor.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavcodec/h264dec: avoid arithmetic on null pointers
On 3/2/2023 8:33 AM, James Almer wrote:
On 3/2/2023 6:05 AM, Anton Khirnov wrote:
Quoting Jeremy Dorfman (2023-03-01 19:50:08)
null pointer arithmetic is undefined behavior in C.
---
libavcodec/h264dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 2d691731c5..ef698f2630 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -912,8 +912,8 @@ static int finalize_frame(H264Context *h, AVFrame
*dst, H264Picture *out, int *g
av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to
fill missing\n", field);
for (p = 0; p<4; p++) {
- dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
- src_data[p] = f->data[p] + field *f->linesize[p];
+ dst_data[p] = f->data[p] ? f->data[p] +
(field^1)*f->linesize[p] : NULL;
+ src_data[p] = f->data[p] ? f->data[p] + field
*f->linesize[p] : NULL;
Why would that be NULL? Seems like something that should not happen.
None of the supported pixel formats in this decoder use four planes, so
at least the last one will always be NULL. FF_PTR_ADD() is what we did
in similar situations, like in sws_receive_slice(), when we don't use
some helper to get the exact number of used planes from the pixfmt
descriptor.
http://coverage.ffmpeg.org/index.h264dec.c.8820c603e94612cd02689417231bc605.html#l912
The ubsan fate instance would have detected this long ago if we had a
sample that covers this path.
Do you happen to have one you can make public to be added to the FATE
suite, Jeremy? Or was this problem found using some static analyzer?
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter/graphparser: fix filter instance name when an id is provided
Restores the behavior of naming the instance filter@id, which was accidentally
changed
to simpy id in commit f17051eaae.
Fixes ticket #10226.
Signed-off-by: James Almer
---
libavfilter/graphparser.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
index 8e12416ccb..4347131fad 100644
--- a/libavfilter/graphparser.c
+++ b/libavfilter/graphparser.c
@@ -532,8 +532,7 @@ int
avfilter_graph_segment_create_filters(AVFilterGraphSegment *seg, int flags)
for (size_t j = 0; j < ch->nb_filters; j++) {
AVFilterParams *p = ch->filters[j];
const AVFilter *f = avfilter_get_by_name(p->filter_name);
-char inst_name[30], *name = p->instance_name ? p->instance_name :
- inst_name;
+char name[64];
// skip already processed filters
if (p->filter || !p->filter_name)
@@ -546,7 +545,9 @@ int
avfilter_graph_segment_create_filters(AVFilterGraphSegment *seg, int flags)
}
if (!p->instance_name)
-snprintf(inst_name, sizeof(inst_name), "Parsed_%s_%zu",
f->name, idx);
+snprintf(name, sizeof(name), "Parsed_%s_%zu", f->name, idx);
+else
+snprintf(name, sizeof(name), "%s@%s", f->name,
p->instance_name);
p->filter = avfilter_graph_alloc_filter(seg->graph, f, name);
if (!p->filter)
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavfilter/vf_signalstats.c: add new hsl(Hue, Saturation, Lightness) for filter signalstats v2
From: "yizhuo.liu...@gmail.com"
---
libavfilter/vf_signalstats.c | 219 +-
.../fate/filter-metadata-signalstats-yuv420p | 2 +-
.../filter-metadata-signalstats-yuv420p10 | 2 +-
3 files changed, 220 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index b4d1029296..c6c505ec30 100644
--- a/libavfilter/vf_signalstats.c
+++ b/libavfilter/vf_signalstats.c
@@ -2,6 +2,8 @@
* Copyright (c) 2010 Mark Heath mjpeg0 @ silicontrip dot org
* Copyright (c) 2014 Clément Bœsch
* Copyright (c) 2014 Dave Rice @dericed
+ * Copyright (c) 2022 Wang Wei
+ * Copyright (c) 2022 Liu yizhuo
*
* This file is part of FFmpeg.
*
@@ -18,6 +20,11 @@
* You should have received a copy of the GNU Lesser General Public
* License along with FFmpeg; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+* @file
+ * Add Calculate the HSL color space information.
+ * HSL is a color space that is more perceptually uniform than RGB :
+ * https://en.wikipedia.org/wiki/HSL_and_HSV
*/
#include "libavutil/intreadwrite.h"
@@ -25,6 +32,7 @@
#include "libavutil/pixdesc.h"
#include "filters.h"
#include "internal.h"
+#include "libswscale/swscale.h"
enum FilterMode {
FILTER_NONE = -1,
@@ -36,6 +44,8 @@ enum FilterMode {
typedef struct SignalstatsContext {
const AVClass *class;
+int lumah; // height of luma plane
+int lumaw; // width of luma plane
int chromah;// height of chroma plane
int chromaw;// width of chroma plane
int hsub; // horizontal subsampling
@@ -56,6 +66,11 @@ typedef struct SignalstatsContext {
AVFrame *frame_sat;
AVFrame *frame_hue;
+AVFrame *frame_rgb;
+
+int *hsl_h;
+int *hsl_s;
+int *hsl_l;
} SignalstatsContext;
typedef struct ThreadData {
@@ -65,9 +80,21 @@ typedef struct ThreadData {
typedef struct ThreadDataHueSatMetrics {
const AVFrame *src;
-AVFrame *dst_sat, *dst_hue;
+AVFrame *dst_sat, *dst_hue, *dst_h, *dst_s, *dst_l;
} ThreadDataHueSatMetrics;
+typedef struct ThreadDataHSLMetrics {
+const AVFrame *src;
+int *dst_h, *dst_s, *dst_l;
+} ThreadDataHSLMetrics;
+
+typedef float num;
+
+static const float EPSILON = 1e-9;
+
+/** @brief Equal of A and B */
+#define EQ(A,B)((fabs((A) - (B)) < EPSILON) ? 1 : 0)
+
#define OFFSET(x) offsetof(SignalstatsContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
@@ -110,11 +137,15 @@ static av_cold void uninit(AVFilterContext *ctx)
av_frame_free(&s->frame_prev);
av_frame_free(&s->frame_sat);
av_frame_free(&s->frame_hue);
+av_frame_free(&s->frame_rgb);
av_freep(&s->jobs_rets);
av_freep(&s->histy);
av_freep(&s->histu);
av_freep(&s->histv);
av_freep(&s->histsat);
+av_freep(&s->hsl_h);
+av_freep(&s->hsl_s);
+av_freep(&s->hsl_l);
}
// TODO: add more
@@ -151,6 +182,23 @@ static AVFrame *alloc_frame(enum AVPixelFormat pixfmt, int
w, int h)
return frame;
}
+static int config_input(AVFilterLink *inlink)
+{
+// Video input data avilable
+AVFilterContext *ctx = inlink->dst;
+SignalstatsContext *s = ctx->priv;
+
+// free previous buffers in case they are allocated already
+av_frame_free(&s->frame_rgb);
+s->frame_rgb = alloc_frame(AV_PIX_FMT_RGB24, inlink->w, inlink->h);
+
+if (!s->frame_rgb) {
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
static int config_output(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
@@ -172,12 +220,22 @@ static int config_output(AVFilterLink *outlink)
outlink->w = inlink->w;
outlink->h = inlink->h;
+s->lumaw = inlink->w;
+s->lumah = inlink->h;
+
s->chromaw = AV_CEIL_RSHIFT(inlink->w, s->hsub);
s->chromah = AV_CEIL_RSHIFT(inlink->h, s->vsub);
s->fs = inlink->w * inlink->h;
s->cfs = s->chromaw * s->chromah;
+s->hsl_h = av_malloc_array(s->lumah, sizeof(*s->hsl_h));
+s->hsl_s = av_malloc_array(s->lumah, sizeof(*s->hsl_s));
+s->hsl_l = av_malloc_array(s->lumah, sizeof(*s->hsl_l));
+if (!s->hsl_h || !s->hsl_s || !s->hsl_l) {
+return AVERROR(ENOMEM);
+}
+
s->nb_jobs = FFMAX(1, FFMIN(inlink->h, ff_filter_get_nb_threads(ctx)));
s->jobs_rets = av_malloc_array(s->nb_jobs, sizeof(*s->jobs_rets));
if (!s->jobs_rets)
@@ -455,6 +513,110 @@ static const struct {
{NULL}
};
+static void YUV2RGB(const AVFrame* src, enum AVPixelFormat dstFormat, AVFrame*
dst)
+{
+int width = src->width;
+int height = src->height;
+
+struct SwsContext* conversion = NULL;
+conversion = sws_getContext(width,
+height,
+(enum AVPixelFormat)src->format,
+width,
+height,
+
Re: [FFmpeg-devel] [PATCH] libavcodec/h264dec: avoid arithmetic on null pointers
On Thu, Mar 2, 2023 at 6:37 AM James Almer wrote:
>
> On 3/2/2023 8:33 AM, James Almer wrote:
> > On 3/2/2023 6:05 AM, Anton Khirnov wrote:
> >> Quoting Jeremy Dorfman (2023-03-01 19:50:08)
> >>> null pointer arithmetic is undefined behavior in C.
> >>> ---
> >>> libavcodec/h264dec.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> >>> index 2d691731c5..ef698f2630 100644
> >>> --- a/libavcodec/h264dec.c
> >>> +++ b/libavcodec/h264dec.c
> >>> @@ -912,8 +912,8 @@ static int finalize_frame(H264Context *h, AVFrame
> >>> *dst, H264Picture *out, int *g
> >>> av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to
> >>> fill missing\n", field);
> >>> for (p = 0; p<4; p++) {
> >>> -dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
> >>> -src_data[p] = f->data[p] + field *f->linesize[p];
> >>> +dst_data[p] = f->data[p] ? f->data[p] +
> >>> (field^1)*f->linesize[p] : NULL;
> >>> +src_data[p] = f->data[p] ? f->data[p] + field
> >>> *f->linesize[p] : NULL;
> >>
> >> Why would that be NULL? Seems like something that should not happen.
> >
> > None of the supported pixel formats in this decoder use four planes, so
> > at least the last one will always be NULL. FF_PTR_ADD() is what we did
> > in similar situations, like in sws_receive_slice(), when we don't use
> > some helper to get the exact number of used planes from the pixfmt
> > descriptor.
>
> http://coverage.ffmpeg.org/index.h264dec.c.8820c603e94612cd02689417231bc605.html#l912
>
> The ubsan fate instance would have detected this long ago if we had a
> sample that covers this path.
> Do you happen to have one you can make public to be added to the FATE
> suite, Jeremy? Or was this problem found using some static analyzer?
This was found with a particular conformance stream and ffmpeg built
with -fsanitize=undefined. I'm afraid I can't share the conformance
stream. I've spent the last couple of hours trying to create a stream
that triggers the branch in finalize_frame and have not succeeded in
doing so. I suspect doing so may prove fragile as well; the
conformance stream decodes without issue with JM 19.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] lavu/vulkan: fix handle type for 32-bit targets
Fixes compilation with clang which errors out on Wint-conversion.
Signed-off-by: Kacper Michajłow
---
libavutil/hwcontext_vulkan.c | 2 +-
libavutil/vulkan.h | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 2a9b5f4aac..b3eccea7af 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -1149,7 +1149,7 @@ static void free_exec_ctx(AVHWFramesContext *hwfc,
VulkanExecCtx *cmd)
av_freep(&cmd->queues);
av_freep(&cmd->bufs);
-cmd->pool = NULL;
+cmd->pool = VK_NULL_HANDLE;
}
static VkCommandBuffer get_buf_exec_ctx(AVHWFramesContext *hwfc, VulkanExecCtx
*cmd)
diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h
index d1ea1e24fb..90922c6cf3 100644
--- a/libavutil/vulkan.h
+++ b/libavutil/vulkan.h
@@ -122,7 +122,11 @@ typedef struct FFVulkanPipeline {
VkDescriptorSetLayout *desc_layout;
VkDescriptorPool desc_pool;
VkDescriptorSet *desc_set;
+#if VK_USE_64_BIT_PTR_DEFINES == 1
void **desc_staging;
+#else
+uint64_t *desc_staging;
+#endif
VkDescriptorSetLayoutBinding **desc_binding;
VkDescriptorUpdateTemplate*desc_template;
int *desc_set_initialized;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/filters: update SITI description
Am 01.03.23 um 08:46 schrieb Werner Robitza:
On Wed, Mar 1, 2023 at 1:15 AM Thilo Borgmann wrote:
Am 28.02.23 um 18:12 schrieb Werner Robitza:
On Tue, Feb 28, 2023 at 2:16 PM Thilo Borgmann wrote:
Am 28.02.23 um 14:13 schrieb Thilo Borgmann:
Am 28.02.23 um 12:42 schrieb Werner Robitza:
The filter implements the 'legacy' version from a superseded recommendation.
---
doc/filters.texi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 47e92b9269..25574cd55c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex
"[0:v][1:v] signature=nb_inpu
@anchor{siti}
@section siti
-Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as
defined
-in ITU-T P.910: Subjective video quality assessment methods for multimedia
-applications. Available PDF at
@url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
+Calculate Spatial Information (SI) and Temporal Information (TI) scores for a
video,
+as defined in ITU-T Rec. P.910 (11/21): Subjective video quality assessment
methods
+for multimedia applications. Available PDF at
@url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
+Note that this is a legacy implementation that corresponds to a superseded
recommendation.
+Refer to ITU-T Rec. P.910 (07/22) for the latest version.
It accepts the following option:
Ok.
You might want to add the URL of the current spec, though:
https://www.itu.int/rec/T-REC-P.910-202207-I/en
Sure, patch attached.
Looks better but wait - why did you change the implemented version from 09/99
to 11/21 in the first place?
(Does this not even make it more wrong?)
No, as the (legacy) definition of SI/TI is the same, no matter if you
are using the version from '99 or '21. It was only changed in '22.
But it is common practice to refer to the latest versions of ITU-T
recommendations where possible.
(If only to avoid people looking at really outdated versions and then
citing/using something from those.)
Pushed.
-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 2/2] avutil: add HDR10+ dynamic metadata serialization function
On 27/02/2023 12.34, Raphaël Zumer wrote:
Resent due to my mail client incorrectly re-wrapping lines in the version I
sent earlier.
See the previous patch for context.
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 147 +++
libavutil/hdr_dynamic_metadata.h | 10 +++
libavutil/version.h | 2 +-
3 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 98f399b032..72d310e633 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,150 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s,
const uint8_t *data,
return 0;
}
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+// Buffer size per CTA-861-H p.253-254:
+size_bits =
+// 56 bits for the header
+58 +
+// 2 bits for num_windows
+2 +
+// 937 bits for window geometry for each window above 1
+FFMAX((s->num_windows - 1), 0) * 937 +
+// 27 bits for targeted_system_display_maximum_luminance
+27 +
+// 1-3855 bits for targeted system display peak luminance information
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0) +
+// 0-442 bits for intra-window pixel distribution information
+s->num_windows * 82;
+for (int w = 0; w < s->num_windows; w++) {
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+}
+// 1-3855 bits for mastering display peak luminance information
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+// 0-537 bits for per-window tonemapping information
+s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag) {
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+}
+// 0-21 bits for per-window color saturation mapping information
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag) {
+size_bits += 6;
+}
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf) {
+return NULL;
+}
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA)
+put_bits(pb, 8, 0xB5);
This patch series mentions that it would be used for AV1, however the AV1
specification is clear that the payload does not contain the country code.
https://aomediacodec.github.io/av1-hdr10plus/#hdr10plus-metadata, Figure 1.
So far all the AV1 HDR10+ conformance samples also respect this.
There would probably be a need to specify which behaviour is wanted.
The SEI for HEVC does keep the country code in the payload, but not AV1.
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num /
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num /
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num /
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num /
s->params[w].window_lower_right_corner_y.den);
+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(pb, 1, s->params[w].overlap_process_option);
+}
+
+put_bits(pb, 27, s->targeted_system_display_maximum_luminance.num *
luminance_den /
+s->targeted_system_display_maximum_luminance.den);
+put_bits(pb, 1, s->targeted_system_display_actual_peak_luminance_flag);
+if (s->targeted_system_display_actual_peak_luminance_
Re: [FFmpeg-devel] [PATCH] libavformat/tcp: add local_addr/local_port for network option
Le keskiviikkona 1. maaliskuuta 2023, 17.44.56 EET jackarain a écrit :
> Signed-off-by: jackarain
> ---
> doc/protocols.texi| 6 +
> libavformat/network.c | 14
> libavformat/network.h | 2 +-
> libavformat/tcp.c | 53 ++-
> 4 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 21ae6181a0..b3fad55591 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1882,6 +1882,12 @@ The list of supported options follows.
> Listen for an incoming connection. 0 disables listen, 1 enables listen in
> single client mode, 2 enables listen in multi-client mode. Default value is
> 0.
>
> +@item local_addr=@var{addr}
> +Local IP address of a network interface used for tcp socket connect.
> +
> +@item local_port=@var{port}
> +Local port used for tcp socket connect.
> +
> @item timeout=@var{microseconds}
> Set raise error timeout, expressed in microseconds.
>
> diff --git a/libavformat/network.c b/libavformat/network.c
> index 21e20b3e9a..de8b14be82 100644
> --- a/libavformat/network.c
> +++ b/libavformat/network.c
> @@ -356,7 +356,7 @@ struct ConnectionAttempt {
> static int start_connect_attempt(struct ConnectionAttempt *attempt,
> struct addrinfo **ptr, int timeout_ms,
> URLContext *h,
> - void (*customize_fd)(void *, int), void
> *customize_ctx) + int (*customize_fd)(void
> *, int), void *customize_ctx) {
> struct addrinfo *ai = *ptr;
> int ret;
> @@ -371,8 +371,14 @@ static int start_connect_attempt(struct
> ConnectionAttempt *attempt,
>
> ff_socket_nonblock(attempt->fd, 1);
>
> -if (customize_fd)
> -customize_fd(customize_ctx, attempt->fd);
> +if (customize_fd) {
> +ret = customize_fd(customize_ctx, attempt->fd);
> +if (ret) {
> +closesocket(attempt->fd);
> +attempt->fd = -1;
> +return ret;
> +}
> +}
>
> while ((ret = connect(attempt->fd, ai->ai_addr, ai->ai_addrlen))) {
> ret = ff_neterrno();
> @@ -402,7 +408,7 @@ static int start_connect_attempt(struct
> ConnectionAttempt *attempt,
>
> int ff_connect_parallel(struct addrinfo *addrs, int timeout_ms_per_address,
> int parallel, URLContext *h, int *fd,
> -void (*customize_fd)(void *, int), void
> *customize_ctx) +int (*customize_fd)(void *, int),
> void *customize_ctx) {
> struct ConnectionAttempt attempts[3];
> struct pollfd pfd[3];
> diff --git a/libavformat/network.h b/libavformat/network.h
> index 71c49a73fb..8a8cbe672e 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -336,6 +336,6 @@ void ff_log_net_error(void *ctx, int level, const char*
> prefix); */
> int ff_connect_parallel(struct addrinfo *addrs, int timeout_ms_per_address,
> int parallel, URLContext *h, int *fd,
> -void (*customize_fd)(void *, int), void
> *customize_ctx); +int (*customize_fd)(void *, int),
> void *customize_ctx);
>
> #endif /* AVFORMAT_NETWORK_H */
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index a11ccbb913..a897174f6c 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -36,6 +36,8 @@ typedef struct TCPContext {
> const AVClass *class;
> int fd;
> int listen;
> +char *local_port;
> +char *local_addr;
> int open_timeout;
> int rw_timeout;
> int listen_timeout;
> @@ -52,6 +54,8 @@ typedef struct TCPContext {
> #define E AV_OPT_FLAG_ENCODING_PARAM
> static const AVOption options[] = {
> { "listen", "Listen for incoming connections",
> OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2,
> .flags = D|E }, +{ "local_port", "Local port",
> OFFSET(local_port), AV_OPT_TYPE_STRING, { .str =
> NULL }, 0, 0, .flags = D|E }, +{ "local_addr", "Local
> address", OFFSET(local_addr),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, .flags = D|E }, {
> "timeout", "set timeout (in microseconds) of socket I/O operations",
> OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E }, { "listen_timeout", "Connection awaiting timeout
> (in milliseconds)", OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1, INT_MAX, .flags = D|E }, { "send_buffer_size", "Socket
> send buffer size (in bytes)",OFFSET(send_buffer_size),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E }, @@
> -70,9 +74,42 @@ static const AVClass tcp_class = {
> .version= LIBAVUTIL_VERSION_INT,
> };
>
> -static void customize_fd(void *ctx, int fd)
> +static int customize_fd(void *ctx, int fd)
> {
> TCPCo
Re: [FFmpeg-devel] [PATCH] libavformat/tcp: add local_addr/local_port for network option
Rémi Denis-Courmont (12023-03-02): > That needs to match the socket protocol family, or bind() will fail. Oh, right! The proper way to work with getaddrinfo is to create the socket afterwards based on its return, but staying within a family is a good second best choice. Thanks for noticing. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/filters: update SITI description
On Thu, Mar 2, 2023 at 7:02 PM Thilo Borgmann wrote:
>
> Am 01.03.23 um 08:46 schrieb Werner Robitza:
> > On Wed, Mar 1, 2023 at 1:15 AM Thilo Borgmann
> > wrote:
> >>
> >> Am 28.02.23 um 18:12 schrieb Werner Robitza:
> >>> On Tue, Feb 28, 2023 at 2:16 PM Thilo Borgmann
> >>> wrote:
>
> Am 28.02.23 um 14:13 schrieb Thilo Borgmann:
> > Am 28.02.23 um 12:42 schrieb Werner Robitza:
> >> The filter implements the 'legacy' version from a superseded
> >> recommendation.
> >> ---
> >> doc/filters.texi | 8 +---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/doc/filters.texi b/doc/filters.texi
> >> index 47e92b9269..25574cd55c 100644
> >> --- a/doc/filters.texi
> >> +++ b/doc/filters.texi
> >> @@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv
> >> -filter_complex "[0:v][1:v] signature=nb_inpu
> >> @anchor{siti}
> >> @section siti
> >> -Calculate Spatial Info (SI) and Temporal Info (TI) scores for a
> >> video, as defined
> >> -in ITU-T P.910: Subjective video quality assessment methods for
> >> multimedia
> >> -applications. Available PDF at
> >> @url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
> >> +Calculate Spatial Information (SI) and Temporal Information (TI)
> >> scores for a video,
> >> +as defined in ITU-T Rec. P.910 (11/21): Subjective video quality
> >> assessment methods
> >> +for multimedia applications. Available PDF at
> >> @url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
> >> +Note that this is a legacy implementation that corresponds to a
> >> superseded recommendation.
> >> +Refer to ITU-T Rec. P.910 (07/22) for the latest version.
> >> It accepts the following option:
> >
> > Ok.
>
> You might want to add the URL of the current spec, though:
> https://www.itu.int/rec/T-REC-P.910-202207-I/en
> >>>
> >>> Sure, patch attached.
> >>
> >> Looks better but wait - why did you change the implemented version from
> >> 09/99 to 11/21 in the first place?
> >> (Does this not even make it more wrong?)
> >
> > No, as the (legacy) definition of SI/TI is the same, no matter if you
> > are using the version from '99 or '21. It was only changed in '22.
> > But it is common practice to refer to the latest versions of ITU-T
> > recommendations where possible.
> > (If only to avoid people looking at really outdated versions and then
> > citing/using something from those.)
>
> Pushed.
Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function
On 3/2/23 13:33, quietvoid wrote: > This patch series mentions that it would be used for AV1, however the AV1 > specification is clear that the payload does not contain the country code. > https://aomediacodec.github.io/av1-hdr10plus/#hdr10plus-metadata, Figure 1. > > So far all the AV1 HDR10+ conformance samples also respect this. > There would probably be a need to specify which behaviour is wanted. > The SEI for HEVC does keep the country code in the payload, but not AV1. As you pointed out, HEVC does include the country code in the payload, so either approach can be seen as reasonable. There are a few reasons why I don't think it makes sense to reproduce the AV1 specification: - it does not make sense to exclude the country code from the payload while including other static headers like the terminal provider codes and the application identifier, so there is no particular advantage or logic that I can see in splitting the payload in that way. - pragmatically, it is much less inconvenient to deal with a 1-byte offset in the payload for AV1 than it is to insert that byte into the payload for HEVC and other applications that expect the country code to be included in the header. For the same reason, I think that an option to include or exclude the country code byte would be more trouble than it's worth. - perhaps most importantly, the payload syntax is standardized in ANSI/CTA-861-H, which does not make any distinction between the header (country code, terminal provider code, etc.) and the remainder of the payload, so the AV1 specification does not conform either to other implementations nor to the standard. Following the most authoritative document is the safest route in my opinion. Raphaël Zumer ___ ffmpeg-devel mailing list ffmpeg-devel@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: add HDR10+ dynamic metadata serialization function
On 3/2/2023 3:33 PM, quietvoid wrote:> On 27/02/2023 12.34, Raphaël
Zumer wrote:
>
>> Resent due to my mail client incorrectly re-wrapping lines in the
>> version I sent earlier.
>> See the previous patch for context.
>>
>> Signed-off-by: Raphaël Zumer
>> ---
>> libavutil/hdr_dynamic_metadata.c | 147 +++
>> libavutil/hdr_dynamic_metadata.h | 10 +++
>> libavutil/version.h | 2 +-
>> 3 files changed, 158 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavutil/hdr_dynamic_metadata.c
>> b/libavutil/hdr_dynamic_metadata.c
>> index 98f399b032..72d310e633 100644
>> --- a/libavutil/hdr_dynamic_metadata.c
>> +++ b/libavutil/hdr_dynamic_metadata.c
>> @@ -225,3 +225,150 @@ int
>> av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s, const uint8_t *data,
>> return 0;
>> }
>> +
>> +AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
>> +{
>> +AVBufferRef *buf;
>> +size_t size_bits, size_bytes;
>> +PutBitContext pbc, *pb = &pbc;
>> +
>> +if (!s)
>> +return NULL;
>> +
>> +// Buffer size per CTA-861-H p.253-254:
>> +size_bits =
>> +// 56 bits for the header
>> +58 +
>> +// 2 bits for num_windows
>> +2 +
>> +// 937 bits for window geometry for each window above 1
>> +FFMAX((s->num_windows - 1), 0) * 937 +
>> +// 27 bits for targeted_system_display_maximum_luminance
>> +27 +
>> +// 1-3855 bits for targeted system display peak luminance
>> information
>> +1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
>> +s->num_rows_targeted_system_display_actual_peak_luminance *
>> +s->num_cols_targeted_system_display_actual_peak_luminance * 4
>> : 0) +
>> +// 0-442 bits for intra-window pixel distribution information
>> +s->num_windows * 82;
>> +for (int w = 0; w < s->num_windows; w++) {
>> +size_bits += s->params[w].num_distribution_maxrgb_percentiles
>> * 24;
>> +}
>> +// 1-3855 bits for mastering display peak luminance information
>> +size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag
>> ? 10 +
>> +s->num_rows_mastering_display_actual_peak_luminance *
>> +s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
>> +// 0-537 bits for per-window tonemapping information
>> +s->num_windows * 1;
>> +for (int w = 0; w < s->num_windows; w++) {
>> +if (s->params[w].tone_mapping_flag) {
>> +size_bits += 28 + s->params[w].num_bezier_curve_anchors *
>> 10;
>> +}
>> +}
>> +// 0-21 bits for per-window color saturation mapping information
>> +size_bits += s->num_windows * 1;
>> +for (int w = 0; w < s->num_windows; w++) {
>> +if (s->params[w].color_saturation_mapping_flag) {
>> +size_bits += 6;
>> +}
>> +}
>> +
>> +size_bytes = (size_bits + 7) / 8;
>> +
>> +buf = av_buffer_alloc(size_bytes);
>> +if (!buf) {
>> +return NULL;
>> +}
>> +
>> +init_put_bits(pb, buf->data, size_bytes);
>> +
>> +// itu_t_t35_country_code shall be 0xB5 (USA)
>> +put_bits(pb, 8, 0xB5);
>
> This patch series mentions that it would be used for AV1, however the AV1
> specification is clear that the payload does not contain the country
code.
> https://aomediacodec.github.io/av1-hdr10plus/#hdr10plus-metadata,
Figure 1.
>
> So far all the AV1 HDR10+ conformance samples also respect this.
> There would probably be a need to specify which behaviour is wanted.
> The SEI for HEVC does keep the country code in the payload, but not AV1.
Are you sure about HEVC? I just checked a sample and trace_headers
reported this:
[trace_headers] Prefix Supplemental Enhancement Information
[trace_headers] 0 forbidden_zero_bit 0 = 0
[trace_headers] 1 nal_unit_type 100111 = 39
[trace_headers] 7 nuh_layer_id00 = 0
[trace_headers] 13 nuh_temporal_id_plus1 001 = 1
[trace_headers] 16 last_payload_type_byte0100 = 4
[trace_headers] 24 last_payload_size_byte0100 = 64
[trace_headers] User Data Registered ITU-T T.35
[trace_headers] 32 itu_t_t35_country_code10110101 = 181
[trace_headers] 40 itu_t_t35_payload_byte[1] = 0
[trace_headers] 48 itu_t_t35_payload_byte[2] 0000 = 60
[trace_headers] 56 itu_t_t35_payload_byte[3] = 0
[trace_headers] 64 itu_t_t35_payload_byte[4] 0001 = 1
[trace_headers] 72 itu_t_t35_payload_byte[5] 0100 = 4
[trace_headers] 80 itu_t_t35_payload_byte[6] 0001 = 1
Which is in line with section 8.3.1 of ITU-T Rec. H.274 as well as
section D.2.6 of ITU-T Rec. H.265.
So i think this function should not set the country code at all as part
of the payload, and start with itu_t_t35_terminal_provider_code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpe
Re: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function
On 3/2/23 13:57, James Almer wrote: > > The SEI for HEVC does keep the country code in the payload, but not AV1. > Are you sure about HEVC? I just checked a sample and trace_headers > reported this: > > [trace_headers] Prefix Supplemental Enhancement Information > [trace_headers] 0 forbidden_zero_bit 0 = 0 > [trace_headers] 1 nal_unit_type 100111 = 39 > [trace_headers] 7 nuh_layer_id00 = 0 > [trace_headers] 13 nuh_temporal_id_plus1 001 = 1 > [trace_headers] 16 last_payload_type_byte0100 = 4 > [trace_headers] 24 last_payload_size_byte0100 = 64 > [trace_headers] User Data Registered ITU-T T.35 > [trace_headers] 32 itu_t_t35_country_code10110101 = 181 > [trace_headers] 40 itu_t_t35_payload_byte[1] = 0 > [trace_headers] 48 itu_t_t35_payload_byte[2] 0000 = 60 > [trace_headers] 56 itu_t_t35_payload_byte[3] = 0 > [trace_headers] 64 itu_t_t35_payload_byte[4] 0001 = 1 > [trace_headers] 72 itu_t_t35_payload_byte[5] 0100 = 4 > [trace_headers] 80 itu_t_t35_payload_byte[6] 0001 = 1 > > Which is in line with section 8.3.1 of ITU-T Rec. H.274 as well as > section D.2.6 of ITU-T Rec. H.265. > > So i think this function should not set the country code at all as part > of the payload, and start with itu_t_t35_terminal_provider_code. OK, I will make that change since both HEVC and AV1 implementations seem to match. Thanks Raphaël Zumer ___ ffmpeg-devel mailing list ffmpeg-devel@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] Question: about "igndts" flag, and how to handle DTS output problems.
I'm having trouble with DTS values in a single dvbsub stream while
receiving LIVE MPEGTS with muxed video, audio, subs, and other data
(like scte35) over multicast UDP. I'm doing transcoding tasks, and then
output that to another MPEGTS stream that feeds other services. This are
the problems I'm facing:
```
(...)
[mpegts @ 0x5591147cf280] Non-monotonous DTS in output stream 0:3;
previous: 5729374, current: 5292077; changing to 5729375. This may
result in incorrect timestamps in the output file.
[mpegts @ 0x5591147cf280] Non-monotonous DTS in output stream 0:3;
previous: 5729375, current: 5293810; changing to 5729376. This may
result in incorrect timestamps in the output file.
[mpegts @ 0x5591147cf280] Non-monotonous DTS in output stream 0:3;
previous: 5729376, current: 5300564; changing to 5729377. This may
result in incorrect timestamps in the output file.
[mpegts @ 0x5591147cf280] Non-monotonous DTS in output stream 0:3;
previous: 5729377, current: 5302255; changing to 5729378. This may
result in incorrect timestamps in the output file.
(...)
```
This has the effect that, later in my work's pipeline, subtitles give
trouble with players.
I would like to avoid this ffmpeg DTS correction ("with the error", if
you prefer that interpretation), and thus I tested lots of options
without success, including the `+igndts` flag. It actually doesn't seem
to do anything. So I went to check what it actually does, and found
this.
```
user@computer:/path/to/ffmpeg/repo$ grep -rn "AVFMT_FLAG_IGNDTS" .
2>/dev/null
./libavformat/options_table.h:48:{"igndts", "ignore dts", 0,
AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_IGNDTS }, INT_MIN, INT_MAX, D,
"fflags"},
./libavformat/avformat.h:1228:#define AVFMT_FLAG_IGNDTS 0x0008
///< Ignore DTS on frames that contain both DTS & PTS
./libavformat/demux.c:963:if ((s->flags & AVFMT_FLAG_IGNDTS) &&
pkt->pts != AV_NOPTS_VALUE)
user@computer:/path/to/ffmpeg/repo$
```
It seems it's only used on demux (input), and not at mux time (output).
So I went to check what's going on with that "Non-monotonous" thing, and
found that `fftools/ffmpeg_mux.c` has a code in line 108 where it checks
for DTS values without any consideration for skipping such check.
With this in mind, I would like to ask a some questions here about my
situation, which I'm unsure if it's worthy of a ticket.
1. Is there a way to ignore this DTS issue at mux time and just output
whatever DTS is on the packet? Sounds like "igndts" would be useful at
output too, by just adding it to that line 108 check. But perhaps there
are other way to achieve it.
2. Do you know of some way I could fix this my own way without this
ffmpeg mux auto-fix? I would do some setpts filter magic if I could, but
as this is a subtitle stream I have no way to use filters on it. And
being live streams is really troublesome to apply fixes: I'm trying
several other tools as proxies right now.
3. I see another code before that 108 line. It involves
`s->oformat->flags & AVFMT_TS_NONSTRICT`. But I'm not sure of how to
toggle AVFMT_TS_NONSTRICT from command line to see its effects. Is it
perhaps "-strict experimental"?
Thanks,
Daniel.
___
ffmpeg-devel mailing list
ffmpeg-devel@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: add HDR10+ dynamic metadata serialization function
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 11 +++
libavutil/version.h | 2 +-
3 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 98f399b032..39a7886a2e 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,149 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s,
const uint8_t *data,
return 0;
}
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+// Buffer size per CTA-861-H p.253-254:
+size_bits =
+// 56 bits for the header, minus 8-bit excluded country code
+48 +
+// 2 bits for num_windows
+2 +
+// 937 bits for window geometry for each window above 1
+FFMAX((s->num_windows - 1), 0) * 937 +
+// 27 bits for targeted_system_display_maximum_luminance
+27 +
+// 1-3855 bits for targeted system display peak luminance information
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0) +
+// 0-442 bits for intra-window pixel distribution information
+s->num_windows * 82;
+for (int w = 0; w < s->num_windows; w++) {
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+}
+// 1-3855 bits for mastering display peak luminance information
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+// 0-537 bits for per-window tonemapping information
+s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag) {
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+}
+// 0-21 bits for per-window color saturation mapping information
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag) {
+size_bits += 6;
+}
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf) {
+return NULL;
+}
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA) (excluded from the payload)
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num /
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num /
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num /
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num /
s->params[w].window_lower_right_corner_y.den);
+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(pb, 1, s->params[w].overlap_process_option);
+}
+
+put_bits(pb, 27, s->targeted_system_display_maximum_luminance.num *
luminance_den /
+s->targeted_system_display_maximum_luminance.den);
+put_bits(pb, 1, s->targeted_system_display_actual_peak_luminance_flag);
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+put_bits(pb, 5,
s->num_rows_targeted_system_display_actual_peak_luminance);
+put_bits(pb, 5,
s->num_cols_targeted_system_display_actual_peak_luminance);
+for (int i = 0; i <
s->num_rows_targeted_system_display_actual_peak_luminance; i++) {
+for (int j = 0; j <
s->num_cols_targeted_system_display_actual_peak_luminance; j++) {
+put_bits(pb, 4,
s->targeted_system_display_actual_peak_luminance[i][j].num * peak_luminance_den
/
+
s->targeted_system_display_actual_peak_luminance[i][j].den);
+
Re: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function
On 3/2/23 14:25, Raphaël Zumer wrote:
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 146 +++
libavutil/hdr_dynamic_metadata.h | 11 +++
libavutil/version.h | 2 +-
3 files changed, 158 insertions(+), 1 deletion(-)
Why not put this in avcodec/dynamic_hdr10_plus.c? You reference
put_bits.h which is in avcodec, so that can possibly be an issue, even
though it is inlined (i.e. it sends the wrong message since avutil is
supposed to not depend on avcodec).
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 98f399b032..39a7886a2e 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,149 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s,
const uint8_t *data,
return 0;
}
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
av_dynamic_hdr_plus_from_t35 returns an int status code and takes a
pointer as an argument, is there any particular reason you didn't mirror
user interface here?
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+// Buffer size per CTA-861-H p.253-254:
+size_bits =
+// 56 bits for the header, minus 8-bit excluded country code
+48 +
+// 2 bits for num_windows
+2 +
+// 937 bits for window geometry for each window above 1
+FFMAX((s->num_windows - 1), 0) * 937 +
+// 27 bits for targeted_system_display_maximum_luminance
+27 +
+// 1-3855 bits for targeted system display peak luminance information
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0) +
+// 0-442 bits for intra-window pixel distribution information
+s->num_windows * 82;
This sequence above is difficult to read due to the inline // comments.
It should be more readable to just have the entire expression be
contiguous with a /* */ multiline block comment above it explaining each
item.
+for (int w = 0; w < s->num_windows; w++) {
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+}
Likewise, another code style issue, don't use {} to enclose a single
line unless it's unavoidable. This occurs in several places in this patch.
+// 1-3855 bits for mastering display peak luminance information
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+// 0-537 bits for per-window tonemapping information
+s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag) {
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+}
+// 0-21 bits for per-window color saturation mapping information
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag) {
+size_bits += 6;
+}
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf) {
+return NULL;
+
If you update this to match the status code, this becomes AVERROR(ENOMEM);
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA) (excluded from the payload)
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num /
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num /
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num /
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num /
s->params[w].window_lower_right_corner_y.den);
+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(p
Re: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata serialization function
On 3/2/2023 8:24 PM, Leo Izen wrote: > Why not put this in avcodec/dynamic_hdr10_plus.c? You reference > put_bits.h which is in avcodec, so that can possibly be an issue, even > though it is inlined (i.e. it sends the wrong message since avutil is > supposed to not depend on avcodec). put_bits is a header-only implementation, isn't it? No dependency is introduced. Putting it in avutil was my suggested, as it is a function which takes side data as input, FWIW. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@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: add HDR10+ dynamic metadata serialization function
On 3/2/23 15:24, Leo Izen wrote:
> On 3/2/23 14:25, Raphaël Zumer wrote:
>> Signed-off-by: Raphaël Zumer
>> ---
>> libavutil/hdr_dynamic_metadata.c | 146 +++
>> libavutil/hdr_dynamic_metadata.h | 11 +++
>> libavutil/version.h | 2 +-
>> 3 files changed, 158 insertions(+), 1 deletion(-)
>>
> Why not put this in avcodec/dynamic_hdr10_plus.c? You reference
> put_bits.h which is in avcodec, so that can possibly be an issue, even
> though it is inlined (i.e. it sends the wrong message since avutil is
> supposed to not depend on avcodec).
I agree it is somewhat awkward to introduce a circular dependency (albeit to
header-only files). On the other hand, I think those functions make more sense
in libavutil than libavcodec, and it improves readability by not splitting
files that are logically connected between libraries. If there is a general
consensus that it is better to keep them in libavcodec, I don't mind reverting
that change, or moving get_bits and put_bits to libavutil if that is doable.
>> diff --git a/libavutil/hdr_dynamic_metadata.c
>> b/libavutil/hdr_dynamic_metadata.c
>> index 98f399b032..39a7886a2e 100644
>> --- a/libavutil/hdr_dynamic_metadata.c
>> +++ b/libavutil/hdr_dynamic_metadata.c
>> @@ -225,3 +225,149 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s,
>> const uint8_t *data,
>>
>> return 0;
>> }
>> +
>> +AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
>> +{
> av_dynamic_hdr_plus_from_t35 returns an int status code and takes a
> pointer as an argument, is there any particular reason you didn't mirror
> user interface here?
Mainly the added complexity of buffer size calculation. I think it would be
doable by adding an additional function such as
av_dynamic_hdr_plus_to_t35_size() that would return the serialized buffer size,
which could be then used by the user to allocate a buffer to be written by
av_dynamic_hdr_plus_to_t35(). But adding an additional function just to make
the function signatures consistent feels contrived to me, and there aren't
several errors that could happen in that function that would need to be
disambiguated by the user.
>> +AVBufferRef *buf;
>> +size_t size_bits, size_bytes;
>> +PutBitContext pbc, *pb = &pbc;
>> +
>> +if (!s)
>> +return NULL;
>> +
>> +// Buffer size per CTA-861-H p.253-254:
>> +size_bits =
>> +// 56 bits for the header, minus 8-bit excluded country code
>> +48 +
>> +// 2 bits for num_windows
>> +2 +
>> +// 937 bits for window geometry for each window above 1
>> +FFMAX((s->num_windows - 1), 0) * 937 +
>> +// 27 bits for targeted_system_display_maximum_luminance
>> +27 +
>> +// 1-3855 bits for targeted system display peak luminance information
>> +1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
>> +s->num_rows_targeted_system_display_actual_peak_luminance *
>> +s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0) +
>> +// 0-442 bits for intra-window pixel distribution information
>> +s->num_windows * 82;
> This sequence above is difficult to read due to the inline // comments.
> It should be more readable to just have the entire expression be
> contiguous with a /* */ multiline block comment above it explaining each
> item.
>> +for (int w = 0; w < s->num_windows; w++) {
>> +size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
>> +}
> Likewise, another code style issue, don't use {} to enclose a single
> line unless it's unavoidable. This occurs in several places in this patch.
OK, will correct.
Thanks
Raphaël Zumer
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/libvpxdec: remove unnecessary init_static_data function
On Tue, Feb 28, 2023 at 1:20 PM James Zern wrote:
>
> On Tue, Feb 28, 2023 at 12:49 PM James Almer wrote:
> >
> > On 2/28/2023 5:40 PM, James Zern wrote:
> > > On Tue, Feb 28, 2023 at 4:07 AM James Almer wrote:
> > >>
> > >> It's used only by the encoder.
> > >>
> > >
> > > It sets AVCodec.pix_fmts, but maybe the values reported aren't used
> > > meaningfully.
> >
> > Indeed, they aren't. AVCodec.pix_fmts is a list of formats an encoder
> > accepts as input. Decoders don't use that array.
> >
>
> lgtm. The documentation for that field maybe could use some
> clarification. A few other decoders look to set this, h263dec being
> one.
>
For what it's worth, prior to this patch -h decoder=libvpx-vp9 would
display the supported formats:
Supported pixel formats: yuv420p yuva420p yuv422p yuv440p yuv444p
yuv420p10le yuv422p10le yuv440p10le yuv444p10le yuv420p12le
yuv422p12le yuv440p12le yuv444p12le gbrp gbrp10le gbrp12le
We used this in libvpx tests as one signal that --enable-vp9-bitdepth
builds were integrated correctly with ffmpeg. libaom has a similar
check. This is easy to update, though. The main point of those tests
is to ensure the build doesn't break.
> > >
> > >> Signed-off-by: James Almer
> > >> ---
> > >> libavcodec/libvpxdec.c | 1 -
> > >> 1 file changed, 1 deletion(-)
> > >>
> > >> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> > >> index 0ae19c3f72..8e6291fe20 100644
> > >> --- a/libavcodec/libvpxdec.c
> > >> +++ b/libavcodec/libvpxdec.c
> > >> @@ -391,6 +391,5 @@ FFCodec ff_libvpx_vp9_decoder = {
> > >> FF_CODEC_DECODE_CB(vpx_decode),
> > >> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> > >> FF_CODEC_CAP_AUTO_THREADS,
> > >> -.init_static_data = ff_vp9_init_static,
> > >> };
> > >> #endif /* CONFIG_LIBVPX_VP9_DECODER */
> > >> --
> > >> 2.39.2
> > >>
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@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".
___
ffmpeg-devel mailing list
ffmpeg-devel@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: add HDR10+ dynamic metadata serialization function
Fixed brace style and moved inline buffer size calculation comments to a single
block at the top.
Signed-off-by: Raphaël Zumer
---
libavutil/hdr_dynamic_metadata.c | 142 +++
libavutil/hdr_dynamic_metadata.h | 11 +++
libavutil/version.h | 2 +-
3 files changed, 154 insertions(+), 1 deletion(-)
diff --git a/libavutil/hdr_dynamic_metadata.c b/libavutil/hdr_dynamic_metadata.c
index 98f399b032..24dd3dab2d 100644
--- a/libavutil/hdr_dynamic_metadata.c
+++ b/libavutil/hdr_dynamic_metadata.c
@@ -225,3 +225,145 @@ int av_dynamic_hdr_plus_from_t35(AVDynamicHDRPlus *s,
const uint8_t *data,
return 0;
}
+
+AVBufferRef *av_dynamic_hdr_plus_to_t35(AVDynamicHDRPlus *s)
+{
+AVBufferRef *buf;
+size_t size_bits, size_bytes;
+PutBitContext pbc, *pb = &pbc;
+
+if (!s)
+return NULL;
+
+/**
+ * Buffer size per CTA-861-H p.253-254:
+ * 48 bits for the header (56 minus excluded 8-bit country code)
+ * 2 bits for num_windows
+ * 937 bits for window geometry, for each window above 1
+ * 27 bits for targeted_system_display_maximum_luminance
+ * 1-3855 bits for targeted system display peak luminance information
+ * 0-442 bits for intra-window pixel distribution information
+ * 1-3855 bits for mastering display peak luminance information
+ * 0-537 bits for per-window tonemapping information
+ * 0-21 bits for per-window color saturation mapping information
+ */
+size_bits = 48 +
+2 +
+FFMAX((s->num_windows - 1), 0) * 937 +
+27 +
+1 + (s->targeted_system_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_targeted_system_display_actual_peak_luminance *
+s->num_cols_targeted_system_display_actual_peak_luminance * 4 : 0)
+
+s->num_windows * 82;
+
+for (int w = 0; w < s->num_windows; w++)
+size_bits += s->params[w].num_distribution_maxrgb_percentiles * 24;
+
+size_bits += 1 + (s->mastering_display_actual_peak_luminance_flag ? 10 +
+s->num_rows_mastering_display_actual_peak_luminance *
+s->num_cols_mastering_display_actual_peak_luminance * 4 : 0) +
+s->num_windows * 1;
+
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].tone_mapping_flag)
+size_bits += 28 + s->params[w].num_bezier_curve_anchors * 10;
+}
+
+size_bits += s->num_windows * 1;
+for (int w = 0; w < s->num_windows; w++) {
+if (s->params[w].color_saturation_mapping_flag)
+size_bits += 6;
+}
+
+size_bytes = (size_bits + 7) / 8;
+
+buf = av_buffer_alloc(size_bytes);
+if (!buf)
+return NULL;
+
+init_put_bits(pb, buf->data, size_bytes);
+
+// itu_t_t35_country_code shall be 0xB5 (USA) (excluded from the payload)
+// itu_t_t35_terminal_provider_code shall be 0x003C
+put_bits(pb, 16, 0x003C);
+// itu_t_t35_terminal_provider_oriented_code is set to ST 2094-40
+put_bits(pb, 16, 0x0001);
+// application_identifier shall be set to 4
+put_bits(pb, 8, 4);
+// application_mode is set to Application Version 1
+put_bits(pb, 8, 1);
+
+// Payload as per CTA-861-H p.253-254
+put_bits(pb, 2, s->num_windows);
+
+for (int w = 1; w < s->num_windows; w++) {
+put_bits(pb, 16, s->params[w].window_upper_left_corner_x.num /
s->params[w].window_upper_left_corner_x.den);
+put_bits(pb, 16, s->params[w].window_upper_left_corner_y.num /
s->params[w].window_upper_left_corner_y.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_x.num /
s->params[w].window_lower_right_corner_x.den);
+put_bits(pb, 16, s->params[w].window_lower_right_corner_y.num /
s->params[w].window_lower_right_corner_y.den);
+put_bits(pb, 16, s->params[w].center_of_ellipse_x);
+put_bits(pb, 16, s->params[w].center_of_ellipse_y);
+put_bits(pb, 8, s->params[w].rotation_angle);
+put_bits(pb, 16, s->params[w].semimajor_axis_internal_ellipse);
+put_bits(pb, 16, s->params[w].semimajor_axis_external_ellipse);
+put_bits(pb, 16, s->params[w].semiminor_axis_external_ellipse);
+put_bits(pb, 1, s->params[w].overlap_process_option);
+}
+
+put_bits(pb, 27, s->targeted_system_display_maximum_luminance.num *
luminance_den /
+s->targeted_system_display_maximum_luminance.den);
+put_bits(pb, 1, s->targeted_system_display_actual_peak_luminance_flag);
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+put_bits(pb, 5,
s->num_rows_targeted_system_display_actual_peak_luminance);
+put_bits(pb, 5,
s->num_cols_targeted_system_display_actual_peak_luminance);
+for (int i = 0; i <
s->num_rows_targeted_system_display_actual_peak_luminance; i++) {
+for (int j = 0; j <
s->num_cols_targeted_system_display_actual_peak_luminance; j++)
+put_bits(pb, 4,
s->targeted_system_display_actual_peak_luminance[i][j].num
[FFmpeg-devel] [PATCH] fftools/ffmpeg: reset pointer, which could be reused by Android and iOS
--- fftools/ffmpeg.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 743bc0c6b6..0ce9531235 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -569,6 +569,13 @@ static void ffmpeg_cleanup(int ret) av_freep(&input_files); av_freep(&output_files); +nb_input_files= 0; +nb_output_files = 0; +nb_filtergraphs = 0; +input_files = NULL; +output_files = NULL; +filtergraphs = NULL; + uninit_opts(); avformat_network_deinit(); -- 2.32.0 (Apple Git-132) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
