Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On Wed, May 22, 2019 at 9:54 PM Timo Rothenpieler wrote: > On 22.05.2019 08:59, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > The testing command for the HDR10 output with nvenc: > > $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 > -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ > > -master_display > "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(1000,50)" > -max_cll "0, 0" test.ts > > > > Please notice it is preferable to use the frame sei side data than > master_display and max_cll paramters config > > --- > > libavcodec/nvenc.c | 129 > > libavcodec/nvenc.h | 18 ++ > > libavcodec/nvenc_hevc.c | 11 > > 3 files changed, 158 insertions(+) > > > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > > index 75dda6d689..3fd0eca4a5 100644 > > --- a/libavcodec/nvenc.c > > +++ b/libavcodec/nvenc.c > > @@ -22,6 +22,9 @@ > > #include "config.h" > > > > #include "nvenc.h" > > +#include "cbs_h265.h" > > +#include "hevc_sei.h" > > +#include "put_bits.h" > > > > #include "libavutil/hwcontext_cuda.h" > > #include "libavutil/hwcontext.h" > > @@ -30,6 +33,7 @@ > > #include "libavutil/avassert.h" > > #include "libavutil/mem.h" > > #include "libavutil/pixdesc.h" > > +#include "libavutil/mastering_display_metadata.h" > > #include "internal.h" > > > > #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x) > > @@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext > *avctx) > > ctx->data_pix_fmt = avctx->pix_fmt; > > } > > > > +ctx->display_primaries_x[0] = 13250; > > +ctx->display_primaries_y[0] = 34500; > > +ctx->display_primaries_x[1] = 7500; > > +ctx->display_primaries_y[1] = 3000; > > +ctx->display_primaries_x[2] = 34000; > > +ctx->display_primaries_y[2] = 16000; > > +ctx->white_point_x = 15635; > > +ctx->white_point_y = 16450; > > +ctx->max_display_mastering_luminance = 1000; > > +ctx->min_display_mastering_luminance = 500; > > +ctx->max_content_light_level = 0; > > +ctx->max_pic_average_light_level = 0; > > Does all this really belong into an encoder? The command line parameter > also looks very arcane. > To me, this looks more like a filter or something should add this as > extra data, and then multiple encoders can pick it up from there. > > Yes, now Nvidia video sdk can't support output HDR SEI data directly, however its API allow us to set it by SeiPayloadArray in parameters by the format, that's the only ways to get 4K HDR output by nvenc. Below is the discussion for the background FYI: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=3729&start=10 https://devtalk.nvidia.com/default/topic/976304/video-technologies/nvidia-video-codec-sdk-7-0-hevc-custom-sei-support-problem/ For the master_display and max_cll parameters, it's same format as x265, in case the input is raw video, you can configure it by parameters. With the patches, you can get correct HDR10 and HLG with SDR 4K content. Or after you get transcode 4K file by Nvenc, you'll lost SEI data, you had to using the below project to patch the data. https://github.com/SK-Hardwired/nv_hevc_hdr_patcher Thanks, Limin > Same goes for patch 3/3. Patch 1/3 is looks OK to me. > > > Timo > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] libavfilter/vf_overlay.c: Add '\' for every line of the blend_slice_yuv function by vim column edit
On Saturday, May 25, 2019, Carl Eugen Hoyos wrote:
> Am Fr., 24. Mai 2019 um 11:36 Uhr schrieb :
> >
> > From: Limin Wang
> >
> > ---
> > libavfilter/vf_overlay.c | 52
> > 1 file changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> > index b468cedf2e..c1abd3e1b2 100644
> > --- a/libavfilter/vf_overlay.c
> > +++ b/libavfilter/vf_overlay.c
> > @@ -598,32 +598,32 @@ static inline void alpha_composite(const AVFrame
> *src, const AVFrame *dst,
> > }
> > }
> >
> > -static av_always_inline void blend_slice_yuv(AVFilterContext *ctx,
> > - AVFrame *dst, const
> AVFrame *src,
> > - int hsub, int vsub,
> > - int main_has_alpha,
> > - int x, int y,
> > - int is_straight,
> > - int jobnr, int nb_jobs)
> > -{
> > -OverlayContext *s = ctx->priv;
> > -const int src_w = src->width;
> > -const int src_h = src->height;
> > -const int dst_w = dst->width;
> > -const int dst_h = dst->height;
> > -
> > -blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,
> 0, x, y, main_has_alpha,
> > -s->main_desc->comp[0].plane,
> s->main_desc->comp[0].offset, s->main_desc->comp[0].step, is_straight, 1,
> > -jobnr, nb_jobs);
> > -blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 1, hsub,
> vsub, x, y, main_has_alpha,
> > -s->main_desc->comp[1].plane,
> s->main_desc->comp[1].offset, s->main_desc->comp[1].step, is_straight, 1,
> > -jobnr, nb_jobs);
> > -blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 2, hsub,
> vsub, x, y, main_has_alpha,
> > -s->main_desc->comp[2].plane,
> s->main_desc->comp[2].offset, s->main_desc->comp[2].step, is_straight, 1,
> > -jobnr, nb_jobs);
> > -
> > -if (main_has_alpha)
> > -alpha_composite(src, dst, src_w, src_h, dst_w, dst_h, x, y,
> jobnr, nb_jobs);
> > +static av_always_inline void blend_slice_yuv(AVFilterContext *ctx,
> \
> > + AVFrame *dst, const
> AVFrame *src, \
> > + int hsub, int vsub,
>\
> > + int main_has_alpha,
>\
> > + int x, int y,
>\
> > + int is_straight,
> \
> > + int jobnr, int nb_jobs)
>\
> > +{
> \
> > +OverlayContext *s = ctx->priv;
>\
> > +const int src_w = src->width;
> \
> > +const int src_h = src->height;
>\
> > +const int dst_w = dst->width;
> \
> > +const int dst_h = dst->height;
>\
> > +
>\
> > +blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0,
> 0, x, y, main_has_alpha,\
> > +s->main_desc->comp[0].plane,
> s->main_desc->comp[0].offset, s->main_desc->comp[0].step, is_straight, 1, \
> > +jobnr, nb_jobs);
>\
> > +blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 1, hsub,
> vsub, x, y, main_has_alpha,\
> > +s->main_desc->comp[1].plane,
> s->main_desc->comp[1].offset, s->main_desc->comp[1].step, is_straight, 1, \
> > +jobnr, nb_jobs);
>\
> > +blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 2, hsub,
> vsub, x, y, main_has_alpha,\
> > +s->main_desc->comp[2].plane,
> s->main_desc->comp[2].offset, s->main_desc->comp[2].step, is_straight, 1, \
> > +jobnr, nb_jobs);
>\
> > +
>\
> > +if (main_has_alpha)
> \
> > +alpha_composite(src, dst, src_w, src_h, dst_w, dst_h, x, y,
> jobnr, nb_jobs); \
>
> I believe merging patches 2, 3 and 4 makes understanding them
Re: [FFmpeg-devel] [PATCH 6/7] libavfilter/vf_overlay.c: using the nbits and depth for 8bits and 10bit support
On Sat, May 25, 2019 at 7:52 PM Michael Niedermayer wrote: > On Fri, May 24, 2019 at 05:36:15PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > --- > > libavfilter/vf_overlay.c | 69 +--- > > 1 file changed, 44 insertions(+), 25 deletions(-) > > breaks build > > CC libavfilter/vf_overlay.o > libavfilter/vf_overlay.c: In function ‘blend_plane_8_8bits’: > libavfilter/vf_overlay.c:567:972: warning: unused variable ‘mid’ > [-Wunused-variable] > DEFINE_BLEND_PLANE(8, 8); > > > > > > > > > > > > > ^ > libavfilter/vf_overlay.c: In function ‘alpha_composite_8_8bits’: > libavfilter/vf_overlay.c:622:1: error: case label does not reduce to an > integer constant > DEFINE_ALPHA_COMPOSITE(8, 8); > ^ > make: *** [libavfilter/vf_overlay.o] Error 1 > make: Target `all' not remade because of errors. > > > Sorry, I have tested with other system and fix the build issue now. Please help to check the new version patch. It's OK with Mac and CentOS linux system. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If a bugfix only changes things apparently unrelated to the bug with no > further explanation, that is a good sign that the bugfix is wrong. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On Saturday, May 25, 2019, James Almer wrote:
> On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > The testing command for the HDR10 output with nvenc:
> > $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020
> -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \
> > -master_display "G(13250,34500)B(7500,3000)R(
> 34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts
> >
> > Please notice it is preferable to use the frame sei side data than
> master_display and max_cll paramters config
> > ---
> > libavcodec/nvenc.c | 129
> > libavcodec/nvenc.h | 18 ++
> > libavcodec/nvenc_hevc.c | 11
> > 3 files changed, 158 insertions(+)
> >
> > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> > index 75dda6d689..3fd0eca4a5 100644
> > --- a/libavcodec/nvenc.c
> > +++ b/libavcodec/nvenc.c
> > @@ -22,6 +22,9 @@
> > #include "config.h"
> >
> > #include "nvenc.h"
> > +#include "cbs_h265.h"
>
> This doesn't seem right. The encoder isn't using this framework at all.
>
> You're apparently including this only to get the
> H265RawSEIMasteringDisplayColourVolume and
> H265RawSEIContentLightLevelInfo structs, which you don't really need to
> fill sei_data[i].payload
>
> OK, I'll remove the dependent for the two structure and update the patch.
> > +#include "hevc_sei.h"
> > +#include "put_bits.h"
> >
> > #include "libavutil/hwcontext_cuda.h"
> > #include "libavutil/hwcontext.h"
> > @@ -30,6 +33,7 @@
> > #include "libavutil/avassert.h"
> > #include "libavutil/mem.h"
> > #include "libavutil/pixdesc.h"
> > +#include "libavutil/mastering_display_metadata.h"
> > #include "internal.h"
> >
> > #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, dl_fn->cuda_dl, x)
> > @@ -1491,6 +1495,46 @@ av_cold int ff_nvenc_encode_init(AVCodecContext
> *avctx)
> > ctx->data_pix_fmt = avctx->pix_fmt;
> > }
> >
> > +ctx->display_primaries_x[0] = 13250;
> > +ctx->display_primaries_y[0] = 34500;
> > +ctx->display_primaries_x[1] = 7500;
> > +ctx->display_primaries_y[1] = 3000;
> > +ctx->display_primaries_x[2] = 34000;
> > +ctx->display_primaries_y[2] = 16000;
> > +ctx->white_point_x = 15635;
> > +ctx->white_point_y = 16450;
> > +ctx->max_display_mastering_luminance = 1000;
> > +ctx->min_display_mastering_luminance = 500;
> > +ctx->max_content_light_level = 0;
> > +ctx->max_pic_average_light_level = 0;
> > +if (ctx->master_display) {
> > +ret = sscanf(ctx->master_display, "G(%hu,%hu)B(%hu,%hu)R(%hu,%
> hu)WP(%hu,%hu)L(%u,%u)",
> > +&ctx->display_primaries_x[0],
> &ctx->display_primaries_y[0],
> > +&ctx->display_primaries_x[1],
> &ctx->display_primaries_y[1],
> > +&ctx->display_primaries_x[2],
> &ctx->display_primaries_y[2],
> > +&ctx->white_point_x, &ctx->white_point_y,
> > +&ctx->max_display_mastering_luminance,
> &ctx->min_display_mastering_luminance);
> > +if (ret != 10) {
> > +ret = sscanf(ctx->master_display,
> "G[%hu,%hu]B[%hu,%hu]R[%hu,%hu]WP[%hu,%hu]L[%u,%u]",
> > +&ctx->display_primaries_x[0],
> &ctx->display_primaries_y[0],
> > +&ctx->display_primaries_x[1],
> &ctx->display_primaries_y[1],
> > +&ctx->display_primaries_x[2],
> &ctx->display_primaries_y[2],
> > +&ctx->white_point_x, &ctx->white_point_y,
> > +&ctx->max_display_mastering_luminance,
> &ctx->min_display_mastering_luminance);
> > +}
> > +
> > +if (ret != 10) {
> > +av_log(avctx, AV_LOG_INFO, "Failed to parse master
> display(%s)\n", ctx->master_display);
> > +}
> > +}
> > +
> > +if (ctx->max_cll) {
> > +ret = sscanf(ctx->max_cll, "%hu,%hu",
> &ctx->max_content_light_level, &ctx->max_pic_average_light_level);
> > +if (ret != 2) {
> > +av_log(avctx, AV_LOG_INFO, "Failed to parse max cll(%s)\n",
> ctx->max_cll);
> > +}
> > +}
> > +
> > if ((ret = nvenc_load_libraries(avctx)) < 0)
> > return ret;
> >
> > @@ -2110,6 +2154,91 @@ int ff_nvenc_send_frame(AVCodecContext *avctx,
> const AVFrame *frame)
> > }
> > }
> >
> > +if (ctx->sei & SEI_MASTERING_DISPLAY) {
> > +AVFrameSideData *sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> > +H265RawSEIMasteringDisplayColourVolume smd;
> > +
> > +if (sd) {
> > +AVMasteringDisplayMetadata *mdm =
> (AVMasteringDisplayMetadata *)sd->data;
> > +// HEVC uses a g,b,r ordering, which we convert from a
> more natural r,g,b
> > +const int mapping[3] = {2, 0, 1};
> > +const int chroma_den = 5;
> > +const int luma_den = 1;
> > +
> > +if (mdm->has_prim
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On Wed, May 29, 2019 at 7:11 PM Dennis Mungai wrote: > On Tue, May 28, 2019, 01:15 James Almer wrote: > > > On 5/27/2019 7:13 PM, Timo Rothenpieler wrote: > > > On 27.05.2019 23:49, Lance Wang wrote: > > >> On Saturday, May 25, 2019, James Almer wrote: > > >> > > >>> On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote: > > >>>> From: Limin Wang > > >>>> > > >>>> The testing command for the HDR10 output with nvenc: > > >>>> $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries > bt2020 > > >>> -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ > > >>>> -master_display "G(13250,34500)B(7500,3000)R( > > >>> 34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts > > >>>> > > >>>> Please notice it is preferable to use the frame sei side data than > > >>> master_display and max_cll paramters config > > >>>> --- > > >>>> libavcodec/nvenc.c | 129 > > >>>> > > >>>> libavcodec/nvenc.h | 18 ++ > > >>>> libavcodec/nvenc_hevc.c | 11 > > >>>> 3 files changed, 158 insertions(+) > > >>>> > > >>>> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > > >>>> index 75dda6d689..3fd0eca4a5 100644 > > >>>> --- a/libavcodec/nvenc.c > > >>>> +++ b/libavcodec/nvenc.c > > >>>> @@ -22,6 +22,9 @@ > > >>>> #include "config.h" > > >>>> > > >>>> #include "nvenc.h" > > >>>> +#include "cbs_h265.h" > > >>> > > >>> This doesn't seem right. The encoder isn't using this framework at > all. > > >>> > > >>> You're apparently including this only to get the > > >>> H265RawSEIMasteringDisplayColourVolume and > > >>> H265RawSEIContentLightLevelInfo structs, which you don't really need > to > > >>> fill sei_data[i].payload > > >>> > > >>> OK, I'll remove the dependent for the two structure and update the > > >>> patch. > > >> > > >> > > > > > > I'm still not convinced that all this belong in an encoder. > > > Can it really not be made into a filter that adds it as extra data to > > > frames? There got to be other frame consumers that use this kind of > data. > > > > hevc_metadata (h265_metadata_bsf.c) already exists. It should be trivial > > to add support for this there. > > > > Case in point: Some encoders, such as hevc_vaapi, present private codec > options for the retention of specific SEIs, such as HDR (and is on by > default), yet others, such as the QSV runtime, have no such options. > > Wiring this into a bitstream filter (such as hevc_metadata), etc would > easily address such disparities without mucking around with convoluted > private encoder options. > I haven't seen any support for the SEI data process for the hevc_metadata. That's great if any expert to extend the hevc_metadata for the SEI HDR support in future. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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 5/5] libavfilter/vf_overlay.c: add the yuv420p10 10bit support
On Sun, May 26, 2019 at 8:08 AM wrote:
> From: Limin Wang
>
> The test ffmpeg command in iMAC system:
> ./ffmpeg -y -i input.ts -i ./logo.png -filter_complex
> overlay=50:50:format=yuv420p10 -c:v hevc_videotoolbox ./test.ts
> Now I have tested with yuv420p10 overlay and check the result is OK,
> please help to test with your condition.
> ---
> libavfilter/vf_overlay.c | 42 +++-
> libavfilter/vf_overlay.h | 1 +
> 2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index 2d06074f15..e708d525e5 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -153,7 +153,7 @@ static int process_command(AVFilterContext *ctx, const
> char *cmd, const char *ar
> }
>
> static const enum AVPixelFormat alpha_pix_fmts[] = {
> -AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
> +AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P,
> AV_PIX_FMT_YUVA444P,
> AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
> AV_PIX_FMT_BGRA, AV_PIX_FMT_GBRAP, AV_PIX_FMT_NONE
> };
> @@ -172,6 +172,14 @@ static int query_formats(AVFilterContext *ctx)
> AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE
> };
>
> +static const enum AVPixelFormat main_pix_fmts_yuv420p10[] = {
> +AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
> +AV_PIX_FMT_NONE
> +};
> +static const enum AVPixelFormat overlay_pix_fmts_yuv420p10[] = {
> +AV_PIX_FMT_YUVA420P10LE, AV_PIX_FMT_NONE
> +};
> +
> static const enum AVPixelFormat main_pix_fmts_yuv422[] = {
> AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVA422P,
> AV_PIX_FMT_NONE
> };
> @@ -217,6 +225,13 @@ static int query_formats(AVFilterContext *ctx)
> goto fail;
> }
> break;
> +case OVERLAY_FORMAT_YUV420P10:
> +if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv420p10)) ||
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv420p10))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +break;
> case OVERLAY_FORMAT_YUV422:
> if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv422)) ||
> !(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv422))) {
> @@ -565,6 +580,7 @@ static av_always_inline void
> blend_plane_##depth##_##nbits##bits(AVFilterContext
> }
> \
> }
> DEFINE_BLEND_PLANE(8, 8);
> +DEFINE_BLEND_PLANE(16, 10);
>
> #define DEFINE_ALPHA_COMPOSITE(depth, nbits)
> \
> static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame
> *src, const AVFrame *dst, \
> @@ -616,6 +632,7 @@ static inline void
> alpha_composite_##depth##_##nbits##bits(const AVFrame *src, c
> }
> \
> }
> DEFINE_ALPHA_COMPOSITE(8, 8);
> +DEFINE_ALPHA_COMPOSITE(16, 10);
>
> #define DEFINE_BLEND_SLICE_YUV(depth, nbits)
> \
> static av_always_inline void
> blend_slice_yuv_##depth##_##nbits##bits(AVFilterContext *ctx,
>\
> @@ -646,6 +663,7 @@ static av_always_inline void
> blend_slice_yuv_##depth##_##nbits##bits(AVFilterCon
> alpha_composite_##depth##_##nbits##bits(src, dst, src_w, src_h,
> dst_w, dst_h, x, y, jobnr, nb_jobs); \
> }
> DEFINE_BLEND_SLICE_YUV(8, 8);
> +DEFINE_BLEND_SLICE_YUV(16, 10);
>
> static av_always_inline void blend_slice_planar_rgb(AVFilterContext *ctx,
> AVFrame *dst, const
> AVFrame *src,
> @@ -692,6 +710,21 @@ static int blend_slice_yuva420(AVFilterContext *ctx,
> void *arg, int jobnr, int n
> return 0;
> }
>
> +static int blend_slice_yuv420p10(AVFilterContext *ctx, void *arg, int
> jobnr, int nb_jobs)
> +{
> +OverlayContext *s = ctx->priv;
> +ThreadData *td = arg;
> +blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 0, s->x, s->y,
> 1, jobnr, nb_jobs);
> +return 0;
> +}
> +
> +static int blend_slice_yuva420p10(AVFilterContext *ctx, void *arg, int
> jobnr, int nb_jobs)
> +{
> +OverlayContext *s = ctx->priv;
> +ThreadData *td = arg;
> +blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 1, s->x, s->y,
> 1, jobnr, nb_jobs);
> +return 0;
> +}
> static int blend_slice_yuv422(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> {
> OverlayContext *s = ctx->priv;
> @@ -855,6 +888,9 @@ static int config_input_main(AVFilterLink *inlink)
> case OVERLAY_FORMAT_YUV420:
> s->blend_slice = s->main_has_alpha ? blend_slice_yuva420 :
> blend_slice_yuv420;
> break;
> +case OVERLAY_FORMAT_YUV420P10:
> +s->blend_slice = s->main_has_alpha ? blend_slice_yuva420p10 :
> blend_slice_yuv420p10;
> +break;
> case
Re: [FFmpeg-devel] [PATCH 5/5] libavfilter/vf_overlay.c: add the yuv420p10 10bit support
OK, I'll update the doc/filters.texi for the new option for the update
patch. Thanks for the feedback.
On Thu, Jun 6, 2019 at 2:19 PM Liu Steven wrote:
>
>
> > 在 2019年6月6日，下午2:06，Lance Wang 写道：
> >
> > On Sun, May 26, 2019 at 8:08 AM wrote:
> >
> >> From: Limin Wang
> >>
> >> The test ffmpeg command in iMAC system:
> >> ./ffmpeg -y -i input.ts -i ./logo.png -filter_complex
> >> overlay=50:50:format=yuv420p10 -c:v hevc_videotoolbox ./test.ts
> >> Now I have tested with yuv420p10 overlay and check the result is OK,
> >> please help to test with your condition.
> >> ---
> >> libavfilter/vf_overlay.c | 42 +++-
> >> libavfilter/vf_overlay.h | 1 +
> >> 2 files changed, 42 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> >> index 2d06074f15..e708d525e5 100644
> >> --- a/libavfilter/vf_overlay.c
> >> +++ b/libavfilter/vf_overlay.c
> >> @@ -153,7 +153,7 @@ static int process_command(AVFilterContext *ctx,
> const
> >> char *cmd, const char *ar
> >> }
> >>
> >> static const enum AVPixelFormat alpha_pix_fmts[] = {
> >> -AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
> >> +AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P,
> >> AV_PIX_FMT_YUVA444P,
> >> AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
> >> AV_PIX_FMT_BGRA, AV_PIX_FMT_GBRAP, AV_PIX_FMT_NONE
> >> };
> >> @@ -172,6 +172,14 @@ static int query_formats(AVFilterContext *ctx)
> >> AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE
> >> };
> >>
> >> +static const enum AVPixelFormat main_pix_fmts_yuv420p10[] = {
> >> +AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
> >> +AV_PIX_FMT_NONE
> >> +};
> >> +static const enum AVPixelFormat overlay_pix_fmts_yuv420p10[] = {
> >> +AV_PIX_FMT_YUVA420P10LE, AV_PIX_FMT_NONE
> >> +};
> >> +
> >> static const enum AVPixelFormat main_pix_fmts_yuv422[] = {
> >> AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVA422P,
> >> AV_PIX_FMT_NONE
> >> };
> >> @@ -217,6 +225,13 @@ static int query_formats(AVFilterContext *ctx)
> >> goto fail;
> >> }
> >> break;
> >> +case OVERLAY_FORMAT_YUV420P10:
> >> +if (!(main_formats=
> >> ff_make_format_list(main_pix_fmts_yuv420p10)) ||
> >> +!(overlay_formats =
> >> ff_make_format_list(overlay_pix_fmts_yuv420p10))) {
> >> +ret = AVERROR(ENOMEM);
> >> +goto fail;
> >> +}
> >> +break;
> >> case OVERLAY_FORMAT_YUV422:
> >> if (!(main_formats=
> >> ff_make_format_list(main_pix_fmts_yuv422)) ||
> >> !(overlay_formats =
> >> ff_make_format_list(overlay_pix_fmts_yuv422))) {
> >> @@ -565,6 +580,7 @@ static av_always_inline void
> >> blend_plane_##depth##_##nbits##bits(AVFilterContext
> >> }
> >> \
> >> }
> >> DEFINE_BLEND_PLANE(8, 8);
> >> +DEFINE_BLEND_PLANE(16, 10);
> >>
> >> #define DEFINE_ALPHA_COMPOSITE(depth, nbits)
> >> \
> >> static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame
> >> *src, const AVFrame *dst, \
> >> @@ -616,6 +632,7 @@ static inline void
> >> alpha_composite_##depth##_##nbits##bits(const AVFrame *src, c
> >> }
> >> \
> >> }
> >> DEFINE_ALPHA_COMPOSITE(8, 8);
> >> +DEFINE_ALPHA_COMPOSITE(16, 10);
> >>
> >> #define DEFINE_BLEND_SLICE_YUV(depth, nbits)
> >> \
> >> static av_always_inline void
> >> blend_slice_yuv_##depth##_##nbits##bits(AVFilterContext *ctx,
> >> \
> >> @@ -646,6 +663,7 @@ static av_always_inline void
> >> blend_slice_yuv_##depth##_##nbits##bits(AVFilterCon
> >> alpha_composite_##depth##_##nbits##bits(src, dst, src_w, src_h,
> >> dst_w, dst_h, x, y, jobnr, nb_jobs); \
> >> }
> >> DEFINE_BLEND_SLICE_YUV(8, 8);
> >> +DEFINE_BLEND_SLICE_YUV(16, 10);
> >>
> >> static av_always_inline void blend_
Re: [FFmpeg-devel] [PATCH v3 5/6] libavfilter/vf_overlay.c: add the yuv420p10 10bit support
On Thu, Jun 6, 2019 at 3:10 PM wrote:
> From: Limin Wang
>
> The test ffmpeg command in iMAC system:
> ./ffmpeg -y -i input.ts -i ./logo.png -filter_complex
> overlay=50:50:format=yuv420p10 -c:v hevc_videotoolbox ./test.ts
> Now I have tested with yuv420p10 overlay and check the result is OK,
> please help to test with your condition.
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_overlay.c | 42 +++-
> libavfilter/vf_overlay.h | 1 +
> 2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index 70961befa5..e332a3647e 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -153,7 +153,7 @@ static int process_command(AVFilterContext *ctx, const
> char *cmd, const char *ar
> }
>
> static const enum AVPixelFormat alpha_pix_fmts[] = {
> -AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
> +AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P,
> AV_PIX_FMT_YUVA444P,
> AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
> AV_PIX_FMT_BGRA, AV_PIX_FMT_GBRAP, AV_PIX_FMT_NONE
> };
> @@ -172,6 +172,14 @@ static int query_formats(AVFilterContext *ctx)
> AV_PIX_FMT_YUVA420P, AV_PIX_FMT_NONE
> };
>
> +static const enum AVPixelFormat main_pix_fmts_yuv420p10[] = {
> +AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_YUVA420P10LE,
> +AV_PIX_FMT_NONE
> +};
> +static const enum AVPixelFormat overlay_pix_fmts_yuv420p10[] = {
> +AV_PIX_FMT_YUVA420P10LE, AV_PIX_FMT_NONE
> +};
> +
> static const enum AVPixelFormat main_pix_fmts_yuv422[] = {
> AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVA422P,
> AV_PIX_FMT_NONE
> };
> @@ -217,6 +225,13 @@ static int query_formats(AVFilterContext *ctx)
> goto fail;
> }
> break;
> +case OVERLAY_FORMAT_YUV420P10:
> +if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv420p10)) ||
> +!(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv420p10))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +break;
> case OVERLAY_FORMAT_YUV422:
> if (!(main_formats=
> ff_make_format_list(main_pix_fmts_yuv422)) ||
> !(overlay_formats =
> ff_make_format_list(overlay_pix_fmts_yuv422))) {
> @@ -565,6 +580,7 @@ static av_always_inline void
> blend_plane_##depth##_##nbits##bits(AVFilterContext
> }
> \
> }
> DEFINE_BLEND_PLANE(8, 8);
> +DEFINE_BLEND_PLANE(16, 10);
>
> #define DEFINE_ALPHA_COMPOSITE(depth, nbits)
> \
> static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame
> *src, const AVFrame *dst, \
> @@ -616,6 +632,7 @@ static inline void
> alpha_composite_##depth##_##nbits##bits(const AVFrame *src, c
> }
> \
> }
> DEFINE_ALPHA_COMPOSITE(8, 8);
> +DEFINE_ALPHA_COMPOSITE(16, 10);
>
> #define DEFINE_BLEND_SLICE_YUV(depth, nbits)
> \
> static av_always_inline void
> blend_slice_yuv_##depth##_##nbits##bits(AVFilterContext *ctx,
>\
> @@ -646,6 +663,7 @@ static av_always_inline void
> blend_slice_yuv_##depth##_##nbits##bits(AVFilterCon
> alpha_composite_##depth##_##nbits##bits(src, dst, src_w, src_h,
> dst_w, dst_h, x, y, jobnr, nb_jobs); \
> }
> DEFINE_BLEND_SLICE_YUV(8, 8);
> +DEFINE_BLEND_SLICE_YUV(16, 10);
>
> static av_always_inline void blend_slice_planar_rgb(AVFilterContext *ctx,
> AVFrame *dst, const
> AVFrame *src,
> @@ -692,6 +710,21 @@ static int blend_slice_yuva420(AVFilterContext *ctx,
> void *arg, int jobnr, int n
> return 0;
> }
>
> +static int blend_slice_yuv420p10(AVFilterContext *ctx, void *arg, int
> jobnr, int nb_jobs)
> +{
> +OverlayContext *s = ctx->priv;
> +ThreadData *td = arg;
> +blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 0, s->x, s->y,
> 1, jobnr, nb_jobs);
> +return 0;
> +}
> +
> +static int blend_slice_yuva420p10(AVFilterContext *ctx, void *arg, int
> jobnr, int nb_jobs)
> +{
> +OverlayContext *s = ctx->priv;
> +ThreadData *td = arg;
> +blend_slice_yuv_16_10bits(ctx, td->dst, td->src, 1, 1, 1, s->x, s->y,
> 1, jobnr, nb_jobs);
> +return 0;
> +}
> static int blend_slice_yuv422(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> {
> OverlayContext *s = ctx->priv;
> @@ -855,6 +888,9 @@ static int config_input_main(AVFilterLink *inlink)
> case OVERLAY_FORMAT_YUV420:
> s->blend_slice = s->main_has_alpha ? blend_slice_yuva420 :
> blend_slice_yuv420;
> break;
> +case OVERLAY_FORMAT_YUV420P10:
> +s->blend_slice = s->main_has_alpha ? blend_slice_yuva420p10 :
> blend_slice_yuv420p10;
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Fri, Jun 7, 2019 at 6:56 AM Michael Niedermayer
wrote:
> On Thu, Jun 06, 2019 at 01:54:41PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_find_rect.c | 37 ++---
> > 1 file changed, 26 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > index d7e6579af7..abf7d89d21 100644
> > --- a/libavfilter/vf_find_rect.c
> > +++ b/libavfilter/vf_find_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > #define MAX_MIPMAPS 5
> >
>
> > @@ -244,6 +245,7 @@ static av_cold int init(AVFilterContext *ctx)
> > {
> > FOCContext *foc = ctx->priv;
> > int ret, i;
>
> > +AVFrame tmp_frame;
>
> AVFrames size cannot be used outside libavutil as it breaks extensibility
>
>
OK, I have updated the patch for review.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolboxenc: Fix for the compiler error for my old mac pro
On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz wrote:
> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
>
> This looks like a different approach to a similar patch sent before
> by Thilo.
>
> ---
> > libavcodec/videotoolboxenc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/videotoolboxenc.c
> > b/libavcodec/videotoolboxenc.c
> > index 3665581..e4f44e5 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -763,10 +763,14 @@ static int get_cv_pixel_format(AVCodecContext*
> > avctx,
> >
> kCVPixelFormatType_420YpCbCr8PlanarFullRange
> > :
> >
> kCVPixelFormatType_420YpCbCr8Planar;
> > } else if (fmt == AV_PIX_FMT_P010LE) {
> > +#ifndef kCVPixelFormatType_420YpCbCr10BiPlanarFullRange
> > +return AVERROR(EINVAL);
> > +#else
>
> I do not think this can ever reach the else branch, as
> kCVPixelFormatType_420YpCbCr10BiPlanarFullRange is not
> a define but a normal symbol and the preprocessor can not
> check for symbols using ifdef, just for defines.
>
>
Sorry, I tested with my system successfully and haven't check it's enum
type, now I have updated the patch, please review it.
https://patchwork.ffmpeg.org/patch/13450/
> > *av_pixel_format = range == AVCOL_RANGE_JPEG ?
> >
> kCVPixelFormatType_420YpCbCr10BiPlanarFullRange
> > :
> >
> kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
> > *av_pixel_format =
> > kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange;
> > +#endif
> > } else {
> > return AVERROR(EINVAL);
> > }
> > --
> > 2.6.4
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_cover_rect.c: free the allocated frame
On Fri, Jun 7, 2019 at 11:13 PM Michael Niedermayer
wrote:
> On Thu, Jun 06, 2019 at 04:30:56PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 41cd1a12b9..d63c03215d 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -196,8 +196,10 @@ static av_cold void uninit(AVFilterContext *ctx)
> > {
> > CoverContext *cover = ctx->priv;
> >
> > -if (cover->cover_frame)
> > +if (cover->cover_frame) {
> > av_freep(&cover->cover_frame->data[0]);
> > +av_frame_free(&cover->cover_frame);
>
> the AVFrame should be setup in such a way that a av_frame_free() alone is
> enough and explicit no av_freep of data is needed
>
Sorry, I haven't catch your point. Don't need av_freep() or
av_frame_free() to free the memory?
For the av_freep is existing code already.
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolboxenc: Fix for the compiler error for my old mac pro
On Fri, Jun 7, 2019 at 11:52 PM Thilo Borgmann wrote: > Am 07.06.19 um 17:21 schrieb Lance Wang: > > On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz wrote: > > > >> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote: > >> > >>> From: Limin Wang > >>> > >>> Signed-off-by: Limin Wang > >> > >> This looks like a different approach to a similar patch sent before > >> by Thilo. > > It is. We'd discussed a possible solution in the corresponding thread: > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244049.html > > I guess I'll implement it next week like said in there - feel free to > implement that approach beofre I'll get to it. > > -Thilo > I can't reply to the old thread, please check my updated approach. https://patchwork.ffmpeg.org/patch/13450/ HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE is generated in config.h by configure already. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Sun, Jun 9, 2019 at 5:41 AM Michael Niedermayer wrote: > On Sat, Jun 08, 2019 at 06:53:58AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavfilter/vf_find_rect.c | 40 +++- > > 1 file changed, 27 insertions(+), 13 deletions(-) > > > > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c > > index d7e6579..6fe12fe 100644 > > --- a/libavfilter/vf_find_rect.c > > +++ b/libavfilter/vf_find_rect.c > > @@ -28,6 +28,7 @@ > > #include "internal.h" > > > > #include "lavfutils.h" > > +#include "lswsutils.h" > > > > #define MAX_MIPMAPS 5 > > > > @@ -235,8 +236,6 @@ static av_cold void uninit(AVFilterContext *ctx) > > av_frame_free(&foc->haystack_frame[i]); > > } > > > > -if (foc->obj_frame) > > -av_freep(&foc->obj_frame->data[0]); > > av_frame_free(&foc->obj_frame); > > } > > this alone will leak > > something like: > foc->obj_frame->buf[0] = > av_buffer_create(foc->obj_frame->data[0], > foc->obj_frame->linesize[0] * > foc->obj_frame->height, > av_buffer_default_free, > NULL, > 0); > > would be needed, but maybe theres a cleaner way to do this > like having a function that does all this in one step and produces a normal > AVFrame. I think more filters could benefit from this if theres nothing > like it yet ... > > I misunderstand by another code review and think the buffer is freed by av_free_frame. I'll revert it back in the update patch. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Its not that you shouldnt use gotos but rather that you should write > readable code and code with gotos often but not always is less readable > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Sun, Jun 9, 2019 at 4:38 AM Michael Niedermayer
wrote:
> On Sat, Jun 08, 2019 at 06:53:58AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_find_rect.c | 40 +++-
> > 1 file changed, 27 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > index d7e6579..6fe12fe 100644
> > --- a/libavfilter/vf_find_rect.c
> > +++ b/libavfilter/vf_find_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > #define MAX_MIPMAPS 5
> >
> > @@ -235,8 +236,6 @@ static av_cold void uninit(AVFilterContext *ctx)
> > av_frame_free(&foc->haystack_frame[i]);
> > }
> >
> > -if (foc->obj_frame)
> > -av_freep(&foc->obj_frame->data[0]);
> > av_frame_free(&foc->obj_frame);
> > }
> >
> > @@ -244,6 +243,9 @@ static av_cold int init(AVFilterContext *ctx)
> > {
> > FOCContext *foc = ctx->priv;
> > int ret, i;
> > +uint8_t *tmp_data[4];
> > +int tmp_linesize[4], width, height;
> > +enum AVPixelFormat pix_fmt;
> >
> > if (!foc->obj_filename) {
> > av_log(ctx, AV_LOG_ERROR, "object filename not set\n");
> > @@ -254,24 +256,36 @@ static av_cold int init(AVFilterContext *ctx)
> > if (!foc->obj_frame)
> > return AVERROR(ENOMEM);
> >
> > -if ((ret = ff_load_image(foc->obj_frame->data,
> foc->obj_frame->linesize,
> > - &foc->obj_frame->width,
> &foc->obj_frame->height,
> > - &foc->obj_frame->format,
> foc->obj_filename, ctx)) < 0)
> > -return ret;
> > -
> > -if (foc->obj_frame->format != AV_PIX_FMT_GRAY8) {
> > -av_log(ctx, AV_LOG_ERROR, "object image is not a grayscale
> image\n");
> > -return AVERROR(EINVAL);
> > -}
> > +if ((ret = ff_load_image(&tmp_data, tmp_linesize,
> > + &width, &height,
> > + &pix_fmt, foc->obj_filename, ctx)) < 0)
>
> libavfilter/vf_find_rect.c: In function ‘init’:
> libavfilter/vf_find_rect.c:261:30: warning: passing argument 1 of
> ‘ff_load_image’ from incompatible pointer type [enabled by default]
>
>
>
Should be fixed in the update v4 version patch. Have tested with expected
function with below command:
./ffmpeg -i ./input.ts -vf
find_rect=./logo.jpg,cover_rect=./cover.jpg:mode=cover output.ts
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> During times of universal deceit, telling the truth becomes a
> revolutionary act. -- George Orwell
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libavfilter/vf_blend.c: remove duplicate code with macro-defined function
On Mon, May 27, 2019 at 2:22 PM wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_blend.c | 188 +++--
> 1 file changed, 48 insertions(+), 140 deletions(-)
>
> diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
> index 46e0518d26..cf71200773 100644
> --- a/libavfilter/vf_blend.c
> +++ b/libavfilter/vf_blend.c
> @@ -555,156 +555,64 @@ static av_cold void uninit(AVFilterContext *ctx)
> av_expr_free(s->params[i].e);
> }
>
> +#define DEFINE_INIT_BLEND_FUNC(depth, nbits)
> \
> +static av_cold void init_blend_func_##depth##_##nbits##bit(FilterParams
> *param) \
> +{
> \
> +switch (param->mode) {
> \
> +case BLEND_ADDITION: param->blend =
> blend_addition_##depth##bit; break; \
> +case BLEND_GRAINMERGE: param->blend =
> blend_grainmerge_##depth##bit; break; \
> +case BLEND_AND:param->blend = blend_and_##depth##bit;
> break; \
> +case BLEND_AVERAGE:param->blend =
> blend_average_##depth##bit;break; \
> +case BLEND_BURN: param->blend = blend_burn_##depth##bit;
>break; \
> +case BLEND_DARKEN: param->blend = blend_darken_##depth##bit;
>break; \
> +case BLEND_DIFFERENCE: param->blend =
> blend_difference_##depth##bit; break; \
> +case BLEND_GRAINEXTRACT: param->blend =
> blend_grainextract_##depth##bit; break; \
> +case BLEND_DIVIDE: param->blend = blend_divide_##depth##bit;
>break; \
> +case BLEND_DODGE: param->blend = blend_dodge_##depth##bit;
> break; \
> +case BLEND_EXCLUSION: param->blend =
> blend_exclusion_##depth##bit; break; \
> +case BLEND_EXTREMITY: param->blend =
> blend_extremity_##depth##bit; break; \
> +case BLEND_FREEZE: param->blend = blend_freeze_##depth##bit;
>break; \
> +case BLEND_GLOW: param->blend = blend_glow_##depth##bit;
>break; \
> +case BLEND_HARDLIGHT: param->blend =
> blend_hardlight_##depth##bit; break; \
> +case BLEND_HARDMIX:param->blend =
> blend_hardmix_##depth##bit;break; \
> +case BLEND_HEAT: param->blend = blend_heat_##depth##bit;
>break; \
> +case BLEND_LIGHTEN:param->blend =
> blend_lighten_##depth##bit;break; \
> +case BLEND_LINEARLIGHT:param->blend =
> blend_linearlight_##depth##bit;break; \
> +case BLEND_MULTIPLY: param->blend =
> blend_multiply_##depth##bit; break; \
> +case BLEND_MULTIPLY128:param->blend =
> blend_multiply128_##depth##bit;break; \
> +case BLEND_NEGATION: param->blend =
> blend_negation_##depth##bit; break; \
> +case BLEND_NORMAL: param->blend = blend_normal_##nbits##bit;
>break; \
> +case BLEND_OR: param->blend = blend_or_##depth##bit;
>break; \
> +case BLEND_OVERLAY:param->blend =
> blend_overlay_##depth##bit;break; \
> +case BLEND_PHOENIX:param->blend =
> blend_phoenix_##depth##bit;break; \
> +case BLEND_PINLIGHT: param->blend =
> blend_pinlight_##depth##bit; break; \
> +case BLEND_REFLECT:param->blend =
> blend_reflect_##depth##bit;break; \
> +case BLEND_SCREEN: param->blend = blend_screen_##depth##bit;
>break; \
> +case BLEND_SOFTLIGHT: param->blend =
> blend_softlight_##depth##bit; break; \
> +case BLEND_SUBTRACT: param->blend =
> blend_subtract_##depth##bit; break; \
> +case BLEND_VIVIDLIGHT: param->blend =
> blend_vividlight_##depth##bit; break; \
> +case BLEND_XOR:param->blend = blend_xor_##depth##bit;
> break; \
> +}
> \
> +}
> +DEFINE_INIT_BLEND_FUNC(8, 8);
> +DEFINE_INIT_BLEND_FUNC(10, 16);
> +DEFINE_INIT_BLEND_FUNC(12, 16);
> +DEFINE_INIT_BLEND_FUNC(16, 16);
> +
> void ff_blend_init(FilterParams *param, int depth)
> {
> switch (depth) {
> case 8:
> -switch (param->mode) {
> -case BLEND_ADDITION: param->blend = blend_addition_8bit;
> break;
> -case BLEND_GRAINMERGE: param->blend = blend_grainmerge_8bit;
> break;
> -case BLEND_AND:param->blend = blend_and_8bit;
> break;
> -case BLEND_AVERAGE:param->blend = blend_average_8bit;
> break;
> -case BLEND_BURN: param->blend = blend_burn_8bit;
> break;
> -case BLEND_DARKEN: param->blend = blend_darken_8bit;
> break;
> -case BLEND_DIFFERENCE: param->blend = blend_difference_8bit;
> break;
> -case BLEND_GRAINEXTRACT: param->blend = blend_grainextract_8bit;
> break;
> -case BLEND_DIVIDE: param->blend = blend_divide_8bit;
> break;
> -case BLEND_DODGE: param->blend = b
Re: [FFmpeg-devel] [PATCH v4 2/2] doc/filters.texi: don't need to be in gray8 for find image
On Wed, Jun 12, 2019 at 5:23 AM Michael Niedermayer wrote: > On Tue, Jun 11, 2019 at 02:07:30PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/filters.texi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/doc/filters.texi b/doc/filters.texi > > index ec1c7c7591..90c57430a6 100644 > > --- a/doc/filters.texi > > +++ b/doc/filters.texi > > @@ -10150,7 +10150,7 @@ It accepts the following options: > > > > @table @option > > @item object > > -Filepath of the object image, needs to be in gray8. > > +Filepath of the object image. > > this belongs in the same patch which changes the code accordingly > > thx > > OK, I'll put into one patch and send update version. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/3] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Wed, Jun 12, 2019 at 4:51 AM Michael Niedermayer
wrote:
> On Tue, Jun 11, 2019 at 01:38:43PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 49 +++--
> > 1 file changed, 36 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 898debf09d..22389b79d2 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > enum mode {
> > MODE_COVER,
> > @@ -40,6 +41,7 @@ typedef struct CoverContext {
> > int mode;
> > char *cover_filename;
> > AVFrame *cover_frame;
> > +AVFrame *match_frame;
> > int width, height;
> > } CoverContext;
> >
> > @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int
> offy)
> > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int
> offy)
> > {
> > int x, y, p;
> >
> > for (p = 0; p < 3; p++) {
> > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> > -const uint8_t *src = cover->cover_frame->data[p];
> > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > +const uint8_t *src = cover_frame->data[p];
> > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > for (y = 0; y < h; y++) {
> > for (x = 0; x < w; x++) {
> > data[x] = src[x];
> > }
> > data += in->linesize[p];
> > -src += cover->cover_frame->linesize[p];
> > +src += cover_frame->linesize[p];
> > }
> > }
> > }
> > @@ -138,7 +140,10 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > CoverContext *cover = ctx->priv;
> > AVDictionaryEntry *ex, *ey, *ew, *eh;
> > int x = -1, y = -1, w = -1, h = -1;
> > +enum AVPixelFormat in_format;
> > char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr =
> NULL;
> > +AVFrame *cover_frame = NULL;
> > +int ret;
> >
> > ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL,
> AV_DICT_MATCH_CASE);
> > ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL,
> AV_DICT_MATCH_CASE);
> > @@ -167,13 +172,30 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > }
> > w = FFMIN(w, in->width - x);
> > h = FFMIN(h, in->height - y);
> > +in_format = in->format;
> >
> > if (w > in->width || h > in->height || w <= 0 || h <= 0)
> > return AVERROR(EINVAL);
> >
> > if (cover->cover_frame) {
> > -if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> > -return AVERROR(EINVAL);
> > +if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height ||
> > +in_format != cover->cover_frame->format) {
> > +if (!cover->match_frame && !(cover->match_frame =
> av_frame_alloc()))
> > +return AVERROR(EINVAL);
> > +
> > +if ((ret = ff_scale_image(cover->match_frame->data,
> cover->match_frame->linesize,
> > +w, h, in_format, cover->cover_frame->data,
> cover->cover_frame->linesize,
> > +cover->cover_frame->width,
> cover->cover_frame->height,
> > +cover->cover_frame->format, ctx)) < 0)
> > +return AVERROR(EINVAL);
>
> This looks like the same static cover image would be converted again for
> each input frame
> which if iam not misreading this would be doing the exact same operation
> over and over
> again, thats same wastefull
>
> I plan to add code t to find more different object with different width
and height, however the cover image is same.
So it's necessary to convert it after get the real find object width and
height. If you use the same width and height with
current code, it'll do the same function. After the patch applied, I'll
send with another patch to avoid conversion every time
if width and height, format is same.
> []
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> ___
> 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
Re: [FFmpeg-devel] [PATCH v3 3/3] doc/filters.texi: Don't need to be yuv420 format for cover image
On Wed, Jun 12, 2019 at 5:46 PM Moritz Barsnick wrote:
> On Tue, Jun 11, 2019 at 13:38:44 +0800, lance.lmw...@gmail.com wrote:
> > doc/filters.texi | 2 +-
>
> While you're at it, could you kindly add another patch to fix the
> descriptions of the examples for find_rect and cover_rect? They are
> copy pasted from pallettegen, and are totally misleading:
>
> > Generate a representative palette of a given video using
> @command{ffmpeg}:
>
>
OK, I'll update the patch with the description also. Please help to review
it.
> Thanks,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/3] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Wed, Jun 12, 2019 at 4:51 AM Michael Niedermayer
wrote:
> On Tue, Jun 11, 2019 at 01:38:43PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 49 +++--
> > 1 file changed, 36 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 898debf09d..22389b79d2 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > enum mode {
> > MODE_COVER,
> > @@ -40,6 +41,7 @@ typedef struct CoverContext {
> > int mode;
> > char *cover_filename;
> > AVFrame *cover_frame;
> > +AVFrame *match_frame;
> > int width, height;
> > } CoverContext;
> >
> > @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int
> offy)
> > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int
> offy)
> > {
> > int x, y, p;
> >
> > for (p = 0; p < 3; p++) {
> > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> > -const uint8_t *src = cover->cover_frame->data[p];
> > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > +const uint8_t *src = cover_frame->data[p];
> > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > for (y = 0; y < h; y++) {
> > for (x = 0; x < w; x++) {
> > data[x] = src[x];
> > }
> > data += in->linesize[p];
> > -src += cover->cover_frame->linesize[p];
> > +src += cover_frame->linesize[p];
> > }
> > }
> > }
> > @@ -138,7 +140,10 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > CoverContext *cover = ctx->priv;
> > AVDictionaryEntry *ex, *ey, *ew, *eh;
> > int x = -1, y = -1, w = -1, h = -1;
> > +enum AVPixelFormat in_format;
> > char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr =
> NULL;
> > +AVFrame *cover_frame = NULL;
> > +int ret;
> >
> > ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL,
> AV_DICT_MATCH_CASE);
> > ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL,
> AV_DICT_MATCH_CASE);
> > @@ -167,13 +172,30 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > }
> > w = FFMIN(w, in->width - x);
> > h = FFMIN(h, in->height - y);
> > +in_format = in->format;
> >
> > if (w > in->width || h > in->height || w <= 0 || h <= 0)
> > return AVERROR(EINVAL);
> >
> > if (cover->cover_frame) {
> > -if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> > -return AVERROR(EINVAL);
> > +if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height ||
> > +in_format != cover->cover_frame->format) {
> > +if (!cover->match_frame && !(cover->match_frame =
> av_frame_alloc()))
> > +return AVERROR(EINVAL);
> > +
> > +if ((ret = ff_scale_image(cover->match_frame->data,
> cover->match_frame->linesize,
> > +w, h, in_format, cover->cover_frame->data,
> cover->cover_frame->linesize,
> > +cover->cover_frame->width,
> cover->cover_frame->height,
> > +cover->cover_frame->format, ctx)) < 0)
> > +return AVERROR(EINVAL);
>
> This looks like the same static cover image would be converted again for
> each input frame
> which if iam not misreading this would be doing the exact same operation
> over and over
> again, thats same wastefull
>
>
I have fixed the issue in the updated patch, please help to review again.
https://patchwork.ffmpeg.org/patch/13510/
> []
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/3] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Wed, Jun 12, 2019 at 5:43 PM Moritz Barsnick wrote:
> On Tue, Jun 11, 2019 at 13:38:43 +0800, lance.lmw...@gmail.com wrote:
> > @@ -220,11 +248,6 @@ static av_cold int init(AVFilterContext *ctx)
> > &cover->cover_frame->width,
> &cover->cover_frame->height,
> > &cover->cover_frame->format,
> cover->cover_filename, ctx)) < 0)
> > return ret;
> > -
> > -if (cover->cover_frame->format != AV_PIX_FMT_YUV420P &&
> cover->cover_frame->format != AV_PIX_FMT_YUVJ420P) {
> > -av_log(ctx, AV_LOG_ERROR, "cover image is not a YUV420
> image\n");
> > -return AVERROR(EINVAL);
> > -}
> > }
>
> Don't you also need to update query_formats()? Just wondering,
> untested.
>
> It's image format only, the patch will convert it to same format as input
frame. I have tested with the new patch and haven't see any issue.
> Moritz
> ___
> 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 v4 2/2] doc/filters.texi: don't need to be in gray8 for find image
On Wed, Jun 12, 2019 at 5:23 AM Michael Niedermayer wrote: > On Tue, Jun 11, 2019 at 02:07:30PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/filters.texi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/doc/filters.texi b/doc/filters.texi > > index ec1c7c7591..90c57430a6 100644 > > --- a/doc/filters.texi > > +++ b/doc/filters.texi > > @@ -10150,7 +10150,7 @@ It accepts the following options: > > > > @table @option > > @item object > > -Filepath of the object image, needs to be in gray8. > > +Filepath of the object image. > > this belongs in the same patch which changes the code accordingly > > Have update the patch below: https://patchwork.ffmpeg.org/patch/13513/ Also I have add more patch to improve the performance, please help to review and give comments: https://patchwork.ffmpeg.org/patch/13511/ https://patchwork.ffmpeg.org/patch/13512/ Thx. thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > ___ > 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 v4] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Fri, Jun 14, 2019 at 5:31 PM Michael Niedermayer
wrote:
> On Wed, Jun 12, 2019 at 06:50:18PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/filters.texi| 6 ++--
> > libavfilter/vf_cover_rect.c | 56 +++--
> > 2 files changed, 44 insertions(+), 18 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index ec1c7c7591..4594a61c13 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -10166,7 +10166,7 @@ Specifies the rectangle in which to search.
> >
> > @itemize
> > @item
> > -Generate a representative palette of a given video using
> @command{ffmpeg}:
> > +Cover a rectangular object by the supplied image of a given video using
> @command{ffmpeg}:
> > @example
> > ffmpeg -i file.ts -vf
> find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
> > @end example
> > @@ -10180,7 +10180,7 @@ It accepts the following options:
> >
> > @table @option
> > @item cover
> > -Filepath of the optional cover image, needs to be in yuv420.
> > +Filepath of the optional cover image.
> >
> > @item mode
> > Set covering mode.
> > @@ -10200,7 +10200,7 @@ Default value is @var{blur}.
> >
> > @itemize
> > @item
> > -Generate a representative palette of a given video using
> @command{ffmpeg}:
> > +Cover a rectangular object by the supplied image of a given video using
> @command{ffmpeg}:
> > @example
> > ffmpeg -i file.ts -vf
> find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
> > @end example
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 898debf09d..36c650dd21 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > enum mode {
> > MODE_COVER,
> > @@ -40,6 +41,7 @@ typedef struct CoverContext {
> > int mode;
> > char *cover_filename;
> > AVFrame *cover_frame;
> > +AVFrame *match_frame;
> > int width, height;
> > } CoverContext;
> >
>
> > @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int
> offy)
> > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int
> offy)
> > {
> > int x, y, p;
> >
> > for (p = 0; p < 3; p++) {
> > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> > -const uint8_t *src = cover->cover_frame->data[p];
> > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > +const uint8_t *src = cover_frame->data[p];
> > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > for (y = 0; y < h; y++) {
> > for (x = 0; x < w; x++) {
> > data[x] = src[x];
> > }
> > data += in->linesize[p];
> > -src += cover->cover_frame->linesize[p];
> > +src += cover_frame->linesize[p];
> > }
> > }
> > }
>
> This hunk is independant and can be done in a seperate patch before
>
>
OK, I'll split the patch.
>
> > @@ -138,7 +140,10 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > CoverContext *cover = ctx->priv;
> > AVDictionaryEntry *ex, *ey, *ew, *eh;
> > int x = -1, y = -1, w = -1, h = -1;
> > +enum AVPixelFormat in_format;
> > char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr =
> NULL;
> > +AVFrame *cover_frame = NULL;
> > +int ret;
> >
> > ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL,
> AV_DICT_MATCH_CASE);
> > ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL,
> AV_DICT_MATCH_CASE);
>
> > @@ -167,14 +172,34 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > }
> > w = FFMIN(w, in->width - x);
> > h = FFMIN(h, in->height - y);
> > +in_format = in->format;
> >
> > if (w > in->width || h > in->height || w <= 0 || h <= 0)
> > return AVERROR(EINVAL);
> >
> > -if (cover->cover_frame) {
> > -if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> > -return AVERROR(EINVAL);
> > -}
> > +if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height ||
> > +in_format != cover->cover_frame->format) {
>
> This segfaults
>
cover->cover_frame is checked in the init function, if it's null, it'll
failed already, so I remove the checking and haven't got any segments issue.
anyway, I'll add it for the updated patch.
>
>
> > +if (!cover->match_frame || (w != cover->match_frame->width || h
> != cover->match_frame->height
> > +|| in_format != cover->match_frame->format)) {
> > +
Re: [FFmpeg-devel] [PATCH v5 2/3] vf_find_rect.c: use the optimized sad function to improve the find performance
On Sat, Jun 15, 2019 at 3:02 AM Michael Niedermayer
wrote:
> Hi
>
> On Wed, Jun 12, 2019 at 06:57:30PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > benchmark on x86_64: 6.4 -> 16 with below command:
> > ./ffmpeg -i 1920x1080.mp4 -vf
> find_rect=./find.tif,cover_rect=./cover.jpg:mode=cover -f null -
> > 6.4 fps -> 16fps
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_find_rect.c | 53 +++---
> > 1 file changed, 21 insertions(+), 32 deletions(-)
> >
> > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > index ee6c3f4b45..ed15885bc2 100644
> > --- a/libavfilter/vf_find_rect.c
> > +++ b/libavfilter/vf_find_rect.c
> > @@ -26,6 +26,7 @@
> > #include "libavutil/imgutils.h"
> > #include "libavutil/opt.h"
> > #include "internal.h"
> > +#include "scene_sad.h"
> >
> > #include "lavfutils.h"
> > #include "lswsutils.h"
> > @@ -36,6 +37,8 @@ typedef struct FOCContext {
> > AVClass *class;
> > float threshold;
> > int mipmaps;
> > +ff_scene_sad_fn sad;
> > +int bitdepth;
> > int xmin, ymin, xmax, ymax;
> > char *obj_filename;
> > int last_x, last_y;
> > @@ -103,54 +106,40 @@ static AVFrame *downscale(AVFrame *in)
> > return frame;
> > }
> >
> > -static float compare(const AVFrame *haystack, const AVFrame *obj, int
> offx, int offy)
> > +static float compare_sad(FOCContext *foc, AVFrame *haystack, AVFrame
> *obj, int offx, int offy)
> > {
> > -int x,y;
> > -int o_sum_v = 0;
> > -int h_sum_v = 0;
> > -int64_t oo_sum_v = 0;
> > -int64_t hh_sum_v = 0;
> > -int64_t oh_sum_v = 0;
> > -float c;
> > +uint64_t sad = 0;
> > int n = obj->height * obj->width;
> > -const uint8_t *odat = obj ->data[0];
> > +double mafd;
> > +const uint8_t *odat = obj->data[0];
> > const uint8_t *hdat = haystack->data[0] + offx + offy *
> haystack->linesize[0];
> > -int64_t o_sigma, h_sigma;
> > -
> > -for(y = 0; y < obj->height; y++) {
> > -for(x = 0; x < obj->width; x++) {
> > -int o_v = odat[x];
> > -int h_v = hdat[x];
> > -o_sum_v += o_v;
> > -h_sum_v += h_v;
> > -oo_sum_v += o_v * o_v;
> > -hh_sum_v += h_v * h_v;
> > -oh_sum_v += o_v * h_v;
> > -}
> > -odat += obj->linesize[0];
> > -hdat += haystack->linesize[0];
> > -}
> > -o_sigma = n*oo_sum_v - o_sum_v*(int64_t)o_sum_v;
> > -h_sigma = n*hh_sum_v - h_sum_v*(int64_t)h_sum_v;
> >
> > -if (o_sigma == 0 || h_sigma == 0)
> > -return 1.0;
> > +foc->sad(hdat, haystack->linesize[0], odat, obj->linesize[0],
> > +obj->width, obj->height, &sad);
> > +emms_c();
> > +mafd = (double)sad / n / (1ULL << foc->bitdepth);
>
> mixing floating point and MMX in the same function is likely not
> safe
>
The code is changed from vf_freezedetect.c, it's OK on my testing system.
That's
why we had to use emms_c to avoid it.
>
> also SAD wont recognize objects that are a different contrast or brightness
>
>
I haven't chance to test these condition, that's the issue. Please ignore
the patch function.
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
> ___
> 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 v5 3/3] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Sat, Jun 15, 2019 at 3:10 AM Michael Niedermayer wrote: > On Sat, Jun 15, 2019 at 12:48:26AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/filters.texi| 2 +- > > libavfilter/vf_cover_rect.c | 40 > > > 2 files changed, 33 insertions(+), 9 deletions(-) > > The subject is "libavfilter/vf_find_rect: convert the object image to > gray8 format instead of failed directly" > while this changes vf_cover_rect instead of vf_find_rect > > Sorry, when I split the patch, I copy the subject from patch wrongly. Have update the subject. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Does the universe only have a finite lifespan? No, its going to go on > forever, its just that you wont like living in it. -- Hiranya Peiri > ___ > 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 v5 1/3] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Sat, Jun 15, 2019 at 3:16 AM Michael Niedermayer
wrote:
> On Wed, Jun 12, 2019 at 06:57:29PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/filters.texi | 2 +-
> > libavfilter/vf_find_rect.c | 39 +++---
> > 2 files changed, 29 insertions(+), 12 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index ec1c7c7591..90c57430a6 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -10150,7 +10150,7 @@ It accepts the following options:
> >
> > @table @option
> > @item object
> > -Filepath of the object image, needs to be in gray8.
> > +Filepath of the object image.
> >
> > @item threshold
> > Detection threshold, default is 0.5.
> > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > index d7e6579af7..ee6c3f4b45 100644
> > --- a/libavfilter/vf_find_rect.c
> > +++ b/libavfilter/vf_find_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > #define MAX_MIPMAPS 5
> >
> > @@ -244,6 +245,9 @@ static av_cold int init(AVFilterContext *ctx)
> > {
> > FOCContext *foc = ctx->priv;
> > int ret, i;
> > +uint8_t *tmp_data[4] = { NULL };
> > +int tmp_linesize[4], width, height;
> > +enum AVPixelFormat pix_fmt;
> >
> > if (!foc->obj_filename) {
> > av_log(ctx, AV_LOG_ERROR, "object filename not set\n");
> > @@ -254,24 +258,37 @@ static av_cold int init(AVFilterContext *ctx)
> > if (!foc->obj_frame)
> > return AVERROR(ENOMEM);
> >
> > -if ((ret = ff_load_image(foc->obj_frame->data,
> foc->obj_frame->linesize,
> > - &foc->obj_frame->width,
> &foc->obj_frame->height,
> > - &foc->obj_frame->format,
> foc->obj_filename, ctx)) < 0)
> > -return ret;
> > -
> > -if (foc->obj_frame->format != AV_PIX_FMT_GRAY8) {
> > -av_log(ctx, AV_LOG_ERROR, "object image is not a grayscale
> image\n");
> > -return AVERROR(EINVAL);
> > -}
> > +if ((ret = ff_load_image(tmp_data, tmp_linesize,
> > + &width, &height,
> > + &pix_fmt, foc->obj_filename, ctx)) < 0)
> > +goto error;
> > +
> > +/* convert object image to gray8 format with same width and height
> */
> > +foc->obj_frame->format = AV_PIX_FMT_GRAY8;
> > +foc->obj_frame->width = width;
> > +foc->obj_frame->height = height;
> > +if ((ret = ff_scale_image(foc->obj_frame->data,
> foc->obj_frame->linesize,
> > +foc->obj_frame->width, foc->obj_frame->height,
> foc->obj_frame->format,
> > +tmp_data, tmp_linesize, width, height, pix_fmt,
> ctx)) < 0)
> > +goto error;
> > +av_freep(&tmp_data[0]);
>
> Iam not sure i understand what this patch is intending to do
>
> Before a grayscale image was needed, after the patch anything is accepted
> but
> only grayscale is used. This is quite unexpected for a user who might
> expect
> color to be used if color is accpeted.
> Generally, doing something that is unexpected by the user is not good
>
> The goal is make the common user to use it more friendly. When I'm do the
testing, I have got some object
file isn't gray image, I had to use ffmpeg convert it to gray every time.
although I don't care for only gray color is used
clearly.
How about to add description to explain we use gray color only for the
compare now.
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
> ___
> 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 v5 1/3] libavfilter/vf_find_rect: convert the object image to gray8 format instead of failed directly
On Sun, Jun 16, 2019 at 6:16 AM Michael Niedermayer
wrote:
> On Sat, Jun 15, 2019 at 06:53:20AM +0800, Lance Wang wrote:
> > On Sat, Jun 15, 2019 at 3:16 AM Michael Niedermayer
>
> > wrote:
> >
> > > On Wed, Jun 12, 2019 at 06:57:29PM +0800, lance.lmw...@gmail.com
> wrote:
> > > > From: Limin Wang
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > doc/filters.texi | 2 +-
> > > > libavfilter/vf_find_rect.c | 39
> +++---
> > > > 2 files changed, 29 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > > index ec1c7c7591..90c57430a6 100644
> > > > --- a/doc/filters.texi
> > > > +++ b/doc/filters.texi
> > > > @@ -10150,7 +10150,7 @@ It accepts the following options:
> > > >
> > > > @table @option
> > > > @item object
> > > > -Filepath of the object image, needs to be in gray8.
> > > > +Filepath of the object image.
> > > >
> > > > @item threshold
> > > > Detection threshold, default is 0.5.
> > > > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > > > index d7e6579af7..ee6c3f4b45 100644
> > > > --- a/libavfilter/vf_find_rect.c
> > > > +++ b/libavfilter/vf_find_rect.c
> > > > @@ -28,6 +28,7 @@
> > > > #include "internal.h"
> > > >
> > > > #include "lavfutils.h"
> > > > +#include "lswsutils.h"
> > > >
> > > > #define MAX_MIPMAPS 5
> > > >
> > > > @@ -244,6 +245,9 @@ static av_cold int init(AVFilterContext *ctx)
> > > > {
> > > > FOCContext *foc = ctx->priv;
> > > > int ret, i;
> > > > +uint8_t *tmp_data[4] = { NULL };
> > > > +int tmp_linesize[4], width, height;
> > > > +enum AVPixelFormat pix_fmt;
> > > >
> > > > if (!foc->obj_filename) {
> > > > av_log(ctx, AV_LOG_ERROR, "object filename not set\n");
> > > > @@ -254,24 +258,37 @@ static av_cold int init(AVFilterContext *ctx)
> > > > if (!foc->obj_frame)
> > > > return AVERROR(ENOMEM);
> > > >
> > > > -if ((ret = ff_load_image(foc->obj_frame->data,
> > > foc->obj_frame->linesize,
> > > > - &foc->obj_frame->width,
> > > &foc->obj_frame->height,
> > > > - &foc->obj_frame->format,
> > > foc->obj_filename, ctx)) < 0)
> > > > -return ret;
> > > > -
> > > > -if (foc->obj_frame->format != AV_PIX_FMT_GRAY8) {
> > > > -av_log(ctx, AV_LOG_ERROR, "object image is not a grayscale
> > > image\n");
> > > > -return AVERROR(EINVAL);
> > > > -}
> > > > +if ((ret = ff_load_image(tmp_data, tmp_linesize,
> > > > + &width, &height,
> > > > + &pix_fmt, foc->obj_filename, ctx)) < 0)
> > > > +goto error;
> > > > +
> > > > +/* convert object image to gray8 format with same width and
> height
> > > */
> > > > +foc->obj_frame->format = AV_PIX_FMT_GRAY8;
> > > > +foc->obj_frame->width = width;
> > > > +foc->obj_frame->height = height;
> > > > +if ((ret = ff_scale_image(foc->obj_frame->data,
> > > foc->obj_frame->linesize,
> > > > +foc->obj_frame->width, foc->obj_frame->height,
> > > foc->obj_frame->format,
> > > > +tmp_data, tmp_linesize, width, height, pix_fmt,
> > > ctx)) < 0)
> > > > +goto error;
> > > > +av_freep(&tmp_data[0]);
> > >
> > > Iam not sure i understand what this patch is intending to do
> > >
> > > Before a grayscale image was needed, after the patch anything is
> accepted
> > > but
> > > only grayscale is used. This is quite unexpected for a user who might
> > > expect
> > > color to be used if color is accpeted.
> > > Generally, doing something that is unexpected by the user is not good
> > >
> > > The goal is make the common user to use it more friendly. When I'm do
> the
> > testing, I have got some object
> > file isn't gray image, I had to use ffmpeg convert it to gray every
> time.
> > although I don't care for only gray color is used
> > clearly.
> >
>
> > How about to add description to explain we use gray color only for the
> > compare now.
>
> not sure its best but its better, yes
>
> OK, I'll add one description in the filters.texi.
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is dangerous to be right in matters on which the established authorities
> are wrong. -- Voltaire
> ___
> 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 v5 2/3] vf_find_rect.c: use the optimized sad function to improve the find performance
On Sun, Jun 16, 2019 at 6:41 AM Michael Niedermayer
wrote:
> On Sat, Jun 15, 2019 at 06:39:38AM +0800, Lance Wang wrote:
> > On Sat, Jun 15, 2019 at 3:02 AM Michael Niedermayer
>
> > wrote:
> >
> > > Hi
> > >
> > > On Wed, Jun 12, 2019 at 06:57:30PM +0800, lance.lmw...@gmail.com
> wrote:
> > > > From: Limin Wang
> > > >
> > > > benchmark on x86_64: 6.4 -> 16 with below command:
> > > > ./ffmpeg -i 1920x1080.mp4 -vf
> > > find_rect=./find.tif,cover_rect=./cover.jpg:mode=cover -f null -
> > > > 6.4 fps -> 16fps
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > libavfilter/vf_find_rect.c | 53
> +++---
> > > > 1 file changed, 21 insertions(+), 32 deletions(-)
> > > >
> > > > diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
> > > > index ee6c3f4b45..ed15885bc2 100644
> > > > --- a/libavfilter/vf_find_rect.c
> > > > +++ b/libavfilter/vf_find_rect.c
> > > > @@ -26,6 +26,7 @@
> > > > #include "libavutil/imgutils.h"
> > > > #include "libavutil/opt.h"
> > > > #include "internal.h"
> > > > +#include "scene_sad.h"
> > > >
> > > > #include "lavfutils.h"
> > > > #include "lswsutils.h"
> > > > @@ -36,6 +37,8 @@ typedef struct FOCContext {
> > > > AVClass *class;
> > > > float threshold;
> > > > int mipmaps;
> > > > +ff_scene_sad_fn sad;
> > > > +int bitdepth;
> > > > int xmin, ymin, xmax, ymax;
> > > > char *obj_filename;
> > > > int last_x, last_y;
> > > > @@ -103,54 +106,40 @@ static AVFrame *downscale(AVFrame *in)
> > > > return frame;
> > > > }
> > > >
> > > > -static float compare(const AVFrame *haystack, const AVFrame *obj,
> int
> > > offx, int offy)
> > > > +static float compare_sad(FOCContext *foc, AVFrame *haystack, AVFrame
> > > *obj, int offx, int offy)
> > > > {
> > > > -int x,y;
> > > > -int o_sum_v = 0;
> > > > -int h_sum_v = 0;
> > > > -int64_t oo_sum_v = 0;
> > > > -int64_t hh_sum_v = 0;
> > > > -int64_t oh_sum_v = 0;
> > > > -float c;
> > > > +uint64_t sad = 0;
> > > > int n = obj->height * obj->width;
> > > > -const uint8_t *odat = obj ->data[0];
> > > > +double mafd;
> > > > +const uint8_t *odat = obj->data[0];
> > > > const uint8_t *hdat = haystack->data[0] + offx + offy *
> > > haystack->linesize[0];
> > > > -int64_t o_sigma, h_sigma;
> > > > -
> > > > -for(y = 0; y < obj->height; y++) {
> > > > -for(x = 0; x < obj->width; x++) {
> > > > -int o_v = odat[x];
> > > > -int h_v = hdat[x];
> > > > -o_sum_v += o_v;
> > > > -h_sum_v += h_v;
> > > > -oo_sum_v += o_v * o_v;
> > > > -hh_sum_v += h_v * h_v;
> > > > -oh_sum_v += o_v * h_v;
> > > > -}
> > > > -odat += obj->linesize[0];
> > > > -hdat += haystack->linesize[0];
> > > > -}
> > > > -o_sigma = n*oo_sum_v - o_sum_v*(int64_t)o_sum_v;
> > > > -h_sigma = n*hh_sum_v - h_sum_v*(int64_t)h_sum_v;
> > > >
> > > > -if (o_sigma == 0 || h_sigma == 0)
> > > > -return 1.0;
> > > > +foc->sad(hdat, haystack->linesize[0], odat, obj->linesize[0],
> > > > +obj->width, obj->height, &sad);
> > > > +emms_c();
> > > > +mafd = (double)sad / n / (1ULL << foc->bitdepth);
> > >
> > > mixing floating point and MMX in the same function is likely not
> > > safe
> > >
> >
> > The code is changed from vf_freezedetect.c, it's OK on my testing
> system.
> > That's
> > why we had to use emms_c to avoid it.
>
> Nothing stops the compiler from moving any floating
> point operations, registers, ... around
> putting mmx + emms in a function with floating point is asking for
> problems, its better not to do this
> worse such problem would only show up on 32bit mmx systems, so if an issue
> occured it would be specific to older systems, thats never good for finding
> and fixing issues quickly
>
>
OK, I'll update the first patch for review, the other two patch will be
ignored and stop update anyway.
thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
> ___
> 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 v4] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Sun, Jun 16, 2019 at 6:20 AM Michael Niedermayer
wrote:
> On Fri, Jun 14, 2019 at 11:52:47PM +0800, Lance Wang wrote:
> > On Fri, Jun 14, 2019 at 5:31 PM Michael Niedermayer
>
> > wrote:
> >
> > > On Wed, Jun 12, 2019 at 06:50:18PM +0800, lance.lmw...@gmail.com
> wrote:
> > > > From: Limin Wang
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > doc/filters.texi| 6 ++--
> > > > libavfilter/vf_cover_rect.c | 56
> +++--
> > > > 2 files changed, 44 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > > index ec1c7c7591..4594a61c13 100644
> > > > --- a/doc/filters.texi
> > > > +++ b/doc/filters.texi
> > > > @@ -10166,7 +10166,7 @@ Specifies the rectangle in which to search.
> > > >
> > > > @itemize
> > > > @item
> > > > -Generate a representative palette of a given video using
> > > @command{ffmpeg}:
> > > > +Cover a rectangular object by the supplied image of a given video
> using
> > > @command{ffmpeg}:
> > > > @example
> > > > ffmpeg -i file.ts -vf
> > > find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
> > > > @end example
> > > > @@ -10180,7 +10180,7 @@ It accepts the following options:
> > > >
> > > > @table @option
> > > > @item cover
> > > > -Filepath of the optional cover image, needs to be in yuv420.
> > > > +Filepath of the optional cover image.
> > > >
> > > > @item mode
> > > > Set covering mode.
> > > > @@ -10200,7 +10200,7 @@ Default value is @var{blur}.
> > > >
> > > > @itemize
> > > > @item
> > > > -Generate a representative palette of a given video using
> > > @command{ffmpeg}:
> > > > +Cover a rectangular object by the supplied image of a given video
> using
> > > @command{ffmpeg}:
> > > > @example
> > > > ffmpeg -i file.ts -vf
> > > find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.mkv
> > > > @end example
> > > > diff --git a/libavfilter/vf_cover_rect.c
> b/libavfilter/vf_cover_rect.c
> > > > index 898debf09d..36c650dd21 100644
> > > > --- a/libavfilter/vf_cover_rect.c
> > > > +++ b/libavfilter/vf_cover_rect.c
> > > > @@ -28,6 +28,7 @@
> > > > #include "internal.h"
> > > >
> > > > #include "lavfutils.h"
> > > > +#include "lswsutils.h"
> > > >
> > > > enum mode {
> > > > MODE_COVER,
> > > > @@ -40,6 +41,7 @@ typedef struct CoverContext {
> > > > int mode;
> > > > char *cover_filename;
> > > > AVFrame *cover_frame;
> > > > +AVFrame *match_frame;
> > > > int width, height;
> > > > } CoverContext;
> > > >
> > >
> > > > @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> > > > return 0;
> > > > }
> > > >
> > > > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx,
> int
> > > offy)
> > > > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx,
> int
> > > offy)
> > > > {
> > > > int x, y, p;
> > > >
> > > > for (p = 0; p < 3; p++) {
> > > > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> > > in->linesize[p];
> > > > -const uint8_t *src = cover->cover_frame->data[p];
> > > > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > > > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > > > +const uint8_t *src = cover_frame->data[p];
> > > > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > > > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > > > for (y = 0; y < h; y++) {
> > > > for (x = 0; x < w; x++) {
> > > > data[x] = src[x];
> > > > }
> > > > data += in->linesize[p];
> > > > -src += cover->cover_frame->linesize[p];
> > > > +src += cover_fram
Re: [FFmpeg-devel] [PATCH v2] libavcodec/videotoolboxenc: Fix compilation broken on macOS 10.12
On Fri, Jun 7, 2019 at 11:13 PM wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/videotoolboxenc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 3665581..f8ccdea 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -39,6 +39,11 @@
> enum { kCMVideoCodecType_HEVC = 'hvc1' };
> #endif
>
> +#if !HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
> +enum { kCVPixelFormatType_420YpCbCr10BiPlanarFullRange = 'xf20' };
> +enum { kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange = 'x420' };
> +#endif
> +
>
Anybody can check the patch is OK or not, I'm glad that the FFmpeg master
will be build on my old Mac pro system without self patch.
Or apply below patch if you prefer to.
https://patchwork.ffmpeg.org/patch/13109/
> typedef OSStatus (*getParameterSetAtIndex)(CMFormatDescriptionRef
> videoDesc,
> size_t parameterSetIndex,
> const uint8_t
> **parameterSetPointerOut,
> --
> 2.6.4
>
>
___
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 v4] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Sun, Jun 16, 2019 at 3:26 PM Michael Niedermayer
wrote:
> On Sun, Jun 16, 2019 at 07:11:27AM +0800, Lance Wang wrote:
> > On Sun, Jun 16, 2019 at 6:20 AM Michael Niedermayer
>
> > wrote:
> >
> > > On Fri, Jun 14, 2019 at 11:52:47PM +0800, Lance Wang wrote:
> > > > On Fri, Jun 14, 2019 at 5:31 PM Michael Niedermayer
> > >
> > > > wrote:
> [...]
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > > +if (!cover->match_frame || (w !=
> cover->match_frame->width
> > > || h
> > > > > != cover->match_frame->height
> > > > > > +|| in_format !=
> cover->match_frame->format)) {
> > > > > > +if (cover->match_frame)
> > > > > > +av_freep(&cover->match_frame->data[0]);
> > > > > > +else if (!(cover->match_frame = av_frame_alloc()))
> > > > > > +return AVERROR(ENOMEM);
> > > > > > +
> > > > >
> > > > > > +if ((ret = ff_scale_image(cover->match_frame->data,
> > > > > cover->match_frame->linesize,
> > > > > > +w, h, in_format,
> > > cover->cover_frame->data,
> > > > > cover->cover_frame->linesize,
> > > > > > +cover->cover_frame->width,
> > > > > cover->cover_frame->height,
> > > > > > +cover->cover_frame->format, ctx)) <
> 0)
> > > > > > +return AVERROR(ENOMEM);
> > > > >
> > > > > This sort of reimplements the scale filter and it
> > > > > doesnt consider some parameters like AVCOL_RANGE*
> > > > >
> > > >
> > > > the ff_scale_image is implemented and used by other alike place, I
> try
> > > to
> > > > reuse the function anyway.
> > > > If we need other parameters for scale, we may improve the function
> later,
> > > > now it's OK for my testing as
> > > > the cover image is logo mostly.
> > >
> > > I think one could argue that the scale filter should be used for
> converting
> > > this way the cover image would become one externally vissible input.
> (which
> > > then subsequently also could change over time and not just be a static
> > > image ...)
> > >
> > >
> > For now, the code is simple and prefer to use it. How about to improve
> all
> > other function which use ff_scale_image in future.
>
> if you add no new ff_scale_image(), sure theres no need to clean it up
> but if you add more bad code, no thats not ok IMO.
>
>
OK, if not use ff_scale_image function, what's better recommended to reuse
the vf_scale complete function simply?
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
> ___
> 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 v5 2/3] ibavfilter/vf_cover_rect.c: change the cover_rect function for support cover frame can be changed
On Sun, Jun 16, 2019 at 3:24 PM Michael Niedermayer
wrote:
> On Sat, Jun 15, 2019 at 12:48:25AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 17 ++---
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 898debf..b66c40b 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -71,24 +71,25 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int
> offy)
> > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int
> offy)
> > {
> > int x, y, p;
> >
> > for (p = 0; p < 3; p++) {
> > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> > -const uint8_t *src = cover->cover_frame->data[p];
> > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > +const uint8_t *src = cover_frame->data[p];
> > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > for (y = 0; y < h; y++) {
> > for (x = 0; x < w; x++) {
> > data[x] = src[x];
> > }
> > data += in->linesize[p];
> > -src += cover->cover_frame->linesize[p];
> > +src += cover_frame->linesize[p];
> > }
> > }
>
> > }
> > +
> > static void blur(CoverContext *cover, AVFrame *in, int offx, int offy)
> > {
> > int x, y, p;
> > @@ -139,6 +140,7 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > AVDictionaryEntry *ex, *ey, *ew, *eh;
> > int x = -1, y = -1, w = -1, h = -1;
> > char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr =
> NULL;
> > +AVFrame *cover_frame = NULL;
> >
> > ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL,
> AV_DICT_MATCH_CASE);
> > ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL,
> AV_DICT_MATCH_CASE);
> > @@ -174,6 +176,7 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > if (cover->cover_frame) {
> > if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> > return AVERROR(EINVAL);
> > +cover_frame = cover->cover_frame;
> > }
> >
> > cover->width = w;
> > @@ -186,8 +189,8 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> >
> > if (cover->mode == MODE_BLUR) {
> > blur (cover, in, x, y);
>
> > -} else {
> > -cover_rect(cover, in, x, y);
> > +} else if (cover_frame) {
> > +cover_rect(cover_frame, in, x, y);
>
> replacing a field from the context by a local variable cannot make a field
> null that was not before
>
Yes, no need to check here. I'll update if the ff_scale_image function
issue can be fixed.
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Its not that you shouldnt use gotos but rather that you should write
> readable code and code with gotos often but not always is less readable
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/6] libavfilter/vf_overlay.c: change the comment style for the following macro defined function
On Thu, Jun 6, 2019 at 3:10 PM wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_overlay.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
> index 0a8f089c0d..b468cedf2e 100644
> --- a/libavfilter/vf_overlay.c
> +++ b/libavfilter/vf_overlay.c
> @@ -500,7 +500,7 @@ static av_always_inline void
> blend_plane(AVFilterContext *ctx,
> for (; k < kmax; k++) {
> int alpha_v, alpha_h, alpha;
>
> -// average alpha for color components, improve quality
> +/* average alpha for color components, improve quality */
> if (hsub && vsub && j+1 < src_hp && k+1 < src_wp) {
> alpha = (a[0] + a[src->linesize[3]] +
> a[1] + a[src->linesize[3]+1]) >> 2;
> @@ -512,10 +512,10 @@ static av_always_inline void
> blend_plane(AVFilterContext *ctx,
> alpha = (alpha_v + alpha_h) >> 1;
> } else
> alpha = a[0];
> -// if the main channel has an alpha channel, alpha has to be
> calculated
> -// to create an un-premultiplied (straight) alpha value
> +/* if the main channel has an alpha channel, alpha has to be
> calculated */
> +/* to create an un-premultiplied (straight) alpha value */
> if (main_has_alpha && alpha != 0 && alpha != 255) {
> -// average alpha for color components, improve quality
> +/* average alpha for color components, improve quality */
> uint8_t alpha_d;
> if (hsub && vsub && j+1 < src_hp && k+1 < src_wp) {
> alpha_d = (da[0] + da[dst->linesize[3]] +
> @@ -556,7 +556,7 @@ static inline void alpha_composite(const AVFrame *src,
> const AVFrame *dst,
> int x, int y,
> int jobnr, int nb_jobs)
> {
> -uint8_t alpha; ///< the amount of overlay to blend on to main
> +uint8_t alpha; /* the amount of overlay to blend on to main
> */
> uint8_t *s, *sa, *d, *da;
> int i, imax, j, jmax;
> int slice_start, slice_end;
> @@ -587,7 +587,7 @@ static inline void alpha_composite(const AVFrame *src,
> const AVFrame *dst,
> *d = *s;
> break;
> default:
> -// apply alpha compositing: main_alpha += (1-main_alpha)
> * overlay_alpha
> +/* apply alpha compositing: main_alpha += (1-main_alpha)
> * overlay_alpha */
> *d += FAST_DIV255((255 - *d) * *s);
> }
> d += 1;
> --
>
ping, who can help to review and test the patches.
> 2.21.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 v2] lavf/vf_find_rect: add the dual input support function
On Thu, Jun 27, 2019 at 09:40:22AM +0200, Moritz Barsnick wrote: > On Thu, Jun 27, 2019 at 10:12:35 +0800, lance.lmw...@gmail.com wrote: > > +This filter takes in two video input, the first input is considered > ^ inputs > > +the "main" source and is passed unchanged to the output. The "second" > > +input is used as a rectangular object for finding, now the "second" > ^ Now? > The part from "now" - once you have clarified why the word "now" > belongs here - should be a separate sentence. Please help to check my updated words for the v3 patch > > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > > new.mkv > > +ffmpeg -i file.ts -newref.pgm -filter_complex > > find_rect,cover_rect=cover.jpg:mode=cover new.mkv > This is certainly wrong. > > > -ffmpeg -i file.ts -vf find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover > > new.mkv > > +ffmpeg -i file.ts -newref.pgm -filter_complex > > find_rect,cover_rect=cover.jpg:mode=cover new.mkv > ditto > Yes, it's typo, fixed. > If you change the options behavior of a filter, you should bump > libavfilter micro version. Fixed. > > I can't just on most of the rest of your changes. > > Moritz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avformat/mxfdec: reindent code
On Mon, May 4, 2020 at 4:13 PM Tomas Härdin wrote:
> tor 2020-04-30 klockan 20:59 +0800 skrev lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/mxfdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index fdd0dd2a88..02a2a6d97a 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -363,7 +363,7 @@ static void mxf_free_metadataset(MXFMetadataSet
> > **ctx, int freectx)
> > break;
> > }
> > if (freectx)
> > -av_freep(ctx);
> > +av_freep(ctx);
> > }
>
> Might as well att some {} braces too
>
>
Sorry, I haven't understand your comments, are you want to change like
below?
if (freectx) {
av_freep(cox);
}
/Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avfilter/vf_subtitles: add wrap_unicode option
On Mon, May 22, 2023 at 12:05 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> So CJK can be wrapped automatically.
>
> Signed-off-by: Zhao Zhili
> ---
> v2: Don't overwrite wrap automatically for native ASS
>
> libavfilter/version.h | 2 +-
> libavfilter/vf_subtitles.c | 14 ++
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index ba8a6fdab2..08779130f5 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -32,7 +32,7 @@
> #include "version_major.h"
>
> #define LIBAVFILTER_VERSION_MINOR 8
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>
>
> #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR,
> \
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index 82e140e986..48038cde23 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -61,6 +61,7 @@ typedef struct AssContext {
> int original_w, original_h;
> int shaping;
> FFDrawContext draw;
> +int wrap_unicode;
> } AssContext;
>
> #define OFFSET(x) offsetof(AssContext, x)
> @@ -271,6 +272,9 @@ static const AVOption subtitles_options[] = {
> {"stream_index", "set stream index",
> OFFSET(stream_index), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,
> INT_MAX, FLAGS},
> {"si", "set stream index",
> OFFSET(stream_index), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1,
> INT_MAX, FLAGS},
> {"force_style", "force subtitle style",
> OFFSET(force_style), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS},
> +#if (LIBASS_VERSION >= 0x01600010)
> +{"wrap_unicode", "break lines according to the Unicode Line Breaking
> Algorithm", OFFSET(wrap_unicode), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1,
> FLAGS },
> +#endif
{NULL},
> };
>
> @@ -432,6 +436,16 @@ static av_cold int init_subtitles(AVFilterContext
> *ctx)
> if (ret < 0)
> goto end;
>
> +/* Don't overwrite wrap automatically for native ASS */
> +if (ass->wrap_unicode == -1)
> +ass->wrap_unicode = st->codecpar->codec_id != AV_CODEC_ID_ASS;
> +if (ass->wrap_unicode) {
> +ret = ass_track_set_feature(ass->track, ASS_FEATURE_WRAP_UNICODE,
> 1);
>
ASS_FEATURE_WRAP_UNICODE is defined if LIBASS_VERSION < 0x01600010?
> +if (ret < 0)
> +av_log(ctx, AV_LOG_WARNING,
> + "libass wasn't built with ASS_FEATURE_WRAP_UNICODE
> support\n");
> +}
> +
> if (ass->force_style) {
> char **list = NULL;
> char *temp = NULL;
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS attribute of H.264
On Mon, May 29, 2023 at 10:16 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> libavformat/hlsenc.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 871afb571b..1e0848ce3d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -355,9 +355,19 @@ static void write_codec_attr(AVStream *st,
> VariantStream *vs)
>
> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> uint8_t *data = st->codecpar->extradata;
> -if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 &&
> (data[4] & 0x1F) == 7) {
> +if (data) {
> +const uint8_t *p;
> +
> +if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
> +p = &data[5];
> +else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
> +p = &data[4];
> +else if (data[0] == 0x01) /* avcC */
> +p = &data[1];
> +else
> +goto fail;
>
how to reproduce the issue? I recall mpegts is annex b format and sps/pps
start code is 4 byte always.
> snprintf(attr, sizeof(attr),
> - "avc1.%02x%02x%02x", data[5], data[6], data[7]);
> + "avc1.%02x%02x%02x", p[0], p[1], p[2]);
> } else {
> goto fail;
> }
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix CODECS attribute of H.264
On Tue, May 30, 2023 at 11:09 AM "zhilizhao(赵志立)"
wrote:
>
>
> > On May 30, 2023, at 09:03, Lance Wang wrote:
> >
> > On Mon, May 29, 2023 at 10:16 PM Zhao Zhili
> wrote:
> >
> >> From: Zhao Zhili
> >>
> >> Signed-off-by: Zhao Zhili
> >> ---
> >> libavformat/hlsenc.c | 14 --
> >> 1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index 871afb571b..1e0848ce3d 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -355,9 +355,19 @@ static void write_codec_attr(AVStream *st,
> >> VariantStream *vs)
> >>
> >> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> >> uint8_t *data = st->codecpar->extradata;
> >> -if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1
> &&
> >> (data[4] & 0x1F) == 7) {
> >> +if (data) {
> >> +const uint8_t *p;
> >> +
> >> +if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
> >> +p = &data[5];
> >> +else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
> >> +p = &data[4];
> >> +else if (data[0] == 0x01) /* avcC */
> >> +p = &data[1];
> >> +else
> >> +goto fail;
> >>
> >
> > how to reproduce the issue? I recall mpegts is annex b format and sps/pps
> > start code is 4 byte always.
>
> For example:
>
> ffmpeg -i foo.mp4 -c copy -hls_playlist_type vod -master_pl_name bar.m3u8
> test.m3u8
>
> 1. The input of hls muxer can be avcc
>
> 2. The output of hls muxer can be avcc too, with fmp4 segments.
>
>
Yes, this is the case. I had to add mp4toannexb bsf after the copy for avcc
input. If we
don't add the format conversion, hevc may have the same issue I guess.
Also we should
check the size of extradata.
> 3. Start code of SPS/PPS should be 0 0 0 1, however, 0 0 1 exist in wild.
> ff_isom_write_avcc() does the same:
>
> /* check for H.264 start code */
> if (AV_RB32(data) != 0x0001 &&
> AV_RB24(data) != 0x01) {
> avio_write(pb, data, len);
> return 0;
> }
>
> ff_isom_write_avcc() can be used here, and get/create CODECS attribute can
> be
> shared by multiple muxers. I won't go that further by now.
>
>
The next NALU checking is for SPS only, so one more byte is zero_byte. It's
required by specs:
zero_byte is a single byte equal to 0x00.
When any of the following conditions are true, the zero_byte syntax element
shall be present:
-
– the nal_unit_type within the nal_unit( ) is equal to 7 (sequence
parameter set) or 8 (picture parameter set),
-
– the byte stream NAL unit syntax structure contains the first NAL unit
of an access unit in decoding order, as specified in clause 7.4.1.2.3.
>
> >
> >
> >> snprintf(attr, sizeof(attr),
> >> - "avc1.%02x%02x%02x", data[5], data[6], data[7]);
> >> + "avc1.%02x%02x%02x", p[0], p[1], p[2]);
> >> } else {
> >> goto fail;
> >> }
> >> --
> >> 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 mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 1/6] avformat/flvenc: support mux hevc in enhanced flv
On Fri, Jun 2, 2023 at 3:31 PM Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavformat/Makefile | 2 +-
> libavformat/flv.h| 15 +++
> libavformat/flvenc.c | 41 +++--
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index f8ad7c6a11..1ef3d15467 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -214,7 +214,7 @@ OBJS-$(CONFIG_FLAC_MUXER)+= flacenc.o
> flacenc_header.o \
> OBJS-$(CONFIG_FLIC_DEMUXER) += flic.o
> OBJS-$(CONFIG_FLV_DEMUXER) += flvdec.o
> OBJS-$(CONFIG_LIVE_FLV_DEMUXER) += flvdec.o
> -OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o
> +OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o hevc.o
> OBJS-$(CONFIG_FOURXM_DEMUXER)+= 4xm.o
> OBJS-$(CONFIG_FRAMECRC_MUXER)+= framecrcenc.o framehash.o
> OBJS-$(CONFIG_FRAMEHASH_MUXER) += hashenc.o framehash.o
> diff --git a/libavformat/flv.h b/libavformat/flv.h
> index 3571b90279..91e0a4140c 100644
> --- a/libavformat/flv.h
> +++ b/libavformat/flv.h
> @@ -35,6 +35,12 @@
>
> #define FLV_VIDEO_FRAMETYPE_OFFSET 4
>
> +/* Extended VideoTagHeader
> + * defined in reference link:
> + *
> https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp-v1.pdf
> + * */
> +#define FLV_IS_EX_HEADER 0x80
> +
> /* bitmasks to isolate specific values */
> #define FLV_AUDIO_CHANNEL_MASK0x01
> #define FLV_AUDIO_SAMPLESIZE_MASK 0x02
> @@ -112,6 +118,15 @@ enum {
> FLV_CODECID_MPEG4 = 9,
> };
>
> +enum {
> +PacketTypeSequenceStart = 0,
> +PacketTypeCodedFrames = 1,
> +PacketTypeSequenceEnd = 2,
> +PacketTypeCodedFramesX = 3,
> +PacketTypeMetadata = 4,
> +PacketTypeMPEG2TSSequenceStart = 5,
> +};
> +
>
format and align the "="?
> enum {
> FLV_FRAME_KEY= 1 << FLV_VIDEO_FRAMETYPE_OFFSET, ///< key
> frame (for AVC, a seekable frame)
> FLV_FRAME_INTER = 2 << FLV_VIDEO_FRAMETYPE_OFFSET, ///<
> inter frame (for AVC, a non-seekable frame)
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 721f062811..aed0946a2e 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -28,6 +28,7 @@
> #include "libavcodec/mpeg4audio.h"
> #include "avio.h"
> #include "avc.h"
> +#include "hevc.h"
> #include "avformat.h"
> #include "flv.h"
> #include "internal.h"
> @@ -46,6 +47,7 @@ static const AVCodecTag flv_video_codec_ids[] = {
> { AV_CODEC_ID_VP6, FLV_CODECID_VP6 },
> { AV_CODEC_ID_VP6A, FLV_CODECID_VP6A },
> { AV_CODEC_ID_H264, FLV_CODECID_H264 },
> +{ AV_CODEC_ID_HEVC, MKBETAG('h', 'v', 'c', '1') },
> { AV_CODEC_ID_NONE, 0 }
> };
>
> @@ -489,7 +491,7 @@ static void flv_write_codec_header(AVFormatContext* s,
> AVCodecParameters* par, i
> FLVContext *flv = s->priv_data;
>
> if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id ==
> AV_CODEC_ID_H264
> -|| par->codec_id == AV_CODEC_ID_MPEG4) {
> +|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> AV_CODEC_ID_HEVC) {
> int64_t pos;
> avio_w8(pb,
> par->codec_type == AVMEDIA_TYPE_VIDEO ?
> @@ -532,10 +534,19 @@ static void flv_write_codec_header(AVFormatContext*
> s, AVCodecParameters* par, i
> }
> avio_write(pb, par->extradata, par->extradata_size);
> } else {
> -avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
> -avio_w8(pb, 0); // AVC sequence header
> -avio_wb24(pb, 0); // composition time
> -ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
> +if (par->codec_id == AV_CODEC_ID_HEVC) {
> +avio_w8(pb, FLV_IS_EX_HEADER | PacketTypeSequenceStart |
> FLV_FRAME_KEY); // ExVideoTagHeader mode with PacketTypeSequenceStart
> +avio_write(pb, "hvc1", 4);
>
ff_isom_write_hvcc(pb, par->extradata, par->extradata_size, 0);
> +} else {
> +avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
> +avio_w8(pb, 0); // AVC sequence header
> +avio_wb24(pb, 0); // composition time
>
ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
> +}
> +
> +if (par->codec_id == AV_CODEC_ID_HEVC)
> +ff_isom_write_hvcc(pb, par->extradata,
> par->extradata_size, 0);
> +else
> +ff_isom_write_avcc(pb, par->extradata,
> par->extradata_size);
>
merge the if else?
}
> data_size = avio_tell(pb) - pos;
> avio_seek(pb, -data_size - 10, SEEK_CUR);
> @@ -821,6 +832,7 @@ static int flv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> unsigned ts;
> int size = pkt->size;
> uint8_t *data = NULL;
> +uint8_t frametype
Re: [FFmpeg-devel] [PATCH v11 2/6] avformat/flvdec: support demux hevc in enhanced flv
On Fri, Jun 2, 2023 at 3:32 PM Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavformat/flvdec.c | 58 ++--
> 1 file changed, 50 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index d83edff727..c8e6cadf1c 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -79,6 +79,8 @@ typedef struct FLVContext {
> int64_t last_ts;
> int64_t time_offset;
> int64_t time_pos;
> +
> +uint8_t exheader;
> } FLVContext;
>
> /* AMF date type */
> @@ -302,13 +304,25 @@ static void flv_set_audio_codec(AVFormatContext *s,
> AVStream *astream,
> }
> }
>
> -static int flv_same_video_codec(AVCodecParameters *vpar, int flags)
> +static int flv_same_video_codec(AVFormatContext *s, AVCodecParameters
> *vpar, int flags)
> {
> int flv_codecid = flags & FLV_VIDEO_CODECID_MASK;
> +FLVContext *flv = s->priv_data;
>
> if (!vpar->codec_id && !vpar->codec_tag)
> return 1;
>
> +if (flv->exheader) {
> +uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
> +uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
> codec_id_str[1] << 16 | codec_id_str[0] << 24;
> +switch(codec_id) {
> +case MKBETAG('h', 'v', 'c', '1'):
> +return vpar->codec_id == AV_CODEC_ID_HEVC;
> +default:
> +break;
> +}
> +}
> +
> switch (flv_codecid) {
> case FLV_CODECID_H263:
> return vpar->codec_id == AV_CODEC_ID_FLV1;
> @@ -331,9 +345,24 @@ static int flv_set_video_codec(AVFormatContext *s,
> AVStream *vstream,
> int flv_codecid, int read)
> {
> FFStream *const vstreami = ffstream(vstream);
> +FLVContext *flv = s->priv_data;
> int ret = 0;
> AVCodecParameters *par = vstream->codecpar;
> enum AVCodecID old_codec_id = vstream->codecpar->codec_id;
> +flv_codecid &= FLV_VIDEO_CODECID_MASK;
> +
> +if (flv->exheader) {
> +uint32_t codec_id = avio_rb32(s->pb);
> +
> +switch(codec_id) {
> +case MKBETAG('h', 'v', 'c', '1'):
> +par->codec_id = AV_CODEC_ID_HEVC;
> +vstreami->need_parsing = AVSTREAM_PARSE_HEADERS;
> +return 4;
> +default:
> +break;
> +}
> +}
> switch (flv_codecid) {
> case FLV_CODECID_H263:
> par->codec_id = AV_CODEC_ID_FLV1;
> @@ -796,6 +825,7 @@ static int flv_read_header(AVFormatContext *s)
> s->start_time = 0;
> flv->sum_flv_tag_size = 0;
> flv->last_keyframe_stream_index = -1;
> +flv->exheader = 0;
>
> return 0;
> }
> @@ -1071,6 +1101,11 @@ retry:
> } else if (type == FLV_TAG_TYPE_VIDEO) {
> stream_type = FLV_STREAM_TYPE_VIDEO;
> flags= avio_r8(s->pb);
> +/*
> + * Reference Enhancing FLV 2023-03-v1.0.0-B.8
> + *
> https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp-v1.pdf
> + * */
> +flv->exheader = (flags >> 7) & 1;
> size--;
> if ((flags & FLV_VIDEO_FRAMETYPE_MASK) ==
> FLV_FRAME_VIDEO_INFO_CMD)
> goto skip;
> @@ -1129,7 +1164,7 @@ skip:
> break;
> } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
> if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> -(s->video_codec_id || flv_same_video_codec(st->codecpar,
> flags)))
> +(s->video_codec_id || flv_same_video_codec(s,
> st->codecpar, flags)))
> break;
> } else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
> if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
> @@ -1230,7 +1265,7 @@ retry_duration:
> avcodec_parameters_free(&par);
> }
> } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
> -int ret = flv_set_video_codec(s, st, flags &
> FLV_VIDEO_CODECID_MASK, 1);
> +int ret = flv_set_video_codec(s, st, flags, 1);
> if (ret < 0)
> return ret;
> size -= ret;
> @@ -1242,16 +1277,23 @@ retry_duration:
>
> if (st->codecpar->codec_id == AV_CODEC_ID_AAC ||
> st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> -st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
> -int type = avio_r8(s->pb);
> -size--;
> +st->codecpar->codec_id == AV_CODEC_ID_MPEG4 ||
> +st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
> +int type = 0;
>
int type;
+if (flv->exheader && stream_type == FLV_STREAM_TYPE_VIDEO) {
> +type = flags & 0x0F;
> +} else {
> +type = avio_r8(s->pb);
> +size--;
> +}
>
> if (size < 0) {
> ret = AVERROR_INVALIDDATA;
> goto leave;
> }
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_H264 ||
> st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
> +if (st->codecpa
Re: [FFmpeg-devel] [PATCH v11 1/6] avformat/flvenc: support mux hevc in enhanced flv
On Fri, Jun 2, 2023 at 7:29 PM Steven Liu wrote:
> Lance Wang 于2023年6月2日周五 19:09写道：
> >
> > On Fri, Jun 2, 2023 at 3:31 PM Steven Liu wrote:
> >
> > > Signed-off-by: Steven Liu
> > > ---
> > > libavformat/Makefile | 2 +-
> > > libavformat/flv.h| 15 +++
> > > libavformat/flvenc.c | 41 +++--
> > > 3 files changed, 47 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > > index f8ad7c6a11..1ef3d15467 100644
> > > --- a/libavformat/Makefile
> > > +++ b/libavformat/Makefile
> > > @@ -214,7 +214,7 @@ OBJS-$(CONFIG_FLAC_MUXER)+=
> flacenc.o
> > > flacenc_header.o \
> > > OBJS-$(CONFIG_FLIC_DEMUXER) += flic.o
> > > OBJS-$(CONFIG_FLV_DEMUXER) += flvdec.o
> > > OBJS-$(CONFIG_LIVE_FLV_DEMUXER) += flvdec.o
> > > -OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o
> > > +OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o hevc.o
> > > OBJS-$(CONFIG_FOURXM_DEMUXER)+= 4xm.o
> > > OBJS-$(CONFIG_FRAMECRC_MUXER)+= framecrcenc.o framehash.o
> > > OBJS-$(CONFIG_FRAMEHASH_MUXER) += hashenc.o framehash.o
> > > diff --git a/libavformat/flv.h b/libavformat/flv.h
> > > index 3571b90279..91e0a4140c 100644
> > > --- a/libavformat/flv.h
> > > +++ b/libavformat/flv.h
> > > @@ -35,6 +35,12 @@
> > >
> > > #define FLV_VIDEO_FRAMETYPE_OFFSET 4
> > >
> > > +/* Extended VideoTagHeader
> > > + * defined in reference link:
> > > + *
> > >
> https://github.com/veovera/enhanced-rtmp/blob/main/enhanced-rtmp-v1.pdf
> > > + * */
> > > +#define FLV_IS_EX_HEADER 0x80
> > > +
> > > /* bitmasks to isolate specific values */
> > > #define FLV_AUDIO_CHANNEL_MASK0x01
> > > #define FLV_AUDIO_SAMPLESIZE_MASK 0x02
> > > @@ -112,6 +118,15 @@ enum {
> > > FLV_CODECID_MPEG4 = 9,
> > > };
> > >
> > > +enum {
> > > +PacketTypeSequenceStart = 0,
> > > +PacketTypeCodedFrames = 1,
> > > +PacketTypeSequenceEnd = 2,
> > > +PacketTypeCodedFramesX = 3,
> > > +PacketTypeMetadata = 4,
> > > +PacketTypeMPEG2TSSequenceStart = 5,
> > > +};
> > > +
> > >
> >
> > format and align the "="?
> yes it is aligned in patch, you can reference in
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230602073109.14086-2...@chinaffmpeg.org/
> >
> >
> >
> > > enum {
> > > FLV_FRAME_KEY= 1 << FLV_VIDEO_FRAMETYPE_OFFSET, ///<
> key
> > > frame (for AVC, a seekable frame)
> > > FLV_FRAME_INTER = 2 << FLV_VIDEO_FRAMETYPE_OFFSET, ///<
> > > inter frame (for AVC, a non-seekable frame)
> > > diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> > > index 721f062811..aed0946a2e 100644
> > > --- a/libavformat/flvenc.c
> > > +++ b/libavformat/flvenc.c
> > > @@ -28,6 +28,7 @@
> > > #include "libavcodec/mpeg4audio.h"
> > > #include "avio.h"
> > > #include "avc.h"
> > > +#include "hevc.h"
> > > #include "avformat.h"
> > > #include "flv.h"
> > > #include "internal.h"
> > > @@ -46,6 +47,7 @@ static const AVCodecTag flv_video_codec_ids[] = {
> > > { AV_CODEC_ID_VP6, FLV_CODECID_VP6 },
> > > { AV_CODEC_ID_VP6A, FLV_CODECID_VP6A },
> > > { AV_CODEC_ID_H264, FLV_CODECID_H264 },
> > > +{ AV_CODEC_ID_HEVC, MKBETAG('h', 'v', 'c', '1') },
> > > { AV_CODEC_ID_NONE, 0 }
> > > };
> > >
> > > @@ -489,7 +491,7 @@ static void
> flv_write_codec_header(AVFormatContext* s,
> > > AVCodecParameters* par, i
> > > FLVContext *flv = s->priv_data;
> > >
> > > if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id ==
> > > AV_CODEC_ID_H264
> > > -|| par->codec_id == AV_CODEC_ID_MPEG4) {
> > > +|| par->codec_id == AV_CODEC_ID_MPEG4 || par->codec_id ==
> > > AV_CODEC_ID_HEVC) {
> > > int64_t pos;
> > > avio_w8(pb,
> > > par->
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: fix CODECS attribute of H.264
On Thu, Jun 8, 2023 at 10:47 AM Zhao Zhili wrote:
> From: Zhao Zhili
>
> 1. Add avcc extradata support.
> 2. Add non-standard annexb support with 0 0 1 as prefix for SPS.
>
>
LGTM
> Signed-off-by: Zhao Zhili
> ---
> v2: Describe what the patch does.
>
> libavformat/hlsenc.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 871afb571b..1e0848ce3d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -355,9 +355,19 @@ static void write_codec_attr(AVStream *st,
> VariantStream *vs)
>
> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> uint8_t *data = st->codecpar->extradata;
> -if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 &&
> (data[4] & 0x1F) == 7) {
> +if (data) {
> +const uint8_t *p;
> +
> +if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
> +p = &data[5];
> +else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
> +p = &data[4];
> +else if (data[0] == 0x01) /* avcC */
> +p = &data[1];
> +else
> +goto fail;
> snprintf(attr, sizeof(attr),
> - "avc1.%02x%02x%02x", data[5], data[6], data[7]);
> + "avc1.%02x%02x%02x", p[0], p[1], p[2]);
> } else {
> goto fail;
> }
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/hevc_parse: check the size of hvcC is at least 23
On Tue, Jun 13, 2023 at 3:37 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> The code after the check skip 21 bytes and then read two bytes.
>
> Signed-off-by: Zhao Zhili
> ---
> libavcodec/hevc_parse.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
> index 1f3beed183..7bc28fd081 100644
> --- a/libavcodec/hevc_parse.c
> +++ b/libavcodec/hevc_parse.c
> @@ -88,8 +88,10 @@ int ff_hevc_decode_extradata(const uint8_t *data, int
> size, HEVCParamSets *ps,
>
> /* data[0] == 1 is configurationVersion from 14496-15.
> * data[0] == 0 is for backward compatibility predates the standard.
> + *
> + * Minimum number of bytes of hvcC with 0 numOfArrays is 23.
> */
> -if (size > 3 && ((data[0] == 1) || (data[0] == 0 && (data[1] ||
> data[2] > 1 {
> +if (size >= 23 && ((data[0] == 1) || (data[0] == 0 && (data[1] ||
> data[2] > 1 {
>
I think it's better to move the size checking before 21 byte are skipped,
or it'll go to the else logic which
is different.
/* It seems the extradata is encoded as hvcC format. */
> int i, j, num_arrays, nal_len_size;
>
> --
> 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 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 major bump 0/6] Fix HDR vivid support
The patchset lgtm. thanks. On Thu, Feb 2, 2023 at 3:11 PM Zhao Zhili wrote: > From: Zhao Zhili > > Only patch 1/6 needs to go with major version bump. > > Zhao Zhili (6): > libavutil/hdr_dynamic_vivid_metadata: fix > AVHDRVividColorToneMappingParams > libavcodec/dynamic_hdr_vivid: fix start code check > avcodec/dynamic_hdr_vivid: fix base_param_Delta > avcodec/dynamic_hdr_vivid: fix base_enable_flag control > avcodec/dynamic_hdr_vivid: reindent after the previous commit > fftools/ffprobe: fix print_dynamic_hdr_vivid > > fftools/ffprobe.c | 16 + > libavcodec/dynamic_hdr_vivid.c | 49 -- > libavfilter/vf_showinfo.c | 17 - > libavutil/hdr_dynamic_vivid_metadata.h | 12 +++ > 4 files changed, 46 insertions(+), 48 deletions(-) > > -- > 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 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/5] ccfifo: Properly handle CEA-708 captions through framerate conversion
On Fri, Apr 21, 2023 at 9:29 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> When transcoding video that contains 708 closed captions, the
> caption data is tied to the frames as side data. Simply dropping
> or adding frames to change the framerate will result in loss of
> data, so the caption data needs to be preserved and reformatted.
>
> For example, without this patch converting 720p59 to 1080i59
> would result in loss of 50% of the caption bytes, resulting in
> garbled 608 captions and 708 probably wouldn't render at all.
> Further, the frames that are there will have an illegal
> cc_count for the target framerate, so some decoders may ignore
> the packets entirely.
>
> Extract the 608 and 708 tuples and insert them onto queues. Then
> after dropping/adding frames, re-write the tuples back into the
> resulting frames at the appropriate rate given the target
> framerate. This includes both having the correct cc_count as
> well as clocking out the 608 pairs at the appropriate rate.
>
> Signed-off-by: Devin Heitmueller
> ---
> libavfilter/Makefile | 1 +
> libavfilter/ccfifo.c | 191
> +++
> libavfilter/ccfifo.h | 85 +++
> 3 files changed, 277 insertions(+)
> create mode 100644 libavfilter/ccfifo.c
> create mode 100644 libavfilter/ccfifo.h
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 71e198b..628ade8 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -14,6 +14,7 @@ OBJS = allfilters.o
>\
> buffersink.o \
> buffersrc.o \
> colorspace.o \
> + ccfifo.o \
> drawutils.o \
> fifo.o \
> formats.o\
> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
> new file mode 100644
> index 000..3f8be57
> --- /dev/null
> +++ b/libavfilter/ccfifo.c
> @@ -0,0 +1,191 @@
> +/*
> + * CEA-708 Closed Captioning FIFO
> + * Copyright (c) 2023 LTN Global Communications
> + *
> + * Author: Devin Heitmueller
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "ccfifo.h"
> +
> +struct AVCCFifo {
> +AVFifo *cc_608_fifo;
> +AVFifo *cc_708_fifo;
> +int expected_cc_count;
> +int expected_608;
> +int cc_detected;
> +void *log_ctx;
> +};
> +
> +#define MAX_CC_ELEMENTS 128
> +#define CC_BYTES_PER_ENTRY 3
> +
> +struct cc_lookup {
> +int num;
> +int den;
> +int cc_count;
> +int num_608;
> +};
> +
> +const static struct cc_lookup cc_lookup_vals[] = {
> +{ 15, 1, 40, 4 },
> +{ 24, 1, 25, 3 },
> +{ 24000, 1001, 25, 3 },
> +{ 30, 1, 20, 2 },
> +{ 3, 1001, 20, 2},
> +{ 60, 1, 10, 1 },
> +{ 6, 1001, 10, 1},
> +};
> +
> +void ff_ccfifo_freep(AVCCFifo **ccf)
> +{
> +if (ccf && *ccf) {
> +AVCCFifo *tmp = *ccf;
> +if (tmp->cc_608_fifo)
> +av_fifo_freep2(&tmp->cc_608_fifo);
> +if (tmp->cc_708_fifo)
> +av_fifo_freep2(&tmp->cc_708_fifo);
> +av_freep(*ccf);
> +}
> +}
> +
> +AVCCFifo *ff_ccfifo_alloc(AVRational *framerate, void *log_ctx)
> +{
> +AVCCFifo *ccf;
> +int i;
> +
> +ccf = av_mallocz(sizeof(*ccf));
> +if (!ccf)
> +return NULL;
> +
> +if (!(ccf->cc_708_fifo = av_fifo_alloc2(MAX_CC_ELEMENTS,
> CC_BYTES_PER_ENTRY, 0)))
> +goto error;
> +
> +if (!(ccf->cc_608_fifo = av_fifo_alloc2(MAX_CC_ELEMENTS,
> CC_BYTES_PER_ENTRY, 0)))
> +goto error;
> +
> +/* Based on the target FPS, figure out the expected cc_count and
> number of
> + 608 tuples per packet. See ANSI/CTA-708-E Sec 4.3.6.1. */
> +for (i = 0; i < (sizeof(cc_lookup_vals) / sizeof(struct cc_lookup));
> i++) {
>
I prefer to use FF_ARRAY_ELEMS here.
> +if (framerate->num == cc_lookup_vals[i].num &&
> +framerate->den == cc_loo
Re: [FFmpeg-devel] [PATCH v3 1/5] ccfifo: Properly handle CEA-708 captions through framerate conversion
On Wed, Apr 26, 2023 at 10:14 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> Hi Lance,
>
> Thank you for your review. Comments inline.
>
> On Tue, Apr 25, 2023 at 10:28 AM Lance Wang
> wrote:
> > > +/* Based on the target FPS, figure out the expected cc_count and
> > > number of
> > > + 608 tuples per packet. See ANSI/CTA-708-E Sec 4.3.6.1. */
> > > +for (i = 0; i < (sizeof(cc_lookup_vals) / sizeof(struct
> cc_lookup));
> > > i++) {
> > >
> >
> > I prefer to use FF_ARRAY_ELEMS here.
>
> Ok.
>
> > > +if (framerate->num == cc_lookup_vals[i].num &&
> > > +framerate->den == cc_lookup_vals[i].den) {
> > > +ccf->expected_cc_count = cc_lookup_vals[i].cc_count;
> > > +ccf->expected_608 = cc_lookup_vals[i].num_608;
> > > +break;
> > > +}
> > > +}
> > > +
> > > +if (ccf->expected_608 == 0) {
> > > +av_log(ccf->log_ctx, AV_LOG_WARNING, "cc_fifo cannot transcode
> > > captions fps=%d/%d\n",
> > > + framerate->num, framerate->den);
> > > +return NULL;
> > >
> >
> > why not use goto error? I feel ccf should be freed.
>
> Good point. I'll fix that.
>
> >
> >
> > > +}
> > > +
> > > +return ccf;
> > > +
> > > +error:
> > > +ff_ccfifo_freep(&ccf);
> > > +return NULL;
> > > +}
> > > +
> > > +int ff_ccfifo_inject(AVCCFifo *ccf, AVFrame *frame)
> > > +{
> > > +AVFrameSideData *sd;
> > > +int cc_filled = 0;
> > > +int i;
> > > +
> > > +if (!ccf)
> > > +return 0;
> > >
> >
> > + * @returnZero on success, or negative AVERROR
> > + *code on failure.
> >
> > why not return error code? the same to other failure condition.
>
> Ok, so there are legal cases where ccf is NULL and it isn't an error
> condition. If the creation of the FIFO fails due to an unsupported
> output framerate, the expectation is that you can continue to call the
> inject/extract functions and they will simply do nothing (i.e. it will
> work in passthrough mode). There are two alternatives to this
> approach:
>
> 1. Continue to have the FIFO creation fail (returning a NULL
> pointer), and then have to make sure every caller of extract/inject
> checks for the NULL pointer prior to calling the function.
>
> 2. Have the FIFO creation report the warning but "succeed" and create
> the FIFO, and then have the inject/extract functions check some flag
> within the ccf structure and do nothing if the flag is set.
>
>
I prefer to 2
I'm open to ideas on the best approach here.
>
> > +
> > > +if (ccf->cc_detected == 0 || ccf->expected_cc_count == 0)
> > > +return 0;
> > > +
> > > +sd = av_frame_new_side_data(frame, AV_FRAME_DATA_A53_CC,
> > > +ccf->expected_cc_count *
> > > CC_BYTES_PER_ENTRY);
> > > +if (!sd)
> > > +return 0;
> > >
> >
> > same.
>
> Ok.
>
> > > +int ff_ccfifo_extract(AVCCFifo *ccf, AVFrame *frame)
> > > +{
> > > +int i;
> > > +
> > > +if (!ccf)
> > > +return 0;
> > >
> >
> > + * @returnZero on success, or negative AVERROR
> > + *code on failure.
> > same question.
>
> Same explanation as for ff_ccfifo_inject() above,
>
> > > +#ifndef AVUTIL_CCFIFO_H
> > > +#define AVUTIL_CCFIFO_H
> > >
> >
> > AVUTIL is wrong here
>
> Ok.
>
> >
> > > +
> > > +#include "libavutil/avutil.h"
> > > +#include "libavutil/frame.h"
> > > +#include "libavutil/fifo.h"
> > > +
> > > +typedef struct AVCCFifo AVCCFifo;
> > > +
> > > +/**
> > > + * Allocate an AVCCFifo.
> > > + *
> > > + * @param sample_fmt sample format
> > > + * @param channelsnumber of channels
> > > + * @param nb_samples initial allocation size, in samples
> > >
> >
> > This is mismatch comments
>
> Ok.
>
> > > + * @returnnewly allocated AVCCFifo, or NULL on error
> > > + */
> > > +AVCCFifo *ff_ccfifo_alloc(AVRational *framerate, void *log_
Re: [FFmpeg-devel] [PATCH v4 5/6] vf_ccrepack: Add new filter to repack CEA-708 side data
On Fri, Apr 28, 2023 at 11:43 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> THis filter can correct certain issues seen from upstream sources
> where the cc_count is not properly set or the CEA-608 tuples are
> not at the start of the payload as expected.
>
> Make use of the ccfifo to extract and immediately repack the CEA-708
> side data, thereby removing any extra padding and ensuring the 608
> tuples are at the front of the payload.
>
> Signed-off-by: Devin Heitmueller
> ---
> doc/filters.texi | 10 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_ccrepack.c | 100
> ++
> 4 files changed, 112 insertions(+)
> create mode 100644 libavfilter/vf_ccrepack.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 5dde799..9f67a00 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8936,6 +8936,16 @@ Only deinterlace frames marked as interlaced.
> The default value is @code{all}.
> @end table
>
> +@section ccrepack
> +
> +Repack CEA-708 closed captioning side data
> +
> +This filter fixes various issues seen with commerical encoders
> +related to upstream malformed CEA-708 payloads, specifically
> +incorrect number of tuples (wrong cc_count for the target FPS),
> +and incorrect ordering of tuples (i.e. the CEA-608 tuples are not at
> +the first entries in the payload).
> +
> @section cas
>
> Apply Contrast Adaptive Sharpen filter to video stream.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 628ade8..3d0b3ad 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -212,6 +212,7 @@ OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) +=
> vf_avgblur_opencl.o opencl.o \
> opencl/avgblur.o boxblur.o
> OBJS-$(CONFIG_BWDIF_FILTER) += vf_bwdif.o yadif_common.o
> OBJS-$(CONFIG_CAS_FILTER)+= vf_cas.o
> +OBJS-$(CONFIG_CCREPACK_FILTER) += vf_ccrepack.o
> OBJS-$(CONFIG_CHROMABER_VULKAN_FILTER) += vf_chromaber_vulkan.o
> vulkan.o vulkan_filter.o
> OBJS-$(CONFIG_CHROMAHOLD_FILTER) += vf_chromakey.o
> OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index d7db46c..b38550b 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -196,6 +196,7 @@ extern const AVFilter ff_vf_boxblur;
> extern const AVFilter ff_vf_boxblur_opencl;
> extern const AVFilter ff_vf_bwdif;
> extern const AVFilter ff_vf_cas;
> +extern const AVFilter ff_vf_ccrepack;
> extern const AVFilter ff_vf_chromaber_vulkan;
> extern const AVFilter ff_vf_chromahold;
> extern const AVFilter ff_vf_chromakey;
> diff --git a/libavfilter/vf_ccrepack.c b/libavfilter/vf_ccrepack.c
> new file mode 100644
> index 000..fb9120c
> --- /dev/null
> +++ b/libavfilter/vf_ccrepack.c
> @@ -0,0 +1,100 @@
> +/*
> + * CEA-708 Closed Caption Repacker
> + * Copyright (c) 2023 LTN Global Communications
> + *
> + * Author: Devin Heitmueller
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +/*
> + * Repackage CEA-708 arrays, which deals with incorrect cc_count for a
> given
> + * output framerate, and incorrect 708 padding.
> + *
> + * See CEA CEA-10-A "EIA-708-B Implementation Guidance", Section 26.5
> + * "Grouping DTVCC Data Within user_data() Structure"
> + */
> +
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "ccfifo.h"
> +#include "libavutil/opt.h"
> +
> +typedef struct CCRepackContext
> +{
> +const AVClass *class;
> +AVCCFifo *cc_fifo;
> +} CCRepackContext;
> +
> +static const AVOption ccrepack_options[] = {
> +{ NULL }
> +};
> +
>
unused code as no option
> +AVFILTER_DEFINE_CLASS(ccrepack);
> +
> +static int config_input(AVFilterLink *link)
> +{
> +CCRepackContext *ctx = link->dst->priv;
> +
> +if (!(ctx->cc_fifo = ff_ccfifo_alloc(&link->frame_rate, ctx)))
> +av_log(ctx, AV_LOG_VERBOSE, "Failure to setup CC FIFO queue\n");
> +
>
it's better to return error and print error log here.
> +return 0;
> +}
> +
> +static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
Re: [FFmpeg-devel] [PATCH v4 6/6] decklink_enc: add support for playout of 608 captions in MOV files
On Fri, Apr 28, 2023 at 11:43 PM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> Unlike other cases where the closed captions are embedded in the
> video stream as MPEG-2 userdata or H.264 SEI data, with MOV files
> the captions are often found on a separate "e608" subtitle track.
>
> Add support for playout of such files, leveraging the new ccfifo
> mechanism to ensure that they are embedded into VANC at the correct
> rate (since e608 packets often contain batches of multiple 608 pairs).
>
> Note this patch includes a new file named libavdevice/ccfifo.c, which
> allows the ccfifo functionality in libavfilter to be reused even if
> doing shared builds. This is the same approach used for log2_tab.c.
>
>
This implementation is limited to decklink SDI output only, If possible,
can we implement the function from demuxer layer, and then passthrough
by SEI side data? By this way, we can convert such stream in streaming
to embedded CC to video stream easily also.
Signed-off-by: Devin Heitmueller
> ---
> libavdevice/Makefile | 1 +
> libavdevice/ccfifo.c | 24
> libavdevice/decklink_common.h | 3 ++
> libavdevice/decklink_enc.cpp | 66
> +++
> libavdevice/decklink_enc_c.c | 2 +-
> 5 files changed, 95 insertions(+), 1 deletion(-)
> create mode 100644 libavdevice/ccfifo.c
>
> diff --git a/libavdevice/Makefile b/libavdevice/Makefile
> index 8a62822..c304492 100644
> --- a/libavdevice/Makefile
> +++ b/libavdevice/Makefile
> @@ -57,6 +57,7 @@ OBJS-$(CONFIG_LIBDC1394_INDEV) += libdc1394.o
>
> # Objects duplicated from other libraries for shared builds
> SHLIBOBJS-$(CONFIG_DECKLINK_INDEV) += reverse.o
> +SHLIBOBJS-$(CONFIG_DECKLINK_OUTDEV) += ccfifo.o
>
> # Windows resource file
> SHLIBOBJS-$(HAVE_GNU_WINDRES)+= avdeviceres.o
> diff --git a/libavdevice/ccfifo.c b/libavdevice/ccfifo.c
> new file mode 100644
> index 000..9007094
> --- /dev/null
> +++ b/libavdevice/ccfifo.c
> @@ -0,0 +1,24 @@
> +/*
> + * CEA-708 Closed Captioning FIFO
> + * Copyright (c) 2023 LTN Global Communications
> + *
> + * Author: Devin Heitmueller
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "libavfilter/ccfifo.c"
> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
> index 088e165..0d33f94 100644
> --- a/libavdevice/decklink_common.h
> +++ b/libavdevice/decklink_common.h
> @@ -31,6 +31,7 @@
>
> extern "C" {
> #include "libavcodec/packet_internal.h"
> +#include "libavfilter/ccfifo.h"
> }
> #include "libavutil/thread.h"
> #include "decklink_common_c.h"
> @@ -112,6 +113,8 @@ struct decklink_ctx {
> /* Capture buffer queue */
> AVPacketQueue queue;
>
> +AVCCFifo *cc_fifo; ///< closed captions
> +
> /* Streams present */
> int audio;
> int video;
> diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
> index 9f1a8df..616e9c7 100644
> --- a/libavdevice/decklink_enc.cpp
> +++ b/libavdevice/decklink_enc.cpp
> @@ -326,6 +326,25 @@ static int create_s337_payload(AVPacket *pkt, uint8_t
> **outbuf, int *outsize)
> return 0;
> }
>
> +static int decklink_setup_subtitle(AVFormatContext *avctx, AVStream *st)
> +{
> +int ret = -1;
> +
> +switch(st->codecpar->codec_id) {
> +#if CONFIG_LIBKLVANC
> +case AV_CODEC_ID_EIA_608:
> +/* No special setup required */
> +ret = 0;
> +break;
> +#endif
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Unsupported subtitle codec
> specified\n");
> +break;
> +}
> +
> +return ret;
> +}
> +
> av_cold int ff_decklink_write_trailer(AVFormatContext *avctx)
> {
> struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
> @@ -352,6 +371,7 @@ av_cold int ff_decklink_write_trailer(AVFormatContext
> *avctx)
> klvanc_context_destroy(ctx->vanc_ctx);
> #endif
>
> +ff_ccfifo_freep(&ctx->cc_fifo);
> av_freep(&cctx->ctx);
>
> return 0;
> @@ -503,6 +523,23 @@ out:
> free(afd_words);
> }
>
> +/* Parse any EIA-608 subtitles sitting on the queue, and write packet
> side data
> + that will later be handled by construct_cc... */
> +static
Re: [FFmpeg-devel] [PATCH v4 6/6] decklink_enc: add support for playout of 608 captions in MOV files
On Tue, May 2, 2023 at 10:48 PM Devin Heitmueller < devin.heitmuel...@ltnglobal.com> wrote: > Hi Lance, > > On Sun, Apr 30, 2023 at 7:01 PM Lance Wang wrote: > > This implementation is limited to decklink SDI output only, If > possible, > > can we implement the function from demuxer layer, and then passthrough > > by SEI side data? By this way, we can convert such stream in streaming > > to embedded CC to video stream easily also. > > I did consider this approach, and it does raise the more fundamental > issue about trying to minimize the number of ways we have to process > CC data depending on whether it originated in SEI metadata or in > separate packets. There are a number of problems with what you are > proposing though: > > 1. There could be multiple CC streams within an MOV file but only a > single CC stream can be embedded into AVFrame side data. Hence you > would have to specify some sort of argument to the demux to decide > which stream to embed. This makes it much more difficult to do things > like ingest a stream with multiple CC streams and have separate > outputs with different CC streams. Performing the work on the output > side allows you to use the standard "-map" mechanism to dictate which > CC streams are routed to which outputs, and to deliver the content to > different outputs with different CC streams. > > 2. I have use cases in mind where the captions originate from sources > other than MOV files, where the video framerate is not known (or there > is no video at all in the source). For example, I want to be able to > consume video from a TS source while simultaneously demuxing an SCC or > MCC file and sending the result in the output. In such cases the > correct rate control for the captions can only be implemented on the > output side, since in such cases the SCC/MCC demux doesn't have access > to the corresponding video stream (it won't know the video framerate, > nor is it able to embed the captions into the AVFrame side data). > > I can indeed imagine there are use cases where doing it further up the > pipeline could be useful. For example, if you were taking in an MOV > file and wanting to produce a TS where the captions need to be > embedded as SEI metadata (hence you would need the e608 packets > converted to AVFrame side data prior to reaching the encoder). > However I don't see this as a substitute for being able to do it on > the output side when that is the most flexible approach for those > other use cases described above. > Much of this comes down to the fundamental limitations of the ffmpeg > framework related to being able to move data back/forth between data > packets and side data. You can't feed data packets into > AVFilterGraphs. You can't easily combine data from data packets into > AVFrames carrying video (or extract side data from AVFrames to > generate data packets), etc. You can't use BSF filters to combine > data from multiple inputs such as compressed video streams and data > streams after encoding. I've run across all these limitations over > the years, and at this point I'm trying to take the least invasive > approach possible that doesn't require changes to the fundamental > frameworks for handling data packets. > It's worth noting that nothing you have suggested is an "either/or" > situation. Because caption processing is inexpensive, there isn't any > significant overhead in having multiple AvCCFifo instances in the > pipeline. In other words, if you added a feature to the MOV demuxer, > it wouldn't prevent us from running the packets through an AvCCFifo > instance on the output side. The patch proposed doesn't preclude you > adding such a feature on the demux side in the future. > > Thanks for the answer. It's acceptable from my side. Devin > > -- > Devin Heitmueller, Senior Software Engineer > LTN Global Communications > o: +1 (301) 363-1001 > w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com > ___ > 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 v5 1/6] ccfifo: Properly handle CEA-708 captions through framerate conversion
On Fri, May 5, 2023 at 5:07 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> When transcoding video that contains 708 closed captions, the
> caption data is tied to the frames as side data. Simply dropping
> or adding frames to change the framerate will result in loss of
> data, so the caption data needs to be preserved and reformatted.
>
> For example, without this patch converting 720p59 to 1080i59
> would result in loss of 50% of the caption bytes, resulting in
> garbled 608 captions and 708 probably wouldn't render at all.
> Further, the frames that are there will have an illegal
> cc_count for the target framerate, so some decoders may ignore
> the packets entirely.
>
> Extract the 608 and 708 tuples and insert them onto queues. Then
> after dropping/adding frames, re-write the tuples back into the
> resulting frames at the appropriate rate given the target
> framerate. This includes both having the correct cc_count as
> well as clocking out the 608 pairs at the appropriate rate.
>
> Thanks for Lance Wang and Anton
> Khirnov for providing review/feedback.
>
> Signed-off-by: Devin Heitmueller
> ---
> libavfilter/Makefile | 1 +
> libavfilter/ccfifo.c | 222
> +++
> libavfilter/ccfifo.h | 110 +
> 3 files changed, 333 insertions(+)
> create mode 100644 libavfilter/ccfifo.c
> create mode 100644 libavfilter/ccfifo.h
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 482aeaf..68c8f14 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -14,6 +14,7 @@ OBJS = allfilters.o
>\
> buffersink.o \
> buffersrc.o \
> colorspace.o \
> + ccfifo.o \
> drawutils.o \
> fifo.o \
> formats.o\
> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
> new file mode 100644
> index 000..357f764
> --- /dev/null
> +++ b/libavfilter/ccfifo.c
> @@ -0,0 +1,222 @@
> +/*
> + * CEA-708 Closed Captioning FIFO
> + * Copyright (c) 2023 LTN Global Communications
> + *
> + * Author: Devin Heitmueller
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "ccfifo.h"
> +
> +struct AVCCFifo {
> +AVFifo *cc_608_fifo;
> +AVFifo *cc_708_fifo;
> +AVRational framerate;
> +int expected_cc_count;
> +int expected_608;
> +int cc_detected;
> +int passthrough;
> +int passthrough_warning;
> +void *log_ctx;
> +};
> +
> +#define MAX_CC_ELEMENTS 128
> +#define CC_BYTES_PER_ENTRY 3
> +
> +struct cc_lookup {
> +int num;
> +int den;
> +int cc_count;
> +int num_608;
> +};
> +
> +const static struct cc_lookup cc_lookup_vals[] = {
> +{ 15, 1, 40, 4 },
> +{ 24, 1, 25, 3 },
> +{ 24000, 1001, 25, 3 },
> +{ 30, 1, 20, 2 },
> +{ 3, 1001, 20, 2},
> +{ 60, 1, 10, 1 },
> +{ 6, 1001, 10, 1},
> +};
> +
> +void ff_ccfifo_freep(AVCCFifo **ccf)
> +{
> +AVCCFifo *tmp = *ccf;
> +av_fifo_freep2(&tmp->cc_608_fifo);
> +av_fifo_freep2(&tmp->cc_708_fifo);
> +av_freep(*ccf);
> +}
> +
> +AVCCFifo *ff_ccfifo_alloc(AVRational framerate, void *log_ctx)
> +{
> +AVCCFifo *ccf;
> +int i;
> +
> +ccf = av_mallocz(sizeof(*ccf));
> +if (!ccf)
> +return NULL;
> +
> +ccf->log_ctx = log_ctx;
> +ccf->framerate = framerate;
> +
> +if (!(ccf->cc_708_fifo = av_fifo_alloc2(MAX_CC_ELEMENTS,
>
Re: [FFmpeg-devel] [RFC/PATCH] bitpacked_dec: Optimization for bitpacked_dec decoder performance
On Sat, May 6, 2023 at 4:58 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> Rework the code a bit to speed up the 10-bit bitpacked decoding
> routine. This is probably about as fast as I can get it without
> switching to assembly language.
>
> Demonstratable with:
>
> ./ffmpeg -f lavfi -i "smptehdbars=size=3840x2160" -c bitpacked -f image2
> -frames:v 1 source.yuv
> ./ffmpeg -f bitpacked -pix_fmt yuv422p10le -s 3840x2160 -c:v bitpacked -i
> source.yuv -pix_fmt yuv422p10le out.yuv
>
> On my development system, it went from 80ms for a 2160p frame
> down to 20ms (i.e. a 4X speedup). Good enough for now, I hope...
>
>
FYI, on my development system, I run two time for the original and modified
version and no obvious difference:
./ffmpeg -f lavfi -i "smptehdbars=size=3840x2160" -c bitpacked -frames:v 25
source.yuv
time ./ffmpeg -f bitpacked -pix_fmt yuv422p10le -s 3840x2160 -c:v bitpacked
-i source.yuv -pix_fmt yuv422p10le out.yuv
frame= 25 fps=0.0 q=-0.0 Lsize= 81kB time=00:00:00.96
bitrate=6912000.0kbits/s speed=1.13x
real 0m0.961s
user 0m1.086s
sys 0m1.360s
frame= 25 fps=0.0 q=-0.0 Lsize= 81kB time=00:00:00.96
bitrate=6912000.0kbits/s speed=1.16x
real 0m0.936s
user 0m1.358s
sys 0m1.350s
after apply the patch:
frame= 25 fps=0.0 q=-0.0 Lsize= 81kB time=00:00:00.96
bitrate=6912000.0kbits/s speed=1.14x
real 0m0.953s
user 0m0.906s
sys 0m1.438s
frame= 25 fps=0.0 q=-0.0 Lsize= 81kB time=00:00:00.96
bitrate=6912000.0kbits/s speed=1.17x
real 0m0.922s
user 0m0.926s
sys 0m1.066s
> Signed-off-by: Devin Heitmueller
> ---
> libavcodec/bitpacked_dec.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/bitpacked_dec.c b/libavcodec/bitpacked_dec.c
> index a1ffef1..96aba27 100644
> --- a/libavcodec/bitpacked_dec.c
> +++ b/libavcodec/bitpacked_dec.c
> @@ -28,7 +28,6 @@
>
> #include "avcodec.h"
> #include "codec_internal.h"
> -#include "get_bits.h"
> #include "libavutil/imgutils.h"
> #include "thread.h"
>
> @@ -65,7 +64,7 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
> {
> uint64_t frame_size = (uint64_t)avctx->width *
> (uint64_t)avctx->height * 20;
> uint64_t packet_size = (uint64_t)avpkt->size * 8;
> -GetBitContext bc;
> +uint8_t *src;
> uint16_t *y, *u, *v;
> int ret, i, j;
>
> @@ -79,20 +78,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
> if (avctx->width % 2)
> return AVERROR_PATCHWELCOME;
>
> -ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height *
> 20);
> -if (ret)
> -return ret;
> -
> +src = avpkt->data;
> for (i = 0; i < avctx->height; i++) {
> y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
> u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
> v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
>
> for (j = 0; j < avctx->width; j += 2) {
> -*u++ = get_bits(&bc, 10);
> -*y++ = get_bits(&bc, 10);
> -*v++ = get_bits(&bc, 10);
> -*y++ = get_bits(&bc, 10);
> +*u++ = (src[0] << 2) | (src[1] >> 6);
> +*y++ = ((src[1] << 4) | (src[2] >> 4)) & 0x3ff;
> +*v++ = ((src[2] << 6) | (src[3] >> 2)) & 0x3ff;
> +*y++ = ((src[3] << 8) | (src[4])) & 0x3ff;
> +src += 5;
> }
> }
>
> --
> 1.8.3.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 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] avcodec/bitpacked_enc: add support for uyvy422 encoding
On Sun, May 7, 2023 at 1:38 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/bitpacked_enc.c | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/bitpacked_enc.c b/libavcodec/bitpacked_enc.c
> index 3c4e11293d..cbca38006b 100644
> --- a/libavcodec/bitpacked_enc.c
> +++ b/libavcodec/bitpacked_enc.c
> @@ -25,12 +25,36 @@
> #include "encode.h"
> #include "internal.h"
> #include "put_bits.h"
> +#include "libavutil/imgutils.h"
> #include "libavutil/pixdesc.h"
>
> struct BitpackedContext {
> int (*encode)(AVCodecContext *avctx, AVPacket *pkt, const AVFrame
> *frame);
> };
>
> +static int encode_uyvy422(AVCodecContext *avctx, AVPacket *pkt, const
> AVFrame *frame)
> +{
> +int ret = av_image_get_buffer_size(frame->format,
> + frame->width, frame->height, 1);
> +
> +if (ret < 0)
> +return ret;
> +
> +ret = ff_get_encode_buffer(avctx, pkt, ret, 0);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_image_copy_to_buffer(pkt->data, pkt->size,
> + (const uint8_t **)frame->data,
> frame->linesize,
> + frame->format,
> + frame->width, frame->height, 1);
> +
> +if (ret < 0)
> +return ret;
> +
> +return 0;
> +}
> +
>
I prefer to bitpack will used for 10-bit 4:2:2 packed format. uyvy422
should use rawvideo as it'll passthrough directly.
static int encode_yuv422p10(AVCodecContext *avctx, AVPacket *pkt, const
> AVFrame *frame)
> {
> const int buf_size = avctx->height * avctx->width *
> avctx->bits_per_coded_sample / 8;
> @@ -85,7 +109,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
> if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> s->encode = encode_yuv422p10;
> else
> -return AVERROR(EINVAL);
> +s->encode = encode_uyvy422;
>
> return 0;
> }
> @@ -115,5 +139,6 @@ const FFCodec ff_bitpacked_encoder = {
> .init = encode_init,
> FF_CODEC_ENCODE_CB(encode_frame),
> .p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV422P10,
> +AV_PIX_FMT_UYVY422,
> AV_PIX_FMT_NONE },
> };
> --
> 2.40.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 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 v6 1/6] ccfifo: Properly handle CEA-708 captions through framerate conversion
LGTM for the patchset.
On Sat, May 6, 2023 at 2:13 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> When transcoding video that contains 708 closed captions, the
> caption data is tied to the frames as side data. Simply dropping
> or adding frames to change the framerate will result in loss of
> data, so the caption data needs to be preserved and reformatted.
>
> For example, without this patch converting 720p59 to 1080i59
> would result in loss of 50% of the caption bytes, resulting in
> garbled 608 captions and 708 probably wouldn't render at all.
> Further, the frames that are there will have an illegal
> cc_count for the target framerate, so some decoders may ignore
> the packets entirely.
>
> Extract the 608 and 708 tuples and insert them onto queues. Then
> after dropping/adding frames, re-write the tuples back into the
> resulting frames at the appropriate rate given the target
> framerate. This includes both having the correct cc_count as
> well as clocking out the 608 pairs at the appropriate rate.
>
> Thanks to Lance Wang , Anton
> Khirnov , and Michael Niedermayer <
> mich...@niedermayer.cc>
> for providing review/feedback.
>
> Signed-off-by: Devin Heitmueller
> ---
> libavfilter/Makefile | 1 +
> libavfilter/ccfifo.c | 224
> +++
> libavfilter/ccfifo.h | 110 +
> 3 files changed, 335 insertions(+)
> create mode 100644 libavfilter/ccfifo.c
> create mode 100644 libavfilter/ccfifo.h
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 482aeaf..68c8f14 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -14,6 +14,7 @@ OBJS = allfilters.o
>\
> buffersink.o \
> buffersrc.o \
> colorspace.o \
> + ccfifo.o \
> drawutils.o \
> fifo.o \
> formats.o\
> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
> new file mode 100644
> index 000..5fb68ce
> --- /dev/null
> +++ b/libavfilter/ccfifo.c
> @@ -0,0 +1,224 @@
> +/*
> + * CEA-708 Closed Captioning FIFO
> + * Copyright (c) 2023 LTN Global Communications
> + *
> + * Author: Devin Heitmueller
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "ccfifo.h"
> +
> +struct AVCCFifo {
> +AVFifo *cc_608_fifo;
> +AVFifo *cc_708_fifo;
> +AVRational framerate;
> +int expected_cc_count;
> +int expected_608;
> +int cc_detected;
> +int passthrough;
> +int passthrough_warning;
> +void *log_ctx;
> +};
> +
> +#define MAX_CC_ELEMENTS 128
> +#define CC_BYTES_PER_ENTRY 3
> +
> +struct cc_lookup {
> +int num;
> +int den;
> +int cc_count;
> +int num_608;
> +};
> +
> +const static struct cc_lookup cc_lookup_vals[] = {
> +{ 15, 1, 40, 4 },
> +{ 24, 1, 25, 3 },
> +{ 24000, 1001, 25, 3 },
> +{ 30, 1, 20, 2 },
> +{ 3, 1001, 20, 2},
> +{ 60, 1, 10, 1 },
> +{ 6, 1001, 10, 1},
> +};
> +
> +void ff_ccfifo_freep(AVCCFifo **ccf)
> +{
> +AVCCFifo *tmp = *ccf;
> +if (tmp) {
> +av_fifo_freep2(&tmp->cc_608_fifo);
> +av_fifo_freep2(&tmp->cc_708_fifo);
> +}
> +av_freep(ccf);
> +}
> +
> +AVCCFifo *ff_ccfifo_alloc(AVRational framerate, void *log_ctx)
> +{
> +AVCCFifo *ccf;
> +int i;
> +
> +ccf = av_mallocz(sizeof(*ccf));
> +if (!ccf)
> +return NULL;
> +
> +ccf->log_ctx
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/bitpacked_enc: add support for uyvy422 encoding
On Mon, May 8, 2023 at 6:56 AM James Almer wrote:
> On 5/7/2023 4:00 AM, Lance Wang wrote:
> > On Sun, May 7, 2023 at 1:38 AM James Almer wrote:
> >
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/bitpacked_enc.c | 27 ++-
> >> 1 file changed, 26 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/bitpacked_enc.c b/libavcodec/bitpacked_enc.c
> >> index 3c4e11293d..cbca38006b 100644
> >> --- a/libavcodec/bitpacked_enc.c
> >> +++ b/libavcodec/bitpacked_enc.c
> >> @@ -25,12 +25,36 @@
> >> #include "encode.h"
> >> #include "internal.h"
> >> #include "put_bits.h"
> >> +#include "libavutil/imgutils.h"
> >> #include "libavutil/pixdesc.h"
> >>
> >> struct BitpackedContext {
> >> int (*encode)(AVCodecContext *avctx, AVPacket *pkt, const AVFrame
> >> *frame);
> >> };
> >>
> >> +static int encode_uyvy422(AVCodecContext *avctx, AVPacket *pkt, const
> >> AVFrame *frame)
> >> +{
> >> +int ret = av_image_get_buffer_size(frame->format,
> >> + frame->width, frame->height, 1);
> >> +
> >> +if (ret < 0)
> >> +return ret;
> >> +
> >> +ret = ff_get_encode_buffer(avctx, pkt, ret, 0);
> >> +if (ret < 0)
> >> +return ret;
> >> +
> >> +ret = av_image_copy_to_buffer(pkt->data, pkt->size,
> >> + (const uint8_t **)frame->data,
> >> frame->linesize,
> >> + frame->format,
> >> + frame->width, frame->height, 1);
> >> +
> >> +if (ret < 0)
> >> +return ret;
> >> +
> >> +return 0;
> >> +}
> >> +
> >>
> >
> >
> > I prefer to bitpack will used for 10-bit 4:2:2 packed format. uyvy422
> > should use rawvideo as it'll passthrough directly.
>
> I'm not sure i follow. The rawvideo encoder will do exactly the same
> thing I'm doing here.
>
> Are you maybe talking about patch 3/4?
>
The old rtpdec_rfc4175 use bitpack with rawvideo for uyvy422 and I have
changed to
used rawvideo directly. For I think bitpacked is better to use for 10-bit
4:2:2 packed format.
However I haven't removed the old uyvy422 decode code in 3/4 for I'm not
sure whether
it'll break any ABI for old avformat.
> >
> >
> > static int encode_yuv422p10(AVCodecContext *avctx, AVPacket *pkt, const
> >> AVFrame *frame)
> >> {
> >> const int buf_size = avctx->height * avctx->width *
> >> avctx->bits_per_coded_sample / 8;
> >> @@ -85,7 +109,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
> >> if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> >> s->encode = encode_yuv422p10;
> >> else
> >> -return AVERROR(EINVAL);
> >> +s->encode = encode_uyvy422;
> >>
> >> return 0;
> >> }
> >> @@ -115,5 +139,6 @@ const FFCodec ff_bitpacked_encoder = {
> >> .init = encode_init,
> >> FF_CODEC_ENCODE_CB(encode_frame),
> >> .p.pix_fmts = (const enum AVPixelFormat[]){
> AV_PIX_FMT_YUV422P10,
> >> +AV_PIX_FMT_UYVY422,
> >> AV_PIX_FMT_NONE },
> >> };
> >> --
> >> 2.40.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 mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 1/6] ccfifo: Properly handle CEA-708 captions through framerate conversion
On Sun, May 7, 2023 at 3:03 PM Lance Wang wrote:
> LGTM for the patchset.
>
>
I will help to apply the patchset tomorrow if no further comments. thx.
> On Sat, May 6, 2023 at 2:13 AM Devin Heitmueller <
> devin.heitmuel...@ltnglobal.com> wrote:
>
>> When transcoding video that contains 708 closed captions, the
>> caption data is tied to the frames as side data. Simply dropping
>> or adding frames to change the framerate will result in loss of
>> data, so the caption data needs to be preserved and reformatted.
>>
>> For example, without this patch converting 720p59 to 1080i59
>> would result in loss of 50% of the caption bytes, resulting in
>> garbled 608 captions and 708 probably wouldn't render at all.
>> Further, the frames that are there will have an illegal
>> cc_count for the target framerate, so some decoders may ignore
>> the packets entirely.
>>
>> Extract the 608 and 708 tuples and insert them onto queues. Then
>> after dropping/adding frames, re-write the tuples back into the
>> resulting frames at the appropriate rate given the target
>> framerate. This includes both having the correct cc_count as
>> well as clocking out the 608 pairs at the appropriate rate.
>>
>> Thanks to Lance Wang , Anton
>> Khirnov , and Michael Niedermayer <
>> mich...@niedermayer.cc>
>> for providing review/feedback.
>>
>> Signed-off-by: Devin Heitmueller
>> ---
>> libavfilter/Makefile | 1 +
>> libavfilter/ccfifo.c | 224
>> +++
>> libavfilter/ccfifo.h | 110 +
>> 3 files changed, 335 insertions(+)
>> create mode 100644 libavfilter/ccfifo.c
>> create mode 100644 libavfilter/ccfifo.h
>>
>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> index 482aeaf..68c8f14 100644
>> --- a/libavfilter/Makefile
>> +++ b/libavfilter/Makefile
>> @@ -14,6 +14,7 @@ OBJS = allfilters.o
>> \
>> buffersink.o \
>> buffersrc.o \
>> colorspace.o \
>> + ccfifo.o \
>> drawutils.o \
>> fifo.o \
>> formats.o\
>> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
>> new file mode 100644
>> index 000..5fb68ce
>> --- /dev/null
>> +++ b/libavfilter/ccfifo.c
>> @@ -0,0 +1,224 @@
>> +/*
>> + * CEA-708 Closed Captioning FIFO
>> + * Copyright (c) 2023 LTN Global Communications
>> + *
>> + * Author: Devin Heitmueller
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> + */
>> +
>> +#include "ccfifo.h"
>> +
>> +struct AVCCFifo {
>> +AVFifo *cc_608_fifo;
>> +AVFifo *cc_708_fifo;
>> +AVRational framerate;
>> +int expected_cc_count;
>> +int expected_608;
>> +int cc_detected;
>> +int passthrough;
>> +int passthrough_warning;
>> +void *log_ctx;
>> +};
>> +
>> +#define MAX_CC_ELEMENTS 128
>> +#define CC_BYTES_PER_ENTRY 3
>> +
>> +struct cc_lookup {
>> +int num;
>> +int den;
>> +int cc_count;
>> +int num_608;
>> +};
>> +
>> +const static struct cc_lookup cc_lookup_vals[] = {
>> +{ 15, 1, 40, 4 },
>> +{ 24, 1, 25, 3 },
>> +{ 24000, 1001, 25, 3 },
>> +{ 30, 1, 20, 2 },
>> +{ 3, 1001, 20, 2},
>> +
Re: [FFmpeg-devel] [RFC/PATCH] bitpacked_dec: Optimization for bitpacked_dec decoder performance
On Sat, May 6, 2023 at 8:41 PM Devin Heitmueller < devin.heitmuel...@ltnglobal.com> wrote: > On Sat, May 6, 2023 at 8:16 AM James Almer wrote: > > Can you bench with the START_TIMER and STOP_TIMER macros in timer.h? > > Also, define CACHED_BITSTREAM_READER in bitpacked_dec.c before including > > git_bits.h and test the actual implementation again, to see if it makes > > any difference. > > Original code: > 671661910 decicycles in bitpacked_dec, 1 runs, 0 skips > 669736380 decicycles in bitpacked_dec, 1 runs, 0 skips > 669370700 decicycles in bitpacked_dec, 1 runs, 0 skips > > Original code with CACHED_BITSTREAM_READER defined > 352599030 decicycles in bitpacked_dec, 1 runs, 0 skips > 336163810 decicycles in bitpacked_dec, 1 runs, 0 skips > 344628350 decicycles in bitpacked_dec, 1 runs, 0 skips > > My proposed versioned: > 257353330 decicycles in bitpacked_dec, 1 runs, 0 skips > 271527000 decicycles in bitpacked_dec, 1 runs, 0 skips > 252701500 decicycles in bitpacked_dec, 1 runs, 0 skips > > Yes, it's show better performance, so LGTM if nobody have plan to optimize the bitstream function. Devin > > -- > Devin Heitmueller, Senior Software Engineer > LTN Global Communications > o: +1 (301) 363-1001 > w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com > ___ > 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 v6 1/6] ccfifo: Properly handle CEA-708 captions through framerate conversion
On Wed, May 10, 2023 at 7:08 PM Lance Wang wrote:
>
>
> On Sun, May 7, 2023 at 3:03 PM Lance Wang wrote:
>
>> LGTM for the patchset.
>>
>>
> I will help to apply the patchset tomorrow if no further comments. thx.
>
applied, thanks for the effort.
>
>
>> On Sat, May 6, 2023 at 2:13 AM Devin Heitmueller <
>> devin.heitmuel...@ltnglobal.com> wrote:
>>
>>> When transcoding video that contains 708 closed captions, the
>>> caption data is tied to the frames as side data. Simply dropping
>>> or adding frames to change the framerate will result in loss of
>>> data, so the caption data needs to be preserved and reformatted.
>>>
>>> For example, without this patch converting 720p59 to 1080i59
>>> would result in loss of 50% of the caption bytes, resulting in
>>> garbled 608 captions and 708 probably wouldn't render at all.
>>> Further, the frames that are there will have an illegal
>>> cc_count for the target framerate, so some decoders may ignore
>>> the packets entirely.
>>>
>>> Extract the 608 and 708 tuples and insert them onto queues. Then
>>> after dropping/adding frames, re-write the tuples back into the
>>> resulting frames at the appropriate rate given the target
>>> framerate. This includes both having the correct cc_count as
>>> well as clocking out the 608 pairs at the appropriate rate.
>>>
>>> Thanks to Lance Wang , Anton
>>> Khirnov , and Michael Niedermayer <
>>> mich...@niedermayer.cc>
>>> for providing review/feedback.
>>>
>>> Signed-off-by: Devin Heitmueller
>>> ---
>>> libavfilter/Makefile | 1 +
>>> libavfilter/ccfifo.c | 224
>>> +++
>>> libavfilter/ccfifo.h | 110 +
>>> 3 files changed, 335 insertions(+)
>>> create mode 100644 libavfilter/ccfifo.c
>>> create mode 100644 libavfilter/ccfifo.h
>>>
>>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>>> index 482aeaf..68c8f14 100644
>>> --- a/libavfilter/Makefile
>>> +++ b/libavfilter/Makefile
>>> @@ -14,6 +14,7 @@ OBJS = allfilters.o
>>> \
>>> buffersink.o
>>> \
>>> buffersrc.o
>>> \
>>> colorspace.o
>>> \
>>> + ccfifo.o
>>> \
>>> drawutils.o
>>> \
>>> fifo.o
>>> \
>>> formats.o
>>> \
>>> diff --git a/libavfilter/ccfifo.c b/libavfilter/ccfifo.c
>>> new file mode 100644
>>> index 000..5fb68ce
>>> --- /dev/null
>>> +++ b/libavfilter/ccfifo.c
>>> @@ -0,0 +1,224 @@
>>> +/*
>>> + * CEA-708 Closed Captioning FIFO
>>> + * Copyright (c) 2023 LTN Global Communications
>>> + *
>>> + * Author: Devin Heitmueller
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> + */
>>> +
>>> +#include "ccfifo.h"
>>> +
>>> +struct AVCCFifo {
>>> +AVFifo *cc_608_fifo;
>>> +AVFifo *cc_708_fifo;
>>> +AVRational framerate;
>>> +int expected_cc_count;
>>> +int expected_608;
>>> +int cc_detected;
>>> +int passthrough;
>>> +int passthrough_warning;
>>> +void *log_ctx;
>>> +};
>>> +
>>> +#define MAX_CC_ELEMENTS 128
>>> +#define CC_BYTES_PER_ENTRY 3
>>> +
>>> +struct cc_lookup {
>>> +int num;
>>> +int den;
>>> +int cc_count;
>>> +int num_608;
>>
Re: [FFmpeg-devel] [PATCH] libavfilter/yadif_cuda: Fix build breakage
On Fri, May 12, 2023 at 1:12 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> Address build breakage caused by my latest series when compiling
> with CUDA support. Thanks to Paul Mahol for pointing it out.
>
> Signed-off-by: Devin Heitmueller
> ---
> libavfilter/vf_yadif_cuda.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_yadif_cuda.c b/libavfilter/vf_yadif_cuda.c
> index f3f0b56..73f0412 100644
> --- a/libavfilter/vf_yadif_cuda.c
> +++ b/libavfilter/vf_yadif_cuda.c
> @@ -205,7 +205,7 @@ static av_cold void deint_cuda_uninit(AVFilterContext
> *ctx)
> av_frame_free(&y->prev);
> av_frame_free(&y->cur);
> av_frame_free(&y->next);
> -ff_cc_fifo_freep(&y->cc_fifo);
> +ff_ccfifo_freep(&y->cc_fifo);
>
> av_buffer_unref(&s->device_ref);
> s->hwctx = NULL;
> @@ -295,7 +295,7 @@ static int config_output(AVFilterLink *link)
> else
> link->frame_rate = ctx->inputs[0]->frame_rate;
>
> -if (!(s->cc_fifo = ff_cc_fifo_alloc(link->frame_rate, ctx))) {
> +if (!(y->cc_fifo = ff_ccfifo_alloc(link->frame_rate, ctx))) {
> av_log(ctx, AV_LOG_ERROR, "Failure to setup CC FIFO queue\n");
> ret = AVERROR(ENOMEM);
> goto exit;
> --
> 1.8.3.1
>
>
LGTM, will apply.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: add wrap_unicode option
On Fri, May 19, 2023 at 3:59 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> So CJK can be wrapped automatically.
>
> Signed-off-by: Zhao Zhili
> ---
> libavfilter/version.h | 2 +-
> libavfilter/vf_subtitles.c | 13 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index ba8a6fdab2..08779130f5 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -32,7 +32,7 @@
> #include "version_major.h"
>
> #define LIBAVFILTER_VERSION_MINOR 8
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>
>
> #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR,
> \
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index 82e140e986..d6a68e5cdd 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -61,6 +61,7 @@ typedef struct AssContext {
> int original_w, original_h;
> int shaping;
> FFDrawContext draw;
> +int wrap_unicode;
> } AssContext;
>
> #define OFFSET(x) offsetof(AssContext, x)
> @@ -72,6 +73,7 @@ typedef struct AssContext {
> {"original_size", "set the size of the original video (used to scale
> fonts)", OFFSET(original_w), AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0,
> FLAGS }, \
> {"fontsdir", "set the directory containing the fonts to read",
> OFFSET(fontsdir), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,
> FLAGS }, \
> {"alpha", "enable processing of alpha channel",
> OFFSET(alpha), AV_OPT_TYPE_BOOL, {.i64 = 0 },
> 0,1, FLAGS }, \
> +{"wrap_unicode", "break lines according to the Unicode Line
> Breaking Algorithm", OFFSET(wrap_unicode), AV_OPT_TYPE_BOOL, {.i64 = 1
> }, 0,1, FLAGS }, \
>
> /* libass supports a log level ranging from 0 to 7 */
> static const int ass_libavfilter_log_level_map[] = {
> @@ -329,6 +331,17 @@ static av_cold int init_subtitles(AVFilterContext
> *ctx)
> return AVERROR(EINVAL);
> }
>
> +if (ass->wrap_unicode) {
> +#if (LIBASS_VERSION >= 0x01600010)
> +ret = ass_track_set_feature(ass->track, ASS_FEATURE_WRAP_UNICODE,
> 1);
> +if (ret < 0)
> +av_log(ctx, AV_LOG_WARNING, "libass doesn't build with
> ASS_FEATURE_WRAP_UNICODE support\n");
> +#else
> +av_log(ctx, AV_LOG_INFO, "libass version %#x doesn't support
> ASS_FEATURE_WRAP_UNICODE\n",
> + LIBASS_VERSION);
> +#endif
> +}
> +
>
I prefer to enable the feature default(if libass library support) instead
of adding a new option to turn off it(default is on).
Also, if the version is right, then why to check the return?
+#if (LIBASS_VERSION >= 0x01600010)
+ass_track_set_feature(ass->track, ASS_FEATURE_WRAP_UNICODE, 1);
+#endif
+
> /* Open subtitles file */
> ret = avformat_open_input(&fmt, ass->filename, NULL, NULL);
> if (ret < 0) {
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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".
