date:20181205

[FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

2018-12-05 Thread Karthick J

---
 doc/muxers.texi  |  4 
 libavformat/movenc.c | 12 ++--
 libavformat/movenc.h |  1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
 pair for each track, making it easier to separate tracks.
 
 This option is implicitly set when writing ismv (Smooth Streaming) files.
+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored. 
 @item -movflags faststart
 Run a second pass moving the index (moov atom) to the beginning of the file.
 This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..28cf8b719c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
 { "frag_discont", "Signal that the next fragment is discontinuous from 
earlier ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "delay_moov", "Delay writing the initial moov until the first fragment 
is cut, or until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_colr", "Write colr atom (Experimental, may be renamed or changed, 
do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
 mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
 moof_size = ffio_close_null_buf(avio_buf);
 
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))
+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_SKIP_SIDX)))
 mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
 
 if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)
@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
  * the next fragment. This means the cts of the first sample must
  * be the same in all fragments, unless end_pts was updated by
  * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||
 mov->mode == MODE_ISM)
 pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
 } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
 s->flags &= ~AVFMT_FLAG_AUTO_BSF;
 }
 
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && mov->flags & 
FF_MOV_FLAG_SKIP_SIDX) {
+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+mov->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+
 if (mov->flags & FF_MOV_FLAG_FASTSTART) {
 mov->reserved_moov_size = -1;
 }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
 #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
 #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
 #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
 
 int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
 
-- 
2.17.1 (Apple Git-112)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/movenc: Added an option to disable SIDX atom

2018-12-05 Thread Tobias Rapp


On 06.12.2018 06:07, Karthick J wrote:

---
  doc/muxers.texi  |  4 
  libavformat/movenc.c | 12 ++--
  libavformat/movenc.h |  1 +
  3 files changed, 15 insertions(+), 2 deletions(-)

[...]
  
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)

  s->flags &= ~AVFMT_FLAG_AUTO_BSF;
  }
  
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & FF_MOV_FLAG_SKIP_SIDX) {

+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+mov->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+


There is still one use of s->flags instead of mov->flags, that should be 
changed.



  if (mov->flags & FF_MOV_FLAG_FASTSTART) {
  mov->reserved_moov_size = -1;
  }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
  #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
  #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
  #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
  
  int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
  



Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding

2018-12-05 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Thursday, December 06, 2018 1:57 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Guo, Yejun
> > Sent: Wednesday, December 5, 2018 5:59 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
> >
> > this patch is not ask for merge, it is more to get a feature feedback.
> >
> > The encoders such as libx264 support different QPs offset for
> > different MBs, it makes possible for ROI-based encoding. It makes
> > sense to add support within ffmpeg to generate/accept ROI infos and pass
> into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > code generates ROI info for that frame, and the encoder finally does
> > the ROI-based encoding. And so I choose to maintain the ROI info
> > within AVFrame struct.
> >
> > TODO:
> > - remove code in vf_scale.c, it is just an example to generate ROI
> > info
> > - use AVBufferRef instead of current implementation within AVFrame
> struct.
> > - add other encoders support
> >
> > Signed-off-by: Guo, Yejun 
> > ---
> >  libavcodec/libx264.c   | 35 +++
> >  libavfilter/vf_scale.c |  8 
> >  libavutil/frame.c  |  9 +
> >  libavutil/frame.h  | 14 ++
> >  4 files changed, 66 insertions(+)
> >
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index
> > a68d0a7..d8cc327 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -26,6 +26,7 @@
> >  #include "libavutil/pixdesc.h"
> >  #include "libavutil/stereo3d.h"
> >  #include "libavutil/intreadwrite.h"
> > +#include "libavutil/avassert.h"
> >  #include "avcodec.h"
> >  #include "internal.h"
> >
> > @@ -345,6 +346,40 @@ static int X264_frame(AVCodecContext *ctx,
> > AVPacket *pkt, const AVFrame *frame,
> >  }
> >  }
> >  }
> > +
> > +if (frame->nb_rois > 0) {
> > +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> > +av_log(ctx, AV_LOG_ERROR, "Adaptive quantization
> > must be enabled to use ROI encoding, skipping ROI.\n");
> > +}
> > +if (frame->interlaced_frame == 0) {
> > +const static int MBSIZE = 16;
> > +size_t mbx = (frame->width + MBSIZE - 1) / MBSIZE;
> > +size_t mby = (frame->height + MBSIZE - 1) / MBSIZE;
> 
> > +float* qoffsets = (float*)av_malloc(sizeof(float) *
> > + mbx *
> > mby);
> > +memset(qoffsets, 0, sizeof(float) * mbx * mby);
> > +
> > +for (size_t roi = 0; roi < frame->nb_rois; ++roi) {
> > +int starty = FFMIN(mby, frame->rois[roi].top /
> > MBSIZE);
> > +int endy = FFMIN(mby, (frame->rois[roi].bottom +
> > MBSIZE - 1)/ MBSIZE);
> > +int startx = FFMIN(mbx, frame->rois[roi].left /
> > MBSIZE);
> > +int endx = FFMIN(mbx, (frame->rois[roi].right +
> > MBSIZE - 1)/ MBSIZE);
> > +for (int y = starty; y < endy; ++y) {
> > +for (int x = startx; x < endx; ++x) {
> > +qoffsets[x + y*mbx] =
> > frame->rois[roi].qoffset;
> > +}
> > +}
> > +}
> > +
> > +x4->pic.prop.quant_offsets = qoffsets;
> > +x4->pic.prop.quant_offsets_free = av_free;
> > +} else {
> > +av_log(ctx, AV_LOG_ERROR, "interlaced_frame not
> > supported for ROI encoding, skipping ROI.\n");
> > +}
> > +} else {
> > +//to be removed in the final code, it is just for debug
> > + usage
> > now.
> > +printf("ops, frame 0x%p with rois %ld\n", frame,
> > frame->nb_rois);
> > +av_assert0(!"should not reach here");
> > +}
> >  }
> >
> >  do {
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index
> > f741419..71def72 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -437,6 +437,14 @@ static int filter_frame(AVFilterLink *link,
> > AVFrame
> > *in)
> >  return ret;
> >  }
> >
> > +// to be removed, just for debug usage temporarily
> > +in->nb_rois = 1;
> > +in->rois[0].top = 0;
> > +in->rois[0].left = 0;
> > +in->rois[0].bottom = in->height;
> > +in->rois[0].right = in->width/2;
> > +in->rois[0].qoffset = 15.0f; // 15.0f, +-5.0f, +-25.0f
> > +
> >  if (!scale->sws)
> >  return ff_filter_frame(outlink, in);
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c index
> > 9b3fb13..9c38bdd
> > 100644
> > --- a/libavutil/frame.c
> > +++

Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding

2018-12-05 Thread Li, Zhong

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Guo, Yejun
> Sent: Wednesday, December 5, 2018 5:59 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
> 
> this patch is not ask for merge, it is more to get a feature feedback.
> 
> The encoders such as libx264 support different QPs offset for different MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
> 
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding. And so I choose to maintain the ROI info within
> AVFrame struct.
> 
> TODO:
> - remove code in vf_scale.c, it is just an example to generate ROI info
> - use AVBufferRef instead of current implementation within AVFrame struct.
> - add other encoders support
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libx264.c   | 35 +++
>  libavfilter/vf_scale.c |  8 
>  libavutil/frame.c  |  9 +
>  libavutil/frame.h  | 14 ++
>  4 files changed, 66 insertions(+)
> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index
> a68d0a7..d8cc327 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -26,6 +26,7 @@
>  #include "libavutil/pixdesc.h"
>  #include "libavutil/stereo3d.h"
>  #include "libavutil/intreadwrite.h"
> +#include "libavutil/avassert.h"
>  #include "avcodec.h"
>  #include "internal.h"
> 
> @@ -345,6 +346,40 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
>  }
>  }
>  }
> +
> +if (frame->nb_rois > 0) {
> +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> +av_log(ctx, AV_LOG_ERROR, "Adaptive quantization
> must be enabled to use ROI encoding, skipping ROI.\n");
> +}
> +if (frame->interlaced_frame == 0) {
> +const static int MBSIZE = 16;
> +size_t mbx = (frame->width + MBSIZE - 1) / MBSIZE;
> +size_t mby = (frame->height + MBSIZE - 1) / MBSIZE;

> +float* qoffsets = (float*)av_malloc(sizeof(float) * mbx *
> mby);
> +memset(qoffsets, 0, sizeof(float) * mbx * mby);
> +
> +for (size_t roi = 0; roi < frame->nb_rois; ++roi) {
> +int starty = FFMIN(mby, frame->rois[roi].top /
> MBSIZE);
> +int endy = FFMIN(mby, (frame->rois[roi].bottom +
> MBSIZE - 1)/ MBSIZE);
> +int startx = FFMIN(mbx, frame->rois[roi].left /
> MBSIZE);
> +int endx = FFMIN(mbx, (frame->rois[roi].right +
> MBSIZE - 1)/ MBSIZE);
> +for (int y = starty; y < endy; ++y) {
> +for (int x = startx; x < endx; ++x) {
> +qoffsets[x + y*mbx] =
> frame->rois[roi].qoffset;
> +}
> +}
> +}
> +
> +x4->pic.prop.quant_offsets = qoffsets;
> +x4->pic.prop.quant_offsets_free = av_free;
> +} else {
> +av_log(ctx, AV_LOG_ERROR, "interlaced_frame not
> supported for ROI encoding, skipping ROI.\n");
> +}
> +} else {
> +//to be removed in the final code, it is just for debug usage
> now.
> +printf("ops, frame 0x%p with rois %ld\n", frame,
> frame->nb_rois);
> +av_assert0(!"should not reach here");
> +}
>  }
> 
>  do {
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index
> f741419..71def72 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -437,6 +437,14 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
>  return ret;
>  }
> 
> +// to be removed, just for debug usage temporarily
> +in->nb_rois = 1;
> +in->rois[0].top = 0;
> +in->rois[0].left = 0;
> +in->rois[0].bottom = in->height;
> +in->rois[0].right = in->width/2;
> +in->rois[0].qoffset = 15.0f; // 15.0f, +-5.0f, +-25.0f
> +
>  if (!scale->sws)
>  return ff_filter_frame(outlink, in);
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c index 9b3fb13..9c38bdd
> 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -425,6 +425,15 @@ FF_DISABLE_DEPRECATION_WARNINGS
> FF_ENABLE_DEPRECATION_WARNINGS  #endif
> 
> +dst->nb_rois = src->nb_rois;
> +for (int i = 0; i < dst->nb_rois; ++i) {
> +dst->rois[i].top = src->rois[i].top;
> +dst->rois[i].bottom = src->rois[i].bottom;
> +dst->rois[i].left = src->rois[i].left;
> +dst->rois[i].right = src->rois[i].right;
> +dst->rois[i].qoffset = src->rois[i].qoffset;
> +}
> +
>  av_buffer_unref(>opaque_ref);
>  av_buffer_unref(>private_ref);
>  if (src->opaque_ref)

Re: [FFmpeg-devel] [PATCH v4 8/9] lavc/qsvenc: enable QVBR mode

2018-12-05 Thread Li, Zhong

> From: Li, Zhong
> Sent: Thursday, November 29, 2018 4:29 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [PATCH v4 8/9] lavc/qsvenc: enable QVBR mode
> 
> QVBR mode is to use the variable bitrate control algorithm with constant
> quality.
> mfxExtCodingOption3 should be supported to enable QVBR mode.
> 
> Example usage: ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v
> h264_qsv -global_quality 25 -maxrate 2M test_qvbr.mp4 -v verbose
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc.c | 39 +--
>  libavcodec/qsvenc.h |  7 +--
>  2 files changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> ba74821..2dd41d7 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -136,6 +136,9 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,  #if QSV_HAVE_CO2
>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
>  #endif
> +#if QSV_HAVE_CO3
> +mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> +#endif
> 
>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(info->CodecProfile), info->CodecLevel); @@
> -190,7 +193,12 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> info->ICQQuality, co2->LookAheadDepth);
>  }
>  #endif
> -
> +#if QSV_HAVE_QVBR
> +else if (info->RateControlMethod == MFX_RATECONTROL_QVBR) {
> +av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
> +   co3->QVBRQuality);
> +}
> +#endif
>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16";
> NumRefFrame: %"PRIu16"\n",
> info->NumSlice, info->NumRefFrame);
>  av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n", @@
> -326,7 +334,7 @@ static int select_rc_mode(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  #endif
>  #if QSV_HAVE_ICQ
> -else if (avctx->global_quality > 0) {
> +else if (avctx->global_quality > 0 && !avctx->rc_max_rate) {
>  rc_mode = MFX_RATECONTROL_ICQ;
>  rc_desc = "intelligent constant quality (ICQ)";
>  }
> @@ -341,6 +349,12 @@ static int select_rc_mode(AVCodecContext *avctx,
> QSVEncContext *q)
>  rc_desc = "average variable bitrate (AVBR)";
>  }
>  #endif
> +#if QSV_HAVE_QVBR
> +else if (avctx->global_quality > 0) {
> +rc_mode = MFX_RATECONTROL_QVBR;
> +rc_desc = "constant quality with VBR algorithm (QVBR)";
> +}
> +#endif
>  else {
>  rc_mode = MFX_RATECONTROL_VBR;
>  rc_desc = "variable bitrate (VBR)"; @@ -551,10 +565,17 @@
> static int init_video_param(AVCodecContext *avctx, QSVEncContext *q)
> #if QSV_HAVE_VCM
>  case MFX_RATECONTROL_VCM:
>  #endif
> +#if QSV_HAVE_QVBR
> +case MFX_RATECONTROL_QVBR:
> +#endif
>  q->param.mfx.BufferSizeInKB   = avctx->rc_buffer_size / 8000;
>  q->param.mfx.InitialDelayInKB =
> avctx->rc_initial_buffer_occupancy / 1000;
>  q->param.mfx.TargetKbps   = avctx->bit_rate / 1000;
>  q->param.mfx.MaxKbps  = avctx->rc_max_rate /
> 1000;
> +#if QSV_HAVE_QVBR
> +if (q->param.mfx.RateControlMethod ==
> MFX_RATECONTROL_QVBR)
> +q->extco3.QVBRQuality = avctx->global_quality; #endif
>  break;
>  case MFX_RATECONTROL_CQP:
>  quant = avctx->global_quality / FF_QP2LAMBDA; @@ -699,6
> +720,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  }
>  #endif
>  }
> +#if QSV_HAVE_CO3
> +q->extco3.Header.BufferId  =
> MFX_EXTBUFF_CODING_OPTION3;
> +q->extco3.Header.BufferSz  = sizeof(q->extco3);
> +q->extparam_internal[q->nb_extparam_internal++] =
> (mfxExtBuffer
> +*)>extco3; #endif
>  }
> 
>  if (!check_enc_param(avctx,q)) {
> @@ -753,6 +779,12 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
>  .Header.BufferSz = sizeof(co2),
>  };
>  #endif
> +#if QSV_HAVE_CO3
> +mfxExtCodingOption3 co3 = {
> +.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
> +.Header.BufferSz = sizeof(co3),
> +};
> +#endif
> 
>  mfxExtBuffer *ext_buffers[] = {
>  (mfxExtBuffer*),
> @@ -760,6 +792,9 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)  #if QSV_HAVE_CO2
>  (mfxExtBuffer*),
>  #endif
> +#if QSV_HAVE_CO3
> +(mfxExtBuffer*),
> +#endif
>  };
> 
>  int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO; diff
> --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index c2aa88e..075c86b
> 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -55,7 +55,7 @@
>  #define QSV_HAVE_AVBR   0
>  #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 28)
>  #define QSV_HAVE_VCM0
> -#define QSV_HAVE_QVBR   0
> +#define QSV_HAVE_QVBR   QSV_VERSION_ATLEAST(1, 28)
>  #define QSV_HAVE_MF QSV_VERSION_ATLEAST(1, 25)
>  #endif
> 
> @@ -110,6 +110,9 @@ typedef

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

2018-12-05 Thread Li, Zhong

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Landgraph
> Sent: Thursday, December 6, 2018 4:23 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for
> QSV HEVC default plugin selection on Windows
> 
> Hi All,
> 
> This is my first commit to ffmpeg, what should I do to merge it?
> 
> Do we have any reasons to not merge this?
> 
> Thanks!

Will apply if nobody against now. 

> 23.10.2018 10:14, Li, Zhong пишет:
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Maxym Dmytrychenko
> >> Sent: Sunday, October 14, 2018 3:36 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc:
> >> correction for QSV HEVC default plugin selection on Windows
> >>
> >> On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson  wrote:
> >>
> >>> On 06/10/18 07:21, Landgraph wrote:
>  1. Old logic meaned: everywhere, except Windows, ffmpeg has to use
>  HW
> >>> acceleration, but on Windows ffmpeg has to use (unavailable)
> >>> software encode by default
>  2. Software encode is available only if you provide corresponding
> >>> software MediaSDK library, which isn't provided with ffmpeg. More
> >>> information could be found in
> >>>
> >>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/r
> >> e
> >>> adme-encode_linux.pdf
>  3. HW encode is available on Windows in the driver by default
> >>> This has been proposed before - I can't find the original discussion
> >>> (maybe it was on IRC), but I did find <
> >>>
> >>
> https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html>.
> >>> The reason for not doing it is that a subset of the Intel drivers
> >>> segfault immediately when the hardware plugin is loaded on some
> >>> platforms.  That's a pain for anyone wanting to support diverse
> >>> systems, so the decision was to continue to load the sw plugin by
> >>> default so it doesn't crash (even if the software plugin isn't
> >>> present), and leave the non-default case as the crashing one so the
> >>> user
> >> has to do something to trigger it.
> >>> If you can characterise either the set of platforms it crashes on or
> >>> a set of platforms it definitely works on then maybe we could
> >>> conditionally change the default behaviour?
> >>>
> >>> - Mark
> >>>
> >>>
> >> it was 2 years old discussion and with early drivers (we even had
> >> this development a bit ahead of general driver availability) now it
> >> should be working on most of the platforms - I would suggest to make a
> positive side.
> > Basically, HEVC HW encoding should be the default case if HW platform
> can support.
> > If crashed with some specified drivers, thus should be a driver issue 
> > instead
> of hiding it in ffmpeg level.
> > So, I agree with Maxym and the patch LGTM.
> > (Of course, if we can verified on the platforms which was crashed as
> > two years ago, that should be fine. However, IMHO this is not MUST. If
> > it is still crash, reporting a bug to the driver developer should be
> > the right way.)
> >

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/movenc: Added an option to disable SIDX atom

2018-12-05 Thread Jeyapal, Karthick



On 12/5/18, 6:10 PM, "Tobias Rapp"  wrote:
>
>On 05.12.2018 07:18, Karthick J wrote:
>> [...]   
>> +if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & 
>> FF_MOV_FLAG_SKIP_SIDX) {
>> +av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
>> option\n");
>> +s->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
>> +}
>> +
>
>I guess this should use mov->flags instead of s->flags?
Oops. Sorry about it. Thanks for pointing it out. Have sent PATCH v3 with this 
change.
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237232.html

>
>> [...]
>
>Otherwise changes look fine, but I am not the maintainer of this file.
>
>Regards,
>Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] avformat/movenc: Added an option to disable SIDX atom

2018-12-05 Thread Karthick J

---
 doc/muxers.texi  |  4 
 libavformat/movenc.c | 12 ++--
 libavformat/movenc.h |  1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
 pair for each track, making it easier to separate tracks.
 
 This option is implicitly set when writing ismv (Smooth Streaming) files.
+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored. 
 @item -movflags faststart
 Run a second pass moving the index (moov atom) to the beginning of the file.
 This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..2f7755bf69 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
 { "frag_discont", "Signal that the next fragment is discontinuous from 
earlier ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, 
INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
 { "delay_moov", "Delay writing the initial moov until the first fragment 
is cut, or until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
+{ "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_colr", "Write colr atom (Experimental, may be renamed or changed, 
do not use from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 
= FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
 { "use_metadata_tags", "Use mdta atom for metadata.", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
 mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
 moof_size = ffio_close_null_buf(avio_buf);
 
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX))
+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_SKIP_SIDX)))
 mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
 
 if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)
@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
  * the next fragment. This means the cts of the first sample must
  * be the same in all fragments, unless end_pts was updated by
  * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||
 mov->mode == MODE_ISM)
 pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
 } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
 s->flags &= ~AVFMT_FLAG_AUTO_BSF;
 }
 
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & 
FF_MOV_FLAG_SKIP_SIDX) {
+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+mov->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+
 if (mov->flags & FF_MOV_FLAG_FASTSTART) {
 mov->reserved_moov_size = -1;
 }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
 #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
 #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
 #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
 
 int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
 
-- 
2.17.1 (Apple Git-112)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding

2018-12-05 Thread Guo, Yejun



> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Thursday, December 06, 2018 4:41 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
> 
> On Wed, Dec 05, 2018 at 05:58:58PM +0800, Guo, Yejun wrote:
> > this patch is not ask for merge, it is more to get a feature feedback.
> >
> > The encoders such as libx264 support different QPs offset for
> > different MBs, it makes possible for ROI-based encoding. It makes
> > sense to add support within ffmpeg to generate/accept ROI infos and pass
> into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > code generates ROI info for that frame, and the encoder finally does
> > the ROI-based encoding. And so I choose to maintain the ROI info
> > within AVFrame struct.
> >
> > TODO:
> > - remove code in vf_scale.c, it is just an example to generate ROI
> > info
> > - use AVBufferRef instead of current implementation within AVFrame
> struct.
> > - add other encoders support
> >
> > Signed-off-by: Guo, Yejun 
> > ---
> >  libavcodec/libx264.c   | 35 +++
> >  libavfilter/vf_scale.c |  8 
> >  libavutil/frame.c  |  9 +
> >  libavutil/frame.h  | 14 ++
> >  4 files changed, 66 insertions(+)
> 
> this causes asserion failures
> ./ffmpeg -i matrixbench_mpeg2.mpg  this.mkv
> 
> ...
> 
> ops, frame 0x0x3c03cc0 with rois 0
> Assertion !"should not reach here" failed at libavcodec/libx264.c:381 Aborted
> (core dumped)
> 

The reason is that no one generates the ROI info with this command line.

In this patch, I just borrowed vf_scale to mock the behavior to generate ROI 
info, the qp offset
of the left half video is forced to be 15, and so the left part will be more 
rough with a given bitrate.

And only libx264 encoder is supported now, so the command line looks like:
./ffmpeg  -i  .../path_to_1920x1080_video_file  -vf scale=1920:1080 -c:v 
libx264  -b:v 2000k -y tmp.264

btw, the impact between the left and the right of the video will be more 
obvious if the video is about
a sky with proper bitrates.

> 
> [...]
> --
> Michael GnuPG fingerprint:
> 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> While the State exists there can be no freedom; when there is freedom
> there will be no State. -- Vladimir Lenin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/dvdsubdec: discard accumulated buffer on error

2018-12-05 Thread Michael Niedermayer

Fixes: Timeout
Fixes: 
10992/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DVDSUB_fuzzer-5657495410835456

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvdsubdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 632a53adab..741ea9fd1e 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -595,6 +595,7 @@ static int dvdsub_decode(AVCodecContext *avctx,
 }
 
 if (is_menu < 0) {
+ctx->buf_size = 0;
 no_subtitle:
 reset_rects(sub);
 *data_size = 0;
-- 
2.19.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/clearvideo: Check remaining input bits in P macro block loop

2018-12-05 Thread Michael Niedermayer

Fixes: Timeout
Fixes: 
11083/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CLEARVIDEO_fuzzer-5657180351496192

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/clearvideo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/clearvideo.c b/libavcodec/clearvideo.c
index 0e3c772123..ad3012f7b7 100644
--- a/libavcodec/clearvideo.c
+++ b/libavcodec/clearvideo.c
@@ -570,6 +570,8 @@ static int clv_decode_frame(AVCodecContext *avctx, void 
*data,
 
 for (j = 0; j < c->pmb_height; j++) {
 for (i = 0; i < c->pmb_width; i++) {
+if (get_bits_left(>gb) <= 0)
+return AVERROR_INVALIDDATA;
 if (get_bits1(>gb)) {
 MV mv = mvi_predict(>mvi, i, j, zero_mv);
 
-- 
2.19.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavcodec/zmbvenc.c: don't allow motion estimation out of range.

2018-12-05 Thread matthew . w . fearnley

From: Matthew Fearnley 

The maximum allowable range for ZMBV motion estimation is [-64..63], since
the dx,dy values are each stored in the upper 7 bits of a signed char.

(Previously, the range was capped in the code to 127, resulting in an
effective range of [-127..126])

Also fix a range error in the zmbv_me() for-loops ('<' instead of '<='),
which made the limit asymmetrical [-N..N-1], and also prevented it from
reaching the blocks touching the bottom/right edges.
The range is now more symmetrical [-N..N], although this requires separate
range caps of 64 and 63 for negative and positive dx,dy.

Practically, this patch fixes graphical glitches e.g. when reencoding the
Commander Keen sample video with me_range 65 or higher:

ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi

(Glitches are worse with higher me_range values up to 127.)
---
 libavcodec/zmbvenc.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 4d9147657d..300a53b08e 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -45,7 +45,7 @@
 typedef struct ZmbvEncContext {
 AVCodecContext *avctx;
 
-int range;
+int lrange, urange;
 uint8_t *comp_buf, *work_buf;
 uint8_t pal[768];
 uint32_t pal2[256]; //for quick comparisons
@@ -101,8 +101,8 @@ static int zmbv_me(ZmbvEncContext *c, uint8_t *src, int 
sstride, uint8_t *prev,
 bh = FFMIN(ZMBV_BLOCK, c->avctx->height - y);
 bv = block_cmp(c, src, sstride, prev, pstride, bw, bh, xored);
 if(!bv) return 0;
-for(ty = FFMAX(y - c->range, 0); ty < FFMIN(y + c->range, c->avctx->height 
- bh); ty++){
-for(tx = FFMAX(x - c->range, 0); tx < FFMIN(x + c->range, 
c->avctx->width - bw); tx++){
+for(ty = FFMAX(y - c->lrange, 0); ty <= FFMIN(y + c->urange, 
c->avctx->height - bh); ty++){
+for(tx = FFMAX(x - c->lrange, 0); tx <= FFMIN(x + c->urange, 
c->avctx->width - bw); tx++){
 if(tx == x && ty == y) continue; // we already tested this block
 dx = tx - x;
 dy = ty - y;
@@ -285,9 +285,13 @@ static av_cold int encode_init(AVCodecContext *avctx)
 
 c->curfrm = 0;
 c->keyint = avctx->keyint_min;
-c->range = 8;
-if(avctx->me_range > 0)
-c->range = FFMIN(avctx->me_range, 127);
+
+// Motion estimation range: maximum distance is -64..63
+c->lrange = c->urange = 8;
+if(avctx->me_range > 0){
+c->lrange = FFMIN(avctx->me_range, 64);
+c->urange = FFMIN(avctx->me_range, 63);
+}
 
 if(avctx->compression_level >= 0)
 lvl = avctx->compression_level;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

2018-12-05 Thread Landgraph


Hi All,

This is my first commit to ffmpeg, what should I do to merge it?

Do we have any reasons to not merge this?

Thanks!

23.10.2018 10:14, Li, Zhong пишет:

From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of Maxym Dmytrychenko
Sent: Sunday, October 14, 2018 3:36 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for
QSV HEVC default plugin selection on Windows

On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson  wrote:


On 06/10/18 07:21, Landgraph wrote:

1. Old logic meaned: everywhere, except Windows, ffmpeg has to use
HW

acceleration, but on Windows ffmpeg has to use (unavailable) software
encode by default

2. Software encode is available only if you provide corresponding

software MediaSDK library, which isn't provided with ffmpeg. More
information could be found in


https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/r
e

adme-encode_linux.pdf

3. HW encode is available on Windows in the driver by default

This has been proposed before - I can't find the original discussion
(maybe it was on IRC), but I did find <


https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html>.

The reason for not doing it is that a subset of the Intel drivers
segfault immediately when the hardware plugin is loaded on some
platforms.  That's a pain for anyone wanting to support diverse
systems, so the decision was to continue to load the sw plugin by
default so it doesn't crash (even if the software plugin isn't
present), and leave the non-default case as the crashing one so the user

has to do something to trigger it.

If you can characterise either the set of platforms it crashes on or a
set of platforms it definitely works on then maybe we could
conditionally change the default behaviour?

- Mark



it was 2 years old discussion and with early drivers (we even had this
development a bit ahead of general driver availability) now it should be
working on most of the platforms - I would suggest to make a positive side.

Basically, HEVC HW encoding should be the default case if HW platform can 
support.
If crashed with some specified drivers, thus should be a driver issue instead 
of hiding it in ffmpeg level.
So, I agree with Maxym and the patch LGTM.
(Of course, if we can verified on the platforms which was crashed as two years 
ago,
that should be fine. However, IMHO this is not MUST. If it is still crash, 
reporting a bug to the driver developer should be the right way.)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

2018-12-05 Thread Paul B Mahol

On 12/6/18, Baptiste Coudurier  wrote:
> Hi Paul
>
> On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/mxfenc.c | 49 
>>  1 file changed, 49 insertions(+)
>>
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index 3549b4137d..e481b19ff3 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -146,6 +146,7 @@ enum ULIndex {
>>  INDEX_JPEG2000,
>>  INDEX_H264,
>>  INDEX_S436M,
>> +INDEX_PRORES,
>>  };
>>
>>  static const struct {
>> @@ -159,6 +160,7 @@ static const struct {
>>  { AV_CODEC_ID_DNXHD,  INDEX_DNXHD },
>>  { AV_CODEC_ID_JPEG2000,   INDEX_JPEG2000 },
>>  { AV_CODEC_ID_H264,   INDEX_H264 },
>> +{ AV_CODEC_ID_PRORES, INDEX_PRORES },
>>  { AV_CODEC_ID_NONE }
>>  };
>>
>> @@ -314,6 +316,11 @@ static const MXFContainerEssenceEntry
>> mxf_essence_container_uls[] = {
>>{
>> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
>> },
>>{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x01,0x5C,0x00
>> },
>>mxf_write_s436m_anc_desc },
>> +// ProRes
>> +{ {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x0d,0x01,0x03,0x01,0x02,0x1c,0x01,0x00
>> },
>> +  {
>> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x17,0x00
>> },
>> +  {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
>> },
>> +  mxf_write_cdci_desc },
>>  { {
>> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>> },
>>{
>> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>> },
>>{
>> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
>> },
>> @@ -1945,6 +1952,43 @@ static int mxf_write_partition(AVFormatContext *s,
>> int bodysid,
>>  return 0;
>>  }
>>
>> +static const struct {
>> +int profile;
>> +UID codec_ul;
>> +} mxf_prores_codec_uls[] = {
>> +{ FF_PROFILE_PRORES_PROXY,{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x01,0x00
>> } },
>> +{ FF_PROFILE_PRORES_LT,   {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x02,0x00
>> } },
>> +{ FF_PROFILE_PRORES_STANDARD, {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
>> } },
>> +{ FF_PROFILE_PRORES_HQ,   {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x04,0x00
>> } },
>> +{ FF_PROFILE_PRORES_, {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x05,0x00
>> } },
>> +{ FF_PROFILE_PRORES_XQ,   {
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x06,0x00
>> } },
>> +};
>> +
>> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
>> AVPacket *pkt)
>> +{
>> +MXFContext *mxf = s->priv_data;
>> +MXFStreamContext *sc = st->priv_data;
>> +int i, profile;
>> +
>> +if (mxf->header_written)
>> +return 1;
>> +
>> +sc->codec_ul = NULL;
>> +profile = st->codecpar->profile;
>>
>
> We should fetch the profile from the bitstream.
>

AFAIK profile is not stored in it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

2018-12-05 Thread Paul B Mahol

On 12/6/18, Baptiste Coudurier  wrote:
> Hi Paul
>
> On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/mxfdec.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> index f49890e140..abb030b1a4 100644
>> --- a/libavformat/mxfdec.c
>> +++ b/libavformat/mxfdec.c
>> @@ -2432,6 +2432,18 @@ static int mxf_parse_structural_metadata(MXFContext
>> *mxf)
>>  default:
>>  av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout
>> type: %d\n", descriptor->frame_layout);
>>  }
>> +
>> +if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
>> +switch (descriptor->essence_codec_ul[14]) {
>> +case 1: st->codecpar->profile = FF_PROFILE_PRORES_PROXY;
>>   break;
>> +case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;
>>break;
>> +case 3: st->codecpar->profile =
>> FF_PROFILE_PRORES_STANDARD; break;
>> +case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;
>>break;
>> +case 5: st->codecpar->profile = FF_PROFILE_PRORES_;
>>break;
>> +case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;
>>break;
>> +}
>> +}
>> +
>
>
>  I'm not sure about that, we don't do it for any other codec. IMHO it
> should be in the decoder/parser.

profile is not stored in bitstream AFAIK so only way it is set is via
demuxer via codec_tag.
MXF does not use codec_tags. So only this way is available.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

2018-12-05 Thread Baptiste Coudurier

Hi Paul

On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mxfdec.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index f49890e140..abb030b1a4 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2432,6 +2432,18 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
>  default:
>  av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout
> type: %d\n", descriptor->frame_layout);
>  }
> +
> +if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
> +switch (descriptor->essence_codec_ul[14]) {
> +case 1: st->codecpar->profile = FF_PROFILE_PRORES_PROXY;
>   break;
> +case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;
>break;
> +case 3: st->codecpar->profile =
> FF_PROFILE_PRORES_STANDARD; break;
> +case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;
>break;
> +case 5: st->codecpar->profile = FF_PROFILE_PRORES_;
>break;
> +case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;
>break;
> +}
> +}
> +


 I'm not sure about that, we don't do it for any other codec. IMHO it
should be in the decoder/parser.

-- 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

2018-12-05 Thread Baptiste Coudurier

Hi Paul

On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mxfenc.c | 49 
>  1 file changed, 49 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..e481b19ff3 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -146,6 +146,7 @@ enum ULIndex {
>  INDEX_JPEG2000,
>  INDEX_H264,
>  INDEX_S436M,
> +INDEX_PRORES,
>  };
>
>  static const struct {
> @@ -159,6 +160,7 @@ static const struct {
>  { AV_CODEC_ID_DNXHD,  INDEX_DNXHD },
>  { AV_CODEC_ID_JPEG2000,   INDEX_JPEG2000 },
>  { AV_CODEC_ID_H264,   INDEX_H264 },
> +{ AV_CODEC_ID_PRORES, INDEX_PRORES },
>  { AV_CODEC_ID_NONE }
>  };
>
> @@ -314,6 +316,11 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x01,0x5C,0x00
> },
>mxf_write_s436m_anc_desc },
> +// ProRes
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x0d,0x01,0x03,0x01,0x02,0x1c,0x01,0x00
> },
> +  {
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x17,0x00
> },
> +  {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
> },
> +  mxf_write_cdci_desc },
>  { {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
>{
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
>{
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
> @@ -1945,6 +1952,43 @@ static int mxf_write_partition(AVFormatContext *s,
> int bodysid,
>  return 0;
>  }
>
> +static const struct {
> +int profile;
> +UID codec_ul;
> +} mxf_prores_codec_uls[] = {
> +{ FF_PROFILE_PRORES_PROXY,{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x01,0x00
> } },
> +{ FF_PROFILE_PRORES_LT,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x02,0x00
> } },
> +{ FF_PROFILE_PRORES_STANDARD, {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
> } },
> +{ FF_PROFILE_PRORES_HQ,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x04,0x00
> } },
> +{ FF_PROFILE_PRORES_, {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x05,0x00
> } },
> +{ FF_PROFILE_PRORES_XQ,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x06,0x00
> } },
> +};
> +
> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> AVPacket *pkt)
> +{
> +MXFContext *mxf = s->priv_data;
> +MXFStreamContext *sc = st->priv_data;
> +int i, profile;
> +
> +if (mxf->header_written)
> +return 1;
> +
> +sc->codec_ul = NULL;
> +profile = st->codecpar->profile;
>

We should fetch the profile from the bitstream.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 22:56 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>>> Fixes #4409.
>>>
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/dpx.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>>> index 538a1b9943..04b55ffadf 100644
>>> --- a/libavcodec/dpx.c
>>> +++ b/libavcodec/dpx.c
>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext
>>> *avctx,
>>>  read10in32(, ,
>>> _datum, endian, shift);
>>>  }
>>> -n_datum = 0;
>>> +if (packing != 2)
>>> +n_datum = 0;
>>>  for (i = 0; i < elements; i++)
>>>  ptr[i] += p->linesize[i];
>>>  }
>>
>> This breaks decoding the output of the following command:
>> $ gm convert converted_image_gets_skewed.dpx -define
>> dpx:packing-method=b out.dpx
>
> I do not trust that app, its full of bugs.

 What is the reference for dpx in your opinion?
>>>
>>> ImageTragick certainly not.
>>
>> That's not ImageMagick above.
>
> Then what is it?

 GraphicsMagick which claims to be the dpx reference (afaiu).

>> The sample in question looks better with attached poc, breaks
>> four component sample, also attaching other samples that
>> show the difference.
>
> Attacking crappy patches and non-compliant files that

 Do you know of a 10bit gray dpx sample that does not look
 better with my "crappy" patch?

> conflict and do not follow specification is not productive.

 GraphicsMagick claims differently.
>>>
>>> How sample from ticket #4409 looks with that tool?
>>
>> It fails differently than with your patch.
>>
>
> I have dpx specification,

> and my patch above show correct output for that file.

I am not so sure: Look at the right border with and without my change.

> So I do not know what we are discussing about.
>
> Find actual program that correctly displays sample from above
> ticket and that we can talk again.

It displays correctly with my change, I am not sure if the file
conforms to the dpx specification.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 22:42 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>> Fixes #4409.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dpx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>> index 538a1b9943..04b55ffadf 100644
>> --- a/libavcodec/dpx.c
>> +++ b/libavcodec/dpx.c
>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>  read10in32(, ,
>> _datum, endian, shift);
>>  }
>> -n_datum = 0;
>> +if (packing != 2)
>> +n_datum = 0;
>>  for (i = 0; i < elements; i++)
>>  ptr[i] += p->linesize[i];
>>  }
>
> This breaks decoding the output of the following command:
> $ gm convert converted_image_gets_skewed.dpx -define
> dpx:packing-method=b out.dpx

 I do not trust that app, its full of bugs.
>>>
>>> What is the reference for dpx in your opinion?
>>
>> ImageTragick certainly not.
>
> That's not ImageMagick above.

 Then what is it?
>>>
>>> GraphicsMagick which claims to be the dpx reference (afaiu).
>>>
> The sample in question looks better with attached poc, breaks
> four component sample, also attaching other samples that
> show the difference.

 Attacking crappy patches and non-compliant files that
>>>
>>> Do you know of a 10bit gray dpx sample that does not look
>>> better with my "crappy" patch?
>>>
 conflict and do not follow specification is not productive.
>>>
>>> GraphicsMagick claims differently.
>>
>> How sample from ticket #4409 looks with that tool?
>
> It fails differently than with your patch.
>

I have dpx specification, and my patch above show correct output for that file.
So I do not know what we are discussing about.

Find actual program that correctly displays sample from above ticket
and that we can talk again.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations

2018-12-05 Thread Michael Niedermayer

On Wed, Dec 05, 2018 at 12:15:14AM +0100, Carl Eugen Hoyos wrote:
> 2018-12-04 18:02 GMT+01:00, Michael Niedermayer :
> > On Tue, Dec 04, 2018 at 04:33:03PM +0100, Carl Eugen Hoyos wrote:
> >> 2018-12-04 16:29 GMT+01:00, Michael Niedermayer :
> >> > The affected functions could also be changed into macros, this is the
> >> > smaller change to fix it though. And avoids (probably) less readable
> >> > macros
> >>
> >> > The extra code should be optimized out when optimizations are done as
> >> > all
> >> > values are known at build after inlining.
> >>
> >> Shouldn't this be verified?
> >
> > ive verified it with the patch below
> 
> Thank you!

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 22:42 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
> Fixes #4409.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dpx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 538a1b9943..04b55ffadf 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>  read10in32(, ,
> _datum, endian, shift);
>  }
> -n_datum = 0;
> +if (packing != 2)
> +n_datum = 0;
>  for (i = 0; i < elements; i++)
>  ptr[i] += p->linesize[i];
>  }

 This breaks decoding the output of the following command:
 $ gm convert converted_image_gets_skewed.dpx -define
 dpx:packing-method=b out.dpx
>>>
>>> I do not trust that app, its full of bugs.
>>
>> What is the reference for dpx in your opinion?
>
> ImageTragick certainly not.

 That's not ImageMagick above.
>>>
>>> Then what is it?
>>
>> GraphicsMagick which claims to be the dpx reference (afaiu).
>>
 The sample in question looks better with attached poc, breaks
 four component sample, also attaching other samples that
 show the difference.
>>>
>>> Attacking crappy patches and non-compliant files that
>>
>> Do you know of a 10bit gray dpx sample that does not look
>> better with my "crappy" patch?
>>
>>> conflict and do not follow specification is not productive.
>>
>> GraphicsMagick claims differently.
>
> How sample from ticket #4409 looks with that tool?

It fails differently than with your patch.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
 Fixes #4409.

 Signed-off-by: Paul B Mahol 
 ---
  libavcodec/dpx.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
 index 538a1b9943..04b55ffadf 100644
 --- a/libavcodec/dpx.c
 +++ b/libavcodec/dpx.c
 @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
  read10in32(, ,
 _datum, endian, shift);
  }
 -n_datum = 0;
 +if (packing != 2)
 +n_datum = 0;
  for (i = 0; i < elements; i++)
  ptr[i] += p->linesize[i];
  }
>>>
>>> This breaks decoding the output of the following command:
>>> $ gm convert converted_image_gets_skewed.dpx -define
>>> dpx:packing-method=b out.dpx
>>
>> I do not trust that app, its full of bugs.
>
> What is the reference for dpx in your opinion?

 ImageTragick certainly not.
>>>
>>> That's not ImageMagick above.
>>
>> Then what is it?
>
> GraphicsMagick which claims to be the dpx reference (afaiu).
>
>>> The sample in question looks better with attached poc, breaks
>>> four component sample, also attaching other samples that
>>> show the difference.
>>
>> Attacking crappy patches and non-compliant files that
>
> Do you know of a 10bit gray dpx sample that does not look
> better with my "crappy" patch?
>
>> conflict and do not follow specification is not productive.
>
> GraphicsMagick claims differently.

How sample from ticket #4409 looks with that tool?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 18:58 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos  wrote:
 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>>> Fixes #4409.
>>>
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/dpx.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>>> index 538a1b9943..04b55ffadf 100644
>>> --- a/libavcodec/dpx.c
>>> +++ b/libavcodec/dpx.c
>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>>  read10in32(, ,
>>> _datum, endian, shift);
>>>  }
>>> -n_datum = 0;
>>> +if (packing != 2)
>>> +n_datum = 0;
>>>  for (i = 0; i < elements; i++)
>>>  ptr[i] += p->linesize[i];
>>>  }
>>
>> This breaks decoding the output of the following command:
>> $ gm convert converted_image_gets_skewed.dpx -define
>> dpx:packing-method=b out.dpx
>
> I do not trust that app, its full of bugs.

 What is the reference for dpx in your opinion?
>>>
>>> ImageTragick certainly not.
>>
>> That's not ImageMagick above.
>
> Then what is it?

GraphicsMagick which claims to be the dpx reference (afaiu).

>> The sample in question looks better with attached poc, breaks
>> four component sample, also attaching other samples that
>> show the difference.
>
> Attacking crappy patches and non-compliant files that

Do you know of a 10bit gray dpx sample that does not look
better with my "crappy" patch?

> conflict and do not follow specification is not productive.

GraphicsMagick claims differently.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 19:00 GMT+01:00, Gregor Riepl :
> There seems to be an indentation issue here:

This is intended to allow an actual review.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 21:22 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/proresdec2.c | 51 ++---
>  1 file changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 8581d797fb..80a76bbba1 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -140,32 +140,35 @@ static av_cold int decode_init(AVCodecContext *avctx)
>
>  avctx->bits_per_raw_sample = 10;
>
> -switch (avctx->codec_tag) {

I beg you, please don't reindent.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding

2018-12-05 Thread Michael Niedermayer

On Wed, Dec 05, 2018 at 05:58:58PM +0800, Guo, Yejun wrote:
> this patch is not ask for merge, it is more to get a feature feedback.
> 
> The encoders such as libx264 support different QPs offset for different MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
> 
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding. And so I choose to maintain the ROI info within
> AVFrame struct.
> 
> TODO:
> - remove code in vf_scale.c, it is just an example to generate ROI info
> - use AVBufferRef instead of current implementation within AVFrame struct.
> - add other encoders support
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libx264.c   | 35 +++
>  libavfilter/vf_scale.c |  8 
>  libavutil/frame.c  |  9 +
>  libavutil/frame.h  | 14 ++
>  4 files changed, 66 insertions(+)

this causes asserion failures
./ffmpeg -i matrixbench_mpeg2.mpg  this.mkv

...

ops, frame 0x0x3c03cc0 with rois 0
Assertion !"should not reach here" failed at libavcodec/libx264.c:381
Aborted (core dumped)


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavcodec/proresdec2.c | 51 ++---
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 8581d797fb..80a76bbba1 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -140,32 +140,35 @@ static av_cold int decode_init(AVCodecContext *avctx)
 
 avctx->bits_per_raw_sample = 10;
 
-switch (avctx->codec_tag) {
-case MKTAG('a','p','c','o'):
-avctx->profile = FF_PROFILE_PRORES_PROXY;
-break;
-case MKTAG('a','p','c','s'):
-avctx->profile = FF_PROFILE_PRORES_LT;
-break;
-case MKTAG('a','p','c','n'):
-avctx->profile = FF_PROFILE_PRORES_STANDARD;
-break;
-case MKTAG('a','p','c','h'):
-avctx->profile = FF_PROFILE_PRORES_HQ;
-break;
-case MKTAG('a','p','4','h'):
-avctx->profile = FF_PROFILE_PRORES_;
-avctx->bits_per_raw_sample = 12;
-break;
-case MKTAG('a','p','4','x'):
-avctx->profile = FF_PROFILE_PRORES_XQ;
-avctx->bits_per_raw_sample = 12;
-break;
-default:
-avctx->profile = FF_PROFILE_UNKNOWN;
-av_log(avctx, AV_LOG_WARNING, "Unknown prores profile %d\n", 
avctx->codec_tag);
+if (avctx->profile == FF_PROFILE_UNKNOWN) {
+switch (avctx->codec_tag) {
+case MKTAG('a','p','c','o'):
+avctx->profile = FF_PROFILE_PRORES_PROXY;
+break;
+case MKTAG('a','p','c','s'):
+avctx->profile = FF_PROFILE_PRORES_LT;
+break;
+case MKTAG('a','p','c','n'):
+avctx->profile = FF_PROFILE_PRORES_STANDARD;
+break;
+case MKTAG('a','p','c','h'):
+avctx->profile = FF_PROFILE_PRORES_HQ;
+break;
+case MKTAG('a','p','4','h'):
+avctx->profile = FF_PROFILE_PRORES_;
+break;
+case MKTAG('a','p','4','x'):
+avctx->profile = FF_PROFILE_PRORES_XQ;
+break;
+default:
+av_log(avctx, AV_LOG_WARNING, "Unknown prores profile %d\n", 
avctx->codec_tag);
+}
 }
 
+if (avctx->profile == FF_PROFILE_PRORES_XQ ||
+avctx->profile == FF_PROFILE_PRORES_)
+avctx->bits_per_raw_sample = 12;
+
 if (avctx->bits_per_raw_sample == 10) {
 av_log(avctx, AV_LOG_DEBUG, "Auto bitdepth precision. Use 10b decoding 
based on codec tag");
 } else { /* 12b */
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/h264dec: get field_order for typical frames

2018-12-05 Thread Paul B Mahol

On 12/5/18, Michael Niedermayer  wrote:
> On Wed, Dec 05, 2018 at 12:42:39PM +0100, Paul B Mahol wrote:
>> This is normally set by parser but parsing is not always enabled.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/h264dec.c | 18 ++
>>  1 file changed, 18 insertions(+)
>
> breaks: fate-api-h264-slice
> make: *** [fate-api-h264-slice] Error 139

How so? Do you know why?

> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Michael Niedermayer

On Wed, Dec 05, 2018 at 06:52:06PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/proresdec2.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

breaks 
make fate-prores-alpha_skip
TESTprores-alpha_skip
--- ./tests/ref/fate/prores-alpha_skip  2018-12-04 23:28:22.177830519 +0100
+++ tests/data/fate/prores-alpha_skip   2018-12-05 20:27:52.523422579 +0100
@@ -3,5 +3,5 @@
 #codec_id 0: rawvideo
 #dimensions 0: 1920x1080
 #sar 0: 0/1
-0,  0,  0,1, 12441600, 0x65e009b8
-0,  1,  1,1, 12441600, 0x65e009b8
+0,  0,  0,1, 12441600, 0xf06f2ff5
+0,  1,  1,1, 12441600, 0xf06f2ff5
Test prores-alpha_skip failed. Look at tests/data/fate/prores-alpha_skip.err 
for details.
make: *** [fate-prores-alpha_skip] Error 1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/h264dec: get field_order for typical frames

2018-12-05 Thread Michael Niedermayer

On Wed, Dec 05, 2018 at 12:42:39PM +0100, Paul B Mahol wrote:
> This is normally set by parser but parsing is not always enabled.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/h264dec.c | 18 ++
>  1 file changed, 18 insertions(+)

breaks: fate-api-h264-slice
make: *** [fate-api-h264-slice] Error 139

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Gregor Riepl

There seems to be an indentation issue here:

> +if (avctx->profile == FF_PROFILE_UNKNOWN) {
>  switch (avctx->codec_tag) {
>  case MKTAG('a','p','c','o'):

and here:

>  av_log(avctx, AV_LOG_WARNING, "Unknown prores profile %d\n", 
> avctx->codec_tag);
>  }
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 18:19 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
 On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>> Fixes #4409.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dpx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>> index 538a1b9943..04b55ffadf 100644
>> --- a/libavcodec/dpx.c
>> +++ b/libavcodec/dpx.c
>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>  read10in32(, ,
>> _datum, endian, shift);
>>  }
>> -n_datum = 0;
>> +if (packing != 2)
>> +n_datum = 0;
>>  for (i = 0; i < elements; i++)
>>  ptr[i] += p->linesize[i];
>>  }
>
> This breaks decoding the output of the following command:
> $ gm convert converted_image_gets_skewed.dpx -define
> dpx:packing-method=b out.dpx

 I do not trust that app, its full of bugs.
>>>
>>> What is the reference for dpx in your opinion?
>>
>> ImageTragick certainly not.
>
> That's not ImageMagick above.

Then what is it?

>
> The sample in question looks better with attached poc, breaks
> four component sample, also attaching other samples that
> show the difference.

Attacking crappy patches and non-compliant files that conflict and do
not follow specification is not productive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/4] avcodec/proresdec2: change profile only if it is unknown

2018-12-05 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavcodec/proresdec2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 8581d797fb..f715b86aad 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -140,6 +140,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 
 avctx->bits_per_raw_sample = 10;
 
+if (avctx->profile == FF_PROFILE_UNKNOWN) {
 switch (avctx->codec_tag) {
 case MKTAG('a','p','c','o'):
 avctx->profile = FF_PROFILE_PRORES_PROXY;
@@ -162,9 +163,9 @@ static av_cold int decode_init(AVCodecContext *avctx)
 avctx->bits_per_raw_sample = 12;
 break;
 default:
-avctx->profile = FF_PROFILE_UNKNOWN;
 av_log(avctx, AV_LOG_WARNING, "Unknown prores profile %d\n", 
avctx->codec_tag);
 }
+}
 
 if (avctx->bits_per_raw_sample == 10) {
 av_log(avctx, AV_LOG_DEBUG, "Auto bitdepth precision. Use 10b decoding 
based on codec tag");
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

2018-12-05 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavformat/mxfenc.c | 49 
 1 file changed, 49 insertions(+)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3549b4137d..e481b19ff3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -146,6 +146,7 @@ enum ULIndex {
 INDEX_JPEG2000,
 INDEX_H264,
 INDEX_S436M,
+INDEX_PRORES,
 };
 
 static const struct {
@@ -159,6 +160,7 @@ static const struct {
 { AV_CODEC_ID_DNXHD,  INDEX_DNXHD },
 { AV_CODEC_ID_JPEG2000,   INDEX_JPEG2000 },
 { AV_CODEC_ID_H264,   INDEX_H264 },
+{ AV_CODEC_ID_PRORES, INDEX_PRORES },
 { AV_CODEC_ID_NONE }
 };
 
@@ -314,6 +316,11 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x01,0x5C,0x00 
},
   mxf_write_s436m_anc_desc },
+// ProRes
+{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x0d,0x01,0x03,0x01,0x02,0x1c,0x01,0x00 
},
+  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x17,0x00 
},
+  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00 
},
+  mxf_write_cdci_desc },
 { { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},
   { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},
   { 
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 
},
@@ -1945,6 +1952,43 @@ static int mxf_write_partition(AVFormatContext *s, int 
bodysid,
 return 0;
 }
 
+static const struct {
+int profile;
+UID codec_ul;
+} mxf_prores_codec_uls[] = {
+{ FF_PROFILE_PRORES_PROXY,{ 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x01,0x00 
} },
+{ FF_PROFILE_PRORES_LT,   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x02,0x00 
} },
+{ FF_PROFILE_PRORES_STANDARD, { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00 
} },
+{ FF_PROFILE_PRORES_HQ,   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x04,0x00 
} },
+{ FF_PROFILE_PRORES_, { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x05,0x00 
} },
+{ FF_PROFILE_PRORES_XQ,   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x06,0x00 
} },
+};
+
+static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st, AVPacket 
*pkt)
+{
+MXFContext *mxf = s->priv_data;
+MXFStreamContext *sc = st->priv_data;
+int i, profile;
+
+if (mxf->header_written)
+return 1;
+
+sc->codec_ul = NULL;
+profile = st->codecpar->profile;
+for (i = 0; i < FF_ARRAY_ELEMS(mxf_prores_codec_uls); i++) {
+if (profile == mxf_prores_codec_uls[i].profile) {
+sc->codec_ul = _prores_codec_uls[i].codec_ul;
+break;
+}
+}
+if (!sc->codec_ul)
+return 0;
+
+sc->frame_size = pkt->size;
+
+return 1;
+}
+
 static const struct {
 int cid;
 UID codec_ul;
@@ -2736,6 +2780,11 @@ static int mxf_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 av_log(s, AV_LOG_ERROR, "could not get dnxhd profile\n");
 return -1;
 }
+} else if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
+if (!mxf_parse_prores_frame(s, st, pkt)) {
+av_log(s, AV_LOG_ERROR, "could not get prores profile\n");
+return -1;
+}
 } else if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO) {
 if (!mxf_parse_dv_frame(s, st, pkt)) {
 av_log(s, AV_LOG_ERROR, "could not get dv profile\n");
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] avcodec/proresdec2: allow changing resolution

2018-12-05 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavcodec/proresdec2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index f715b86aad..4a9c408291 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -222,9 +222,8 @@ static int decode_frame_header(ProresContext *ctx, const 
uint8_t *buf,
 height = AV_RB16(buf + 10);
 
 if (width != avctx->width || height != avctx->height) {
-av_log(avctx, AV_LOG_ERROR, "picture resolution change: %dx%d -> 
%dx%d\n",
+av_log(avctx, AV_LOG_WARNING, "picture resolution change: %dx%d -> 
%dx%d\n",
avctx->width, avctx->height, width, height);
-return AVERROR_PATCHWELCOME;
 }
 
 ctx->frame_type = (buf[12] >> 2) & 3;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

2018-12-05 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavformat/mxfdec.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f49890e140..abb030b1a4 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2432,6 +2432,18 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 default:
 av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout type: 
%d\n", descriptor->frame_layout);
 }
+
+if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
+switch (descriptor->essence_codec_ul[14]) {
+case 1: st->codecpar->profile = FF_PROFILE_PRORES_PROXY;
break;
+case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;   
break;
+case 3: st->codecpar->profile = FF_PROFILE_PRORES_STANDARD; 
break;
+case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;   
break;
+case 5: st->codecpar->profile = FF_PROFILE_PRORES_; 
break;
+case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;   
break;
+}
+}
+
 if (st->codecpar->codec_id == AV_CODEC_ID_RAWVIDEO) {
 st->codecpar->format = descriptor->pix_fmt;
 if (st->codecpar->format == AV_PIX_FMT_NONE) {
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>> On 12/5/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
 Fixes #4409.

 Signed-off-by: Paul B Mahol 
 ---
  libavcodec/dpx.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
 index 538a1b9943..04b55ffadf 100644
 --- a/libavcodec/dpx.c
 +++ b/libavcodec/dpx.c
 @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
  read10in32(, ,
 _datum, endian, shift);
  }
 -n_datum = 0;
 +if (packing != 2)
 +n_datum = 0;
  for (i = 0; i < elements; i++)
  ptr[i] += p->linesize[i];
  }
>>>
>>> This breaks decoding the output of the following command:
>>> $ gm convert converted_image_gets_skewed.dpx -define
>>> dpx:packing-method=b out.dpx
>>
>> I do not trust that app, its full of bugs.
>
> What is the reference for dpx in your opinion?

ImageTragick certainly not.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-05 Thread Jan Ekström

On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström  wrote:
>
> From: Rodger Combs 
>
> These are registered identifiers at the MPEG-4 RA, which are
> defined as to be utilized for Dolby Vision AVC/HEVC streams that
> are not correctly presentable by standards-compliant AVC/HEVC players.
>
> According to the Dolby Vision specification for ISOBMFF, these sample
> entry codes are specified to have the standard AVC or HEVC decoder
> configuration box in addition to the Dolby custom DOVIConfigurationBox.
> This is what enables us to decode the streams without custom parsing.
>
> For correct presentation information from the DOVIConfigurationBox
> is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> layer).
> ---

Gentle Ping?

Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 17:33 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>>> Fixes #4409.
>>>
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/dpx.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>>> index 538a1b9943..04b55ffadf 100644
>>> --- a/libavcodec/dpx.c
>>> +++ b/libavcodec/dpx.c
>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>>  read10in32(, ,
>>> _datum, endian, shift);
>>>  }
>>> -n_datum = 0;
>>> +if (packing != 2)
>>> +n_datum = 0;
>>>  for (i = 0; i < elements; i++)
>>>  ptr[i] += p->linesize[i];
>>>  }
>>
>> This breaks decoding the output of the following command:
>> $ gm convert converted_image_gets_skewed.dpx -define
>> dpx:packing-method=b out.dpx
>
> I do not trust that app, its full of bugs.

What is the reference for dpx in your opinion?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 14:27 GMT+01:00, Paul B Mahol :
>> Fixes #4409.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dpx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>> index 538a1b9943..04b55ffadf 100644
>> --- a/libavcodec/dpx.c
>> +++ b/libavcodec/dpx.c
>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>  read10in32(, ,
>> _datum, endian, shift);
>>  }
>> -n_datum = 0;
>> +if (packing != 2)
>> +n_datum = 0;
>>  for (i = 0; i < elements; i++)
>>  ptr[i] += p->linesize[i];
>>  }
>
> This breaks decoding the output of the following command:
> $ gm convert converted_image_gets_skewed.dpx -define
> dpx:packing-method=b out.dpx

I do not trust that app, its full of bugs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

2018-12-05 Thread Jean-Baptiste Kempf

On Tue, 4 Dec 2018, at 22:50, Martin Vignali wrote:
> > But then, you will get absolutely all the integration from ALL the various
> > non-open source multimedia libraries, because it is useful to someone.
> > Including shims for Adobe, Dolby and others.
> 
> I'm probably disagree with you on this subject ! :-)

Then, this is the crux of the discussion: do you want every non-open-source 
library to be in FFmpeg?
For hardware acceleration and drivers, the cut is quite clear. For the rest, 
I'm not so sure.

If so, be prepared for a LOT of patches, for everything under the world, 
starting with librv11, and Eve and so on.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes

2018-12-05 Thread Mironov, Mikhail

Hi Mark,
Did you have chance to try this sample?
BTW: Alex Karvchenko waits for your review and commit for AMF context for some 
time. With this commit he can add more interesting things. Could you please 
take a look?
Thanks,
Mikhail

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mironov, Mikhail
> Sent: November 29, 2018 10:52 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
> 
> HI,
> I've wrote a small sample you can use:
> https://www.dropbox.com/s/c8m8evoao731tbm/OCLDX11Interop.zip?dl=0
> If it doesn’t work - you have conflict of drivers with Intel - saw this 
> before.
> Thanks,
> Mikhail
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> Mark
> > Thompson
> > Sent: November 27, 2018 7:05 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop
> > extension for NV12 and P010 textures - split planes
> >
> > On 26/11/2018 15:32, Mironov, Mikhail wrote:
> > > You assume that device ID returned from regular enumeration is the
> > > same
> > as device ID returned from clGetDeviceIDsFromD3D11KHR. It is not
> > guaranteed and I didn't try this.
> >
> > Ok, that's fair I suppose.  Fixing it hasn't changed anything, though.
> >
> > > Also I would add tracing to ensure that CL_CONTEXT_D3D11_DEVICE_KHR
> > is actually set and clGetDeviceIDsFromD3D11KHR is called.
> >
> > The first was always true (Intel requires it too), the second is now.
> >
> > > In AMF code I always set CL_CONTEXT_INTEROP_USER_SYNC to true.
> >
> > I'm not completely sure of the precise semantics of D3D11, but I don't
> > think we want that here - the clEnqueueAcquireD3D11ObjectsKHR() call
> > should be the first synchronisation point following the previous
> > component (generally a decoder).
> >
> > I tried setting it anyway, but the behaviour doesn't change - I still
> > get CL_INVALID_D3D11_RESOURCE_KHR.
> >
> > > Also I would trace other parameters to
> clCreateFromD3D11Texture2DKHR:
> > memory flags and texture descriptor.
> >
> > For the flags, I tried all of CL_MEM_READ_WRITE / CL_MEM_WRITE_ONLY
> /
> > CL_MEM_READ_ONLY, which are the only allowed values.  The texture
> > descriptor is just the one created for the decoder.
> >
> > > BTW: does the interop work for NV or Intel?
> >
> > The D3D11 interop works on Intel, though not directly in the ffmpeg
> > utility without a little change because it requires the textures to be
> > created with D3D11_RESOURCE_MISC_FLAG (as described in the extension
> > document
> >  > 11 _nv12_media_sharing.txt>).  Intel doesn't care whether
> > clGetDeviceIDsFromD3D11KHR() is used or not (though I've fixed that
> > anyway), but it does require the CL_CONTEXT_D3D11_DEVICE_KHR option
> to
> > clCreateContext() (fails with CL_INVALID_CONTEXT if it isn't).
> >
> > It can't work on Nvidia because they don't offer any way to share NV12
> > textures.
> >
> > The DXVA2/D3D9 interop works correctly on both AMD and Intel with only
> > the common standard extension.  The one Nvidia device I can find
> > easily doesn't have cl_khr_dx9_media_sharing at all, so that doesn't work.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> > >> -Original Message-
> > >> From: ffmpeg-devel  On Behalf Of
> > >> Mark Thompson
> > >> Sent: November 25, 2018 5:22 PM
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop
> > >> extension for NV12 and P010 textures - split planes
> > >>
> > >> On 25/11/2018 21:28, Mironov, Mikhail wrote:
> > >>> It seem that the failure is not in the new extension but before,
> > >>> in the
> > >> interop from D3D11 to OCL. It can happen in two cases: OCL
> > >> device/context are created without D3D11 device or format of the
> > >> texture
> > is not supported.
> > >> NV12 is supported. I went through the latest ffmpeg snapshot and
> > >> found that function opencl_enumerate_d3d11_devices() looks correct,
> > >> pointer to the function is set to
> > >> OpenCLDeviceSelector::enumerate_devices member but I cannot find a
> > >> call to selector->enumerate_devices(). Instead
> > >> opencl_enumerate_devices() is called directly. So my guess is that
> > >> created OCL device is not created from D3D11.
> > >>
> > >> Hmm, right - patch just sent to fix the selection call.
> > >>
> > >> It doesn't actually make any difference to this case, though, since
> > >> the filter made it choose the right device anyway and
> > >> CL_CONTEXT_D3D11_DEVICE_KHR was always set when deriving from
> > D3D11.
> > >> (It could only have made a difference if there were other
> > >> conflicting
> > >> D3D11 devices it could have picked incorrectly.)
> > >>
> > >>> Just in case OCL device creation sample:
> > >>> https://github.com/GPUOpen-
> > >>

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: Remove global_sidx from movenc params for live streaming.

2018-12-05 Thread Andrey Semashev


On 12/4/18 2:47 PM, Andrey Semashev wrote:

On 12/4/18 11:49 AM, Jeyapal, Karthick wrote:


On 11/29/18 8:28 PM, Andrey Semashev wrote:

On 11/28/18 7:25 PM, Jeyapal, Karthick wrote:


On 11/28/18 4:41 PM, Andrey Semashev wrote:
The global_sidx flag causes errors like the following in movenc 
when media

segment removal is enabled via windos_size or remove_at_exit:

Non-consecutive fragments, writing incorrect sidx
Unable to re-open  output file for the second pass (faststart)
Removing global_sidx flag adds sidx atom to each moof fragment 
adding significant bitrate overhead.
Instead I have submitted a patch to handle this case cleanly in 
movenc. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236873.html

Please try the above patch and let me know if that will work for you.


Yes, that patch seems to fix the errors. Thanks.

Hi Andrey,

That patch was not pushed due to some objections. I have submitted a 
new patch set addressing it.

http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237121.html
Could you please try the above patchset and confirm if everything 
works as expected?


I will test the final version. Though, if it doesn't change the effect 
since the last version then it should work as well.


I have tested v2 with the fixed flags setup as noted by Tobias and don't 
see any errors.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 14:27 GMT+01:00, Paul B Mahol :
> Fixes #4409.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dpx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 538a1b9943..04b55ffadf 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>  read10in32(, ,
> _datum, endian, shift);
>  }
> -n_datum = 0;
> +if (packing != 2)
> +n_datum = 0;
>  for (i = 0; i < elements; i++)
>  ptr[i] += p->linesize[i];
>  }

This breaks decoding the output of the following command:
$ gm convert converted_image_gets_skewed.dpx -define
dpx:packing-method=b out.dpx

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

2018-12-05 Thread Nicolas George

Marton Balint (2018-12-03):
> You should think about our users who compile and use ffmpeg with NDI. This
> change affects them negatively, so I don't support it.

They chose to use hardware that only works with non-free software. They
made their bed.

I support the removal.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

2018-12-05 Thread Paul B Mahol

Fixes #4409.

Signed-off-by: Paul B Mahol 
---
 libavcodec/dpx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 538a1b9943..04b55ffadf 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
 read10in32(, ,
_datum, endian, shift);
 }
-n_datum = 0;
+if (packing != 2)
+n_datum = 0;
 for (i = 0; i < elements; i++)
 ptr[i] += p->linesize[i];
 }
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/movenc: Added an option to disable SIDX atom

2018-12-05 Thread Tobias Rapp


On 05.12.2018 07:18, Karthick J wrote:

---
  doc/muxers.texi  |  4 
  libavformat/movenc.c | 12 ++--
  libavformat/movenc.h |  1 +
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index f1cc6f5fee..ca10741900 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1325,6 +1325,10 @@ more efficient), but with this option set, the muxer 
writes one moof/mdat
  pair for each track, making it easier to separate tracks.
  
  This option is implicitly set when writing ismv (Smooth Streaming) files.

+@item -movflags skip_sidx
+Skip writing of sidx atom. When bitrate overhead due to sidx atom is high,
+this option could be used for cases where sidx atom is not mandatory.
+When global_sidx flag is enabled, this option will be ignored.
  @item -movflags faststart
  Run a second pass moving the index (moov atom) to the beginning of the file.
  This operation can take a while, and will not work in various situations such
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 6dab5193b0..3781a32895 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -75,6 +75,7 @@ static const AVOption options[] = {
  { "frag_discont", "Signal that the next fragment is discontinuous from earlier 
ones", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_FRAG_DISCONT}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "delay_moov", "Delay writing the initial moov until the first fragment is cut, or 
until the first fragment flush", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_DELAY_MOOV}, INT_MIN, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "global_sidx", "Write a global sidx index at the start of the file", 0, 
AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_GLOBAL_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, 
"movflags" },
+{ "skip_sidx", "Skip writing of sidx atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_SKIP_SIDX}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "write_colr", "Write colr atom (Experimental, may be renamed or changed, do not use 
from scripts)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_WRITE_COLR}, INT_MIN, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "write_gama", "Write deprecated gama atom", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_WRITE_GAMA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
  { "use_metadata_tags", "Use mdta atom for metadata.", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_MOV_FLAG_USE_MDTA}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
@@ -4603,7 +4604,8 @@ static int mov_write_moof_tag(AVIOContext *pb, 
MOVMuxContext *mov, int tracks,
  mov_write_moof_tag_internal(avio_buf, mov, tracks, 0);
  moof_size = ffio_close_null_buf(avio_buf);
  
-if (mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & FF_MOV_FLAG_GLOBAL_SIDX))

+if (mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | FF_MOV_FLAG_SKIP_SIDX)))
  mov_write_sidx_tags(pb, mov, tracks, moof_size + 8 + mdat_size);
  
  if (mov->write_prft > MOV_PRFT_NONE && mov->write_prft < MOV_PRFT_NB)

@@ -5422,7 +5424,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
   * the next fragment. This means the cts of the first sample must
   * be the same in all fragments, unless end_pts was updated by
   * the packet causing the fragment to be written. */
-if ((mov->flags & FF_MOV_FLAG_DASH && !(mov->flags & 
FF_MOV_FLAG_GLOBAL_SIDX)) ||
+if ((mov->flags & FF_MOV_FLAG_DASH &&
+!(mov->flags & (FF_MOV_FLAG_GLOBAL_SIDX | 
FF_MOV_FLAG_SKIP_SIDX))) ||
  mov->mode == MODE_ISM)
  pkt->pts = pkt->dts + trk->end_pts - 
trk->cluster[trk->entry].dts;
  } else {
@@ -6067,6 +6070,11 @@ static int mov_init(AVFormatContext *s)
  s->flags &= ~AVFMT_FLAG_AUTO_BSF;
  }
  
+if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX && s->flags & FF_MOV_FLAG_SKIP_SIDX) {

+av_log(s, AV_LOG_WARNING, "Global SIDX enabled; Ignoring skip_sidx 
option\n");
+s->flags &= ~FF_MOV_FLAG_SKIP_SIDX;
+}
+


I guess this should use mov->flags instead of s->flags?


  if (mov->flags & FF_MOV_FLAG_FASTSTART) {
  mov->reserved_moov_size = -1;
  }
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index fe605d1ad2..68d6f23a5a 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -257,6 +257,7 @@ typedef struct MOVMuxContext {
  #define FF_MOV_FLAG_SKIP_TRAILER  (1 << 18)
  #define FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS  (1 << 19)
  #define FF_MOV_FLAG_FRAG_EVERY_FRAME  (1 << 20)
+#define FF_MOV_FLAG_SKIP_SIDX (1 << 21)
  
  int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt);
  



Otherwise changes look fine, but I am not the maintainer of this file.

Regards,
Tobias

___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: replace assert0 with an error return when pict_type is uninitialized

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 6:37 GMT+01:00, Li, Zhong :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Linjie Fu
>> Sent: Monday, December 3, 2018 4:34 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Fu, Linjie 
>> Subject: [FFmpeg-devel] [PATCH] lavc/qsvenc: replace assert0 with an
>> error
>> return when pict_type is uninitialized
>>
>> pict_type may be uninitialized, and assert on a value coming from an
>> external library is not proper.
>>
>> Return invalid data error in function ff_qsv_encode to avoid using
>> uninitialized value.
>>
>> Signed-off-by: Linjie Fu 
>> ---
>>  libavcodec/qsvenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
>> 7f4592f878..891253be76 100644
>> --- a/libavcodec/qsvenc.c
>> +++ b/libavcodec/qsvenc.c
>> @@ -1338,7 +1338,7 @@ int ff_qsv_encode(AVCodecContext *avctx,
>> QSVEncContext *q,
>>  else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType
>> & MFX_FRAMETYPE_xB)
>>  pict_type = AV_PICTURE_TYPE_B;
>>  else
>> -av_assert0(!"Uninitialized pict_type!");
>> +return AVERROR_INVALIDDATA;
>
> Thus will be still a broken issue of ticket # 7593.

But an important - and long discussed - bug would be replaced by a
graceful exit.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 12:49 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos  wrote:
>> 2018-12-05 11:30 GMT+01:00, Paul B Mahol :
>>> Fixes #4409.
>>>
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/dpx.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>>> index 538a1b9943..b09f65eeb6 100644
>>> --- a/libavcodec/dpx.c
>>> +++ b/libavcodec/dpx.c
>>> @@ -378,7 +378,6 @@ static int decode_frame(AVCodecContext *avctx,
>>>  read10in32(, ,
>>> _datum, endian, shift);
>>>  }
>>> -n_datum = 0;
>>>  for (i = 0; i < elements; i++)
>>>  ptr[i] += p->linesize[i];
>>>  }
>>> @@ -413,7 +412,6 @@ static int decode_frame(AVCodecContext *avctx,
>>> _datum, endian);
>>>  }
>>>  }
>>> -n_datum = 0;
>>
>> This breaks existing files.
>
> Have proof?

Seriously?

> Link to such existing files?

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2392/converted_image_gets_skewed.dpx
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5639/odd_12bpp.dpx
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5639/odd_12bpp_alpha.dpx

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row

2018-12-05 Thread Paul B Mahol

On 12/5/18, Carl Eugen Hoyos  wrote:
> 2018-12-05 11:30 GMT+01:00, Paul B Mahol :
>> Fixes #4409.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/dpx.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>> index 538a1b9943..b09f65eeb6 100644
>> --- a/libavcodec/dpx.c
>> +++ b/libavcodec/dpx.c
>> @@ -378,7 +378,6 @@ static int decode_frame(AVCodecContext *avctx,
>>  read10in32(, ,
>> _datum, endian, shift);
>>  }
>> -n_datum = 0;
>>  for (i = 0; i < elements; i++)
>>  ptr[i] += p->linesize[i];
>>  }
>> @@ -413,7 +412,6 @@ static int decode_frame(AVCodecContext *avctx,
>> _datum, endian);
>>  }
>>  }
>> -n_datum = 0;
>
> This breaks existing files.

Have proof? Link to such existing files?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row

2018-12-05 Thread Carl Eugen Hoyos

2018-12-05 11:30 GMT+01:00, Paul B Mahol :
> Fixes #4409.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dpx.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index 538a1b9943..b09f65eeb6 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -378,7 +378,6 @@ static int decode_frame(AVCodecContext *avctx,
>  read10in32(, ,
> _datum, endian, shift);
>  }
> -n_datum = 0;
>  for (i = 0; i < elements; i++)
>  ptr[i] += p->linesize[i];
>  }
> @@ -413,7 +412,6 @@ static int decode_frame(AVCodecContext *avctx,
> _datum, endian);
>  }
>  }
> -n_datum = 0;

This breaks existing files.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/h264dec: get field_order for typical frames

2018-12-05 Thread Paul B Mahol

This is normally set by parser but parsing is not always enabled.

Signed-off-by: Paul B Mahol 
---
 libavcodec/h264dec.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 00d922fbe9..39142da7af 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1018,6 +1018,24 @@ static int h264_decode_frame(AVCodecContext *avctx, void 
*data,
 }
 }
 
+if (h->picture_structure == PICT_FRAME) {
+if (h->ps.sps->pic_struct_present_flag && 
h->sei.picture_timing.present) {
+switch (h->sei.picture_timing.pic_struct) {
+case H264_SEI_PIC_STRUCT_TOP_BOTTOM:
+case H264_SEI_PIC_STRUCT_TOP_BOTTOM_TOP:
+avctx->field_order = AV_FIELD_TT;
+break;
+case H264_SEI_PIC_STRUCT_BOTTOM_TOP:
+case H264_SEI_PIC_STRUCT_BOTTOM_TOP_BOTTOM:
+avctx->field_order = AV_FIELD_BB;
+break;
+default:
+avctx->field_order = AV_FIELD_PROGRESSIVE;
+break;
+}
+}
+}
+
 av_assert0(pict->buf[0] || !*got_frame);
 
 ff_h264_unref_picture(h, >last_pic_for_ec);
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mjpeg: don't override color information from demuxer

2018-12-05 Thread Steinar H. Gunderson

On Wed, Dec 05, 2018 at 01:33:12AM +0100, Hendrik Leppkes wrote:
> The real problem is that its impossible to know which component to
> really trust. Why does a demuxer have more authority on the color
> format then a decoder? Or vice-versa?

You can make this arbitrarily complicated, of course, but if the codec
has no info apart from defaults (as in this case), I'd say the decision is
fairly simple. The one with the more specific information wins, which is the
demuxer.

There's a corner case where you can't specify _explicitly_ in the mux
“I don't know, but it's probably not the defaults” (since there's no
distinction between “unspecified because the format doesn't say so”
and “unspecified because the user explicitly told us to”), but I can't see
what an application would do in that case except use the codec defaults
anyway.

> We don't have a solution for that, and its really something the user
> application currently has to solve.

The user application doesn't feel like the right place for this. How would it
be in a better position than FFmpeg to know? And if it really is in the
position to set a policy here, it can read out the information of the codec
parameter struct and override it, no matter what libavcodec decided to do.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

53 matches

Mail list logo