[FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for ppc64
Hi Please find attached the patch, it enables ffnvcodec and nvenc, nvdec, cuvid for PPC64 architecture. PPC64 support requires Video Codec SDK 9. Thanks Ruta --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-configure-enable-ffnvcodec-nvenc-nvdec-for-ppc64.patch Description: 0001-configure-enable-ffnvcodec-nvenc-nvdec-for-ppc64.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffnvcodec/compat: Fix CUdeviceptr definition for 64bit CPU
Hi Please find the attached patch, it rectifies the definition of cuda device pointer for PPC64 architecture. PPC64 support is present from Video Codec SDK 9. Thanks Ruta --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- 0001-compat-cuda-Fix-CUdeviceptr-definition-for-64bit-CPU.patch Description: 0001-compat-cuda-Fix-CUdeviceptr-definition-for-64bit-CPU.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.
I just searched my inbox again but failed to find that email of question you mentioned. Could you please elaborate your request? What is the preservation for and how is it expected to work? Regards, SUN, Jing From: Vittorio Giovara [mailto:vittorio.giov...@gmail.com] Sent: Saturday, March 9, 2019 4:48 AM To: FFmpeg development discussions and patches Cc: Sun, Jing A ; Huang, Zhengxu ; Jun Zhao ; Tmar, Hassene Subject: Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper. On Fri, Mar 8, 2019 at 4:39 AM Jing SUN mailto:jing.a@intel.com>> wrote: From: Jing Sun mailto:jing.a@intel.com>> base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC V4: - Fix the build error with new API in PR#52 - Fix the encoding hang issue by API change in PR#52 - Fix the last frame dropping issue - Fix the invalid parameter causing segmentation fault issue - Add the support to svt hevc and av1 plugins coexistance - Add the VMAF optimized mode to "-tune" - Add the "-hdr" parameter Apologies if i missed your reply but i think my question was not answered Is there any way to preserve the color matrix/primary/transfer properties during encoding? Thank you -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl
Eugen Hoyos
Sent: Saturday, March 9, 2019 5:07 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v7 1/2] lavc/svt_hevc: add libsvt hevc
encoder wrapper.
2019-03-08 11:36 GMT+01:00, Jing SUN :
> +static void free_buffer(SvtContext *svt_enc) {
> +EB_H265_ENC_INPUT *in_data =
> (EB_H265_ENC_INPUT *)svt_enc->in_buf.pBuffer;
Is the cast necessary?
Or actually: Can't in_data be whatever doesn't produce a warning?
[SUN, Jing] Yes, it's necessary, because the type of pBuffer is uint8_t* in
libsvt_hevc.
> +
> +if (in_data)
> +av_freep(_data);
The condition is unnecessary.
[SUN, Jing] If av_mallocz fails, free_buffer will be called with in_data being
NULL. Checking it avoids unnecessary calling to av_freep in that case.
static void free_buffer(SvtContext *svt_enc)
{
...
if (in_data)
av_freep(_data);
}
static int alloc_buffer(EB_H265_ENC_CONFIGURATION *config, SvtContext *svt_enc)
{
...
in_data = av_mallocz(sizeof(*in_data));
if (!in_data)
goto failed;
...
failed:
free_buffer(svt_enc);
...
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/smoothstreamingenc:add bitrate calculate
ping.
On Thu, Mar 7, 2019 at 11:55 AM Jun Li wrote:
> From: jun
>
> Calculate bitrate based on fragment size, only applied when
> bitrate is not set, for example rtsp source.
>
> Signed-off-by: Jun Li
> ---
> libavformat/smoothstreamingenc.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/smoothstreamingenc.c
> b/libavformat/smoothstreamingenc.c
> index 094712af27..75a47a9668 100644
> --- a/libavformat/smoothstreamingenc.c
> +++ b/libavformat/smoothstreamingenc.c
> @@ -320,11 +320,12 @@ static int ism_write_header(AVFormatContext *s)
> AVDictionary *opts = NULL;
>
> if (!s->streams[i]->codecpar->bit_rate) {
> -av_log(s, AV_LOG_ERROR, "No bit rate set for stream %d\n", i);
> -ret = AVERROR(EINVAL);
> -goto fail;
> +av_log(s, AV_LOG_WARNING, "No bit rate set for stream %d\n",
> i);
> +snprintf(os->dirname, sizeof(os->dirname),
> "%s/QualityLevels(Tmp_%"PRId64")", s->url, i);
> +} else {
> +snprintf(os->dirname, sizeof(os->dirname),
> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
> }
> -snprintf(os->dirname, sizeof(os->dirname),
> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
> +
> if (mkdir(os->dirname, 0777) == -1 && errno != EEXIST) {
> ret = AVERROR(errno);
> av_log(s, AV_LOG_ERROR, "mkdir failed\n");
> @@ -519,7 +520,7 @@ static int ism_flush(AVFormatContext *s, int final)
>
> for (i = 0; i < s->nb_streams; i++) {
> OutputStream *os = >streams[i];
> -char filename[1024], target_filename[1024], header_filename[1024];
> +char filename[1024], target_filename[1024],
> header_filename[1024], curr_dirname[1024];
> int64_t size;
> int64_t start_ts, duration, moof_size;
> if (!os->packets_written)
> @@ -541,6 +542,25 @@ static int ism_flush(AVFormatContext *s, int final)
> size = os->tail_pos - os->cur_start_pos;
> if ((ret = parse_fragment(s, filename, _ts, ,
> _size, size)) < 0)
> break;
> +
> +if (!s->streams[i]->codecpar->bit_rate) {
> +int64_t bitrate = (int64_t) size * 8 * AV_TIME_BASE /
> av_rescale_q(duration, s->streams[i]->time_base, AV_TIME_BASE_Q);
> +if (!bitrate) {
> +av_log(s, AV_LOG_ERROR, "calculating bitrate get zero.");
> +ret = AVERROR(EINVAL);
> +return ret;
> +}
> +
> +av_log(s, AV_LOG_WARNING, "calculated bitrate: %ld\n",
> bitrate);
> +s->streams[i]->codecpar->bit_rate = bitrate;
> +memcpy(curr_dirname, os->dirname, sizeof(os->dirname));
> +snprintf(os->dirname, sizeof(os->dirname),
> "%s/QualityLevels(%"PRId64")", s->url, s->streams[i]->codecpar->bit_rate);
> +snprintf(filename, sizeof(filename), "%s/temp", os->dirname);
> +
> +if ((ret = ff_rename((const char*)curr_dirname, os->dirname,
> s)) < 0)
> +return ret;
> +}
> +
> snprintf(header_filename, sizeof(header_filename),
> "%s/FragmentInfo(%s=%"PRIu64")", os->dirname, os->stream_type_tag,
> start_ts);
> snprintf(target_filename, sizeof(target_filename),
> "%s/Fragments(%s=%"PRIu64")", os->dirname, os->stream_type_tag, start_ts);
> copy_moof(s, filename, header_filename, moof_size);
> --
> 2.17.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] libx264: Update ROI behaviour to match documentation
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Guo, Yejun
> Sent: Tuesday, March 05, 2019 8:46 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/5] libx264: Update ROI behaviour to
> match documentation
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Tuesday, March 05, 2019 8:52 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 2/5] libx264: Update ROI behaviour to
> > match documentation
> >
> > On 28/02/2019 06:38, Guo, Yejun wrote:
> > >> -Original Message-
> > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > >> Of myp...@gmail.com
> > >> Sent: Thursday, February 28, 2019 11:26 AM
> > >> To: FFmpeg development discussions and patches > >> de...@ffmpeg.org>
> > >> Subject: Re: [FFmpeg-devel] [PATCH 2/5] libx264: Update ROI behaviour
> > to
> > >> match documentation
> > >>
> > >> On Thu, Feb 28, 2019 at 10:53 AM Guo, Yejun
> > wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > >> Behalf
> > Of Mark Thompson
> > Sent: Thursday, February 28, 2019 6:00 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 2/5] libx264: Update ROI behaviour
> to
> > match documentation
> >
> > Fix the quantisation offset - use the whole range, and don't change
> the
> > offset size based on bit depth.
> >
> > Use correct bottom/right edge locations (they are offsets from
> > >> bottom/right,
> > not from top/left).
> >
> > Iterate the list in reverse order. The regions are in order of
> > >> decreasing
> > importance, so the most important must be applied last.
> > ---
> > libavcodec/libx264.c | 50 ---
> --
> > ---
> > 1 file changed, 27 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index a3493f393d..475719021e 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -285,16 +285,18 @@ static int X264_frame(AVCodecContext *ctx,
> > AVPacket *pkt, const AVFrame *frame,
> > int nnal, i, ret;
> > x264_picture_t pic_out = {0};
> > int pict_type;
> > +int bit_depth;
> > int64_t *out_opaque;
> > AVFrameSideData *sd;
> >
> > x264_picture_init( >pic );
> > x4->pic.img.i_csp = x4->params.i_csp;
> > #if X264_BUILD >= 153
> > -if (x4->params.i_bitdepth > 8)
> > +bit_depth = x4->params.i_bitdepth;
> > #else
> > -if (x264_bit_depth > 8)
> > +bit_depth = x264_bit_depth;
> > #endif
> > +if (bit_depth > 8)
> > x4->pic.img.i_csp |= X264_CSP_HIGH_DEPTH;
> > x4->pic.img.i_plane = avfmt2_num_planes(ctx->pix_fmt);
> >
> > @@ -359,45 +361,47 @@ static int X264_frame(AVCodecContext *ctx,
> > AVPacket *pkt, const AVFrame *frame,
> > if (frame->interlaced_frame == 0) {
> > int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
> > int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
> > +int qp_range = 51 + 6 * (bit_depth - 8);
> > >>>
> > >>> just found following from "$ ./x264 --fullhelp", not sure what 81 means
> > >> here. Shall we change our qoffset formula accordingly?
> > >>> --qpminSet min QP [0]
> > >>> --qpmaxSet max QP [81]
> >
> > libx264 applies a fixed offset to the QP range to make it nonnegative (by
> > adding QpBdOffsetY). The maximum of 81 therefore corresponds to a bit
> > depth of (81-51)/6+8 = 13 bits, the higher values only being valid at the
> higher
> > depths.
> >
> > I guess that's set for a higher depth than libx264 actually supports to
> > avoid
> > any future problems with range (e.g. 12-bit support would not be an
> > unreasonable feature).
> >
>
> got it, thanks.
>
> > int nb_rois;
> > -AVRegionOfInterest* roi;
> > -float* qoffsets;
> > +const AVRegionOfInterest *roi;
> > +float *qoffsets;
> > qoffsets = av_mallocz_array(mbx * mby,
> > >> sizeof(*qoffsets));
> > if (!qoffsets)
> > return AVERROR(ENOMEM);
> >
> > -nb_rois = sd->size / sizeof(AVRegionOfInterest);
> > -roi = (AVRegionOfInterest*)sd->data;
> > -for (int count = 0; count < nb_rois; count++) {
> > -int starty = FFMIN(mby, roi->top / MB_SIZE);
> >
Re: [FFmpeg-devel] [PATCH] avformat/avformat.h: update the comment from deprecated to new API
> 在 2019年3月11日，上午10:34，James Almer 写道： > > On 2/21/2019 4:16 AM, Steven Liu wrote: >> Signed-off-by: Steven Liu >> --- >> libavformat/avformat.h | 7 +++ >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h >> index fdaffa5bf4..12cc8387ed 100644 >> --- a/libavformat/avformat.h >> +++ b/libavformat/avformat.h >> @@ -36,15 +36,14 @@ >> * into component streams, and the reverse process of muxing - writing >> supplied >> * data in a specified container format. It also has an @ref lavf_io >> * "I/O module" which supports a number of protocols for accessing the data >> (e.g. >> - * file, tcp, http and others). Before using lavf, you need to call >> - * av_register_all() to register all compiled muxers, demuxers and >> protocols. >> + * file, tcp, http and others). >> * Unless you are absolutely sure you won't use libavformat's network >> * capabilities, you should also call avformat_network_init(). >> * >> * A supported input format is described by an AVInputFormat struct, >> conversely >> * an output format is described by AVOutputFormat. You can iterate over all >> - * registered input/output formats using the av_iformat_next() / >> - * av_oformat_next() functions. The protocols layer is not part of the >> public >> + * input/output formats using the av_demuxer_iterate / >> + * av_muxer_iterate() functions. The protocols layer is not part of the >> public > > You can add av_muxer_iterate() to the previous line, and after > rearranging the following sentence you'd save an entire line. > > Like so: > >> * A supported input format is described by an AVInputFormat struct, >> conversely >> * an output format is described by AVOutputFormat. You can iterate over all >> * input/output formats using the av_demuxer_iterate / av_muxer_iterate() >> functions. >> * The protocols layer is not part of the public API, so you can only get the >> names >> * of supported protocols with the avio_enum_protocols() function. Thanks James, new patch submit: https://patchwork.ffmpeg.org/patch/12284/ > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/avformat.h: update the comment from deprecated to new API
Signed-off-by: Steven Liu --- libavformat/avformat.h | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index fdaffa5bf4..3fec074373 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -36,17 +36,15 @@ * into component streams, and the reverse process of muxing - writing supplied * data in a specified container format. It also has an @ref lavf_io * "I/O module" which supports a number of protocols for accessing the data (e.g. - * file, tcp, http and others). Before using lavf, you need to call - * av_register_all() to register all compiled muxers, demuxers and protocols. + * file, tcp, http and others). * Unless you are absolutely sure you won't use libavformat's network * capabilities, you should also call avformat_network_init(). * * A supported input format is described by an AVInputFormat struct, conversely * an output format is described by AVOutputFormat. You can iterate over all - * registered input/output formats using the av_iformat_next() / - * av_oformat_next() functions. The protocols layer is not part of the public - * API, so you can only get the names of supported protocols with the - * avio_enum_protocols() function. + * input/output formats using the av_demuxer_iterate / av_muxer_iterate() functions. + * The protocols layer is not part of the public API, so you can only get the names + * of supported protocols with the avio_enum_protocols() function. * * Main lavf structure used for both muxing and demuxing is AVFormatContext, * which exports all information about the file being read or written. As with -- 2.15.2 (Apple Git-101.1) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of interest sidedata
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of myp...@gmail.com
> Sent: Monday, March 11, 2019 11:05 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Jun Zhao
> Subject: Re: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of
> interest sidedata
>
> On Mon, Mar 11, 2019 at 10:51 AM Guo, Yejun
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Jun Zhao
> > > Sent: Sunday, March 10, 2019 9:17 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Jun Zhao
> > > Subject: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of
> > > interest sidedata
> > >
> > > From: Jun Zhao
> > >
> > > support regions of interest sidedata
> > >
> > > Signed-off-by: Jun Zhao
> > > ---
> > > libavfilter/vf_showinfo.c | 33
> +
> > > 1 files changed, 33 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > > index e41c330..d0e140f 100644
> > > --- a/libavfilter/vf_showinfo.c
> > > +++ b/libavfilter/vf_showinfo.c
> > > @@ -111,6 +111,36 @@ static void dump_stereo3d(AVFilterContext *ctx,
> > > AVFrameSideData *sd)
> > > av_log(ctx, AV_LOG_INFO, " (inverted)");
> > > }
> > >
> > > +static void dump_roi(AVFilterContext *ctx, AVFrameSideData *sd)
> > > +{
> > > +AVRegionOfInterest *roi;
> > > +int nb_rois;
> > > +
> > > +if (sd->size < sizeof(*roi)) {
> > > +av_log(ctx, AV_LOG_INFO, "invalid data");
> > > +return;
> > > +}
> >
> > it is possible.
> It's a surprised behavior for me, how to check the corrupted side data
> for this case? I don't like the self_size field in this case in fact.
it is for ABI compatible, just imaging that we expand the struct, while the
user is using an old version and there is only one roi in the sd buffer.
For this case, sd->size is less than sizeof(*roi).
> >
> > > +
> > > +roi = (AVRegionOfInterest *)sd->data;
> > > +if (roi->self_size == 0 || sd->size % roi->self_size != 0) {
> > > +av_log(ctx, AV_LOG_INFO, "invalid ROI side data");
> > > +return;
> > > +}
> > > +nb_rois = sd->size / roi->self_size;
> > > +
> > > +av_log(ctx, AV_LOG_INFO, "Regions Of Interest(RoI) information: ");
> > > +for (int index = 0; index < nb_rois; index++) {
> > > +av_log(ctx, AV_LOG_INFO, "index: %d, region: (%d %d)/(%d %d),
> qp
> > > offset: %d/%d",
> > > + index, roi->left, roi->top, roi->right, roi->bottom, roi-
> >qoffset.num,
> > > roi->qoffset.den);
> > > +
> > > +if (roi->self_size == 0)
> > > +av_log(ctx, AV_LOG_INFO,
> > > + "AVRegionOfInterest.self_size must be set to
> > > sizeof(AVRegionOfInterest).\n");
> >
> > we can skip this since the first roi->self_size is tested.
> >
> If we have N ROIs, we just need to check the first roi entry for
> roi->self_size? It's the other surprised behavior for me
forgot to mention the next line together.
let's save the first roi->self_size and so the next line will be:
roi = (AVRegionOfInterest *)((char *)roi + self_size);
The self_size here is to indicates the struct size when the user uses it.
It is actually enough to just set the first roi.
btw, there is an issue in my original code pushed, and Mark Thompson has given
better code which has not been pushed yet, except saving the first
roi->self_size.
(I just realized this, and will comment MarkT again).
> > > +
> > > +roi = (AVRegionOfInterest *)((char *)roi + roi->self_size);
> > > +}
> > > +}
> > > +
> > > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > > {
> > > const char *color_range_str = av_color_range_name(frame-
> > > >color_range);
> > > @@ -246,6 +276,9 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame
> > > *frame)
> > > case AV_FRAME_DATA_AFD:
> > > av_log(ctx, AV_LOG_INFO, "afd: value of %"PRIu8,
> > > sd->data[0]);
> > > break;
> > > +case AV_FRAME_DATA_REGIONS_OF_INTEREST:
> > > +dump_roi(ctx, sd);
> > > +break;
> > > default:
> > > av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > > bytes)",
> > > sd->type, sd->size);
> > > --
> > > 1.7.1
> > >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of interest sidedata
On Mon, Mar 11, 2019 at 10:51 AM Guo, Yejun wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Jun Zhao
> > Sent: Sunday, March 10, 2019 9:17 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao
> > Subject: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of
> > interest sidedata
> >
> > From: Jun Zhao
> >
> > support regions of interest sidedata
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/vf_showinfo.c | 33 +
> > 1 files changed, 33 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index e41c330..d0e140f 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -111,6 +111,36 @@ static void dump_stereo3d(AVFilterContext *ctx,
> > AVFrameSideData *sd)
> > av_log(ctx, AV_LOG_INFO, " (inverted)");
> > }
> >
> > +static void dump_roi(AVFilterContext *ctx, AVFrameSideData *sd)
> > +{
> > +AVRegionOfInterest *roi;
> > +int nb_rois;
> > +
> > +if (sd->size < sizeof(*roi)) {
> > +av_log(ctx, AV_LOG_INFO, "invalid data");
> > +return;
> > +}
>
> it is possible.
It's a surprised behavior for me, how to check the corrupted side data
for this case? I don't like the self_size field in this case in fact.
>
> > +
> > +roi = (AVRegionOfInterest *)sd->data;
> > +if (roi->self_size == 0 || sd->size % roi->self_size != 0) {
> > +av_log(ctx, AV_LOG_INFO, "invalid ROI side data");
> > +return;
> > +}
> > +nb_rois = sd->size / roi->self_size;
> > +
> > +av_log(ctx, AV_LOG_INFO, "Regions Of Interest(RoI) information: ");
> > +for (int index = 0; index < nb_rois; index++) {
> > +av_log(ctx, AV_LOG_INFO, "index: %d, region: (%d %d)/(%d %d), qp
> > offset: %d/%d",
> > + index, roi->left, roi->top, roi->right, roi->bottom,
> > roi->qoffset.num,
> > roi->qoffset.den);
> > +
> > +if (roi->self_size == 0)
> > +av_log(ctx, AV_LOG_INFO,
> > + "AVRegionOfInterest.self_size must be set to
> > sizeof(AVRegionOfInterest).\n");
>
> we can skip this since the first roi->self_size is tested.
>
If we have N ROIs, we just need to check the first roi entry for
roi->self_size? It's the other surprised behavior for me
> > +
> > +roi = (AVRegionOfInterest *)((char *)roi + roi->self_size);
> > +}
> > +}
> > +
> > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > {
> > const char *color_range_str = av_color_range_name(frame-
> > >color_range);
> > @@ -246,6 +276,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *frame)
> > case AV_FRAME_DATA_AFD:
> > av_log(ctx, AV_LOG_INFO, "afd: value of %"PRIu8, sd->data[0]);
> > break;
> > +case AV_FRAME_DATA_REGIONS_OF_INTEREST:
> > +dump_roi(ctx, sd);
> > +break;
> > default:
> > av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > bytes)",
> > sd->type, sd->size);
> > --
> > 1.7.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of interest sidedata
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jun Zhao
> Sent: Sunday, March 10, 2019 9:17 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao
> Subject: [FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of
> interest sidedata
>
> From: Jun Zhao
>
> support regions of interest sidedata
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_showinfo.c | 33 +
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index e41c330..d0e140f 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -111,6 +111,36 @@ static void dump_stereo3d(AVFilterContext *ctx,
> AVFrameSideData *sd)
> av_log(ctx, AV_LOG_INFO, " (inverted)");
> }
>
> +static void dump_roi(AVFilterContext *ctx, AVFrameSideData *sd)
> +{
> +AVRegionOfInterest *roi;
> +int nb_rois;
> +
> +if (sd->size < sizeof(*roi)) {
> +av_log(ctx, AV_LOG_INFO, "invalid data");
> +return;
> +}
it is possible.
> +
> +roi = (AVRegionOfInterest *)sd->data;
> +if (roi->self_size == 0 || sd->size % roi->self_size != 0) {
> +av_log(ctx, AV_LOG_INFO, "invalid ROI side data");
> +return;
> +}
> +nb_rois = sd->size / roi->self_size;
> +
> +av_log(ctx, AV_LOG_INFO, "Regions Of Interest(RoI) information: ");
> +for (int index = 0; index < nb_rois; index++) {
> +av_log(ctx, AV_LOG_INFO, "index: %d, region: (%d %d)/(%d %d), qp
> offset: %d/%d",
> + index, roi->left, roi->top, roi->right, roi->bottom,
> roi->qoffset.num,
> roi->qoffset.den);
> +
> +if (roi->self_size == 0)
> +av_log(ctx, AV_LOG_INFO,
> + "AVRegionOfInterest.self_size must be set to
> sizeof(AVRegionOfInterest).\n");
we can skip this since the first roi->self_size is tested.
> +
> +roi = (AVRegionOfInterest *)((char *)roi + roi->self_size);
> +}
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
> const char *color_range_str = av_color_range_name(frame-
> >color_range);
> @@ -246,6 +276,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> case AV_FRAME_DATA_AFD:
> av_log(ctx, AV_LOG_INFO, "afd: value of %"PRIu8, sd->data[0]);
> break;
> +case AV_FRAME_DATA_REGIONS_OF_INTEREST:
> +dump_roi(ctx, sd);
> +break;
> default:
> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> bytes)",
> sd->type, sd->size);
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avformat.h: update the comment from deprecated to new API
On 2/21/2019 4:16 AM, Steven Liu wrote: > Signed-off-by: Steven Liu > --- > libavformat/avformat.h | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > index fdaffa5bf4..12cc8387ed 100644 > --- a/libavformat/avformat.h > +++ b/libavformat/avformat.h > @@ -36,15 +36,14 @@ > * into component streams, and the reverse process of muxing - writing > supplied > * data in a specified container format. It also has an @ref lavf_io > * "I/O module" which supports a number of protocols for accessing the data > (e.g. > - * file, tcp, http and others). Before using lavf, you need to call > - * av_register_all() to register all compiled muxers, demuxers and protocols. > + * file, tcp, http and others). > * Unless you are absolutely sure you won't use libavformat's network > * capabilities, you should also call avformat_network_init(). > * > * A supported input format is described by an AVInputFormat struct, > conversely > * an output format is described by AVOutputFormat. You can iterate over all > - * registered input/output formats using the av_iformat_next() / > - * av_oformat_next() functions. The protocols layer is not part of the public > + * input/output formats using the av_demuxer_iterate / > + * av_muxer_iterate() functions. The protocols layer is not part of the > public You can add av_muxer_iterate() to the previous line, and after rearranging the following sentence you'd save an entire line. Like so: > * A supported input format is described by an AVInputFormat struct, > conversely > * an output format is described by AVOutputFormat. You can iterate over all > * input/output formats using the av_demuxer_iterate / av_muxer_iterate() > functions. > * The protocols layer is not part of the public API, so you can only get the > names > * of supported protocols with the avio_enum_protocols() function. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avformat.h: update the comment from deprecated to new API
> 在 2019年2月21日，下午3:16，Steven Liu 写道： > > Signed-off-by: Steven Liu > --- > libavformat/avformat.h | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > index fdaffa5bf4..12cc8387ed 100644 > --- a/libavformat/avformat.h > +++ b/libavformat/avformat.h > @@ -36,15 +36,14 @@ > * into component streams, and the reverse process of muxing - writing > supplied > * data in a specified container format. It also has an @ref lavf_io > * "I/O module" which supports a number of protocols for accessing the data > (e.g. > - * file, tcp, http and others). Before using lavf, you need to call > - * av_register_all() to register all compiled muxers, demuxers and protocols. > + * file, tcp, http and others). > * Unless you are absolutely sure you won't use libavformat's network > * capabilities, you should also call avformat_network_init(). > * > * A supported input format is described by an AVInputFormat struct, > conversely > * an output format is described by AVOutputFormat. You can iterate over all > - * registered input/output formats using the av_iformat_next() / > - * av_oformat_next() functions. The protocols layer is not part of the public > + * input/output formats using the av_demuxer_iterate / > + * av_muxer_iterate() functions. The protocols layer is not part of the > public > * API, so you can only get the names of supported protocols with the > * avio_enum_protocols() function. > * > -- > 2.15.2 (Apple Git-101.1) > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mxfenc: allow user comments for opatom muxer
From: Mark Reid
This patch restores the ability to add user comments for the opatom_mxf muxer.
The ability seems to have been disabled in d9726893f31.
---
doc/muxers.texi | 2 +-
libavformat/mxfenc.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 372fab2f92..764102bf4b 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1629,7 +1629,7 @@ ffmpeg -i file.mpg -c copy \
out.ts
@end example
-@section mxf, mxf_d10
+@section mxf, mxf_d10, mxf_opatom
MXF muxer.
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 032ee3bf3d..8c6db94865 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -3095,6 +3095,8 @@ static const AVOption opatom_options[] = {
{ "mxf_audio_edit_rate", "Audio edit rate for timecode",
offsetof(MXFContext, audio_edit_rate), AV_OPT_TYPE_RATIONAL,
{.dbl=25}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
MXF_COMMON_OPTIONS
+{ "store_user_comments", "",
+ offsetof(MXFContext, store_user_comments), AV_OPT_TYPE_BOOL, {.i64 = 1},
0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{ NULL },
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for a new H.264 codec
2019-02-25 21:41 GMT+01:00, Yufei He : > Please review this one. The library needs non-free in configure and please use dynamic linking, not loading at run-time. Please find out what top-posting means and avoid it here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/pnm: Optimize reading loop in pnm_get()
Fixes: Timeout 13149 (5sec -> 3sec), 13166 (11sec -> 7sec), 13430 (5sec -> 3sec)
Fixes:
13149/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGM_fuzzer-5760833622114304
Fixes:
13166/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5763216322330624
Fixes:
13430/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PPM_fuzzer-5758658334425088
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index 17926f256f..a9771710c2 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -52,12 +52,13 @@ static void pnm_get(PNMContext *sc, char *str, int buf_size)
}
s = str;
-while (bs < end && !pnm_space(c)) {
-if ((s - str) < buf_size - 1)
-*s++ = c;
+while (bs < end && !pnm_space(c) && (s - str) < buf_size - 1) {
+*s++ = c;
c = *bs++;
}
*s = '\0';
+while (bs < end && !pnm_space(c))
+c = *bs++;
sc->bytestream = bs;
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/dfa: Check the chunk header is not truncated
Fixes: Timeout (11sec -> 3sec)
Fixes:
13218/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-5661074316066816
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/dfa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dfa.c b/libavcodec/dfa.c
index 970175fb73..c6106b9397 100644
--- a/libavcodec/dfa.c
+++ b/libavcodec/dfa.c
@@ -355,6 +355,8 @@ static int dfa_decode_frame(AVCodecContext *avctx,
bytestream2_init(, avpkt->data, avpkt->size);
while (bytestream2_get_bytes_left() > 0) {
+if (bytestream2_get_bytes_left() < 12)
+return AVERROR_INVALIDDATA;
bytestream2_skip(, 4);
chunk_size = bytestream2_get_le32();
chunk_type = bytestream2_get_le32();
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/10] avformat/matroskadec: Remove non-incremental parsing of clusters
Michael Niedermayer: > On Fri, Mar 08, 2019 at 10:25:59AM +0100, Andreas Rheinhardt wrote: >> When the new incremental parser was introduced, the old parser was >> kept, because the new parser was unable to handle the way SSA packets >> are put into Matroska. But since 2014 (since >> c7d8dbad14ed5fa3c217a4fc1790021d6c0b6416) this is no longer needed, so >> that the old parser can be completely removed. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavformat/matroskadec.c | 72 ++- >> 1 file changed, 10 insertions(+), 62 deletions(-) > > This affects seeking: > > libavformat/tests/seek > issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv > -duration 400 >oldseek > > The file appears to be available here: > https://samples.ffmpeg.org/Matroska/matrix/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv > > --- oldseek 2019-03-08 23:08:21.380042329 +0100 > +++ newseek 2019-03-08 23:08:02.048041745 +0100 > @@ -8,7 +8,7 @@ > ret: 0 st:13 flags:1 dts: 86.75 pts: 86.75 pos: -1 size: > 50436 > ret:-1 st: 1 flags:0 ts: 250.577000 > ret: 0 st: 1 flags:1 ts: 13.471000 > -ret: 0 st:13 flags:1 dts: 1.776000 pts: 1.776000 pos: -1 size: > 50436 > +ret: 0 st:13 flags:1 dts: 0.00 pts: 0.00 pos: -1 size: > 50436 > ret:-1 st: 2 flags:0 ts: 176.365000 > ret: 0 st: 2 flags:1 ts: 339.259000 > ret: 0 st:13 flags:1 dts: 145.08 pts: 145.08 pos: -1 > size: 50436 > This is not unexpected. The reason is that the old parser always parses a whole cluster at once while the new parser parses clusters incrementally, i.e. one block (I use block as a general term for SimpleBlock or BlockGroup) at a time. The goal of incremental parsing was reduced latency (and with my patch #6 one also achieves a reduction of memory used and an increase in performance as well). With the old parser, the very first cluster gets parsed during avformat_find_stream_info() and index entries were created for all the keyframes contained therein (the cues only contain entries for the main video track, so this only affects the other tracks). The 1.776 pts corresponds to the block with the highest timestamp for track #1 (or track #2 in Matroska's counting) in the first cluster (with a timestamp of 1776ms). With the incremental parser, only one block of the audio track gets parsed during avformat_find_stream_info() (it has a timestamp of 0) and so only one index entry gets created for it. So when the seek based upon the audio track is performed, the used index point has a timestamp of either 0ms or 1776ms. Then the current_dts is updated based upon this timestamp. Now this file has an attached picture which gets translated into its own track and upon every seek this picture will be put into the raw_packet_buffer from which it will be read by ff_read_packet as the first packet after each seek. Given that this packet doesn't have timestamps, the timestamp will be set equal to current_dts (in compute_pkt_fields()). Hence the discrepancy. Btw: Because of things like this, a fate test had to be changed during the initial introduction of incremental parsing (in 8336eb6f85e4b94b9c198b16bd0ac4178f4dba86). - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Maksym Veremeyenko (12019-03-10): > removal code authors should find the core of their hates: either NDI > technology or NewTek company Please control your wording. Hate is a toxic irrational emotion. Fighting companies that produce non-Libre software and want to profit from the efforts of the Libre software community nonetheless is a rational political stance. > FYI, > from my experience NewTek and Blackmagic are only two adequate > SDK-for-developers companies that does not requires you signing NDAs and > make it close-source from beginning... Your expectations are very low. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On 10.03.2019 19:04, Martin Vignali wrote: [...] The interest of sending a patch to this project is to benefit of the entire infrastructure around the ffmpeg project. Not the pleasure to read this mailing list. Taking time to have a feature/enhancement integrate inside this project, are interesting only if at the end, the integrated feature stay, otherwise is just a waste of time (for contributors, reviewers, and users). i completely agree with such statement. code part for NDI support is 100% satisfy condition of ffmpeg development - it placed in *non-free* list. removal code authors should find the core of their hates: either NDI technology or NewTek company FYI, from my experience NewTek and Blackmagic are only two adequate SDK-for-developers companies that does not requires you signing NDAs and make it close-source from beginning... -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Andrey Semashev (12019-03-10): > Yes. It doesn't make it less true, IMO. It makes it neither true nor false but subject to personal judgements. > I'm pointing out that there seem to be no technical reason for the removal, > but instead there is a political one. Indeed. > And apparently, there are users of the > code out there, who will be affected. Indeed. And we would be RESPONSIBLE for that. But the party CULPABLE for that is the party that makes the non-Libre software. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Martin Vignali (12019-03-10): > It's about the lack of consistency on this topic, and the lack of a clear > definition (documented at the project level, to avoid precisely this kind > of situation) As I said: if there is support for removing ALL non-free stuff, I am behind it too. Is it clear enough? > And now the same functionality needs to be removed because the original > creator of ndi was not nice ! I guess next time we will ask somebody to read tea leaves to know whether the company behind a piece of software or hardware will turn out to be a bully against Libre software developers. Are you fluent in tea leaves? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On 3/10/19 9:39 PM, Nicolas George wrote: Andrey Semashev (12019-03-10): But I think decisions like this should be based exclusively on technical grounds. Political or populist arguments are not valid for technical decisions, regardless how "good" or aligned with your personal views they might seem. Do you realize that this statement is itself a political one? Yes. It doesn't make it less true, IMO. Note that I'm not arguing for or against the removal. I don't really care. I'm pointing out that there seem to be no technical reason for the removal, but instead there is a political one. And apparently, there are users of the code out there, who will be affected. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Le dim. 10 mars 2019 à 18:55, Nicolas George a écrit : > Martin Vignali (12019-03-10): > > Le dim. 10 mars 2019 à 17:03, Nicolas George a écrit : > > > It's just ruining his effort to integrate this feature inside the > project. > > Please do not attribute your sentences to me. > > > This discussion just send bad message to contributors. > > If you consider "we do not want proprietary software" bad, then we will > just have to agree to disagree. > > Regards, > > -- > Nicolas George > > It's not about the choice to integrate or not proprietary libraries It's about the lack of consistency on this topic, and the lack of a clear definition (documented at the project level, to avoid precisely this kind of situation) You tell the contributor of this feature in July 2017 (it's your words): "Thanks for the patch. It looks promising." Nobody says anything about it for several months, this feature is even part of the release notes of the 3.4 (October 2017). And now the same functionality needs to be removed because the original creator of ndi was not nice ! Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Andrey Semashev (12019-03-10): > But I think decisions like this should be based exclusively on > technical grounds. Political or populist arguments are not valid for > technical decisions, regardless how "good" or aligned with your personal > views they might seem. Do you realize that this statement is itself a political one? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On 3/10/19 8:28 PM, Jean-Baptiste Kempf wrote: On Sun, 10 Mar 2019, at 18:04, Martin Vignali wrote: This discussion just send bad message to contributors. You're just encourage them to keep code improvement in their own version of ffmpeg. Maintaining an FFmpeg is hard and costly. This gives those people incentives to use open source libraries or write new ones. I would say, the message is quite the opposite. I'm not an active member of the community, so please disregard my opinion if you will. But I think decisions like this should be based exclusively on technical grounds. Political or populist arguments are not valid for technical decisions, regardless how "good" or aligned with your personal views they might seem. That is, if you care about technical quality of your project and not just "fighting the good fight". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Martin Vignali (12019-03-10): > Le dim. 10 mars 2019 à 17:03, Nicolas George a écrit : > > It's just ruining his effort to integrate this feature inside the project. Please do not attribute your sentences to me. > This discussion just send bad message to contributors. If you consider "we do not want proprietary software" bad, then we will just have to agree to disagree. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Hi, On Sun, Mar 10, 2019 at 1:04 PM Martin Vignali wrote: > But if this is the project policy... > Yes, I would like to propose to make this project policy. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On Sun, 10 Mar 2019, at 18:04, Martin Vignali wrote: > This discussion just send bad message to contributors. > You're just encourage them to keep code improvement in their own version of > ffmpeg. Maintaining an FFmpeg is hard and costly. This gives those people incentives to use open source libraries or write new ones. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Le dim. 10 mars 2019 à 17:03, Nicolas George a écrit : > Maksym Veremeyenko (12019-03-10): > > code you going to remove was not made by you nor NewTek company. > > > > if you have a problem with NewTek company - do a step to solve it - dont > > ruin a code. > > Nobody is ruining any code. Just removing it from a prominent > distribution and development platform. > > It's just ruining his effort to integrate this feature inside the project. The interest of sending a patch to this project is to benefit of the entire infrastructure around the ffmpeg project. Not the pleasure to read this mailing list. Taking time to have a feature/enhancement integrate inside this project, are interesting only if at the end, the integrated feature stay, otherwise is just a waste of time (for contributors, reviewers, and users). This discussion just send bad message to contributors. You're just encourage them to keep code improvement in their own version of ffmpeg. But if this is the project policy... Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/imm4: Unreference previous frame on frame size change
On Sun, Mar 10, 2019 at 09:15:40AM +0100, Paul B Mahol wrote:
> On 3/10/19, Michael Niedermayer wrote:
> > Fixes: Out of array access
> > Fixes:
> > 13552/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IMM4_fuzzer-5767949648920576
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/imm4.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/imm4.c b/libavcodec/imm4.c
> > index b66689acab..1a4d0decd7 100644
> > --- a/libavcodec/imm4.c
> > +++ b/libavcodec/imm4.c
> > @@ -446,11 +446,13 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data,
> > return AVERROR_PATCHWELCOME;
> > }
> >
> > -if (!frame->key_frame &&
> > -(avctx->width != width ||
> > - avctx->height != height)) {
> > -av_log(avctx, AV_LOG_ERROR, "Frame size change is unsupported.\n");
> > -return AVERROR_INVALIDDATA;
> > +if (avctx->width != width ||
> > +avctx->height != height) {
> > +if (!frame->key_frame) {
> > +av_log(avctx, AV_LOG_ERROR, "Frame size change is
> > unsupported.\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +av_frame_unref(s->prev_frame);
> > }
>
> ok
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Maksym Veremeyenko (12019-03-10): > code you going to remove was not made by you nor NewTek company. > > if you have a problem with NewTek company - do a step to solve it - dont > ruin a code. Nobody is ruining any code. Just removing it from a prominent distribution and development platform. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On 09.03.2019 22:12, Kieran Kunhya wrote: They have not responded to any communications: https://trac.ffmpeg.org/ticket/7589 code you going to remove was not made by you nor NewTek company. if you have a problem with NewTek company - do a step to solve it - dont ruin a code. -- Maksym Veremeyenko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] lavfi/showinfo: support regions of interest sidedata
From: Jun Zhao
support regions of interest sidedata
Signed-off-by: Jun Zhao
---
libavfilter/vf_showinfo.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index e41c330..d0e140f 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -111,6 +111,36 @@ static void dump_stereo3d(AVFilterContext *ctx,
AVFrameSideData *sd)
av_log(ctx, AV_LOG_INFO, " (inverted)");
}
+static void dump_roi(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+AVRegionOfInterest *roi;
+int nb_rois;
+
+if (sd->size < sizeof(*roi)) {
+av_log(ctx, AV_LOG_INFO, "invalid data");
+return;
+}
+
+roi = (AVRegionOfInterest *)sd->data;
+if (roi->self_size == 0 || sd->size % roi->self_size != 0) {
+av_log(ctx, AV_LOG_INFO, "invalid ROI side data");
+return;
+}
+nb_rois = sd->size / roi->self_size;
+
+av_log(ctx, AV_LOG_INFO, "Regions Of Interest(RoI) information: ");
+for (int index = 0; index < nb_rois; index++) {
+av_log(ctx, AV_LOG_INFO, "index: %d, region: (%d %d)/(%d %d), qp
offset: %d/%d",
+ index, roi->left, roi->top, roi->right, roi->bottom,
roi->qoffset.num, roi->qoffset.den);
+
+if (roi->self_size == 0)
+av_log(ctx, AV_LOG_INFO,
+ "AVRegionOfInterest.self_size must be set to
sizeof(AVRegionOfInterest).\n");
+
+roi = (AVRegionOfInterest *)((char *)roi + roi->self_size);
+}
+}
+
static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
{
const char *color_range_str = av_color_range_name(frame->color_range);
@@ -246,6 +276,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
case AV_FRAME_DATA_AFD:
av_log(ctx, AV_LOG_INFO, "afd: value of %"PRIu8, sd->data[0]);
break;
+case AV_FRAME_DATA_REGIONS_OF_INTEREST:
+dump_roi(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
sd->type, sd->size);
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On Sun, 10 Mar 2019, Jean-Baptiste Kempf wrote: On Sat, 9 Mar 2019, at 21:58, Marton Balint wrote: On Sat, 9 Mar 2019, Dennis Mungai wrote: > On Sat, 9 Mar 2019 at 23:19, Carl Eugen Hoyos wrote: >> 2019-03-09 21:16 GMT+01:00, Carl Eugen Hoyos : >> > 2019-03-09 21:12 GMT+01:00, Kieran Kunhya : >> >> They have not responded to any communications: >> >> https://trac.ffmpeg.org/ticket/7589 >> > >> > Missing minor version bump >> >> Sorry about this, I used the wrong patch reading tool... >> >> > and please also post a news entry. >> >> Please do, Carl Eugen >> >> > Thanks for this. > It's long overdue (3 months is more than enough time to respond and act on > a license violation). Huh? Newtek removed the nonfree ffmpeg from their site, that was their response. So the company is no longer violating the license. Removal of past violations does not magically erase the past infrigement. Legally, OK. But as far as I know we typically ask license violators to either release the source code, or stop distribuiting the violating code. And a company that does either usually goes into the good-guys bucket. Not here. So removing NDI to punish a them for past violations does not seem fair to me. It was also unfortunate to give them ultimatums. If you look at the trac ticket, we look like the bully, and not newtek. A reasonable request would have been to ask them for protocol specs. Maybe can you do that? You are a president of a quite famous organization after all, maybe they will consider it. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Marton Balint (12019-03-09): > You are not removing ndi because of the license violation, you are removing > it because you don't like it. Let us assume, for the rice wine of the argument, that you are right: that we want to remove it because we do not like them. But ask yourself: why do we not like them. And he answer would be: because they make a habit of infringing Libre Software licenses when they can get away with it. Removing this is not just something internal to FFmpeg: it is an important Libre Software project helping to hold the line against hoarders. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Ronald S. Bultje (12019-03-09): > I would not be against removing all closed-source support. I would get behind that. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On Sat, 9 Mar 2019, at 23:58, Ronald S. Bultje wrote: > On Sat, Mar 9, 2019 at 4:02 PM Martin Vignali > I would not be against removing all closed-source support. I have voiced > this before in the realvideo discussion: > https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer Agreed. HwAccel and access to hardware are different (See the GPL system library), but else where is the limit of what to integrate. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
On Sat, 9 Mar 2019, at 21:58, Marton Balint wrote: > On Sat, 9 Mar 2019, Dennis Mungai wrote: > > On Sat, 9 Mar 2019 at 23:19, Carl Eugen Hoyos wrote: > >> 2019-03-09 21:16 GMT+01:00, Carl Eugen Hoyos : > >> > 2019-03-09 21:12 GMT+01:00, Kieran Kunhya : > >> >> They have not responded to any communications: > >> >> https://trac.ffmpeg.org/ticket/7589 > >> > > >> > Missing minor version bump > >> > >> Sorry about this, I used the wrong patch reading tool... > >> > >> > and please also post a news entry. > >> > >> Please do, Carl Eugen > >> > >> > > Thanks for this. > > It's long overdue (3 months is more than enough time to respond and act on > > a license violation). > > Huh? Newtek removed the nonfree ffmpeg from their site, that was their > response. So the company is no longer violating the license. Removal of past violations does not magically erase the past infrigement. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/imm4: Unreference previous frame on frame size change
On 3/10/19, Michael Niedermayer wrote:
> Fixes: Out of array access
> Fixes:
> 13552/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IMM4_fuzzer-5767949648920576
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/imm4.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/imm4.c b/libavcodec/imm4.c
> index b66689acab..1a4d0decd7 100644
> --- a/libavcodec/imm4.c
> +++ b/libavcodec/imm4.c
> @@ -446,11 +446,13 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
> return AVERROR_PATCHWELCOME;
> }
>
> -if (!frame->key_frame &&
> -(avctx->width != width ||
> - avctx->height != height)) {
> -av_log(avctx, AV_LOG_ERROR, "Frame size change is unsupported.\n");
> -return AVERROR_INVALIDDATA;
> +if (avctx->width != width ||
> +avctx->height != height) {
> +if (!frame->key_frame) {
> +av_log(avctx, AV_LOG_ERROR, "Frame size change is
> unsupported.\n");
> +return AVERROR_INVALIDDATA;
> +}
> +av_frame_unref(s->prev_frame);
> }
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
