Re: [FFmpeg-devel] [PATCH 3/5] doc/examples/vaapi_transcode: Simplify loop

2024-04-23 Thread myp...@gmail.com
On Wed, Apr 24, 2024 at 9:45 AM Michael Niedermayer
 wrote:
>
> Fixes: CID1428858(1/2) Logically dead code
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/examples/vaapi_transcode.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/doc/examples/vaapi_transcode.c b/doc/examples/vaapi_transcode.c
> index 8367cb30404..e1b7a438836 100644
> --- a/doc/examples/vaapi_transcode.c
> +++ b/doc/examples/vaapi_transcode.c
> @@ -215,10 +215,8 @@ static int dec_enc(AVPacket *pkt, const AVCodec 
> *enc_codec)
>
>  fail:
>  av_frame_free(&frame);
> -if (ret < 0)
> -return ret;
>  }
> -return 0;
> +return ret;
>  }
>
it's ok, thx
>  int main(int argc, char **argv)
> --
> 2.43.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/4] lavc/vvc_parser: Fixed the has_b_frames setting

2024-04-20 Thread myp...@gmail.com
On Sat, Apr 20, 2024 at 11:50 AM Nuo Mi  wrote:
>
> On Fri, Apr 19, 2024 at 9:55 PM Jun Zhao  wrote:
>
> > From: Jun Zhao 
> >
> > has_b_frames used in decoder for size of the frame reordering
> > buffer, setting this field from dpb_max_num_reorder_pics.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/vvc_parser.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
> > index a0e10e1a7c..5373875aae 100644
> > --- a/libavcodec/vvc_parser.c
> > +++ b/libavcodec/vvc_parser.c
> > @@ -185,8 +185,8 @@ static void set_parser_ctx(AVCodecParserContext *s,
> > AVCodecContext *avctx,
> >  avctx->color_range =
> >  sps->vui.vui_full_range_flag ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> >
> > -avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
> > -   sps->sps_max_sublayers_minus1;
> > +avctx->has_b_frames =
> > +
> > sps->sps_dpb_params.dpb_max_num_reorder_pics[sps->sps_max_sublayers_minus1];
> >
> Should we relocate this to the decoder? Other codecs typically set this
> parameter in the decoder.
>
I think the part that needs to be refactored is like the 264/265
decoder, but before the refactoring, we need to fix the issue first.
> thank you
>
> >
> >  if (sps->sps_ptl_dpb_hrd_params_present_flag &&
> >  sps->sps_timing_hrd_params_present_flag) {
> > --
> > 2.25.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 4/4] lavc/vvc/refs: Use dpb_max_num_reorder_pics to control output

2024-04-20 Thread myp...@gmail.com
Send it privately via email


On Sat, Apr 20, 2024 at 11:55 AM Nuo Mi  wrote:
>
> Hi Barry and Eliny,
> LGTM.
> Thank you for the patch.
> Is it possible to provide the clip so we can add it to our CI?
>
>  ci like https://github.com/ffvvc/FFmpeg/actions
>
>

> On Fri, Apr 19, 2024 at 9:48 PM Jun Zhao  wrote:
>
> > From: Jun Zhao 
> >
> > Use dpb_max_num_reorder_pics to control output instead of
> > dpb_max_dec_pic_buffering, when dpb_max_dec_pic_buffering
> > is much larger than dpb_max_num_reorder_pics, it may cause
> > dpb overflow error.
> >
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: elinyhuang 
> > ---
> >  libavcodec/vvc/refs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
> > index a5ee7338d6..6694bc4c51 100644
> > --- a/libavcodec/vvc/refs.c
> > +++ b/libavcodec/vvc/refs.c
> > @@ -226,7 +226,7 @@ int ff_vvc_output_frame(VVCContext *s, VVCFrameContext
> > *fc, AVFrame *out, const
> >
> >  /* wait for more frames before output */
> >  if (!flush && s->seq_output == s->seq_decode && sps &&
> > -nb_output <=
> > sps->r->sps_dpb_params.dpb_max_dec_pic_buffering_minus1[sps->r->sps_max_sublayers_minus1]
> > + 1)
> > +nb_output <=
> > sps->r->sps_dpb_params.dpb_max_num_reorder_pics[sps->r->sps_max_sublayers_minus1])
> >  return 0;
> >
> >  if (nb_output) {
> > --
> > 2.25.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] 7.0 Name

2024-04-02 Thread myp...@gmail.com
On Tue, Apr 2, 2024 at 4:01 AM Michael Niedermayer
 wrote:
>
> Hi all
>
> I think we didnt decide on a name for 7.0 yet
>
> Previously suggested names:
> Darwin,
> De broglie,
> Dijkstra,
> Galois,
> Gauss,
> Jacobi,
> Jemison
> Johnson
> Leavitt
> Maxwell,
> Mellin,
> Perelman,
> Poincaré,
> Ramanujan,
> Sagan,
> Ting
> Viterbi,
> Voltaire,
> de Sitter,
>
> Please reply with what you prefer or add more to the list.
> If we end in a tie, previously suggested names will be favoured
> I will vote last so that i can resolve a tie if one occurs.
>
> thx
>
Viterbi
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/evc: Remove redefine of HEVC_MAX_ENTRY_POINT_OFFSETS

2024-02-21 Thread myp...@gmail.com
On Thu, Feb 22, 2024 at 2:42 PM Zhao Zhili  wrote:
>
> From: Zhao Zhili 
>
> ---
>  libavcodec/evc.h | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/libavcodec/evc.h b/libavcodec/evc.h
> index 9711c760fe..e493455a42 100644
> --- a/libavcodec/evc.h
> +++ b/libavcodec/evc.h
> @@ -141,15 +141,6 @@ enum {
>
>  // A.4.1: table A.1 allows at most 600 slice segments for any level.
>  EVC_MAX_SLICE_SEGMENTS = 600,
> -
> -// 7.4.7.1: in the worst case (tiles_enabled_flag and
> -// entropy_coding_sync_enabled_flag are both set), entry points can be
> -// placed at the beginning of every Ctb row in every tile, giving an
> -// upper bound of (num_tile_columns_minus1 + 1) * PicHeightInCtbsY - 1.
> -// Only a stream with very high resolution and perverse parameters could
> -// get near that, though, so set a lower limit here with the maximum
> -// possible value for 4K video (at most 135 16x16 Ctb rows).
> -HEVC_MAX_ENTRY_POINT_OFFSETS = EVC_MAX_TILE_COLUMNS * 135,
>  };
LGTM, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavc/cbs_h265: Add sps_multilayer_extension support

2023-11-27 Thread myp...@gmail.com
On Tue, Nov 28, 2023 at 1:59 AM Mark Thompson  wrote:
>
> On 17/11/2023 13:03, Jun Zhao wrote:
> > Add sps_multilayer_extensio support.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   libavcodec/cbs_h265.h |  3 +++
> >   libavcodec/cbs_h265_syntax_template.c | 12 +++-
> >   2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
> > index 1b1195f198..15951269fd 100644
> > --- a/libavcodec/cbs_h265.h
> > +++ b/libavcodec/cbs_h265.h
> > @@ -330,6 +330,9 @@ typedef struct H265RawSPS {
> >   uint8_t persistent_rice_adaptation_enabled_flag;
> >   uint8_t cabac_bypass_alignment_enabled_flag;
> >
> > +// Multilayer extension.
> > +uint8_t inter_view_mv_vert_constraint_flag;
> > +
> >   // Screen content coding extension.
> >   uint8_t sps_curr_pic_ref_enabled_flag;
> >   uint8_t palette_mode_enabled_flag;
> > diff --git a/libavcodec/cbs_h265_syntax_template.c 
> > b/libavcodec/cbs_h265_syntax_template.c
> > index 2d4b954718..1e3bc1acd8 100644
> > --- a/libavcodec/cbs_h265_syntax_template.c
> > +++ b/libavcodec/cbs_h265_syntax_template.c
> > @@ -717,6 +717,16 @@ static int 
> > FUNC(sps_range_extension)(CodedBitstreamContext *ctx, RWContext *rw,
> >   return 0;
> >   }
> >
> > +static int FUNC(sps_multilayer_extension)(CodedBitstreamContext *ctx, 
> > RWContext *rw,
> > +  H265RawSPS *current)
> > +{
> > +int err;
> > +
> > +flag(inter_view_mv_vert_constraint_flag);
> > +
> > +return 0;
> > +}
> > +
> >   static int FUNC(sps_scc_extension)(CodedBitstreamContext *ctx, RWContext 
> > *rw,
> >  H265RawSPS *current)
> >   {
> > @@ -952,7 +962,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, 
> > RWContext *rw,
> >   if (current->sps_range_extension_flag)
> >   CHECK(FUNC(sps_range_extension)(ctx, rw, current));
> >   if (current->sps_multilayer_extension_flag)
> > -return AVERROR_PATCHWELCOME;
> > +CHECK(FUNC(sps_multilayer_extension)(ctx, rw, current));
> >   if (current->sps_3d_extension_flag)
> >   return AVERROR_PATCHWELCOME;
> >   if (current->sps_scc_extension_flag)
>
> This doesn't seem like it it sufficient - when in multilayer the SPS format 
> isn't the same (§F.7.3.2.2.1).
>
> Alternatively: maybe this works for the first layer (haven't verified this 
> but seems plausible), and therefore to work there only it would be sufficient 
> to check if MultiLayerExtSpsFlag is true in an SPS and stop if it is?
>
Actually, this case is from MV-HEVC, and I didn't find any other real
examples like the Spec  above
> (A sample suitable for using with fate would help.)
>
Will add a new MV-HEVC fate test case
> Thanks,
>
> - Mark
___
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] avcodec/videotoolboxenc: refactor dump encoder name

2023-11-26 Thread myp...@gmail.com
On Sat, Nov 25, 2023 at 12:06 PM Zhao Zhili  wrote:
>
> From: Zhao Zhili 
>
> ---
>  libavcodec/videotoolboxenc.c | 65 +---
>  1 file changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index b8a07e4e44..fbd33fd3f9 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -280,6 +280,41 @@ typedef struct VTEncContext {
>  int max_ref_frames;
>  } VTEncContext;
>
> +static int vt_dump_encoder(AVCodecContext *avctx)
> +{
> +VTEncContext *vtctx = avctx->priv_data;
> +CFStringRef encoder_id = NULL;
> +int status;
> +CFIndex length, max_size;
> +char *name;
> +
> +status = VTSessionCopyProperty(vtctx->session,
> +   
> compat_keys.kVTCompressionPropertyKey_EncoderID,
> +   kCFAllocatorDefault,
> +   &encoder_id);
> +// OK if not supported
> +if (status != noErr)
> +return 0;
> +
> +length = CFStringGetLength(encoder_id);
> +max_size = CFStringGetMaximumSizeForEncoding(length, 
> kCFStringEncodingUTF8);
> +name = av_malloc(max_size);
> +if (!name) {
> +CFRelease(encoder_id);
> +return AVERROR(ENOMEM);
> +}
> +
> +CFStringGetCString(encoder_id,
> +   name,
> +   max_size,
> +   kCFStringEncodingUTF8);
> +av_log(avctx, AV_LOG_DEBUG, "Init the encoder: %s\n", name);
> +av_freep(&name);
> +CFRelease(encoder_id);
> +
> +return 0;
> +}
> +
>  static int vtenc_populate_extradata(AVCodecContext   *avctx,
>  CMVideoCodecType codec_type,
>  CFStringRef  profile_level,
> @@ -1176,33 +1211,9 @@ static int vtenc_create_encoder(AVCodecContext   
> *avctx,
>  }
>  #endif
>
> -// Dump the init encoder
> -{
> -CFStringRef encoderID = NULL;
> -status = VTSessionCopyProperty(vtctx->session,
> -   
> compat_keys.kVTCompressionPropertyKey_EncoderID,
> -   kCFAllocatorDefault,
> -   &encoderID);
> -if (status == noErr) {
> -CFIndex length   = CFStringGetLength(encoderID);
> -CFIndex max_size = CFStringGetMaximumSizeForEncoding(length, 
> kCFStringEncodingUTF8);
> -char *name   = av_malloc(max_size);
> -if (!name) {
> -CFRelease(encoderID);
> -return AVERROR(ENOMEM);
> -}
> -
> -CFStringGetCString(encoderID,
> -   name,
> -   max_size,
> -   kCFStringEncodingUTF8);
> -av_log(avctx, AV_LOG_DEBUG, "Init the encoder: %s\n", name);
> -
> -av_freep(&name);
> -}
> -if (encoderID != NULL)
> -CFRelease(encoderID);
> -}
> +status = vt_dump_encoder(avctx);
> +if (status < 0)
> +return status;
>
>  if (avctx->flags & AV_CODEC_FLAG_QSCALE && !vtenc_qscale_enabled()) {
>  av_log(avctx, AV_LOG_ERROR, "Error: -q:v qscale not available for 
> encoder. Use -b:v bitrate instead.\n");
> --
> 2.42.0
>
Patchset looks good for if pass the build
___
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/2] lavc/videotoolboxenc: Get the encoder supported properties

2023-09-07 Thread myp...@gmail.com
On Fri, Sep 8, 2023 at 11:15 AM Marvin Scholz  wrote:
>
>
>
> On 8 Sep 2023, at 4:55, Jun Zhao wrote:
>
> > Get the encoder supported properties list, it will be used for
> > feature support checks.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/videotoolboxenc.c | 70 
> >  1 file changed, 47 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index 2e96990741..832147b6cd 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -232,6 +232,7 @@ typedef struct VTEncContext {
> >  AVClass *class;
> >  enum AVCodecID codec_id;
> >  VTCompressionSessionRef session;
> > +CFDictionaryRef supported_props;
> >  CFStringRef ycbcr_matrix;
> >  CFStringRef color_primaries;
> >  CFStringRef transfer_function;
> > @@ -321,6 +322,34 @@ static void clear_frame_queue(VTEncContext *vtctx)
> >  set_async_error(vtctx, 0);
> >  }
> >
> > +static void vtenc_reset(VTEncContext *vtctx)
> > +{
> > +if (vtctx->session) {
> > +CFRelease(vtctx->session);
> > +vtctx->session = NULL;
> > +}
> > +
> > +if (vtctx->supported_props) {
> > +CFRelease(vtctx->supported_props);
> > +vtctx->supported_props = NULL;
> > +}
> > +
> > +if (vtctx->color_primaries) {
> > +CFRelease(vtctx->color_primaries);
> > +vtctx->color_primaries = NULL;
> > +}
> > +
> > +if (vtctx->transfer_function) {
> > +CFRelease(vtctx->transfer_function);
> > +vtctx->transfer_function = NULL;
> > +}
> > +
> > +if (vtctx->ycbcr_matrix) {
> > +CFRelease(vtctx->ycbcr_matrix);
> > +vtctx->ycbcr_matrix = NULL;
> > +}
> > +}
> > +
> >  static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
> > *buf, ExtraSEI **sei)
> >  {
> >  BufNode *info;
> > @@ -1110,6 +1139,20 @@ static int vtenc_create_encoder(AVCodecContext   
> > *avctx,
> >  return AVERROR_EXTERNAL;
> >  }
> >
> > +if (__builtin_available(macOS 10.13, iOS 11, tvOS 11, *)) {
>
> Thanks, though this needs the proper SDK guards as well too, to not break
> building with SDKs older than 10.13, unless FFmpeg does not care about this.
>
> See 
> https://epir.at/2019/10/30/api-availability-and-target-conditionals/#checking-api-availability-at-compile-time
>
Thx the reference link, will add the build check
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/videotoolboxenc: Get the encoder supported properties

2023-09-05 Thread myp...@gmail.com
On Wed, Sep 6, 2023 at 12:13 AM Marvin Scholz  wrote:
>
> On 5 Sep 2023, at 18:02, Jun Zhao wrote:
>
> > Get the encoder supported properties list, it will be used for
> > feature support checks.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/videotoolboxenc.c | 68 
> >  1 file changed, 45 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index 3512d35b73..0142342c58 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -232,6 +232,7 @@ typedef struct VTEncContext {
> >  AVClass *class;
> >  enum AVCodecID codec_id;
> >  VTCompressionSessionRef session;
> > +CFDictionaryRef supported_props;
> >  CFStringRef ycbcr_matrix;
> >  CFStringRef color_primaries;
> >  CFStringRef transfer_function;
> > @@ -321,6 +322,34 @@ static void clear_frame_queue(VTEncContext *vtctx)
> >  set_async_error(vtctx, 0);
> >  }
> >
> > +static void vtenc_reset(VTEncContext *vtctx)
> > +{
> > +if (vtctx->session) {
> > +CFRelease(vtctx->session);
> > +vtctx->session = NULL;
> > +}
> > +
> > +if (vtctx->supported_props) {
> > +CFRelease(vtctx->supported_props);
> > +vtctx->supported_props = NULL;
> > +}
> > +
> > +if (vtctx->color_primaries) {
> > +CFRelease(vtctx->color_primaries);
> > +vtctx->color_primaries = NULL;
> > +}
> > +
> > +if (vtctx->transfer_function) {
> > +CFRelease(vtctx->transfer_function);
> > +vtctx->transfer_function = NULL;
> > +}
> > +
> > +if (vtctx->ycbcr_matrix) {
> > +CFRelease(vtctx->ycbcr_matrix);
> > +vtctx->ycbcr_matrix = NULL;
> > +}
> > +}
> > +
> >  static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
> > *buf, ExtraSEI **sei)
> >  {
> >  BufNode *info;
> > @@ -1110,6 +1139,18 @@ static int vtenc_create_encoder(AVCodecContext   
> > *avctx,
> >  return AVERROR_EXTERNAL;
> >  }
> >
> > +status = VTCopySupportedPropertyDictionaryForEncoder(avctx->width,
> > + avctx->height,
> > + codec_type,
> > + enc_info,
> > + NULL,
> > + 
> > &vtctx->supported_props);
>
> Only available starting macOS 10.13+, needs to be handled accordingly, I 
> think.
>
Add the version check in local, thx, any other comments?
> > +
> > +if (status != noErr) {
> > +av_log(avctx, AV_LOG_ERROR,"Error retrieving the supported 
> > property dictionary err=%"PRId64"\n", (int64_t)status);
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> >  // Dump the init encoder
> >  {
> >  CFStringRef encoderID = NULL;
> > @@ -1660,7 +1701,6 @@ static av_cold int vtenc_init(AVCodecContext *avctx)
> >  // It can happen when user set avctx->profile directly.
> >  if (vtctx->profile == FF_PROFILE_UNKNOWN)
> >  vtctx->profile = avctx->profile;
> > -vtctx->session = NULL;
> >  status = vtenc_configure_encoder(avctx);
> >  if (status) return status;
> >
> > @@ -2429,8 +2469,8 @@ static int create_cv_pixel_buffer(AVCodecContext   
> > *avctx,
> >
> >  vtstatus = 
> > VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
> >  if (vtstatus == kVTInvalidSessionErr) {
> > -CFRelease(vtctx->session);
> > -vtctx->session = NULL;
> > +vtenc_reset(vtctx);
> > +
> >  status = vtenc_configure_encoder(avctx);
> >  if (status == 0)
> >  pix_buf_pool = 
> > VTCompressionSessionGetPixelBufferPool(vtctx->session);
> > @@ -2686,10 +2726,7 @@ static int vtenc_populate_extradata(AVCodecContext   
> > *avctx,
> >
> >  pe_cleanup:
> >  CVPixelBufferRelease(pix_buf);
> > -if(vtctx->session)
> > -CFRelease(vtctx->session);
> > -
> > -vtctx->session = NULL;
> > +vtenc_reset(vtctx);
> >  vtctx->frame_ct_out = 0;
> >
> >  av_assert0(status != 0 || (avctx->extradata && avctx->extradata_size > 
> > 0));
> > @@ -2712,23 +2749,8 @@ static av_cold int vtenc_close(AVCodecContext *avctx)
> >  clear_frame_queue(vtctx);
> >  pthread_cond_destroy(&vtctx->cv_sample_sent);
> >  pthread_mutex_destroy(&vtctx->lock);
> > -CFRelease(vtctx->session);
> > -vtctx->session = NULL;
> >
> > -if (vtctx->color_primaries) {
> > -CFRelease(vtctx->color_primaries);
> > -vtctx->color_primaries = NULL;
> > -}
> > -
> > -if (vtctx->transfer_function) {
> > -CFRelease(vtctx->transfer_function);
> > -vtctx->transfer_function = NULL;
> > -}
> > -
> > -if (vtctx->ycbcr_matrix) {
> > -CFRelease(vtctx->ycbcr_matrix);
> > -vtctx->y

Re: [FFmpeg-devel] [PATCH 2/2] lavc/videotoolboxenc: Get the encoder supported properties

2023-09-05 Thread myp...@gmail.com
On Tue, Sep 5, 2023 at 3:52 PM Tomas Härdin  wrote:
>
> mån 2023-09-04 klockan 11:53 +0800 skrev Jun Zhao:
> > Get the encoder supported properties list, it will be used for
> > feature support checks.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/videotoolboxenc.c | 27 +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/libavcodec/videotoolboxenc.c
> > b/libavcodec/videotoolboxenc.c
> > index 5633640a30..8e70915225 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -232,6 +232,7 @@ typedef struct VTEncContext {
> >  AVClass *class;
> >  enum AVCodecID codec_id;
> >  VTCompressionSessionRef session;
> > +CFDictionaryRef supported_props;
> >  CFStringRef ycbcr_matrix;
> >  CFStringRef color_primaries;
> >  CFStringRef transfer_function;
> > @@ -1110,6 +,18 @@ static int
> > vtenc_create_encoder(AVCodecContext   *avctx,
> >  return AVERROR_EXTERNAL;
> >  }
> >
> > +status = VTCopySupportedPropertyDictionaryForEncoder(avctx-
> > >width,
> > + avctx-
> > >height,
> > + codec_type,
> > + enc_info,
> > + NULL,
> > + &vtctx-
> > >supported_props);
> > +
> > +if (status != noErr) {
> > +av_log(avctx, AV_LOG_ERROR,"Error retrieving the supported
> > property dictionary err=%"PRId64"", (int64_t)status);
>
> Missing \n
Good catch
>
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> >  // Dump the init encoder
> >  {
> >  CFStringRef encoderID = NULL;
> > @@ -1656,6 +1669,7 @@ static av_cold int vtenc_init(AVCodecContext
> > *avctx)
> >  if (vtctx->profile == FF_PROFILE_UNKNOWN)
> >  vtctx->profile = avctx->profile;
> >  vtctx->session = NULL;
> > +vtctx->supported_props = NULL;
>
> NULLing isn't necessary since priv_data is calloc'd
Yes,I know this, just following the old code behaviour,maybe need to
refine the old code
>
> >  status = vtenc_configure_encoder(avctx);
> >  if (status) return status;
> >
> > @@ -2426,6 +2440,11 @@ static int
> > create_cv_pixel_buffer(AVCodecContext   *avctx,
> >  if (vtstatus == kVTInvalidSessionErr) {
> >  CFRelease(vtctx->session);
> >  vtctx->session = NULL;
> > +if (vtctx->supported_props) {
> > +CFRelease(vtctx->supported_props);
> > +vtctx->supported_props = NULL;
> > +}
> > +
> >  status = vtenc_configure_encoder(avctx);
> >  if (status == 0)
> >  pix_buf_pool =
> > VTCompressionSessionGetPixelBufferPool(vtctx->session);
> > @@ -2685,6 +2704,10 @@ pe_cleanup:
> >  CFRelease(vtctx->session);
> >
> >  vtctx->session = NULL;
> > +if (vtctx->supported_props) {
> > +CFRelease(vtctx->supported_props);
> > +vtctx->supported_props = NULL;
> > +}
> >  vtctx->frame_ct_out = 0;
> >
> >  av_assert0(status != 0 || (avctx->extradata && avctx-
> > >extradata_size > 0));
> > @@ -2709,6 +2732,10 @@ static av_cold int vtenc_close(AVCodecContext
> > *avctx)
> >  pthread_mutex_destroy(&vtctx->lock);
> >  CFRelease(vtctx->session);
> >  vtctx->session = NULL;
> > +if (vtctx->supported_props) {
> > +CFRelease(vtctx->supported_props);
> > +vtctx->supported_props = NULL;
> > +}
>
> Copy-pasting this in three places looks ugly. Moving cleanup of session
> and supported_props to a small function would reduce the number of
> lines and look prettier.
>
It makes more sense.
___
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] lavc/videotoolboxenc: enable low-latency mode for HEVC

2023-08-31 Thread myp...@gmail.com
On Fri, Sep 1, 2023 at 11:50 AM "zhilizhao(赵志立)"  wrote:
>
>
>
> > On Sep 1, 2023, at 09:13, myp...@gmail.com wrote:
> >
> > On Fri, Sep 1, 2023 at 2:13 AM Zhao Zhili  wrote:
> >>
> >>
> >>> From: ffmpeg-devel  On Behalf Of Jun Zhao
> >>> Sent: 2023年8月31日 22:50
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Cc: Jun Zhao ; Jun Zhao 
> >>> Subject: [FFmpeg-devel] [PATCH 2/2] lavc/videotoolboxenc: enable 
> >>> low-latency mode for HEVC
> >>>
> >>> Enable the HEVC encoder that supports low-latency mode.
> >>>
> >>> Signed-off-by: Jun Zhao 
> >>> ---
> >>> libavcodec/videotoolboxenc.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> >>> index 8e493c4f7a..bfc03787a0 100644
> >>> --- a/libavcodec/videotoolboxenc.c
> >>> +++ b/libavcodec/videotoolboxenc.c
> >>> @@ -1568,7 +1568,8 @@ static int vtenc_configure_encoder(AVCodecContext 
> >>> *avctx)
> >>> #endif
> >>>
> >>> // low-latency mode: eliminate frame reordering, follow a 
> >>> one-in-one-out encoding mode
> >>> -if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) && avctx->codec_id == 
> >>> AV_CODEC_ID_H264) {
> >>> +if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) &&
> >>> +(avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id == 
> >>> AV_CODEC_ID_HEVC)) {
> >>
> >> How about just remove the codec_id check?
> >> Is there any unwelcome side effects for encoders other than H264/HEVC?
> >
> > 1. One reason is that there are now other encoders available, such as
> > prores_videotoolbox.
> >
> > 2. It may be more appropriate to use a strictly qualified check
> > instead of an open condition.
>
> Both HEVC and ProRes failed with low_latency on my machine (with or without 
> -allow_sw 1)
>
> [hevc_videotoolbox @ 0x6192a380] Error: cannot create compression 
> session: -12902
> [prores_videotoolbox @ 0x6192a380] Error: cannot create compression 
> session: -12902
>
> kVTParameterErr = 
> -12902,
>
I think you missed the other options, low delay in VT encoder need to
co-work with some other options

> 1. FFmpeg users should have an idea whether or not to set 
> AV_CODEC_FLAG_LOW_DELAY.
> AV_CODEC_FLAG_LOW_DELAY doesn’t make sense for ProRes, but if user wants to 
> try, let he/she
> do.
>
> 2. I can’t find API to query the capability. Only VideoToolBox framework 
> itself know how
> to handle the argument. There isn’t much protect to provide for users.
>
Yes, now FFmpeg VT encoder didn't used the capability query, I think
need to used the some API VTCopySupportedPropertyDictionaryForEncoder
for capability query, this my next step
> Even with H.264, the results is unexpected: the input framerate is 25 but the 
> output
> framerate is 5, it dropped 80 percent frames silently.
>
___
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] lavc/videotoolboxenc: enable low-latency mode for HEVC

2023-08-31 Thread myp...@gmail.com
On Fri, Sep 1, 2023 at 2:13 AM Zhao Zhili  wrote:
>
>
> > From: ffmpeg-devel  On Behalf Of Jun Zhao
> > Sent: 2023年8月31日 22:50
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao ; Jun Zhao 
> > Subject: [FFmpeg-devel] [PATCH 2/2] lavc/videotoolboxenc: enable 
> > low-latency mode for HEVC
> >
> > Enable the HEVC encoder that supports low-latency mode.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/videotoolboxenc.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index 8e493c4f7a..bfc03787a0 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -1568,7 +1568,8 @@ static int vtenc_configure_encoder(AVCodecContext 
> > *avctx)
> >  #endif
> >
> >  // low-latency mode: eliminate frame reordering, follow a 
> > one-in-one-out encoding mode
> > -if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) && avctx->codec_id == 
> > AV_CODEC_ID_H264) {
> > +if ((avctx->flags & AV_CODEC_FLAG_LOW_DELAY) &&
> > +(avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id == 
> > AV_CODEC_ID_HEVC)) {
>
> How about just remove the codec_id check?
> Is there any unwelcome side effects for encoders other than H264/HEVC?

1. One reason is that there are now other encoders available, such as
prores_videotoolbox.

2. It may be more appropriate to use a strictly qualified check
instead of an open condition.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavc/libx264: replace ITU-T T35(A/53 CC) SEI type by enum value

2023-08-26 Thread myp...@gmail.com
On Sat, Aug 26, 2023 at 2:40 PM Kieran Kunhya  wrote:
>
> On Sat, 26 Aug 2023 at 07:32, Jun Zhao  wrote:
>
> > replace ITU-T T35(A/53 CC) SEI type by enum value
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/libx264.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index 1a7dc7bdd5..ce849d6c9a 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -563,7 +563,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >
> >  sei->payloads[0].payload_size = sei_size;
> >  sei->payloads[0].payload  = sei_data;
> > -sei->payloads[0].payload_type = 4;
> > +sei->payloads[0].payload_type =
> > SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35;
> >  sei->num_payloads = 1;
> >  }
> >  }
> > --
> > 2.25.1
> >
>
> LGTM
thx,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".


Re: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of frames" in IVF header

2023-07-03 Thread myp...@gmail.com
On Mon, Jul 3, 2023 at 12:25 PM Dai, Jianhui J
 wrote:
>
> Should set "number of frames" to bytes 24-27 of IVF header, not
> duration.
> It is described by [1], and confirmed by parsing all IVF files in [2].
>
> This commit also updates the md5sum of refs to pass fate-cbs.
>
> [1] Duck IVF - MultimediaWiki
> https://wiki.multimedia.cx/index.php/Duck_IVF
>
> [2] webm/vp8-test-vectors
> https://chromium.googlesource.com/webm/vp8-test-vectors
>
> Signed-off-by: Jianhui Dai 
> ---
>  libavformat/ivfdec.c| 13 ++---
>  libavformat/ivfenc.c| 13 +
>  tests/ref/fate/cbs-vp9-vp90-2-03-deltaq |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-06-bilinear   |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas  |  2 +-
>  .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame  |  2 +-
>  .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo |  2 +-
>  tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian |  2 +-
>  tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 |  2 +-
>  tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 |  2 +-
>  tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420   |  2 +-
>  tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422   |  2 +-
>  tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444   |  2 +-
>  15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
> index 511f2387ed..141ce4f1be 100644
> --- a/libavformat/ivfdec.c
> +++ b/libavformat/ivfdec.c
> @@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
>  st->codecpar->codec_id   = ff_codec_get_id(ff_codec_bmp_tags, 
> st->codecpar->codec_tag);
>  st->codecpar->width  = avio_rl16(s->pb);
>  st->codecpar->height = avio_rl16(s->pb);
> -time_base.den = avio_rl32(s->pb);
> -time_base.num = avio_rl32(s->pb);
> -st->duration  = avio_rl32(s->pb);
> +time_base.den= avio_rl32(s->pb);
> +time_base.num= avio_rl32(s->pb);
 Don't piggyback the coding style formatting part
> +st->nb_frames= avio_rl32(s->pb);
>  avio_skip(s->pb, 4); // unused
>
> +// Infer duration from nb_frames, in order to be backward compatible with
> +// previous IVF demuxer.
> +// It is popular to configure time_base to 1/frame_rate by IVF muxer, 
> that
> +// the duration happens to be the same with nb_frames. See
> +// 
> `https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/main`
> +st->duration = st->nb_frames;
> +
>  ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
>
>  if (!time_base.den || !time_base.num) {
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 47b4efbcd1..88399099d4 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
>  avio_wl16(pb, par->height);
>  avio_wl32(pb, s->streams[0]->time_base.den);
>  avio_wl32(pb, s->streams[0]->time_base.num);
> -avio_wl64(pb, 0xULL); // length is overwritten at the 
> end of muxing
> +avio_wl32(pb, 0x); // "number of frames" is overwritten at the 
> end of muxing
> +avio_wl32(pb, 0); // unused
>
>  return 0;
>  }
> @@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
>  AVIOContext *pb = s->pb;
>  IVFEncContext *ctx = s->priv_data;
>
> -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> -(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 && 
> ctx->last_pkt_duration))) {
> +// overwrite the "number of frames"
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
>  int64_t end = avio_tell(pb);
>
>  avio_seek(pb, 24, SEEK_SET);
> -// overwrite the "length" field (duration)
> -avio_wl32(pb, ctx->last_pkt_duration ?
> -  ctx->sum_delta_pts + ctx->last_pkt_duration :
> -  ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 
> 1));
> -avio_wl32(pb, 0); // zero out unused bytes
> +avio_wl32(pb, ctx->frame_cnt);
>  avio_seek(pb, end, SEEK_SET);
>  }
>
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq 
> b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> index db09cfd5e0..f621d7a480 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> @@ -1 +1 @@
> -bb630ef560f83951fa6547a664fdb636
> +fe62460fe28202e0666e628afd8602ca
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear 
> b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> index f579459179..9359e21e40 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> @@ -1 +1 @@
> -2ca9d012c7212e38f5e2727ac66ec6c5
> +179e228004c396a301c89f34b6c72f68
> diff --git a/tests/ref/fate/cbs-v

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/h264_mp4toannexb_bsf: refactor start_code_size handling

2023-05-29 Thread myp...@gmail.com
On Fri, May 19, 2023 at 4:41 PM Zhao Zhili  wrote:
>
> From: Zhao Zhili 
>
> start_code_size depends on whether PS comes from out-of-band or
> in-band. Make the code more readable.
> ---
>  libavcodec/h264_mp4toannexb_bsf.c | 34 ---
>  1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
> b/libavcodec/h264_mp4toannexb_bsf.c
> index d11be455c2..7dce1ae9b6 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -43,10 +43,26 @@ typedef struct H264BSFContext {
>  int  extradata_parsed;
>  } H264BSFContext;
>
> +enum PsSource {
> +PS_OUT_OF_BAND = -1,
> +PS_NONE = 0,
> +PS_IN_BAND = 1,
> +};
> +
>  static void count_or_copy(uint8_t **out, uint64_t *out_size,
> -  const uint8_t *in, int in_size, int ps, int copy)
> +  const uint8_t *in, int in_size, enum PsSource ps, 
> int copy)
>  {
> -uint8_t start_code_size = ps < 0 ? 0 : *out_size == 0 || ps ? 4 : 3;
> +uint8_t start_code_size;
> +
> +if (ps == PS_OUT_OF_BAND)
> +/* start code already present in out-of-band ps data, so don't need 
> to
> + * add it manually again
> + */
> +start_code_size = 0;
> +else if (ps == PS_IN_BAND || *out_size == 0)
> +start_code_size = 4;
> +else
> +start_code_size = 3;
I prefer the original style, they are shorter and more concise
>
>  if (copy) {
>  memcpy(*out + start_code_size, in, in_size);
> @@ -202,6 +218,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
>
>  do {
>  uint32_t nal_size = 0;
> +enum PsSource ps;
>
>  /* possible overread ok due to padding */
>  for (int i = 0; i < s->length_size; i++)
> @@ -230,7 +247,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
>  if (!s->sps_size) {
>  LOG_ONCE(ctx, AV_LOG_WARNING, "SPS not present in 
> the stream, nor in AVCC, stream may be unreadable\n");
>  } else {
> -count_or_copy(&out, &out_size, s->sps, s->sps_size, 
> -1, j);
> +count_or_copy(&out, &out_size, s->sps, s->sps_size, 
> PS_OUT_OF_BAND, j);
>  sps_seen = 1;
>  }
>  }
> @@ -246,19 +263,22 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
> AVPacket *opkt)
>  if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen && 
> !pps_seen) {
>  if (ctx->par_out->extradata)
>  count_or_copy(&out, &out_size, ctx->par_out->extradata,
> -  ctx->par_out->extradata_size, -1, j);
> +  ctx->par_out->extradata_size, 
> PS_OUT_OF_BAND, j);
>  new_idr = 0;
>  /* if only SPS has been seen, also insert PPS */
>  } else if (new_idr && unit_type == H264_NAL_IDR_SLICE && 
> sps_seen && !pps_seen) {
>  if (!s->pps_size) {
>  LOG_ONCE(ctx, AV_LOG_WARNING, "PPS not present in the 
> stream, nor in AVCC, stream may be unreadable\n");
>  } else {
> -count_or_copy(&out, &out_size, s->pps, s->pps_size, -1, 
> j);
> +count_or_copy(&out, &out_size, s->pps, s->pps_size, 
> PS_OUT_OF_BAND, j);
>  }
>  }
>
> -count_or_copy(&out, &out_size, buf, nal_size,
> -  unit_type == H264_NAL_SPS || unit_type == 
> H264_NAL_PPS, j);
> +if (unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)
> +ps = PS_IN_BAND;
> +else
> +ps = PS_NONE;
> +count_or_copy(&out, &out_size, buf, nal_size, ps, j);
>  if (!new_idr && unit_type == H264_NAL_SLICE) {
>  new_idr  = 1;
>  sps_seen = 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".



-- 
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavc/libopenh264: Support full range videos in transcoding

2023-04-20 Thread myp...@gmail.com
On Thu, Apr 20, 2023 at 7:27 PM "zhilizhao(赵志立)"  wrote:
>
>
>
> > On Apr 18, 2023, at 23:33, Jun Zhao  wrote:
> >
> > Support full range videos when transcoding, enabled the
> > YUVJ420P to avoid auto scale from YUVJ420P to YUV420P
>
>
> According to "Towards YUVJ removal"
> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304718.html
>
> > So, as was discussed at the last meeting, we should move towards
> removing YUVJ.
>
> However, it looks like there is no much progress since then.
>
Yes, I know the plan we will remove YUVJ, but now when we transcoding,
ffmpeg auto-inserts swscaler to convert from full range to limited
range when input video with full range, I can't find a full solution
in this case, So until YUVJ is removed, I add the YUVJ format support
for this case.

> >
> > Signed-off-by: Jun Zhao 
> > ---
> > libavcodec/libopenh264enc.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> > index 8b4755f5ba..11fbb7 100644
> > --- a/libavcodec/libopenh264enc.c
> > +++ b/libavcodec/libopenh264enc.c
> > @@ -311,10 +311,12 @@ static av_cold int svc_encode_init(AVCodecContext 
> > *avctx)
> >
> > #if OPENH264_VER_AT_LEAST(1, 6)
> > param.sSpatialLayers[0].uiVideoFormat = VF_UNDEF;
> > +
> > if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED) {
> > param.sSpatialLayers[0].bVideoSignalTypePresent = true;
> > param.sSpatialLayers[0].bFullRange = (avctx->color_range == 
> > AVCOL_RANGE_JPEG);
> > -}
> > +}  else if (avctx->pix_fmt == AV_PIX_FMT_YUVJ420P)
> > +param.sSpatialLayers[0].bFullRange = 1;
> >
> > if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED  ||
> > avctx->color_primaries != AVCOL_PRI_UNSPECIFIED ||
> > @@ -443,6 +445,7 @@ const FFCodec ff_libopenh264_encoder = {
> > .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP |
> >   FF_CODEC_CAP_AUTO_THREADS,
> > .p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
> > +AV_PIX_FMT_YUVJ420P,
> > AV_PIX_FMT_NONE },
> > .defaults   = svc_enc_defaults,
> > .p.priv_class   = &class,
> > --
> > 2.25.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavfi/coreimage: suppress OpenGL deprecation warning

2023-02-25 Thread myp...@gmail.com
On Sun, Feb 26, 2023 at 1:48 AM Thilo Borgmann  wrote:
>
> Am 25.02.23 um 16:26 schrieb Jun Zhao:
> > From: Jun Zhao 
> >
> > suppress OpenGL deprecation warning.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   libavfilter/vf_coreimage.m | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_coreimage.m b/libavfilter/vf_coreimage.m
> > index b1959861de..17b2cde6fe 100644
> > --- a/libavfilter/vf_coreimage.m
> > +++ b/libavfilter/vf_coreimage.m
> > @@ -22,7 +22,8 @@
> >* @file
> >* Video processing based on Apple's CoreImage API
> >*/
> > -
> > +#define GL_SILENCE_DEPRECATION
> > +#define CI_SILENCE_GL_DEPRECATION
> >   #import 
> >   #import 
>
> Why do you want to silence a framework warning?
>
Ok, will drop the fix
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] doc/examples/muxing: Remove unnecessary ret

2023-02-25 Thread myp...@gmail.com
ignore the patch 1-2, send with the wrong branch

On Sat, Feb 25, 2023 at 11:25 PM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Remove unnecessary ret and make the code more compact
>
> Signed-off-by: Jun Zhao 
> ---
>  doc/examples/muxing.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
> index 3acb778322..cd997d5431 100644
> --- a/doc/examples/muxing.c
> +++ b/doc/examples/muxing.c
> @@ -219,8 +219,6 @@ static AVFrame *alloc_audio_frame(enum AVSampleFormat 
> sample_fmt,
>int sample_rate, int nb_samples)
>  {
>  AVFrame *frame = av_frame_alloc();
> -int ret;
> -
>  if (!frame) {
>  fprintf(stderr, "Error allocating an audio frame\n");
>  exit(1);
> @@ -232,8 +230,7 @@ static AVFrame *alloc_audio_frame(enum AVSampleFormat 
> sample_fmt,
>  frame->nb_samples = nb_samples;
>
>  if (nb_samples) {
> -ret = av_frame_get_buffer(frame, 0);
> -if (ret < 0) {
> +if (av_frame_get_buffer(frame, 0) < 0) {
>  fprintf(stderr, "Error allocating an audio buffer\n");
>  exit(1);
>  }
> --
> 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".



-- 
===
Jun zhao/赵军
+++
___
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 v1 00/11] Add support for H266/VVC

2023-01-10 Thread myp...@gmail.com
On Tue, Jan 10, 2023 at 10:56 AM Nuo Mi  wrote:
>
> Hi Thomas
> It works for me.
>
> BTW, I will send out a C version of VVC native decoder very soon.
> Please also help review and improve it.
> Thank you.
Ha, it's great news
>
> On Tue, Jan 3, 2023 at 10:02 PM Thomas Siedel 
> wrote:
>
> > On Thu, 15 Dec 2022 at 10:11, Thomas Siedel 
> > wrote:
> >
> >> On Tue, 13 Dec 2022 at 07:19, Nuo Mi  wrote:
> >>
> >>> Hi Thomas,
> >>> Thank you for sending the patch set.
> >>> It seems the patchset is based on
> >>> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3487
> >>> Please do not change the author's name.
> >>>
> >>> thank you
> >>>
> >>
> >> Some code regarding VVC parsing is based on another FFmpeg fork. This
> >> fork had been based on your patch set, it seems.
> >> On top of this, I did additional modifications to the parsing code and
> >> added the other code regarding format support and the decoder and encoder
> >> integration.
> >>
> >> It was not my intent to hide you as an author of the parsing code.
> >> Your patch set has been in an unmerged state for over 1.5 years now
> >> without new progress, so I assumed that these patches are kind of
> >> discontinued.
> >> Therefore I started submitting my own patchset to get VVC integrated into
> >> FFmpeg.
> >> I kept your original copyright notices in libavformat/vvcdec.c and
> >> livavcodec/vvc_parser.c.
> >> Apart from this, I am not sure how / where else this could be documented
> >> and how other authors can be appropriately referenced.
> >>
> >> Could you explain in more detail what you mean by changing the author's
> >> name?
> >> Do you have any suggestions on what to do in this case or how to change
> >> it?
> >>
> >>
> > I just submitted a new version of the patch set.
> > Among other changes, I now put you as the author of the first three
> > patches, as most of their content is based on your original patch set.
> > I made some modifications to them, so I added myself as a co-author.
> > For patches 4 and 5, I put you as the co-author because some of their
> > content is based on your original patch set, but only to a smaller extent.
> > All other patches are independent.
> >
> > I hope that this solution is OK for you. If not, please let me know.
> >
> >
> >>
> >> On Wed, Oct 19, 2022 at 3:26 PM  wrote:
> >>>
>  From: Thomas Siedel 
> 
>  This patch set adds H266/VVC support.
>  This includes parsing, muxing, demuxing, decoding and encoding.
>  Decoding is done using the external library VVdeC
>  (https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with
>  --enable-libvvdec.
>  Encoding is done using the external library VVenC
>  (https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with
>  --enable-libvvenc.
> 
>  Thomas Siedel (11):
>    avcodec: add enum types for H266/VVC
>    avcodec: add cbs for H266/VVC
>    avcodec: enable cbs for H266/VVC
>    avcodec: add bitstream parser for H266/VVC
>    avcodec: add MP4 to annexb support for H266/VVC
>    avformat: add demuxer and probe support for H266/VVC
>    avformat: add muxer support for H266/VVC
>    avcodec: add external decoder libvvdec for H266/VVC
>    avcodec: add external encoder libvvenc for H266/VVC
>    avformat: add ts stream types for H266/VVC
>    avcodec: increase minor version for H266/VVC
> 
>   configure |   16 +-
>   libavcodec/Makefile   |6 +
>   libavcodec/allcodecs.c|2 +
>   libavcodec/bitstream_filters.c|2 +
>   libavcodec/cbs.c  |6 +
>   libavcodec/cbs_h2645.c|  384 +++-
>   libavcodec/cbs_h266.h |  791 +++
>   libavcodec/cbs_h266_syntax_template.c | 3010 +
>   libavcodec/cbs_internal.h |3 +-
>   libavcodec/cbs_sei.c  |   29 +
>   libavcodec/h2645_parse.c  |   71 +-
>   libavcodec/h266_metadata_bsf.c|  145 ++
>   libavcodec/libvvdec.c |  511 +
>   libavcodec/libvvenc.c |  432 
>   libavcodec/parsers.c  |1 +
>   libavcodec/version.h  |2 +-
>   libavcodec/vvc.h  |  142 ++
>   libavcodec/vvc_mp4toannexb_bsf.c  |  318 +++
>   libavcodec/vvc_paramset.c |  972 
>   libavcodec/vvc_paramset.h |  429 
>   libavcodec/vvc_parse_extradata.c  |  241 ++
>   libavcodec/vvc_parse_extradata.h  |   36 +
>   libavcodec/vvc_parser.c   |  588 +
>   libavformat/Makefile  |8 +-
>   libavformat/allformats.c  |2 +
>   libavformat/demux.c   |7 +-
>   libavformat/isom.c|1 +
>   libavformat/isom_tags.c 

Re: [FFmpeg-devel] [PATCH v3] lavc/libvpx: remove thread limit

2023-01-10 Thread myp...@gmail.com
On Thu, Jan 5, 2023 at 6:42 PM Dmitrii Ovchinnikov
 wrote:
>
> From: Dmitrii Ovchinnikov 
>
> This change improves the performance and multicore
>  scalability of the vp9 codec for streaming single-pass encoded videos. The
>  current thread limit for ffmpeg codecs is 16 (MAX_AUTO_THREADS in
>  pthread_internal.h) due to a limitation in H.264 codec that prevents more
>  than 16 threads being used.
>
> Increasing the thread limit to 64 for vp9 improves
> the performance for encoding 4K raw videos for streaming by up to 47%
> compared to 16 threads, and from 20-30% for 32 threads, with the same quality
> as measured by the VMAF score.
>
> Did not need to add a check for limit in libvpx as it is already present
> in libvpx/vp9/vp9_cx_iface.c:
>   RANGE_CHECK_HI(cfg, g_threads, 64);
> As demonstrated by following message when -threads is set to anything more 
> than 64
> [libvpx-vp9 @ 0x30ed380]   Additional information: g_threads out of range 
> [..64]
>
> ---
>  libavcodec/libvpxdec.c | 2 +-
>  libavcodec/libvpxenc.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 9cd2c56caf..19407092d0 100644
> --- a/libavcodec/libvpxdec.c
> +++ b/libavcodec/libvpxdec.c
> @@ -88,7 +88,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  const struct vpx_codec_iface *iface)
>  {
>  struct vpx_codec_dec_cfg deccfg = {
> -.threads = FFMIN(avctx->thread_count ? avctx->thread_count : 
> av_cpu_count(), 16)
> +.threads = avctx->thread_count ? avctx->thread_count : av_cpu_count()
>  };
>
>  av_log(avctx, AV_LOG_INFO, "%s\n", vpx_codec_version_str());
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 9aa5510c28..0627e13973 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -942,7 +942,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  enccfg.g_timebase.num = avctx->time_base.num;
>  enccfg.g_timebase.den = avctx->time_base.den;
>  enccfg.g_threads  =
> -FFMIN(avctx->thread_count ? avctx->thread_count : av_cpu_count(), 
> 16);
> +avctx->thread_count ? avctx->thread_count : av_cpu_count();
>  enccfg.g_lag_in_frames= ctx->lag_in_frames;
>
Do you check the change with the old version libvpx?  as I know, older
versions libvpx setting the number of threads higher than 16 will
cause a crash, so I think at least a version check needs to be added

>  if (avctx->flags & AV_CODEC_FLAG_PASS1)
> --
> 2.38.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 05/10] avformat: add demuxer and probe support for H266/VVC

2022-11-06 Thread myp...@gmail.com
On Thu, Nov 3, 2022 at 8:23 PM Thomas Siedel  wrote:
>
> Add demuxer to probe raw vvc and parse vvcc byte stream format.
>
> Signed-off-by: Thomas Siedel 
> ---
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/demux.c  |   7 +-
>  libavformat/vvc.c| 919 +++
>  libavformat/vvc.h|  99 +
>  libavformat/vvcdec.c |  61 +++
>  6 files changed, 1086 insertions(+), 2 deletions(-)
>  create mode 100644 libavformat/vvc.c
>  create mode 100644 libavformat/vvc.h
>  create mode 100644 libavformat/vvcdec.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index d7f198bf39..00ab4ded89 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -595,6 +595,7 @@ OBJS-$(CONFIG_VOC_MUXER) += vocenc.o voc.o
>  OBJS-$(CONFIG_VPK_DEMUXER)   += vpk.o
>  OBJS-$(CONFIG_VPLAYER_DEMUXER)   += vplayerdec.o subtitles.o
>  OBJS-$(CONFIG_VQF_DEMUXER)   += vqf.o
> +OBJS-$(CONFIG_VVC_DEMUXER)   += vvcdec.o rawdec.o
>  OBJS-$(CONFIG_W64_DEMUXER)   += wavdec.o w64.o pcm.o
>  OBJS-$(CONFIG_W64_MUXER) += wavenc.o w64.o
>  OBJS-$(CONFIG_WAV_DEMUXER)   += wavdec.o pcm.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 47c419a009..a4e3822681 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -474,6 +474,7 @@ extern const AVOutputFormat ff_voc_muxer;
>  extern const AVInputFormat  ff_vpk_demuxer;
>  extern const AVInputFormat  ff_vplayer_demuxer;
>  extern const AVInputFormat  ff_vqf_demuxer;
> +extern const AVInputFormat  ff_vvc_demuxer;
>  extern const AVInputFormat  ff_w64_demuxer;
>  extern const AVOutputFormat ff_w64_muxer;
>  extern const AVInputFormat  ff_wav_demuxer;
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index 2dfd82a63c..8dbde23fcd 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -120,6 +120,7 @@ static int set_codec_from_probe_data(AVFormatContext *s, 
> AVStream *st,
>  { "mp3",AV_CODEC_ID_MP3,  AVMEDIA_TYPE_AUDIO},
>  { "mpegvideo",  AV_CODEC_ID_MPEG2VIDEO,   AVMEDIA_TYPE_VIDEO},
>  { "truehd", AV_CODEC_ID_TRUEHD,   AVMEDIA_TYPE_AUDIO},
> +{ "vvc",AV_CODEC_ID_VVC,  AVMEDIA_TYPE_VIDEO},
>  { 0 }
>  };
>  int score;
> @@ -743,7 +744,8 @@ static int64_t select_from_pts_buffer(AVStream *st, 
> int64_t *pts_buffer, int64_t
>  {
>  FFStream *const sti = ffstream(st);
>  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> +   st->codecpar->codec_id != AV_CODEC_ID_HEVC &&
> +   st->codecpar->codec_id != AV_CODEC_ID_VVC;
>
>  if (!onein_oneout) {
>  int delay = sti->avctx->has_b_frames;
> @@ -933,7 +935,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
> AVStream *st,
>  int64_t offset;
>  AVRational duration;
>  int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
> -   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
> +   st->codecpar->codec_id != AV_CODEC_ID_HEVC &&
> +   st->codecpar->codec_id != AV_CODEC_ID_VVC;
>
>  if (s->flags & AVFMT_FLAG_NOFILLIN)
>  return;
> diff --git a/libavformat/vvc.c b/libavformat/vvc.c
> new file mode 100644
> index 00..b27a522009
> --- /dev/null
> +++ b/libavformat/vvc.c
> @@ -0,0 +1,919 @@
> +/*
> + * VVC helper functions for muxers
> + *
> + * Copyright (C) 2022, Thomas Siedel
> + *
> + * 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 "libavcodec/get_bits.h"
> +#include "libavcodec/golomb.h"
> +#include "libavcodec/vvc.h"
> +#include "libavutil/intreadwrite.h"
> +#include "avc.h"
> +#include "avio.h"
> +#include "avio_internal.h"
> +#include "vvc.h"
> +
> +typedef struct VVCCNALUnitArray {
> +uint8_t  array_completeness;
> +uint8_t  NAL_unit_type;
> +uint16_t num_nalus;
> +uint16_t *nal_unit_length;
> +uint8_t  **nal_unit;
> +} VVCCNALUnitArray;
> +
> +typedef struct

Re: [FFmpeg-devel] [PATCH] lavc/Makefile: fix make checkheaders fail

2022-08-05 Thread myp...@gmail.com
On Thu, Aug 4, 2022 at 6:34 PM Andreas Rheinhardt
 wrote:
>
> Jun Zhao:
> > Fix the break when used libavcodec/Makefile
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/Makefile | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 836132f430..5ba7fb6b86 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -1234,6 +1234,7 @@ SKIPHEADERS-$(CONFIG_D3D11VA)  += d3d11va.h 
> > dxva2_internal.h
> >  SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h
> >  SKIPHEADERS-$(CONFIG_JNI)  += ffjni.h
> >  SKIPHEADERS-$(CONFIG_LCMS2)+= fflcms2.h
> > +SKIPHEADERS-$(CONFIG_LIBAOM)   += libaom.h
> >  SKIPHEADERS-$(CONFIG_LIBJXL)   += libjxl.h
> >  SKIPHEADERS-$(CONFIG_LIBVPX)   += libvpx.h
> >  SKIPHEADERS-$(CONFIG_LIBWEBP_ENCODER)  += libwebpenc_common.h
> > @@ -1248,6 +1249,7 @@ SKIPHEADERS-$(CONFIG_VAAPI)+= 
> > vaapi_decode.h vaapi_hevc.h vaapi_enco
> >  SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
> >  SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
> >  SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h 
> > v4l2_m2m.h
> > +SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
> >
> >  TESTPROGS = avcodec \
> >  avpacket\
>
> LGTM.
>
> - Andreas
Thx the review, patch applyed
___
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/libuavs3d: use output_reorder_delay as has_b_frames

2022-05-13 Thread myp...@gmail.com
On Fri, May 13, 2022 at 5:41 PM Zhao Zhili  wrote:
>
> has_b_frames is more than a bool, it's the size of the frame
> reordering buffer in the decoder.
> ---
>  libavcodec/libuavs3d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c
> index 23de4c8cd5..e911963a41 100644
> --- a/libavcodec/libuavs3d.c
> +++ b/libavcodec/libuavs3d.c
> @@ -206,7 +206,7 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, 
> AVFrame *frm,
>  avctx->framerate.num = 
> ff_avs3_frame_rate_tab[seqh->frame_rate_code].num;
>  avctx->framerate.den = 
> ff_avs3_frame_rate_tab[seqh->frame_rate_code].den;
>  }
> -avctx->has_b_frames  = !seqh->low_delay;
> +avctx->has_b_frames = seqh->output_reorder_delay;
The same case, AVS3 uses output_reorder_delay but AVS2 uses low_delay,
which is a bit strange
>  avctx->pix_fmt = seqh->bit_depth_internal == 8 ? 
> AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV420P10LE;
>  ret = ff_set_dimensions(avctx, seqh->horizontal_size, 
> seqh->vertical_size);
>  if (ret < 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] avcodec/libuavs3d: fix access uninitialized variable when draining

2022-05-12 Thread myp...@gmail.com
On Thu, May 12, 2022 at 5:55 PM Zhao Zhili  wrote:
>
> buf_ptr is uninitialized and accessed when function return.
> ---
>  libavcodec/libuavs3d.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c
> index 6966e00b62..23de4c8cd5 100644
> --- a/libavcodec/libuavs3d.c
> +++ b/libavcodec/libuavs3d.c
> @@ -149,7 +149,7 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, 
> AVFrame *frm,
>  const uint8_t *buf = avpkt->data;
>  int buf_size = avpkt->size;
>  const uint8_t *buf_end;
> -const uint8_t *buf_ptr;
> +const uint8_t *buf_ptr = buf;
>  int left_bytes;
>  int ret, finish = 0;
>
> @@ -170,7 +170,6 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx, 
> AVFrame *frm,
>  } else {
>  uavs3d_io_frm_t *frm_dec = &h->dec_frame;
>
> -buf_ptr = buf;
>  buf_end = buf + buf_size;
>  frm_dec->pkt_pos  = avpkt->pos;
>  frm_dec->pkt_size = avpkt->size;
> --
> 2.35.3
Sounds Good To Me
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 3/3] lavf/cavsvideodec: Add GuangDian profile support

2022-05-07 Thread myp...@gmail.com
On Mon, May 2, 2022 at 1:15 PM "zhilizhao(赵志立)"  wrote:
>
>
>
> > On May 2, 2022, at 11:36 AM, Jun Zhao  wrote:
> >
> > From: Jun Zhao 
> >
> > Enable the Guangdian profile support
> >
> > Signed-off-by: Jun Zhao 
> > ---
> > libavformat/cavsvideodec.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/cavsvideodec.c b/libavformat/cavsvideodec.c
> > index 1fa3aa5e92..437ad544d3 100644
> > --- a/libavformat/cavsvideodec.c
> > +++ b/libavformat/cavsvideodec.c
> > @@ -29,6 +29,7 @@
> > #define CAVS_PIC_PB_START_CODE0x01b6
> > #define CAVS_VIDEO_EDIT_CODE  0x01b7
> > #define CAVS_PROFILE_JIZHUN   0x20
> > +#define CAVS_PROFILE_GUANGDIAN0x48
>
> Maybe add a comment here that ‘GUANGDIAN' is broadcasting profile.
>
Applied the patchset and add the comment, thx
> >
> > static int cavsvideo_probe(const AVProbeData *p)
> > {
> > @@ -50,7 +51,7 @@ static int cavsvideo_probe(const AVProbeData *p)
> > if (code == CAVS_SEQ_START_CODE) {
> > seq++;
> > /* check for the only currently supported profile */
> > -if (*ptr != CAVS_PROFILE_JIZHUN)
> > +if (*ptr != CAVS_PROFILE_JIZHUN && *ptr != 
> > CAVS_PROFILE_GUANGDIAN)
> > return 0;
> > } else if ((code == CAVS_PIC_I_START_CODE) ||
> >(code == CAVS_PIC_PB_START_CODE)) {
> > @@ -66,4 +67,4 @@ static int cavsvideo_probe(const AVProbeData *p)
> > return 0;
> > }
> >
> > -FF_DEF_RAWVIDEO_DEMUXER(cavsvideo, "raw Chinese AVS (Audio Video 
> > Standard)", cavsvideo_probe, NULL, AV_CODEC_ID_CAVS)
> > +FF_DEF_RAWVIDEO_DEMUXER(cavsvideo, "raw Chinese AVS (Audio Video 
> > Standard)", cavsvideo_probe, "avs", AV_CODEC_ID_CAVS)
> > --
> > 2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_libplacebo: Match AV_OPT_TYPE_FLOAT to dbl

2022-05-04 Thread myp...@gmail.com
On Wed, May 4, 2022 at 11:37 PM Michael Niedermayer
 wrote:
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/vf_libplacebo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
> index 5bcdd64d84..cfee1117e8 100644
> --- a/libavfilter/vf_libplacebo.c
> +++ b/libavfilter/vf_libplacebo.c
> @@ -718,7 +718,7 @@ static const AVOption libplacebo_options[] = {
>
>  /* Performance/quality tradeoff options */
>  { "skip_aa", "Skip anti-aliasing", OFFSET(skip_aa), AV_OPT_TYPE_BOOL, 
> {.i64 = 0}, 0, 0, DYNAMIC },
> -{ "polar_cutoff", "Polar LUT cutoff", OFFSET(polar_cutoff), 
> AV_OPT_TYPE_FLOAT, {.i64 = 0}, 0.0, 1.0, DYNAMIC },
> +{ "polar_cutoff", "Polar LUT cutoff", OFFSET(polar_cutoff), 
> AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0.0, 1.0, DYNAMIC },
>  { "disable_linear", "Disable linear scaling", OFFSET(disable_linear), 
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
>  { "disable_builtin", "Disable built-in scalers", 
> OFFSET(disable_builtin), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
>  { "force_icc_lut", "Force the use of a full ICC 3DLUT for color 
> mapping", OFFSET(force_icc_lut), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC 
> },
> --
> 2.17.1
>
Patchset looks good, thx
___
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 01/10] avformat/hls: fix repeated requests for media init section

2022-04-12 Thread myp...@gmail.com
On Tue, Apr 12, 2022 at 4:15 PM Zhao Zhili  wrote:
>
> ---
>  libavformat/hls.c | 59 ---
>  1 file changed, 40 insertions(+), 19 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 83ff4cc607..67c9650e0b 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -407,48 +407,65 @@ struct init_section_info {
>  char byterange[32];
>  };
>
> -static struct segment *new_init_section(struct playlist *pls,
> +/*
> + * Return a new init section if info is new, otherwise return an entry
> + * from pls->init_sections.
> + */
> +static struct segment *get_init_section(struct playlist *pls,
>  struct init_section_info *info,
> -const char *url_base)
> +const char *url_base,
> +int *new_init)
>  {
> -struct segment *sec;
> +struct segment *sec_ptr = NULL;
> +struct segment sec = {};
>  char tmp_str[MAX_URL_SIZE], *ptr = tmp_str;
>
> +*new_init = 1;
>  if (!info->uri[0])
>  return NULL;
>
> -sec = av_mallocz(sizeof(*sec));
> -if (!sec)
> -return NULL;
> -
>  if (!av_strncasecmp(info->uri, "data:", 5)) {
>  ptr = info->uri;
>  } else {
>  ff_make_absolute_url(tmp_str, sizeof(tmp_str), url_base, info->uri);
>  if (!tmp_str[0]) {
> -av_free(sec);
>  return NULL;
>  }
>  }
> -sec->url = av_strdup(ptr);
> -if (!sec->url) {
> -av_free(sec);
> -return NULL;
> -}
> +// Don't dup until make sure it's a new initialization section
> +sec.url = ptr;
>
>  if (info->byterange[0]) {
> -sec->size = strtoll(info->byterange, NULL, 10);
> +sec.size = strtoll(info->byterange, NULL, 10);
>  ptr = strchr(info->byterange, '@');
>  if (ptr)
> -sec->url_offset = strtoll(ptr+1, NULL, 10);
> +sec.url_offset = strtoll(ptr+1, NULL, 10);
>  } else {
>  /* the entire file is the init section */
> -sec->size = -1;
> +sec.size = -1;
>  }
>
> -dynarray_add(&pls->init_sections, &pls->n_init_sections, sec);
> +for (int i = 0; i < pls->n_init_sections; i++) {
> +sec_ptr = pls->init_sections[i];
> +if (!strcmp(sec_ptr->url, sec.url) &&
> +sec_ptr->size == sec.size &&
> +sec_ptr->url_offset == sec.url_offset) {
> +*new_init = 0;
> +return sec_ptr;
> +}
> +}
> +
> +sec_ptr = av_malloc(sizeof(*sec_ptr));
> +if (!sec_ptr) return NULL;
> +*sec_ptr = sec;
> +sec_ptr->url = av_strdup(ptr);
> +if (!sec_ptr->url) {
> +av_free(sec_ptr);
> +return NULL;
> +}
> +dynarray_add(&pls->init_sections, &pls->n_init_sections, sec_ptr);
>
> -return sec;
> +return sec_ptr;
>  }
>
>  static void handle_init_section_args(struct init_section_info *info, const 
> char *key,
> @@ -851,13 +868,17 @@ static int parse_playlist(HLSContext *c, const char 
> *url,
>  else if (!strcmp(ptr, "VOD"))
>  pls->type = PLS_TYPE_VOD;
>  } else if (av_strstart(line, "#EXT-X-MAP:", &ptr)) {
> +int new_init = 1;
>  struct init_section_info info = {{0}};
>  ret = ensure_playlist(c, &pls, url);
>  if (ret < 0)
>  goto fail;
>  ff_parse_key_value(ptr, (ff_parse_key_val_cb) 
> handle_init_section_args,
> &info);
> -cur_init_section = new_init_section(pls, &info, url);
> +cur_init_section = get_init_section(pls, &info, url, &new_init);
> +/* Skip if it's the same init section */
> +if (!new_init)
> +continue;
>  if (!cur_init_section) {
>  ret = AVERROR(ENOMEM);
>  goto fail;
> --
> 2.31.1
Can these patches handle multiple instances of the media init sections?
___
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/webmdashenc: fix on-demand profile string

2022-04-07 Thread myp...@gmail.com
On Fri, Apr 8, 2022 at 8:58 AM James Almer  wrote:
>
> Fixes ticket #9596
>
> Signed-off-by: James Almer 
> ---
>  libavformat/webmdashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
> index a942c484e9..f8f2274556 100644
> --- a/libavformat/webmdashenc.c
> +++ b/libavformat/webmdashenc.c
> @@ -95,7 +95,7 @@ static int write_header(AVFormatContext *s)
>  }
>  avio_printf(pb, "  minBufferTime=\"PT%gS\"\n", min_buffer_time);
>  avio_printf(pb, "  profiles=\"%s\"%s",
> -w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" : 
> "urn:webm:dash:profile:webm-on-demand:2012",
> +w->is_live ? "urn:mpeg:dash:profile:isoff-live:2011" : 
> "urn:mpeg:dash:profile:webm-on-demand:2012",
>  w->is_live ? "\n" : ">\n");
>  if (w->is_live) {
>  time_t local_time = time(NULL);
LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avformat/libsrt: use a larger buffer for find_info_tag

2022-03-28 Thread myp...@gmail.com
On Tue, Mar 29, 2022 at 10:21 AM "zhilizhao(赵志立)"
 wrote:
>
> Ping.
>
> > On Aug 14, 2021, at 6:43 PM, Zhao Zhili  wrote:
> >
> > The upper limit of strlen(streamid) is 512. Use a larger buffer for
> > future proof, for example, deal with percent-encoding.
> > ---
> > libavformat/libsrt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> > index e5701625b8..a66c85d3a2 100644
> > --- a/libavformat/libsrt.c
> > +++ b/libavformat/libsrt.c
> > @@ -513,7 +513,7 @@ static int libsrt_open(URLContext *h, const char *uri, 
> > int flags)
> > {
> > SRTContext *s = h->priv_data;
> > const char * p;
> > -char buf[256];
> > +char buf[1024];
> > int ret = 0;
> >
> > if (srt_startup() < 0) {
> > --
> > 2.31.1

LGTM, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavf/udp: set ttl upper bound to 255

2022-01-27 Thread myp...@gmail.com
On Thu, Jan 27, 2022 at 1:09 PM "zhilizhao(赵志立)"  wrote:
>
>
>
> > On Jan 27, 2022, at 12:22 AM, Zhao Zhili  wrote:
> >
> > ---
> > libavformat/udp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/udp.c b/libavformat/udp.c
> > index 83c042d079..b441d2ea0d 100644
> > --- a/libavformat/udp.c
> > +++ b/libavformat/udp.c
> > @@ -134,7 +134,7 @@ static const AVOption options[] = {
> > { "reuse",  "explicitly allow reusing UDP sockets",
> > OFFSET(reuse_socket),   AV_OPT_TYPE_BOOL,   { .i64 = -1 },-1, 1,   
> > D|E },
> > { "reuse_socket",   "explicitly allow reusing UDP sockets",
> > OFFSET(reuse_socket),   AV_OPT_TYPE_BOOL,   { .i64 = -1 },-1, 1,   
> > .flags = D|E },
> > { "broadcast", "explicitly allow or disallow broadcast destination",   
> > OFFSET(is_broadcast),   AV_OPT_TYPE_BOOL,   { .i64 = 0  }, 0, 1,   
> > E },
> > -{ "ttl","Time to live (multicast only)",   
> > OFFSET(ttl),AV_OPT_TYPE_INT,{ .i64 = 16 }, 0, INT_MAX, 
> > E },
> > +{ "ttl","Time to live (multicast only)",   
> > OFFSET(ttl),AV_OPT_TYPE_INT,{ .i64 = 16 }, 0, 255, 
> > E },
> > { "connect","set if connect() should be called on socket", 
> > OFFSET(is_connected),   AV_OPT_TYPE_BOOL,   { .i64 =  0 }, 0, 1,   
> > .flags = D|E },
> > { "fifo_size",  "set the UDP receiving circular buffer size, 
> > expressed as a number of packets with size of 188 bytes", 
> > OFFSET(circular_buffer_size), AV_OPT_TYPE_INT, {.i64 = 7*4096}, 0, INT_MAX, 
> > D },
> > { "overrun_nonfatal", "survive in case of UDP receiving circular buffer 
> > overrun", OFFSET(overrun_nonfatal), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
> > D },
> > --
> > 2.29.2
> >
>
> This patchset is related to 'Fix setsockopt IP_MULTICAST_TTL on OpenBSD’.
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/yd5jaxbcd6gp7...@humpty.home.comstyle.com/
>
> Looks like it’s impossible to avoid casting int to unsigned char, so integer
> overflow/truncation must be handled. Since the maximum value of TTL is 255
> limited by IPv4/IPv6, set the upper bound of AVOption to fail early for
> invalid value.
Patchset LGTM, limited the TTL(Time to live) in IPv4  <= 255 in option
is better than coding in the function
___
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] lavc/qsvenc: add tile encoding support for VP9

2022-01-17 Thread myp...@gmail.com
On Mon, Jan 17, 2022 at 6:57 PM Soft Works  wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > myp...@gmail.com
> > Sent: Monday, January 17, 2022 11:36 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: add tile encoding 
> > support
> > for VP9
> >
> > On Mon, Jan 17, 2022 at 4:30 PM Xiang, Haihao
> >  wrote:
> > >
> > > On Thu, 2022-01-13 at 13:45 +0800, Haihao Xiang wrote:
> > > > Add -tile_rows and -tile_cols options to specify the number of tile
> > > > rows and columns
> > > >
> > > > Signed-off-by: Haihao Xiang 
> > > > ---
> > > > v2: add option descriptions in the doc
> > > >
> > > >  doc/encoders.texi   |  6 ++
> > > >  libavcodec/qsvenc.c |  4 
> > > >  libavcodec/qsvenc.h |  1 +
> > > >  libavcodec/qsvenc_vp9.c | 10 ++
> > > >  4 files changed, 21 insertions(+)
> > > >
> > > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > > index 7cc8be1209..a4176089d5 100644
> > > > --- a/doc/encoders.texi
> > > > +++ b/doc/encoders.texi
> > > > @@ -3457,6 +3457,12 @@ These options are used by vp9_qsv
> > > >  @item profile2
> > > >  @item profile3
> > > >  @end table
> > > > +
> > > > +@item @var{tile_cols}
> > > > +Number of columns for tiled encoding (requires libmfx >= 1.29).
> > > > +
> > > > +@item @var{tile_rows}
> > > > +Number of rows for tiled encoding (requires libmfx  >= 1.29).
> > > >  @end table
> > > >
> > > >  @section snow
> > > > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > > > index 4e7a15f060..4cbc9ff4dc 100644
> > > > --- a/libavcodec/qsvenc.c
> > > > +++ b/libavcodec/qsvenc.c
> > > > @@ -939,6 +939,10 @@ static int init_video_param(AVCodecContext *avctx,
> > > > QSVEncContext *q)
> > > >  q->extvp9param.Header.BufferId = MFX_EXTBUFF_VP9_PARAM;
> > > >  q->extvp9param.Header.BufferSz = sizeof(q->extvp9param);
> > > >  q->extvp9param.WriteIVFHeaders = MFX_CODINGOPTION_OFF;
> > > > +#if QSV_HAVE_EXT_VP9_TILES
> > > > +q->extvp9param.NumTileColumns  = q->tile_cols;
> > > > +q->extvp9param.NumTileRows = q->tile_rows;
> > > > +#endif
> > > >  q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> > *)&q-
> > > > >extvp9param;
> > > >  }
> > > >  #endif
> > > > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> > > > index 31516b8e55..00ee52a5d1 100644
> > > > --- a/libavcodec/qsvenc.h
> > > > +++ b/libavcodec/qsvenc.h
> > > > @@ -41,6 +41,7 @@
> > > >
> > > >  #define QSV_HAVE_EXT_HEVC_TILES QSV_VERSION_ATLEAST(1, 13)
> > > >  #define QSV_HAVE_EXT_VP9_PARAM QSV_VERSION_ATLEAST(1, 26)
> > > > +#define QSV_HAVE_EXT_VP9_TILES QSV_VERSION_ATLEAST(1, 29)
> > > >
> > > >  #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
> > > >  #define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
> > > > diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
> > > > index 9329990d11..1168ddda0e 100644
> > > > --- a/libavcodec/qsvenc_vp9.c
> > > > +++ b/libavcodec/qsvenc_vp9.c
> > > > @@ -73,6 +73,16 @@ static const AVOption options[] = {
> > > >  { "profile2",  NULL, 0,   AV_OPT_TYPE_CONST, { .i64
> > =
> > > > MFX_PROFILE_VP9_2   },  INT_MIN,  INT_MAX,  VE,  "profile" },
> > > >  { "profile3",  NULL, 0,   AV_OPT_TYPE_CONST, { .i64
> > =
> > > > MFX_PROFILE_VP9_3   },  INT_MIN,  INT_MAX,  VE,  "profile" },
> > > >
> > > > +#if QSV_HAVE_EXT_VP9_TILES
> > > > +/* The minimum tile width in luma pixels is 256, set maximum
> > tile_cols to
> > > > 32 for 8K video */
> > > > +{ "tile_cols",  "Number of columns for tiled
> > > > encoding",   OFFSET(qsv.tile_cols),AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> > 32,
> > > > VE },
> > > > +/* Set maximum tile_rows to 4 per VP9 spec */
> > > > + 

Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: add tile encoding support for VP9

2022-01-17 Thread myp...@gmail.com
On Mon, Jan 17, 2022 at 4:30 PM Xiang, Haihao
 wrote:
>
> On Thu, 2022-01-13 at 13:45 +0800, Haihao Xiang wrote:
> > Add -tile_rows and -tile_cols options to specify the number of tile
> > rows and columns
> >
> > Signed-off-by: Haihao Xiang 
> > ---
> > v2: add option descriptions in the doc
> >
> >  doc/encoders.texi   |  6 ++
> >  libavcodec/qsvenc.c |  4 
> >  libavcodec/qsvenc.h |  1 +
> >  libavcodec/qsvenc_vp9.c | 10 ++
> >  4 files changed, 21 insertions(+)
> >
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 7cc8be1209..a4176089d5 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -3457,6 +3457,12 @@ These options are used by vp9_qsv
> >  @item profile2
> >  @item profile3
> >  @end table
> > +
> > +@item @var{tile_cols}
> > +Number of columns for tiled encoding (requires libmfx >= 1.29).
> > +
> > +@item @var{tile_rows}
> > +Number of rows for tiled encoding (requires libmfx  >= 1.29).
> >  @end table
> >
> >  @section snow
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index 4e7a15f060..4cbc9ff4dc 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -939,6 +939,10 @@ static int init_video_param(AVCodecContext *avctx,
> > QSVEncContext *q)
> >  q->extvp9param.Header.BufferId = MFX_EXTBUFF_VP9_PARAM;
> >  q->extvp9param.Header.BufferSz = sizeof(q->extvp9param);
> >  q->extvp9param.WriteIVFHeaders = MFX_CODINGOPTION_OFF;
> > +#if QSV_HAVE_EXT_VP9_TILES
> > +q->extvp9param.NumTileColumns  = q->tile_cols;
> > +q->extvp9param.NumTileRows = q->tile_rows;
> > +#endif
> >  q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer 
> > *)&q-
> > >extvp9param;
> >  }
> >  #endif
> > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> > index 31516b8e55..00ee52a5d1 100644
> > --- a/libavcodec/qsvenc.h
> > +++ b/libavcodec/qsvenc.h
> > @@ -41,6 +41,7 @@
> >
> >  #define QSV_HAVE_EXT_HEVC_TILES QSV_VERSION_ATLEAST(1, 13)
> >  #define QSV_HAVE_EXT_VP9_PARAM QSV_VERSION_ATLEAST(1, 26)
> > +#define QSV_HAVE_EXT_VP9_TILES QSV_VERSION_ATLEAST(1, 29)
> >
> >  #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
> >  #define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
> > diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
> > index 9329990d11..1168ddda0e 100644
> > --- a/libavcodec/qsvenc_vp9.c
> > +++ b/libavcodec/qsvenc_vp9.c
> > @@ -73,6 +73,16 @@ static const AVOption options[] = {
> >  { "profile2",  NULL, 0,   AV_OPT_TYPE_CONST, { .i64 =
> > MFX_PROFILE_VP9_2   },  INT_MIN,  INT_MAX,  VE,  "profile" },
> >  { "profile3",  NULL, 0,   AV_OPT_TYPE_CONST, { .i64 =
> > MFX_PROFILE_VP9_3   },  INT_MIN,  INT_MAX,  VE,  "profile" },
> >
> > +#if QSV_HAVE_EXT_VP9_TILES
> > +/* The minimum tile width in luma pixels is 256, set maximum tile_cols 
> > to
> > 32 for 8K video */
> > +{ "tile_cols",  "Number of columns for tiled
> > encoding",   OFFSET(qsv.tile_cols),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 32,
> > VE },
> > +/* Set maximum tile_rows to 4 per VP9 spec */
> > +{ "tile_rows",  "Number of rows for tiled
> > encoding",  OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 
> > 4,
> > VE },
> > +#else
> > +{ "tile_cols",  "(not
> > supported)",OFFSET(qsv.tile_cols),
> > AV_OPT_TYPE_INT,
> > { .i64 = 0 }, 0, 0, VE },
> > +{ "tile_rows",  "(not
> > supported)",OFFSET(qsv.tile_rows),
> > AV_OPT_TYPE_INT,
> > { .i64 = 0 }, 0, 0, VE },
> > +#endif
> > +
perfer one option like "-tile rows x cols" than two options like
"-tile_rows  row  -tile_cols  col"
> >  { NULL },
> >  };
> >
>
> Will apply,
>
> -Haihao
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavc/{av1, h264, h265}_metadata_bsf: fix description of tick_rate

2021-12-14 Thread myp...@gmail.com
On Tue, Dec 14, 2021 at 11:26 AM myp...@gmail.com  wrote:
>
> On Fri, Aug 27, 2021 at 3:14 PM Zhao Zhili  wrote:
> >
> > Users may take the description literally which leads to inverted
> > results.
> > ---
> >  doc/bitstream_filters.texi | 8 
> >  libavcodec/av1_metadata_bsf.c  | 2 +-
> >  libavcodec/h264_metadata_bsf.c | 2 +-
> >  libavcodec/h265_metadata_bsf.c | 2 +-
> >  4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> > index 1900eb4352..6051dc28d2 100644
> > --- a/doc/bitstream_filters.texi
> > +++ b/doc/bitstream_filters.texi
> > @@ -81,7 +81,7 @@ Top-left position.
> >  @end table
> >
> >  @item tick_rate
> > -Set the tick rate (@emph{num_units_in_display_tick / time_scale}) in
> > +Set the tick rate (@emph{time_scale / num_units_in_display_tick}) in
> >  the timing info in the sequence header.
> >  @item num_ticks_per_picture
> >  Set the number of ticks in each picture, to indicate that the stream
> > @@ -244,7 +244,7 @@ Set the chroma sample location in the stream (see H.264 
> > section
> >  E.2.1 and figure E-1).
> >
> >  @item tick_rate
> > -Set the tick rate (num_units_in_tick / time_scale) in the VUI
> > +Set the tick rate (time_scale / num_units_in_tick) in the VUI
> >  parameters.  This is the smallest time unit representable in the
> >  stream, and in many cases represents the field rate of the stream
> >  (double the frame rate).
> > @@ -352,8 +352,8 @@ Set the chroma sample location in the stream (see H.265 
> > section
> >  E.3.1 and figure E.1).
> >
> >  @item tick_rate
> > -Set the tick rate in the VPS and VUI parameters (num_units_in_tick /
> > -time_scale).  Combined with @option{num_ticks_poc_diff_one}, this can
> > +Set the tick rate in the VPS and VUI parameters (time_scale /
> > +num_units_in_tick). Combined with @option{num_ticks_poc_diff_one}, this can
> >  set a constant framerate in the stream.  Note that it is likely to be
> >  overridden by container parameters when the stream is in a container.
> >
> > diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
> > index 1fb85d88b7..c52673bf6a 100644
> > --- a/libavcodec/av1_metadata_bsf.c
> > +++ b/libavcodec/av1_metadata_bsf.c
> > @@ -194,7 +194,7 @@ static const AVOption av1_metadata_options[] = {
> >  { "colocated", "Top-left chroma sample position", 0, AV_OPT_TYPE_CONST,
> >  { .i64 = AV1_CSP_COLOCATED }, .flags = FLAGS, .unit = "csp" },
> >
> > -{ "tick_rate", "Set display tick rate (num_units_in_display_tick / 
> > time_scale)",
> > +{ "tick_rate", "Set display tick rate (time_scale / 
> > num_units_in_display_tick)",
> >  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
> >  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
> >  { "num_ticks_per_picture", "Set display ticks per picture for CFR 
> > streams",
> > diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> > index 452a8ec5dc..c79d91dcef 100644
> > --- a/libavcodec/h264_metadata_bsf.c
> > +++ b/libavcodec/h264_metadata_bsf.c
> > @@ -617,7 +617,7 @@ static const AVOption h264_metadata_options[] = {
> >  OFFSET(chroma_sample_loc_type), AV_OPT_TYPE_INT,
> >  { .i64 = -1 }, -1, 6, FLAGS },
> >
> > -{ "tick_rate", "Set VUI tick rate (num_units_in_tick / time_scale)",
> > +{ "tick_rate", "Set VUI tick rate (time_scale / num_units_in_tick)",
> >  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
> >  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
> >  { "fixed_frame_rate_flag", "Set VUI fixed frame rate flag",
> > diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
> > index d841839762..e5f70cfbc1 100644
> > --- a/libavcodec/h265_metadata_bsf.c
> > +++ b/libavcodec/h265_metadata_bsf.c
> > @@ -439,7 +439,7 @@ static const AVOption h265_metadata_options[] = {
> >  { .i64 = -1 }, -1, 6, FLAGS },
> >
> >  { "tick_rate",
> > -"Set VPS and VUI tick rate (num_units_in_tick / time_scale)",
> > +"Set VPS and VUI tick rate (time_scale / num_units_in_tick)",
> >  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
> >  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
> >  { "num_ticks_poc_diff_one",
> > --
>
> Patch is Ok,tick rate  is likes to  frame rate, so  time_scale /
> num_units_in_tick is the correct way to calculate it. Thx

Will apply if no other comments after 3 days,  thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavc/{av1, h264, h265}_metadata_bsf: fix description of tick_rate

2021-12-13 Thread myp...@gmail.com
On Fri, Aug 27, 2021 at 3:14 PM Zhao Zhili  wrote:
>
> Users may take the description literally which leads to inverted
> results.
> ---
>  doc/bitstream_filters.texi | 8 
>  libavcodec/av1_metadata_bsf.c  | 2 +-
>  libavcodec/h264_metadata_bsf.c | 2 +-
>  libavcodec/h265_metadata_bsf.c | 2 +-
>  4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 1900eb4352..6051dc28d2 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -81,7 +81,7 @@ Top-left position.
>  @end table
>
>  @item tick_rate
> -Set the tick rate (@emph{num_units_in_display_tick / time_scale}) in
> +Set the tick rate (@emph{time_scale / num_units_in_display_tick}) in
>  the timing info in the sequence header.
>  @item num_ticks_per_picture
>  Set the number of ticks in each picture, to indicate that the stream
> @@ -244,7 +244,7 @@ Set the chroma sample location in the stream (see H.264 
> section
>  E.2.1 and figure E-1).
>
>  @item tick_rate
> -Set the tick rate (num_units_in_tick / time_scale) in the VUI
> +Set the tick rate (time_scale / num_units_in_tick) in the VUI
>  parameters.  This is the smallest time unit representable in the
>  stream, and in many cases represents the field rate of the stream
>  (double the frame rate).
> @@ -352,8 +352,8 @@ Set the chroma sample location in the stream (see H.265 
> section
>  E.3.1 and figure E.1).
>
>  @item tick_rate
> -Set the tick rate in the VPS and VUI parameters (num_units_in_tick /
> -time_scale).  Combined with @option{num_ticks_poc_diff_one}, this can
> +Set the tick rate in the VPS and VUI parameters (time_scale /
> +num_units_in_tick). Combined with @option{num_ticks_poc_diff_one}, this can
>  set a constant framerate in the stream.  Note that it is likely to be
>  overridden by container parameters when the stream is in a container.
>
> diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
> index 1fb85d88b7..c52673bf6a 100644
> --- a/libavcodec/av1_metadata_bsf.c
> +++ b/libavcodec/av1_metadata_bsf.c
> @@ -194,7 +194,7 @@ static const AVOption av1_metadata_options[] = {
>  { "colocated", "Top-left chroma sample position", 0, AV_OPT_TYPE_CONST,
>  { .i64 = AV1_CSP_COLOCATED }, .flags = FLAGS, .unit = "csp" },
>
> -{ "tick_rate", "Set display tick rate (num_units_in_display_tick / 
> time_scale)",
> +{ "tick_rate", "Set display tick rate (time_scale / 
> num_units_in_display_tick)",
>  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
>  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
>  { "num_ticks_per_picture", "Set display ticks per picture for CFR 
> streams",
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 452a8ec5dc..c79d91dcef 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -617,7 +617,7 @@ static const AVOption h264_metadata_options[] = {
>  OFFSET(chroma_sample_loc_type), AV_OPT_TYPE_INT,
>  { .i64 = -1 }, -1, 6, FLAGS },
>
> -{ "tick_rate", "Set VUI tick rate (num_units_in_tick / time_scale)",
> +{ "tick_rate", "Set VUI tick rate (time_scale / num_units_in_tick)",
>  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
>  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
>  { "fixed_frame_rate_flag", "Set VUI fixed frame rate flag",
> diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
> index d841839762..e5f70cfbc1 100644
> --- a/libavcodec/h265_metadata_bsf.c
> +++ b/libavcodec/h265_metadata_bsf.c
> @@ -439,7 +439,7 @@ static const AVOption h265_metadata_options[] = {
>  { .i64 = -1 }, -1, 6, FLAGS },
>
>  { "tick_rate",
> -"Set VPS and VUI tick rate (num_units_in_tick / time_scale)",
> +"Set VPS and VUI tick rate (time_scale / num_units_in_tick)",
>  OFFSET(tick_rate), AV_OPT_TYPE_RATIONAL,
>  { .dbl = 0.0 }, 0, UINT_MAX, FLAGS },
>  { "num_ticks_poc_diff_one",
> --

Patch is Ok,tick rate  is likes to  frame rate, so  time_scale /
num_units_in_tick is the correct way to calculate it. Thx
___
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/8] avformat/mov: support dvwC box for Dolby Vision

2021-10-15 Thread myp...@gmail.com
On Thu, Oct 14, 2021 at 9:10 PM  wrote:
>
> From: Limin Wang 
>
> By <>
>
> Signed-off-by: Limin Wang 
> ---
>  libavformat/mov.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 57c67e3..49a8c27 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7074,7 +7074,7 @@ static int mov_read_dvcc_dvvc(MOVContext *c, 
> AVIOContext *pb, MOVAtom atom)
>  return ret;
>  }
>
> -av_log(c, AV_LOG_TRACE, "DOVI in dvcC/dvvC box, version: %d.%d, profile: 
> %d, level: %d, "
> +av_log(c, AV_LOG_TRACE, "DOVI in dvcC/dvvC/dvwC box, version: %d.%d, 
> profile: %d, level: %d, "
> "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
> dovi->dv_version_major, dovi->dv_version_minor,
> dovi->dv_profile, dovi->dv_level,
> @@ -7273,6 +7273,7 @@ static const MOVParseTableEntry 
> mov_default_parse_table[] = {
>  { MKTAG('c','l','l','i'), mov_read_clli },
>  { MKTAG('d','v','c','C'), mov_read_dvcc_dvvc },
>  { MKTAG('d','v','v','C'), mov_read_dvcc_dvvc },
> +{ MKTAG('d','v','w','C'), mov_read_dvcc_dvvc },
>  { MKTAG('k','i','n','d'), mov_read_kind },
>  { 0, NULL }
>  };
> --
> 1.8.3.1
Do you have test clip for this patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1] avfilter/vf_avgblur: switch to faster algorithm

2021-10-07 Thread myp...@gmail.com
On Thu, Sep 30, 2021 at 12:01 AM Paul B Mahol  wrote:
>
> will apply soon.
Ok, in my testbed, the patch gets about twice the performance gain
with small radius
___
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 1/4] avformat/dovi_isom Implement Dolby Vision configuration parsing/writing

2021-09-26 Thread myp...@gmail.com
On Mon, Sep 27, 2021 at 10:57 AM quietvoid  wrote:
>
> According to specification "Dolby Vision Stream Within the ISO Base Media 
> File Format Version 2.2"
>
> This only adds support for the "Dolby Vision configuration box".
> Other configuration boxes such as "Dolby Vision enhancement layer 
> configuration box" are not supported.
>
> The new functions will be used to implement parsing/writing the DOVI config 
> for Matroska.
> As well as to refactor MOV/MPEG TS to parse the DOVI box/descriptor using 
> dovi_isom.
>
> Signed-off-by: quietvoid 
> ---
>  libavformat/dovi_isom.c | 120 
>  libavformat/dovi_isom.h |  35 
>  2 files changed, 155 insertions(+)
>  create mode 100644 libavformat/dovi_isom.c
>  create mode 100644 libavformat/dovi_isom.h
>
> diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
> new file mode 100644
> index 00..747ffc8b2c
> --- /dev/null
> +++ b/libavformat/dovi_isom.c
> @@ -0,0 +1,120 @@
> +/*
> + * DOVI ISO Media common code
> + * Copyright (c) 2021 quietvoid
> + *
> + * 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 "libavutil/dovi_meta.h"
> +
> +#include "libavcodec/put_bits.h"
> +
> +#include "avformat.h"
> +#include "dovi_isom.h"
> +
> +int ff_isom_parse_dvcc_dvvc(AVFormatContext *s, AVStream *st, const uint8_t 
> *buf_ptr, uint64_t size)
> +{
> +uint32_t buf;
> +AVDOVIDecoderConfigurationRecord *dovi;
> +size_t dovi_size;
> +int ret;
> +
> +if (size > (1 << 30) || size < 4)
> +return AVERROR_INVALIDDATA;
> +
> +dovi = av_dovi_alloc(&dovi_size);
> +if (!dovi)
> +return AVERROR(ENOMEM);
> +
> +dovi->dv_version_major = *buf_ptr++;// 8 bits
> +dovi->dv_version_minor = *buf_ptr++;// 8 bits
> +
> +buf = *buf_ptr++ << 8;
> +buf |= *buf_ptr++;
> +
> +dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
> +dovi->dv_level  = (buf >> 3) & 0x3f;// 6 bits
> +dovi->rpu_present_flag  = (buf >> 2) & 0x01;// 1 bit
> +dovi->el_present_flag   = (buf >> 1) & 0x01;// 1 bit
> +dovi->bl_present_flag   =  buf   & 0x01;// 1 bit
> +
> +// Has enough remaining data
> +if (size >= 5) {
> +dovi->dv_bl_signal_compatibility_id = ((*buf_ptr++) >> 4) & 0x0f; // 
> 4 bits
> +} else {
> +// 0 stands for None
> +// Dolby Vision V1.2.93 profiles and levels
> +dovi->dv_bl_signal_compatibility_id = 0;
> +}
> +
> +ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
> +  (uint8_t *)dovi, dovi_size);
> +if (ret < 0) {
> +av_free(dovi);
> +return ret;
> +}
> +
> +av_log(s, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d, level: %d, "
> +   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
> +   dovi->dv_version_major, dovi->dv_version_minor,
> +   dovi->dv_profile, dovi->dv_level,
> +   dovi->rpu_present_flag,
> +   dovi->el_present_flag,
> +   dovi->bl_present_flag,
> +   dovi->dv_bl_signal_compatibility_id
> +);
> +
> +return 0;
> +}
> +
> +int ff_isom_put_dvcc_dvvc(AVFormatContext *s, uint8_t 
> out[ISOM_DVCC_DVVC_SIZE], uint64_t size,
> + AVDOVIDecoderConfigurationRecord *dovi)
> +{
> +PutBitContext pb;
> +init_put_bits(&pb, out, size);
> +
> +if (size < ISOM_DVCC_DVVC_SIZE)
> +return AVERROR(EINVAL);
> +
> +put_bits(&pb, 8, dovi->dv_version_major);
> +put_bits(&pb, 8, dovi->dv_version_minor);
> +put_bits(&pb, 7, dovi->dv_profile);
> +put_bits(&pb, 6, dovi->dv_level);
> +put_bits(&pb, 1, dovi->rpu_present_flag);
> +put_bits(&pb, 1, dovi->el_present_flag);
> +put_bits(&pb, 1, dovi->bl_present_flag);
> +put_bits(&pb, 4, dovi->dv_bl_signal_compatibility_id);
> +
> +put_bits(&pb, 28, 0); /* reserved */
> +put_bits32(&pb, 0); /* reserved */
> +put_bits32(&pb, 0); /* reserved */
> +put_bits32(&pb, 0); /* reserved */
> +put_bits32(&pb, 0); /* reserved */
> +flush_put_bits(&pb);
> +
> +av_log(s, AV_LOG_DEBUG, "DOVI in %s box, version: %d.%d, profile: %d, 
> level: %d, "
> + 

Re: [FFmpeg-devel] [PATCH 1] avfilter/vf_avgblur: switch to faster algorithm

2021-09-26 Thread myp...@gmail.com
On Sun, Sep 26, 2021 at 8:11 PM Paul B Mahol  wrote:
>
> On Sun, Sep 26, 2021 at 1:27 PM myp...@gmail.com  wrote:
>
> > On Sun, Sep 26, 2021 at 4:11 PM Paul B Mahol  wrote:
> > >
> > > Signed-off-by: Paul B Mahol 
> > > ---
> > >  libavfilter/vf_avgblur.c  | 311 ++
> > >  tests/ref/fate/filter-refcmp-psnr-yuv |  80 +++
> > >  2 files changed, 211 insertions(+), 180 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_avgblur.c b/libavfilter/vf_avgblur.c
> > > index 3e222a43fa..a838285bb4 100644
> > > --- a/libavfilter/vf_avgblur.c
> > > +++ b/libavfilter/vf_avgblur.c
> > > @@ -20,6 +20,7 @@
> > >   * SOFTWARE.
> > >   */
> > >
> > > +#include "libavutil/avassert.h"
> > >  #include "libavutil/imgutils.h"
> > >  #include "libavutil/opt.h"
> > >  #include "libavutil/pixdesc.h"
> > > @@ -36,13 +37,15 @@ typedef struct AverageBlurContext {
> > >  int planes;
> > >
> > >  int depth;
> > > +int max;
> > > +int area;
> > >  int planewidth[4];
> > >  int planeheight[4];
> > > -float *buffer;
> > > +void *buffer;
> > > +uint16_t lut[256 * 256 * 256];
> > >  int nb_planes;
> > >
> > > -int (*filter_horizontally)(AVFilterContext *ctx, void *arg, int
> > jobnr, int nb_jobs);
> > > -int (*filter_vertically)(AVFilterContext *ctx, void *arg, int
> > jobnr, int nb_jobs);
> > > +int (*filter[2])(AVFilterContext *ctx, void *arg, int jobnr, int
> > nb_jobs);
> > >  } AverageBlurContext;
> > >
> > >  #define OFFSET(x) offsetof(AverageBlurContext, x)
> > > @@ -60,124 +63,138 @@ AVFILTER_DEFINE_CLASS(avgblur);
> > >  typedef struct ThreadData {
> > >  int height;
> > >  int width;
> > > -uint8_t *ptr;
> > > -int linesize;
> > > +const void *ptr;
> > > +void *dptr;
> > > +int linesize, dlinesize;
> > >  } ThreadData;
> > >
> > > -#define HORIZONTAL_FILTER(name, type)
> >\
> > > -static int filter_horizontally_##name(AVFilterContext *ctx, void *arg,
> > int jobnr, int nb_jobs)\
> > > -{
> >\
> > > -AverageBlurContext *s = ctx->priv;
> >   \
> > > -ThreadData *td = arg;
> >\
> > > -const int height = td->height;
> >   \
> > > -const int width = td->width;
> >   \
> > > -const int slice_start = (height *  jobnr   ) / nb_jobs;
> >\
> > > -const int slice_end   = (height * (jobnr+1)) / nb_jobs;
> >\
> > > -const int radius = FFMIN(s->radius, width / 2);
> >\
> > > -const int linesize = td->linesize / sizeof(type);
> >\
> > > -float *buffer = s->buffer;
> >   \
> > > -const type *src;
> >   \
> > > -float *ptr;
> >\
> > > -int y, x;
> >\
> > > -
> >   \
> > > -/* Filter horizontally along each row */
> >   \
> > > -for (y = slice_start; y < slice_end; y++) {
> >\
> > > -float acc = 0;
> >   \
> > > -int count = 0;
> >   \
> > > -
> >   \
> > > -src = (const type *)td->ptr + linesize * y;
> >\
> > > -ptr = buffer + width * y;
> >\
> > > -
> >   \
> > > -for (x = 0; x < radius; x++) {
> >   \
> > > -acc += src[x];
> >   \
> > > -}
> >\
> > > -count += radius;
> >   \
> > > -
> >   \
> > > -for (x = 0; x <= radius; x++) {
> >\
> > > -acc += src[x + radius];
> >\
> > > -count++;
> > 

Re: [FFmpeg-devel] [PATCH v1 1/1] avformat/amr: Return PATCHWELCOME on stereo files

2021-09-26 Thread myp...@gmail.com
On Thu, Sep 16, 2021 at 11:24 AM sunzhenliang
 wrote:
>
> Signed-off-by: sunzhenliang 
> ---
>  libavformat/amr.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/amr.c b/libavformat/amr.c
> index 836b276fd5..2762010ebe 100644
> --- a/libavformat/amr.c
> +++ b/libavformat/amr.c
> @@ -36,8 +36,10 @@ typedef struct {
>  uint64_t block_count;
>  } AMRContext;
>
> -static const char AMR_header[]   = "#!AMR\n";
> -static const char AMRWB_header[] = "#!AMR-WB\n";
> +static const char AMR_header[]  = "#!AMR\n";
> +static const char AMR_MC_header[]   = "#!AMR_MC1.0\n";
> +static const char AMRWB_header[]= "#!AMR-WB\n";
> +static const char AMRWB_MC_header[] = "#!AMR-WB_MC1.0\n";
I don't think you need to format the AMR_header[] and AMRWB_header[]
in the patch
>
>  static const uint8_t amrnb_packed_size[16] = {
>  13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
> @@ -82,7 +84,7 @@ static int amr_read_header(AVFormatContext *s)
>  {
>  AVIOContext *pb = s->pb;
>  AVStream *st;
> -uint8_t header[9];
> +uint8_t header[15];
>
>  if (avio_read(pb, header, 6) != 6)
>  return AVERROR_INVALIDDATA;
> @@ -94,7 +96,19 @@ static int amr_read_header(AVFormatContext *s)
>  if (avio_read(pb, header + 6, 3) != 3)
>  return AVERROR_INVALIDDATA;
>  if (memcmp(header, AMRWB_header, 9)) {
> -return -1;
> +if (avio_read(pb, header + 6 + 3, 3) != 3)
> +return AVERROR_INVALIDDATA;
> +if (memcmp(header, AMR_MC_header, 12)) {
> +if (avio_read(pb, header + 6 + 3 + 3, 3) != 3)
> +return AVERROR_INVALIDDATA;
> +if (memcmp(header, AMRWB_MC_header, 15)) {
> +return -1;
> +}
> +avpriv_report_missing_feature(s, "multi-channel AMRWB");
> +return AVERROR_PATCHWELCOME;
> +}
> +avpriv_report_missing_feature(s, "multi-channel AMR");
> +return AVERROR_PATCHWELCOME;
>  }
>
>  st->codecpar->codec_tag   = MKTAG('s', 'a', 'w', 'b');
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

2021-09-26 Thread myp...@gmail.com
On Sat, Sep 25, 2021 at 8:36 PM Jan Ekström  wrote:
>
> On Thu, Sep 23, 2021 at 6:08 PM  wrote:
> >
> > On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote:
> > > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa  
> > > wrote:
> > > >
> > > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > > > >
> > > > >> From: Limin Wang 
> > > > >>
> > > > >> Signed-off-by: Limin Wang 
> > > > >>
> > > > > As a note, I personally favor this patch over mine since I don't think
> > > > > `enable_tpl_la` is worth exposing to the user if its main role is to 
> > > > > switch
> > > > > between crf and cqp
> > > > >
> > > >
> > > > Ping on this patch, this has been requested on SVT-AV1's side as well
> > >
> > > I think my further comments on the previous version were mostly to
> > > move off from the rc option for rate control, which has become more
> > > and more seemingly unnecessary (and different from most other encoders
> > > for no obvious reason).
> > >
> > > The only option that with a quick look doesn't match just setting
> > > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible
> > > to either rework "rc" for it, or to utilize a separate option for it.
> >
> > Do you think it's OK to remove the rc option? to match other encoders,
> > We can choose the rate control by the related parameters like:
> >
> > if (crf >= 0)
> > choose crf rate control;
> > else if (bitrate > 0)
> > choose cvbr rate control;
> > else if (cqp >=0 )
> > choose cqp rate control;
> >
>
> In general that is the idea, yes (except bit rate would mean either
> vbr or cvbr). It would be nice to follow whatever is the default on
> SVT-AV1's side by default, and then if the user specifies a rate
> control mode that is not the default, his selection is honored. Not
> sure what the best way for that is to be honest. Possibly the style of
> setting AVCodecDefault a la libx265?
>
> For the rc option, given how much SVT-AV1 itself is in flux, I would
> be OK with removing the option, or making it an option that decides
> between cvbr and vbr (essentially making it "VBR bit rate control
> mode"). I wish cvbr would instead be something like VBV/HRD elsewhere,
> so we could just utilize maxrate&bufsize for controlling it, instead
> of having it as another discrete rate control mode.
>
> As these things change, I also hope that SVT-AV1 will soon get a
> key=value style of option API, that way the wrapper will not have to
I agree with this part , now FFmpeg SVT-AV1 wrapper needs to update
with the SVT-AV1's structural mapping if want to enable a new feature
> be updated constantly according to the changes in the library :) . As
> I feel SVT-AV1 will be changed quite a bit in the future (due to its
> recent age).
>
___
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] avfilter/vf_avgblur: switch to faster algorithm

2021-09-26 Thread myp...@gmail.com
On Sun, Sep 26, 2021 at 4:11 PM Paul B Mahol  wrote:
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/vf_avgblur.c  | 311 ++
>  tests/ref/fate/filter-refcmp-psnr-yuv |  80 +++
>  2 files changed, 211 insertions(+), 180 deletions(-)
>
> diff --git a/libavfilter/vf_avgblur.c b/libavfilter/vf_avgblur.c
> index 3e222a43fa..a838285bb4 100644
> --- a/libavfilter/vf_avgblur.c
> +++ b/libavfilter/vf_avgblur.c
> @@ -20,6 +20,7 @@
>   * SOFTWARE.
>   */
>
> +#include "libavutil/avassert.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/pixdesc.h"
> @@ -36,13 +37,15 @@ typedef struct AverageBlurContext {
>  int planes;
>
>  int depth;
> +int max;
> +int area;
>  int planewidth[4];
>  int planeheight[4];
> -float *buffer;
> +void *buffer;
> +uint16_t lut[256 * 256 * 256];
>  int nb_planes;
>
> -int (*filter_horizontally)(AVFilterContext *ctx, void *arg, int jobnr, 
> int nb_jobs);
> -int (*filter_vertically)(AVFilterContext *ctx, void *arg, int jobnr, int 
> nb_jobs);
> +int (*filter[2])(AVFilterContext *ctx, void *arg, int jobnr, int 
> nb_jobs);
>  } AverageBlurContext;
>
>  #define OFFSET(x) offsetof(AverageBlurContext, x)
> @@ -60,124 +63,138 @@ AVFILTER_DEFINE_CLASS(avgblur);
>  typedef struct ThreadData {
>  int height;
>  int width;
> -uint8_t *ptr;
> -int linesize;
> +const void *ptr;
> +void *dptr;
> +int linesize, dlinesize;
>  } ThreadData;
>
> -#define HORIZONTAL_FILTER(name, type)
>  \
> -static int filter_horizontally_##name(AVFilterContext *ctx, void *arg, int 
> jobnr, int nb_jobs)\
> -{
>  \
> -AverageBlurContext *s = ctx->priv;   
>  \
> -ThreadData *td = arg;
>  \
> -const int height = td->height;   
>  \
> -const int width = td->width; 
>  \
> -const int slice_start = (height *  jobnr   ) / nb_jobs;  
>  \
> -const int slice_end   = (height * (jobnr+1)) / nb_jobs;  
>  \
> -const int radius = FFMIN(s->radius, width / 2);  
>  \
> -const int linesize = td->linesize / sizeof(type);
>  \
> -float *buffer = s->buffer;   
>  \
> -const type *src; 
>  \
> -float *ptr;  
>  \
> -int y, x;
>  \
> - 
>  \
> -/* Filter horizontally along each row */ 
>  \
> -for (y = slice_start; y < slice_end; y++) {  
>  \
> -float acc = 0;   
>  \
> -int count = 0;   
>  \
> - 
>  \
> -src = (const type *)td->ptr + linesize * y;  
>  \
> -ptr = buffer + width * y;
>  \
> - 
>  \
> -for (x = 0; x < radius; x++) {   
>  \
> -acc += src[x];   
>  \
> -}
>  \
> -count += radius; 
>  \
> - 
>  \
> -for (x = 0; x <= radius; x++) {  
>  \
> -acc += src[x + radius];  
>  \
> -count++; 
>  \
> -ptr[x] = acc / count;
>  \
> -}
>  \
>

Re: [FFmpeg-devel] [PATCH v3 2/5] avformat/matroskadec: Parse dvcC/dvvC block additional mapping

2021-09-26 Thread myp...@gmail.com
On Sat, Sep 25, 2021 at 11:58 PM quietvoid  wrote:
>
> The parsing was implemented in a new dovi_isom file for the
> unification of the mov/mpegts DOVI parsing into one function, in a following 
> patch.
>
> Most of the Matroska elements implementation was done by Plex developers.
>
> Signed-off-by: quietvoid 
> ---
>  libavformat/Makefile  |  2 +-
>  libavformat/dovi_isom.c   | 80 +++
>  libavformat/dovi_isom.h   | 29 ++
>  libavformat/matroskadec.c | 15 
>  4 files changed, 125 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/dovi_isom.c
>  create mode 100644 libavformat/dovi_isom.h
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index c45caa3eed..61a1fecf6c 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -313,7 +313,7 @@ OBJS-$(CONFIG_M4V_MUXER) += rawenc.o
>  OBJS-$(CONFIG_MATROSKA_DEMUXER)  += matroskadec.o matroska.o  \
>  flac_picture.o isom_tags.o 
> rmsipr.o \
>  oggparsevorbis.o vorbiscomment.o 
> \
> -qtpalette.o replaygain.o
> +qtpalette.o replaygain.o 
> dovi_isom.o
>  OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
>  av1.o avc.o hevc.o isom_tags.o \
>  flacenc_header.o avlanguage.o \
> diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
> new file mode 100644
> index 00..2c0a49c993
> --- /dev/null
> +++ b/libavformat/dovi_isom.c
> @@ -0,0 +1,80 @@
> +/*
> + * DOVI ISO Media common code
> + * Copyright (c) 2021 quietvoid
> + *
> + * 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 "libavutil/dovi_meta.h"
> +
> +#include "avformat.h"
> +#include "dovi_isom.h"
> +
> +int ff_isom_parse_dvcc_dvvc(AVFormatContext *s, AVStream *st, const uint8_t 
> *buf_ptr, uint64_t size)
> +{
> +uint32_t buf;
> +AVDOVIDecoderConfigurationRecord *dovi;
> +size_t dovi_size;
> +int ret;
> +
> +if (size > (1 << 30) || size < 4)
> +return AVERROR_INVALIDDATA;
> +
> +dovi = av_dovi_alloc(&dovi_size);
> +if (!dovi)
> +return AVERROR(ENOMEM);
> +
> +dovi->dv_version_major = *buf_ptr++;// 8 bits
> +dovi->dv_version_minor = *buf_ptr++;// 8 bits
> +
> +buf = *buf_ptr++ << 8;
> +buf |= *buf_ptr++;
> +
> +dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
> +dovi->dv_level  = (buf >> 3) & 0x3f;// 6 bits
> +dovi->rpu_present_flag  = (buf >> 2) & 0x01;// 1 bit
> +dovi->el_present_flag   = (buf >> 1) & 0x01;// 1 bit
> +dovi->bl_present_flag   =  buf   & 0x01;// 1 bit
> +
> +// Has enough remaining data
> +if (size >= 5) {
> +dovi->dv_bl_signal_compatibility_id = ((*buf_ptr++) >> 4) & 0x0f; // 
> 4 bits
> +} else {
> +// 0 stands for None
> +// Dolby Vision V1.2.93 profiles and levels
> +dovi->dv_bl_signal_compatibility_id = 0;
> +}
> +
> +ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
> +  (uint8_t *)dovi, dovi_size);
> +if (ret < 0) {
> +av_free(dovi);
> +return ret;
> +}
> +
> +av_log(s, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d, level: %d, "
> +   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
> +   dovi->dv_version_major, dovi->dv_version_minor,
> +   dovi->dv_profile, dovi->dv_level,
> +   dovi->rpu_present_flag,
> +   dovi->el_present_flag,
> +   dovi->bl_present_flag,
> +   dovi->dv_bl_signal_compatibility_id
> +);
> +
> +return 0;
> +}
> diff --git a/libavformat/dovi_isom.h b/libavformat/dovi_isom.h
> new file mode 100644
> index 00..4c313046a7
> --- /dev/null
> +++ b/libavformat/dovi_isom.h
> @@ -0,0 +1,29 @@
> +/*
> + * DOVI ISO Media common code
> + * Copyright (c) 2021 quietvoid
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
>

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/hevc_sei: check size before using it

2021-09-14 Thread myp...@gmail.com
On Tue, Sep 14, 2021 at 6:50 PM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/hevc_sei.c | 31 +--
>  1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index 2c326bf..29d0346 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -52,9 +52,13 @@ static int 
> decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s, GetBitCont
>  return 0;
>  }
>
> -static int decode_nal_sei_mastering_display_info(HEVCSEIMasteringDisplay *s, 
> GetBitContext *gb)
> +static int decode_nal_sei_mastering_display_info(HEVCSEIMasteringDisplay *s, 
> GetBitContext *gb, int size)
>  {
>  int i;
> +
> +if (size < 24)
> +return AVERROR_INVALIDDATA;
> +
I can't find more information about this change, is it the old code
leading some issue?

>  // Mastering primaries
>  for (i = 0; i < 3; i++) {
>  s->display_primaries[i][0] = get_bits(gb, 16);
> @@ -67,23 +71,32 @@ static int 
> decode_nal_sei_mastering_display_info(HEVCSEIMasteringDisplay *s, Get
>  // Max and min luminance of mastering display
>  s->max_luminance = get_bits_long(gb, 32);
>  s->min_luminance = get_bits_long(gb, 32);
> +size -= 24;
>
>  // As this SEI message comes before the first frame that references it,
>  // initialize the flag to 2 and decrement on IRAP access unit so it
>  // persists for the coded video sequence (e.g., between two IRAPs)
>  s->present = 2;
> +
> +skip_bits_long(gb, 8 * size);
>  return 0;
>  }
>
> -static int decode_nal_sei_content_light_info(HEVCSEIContentLight *s, 
> GetBitContext *gb)
> +static int decode_nal_sei_content_light_info(HEVCSEIContentLight *s, 
> GetBitContext *gb, int size)
>  {
> +if (size < 4)
> +return AVERROR_INVALIDDATA;
> +
>  // Max and average light levels
>  s->max_content_light_level = get_bits(gb, 16);
>  s->max_pic_average_light_level = get_bits(gb, 16);
> +size -= 4;
>  // As this SEI message comes before the first frame that references it,
>  // initialize the flag to 2 and decrement on IRAP access unit so it
>  // persists for the coded video sequence (e.g., between two IRAPs)
>  s->present = 2;
> +
> +skip_bits_long(gb, 8 * size);
>  return  0;
>  }
>
> @@ -342,10 +355,16 @@ static int decode_nal_sei_active_parameter_sets(HEVCSEI 
> *s, GetBitContext *gb, v
>  return 0;
>  }
>
> -static int decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer 
> *s, GetBitContext *gb)
> +static int decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer 
> *s, GetBitContext *gb, int size)
>  {
> +if (size < 1)
> +return AVERROR_INVALIDDATA;
> +
>  s->present = 1;
>  s->preferred_transfer_characteristics = get_bits(gb, 8);
> +size--;
> +
> +skip_bits_long(gb, 8 * size);
>  return 0;
>  }
>
> @@ -451,9 +470,9 @@ static int decode_nal_sei_prefix(GetBitContext *gb, void 
> *logctx, HEVCSEI *s,
>  case SEI_TYPE_PIC_TIMING:
>  return decode_nal_sei_pic_timing(s, gb, ps, logctx, size);
>  case SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
> -return decode_nal_sei_mastering_display_info(&s->mastering_display, 
> gb);
> +return decode_nal_sei_mastering_display_info(&s->mastering_display, 
> gb, size);
>  case SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO:
> -return decode_nal_sei_content_light_info(&s->content_light, gb);
> +return decode_nal_sei_content_light_info(&s->content_light, gb, 
> size);
>  case SEI_TYPE_ACTIVE_PARAMETER_SETS:
>  return decode_nal_sei_active_parameter_sets(s, gb, logctx);
>  case SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
> @@ -461,7 +480,7 @@ static int decode_nal_sei_prefix(GetBitContext *gb, void 
> *logctx, HEVCSEI *s,
>  case SEI_TYPE_USER_DATA_UNREGISTERED:
>  return decode_nal_sei_user_data_unregistered(&s->unregistered, gb, 
> size);
>  case SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
> -return decode_nal_sei_alternative_transfer(&s->alternative_transfer, 
> gb);
> +return decode_nal_sei_alternative_transfer(&s->alternative_transfer, 
> gb, size);
>  case SEI_TYPE_TIME_CODE:
>  return decode_nal_sei_timecode(&s->timecode, gb);
>  case SEI_TYPE_FILM_GRAIN_CHARACTERISTICS:
> --
> 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".



-- 
===
Jun zhao/赵军
+++
___
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 "uns

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libx265: improve full range flag setting logic

2021-08-17 Thread myp...@gmail.com
On Wed, Aug 18, 2021 at 5:01 AM Jan Ekström  wrote:
>
> Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
> default for color range, so we do always have to specify it.
> Thus, we are required to handle the RGB case on the libavcodec
> side to enable the correct value to be written out in in case
> of RGB content with unspecified color range being received.
>
> In other words:
> 1. If the user has set color range specifically, follow that.
> 2. If the user has not set color range specifically, set full
>range by default in case of RGB and YUVJ pixel formats.
> ---
>  libavcodec/libx265.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 9395120471..b5c94b64a3 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -181,10 +181,15 @@ static av_cold int libx265_encode_init(AVCodecContext 
> *avctx)
>
>  ctx->params->vui.bEnableVideoSignalTypePresentFlag = 1;
>
> -ctx->params->vui.bEnableVideoFullRangeFlag = avctx->pix_fmt == 
> AV_PIX_FMT_YUVJ420P ||
> - avctx->pix_fmt == 
> AV_PIX_FMT_YUVJ422P ||
> - avctx->pix_fmt == 
> AV_PIX_FMT_YUVJ444P ||
> - avctx->color_range == 
> AVCOL_RANGE_JPEG;
> +if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED)
> +ctx->params->vui.bEnableVideoFullRangeFlag =
> +avctx->color_range == AVCOL_RANGE_JPEG;
> +else
> +ctx->params->vui.bEnableVideoFullRangeFlag =
> +(av_pix_fmt_desc_get(avctx->pix_fmt)->flags & 
> AV_PIX_FMT_FLAG_RGB) ||
> +avctx->pix_fmt == AV_PIX_FMT_YUVJ420P ||
> +avctx->pix_fmt == AV_PIX_FMT_YUVJ422P ||
> +avctx->pix_fmt == AV_PIX_FMT_YUVJ444P;
>
>  if ((avctx->color_primaries <= AVCOL_PRI_SMPTE432 &&
>   avctx->color_primaries != AVCOL_PRI_UNSPECIFIED) ||
> --
> 2.31.1
Patchset LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] Handle AV_PIX_FMT_PAL8

2021-08-16 Thread myp...@gmail.com
The patch was broken

On Sun, Aug 15, 2021 at 5:22 PM 一滴水 <229135...@qq.com> wrote:
>
> Signed-off-by: Ray <229135...@qq.com>
> ---
>  libavformat/riffenc.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> index 971c4a7eb8..6926fbf060 100644
> --- a/libavformat/riffenc.c
> +++ b/libavformat/riffenc.c
> @@ -271,7 +271,14 @@ void ff_put_bmp_header(AVIOContext *pb, 
> AVCodecParameters *par,
> 
>  if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
> 
>  avio_wl32(pb, 0xff);
> 
>  else if (i == 1 && pix_fmt == AV_PIX_FMT_MONOBLACK)
> -   
>  avio_wl32(pb, 0xff);
> +   
>  avio_wl32(pb, 0xff);
> +   
>  else if (pix_fmt == AV_PIX_FMT_PAL8) {
> +   
>  /* Initialize 8 bpp palette */
> +   
>  avio_w8(pb,i);
> +   
>  avio_w8(pb,i);
> +   
>  avio_w8(pb,i);
> +   
>  avio_w8(pb,0);
> +   
>  }
> 
>  else
> 
>  avio_wl32(pb, 0);
>  }
> --
> 2.30.1 (Apple Git-130)
> ___
> 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".



-- 
===
Jun zhao/赵军
+++
___
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/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()

2021-08-02 Thread myp...@gmail.com
Do you have CPU info, I can't find more info from the patch set

On Mon, Aug 2, 2021 at 1:35 PM Wu Jianhua  wrote:
>
> Co-authored-by: Cheng Yanfei 
> Co-authored-by: Jin Jun 
> Signed-off-by: Wu Jianhua 
> ---
>  libavfilter/x86/vf_gblur.asm| 21 -
>  libavfilter/x86/vf_gblur_init.c |  4 
>  2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/x86/vf_gblur.asm b/libavfilter/x86/vf_gblur.asm
> index 4d84e6d011..276fe347f5 100644
> --- a/libavfilter/x86/vf_gblur.asm
> +++ b/libavfilter/x86/vf_gblur.asm
> @@ -194,19 +194,17 @@ cglobal postscale_slice, 2, 2, 4, ptr, length, 
> postscale, min, max
>  VBROADCASTSS m1, minm
>  VBROADCASTSS m2, maxm
>  %elif WIN64
> -SWAP 0, 2
> -SWAP 1, 3
> -VBROADCASTSS m0, xm0
> -VBROADCASTSS m1, xm1
> +VBROADCASTSS m0, xmm2
> +VBROADCASTSS m1, xmm3
>  VBROADCASTSS m2, maxm
> -%else ; UNIX64
> -VBROADCASTSS m0, xm0
> -VBROADCASTSS m1, xm1
> -VBROADCASTSS m2, xm2
> +%else ; UNIX
> +VBROADCASTSS m0, xmm0
> +VBROADCASTSS m1, xmm1
> +VBROADCASTSS m2, xmm2
>  %endif
>
>  .loop:
> -%if cpuflag(avx2)
> +%if cpuflag(avx2) || cpuflag(avx512)
>  mulps m3, m0, [ptrq + lengthq]
>  %else
>  movu  m3, [ptrq + lengthq]
> @@ -229,3 +227,8 @@ POSTSCALE_SLICE
>  INIT_YMM avx2
>  POSTSCALE_SLICE
>  %endif
> +
> +%if HAVE_AVX512_EXTERNAL
> +INIT_ZMM avx512
> +POSTSCALE_SLICE
> +%endif
> diff --git a/libavfilter/x86/vf_gblur_init.c b/libavfilter/x86/vf_gblur_init.c
> index d80fb46fe4..34aba4ca6e 100644
> --- a/libavfilter/x86/vf_gblur_init.c
> +++ b/libavfilter/x86/vf_gblur_init.c
> @@ -29,6 +29,7 @@ void ff_horiz_slice_avx2(float *ptr, int width, int height, 
> int steps, float nu,
>
>  void ff_postscale_slice_sse(float *ptr, int length, float postscale, float 
> min, float max);
>  void ff_postscale_slice_avx2(float *ptr, int length, float postscale, float 
> min, float max);
> +void ff_postscale_slice_avx512(float *ptr, int length, float postscale, 
> float min, float max);
>
>  av_cold void ff_gblur_init_x86(GBlurContext *s)
>  {
> @@ -47,5 +48,8 @@ av_cold void ff_gblur_init_x86(GBlurContext *s)
>  if (EXTERNAL_AVX2(cpu_flags)) {
>  s->horiz_slice = ff_horiz_slice_avx2;
>  }
> +if (EXTERNAL_AVX512(cpu_flags)) {
> +s->postscale_slice = ff_postscale_slice_avx512;
> +}
>  #endif
>  }
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: update color properties in codec context

2021-07-28 Thread myp...@gmail.com
On Wed, Jul 28, 2021 at 4:16 PM Haihao Xiang  wrote:
>
> User may get color properties from the SDK via VIDEO_SIGNAL_INFO extbuf
> ---
>  libavcodec/qsvdec.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 622750927c..19a6a776db 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -311,7 +311,8 @@ static int qsv_decode_header(AVCodecContext *avctx, 
> QSVContext *q,
>   mfxVideoParam *param)
>  {
>  int ret;
> -
> +mfxExtVideoSignalInfo video_signal_info = { 0 };
> +mfxExtBuffer *header_ext_params[1] = { (mfxExtBuffer 
> *)&video_signal_info };
>  mfxBitstream bs = { 0 };
>
>  if (avpkt->size) {
> @@ -336,6 +337,12 @@ static int qsv_decode_header(AVCodecContext *avctx, 
> QSVContext *q,
>  return ret;
>
>  param->mfx.CodecId = ret;
> +video_signal_info.Header.BufferId = MFX_EXTBUFF_VIDEO_SIGNAL_INFO;
> +video_signal_info.Header.BufferSz = sizeof(video_signal_info);
> +// The SDK doesn't support other ext buffers when calling 
> MFXVideoDECODE_DecodeHeader,
> +// so do not append this buffer to the existent buffer array
> +param->ExtParam= header_ext_params;
> +param->NumExtParam = 1;
>  ret = MFXVideoDECODE_DecodeHeader(q->session, &bs, param);
>  if (MFX_ERR_MORE_DATA == ret) {
> return AVERROR(EAGAIN);
> @@ -344,6 +351,17 @@ static int qsv_decode_header(AVCodecContext *avctx, 
> QSVContext *q,
>  return ff_qsv_print_error(avctx, ret,
>  "Error decoding stream header");
>
> +avctx->color_range = video_signal_info.VideoFullRange ? AVCOL_RANGE_JPEG 
> : AVCOL_RANGE_MPEG;
> +
> +if (video_signal_info.ColourDescriptionPresent) {
> +avctx->color_primaries = video_signal_info.ColourPrimaries;
> +avctx->color_trc = video_signal_info.TransferCharacteristics;
> +avctx->colorspace = video_signal_info.MatrixCoefficients;
> +}
> +
> +param->ExtParam= q->ext_buffers;
> +param->NumExtParam = q->nb_ext_buffers;
> +
>  return 0;
>  }
>
> --
> 2.17.1
Both patches LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/3] lavc/libsvtav1: Enable svtav1-params like x264-params in libx264

2021-07-05 Thread myp...@gmail.com
On Sun, Jul 4, 2021 at 8:16 PM Lynne  wrote:
>
> 4 Jul 2021, 03:40 by mypopy...@gmail.com:
>
> > From: Jun Zhao 
> >
> > Enabled the svtav1-params, then we can set all the params
> >
>
> The whole purpose of the params field was to give it off to the encoder
> and have it do its own parsing, such that we wouldn't have to keep up
> adding more and more options.
> But svt-av1 cannot parse a generic option field on its own, so no, add
> those as separate options rather than a generic text field.
>
Will split the options as the comments, thx
>
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/libsvtav1.c | 337 +
> >  1 file changed, 337 insertions(+)
> >
> > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> > index fabc4e6428..9d72a35f6c 100644
> > --- a/libavcodec/libsvtav1.c
> > +++ b/libavcodec/libsvtav1.c
> > @@ -71,6 +71,8 @@ typedef struct SvtContext {
> >
> >  int tile_columns;
> >  int tile_rows;
> > +
> > +AVDictionary *svt_av1_params;
> >  } SvtContext;
> >
> >  static const struct {
> > @@ -146,11 +148,334 @@ static int alloc_buffer(EbSvtAv1EncConfiguration 
> > *config, SvtContext *svt_enc)
> >
> >  }
> >
> > +static void set_asm_type(EbSvtAv1EncConfiguration *p, const char *value)
> > +{
> > +const struct {
> > +const char *name;
> > +CPU_FLAGS   flags;
> > +} param_maps[] = {
> > +{"c", 0},
> > +{"0", 0},
> > +
> > +{"mmx", (CPU_FLAGS_MMX << 1) - 1},
> > +{"1",   (CPU_FLAGS_MMX << 1) - 1},
> > +
> > +{"sse", (CPU_FLAGS_SSE << 1) - 1},
> > +{"2",   (CPU_FLAGS_SSE << 1) - 1},
> > +
> > +{"sse2", (CPU_FLAGS_SSE2 << 1) - 1},
> > +{"3",(CPU_FLAGS_SSE2 << 1) - 1},
> > +
> > +{"sse3", (CPU_FLAGS_SSE3 << 1) - 1},
> > +{"4",(CPU_FLAGS_SSE3 << 1) - 1},
> > +
> > +{"ssse3", (CPU_FLAGS_SSSE3 << 1) - 1},
> > +{"5", (CPU_FLAGS_SSSE3 << 1) - 1},
> > +
> > +{"sse4_1", (CPU_FLAGS_SSE4_1 << 1) - 1},
> > +{"6",  (CPU_FLAGS_SSE4_1 << 1) - 1},
> > +
> > +{"sse4_2", (CPU_FLAGS_SSE4_2 << 1) - 1},
> > +{"7",  (CPU_FLAGS_SSE4_2 << 1) - 1},
> > +
> > +{"avx", (CPU_FLAGS_AVX << 1) - 1},
> > +{"8",   (CPU_FLAGS_AVX << 1) - 1},
> > +
> > +{"avx2", (CPU_FLAGS_AVX2 << 1) - 1},
> > +{"9",(CPU_FLAGS_AVX2 << 1) - 1},
> > +
> > +{"avx512", (CPU_FLAGS_AVX512VL << 1) - 1},
> > +{"10", (CPU_FLAGS_AVX512VL << 1) - 1},
> > +
> > +{"max", CPU_FLAGS_ALL},
> > +{"11",  CPU_FLAGS_ALL},
> > +};
> >
>
> We already have a generic way to set up cpuflags, you should use that
> instead of adding another field.

Good suggestion!
___
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/udp: fix check for pthread_cond_wait return value

2021-06-22 Thread myp...@gmail.com
LGTM, check the negative return value/errno  is wrong before this patch

On Mon, Jun 21, 2021 at 10:33 PM Zhao Zhili  wrote:
>
> POSIX errno is positive. We have strict_pthread_cond_wait to handle
> error code during development.
> ---
>  libavformat/udp.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 9b9d3de197..bbe5aecc46 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -550,9 +550,7 @@ static void *circular_buffer_task_tx( void *_URLContext)
>  while (len<4) {
>  if (s->close_req)
>  goto end;
> -if (pthread_cond_wait(&s->cond, &s->mutex) < 0) {
> -goto end;
> -}
> +pthread_cond_wait(&s->cond, &s->mutex);
>  len = av_fifo_size(s->fifo);
>  }
>
> --
> 2.31.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



-- 
===
Jun zhao/赵军
+++
___
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] GSoC: Support fast guided filter.

2021-05-10 Thread myp...@gmail.com
On Tue, May 11, 2021 at 1:08 PM myp...@gmail.com  wrote:
>
> On Mon, May 10, 2021 at 9:42 PM Xuewei Meng <928826...@qq.com> wrote:
> >
> > From: Xuewei Meng 
> >
> > Two modes are supported in guided filter, basic mode and fast mode.
> > Basic mode is the initial pushed guided filter without optimization.
> > Fast mode is implemented based on the basic one by sub-sampling method.
> > The sub-sampling ratio which can be defined by users controls the
> > algorithm complexity. The larger the sub-sampling ratio, the lower
> > the algorithm complexity.
> >
> > Signed-off-by: Xuewei Meng 
> > ---
> >  doc/filters.texi|  20 +++---
> >  libavfilter/vf_guided.c | 104 
> > 
> >  2 files changed, 85 insertions(+), 39 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 03ca9ae..eb747cb 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -12963,12 +12963,22 @@ Apply guided filter for edge-preserving 
> > smoothing, dehazing and so on.
> >  The filter accepts the following options:
> >  @table @option
> >  @item radius
> > -Set the radius in pixels.
> > +Set the box radius in pixels.
> >  Allowed range is 1 to 20. Default is 3.
> >
> >  @item eps
> > -Set regularization parameter.
> > -Allowed range is 0 to 1. Default is 0.1.
> > +Set regularization parameter (with square).
> > +Allowed range is 0 to 1. Default is 0.01.
> > +
> > +@item mode
> > +Set filter mode. Can be @code{basic} or @code{fast}.
> > +Default is @code{basic}.
> > +
> > +@item sub
> > +Set subsampling ratio.
> > +Allowed range is 1 to 64.
> > +Default is always 1 for @code{basic} value of @var{mode} option,
> > +and 4 for @code{fast} value of @var{mode} option.
> >
> >  @item planes
> >  Set planes to filter. Default is first only.
> > @@ -12987,8 +12997,8 @@ ffmpeg -i in.png -i in.png -filter_complex guided 
> > out.png
> >
> >  @item
> >  Dehazing, structure-transferring filtering, detail enhancement with guided 
> > filter.
> > -For the generation of guidance image,
> > -see @url{http://kaiminghe.com/publications/pami12guidedfilter.pdf}.
> > +For the generation of guidance image, refer to paper "Guided Image 
> > Filtering".
> > +See: @url{http://kaiminghe.com/publications/pami12guidedfilter.pdf}.
> >  @example
> >  ffmpeg -i in.png -i guidance.png -filter_complex guided out.png
> >  @end example
> > diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
> > index 86c0db5..230fb7b 100644
> > --- a/libavfilter/vf_guided.c
> > +++ b/libavfilter/vf_guided.c
> > @@ -27,12 +27,20 @@
> >  #include "internal.h"
> >  #include "video.h"
> >
> > +enum FilterModes {
> > +BASIC,
> > +FAST,
> > +NB_MODES,
> > +};
> > +
> >  typedef struct GuidedContext {
> >  const AVClass *class;
> >  FFFrameSync fs;
> >
> >  int radius;
> >  float eps;
> > +int mode;
> > +int sub;
> >
> >  int planes;
> >
> > @@ -51,9 +59,13 @@ typedef struct GuidedContext {
> >  #define FLAGS 
> > AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
> >
> >  static const AVOption guided_options[] = {
> > -{ "radius", "set the box radius",   OFFSET(radius), 
> > AV_OPT_TYPE_INT,   {.i64=3},   1,  20, FLAGS },
> > -{ "eps","set the regularization parameter (with square)",  
> > OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl=0.01  }, 0.0,   1, FLAGS },
> > -{ "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,   
> > {.i64=1},   0, 0xF, FLAGS },
> > +{ "radius", "set the box radius",   
> > OFFSET(radius), AV_OPT_TYPE_INT,   {.i64 = 3},   1,   20, FLAGS 
> > },
> > +{ "eps","set the regularization parameter (with square)",   
> > OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl = 0.01 }, 0.0,1, FLAGS 
> > },
> > +{ "mode",   "set filtering mode (0: basic mode; 1: fast mode)", 
> > OFFSET(mode),   AV_OPT_TYPE_INT,   {.i64 = BASIC},   0, NB_MODES - 1, 
> > FLAGS, "mode" },
> > +{ "basic",  "basic guided filter",  0, 
> >  AV_OPT_TYPE_C

Re: [FFmpeg-devel] [PATCH] GSoC: Support fast guided filter.

2021-05-10 Thread myp...@gmail.com
On Mon, May 10, 2021 at 9:42 PM Xuewei Meng <928826...@qq.com> wrote:
>
> From: Xuewei Meng 
>
> Two modes are supported in guided filter, basic mode and fast mode.
> Basic mode is the initial pushed guided filter without optimization.
> Fast mode is implemented based on the basic one by sub-sampling method.
> The sub-sampling ratio which can be defined by users controls the
> algorithm complexity. The larger the sub-sampling ratio, the lower
> the algorithm complexity.
>
> Signed-off-by: Xuewei Meng 
> ---
>  doc/filters.texi|  20 +++---
>  libavfilter/vf_guided.c | 104 
> 
>  2 files changed, 85 insertions(+), 39 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 03ca9ae..eb747cb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -12963,12 +12963,22 @@ Apply guided filter for edge-preserving smoothing, 
> dehazing and so on.
>  The filter accepts the following options:
>  @table @option
>  @item radius
> -Set the radius in pixels.
> +Set the box radius in pixels.
>  Allowed range is 1 to 20. Default is 3.
>
>  @item eps
> -Set regularization parameter.
> -Allowed range is 0 to 1. Default is 0.1.
> +Set regularization parameter (with square).
> +Allowed range is 0 to 1. Default is 0.01.
> +
> +@item mode
> +Set filter mode. Can be @code{basic} or @code{fast}.
> +Default is @code{basic}.
> +
> +@item sub
> +Set subsampling ratio.
> +Allowed range is 1 to 64.
> +Default is always 1 for @code{basic} value of @var{mode} option,
> +and 4 for @code{fast} value of @var{mode} option.
>
>  @item planes
>  Set planes to filter. Default is first only.
> @@ -12987,8 +12997,8 @@ ffmpeg -i in.png -i in.png -filter_complex guided 
> out.png
>
>  @item
>  Dehazing, structure-transferring filtering, detail enhancement with guided 
> filter.
> -For the generation of guidance image,
> -see @url{http://kaiminghe.com/publications/pami12guidedfilter.pdf}.
> +For the generation of guidance image, refer to paper "Guided Image 
> Filtering".
> +See: @url{http://kaiminghe.com/publications/pami12guidedfilter.pdf}.
>  @example
>  ffmpeg -i in.png -i guidance.png -filter_complex guided out.png
>  @end example
> diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
> index 86c0db5..230fb7b 100644
> --- a/libavfilter/vf_guided.c
> +++ b/libavfilter/vf_guided.c
> @@ -27,12 +27,20 @@
>  #include "internal.h"
>  #include "video.h"
>
> +enum FilterModes {
> +BASIC,
> +FAST,
> +NB_MODES,
> +};
> +
>  typedef struct GuidedContext {
>  const AVClass *class;
>  FFFrameSync fs;
>
>  int radius;
>  float eps;
> +int mode;
> +int sub;
>
>  int planes;
>
> @@ -51,9 +59,13 @@ typedef struct GuidedContext {
>  #define FLAGS 
> AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
>
>  static const AVOption guided_options[] = {
> -{ "radius", "set the box radius",   OFFSET(radius), 
> AV_OPT_TYPE_INT,   {.i64=3},   1,  20, FLAGS },
> -{ "eps","set the regularization parameter (with square)",
>   OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl=0.01  }, 0.0,   1, FLAGS },
> -{ "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,   
> {.i64=1},   0, 0xF, FLAGS },
> +{ "radius", "set the box radius",   
> OFFSET(radius), AV_OPT_TYPE_INT,   {.i64 = 3},   1,   20, FLAGS },
> +{ "eps","set the regularization parameter (with square)",   
> OFFSET(eps),AV_OPT_TYPE_FLOAT, {.dbl = 0.01 }, 0.0,1, FLAGS },
> +{ "mode",   "set filtering mode (0: basic mode; 1: fast mode)", 
> OFFSET(mode),   AV_OPT_TYPE_INT,   {.i64 = BASIC},   0, NB_MODES - 1, FLAGS, 
> "mode" },
> +{ "basic",  "basic guided filter",  0,   
>AV_OPT_TYPE_CONST, {.i64 = BASIC},   0,0, FLAGS, "mode" },
> +{ "fast",   "fast guided filter",   0,   
>AV_OPT_TYPE_CONST, {.i64 = FAST },   0,0, FLAGS, "mode" },
> +{ "sub","subsampling ratio",
> OFFSET(sub),AV_OPT_TYPE_INT,   {.i64 = 1},   1,   64, FLAGS },
> +{ "planes", "set planes to filter", 
> OFFSET(planes), AV_OPT_TYPE_INT,   {.i64=1  },   0,  0xF, FLAGS },
>  { NULL }
>  };
>
> @@ -147,6 +159,26 @@ static int config_input(AVFilterLink *inlink)
>  return AVERROR(EINVAL);
>  }
>
> +if (s->mode == BASIC) {
> +if (s->sub != 1) {
> +av_log(ctx, AV_LOG_WARNING, "Subsampling ratio is 1 in basic 
> mode.\n");
> +s->sub = 1;
> +}
> +}
> +else if (s->mode == FAST) {
> +if (s->sub == 1) {
> +av_log(ctx, AV_LOG_WARNING, "Subsampling ratio is larger than 1 
> in fast mode.\n");
> +s->sub = 4;
> +}
> +if (s->radius >= s->sub)
> +s->radius = s->

Re: [FFmpeg-devel] [PATCH 1/2] doc/filters: Update commands doc for amix

2021-05-10 Thread myp...@gmail.com
On Mon, May 10, 2021 at 10:11 PM Gyan Doshi  wrote:
>
>
>
> On 2021-05-07 18:33, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > commit 95b854dd06 "rename sum option to normalize" missed command
> > part docs
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   doc/filters.texi | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index b405cc5dfb..3d5aa8e8ef 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -1947,7 +1947,7 @@ by this filter if this option is disabled. By default 
> > is enabled.
> >   This filter supports the following commands:
> >   @table @option
> >   @item weights
> > -@item sum
> > +@item normalize
> >   Syntax is same as option with same name.
> >   @end table
> >
>
> LGTM.
Will apply, thx
___
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] lavf/mpegts: fix av_log use the uninitialized stream id

2021-05-10 Thread myp...@gmail.com
On Mon, May 10, 2021 at 6:33 AM Marton Balint  wrote:
>
>
>
> On Fri, 7 May 2021, Jun Zhao wrote:
>
> > From: Jun Zhao 
> >
> > fix av_log use the uninitialized stream id
>
> Actually i is not the correct value even if it is initialized because the
> loop is executed in full.
>
> Either remove remove logging the stream index, it is not super useful
> anyway, or rework the function to find an index instead of an AVStream*,
> that way you can log it cleanly and in the end return something like:
>
> return found_idx == -1 ? NULL : s->streams[p->streams[found_idx].idx];
>
> But it is also fine if you simply remove the PMT stream index logging.
Will follow the comments, thx
>
> Thanks,
> Marton
>
___
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 V8 1/3] lavu: add side data AV_FRAME_DATA_DETECTION_BBOXES for object detection/classification

2021-04-13 Thread myp...@gmail.com
On Tue, Apr 13, 2021 at 1:26 PM Guo, Yejun  wrote:
>
> ---
>  doc/APIchanges |   2 +
>  libavutil/Makefile |   2 +
>  libavutil/detection_bbox.c |  73 +
>  libavutil/detection_bbox.h | 107 +
>  libavutil/frame.c  |   1 +
>  libavutil/frame.h  |   6 +++
>  6 files changed, 191 insertions(+)
>  create mode 100644 libavutil/detection_bbox.c
>  create mode 100644 libavutil/detection_bbox.h
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 9dfcc97d5c..30bd235691 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,8 @@ libavutil: 2017-10-21
>
>
>  API changes, most recent first:
> +2021-04-xx - xx - lavu 56.xx.100 - frame.h detection_bbox.h
> +  Add AV_FRAME_DATA_DETECTION_BBOXES
>
>  2021-04-06 - xx - lavf 58.78.100 - avformat.h
>Add avformat_index_get_entries_count(), avformat_index_get_entry(),
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 27bafe9e12..47efb718d2 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -21,6 +21,7 @@ HEADERS = adler32.h 
> \
>cpu.h \
>crc.h \
>des.h \
> +  detection_bbox.h  \
>dict.h\
>display.h \
>dovi_meta.h   \
> @@ -113,6 +114,7 @@ OBJS = adler32.o  
>   \
> cpu.o\
> crc.o\
> des.o\
> +   detection_bbox.o \
> dict.o   \
> display.o\
> dovi_meta.o  \
> diff --git a/libavutil/detection_bbox.c b/libavutil/detection_bbox.c
> new file mode 100644
> index 00..c54a30d9e5
> --- /dev/null
> +++ b/libavutil/detection_bbox.c
> @@ -0,0 +1,73 @@
> +/*
> + * 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 "detection_bbox.h"
> +
> +AVDetectionBBoxHeader *av_detection_bbox_alloc(uint32_t nb_bboxes, size_t 
> *out_size)
> +{
> +size_t size;
> +struct {
> +   AVDetectionBBoxHeader header;
> +   AVDetectionBBox boxes[1];
> +} *ret;
> +
> +size = sizeof(*ret);
> +if (nb_bboxes - 1 > (SIZE_MAX - size) / sizeof(*ret->boxes))
> +return NULL;
> +size += sizeof(*ret->boxes) * (nb_bboxes - 1);
> +
> +ret = av_mallocz(size);
> +if (!ret)
> +return NULL;
> +
> +ret->header.nb_bboxes = nb_bboxes;
> +ret->header.bbox_size = sizeof(*ret->boxes);
> +ret->header.bboxes_offset = (char *)&ret->boxes - (char *)&ret->header;
> +
> +if (out_size)
> +*out_size = size;
> +
> +return &ret->header;
> +}
> +
> +AVDetectionBBoxHeader *av_detection_bbox_create_side_data(AVFrame *frame, 
> uint32_t nb_bboxes)
> +{
> +AVBufferRef *buf;
> +AVDetectionBBoxHeader *header;
> +size_t size;
> +
> +header = av_detection_bbox_alloc(nb_bboxes, &size);
> +if (!header)
> +return NULL;
> +if (size > INT_MAX) {
I think need to use SIZE_MAX, not INT_MAX in this case
> +av_freep(&header);
> +return NULL;
> +}
> +buf = av_buffer_create((uint8_t *)header, size, NULL, NULL, 0);
> +if (!buf) {
> +av_freep(&header);
> +return NULL;
> +}
> +
> +if (!av_frame_new_side_data_from_buf(frame, 
> AV_FRAME_DATA_DETECTION_BBOXES, buf)) {
> +av_buffer_unref(&buf);
> +return NULL;
> +}
> +
> +return header;
> +}
> diff --git a/libavutil/

Re: [FFmpeg-devel] [PATCH v2] examples/decode_video: flush parser to fix missing frame

2021-03-31 Thread myp...@gmail.com
On Thu, Sep 24, 2020 at 2:01 AM Zhao Zhili  wrote:
>
> To reproduce, run decode_video with a single frame sample. No frame
> was decoded before the patch.
> ---
>  doc/examples/decode_video.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
> index 18ee90a6c0..9ce3531d63 100644
> --- a/doc/examples/decode_video.c
> +++ b/doc/examples/decode_video.c
> @@ -92,6 +92,7 @@ int main(int argc, char **argv)
>  uint8_t *data;
>  size_t   data_size;
>  int ret;
> +int eof;
>  AVPacket *pkt;
>
>  if (argc <= 2) {
> @@ -150,15 +151,14 @@ int main(int argc, char **argv)
>  exit(1);
>  }
>
> -while (!feof(f)) {
> +do {
>  /* read raw data from the input file */
>  data_size = fread(inbuf, 1, INBUF_SIZE, f);
> -if (!data_size)
> -break;
> +eof = !data_size;
>
>  /* use the parser to split the data into frames */
>  data = inbuf;
> -while (data_size > 0) {
> +while (data_size > 0 || eof) {
>  ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
> data, data_size, AV_NOPTS_VALUE, 
> AV_NOPTS_VALUE, 0);
If fread get a reading error occurred (not end-of-file), I don't think
we need to run this part.
>  if (ret < 0) {
> @@ -170,8 +170,10 @@ int main(int argc, char **argv)
>
>  if (pkt->size)
>  decode(c, frame, pkt, outfilename);
> +else if (eof)
> +break;
>  }
> -}
> +} while (!eof);
>
>  /* flush the decoder */
>  decode(c, frame, NULL, outfilename);
> --
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avformat/libsrt: fix setsockopt() typo

2021-03-16 Thread myp...@gmail.com
On Mon, Mar 15, 2021 at 5:06 PM Zhao Zhili  wrote:
>
> ---
>  libavformat/libsrt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index 233e9096fa..ac865c5658 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -334,7 +334,7 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
>  (s->latency >= 0 && libsrt_setsockopt(h, fd, SRTO_LATENCY, 
> "SRTO_LATENCY", &latency, sizeof(latency)) < 0) ||
>  (s->rcvlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_RCVLATENCY, 
> "SRTO_RCVLATENCY", &rcvlatency, sizeof(rcvlatency)) < 0) ||
>  (s->peerlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_PEERLATENCY, 
> "SRTO_PEERLATENCY", &peerlatency, sizeof(peerlatency)) < 0) ||
> -(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, 
> "SRTO_TLPKDROP", &s->tlpktdrop, sizeof(s->tlpktdrop)) < 0) ||
> +(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, 
> "SRTO_TLPKTDROP", &s->tlpktdrop, sizeof(s->tlpktdrop)) < 0) ||

>  (s->nakreport >= 0 && libsrt_setsockopt(h, fd, SRTO_NAKREPORT, 
> "SRTO_NAKREPORT", &s->nakreport, sizeof(s->nakreport)) < 0) ||
>  (connect_timeout >= 0 && libsrt_setsockopt(h, fd, SRTO_CONNTIMEO, 
> "SRTO_CONNTIMEO", &connect_timeout, sizeof(connect_timeout)) <0 ) ||
>  (s->sndbuf >= 0 && libsrt_setsockopt(h, fd, SRTO_SNDBUF, 
> "SRTO_SNDBUF", &s->sndbuf, sizeof(s->sndbuf)) < 0) ||
> --
Both of two patches LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/avcodec: Don't suggest calling deprecated avcodec_register_all()

2021-03-06 Thread myp...@gmail.com
Looks good

On Sun, Mar 7, 2021 at 8:16 AM Andreas Rheinhardt
 wrote:
>
> Despite avcodec_register and avcodec_register_all being deprecated,
> their documentation still said that one of them has to be called
> before doing anything else. Clarify this confusing situation.
>
> Furthermore, don't use avcodec_register_all in sample code for
> a non-deprecated function.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/avcodec.h | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 309d9965be..46d31b34ad 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2708,25 +2708,13 @@ const char *avcodec_license(void);
>
>  #if FF_API_NEXT
>  /**
> - * Register the codec codec and initialize libavcodec.
> - *
> - * @warning either this function or avcodec_register_all() must be called
> - * before any other libavcodec functions.
> - *
> - * @see avcodec_register_all()
> + * @deprecated Calling this function is unnecessary.
>   */
>  attribute_deprecated
>  void avcodec_register(AVCodec *codec);
>
>  /**
> - * Register all the codecs, parsers and bitstream filters which were enabled 
> at
> - * configuration time. If you do not call this function you can select 
> exactly
> - * which formats you want to support, by using the individual registration
> - * functions.
> - *
> - * @see avcodec_register
> - * @see av_register_codec_parser
> - * @see av_register_bitstream_filter
> + * @deprecated Calling this function is unnecessary.
>   */
>  attribute_deprecated
>  void avcodec_register_all(void);
> @@ -2843,7 +2831,6 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
>   * @ref avcodec_receive_frame()).
>   *
>   * @code
> - * avcodec_register_all();
>   * av_dict_set(&opts, "b", "2.5M", 0);
>   * codec = avcodec_find_decoder(AV_CODEC_ID_H264);
>   * if (!codec)
> --
> 2.27.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".



-- 
===
Jun zhao/赵军
+++
___
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] ffmpeg: remove dead code for -vol

2021-01-31 Thread myp...@gmail.com
On Sun, Jan 31, 2021 at 1:01 PM Gyan Doshi  wrote:
>
> It is applied via configure_input_audio_filter()
> ---
>  fftools/ffmpeg_filter.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index e9e31e043e..1cba3055cc 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -641,13 +641,6 @@ static int configure_output_audio_filter(FilterGraph 
> *fg, OutputFilter *ofilter,
>  pad_idx = 0;
>  }
>
> -if (audio_volume != 256 && 0) {
> -char args[256];
> -
> -snprintf(args, sizeof(args), "%f", audio_volume / 256.);
> -AUTO_INSERT_FILTER("-vol", "volume", args);
> -}
> -
>  if (ost->apad && of->shortest) {
>  char args[256];
>  int i;
> --
> 2.30.0
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2] libavcodec/qsvenc: add low latency P-pyramid support for qsv

2020-12-24 Thread myp...@gmail.com
On Fri, Dec 25, 2020 at 12:55 PM  wrote:
>
> From: Wenbinc-Bin 
>
> Add low latency P-pyramid support for qsv, and it relates to a new
> command line parameter "-p_strategy". To enable this flag, user also
> need to set "-bf" to -1 or 0.
>
> Signed-off-by Wenbin Chen 
> ---
>  libavcodec/qsvenc.c | 23 +++
>  libavcodec/qsvenc.h |  2 ++
>  2 files changed, 25 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 0d20d1968f..8cb0ecff89 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -268,6 +268,14 @@ static void dump_video_param(AVCodecContext *avctx, 
> QSVEncContext *q,
>  case MFX_B_REF_PYRAMID: av_log(avctx, AV_LOG_VERBOSE, "pyramid");   
> break;
>  default:av_log(avctx, AV_LOG_VERBOSE, "auto");  
> break;
>  }
> +
> +av_log(avctx, AV_LOG_VERBOSE, "; PRefType: ");
> +switch(co3->PRefType){
Please follow the coding style, thx
> +case MFX_P_REF_DEFAULT: av_log(avctx, AV_LOG_VERBOSE, "default");   
> break;
> +case MFX_P_REF_SIMPLE:  av_log(avctx, AV_LOG_VERBOSE, "simple");   
> break;
> +case MFX_P_REF_PYRAMID: av_log(avctx, AV_LOG_VERBOSE, "pyramid");   
> break;
> +default:break;
> +}
>  av_log(avctx, AV_LOG_VERBOSE, "\n");
>  #endif
>
> @@ -781,6 +789,21 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  #if QSV_HAVE_CO3
>  q->extco3.Header.BufferId  = MFX_EXTBUFF_CODING_OPTION3;
>  q->extco3.Header.BufferSz  = sizeof(q->extco3);
> +switch(q->p_strategy){
Same as above
> +case 0:
And this
> +q->extco3.PRefType = MFX_P_REF_DEFAULT;
> +break;
> +case 1:
> +q->extco3.PRefType = MFX_P_REF_SIMPLE;
> +break;
> +case 2:
> +q->extco3.PRefType = MFX_P_REF_PYRAMID;
> +break;
> +default:
> +q->extco3.PRefType = MFX_P_REF_DEFAULT;
> +av_log(avctx, AV_LOG_VERBOSE, "invalid p_strategy, set to 
> default\n");
> +break;
> +}
>  #if QSV_HAVE_GPB
>  if (avctx->codec_id == AV_CODEC_ID_HEVC)
>  q->extco3.GPB  = q->gpb ? MFX_CODINGOPTION_ON : 
> MFX_CODINGOPTION_OFF;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 3720320789..a074561ca8 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,6 +96,7 @@
>  { "adaptive_i", "Adaptive I-frame placement", 
> OFFSET(qsv.adaptive_i), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, 
> VE }, \
>  { "adaptive_b", "Adaptive B-frame placement", 
> OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, 
> VE }, \
>  { "b_strategy", "Strategy to choose between I/P/B-frames", 
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
> }, \
> +{ "p_strategy", "enable P-pyramid 0-default 1-simple 2-pyramid",
> OFFSET(qsv.p_strategy), AV_OPT_TYPE_INT,{ .i64 = 0}, 0,2, VE },   
>   \
>  { "forced_idr", "Forcing I frames as IDR frames", 
> OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,  1, 
> VE }, \
>  { "low_power", "enable low power mode(experimental: many limitations by mfx 
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 = 
> 0}, 0, 1, VE},\
>  { "dblk_idc", "value of DisableDeblockingIdc (default is 0), in range 
> [0,2]",   OFFSET(qsv.dblk_idc),   AV_OPT_TYPE_INT,{ .i64 = 0 },   0,  2,  
> VE},\
> @@ -185,6 +186,7 @@ typedef struct QSVEncContext {
>  int adaptive_i;
>  int adaptive_b;
>  int b_strategy;
> +int p_strategy;
>  int cavlc;
>
>  int int_ref_type;
> --
> 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".



-- 
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] tests/audiomatch: add free to make static analysis tools happy

2020-12-10 Thread myp...@gmail.com
On Thu, Dec 10, 2020 at 4:11 PM Anton Khirnov  wrote:
>
> Quoting Jun Zhao (2020-12-09 10:53:08)
> > From: Jun Zhao 
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  tests/audiomatch.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
>
> looks ok
>
Pushed, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: remove an always true condition

2020-12-08 Thread myp...@gmail.com
On Sat, Oct 17, 2020 at 11:48 PM Zhao Zhili  wrote:
>
>
>
> > On Sep 18, 2020, at 10:33 PM, Zhao Zhili  wrote:
> >
> > From: Zhao Zhili 
> >
> > ---
> > libavformat/mov.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 9fc0db24d5..f99605c2cd 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -1475,7 +1475,7 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> > c->duration = (version == 1) ? avio_rb64(pb) : avio_rb32(pb); /* 
> > duration */
> > // set the AVFormatContext duration because the duration of individual 
> > tracks
> > // may be inaccurate
> > -if (c->time_scale > 0 && !c->trex_data)
> > +if (!c->trex_data)
> > c->fc->duration = av_rescale(c->duration, AV_TIME_BASE, 
> > c->time_scale);
> > avio_rb32(pb); /* preferred scale */
>
> Ping for review.
>
> The always true condition is not obvious in the patch. time_scale is checked 
> a few lines before explicitly.
>
> 1471 if (c->time_scale <= 0) {
> 1472 av_log(c->fc, AV_LOG_ERROR, "Invalid mvhd time scale %d, 
> defaulting to 1\n", c->time_scale);
> 1473 c->time_scale = 1;
> 1474 }
> 1475 av_log(c->fc, AV_LOG_TRACE, "time scale = %i\n", c->time_scale);
> 1476
> 1477 c->duration = (version == 1) ? avio_rb64(pb) : avio_rb32(pb); /* 
> duration */
> 1478 // set the AVFormatContext duration because the duration of 
> individual tracks
> 1479 // may be inaccurate
> 1480 if (c->time_scale > 0 && !c->trex_data)
> 1481 c->fc->duration = av_rescale(c->duration, AV_TIME_BASE, 
> c->time_scale);
>
LGTM, will apply if no object
___
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] lavf/hls: add AC-3/EAC-3 to allowed extensions file list

2020-09-27 Thread myp...@gmail.com
On Sat, Sep 26, 2020 at 4:47 PM Steven Liu  wrote:
>
> Jun Zhao  于2020年9月25日周五 下午8:25写道:
> >
> > From: Jun Zhao 
> >
> > Add AC-3/EAC-3 to allowed extensions file list.
> >
> > From HTTP Live Streaming 2nd Edition draft-pantos-hls-rfc8216bis-07
> > section 3.1.3.Packed Audio, HLS demuxer need to support MP3/AC-3/EAC-3.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/hls.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index f33ff3f..72e28ab 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -2371,7 +2371,7 @@ static const AVOption hls_options[] = {
> >  OFFSET(live_start_index), AV_OPT_TYPE_INT, {.i64 = -3}, INT_MIN, 
> > INT_MAX, FLAGS},
> >  {"allowed_extensions", "List of file extensions that hls is allowed to 
> > access",
> >  OFFSET(allowed_extensions), AV_OPT_TYPE_STRING,
> > -{.str = 
> > "3gp,aac,avi,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
> > +{.str = 
> > "3gp,aac,avi,ac3,eac3,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
> >  INT_MIN, INT_MAX, FLAGS},
> >  {"max_reload", "Maximum number of times a insufficient list is 
> > attempted to be reloaded",
> >  OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, 
> > FLAGS},
> > --
> > 2.7.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".
>
> LGTM
>
>

patchset pushed, thx
___
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/http: fix memleak

2020-09-23 Thread myp...@gmail.com
On Thu, Sep 24, 2020 at 2:10 AM Zhao Zhili  wrote:
>
> Ping for review.
>
> > On Aug 24, 2020, at 12:58 AM, Zhao Zhili  wrote:
> >
> > ---
> > libavformat/http.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/http.c b/libavformat/http.c
> > index 6c39da1a8b..3d25d652d3 100644
> > --- a/libavformat/http.c
> > +++ b/libavformat/http.c
> > @@ -577,7 +577,7 @@ static int http_open(URLContext *h, const char *uri, 
> > int flags,
> >"No trailing CRLF found in HTTP header. Adding it.\n");
> > ret = av_reallocp(&s->headers, len + 3);
> > if (ret < 0)
> > -return ret;
> > +goto bail_out;
> > s->headers[len] = '\r';
> > s->headers[len + 1] = '\n';
> > s->headers[len + 2] = '\0';
> > @@ -588,6 +588,7 @@ static int http_open(URLContext *h, const char *uri, 
> > int flags,
> > return http_listen(h, uri, flags, options);
> > }
> > ret = http_open_cnx(h, options);
> > +bail_out:
> > if (ret < 0)
> > av_dict_free(&s->chained_options);
> > return ret;
> > --
> > 2.25.1
> >
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/udp: remove redundant setting of h->max_packet_size

2020-09-23 Thread myp...@gmail.com
On Thu, Sep 24, 2020 at 12:15 AM Zhao Zhili  wrote:
>
> h->max_packet_size is being reset in the following code.
> ---
>  libavformat/udp.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 30d8041433..96d8b8ee11 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -650,9 +650,6 @@ static int udp_open(URLContext *h, const char *uri, int 
> flags)
>  goto fail;
>  }
>
> -if (s->pkt_size > 0)
> -h->max_packet_size = s->pkt_size;
> -
>  p = strchr(uri, '?');
>  if (p) {
>  if (av_find_info_tag(buf, sizeof(buf), "reuse", p)) {
> --
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-09-20 Thread myp...@gmail.com
On Mon, Sep 21, 2020 at 1:27 AM Gyan Doshi  wrote:
>
>
>
> On 17-09-2020 01:07 pm, Gyan Doshi wrote:
> >
> >
> > On 15-09-2020 12:47 pm, myp...@gmail.com wrote:
> >> On Tue, Sep 15, 2020 at 2:23 PM Gyan Doshi  wrote:
> >>> This should be backported to 4.3 and other releases whose builds fail.
> >>>
> >>> Gyan
> >> Will backporting, thx
> >
> > Ping.
> >
> > 4.3.1 build with libsrt remains broken.
>
> I'll test and apply this myself, I guess.
>
Done, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-09-20 Thread myp...@gmail.com
On Mon, Sep 21, 2020 at 1:27 AM Gyan Doshi  wrote:
>
>
>
> On 17-09-2020 01:07 pm, Gyan Doshi wrote:
> >
> >
> > On 15-09-2020 12:47 pm, myp...@gmail.com wrote:
> >> On Tue, Sep 15, 2020 at 2:23 PM Gyan Doshi  wrote:
> >>> This should be backported to 4.3 and other releases whose builds fail.
> >>>
> >>> Gyan
> >> Will backporting, thx
> >
> > Ping.
> >
> > 4.3.1 build with libsrt remains broken.
>
> I'll test and apply this myself, I guess.
>

Busy with other urgent things last week, sorry, will test /back
porting then push to 4.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".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-09-15 Thread myp...@gmail.com
On Tue, Sep 15, 2020 at 2:23 PM Gyan Doshi  wrote:
>
> This should be backported to 4.3 and other releases whose builds fail.
>
> Gyan

Will backporting, thx
___
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] Added MKV tag for AVS2 video codec

2020-09-14 Thread myp...@gmail.com
On Sun, Sep 6, 2020 at 6:40 PM Ze Yuan  wrote:
>
> From ea96e70874c87b003af1fb3fcd5c792b3292bf29 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E9=83=91=E5=A4=A9=E6=B3=A2?= 
> Date: Sun, 6 Sep 2020 18:35:51 +0800
> Subject: [PATCH] Added MKV tag for AVS2 video codec
>
> avs2 (IEEE 1857.4) video codec
>
> MKV spec: V_AVS2 Codec ID: V_AVS2 Codec Name: AVS2-P2/IEEE.1857.4
> (https://github.com/xatabhk/matroska-specification/blob/master/codec_specs.md)
>
> Standard document:
> 1857.4-2018 - IEEE Standard for Second-Generation IEEE 1857 Video Coding 
> (https://ieeexplore.ieee.org/document/8821610)
>
> Encoding tool:
> Ffmpeg with avs2 enabled: https://github.com/xatabhk/FFmpeg-avs2-avs3/releases
> Command line:
>
>  ffmpeg -i .mp4 -vcodec avs2 -acodec copy _avs2.mkv
>  ffmpeg -i .mp4 -vcodec avs2 -speed_level 4 -acodec copy 
> _avs2.mkv`
>
> Players:
> (1) Ffmpeg with avs2 enabled: 
> (https://github.com/xatabhk/FFmpeg-avs2-avs3/releases):
> Command line:
>
>  ffplay _avs2.mkv`
> (2) VLC 3.0.x with avs2 enabled: 
> https://github.com/xatabhk/vlc-3.0-avs2-avs3/releases
> (3) Mpc-hc 1.9.x with avs2 enabled: 
> https://gitee.com/zhengtianbo/cavs-avs2-avs3_decoder_added_to_mpc_hc/releases
>
> Avs2-MKV samples:
> https://github.com/xatabhk/avs2-avs3-video-samples
>
> ---
> libavformat/matroska.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/matroska.c b/libavformat/matroska.c
> index 7c56aba403..2ce60c6277 100644
> --- a/libavformat/matroska.c
> +++ b/libavformat/matroska.c
> @@ -78,6 +78,7 @@ const CodecTags ff_mkv_codec_tags[]={
>  {"S_HDMV/TEXTST", AV_CODEC_ID_HDMV_TEXT_SUBTITLE},
>
>  {"V_AV1", AV_CODEC_ID_AV1},
> +{"V_AVS2"   , AV_CODEC_ID_AVS2},
>  {"V_DIRAC"  , AV_CODEC_ID_DIRAC},
>  {"V_FFV1"   , AV_CODEC_ID_FFV1},
>  {"V_MJPEG"  , AV_CODEC_ID_MJPEG},
> --
> 2.25.1

LGTM, now AVS2 supported by MKV spec from link
https://github.com/cellar-wg/matroska-specification/blob/master/codec_specs.md
___
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 v9 2/5] lavc/avs3: add AVS3 related definitions

2020-09-14 Thread myp...@gmail.com
On Mon, Aug 31, 2020 at 11:09 PM  wrote:
>
> From: hwren 
>
> Signed-off-by: hwren 
> ---
>  libavcodec/avs3.h | 118 ++
>  1 file changed, 118 insertions(+)
>  create mode 100644 libavcodec/avs3.h
>
> diff --git a/libavcodec/avs3.h b/libavcodec/avs3.h
> new file mode 100644
> index 00..4189d9b583
> --- /dev/null
> +++ b/libavcodec/avs3.h
> @@ -0,0 +1,118 @@
> +/*
> + *  AVS3 related definitions
> + *
> + * Copyright (C) 2020 Huiwen Ren, 
> + *
> + * 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
> + */
> +
> +#ifndef AVCODEC_AVS3_H
> +#define AVCODEC_AVS3_H
> +
> +#define AVS3_NAL_START_CODE  0x01
> +#define AVS3_SEQ_START_CODE  0xB0
> +#define AVS3_SEQ_END_CODE0xB1
> +#define AVS3_USER_DATA_START_CODE0xB2
> +#define AVS3_INTRA_PIC_START_CODE0xB3
> +#define AVS3_UNDEF_START_CODE0xB4
> +#define AVS3_EXTENSION_START_CODE0xB5
> +#define AVS3_INTER_PIC_START_CODE0xB6
> +#define AVS3_VIDEO_EDIT_CODE 0xB7
> +#define AVS3_FIRST_SLICE_START_CODE  0x00
> +#define AVS3_PROFILE_BASELINE_MAIN   0x20
> +#define AVS3_PROFILE_BASELINE_MAIN10 0x22
> +
> +#define AVS3_ISPIC(x) ((x) == AVS3_INTRA_PIC_START_CODE || (x) == 
> AVS3_INTER_PIC_START_CODE)
> +#define AVS3_ISUNIT(x) ((x) == AVS3_SEQ_START_CODE || AVS3_ISPIC(x))
> +
> +#include "libavutil/avutil.h"
> +#include "libavutil/pixfmt.h"
> +#include "libavutil/rational.h"
> +
> +static const AVRational ff_avs3_frame_rate_tab[16] = {
> +{ 0, 0   }, // forbid
> +{ 24000, 1001},
> +{ 24   , 1   },
> +{ 25   , 1   },
> +{ 3, 1001},
> +{ 30   , 1   },
> +{ 50   , 1   },
> +{ 6, 1001},
> +{ 60   , 1   },
> +{ 100  , 1   },
> +{ 120  , 1   },
> +{ 200  , 1   },
> +{ 240  , 1   },
> +{ 300  , 1   },
> +{ 0, 0   }, // reserved
> +{ 0, 0   }  // reserved
> +};
> +
> +static const int ff_avs3_color_primaries_tab[10] = {
> +AVCOL_PRI_RESERVED0   ,// 0
> +AVCOL_PRI_BT709   ,// 1
> +AVCOL_PRI_UNSPECIFIED ,// 2
> +AVCOL_PRI_RESERVED,// 3
> +AVCOL_PRI_BT470M  ,// 4
> +AVCOL_PRI_BT470BG ,// 5
> +AVCOL_PRI_SMPTE170M   ,// 6
> +AVCOL_PRI_SMPTE240M   ,// 7
> +AVCOL_PRI_FILM,// 8
> +AVCOL_PRI_BT2020   // 9
> +};
> +
> +static const int ff_avs3_color_transfer_tab[15] = {
> +AVCOL_TRC_RESERVED0, // 0
> +AVCOL_TRC_BT709, // 1
> +AVCOL_TRC_UNSPECIFIED  , // 2
> +AVCOL_TRC_RESERVED , // 3
> +AVCOL_TRC_GAMMA22  , // 4
> +AVCOL_TRC_GAMMA28  , // 5
> +AVCOL_TRC_SMPTE170M, // 6
> +AVCOL_TRC_SMPTE240M, // 7
> +AVCOL_TRC_LINEAR   , // 8
> +AVCOL_TRC_LOG  , // 9
> +AVCOL_TRC_LOG_SQRT , // 10
> +AVCOL_TRC_BT2020_12, // 11
> +AVCOL_TRC_SMPTE2084, // 12
> +AVCOL_TRC_UNSPECIFIED  , // 13
> +AVCOL_TRC_ARIB_STD_B67   // 14
> +};
> +
> +static const int ff_avs3_color_matrix_tab[12] = {
> +AVCOL_SPC_RESERVED , // 0
> +AVCOL_SPC_BT709, // 1
> +AVCOL_SPC_UNSPECIFIED  , // 2
> +AVCOL_SPC_RESERVED , // 3
> +AVCOL_SPC_FCC  , // 4
> +AVCOL_SPC_BT470BG  , // 5
> +AVCOL_SPC_SMPTE170M, // 6
> +AVCOL_SPC_SMPTE240M, // 7
> +AVCOL_SPC_BT2020_NCL   , // 8
> +AVCOL_SPC_BT2020_CL, // 9
> +AVCOL_SPC_UNSPECIFIED  , // 10
> +AVCOL_SPC_UNSPECIFIED// 11
> +};
> +
> +static const enum AVPictureType ff_avs3_image_type[4] = {
> +AV_PICTURE_TYPE_NONE,
> +AV_PICTURE_TYPE_I,
> +AV_PICTURE_TYPE_P,
> +AV_PICTURE_TYPE_B
> +};
> +
> +#endif /* AVCODEC_AVS3_H */
> --
Now patchset is OK for me, no more comments
___
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] lavfi/sendcmd: correct the option flags dump

2020-09-13 Thread myp...@gmail.com
On Sun, Sep 13, 2020 at 6:30 PM Paul B Mahol  wrote:
>
> On Sun, Sep 13, 2020 at 12:40:45PM +0800, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > correct the option flags dump for sendcmd/asendcmd.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavfilter/f_sendcmd.c | 26 --
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
> > index 6b02669..5e4c891 100644
> > --- a/libavfilter/f_sendcmd.c
> > +++ b/libavfilter/f_sendcmd.c
> > @@ -103,14 +103,6 @@ typedef struct SendCmdContext {
> >  } SendCmdContext;
> >
> >  #define OFFSET(x) offsetof(SendCmdContext, x)
> > -#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_AUDIO_PARAM | 
> > AV_OPT_FLAG_VIDEO_PARAM
> > -static const AVOption options[] = {
> > -{ "commands", "set commands", OFFSET(commands_str), 
> > AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS },
> > -{ "c","set commands", OFFSET(commands_str), 
> > AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS },
> > -{ "filename", "set commands file",  OFFSET(commands_filename), 
> > AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS },
> > -{ "f","set commands file",  OFFSET(commands_filename), 
> > AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS },
> > -{ NULL }
> > -};
>
> Cant you use macro somehow?, because you are duplicating most of lines/code.
>
Will try to remove the redundant, thx
___
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] ffmpeg_qsv: use -hwaccel_device to specify a device for VAAPI backend

2020-09-02 Thread myp...@gmail.com
On Thu, Sep 3, 2020 at 9:21 AM Xiang, Haihao  wrote:
>
> On Wed, 2020-09-02 at 14:04 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Rogozhkin, Dmitry V
> > > Sent: Wednesday, September 2, 2020 3:54 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device to
> > > specify a device for VAAPI backend
> > >
> > > On Wed, 2020-09-02 at 07:31 +, Soft Works wrote:
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf Of
> > > > > Rogozhkin, Dmitry V
> > > > > Sent: Wednesday, September 2, 2020 9:00 AM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use -hwaccel_device
> > > > > to specify a device for VAAPI backend
> > > > >
> > > > > On Wed, 2020-09-02 at 04:28 +, Xiang, Haihao wrote:
> > > > > > On Wed, 2020-09-02 at 04:20 +, Soft Works wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: ffmpeg-devel  On
> > >
> > > Behalf
> > > > >
> > > > > Of
> > > > > > > > Haihao Xiang
> > > > > > > > Sent: Wednesday, September 2, 2020 6:01 AM
> > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > Cc: Haihao Xiang 
> > > > > > > > Subject: [FFmpeg-devel] [PATCH] ffmpeg_qsv: use
> > > > > > > > -hwaccel_device to specify a device for VAAPI backend
> > > > > > > >
> > > > > > > > According to the FFmpeg documentation, -hwaccel_device can be
> > > > > > > > used to select a device for hardware acceleration
> > > > > > > >
> > > > > > > > Example:
> > > > > > > > ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD129 -c:v
> > > > > > > > h264_qsv \ -i
> > > > > > > > in.h264 -c:v hevc_qsv out.h265
> > > > > > >
> > > > > > > No. The docs say about hwaccel_device
> > > > > > >
> > > > > > > It can either refer to an existing device created with
> > > > > > > -init_hw_device by name,
> > > > > > >
> > > > > > > => /dev/dri/renderD129 is not an existing device name
> > > > > > >
> > > > > > > or it can create a new device as if ‘-init_hw_device’
> > > > > > > type:hwaccel_device were called immediately before.
> > > > > > >
> > > > > > > => /dev/dri/renderD129 is not a valid string for init_hw_device
> > > > >
> > > > > Well, it seems that's where documentation does not reflect the
> > > > > reality since (as pointed by Haihao below)
> > > > > https://trac.ffmpeg.org/wiki/Hardware/VAAPI
> > > > > is full of contradictory examples.
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hence, the patch doesn't make sense.
> > > > > >
> > > > > > in https://trac.ffmpeg.org/wiki/Hardware/VAAPI,
> > > > > >
> > > > > > If only one stream is being used, -hwaccel_device can also accept
> > > > > > a device path directly
> > > > > >
> > > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i ...
> > > > > >
> > > > > > I think it can be applied to qsv too.
> > > > > >
> > > > >
> > > > > I agree. Part of ffmpeg help:
> > > > > -hwaccel hwaccel name  use HW accelerated decoding
> > > > > -hwaccel_device devicename  select a device for HW acceleration
> > > > >
> > > > > To me specifying device via -hwaccel_device in the way it is being
> > > > > suggest in commit is pretty intuitive and is better than explain
> > > > > people that there is - qsv_device for that purpose. Niceness of
> > > > > -hwaccel_device is that it is not tight to particular acceleration,
> > > > > hence easier to work with for end users.
> > > >
> > > > In case of QSV, the usage of hwaccel_device is already defined:
> > > >
> > > > device selects a value in ‘MFX_IMPL_*’. Allowed values are:
> > > > auto sw  hw  auto_any hw_any hw2 hw3 hw4
> > > >
> > > > I agree that it would be more intuitive, but you can't just give it a
> > > > different meaning from one day to another and break functionality.
> > >
> > > Adding new values does not break functionality! No one  suggests to drop
> > > existing set of values (sw, hw, etc.) - these are remaining. But basically
> > > suggestion is to extend allowed set to accept drm device specification on
> > > Linux, that's it. Honestly, I don't see problem here.
> > > Some background story: hw,hw2,hw3 allows to select adapter for msdk
> > > library on Windows, but they don't allow to do that on Linux. On Linux all
> > > these hw options are basically the same for the reason that device is 
> > > being
> > > specified externally via SetHandle call. On Linux only sw/hw makes a
> > > difference (other story that sw msdk library is not actually released
> > > currently
> > > on Linux). That's the origin of the request: we need a good way to specify
> > > adapter on Linux.
> >
> > As mentioned, there are cases where both needs to be specified on Windows:
> > hw, hw2, hw3,.. plus adapter number.
> >
> > 'qsv_device' is for specifying adapter number on Windows and DRI on Linux
> > 'hwaccel_device' is for specifying hw, hw2, hw3 (everywhere)
>
> According to https://trac.ffmpeg.org/ticket/7649, -qsv_device w

Re: [FFmpeg-devel] [PATCH v8 2/5] lavc/avs3: add AVS3 related definitions

2020-08-27 Thread myp...@gmail.com
On Thu, Aug 27, 2020 at 1:34 PM  wrote:
>
> From: hwren 
>
> Signed-off-by: hwren 
> ---
>  libavcodec/Makefile |  2 +
>  libavcodec/avs3.c   | 95 +
>  libavcodec/avs3.h   | 52 +
>  3 files changed, 149 insertions(+)
>  create mode 100644 libavcodec/avs3.c
>  create mode 100644 libavcodec/avs3.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3431ba2dca..e1e0c4629d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -6,6 +6,7 @@ HEADERS = ac3_parser.h
>   \
>avcodec.h \
>avdct.h   \
>avfft.h   \
> +  avs3.h\
>bsf.h \
>codec.h   \
>codec_desc.h  \
> @@ -32,6 +33,7 @@ OBJS = ac3_parser.o 
> \
> avdct.o  \
> avpacket.o   \
> avpicture.o  \
> +   avs3.o   \
> bitstream.o  \
> bitstream_filter.o   \
> bitstream_filters.o  \
> diff --git a/libavcodec/avs3.c b/libavcodec/avs3.c
> new file mode 100644
> index 00..411a6c39a0
> --- /dev/null
> +++ b/libavcodec/avs3.c
> @@ -0,0 +1,95 @@
> +/*
> + * AVS3 related definitions
> + *
> + * Copyright (C) 2020 Huiwen Ren, 
> + *
> + * 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 "avs3.h"
> +
> +const AVRational ff_avs3_frame_rate_tab[16] = {
> +{ 0, 0   }, // forbid
> +{ 24000, 1001},
> +{ 24   , 1   },
> +{ 25   , 1   },
> +{ 3, 1001},
> +{ 30   , 1   },
> +{ 50   , 1   },
> +{ 6, 1001},
> +{ 60   , 1   },
> +{ 100  , 1   },
> +{ 120  , 1   },
> +{ 200  , 1   },
> +{ 240  , 1   },
> +{ 300  , 1   },
> +{ 0, 0   }, // reserved
> +{ 0, 0   }  // reserved
> +};
> +
> +const int ff_avs3_color_primaries_tab[10] = {
> +AVCOL_PRI_RESERVED0   ,// 0
> +AVCOL_PRI_BT709   ,// 1
> +AVCOL_PRI_UNSPECIFIED ,// 2
> +AVCOL_PRI_RESERVED,// 3
> +AVCOL_PRI_BT470M  ,// 4
> +AVCOL_PRI_BT470BG ,// 5
> +AVCOL_PRI_SMPTE170M   ,// 6
> +AVCOL_PRI_SMPTE240M   ,// 7
> +AVCOL_PRI_FILM,// 8
> +AVCOL_PRI_BT2020   // 9
> +};
> +
> +const int ff_avs3_color_transfer_tab[15] = {
> +AVCOL_TRC_RESERVED0, // 0
> +AVCOL_TRC_BT709, // 1
> +AVCOL_TRC_UNSPECIFIED  , // 2
> +AVCOL_TRC_RESERVED , // 3
> +AVCOL_TRC_GAMMA22  , // 4
> +AVCOL_TRC_GAMMA28  , // 5
> +AVCOL_TRC_SMPTE170M, // 6
> +AVCOL_TRC_SMPTE240M, // 7
> +AVCOL_TRC_LINEAR   , // 8
> +AVCOL_TRC_LOG  , // 9
> +AVCOL_TRC_LOG_SQRT , // 10
> +AVCOL_TRC_BT2020_12, // 11
> +AVCOL_TRC_SMPTE2084, // 12
> +AVCOL_TRC_UNSPECIFIED  , // 13
> +AVCOL_TRC_ARIB_STD_B67   // 14
> +};
> +
> +const int ff_avs3_color_matrix_tab[12] = {
> +AVCOL_SPC_RESERVED , // 0
> +AVCOL_SPC_BT709, // 1
> +AVCOL_SPC_UNSPECIFIED  , // 2
> +AVCOL_SPC_RESERVED , // 3
> +AVCOL_SPC_FCC  , // 4
> +AVCOL_SPC_BT470BG  , // 5
> +AVCOL_SPC_SMPTE170M, // 6
> +AVCOL_SPC_SMPTE240M, // 7
> +AVCOL_SPC_BT2020_NCL   , // 8
> +AVCOL_SPC_BT2020_CL, // 9
> +AVCOL_SPC_UNSPECIFIED  , // 10
> +AVCOL_SPC_UNSPECIFIED// 11
> +};
> +
> +const enum AVPictureType ff_avs3_image_type[4] = {
> +AV_PICTURE_TYPE_NONE,
>

Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats

2020-08-21 Thread myp...@gmail.com
On Fri, Aug 21, 2020 at 7:15 AM James Almer  wrote:
>
> On 8/15/2020 5:48 AM, myp...@gmail.com wrote:
> > On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson  wrote:
> >>
> >> On 26/07/2020 13:26, Jun Zhao wrote:
> >>> From: Jun Zhao 
> >>>
> >>> Export choosen pict_type and qp.
> >>>
> >>> Signed-off-by: Jun Zhao 
> >>> ---
> >>>   libavcodec/libkvazaar.c | 30 ++
> >>>   1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >>> index 71c9c8f..9032547 100644
> >>> --- a/libavcodec/libkvazaar.c
> >>> +++ b/libavcodec/libkvazaar.c
> >>> @@ -37,6 +37,7 @@
> >>>
> >>>   #include "avcodec.h"
> >>>   #include "internal.h"
> >>> +#include "packet_internal.h"
> >>>
> >>>   typedef struct LibkvazaarContext {
> >>>   const AVClass *class;
> >>> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>   kvz_data_chunk *data_out = NULL;
> >>>   uint32_t len_out = 0;
> >>>   int retval = 0;
> >>> +int pict_type;
> >>>
> >>>   *got_packet_ptr = 0;
> >>>
> >>> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>   avpkt->flags |= AV_PKT_FLAG_KEY;
> >>>   }
> >>>
> >>> +switch (frame_info.slice_type) {
> >>> +case KVZ_SLICE_I:
> >>> +pict_type = AV_PICTURE_TYPE_I;
> >>> +break;
> >>> +case KVZ_SLICE_P:
> >>> +pict_type = AV_PICTURE_TYPE_P;
> >>> +break;
> >>> +case KVZ_SLICE_B:
> >>> +pict_type = AV_PICTURE_TYPE_B;
> >>> +break;
> >>> +default:
> >>> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type 
> >>> encountered.\n");
> >>> +return AVERROR_EXTERNAL;
> >>> +}
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->pict_type = pict_type;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>
> >> Is there some value to setting the deprecated fields?  They will disappear 
> >> on the next version bump, which probably isn't very far away.
> >>
> > I think we can keep this part, if we want to remove the
> > avctx->coded_frame->pict_type from next version bump, we can drop this
> > part from all codec one-time
>
> No, the usage of deprecated features should not be expanded. It's kept
> in old encoders for compatibility reasons, but new ones should not use
> it at all. So please remove it.
>
Will remove it, thx
> >>> +
> >>> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp * 
> >>> FF_QP2LAMBDA, NULL, 0, pict_type);
> >>
> >> I'm not familiar with kvazaar - is the QP value here actually reflective 
> >> of the global quality in a useful way?  The documentation is not very 
> >> good...
> >>
> > Yes, it's a global quality based on Frame in kvazaar
> >
> >> (Your following patch for OpenH264 uses a field "AverageFrameQP", which 
> >> has an much more usefully-suggestive name.)
> >>
> >> Zero is a valid QP value, but you shouldn't be passing it here.  Possibly 
> >> it needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
> >>
> > I know vpx encoder wrapper used the zero QP value in side data, maybe
> > we can keep the same action
> >>> +
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>> +
> >>>   *got_packet_ptr = 1;
> >>>   }
> >>>
> >>>
> >> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats

2020-08-21 Thread myp...@gmail.com
On Fri, Aug 21, 2020 at 7:03 AM Mark Thompson  wrote:
>
> On 15/08/2020 09:48, myp...@gmail.com wrote:
> > On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson  wrote:
> >>
> >> On 26/07/2020 13:26, Jun Zhao wrote:
> >>> From: Jun Zhao 
> >>>
> >>> Export choosen pict_type and qp.
> >>>
> >>> Signed-off-by: Jun Zhao 
> >>> ---
> >>>libavcodec/libkvazaar.c | 30 ++
> >>>1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >>> index 71c9c8f..9032547 100644
> >>> --- a/libavcodec/libkvazaar.c
> >>> +++ b/libavcodec/libkvazaar.c
> >>> @@ -37,6 +37,7 @@
> >>>
> >>>#include "avcodec.h"
> >>>#include "internal.h"
> >>> +#include "packet_internal.h"
> >>>
> >>>typedef struct LibkvazaarContext {
> >>>const AVClass *class;
> >>> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>kvz_data_chunk *data_out = NULL;
> >>>uint32_t len_out = 0;
> >>>int retval = 0;
> >>> +int pict_type;
> >>>
> >>>*got_packet_ptr = 0;
> >>>
> >>> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>avpkt->flags |= AV_PKT_FLAG_KEY;
> >>>}
> >>>
> >>> +switch (frame_info.slice_type) {
> >>> +case KVZ_SLICE_I:
> >>> +pict_type = AV_PICTURE_TYPE_I;
> >>> +break;
> >>> +case KVZ_SLICE_P:
> >>> +pict_type = AV_PICTURE_TYPE_P;
> >>> +break;
> >>> +case KVZ_SLICE_B:
> >>> +pict_type = AV_PICTURE_TYPE_B;
> >>> +break;
> >>> +default:
> >>> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type 
> >>> encountered.\n");
> >>> +return AVERROR_EXTERNAL;
> >>> +}
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->pict_type = pict_type;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>
> >> Is there some value to setting the deprecated fields?  They will disappear 
> >> on the next version bump, which probably isn't very far away.
> >>
> > I think we can keep this part, if we want to remove the
> > avctx->coded_frame->pict_type from next version bump, we can drop this
> > part from all codec one-time
> >>> +
> >>> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp * 
> >>> FF_QP2LAMBDA, NULL, 0, pict_type);
> >>
> >> I'm not familiar with kvazaar - is the QP value here actually reflective 
> >> of the global quality in a useful way?  The documentation is not very 
> >> good...
> >>
> > Yes, it's a global quality based on Frame in kvazaar
> >
> >> (Your following patch for OpenH264 uses a field "AverageFrameQP", which 
> >> has an much more usefully-suggestive name.)
> >>
> >> Zero is a valid QP value, but you shouldn't be passing it here.  Possibly 
> >> it needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
> >>
> > I know vpx encoder wrapper used the zero QP value in side data, maybe
> > we can keep the same action
>
> So the libvpx wrapper is also broken?  This all seems very inconsistent - the 
> documentation requires that the number be in [1, FF_LAMBDA_MAX], but codecs 
> are using random numbers which include zero.
>
> libx264 is applying some sort of offset so that the returned qpplus1 field is 
> actually qpplussomewherebetween1and30 (with 10-bit input qp == -12 gives 
> qpplus1 == 1 and qp == 51 gives qpplus1 == 81), but we still subtract 1 so 
> the result includes zero.
>
> libx265 doesn't seem to support negative QPs so it's always in the 8-bit 
> range, but that still includes zero.
>
> nvenc has frameAvgQP - 1, which seems bizarre.  I guess it would work if it 
> doesn't support QP < 2, but given that it allows 12-bit inputs (range -24 to 
> 51) that seems unlikely.
>
> Scaling to match what the documentation actually says seems like the sanest 
> way to fix this - we can't change the range because zero is the "unused" 
> value.
>
I believe  the  parameter  int quality in function int
ff_side_data_set_encoder_stats(AVPacket *pkt, int quality, int64_t
*error, int error_count, int pict_type) is  inconsistent, I think need
to more check/clarification in  different codec
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] lavf/libkvazaar: export encoded frame stats

2020-08-20 Thread myp...@gmail.com
On Tue, Aug 18, 2020 at 10:41 AM myp...@gmail.com  wrote:
>
> On Mon, Aug 17, 2020 at 7:08 PM Joose Sainio  wrote:
> >
> > On 7.8.2020 5.40, myp...@gmail.com wrote:
> > > On Sun, Jul 26, 2020 at 8:45 PM Jun Zhao  wrote:
> > >> From: Jun Zhao 
> > >>
> > >> Export choosen pict_type and qp.
> > >>
> > >> Signed-off-by: Jun Zhao 
> > >> ---
> > >> libavcodec/libkvazaar.c | 30 ++
> > >> 1 file changed, 30 insertions(+)
> > >>
> > >> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> > >> index 71c9c8f..9032547 100644
> > >> --- a/libavcodec/libkvazaar.c
> > >> +++ b/libavcodec/libkvazaar.c
> > >> @@ -37,6 +37,7 @@
> > >>
> > >> #include "avcodec.h"
> > >> #include "internal.h"
> > >> +#include "packet_internal.h"
> > >>
> > >> typedef struct LibkvazaarContext {
> > >> const AVClass *class;
> > >> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> > >> kvz_data_chunk *data_out = NULL;
> > >> uint32_t len_out = 0;
> > >> int retval = 0;
> > >> + int pict_type;
> > >>
> > >> *got_packet_ptr = 0;
> > >>
> > >> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> > >> avpkt->flags |= AV_PKT_FLAG_KEY;
> > >> }
> > >>
> > >> + switch (frame_info.slice_type) {
> > >> + case KVZ_SLICE_I:
> > >> + pict_type = AV_PICTURE_TYPE_I;
> > >> + break;
> > >> + case KVZ_SLICE_P:
> > >> + pict_type = AV_PICTURE_TYPE_P;
> > >> + break;
> > >> + case KVZ_SLICE_B:
> > >> + pict_type = AV_PICTURE_TYPE_B;
> > >> + break;
> > >> + default:
> > >> + av_log(avctx, AV_LOG_ERROR, "Unknown picture type encountered.\n");
> > >> + return AVERROR_EXTERNAL;
> > >> + }
> > >> +#if FF_API_CODED_FRAME
> > >> +FF_DISABLE_DEPRECATION_WARNINGS
> > >> + avctx->coded_frame->pict_type = pict_type;
> > >> +FF_ENABLE_DEPRECATION_WARNINGS
> > >> +#endif
> > >> +
> > >> + ff_side_data_set_encoder_stats(avpkt, frame_info.qp * FF_QP2LAMBDA,
> > >> NULL, 0, pict_type);
> > >> +
> > >> +#if FF_API_CODED_FRAME
> > >> +FF_DISABLE_DEPRECATION_WARNINGS
> > >> + avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> > >> +FF_ENABLE_DEPRECATION_WARNINGS
> > >> +#endif
> > >> +
> > >> *got_packet_ptr = 1;
> > >> }
> > >>
> > >> --
> > >> 2.7.4
> > >>
> > > ping ?
> > Sorry, I forgot I was subscribed to the list on the old organization
> > so the message didn't go through originally.
> >
> > In terms of Kvazaar this seems ok but the QP to lambda conversion will
> > result
> > in vastly different lambda value than what Kvazaar would have used
> > internally (and in fact the FF_QP2LAMBDA macro states it is for h.263).
> > I can't comment whether this is problem on the ffmpeg side.
> >
> > The correct formula for hevc/h.265 would be
> > lambda = 0.57 * pow(2.0, (qp - 12 / 3.0))
> This is the other issue, I think, will try to fix it.
After grep and dig in the ff_side_data_set_encoder_stats, I think use
frame_info.qp * FF_QP2LAMBDA (Avg frame QP as frame quality number
with scale number FF_QP2LAMBDA ) is Ok in this case.

In fact, the function int ff_side_data_set_encoder_stats(AVPacket
*pkt, int quality, int64_t *error, int error_count, int pict_type);
we just give a inaccuracy quality number for encoded Frame and depend
on the  specific codec
___
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] qsv: remove audio error code

2020-08-19 Thread myp...@gmail.com
On Wed, Aug 19, 2020 at 2:10 PM Haihao Xiang  wrote:
>
> ---
>  libavcodec/qsv.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index faa424bb68..6776b745b9 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -143,8 +143,6 @@ static const struct {
>  { MFX_ERR_INVALID_VIDEO_PARAM,  AVERROR(EINVAL), "invalid video 
> parameters" },
>  { MFX_ERR_UNDEFINED_BEHAVIOR,   AVERROR_BUG, "undefined 
> behavior"   },
>  { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed" 
>},
> -{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio 
> parameters"},
> -{ MFX_ERR_INVALID_AUDIO_PARAM,  AVERROR(EINVAL), "invalid audio 
> parameters" },
>
>  { MFX_WRN_IN_EXECUTION, 0,   "operation in 
> execution"   },
>  { MFX_WRN_DEVICE_BUSY,  0,   "device busy"   
>},
> @@ -154,7 +152,6 @@ static const struct {
>  { MFX_WRN_VALUE_NOT_CHANGED,0,   "value is 
> saturated"   },
>  { MFX_WRN_OUT_OF_RANGE, 0,   "value out of 
> range"   },
>  { MFX_WRN_FILTER_SKIPPED,   0,   "filter skipped"
>},
> -{ MFX_WRN_INCOMPATIBLE_AUDIO_PARAM, 0,   "incompatible audio 
> parameters"},
>  };
>
>  int ff_qsv_map_error(mfxStatus mfx_err, const char **desc)
> --
> 2.25.1
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] lavf/libkvazaar: export encoded frame stats

2020-08-17 Thread myp...@gmail.com
On Mon, Aug 17, 2020 at 7:08 PM Joose Sainio  wrote:
>
> On 7.8.2020 5.40, myp...@gmail.com wrote:
> > On Sun, Jul 26, 2020 at 8:45 PM Jun Zhao  wrote:
> >> From: Jun Zhao 
> >>
> >> Export choosen pict_type and qp.
> >>
> >> Signed-off-by: Jun Zhao 
> >> ---
> >> libavcodec/libkvazaar.c | 30 ++
> >> 1 file changed, 30 insertions(+)
> >>
> >> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >> index 71c9c8f..9032547 100644
> >> --- a/libavcodec/libkvazaar.c
> >> +++ b/libavcodec/libkvazaar.c
> >> @@ -37,6 +37,7 @@
> >>
> >> #include "avcodec.h"
> >> #include "internal.h"
> >> +#include "packet_internal.h"
> >>
> >> typedef struct LibkvazaarContext {
> >> const AVClass *class;
> >> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >> kvz_data_chunk *data_out = NULL;
> >> uint32_t len_out = 0;
> >> int retval = 0;
> >> + int pict_type;
> >>
> >> *got_packet_ptr = 0;
> >>
> >> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >> avpkt->flags |= AV_PKT_FLAG_KEY;
> >> }
> >>
> >> + switch (frame_info.slice_type) {
> >> + case KVZ_SLICE_I:
> >> + pict_type = AV_PICTURE_TYPE_I;
> >> + break;
> >> + case KVZ_SLICE_P:
> >> + pict_type = AV_PICTURE_TYPE_P;
> >> + break;
> >> + case KVZ_SLICE_B:
> >> + pict_type = AV_PICTURE_TYPE_B;
> >> + break;
> >> + default:
> >> + av_log(avctx, AV_LOG_ERROR, "Unknown picture type encountered.\n");
> >> + return AVERROR_EXTERNAL;
> >> + }
> >> +#if FF_API_CODED_FRAME
> >> +FF_DISABLE_DEPRECATION_WARNINGS
> >> + avctx->coded_frame->pict_type = pict_type;
> >> +FF_ENABLE_DEPRECATION_WARNINGS
> >> +#endif
> >> +
> >> + ff_side_data_set_encoder_stats(avpkt, frame_info.qp * FF_QP2LAMBDA,
> >> NULL, 0, pict_type);
> >> +
> >> +#if FF_API_CODED_FRAME
> >> +FF_DISABLE_DEPRECATION_WARNINGS
> >> + avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> >> +FF_ENABLE_DEPRECATION_WARNINGS
> >> +#endif
> >> +
> >> *got_packet_ptr = 1;
> >> }
> >>
> >> --
> >> 2.7.4
> >>
> > ping ?
> Sorry, I forgot I was subscribed to the list on the old organization
> so the message didn't go through originally.
>
> In terms of Kvazaar this seems ok but the QP to lambda conversion will
> result
> in vastly different lambda value than what Kvazaar would have used
> internally (and in fact the FF_QP2LAMBDA macro states it is for h.263).
> I can't comment whether this is problem on the ffmpeg side.
>
> The correct formula for hevc/h.265 would be
> lambda = 0.57 * pow(2.0, (qp - 12 / 3.0))
This is the other issue, I think, will try to fix it.
>
> - Joose
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats

2020-08-15 Thread myp...@gmail.com
On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson  wrote:
>
> On 26/07/2020 13:26, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > Export choosen pict_type and qp.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   libavcodec/libkvazaar.c | 30 ++
> >   1 file changed, 30 insertions(+)
> >
> > diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> > index 71c9c8f..9032547 100644
> > --- a/libavcodec/libkvazaar.c
> > +++ b/libavcodec/libkvazaar.c
> > @@ -37,6 +37,7 @@
> >
> >   #include "avcodec.h"
> >   #include "internal.h"
> > +#include "packet_internal.h"
> >
> >   typedef struct LibkvazaarContext {
> >   const AVClass *class;
> > @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >   kvz_data_chunk *data_out = NULL;
> >   uint32_t len_out = 0;
> >   int retval = 0;
> > +int pict_type;
> >
> >   *got_packet_ptr = 0;
> >
> > @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >   avpkt->flags |= AV_PKT_FLAG_KEY;
> >   }
> >
> > +switch (frame_info.slice_type) {
> > +case KVZ_SLICE_I:
> > +pict_type = AV_PICTURE_TYPE_I;
> > +break;
> > +case KVZ_SLICE_P:
> > +pict_type = AV_PICTURE_TYPE_P;
> > +break;
> > +case KVZ_SLICE_B:
> > +pict_type = AV_PICTURE_TYPE_B;
> > +break;
> > +default:
> > +av_log(avctx, AV_LOG_ERROR, "Unknown picture type 
> > encountered.\n");
> > +return AVERROR_EXTERNAL;
> > +}
> > +#if FF_API_CODED_FRAME
> > +FF_DISABLE_DEPRECATION_WARNINGS
> > +avctx->coded_frame->pict_type = pict_type;
> > +FF_ENABLE_DEPRECATION_WARNINGS
> > +#endif
>
> Is there some value to setting the deprecated fields?  They will disappear on 
> the next version bump, which probably isn't very far away.
>
I think we can keep this part, if we want to remove the
avctx->coded_frame->pict_type from next version bump, we can drop this
part from all codec one-time
> > +
> > +ff_side_data_set_encoder_stats(avpkt, frame_info.qp * 
> > FF_QP2LAMBDA, NULL, 0, pict_type);
>
> I'm not familiar with kvazaar - is the QP value here actually reflective of 
> the global quality in a useful way?  The documentation is not very good...
>
Yes, it's a global quality based on Frame in kvazaar

> (Your following patch for OpenH264 uses a field "AverageFrameQP", which has 
> an much more usefully-suggestive name.)
>
> Zero is a valid QP value, but you shouldn't be passing it here.  Possibly it 
> needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
>
I know vpx encoder wrapper used the zero QP value in side data, maybe
we can keep the same action
> > +
> > +#if FF_API_CODED_FRAME
> > +FF_DISABLE_DEPRECATION_WARNINGS
> > +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> > +FF_ENABLE_DEPRECATION_WARNINGS
> > +#endif
> > +
> >   *got_packet_ptr = 1;
> >   }
> >
> >
> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] doc/filters: update filter buffer/abuffer interface file name

2020-08-08 Thread myp...@gmail.com
On Sat, Aug 8, 2020 at 12:56 PM Gyan Doshi  wrote:
>
>
>
> On 07-08-2020 07:06 pm, Jun Zhao wrote:
> > From: tomajsjiang 
> >
> > Update filter buffer/abuffer interface file name, from
> > libavfilter/{vsrc|asrc_buffer.h} to libavfilter/buffersrc.h
> >
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: tomajsjiang 
> > ---
> >   doc/filters.texi | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 561aa98..d8cd450 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -5798,7 +5798,7 @@ Below is a description of the currently available 
> > audio sources.
> >   Buffer audio frames, and make them available to the filter chain.
> >
> >   This source is mainly intended for a programmatic use, in particular
> > -through the interface defined in @file{libavfilter/asrc_abuffer.h}.
> > +through the interface defined in @file{libavfilter/buffersrc.h}.
> >
> >   It accepts the following parameters:
> >   @table @option
> > @@ -22232,7 +22232,7 @@ Below is a description of the currently available 
> > video sources.
> >   Buffer video frames, and make them available to the filter chain.
> >
> >   This source is mainly intended for a programmatic use, in particular
> > -through the interface defined in @file{libavfilter/vsrc_buffer.h}.
> > +through the interface defined in @file{libavfilter/buffersrc.h}.
> >
> >   It accepts the following parameters:
>
> LGTM.
>
Pused patch 1-3 ,thx
___
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] lavf/mov: Support dref.url box for ISO 14496-12

2020-08-07 Thread myp...@gmail.com
On Fri, Aug 7, 2020 at 10:29 PM Zhao Zhili  wrote:
>
>
>
> > On Aug 7, 2020, at 9:37 PM, Jun Zhao  wrote:
> >
> > From: Jun Zhao 
> >
> > Enable the dref.url box
> >
> > Signed-off-by: Jun Zhao 
> > ---
> > libavformat/isom.h |  6 ++
> > libavformat/mov.c  | 45 ++---
> > 2 files changed, 44 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavformat/isom.h b/libavformat/isom.h
> > index 41a9c64..01e2c33 100644
> > --- a/libavformat/isom.h
> > +++ b/libavformat/isom.h
> > @@ -77,6 +77,12 @@ typedef struct MOVDref {
> > char volume[28];
> > char filename[64];
> > int16_t nlvl_to, nlvl_from;
> > +
> > +/*
> > + * DataEntryUrlBox
> > + */
> > +char *location; /* a location to find the resource with the 
> > given name */
> > +uint32_t location_len;
> > } MOVDref;
> >
> > typedef struct MOVAtom {
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 808ef7c..8fe2981 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -575,6 +575,7 @@ static int mov_read_dref(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> > AVStream *st;
> > MOVStreamContext *sc;
> > int entries, i, j;
> > +int flags;
> >
> > if (c->fc->nb_streams < 1)
> > return 0;
> > @@ -599,18 +600,19 @@ static int mov_read_dref(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> > MOVDref *dref = &sc->drefs[i];
> > uint32_t size = avio_rb32(pb);
> > int64_t next = avio_tell(pb) + size - 4;
> > +int ret;
> >
> > if (size < 12)
> > return AVERROR_INVALIDDATA;
> >
> > dref->type = avio_rl32(pb);
> > -avio_rb32(pb); // version + flags
> > +avio_r8(pb); /* version */
> > +flags = avio_rb24(pb);
> >
> > if (dref->type == MKTAG('a','l','i','s') && size > 150) {
> > /* macintosh alias record */
> > uint16_t volume_len, len;
> > int16_t type;
> > -int ret;
> >
> > avio_skip(pb, 10);
> >
> > @@ -696,6 +698,24 @@ static int mov_read_dref(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> > } else
> > avio_skip(pb, len);
> > }
> > +} else if (dref->type == MKTAG('u','r','l',' ') && size >= 12) {
> > +if (flags == 1) {
> > +/* do noting when elementray stream in the same file */
> > +av_log(c->fc, AV_LOG_TRACE, "media data location in the 
> > same file\n");
> > +} else {
> > +uint32_t len = size - 12;
> > +dref->location = av_malloc(len + 1); /* Add null 
> > terminator */
> > +if (!dref->location)
> > +return AVERROR(ENOMEM);
> > +
> > +ret = ffio_read_size(pb, dref->location, len);
> > +if (ret < 0) {
> > +av_freep(&dref->location);
> > +return ret;
> > +}
> > +dref->location_len = len;
> > +dref->location[len] = 0;
> > +}
> > } else {
> > av_log(c->fc, AV_LOG_DEBUG, "Unknown dref type 0x%08"PRIx32" 
> > size %"PRIu32"\n",
> >dref->type, size);
> > @@ -4169,6 +4189,11 @@ static int mov_open_dref(MOVContext *c, AVIOContext 
> > **pb, const char *src, MOVDr
> > if (!c->fc->io_open(c->fc, pb, filename, AVIO_FLAG_READ, NULL))
> > return 0;
> > }
> > +} else if (ref->location) {
> > +av_log(c->fc, AV_LOG_WARNING, "Try to open the media file in 
> > separate file from %s.\n",
> > +ref->location);
> > +if (!c->fc->io_open(c->fc, pb, ref->location, AVIO_FLAG_READ, 
> > NULL))
> > +return 0;
> > } else if (c->use_absolute_path) {
> > av_log(c->fc, AV_LOG_WARNING, "Using absolute path on user request, 
> > "
> >"this is a possible security issue\n");
> > @@ -4243,23 +4268,28 @@ static int mov_read_trak(MOVContext *c, AVIOContext 
> > *pb, MOVAtom atom)
> >
> > mov_build_index(c, st);
> >
> > -if (sc->dref_id-1 < sc->drefs_count && sc->drefs[sc->dref_id-1].path) {
> > +if (sc->dref_id-1 < sc->drefs_count &&
> > +(sc->drefs[sc->dref_id-1].path || 
> > sc->drefs[sc->dref_id-1].location)) {
> > MOVDref *dref = &sc->drefs[sc->dref_id - 1];
> > if (c->enable_drefs) {
> > if (mov_open_dref(c, &sc->pb, c->fc->url, dref) < 0)
> > av_log(c->fc, AV_LOG_ERROR,
> >"stream %d, error opening alias: path='%s', 
> > dir='%s', "
> > -   "filename='%s', volume='%s', nlvl_from=%d, 
> > nlvl_to=%d\n",
> > +   "filename='%s', volume='%s', nlvl_from=%d, 
> > nlvl_to=%d, "
> > +   "url : len=%d, location='%s'\n",
>
> %d should be %u
>
> Print null as string is undefined, I'm not sure about the rules of ff

Re: [FFmpeg-devel] [PATCH 3/5] lavf/libkvazaar: export encoded frame stats

2020-08-07 Thread myp...@gmail.com
On Fri, Aug 7, 2020 at 11:16 AM Andreas Rheinhardt
 wrote:
>
> myp...@gmail.com:
> > On Sun, Jul 26, 2020 at 8:45 PM Jun Zhao  wrote:
> >>
> >> From: Jun Zhao 
> >>
> >> Export choosen pict_type and qp.
> >>
> >> Signed-off-by: Jun Zhao 
> >> ---
> >>  libavcodec/libkvazaar.c | 30 ++
> >>  1 file changed, 30 insertions(+)
> >>
> >> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >> index 71c9c8f..9032547 100644
> >> --- a/libavcodec/libkvazaar.c
> >> +++ b/libavcodec/libkvazaar.c
> >> @@ -37,6 +37,7 @@
> >>
> >>  #include "avcodec.h"
> >>  #include "internal.h"
> >> +#include "packet_internal.h"
> >>
> >>  typedef struct LibkvazaarContext {
> >>  const AVClass *class;
> >> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>  kvz_data_chunk *data_out = NULL;
> >>  uint32_t len_out = 0;
> >>  int retval = 0;
> >> +int pict_type;
> >>
> >>  *got_packet_ptr = 0;
> >>
> >> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>  avpkt->flags |= AV_PKT_FLAG_KEY;
> >>  }
> >>
> >> +switch (frame_info.slice_type) {
> >> +case KVZ_SLICE_I:
> >> +pict_type = AV_PICTURE_TYPE_I;
> >> +break;
> >> +case KVZ_SLICE_P:
> >> +pict_type = AV_PICTURE_TYPE_P;
> >> +break;
> >> +case KVZ_SLICE_B:
> >> +pict_type = AV_PICTURE_TYPE_B;
> >> +break;
> >> +default:
> >> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type 
> >> encountered.\n");
> >> +return AVERROR_EXTERNAL;
> >> +}
> >> +#if FF_API_CODED_FRAME
> >> +FF_DISABLE_DEPRECATION_WARNINGS
> >> +avctx->coded_frame->pict_type = pict_type;
> >> +FF_ENABLE_DEPRECATION_WARNINGS
> >> +#endif
> >> +
> >> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp * 
> >> FF_QP2LAMBDA, NULL, 0, pict_type);
> >> +
> >> +#if FF_API_CODED_FRAME
> >> +FF_DISABLE_DEPRECATION_WARNINGS
> >> +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> >> +FF_ENABLE_DEPRECATION_WARNINGS
> >> +#endif
> >> +
> >>  *got_packet_ptr = 1;
> >>  }
> >>
> >> --
> >> 2.7.4
> >>
> > ping ?
>
> Wrong commit message: It is not lavf. I have no opinion on the actual
> change.
>
fixed the commit message typo in local.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] lavf/libkvazaar: export encoded frame stats

2020-08-06 Thread myp...@gmail.com
On Sun, Jul 26, 2020 at 8:45 PM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Export choosen pict_type and qp.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/libkvazaar.c | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> index 71c9c8f..9032547 100644
> --- a/libavcodec/libkvazaar.c
> +++ b/libavcodec/libkvazaar.c
> @@ -37,6 +37,7 @@
>
>  #include "avcodec.h"
>  #include "internal.h"
> +#include "packet_internal.h"
>
>  typedef struct LibkvazaarContext {
>  const AVClass *class;
> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
>  kvz_data_chunk *data_out = NULL;
>  uint32_t len_out = 0;
>  int retval = 0;
> +int pict_type;
>
>  *got_packet_ptr = 0;
>
> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
>  avpkt->flags |= AV_PKT_FLAG_KEY;
>  }
>
> +switch (frame_info.slice_type) {
> +case KVZ_SLICE_I:
> +pict_type = AV_PICTURE_TYPE_I;
> +break;
> +case KVZ_SLICE_P:
> +pict_type = AV_PICTURE_TYPE_P;
> +break;
> +case KVZ_SLICE_B:
> +pict_type = AV_PICTURE_TYPE_B;
> +break;
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type 
> encountered.\n");
> +return AVERROR_EXTERNAL;
> +}
> +#if FF_API_CODED_FRAME
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->pict_type = pict_type;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
> +
> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp * FF_QP2LAMBDA, 
> NULL, 0, pict_type);
> +
> +#if FF_API_CODED_FRAME
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
> +
>  *got_packet_ptr = 1;
>  }
>
> --
> 2.7.4
>
ping ?
___
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] Increasing the max length of control URI to 2048 characters, as urls of some RTSP streams do exceed this limit.

2020-08-06 Thread myp...@gmail.com
On Thu, Aug 6, 2020 at 11:47 AM Yiğit (Yeet) Uyan
 wrote:
>
> Hey Zhilizhao,
>
> The RTSPState you mentioned is ok, but we need to get the char control_uri
> buffer from 1024 characters to 2048. Some of the long rtsps links are
> getting cut, and cannot play. Can you help getting this patch to the next
> version? The patch does not show up in https://patchwork.ffmpeg.org/ at the
> moment.
>
> *•  **Yiğit (Yeet) Uyan*
> *•*  Smart Home Intelligence | Google Home
> *•*  yigitu...@google.com
>
>
>
> On Wed, Aug 5, 2020 at 7:58 PM zhilizhao  wrote:
>
> >
> >
> > > On Aug 6, 2020, at 10:46 AM, zhilizhao  wrote:
> > >
> > >
> > >
> > >> On Aug 6, 2020, at 6:38 AM, Yiğit (Yeet) Uyan <
> > yigituyan-at-google@ffmpeg.org> wrote:
> > >>
> > >> Hello everyone,
> > >>
> > >> This is the first time for me to send a patch via email. Is this the
> > >> correct format?
> > >>
> > >> I would appreciate it if someone could confirm, and if there is anything
> > >> else I need to do to get it into upcoming releases.
> > >>
> > >> Best,
> > >>
> > >> *•  **Yiğit (Yeet) Uyan*
> > >> *•*  Smart Home Intelligence | Google Home
> > >> *•*  yigitu...@google.com
> > >>
> > >>
> > >>
> > >> On Wed, Aug 5, 2020 at 11:30 AM  wrote:
> > >>
> > >>> From: Yiğit (Yeet) Uyan 
> > >>>
> > >>> Signed-off-by: Yiğit (Yeet) Uyan 
> > >>> ---
> > >>> libavformat/rtsp.h | 2 +-
> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> > >>> index 54a9a30c16..2b37f5b49f 100644
> > >>> --- a/libavformat/rtsp.h
> > >>> +++ b/libavformat/rtsp.h
> > >>> @@ -315,7 +315,7 @@ typedef struct RTSPState {
> > >>>/** some MS RTSP streams contain a URL in the SDP that we need to
> > use
> > >>> * for all subsequent RTSP requests, rather than the input URI; in
> > >>> * other cases, this is a copy of AVFormatContext->filename. */
> > >>> -char control_uri[1024];
> > >>> +char control_uri[2048];
I know 1024 is a hard limitation, but this patch have the same problem if
the length of the Control URL Attribute in RTSP SDP > 2048
___
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] lavc/libopenh264enc: use framerate if available

2020-08-05 Thread myp...@gmail.com
On Wed, Aug 5, 2020 at 4:26 PM Martin Storsjö  wrote:
>
> On Wed, 5 Aug 2020, myp...@gmail.com wrote:
>
> > On Sun, Jul 26, 2020 at 8:26 PM Jun Zhao  wrote:
> >>
> >> From: Jun Zhao 
> >>
> >> Respecting the framerate in the libopenh264enc codec context.
> >>
> >> Both the libx264 and libx264 encoders already contain similar logic
> >> to first check the framerate before falling back to the timebase.
> >>
> >> Signed-off-by: Jun Zhao 
> >> ---
> >>  libavcodec/libopenh264enc.c | 11 ++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> >> index f63aa52..cf48566 100644
> >> --- a/libavcodec/libopenh264enc.c
> >> +++ b/libavcodec/libopenh264enc.c
> >> @@ -156,7 +156,16 @@ static av_cold int svc_encode_init(AVCodecContext 
> >> *avctx)
> >>
> >>  (*s->encoder)->GetDefaultParams(s->encoder, ¶m);
> >>
> >> -param.fMaxFrameRate  = 1/av_q2d(avctx->time_base);
> >> +if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> >> +param.fMaxFrameRate = av_q2d(avctx->framerate);
> >> +} else {
> >> +if (avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
> >> +av_log(avctx, AV_LOG_ERROR,
> >> +   "Could not set framerate for libopenh264enc: integer 
> >> overflow\n");
> >> +return AVERROR(EINVAL);
> >> +}
> >> +param.fMaxFrameRate = 1.0 / av_q2d(avctx->time_base) / 
> >> FFMAX(avctx->ticks_per_frame, 1);
> >> +}
> >>  param.iPicWidth  = avctx->width;
> >>  param.iPicHeight = avctx->height;
> >>  param.iTargetBitrate = avctx->bit_rate > 0 ? 
> >> avctx->bit_rate : TARGET_BITRATE_DEFAULT;
> >> --
> >> 2.7.4
> > ping ?
>
> LGTM
>
> // Martin
Applied and fixed typo in commit message (Both the libx264 and libx264
=> Both the libx264 and libx265), thx
___
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] lavc/libopenh264enc: use framerate if available

2020-08-05 Thread myp...@gmail.com
On Sun, Jul 26, 2020 at 8:26 PM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Respecting the framerate in the libopenh264enc codec context.
>
> Both the libx264 and libx264 encoders already contain similar logic
> to first check the framerate before falling back to the timebase.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/libopenh264enc.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index f63aa52..cf48566 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -156,7 +156,16 @@ static av_cold int svc_encode_init(AVCodecContext *avctx)
>
>  (*s->encoder)->GetDefaultParams(s->encoder, ¶m);
>
> -param.fMaxFrameRate  = 1/av_q2d(avctx->time_base);
> +if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> +param.fMaxFrameRate = av_q2d(avctx->framerate);
> +} else {
> +if (avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Could not set framerate for libopenh264enc: integer 
> overflow\n");
> +return AVERROR(EINVAL);
> +}
> +param.fMaxFrameRate = 1.0 / av_q2d(avctx->time_base) / 
> FFMAX(avctx->ticks_per_frame, 1);
> +}
>  param.iPicWidth  = avctx->width;
>  param.iPicHeight = avctx->height;
>  param.iTargetBitrate = avctx->bit_rate > 0 ? avctx->bit_rate 
> : TARGET_BITRATE_DEFAULT;
> --
> 2.7.4
ping ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 4/4] lavc, doc: add libuavs3d video decoder wrapper

2020-08-04 Thread myp...@gmail.com
 ?

On Mon, Jun 22, 2020 at 9:59 PM  wrote:
>
> From: hwren 
>
> Signed-off-by: hbj 
> Signed-off-by: hwren 
> ---
>  Changelog  |   1 +
>  configure  |   4 +
>  doc/decoders.texi  |  21 +++
>  doc/general.texi   |   8 ++
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libuavs3d.c | 283 +
>  7 files changed, 319 insertions(+)
>  create mode 100644 libavcodec/libuavs3d.c
>
> diff --git a/Changelog b/Changelog
> index a60e7d2eb8..dfd56b3fc6 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest.
>  version :
>  - AudioToolbox output device
>  - MacCaption demuxer
> +- AVS3 video decoder via libuavs3d
>
>
>  version 4.3:
> diff --git a/configure b/configure
> index 7495f35faa..7340bc4a35 100755
> --- a/configure
> +++ b/configure
> @@ -274,6 +274,7 @@ External library support:
>--enable-libtls  enable LibreSSL (via libtls), needed for https 
> support
> if openssl, gnutls or mbedtls is not used [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
> +  --enable-libuavs3d   enable AVS3 decoding via libuavs3d [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
>--enable-libvmaf enable vmaf filter via libvmaf [no]
> @@ -1807,6 +1808,7 @@ EXTERNAL_LIBRARY_LIST="
>  libtesseract
>  libtheora
>  libtwolame
> +libuavs3d
>  libv4l2
>  libvorbis
>  libvpx
> @@ -3242,6 +3244,7 @@ libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
> +libuavs3d_decoder_deps="libuavs3d"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
>  libvorbis_encoder_deps="libvorbis libvorbisenc"
> @@ -6379,6 +6382,7 @@ enabled libtls&& require_pkg_config libtls 
> libtls tls.h tls_configur
>  enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
>   { check_lib libtwolame twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> +enabled libuavs3d && require_pkg_config libuavs3d uavs3d uavs3d.h 
> uavs3d_decode
>  enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
> v4l2_ioctl
>  enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98" 
> vid.stab/libvidstab.h vsMotionDetectInit
>  enabled libvmaf   && require_pkg_config libvmaf "libvmaf >= 1.3.9" 
> libvmaf.h compute_vmaf
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index 9005714e3c..f1a0b3c36e 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -86,6 +86,27 @@ AVS2-P2/IEEE1857.4 video decoder wrapper.
>
>  This decoder allows libavcodec to decode AVS2 streams with davs2 library.
>
> +@c man end VIDEO DECODERS
> +
> +@section libuavs3d
> +
> +AVS3-P2/IEEE1857.10 video decoder.
> +
> +libuavs3d allows libavcodec to decode AVS3 streams.
> +Requires the presence of the libuavs3d headers and library during 
> configuration.
> +You need to explicitly configure the build with @code{--enable-libuavs3d}.
> +
> +@subsection Options
> +
> +The following option is supported by the libuavs3d wrapper.
> +
> +@table @option
> +
> +@item frame_threads
> +Set amount of frame threads to use during decoding. The default value is 0 
> (autodetect).
> +
> +@end table
> +
>  @c man end VIDEO DECODERS
>
>  @chapter Audio Decoders
> diff --git a/doc/general.texi b/doc/general.texi
> index 9b0ee96752..6d673b74e1 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -125,6 +125,14 @@ Go to @url{https://github.com/pkuvcl/davs2} and follow 
> the instructions for
>  installing the library. Then pass @code{--enable-libdavs2} to configure to
>  enable it.
>
> +@section uavs3d
> +
> +FFmpeg can make use of the uavs3d library for AVS3-P2/IEEE1857.10 video 
> decoding.
> +
> +Go to @url{https://github.com/uavs3/uavs3d} and follow the instructions for
> +installing the library. Then pass @code{--enable-libuavs3d} to configure to
> +enable it.
> +
>  @float NOTE
>  libdavs2 is under the GNU Public License Version 2 or later
>  (see @url{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html} for
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f1512779be..491485f3c0 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1026,6 +1026,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += 
> libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
> +OBJS-$(CONFIG_LIBUAVS3D_DECODER)  += libuavs3

Re: [FFmpeg-devel] [PATCH] fate: Update the test references for h264-skip-nokey and h264-skip-noparse after b48397e7b84864f2

2020-08-03 Thread myp...@gmail.com
On Mon, Aug 3, 2020 at 8:00 PM myp...@gmail.com  wrote:
>
> On Mon, Aug 3, 2020 at 2:54 PM Martin Storsjö  wrote:
> >
> > ---
> >  tests/ref/fate/h264-skip-nointra | 86 
> >  tests/ref/fate/h264-skip-nokey   | 86 
> >  2 files changed, 86 insertions(+), 86 deletions(-)
> >
> > diff --git a/tests/ref/fate/h264-skip-nointra 
> > b/tests/ref/fate/h264-skip-nointra
> > index 0259902927..723235ae6f 100644
> > --- a/tests/ref/fate/h264-skip-nointra
> > +++ b/tests/ref/fate/h264-skip-nointra
> > @@ -9,47 +9,47 @@
> >  #sample_rate 1: 48000
> >  #channel_layout 1: 3
> >  #channel_layout_name 1: stereo
> > -1,  0,  0, 1152, 4608, 0x
> > -1,   1152,   1152, 1152, 4608, 0x
> > -1,   2304,   2304, 1152, 4608, 0x
> > -1,   3456,   3456, 1152, 4608, 0x
> > -1,   4608,   4608, 1152, 4608, 0x
> > -1,   5760,   5760, 1152, 4608, 0x
> > -1,   6912,   6912, 1152, 4608, 0x
> > -1,   8064,   8064, 1152, 4608, 0x
> > -1,   9216,   9216, 1152, 4608, 0x
> > -1,  10368,  10368, 1152, 4608, 0x
> > -1,  11520,  11520, 1152, 4608, 0x
> > -1,  12672,  12672, 1152, 4608, 0x
> > -1,  13824,  13824, 1152, 4608, 0x
> > -1,  14976,  14976, 1152, 4608, 0x
> > -1,  16128,  16128, 1152, 4608, 0x
> > -1,  17280,  17280, 1152, 4608, 0x
> > -1,  18432,  18432, 1152, 4608, 0x
> > -1,  19584,  19584, 1152, 4608, 0x
> > -1,  20736,  20736, 1152, 4608, 0x
> > -1,  21888,  21888, 1152, 4608, 0x
> > -1,  23040,  23040, 1152, 4608, 0x
> > -1,  24192,  24192, 1152, 4608, 0x
> > -1,  25344,  25344, 1152, 4608, 0x
> > -1,  26496,  26496, 1152, 4608, 0x
> > -1,  27648,  27648, 1152, 4608, 0x
> > -1,  28800,  28800, 1152, 4608, 0x
> > -1,  29952,  29952, 1152, 4608, 0x
> > -1,  31104,  31104, 1152, 4608, 0x
> > -1,  32256,  32256, 1152, 4608, 0x
> > -1,  33408,  33408, 1152, 4608, 0x
> > -1,  34560,  34560, 1152, 4608, 0x
> > -1,  35712,  35712, 1152, 4608, 0x
> > -1,  36864,  36864, 1152, 4608, 0x
> > -1,  38016,  38016, 1152, 4608, 0x
> > -1,  39168,  39168, 1152, 4608, 0x
> > -1,  40320,  40320, 1152, 4608, 0x
> > -1,  41472,  41472, 1152, 4608, 0x
> > -1,  42624,  42624, 1152, 4608, 0x
> > -1,  43776,  43776, 1152, 4608, 0x
> > -1,  44928,  44928, 1152, 4608, 0x
> > -1,  46080,  46080, 1152, 4608, 0x
> > -1,  47232,  47232, 1152, 4608, 0x
> > -1,  48384,  48384, 1152, 4608, 0x9eca8b7c
> > +1,  0,  0, 1152, 4608, 0xa5e29a68
> > +1,   1152,   1152, 1152, 4608, 0x3738f584
> > +1,   2304,   2304, 1152, 4608, 0xb427c4ed
> > +1,   3456,   3456, 1152, 4608, 0xb9ded8e3
> > +1,   4608,   4608, 1152, 4608, 0x1951d6e4
> > +1,   5760,   5760, 1152, 4608, 0xeeabd125
> > +1,   6912,   6912, 1152, 4608, 0xd845ef87
> > +1,   8064,   8064, 1152, 4608, 0xac99d4e5
> > +1,   9216,   9216, 1152, 4608, 0x187cd4e5
> > +1,  10368,  10368, 1152, 4608, 0xc3c6bcf0
> > +1,  11520,  11520, 1152, 4608, 0xd4bedf1f
> > +1,  12672,  12672, 1152, 4608, 0xf185
> > +1,  13824,  13824, 1152, 4608, 0x487bd4e5
> > +1,  14976,  14976, 1152, 4608, 0x0cfacaea
> > +1,  16128,  16128, 1152, 4608, 0x9432d4e5
> > +1,  17280,  17280, 1152, 4608, 0x9e5dc12d
> > +1,  18432,  18432, 1152, 4608, 0x035ae58c
> > +1,  19584,  19584, 1152, 4608, 0x0db0bef0
> > +1,  

Re: [FFmpeg-devel] [PATCH] fate: Update the test references for h264-skip-nokey and h264-skip-noparse after b48397e7b84864f2

2020-08-03 Thread myp...@gmail.com
On Mon, Aug 3, 2020 at 2:54 PM Martin Storsjö  wrote:
>
> ---
>  tests/ref/fate/h264-skip-nointra | 86 
>  tests/ref/fate/h264-skip-nokey   | 86 
>  2 files changed, 86 insertions(+), 86 deletions(-)
>
> diff --git a/tests/ref/fate/h264-skip-nointra 
> b/tests/ref/fate/h264-skip-nointra
> index 0259902927..723235ae6f 100644
> --- a/tests/ref/fate/h264-skip-nointra
> +++ b/tests/ref/fate/h264-skip-nointra
> @@ -9,47 +9,47 @@
>  #sample_rate 1: 48000
>  #channel_layout 1: 3
>  #channel_layout_name 1: stereo
> -1,  0,  0, 1152, 4608, 0x
> -1,   1152,   1152, 1152, 4608, 0x
> -1,   2304,   2304, 1152, 4608, 0x
> -1,   3456,   3456, 1152, 4608, 0x
> -1,   4608,   4608, 1152, 4608, 0x
> -1,   5760,   5760, 1152, 4608, 0x
> -1,   6912,   6912, 1152, 4608, 0x
> -1,   8064,   8064, 1152, 4608, 0x
> -1,   9216,   9216, 1152, 4608, 0x
> -1,  10368,  10368, 1152, 4608, 0x
> -1,  11520,  11520, 1152, 4608, 0x
> -1,  12672,  12672, 1152, 4608, 0x
> -1,  13824,  13824, 1152, 4608, 0x
> -1,  14976,  14976, 1152, 4608, 0x
> -1,  16128,  16128, 1152, 4608, 0x
> -1,  17280,  17280, 1152, 4608, 0x
> -1,  18432,  18432, 1152, 4608, 0x
> -1,  19584,  19584, 1152, 4608, 0x
> -1,  20736,  20736, 1152, 4608, 0x
> -1,  21888,  21888, 1152, 4608, 0x
> -1,  23040,  23040, 1152, 4608, 0x
> -1,  24192,  24192, 1152, 4608, 0x
> -1,  25344,  25344, 1152, 4608, 0x
> -1,  26496,  26496, 1152, 4608, 0x
> -1,  27648,  27648, 1152, 4608, 0x
> -1,  28800,  28800, 1152, 4608, 0x
> -1,  29952,  29952, 1152, 4608, 0x
> -1,  31104,  31104, 1152, 4608, 0x
> -1,  32256,  32256, 1152, 4608, 0x
> -1,  33408,  33408, 1152, 4608, 0x
> -1,  34560,  34560, 1152, 4608, 0x
> -1,  35712,  35712, 1152, 4608, 0x
> -1,  36864,  36864, 1152, 4608, 0x
> -1,  38016,  38016, 1152, 4608, 0x
> -1,  39168,  39168, 1152, 4608, 0x
> -1,  40320,  40320, 1152, 4608, 0x
> -1,  41472,  41472, 1152, 4608, 0x
> -1,  42624,  42624, 1152, 4608, 0x
> -1,  43776,  43776, 1152, 4608, 0x
> -1,  44928,  44928, 1152, 4608, 0x
> -1,  46080,  46080, 1152, 4608, 0x
> -1,  47232,  47232, 1152, 4608, 0x
> -1,  48384,  48384, 1152, 4608, 0x9eca8b7c
> +1,  0,  0, 1152, 4608, 0xa5e29a68
> +1,   1152,   1152, 1152, 4608, 0x3738f584
> +1,   2304,   2304, 1152, 4608, 0xb427c4ed
> +1,   3456,   3456, 1152, 4608, 0xb9ded8e3
> +1,   4608,   4608, 1152, 4608, 0x1951d6e4
> +1,   5760,   5760, 1152, 4608, 0xeeabd125
> +1,   6912,   6912, 1152, 4608, 0xd845ef87
> +1,   8064,   8064, 1152, 4608, 0xac99d4e5
> +1,   9216,   9216, 1152, 4608, 0x187cd4e5
> +1,  10368,  10368, 1152, 4608, 0xc3c6bcf0
> +1,  11520,  11520, 1152, 4608, 0xd4bedf1f
> +1,  12672,  12672, 1152, 4608, 0xf185
> +1,  13824,  13824, 1152, 4608, 0x487bd4e5
> +1,  14976,  14976, 1152, 4608, 0x0cfacaea
> +1,  16128,  16128, 1152, 4608, 0x9432d4e5
> +1,  17280,  17280, 1152, 4608, 0x9e5dc12d
> +1,  18432,  18432, 1152, 4608, 0x035ae58c
> +1,  19584,  19584, 1152, 4608, 0x0db0bef0
> +1,  20736,  20736, 1152, 4608, 0x081fd4e5
> +1,  21888,  21888, 1152, 4608, 0x4ad4d6e3
> +1,  23040,  23040, 1152, 4608, 0xa79dd325
> +1,  24192,  24192, 1152, 4608, 0x6c77fb81
> +1,  25344,  25344, 1152, 4608, 0xed25d2e5
> +1,  26496,  26496, 1152, 4608, 0x9b94c2ee
> +1,  27648,  27648, 1152, 4608, 0x9a3ad0e7
> +1,  28800,  28800, 1152, 4608, 0x0f6dcd27
> +1,  29952,  29952, 1152, 4608, 0xa72fe58c
> +1,  31104,  31104, 1152, 4608, 0x5950c2ee
> +1,  32256,  32256, 1152, 4608, 0x7006d6e4
> +1,  33408,  33408,   

Re: [FFmpeg-devel] [PATCH 1/2] lavc/aac_ac3_parser: fix the potential overflow

2020-07-30 Thread myp...@gmail.com
On Fri, Jul 31, 2020 at 3:47 AM Alexander Strasser  wrote:
>
> On 2020-07-30 21:18 +0800, myp...@gmail.com wrote:
> >
> > After repeated thinking, I can accept this solution, thx
>
> Just to avoid confusion. You accept this
>
> > > > > avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;
>
This part  for potential overflow :)
> or this
>
> > > If you are aiming for improving accuracy, I guess going for
> > > implementing the sum of bitrates is the most straight forward
> > > way. It wouldn't need floating point arithmetic and overflow
> > > wouldn't be much of a concern if I'm not mistaken.
>
> solution?
>
>
> Thanks,
>   Alexander
> ___
> 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".



-- 
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavc/aac_ac3_parser: fix the potential overflow

2020-07-30 Thread myp...@gmail.com
On Sat, Jul 25, 2020 at 3:21 AM Alexander Strasser  wrote:
>
> On 2020-07-24 19:56 +0800, zhilizhao wrote:
> >
> >
> > > On Jul 24, 2020, at 9:40 AM, myp...@gmail.com wrote:
> > >
> > > On Fri, Jul 24, 2020 at 4:43 AM Alexander Strasser  > > <mailto:eclip...@gmx.net>> wrote:
> > >>
> > >> On 2020-07-01 21:05 +0200, Alexander Strasser wrote:
> > >>> On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> > >>>> Quoting Jun Zhao (2020-06-29 15:23:10)
> > >>>>> From: Jun Zhao 
> > >>>>>
> > >>>>> Fix the potential overflow.
> > >>>>>
> > >>>>> Suggested-by: Alexander Strasser 
> > >>>>> Signed-off-by: Jun Zhao 
> > >>>>> ---
> > >>>>> libavcodec/aac_ac3_parser.c | 9 +
> > >>>>> libavcodec/aac_ac3_parser.h | 4 ++--
> > >>>>> tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> > >>>>> 3 files changed, 8 insertions(+), 7 deletions(-)
> > >>>>>
> > >>>>> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> > >>>>> index 0746798..b26790d 100644
> > >>>>> --- a/libavcodec/aac_ac3_parser.c
> > >>>>> +++ b/libavcodec/aac_ac3_parser.c
> > >>>>> @@ -98,11 +98,12 @@ get_next:
> > >>>>> }
> > >>>>>
> > >>>>> /* Calculate the average bit rate */
> > >>>>> -s->frame_number++;
> > >>>>> if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> > >>>>> -avctx->bit_rate =
> > >>>>> -(s->last_bit_rate * (s->frame_number -1) + 
> > >>>>> s->bit_rate)/s->frame_number;
> > >>>>> -s->last_bit_rate = avctx->bit_rate;
> > >>>>> +if (s->frame_number < UINT64_MAX) {
> > >>>>> +s->frame_number++;
> > >>>>> +s->last_bit_rate += (s->bit_rate - 
> > >>>>> s->last_bit_rate)/s->frame_number;
> > >>>>> +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> > >>>>> +}
> > >>>>> }
> > >>>>> }
> > >>>>>
> > >>>>> diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> > >>>>> index b04041f..c53d16f 100644
> > >>>>> --- a/libavcodec/aac_ac3_parser.h
> > >>>>> +++ b/libavcodec/aac_ac3_parser.h
> > >>>>> @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> > >>>>> uint64_t state;
> > >>>>>
> > >>>>> int need_next_header;
> > >>>>> -int frame_number;
> > >>>>> -int last_bit_rate;
> > >>>>> +uint64_t frame_number;
> > >>>>> +double last_bit_rate;
> > >>>>
> > >>>> This won't give the same result on all platforms anymore.
> > >>>
> > >>> It's also a bit different from what I had in mind.
> > >>>
> > >>> I was thinking more in the line of how it's implemented in
> > >>> libavcodec/mpegaudio_parser.c .
> > >>>
> > >>> There is a bit of noise there because of data that doesn't contain audio
> > >>> and also for the CBR case I think. Wouldn't be needed here AFAICT.
> > >>>
> > >>> I may well be missing something. If so understanding more would help me
> > >>> and we could fix both places. Otherwise if it's OK like it was done in
> > >>> mpegaudio_parser, we could maybe use the same strategy here too.
> > >>>
> > >>>
> > >>> Thanks for sending the patch and sorry for the delayed response.
> > >>
> > >> I meant like this:
> > >>
> > >>avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;
> > >>
> > >> Patch attached. What do you think?
> > >>
> > >> Would probably be even better to sum up in an uint64_t and divide
> > >> that sum to update the bit_rate field in AVCodecContext. C

Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter

2020-07-30 Thread myp...@gmail.com
On Thu, Jul 30, 2020 at 5:15 PM myp...@gmail.com  wrote:
>
> On Thu, Jul 30, 2020 at 5:12 PM Nicolas George  wrote:
> >
> > zongwave (12020-07-31):
> > > From: Yinhang Liu 
> > >
> > > xcam filter is a wrapper of libxcam project which supports 360 video 
> > > stitching,
> > > automotive surround view stitching, digital video stabilization (DVS),
> > > Wide dynamic range (WDR), wavelet noise reduction, 3D noise reduction, 
> > > etc.
> >
> > Hi. Thanks for the patch. But it seems to have been generated in a
> > strange way, with double insertion marks. Did you commit your changes
> > and then use git format-patch or git send-email?
> >
> > Regards,
> >
> > --
> >   Nicolas George
>
> The other thing is, I found libxcam (https://github.com/intel/libxcam)
> depend on a lot of 3rd libs
> "
> If --enable-gst, need install libgstreamer1.0-dev,
> libgstreamer-plugins-base1.0-dev
> If --enable-aiq, need get ia_imaging lib which we don't support
> If --enable-libcl, need compile or install OpenCL driver
> If --enable-opencv, suggest OpenCV versions [3.0.0 - 4.0.0) (or: OpenCV Wiki)
> If --enable-render, need compile OpenSceneGraph library with configure
> option "-DOSG_WINDOWING_SYSTEM=X11"
> If --enable-gles, need to install Mesa3D library
> If --enable-vulkan, need to install Mesa3D library
> If --enable-avx512, need to install GCC version > 4.9 ( CPUs With
> AVX-512 required)
> If --enable-dnn, need to compile OpenVino inference-engine
> If --enable-json, need to install json.hpp
> "
> Is it a good idea to wrap a lib like this in AVFilter?

My confusion is, where is the boundary of FFmpeg?
in my personal opinion, libxcam is not a self-contained library.
___
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_xcam: add xcam video filter

2020-07-30 Thread myp...@gmail.com
On Thu, Jul 30, 2020 at 5:12 PM Nicolas George  wrote:
>
> zongwave (12020-07-31):
> > From: Yinhang Liu 
> >
> > xcam filter is a wrapper of libxcam project which supports 360 video 
> > stitching,
> > automotive surround view stitching, digital video stabilization (DVS),
> > Wide dynamic range (WDR), wavelet noise reduction, 3D noise reduction, etc.
>
> Hi. Thanks for the patch. But it seems to have been generated in a
> strange way, with double insertion marks. Did you commit your changes
> and then use git format-patch or git send-email?
>
> Regards,
>
> --
>   Nicolas George

The other thing is, I found libxcam (https://github.com/intel/libxcam)
depend on a lot of 3rd libs
"
If --enable-gst, need install libgstreamer1.0-dev,
libgstreamer-plugins-base1.0-dev
If --enable-aiq, need get ia_imaging lib which we don't support
If --enable-libcl, need compile or install OpenCL driver
If --enable-opencv, suggest OpenCV versions [3.0.0 - 4.0.0) (or: OpenCV Wiki)
If --enable-render, need compile OpenSceneGraph library with configure
option "-DOSG_WINDOWING_SYSTEM=X11"
If --enable-gles, need to install Mesa3D library
If --enable-vulkan, need to install Mesa3D library
If --enable-avx512, need to install GCC version > 4.9 ( CPUs With
AVX-512 required)
If --enable-dnn, need to compile OpenVino inference-engine
If --enable-json, need to install json.hpp
"
Is it a good idea to wrap a lib like this in AVFilter?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-07-27 Thread myp...@gmail.com
On Mon, Jul 27, 2020 at 7:37 PM myp...@gmail.com  wrote:
>
> On Sat, Jul 18, 2020 at 8:31 PM myp...@gmail.com  wrote:
> >
> > On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com  wrote:
> > >
> > > On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick  wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > > > > Maybe I give an inaccurate description in the commit message, in fact,
> > > > > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> > > > > lead to FFmpeg build fail when using libsrt  version >= 1.4.1
> > > >
> > > > I don't mind you description. Yet your code change references 1.4.1:
> > > > SRT_VERSION_VALUE >= 0x010401
> > > > while I am trying to make the point that 1.4.0 also needs this change
> > > > (or 1.3.0 in one case, which is already ensured by #if).
> > > >
> > >
> > > After double-check, I think the patch is Ok, in fact, libsrt keeps the
> > > deprecated SRTO_STRICTENC/SRTO_SMOOTHER options in srt.h (inclued the
> > > options in libsrt 1.3.3/1.3.4/1.4.0) until commit
> > > 0e2201aff6b379979cec43fee5e8f162717f6346 , so FFmpeg build with libsrt
> > > 1.3.3/1.3.4/1.4.0 is OK with the patch.
> > Ping
> I'll apply it tomorrow if don't object, thx
Pushed, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-07-27 Thread myp...@gmail.com
On Sat, Jul 18, 2020 at 8:31 PM myp...@gmail.com  wrote:
>
> On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com  wrote:
> >
> > On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick  wrote:
> > >
> > > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > > > Maybe I give an inaccurate description in the commit message, in fact,
> > > > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> > > > lead to FFmpeg build fail when using libsrt  version >= 1.4.1
> > >
> > > I don't mind you description. Yet your code change references 1.4.1:
> > > SRT_VERSION_VALUE >= 0x010401
> > > while I am trying to make the point that 1.4.0 also needs this change
> > > (or 1.3.0 in one case, which is already ensured by #if).
> > >
> >
> > After double-check, I think the patch is Ok, in fact, libsrt keeps the
> > deprecated SRTO_STRICTENC/SRTO_SMOOTHER options in srt.h (inclued the
> > options in libsrt 1.3.3/1.3.4/1.4.0) until commit
> > 0e2201aff6b379979cec43fee5e8f162717f6346 , so FFmpeg build with libsrt
> > 1.3.3/1.3.4/1.4.0 is OK with the patch.
> Ping
I'll apply it tomorrow if don't object, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavc/aac_ac3_parser: fix the potential overflow

2020-07-23 Thread myp...@gmail.com
On Fri, Jul 24, 2020 at 4:43 AM Alexander Strasser  wrote:
>
> On 2020-07-01 21:05 +0200, Alexander Strasser wrote:
> > On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> > > Quoting Jun Zhao (2020-06-29 15:23:10)
> > > > From: Jun Zhao 
> > > >
> > > > Fix the potential overflow.
> > > >
> > > > Suggested-by: Alexander Strasser 
> > > > Signed-off-by: Jun Zhao 
> > > > ---
> > > >  libavcodec/aac_ac3_parser.c | 9 +
> > > >  libavcodec/aac_ac3_parser.h | 4 ++--
> > > >  tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> > > >  3 files changed, 8 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> > > > index 0746798..b26790d 100644
> > > > --- a/libavcodec/aac_ac3_parser.c
> > > > +++ b/libavcodec/aac_ac3_parser.c
> > > > @@ -98,11 +98,12 @@ get_next:
> > > >  }
> > > >
> > > >  /* Calculate the average bit rate */
> > > > -s->frame_number++;
> > > >  if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> > > > -avctx->bit_rate =
> > > > -(s->last_bit_rate * (s->frame_number -1) + 
> > > > s->bit_rate)/s->frame_number;
> > > > -s->last_bit_rate = avctx->bit_rate;
> > > > +if (s->frame_number < UINT64_MAX) {
> > > > +s->frame_number++;
> > > > +s->last_bit_rate += (s->bit_rate - 
> > > > s->last_bit_rate)/s->frame_number;
> > > > +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> > > > +}
> > > >  }
> > > >  }
> > > >
> > > > diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> > > > index b04041f..c53d16f 100644
> > > > --- a/libavcodec/aac_ac3_parser.h
> > > > +++ b/libavcodec/aac_ac3_parser.h
> > > > @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> > > >  uint64_t state;
> > > >
> > > >  int need_next_header;
> > > > -int frame_number;
> > > > -int last_bit_rate;
> > > > +uint64_t frame_number;
> > > > +double last_bit_rate;
> > >
> > > This won't give the same result on all platforms anymore.
> >
> > It's also a bit different from what I had in mind.
> >
> > I was thinking more in the line of how it's implemented in
> > libavcodec/mpegaudio_parser.c .
> >
> > There is a bit of noise there because of data that doesn't contain audio
> > and also for the CBR case I think. Wouldn't be needed here AFAICT.
> >
> > I may well be missing something. If so understanding more would help me
> > and we could fix both places. Otherwise if it's OK like it was done in
> > mpegaudio_parser, we could maybe use the same strategy here too.
> >
> >
> > Thanks for sending the patch and sorry for the delayed response.
>
> I meant like this:
>
> avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;
>
> Patch attached. What do you think?
>
> Would probably be even better to sum up in an uint64_t and divide
> that sum to update the bit_rate field in AVCodecContext. Could be
> implemented later for both parsers if it's considered worthwhile.
>
I see, my concern is

avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;

will lose precision in (s->bit_rate - avctx->bit_rate) /
s->frame_number, this is the reason I used the  double replace
uint64_t

I can give an example of you code, suppose we probe 4 ADTS AAC frames,
the s->bit_rate is 4Kbps 3Kbps 2Kbps 1Kbps respectively,

In this code, we will always get the bitrate 4Kbps, but in an ideal
situation, we want to get the average bitrate be close to  (4 + 3 + 2
+ 1) / 4 = 2.5Kbps after the probe
___
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] lavf/hls: enable custom interrup callback in sub-demuxer

2020-07-20 Thread myp...@gmail.com
On Mon, Jul 20, 2020 at 10:18 AM Steven Liu  wrote:
>
> Jun Zhao  于2020年7月18日周六 下午7:56写道:
> >
> > From: Jun Zhao 
> >
> > Enable the custom callback in sub-demuxer
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/hls.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index ba17c4e..cf0b71d 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1984,6 +1984,7 @@ static int hls_read_header(AVFormatContext *s)
> >read_data, NULL, NULL);
> >  pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
> >  pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ? 
> > s->max_analyze_duration : 4 * AV_TIME_BASE;
> > +pls->ctx->interrupt_callback = s->interrupt_callback;
> >  url = av_strdup(pls->segments[0]->url);
> >  ret = av_probe_input_buffer(&pls->pb, &in_fmt, url, NULL, 0, 0);
> >  av_free(url);
> > --
> > 2.7.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".
>
>
> LGTM
>
Pushed, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] lavf/dashdec: enable custom interrup callback in sub-demuxer

2020-07-20 Thread myp...@gmail.com
On Mon, Jul 20, 2020 at 10:18 AM Steven Liu  wrote:
>
> Jun Zhao  于2020年7月18日周六 下午8:19写道:
> >
> > From: Jun Zhao 
> >
> > Enable the custom callback in sub-demuxer
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/dashdec.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index 694782c..c5a5ff6 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -1943,6 +1943,7 @@ static int reopen_demux_for_component(AVFormatContext 
> > *s, struct representation
> >  pls->ctx->flags = AVFMT_FLAG_CUSTOM_IO;
> >  pls->ctx->probesize = s->probesize > 0 ? s->probesize : 1024 * 4;
> >  pls->ctx->max_analyze_duration = s->max_analyze_duration > 0 ? 
> > s->max_analyze_duration : 4 * AV_TIME_BASE;
> > +pls->ctx->interrupt_callback = s->interrupt_callback;
> >  ret = av_probe_input_buffer(&pls->pb, &in_fmt, "", NULL, 0, 0);
> >  if (ret < 0) {
> >  av_log(s, AV_LOG_ERROR, "Error when loading first fragment, 
> > playlist %d\n", (int)pls->rep_idx);
> > --
> > 2.7.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".
>
> LGTM
>
Pushed, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] doc/http: Update HTTP protocol options

2020-07-19 Thread myp...@gmail.com
On Sat, Jul 18, 2020 at 11:34 PM Gyan Doshi  wrote:
>
>
>
> On 18-07-2020 05:26 pm, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > remove the timeout option docs part for HTTP protocol and add
> > auth_type option part.
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >   doc/protocols.texi | 27 ++-
> >   1 file changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index 64ad3f0..7b3df96 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -392,11 +392,6 @@ string describing the libavformat build. 
> > ("Lavf/")
> >   @item user-agent
> >   This is a deprecated option, you can use user_agent instead it.
> >
> > -@item timeout
> > -Set timeout in microseconds of socket I/O operations used by the 
> > underlying low level
> > -operation. By default it is set to -1, which means that the timeout is
> > -not specified.
> > -
> >   @item reconnect_at_eof
> >   If set then eof is treated like an error and causes reconnection, this is 
> > useful
> >   for live / endless streams.
> > @@ -481,6 +476,28 @@ Send an Expect: 100-continue header for POST. If set 
> > to 1 it will send, if set
> >   to 0 it won't, if set to -1 it will try to send if it is applicable. 
> > Default
> >   value is -1.
> >
> > +@item auth_type
> > +
> > +Set HTTP authentication type. No option for Digest, since this method 
> > requires
> > +getting nonce parameters from the server first and can't be used straight 
> > away like
> > +Basic.
> > +
> > +@table @option
> > +@item none
> > +Choose the HTTP authentication type automatically. This is the default.
> > +@item basic
> > +
> > +Choose the HTTP basic authentication.
> > +
> > +Basic authentication sends a Base64-encoded string that contains a user 
> > name and password
> > +for the client. Base64 is not a form of encryption and should be 
> > considered the same as
> > +sending the user name and password in clear text (Base64 is a reversible 
> > encoding).
> > +If a resource needs to be protected, strongly consider using an 
> > authentication scheme
> > +other than basic authentication. HTTPS/TLS should be used with basic 
> > authentication.
> > +Without these additional security enhancements, basic authentication 
> > should not be used
> > +to protect sensitive or valuable information.
> > +@end table
> > +
> >   @end table
> >
> >   @subsection HTTP Cookies
>
> LGTM.
>
Pused, thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-07-18 Thread myp...@gmail.com
On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com  wrote:
>
> On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick  wrote:
> >
> > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > > Maybe I give an inaccurate description in the commit message, in fact,
> > > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> > > lead to FFmpeg build fail when using libsrt  version >= 1.4.1
> >
> > I don't mind you description. Yet your code change references 1.4.1:
> > SRT_VERSION_VALUE >= 0x010401
> > while I am trying to make the point that 1.4.0 also needs this change
> > (or 1.3.0 in one case, which is already ensured by #if).
> >
>
> After double-check, I think the patch is Ok, in fact, libsrt keeps the
> deprecated SRTO_STRICTENC/SRTO_SMOOTHER options in srt.h (inclued the
> options in libsrt 1.3.3/1.3.4/1.4.0) until commit
> 0e2201aff6b379979cec43fee5e8f162717f6346 , so FFmpeg build with libsrt
> 1.3.3/1.3.4/1.4.0 is OK with the patch.
Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavf/srt: fix build fail when used the libsrt 1.4.1

2020-07-15 Thread myp...@gmail.com
On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick  wrote:
>
> On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > Maybe I give an inaccurate description in the commit message, in fact,
> > libsrt 1.4.1 remove the SRTO_STRICTENC/SRTO_SMOOTHER option, it's will
> > lead to FFmpeg build fail when using libsrt  version >= 1.4.1
>
> I don't mind you description. Yet your code change references 1.4.1:
> SRT_VERSION_VALUE >= 0x010401
> while I am trying to make the point that 1.4.0 also needs this change
> (or 1.3.0 in one case, which is already ensured by #if).
>

After double-check, I think the patch is Ok, in fact, libsrt keeps the
deprecated SRTO_STRICTENC/SRTO_SMOOTHER options in srt.h (inclued the
options in libsrt 1.3.3/1.3.4/1.4.0) until commit
0e2201aff6b379979cec43fee5e8f162717f6346 , so FFmpeg build with libsrt
1.3.3/1.3.4/1.4.0 is OK with the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

  1   2   3   4   5   6   >