Re: [FFmpeg-devel] [PATCH] avfilter/yadif: Fix time base for large denominators
Hello,
On Mon, 24. May 11:52, Tom Boshoven wrote:
> This fixes an issue where the yadif filter could cause the timebase
> denominator to overflow.
>
> Signed-off-by: Tom Boshoven
> ---
> libavfilter/vf_yadif.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
> index a6942a2aa2..b067c5eead 100644
> --- a/libavfilter/vf_yadif.c
> +++ b/libavfilter/vf_yadif.c
> @@ -293,8 +293,7 @@ static int config_output(AVFilterLink *outlink)
> AVFilterContext *ctx = outlink->src;
> YADIFContext *s = ctx->priv;
>
> -outlink->time_base.num = ctx->inputs[0]->time_base.num;
> -outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
> +outlink->time_base = av_mul_q(outlink->time_base, (AVRational){1, 2});
> outlink->w = ctx->inputs[0]->w;
> outlink->h = ctx->inputs[0]->h;
Some fate tests fail on patchwork:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210524155206.47644-1-...@jwplayer.com/
--
Andriy
___
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/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
On Fri, 14 May 2021 21:42:25 +0200
Gustav Grusell wrote:
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp. With this fix, if AVSEEK_FLAG_BACKWARD is
> set, seeking will be to the first keyframe of the segment containing
> the given timestamp. This fixes #6850. ---
> libavformat/hls.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 8fc6924c90..3f1fd2cb70 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2199,10 +2199,15 @@ static int hls_read_packet(AVFormatContext
> *s, AVPacket *pkt)
> tb = get_timebase(pls);
> ts_diff = av_rescale_rnd(pls->pkt->dts,
> AV_TIME_BASE,
> -tb.den, AV_ROUND_DOWN) -
> -pls->seek_timestamp;
> -if (ts_diff >= 0 && (pls->seek_flags &
> AVSEEK_FLAG_ANY ||
> -pls->pkt->flags &
> AV_PKT_FLAG_KEY)) {
> + tb.den, AV_ROUND_DOWN) -
> + pls->seek_timestamp;
only format change, maybe better to revert if you don't mean to do so
:)
> +/* If AVSEEK_FLAG_BACKWARD set and not
> AVSEEK_FLAG_ANY,
> + * we return the first keyframe encountered */
> +if ((pls->seek_flags & AVSEEK_FLAG_BACKWARD &&
> + !(pls->seek_flags & AVSEEK_FLAG_ANY) &&
> + pls->pkt->flags & AV_PKT_FLAG_KEY) ||
> +(ts_diff >= 0 && (pls->seek_flags &
> AVSEEK_FLAG_ANY ||
> + pls->pkt->flags &
> AV_PKT_FLAG_KEY))) { pls->seek_timestamp = AV_NOPTS_VALUE;
> break;
> }
Regards,
Lingjiang Fang
___
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] libavfilter: vf_drawtext filter support draw text with detection bounding boxes in side_data
> -Original Message-
> From: ffmpeg-devel On Behalf Of Guo,
> Yejun
> Sent: 2021年5月20日 11:04
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] libavfilter: vf_drawtext filter
> support draw text with detection bounding boxes in side_data
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Ting
> > Fu
> > Sent: 2021年5月14日 16:47
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 3/3] libavfilter: vf_drawtext filter support
> > draw text with detection bounding boxes in side_data
> >
> > This feature can be used with dnn detection by setting vf_drawtext's option
> > text_source=side_data_detection_bboxes, for example:
> > ./ffmpeg -i face.jpeg -vf
> >
> dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:\
> >
> input=data:output=detection_out:labels=face-detection-adas-0001.label,dra
> > wbox=box_source=
> >
> side_data_detection_bboxes,drawtext=text_source=side_data_detection_bbo
> > xes:fontcolor=green:\
> > fontsize=40, -y face_detect.jpeg
> > Please note, the default fontsize of vf_drawtext is 12, which may be too
> > small to be seen clearly.
> >
> > Signed-off-by: Ting Fu
> > ---
> > doc/filters.texi | 8
> > libavfilter/vf_drawtext.c | 77
> > ---
> > 2 files changed, 79 insertions(+), 6 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index f2ac8c4cc8..d10e6de03d 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -10788,6 +10788,14 @@ parameter @var{text}.
> >
> > If both @var{text} and @var{textfile} are specified, an error is thrown.
> >
> > +@item text_source
> > +Text source should be set as side_data_detection_bboxes if you want to
> use
> > text data in
> > +detection bboxes of side data.
> > +
> > +If text source is set, @var{text} and @var{textfile} will be ignored and
> > still
> > use
> > +text data in detection bboxes of side data. So please do not use this
> > parameter
> > +if you are not sure about the text source.
> > +
> > @item reload
> > If set to 1, the @var{textfile} will be reloaded before each frame.
> > Be sure to update it atomically, or it may be read partially, or even fail.
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index 7ea057b812..382d589e26 100644
> > --- a/libavfilter/vf_drawtext.c
> > +++ b/libavfilter/vf_drawtext.c
> > @@ -55,6 +55,7 @@
> > #include "libavutil/time_internal.h"
> > #include "libavutil/tree.h"
> > #include "libavutil/lfg.h"
> > +#include "libavutil/detection_bbox.h"
> > #include "avfilter.h"
> > #include "drawutils.h"
> > #include "formats.h"
> > @@ -199,6 +200,8 @@ typedef struct DrawTextContext {
> > int tc24hmax; ///< 1 if timecode is wrapped to
> 24
> > hours, 0 otherwise
> > int reload; ///< reload text file for each frame
> > int start_number; ///< starting frame number for
> > n/frame_num var
> > +char *text_source_string; ///< the string to specify text data
> > source
> > +enum AVFrameSideDataType text_source;
> > #if CONFIG_LIBFRIBIDI
> > int text_shaping; ///< 1 to shape the text before
> > drawing it
> > #endif
> > @@ -246,6 +249,7 @@ static const AVOption drawtext_options[]= {
> > { "alpha", "apply alpha while rendering", OFFSET(a_expr),
> > AV_OPT_TYPE_STRING, { .str = "1" }, .flags = FLAGS },
> > {"fix_bounds", "check and fix text coords to avoid clipping",
> > OFFSET(fix_bounds), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> > {"start_number", "start frame number for n/frame_num variable",
> > OFFSET(start_number), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, FLAGS},
> > +{"text_source", "the source of text", OFFSET(text_source_string),
> > AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS },
> >
> > #if CONFIG_LIBFRIBIDI
> > {"text_shaping", "attempt to shape text before drawing",
> > OFFSET(text_shaping), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS},
> > @@ -690,6 +694,16 @@ out:
> > }
> > #endif
> >
> > +static enum AVFrameSideDataType text_source_string_parse(const char
> > *text_source_string)
> > +{
> > +av_assert0(text_source_string);
> > +if (!strcmp(text_source_string, "side_data_detection_bboxes")) {
> > +return AV_FRAME_DATA_DETECTION_BBOXES;
> > +} else {
> > +return AVERROR(EINVAL);
> > +}
> > +}
> > +
> > static av_cold int init(AVFilterContext *ctx)
> > {
> > int err;
> > @@ -731,9 +745,28 @@ static av_cold int init(AVFilterContext *ctx)
> > s->text = av_strdup("");
> > }
> >
> > +if (s->text_source_string) {
> > +s->text_source = text_source_string_parse(s->text_source_string);
> > +if ((int)s->text_source < 0) {
> > +av_log(ctx, AV_LOG_ERROR, "Error text source: %s\n",
> > s->text_source_string);
> > +return AVERROR(EINVAL);
> > +}
> > +
Re: [FFmpeg-devel] [PATCH] Pass the HDR10+ metadata to the packet side data in VP9 encoder
Any more comments or looks good to go?
Thanks,
Mohammad
On Mon, Apr 26, 2021 at 6:54 PM Mohammad Izadi wrote:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to packet side data an stored in the container (mkv) for
> VP9.
>
> This CL is taking HDR10+ from AVFrame side data in libvpxenc and is
> passing it to the AVPacket side data.
> ---
> libavcodec/avpacket.c | 1 +
> libavcodec/decode.c| 1 +
> libavcodec/libvpxenc.c | 88 +-
> libavcodec/packet.h| 8
> 4 files changed, 96 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index b5bac5c5f2..7a3b0a73e3 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -416,6 +416,7 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
> case AV_PKT_DATA_DOVI_CONF: return "DOVI
> configuration record";
> case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST
> 12-1:2014 timecode";
> +case AV_PKT_DATA_DYNAMIC_HDR10_PLUS: return "HDR10+ Dynamic
> Metadata (SMPTE 2094-40)";
> }
> return NULL;
> }
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 0956a6ac6f..bf5fbcca97 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1736,6 +1736,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
> { AV_PKT_DATA_ICC_PROFILE,
> AV_FRAME_DATA_ICC_PROFILE },
> { AV_PKT_DATA_S12M_TIMECODE,
> AV_FRAME_DATA_S12M_TIMECODE },
> +{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
> AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
> };
>
> if (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
> sizeof(*pkt))
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 3f36943c12..2096c08437 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -63,6 +63,12 @@ struct FrameListData {
> struct FrameListData *next;
> };
>
> +typedef struct FrameHDR10PlusList {
> +int64_t pts;
> +AVBufferRef *hdr10_plus;
> +struct FrameHDR10PlusList *next;
> +} FrameHDR10PlusList;
> +
> typedef struct VPxEncoderContext {
> AVClass *class;
> struct vpx_codec_ctx encoder;
> @@ -120,6 +126,8 @@ typedef struct VPxEncoderContext {
> int tune_content;
> int corpus_complexity;
> int tpl_model;
> +int discard_hdr10_plus;
> +struct FrameHDR10PlusList *hdr10_plus_list;
> /**
> * If the driver does not support ROI then warn the first time we
> * encounter a frame with ROI side data.
> @@ -315,6 +323,53 @@ static av_cold void free_frame_list(struct
> FrameListData *list)
> }
> }
>
> +
> +static void add_hdr10_plus(void *list, struct FrameHDR10PlusList *data)
> +{
> +struct FrameHDR10PlusList **p = list;
> +while (*p)
> +p = &(*p)->next;
> +*p = data;
> +data->next = NULL;
> +}
> +
> +static av_cold void free_hdr10_plus(struct FrameHDR10PlusList *p)
> +{
> +av_buffer_unref(>hdr10_plus);
> +av_free(p);
> +}
> +
> +static av_cold void free_hdr10_plus_list(struct FrameHDR10PlusList *list)
> +{
> +struct FrameHDR10PlusList *p = list;
> +while (p) {
> +list = list->next;
> +free_hdr10_plus(p);
> +p = list;
> +}
> +}
> +
> +static int copy_hdr10_plus_to_pkt(void *list, AVPacket *pkt)
> +{
> +struct FrameHDR10PlusList **p = list;
> +struct FrameHDR10PlusList *head = *p;
> +
> +if (head && pkt && head->hdr10_plus && head->pts == pkt->pts) {
> +uint8_t *data;
> +*p = (*p)->next;
> +data = av_packet_new_side_data(pkt,
> AV_PKT_DATA_DYNAMIC_HDR10_PLUS, head->hdr10_plus->size);
> +
> +if (!data) {
> +free_hdr10_plus(head);
> +return AVERROR(ENOMEM);
> +}
> +memcpy(data, head->hdr10_plus->data, head->hdr10_plus->size);
> +free_hdr10_plus(head);
> +
> +}
> +return 0;
> +}
> +
> static av_cold int codecctl_int(AVCodecContext *avctx,
> enum vp8e_enc_control_id id, int val)
> {
> @@ -383,6 +438,7 @@ static av_cold int vpx_free(AVCodecContext *avctx)
> av_freep(>twopass_stats.buf);
> av_freep(>stats_out);
> free_frame_list(ctx->coded_frame_list);
> +free_hdr10_plus_list(ctx->hdr10_plus_list);
> return 0;
> }
>
> @@ -828,6 +884,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
> AVCPBProperties *cpb_props;
> int res;
> vpx_img_fmt_t img_fmt = VPX_IMG_FMT_I420;
> +ctx->discard_hdr10_plus = 1;
> #if CONFIG_LIBVPX_VP9_ENCODER
> vpx_codec_caps_t codec_caps = vpx_codec_get_caps(iface);
> vpx_svc_extra_cfg_t svc_params;
> @@ -850,11 +907,16 @@ static av_cold int
[FFmpeg-devel] [PATCH] avfilter/yadif: Fix time base for large denominators
This fixes an issue where the yadif filter could cause the timebase denominator
to overflow.
Signed-off-by: Tom Boshoven
---
libavfilter/vf_yadif.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index a6942a2aa2..b067c5eead 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -293,8 +293,7 @@ static int config_output(AVFilterLink *outlink)
AVFilterContext *ctx = outlink->src;
YADIFContext *s = ctx->priv;
-outlink->time_base.num = ctx->inputs[0]->time_base.num;
-outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
+outlink->time_base = av_mul_q(outlink->time_base, (AVRational){1, 2});
outlink->w = ctx->inputs[0]->w;
outlink->h = ctx->inputs[0]->h;
--
2.31.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] FSB File Version 5 Support
Am So., 23. Mai 2021 um 15:51 Uhr schrieb Michael Tonks : > The sampel file is available via github here: > https://gist.github.com/miketonks/b9fe5b647407a44c86c65a017927e7d9 I have created ticket #9261, thank you for the sample! Carl Eugen ___ 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] avcodec/error_resilience: cleanup mpeg2 handling
After this, the loop for the mpeg2 case is only executed when needed
Signed-off-by: Michael Niedermayer
---
libavcodec/error_resilience.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index ca2287198b..68bc10ac31 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -917,19 +917,20 @@ void ff_er_frame_end(ERContext *s)
return;
}
linesize = s->cur_pic.f->linesize;
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
-int status = s->error_status_table[mb_x + (s->mb_height - 1) *
s->mb_stride];
-if (status != 0x7F)
-break;
-}
-if ( mb_x == s->mb_width
-&& s->avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO
+if ( s->avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO
&& (FFALIGN(s->avctx->height, 16)&16)
-&& atomic_load(>error_count) == 3 * s->mb_width *
(s->avctx->skip_top + s->avctx->skip_bottom + 1)
-) {
-av_log(s->avctx, AV_LOG_DEBUG, "ignoring last missing slice\n");
-return;
+&& atomic_load(>error_count) == 3 * s->mb_width *
(s->avctx->skip_top + s->avctx->skip_bottom + 1)) {
+for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+int status = s->error_status_table[mb_x + (s->mb_height - 1) *
s->mb_stride];
+if (status != 0x7F)
+break;
+}
+
+if (mb_x == s->mb_width) {
+av_log(s->avctx, AV_LOG_DEBUG, "ignoring last missing slice\n");
+return;
+}
}
if (s->last_pic.f) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcdec: move setting decode_error_flags from h264 decoder to error concealment code
This should fix some minor race condition
Untested (no testcase, the flag is not tested by fate)
Signed-off-by: Michael Niedermayer
---
libavcodec/error_resilience.c | 3 +++
libavcodec/h264dec.c | 5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index 68bc10ac31..e880efcc51 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -907,6 +907,9 @@ void ff_er_frame_end(ERContext *s)
int is_intra_likely;
int size = s->b8_stride * 2 * s->mb_height;
+if (s->error_occurred && s->cur_pic.f)
+s->cur_pic.f->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
+
/* We do not support ER of field pictures yet,
* though it should not crash if enabled. */
if (!s->avctx->error_concealment || !atomic_load(>error_count) ||
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 38f8967265..05e46cb456 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -716,11 +716,6 @@ static int decode_nal_units(H264Context *h, const uint8_t
*buf, int buf_size)
if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
goto end;
-// set decode_error_flags to allow users to detect concealed decoding
errors
-if ((ret < 0 || h->slice_ctx->er.error_occurred) && h->cur_pic_ptr) {
-h->cur_pic_ptr->f->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
-}
-
ret = 0;
end:
--
2.17.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/matroskaenc: Allow changing the time stamp precision via option
michael.di...@xaymar.com:
> From: Michael Fabian 'Xaymar' Dirks
>
> Adds "timestamp_precision" to the available options for Matroska muxing.
> The option enables users and developers to change the precision of the
> time stamps in the Matroska container up to 1 nanosecond, which can aid
> with the proper detection of constant and variable rate content.
>
> Work-around fix for: 259, 6406, 7927, 8909 and 9124.
>
> Signed-off-by: Michael Fabian 'Xaymar' Dirks
> ---
> doc/muxers.texi | 8
> libavformat/matroskaenc.c | 33 ++---
> 2 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index e1c6ad0829..8655be94ff 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1583,6 +1583,14 @@ bitmap is stored bottom-up. Note that this option does
> not flip the bitmap
> which has to be done manually beforehand, e.g. by using the vflip filter.
> Default is @var{false} and indicates bitmap is stored top down.
>
> +@item timestamp_precision
> +Sets the timestamp precision up to 1 nanosecond for Matroska/WebM, which can
> +improve detection of constant rate content in demuxers. Note that some poorly
> +implemented demuxers may require a timestamp precision of 1 millisecond, so
> +increasing it past that point may result in playback issues. Higher precision
> +also reduces the maximum possible timestamp significantly.
This should mention that a too high precision will increase container
overhead.
> +Default is @var{1/1000} (1 millisecond).
> +
> @end table
>
> @anchor{md5}
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 186a25d920..1b911a648c 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -158,6 +158,8 @@ typedef struct MatroskaMuxContext {
> int default_mode;
>
> uint32_tsegment_uid[4];
> +
> +AVRational time_base;
> } MatroskaMuxContext;
>
> /** 2 bytes * 7 for EBML IDs, 7 1-byte EBML lengths, 6 1-byte uint,
> @@ -1814,6 +1816,7 @@ static int mkv_write_header(AVFormatContext *s)
> const AVDictionaryEntry *tag;
> int ret, i, version = 2;
> int64_t creation_time;
> +int64_t time_base = 1;
>
> if (mkv->mode != MODE_WEBM ||
> av_dict_get(s->metadata, "stereo_mode", NULL, 0) ||
> @@ -1850,7 +1853,10 @@ static int mkv_write_header(AVFormatContext *s)
> return ret;
> pb = mkv->info.bc;
>
> -put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, 100);
> +time_base = av_rescale_q(time_base, mkv->time_base, (AVRational){1,
> 10});
> +av_log(s, AV_LOG_DEBUG, "TimestampScale is: %" PRId64 " ns\n",
> time_base);
> +put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, time_base);
There is a serious problem here: mkv->time_base is the time base that
the muxer uses; yet if mkv->time_base is not a multiple of 1/10,
then av_rescale_q will have to round a bit and then the demuxer will
read a different time base, leading to a drift of all timestamps. This
is not acceptable.
> +
> if ((tag = av_dict_get(s->metadata, "title", NULL, 0)))
> put_ebml_string(pb, MATROSKA_ID_TITLE, tag->value);
> if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
> @@ -1883,11 +1889,11 @@ static int mkv_write_header(AVFormatContext *s)
> int64_t metadata_duration = get_metadata_duration(s);
>
> if (s->duration > 0) {
> -int64_t scaledDuration = av_rescale(s->duration, 1000,
> AV_TIME_BASE);
> +int64_t scaledDuration = av_rescale_q(s->duration,
> AV_TIME_BASE_Q, mkv->time_base);
> put_ebml_float(pb, MATROSKA_ID_DURATION, scaledDuration);
> av_log(s, AV_LOG_DEBUG, "Write early duration from recording
> time = %" PRIu64 "\n", scaledDuration);
> } else if (metadata_duration > 0) {
> -int64_t scaledDuration = av_rescale(metadata_duration, 1000,
> AV_TIME_BASE);
> +int64_t scaledDuration = av_rescale_q(metadata_duration,
> AV_TIME_BASE_Q, mkv->time_base);
> put_ebml_float(pb, MATROSKA_ID_DURATION, scaledDuration);
> av_log(s, AV_LOG_DEBUG, "Write early duration from metadata = %"
> PRIu64 "\n", scaledDuration);
> } else if (s->pb->seekable & AVIO_SEEKABLE_NORMAL) {
> @@ -1948,12 +1954,12 @@ static int mkv_write_header(AVFormatContext *s)
> // after 4k and on a keyframe
> if (IS_SEEKABLE(pb, mkv)) {
> if (mkv->cluster_time_limit < 0)
> -mkv->cluster_time_limit = 5000;
> +mkv->cluster_time_limit = av_rescale_q(5000, (AVRational){1,
> 1000}, mkv->time_base);
> if (mkv->cluster_size_limit < 0)
> mkv->cluster_size_limit = 5 * 1024 * 1024;
> } else {
> if (mkv->cluster_time_limit < 0)
> -mkv->cluster_time_limit = 1000;
> +mkv->cluster_time_limit = av_rescale_q(1000, (AVRational){1,
> 1000}, mkv->time_base);
There
Re: [FFmpeg-devel] [PATCH] set AVFrame decode_error_flags in case of decoding error by h264dec
On 7/7/2019 5:15 PM, Michael Niedermayer wrote:
On Fri, Jun 21, 2019 at 07:15:17AM -0700, Amir Pauker wrote:
set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred is set
after the call to ff_h264_execute_decode_slices. This allows the user to detect
concealed decoding errors in the call to avcodec_receive_frame
Signed-off-by: Amir Pauker
---
libavcodec/error_resilience.c | 2 ++
libavcodec/h264dec.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index 35d0c60..ca22871 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -1121,6 +1121,8 @@ void ff_er_frame_end(ERContext *s)
av_log(s->avctx, AV_LOG_INFO, "concealing %d DC, %d AC, %d MV errors in %c
frame\n",
dc_error, ac_error, mv_error,
av_get_picture_type_char(s->cur_pic.f->pict_type));
+s->cur_pic.f->decode_error_flags |= FF_DECODE_ERROR_CONCEALMENT_ACTIVE;
+
is_intra_likely = is_intra_more_likely(s);
/* set unknown mb-type to most likely */
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 837c3b7..8d1bd16 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -761,6 +761,11 @@ static int decode_nal_units(H264Context *h, const uint8_t
*buf, int buf_size)
if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
goto end;
+// set decode_error_flags to allow users to detect concealed decoding errors
+if ((ret < 0 || h->slice_ctx->er.error_occurred) && h->cur_pic_ptr) {
+h->cur_pic_ptr->f->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
+}
+
ret = 0;
end:
will split and apply
thx
This change seems to have produced FATE failures when run under tsan.
http://fate.ffmpeg.org/report.cgi?time=20210524021410=x86_64-archlinux-gcc-tsan
That being said, TSAN runs show a lot of issues that have remained
unresolved for a long while. No idea if they are false positives, or if
they are benign and rarely (if at all) have any effect on real world
usage (Like this one, apparently), but what i can say is that they are
masking new and potentially bad threading bugs that nobody will notice
in a timely manner.
___
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: add Intel IPP library based x86 optimized video scaling filter
On Mon, May 24, 2021 at 04:27:48PM +0200, Nicolas George wrote: > Lynne (12021-05-24): > > I'd rather not support an external non-free library that does > > the same as libavfilter only faster on one single platform > > but rather see libavfilter's assembly and code improved. > > I second that. +1 [...] -- 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] web/contact: Add libera.chat
On Sun, May 23, 2021 at 04:11:22PM +0200, Tomas Härdin wrote: > fre 2021-05-21 klockan 21:42 +0200 skrev Michael Niedermayer: > > See the internets about the whole freenode vs. libera drama > > > > This is a bit a RFC, i would assume that we will move forward with only > > one set of official IRC channels. > > But maybe its too early to ask for RFC, iam not sure how much everyone > > knows about this, and knowledge must come before making comments and > > decissions > > Perhaps we should wait a month or two for the dust to settle. > I presume > both channels have already been registered on libera.chat. I'm fine > with either network. The channels on libera are registered The channels on freenode where registered previously One question that i think we should ask is what "buisness model" these 2 have. One seems to be a simple volunteer based "not for profit" the other is said to be bought by some rich person. Does anyone know what the buisness model behind that is ? Normally when someone buys / invests in something he expects something more valuable in return. Is this some sort of "free" funded by advertisement model or if not then how does it work? does anyone know ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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] mxfdec.c: Try TC from Footer if Header TC was < 1
Am 2021-05-24 17:31, schrieb Tomas Härdin:
mån 2021-05-24 klockan 12:30 +0200 skrev emcodem:
Added support for reading Start Timecode from Footer (if any).
Specifically targets Omneon 6.4.3.0 but also works on other Versions
and Vendors, e.g. when Header is OpenIncomplete.
Function mxf_resolve_strong_ref_reverse can potentially be re-used for
getting other values like Duration and
Origin from Footer.
This needs a sample and a test
Sure, Will add.
---
libavformat/mxfdec.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..557e01f8ed 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1396,6 +1396,19 @@ static const MXFCodecUL *mxf_get_codec_ul(const
MXFCodecUL *uls, UID *uid)
return uls;
}
+static void *mxf_resolve_strong_ref_reverse(MXFContext *mxf, UID
*strong_ref, enum MXFMetadataSetType type)
This and mxf_resolve_strong_ref() could maybe be merged to one function
with an "int dir" option, and mxf_resolve_strong_ref() just calling it
with the value 1.
Will delete the revers function and alter the mxf_resolve_strong_ref as
suggested.
+{
+int i;
+if (!strong_ref)
+return NULL;
+for (i = mxf->metadata_sets_count-1; i >= 0 ; i--) {
+if (!memcmp(*strong_ref, mxf->metadata_sets[i]->uid, 16) &&
+(type == AnyType || mxf->metadata_sets[i]->type == type))
{
+return mxf->metadata_sets[i];
+}
+}
+return NULL;
+}
Missing newline, but I can add that locally
static void *mxf_resolve_strong_ref(MXFContext *mxf, UID *strong_ref,
enum MXFMetadataSetType type)
{
int i;
@@ -2328,8 +2341,15 @@ static int
mxf_parse_structural_metadata(MXFContext *mxf)
continue;
mxf_tc = (MXFTimecodeComponent*)component;
+if (mxf_tc->start_frame <= 0) {
I feel like this should trigger on OpenIncomplete instead. I wouldn't
be surprised if start_frame < 0 is perfectly valid.
OK thats an interesting discussion, from my perspective there is a
little gray area here and what i did should deliver the best effort. My
thoughts are:
*) openincomplete may or may not carry the correct value, it is not
guaranteed to carry the wrong value
*) there may not be a footer (file truncated, file growing)
*) if a footer is there, it may or may not repeat the header metadata
*) all 377m versions say "if values are unknonwn (open/incomplete), one
must use the "distinguished value", but none of the 377m up to 2011
define such a value for the start timecode - BUT my guess was that this
distinguished value shall be a valid TC, instead of e.g. "-1" (...)
because the value -1 would potentially fail in the TC parsing code
(thinking globally here, not only for libav*)
*) if the Start TC is actually 0 AND there is a Footer Metadata
repetition, my code still works because it will take the value 0 from
the footer
So after all i believe checking for "openincomplete" would be kind of
superfluous for this usecase. Checking if there is another value than 0
in the footer does not really hurt and as the footer is guaranteed to
carry the correct timecode, it should never return a really wrong value.
The really correct solution i believe would be to parse ALL metadata
from footer (if any) first but i don't want to change the mxfdec.c
fundamentally just for this sidecase.
+if (mxf_tc->start_frame <= 0) {
+av_log(mxf->fc, AV_LOG_TRACE, "Header Start
Timecode was %d, trying reversed parsing\n",mxf_tc->start_frame);
+component = mxf_resolve_strong_ref_reverse(mxf,
_track->sequence->structural_components_refs[j],
TimecodeComponent);
+mxf_tc = (MXFTimecodeComponent*)component;
Wrong indent. I was also going to comment that mxf_tc might end up NULL
here but it can't since it's non-NULL when resolving in the forward
direction.
Yeah, in worst case the reverse parsing should return exactly the same
value as the forward parsing did, so i guess we are safe here. My
intention was to be backward compatible as far as possible.
/Tomas
Hi Tomas, thanks for the quick reply.
OK i'll try to get hold of a short example file, upload to the fate
suite and add a test. If i cannot get a very short sample (XDCAM, ~1-2
GOP's), i'll make some up by altering values using hex editor if thats
ok for you.
Other comments inline, please let me know your thougts - AND as i am
pretty new to sending patches here, please also let me know if you like
me to send ONE patch with the new code for mxfdec.c AND the test or you
want me to send it separately?
Thanks,
-emcodem
___
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] mxfdec.c: Try TC from Footer if Header TC was < 1
mån 2021-05-24 klockan 12:30 +0200 skrev emcodem:
> Added support for reading Start Timecode from Footer (if any).
> Specifically targets Omneon 6.4.3.0 but also works on other Versions and
> Vendors, e.g. when Header is OpenIncomplete.
> Function mxf_resolve_strong_ref_reverse can potentially be re-used for
> getting other values like Duration and
> Origin from Footer.
This needs a sample and a test
> ---
> libavformat/mxfdec.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 3bf480a3a6..557e01f8ed 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1396,6 +1396,19 @@ static const MXFCodecUL *mxf_get_codec_ul(const
> MXFCodecUL *uls, UID *uid)
> return uls;
> }
>
> +static void *mxf_resolve_strong_ref_reverse(MXFContext *mxf, UID
> *strong_ref, enum MXFMetadataSetType type)
This and mxf_resolve_strong_ref() could maybe be merged to one function
with an "int dir" option, and mxf_resolve_strong_ref() just calling it
with the value 1.
> +{
> +int i;
> +if (!strong_ref)
> +return NULL;
> +for (i = mxf->metadata_sets_count-1; i >= 0 ; i--) {
> +if (!memcmp(*strong_ref, mxf->metadata_sets[i]->uid, 16) &&
> +(type == AnyType || mxf->metadata_sets[i]->type == type)) {
> +return mxf->metadata_sets[i];
> +}
> +}
> +return NULL;
> +}
Missing newline, but I can add that locally
> static void *mxf_resolve_strong_ref(MXFContext *mxf, UID *strong_ref, enum
> MXFMetadataSetType type)
> {
> int i;
> @@ -2328,8 +2341,15 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
> continue;
>
> mxf_tc = (MXFTimecodeComponent*)component;
> +if (mxf_tc->start_frame <= 0) {
I feel like this should trigger on OpenIncomplete instead. I wouldn't
be surprised if start_frame < 0 is perfectly valid.
> +if (mxf_tc->start_frame <= 0) {
> +av_log(mxf->fc, AV_LOG_TRACE, "Header Start Timecode was
> %d, trying reversed parsing\n",mxf_tc->start_frame);
> +component = mxf_resolve_strong_ref_reverse(mxf,
> _track->sequence->structural_components_refs[j], TimecodeComponent);
> +mxf_tc = (MXFTimecodeComponent*)component;
Wrong indent. I was also going to comment that mxf_tc might end up NULL
here but it can't since it's non-NULL when resolving in the forward
direction.
/Tomas
___
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] avisynth.c corrected interlace detection
Sorry for the delay on this, should have corrected it much earlier.
There was some confusion in the interlaced analysis. From 3rdparty decoders
perspective, a clip
can only be interlaced when it is NOT field_based. This is because in a
field_based clip, the fields
are separate images, so it is actually progressive. In that case, avisynth
still shows is_tff or bff because those
values are needed in case the script decides to weave the separated fields
later on.
---
libavformat/avisynth.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 350ac6d11d..ff6e6e1bfa 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -250,15 +250,12 @@ static int avisynth_create_stream_video(AVFormatContext
*s, AVStream *st)
st->nb_frames = avs->vi->num_frames;
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator,
avs->vi->fps_numerator);
-av_log(s, AV_LOG_TRACE, "avs_is_field_based: %d\n",
avs_is_field_based(avs->vi));
-av_log(s, AV_LOG_TRACE, "avs_is_parity_known: %d\n",
avs_is_parity_known(avs->vi));
-/* The following typically only works when assumetff (-bff) and
- * assumefieldbased is used in-script. Additional
- * logic using GetParity() could deliver more accurate results
- * but also decodes a frame which we want to avoid. */
st->codecpar->field_order = AV_FIELD_UNKNOWN;
-if (avs_is_field_based(avs->vi)) {
+/* separatefields makes field_based==true, weave makes field_based==false
+ * only non field_based clips can therefore be interlaced */
+av_log(s, AV_LOG_TRACE, "avs_is_field_based: %d\n",
avs_is_field_based(avs->vi));
+if (avs_is_field_based(avs->vi) == 0) {
if (avs_is_tff(avs->vi)) {
st->codecpar->field_order = AV_FIELD_TT;
}
--
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]avfilter: add Intel IPP library based x86 optimized video scaling filter
Lynne (12021-05-24): > I'd rather not support an external non-free library that does > the same as libavfilter only faster on one single platform > but rather see libavfilter's assembly and code improved. I second that. 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]avfilter: add Intel IPP library based x86 optimized video scaling filter
May 24, 2021, 14:21 by kier...@obe.tv: > On Sun, 23 May 2021 at 13:31, Zhislina, Victoria < > victoria.zhisl...@intel.com> wrote: > >> From b01b4130d7301a289b3ad771eaeaf1ca2839045a Mon Sep 17 00:00:00 2001 >> From: Zhislina >> Date: Mon, 3 May 2021 21:53:54 +0300 >> Subject: [PATCH] avfilter: add Intel IPP library based x86 optimized video >> scaling filter. >> >> Uses vector instructions from SSE2 (default) up to AVX512 for the suitable >> CPUs >> and multithreading (slices) to provide multiple performance increase vs >> libswscale. >> > > As I understand it, IPP is not open source so this will need > --enable-nonfree > I'd rather not support an external non-free library that does the same as libavfilter only faster on one single platform but rather see libavfilter's assembly and code improved. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3 v2] avcodec/utils: don't use ff_fast_mallocz in av_fast_padded_malloc()
It will be removed in the next commit. Signed-off-by: James Almer --- libavcodec/utils.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index c08f9a7da3..cc6796d8b6 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -29,7 +29,7 @@ #include "libavutil/avassert.h" #include "libavutil/avstring.h" #include "libavutil/intreadwrite.h" -#include "libavutil/mem_internal.h" +#include "libavutil/mem.h" #include "libavutil/pixdesc.h" #include "libavutil/imgutils.h" #include "libavutil/pixfmt.h" @@ -55,7 +55,8 @@ void av_fast_padded_malloc(void *ptr, unsigned int *size, size_t min_size) *size = 0; return; } -if (!ff_fast_malloc(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE, 1)) +av_fast_mallocz(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE); +if (*p) memset(*p + min_size, 0, AV_INPUT_BUFFER_PADDING_SIZE); } @@ -67,7 +68,8 @@ void av_fast_padded_mallocz(void *ptr, unsigned int *size, size_t min_size) *size = 0; return; } -if (!ff_fast_malloc(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE, 1)) +av_fast_malloc(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE); +if (*p) memset(*p, 0, min_size + AV_INPUT_BUFFER_PADDING_SIZE); } -- 2.31.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]avfilter: add Intel IPP library based x86 optimized video scaling filter
On Sun, 23 May 2021 at 13:31, Zhislina, Victoria < victoria.zhisl...@intel.com> wrote: > From b01b4130d7301a289b3ad771eaeaf1ca2839045a Mon Sep 17 00:00:00 2001 > From: Zhislina > Date: Mon, 3 May 2021 21:53:54 +0300 > Subject: [PATCH] avfilter: add Intel IPP library based x86 optimized video > scaling filter. > > Uses vector instructions from SSE2 (default) up to AVX512 for the suitable > CPUs > and multithreading (slices) to provide multiple performance increase vs > libswscale. > As I understand it, IPP is not open source so this will need --enable-nonfree Kieran ___ 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] lavf/dashenc.c: Fix creating audio-only HLS playlists
Hello all,
I wanted to follow Carl's advice (
https://trac.ffmpeg.org/ticket/9252#comment:4) and prepared a patch with
hidden indentation changes, via git format-patch --ignore-space-change
origin/master (see my previous message) but that patch does not apply then.
So once again I'm sending the whole patch that applies correctly, as an
attachment.
Really, contributing to FFmpeg should be made easier (e.g. reviewing
indentation changes is easy when sent as GitHub merge request)
--
Best regards.
Przemysław Sobala
On Fri, 21 May 2021 at 13:46, Przemysław Sobala
wrote:
> With audio/video HLS playlists, audio chunklists are treated as
> alternative renditions for video chunklists. This is wrong for
> audio-only HLS playlists.
>
> fixes: 9252
>
> Please correct indentation of introduced if statement's body, before
> applying.
> ---
> libavformat/dashenc.c | 39 +++
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 07f191e2a2..c5da02840b 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1256,10 +1256,6 @@ static int write_manifest(AVFormatContext *s, int
> final)
>
> if (c->hls_playlist) {
> char filename_hls[1024];
> -const char *audio_group = "A1";
> -char audio_codec_str[128] = "\0";
> -int is_default = 1;
> -int max_audio_bitrate = 0;
>
> // Publish master playlist only the configured rate
> if (c->master_playlist_created && (!c->master_publish_rate ||
> @@ -1282,6 +1278,13 @@ static int write_manifest(AVFormatContext *s, int
> final)
>
> ff_hls_write_playlist_version(c->m3u8_out, 7);
>
> +if (c->has_video) {
> +// treat audio streams as alternative renditions for video
> streams
> +const char *audio_group = "A1";
> +char audio_codec_str[128] = "\0";
> +int is_default = 1;
> +int max_audio_bitrate = 0;
> +
> for (i = 0; i < s->nb_streams; i++) {
> char playlist_file[64];
> AVStream *st = s->streams[i];
> @@ -1336,6 +1339,34 @@ static int write_manifest(AVFormatContext *s, int
> final)
> playlist_file, agroup,
> codec_str_ptr, NULL, NULL);
> }
> +
> +} else {
> +// treat audio streams as separate renditions
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +char playlist_file[64];
> +char codec_str[128];
> +AVStream *st = s->streams[i];
> +OutputStream *os = >streams[i];
> +int stream_bitrate = os->muxer_overhead;
> +if (os->bit_rate > 0)
> +stream_bitrate += os->bit_rate;
> +else if (final)
> +stream_bitrate += os->pos * 8 * AV_TIME_BASE /
> c->total_duration;
> +else if (os->first_segment_bit_rate > 0)
> +stream_bitrate += os->first_segment_bit_rate;
> +if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
> +continue;
> +if (os->segment_type != SEGMENT_TYPE_MP4)
> +continue;
> +av_strlcpy(codec_str, os->codec_str, sizeof(codec_str));
> +get_hls_playlist_name(playlist_file,
> sizeof(playlist_file), NULL, i);
> +ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
> +playlist_file, NULL,
> +codec_str, NULL, NULL);
> +}
> +}
> +
> dashenc_io_close(s, >m3u8_out, temp_filename);
> if (use_rename)
> if ((ret = ff_rename(temp_filename, filename_hls, s)) < 0)
> --
> 2.31.1
>
>
From 00e71833cef4b8e0052b8bd7dcb83758385cfd31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Przemys=C5=82aw=20Sobala?=
Date: Thu, 20 May 2021 11:50:27 +0200
Subject: [PATCH] lavf/dashenc.c: Fix creating audio-only HLS playlists
With audio/video HLS playlists, audio chunklists are treated as
alternative renditions for video chunklists. This is wrong for
audio-only HLS playlists.
fixes: 9252
---
libavformat/dashenc.c | 137 ++
1 file changed, 84 insertions(+), 53 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 07f191e2a2..c5da02840b 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1256,10 +1256,6 @@ static int write_manifest(AVFormatContext *s, int final)
if (c->hls_playlist) {
char filename_hls[1024];
-const char *audio_group = "A1";
-char audio_codec_str[128] = "\0";
-int is_default = 1;
-int max_audio_bitrate = 0;
// Publish master playlist only the configured rate
if (c->master_playlist_created &&
Re: [FFmpeg-devel] [PATCH] avformat/hls Implement support for using AVSEEK_FLAG_BACKWARD when seeking
Den fre 14 maj 2021 21:42Gustav Grusell skrev:
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp.
> With this fix, if AVSEEK_FLAG_BACKWARD is set, seeking will be to the
> first keyframe of the
> segment containing the given timestamp. This fixes #6850.
> ---
> libavformat/hls.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 8fc6924c90..3f1fd2cb70 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2199,10 +2199,15 @@ static int hls_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> tb = get_timebase(pls);
> ts_diff = av_rescale_rnd(pls->pkt->dts, AV_TIME_BASE,
> -tb.den, AV_ROUND_DOWN) -
> -pls->seek_timestamp;
> -if (ts_diff >= 0 && (pls->seek_flags &
> AVSEEK_FLAG_ANY ||
> -pls->pkt->flags &
> AV_PKT_FLAG_KEY)) {
> + tb.den, AV_ROUND_DOWN) -
> + pls->seek_timestamp;
> +/* If AVSEEK_FLAG_BACKWARD set and not
> AVSEEK_FLAG_ANY,
> + * we return the first keyframe encountered */
> +if ((pls->seek_flags & AVSEEK_FLAG_BACKWARD &&
> + !(pls->seek_flags & AVSEEK_FLAG_ANY) &&
> + pls->pkt->flags & AV_PKT_FLAG_KEY) ||
> +(ts_diff >= 0 && (pls->seek_flags &
> AVSEEK_FLAG_ANY ||
> + pls->pkt->flags &
> AV_PKT_FLAG_KEY))) {
> pls->seek_timestamp = AV_NOPTS_VALUE;
> break;
> }
>
Did anyone find time to look at this? Any comments?
Cheers,
Gustav
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/utils: don't use ff_fast_mallocz in av_fast_padded_malloc()
James Almer:
> It will be removed in the next commit.
>
> Signed-off-by: James Almer
> ---
> libavcodec/utils.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index c08f9a7da3..5394a179b0 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -29,7 +29,7 @@
> #include "libavutil/avassert.h"
> #include "libavutil/avstring.h"
> #include "libavutil/intreadwrite.h"
> -#include "libavutil/mem_internal.h"
> +#include "libavutil/mem.h"
> #include "libavutil/pixdesc.h"
> #include "libavutil/imgutils.h"
> #include "libavutil/pixfmt.h"
> @@ -49,25 +49,31 @@
>
> void av_fast_padded_malloc(void *ptr, unsigned int *size, size_t min_size)
> {
> -uint8_t **p = ptr;
> +uint8_t *tmp, **p = ptr;
> if (min_size > SIZE_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> av_freep(p);
> *size = 0;
> return;
> }
> -if (!ff_fast_malloc(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE, 1))
> +tmp = *p;
> +av_fast_mallocz(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE);
> +/* don't zero the padding if the buffer was reallocated */
> +if (*p && *p == tmp)
> memset(*p + min_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> }
>
> void av_fast_padded_mallocz(void *ptr, unsigned int *size, size_t min_size)
> {
> -uint8_t **p = ptr;
> +uint8_t *tmp, **p = ptr;
> if (min_size > SIZE_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> av_freep(p);
> *size = 0;
> return;
> }
> -if (!ff_fast_malloc(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE, 1))
> +tmp = *p;
> +av_fast_mallocz(p, size, min_size + AV_INPUT_BUFFER_PADDING_SIZE);
> +/* don't zero the buffer if it was reallocated */
> +if (*p && *p == tmp)
> memset(*p, 0, min_size + AV_INPUT_BUFFER_PADDING_SIZE);
> }
>
>
The checks "*p == tmp" are flawed: It might be that the buffer has been
reallocated and that *p == tmp is nevertheless true (namely if the
buffer could have just been extended at the end) which might lead to
unnecessary zeroing; even worse, "[t]he value of a pointer becomes
indeterminate when the object it points to reaches the end of its
lifetime" (C99, 6.2.4.2), so it is compliant with the standard that if
av_fast_mallocz() reallocates the buffer, the tmp pointer on the stack
of av_fast_padded_malloc[z] might suddenly change (I don't know a system
in which this happens, though).
This can be avoided by always zeroing the padding in
av_fast_padded_malloc() and zeroing the buffer in
av_fast_padded_mallocz() ourselves (in which case one should use
av_fast_malloc() in av_fast_padded_mallocz()).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] mxfdec.c: Try TC from Footer if Header TC was < 1
Added support for reading Start Timecode from Footer (if any).
Specifically targets Omneon 6.4.3.0 but also works on other Versions and
Vendors, e.g. when Header is OpenIncomplete.
Function mxf_resolve_strong_ref_reverse can potentially be re-used for getting
other values like Duration and
Origin from Footer.
---
libavformat/mxfdec.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 3bf480a3a6..557e01f8ed 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1396,6 +1396,19 @@ static const MXFCodecUL *mxf_get_codec_ul(const
MXFCodecUL *uls, UID *uid)
return uls;
}
+static void *mxf_resolve_strong_ref_reverse(MXFContext *mxf, UID *strong_ref,
enum MXFMetadataSetType type)
+{
+int i;
+if (!strong_ref)
+return NULL;
+for (i = mxf->metadata_sets_count-1; i >= 0 ; i--) {
+if (!memcmp(*strong_ref, mxf->metadata_sets[i]->uid, 16) &&
+(type == AnyType || mxf->metadata_sets[i]->type == type)) {
+return mxf->metadata_sets[i];
+}
+}
+return NULL;
+}
static void *mxf_resolve_strong_ref(MXFContext *mxf, UID *strong_ref, enum
MXFMetadataSetType type)
{
int i;
@@ -2328,8 +2341,15 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
continue;
mxf_tc = (MXFTimecodeComponent*)component;
+if (mxf_tc->start_frame <= 0) {
+av_log(mxf->fc, AV_LOG_TRACE, "Header Start Timecode was
%d, trying reversed parsing\n",mxf_tc->start_frame);
+component = mxf_resolve_strong_ref_reverse(mxf,
_track->sequence->structural_components_refs[j], TimecodeComponent);
+mxf_tc = (MXFTimecodeComponent*)component;
+}
+
flags = mxf_tc->drop_frame == 1 ? AV_TIMECODE_FLAG_DROPFRAME : 0;
if (av_timecode_init(, mxf_tc->rate, flags,
mxf_tc->start_frame, mxf->fc) == 0) {
+av_log(mxf->fc, AV_LOG_TRACE, "Setting Start Timecode: %d
\n",mxf_tc->start_frame);
mxf_add_timecode_metadata(>fc->metadata, "timecode", );
break;
}
--
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] Unable to compile with cuda
On Sun, May 23, 2021 at 3:03 PM Dennis Mungai wrote: > On Sun, 23 May 2021 at 15:08, Dylan Fernando wrote: > > > I got it to work, with --enable-cuda as well, using: > > > > PKG_CONFIG_PATH="/home/dylan/Files/nv-codec-headers" ./configure > > --enable-opencl --enable-vulkan --enable-libglslang --disable-stripping > > --enable-nonfree --enable-cuda --enable-cuda-nvcc > > --extra-cflags=-I/opt/local/cuda/include --nvccflags="-gencode > > arch=compute_52,code=sm_52 -O2" > > > > Thanks, > > Dylan > > > > > > Dylan, > > That has to be a very old build of FFmpeg. The option --enable-cuda has > been deprecated for months. Try building from a current release or git > master. > For the LLVM route, you can also pass nvccflags in this fashion: > --enable-cuda-llvm --nvccflags="--cuda-gpu-arch=sm_52 -O2". > These flags will differ based on your current GPU and the CUDA version in > use. See > > https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#options-for-steering-gpu-code-generation > FFmpeg's ./cconfigure script picks a very old set of flags that are > deprecated in newer CUDA versions, hence the need to override these flags > with CUDA builds. See: > https://github.com/FFmpeg/FFmpeg/blob/master/configure#L4382 > The difference between the build with and without the proprietary CUDA SDK > will be the inclusion of the scale_npp filters. > With the proprietary SDK, both the scale_npp and scale_cuda filters will be > available. > With the cuda llvm route, only scale_cuda will be available. > For more on their usage, see https://superuser.com/a/1650962/473795 > And for more on compiling cuda with llvm, see the llvm wiki entry here: > https://llvm.org/docs/CompileCudaWithLLVM.html > ___ > 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". > Hi Dennis, Timo, I omitted --enable-cuda and it works correctly. I also switched to using --enable-cuda-llvm. Thanks, Dylan ___ 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] avcodec/j2kenc: fixed help for jpeg2000 dwt53
Now with cosmetics and two new defines.
---
libavcodec/j2kenc.c | 16
libavcodec/jpeg2000.h | 4
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..4d5022db26 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1812,16 +1812,16 @@ static const AVOption options[] = {
{ "tile_width","Tile Width",OFFSET(tile_width),
AV_OPT_TYPE_INT, { .i64 = 256 }, 1, 1<<30, VE, },
{ "tile_height", "Tile Height", OFFSET(tile_height),
AV_OPT_TYPE_INT, { .i64 = 256 }, 1, 1<<30, VE, },
{ "pred", "DWT Type", OFFSET(pred),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, "pred"
},
-{ "dwt97int", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
-{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX, VE, "pred"
},
+{ "dwt97int", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_DWT97INT}, INT_MIN, INT_MAX, VE,
"pred"},
+{ "dwt53", NULL,0,
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_DWT53 }, INT_MIN, INT_MAX, VE,
"pred"},
{ "sop", "SOP marker",OFFSET(sop),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
{ "eph", "EPH marker",OFFSET(eph),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE, },
-{ "prog", "Progression Order", OFFSET(prog),
AV_OPT_TYPE_INT, { .i64 = 0 }, JPEG2000_PGOD_LRCP,
JPEG2000_PGOD_CPRL, VE, "prog" },
-{ "lrcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_LRCP }, 0, 0,
VE, "prog" },
-{ "rlcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RLCP}, 0, 0,
VE, "prog" },
-{ "rpcl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RPCL}, 0, 0,
VE, "prog" },
-{ "pcrl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_PCRL}, 0, 0,
VE, "prog" },
-{ "cprl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_CPRL}, 0, 0,
VE, "prog" },
+{ "prog", "Progression Order", OFFSET(prog),
AV_OPT_TYPE_INT, { .i64 = 0 }, JPEG2000_PGOD_LRCP,
JPEG2000_PGOD_CPRL, VE, "prog" },
+{ "lrcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_LRCP}, 0, 0, VE,
"prog" },
+{ "rlcp", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RLCP}, 0, 0, VE,
"prog" },
+{ "rpcl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_RPCL}, 0, 0, VE,
"prog" },
+{ "pcrl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_PCRL}, 0, 0, VE,
"prog" },
+{ "cprl", NULL,OFFSET(prog),
AV_OPT_TYPE_CONST, { .i64 = JPEG2000_PGOD_CPRL}, 0, 0, VE,
"prog" },
{ "layer_rates", "Layer Rates", OFFSET(lr_str),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, VE },
{ NULL }
};
diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index 612832c872..1a37f0bbbe 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -111,6 +111,10 @@ enum Jpeg2000Quantsty { // quantization style
#define JPEG2000_CSTY_SOP 0x02 // SOP marker present
#define JPEG2000_CSTY_EPH 0x04 // EPH marker present
+// Lossy and lossless DWTs
+#define JPEG2000_DWT97INT 0x00 // lossy DWT
+#define JPEG2000_DWT53 0x01 // lossless DWT
+
// Progression orders
#define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
level-component-position progression
#define JPEG2000_PGOD_RLCP 0x01 // Resolution
level-layer-component-position progression
--
2.30.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".
