Re: [FFmpeg-devel] [PATCH v5 0/6] Implement SEI parsing for QSV decoders
On Fri, 2022-07-01 at 20:48 +, ffmpegagent wrote: > Missing SEI information has always been a major drawback when using the QSV > decoders. I used to think that there's no chance to get at the data without > explicit implementation from the MSDK side (or doing something weird like > parsing in parallel). It turned out that there's a hardly known api method > that provides access to all SEI (h264/hevc) or user data (mpeg2video). > > This allows to get things like closed captions, frame packing, display > orientation, HDR data (mastering display, content light level, etc.) without > having to rely on those data being provided by the MSDK as extended buffers. > > The commit "Implement SEI parsing for QSV decoders" includes some hard-coded > workarounds for MSDK bugs which I reported: > https://github.com/Intel-Media-SDK/MediaSDK/issues/2597#issuecomment-1072795311 > > But that doesn't help. Those bugs exist and I'm sharing my workarounds, > which are empirically determined by testing a range of files. If someone is > interested, I can provide private access to a repository where we have been > testing this. Alternatively, I could also leave those workarounds out, and > just skip those SEI types. > > In a previous version of this patchset, there was a concern that payload > data might need to be re-ordered. Meanwhile I have researched this carefully > and the conclusion is that this is not required. > > My detailed analysis can be found here: > https://gist.github.com/softworkz/36c49586a8610813a32270ee3947a932 > > v4 > > * add new dependencies in makefile Now, build still works when someone uses >configure --disable-decoder=h264 --disable-decoder=hevc >--disable-decoder=mpegvideo --disable-decoder=mpeg1video >--disable-decoder=mpeg2video --enable-libmfx > > v3 > > * frame.h: clarify doc text for av_frame_copy_side_data() > > v2 > > * qsvdec: make error handling consistent and clear > * qsvdec: remove AV_CODEC_ID_MPEG1VIDEO constants > * hevcdec: rename function to ff_hevc_set_side_data(), add doc text > > v3 > > * qsvdec: fix c/p error > > softworkz (6): > avutil/frame: Add av_frame_copy_side_data() and > av_frame_remove_all_side_data() > avcodec/vpp_qsv: Copy side data from input to output frame > avcodec/mpeg12dec: make mpeg_decode_user_data() accessible > avcodec/hevcdec: make set_side_data() accessible > avcodec/h264dec: make h264_export_frame_props() accessible > avcodec/qsvdec: Implement SEI parsing for QSV decoders > > doc/APIchanges | 4 + > libavcodec/Makefile | 6 +- > libavcodec/h264_slice.c | 98 --- > libavcodec/h264dec.h | 2 + > libavcodec/hevcdec.c | 117 +- > libavcodec/hevcdec.h | 9 ++ > libavcodec/hevcdsp.c | 4 + > libavcodec/mpeg12.h | 28 + > libavcodec/mpeg12dec.c | 40 +- > libavcodec/qsvdec.c | 234 +++ > libavfilter/qsvvpp.c | 6 + > libavfilter/vf_overlay_qsv.c | 19 ++- > libavutil/frame.c| 67 ++ > libavutil/frame.h| 32 + > libavutil/version.h | 2 +- > 15 files changed, 494 insertions(+), 174 deletions(-) > > > base-commit: 6a82412bf33108111eb3f63076fd5a51349ae114 > Published-As: > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-31%2Fsoftworkz%2Fsubmit_qsv_sei-v5 > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging- > 31/softworkz/submit_qsv_sei-v5 > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/31 > > Range-diff vs v4: > > 1: 7656477360 = 1: 7656477360 avutil/frame: Add av_frame_copy_side_data() > and av_frame_remove_all_side_data() > 2: 06976606c5 = 2: 06976606c5 avcodec/vpp_qsv: Copy side data from input to > output frame > 3: 320a8a535c = 3: 320a8a535c avcodec/mpeg12dec: make > mpeg_decode_user_data() accessible > 4: e58ad6564f = 4: e58ad6564f avcodec/hevcdec: make set_side_data() > accessible > 5: a57bfaebb9 = 5: 4c0b6eb4cb avcodec/h264dec: make > h264_export_frame_props() accessible > 6: 3f2588563e ! 6: 19bc00be4d avcodec/qsvdec: Implement SEI parsing for QSV > decoders > @@ Commit message > > Signed-off-by: softworkz > > + ## libavcodec/Makefile ## > +@@ libavcodec/Makefile: OBJS-$(CONFIG_MSS34DSP)+= > mss34dsp.o > + OBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o > + OBJS-$(CONFIG_QPELDSP) += qpeldsp.o > + OBJS-$(CONFIG_QSV) += qsv.o > +-OBJS-$(CONFIG_QSVDEC) += qsvdec.o > ++OBJS-$(CONFIG_QSVDEC) += qsvdec.o h264_slice.o > h264_cabac.o h264_cavlc.o \ > ++ h264_direct.o h264_mb.o > h264_picture.o h264_loopfilter.o \ > ++ h264dec.o h264_refs.o cabac.o > hevcdec.o hevc_refs.o \ > +
Re: [FFmpeg-devel] [PATCH v2] libavcodec/qsvenc: Use parameter from AVCodecContext to reset qsv codec
On Thu, 2022-07-14 at 16:43 +0800, Wenbin Chen wrote:
> Using parameter from AVCodecContext to reset qsv codec is more suitable
> for MFXVideoENCODE_Reset()'s usage. Per-frame metadata is more suitable
> for the usage of mfxEncodeCtrl being passed to
> MFXVideoENCODE_EncodeFrameAsync(). Now change it to use the value
> from AVCodecContext.
> Because q->param is passed to both "in" and "out" parameters when call
> MFXVideoENCODE_Query(), the value in q->param may be changed. New
> variables are added to store old configuration, so that we can detect
> real parameter change.
>
> Signed-off-by: Wenbin Chen
> ---
> doc/encoders.texi | 9 +---
> libavcodec/qsvenc.c | 50 ++---
> libavcodec/qsvenc.h | 6 ++
> 3 files changed, 36 insertions(+), 29 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 02a91ffe96..6d73f74196 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3337,10 +3337,13 @@ For encoders set this flag to ON to reduce power
> consumption and GPU usage.
> Following options can be used durning qsv encoding.
>
> @table @option
> -@item @var{qsv_config_qp}
> +@item @var{global_quality}
> +@item @var{i_quant_factor}
> +@item @var{i_quant_offset}
> +@item @var{b_quant_factor}
> +@item @var{b_quant_offset}
> Supported in h264_qsv and hevc_qsv.
> -This option can be set in per-frame metadata. QP parameter can be dynamically
> -changed when encoding in CQP mode.
> +Change these value to reset qsv codec's qp configuration.
> @end table
>
> @subsection H264 options
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2382c2f5f7..c817577c23 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -738,6 +738,11 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
> q->param.mfx.QPI = av_clip(quant * fabs(avctx->i_quant_factor) +
> avctx->i_quant_offset, 0, 51);
> q->param.mfx.QPP = av_clip(quant, 0, 51);
> q->param.mfx.QPB = av_clip(quant * fabs(avctx->b_quant_factor) +
> avctx->b_quant_offset, 0, 51);
> +q->old_global_quality = avctx->global_quality;
> +q->old_i_quant_factor = avctx->i_quant_factor;
> +q->old_i_quant_offset = avctx->i_quant_offset;
> +q->old_b_quant_factor = avctx->b_quant_factor;
> +q->old_b_quant_offset = avctx->b_quant_offset;
>
> break;
> #if QSV_HAVE_AVBR
> @@ -1621,38 +1626,31 @@ static int set_roi_encode_ctrl(AVCodecContext *avctx,
> const AVFrame *frame,
> return 0;
> }
>
> -static int update_qp(AVCodecContext *avctx, QSVEncContext *q,
> - const AVFrame *frame)
> +static int update_qp(AVCodecContext *avctx, QSVEncContext *q)
> {
> -int updated = 0, qp = 0, new_qp;
> -char *tail;
> -AVDictionaryEntry *entry = NULL;
> +int updated = 0, new_qp = 0;
>
> if (avctx->codec_id != AV_CODEC_ID_H264 && avctx->codec_id !=
> AV_CODEC_ID_HEVC)
> return 0;
>
> -entry = av_dict_get(frame->metadata, "qsv_config_qp", NULL, 0);
> -if (entry && q->param.mfx.RateControlMethod == MFX_RATECONTROL_CQP) {
> -qp = strtol(entry->value, &tail, 10);
> -if (*tail) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid qsv_config_qp string.
> Ignore this metadata\n");
> +if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_CQP) {
> +UPDATE_PARAM(q->old_global_quality, avctx->global_quality);
> +UPDATE_PARAM(q->old_i_quant_factor, avctx->i_quant_factor);
> +UPDATE_PARAM(q->old_i_quant_offset, avctx->i_quant_offset);
> +UPDATE_PARAM(q->old_b_quant_factor, avctx->b_quant_factor);
> +UPDATE_PARAM(q->old_b_quant_offset, avctx->b_quant_offset);
> +if (!updated)
> return 0;
> -}
> -if (qp < 0 || qp > 51) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid qp, clip to 0 ~ 51\n");
> -qp = av_clip(qp, 0, 51);
> -}
> -av_log(avctx, AV_LOG_DEBUG, "Configure qp: %d\n",qp);
> -UPDATE_PARAM(q->param.mfx.QPP, qp);
> -new_qp = av_clip(qp * fabs(avctx->i_quant_factor) +
> -avctx->i_quant_offset, 0, 51);
> -UPDATE_PARAM(q->param.mfx.QPI, new_qp);
> -new_qp = av_clip(qp * fabs(avctx->b_quant_factor) +
> -avctx->b_quant_offset, 0, 51);
> -UPDATE_PARAM(q->param.mfx.QPB, new_qp);
> +
> +new_qp = avctx->global_quality / FF_QP2LAMBDA;
> +q->param.mfx.QPI = av_clip(new_qp * fabs(avctx->i_quant_factor) +
> +avctx->i_quant_offset, 0, 51);
> +q->param.mfx.QPP = av_clip(new_qp, 0, 51);
> +q->param.mfx.QPB = av_clip(new_qp * fabs(avctx->b_quant_factor) +
> +avctx->b_quant_offset, 0, 51);
> av_log(avctx, AV_LOG_DEBUG,
> -"using fixed qp = %d/%d/%d for idr/p/b frames\n",
> -q->param.mfx.QPI,
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: Change the parameter log to be thread safe
On Fri, 2022-07-08 at 15:14 +0800, Wenbin Chen wrote:
> Dividing one line log into several av_log() call is not thread safe. Now
> merge these strings into one av_log() call.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/qsvenc.c | 87 ++---
> 1 file changed, 42 insertions(+), 45 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2382c2f5f7..5729292f94 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -182,6 +182,7 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> mfxExtCodingOption2 *co2 = NULL;
> mfxExtCodingOption3 *co3 = NULL;
> mfxExtHEVCTiles *exthevctiles = NULL;
> +const char *tmp_str = NULL;
>
> if (q->co2_idx > 0)
> co2 = (mfxExtCodingOption2*)coding_opts[q->co2_idx];
> @@ -195,13 +196,12 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(avctx->codec_id, info->CodecProfile), info-
> >CodecLevel);
>
> -av_log(avctx, AV_LOG_VERBOSE, "GopPicSize: %"PRIu16"; GopRefDist:
> %"PRIu16"; GopOptFlag: ",
> - info->GopPicSize, info->GopRefDist);
> -if (info->GopOptFlag & MFX_GOP_CLOSED)
> -av_log(avctx, AV_LOG_VERBOSE, "closed ");
> -if (info->GopOptFlag & MFX_GOP_STRICT)
> -av_log(avctx, AV_LOG_VERBOSE, "strict ");
> -av_log(avctx, AV_LOG_VERBOSE, "; IdrInterval: %"PRIu16"\n", info-
> >IdrInterval);
> +av_log(avctx, AV_LOG_VERBOSE,
> + "GopPicSize: %"PRIu16"; GopRefDist: %"PRIu16"; GopOptFlag:%s%s;
> IdrInterval: %"PRIu16"\n",
> + info->GopPicSize, info->GopRefDist,
> + info->GopOptFlag & MFX_GOP_CLOSED ? " closed" : "",
> + info->GopOptFlag & MFX_GOP_STRICT ? " strict" : "",
> + info->IdrInterval);
>
> av_log(avctx, AV_LOG_VERBOSE, "TargetUsage: %"PRIu16"; RateControlMethod:
> %s\n",
> info->TargetUsage, print_ratecontrol(info->RateControlMethod));
> @@ -269,45 +269,46 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> av_log(avctx, AV_LOG_VERBOSE, "IntRefType: %"PRIu16";
> IntRefCycleSize: %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> co2->IntRefType, co2->IntRefCycleSize, co2->IntRefQPDelta);
>
> -av_log(avctx, AV_LOG_VERBOSE, "MaxFrameSize: %d; ", co2-
> >MaxFrameSize);
> -av_log(avctx, AV_LOG_VERBOSE, "MaxSliceSize: %d; ", co2-
> >MaxSliceSize);
> -av_log(avctx, AV_LOG_VERBOSE, "\n");
> +av_log(avctx, AV_LOG_VERBOSE, "MaxFrameSize: %d; MaxSliceSize: %d\n",
> + co2->MaxFrameSize, co2->MaxSliceSize);
>
> av_log(avctx, AV_LOG_VERBOSE,
> "BitrateLimit: %s; MBBRC: %s; ExtBRC: %s\n",
> print_threestate(co2->BitrateLimit), print_threestate(co2-
> >MBBRC),
> print_threestate(co2->ExtBRC));
>
> -av_log(avctx, AV_LOG_VERBOSE, "Trellis: ");
> if (co2->Trellis & MFX_TRELLIS_OFF) {
> -av_log(avctx, AV_LOG_VERBOSE, "off");
> +av_log(avctx, AV_LOG_VERBOSE, "Trellis: off\n");
> } else if (!co2->Trellis) {
> -av_log(avctx, AV_LOG_VERBOSE, "auto");
> +av_log(avctx, AV_LOG_VERBOSE, "Trellis: auto\n");
> } else {
> -if (co2->Trellis & MFX_TRELLIS_I) av_log(avctx, AV_LOG_VERBOSE,
> "I");
> -if (co2->Trellis & MFX_TRELLIS_P) av_log(avctx, AV_LOG_VERBOSE,
> "P");
> -if (co2->Trellis & MFX_TRELLIS_B) av_log(avctx, AV_LOG_VERBOSE,
> "B");
> +char trellis_type[4];
> +int i = 0;
> +if (co2->Trellis & MFX_TRELLIS_I) trellis_type[i++] = 'I';
> +if (co2->Trellis & MFX_TRELLIS_P) trellis_type[i++] = 'P';
> +if (co2->Trellis & MFX_TRELLIS_B) trellis_type[i++] = 'B';
> +trellis_type[i] = 0;
> +av_log(avctx, AV_LOG_VERBOSE, "Trellis: %s\n", trellis_type);
> }
> -av_log(avctx, AV_LOG_VERBOSE, "\n");
>
> -av_log(avctx, AV_LOG_VERBOSE,
> - "RepeatPPS: %s; NumMbPerSlice: %"PRIu16"; LookAheadDS: ",
> - print_threestate(co2->RepeatPPS), co2->NumMbPerSlice);
> switch (co2->LookAheadDS) {
> -case MFX_LOOKAHEAD_DS_OFF: av_log(avctx, AV_LOG_VERBOSE,
> "off"); break;
> -case MFX_LOOKAHEAD_DS_2x: av_log(avctx, AV_LOG_VERBOSE,
> "2x"); break;
> -case MFX_LOOKAHEAD_DS_4x: av_log(avctx, AV_LOG_VERBOSE,
> "4x"); break;
> -default: av_log(avctx, AV_LOG_VERBOSE, "unknown");
> break;
> +case MFX_LOOKAHEAD_DS_OFF: tmp_str = "off"; break;
> +case MFX_LOOKAHEAD_DS_2x: tmp_str = "2x"; break;
> +case MFX_LOOKAHEAD_DS_4x: tmp_str = "4x"; break;
> +default: tmp_str = "unknown"; break;
> }
> -av_log(avctx, AV_
Re: [FFmpeg-devel] [PATCH v2] libavfilter/vf_overlay_qsv: Use format of first input to set output format for overlay_qsv
On Thu, 2022-07-07 at 11:12 +0800, Wenbin Chen wrote:
> overlay_qsv hard coded to use nv12 as output format. Now use the format
> of the first input to set output format.
>
> For detailed information of supported format on different platform,
> please see the "composition" rows in "Video Processing Features" at
> below link:
>
https://www.intel.com/content/www/us/en/develop/documentation/media-capabilities-of-intel-hardware/top.html
>
> Signed-off-by: Wenbin Chen
> ---
> libavfilter/vf_overlay_qsv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
> index 7e76b39aa9..d947a1faa1 100644
> --- a/libavfilter/vf_overlay_qsv.c
> +++ b/libavfilter/vf_overlay_qsv.c
> @@ -276,6 +276,7 @@ static int config_output(AVFilterLink *outlink)
> int ret;
>
> av_log(ctx, AV_LOG_DEBUG, "Output is of %s.\n",
> av_get_pix_fmt_name(outlink->format));
> +vpp->qsv_param.out_sw_format = in0->format;
> if ((in0->format == AV_PIX_FMT_QSV && in1->format != AV_PIX_FMT_QSV) ||
> (in0->format != AV_PIX_FMT_QSV && in1->format == AV_PIX_FMT_QSV)) {
> av_log(ctx, AV_LOG_ERROR, "Mixing hardware and software pixel formats
> is not supported.\n");
> @@ -288,6 +289,7 @@ static int config_output(AVFilterLink *outlink)
> av_log(ctx, AV_LOG_ERROR, "Inputs with different underlying QSV
> devices are forbidden.\n");
> return AVERROR(EINVAL);
> }
> +vpp->qsv_param.out_sw_format = hw_frame0->sw_format;
> }
>
> outlink->w = vpp->var_values[VAR_MW];
LGTM, will apply
Thanks
Haihao
___
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] lavc: add API for exporting reconstructed frames from encoders
On 7/18/2022 3:05 PM, Anton Khirnov wrote: --- doc/APIchanges | 5 + libavcodec/avcodec.c | 12 libavcodec/avcodec.h | 20 libavcodec/codec.h | 8 libavcodec/decode.c| 4 +--- libavcodec/decode.h| 5 + libavcodec/encode.c| 25 + libavcodec/encode.h| 5 + libavcodec/internal.h | 8 libavcodec/options_table.h | 1 + libavcodec/version.h | 2 +- 11 files changed, 87 insertions(+), 8 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 4e218af94e..b50fece404 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -14,6 +14,11 @@ libavutil: 2021-04-27 API changes, most recent first: +2022-07-xx - xx - lavc 59.40.100 - avcodec.h codec.h + Add AV_CODEC_FLAG_RECON_FRAME and AV_CODEC_CAP_ENCODER_RECON_FRAME. + avcodec_receive_frame() may now be used on encoders when + AV_CODEC_FLAG_RECON_FRAME is active. + 2022-07-xx - xx - lavu 57.30.100 - frame.h av_frame_make_writable() may now be called on non-refcounted frames and will make a refcounted copy out of them. LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Patch: fftools/ffprobe.c: avoid overriding error code.
fftools/ffprobe.c: avoid overriding error code. 0001-fftools-ffprobe.c-avoid-overriding-error-code.patch Description: 0001-fftools-ffprobe.c-avoid-overriding-error-code.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Make disposition forced work with mov_text subtitles.
I see what I did wrong. -v or --reroll-count are arguments to git format-patch so obviously aren't applied by git send-email when providing a preformatted patch, which I did. My mistake. On Mon, 18 Jul 2022 at 18:48, Leo Izen wrote: > On 7/18/22 12:08, facefunk wrote: > > We are not currently able to force mov_text subtitles by setting > -disposition:s:0 +forced or equivalent. By setting the forced flags in > movtextenc as specifid in > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html > subtitles can be forced as expected in VLC and similar players. > > > > ___ > > 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". > In the future, add -v2 to your git-format-patch or git-send-email > command, to make it say [PATCH v2]. This makes it easier to keep track > of what's changed. > > - Leo Izen (thebombzen) > ___ > 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 v3] libavcodec: Make disposition forced work with mov_text subtitles.
We are not currently able to force mov_text subtitles by setting
-disposition:s:0 +forced or equivalent. By setting the forced flags in
movtextenc as specifid in
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
subtitles can be forced as expected in VLC and similar players.
Copy AVStream disposition to AVCodecContext and use to set
DISPLAY_FLAG_ALL_SAMPLES_FORCED in movtextenc.c.
Signed-off-by: facefunk
---
fftools/ffmpeg_opt.c| 5 +
libavcodec/avcodec.h| 11 +++
libavcodec/movtextenc.c | 41 -
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index e08455478f..a7fa809859 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2244,6 +2244,11 @@ static int set_dispositions(OutputFile *of,
AVFormatContext *ctx)
if (ret < 0)
return ret;
+
+// For output streams, Set subtitle flags to forced when stream
+// disposition is forced.
+if(ost->enc_ctx && ost->st->disposition & AV_DISPOSITION_FORCED)
+ost->enc_ctx->subtitle_flags |= AV_SUBTITLE_FLAG_FORCED;
}
} else {
// For each media type with more than one stream, find a suitable
stream to
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index cb5c25bf63..182f452557 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2054,6 +2054,17 @@ typedef struct AVCodecContext {
* The decoder can then override during decoding as needed.
*/
AVChannelLayout ch_layout;
+
+/**
+ * Subtitle codecs only. Bit set of AV_SUBTITLE_FLAG_*.
+ *
+ * Some subtitle codecs may use this field to determine the subtitle
+ * display flags to encode.
+ *
+ * - encoding: set by user
+ * - decoding: unused
+ */
+int subtitle_flags;
} AVCodecContext;
/**
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 728338f2cc..bb6021f6d1 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -50,6 +50,40 @@
#define FONTSIZE_SCALE(s,fs) ((fs) * (s)->font_scale_factor + 0.5)
#define av_bprint_append_any(buf, data, size) av_bprint_append_data(buf,
((const char*)data), size)
+/**
+ *
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
+ *
+ * Display flags
+ * A 32-bit integer containing flags that describe how the subtitle text should
+ * be drawn.
+ * The following flags are defined:
+ *
+ * Vertical placement
+ * Controls vertical placement of the subtitle text.
+ * If this flag is set, the subtitle media handler uses the top coordinate of
+ * the display bounds of the override 'tbox' text box to determine the
+ * subtitle’s vertical placement as described in Subtitle Track Header Size
+ * and Placement. Otherwise, the subtitle displays at the bottom of the video.
+ */
+#define DISPLAY_FLAG_VERTICAL_PLACEMENT_TOP 0x2000
+
+/**
+ * Some samples are forced
+ * Indicates whether any subtitle samples contain forced atoms. If this flag is
+ * set, at least one sample contains a forced ('frcd') atom as described in
+ * Subtitle Sample Data.
+ */
+#define DISPLAY_FLAG_SOME_SAMPLES_FORCED0x4000
+
+/**
+ * All samples are forced
+ * If this flag is set, the subtitle media handler treats all samples as forced
+ * subtitles, regardless of the presence or absence of a 'frcd' atom.
+ * If this flag is set, the Some Samples Are Forced flag must also be set
+ * (making 0xC000).
+ */
+#define DISPLAY_FLAG_ALL_SAMPLES_FORCED 0x8000
+
typedef struct {
uint16_t style_start;
uint16_t style_end;
@@ -183,6 +217,7 @@ static int encode_sample_description(AVCodecContext *avctx)
int font_names_total_len = 0;
MovTextContext *s = avctx->priv_data;
uint8_t buf[30], *p = buf;
+uint32_t display_flags = 0;
// 0x00, 0x00, 0x00, 0x00, // uint32_t displayFlags
// 0x01, // int8_t horizontal-justification
@@ -241,7 +276,11 @@ static int encode_sample_description(AVCodecContext *avctx)
(255 - ((uint32_t)style->back_color >> 24));
}
-bytestream_put_be32(&p, 0); // displayFlags
+if (avctx->subtitle_flags & AV_SUBTITLE_FLAG_FORCED)
+display_flags = DISPLAY_FLAG_SOME_SAMPLES_FORCED |
+DISPLAY_FLAG_ALL_SAMPLES_FORCED;
+
+bytestream_put_be32(&p, display_flags); // displayFlags
bytestream_put_be16(&p, 0x01FF); // horizontal/vertical justification (2x
int8_t)
bytestream_put_be32(&p, back_color);
bytestream_put_be64(&p, 0); // BoxRecord - 4xint16_t: top, left, bottom,
right
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Make disposition forced work with mov_text subtitles.
Okay, great! Thanks for reviewing. I've addressed your points as well as a few tweaks in the spirit of preserving the abstraction boundary. Would the attached patch revision be acceptable? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/pthread_frame: update the main avctx from the current, ThreadContext
On Sat, Jul 09, 2022 at 08:45:31AM +0200, Steve Lhomme wrote: > Patch attached in the email. > > In some cases, the submit packet can result in configurations changes of the > hardware decoders. The previous HW context is then freed and a new one > created. That context is supposed to move up to the main context and the > other threads. > > It appears that when more than 2 frame threads are involved, the new context > doesn't move in the right place (or rather at the right time). And it can > create a crash when reusing the old HW context. This patch fixes the issue I > could reproduce in VLC with DXVA decoding. > > I have no idea if this is correct or the side effects induced by this. It > seems the right thing to do. Keeping the previous call exhibits the issue. > It seems odd the other existing thread context are not updated with the > current hwaccel_priv_data. But maybe they are updated later from the "main" > thread context, in which case this patch seems solid. > pthread_frame.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > 2274e52382008f403c7bf52f76d608d2a56ef859 > 0001-avcodec-pthread_frame-update-the-main-avctx-from-the.patch > From e8abeeff92f5d7b3b553acdb7595d40153cbec1e Mon Sep 17 00:00:00 2001 > From: Steve Lhomme > Date: Fri, 8 Jul 2022 11:49:27 +0200 > Subject: [PATCH] avcodec/pthread_frame: update the main avctx from the current > ThreadContext > > After a submit_decoder() the hwaccel_priv_data may have changed in that avctx. > > Doing it after the "next available frame" loop will likely point to the > hwaccel_priv_data from another PerThreadContext which had the old value which > might have been freed, if the submit_decoder() resulting in a format change. > --- > libavcodec/pthread_frame.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) It would be nice if a solution to this would make it in 5.1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfdec: SMPTE RDD 48:2018 support
mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxf.c | 3 +++
> libavformat/mxf.h | 1 +
> libavformat/mxfdec.c | 48
>
> 3 files changed, 52 insertions(+)
>
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index 36d662b58c..8ef928b8fc 100644
> --- a/libavformat/mxf.c
> +++ b/libavformat/mxf.c
> @@ -66,6 +66,9 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02
> ,0x02,0x01 }, 16, AV_CODEC_ID_V210 }, /* V210 */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x11
> ,0x00,0x00 }, 14, AV_CODEC_ID_PRORES }, /* Avid MC7 ProRes */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x06
> ,0x00,0x00 }, 14, AV_CODEC_ID_PRORES }, /* Apple ProRes */
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> ,0x01,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> ,0x02,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V1 */
> + { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> ,0x04,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V3 */
I do not see these ULs listed in the spec. Are they in some appropriate
RP?
> +static const uint8_t mxf_ffv1_extradata[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x04,0x01,0x06,0x0c,0x01,0x00
> ,0x00,0x00 };
Nor do I see this UL. In fact the spec doesn't seem to mention FFV1 at
all unless my eyes deceive me.
/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".
Re: [FFmpeg-devel] [PATCH] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
Quoting James Almer (2022-07-18 20:18:16)
>
>
> On 7/18/2022 3:15 PM, Anton Khirnov wrote:
> > Quoting James Almer (2022-07-18 14:23:58)
> >> On 7/18/2022 4:12 AM, Anton Khirnov wrote:
> >>> ---
> >>>libavcodec/libx264.c | 52 +++-
> >>>1 file changed, 51 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> >>> index 98ec030865..5e360682e6 100644
> >>> --- a/libavcodec/libx264.c
> >>> +++ b/libavcodec/libx264.c
> >>> @@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
> >>>pic->extra_sei.num_payloads = 0;
> >>>}
> >>>
> >>> +static enum AVPixelFormat csp_to_pixfmt(int csp)
> >>> +{
> >>> +switch (csp) {
> >>> +#ifdef X264_CSP_I400
> >>> +case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
> >>> +case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
> >>> +#endif
> >>> +case X264_CSP_I420: return
> >>> AV_PIX_FMT_YUV420P;
> >>> +case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return
> >>> AV_PIX_FMT_YUV420P10;
> >>> +case X264_CSP_I422: return
> >>> AV_PIX_FMT_YUV422P;
> >>> +case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return
> >>> AV_PIX_FMT_YUV422P10;
> >>> +case X264_CSP_I444: return
> >>> AV_PIX_FMT_YUV444P;
> >>> +case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return
> >>> AV_PIX_FMT_YUV444P10;
> >>
> >> We're still supporting old x264 versions, so you should add some
> >> considerations for 9 bit pixfmts. On X264_BUILD < 153, just check the
> >> value of x264_bit_depth.
> >
> > Is there much point in continuing to support 5.5 year old x264? We could
> > drop a lot of ugliness, including the abominable X264_init_static().
>
> Afaik we tend to support what's shipped with not yet EOL'd big distros
> like Debian and Ubuntu. I assume Michael's Ubuntu setup is one of those,
> and it has a libx264 without X264_CSP_I400, for example.
Debian oldstable has libx264 155 at least.
--
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] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
On 7/18/2022 3:15 PM, Anton Khirnov wrote:
Quoting James Almer (2022-07-18 14:23:58)
On 7/18/2022 4:12 AM, Anton Khirnov wrote:
---
libavcodec/libx264.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 98ec030865..5e360682e6 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
pic->extra_sei.num_payloads = 0;
}
+static enum AVPixelFormat csp_to_pixfmt(int csp)
+{
+switch (csp) {
+#ifdef X264_CSP_I400
+case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
+case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
+#endif
+case X264_CSP_I420: return AV_PIX_FMT_YUV420P;
+case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV420P10;
+case X264_CSP_I422: return AV_PIX_FMT_YUV422P;
+case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV422P10;
+case X264_CSP_I444: return AV_PIX_FMT_YUV444P;
+case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV444P10;
We're still supporting old x264 versions, so you should add some
considerations for 9 bit pixfmts. On X264_BUILD < 153, just check the
value of x264_bit_depth.
Is there much point in continuing to support 5.5 year old x264? We could
drop a lot of ugliness, including the abominable X264_init_static().
Afaik we tend to support what's shipped with not yet EOL'd big distros
like Debian and Ubuntu. I assume Michael's Ubuntu setup is one of those,
and it has a libx264 without X264_CSP_I400, for example.
___
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] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
Quoting James Almer (2022-07-18 14:23:58)
> On 7/18/2022 4:12 AM, Anton Khirnov wrote:
> > ---
> > libavcodec/libx264.c | 52 +++-
> > 1 file changed, 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index 98ec030865..5e360682e6 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
> > pic->extra_sei.num_payloads = 0;
> > }
> >
> > +static enum AVPixelFormat csp_to_pixfmt(int csp)
> > +{
> > +switch (csp) {
> > +#ifdef X264_CSP_I400
> > +case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
> > +case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
> > +#endif
> > +case X264_CSP_I420: return AV_PIX_FMT_YUV420P;
> > +case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return
> > AV_PIX_FMT_YUV420P10;
> > +case X264_CSP_I422: return AV_PIX_FMT_YUV422P;
> > +case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return
> > AV_PIX_FMT_YUV422P10;
> > +case X264_CSP_I444: return AV_PIX_FMT_YUV444P;
> > +case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return
> > AV_PIX_FMT_YUV444P10;
>
> We're still supporting old x264 versions, so you should add some
> considerations for 9 bit pixfmts. On X264_BUILD < 153, just check the
> value of x264_bit_depth.
Is there much point in continuing to support 5.5 year old x264? We could
drop a lot of ugliness, including the abominable X264_init_static().
--
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] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
Quoting James Almer (2022-07-18 19:41:27) > Why not ff_encode_alloc_frame() for this? Can > csp_to_pixfmt(pic_out.img.i_csp) be different than ctx->pix_fmt? Yes, the reconstructed frame is in x264's internal format, which will typically be some flavor of nv12, even if the input format is fully planar. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc: add API for exporting reconstructed frames from encoders
---
doc/APIchanges | 5 +
libavcodec/avcodec.c | 12
libavcodec/avcodec.h | 20
libavcodec/codec.h | 8
libavcodec/decode.c| 4 +---
libavcodec/decode.h| 5 +
libavcodec/encode.c| 25 +
libavcodec/encode.h| 5 +
libavcodec/internal.h | 8
libavcodec/options_table.h | 1 +
libavcodec/version.h | 2 +-
11 files changed, 87 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4e218af94e..b50fece404 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,11 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-07-xx - xx - lavc 59.40.100 - avcodec.h codec.h
+ Add AV_CODEC_FLAG_RECON_FRAME and AV_CODEC_CAP_ENCODER_RECON_FRAME.
+ avcodec_receive_frame() may now be used on encoders when
+ AV_CODEC_FLAG_RECON_FRAME is active.
+
2022-07-xx - xx - lavu 57.30.100 - frame.h
av_frame_make_writable() may now be called on non-refcounted
frames and will make a refcounted copy out of them.
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 5f6e71a39e..9dd4157750 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -390,6 +390,8 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
}
if (avci->in_frame)
av_frame_unref(avci->in_frame);
+if (avci->recon_frame)
+av_frame_unref(avci->recon_frame);
} else {
av_packet_unref(avci->last_pkt_props);
while (av_fifo_read(avci->pkt_props, avci->last_pkt_props, 1) >= 0)
@@ -470,6 +472,7 @@ av_cold int avcodec_close(AVCodecContext *avctx)
av_packet_free(&avci->in_pkt);
av_frame_free(&avci->in_frame);
+av_frame_free(&avci->recon_frame);
av_buffer_unref(&avci->pool);
@@ -716,3 +719,12 @@ int avcodec_is_open(AVCodecContext *s)
{
return !!s->internal;
}
+
+int attribute_align_arg avcodec_receive_frame(AVCodecContext *avctx, AVFrame
*frame)
+{
+av_frame_unref(frame);
+
+if (av_codec_is_decoder(avctx->codec))
+return ff_decode_receive_frame(avctx, frame);
+return ff_encode_receive_frame(avctx, frame);
+}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index cb5c25bf63..04e9d33493 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -231,6 +231,16 @@ typedef struct RcOverride{
* decoded frame in stream.
*/
#define AV_CODEC_FLAG_DROPCHANGED (1 << 5)
+/**
+ * Request the encoder to output reconstructed frames, i.e. frames that would
be
+ * produced by decoding the encoded bistream. These frames may be retrieved by
+ * calling avcodec_receive_frame() immediately after a successful call to
+ * avcodec_receive_packet().
+ *
+ * Should only be used with encoders flagged with the
+ * AV_CODEC_CAP_ENCODER_RECON_FRAME capability.
+ */
+#define AV_CODEC_FLAG_RECON_FRAME (1 << 6)
/**
* Use internal 2pass ratecontrol in first pass mode.
*/
@@ -2595,21 +2605,23 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
AVSubtitle *sub,
int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt);
/**
- * Return decoded output data from a decoder.
+ * Return decoded output data from a decoder or encoder (when the
+ * AV_CODEC_FLAG_RECON_FRAME flag is used).
*
* @param avctx codec context
* @param frame This will be set to a reference-counted video or audio
* frame (depending on the decoder type) allocated by the
- * decoder. Note that the function will always call
+ * codec. Note that the function will always call
* av_frame_unref(frame) before doing anything else.
*
* @return
* 0: success, a frame was returned
* AVERROR(EAGAIN): output is not available in this state - user must
try
* to send new input
- * AVERROR_EOF: the decoder has been fully flushed, and there will
be
+ * AVERROR_EOF: the codec has been fully flushed, and there will be
* no more output frames
- * AVERROR(EINVAL): codec not opened, or it is an encoder
+ * AVERROR(EINVAL): codec not opened, or it is an encoder without
+ * the AV_CODEC_FLAG_RECON_FRAME flag enabled
* AVERROR_INPUT_CHANGED: current decoded frame has changed parameters
* with respect to first decoded frame.
Applicable
* when flag AV_CODEC_FLAG_DROPCHANGED is set.
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 03e8be90a2..77a1a3f5a2 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -182,6 +182,14 @@
*/
#define AV_CODEC_CAP_ENCODER_FLUSH (1 << 21)
+/**
+ * The encoder is able to output reconstructed frame data, i.e. raw frames that
+ * would be produced by decoding the encoded bitstream.
+ *
+ * Reconstructed f
Re: [FFmpeg-devel] Make disposition forced work with mov_text subtitles.
Thanks for the advice. I did --reroll-count=2 but it doesn't seem to have worked. On Mon, 18 Jul 2022 at 18:48, Leo Izen wrote: > On 7/18/22 12:08, facefunk wrote: > > We are not currently able to force mov_text subtitles by setting > -disposition:s:0 +forced or equivalent. By setting the forced flags in > movtextenc as specifid in > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html > subtitles can be forced as expected in VLC and similar players. > > > > ___ > > 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". > In the future, add -v2 to your git-format-patch or git-send-email > command, to make it say [PATCH v2]. This makes it easier to keep track > of what's changed. > > - Leo Izen (thebombzen) > ___ > 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] Make disposition forced work with mov_text subtitles.
On 7/18/22 12:08, facefunk wrote: We are not currently able to force mov_text subtitles by setting -disposition:s:0 +forced or equivalent. By setting the forced flags in movtextenc as specifid in https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html subtitles can be forced as expected in VLC and similar players. ___ 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". In the future, add -v2 to your git-format-patch or git-send-email command, to make it say [PATCH v2]. This makes it easier to keep track of what's changed. - Leo Izen (thebombzen) ___ 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] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
On 7/18/2022 4:12 AM, Anton Khirnov wrote:
---
libavcodec/libx264.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 98ec030865..5e360682e6 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
pic->extra_sei.num_payloads = 0;
}
+static enum AVPixelFormat csp_to_pixfmt(int csp)
+{
+switch (csp) {
+#ifdef X264_CSP_I400
+case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
+case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
+#endif
+case X264_CSP_I420: return AV_PIX_FMT_YUV420P;
+case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV420P10;
+case X264_CSP_I422: return AV_PIX_FMT_YUV422P;
+case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV422P10;
+case X264_CSP_I444: return AV_PIX_FMT_YUV444P;
+case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV444P10;
+case X264_CSP_NV12: return AV_PIX_FMT_NV12;
+case X264_CSP_NV16: return AV_PIX_FMT_NV16;
+};
+return AV_PIX_FMT_NONE;
+}
+
static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, const AVFrame
*frame,
int *got_packet)
{
@@ -496,6 +515,33 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL,
&pic_out) < 0)
return AVERROR_EXTERNAL;
+if (nnal && (ctx->flags & AV_CODEC_FLAG_RECON_FRAME)) {
+AVCodecInternal *avci = ctx->internal;
+
+av_frame_unref(avci->recon_frame);
+
+avci->recon_frame->format = csp_to_pixfmt(pic_out.img.i_csp);
+if (avci->recon_frame->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unhandled reconstructed frame colorspace: %d\n",
+ pic_out.img.i_csp);
+return AVERROR(ENOSYS);
+}
+
+avci->recon_frame->width = ctx->width;
+avci->recon_frame->height = ctx->height;
+for (int i = 0; i < pic_out.img.i_plane; i++) {
+avci->recon_frame->data[i] = pic_out.img.plane[i];
+avci->recon_frame->linesize[i] = pic_out.img.i_stride[i];
+}
+
+ret = av_frame_make_writable(avci->recon_frame);
Why not ff_encode_alloc_frame() for this? Can
csp_to_pixfmt(pic_out.img.i_csp) be different than ctx->pix_fmt?
+if (ret < 0) {
+av_frame_unref(avci->recon_frame);
+return ret;
+}
+}
+
ret = encode_nals(ctx, pkt, nal, nnal);
if (ret < 0)
return ret;
@@ -928,6 +974,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
x4->params.b_repeat_headers = 0;
+if (avctx->flags & AV_CODEC_FLAG_RECON_FRAME)
+x4->params.b_full_recon = 1;
+
if(x4->x264opts){
const char *p= x4->x264opts;
while(p){
@@ -1223,7 +1272,8 @@ FFCodec ff_libx264_encoder = {
.p.id = AV_CODEC_ID_H264,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS |
-AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+AV_CODEC_CAP_ENCODER_RECON_FRAME,
.p.priv_class = &x264_class,
.p.wrapper_name = "libx264",
.priv_data_size = sizeof(X264Context),
___
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] avcodec/wrapped_avframe: Don't presume AVPacket to be writable
It need not be writable; in fact, it is often not writable even if the packet sent to the decoder was writable, because the generic code calls av_packet_ref() on it. It is never writable if a user drains the decoder after every packet, because in this case the decode callback is called from avcodec_send_packet(). Signed-off-by: Andreas Rheinhardt --- libavcodec/wrapped_avframe.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c index e2f27f91a3..c89cdfd1e8 100644 --- a/libavcodec/wrapped_avframe.c +++ b/libavcodec/wrapped_avframe.c @@ -92,7 +92,9 @@ static int wrapped_avframe_decode(AVCodecContext *avctx, AVFrame *out, in = (AVFrame*)pkt->data; -av_frame_move_ref(out, in); +err = av_frame_ref(out, in); +if (err < 0) +return err; err = ff_decode_frame_props(avctx, out); if (err < 0) -- 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] Development opportunity: LTC noise on files created from videotape source: filter idea
On Mon, Jul 18, 2022 at 7:14 PM Michael Niedermayer wrote: > On Mon, Jul 18, 2022 at 09:53:14AM +, Stephen McConnachie wrote: > > Hi FFMPEG developers, > > > > I have a proposal for a paid development opportunity to add a filter to > FFMPEG. > > > > I followed the advice on the FFMPEG Consulting page at > https://ffmpeg.org/consulting.html and am emailing this list to try to > identify if any of the FFMPEG developers may be able to take on a > development commission. > > > > Background: we are digitising high volumes of videotape carriers, and > have identified a common case in some videotape formats where Linear Time > Code from the tape carrier is present on audio stream 1 in the encoded file > - manifesting as a continuous noise. > > > > Idea: could a filter be developed in FFMPEG, based on example files we > can provide, to identify the presence of an LTC-derived audio stream, and > additionally identify which of the streams is the LTC stream. > > > > If this filter idea sounds achievable, I would aim to identify which of > the FFMPEG developers may be able to take on this work, and estimated costs > and timeline. > > It should be possible to implement a LTC decoder that turns a audio track > into > LTC binary data. If that succeeded and the data is valid then teh track > would > very likely have contained LTC. > > Do i understand correctly that the tracks are LTC or normal audio not > mixed? > or are there tracks that mix audio and LTC and require seperation ? > > I think there are several developers who could develop such filter. > I could do it, Iam sure paul could do as well. > Perhaps it there are clear specifications I could. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "I am not trying to be anyone's saviour, I'm trying to think about the > future and not be sad" - Elon Musk > > ___ > 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 1/2] avcodec/wrapped_avframe: Don't leak frame metadata, side-data
wrapped_avframe_decode() uses an AVFrame as dst in av_frame_move_ref() after having called ff_decode_frame_props() to attach side-date to this very frame. This leaks all the side-data and metadata that ff_decode_frame_props() has attached. This happens in various fate-filter-metadata tests since 6ca43a9675d651d7ea47c7ba2fafb1bf831c4d0b. These particular leaks (which affect metadata-only) could be fixed by not adding metadata side-data to AVPackets in libavdevice if they are also available from the AVFrames. Yet this would break users that extract the metadata from AVPackets. The changes to FATE happen because of the way av_dict_set() works when it overwrites an already existing entry: It overwrites the entry to be overwritten with the last entry and adds the new entry at the end. The end result is that the first entry of the dict is the second-to-last-entry of the original dict, the last entry of the dict is the last entry of the old dict and the first count - 2 entries of the original dict are at positions 1..count - 2 in their original order. Signed-off-by: Andreas Rheinhardt --- libavcodec/wrapped_avframe.c | 4 +- tests/ref/fate/filter-metadata-cropdetect | 60 +-- tests/ref/fate/filter-metadata-freezedetect | 4 +- tests/ref/fate/filter-metadata-scdet | 22 +++ .../fate/filter-metadata-signalstats-yuv420p | 2 +- .../filter-metadata-signalstats-yuv420p10 | 2 +- 6 files changed, 47 insertions(+), 47 deletions(-) diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c index 06c274eed0..e2f27f91a3 100644 --- a/libavcodec/wrapped_avframe.c +++ b/libavcodec/wrapped_avframe.c @@ -92,12 +92,12 @@ static int wrapped_avframe_decode(AVCodecContext *avctx, AVFrame *out, in = (AVFrame*)pkt->data; +av_frame_move_ref(out, in); + err = ff_decode_frame_props(avctx, out); if (err < 0) return err; -av_frame_move_ref(out, in); - *got_frame = 1; return 0; } diff --git a/tests/ref/fate/filter-metadata-cropdetect b/tests/ref/fate/filter-metadata-cropdetect index 104acdd77f..f3e1865abd 100644 --- a/tests/ref/fate/filter-metadata-cropdetect +++ b/tests/ref/fate/filter-metadata-cropdetect @@ -1,33 +1,33 @@ pts=0| pts=400 -pts=800|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=1200|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=1600|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=2000|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=2400|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=2800|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=3200|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=3600|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=4000|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=4400|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=4800|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=5200|tag:lavfi.cropdetect.x1=0|tag:lavfi.cropdetect.x2=719|tag:lavfi.cropdetect.y1=61|tag:lavfi.cropdetect.y2=424|tag:lavfi.cropdetect.w=720|tag:lavfi.cropdetect.h=352|tag:lavfi.cropdetect.x=0|tag:lavfi.cropdetect.y=68 -pts=5600|tag:lavfi.cropdetect.
Re: [FFmpeg-devel] Development opportunity: LTC noise on files created from videotape source: filter idea
On Mon, Jul 18, 2022 at 09:53:14AM +, Stephen McConnachie wrote: > Hi FFMPEG developers, > > I have a proposal for a paid development opportunity to add a filter to > FFMPEG. > > I followed the advice on the FFMPEG Consulting page at > https://ffmpeg.org/consulting.html and am emailing this list to try to > identify if any of the FFMPEG developers may be able to take on a development > commission. > > Background: we are digitising high volumes of videotape carriers, and have > identified a common case in some videotape formats where Linear Time Code > from the tape carrier is present on audio stream 1 in the encoded file - > manifesting as a continuous noise. > > Idea: could a filter be developed in FFMPEG, based on example files we can > provide, to identify the presence of an LTC-derived audio stream, and > additionally identify which of the streams is the LTC stream. > > If this filter idea sounds achievable, I would aim to identify which of the > FFMPEG developers may be able to take on this work, and estimated costs and > timeline. It should be possible to implement a LTC decoder that turns a audio track into LTC binary data. If that succeeded and the data is valid then teh track would very likely have contained LTC. Do i understand correctly that the tracks are LTC or normal audio not mixed? or are there tracks that mix audio and LTC and require seperation ? I think there are several developers who could develop such filter. I could do it, Iam sure paul could do as well. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] libavcodec: Make disposition forced work with mov_text subtitles.
On Mon, Jul 18, 2022 at 05:08:31PM +0100, facefunk wrote:
> We are not currently able to force mov_text subtitles by setting
> -disposition:s:0 +forced or equivalent. By setting the forced flags in
> movtextenc as specifid in
> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
> subtitles can be forced as expected in VLC and similar players.
>
> Copy AVStream disposition to AVCodecContext and use to set
> DISPLAY_FLAG_ALL_SAMPLES_FORCED in movtextenc.c.
>
> Signed-off-by: facefunk
> ---
> fftools/ffmpeg_opt.c| 5 +
> libavcodec/avcodec.h| 16
> libavcodec/movtextenc.c | 41 -
> 3 files changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index e08455478f..d8ea1d4bc1 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -2244,6 +2244,11 @@ static int set_dispositions(OutputFile *of,
> AVFormatContext *ctx)
>
> if (ret < 0)
> return ret;
> +
> +// For output streams, copy stream disposition to the
> AVCodecContext
> +// object.
> +if(ost->enc_ctx)
> +ost->enc_ctx->stream_disposition = ost->st->disposition;
> }
> } else {
> // For each media type with more than one stream, find a suitable
> stream to
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index cb5c25bf63..eb11de0293 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -37,6 +37,8 @@
> #include "libavutil/pixfmt.h"
> #include "libavutil/rational.h"
>
> +#include "libavformat/avformat.h"
libavcodec should not depend on libavformat
> +
> #include "codec.h"
> #include "codec_desc.h"
> #include "codec_par.h"
> @@ -2054,6 +2056,20 @@ typedef struct AVCodecContext {
> * The decoder can then override during decoding as needed.
> */
> AVChannelLayout ch_layout;
> +
> +/**
> + * Stream disposition - a combination of AV_DISPOSITION_* flags from
> + * libavformat.
> + *
> + * Copied from the relevant AVStream object for codecs that need access
> to
> + * the stream disposition parameter, such as movtextenc.c which needs to
> + * read the AV_DISPOSITION_FORCED flag so it knows when to set forced
> + * subtitles.
> + *
> + * - encoding: Set by set_dispositions in ffmpeg_opt.c.
ffmpeg is one application that uses libavcodec.
libavcodec API should not really talk about ffmpeg doing this or that, thats
kind of odd
also, your patches dont contain a full name, thats ok if thats what you want
but if you want your full name in git then you may want to correct that
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 4/5] libswscale: Enable hscale_avx2 for all input sizes.
On Mon, Jul 18, 2022 at 09:54:39AM +0200, Alan Kelly wrote: > Hi Michael, > > I have tried to recreate this locally in a clean client applying the > patches as sent in the email thread. I have tried gcc and mingw and this > passes for me. Are you sure you applied both patches 3 & 4? If only patch 4 > is applied, then I get the error you have. ive retested, and i cannot reproduce, i think i had #4 & #5 not #3 and #4 applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato 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] RELEASE_NOTES: Based on the version from 5.0
On Mon, Jul 18, 2022 at 01:39:47PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2022-07-17 16:23:40) > > On Sun, Jul 17, 2022 at 10:43:02AM +0200, Jean-Baptiste Kempf wrote: > > > Maybe some highlights of this release? Like the biggest changes and > > > improvements? > > > > Isnt that what Changelog is already doing ? > > By tradition, only certain things get mentioned in Changelog, like new > codecs/(de)muxers/filters and such. Things like API changes, performance > improvements, or other significant changes that are not one of the > above, do not get mentioned. We might want to change that. i agree [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] libavutil: Correct number of parameters in flag type options documentation.
Signed-off-by: facefunk
---
libavutil/opt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 461b5d3b6b..f250579b29 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -175,8 +175,8 @@
* above, put the following into the child_opts array:
* @code
* { "test_flags", "This is a test option of flags type.",
- *offsetof(child_struct, flags_opt), AV_OPT_TYPE_FLAGS, { .i64 = 0 },
INT_MIN, INT_MAX, "test_unit" },
- * { "flag1", "This is a flag with value 16", 0, AV_OPT_TYPE_CONST, {
.i64 = 16 }, 0, 0, "test_unit" },
+ *offsetof(child_struct, flags_opt), AV_OPT_TYPE_FLAGS, { .i64 = 0 },
.unit = "test_unit" },
+ * { "flag1", "This is a flag with value 16", 0, AV_OPT_TYPE_CONST, {
.i64 = 16 }, .unit = "test_unit" },
* @endcode
*
* @section avoptions_use Using AVOptions
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] libavcodec: Correct typo in mov_text encoder class name.
Signed-off-by: facefunk
---
libavcodec/movtextenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index d2550585e8..6f54e2a64c 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -732,7 +732,7 @@ static const AVOption options[] = {
};
static const AVClass mov_text_encoder_class = {
-.class_name = "MOV text enoder",
+.class_name = "MOV text encoder",
.item_name = av_default_item_name,
.option = options,
.version= LIBAVUTIL_VERSION_INT,
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] libavcodec: Make disposition forced work with mov_text subtitles.
We are not currently able to force mov_text subtitles by setting
-disposition:s:0 +forced or equivalent. By setting the forced flags in
movtextenc as specifid in
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
subtitles can be forced as expected in VLC and similar players.
Copy AVStream disposition to AVCodecContext and use to set
DISPLAY_FLAG_ALL_SAMPLES_FORCED in movtextenc.c.
Signed-off-by: facefunk
---
fftools/ffmpeg_opt.c| 5 +
libavcodec/avcodec.h| 16
libavcodec/movtextenc.c | 41 -
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index e08455478f..d8ea1d4bc1 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2244,6 +2244,11 @@ static int set_dispositions(OutputFile *of,
AVFormatContext *ctx)
if (ret < 0)
return ret;
+
+// For output streams, copy stream disposition to the
AVCodecContext
+// object.
+if(ost->enc_ctx)
+ost->enc_ctx->stream_disposition = ost->st->disposition;
}
} else {
// For each media type with more than one stream, find a suitable
stream to
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index cb5c25bf63..eb11de0293 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -37,6 +37,8 @@
#include "libavutil/pixfmt.h"
#include "libavutil/rational.h"
+#include "libavformat/avformat.h"
+
#include "codec.h"
#include "codec_desc.h"
#include "codec_par.h"
@@ -2054,6 +2056,20 @@ typedef struct AVCodecContext {
* The decoder can then override during decoding as needed.
*/
AVChannelLayout ch_layout;
+
+/**
+ * Stream disposition - a combination of AV_DISPOSITION_* flags from
+ * libavformat.
+ *
+ * Copied from the relevant AVStream object for codecs that need access to
+ * the stream disposition parameter, such as movtextenc.c which needs to
+ * read the AV_DISPOSITION_FORCED flag so it knows when to set forced
+ * subtitles.
+ *
+ * - encoding: Set by set_dispositions in ffmpeg_opt.c.
+ * - decoding: unused
+ */
+int stream_disposition;
} AVCodecContext;
/**
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 728338f2cc..d2550585e8 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -50,6 +50,40 @@
#define FONTSIZE_SCALE(s,fs) ((fs) * (s)->font_scale_factor + 0.5)
#define av_bprint_append_any(buf, data, size) av_bprint_append_data(buf,
((const char*)data), size)
+/**
+ *
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html
+ *
+ * Display flags
+ * A 32-bit integer containing flags that describe how the subtitle text should
+ * be drawn.
+ * The following flags are defined:
+ *
+ * Vertical placement
+ * Controls vertical placement of the subtitle text.
+ * If this flag is set, the subtitle media handler uses the top coordinate of
+ * the display bounds of the override 'tbox' text box to determine the
+ * subtitle’s vertical placement as described in Subtitle Track Header Size
+ * and Placement. Otherwise, the subtitle displays at the bottom of the video.
+ */
+#define DISPLAY_FLAG_VERTICAL_PLACEMENT_TOP 0x2000
+
+/**
+ * Some samples are forced
+ * Indicates whether any subtitle samples contain forced atoms. If this flag is
+ * set, at least one sample contains a forced ('frcd') atom as described in
+ * Subtitle Sample Data.
+ */
+#define DISPLAY_FLAG_SOME_SAMPLES_FORCED0x4000
+
+/**
+ * All samples are forced
+ * If this flag is set, the subtitle media handler treats all samples as forced
+ * subtitles, regardless of the presence or absence of a 'frcd' atom.
+ * If this flag is set, the Some Samples Are Forced flag must also be set
+ * (making 0xC000).
+ */
+#define DISPLAY_FLAG_ALL_SAMPLES_FORCED 0x8000
+
typedef struct {
uint16_t style_start;
uint16_t style_end;
@@ -183,6 +217,7 @@ static int encode_sample_description(AVCodecContext *avctx)
int font_names_total_len = 0;
MovTextContext *s = avctx->priv_data;
uint8_t buf[30], *p = buf;
+uint32_t display_flags = 0;
// 0x00, 0x00, 0x00, 0x00, // uint32_t displayFlags
// 0x01, // int8_t horizontal-justification
@@ -241,7 +276,11 @@ static int encode_sample_description(AVCodecContext *avctx)
(255 - ((uint32_t)style->back_color >> 24));
}
-bytestream_put_be32(&p, 0); // displayFlags
+if (avctx->stream_disposition & AV_DISPOSITION_FORCED)
+display_flags = DISPLAY_FLAG_SOME_SAMPLES_FORCED |
+DISPLAY_FLAG_ALL_SAMPLES_FORCED;
+
+bytestream_put_be32(&p, display_flags); // displayFlags
bytestream_put_be16(&p, 0x01FF); // horizontal/vertical justification (2x
int8_t)
bytestream_put_be32(&p, back_color);
[FFmpeg-devel] Make disposition forced work with mov_text subtitles.
We are not currently able to force mov_text subtitles by setting -disposition:s:0 +forced or equivalent. By setting the forced flags in movtextenc as specifid in https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html subtitles can be forced as expected in VLC and similar players. ___ 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/pnmdec: Mark PHM decoder as init-threadsafe
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pnmdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
> index bb2ce53496..f012ed288b 100644
> --- a/libavcodec/pnmdec.c
> +++ b/libavcodec/pnmdec.c
> @@ -513,5 +513,6 @@ const FFCodec ff_phm_decoder = {
> .priv_data_size = sizeof(PNMContext),
> .init = phm_dec_init,
> FF_CODEC_DECODE_CB(pnm_decode_frame),
> +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
> };
> #endif
Will apply this patchset (with the obvious changes warranted by the new
hdr encoder) later tonight.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavfi/cropdetect: Add new mode to detect crop-area based on motion vectors and edges
Am 17.07.22 um 09:54 schrieb Thilo Borgmann:
Am 16.07.22 um 23:09 schrieb Thilo Borgmann:
Am 11.07.22 um 10:54 schrieb Thilo Borgmann:
$subject
v3.
v4.
v5 now with fixed docs.
-ThiloFrom c5962d580dd103d0b9cc08724a6863e62383da7b Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Mon, 18 Jul 2022 16:10:12 +0200
Subject: [PATCH v5 2/2] lavfi/cropdetect: Add new mode to detect crop-area
based on motion vectors and edges
This filter allows crop detection even if the video is embedded in non-black
areas.
---
doc/filters.texi | 53 +-
libavfilter/vf_cropdetect.c| 211 -
tests/fate/filter-video.mak| 8 +-
tests/ref/fate/filter-metadata-cropdetect1 | 9 +
tests/ref/fate/filter-metadata-cropdetect2 | 9 +
5 files changed, 287 insertions(+), 3 deletions(-)
create mode 100644 tests/ref/fate/filter-metadata-cropdetect1
create mode 100644 tests/ref/fate/filter-metadata-cropdetect2
diff --git a/doc/filters.texi b/doc/filters.texi
index d65e83d4d0..19db8e05aa 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10075,12 +10075,23 @@ Auto-detect the crop size.
It calculates the necessary cropping parameters and prints the
recommended parameters via the logging system. The detected dimensions
-correspond to the non-black area of the input video.
+correspond to the non-black or video area of the input video according to
@var{mode}.
It accepts the following parameters:
@table @option
+@item mode
+Depending on @var{mode} crop detection is based on either the mere black value
of surrounding pixels or a combination of motion vectors and edge pixels.
+
+@table @samp
+@item black
+Detect black pixels surrounding the playing video. For fine control use option
@var{limit}.
+
+@item mvedges
+Detect the playing video by the motion vectors inside the video and scanning
for edge pixels typically forming the border of a playing video.
+@end table
+
@item limit
Set higher black value threshold, which can be optionally specified
from nothing (0) to everything (255 for 8-bit based formats). An intensity
@@ -10106,8 +10117,48 @@ detect the current optimal crop area. Default value is
0.
This can be useful when channel logos distort the video area. 0
indicates 'never reset', and returns the largest area encountered during
playback.
+
+@item mv_threshold
+Set motion in pixel units as threshold for motion detection. It defaults to 8.
+
+@item low
+@item high
+Set low and high threshold values used by the Canny thresholding
+algorithm.
+
+The high threshold selects the "strong" edge pixels, which are then
+connected through 8-connectivity with the "weak" edge pixels selected
+by the low threshold.
+
+@var{low} and @var{high} threshold values must be chosen in the range
+[0,1], and @var{low} should be lesser or equal to @var{high}.
+
+Default value for @var{low} is @code{5/255}, and default value for @var{high}
+is @code{15/255}.
@end table
+@subsection Examples
+
+@itemize
+@item
+Find video area surrounded by black borders:
+@example
+ffmpeg -i file.mp4 -vf cropdetect,metadata=mode=print -f null -
+@end example
+
+@item
+Find an embedded video area, generate motion vectors beforehand:
+@example
+ffmpeg -i file.mp4 -vf mestimate,cropdetect=mode=mvedges,metadata=mode=print
-f null -
+@end example
+
+@item
+Find an embedded video area, use motion vectors from decoder:
+@example
+ffmpeg -flags2 +export_mvs -i file.mp4 -vf
cropdetect=mode=mvedges,metadata=mode=print -f null -
+@end example
+@end itemize
+
@anchor{cue}
@section cue
diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index b887b9ecb1..e920e671ab 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -26,11 +26,14 @@
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/motion_vector.h"
+#include "libavutil/qsort.h"
#include "avfilter.h"
#include "formats.h"
#include "internal.h"
#include "video.h"
+#include "edge_common.h"
typedef struct CropDetectContext {
const AVClass *class;
@@ -42,6 +45,16 @@ typedef struct CropDetectContext {
int frame_nb;
int max_pixsteps[4];
int max_outliers;
+int mode;
+int window_size;
+int mv_threshold;
+float low, high;
+uint8_t low_u8, high_u8;
+uint8_t *filterbuf;
+uint8_t *tmpbuf;
+uint16_t *gradients;
+char *directions;
+int *bboxes[4];
} CropDetectContext;
static const enum AVPixelFormat pix_fmts[] = {
@@ -61,6 +74,17 @@ static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_NONE
};
+enum CropMode {
+MODE_BLACK,
+MODE_MV_EDGES,
+MODE_NB
+};
+
+static int comp(const int *a,const int *b)
+{
+return FFDIFFSIGN(*a, *b);
+}
+
static int checkline(void *ctx, const unsigned char *src, int stride, int len,
int bpp)
{
int total = 0;
@@ -116,11 +140,43 @@ static int checkline(void *ctx, const unsigne
Re: [FFmpeg-devel] [PATCH v2 1/2] lavfi/edge_common: Add 16bit versions of gaussian_blur and sobel
Am 17.07.22 um 09:54 schrieb Thilo Borgmann:
Am 16.07.22 um 23:07 schrieb Thilo Borgmann:
Hi,
1/2 adds 16 bit versions of ff_gaussian_blur and ff_sobel.
2/2 adds new mode to cropdetect.
v3 does it the template way for 1/2 as requested on IRC.
v4 fixed bug in gaussian_blur. Otherwise identical.
v5 fixes minor things mentioned on IRC and another bug found on the way.
-ThiloFrom 74ed982d46acb980d97ec8ba969036504fdbe777 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Mon, 18 Jul 2022 16:09:46 +0200
Subject: [PATCH v5 1/2] lavfi/edge_common: Templatify ff_gaussian_blur and
ff_sobel
---
libavfilter/edge_common.c | 74 ++
libavfilter/edge_common.h | 22 ---
libavfilter/edge_template.c | 118
libavfilter/vf_blurdetect.c | 8 +--
libavfilter/vf_edgedetect.c | 14 ++---
5 files changed, 150 insertions(+), 86 deletions(-)
create mode 100644 libavfilter/edge_template.c
diff --git a/libavfilter/edge_common.c b/libavfilter/edge_common.c
index d72e8521cd..ebd47d7c53 100644
--- a/libavfilter/edge_common.c
+++ b/libavfilter/edge_common.c
@@ -46,33 +46,13 @@ static int get_rounded_direction(int gx, int gy)
return DIRECTION_VERTICAL;
}
-// Simple sobel operator to get rounded gradients
-void ff_sobel(int w, int h,
-uint16_t *dst, int dst_linesize,
-int8_t *dir, int dir_linesize,
-const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-for (j = 1; j < h - 1; j++) {
-dst += dst_linesize;
-dir += dir_linesize;
-src += src_linesize;
-for (i = 1; i < w - 1; i++) {
-const int gx =
--1*src[-src_linesize + i-1] + 1*src[-src_linesize + i+1]
--2*src[i-1] + 2*src[i+1]
--1*src[ src_linesize + i-1] + 1*src[ src_linesize + i+1];
-const int gy =
--1*src[-src_linesize + i-1] + 1*src[ src_linesize + i-1]
--2*src[-src_linesize + i ] + 2*src[ src_linesize + i ]
--1*src[-src_linesize + i+1] + 1*src[ src_linesize + i+1];
+#undef DEPTH
+#define DEPTH 8
+#include "edge_template.c"
-dst[i] = FFABS(gx) + FFABS(gy);
-dir[i] = get_rounded_direction(gx, gy);
-}
-}
-}
+#undef DEPTH
+#define DEPTH 16
+#include "edge_template.c"
// Filters rounded gradients to drop all non-maxima
// Expects gradients generated by ff_sobel()
@@ -137,45 +117,3 @@ void ff_double_threshold(int low, int high, int w, int h,
src += src_linesize;
}
}
-
-// Applies gaussian blur, using 5x5 kernels, sigma = 1.4
-void ff_gaussian_blur(int w, int h,
- uint8_t *dst, int dst_linesize,
- const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-for (j = 2; j < h - 2; j++) {
-dst[0] = src[0];
-dst[1] = src[1];
-for (i = 2; i < w - 2; i++) {
-/* Gaussian mask of size 5x5 with sigma = 1.4 */
-dst[i] = ((src[-2*src_linesize + i-2] + src[2*src_linesize + i-2])
* 2
-+ (src[-2*src_linesize + i-1] + src[2*src_linesize + i-1])
* 4
-+ (src[-2*src_linesize + i ] + src[2*src_linesize + i ])
* 5
-+ (src[-2*src_linesize + i+1] + src[2*src_linesize + i+1])
* 4
-+ (src[-2*src_linesize + i+2] + src[2*src_linesize + i+2])
* 2
-
-+ (src[ -src_linesize + i-2] + src[ src_linesize + i-2])
* 4
-+ (src[ -src_linesize + i-1] + src[ src_linesize + i-1])
* 9
-+ (src[ -src_linesize + i ] + src[ src_linesize + i ])
* 12
-+ (src[ -src_linesize + i+1] + src[ src_linesize + i+1])
* 9
-+ (src[ -src_linesize + i+2] + src[ src_linesize + i+2])
* 4
-
-+ src[i-2] * 5
-+ src[i-1] * 12
-+ src[i ] * 15
-+ src[i+1] * 12
-+ src[i+2] * 5) / 159;
-}
-dst[i] = src[i];
-dst[i + 1] = src[i + 1];
-
-dst += dst_linesize;
-src += src_linesize;
-}
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-memcpy(dst, src, w);
-}
diff --git a/libavfilter/edge_common.h b/libavfilter/edge_common.h
index 87c143f2b8..cff4febd70 100644
--- a/libavfilter/edge_common.h
+++ b/libavfilter/edge_common.h
@@ -48,10 +48,14 @@ enum AVRoundedDirection {
* @param src data pointers to source image
* @param src_linesize linesizes for the source image
*/
-void ff_sobel(int w, int h,
- uint16_t *dst, int dst_linesize,
- int8_t *dir, int dir_linesize,
- const uint8_t *src, int src_linesize);
+#define PROT
Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present
James Almer:
> On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Should fix ticket #3361
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> This also needs an update to some fate ref samples i'll upload before
>>> pushing
>>> (fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now
>>> decoded
>>> properly as he_aac mono, so the .s16 files need to be replaced).
>>>
>>
>> We have both a fixed-point AAC as well as a floating point AAC decoder.
>> Is there actually a test that tests that the output they produce is
>> reasonably close? If not, could we make the test so that the same file
>> is decoded once with the fixed-point and once with the floating-point
>> decoder and then compared?
>
> That wouldn't help much, i think. Almost all changes to *_template.c
> files are going to affect both decoders, so a breakage would not be
> detected if you compare their output with each other as they would both
> exhibit it.
>
I actually thought that the aac_fixed tests used checksums instead of
ref files; then changes and breakages would be visible by changes to
these files. Apparently I was wrong about that and the ref files are
used for both aac and aac_fixed. But a test like the one outlined above
would nevertheless obviate the need for a new ref file.
>>
>>> libavcodec/aacdec_template.c | 15 ++-
>>> libavcodec/aacsbr_template.c | 1 +
>>> tests/fate/gapless.mak | 14 +++---
>>> .../audiomatch-afconvert-16000-stereo-he2-adts | 2 +-
>>> 4 files changed, 15 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>>> index 10fba3d3b2..15c20c07d6 100644
>>> --- a/libavcodec/aacdec_template.c
>>> +++ b/libavcodec/aacdec_template.c
>>> @@ -967,8 +967,7 @@ static int decode_ga_specific_config(AACContext
>>> *ac, AVCodecContext *avctx,
>>> if (count_channels(layout_map, tags) > 1) {
>>> m4ac->ps = 0;
>>> - } else if (m4ac->sbr == 1 && m4ac->ps == -1)
>>> - m4ac->ps = 1;
>>> + }
>>> if (ac && (ret = output_configure(ac, layout_map, tags,
>>> OC_GLOBAL_HDR, 0)))
>>> return ret;
>>> @@ -2572,18 +2571,16 @@ static int
>>> decode_extension_payload(AACContext *ac, GetBitContext *gb, int cnt,
>>> av_log(ac->avctx, AV_LOG_ERROR, "Implicit SBR was found
>>> with a first occurrence after the first frame.\n");
>>> skip_bits_long(gb, 8 * cnt - 4);
>>> return res;
>>> - } else if (ac->oc[1].m4ac.ps == -1 && ac->oc[1].status <
>>> OC_LOCKED &&
>>> - ac->avctx->ch_layout.nb_channels == 1) {
>>> - ac->oc[1].m4ac.sbr = 1;
>>> - ac->oc[1].m4ac.ps = 1;
>>> - ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
>>> - output_configure(ac, ac->oc[1].layout_map,
>>> ac->oc[1].layout_map_tags,
>>> - ac->oc[1].status, 1);
>>> } else {
>>> ac->oc[1].m4ac.sbr = 1;
>>> ac->avctx->profile = FF_PROFILE_AAC_HE;
>>> }
>>> res = AAC_RENAME(ff_decode_sbr_extension)(ac, &che->sbr,
>>> gb, crc_flag, cnt, elem_type);
>>> + if (ac->oc[1].m4ac.ps == 1 && ac->oc[1].status < OC_LOCKED &&
>>> + ac->avctx->ch_layout.nb_channels == 1) {
>>> + output_configure(ac, ac->oc[1].layout_map,
>>> ac->oc[1].layout_map_tags,
>>> + ac->oc[1].status, 1);
>>> + }
>>> break;
>>> case EXT_DYNAMIC_RANGE:
>>> res = decode_dynamic_range(&ac->che_drc, gb);
>>> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
>>> index b72c94b76d..f9925b40e5 100644
>>> --- a/libavcodec/aacsbr_template.c
>>> +++ b/libavcodec/aacsbr_template.c
>>> @@ -954,6 +954,7 @@ static void read_sbr_extension(AACContext *ac,
>>> SpectralBandReplication *sbr,
>>> *num_bits_left = 0;
>>> } else {
>>> *num_bits_left -= ff_ps_read_data(ac->avctx, gb,
>>> &sbr->ps.common, *num_bits_left);
>>> + ac->oc[1].m4ac.ps = 1;
>>> ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
>>> }
>>> break;
>>> diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
>>> index 68a396e187..7dd8ceb142 100644
>>> --- a/tests/fate/gapless.mak
>>> +++ b/tests/fate/gapless.mak
>>> @@ -47,27 +47,27 @@ fate-audiomatch-square-aac: CMD = audio_match
>>> $(TARGET_SAMPLES)/audiomatch/squar
>>> fate-audiomatch-afconvert-16000-mono-lc-adts: CMD = audio_match
>>> $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts
>>> $(SAMPLES)/audiomatch/tones_16000_mono.wav
>>> fate-audiomatch-afconvert-16000-mono-lc-m4a: CMD = audio_match
>>> $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.m4a
>>> $(SAMPLES)/audiomatch/tones_16000_mono.wav
>>> -fate-audiomatch-afconvert-16000-mono-he-adts: CMD = audio_match
>>> $(TARGET_SA
Re: [FFmpeg-devel] [PATCH 1/2] avformat/argo_cvg: name unk{1, 2} fields correctly
Zane van Iperen:
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_cvg.c | 33 +
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/libavformat/argo_cvg.c b/libavformat/argo_cvg.c
> index f32487023a..2ee4a64449 100644
> --- a/libavformat/argo_cvg.c
> +++ b/libavformat/argo_cvg.c
> @@ -40,9 +40,9 @@
> #define ARGO_CVG_SAMPLES_PER_BLOCK 28
>
> typedef struct ArgoCVGHeader {
> -uint32_t size; /*< File size -8 (this + trailing checksum) */
> -uint32_t unk1; /*< Unknown. Always seems to be 0 or 1. */
> -uint32_t unk2; /*< Unknown. Always seems to be 0 or 1. */
> +uint32_t size; /*< File size -8 (this + trailing checksum) */
> +uint32_t loop; /*< Loop flag. */
> +uint32_t reverb; /*< Reverb flag. */
> } ArgoCVGHeader;
>
> typedef struct ArgoCVGOverride {
> @@ -91,17 +91,17 @@ static int argo_cvg_probe(const AVProbeData *p)
> if (p->buf_size < ARGO_CVG_HEADER_SIZE)
> return 0;
>
> -cvg.size = AV_RL32(p->buf + 0);
> -cvg.unk1 = AV_RL32(p->buf + 4);
> -cvg.unk2 = AV_RL32(p->buf + 8);
> +cvg.size = AV_RL32(p->buf + 0);
> +cvg.loop = AV_RL32(p->buf + 4);
> +cvg.reverb = AV_RL32(p->buf + 8);
>
> if (cvg.size < 8)
> return 0;
>
> -if (cvg.unk1 != 0 && cvg.unk1 != 1)
> +if (cvg.loop != 0 && cvg.loop != 1)
> return 0;
>
> -if (cvg.unk2 != 0 && cvg.unk2 != 1)
> +if (cvg.reverb != 0 && cvg.reverb != 1)
> return 0;
>
> return AVPROBE_SCORE_MAX / 4 + 1;
> @@ -150,15 +150,16 @@ static int argo_cvg_read_header(AVFormatContext *s)
> else if (ret != ARGO_CVG_HEADER_SIZE)
> return AVERROR(EIO);
>
> -ctx->header.size = AV_RL32(buf + 0);
> -ctx->header.unk1 = AV_RL32(buf + 4);
> -ctx->header.unk2 = AV_RL32(buf + 8);
> +ctx->header.size = AV_RL32(buf + 0);
> +ctx->header.loop = AV_RL32(buf + 4);
> +ctx->header.reverb = AV_RL32(buf + 8);
>
> if (ctx->header.size < 8)
> return AVERROR_INVALIDDATA;
>
> av_log(s, AV_LOG_TRACE, "size = %u\n", ctx->header.size);
> -av_log(s, AV_LOG_TRACE, "unk= %u, %u\n", ctx->header.unk1,
> ctx->header.unk2);
> +av_log(s, AV_LOG_TRACE, "loop = %u\n", ctx->header.loop);
> +av_log(s, AV_LOG_TRACE, "reverb = %u\n", ctx->header.reverb);
%u is for unsigned, yet these variables are of type uint32_t. It is not
guaranteed that these two types are the same (yet they typically are).
That's why the PRI-macros exist.
(Apart from that: Does this have to be three separate av_logs?)
>
> if ((ret = argo_cvg_read_checksum(s->pb, &ctx->header, &ctx->checksum))
> < 0)
> return ret;
> @@ -172,10 +173,10 @@ static int argo_cvg_read_header(AVFormatContext *s)
>
> for (size_t i = 0; i < FF_ARRAY_ELEMS(overrides); i++) {
> const ArgoCVGOverride *ovr = overrides + i;
> -if (ovr->header.size != ctx->header.size ||
> -ovr->header.unk1 != ctx->header.unk1 ||
> -ovr->header.unk2 != ctx->header.unk2 ||
> -ovr->checksum!= ctx->checksum||
> +if (ovr->header.size != ctx->header.size ||
> +ovr->header.loop != ctx->header.loop ||
> +ovr->header.reverb != ctx->header.reverb ||
> +ovr->checksum != ctx->checksum||
> av_strcasecmp(filename, ovr->name) != 0)
> continue;
>
___
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 v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
Quoting Xiang, Haihao (2022-07-12 08:27:32)
> +static int qsv_va_update_config(void *ctx, mfxHDL handle, mfxConfig cfg)
> +{
> +#if CONFIG_VAAPI
> +#if VA_CHECK_VERSION(1, 5, 0)
> +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> +#else
> +#define LOCAL_VADISPLAYPCIID 21
> +#endif
> +mfxStatus sts;
> +VADisplay dpy = handle;
> +VAStatus vas;
> +VADisplayAttribute attr = {
> +.type = LOCAL_VADISPLAYPCIID
> +};
> +mfxVariant impl_value;
> +
> +vas = vaGetDisplayAttributes(dpy, &attr, 1);
> +if (vas == VA_STATUS_SUCCESS && attr.flags !=
> VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> +impl_value.Type = MFX_VARIANT_TYPE_U16;
> +impl_value.Data.U16 = (attr.value & 0x);
> +sts = MFXSetConfigFilterProperty(cfg,
> + (const mfxU8
> *)"mfxExtendedDeviceId.DeviceID", impl_value);
> +if (sts != MFX_ERR_NONE) {
> +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration"
> + "DeviceID property: %d.\n", sts);
> +goto fail;
> +}
> +} else
> +av_log(ctx, AV_LOG_WARNING, "Cannot get device id from the driver,
> the default "
> + "MFX implementation will be loaded for this device. Please
> consider to "
> + "upgrade the driver to support VAAPI 1.5.0. \n");
I would still prefer to fail here. The user requested a specific device,
disregarding that request is evil.
--
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 2/4] lavc: add API for exporting reconstructed frames from encoders
On 7/17/2022 4:26 PM, Anton Khirnov wrote:
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 1f39ab1a2f..f15309ce09 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -594,6 +594,18 @@ int ff_encode_preinit(AVCodecContext *avctx)
return AVERROR(ENOMEM);
}
+if ((avctx->flags & AV_CODEC_FLAG_RECON_FRAME)) {
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_ENCODER_RECON_FRAME)) {
+av_log(avctx, AV_LOG_ERROR, "Reconstructed frame output requested "
+ "from an encoder not supporting it\n");
+return AVERROR(ENOSYS);
+}
+
+avci->recon_frame = av_frame_alloc();
+if (!avci->recon_frame)
+return AVERROR(ENOMEM);
+}
+
return 0;
}
@@ -630,3 +642,16 @@ int ff_encode_alloc_frame(AVCodecContext *avctx, AVFrame *frame)
return 0;
}
+
+int ff_encode_receive_frame(AVCodecContext *avctx, AVFrame *frame)
+{
+AVCodecInternal *avci = avctx->internal;
+
+if (!avci->recon_frame)
+return AVERROR(EINVAL);
+if (!avci->recon_frame->buf[0])
+return avci->draining_done ? AVERROR_EOF : AVERROR(EAGAIN);
+
+av_frame_move_ref(frame, avci->recon_frame);
The API for avcodec_receive_frame() mentions frame will be unref'd first
thing, so you should do that before even the recon_frame checks.
+return 0;
+}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavu/frame: allow calling av_frame_make_writable() on non-refcounted frames
On 7/17/2022 4:26 PM, Anton Khirnov wrote: This is an easy way to make a refcounted frame from a non-refcounted one. --- doc/APIchanges | 5 + libavutil/frame.c | 3 --- libavutil/frame.h | 3 ++- libavutil/version.h | 2 +- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index f9a1484bbc..4e218af94e 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -14,6 +14,11 @@ libavutil: 2021-04-27 API changes, most recent first: +2022-07-xx - xx - lavu 57.30.100 - frame.h + av_frame_make_writable() may now be called on non-refcounted + frames and will make a refcounted copy out of them. + Previously an error was returned in such cases. + 8< - FFmpeg 5.1 was cut here 8< - 2022-06-12 - 7cae3d8b76 - lavf 59.25.100 - avio.h diff --git a/libavutil/frame.c b/libavutil/frame.c index 4c16488c66..7408817e1f 100644 --- a/libavutil/frame.c +++ b/libavutil/frame.c @@ -542,9 +542,6 @@ int av_frame_make_writable(AVFrame *frame) AVFrame tmp; int ret; -if (!frame->buf[0]) -return AVERROR(EINVAL); - if (av_frame_is_writable(frame)) return 0; diff --git a/libavutil/frame.h b/libavutil/frame.h index 33fac2054c..cc55d67e3c 100644 --- a/libavutil/frame.h +++ b/libavutil/frame.h @@ -818,7 +818,8 @@ int av_frame_is_writable(AVFrame *frame); * Ensure that the frame data is writable, avoiding data copy if possible. * * Do nothing if the frame is writable, allocate new buffers and copy the data - * if it is not. + * if it is not. Non-refcounted frames behave as non-writable, i.e. a copy + * is always made. * * @return 0 on success, a negative AVERROR on error. * diff --git a/libavutil/version.h b/libavutil/version.h index f185322550..734d3f8330 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 57 -#define LIBAVUTIL_VERSION_MINOR 29 +#define LIBAVUTIL_VERSION_MINOR 30 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
On 7/18/2022 4:12 AM, Anton Khirnov wrote:
---
libavcodec/libx264.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 98ec030865..5e360682e6 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
pic->extra_sei.num_payloads = 0;
}
+static enum AVPixelFormat csp_to_pixfmt(int csp)
+{
+switch (csp) {
+#ifdef X264_CSP_I400
+case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
+case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
+#endif
+case X264_CSP_I420: return AV_PIX_FMT_YUV420P;
+case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV420P10;
+case X264_CSP_I422: return AV_PIX_FMT_YUV422P;
+case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV422P10;
+case X264_CSP_I444: return AV_PIX_FMT_YUV444P;
+case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV444P10;
We're still supporting old x264 versions, so you should add some
considerations for 9 bit pixfmts. On X264_BUILD < 153, just check the
value of x264_bit_depth.
+case X264_CSP_NV12: return AV_PIX_FMT_NV12;
+case X264_CSP_NV16: return AV_PIX_FMT_NV16;
Missing X264_CSP_NV21 (wrapped like X264_CSP_I400).
That aside, LGTM.
+};
+return AV_PIX_FMT_NONE;
+}
+
static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, const AVFrame
*frame,
int *got_packet)
{
@@ -496,6 +515,33 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL,
&pic_out) < 0)
return AVERROR_EXTERNAL;
+if (nnal && (ctx->flags & AV_CODEC_FLAG_RECON_FRAME)) {
+AVCodecInternal *avci = ctx->internal;
+
+av_frame_unref(avci->recon_frame);
+
+avci->recon_frame->format = csp_to_pixfmt(pic_out.img.i_csp);
+if (avci->recon_frame->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unhandled reconstructed frame colorspace: %d\n",
+ pic_out.img.i_csp);
+return AVERROR(ENOSYS);
+}
+
+avci->recon_frame->width = ctx->width;
+avci->recon_frame->height = ctx->height;
+for (int i = 0; i < pic_out.img.i_plane; i++) {
+avci->recon_frame->data[i] = pic_out.img.plane[i];
+avci->recon_frame->linesize[i] = pic_out.img.i_stride[i];
+}
+
+ret = av_frame_make_writable(avci->recon_frame);
+if (ret < 0) {
+av_frame_unref(avci->recon_frame);
+return ret;
+}
+}
+
ret = encode_nals(ctx, pkt, nal, nnal);
if (ret < 0)
return ret;
@@ -928,6 +974,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
x4->params.b_repeat_headers = 0;
+if (avctx->flags & AV_CODEC_FLAG_RECON_FRAME)
+x4->params.b_full_recon = 1;
+
if(x4->x264opts){
const char *p= x4->x264opts;
while(p){
@@ -1223,7 +1272,8 @@ FFCodec ff_libx264_encoder = {
.p.id = AV_CODEC_ID_H264,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS |
-AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+AV_CODEC_CAP_ENCODER_RECON_FRAME,
.p.priv_class = &x264_class,
.p.wrapper_name = "libx264",
.priv_data_size = sizeof(X264Context),
___
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] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration
Quoting James Almer (2022-07-18 13:49:18) > On 7/18/2022 4:34 AM, Anton Khirnov wrote: > > diff --git a/tests/ref/fate/exif-image-jpg b/tests/ref/fate/exif-image-jpg > > index b942fc5a7b..2d5fe18d61 100644 > > --- a/tests/ref/fate/exif-image-jpg > > +++ b/tests/ref/fate/exif-image-jpg > > @@ -10,6 +10,8 @@ best_effort_timestamp=0 > > best_effort_timestamp_time=0.00 > > pkt_duration=1 > > pkt_duration_time=0.04 > > +duration=1 > > +duration_time=0.04 > > pkt_pos=N/A > > pkt_size=46095 > > width=400 > > @@ -27,30 +29,30 @@ color_space=bt470bg > > color_primaries=unknown > > color_transfer=unknown > > chroma_location=center > > -TAG:ImageDescription= > > +TAG:ImageDescription= > > TAG:Make=Canon > > TAG:Model=Canon PowerShot SX200 IS > > TAG:Orientation=1 > > -TAG:XResolution=180:1 > > -TAG:YResolution=180:1 > > +TAG:XResolution=180:1 > > +TAG:YResolution=180:1 > > TAG:ResolutionUnit=2 > > TAG:DateTime=2013:07:18 13:12:03 > > TAG:YCbCrPositioning=2 > > -TAG:ExposureTime= 1:1250 > > -TAG:FNumber= 40:10 > > +TAG:ExposureTime= 1:1250 > > +TAG:FNumber= 40:10 > > TAG:ISOSpeedRatings= 160 > > TAG:ExifVersion= 48, 50, 50, 49 > > TAG:DateTimeOriginal=2013:07:18 13:12:03 > > TAG:DateTimeDigitized=2013:07:18 13:12:03 > > TAG:ComponentsConfiguration= 1, 2, 3, 0 > > -TAG:CompressedBitsPerPixel= 3:1 > > -TAG:ShutterSpeedValue=329:32 > > -TAG:ApertureValue=128:32 > > -TAG:ExposureBiasValue= 0:3 > > -TAG:MaxApertureValue=113:32 > > +TAG:CompressedBitsPerPixel= 3:1 > > +TAG:ShutterSpeedValue=329:32 > > +TAG:ApertureValue=128:32 > > +TAG:ExposureBiasValue= 0:3 > > +TAG:MaxApertureValue=113:32 > > TAG:MeteringMode=5 > > TAG:Flash= 16 > > -TAG:FocalLength= 5000:1000 > > +TAG:FocalLength= 5000:1000 > > TAG:MakerNote= > >25, 0, 1, 0, 3, 0, 48, 0, 0, 0, 28, 4, 0, 0, > > 2, 0 > > 3, 0, 4, 0, 0, 0, 124, 4, 0, 0, 3, 0, 3, 0, > > 4, 0 > > This and exif-image-webp got a lot of suspicious changes, adding > trailing whitespaces to several lines. That whitespace is actually present in the tags exported from lavc. Don't know why it wasn't present in the refs before. -- 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] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration
On 7/18/2022 4:34 AM, Anton Khirnov wrote: diff --git a/tests/ref/fate/exif-image-jpg b/tests/ref/fate/exif-image-jpg index b942fc5a7b..2d5fe18d61 100644 --- a/tests/ref/fate/exif-image-jpg +++ b/tests/ref/fate/exif-image-jpg @@ -10,6 +10,8 @@ best_effort_timestamp=0 best_effort_timestamp_time=0.00 pkt_duration=1 pkt_duration_time=0.04 +duration=1 +duration_time=0.04 pkt_pos=N/A pkt_size=46095 width=400 @@ -27,30 +29,30 @@ color_space=bt470bg color_primaries=unknown color_transfer=unknown chroma_location=center -TAG:ImageDescription= +TAG:ImageDescription= TAG:Make=Canon TAG:Model=Canon PowerShot SX200 IS TAG:Orientation=1 -TAG:XResolution=180:1 -TAG:YResolution=180:1 +TAG:XResolution=180:1 +TAG:YResolution=180:1 TAG:ResolutionUnit=2 TAG:DateTime=2013:07:18 13:12:03 TAG:YCbCrPositioning=2 -TAG:ExposureTime= 1:1250 -TAG:FNumber= 40:10 +TAG:ExposureTime= 1:1250 +TAG:FNumber= 40:10 TAG:ISOSpeedRatings= 160 TAG:ExifVersion= 48, 50, 50, 49 TAG:DateTimeOriginal=2013:07:18 13:12:03 TAG:DateTimeDigitized=2013:07:18 13:12:03 TAG:ComponentsConfiguration= 1, 2, 3, 0 -TAG:CompressedBitsPerPixel= 3:1 -TAG:ShutterSpeedValue=329:32 -TAG:ApertureValue=128:32 -TAG:ExposureBiasValue= 0:3 -TAG:MaxApertureValue=113:32 +TAG:CompressedBitsPerPixel= 3:1 +TAG:ShutterSpeedValue=329:32 +TAG:ApertureValue=128:32 +TAG:ExposureBiasValue= 0:3 +TAG:MaxApertureValue=113:32 TAG:MeteringMode=5 TAG:Flash= 16 -TAG:FocalLength= 5000:1000 +TAG:FocalLength= 5000:1000 TAG:MakerNote= 25, 0, 1, 0, 3, 0, 48, 0, 0, 0, 28, 4, 0, 0, 2, 0 3, 0, 4, 0, 0, 0, 124, 4, 0, 0, 3, 0, 3, 0, 4, 0 This and exif-image-webp got a lot of suspicious changes, adding trailing whitespaces to several lines. ___ 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] add HDR image format test coverage
On Mon, Jul 18, 2022 at 1:16 PM Anton Khirnov wrote: > Quoting Paul B Mahol (2022-07-17 16:51:20) > > Patch attached. > > > > From 7080795a572f8f741d4a00b2db02c8e00ce6aaf2 Mon Sep 17 00:00:00 2001 > > From: Paul B Mahol > > Date: Sun, 17 Jul 2022 15:12:12 +0200 > > Subject: [PATCH] fate: add Radiance HDR image test > > > > Signed-off-by: Paul B Mahol > > --- > > tests/fate/lavf-image.mak | 1 + > > tests/ref/lavf/hdr| 3 +++ > > 2 files changed, 4 insertions(+) > > create mode 100644 tests/ref/lavf/hdr > > > > diff --git a/tests/fate/lavf-image.mak b/tests/fate/lavf-image.mak > > index 38d3689abf..6a87ad25a4 100644 > > --- a/tests/fate/lavf-image.mak > > +++ b/tests/fate/lavf-image.mak > > @@ -52,6 +52,7 @@ FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += > rgb8.xwd > > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += rgb4_byte.xwd > > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += gray.xwd > > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += monow.xwd > > +FATE_LAVF_IMAGES-$(call LAVF_IMAGES, HDR) += hdr > > > > FATE_LAVF_IMAGES = $(FATE_LAVF_IMAGES-yes:%=fate-lavf-%) > > > > diff --git a/tests/ref/lavf/hdr b/tests/ref/lavf/hdr > > new file mode 100644 > > index 00..129c309197 > > --- /dev/null > > +++ b/tests/ref/lavf/hdr > > @@ -0,0 +1,3 @@ > > +95961d2136160b39d71858305226f5f2 *tests/data/images/hdr/02.hdr > > +tests/data/images/hdr/%02d.hdr CRC=0x1a5ee73b > > +326788 tests/data/images/hdr/02.hdr > > -- > > 2.36.1 > > The codec seems to be floating point, will this be bitexact everywhere? > > Look at results on patchwork. > -- > 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] RELEASE_NOTES: Based on the version from 5.0
Quoting Michael Niedermayer (2022-07-17 16:23:40) > On Sun, Jul 17, 2022 at 10:43:02AM +0200, Jean-Baptiste Kempf wrote: > > Maybe some highlights of this release? Like the biggest changes and > > improvements? > > Isnt that what Changelog is already doing ? By tradition, only certain things get mentioned in Changelog, like new codecs/(de)muxers/filters and such. Things like API changes, performance improvements, or other significant changes that are not one of the above, do not get mentioned. We might want to change that. -- 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] swscale: add NV16 input/output
Quoting Michael Niedermayer (2022-07-14 20:09:54) > On Fri, Jul 01, 2022 at 10:08:14AM +0200, Matthieu Bouron wrote: > > On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer > > wrote: > > > > > On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote: > > > > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote: > > > > > > --- > > > > > > libswscale/input.c | 1 + > > > > > > libswscale/utils.c | 1 + > > > > > > libswscale/version.h | 2 +- > > > > > > tests/ref/fate/filter-pixdesc-nv16 | 1 + > > > > > > tests/ref/fate/filter-pixfmts-copy | 1 + > > > > > > tests/ref/fate/filter-pixfmts-crop | 1 + > > > > > > tests/ref/fate/filter-pixfmts-field | 1 + > > > > > > tests/ref/fate/filter-pixfmts-fieldorder | 1 + > > > > > > tests/ref/fate/filter-pixfmts-hflip | 1 + > > > > > > tests/ref/fate/filter-pixfmts-il | 1 + > > > > > > tests/ref/fate/filter-pixfmts-null | 1 + > > > > > > tests/ref/fate/filter-pixfmts-pad| 1 + > > > > > > tests/ref/fate/filter-pixfmts-scale | 1 + > > > > > > tests/ref/fate/filter-pixfmts-vflip | 1 + > > > > > > 14 files changed, 14 insertions(+), 1 deletion(-) > > > > > > create mode 100644 tests/ref/fate/filter-pixdesc-nv16 > > > > > > > > > > > > > > Sorry for the late reply > > > > > > > > > > > > > has this been tested ? (various scaled and non scaled) variants ? > > > > > > > > > > > > > I only tested the non scaled variant using the command line doing > > > multiple > > > > round trips to/from nv16. > > > > Is there a particular test procedure to validate every variants ? > > > > > > you can test manually or use something like > > > libswscale/tests/swscale.c > > > > > > > I manually tested without any issue: il, field, fieldorder, copy, crop, > > hflip, null, pad, scale and vflip. > > if that included up & down scaling while changing format then it should be ok Seems to work for me. Will push soonish if nobody objects. -- 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] add HDR image format test coverage
Quoting Paul B Mahol (2022-07-17 16:51:20) > Patch attached. > > From 7080795a572f8f741d4a00b2db02c8e00ce6aaf2 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Sun, 17 Jul 2022 15:12:12 +0200 > Subject: [PATCH] fate: add Radiance HDR image test > > Signed-off-by: Paul B Mahol > --- > tests/fate/lavf-image.mak | 1 + > tests/ref/lavf/hdr| 3 +++ > 2 files changed, 4 insertions(+) > create mode 100644 tests/ref/lavf/hdr > > diff --git a/tests/fate/lavf-image.mak b/tests/fate/lavf-image.mak > index 38d3689abf..6a87ad25a4 100644 > --- a/tests/fate/lavf-image.mak > +++ b/tests/fate/lavf-image.mak > @@ -52,6 +52,7 @@ FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += > rgb8.xwd > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += rgb4_byte.xwd > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += gray.xwd > FATE_LAVF_IMAGES-$(call LAVF_IMAGES, XWD) += monow.xwd > +FATE_LAVF_IMAGES-$(call LAVF_IMAGES, HDR) += hdr > > FATE_LAVF_IMAGES = $(FATE_LAVF_IMAGES-yes:%=fate-lavf-%) > > diff --git a/tests/ref/lavf/hdr b/tests/ref/lavf/hdr > new file mode 100644 > index 00..129c309197 > --- /dev/null > +++ b/tests/ref/lavf/hdr > @@ -0,0 +1,3 @@ > +95961d2136160b39d71858305226f5f2 *tests/data/images/hdr/02.hdr > +tests/data/images/hdr/%02d.hdr CRC=0x1a5ee73b > +326788 tests/data/images/hdr/02.hdr > -- > 2.36.1 The codec seems to be floating point, will this be bitexact everywhere? -- 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 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
Quoting p...@sandflow.com (2022-07-13 00:34:12) > +dst->index = src->index; This should probably not be copied. -- 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] Development opportunity: LTC noise on files created from videotape source: filter idea
Hi FFMPEG developers, I have a proposal for a paid development opportunity to add a filter to FFMPEG. I followed the advice on the FFMPEG Consulting page at https://ffmpeg.org/consulting.html and am emailing this list to try to identify if any of the FFMPEG developers may be able to take on a development commission. Background: we are digitising high volumes of videotape carriers, and have identified a common case in some videotape formats where Linear Time Code from the tape carrier is present on audio stream 1 in the encoded file - manifesting as a continuous noise. Idea: could a filter be developed in FFMPEG, based on example files we can provide, to identify the presence of an LTC-derived audio stream, and additionally identify which of the streams is the LTC stream. If this filter idea sounds achievable, I would aim to identify which of the FFMPEG developers may be able to take on this work, and estimated costs and timeline. All the best, Stephen The British Film Institute is governed by Royal Charter and is a charity registered in England and Wales number 287780. The contents of this e-mail are confidential and may be legally privileged. If you are not the intended recipient, kindly notify the sender that you have received this message in error and immediately delete it. Unless you are the intended recipient, you may not forward this e-mail to anybody, nor make any use of its contents. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/4] lavc/hevc_refs: fix dpb logical for IRAP
On Fri, 2022-07-15 at 13:06 +0800, Fei Wang wrote:
> From: Xu Guangxin
>
> According to C.5.2.2, item 2. When we got an IRAP, and the
> NoOutputOfPriorPicsFlag = 0, we need bump all outputable frames.
>
> Tested-by: Fei Wang
> Signed-off-by: Xu Guangxin
> ---
> update:
> 1. clean and replace 0xff with HEVC_SEQUENCE_COUNTER_MASK
>
> libavcodec/hevc_refs.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 6a70c817b0..2b0468d6c4 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -175,21 +175,24 @@ int ff_hevc_set_new_ref(HEVCContext *s, AVFrame **frame,
> int poc)
>
> int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int flush)
> {
> +if (IS_IRAP(s) && s->no_rasl_output_flag == 1) {
> +const static int mask = HEVC_FRAME_FLAG_BUMPING |
> HEVC_FRAME_FLAG_OUTPUT;
> +for (int i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> +HEVCFrame *frame = &s->DPB[i];
> +if ((frame->flags & mask) == HEVC_FRAME_FLAG_OUTPUT &&
> +frame->sequence != s->seq_decode) {
> +if (s->sh.no_output_of_prior_pics_flag == 1)
> +ff_hevc_unref_frame(s, frame, HEVC_FRAME_FLAG_OUTPUT);
> +else
> +frame->flags |= HEVC_FRAME_FLAG_BUMPING;
> +}
> +}
> +}
> do {
> int nb_output = 0;
> int min_poc = INT_MAX;
> int i, min_idx, ret;
>
> -if (s->sh.no_output_of_prior_pics_flag == 1 &&
> s->no_rasl_output_flag
> == 1) {
> -for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> -HEVCFrame *frame = &s->DPB[i];
> -if (!(frame->flags & HEVC_FRAME_FLAG_BUMPING) && frame->poc
> != s->poc &&
> -frame->sequence == s->seq_output) {
> -ff_hevc_unref_frame(s, frame, HEVC_FRAME_FLAG_OUTPUT);
> -}
> -}
> -}
> -
> for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> HEVCFrame *frame = &s->DPB[i];
> if ((frame->flags & HEVC_FRAME_FLAG_OUTPUT) &&
Patchset LGTM.
-Haihao
___
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] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration
Quoting Nicolas George (2022-07-18 10:23:40) > Anton Khirnov (12022-07-18): > > Subject: Re: [FFmpeg-devel] [PATCH] ffprobe: use AVFrame.duration instead of > > AVFrame.pkt_duration > > You may want to update this: it is no longer "instead". Right, changed locally. -- 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] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration
Anton Khirnov (12022-07-18): > Subject: Re: [FFmpeg-devel] [PATCH] ffprobe: use AVFrame.duration instead of > AVFrame.pkt_duration You may want to update this: it is no longer "instead". 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 v2 4/5] libswscale: Enable hscale_avx2 for all input sizes.
Hi Michael, I have tried to recreate this locally in a clean client applying the patches as sent in the email thread. I have tried gcc and mingw and this passes for me. Are you sure you applied both patches 3 & 4? If only patch 4 is applied, then I get the error you have. Thanks, Alan On Sat, Jul 16, 2022 at 1:14 PM Michael Niedermayer wrote: > On Fri, Jul 15, 2022 at 05:03:56PM +0200, Alan Kelly wrote: > > Hi Michael, > > > > Thanks for looking at this. I fixed the test issue. > > seems to be still failing here: > make distclean ; ./configure && make -j32 tests/checkasm/checkasm && > tests/checkasm/checkasm --test=sw_scale > checkasm: using random seed 1328711543 > MMXEXT: > - sw_scale.yuv2yuvX [OK] > SSE2: > - sw_scale.hscale [OK] > SSE3: > - sw_scale.yuv2yuvX [OK] > SSSE3: > - sw_scale.hscale [OK] > SSE4.1: > - sw_scale.hscale [OK] > AVX2: >hscale_8_to_15__fs_4_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_4_dstW_24_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_8_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_8_dstW_24_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_12_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_12_dstW_24_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_16_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_16_dstW_24_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_32_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_32_dstW_24_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_40_dstW_8_avx2 (sw_scale.c:235) >hscale_8_to_15__fs_40_dstW_24_avx2 (sw_scale.c:235) > - sw_scale.hscale [FAILED] > - sw_scale.yuv2yuvX [OK] > checkasm: 12 of 504 tests have failed > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is a danger to trust the dream we wish for rather than > the science we have, -- Dr. Kenneth Brown > ___ > 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] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME
---
libavcodec/libx264.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 98ec030865..5e360682e6 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -311,6 +311,25 @@ static void free_picture(AVCodecContext *ctx)
pic->extra_sei.num_payloads = 0;
}
+static enum AVPixelFormat csp_to_pixfmt(int csp)
+{
+switch (csp) {
+#ifdef X264_CSP_I400
+case X264_CSP_I400: return AV_PIX_FMT_GRAY8;
+case X264_CSP_I400 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_GRAY10;
+#endif
+case X264_CSP_I420: return AV_PIX_FMT_YUV420P;
+case X264_CSP_I420 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV420P10;
+case X264_CSP_I422: return AV_PIX_FMT_YUV422P;
+case X264_CSP_I422 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV422P10;
+case X264_CSP_I444: return AV_PIX_FMT_YUV444P;
+case X264_CSP_I444 | X264_CSP_HIGH_DEPTH: return AV_PIX_FMT_YUV444P10;
+case X264_CSP_NV12: return AV_PIX_FMT_NV12;
+case X264_CSP_NV16: return AV_PIX_FMT_NV16;
+};
+return AV_PIX_FMT_NONE;
+}
+
static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, const AVFrame *frame,
int *got_packet)
{
@@ -496,6 +515,33 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt,
const AVFrame *frame,
if (x264_encoder_encode(x4->enc, &nal, &nnal, frame? &x4->pic: NULL,
&pic_out) < 0)
return AVERROR_EXTERNAL;
+if (nnal && (ctx->flags & AV_CODEC_FLAG_RECON_FRAME)) {
+AVCodecInternal *avci = ctx->internal;
+
+av_frame_unref(avci->recon_frame);
+
+avci->recon_frame->format = csp_to_pixfmt(pic_out.img.i_csp);
+if (avci->recon_frame->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unhandled reconstructed frame colorspace: %d\n",
+ pic_out.img.i_csp);
+return AVERROR(ENOSYS);
+}
+
+avci->recon_frame->width = ctx->width;
+avci->recon_frame->height = ctx->height;
+for (int i = 0; i < pic_out.img.i_plane; i++) {
+avci->recon_frame->data[i] = pic_out.img.plane[i];
+avci->recon_frame->linesize[i] = pic_out.img.i_stride[i];
+}
+
+ret = av_frame_make_writable(avci->recon_frame);
+if (ret < 0) {
+av_frame_unref(avci->recon_frame);
+return ret;
+}
+}
+
ret = encode_nals(ctx, pkt, nal, nnal);
if (ret < 0)
return ret;
@@ -928,6 +974,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
x4->params.b_repeat_headers = 0;
+if (avctx->flags & AV_CODEC_FLAG_RECON_FRAME)
+x4->params.b_full_recon = 1;
+
if(x4->x264opts){
const char *p= x4->x264opts;
while(p){
@@ -1223,7 +1272,8 @@ FFCodec ff_libx264_encoder = {
.p.id = AV_CODEC_ID_H264,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_OTHER_THREADS |
-AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
+AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+AV_CODEC_CAP_ENCODER_RECON_FRAME,
.p.priv_class = &x264_class,
.p.wrapper_name = "libx264",
.priv_data_size = sizeof(X264Context),
--
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".
