Re: [FFmpeg-devel] [PATCH] hevc_mp4toannexb: Do not duplicate parameter sets

2019-08-12 Thread Andriy Gelman
Andreas,

On Sun, 21. Jul 10:47, Andreas Rheinhardt wrote:
> Andriy Gelman:
> > From: Andriy Gelman 
> > 
> > Fixes #7799
> > 
> > Currently, the mp4toannexb filter always inserts extradata at the start
> > of each IRAP unit. This can lead to duplication of parameter sets if the
> > demuxed packet from mdat atom already contains a version of the
> > parameters.
> > 
> > As in ticket #7799 this can also lead to decoding errors when the
> > parameter sets of the IRAP frames are different from the ones stored in
> > extradata.
> > 
> > This commit avoids duplicating the parameter sets if they are already
> > present in the demuxed packet.
> > 
> > This commit also makes an update to the hevc-bsf-mp4toannexb fate
> > test since the result before this patch contained duplicate vps/sps/pps
> > nal units.
> > ---
> >  libavcodec/hevc_mp4toannexb_bsf.c | 9 -
> >  tests/fate/hevc.mak   | 2 +-
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c 
> > b/libavcodec/hevc_mp4toannexb_bsf.c
> > index 09bce5b34c..5c27306b09 100644
> > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > @@ -123,6 +123,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx, 
> > AVPacket *out)
> >  
> >  int got_irap = 0;
> >  int i, ret = 0;
> > +int vps_detected, sps_detected, pps_detected = 0;
> >  
> You are only initiallizing pps_detected.
> 
> >  ret = ff_bsf_get_packet(ctx, );
> >  if (ret < 0)
> > @@ -146,9 +147,15 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx, 
> > AVPacket *out)
> >  
> >  nalu_type = (bytestream2_peek_byte() >> 1) & 0x3f;
> >  
> > +switch (nalu_type) {
> > +  case HEVC_NAL_VPS: vps_detected = 1; break;
> > +  case HEVC_NAL_SPS: sps_detected = 1; break;
> > +  case HEVC_NAL_PPS: pps_detected = 1; break;
> > +}
> > +
> >  /* prepend extradata to IRAP frames */
> >  is_irap   = nalu_type >= 16 && nalu_type <= 23;
> > -add_extradata = is_irap && !got_irap;
> > +add_extradata = is_irap && !got_irap && !(vps_detected && 
> > sps_detected && pps_detected);
> >  extra_size= add_extradata * ctx->par_out->extradata_size;
> >  got_irap |= is_irap;
> >  
> There are two things that I don't like about this approach:
> 1. Image an input file like this: VPS, SPS and PPS in extradata and
> then after a few GOPs there is an inband PPS as part of a VPS, SPS and
> PPS combination where the PPS differs from the PPS in the extradata.
> After this change in parameter sets there are no further inband
> parameter sets. With your proposal, the extradata would again be
> inserted into access units with IRAP frames after the change in
> extradata and it would be the old, outdated extradata, thereby
> breaking decoding (the original mp4 file would probably not be able
> fully seekable in this case, but that would be another story).
> 2. If the sample in #7799 contained only the parameter set that
> actually changed inband, your proposal would still add a whole
> VPS+SPS+PPS combination and therefore still make the sample unplayable.
> 

Thanks for your feedback. 
I believe I'm quite close to finishing the new patch. 

The general workflow in the updated mp4toannexb_filter function is: 
  1. Convert input avcc packet to annexb.
  2. Split the annexb bytestream into NAL units using ff_h2645_packet_splits 
function
  3. If VPS/SPS/PPS nal units are present, parse them to get their id and 
reference to higher level parameter set.
  4. New VPS/SPS/PPS parameter sets are compared their 'cached version'. The 
cached versions are stored in a struct similar to HEVCParamSets. If the new 
parameter set is
  different, then update the cached version.
  5. Update extradata if any of the cached parameter sets have changed.  
  6. Insert new extradata at the first IRAP nal unit (i.e.
  same as original code).

The only part that still remains to be done is dealing with SEI nals. What I'm 
unsure about is whether SEIs from past extradata should be inserted at the 
start of future IRAP frames. The current code seems to do this. 
I think the consistent approach is to add SEI prefix/suffix into extradata. 
But, also update SEI if new version are encountered in the bytestream. 

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

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

[FFmpeg-devel] [PATCH 12/13] avformat/mux: Don't modify packets we don't own

2019-08-12 Thread Andreas Rheinhardt
The documentation of av_write_frame explicitly states that the function
does not take ownership of the packets sent to it; while av_write_frame
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be modified either by prepare_input_packet or
compute_muxer_pkt_fields.
2. If a bitstream filter gets applied, it takes ownership of the
reference and the side-data in the packet sent to it in av_bsf_send_packet.
In case of do_packet_auto_bsf, the end result is that the returned packet
contains the output of the last bsf in the chain. If an error happens,
an empty packet will be returned; a packet may also simply not lead to
any output (vp9_superframe).
This also implies that side data needs to be really copied and can't be
shared with the input packet.
The method choosen here minimizes copying of data: When the input isn't
refcounted and no bitstream filter is applied, the packet's data will
not be copied.

Signed-off-by: Andreas Rheinhardt 
---
I am not sure about this one. If one understands ownership of a packet
as "the right to modify a packet as well as the obligation to ultimately
free the data" (in case the data is shared, one of course needs to make
it writable before modifying it), then it is obvious that av_write_frame
needs to preserve the original packet given to it; that was my
understanding when writing this patch. But Hendrik has said that
"ownership" actually only comes with the obligation to free the data and
that av_write_frame does not taking ownership of the packet does not
imply that the caller may expect the packet to be returned unmodified.
If the latter is correct, then this patch is moot, of course.

 libavformat/mux.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 55fa0a184c..2dc7fc2dcb 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -872,11 +872,12 @@ static int do_packet_auto_bsf(AVFormatContext *s, 
AVPacket *pkt) {
 return 1;
 }
 
-int av_write_frame(AVFormatContext *s, AVPacket *pkt)
+int av_write_frame(AVFormatContext *s, AVPacket *in)
 {
+AVPacket local_pkt, *pkt = _pkt;
 int ret;
 
-if (!pkt) {
+if (!in) {
 if (s->oformat->flags & AVFMT_ALLOW_FLUSH) {
 ret = s->oformat->write_packet(s, NULL);
 flush_if_needed(s);
@@ -887,19 +888,36 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 return 1;
 }
 
+/* We don't own in, so we have to make sure not to modify it.
+ * The following avoids copying in's data unnecessarily.
+ * Copying side data is unavoidable as a bitstream filter
+ * may change it, e.g. free it on errors. */
+pkt->data = in->data;
+pkt->size = in->size;
+if (in->buf) {
+pkt->buf = av_buffer_ref(in->buf);
+if (!pkt->buf)
+return AVERROR(ENOMEM);
+} else {
+pkt->buf = NULL;
+}
+ret = av_packet_copy_props(pkt, in);
+if (ret < 0)
+goto fail;
+
 ret = prepare_input_packet(s, pkt);
 if (ret < 0)
-return ret;
+goto fail;
 
 ret = do_packet_auto_bsf(s, pkt);
 if (ret <= 0)
-return ret;
+goto fail;
 
 #if FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX
 ret = compute_muxer_pkt_fields(s, s->streams[pkt->stream_index], pkt);
 
 if (ret < 0 && !(s->oformat->flags & AVFMT_NOTIMESTAMPS))
-return ret;
+goto fail;
 #endif
 
 ret = write_packet(s, pkt);
@@ -908,6 +926,9 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 
 if (ret >= 0)
 s->streams[pkt->stream_index]->nb_frames++;
+
+fail:
+av_packet_unref(pkt);
 return ret;
 }
 
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 06/13] avformat/mux: Use av_packet_rescale_ts

2019-08-12 Thread Andreas Rheinhardt
ff_write_chained essentially duplicated the functionality of
av_packet_rescale_ts. This has been changed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 44ce099cbf..efe2e94f40 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1317,18 +1317,10 @@ int ff_write_chained(AVFormatContext *dst, int 
dst_stream, AVPacket *pkt,
 
 local_pkt = *pkt;
 local_pkt.stream_index = dst_stream;
-if (pkt->pts != AV_NOPTS_VALUE)
-local_pkt.pts = av_rescale_q(pkt->pts,
- 
src->streams[pkt->stream_index]->time_base,
- dst->streams[dst_stream]->time_base);
-if (pkt->dts != AV_NOPTS_VALUE)
-local_pkt.dts = av_rescale_q(pkt->dts,
- 
src->streams[pkt->stream_index]->time_base,
- dst->streams[dst_stream]->time_base);
-if (pkt->duration)
-local_pkt.duration = av_rescale_q(pkt->duration,
-  
src->streams[pkt->stream_index]->time_base,
-  dst->streams[dst_stream]->time_base);
+
+av_packet_rescale_ts(_pkt,
+ src->streams[pkt->stream_index]->time_base,
+ dst->streams[dst_stream]->time_base);
 
 if (interleave) ret = av_interleaved_write_frame(dst, _pkt);
 elseret = av_write_frame(dst, _pkt);
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 10/13] avformat/mux: Fix memleaks on errors I

2019-08-12 Thread Andreas Rheinhardt
If writing an uncoded frame fails at the preparatory steps of
av_[interleaved_]write_frame, the frame would be either not freed
at all in case of av_write_frame or would leak when the fake packet
would be unreferenced like an ordinary packet.
There is also a memleak when the output format is not suited for
writing uncoded frames as the documentation states that ownership of the
frame passes to av_[interleaved_]write_uncoded frame. Both of these
memleaks have been fixed.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 5b67a793ac..c524c0886c 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1241,7 +1241,11 @@ int av_interleaved_write_frame(AVFormatContext *s, 
AVPacket *pkt)
 return s->pb->error;
 }
 fail:
-av_packet_unref(pkt);
+// This is a deviation from the usual behaviour
+// of av_interleaved_write_frame: We leave cleaning
+// up uncoded frames to write_uncoded_frame_internal.
+if (!(pkt->flags & AV_PKT_FLAG_UNCODED_FRAME))
+av_packet_unref(pkt);
 return ret;
 }
 
@@ -1334,10 +1338,13 @@ static int write_uncoded_frame_internal(AVFormatContext 
*s, int stream_index,
 AVFrame *frame, int interleaved)
 {
 AVPacket pkt, *pktp;
+int ret;
 
 av_assert0(s->oformat);
-if (!s->oformat->write_uncoded_frame)
-return AVERROR(ENOSYS);
+if (!s->oformat->write_uncoded_frame) {
+ret = AVERROR(ENOSYS);
+goto free;
+}
 
 if (!frame) {
 pktp = NULL;
@@ -1353,8 +1360,14 @@ static int write_uncoded_frame_internal(AVFormatContext 
*s, int stream_index,
 pkt.flags |= AV_PKT_FLAG_UNCODED_FRAME;
 }
 
-return interleaved ? av_interleaved_write_frame(s, pktp) :
- av_write_frame(s, pktp);
+ret = interleaved ? av_interleaved_write_frame(s, pktp) :
+av_write_frame(s, pktp);
+if (ret < 0 && pktp && pktp->data) {
+frame = (AVFrame*)pktp->data;
+free:
+av_frame_free();
+}
+return ret;
 }
 
 int av_write_uncoded_frame(AVFormatContext *s, int stream_index,
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 13/13] avformat/mux: Remove pointless timestamp backups

2019-08-12 Thread Andreas Rheinhardt
write_packet currently saves the original timestamps of the packet it got
and restores them in case writing fails. This is unnecessary as none of
write_packet's callers make any use of these timestamps at all. So
remove this and add a general comment to the function that timestamps
may be modified; also remove a long outdated comment about side data.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2dc7fc2dcb..8f617d4011 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -663,8 +663,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 /**
- * Make timestamps non negative, move side data from payload to internal 
struct, call muxer, and restore
- * sidedata.
+ * Make timestamps non negative and call muxer; the original pts/dts are not 
kept.
  *
  * FIXME: this function should NEVER get undefined pts/dts beside when the
  * AVFMT_NOTIMESTAMPS is set.
@@ -674,10 +673,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 static int write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 int ret;
-int64_t pts_backup, dts_backup;
-
-pts_backup = pkt->pts;
-dts_backup = pkt->dts;
 
 // If the timestamp offsetting below is adjusted, adjust
 // ff_interleaved_peek similarly.
@@ -753,11 +748,6 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 ret = s->pb->error;
 }
 
-if (ret < 0) {
-pkt->pts = pts_backup;
-pkt->dts = dts_backup;
-}
-
 return ret;
 }
 
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229

2019-08-12 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Thilo Borgmann
> Sent: Monday, August 12, 2019 3:55 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229
> 
> Am 12.08.19 um 08:13 schrieb Zhong Li:
> > Signed-off-by: Zhong Li 
> > ---
> > https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but
> not found by fate, so add it.
> > Test clip produced by:
> > ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy
> > /fate-suite/mjpeg/mjpeg_field_order.avi
> >
> >  tests/fate/video.mak| 3 +++
> >  tests/ref/fate/mjpeg-ticket3229 | 8 
> >  2 files changed, 11 insertions(+)
> >  create mode 100644 tests/ref/fate/mjpeg-ticket3229 [...]
> 
> LGTM & sample uploaded.
> 
> -Thilo

Thanks!
Patch applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 09/13] avformat/mux: Don't use av_ prefix for static functions

2019-08-12 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index efe2e94f40..5b67a793ac 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1330,8 +1330,8 @@ int ff_write_chained(AVFormatContext *dst, int 
dst_stream, AVPacket *pkt,
 return ret;
 }
 
-static int av_write_uncoded_frame_internal(AVFormatContext *s, int 
stream_index,
-   AVFrame *frame, int interleaved)
+static int write_uncoded_frame_internal(AVFormatContext *s, int stream_index,
+AVFrame *frame, int interleaved)
 {
 AVPacket pkt, *pktp;
 
@@ -1360,13 +1360,13 @@ static int 
av_write_uncoded_frame_internal(AVFormatContext *s, int stream_index,
 int av_write_uncoded_frame(AVFormatContext *s, int stream_index,
AVFrame *frame)
 {
-return av_write_uncoded_frame_internal(s, stream_index, frame, 0);
+return write_uncoded_frame_internal(s, stream_index, frame, 0);
 }
 
 int av_interleaved_write_uncoded_frame(AVFormatContext *s, int stream_index,
AVFrame *frame)
 {
-return av_write_uncoded_frame_internal(s, stream_index, frame, 1);
+return write_uncoded_frame_internal(s, stream_index, frame, 1);
 }
 
 int av_write_uncoded_frame_query(AVFormatContext *s, int stream_index)
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 08/13] avformat/avformat.h: Correct some comments

2019-08-12 Thread Andreas Rheinhardt
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet; it is of course nonsense and has
been replaced by an accurate description.
2. The description of av_write_uncoded_frame suggested
av_interleaved_write_frame as a replacement if the input is not
already correctly interleaved; it also referred to said function for
details. Given that said function can't write AVFrames and that the
stuff specific to writing uncoded frames is explained in the description
of av_interleaved_write_uncoded_frame, both references have been fixed.
3. Removed an outdated comment about avformat_seek_file.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.h | 9 -
 libavformat/version.h  | 2 +-
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6eb329f13f..92c3a89f4b 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -556,7 +556,8 @@ typedef struct AVOutputFormat {
 int (*write_packet)(struct AVFormatContext *, AVPacket *pkt);
 int (*write_trailer)(struct AVFormatContext *);
 /**
- * Currently only used to set pixel format if not YUV420P.
+ * A format-specific function for interleavement.
+ * If unset, packets will be interleaved by dts.
  */
 int (*interleave_packet)(struct AVFormatContext *, AVPacket *out,
  AVPacket *in, int flush);
@@ -2449,8 +2450,6 @@ int av_seek_frame(AVFormatContext *s, int stream_index, 
int64_t timestamp,
  * @return >=0 on success, error code otherwise
  *
  * @note This is part of the new seek API which is still under construction.
- *   Thus do not use this yet. It may change at any time, do not expect
- *   ABI compatibility yet!
  */
 int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, 
int64_t ts, int64_t max_ts, int flags);
 
@@ -2637,9 +2636,9 @@ int av_interleaved_write_frame(AVFormatContext *s, 
AVPacket *pkt);
  * Write an uncoded frame to an output media file.
  *
  * The frame must be correctly interleaved according to the container
- * specification; if not, then av_interleaved_write_frame() must be used.
+ * specification; if not, av_interleaved_write_uncoded_frame() must be used.
  *
- * See av_interleaved_write_frame() for details.
+ * See av_interleaved_write_uncoded_frame() for details.
  */
 int av_write_uncoded_frame(AVFormatContext *s, int stream_index,
AVFrame *frame);
diff --git a/libavformat/version.h b/libavformat/version.h
index 45efaff9b9..feceaedc08 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  30
+#define LIBAVFORMAT_VERSION_MINOR  31
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 04/13] avformat/mux: Cosmetics

2019-08-12 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2728c62de5..4089382ffd 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -921,13 +921,13 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 {
 int ret;
 AVPacketList **next_point, *this_pktl;
-AVStream *st   = s->streams[pkt->stream_index];
-int chunked= s->max_chunk_size || s->max_chunk_duration;
+AVStream *st = s->streams[pkt->stream_index];
+int chunked  = s->max_chunk_size || s->max_chunk_duration;
 
-this_pktl  = av_malloc(sizeof(AVPacketList));
+this_pktl= av_malloc(sizeof(AVPacketList));
 if (!this_pktl)
 return AVERROR(ENOMEM);
-if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
+if (pkt->flags & AV_PKT_FLAG_UNCODED_FRAME) {
 av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
 av_assert0(((AVFrame *)pkt->data)->buf);
 } else {
@@ -940,7 +940,7 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 av_packet_move_ref(_pktl->pkt, pkt);
 pkt = _pktl->pkt;
 
-if (s->streams[pkt->stream_index]->last_in_packet_buffer) {
+if (st->last_in_packet_buffer) {
 next_point = &(st->last_in_packet_buffer->next);
 } else {
 next_point = >internal->packet_buffer;
@@ -952,8 +952,8 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 st->interleaver_chunk_duration += pkt->duration;
 if (   (s->max_chunk_size && st->interleaver_chunk_size > 
s->max_chunk_size)
 || (max && st->interleaver_chunk_duration   > max)) {
-st->interleaver_chunk_size  = 0;
-this_pktl->pkt.flags |= CHUNK_START;
+st->interleaver_chunk_size = 0;
+pkt->flags |= CHUNK_START;
 if (max && st->interleaver_chunk_duration > max) {
 int64_t syncoffset = (st->codecpar->codec_type == 
AVMEDIA_TYPE_VIDEO)*max/2;
 int64_t syncto = av_rescale(pkt->dts + syncoffset, 1, max)*max 
- syncoffset;
@@ -964,7 +964,7 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 }
 }
 if (*next_point) {
-if (chunked && !(this_pktl->pkt.flags & CHUNK_START))
+if (chunked && !(pkt->flags & CHUNK_START))
 goto next_non_null;
 
 if (compare(s, >internal->packet_buffer_end->pkt, pkt)) {
@@ -985,8 +985,7 @@ next_non_null:
 
 this_pktl->next = *next_point;
 
-s->streams[pkt->stream_index]->last_in_packet_buffer =
-*next_point  = this_pktl;
+st->last_in_packet_buffer = *next_point = this_pktl;
 
 return 0;
 }
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 03/13] avformat/mux: Use const AVPacket * in compare functions

2019-08-12 Thread Andreas Rheinhardt
There is no reason for these functions to modify the given packets at
all.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/audiointerleave.c | 2 +-
 libavformat/audiointerleave.h | 2 +-
 libavformat/gxfenc.c  | 5 +++--
 libavformat/internal.h| 2 +-
 libavformat/mux.c | 6 +++---
 libavformat/mxfenc.c  | 3 ++-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
index dea5d99821..b602eb7105 100644
--- a/libavformat/audiointerleave.c
+++ b/libavformat/audiointerleave.c
@@ -108,7 +108,7 @@ static int interleave_new_audio_packet(AVFormatContext *s, 
AVPacket *pkt,
 
 int ff_audio_rechunk_interleave(AVFormatContext *s, AVPacket *out, AVPacket 
*pkt, int flush,
 int (*get_packet)(AVFormatContext *, AVPacket *, 
AVPacket *, int),
-int (*compare_ts)(AVFormatContext *, AVPacket *, 
AVPacket *))
+int (*compare_ts)(AVFormatContext *, const AVPacket *, 
const AVPacket *))
 {
 int i, ret;
 
diff --git a/libavformat/audiointerleave.h b/libavformat/audiointerleave.h
index 4d77832fa1..f28d5fefcc 100644
--- a/libavformat/audiointerleave.h
+++ b/libavformat/audiointerleave.h
@@ -50,6 +50,6 @@ void ff_audio_interleave_close(AVFormatContext *s);
  */
 int ff_audio_rechunk_interleave(AVFormatContext *s, AVPacket *out, AVPacket 
*pkt, int flush,
 int (*get_packet)(AVFormatContext *, AVPacket *, 
AVPacket *, int),
-int (*compare_ts)(AVFormatContext *, AVPacket *, 
AVPacket *));
+int (*compare_ts)(AVFormatContext *, const AVPacket *, 
const AVPacket *));
 
 #endif /* AVFORMAT_AUDIOINTERLEAVE_H */
diff --git a/libavformat/gxfenc.c b/libavformat/gxfenc.c
index 3507c00b40..ad9ddea887 100644
--- a/libavformat/gxfenc.c
+++ b/libavformat/gxfenc.c
@@ -987,10 +987,11 @@ static int gxf_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return 0;
 }
 
-static int gxf_compare_field_nb(AVFormatContext *s, AVPacket *next, AVPacket 
*cur)
+static int gxf_compare_field_nb(AVFormatContext *s, const AVPacket *next,
+const AVPacket *cur)
 {
 GXFContext *gxf = s->priv_data;
-AVPacket *pkt[2] = { cur, next };
+const AVPacket *pkt[2] = { cur, next };
 int i, field_nb[2];
 GXFStreamContext *sc[2];
 
diff --git a/libavformat/internal.h b/libavformat/internal.h
index cf8c16579c..d6a039c497 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -237,7 +237,7 @@ int ff_hex_to_data(uint8_t *data, const char *p);
  * @return 0, or < 0 on error
  */
 int ff_interleave_add_packet(AVFormatContext *s, AVPacket *pkt,
- int (*compare)(AVFormatContext *, AVPacket *, 
AVPacket *));
+ int (*compare)(AVFormatContext *, const AVPacket 
*, const AVPacket *));
 
 void ff_read_frame_flush(AVFormatContext *s);
 
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 870e716950..2728c62de5 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -917,7 +917,7 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 #define CHUNK_START 0x1000
 
 int ff_interleave_add_packet(AVFormatContext *s, AVPacket *pkt,
- int (*compare)(AVFormatContext *, AVPacket *, 
AVPacket *))
+ int (*compare)(AVFormatContext *, const AVPacket 
*, const AVPacket *))
 {
 int ret;
 AVPacketList **next_point, *this_pktl;
@@ -991,8 +991,8 @@ next_non_null:
 return 0;
 }
 
-static int interleave_compare_dts(AVFormatContext *s, AVPacket *next,
-  AVPacket *pkt)
+static int interleave_compare_dts(AVFormatContext *s, const AVPacket *next,
+  const AVPacket *pkt)
 {
 AVStream *st  = s->streams[pkt->stream_index];
 AVStream *st2 = s->streams[next->stream_index];
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 2e54320cf0..8b3d599a6f 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -3148,7 +3148,8 @@ static int mxf_interleave_get_packet(AVFormatContext *s, 
AVPacket *out, AVPacket
 }
 }
 
-static int mxf_compare_timestamps(AVFormatContext *s, AVPacket *next, AVPacket 
*pkt)
+static int mxf_compare_timestamps(AVFormatContext *s, const AVPacket *next,
+  const AVPacket *pkt)
 {
 MXFStreamContext *sc  = s->streams[pkt ->stream_index]->priv_data;
 MXFStreamContext *sc2 = s->streams[next->stream_index]->priv_data;
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 11/13] avformat/mux: Fix memleaks on errors II, improve documentation

2019-08-12 Thread Andreas Rheinhardt
1. When an error happened in ff_interleave_add_packet during
interleaving a packet for output, said packet would not be unreferenced
in ff_interleave_add_packet, but would be zeroed in
av_interleaved_write_frame, which results in a memleak.
2. When no error happened in ff_interleave_add_packet during
interleaving a packet for output, the input packet will already be blank
(as if av_packet_unref had been applied to it), but it will
nevertheless be zeroed and initialized again. This is unnecessary.

Given the possibility of using other functions for interleavement than
ff_interleave_packet_per_dts, this commit sets and documents what
interleavement functions need to do: On success, the input packet (if
given) should be a blank packet on return. On failure, cleaning up will
be done by av_interleave_write_frame (where the already existing code
for error handling can be reused). ff_audio_rechunk_interleave has been
changed to abide by this. In order to keep these requirements
consistent, they are kept in one place that is referenced by the other
documentations.

Updating the documentation incidentally also removed another reference
to AVPacket's destructor.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/audiointerleave.c |  1 +
 libavformat/audiointerleave.h |  4 
 libavformat/avformat.h|  1 +
 libavformat/internal.h| 16 +++-
 libavformat/mux.c | 30 +++---
 5 files changed, 24 insertions(+), 28 deletions(-)

diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
index b7f4113b68..0c0dadf2f9 100644
--- a/libavformat/audiointerleave.c
+++ b/libavformat/audiointerleave.c
@@ -123,6 +123,7 @@ int ff_audio_rechunk_interleave(AVFormatContext *s, 
AVPacket *out, AVPacket *pkt
 aic->fifo_size = new_size;
 }
 av_fifo_generic_write(aic->fifo, pkt->data, pkt->size, NULL);
+av_packet_unref(pkt);
 } else {
 // rewrite pts and dts to be decoded time line position
 pkt->pts = pkt->dts = aic->dts;
diff --git a/libavformat/audiointerleave.h b/libavformat/audiointerleave.h
index f28d5fefcc..99f427c05f 100644
--- a/libavformat/audiointerleave.h
+++ b/libavformat/audiointerleave.h
@@ -47,6 +47,10 @@ void ff_audio_interleave_close(AVFormatContext *s);
  *
  * @param get_packet function will output a packet when streams are correctly 
interleaved.
  * @param compare_ts function will compare AVPackets and decide interleaving 
order.
+ *
+ * Apart from these two functions, this function behaves like 
ff_interleave_packet_per_dts.
+ *
+ * @note  This function must not be used with uncoded audio frames.
  */
 int ff_audio_rechunk_interleave(AVFormatContext *s, AVPacket *out, AVPacket 
*pkt, int flush,
 int (*get_packet)(AVFormatContext *, AVPacket *, 
AVPacket *, int),
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 92c3a89f4b..12aadc0ce7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -558,6 +558,7 @@ typedef struct AVOutputFormat {
 /**
  * A format-specific function for interleavement.
  * If unset, packets will be interleaved by dts.
+ * See the description of ff_interleave_packet_per_dts for details.
  */
 int (*interleave_packet)(struct AVFormatContext *, AVPacket *out,
  AVPacket *in, int flush);
diff --git a/libavformat/internal.h b/libavformat/internal.h
index d6a039c497..ea6f65fecf 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -232,9 +232,9 @@ char *ff_data_to_hex(char *buf, const uint8_t *src, int 
size, int lowercase);
 int ff_hex_to_data(uint8_t *data, const char *p);
 
 /**
- * Add packet to AVFormatContext->packet_buffer list, determining its
+ * Add packet to an AVFormatContext's packet_buffer list, determining its
  * interleaved position using compare() function argument.
- * @return 0, or < 0 on error
+ * @return 0, or < 0 on error. On success, pkt will be blank (as if 
unreferenced).
  */
 int ff_interleave_add_packet(AVFormatContext *s, AVPacket *pkt,
  int (*compare)(AVFormatContext *, const AVPacket 
*, const AVPacket *));
@@ -497,15 +497,13 @@ int ff_framehash_write_header(AVFormatContext *s);
 int ff_read_packet(AVFormatContext *s, AVPacket *pkt);
 
 /**
- * Interleave a packet per dts in an output media file.
- *
- * Packets with pkt->destruct == av_destruct_packet will be freed inside this
- * function, so they cannot be used after it. Note that calling 
av_packet_unref()
- * on them is still safe.
+ * Interleave an AVPacket per dts so it can be muxed.
  *
- * @param s media file handle
+ * @param s   an AVFormatContext for output. in resp. out will be added to
+ *resp. taken from its packet buffer.
  * @param out the interleaved packet will be output here
- * @param pkt the input packet
+ * @param in  the input packet. If not NULL will be a blank packet
+ * 

[FFmpeg-devel] [PATCH 02/13] avformat/mux: Don't unnecessarily zero-initialize AVPacketList

2019-08-12 Thread Andreas Rheinhardt
If no error occurs and this AVPacketList is used at all, its packet
substructure will be overwritten and its next pointer explicitly set, so
every field will still be initialized even when using av_malloc.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index ac370fb24d..870e716950 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -924,7 +924,7 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 AVStream *st   = s->streams[pkt->stream_index];
 int chunked= s->max_chunk_size || s->max_chunk_duration;
 
-this_pktl  = av_mallocz(sizeof(AVPacketList));
+this_pktl  = av_malloc(sizeof(AVPacketList));
 if (!this_pktl)
 return AVERROR(ENOMEM);
 if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 05/13] avformat/mux: Only prepare input packet if there is a packet

2019-08-12 Thread Andreas Rheinhardt
It is unnecessary to call prepare_input_packet if there is no packet as
it doesn't do anything, except when the currently inactive code guarded
by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active:
Then attempting to access pkt->stream_index will crash.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 4089382ffd..44ce099cbf 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -763,9 +763,6 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 
 static int check_packet(AVFormatContext *s, AVPacket *pkt)
 {
-if (!pkt)
-return 0;
-
 if (pkt->stream_index < 0 || pkt->stream_index >= s->nb_streams) {
 av_log(s, AV_LOG_ERROR, "Invalid packet stream index: %d\n",
pkt->stream_index);
@@ -879,10 +876,6 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 {
 int ret;
 
-ret = prepare_input_packet(s, pkt);
-if (ret < 0)
-return ret;
-
 if (!pkt) {
 if (s->oformat->flags & AVFMT_ALLOW_FLUSH) {
 ret = s->oformat->write_packet(s, NULL);
@@ -894,6 +887,10 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 return 1;
 }
 
+ret = prepare_input_packet(s, pkt);
+if (ret < 0)
+return ret;
+
 ret = do_packet_auto_bsf(s, pkt);
 if (ret <= 0)
 return ret;
@@ -1189,12 +1186,12 @@ int av_interleaved_write_frame(AVFormatContext *s, 
AVPacket *pkt)
 {
 int ret, flush = 0;
 
-ret = prepare_input_packet(s, pkt);
-if (ret < 0)
-goto fail;
-
 if (pkt) {
-AVStream *st = s->streams[pkt->stream_index];
+AVStream *st;
+
+ret = prepare_input_packet(s, pkt);
+if (ret < 0)
+goto fail;
 
 ret = do_packet_auto_bsf(s, pkt);
 if (ret == 0)
@@ -1207,6 +1204,7 @@ int av_interleaved_write_frame(AVFormatContext *s, 
AVPacket *pkt)
 pkt->size, av_ts2str(pkt->dts), av_ts2str(pkt->pts));
 
 #if FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX
+st = s->streams[pkt->stream_index];
 if ((ret = compute_muxer_pkt_fields(s, st, pkt)) < 0 && 
!(s->oformat->flags & AVFMT_NOTIMESTAMPS))
 goto fail;
 #endif
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 07/13] avformat/audiointerleave: Fix memleak

2019-08-12 Thread Andreas Rheinhardt
If ff_interleave_add_packet failed, the content of the newly created
packet new_pkt would leak.

Also, it is unnecessary to zero-initialize a packet that will be put
into av_new_packet lateron as the latter already initializes the packet.
Therefore this has been removed, too.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/audiointerleave.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/audiointerleave.c b/libavformat/audiointerleave.c
index b602eb7105..b7f4113b68 100644
--- a/libavformat/audiointerleave.c
+++ b/libavformat/audiointerleave.c
@@ -136,10 +136,12 @@ int ff_audio_rechunk_interleave(AVFormatContext *s, 
AVPacket *out, AVPacket *pkt
 for (i = 0; i < s->nb_streams; i++) {
 AVStream *st = s->streams[i];
 if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-AVPacket new_pkt = { 0 };
+AVPacket new_pkt;
 while ((ret = interleave_new_audio_packet(s, _pkt, i, flush)) 
> 0) {
-if ((ret = ff_interleave_add_packet(s, _pkt, compare_ts)) 
< 0)
+if ((ret = ff_interleave_add_packet(s, _pkt, compare_ts)) 
< 0) {
+av_packet_unref(_pkt);
 return ret;
+}
 }
 if (ret < 0)
 return ret;
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 01/13] avformat/mux: Move packet references

2019-08-12 Thread Andreas Rheinhardt
In the common case that the input packet was already refcounted,
ff_interleave_add_packet would allocate a new AVPacketList, use
av_packet_ref to create a new reference to the buffer for the
AVPacketList's packet, interleave the packet and finally unreference
the original input packet.
This commit changes this: It uses av_packet_move_ref to transfer
the packet to its destination. In case the input packet is refcounted,
this saves an allocation and a free (of an AVBufferRef); if not, the
packet is made refcounted before moving it. When the input packet has
side data, one saves even more than one allocation+free.

Furthermore, when the packet is in reality an uncoded frame, a hacky
ad-hoc variant of av_packet_move_ref has been employed. Not any more.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mux.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 8ab5ea8c2b..ac370fb24d 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -930,17 +930,16 @@ int ff_interleave_add_packet(AVFormatContext *s, AVPacket 
*pkt,
 if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
 av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
 av_assert0(((AVFrame *)pkt->data)->buf);
-this_pktl->pkt = *pkt;
-pkt->buf = NULL;
-pkt->side_data = NULL;
-pkt->side_data_elems = 0;
 } else {
-if ((ret = av_packet_ref(_pktl->pkt, pkt)) < 0) {
+if ((ret = av_packet_make_refcounted(pkt)) < 0) {
 av_free(this_pktl);
 return ret;
 }
 }
 
+av_packet_move_ref(_pktl->pkt, pkt);
+pkt = _pktl->pkt;
+
 if (s->streams[pkt->stream_index]->last_in_packet_buffer) {
 next_point = &(st->last_in_packet_buffer->next);
 } else {
@@ -989,8 +988,6 @@ next_non_null:
 s->streams[pkt->stream_index]->last_in_packet_buffer =
 *next_point  = this_pktl;
 
-av_packet_unref(pkt);
-
 return 0;
 }
 
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates

2019-08-12 Thread Fu, Linjie
> -Original Message-
> From: Aman Gupta [mailto:a...@tmm1.net] On Behalf Of Aman Gupta
> Sent: Tuesday, August 13, 2019 09:05
> To: ffmpeg-devel@ffmpeg.org
> Cc: s...@jkqxz.net; Fu, Linjie ; Aman Gupta
> 
> Subject: [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates
> 
> From: Aman Gupta 
> 
> On some Intel chips, sending VAEncMiscParameterTypeRateControl multiple
> times causes the encoder to produce very low bitrates that do not match
> the requested rate controls.
> 
> This is a regression as of af532c921575eb8ee805cc2c64a914f6302442e1. Prior
> to that global params were sent only once at the start of the
> encoding session.
> 
> The broken VBR behavior was observed on:
> 
>   - i5-7260U Kaby Lake
>   - N3060 CherryView
>   - N3710 CherryView
>   - J3455 Broxton
> 
> /cc intel/intel-vaapi-driver#480

If it's a driver related issue, IMHO we'd better have it fixed in specific 
driver.
Also commented on #480.

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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter/f_select: yuv will use Y plane only for scenecut detect

2019-08-12 Thread Limin Wang
On Mon, Aug 12, 2019 at 11:03:24PM +0200, Marton Balint wrote:
> 
> 
> On Mon, 12 Aug 2019, lance.lmw...@gmail.com wrote:
> 
> >From: Limin Wang 
> >
> >Signed-off-by: Limin Wang 
> >---
> >libavfilter/f_select.c |  3 ++-
> >tests/ref/fate/filter-metadata-scenedetect | 16 
> >2 files changed, 10 insertions(+), 9 deletions(-)
> >
> >diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
> >index 5c7372c976..25a36ff0fa 100644
> >--- a/libavfilter/f_select.c
> >+++ b/libavfilter/f_select.c
> >@@ -211,7 +211,8 @@ static int config_input(AVFilterLink *inlink)
> >const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> >
> >select->bitdepth = desc->comp[0].depth;
> >-select->nb_planes = av_pix_fmt_count_planes(inlink->format);
> >+select->nb_planes = desc->flags & AV_PIX_FMT_FLAG_PLANAR ? 1 : 
> >av_pix_fmt_count_planes(inlink->format);
> >+
> 
> This is very misleading even if it happens to work for the currently
> supported formats.
> 
> An is_yuv variable is good to have, because it says what we want,
> which is limit the number of planes only for YUV. So please use the
> previosuly suggested
> 
> int is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) &&
>  (desc->flags & AV_PIX_FMT_FLAG_PLANAR) &&
>  desc->nb_components >= 3;
> 

OK, it's more clean, please checking the last update version.(please ignore the 
first two)


> (copied from tiff.c by the way) definition.
> 
> Thanks,
> Marton
> 
> 
> >for (int plane = 0; plane < select->nb_planes; plane++) {
> >ptrdiff_t line_size = av_image_get_linesize(inlink->format, 
> > inlink->w, plane);
> >int vsub = desc->log2_chroma_h;
> >diff --git a/tests/ref/fate/filter-metadata-scenedetect 
> >b/tests/ref/fate/filter-metadata-scenedetect
> >index 7ce2d6794e..36c033bc0e 100644
> >--- a/tests/ref/fate/filter-metadata-scenedetect
> >+++ b/tests/ref/fate/filter-metadata-scenedetect
> >@@ -1,11 +1,11 @@
> >pkt_pts=1620|tag:lavfi.scene_score=1.00
> >-pkt_pts=4140|tag:lavfi.scene_score=0.668643
> >-pkt_pts=5800|tag:lavfi.scene_score=0.996721
> >-pkt_pts=6720|tag:lavfi.scene_score=0.357390
> >-pkt_pts=8160|tag:lavfi.scene_score=0.886268
> >-pkt_pts=9760|tag:lavfi.scene_score=0.926219
> >-pkt_pts=14080|tag:lavfi.scene_score=0.650033
> >+pkt_pts=4140|tag:lavfi.scene_score=0.923403
> >+pkt_pts=5800|tag:lavfi.scene_score=1.00
> >+pkt_pts=6720|tag:lavfi.scene_score=0.475643
> >+pkt_pts=8160|tag:lavfi.scene_score=1.00
> >+pkt_pts=9760|tag:lavfi.scene_score=1.00
> >+pkt_pts=14080|tag:lavfi.scene_score=0.874623
> >pkt_pts=15700|tag:lavfi.scene_score=1.00
> >-pkt_pts=18500|tag:lavfi.scene_score=0.316402
> >-pkt_pts=20040|tag:lavfi.scene_score=0.269509
> >+pkt_pts=18500|tag:lavfi.scene_score=0.422509
> >+pkt_pts=20040|tag:lavfi.scene_score=0.352360
> >pkt_pts=21760|tag:lavfi.scene_score=1.00
> >-- 
> >2.21.0
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >To unsubscribe, visit link above, or email
> >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v3] avfilter/f_select: yuv will use Y plane only for scenecut detect

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/f_select.c |  6 +-
 tests/ref/fate/filter-metadata-scenedetect | 16 
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 5c7372c976..755e10a399 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -209,9 +209,13 @@ static int config_input(AVFilterLink *inlink)
 {
 SelectContext *select = inlink->dst->priv;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+int is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) &&
+ (desc->flags & AV_PIX_FMT_FLAG_PLANAR) &&
+ desc->nb_components >= 3;
 
 select->bitdepth = desc->comp[0].depth;
-select->nb_planes = av_pix_fmt_count_planes(inlink->format);
+select->nb_planes = is_yuv ? 1 : av_pix_fmt_count_planes(inlink->format);
+
 for (int plane = 0; plane < select->nb_planes; plane++) {
 ptrdiff_t line_size = av_image_get_linesize(inlink->format, inlink->w, 
plane);
 int vsub = desc->log2_chroma_h;
diff --git a/tests/ref/fate/filter-metadata-scenedetect 
b/tests/ref/fate/filter-metadata-scenedetect
index 7ce2d6794e..36c033bc0e 100644
--- a/tests/ref/fate/filter-metadata-scenedetect
+++ b/tests/ref/fate/filter-metadata-scenedetect
@@ -1,11 +1,11 @@
 pkt_pts=1620|tag:lavfi.scene_score=1.00
-pkt_pts=4140|tag:lavfi.scene_score=0.668643
-pkt_pts=5800|tag:lavfi.scene_score=0.996721
-pkt_pts=6720|tag:lavfi.scene_score=0.357390
-pkt_pts=8160|tag:lavfi.scene_score=0.886268
-pkt_pts=9760|tag:lavfi.scene_score=0.926219
-pkt_pts=14080|tag:lavfi.scene_score=0.650033
+pkt_pts=4140|tag:lavfi.scene_score=0.923403
+pkt_pts=5800|tag:lavfi.scene_score=1.00
+pkt_pts=6720|tag:lavfi.scene_score=0.475643
+pkt_pts=8160|tag:lavfi.scene_score=1.00
+pkt_pts=9760|tag:lavfi.scene_score=1.00
+pkt_pts=14080|tag:lavfi.scene_score=0.874623
 pkt_pts=15700|tag:lavfi.scene_score=1.00
-pkt_pts=18500|tag:lavfi.scene_score=0.316402
-pkt_pts=20040|tag:lavfi.scene_score=0.269509
+pkt_pts=18500|tag:lavfi.scene_score=0.422509
+pkt_pts=20040|tag:lavfi.scene_score=0.352360
 pkt_pts=21760|tag:lavfi.scene_score=1.00
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v3] avfilter/f_select: yuv will use Y plane only for scenecut detect

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/f_select.c |  5 -
 tests/ref/fate/filter-metadata-scenedetect | 16 
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 5c7372c976..c8d30dd226 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -209,9 +209,12 @@ static int config_input(AVFilterLink *inlink)
 {
 SelectContext *select = inlink->dst->priv;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+int is_yuv;
 
 select->bitdepth = desc->comp[0].depth;
-select->nb_planes = av_pix_fmt_count_planes(inlink->format);
+is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) && desc->nb_components >= 3;
+select->nb_planes = is_yuv ? 1 : av_pix_fmt_count_planes(inlink->format);
+
 for (int plane = 0; plane < select->nb_planes; plane++) {
 ptrdiff_t line_size = av_image_get_linesize(inlink->format, inlink->w, 
plane);
 int vsub = desc->log2_chroma_h;
diff --git a/tests/ref/fate/filter-metadata-scenedetect 
b/tests/ref/fate/filter-metadata-scenedetect
index 7ce2d6794e..36c033bc0e 100644
--- a/tests/ref/fate/filter-metadata-scenedetect
+++ b/tests/ref/fate/filter-metadata-scenedetect
@@ -1,11 +1,11 @@
 pkt_pts=1620|tag:lavfi.scene_score=1.00
-pkt_pts=4140|tag:lavfi.scene_score=0.668643
-pkt_pts=5800|tag:lavfi.scene_score=0.996721
-pkt_pts=6720|tag:lavfi.scene_score=0.357390
-pkt_pts=8160|tag:lavfi.scene_score=0.886268
-pkt_pts=9760|tag:lavfi.scene_score=0.926219
-pkt_pts=14080|tag:lavfi.scene_score=0.650033
+pkt_pts=4140|tag:lavfi.scene_score=0.923403
+pkt_pts=5800|tag:lavfi.scene_score=1.00
+pkt_pts=6720|tag:lavfi.scene_score=0.475643
+pkt_pts=8160|tag:lavfi.scene_score=1.00
+pkt_pts=9760|tag:lavfi.scene_score=1.00
+pkt_pts=14080|tag:lavfi.scene_score=0.874623
 pkt_pts=15700|tag:lavfi.scene_score=1.00
-pkt_pts=18500|tag:lavfi.scene_score=0.316402
-pkt_pts=20040|tag:lavfi.scene_score=0.269509
+pkt_pts=18500|tag:lavfi.scene_score=0.422509
+pkt_pts=20040|tag:lavfi.scene_score=0.352360
 pkt_pts=21760|tag:lavfi.scene_score=1.00
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector

2019-08-12 Thread Reimar Döffinger
On 12.08.2019, at 21:53, Michael Niedermayer  wrote:

> On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
>> On 08.08.2019, at 10:36, Michael Niedermayer  wrote:
>> 
>>> This provides an alternative to retry counters.
>>> Useful if there is no reasonable maximum number of iterations and
>>> no ordering that naturally avoids loops.
>> 
>> Going by the old principle of "an API is not tested until it has at least 3 
>> users"
>> might it make sense to delay this until we've found and tested it in a few 
>> use-cases?
>> Depending on how much hurry there is to get the bug-fix in.
> 
>> I assume there is also an actual bug-fix patch somewhere, maybe we should 
>> have that
>> in the same patch series to make it easier to review the actual usage?
> 
> sure will repost this eventually with 3+ bugfixes.
> But wont search for such bugs ATM as ive too many other things to do
> so it might take a bit of time before i do

Of course.
Though on re-considering: if it is added as a purely internal API that we can 
change at any
time and we do not need to think on backwards compatibility (and a comment on 
the file
that we might want to have and review use-cases before making it public) I 
would have
no objections.
I realized only being locked-in compatibility-wise had me worried at this point 
actually.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v3] avfilter/f_select: yuv will use Y plane only for scenecut detect

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/f_select.c |  5 -
 tests/ref/fate/filter-metadata-scenedetect | 16 
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 5c7372c976..c8d30dd226 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -209,9 +209,12 @@ static int config_input(AVFilterLink *inlink)
 {
 SelectContext *select = inlink->dst->priv;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+int is_yuv;
 
 select->bitdepth = desc->comp[0].depth;
-select->nb_planes = av_pix_fmt_count_planes(inlink->format);
+is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) && desc->nb_components >= 3;
+select->nb_planes = is_yuv ? 1 : av_pix_fmt_count_planes(inlink->format);
+
 for (int plane = 0; plane < select->nb_planes; plane++) {
 ptrdiff_t line_size = av_image_get_linesize(inlink->format, inlink->w, 
plane);
 int vsub = desc->log2_chroma_h;
diff --git a/tests/ref/fate/filter-metadata-scenedetect 
b/tests/ref/fate/filter-metadata-scenedetect
index 7ce2d6794e..36c033bc0e 100644
--- a/tests/ref/fate/filter-metadata-scenedetect
+++ b/tests/ref/fate/filter-metadata-scenedetect
@@ -1,11 +1,11 @@
 pkt_pts=1620|tag:lavfi.scene_score=1.00
-pkt_pts=4140|tag:lavfi.scene_score=0.668643
-pkt_pts=5800|tag:lavfi.scene_score=0.996721
-pkt_pts=6720|tag:lavfi.scene_score=0.357390
-pkt_pts=8160|tag:lavfi.scene_score=0.886268
-pkt_pts=9760|tag:lavfi.scene_score=0.926219
-pkt_pts=14080|tag:lavfi.scene_score=0.650033
+pkt_pts=4140|tag:lavfi.scene_score=0.923403
+pkt_pts=5800|tag:lavfi.scene_score=1.00
+pkt_pts=6720|tag:lavfi.scene_score=0.475643
+pkt_pts=8160|tag:lavfi.scene_score=1.00
+pkt_pts=9760|tag:lavfi.scene_score=1.00
+pkt_pts=14080|tag:lavfi.scene_score=0.874623
 pkt_pts=15700|tag:lavfi.scene_score=1.00
-pkt_pts=18500|tag:lavfi.scene_score=0.316402
-pkt_pts=20040|tag:lavfi.scene_score=0.269509
+pkt_pts=18500|tag:lavfi.scene_score=0.422509
+pkt_pts=20040|tag:lavfi.scene_score=0.352360
 pkt_pts=21760|tag:lavfi.scene_score=1.00
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v2 1/2] vaapi_encode: ensure correct VBR bitrate is used in h264 SPS

2019-08-12 Thread Aman Gupta
From: Aman Gupta 

This is a regression from 2562dd9e7831743ba6dc5680501fb7d26a2ec62c
which surfaces a pathological bug in some Intel hardware encoders,
causing very low bitrates to be generated whenever VBR mode is used.

/cc intel/intel-vaapi-driver#480

Signed-off-by: Aman Gupta 
---
 libavcodec/vaapi_encode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e69b59fa37..231efba6cc 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1665,6 +1665,9 @@ rc_mode_found:
 ctx->va_rc_mode  = rc_mode->va_mode;
 ctx->va_bit_rate = rc_bits_per_second;
 
+if (ctx->va_rc_mode == VA_RC_VBR)
+ctx->va_bit_rate = rc_bits_per_second * rc_target_percentage / 100;
+
 av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode->name);
 if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
 // This driver does not want the RC mode attribute to be set.
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates

2019-08-12 Thread Aman Gupta
From: Aman Gupta 

On some Intel chips, sending VAEncMiscParameterTypeRateControl multiple
times causes the encoder to produce very low bitrates that do not match
the requested rate controls.

This is a regression as of af532c921575eb8ee805cc2c64a914f6302442e1. Prior
to that global params were sent only once at the start of the
encoding session.

The broken VBR behavior was observed on:

  - i5-7260U Kaby Lake
  - N3060 CherryView
  - N3710 CherryView
  - J3455 Broxton

/cc intel/intel-vaapi-driver#480

Signed-off-by: Aman Gupta 
---
 libavcodec/vaapi_encode.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 231efba6cc..960f8230de 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -236,6 +236,12 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 
 if (pic->type == PICTURE_TYPE_IDR) {
 for (i = 0; i < ctx->nb_global_params; i++) {
+if (pic->encode_order != 0 &&
+ctx->global_params_type[i] == 
VAEncMiscParameterTypeRateControl &&
+ctx->va_rc_mode == VA_RC_VBR) {
+// send VAEncMiscParameterTypeRateControl only once in VBR mode
+continue;
+}
 err = vaapi_encode_make_misc_param_buffer(avctx, pic,
   
ctx->global_params_type[i],
   ctx->global_params[i],
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from x264

2019-08-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Darnley
> Sent: Monday, August 5, 2019 9:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from
> x264
> 
> Here are a few easy-to-import patches from x264.  These are all after x264
> commit 4a158b00 "x86inc: Correctly set mmreg variables" which FFmpeg
> already
> has (commit eb5f063e7c).
> 
> It does not include the following commits:
> * 82721eae "x86inc: Add x86-32 PIC support macros"
> * 101bd27d "x86inc: Support N_PEXT bit on Mach-O"
> 
> They would not apply cleanly because of existing differences between x264
> and
> FFmpeg.  The PIC one has a change to configure which would need remaking.
> 
> Henrik Gramner (7):
>   x86inc: Fix VEX -> EVEX instruction conversion
>   x86inc: Optimize VEX instruction encoding
>   x86inc: Improve SAVE/LOAD_MM_PERMUTATION macros
>   x86inc: Turn 'movsxd' into 'movifnidn' on x86-32
>   x86inc: Make 'non-adjacent' default in the TAIL_CALL macro
>   x86inc: Improve warnings for use of unsupported instructions
>   x86inc: Add support for GFNI instructions
> 
>  libavutil/x86/x86inc.asm | 219 ---
>  1 file changed, 161 insertions(+), 58 deletions(-)
> 
I think it is a good idea to apply such changes. No sure if anybody else has 
different opinion.

Ruiling
> --
> 2.22.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures

2019-08-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Rheinhardt
> Sent: Monday, August 12, 2019 9:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures
> 
> 98e419cb added SIMD for the convolution filter for x64 systems. As
> usual, it used a check of the form
> if (ARCH_X86_64)
> ff_convolution_init_x86(s);
> and thereby relied on the compiler eliminating this pseudo-runtime check
> at compiletime for non x64 systems (for which ff_convolution_init_x86
> isn't defined) to compile. But vf_convolution.c contains more than one
> filter and if the convolution filter is disabled, but one of the other
> filters (prewitt, sobel, roberts) is enabled, the build will fail on x64,
> because ff_convolution_init_x86 isn't defined in this case.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
Will apply.

> Found via ubitux2's random FATE box:
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-random
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] vaapi_encode: ensure correct VBR bitrate is used in h264 SPS

2019-08-12 Thread Aman Gupta
From: Aman Gupta 

This is a regression from 2562dd9e7831743ba6dc5680501fb7d26a2ec62c
which surfaces a pathological bug in the Intel Broxton/CherryView
hardware encoders, causing very low bitrates to be generated
whenever VBR mode is used.

/cc intel/intel-vaapi-driver#480

Signed-off-by: Aman Gupta 
---
 libavcodec/vaapi_encode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e69b59fa37..231efba6cc 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1665,6 +1665,9 @@ rc_mode_found:
 ctx->va_rc_mode  = rc_mode->va_mode;
 ctx->va_bit_rate = rc_bits_per_second;
 
+if (ctx->va_rc_mode == VA_RC_VBR)
+ctx->va_bit_rate = rc_bits_per_second * rc_target_percentage / 100;
+
 av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode->name);
 if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
 // This driver does not want the RC mode attribute to be set.
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/2] vaapi_encode: work-around VBR driver bug in Intel Broxton/CherryView

2019-08-12 Thread Aman Gupta
From: Aman Gupta 

The hardware encoder on these chipsets produces very low bitrates
in VBR mode if it receives VAEncMiscParameterTypeRateControl more than once.

/cc intel/intel-vaapi-driver#480

Signed-off-by: Aman Gupta 
---
 libavcodec/vaapi_encode.c   |  8 +++-
 libavutil/hwcontext_vaapi.c | 10 ++
 libavutil/hwcontext_vaapi.h |  6 ++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 231efba6cc..a5f46cdee0 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -163,7 +163,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 VAAPIEncodeContext *ctx = avctx->priv_data;
 VAAPIEncodeSlice *slice;
 VAStatus vas;
-int err, i;
+int err, i, send_global_params;
 char data[MAX_PARAM_BUFFER_SIZE];
 size_t bit_len;
 av_unused AVFrameSideData *sd;
@@ -236,6 +236,12 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 
 if (pic->type == PICTURE_TYPE_IDR) {
 for (i = 0; i < ctx->nb_global_params; i++) {
+if (pic->encode_order != 0 &&
+ctx->global_params_type[i] == 
VAEncMiscParameterTypeRateControl &&
+ctx->hwctx->driver_quirks & 
AV_VAAPI_DRIVER_QUIRK_RC_PARAMS_ONCE) {
+// send VAEncMiscParameterTypeRateControl only once to 
affected drivers
+continue;
+}
 err = vaapi_encode_make_misc_param_buffer(avctx, pic,
   
ctx->global_params_type[i],
   ctx->global_params[i],
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index cf117640f2..a206ce8880 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -323,6 +323,16 @@ static const struct {
 "Splitted-Desktop Systems VDPAU backend for VA-API",
 AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
 },
+{
+"Intel Broxton",
+"Intel(R) Broxton",
+AV_VAAPI_DRIVER_QUIRK_RC_PARAMS_ONCE,
+},
+{
+"Intel CherryView",
+"Intel(R) CherryView",
+AV_VAAPI_DRIVER_QUIRK_RC_PARAMS_ONCE,
+},
 };
 
 static int vaapi_device_init(AVHWDeviceContext *hwdev)
diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
index 0b2e071cb3..ea4181fab0 100644
--- a/libavutil/hwcontext_vaapi.h
+++ b/libavutil/hwcontext_vaapi.h
@@ -58,6 +58,12 @@ enum {
  * and the results of the vaQuerySurfaceAttributes() call will be faked.
  */
 AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES = (1 << 3),
+
+/**
+ * The driver does not react well to receiving global parameters with
+ * every IDR frame.
+ */
+AV_VAAPI_DRIVER_QUIRK_RC_PARAMS_ONCE = (1 << 4),
 };
 
 /**
-- 
2.20.1

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

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

Re: [FFmpeg-devel] [PATCH V2] Fixes compiler bug - replace vec_lvsl/vec_perm with vec_xl

2019-08-12 Thread Carl Eugen Hoyos
Am Fr., 2. Aug. 2019 um 17:24 Uhr schrieb ckerchne
:
>
> A bug exist with the gcc compilers for Power in versions 6.x and 7.x
> (verified with 6.3 and 7.4). It was fixed in version 8.x (verified with
> 8.3). I was using a Power 9 ppc64le machine for building and testing.
> This is to address ticket #7124.
>
> It appears the compiler is generating the wrong code for little endian
> machines for the vec_lvsl/vec_perm instruction combos in some cases. If
> these instructions are replaced with vec_xl, the problem goes away for
> all versions of the compilers

I tested with gcc 7 (gcc 6 fails compilation for ppc64le) and was unable
to see a speed difference on be, so pushed.

For future patches: Please provide patches as made by git format-patch,
not diff files.

Thank you for the fix, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 6/8] avcodec/decode: Do not overwrite AVFrame.pkt_pos if its already set

2019-08-12 Thread James Almer
On 8/12/2019 5:31 PM, Michael Niedermayer wrote:
> On Mon, Aug 12, 2019 at 09:21:59PM +0200, Vittorio Giovara wrote:
>> On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer 
>> wrote:
>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/decode.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 6c31166ec2..09a509d659 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -435,7 +435,7 @@ static int decode_simple_internal(AVCodecContext
>>> *avctx, AVFrame *frame)
>>>  if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
>>>  frame->pkt_dts = pkt->dts;
>>>  if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
>>> -if(!avctx->has_b_frames)
>>> +if(!avctx->has_b_frames && frame->pkt_pos < 0)
>>>  frame->pkt_pos = pkt->pos;
>>>  //FIXME these should be under if(!avctx->has_b_frames)
>>>  /* get_buffer is supposed to set frame parameters */
>>> --
>>>
>>
>> sure but why?
> 
> the next 2 patches need this
> [FFmpeg-devel] [PATCH 7/8] avcodec/qtrle: return last frame even if unchanged
> [FFmpeg-devel] [PATCH 8/8] avcodec/nuv: Avoid duplicating frames
> 
> without it the common code overwrites the pkt_pos set by the decoder

What about rawdec.c? It's also setting frame->pkt_pos.

And cant' this be handled with a new internal codec cap like the pkt_dts
one used above?

> 
> thx
> 
> [...]
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

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

Re: [FFmpeg-devel] [PATCH V1 1/2] lavf/avio: add a ffio_realloc_buf API for AVIO buffer realloc

2019-08-12 Thread Steven Liu


> 在 2019年8月12日,20:29,myp...@gmail.com 写道:
> 
> On Sun, Aug 11, 2019 at 4:43 PM Steven Liu  wrote:
>> 
>> 
>> 
>>> 在 2019年8月8日,19:32,Jun Zhao  写道:
>>> 
>>> From: tomajsjiang 
>>> 
>>> Add new API ffio_realloc_buf for AVIO buffer realloc.
>>> 
>>> Signed-off-by: Zhongxing Jiang 
>>> ---
>>> libavformat/avio_internal.h |9 +
>>> libavformat/aviobuf.c   |   31 +++
>>> 2 files changed, 40 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
>>> index 04c1ad5..eb628ac 100644
>>> --- a/libavformat/avio_internal.h
>>> +++ b/libavformat/avio_internal.h
>>> @@ -87,6 +87,15 @@ int ffio_read_size(AVIOContext *s, unsigned char *buf, 
>>> int size);
>>> int ffio_set_buf_size(AVIOContext *s, int buf_size);
>>> 
>>> /**
>>> + * Reallocate a given buffer for AVIOContext.
>>> + *
>>> + * @param s the AVIOContext to realloc.
>>> + * @param buf_size required new buffer size.
>>> + * @return 0 on success, a negative AVERROR on failure.
>>> + */
>>> +int ffio_realloc_buf(AVIOContext *s, int buf_size);
>>> +
>>> +/**
>>> * Ensures that the requested seekback buffer size will be available
>>> *
>>> * Will ensure that when reading sequentially up to buf_size, seeking
>>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>>> index 2d01102..3b59180 100644
>>> --- a/libavformat/aviobuf.c
>>> +++ b/libavformat/aviobuf.c
>>> @@ -1093,6 +1093,37 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size)
>>>return 0;
>>> }
>>> 
>>> +int ffio_realloc_buf(AVIOContext *s, int buf_size)
>>> +{
>>> +uint8_t *buffer;
>>> +int data_size;
>>> +
>>> +if (!s->buffer_size)
>>> +return ffio_set_buf_size(s, buf_size);
>>> +
>>> +if (buf_size <= s->buffer_size)
>>> +return 0;
>>> +
>>> +buffer = av_malloc(buf_size);
>>> +if (!buffer)
>>> +return AVERROR(ENOMEM);
>>> +
>>> +data_size = s->write_flag ? (s->buf_ptr - s->buffer) : (s->buf_end - 
>>> s->buf_ptr);
>>> +if (data_size > 0)
>>> +memcpy(buffer, s->write_flag ? s->buffer : s->buf_ptr, data_size);
>>> +av_free(s->buffer);
>>> +s->buffer = buffer;
>>> +s->orig_buffer_size = buf_size;
>>> +s->buffer_size = buf_size;
>>> +s->buf_ptr = s->write_flag ? (s->buffer + data_size) : s->buffer;
>>> +if (s->write_flag)
>>> +s->buf_ptr_max = s->buffer + data_size;
>>> +
>>> +s->buf_end = s->write_flag ? (s->buffer + s->buffer_size) : 
>>> (s->buf_ptr + data_size);
>>> +
>>> +return 0;
>>> +}
>>> +
>>> static int url_resetbuf(AVIOContext *s, int flags)
>>> {
>>>av_assert1(flags == AVIO_FLAG_WRITE || flags == AVIO_FLAG_READ);
>>> --
>>> 1.7.1
>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
>> 
>> patchset LGTM
>> 
>> btw, maybe this should bump version.h ?
>> 
> ffio_realloc_buf is an internal function, I don't know is it needed to
> bump the version.
yes you are right :)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Thanks
Steven





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

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

Re: [FFmpeg-devel] [PATCH 1/2] fftools: Use right function signature and pointers

2019-08-12 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> The option tables of the various fftools (in particular ffprobe) are
> arrays of OptionDef; said type contains a union of a pointer to void and
> a function pointer of type int (*)(void *, const char *, const char *)
> as well as a size_t. Some entries (namely the common entry for writing a
> report as well as several more of ffprobe's entries) used the pointer to
> void to store a pointer to functions of type int (*)(const char *) or
> type int (*)(const char *, const char *); nevertheless, when the functions
> are actually called in write_option (in cmdutils.c), it is done via a
> pointer of the first type.
> 
> There are two things wrong here:
> 1. Pointer to void can be converted to any pointer to incomplete or
> object type and back; but they are nevertheless not completely generic
> pointers: There is no provision in the C standard that guarantees their
> convertibility with function pointers. C90 lacks a generic function
> pointer, C99 made every function pointer a generic function pointer and
> still disallows the convertibility with void *.
> 2. The signature of the called function differs from the signature
> of the pointed-to type. This is undefined behaviour in C99 (given that
> C90 lacks a way to convert function pointers at all, it doesn't say
> anything about such a situation). It only works because none of the
> functions this patch is about make any use of their parameters at all.
> 
> Therefore this commit changes the type of the relevant functions
> to match the type used for the call and uses the union's function
> pointer to store it. This is legal even in C90.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> There are other places in the codebase that use a pointer to void to
> store a function pointer. Should they be changed or not?
> 
>  fftools/cmdutils.c |  2 +-
>  fftools/cmdutils.h |  4 ++--
>  fftools/ffprobe.c  | 26 +-
>  3 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..fdcd376b76 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -1046,7 +1046,7 @@ static int init_report(const char *env)
>  return 0;
>  }
>  
> -int opt_report(const char *opt)
> +int opt_report(void *optctx, const char *opt, const char *arg)
>  {
>  return init_report(NULL);
>  }
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..1917510589 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -99,7 +99,7 @@ int opt_default(void *optctx, const char *opt, const char 
> *arg);
>   */
>  int opt_loglevel(void *optctx, const char *opt, const char *arg);
>  
> -int opt_report(const char *opt);
> +int opt_report(void *optctx, const char *opt, const char *arg);
>  
>  int opt_max_alloc(void *optctx, const char *opt, const char *arg);
>  
> @@ -236,7 +236,7 @@ void show_help_options(const OptionDef *options, const 
> char *msg, int req_flags,
>  { "colors",  OPT_EXIT, { .func_arg = show_colors },  
> "show available color names" },\
>  { "loglevel",HAS_ARG,  { .func_arg = opt_loglevel }, 
> "set logging level", "loglevel" }, \
>  { "v",   HAS_ARG,  { .func_arg = opt_loglevel }, 
> "set logging level", "loglevel" }, \
> -{ "report",  0,{ (void*)opt_report },
> "generate a report" }, \
> +{ "report",  0,{ .func_arg = opt_report },   
> "generate a report" }, \
>  { "max_alloc",   HAS_ARG,  { .func_arg = opt_max_alloc },
> "set maximum size of a single allocated block", "bytes" }, \
>  { "cpuflags",HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpuflags }, 
> "force specific cpu flags", "flags" }, \
>  { "hide_banner", OPT_BOOL | OPT_EXPERT, {_banner}, "do not show 
> program banner", "hide_banner" },  \
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 5aaddb0308..2380417229 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -3471,7 +3471,7 @@ static int opt_sections(void *optctx, const char *opt, 
> const char *arg)
>  return 0;
>  }
>  
> -static int opt_show_versions(const char *opt, const char *arg)
> +static int opt_show_versions(void *optctx, const char *opt, const char *arg)
>  {
>  mark_section_show_entries(SECTION_ID_PROGRAM_VERSION, 1, NULL);
>  mark_section_show_entries(SECTION_ID_LIBRARY_VERSION, 1, NULL);
> @@ -3479,7 +3479,7 @@ static int opt_show_versions(const char *opt, const 
> char *arg)
>  }
>  
>  #define DEFINE_OPT_SHOW_SECTION(section, target_section_id) \
> -static int opt_show_##section(const char *opt, const char *arg) \
> +static int opt_show_##section(void *optctx, const char *opt, const char 
> *arg) \
>  {   \
>  

Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9 support

2019-08-12 Thread Michael Niedermayer
On Mon, Aug 12, 2019 at 02:40:02PM +0800, Guo, Yejun wrote:
> example command line to verify it:
> ./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M 
> tmp.webm
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libvpxenc.c | 177 
> +
>  1 file changed, 177 insertions(+)

breaks build

CC  libavcodec/libvpxenc.o
libavcodec/libvpxenc.c: In function ‘vp9_encode_set_roi’:
libavcodec/libvpxenc.c:1196:19: error: ‘vpx_roi_map_t’ has no member named 
‘ref_frame’
 memset(roi_map.ref_frame, -1, sizeof(roi_map.ref_frame));
   ^
libavcodec/libvpxenc.c:1196:49: error: ‘vpx_roi_map_t’ has no member named 
‘ref_frame’
 memset(roi_map.ref_frame, -1, sizeof(roi_map.ref_frame));
 ^
libavcodec/libvpxenc.c:1198:43: error: ‘VP9E_SET_ROI_MAP’ undeclared (first use 
in this function)
 if (vpx_codec_control(>encoder, VP9E_SET_ROI_MAP, _map)) {
   ^
libavcodec/libvpxenc.c:1198:43: note: each undeclared identifier is reported 
only once for each function it appears in
make: *** [libavcodec/libvpxenc.o] Error 1
make: Target `all' not remade because of errors.


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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter/f_select: yuv will use Y plane only for scenecut detect

2019-08-12 Thread Marton Balint



On Mon, 12 Aug 2019, lance.lmw...@gmail.com wrote:


From: Limin Wang 

Signed-off-by: Limin Wang 
---
libavfilter/f_select.c |  3 ++-
tests/ref/fate/filter-metadata-scenedetect | 16 
2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 5c7372c976..25a36ff0fa 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -211,7 +211,8 @@ static int config_input(AVFilterLink *inlink)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);

select->bitdepth = desc->comp[0].depth;
-select->nb_planes = av_pix_fmt_count_planes(inlink->format);
+select->nb_planes = desc->flags & AV_PIX_FMT_FLAG_PLANAR ? 1 : 
av_pix_fmt_count_planes(inlink->format);
+


This is very misleading even if it happens to work for the currently 
supported formats.


An is_yuv variable is good to have, because it says what we want, which is 
limit the number of planes only for YUV. So please use the previosuly 
suggested


int is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) &&
 (desc->flags & AV_PIX_FMT_FLAG_PLANAR) &&
 desc->nb_components >= 3;

(copied from tiff.c by the way) definition.

Thanks,
Marton



for (int plane = 0; plane < select->nb_planes; plane++) {
ptrdiff_t line_size = av_image_get_linesize(inlink->format, inlink->w, 
plane);
int vsub = desc->log2_chroma_h;
diff --git a/tests/ref/fate/filter-metadata-scenedetect 
b/tests/ref/fate/filter-metadata-scenedetect
index 7ce2d6794e..36c033bc0e 100644
--- a/tests/ref/fate/filter-metadata-scenedetect
+++ b/tests/ref/fate/filter-metadata-scenedetect
@@ -1,11 +1,11 @@
pkt_pts=1620|tag:lavfi.scene_score=1.00
-pkt_pts=4140|tag:lavfi.scene_score=0.668643
-pkt_pts=5800|tag:lavfi.scene_score=0.996721
-pkt_pts=6720|tag:lavfi.scene_score=0.357390
-pkt_pts=8160|tag:lavfi.scene_score=0.886268
-pkt_pts=9760|tag:lavfi.scene_score=0.926219
-pkt_pts=14080|tag:lavfi.scene_score=0.650033
+pkt_pts=4140|tag:lavfi.scene_score=0.923403
+pkt_pts=5800|tag:lavfi.scene_score=1.00
+pkt_pts=6720|tag:lavfi.scene_score=0.475643
+pkt_pts=8160|tag:lavfi.scene_score=1.00
+pkt_pts=9760|tag:lavfi.scene_score=1.00
+pkt_pts=14080|tag:lavfi.scene_score=0.874623
pkt_pts=15700|tag:lavfi.scene_score=1.00
-pkt_pts=18500|tag:lavfi.scene_score=0.316402
-pkt_pts=20040|tag:lavfi.scene_score=0.269509
+pkt_pts=18500|tag:lavfi.scene_score=0.422509
+pkt_pts=20040|tag:lavfi.scene_score=0.352360
pkt_pts=21760|tag:lavfi.scene_score=1.00
--
2.21.0

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

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

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

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

Re: [FFmpeg-devel] [PATCH 4/8] avcodec/ffwavesynth: Fixes invalid shift with pink noise seeking

2019-08-12 Thread Nicolas George
Michael Niedermayer (12019-08-10):
> Fixes: left shift of negative value -961533698048
> Fixes: 
> 16242/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5738550670131200
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffwavesynth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

No objection for either of these patches.

But I want to be on record that I think they were a waste of time, as
these undefined behaviors have no chance of devolving into anything
except possibly garbled output on strange architectures for an obscure
format. Compilers are practical tools, not an axiomatic system.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/qtrle: return last frame even if unchanged

2019-08-12 Thread Marton Balint



On Mon, 12 Aug 2019, Michael Niedermayer wrote:


On Fri, May 31, 2019 at 10:28:15PM +0200, Marton Balint wrote:



On Thu, 30 May 2019, Michael Niedermayer wrote:


Fixes: Ticket7880

Signed-off-by: Michael Niedermayer 
---
libavcodec/qtrle.c| 42 +++
tests/ref/fate/qtrle-8bit |  1 +
2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 2c29547e5a..4add1aded6 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -45,6 +45,8 @@ typedef struct QtrleContext {

   GetByteContext g;
   uint32_t pal[256];
+int need_flush;
+AVPacket flush_pkt;
} QtrleContext;

#define CHECK_PIXEL_PTR(n)  
  \
@@ -444,6 +446,12 @@ static av_cold int qtrle_decode_init(AVCodecContext *avctx)
   return 0;
}

+static void qtrle_flush(AVCodecContext *avctx){
+QtrleContext *s = avctx->priv_data;
+
+s->need_flush = 0;
+}
+
static int qtrle_decode_frame(AVCodecContext *avctx,
 void *data, int *got_frame,
 AVPacket *avpkt)
@@ -454,11 +462,32 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
   int has_palette = 0;
   int ret, size;

+if (!avpkt->data) {
+if (s->need_flush) {
+s->need_flush = 0;
+if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+return ret;
+s->frame->pkt_pos  = s->flush_pkt.pos;
+s->frame->pkt_duration = s->flush_pkt.duration;
+s->frame->pkt_dts  = s->flush_pkt.dts;
+s->frame->pkt_pts  =
+s->frame->pts  = s->flush_pkt.pts;


This does not seem to work, because the magic in decode_simple_internal in
decode.c will overwrite these fields. Alternative approach which seems to
work is assigning the AVPacket fields instead:

avpkt->pos  = s->flush_pkt.pos;
avpkt->duration = s->flush_pkt.duration;
avpkt->dts  = s->flush_pkt.dts;
avpkt->pts  = s->flush_pkt.pts;

Looks a bit ugly, but as far as I see we are using an internal packet, and
not the one provided by the user, so it might be OK.


ill repost this with a different, less ugly variant.

Please recheck if that works!


Seems fine now, thanks.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 6/8] avcodec/decode: Do not overwrite AVFrame.pkt_pos if its already set

2019-08-12 Thread Michael Niedermayer
On Mon, Aug 12, 2019 at 09:21:59PM +0200, Vittorio Giovara wrote:
> On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer 
> wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/decode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 6c31166ec2..09a509d659 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -435,7 +435,7 @@ static int decode_simple_internal(AVCodecContext
> > *avctx, AVFrame *frame)
> >  if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
> >  frame->pkt_dts = pkt->dts;
> >  if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> > -if(!avctx->has_b_frames)
> > +if(!avctx->has_b_frames && frame->pkt_pos < 0)
> >  frame->pkt_pos = pkt->pos;
> >  //FIXME these should be under if(!avctx->has_b_frames)
> >  /* get_buffer is supposed to set frame parameters */
> > --
> >
> 
> sure but why?

the next 2 patches need this
[FFmpeg-devel] [PATCH 7/8] avcodec/qtrle: return last frame even if unchanged
[FFmpeg-devel] [PATCH 8/8] avcodec/nuv: Avoid duplicating frames

without it the common code overwrites the pkt_pos set by the decoder

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

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

Re: [FFmpeg-devel] Request for a resource

2019-08-12 Thread Michael Niedermayer
On Mon, Aug 12, 2019 at 12:48:51PM +0530, Abhinav Rao wrote:
> Hello, everyone. I'm Abhinav Rao, a second-year undergrad from India. I
> have some experience in working with C and Assembly, and would like to
> contribute to FFmpeg. It would be great if someone could guide me to any
> resource(s) that would help me get acquainted with the codebase.

you could pick some random small project, maybe look at the bug tracker
(avoid long open old issues, they are hard), basically pick something
that appears easy and fun to work on
and just try your luck on it, if you have questions just ask here or on
IRC

Thanks

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector

2019-08-12 Thread Michael Niedermayer
On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
> On 08.08.2019, at 10:36, Michael Niedermayer  wrote:
> 
> > This provides an alternative to retry counters.
> > Useful if there is no reasonable maximum number of iterations and
> > no ordering that naturally avoids loops.
> 
> Going by the old principle of "an API is not tested until it has at least 3 
> users"
> might it make sense to delay this until we've found and tested it in a few 
> use-cases?
> Depending on how much hurry there is to get the bug-fix in.

> I assume there is also an actual bug-fix patch somewhere, maybe we should 
> have that
> in the same patch series to make it easier to review the actual usage?

sure will repost this eventually with 3+ bugfixes.
But wont search for such bugs ATM as ive too many other things to do
so it might take a bit of time before i do


> 
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 6603a8229e..eee4c30ec5 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> > 
> > API changes, most recent first:
> > 
> > +2019-XX-XX - XX - lavu 56.XX.XXX - loop_detector.h
> > +  Add loop_detector.h, av_is_loop(), AVSimpleLoopDetector
> 
> Does is mean it is a public/installed header?

that was intended, but it can of course be trivially be kept local if people
prefer when i repost with 3+ dependant fixes 


> I'd prefer to keep new APIs internal until they are really proven in use if 
> there is no immediate pressure.

[...]

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH] mov: Support fake moov boxes disguised as hoov

2019-08-12 Thread Michael Niedermayer
On Mon, Aug 12, 2019 at 01:46:55PM +0200, Vittorio Giovara wrote:
> On Thu, Aug 8, 2019 at 10:28 PM Vittorio Giovara 
> wrote:
> 
> > Some broken apps generate files that have a fake box named 'hoov'
> > instead of a proper 'moov' one. This is speculation but it seems like
> > this box contains data to be modified later (eg as file grows in size,
> > data gets re-written) and its name is supposed to be changed to 'moov'
> > once it can be used as a 'moov', but for some reason this step is skipped.
> >
> > Since this is not the first time this happens ('moov' boxes can be found
> > in 'free' ones) extend the existing hacks to search for the moov in such
> > boxes and skip the moov_retry since it needs to be found right away.
> > ---
> >  libavformat/mov.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > This code is ugly, tips for improving it are welcome, or a full
> > rejection is ok too. Unfortunately I cannot share the sample, but VLC
> > is able to play it.
> > Vittorio
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 24de5429d1..0c2986b72e 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -6800,10 +6800,10 @@ static int mov_read_default(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> >  if (atom.size >= 8) {
> >  a.size = avio_rb32(pb);
> >  a.type = avio_rl32(pb);
> > -if (a.type == MKTAG('f','r','e','e') &&
> > +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
> > +  a.type == MKTAG('h','o','o','v')) &&
> >  a.size >= 8 &&
> > -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT &&
> > -c->moov_retry) {
> > +c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
> >  uint8_t buf[8];
> >  uint32_t *type = (uint32_t *)buf + 1;
> >  if (avio_read(pb, buf, 8) != 8)
> > @@ -6811,7 +6811,7 @@ static int mov_read_default(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> >  avio_seek(pb, -8, SEEK_CUR);
> >  if (*type == MKTAG('m','v','h','d') ||
> >  *type == MKTAG('c','m','o','v')) {
> > -av_log(c->fc, AV_LOG_ERROR, "Detected moov in a free
> > atom.\n");
> > +av_log(c->fc, AV_LOG_ERROR, "Detected moov in a free
> > or hoov atom.\n");
> >  a.type = MKTAG('m','o','o','v');
> >  }
> >  }
> > --
> >
> 
> ping?

probably ok, but same oppinion as you, cleaner solution preferred if anyone
has a cleaner one

Thanks

[...]
-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures

2019-08-12 Thread Michael Niedermayer
On Mon, Aug 12, 2019 at 11:25:59AM -0700, Juan De León wrote:
> Pinging,
> Any other opinions?

About adding a reserved[128] ?
i think storing the size somewhere is probably better (less memory, and
not having an arbitrary limit which could theoretically be hit one day)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

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

Re: [FFmpeg-devel] [PATCH 6/8] avcodec/decode: Do not overwrite AVFrame.pkt_pos if its already set

2019-08-12 Thread Vittorio Giovara
On Mon, Aug 12, 2019 at 9:19 PM Michael Niedermayer 
wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/decode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6c31166ec2..09a509d659 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -435,7 +435,7 @@ static int decode_simple_internal(AVCodecContext
> *avctx, AVFrame *frame)
>  if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
>  frame->pkt_dts = pkt->dts;
>  if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> -if(!avctx->has_b_frames)
> +if(!avctx->has_b_frames && frame->pkt_pos < 0)
>  frame->pkt_pos = pkt->pos;
>  //FIXME these should be under if(!avctx->has_b_frames)
>  /* get_buffer is supposed to set frame parameters */
> --
>

sure but why?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 4/8] avcodec/loco: Check left column value

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (42sec -> 379 ms)
Fixes: 
16323/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5679178099195904

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

diff --git a/libavcodec/loco.c b/libavcodec/loco.c
index 5fb414b411..d8bf68a100 100644
--- a/libavcodec/loco.c
+++ b/libavcodec/loco.c
@@ -161,6 +161,8 @@ static int loco_decode_plane(LOCOContext *l, uint8_t *data, 
int width, int heigh
 for (j = 1; j < height; j++) {
 /* restore left column */
 val = loco_get_rice();
+if (val == INT_MIN)
+   return AVERROR_INVALIDDATA;
 data[0] = data[-stride] + val;
 /* restore all other pixels */
 for (i = 1; i < width; i++) {
-- 
2.22.0

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

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

Re: [FFmpeg-devel] [PATCH 3/3] tools/target_dec_fuzzer: Print max_pixels and iterations at the end

2019-08-12 Thread Michael Niedermayer
On Wed, Jul 31, 2019 at 10:52:34AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

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

[FFmpeg-devel] [PATCH 8/8] avcodec/nuv: Avoid duplicating frames

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (14sec -> 133ms)
Fixes: 
14843/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5661969614372864
Fixes: 
16257/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5769175464673280
 (35sec ->0.5sec)

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/nuv.c  | 37 ++---
 tests/ref/fate/nuv-rtjpeg |  1 -
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nuv.c b/libavcodec/nuv.c
index 75b14bce5b..0952b537b7 100644
--- a/libavcodec/nuv.c
+++ b/libavcodec/nuv.c
@@ -42,6 +42,8 @@ typedef struct NuvContext {
 unsigned char *decomp_buf;
 uint32_t lq[64], cq[64];
 RTJpegContext rtj;
+int need_flush;
+AVPacket flush_pkt;
 } NuvContext;
 
 static const uint8_t fallback_lquant[] = {
@@ -66,6 +68,12 @@ static const uint8_t fallback_cquant[] = {
 99, 99, 99, 99, 99, 99, 99, 99
 };
 
+static void decode_flush(AVCodecContext *avctx){
+NuvContext *s = avctx->priv_data;
+
+s->need_flush = 0;
+}
+
 /**
  * @brief copy frame data from buffer to AVFrame, handling stride.
  * @param f destination AVFrame
@@ -172,6 +180,26 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 NUV_COPY_LAST = 'L'
 } comptype;
 
+if (!avpkt->data) {
+if (c->need_flush) {
+c->need_flush = 0;
+if ((ret = ff_reget_buffer(avctx, c->pic)) < 0)
+return ret;
+c->pic->pkt_pos  = c->flush_pkt.pos;
+c->pic->pkt_duration = c->flush_pkt.duration;
+c->pic->pkt_dts  = c->flush_pkt.dts;
+c->pic->pkt_pts  =
+c->pic->pts  = c->flush_pkt.pts;
+if ((ret = av_frame_ref(data, c->pic)) < 0)
+return ret;
+*got_frame = 1;
+}
+return 0;
+}
+c->flush_pkt = *avpkt;
+c->pic->pkt_dts = c->flush_pkt.dts;
+
+
 if (buf_size < 12) {
 av_log(avctx, AV_LOG_ERROR, "coded frame too small\n");
 return AVERROR_INVALIDDATA;
@@ -204,8 +232,8 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 }
 break;
 case NUV_COPY_LAST:
-keyframe = 0;
-break;
+c->need_flush = 1;
+return buf_size;
 default:
 keyframe = 1;
 break;
@@ -313,6 +341,7 @@ retry:
 if ((result = av_frame_ref(picture, c->pic)) < 0)
 return result;
 
+c->need_flush = 0;
 *got_frame = 1;
 return orig_size;
 }
@@ -364,6 +393,8 @@ AVCodec ff_nuv_decoder = {
 .init   = decode_init,
 .close  = decode_end,
 .decode = decode_frame,
-.capabilities   = AV_CODEC_CAP_DR1,
+.flush  = decode_flush,
+.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 };
diff --git a/tests/ref/fate/nuv-rtjpeg b/tests/ref/fate/nuv-rtjpeg
index b6f3b080dc..0914b985ec 100644
--- a/tests/ref/fate/nuv-rtjpeg
+++ b/tests/ref/fate/nuv-rtjpeg
@@ -6,7 +6,6 @@
 0,118,118,0,   460800, 0x54aedafe
 0,152,152,0,   460800, 0xb7aa8b56
 0,177,177,0,   460800, 0x283ea3b5
-0,202,202,0,   460800, 0x283ea3b5
 0,235,235,0,   460800, 0x10e577de
 0,269,269,0,   460800, 0x4e091ee2
 0,302,302,0,   460800, 0x2ea88828
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 1/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (12sec -> 32ms)
Fixes: 
16078/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296

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

diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index aeb15de0ed..62eb794332 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -356,6 +356,9 @@ static int cinepak_predecode_check (CinepakContext *s)
 if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
 return AVERROR_INVALIDDATA;
 
+if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
+return AVERROR_INVALIDDATA;
+
 if (num_strips) {
 const uint8_t *data = s->data + 10 + s->sega_film_skip_bytes;
 int strip_size = AV_RB24 (data + 1);
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 5/8] avcodec/flicvideo: Optimize and Simplify FLI_COPY in flic_decode_frame_24BPP() by using bytestream2_get_buffer()

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (31sec  -> 22sec)
Fixes: 
16217/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-5658084189405184

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

diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
index 99868f3ba3..bf8ffeba4f 100644
--- a/libavcodec/flicvideo.c
+++ b/libavcodec/flicvideo.c
@@ -1024,14 +1024,7 @@ static int flic_decode_frame_24BPP(AVCodecContext *avctx,
 for (y_ptr = 0; y_ptr < s->frame->linesize[0] * 
s->avctx->height;
  y_ptr += s->frame->linesize[0]) {
 
-pixel_countdown = s->avctx->width;
-pixel_ptr = 0;
-while (pixel_countdown > 0) {
-pixel = bytestream2_get_le24();
-AV_WL24([y_ptr + pixel_ptr], pixel);
-pixel_ptr += 3;
-pixel_countdown--;
-}
+bytestream2_get_buffer(, pixels + y_ptr, 
3*s->avctx->width);
 if (s->avctx->width & 1)
 bytestream2_skip(, 3);
 }
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 7/8] avcodec/qtrle: return last frame even if unchanged

2019-08-12 Thread Michael Niedermayer
Fixes: Ticket7880

Signed-off-by: Michael Niedermayer 
---
 libavcodec/qtrle.c| 44 +++
 tests/ref/fate/qtrle-8bit |  1 +
 2 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 2c29547e5a..ab620cdb55 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -45,6 +45,8 @@ typedef struct QtrleContext {
 
 GetByteContext g;
 uint32_t pal[256];
+int need_flush;
+AVPacket flush_pkt;
 } QtrleContext;
 
 #define CHECK_PIXEL_PTR(n) 
   \
@@ -444,6 +446,12 @@ static av_cold int qtrle_decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+static void qtrle_flush(AVCodecContext *avctx){
+QtrleContext *s = avctx->priv_data;
+
+s->need_flush = 0;
+}
+
 static int qtrle_decode_frame(AVCodecContext *avctx,
   void *data, int *got_frame,
   AVPacket *avpkt)
@@ -454,11 +462,33 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 int has_palette = 0;
 int ret, size;
 
+if (!avpkt->data) {
+if (s->need_flush) {
+s->need_flush = 0;
+if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+return ret;
+s->frame->pkt_pos  = s->flush_pkt.pos;
+s->frame->pkt_duration = s->flush_pkt.duration;
+s->frame->pkt_dts  = s->flush_pkt.dts;
+s->frame->pkt_pts  =
+s->frame->pts  = s->flush_pkt.pts;
+if ((ret = av_frame_ref(data, s->frame)) < 0)
+return ret;
+*got_frame = 1;
+}
+return 0;
+}
+s->flush_pkt = *avpkt;
+s->frame->pkt_dts = s->flush_pkt.dts;
+
 bytestream2_init(>g, avpkt->data, avpkt->size);
 
 /* check if this frame is even supposed to change */
-if (avpkt->size < 8)
+if (avpkt->size < 8) {
+s->need_flush = 1;
 return avpkt->size;
+}
+s->need_flush = 0;
 
 /* start after the chunk size */
 size = bytestream2_get_be32(>g) & 0x3FFF;
@@ -471,14 +501,18 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
 
 /* if a header is present, fetch additional decoding parameters */
 if (header & 0x0008) {
-if (avpkt->size < 14)
+if (avpkt->size < 14) {
+s->need_flush = 1;
 return avpkt->size;
+}
 start_line = bytestream2_get_be16(>g);
 bytestream2_skip(>g, 2);
 height = bytestream2_get_be16(>g);
 bytestream2_skip(>g, 2);
-if (height > s->avctx->height - start_line)
+if (height > s->avctx->height - start_line) {
+s->need_flush = 1;
 return avpkt->size;
+}
 } else {
 start_line = 0;
 height = s->avctx->height;
@@ -572,5 +606,7 @@ AVCodec ff_qtrle_decoder = {
 .init   = qtrle_decode_init,
 .close  = qtrle_decode_end,
 .decode = qtrle_decode_frame,
-.capabilities   = AV_CODEC_CAP_DR1,
+.flush  = qtrle_flush,
+.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
 };
diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
index 27bb8aad71..39a03b7b6c 100644
--- a/tests/ref/fate/qtrle-8bit
+++ b/tests/ref/fate/qtrle-8bit
@@ -61,3 +61,4 @@
 0,160,160,1,   921600, 0xcfd6ad2b
 0,163,163,1,   921600, 0x3b372379
 0,165,165,1,   921600, 0x36f245f5
+0,166,166,1,   921600, 0x36f245f5
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 6/8] avcodec/decode: Do not overwrite AVFrame.pkt_pos if its already set

2019-08-12 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 libavcodec/decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6c31166ec2..09a509d659 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -435,7 +435,7 @@ static int decode_simple_internal(AVCodecContext *avctx, 
AVFrame *frame)
 if (!(avctx->codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
 frame->pkt_dts = pkt->dts;
 if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if(!avctx->has_b_frames)
+if(!avctx->has_b_frames && frame->pkt_pos < 0)
 frame->pkt_pos = pkt->pos;
 //FIXME these should be under if(!avctx->has_b_frames)
 /* get_buffer is supposed to set frame parameters */
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 2/8] tools/target_dec_fuzzer: adjust pixel threshold for MSRLE, as it allows coding gigantic images on tiny input

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (12sec ->2sec)
Fixes: 
16125/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSRLE_fuzzer-5650846364205056

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

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e6eed88781..d83039417c 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -170,6 +170,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 maxpixels = maxpixels_per_frame * maxiteration;
 switch (c->id) {
 // Allows a small input to generate gigantic output
+case AV_CODEC_ID_MSRLE: maxpixels /= 16;  break;
 case AV_CODEC_ID_QTRLE: maxpixels /= 16;  break;
 case AV_CODEC_ID_GIF:   maxpixels /= 16;  break;
 // Performs slow frame rescaling in C
-- 
2.22.0

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

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

[FFmpeg-devel] [PATCH 3/8] tools/target_dec_fuzzer: adjust pixel threshold for SANM, as it allows coding gigantic images on tiny input

2019-08-12 Thread Michael Niedermayer
Fixes: Timeout (13sec ->1sec)
Fixes: 
16122/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5724944247291904

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

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index d83039417c..b3c26717f6 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -172,6 +172,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 // Allows a small input to generate gigantic output
 case AV_CODEC_ID_MSRLE: maxpixels /= 16;  break;
 case AV_CODEC_ID_QTRLE: maxpixels /= 16;  break;
+case AV_CODEC_ID_SANM:  maxpixels /= 16;  break;
 case AV_CODEC_ID_GIF:   maxpixels /= 16;  break;
 // Performs slow frame rescaling in C
 case AV_CODEC_ID_GDV:   maxpixels /= 256; break;
-- 
2.22.0

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/qtrle: return last frame even if unchanged

2019-08-12 Thread Michael Niedermayer
On Fri, May 31, 2019 at 10:28:15PM +0200, Marton Balint wrote:
> 
> 
> On Thu, 30 May 2019, Michael Niedermayer wrote:
> 
> >Fixes: Ticket7880
> >
> >Signed-off-by: Michael Niedermayer 
> >---
> >libavcodec/qtrle.c| 42 +++
> >tests/ref/fate/qtrle-8bit |  1 +
> >2 files changed, 39 insertions(+), 4 deletions(-)
> >
> >diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
> >index 2c29547e5a..4add1aded6 100644
> >--- a/libavcodec/qtrle.c
> >+++ b/libavcodec/qtrle.c
> >@@ -45,6 +45,8 @@ typedef struct QtrleContext {
> >
> >GetByteContext g;
> >uint32_t pal[256];
> >+int need_flush;
> >+AVPacket flush_pkt;
> >} QtrleContext;
> >
> >#define CHECK_PIXEL_PTR(n)   
> > \
> >@@ -444,6 +446,12 @@ static av_cold int qtrle_decode_init(AVCodecContext 
> >*avctx)
> >return 0;
> >}
> >
> >+static void qtrle_flush(AVCodecContext *avctx){
> >+QtrleContext *s = avctx->priv_data;
> >+
> >+s->need_flush = 0;
> >+}
> >+
> >static int qtrle_decode_frame(AVCodecContext *avctx,
> >  void *data, int *got_frame,
> >  AVPacket *avpkt)
> >@@ -454,11 +462,32 @@ static int qtrle_decode_frame(AVCodecContext *avctx,
> >int has_palette = 0;
> >int ret, size;
> >
> >+if (!avpkt->data) {
> >+if (s->need_flush) {
> >+s->need_flush = 0;
> >+if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
> >+return ret;
> >+s->frame->pkt_pos  = s->flush_pkt.pos;
> >+s->frame->pkt_duration = s->flush_pkt.duration;
> >+s->frame->pkt_dts  = s->flush_pkt.dts;
> >+s->frame->pkt_pts  =
> >+s->frame->pts  = s->flush_pkt.pts;
> 
> This does not seem to work, because the magic in decode_simple_internal in
> decode.c will overwrite these fields. Alternative approach which seems to
> work is assigning the AVPacket fields instead:
> 
> avpkt->pos  = s->flush_pkt.pos;
> avpkt->duration = s->flush_pkt.duration;
> avpkt->dts  = s->flush_pkt.dts;
> avpkt->pts  = s->flush_pkt.pts;
> 
> Looks a bit ugly, but as far as I see we are using an internal packet, and
> not the one provided by the user, so it might be OK.

ill repost this with a different, less ugly variant. 

Please recheck if that works!

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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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

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

Re: [FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures

2019-08-12 Thread Juan De León
Pinging,
Any other opinions?

On Sat, Aug 10, 2019 at 2:22 AM Nicolas George  wrote:

> Lynne (12019-08-10):
> > >> +typedef struct AVEncodeInfoBlock{
> > >> +/**
> > >> + * Distance in luma pixels from the top-left corner of the
> visible frame
> > >> + * to the top-left corner of the block.
> > >> + * Can be negative if top/right padding is present on the coded
> frame.
> > >> + */
> > >> +int src_x, src_y;
> > >> +/**
> > >> + * Width and height of the block in luma pixels
> > >> + */
> > >> +int w, h;
> > >> +/**
> > >> + * Delta quantization index for the block
> > >> + */
> > >> +int delta_q;
> > >> +
> > >>
> > >> +uint8_t reserved[128];
> > >>
> > > What are these (this one and the one below) reserved fields for?
> >
> > For future extensions without breaking the API. Things like block type,
> prediction type, motion vectors, references, etc.
>
> I suspected as much. But remember that setting the size of reserved
> after fields are added will be very tricky: it requires taking into
> account alignment and padding in the structure.
>
> I think something like that might be easier to manage (and also use less
> memory right now):
>
> typedef struct AVEncodeInfoFrame {
> ...
> size_t blocks_offset;
> size_t block_size;
> }
>
> static inline AVEncodeInfoBlock *
> av_encode_info_block(AVEncodeInfoFrame *info, unsigned idx)
> {
> return (AVEncodeInfoBlock *)
>((char *)info + info->blocks_offset +
> idx * info->block_size);
> }
>
> static inline AVEncodeInfoBlock *
> av_encode_info_block_next(AVEncodeInfoFrame *info, AVEncodeInfoBlock
> *block)
> {
> return (AVEncodeInfoBlock *)
>((char *)block + info->block_size);
> }
>
> Regards,
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [REQUEST] ffmpeg-security subscription

2019-08-12 Thread Michael Niedermayer
Hi Paul

On Mon, Aug 05, 2019 at 11:50:04AM +0200, Paul B Mahol wrote:
> Hi,
> 
> I here hereby request from lead FFmpeg entity to give me subscription to
> ffmpeg-security mailing list.

I am not sure who or what a "lead FFmpeg entity" is, But as iam being 
highlighted 
on IRC by you in relation to this, and as iam the most active developer on 
security issues in ffmpeg it would be inpolite from me if i didnt say something.

About ffmpeg-security,
Theres currently no need for more manpower to handle security issues. We have
a backlog of a few days of fuzzing issues only which is shrinking. And no other
issues besides fuzzing issues. (part of the backlog probably was the result 
of distractions and some longer review cycles on some patches recently)
Also all patches are being posted in public so no access is needed for reviews.

I think many of the complaints from people about some of the patches should be
resolved by the recent addition of thresholds on all pixels decoded. That way
slow video decoders can have their timeout thresholds effectively tuned and
would no longer require ugly changes which several people did not like.
That wont eliminate all uglyness but it should reduce it.

PS: also keep in mind that we recently increased coverage of the fuzzers
this created a spike of new issues, so besides more such spikes from more
coverage increases the amount of new issues is expected to decrease over
time

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

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

[FFmpeg-devel] [PATCH v2 2/3] avfilter/vsrc_mptestsrc: simplify the code and change the type of frame

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavfilter/vsrc_mptestsrc.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
index 4a2db18..14e66fd 100644
--- a/libavfilter/vsrc_mptestsrc.c
+++ b/libavfilter/vsrc_mptestsrc.c
@@ -308,7 +308,7 @@ static int request_frame(AVFilterLink *outlink)
 AVFrame *picref;
 int w = WIDTH, h = HEIGHT,
 cw = AV_CEIL_RSHIFT(w, test->hsub), ch = AV_CEIL_RSHIFT(h, test->vsub);
-unsigned int frame = outlink->frame_count_in;
+uint64_t  frame = outlink->frame_count_in;
 enum test_type tt = test->test;
 int i;
 
@@ -327,20 +327,21 @@ static int request_frame(AVFilterLink *outlink)
 memset(picref->data[2] + i*picref->linesize[2], 128, cw);
 }
 
-if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at the 
beginning of each test */
-tt = (frame/test->max_frames)%(TEST_NB-1);
+frame = frame/test->max_frames;
+if (tt == TEST_ALL && frame) /* draw a black frame at the beginning of 
each test */
+tt = frame%(TEST_NB-1);
 
 switch (tt) {
-case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame%test->max_frames); break;
-case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame%test->max_frames); break;
-case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
-case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
-case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
-case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
-case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame%test->max_frames); break;
-case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
-case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
-case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame); break;
+case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame); break;
+case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame); break;
+case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame); break;
+case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame); break;
+case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame); break;
+case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame); break;
+case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame); break;
+case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame); break;
+case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame); break;
 }
 
 return ff_filter_frame(outlink, picref);
-- 
2.6.4

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

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

Re: [FFmpeg-devel] [PATCH v1 1/2] avfilter/vsrc_mptestsrc: add option to set the max number frames generated for each tests

2019-08-12 Thread Limin Wang
On Mon, Aug 12, 2019 at 03:05:32PM +0200, Moritz Barsnick wrote:
> On Mon, Aug 12, 2019 at 19:21:45 +0800, lance.lmw...@gmail.com wrote:
> > +Set the max number frames generated for each tests:
> 
> Grammar nit:
>   Set the maximum number of frames generated for each test
> 
> (Note:
>  - use the complete word maximum
>  - "test", "not tests", when using "for each" singular
>  - *of* frames.

OK, fix it. It'll cause the subject change, so it'll start with new
thread:
https://patchwork.ffmpeg.org/patch/14439/

> 
> > +{ "max_frames", "Set the max number frames generated for each tests", 
> > OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
> > +{ "m",  " Set the max number frames generated for each tests", 
> > OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
> 
> Same here. Also note that you introduced an additional space in the
> second string which doesn't belong there.

OK, fix them and send v2 patch.

> 
> > +if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at 
> > the beginning of each test */
> > +tt = (frame/test->max_frames)%(TEST_NB-1);
> [...]
> > +case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
> > 256, 256, frame%test->max_frames); break;
> > +case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
> > 256, 256, frame%test->max_frames); break;
> > +case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
> > frame%test->max_frames); break;
> [...]
> 
> frame%test->max_frames could probably be assigned to a variable, that
> might avoid a lot of code, unless compilers know how to optimize this.
> (Might not belong into this functional patch though.)
> 
Add patch#3 to simpilify it, change the type for frame and reuse it.

> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH V3] swscale/ppc/yuv2rgb_altivec: Fixes compiler bug - replace vec_lvsl/vec_perm with vec_xl

2019-08-12 Thread ckerchne
A bug exist with the gcc compilers for Power in versions 6.x and 7.x 
(verified with 6.3 and 7.4). It was fixed in version 8.x (verified with 
8.3). I was using a Power 9 ppc64le machine for building and testing.


It appears the compiler is generating the wrong code for little endian 
machines for the vec_lvsl/vec_perm instruction combos in some cases. If 
these instructions are replaced with vec_xl, the problem goes away for 
all versions of the compilers (plus it is a bit faster).


Fixes #7124 and can be reproduced within the docker by following the 
instructions within the ticket.


https://trac.ffmpeg.org/ticket/7124diff --git a/libswscale/ppc/yuv2rgb_altivec.c b/libswscale/ppc/yuv2rgb_altivec.c
index c1e2852adb..536545293d 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_altivec.c
@@ -305,9 +305,6 @@ static int altivec_ ## name(SwsContext *c, const unsigned char **in,  \
 vector signed short R1, G1, B1;   \
 vector unsigned char R, G, B; \
   \
-const vector unsigned char *y1ivP, *y2ivP, *uivP, *vivP;  \
-vector unsigned char align_perm;  \
-  \
 vector signed short lCY   = c->CY;\
 vector signed short lOY   = c->OY;\
 vector signed short lCRV  = c->CRV;   \
@@ -338,26 +335,13 @@ static int altivec_ ## name(SwsContext *c, const unsigned char **in,  \
 vec_dstst(oute, (0x0202 | (((w * 3 + 32) / 32) << 16)), 1);   \
   \
 for (j = 0; j < w / 16; j++) {\
-y1ivP = (const vector unsigned char *) y1i;   \
-y2ivP = (const vector unsigned char *) y2i;   \
-uivP  = (const vector unsigned char *) ui;\
-vivP  = (const vector unsigned char *) vi;\
-  \
-align_perm = vec_lvsl(0, y1i);\
-y0 = (vector unsigned char)   \
- vec_perm(y1ivP[0], y1ivP[1], align_perm);\
+y0 = vec_xl(0, y1i);  \
   \
-align_perm = vec_lvsl(0, y2i);\
-y1 = (vector unsigned char)   \
- vec_perm(y2ivP[0], y2ivP[1], align_perm);\
+y1 = vec_xl(0, y2i);  \
   \
-align_perm = vec_lvsl(0, ui); \
-u = (vector signed char)  \
-vec_perm(uivP[0], uivP[1], align_perm);   \
+u = (vector signed char) vec_xl(0, ui);   \
   \
-align_perm = vec_lvsl(0, vi); \
-v = (vector signed char)  \
-vec_perm(vivP[0], vivP[1], align_perm);   \
+v = (vector signed char) vec_xl(0, vi);   \
   \
 u = (vector signed char)  \
 vec_sub(u,\
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v2 3/3] FATE: add a test for freeezedetect

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 tests/fate/filter-video.mak |   4 +
 tests/ref/fate/filter-metadata-freezedetect | 251 
 2 files changed, 255 insertions(+)
 create mode 100644 tests/ref/fate/filter-metadata-freezedetect

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 60c6be1..5b44208 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -742,6 +742,10 @@ FATE_METADATA_FILTER-$(call ALLYES, $(CROPDETECT_DEPS)) += 
fate-filter-metadata-
 fate-filter-metadata-cropdetect: SRC = $(TARGET_SAMPLES)/filter/cropdetect.mp4
 fate-filter-metadata-cropdetect: CMD = run $(FILTER_METADATA_COMMAND) 
"sws_flags=+accurate_rnd+bitexact;movie='$(SRC)',cropdetect=max_outliers=3"
 
+FREEZEDETECT_DEPS = FFPROBE AVDEVICE LAVFI_INDEV MPTESTSRC_FILTER SCALE_FILTER 
FREEZEDETECT_FILTER
+FATE_METADATA_FILTER-$(call ALLYES, $(FREEZEDETECT_DEPS)) += 
fate-filter-metadata-freezedetect
+fate-filter-metadata-freezedetect: CMD = run $(FILTER_METADATA_COMMAND) 
"sws_flags=+accurate_rnd+bitexact;mptestsrc=r=25:d=10:m=51,freezedetect"
+
 SILENCEDETECT_DEPS = FFPROBE AVDEVICE LAVFI_INDEV AMOVIE_FILTER TTA_DEMUXER 
TTA_DECODER SILENCEDETECT_FILTER
 FATE_METADATA_FILTER-$(call ALLYES, $(SILENCEDETECT_DEPS)) += 
fate-filter-metadata-silencedetect
 fate-filter-metadata-silencedetect: SRC = 
$(TARGET_SAMPLES)/lossless-audio/inside.tta
diff --git a/tests/ref/fate/filter-metadata-freezedetect 
b/tests/ref/fate/filter-metadata-freezedetect
new file mode 100644
index 000..038670b
--- /dev/null
+++ b/tests/ref/fate/filter-metadata-freezedetect
@@ -0,0 +1,251 @@
+pkt_pts=0
+pkt_pts=1
+pkt_pts=2
+pkt_pts=3
+pkt_pts=4
+pkt_pts=5
+pkt_pts=6
+pkt_pts=7
+pkt_pts=8
+pkt_pts=9
+pkt_pts=10
+pkt_pts=11
+pkt_pts=12
+pkt_pts=13
+pkt_pts=14
+pkt_pts=15
+pkt_pts=16
+pkt_pts=17
+pkt_pts=18
+pkt_pts=19
+pkt_pts=20
+pkt_pts=21
+pkt_pts=22
+pkt_pts=23
+pkt_pts=24
+pkt_pts=25
+pkt_pts=26
+pkt_pts=27
+pkt_pts=28
+pkt_pts=29
+pkt_pts=30
+pkt_pts=31
+pkt_pts=32
+pkt_pts=33
+pkt_pts=34
+pkt_pts=35
+pkt_pts=36
+pkt_pts=37
+pkt_pts=38
+pkt_pts=39
+pkt_pts=40
+pkt_pts=41
+pkt_pts=42
+pkt_pts=43
+pkt_pts=44
+pkt_pts=45
+pkt_pts=46
+pkt_pts=47
+pkt_pts=48
+pkt_pts=49
+pkt_pts=50|tag:lavfi.freezedetect.freeze_start=0
+pkt_pts=51|tag:lavfi.freezedetect.freeze_duration=2.04|tag:lavfi.freezedetect.freeze_end=2.04
+pkt_pts=52
+pkt_pts=53
+pkt_pts=54
+pkt_pts=55
+pkt_pts=56
+pkt_pts=57
+pkt_pts=58
+pkt_pts=59
+pkt_pts=60
+pkt_pts=61
+pkt_pts=62
+pkt_pts=63
+pkt_pts=64
+pkt_pts=65
+pkt_pts=66
+pkt_pts=67
+pkt_pts=68
+pkt_pts=69
+pkt_pts=70
+pkt_pts=71
+pkt_pts=72
+pkt_pts=73
+pkt_pts=74
+pkt_pts=75
+pkt_pts=76
+pkt_pts=77
+pkt_pts=78
+pkt_pts=79
+pkt_pts=80
+pkt_pts=81
+pkt_pts=82
+pkt_pts=83
+pkt_pts=84
+pkt_pts=85
+pkt_pts=86
+pkt_pts=87
+pkt_pts=88
+pkt_pts=89
+pkt_pts=90
+pkt_pts=91
+pkt_pts=92
+pkt_pts=93
+pkt_pts=94
+pkt_pts=95
+pkt_pts=96
+pkt_pts=97
+pkt_pts=98
+pkt_pts=99
+pkt_pts=100
+pkt_pts=101|tag:lavfi.freezedetect.freeze_start=2.04
+pkt_pts=102|tag:lavfi.freezedetect.freeze_duration=2.04|tag:lavfi.freezedetect.freeze_end=4.08
+pkt_pts=103
+pkt_pts=104
+pkt_pts=105
+pkt_pts=106
+pkt_pts=107
+pkt_pts=108
+pkt_pts=109
+pkt_pts=110
+pkt_pts=111
+pkt_pts=112
+pkt_pts=113
+pkt_pts=114
+pkt_pts=115
+pkt_pts=116
+pkt_pts=117
+pkt_pts=118
+pkt_pts=119
+pkt_pts=120
+pkt_pts=121
+pkt_pts=122
+pkt_pts=123
+pkt_pts=124
+pkt_pts=125
+pkt_pts=126
+pkt_pts=127
+pkt_pts=128
+pkt_pts=129
+pkt_pts=130
+pkt_pts=131
+pkt_pts=132
+pkt_pts=133
+pkt_pts=134
+pkt_pts=135
+pkt_pts=136
+pkt_pts=137
+pkt_pts=138
+pkt_pts=139
+pkt_pts=140
+pkt_pts=141
+pkt_pts=142
+pkt_pts=143
+pkt_pts=144
+pkt_pts=145
+pkt_pts=146
+pkt_pts=147
+pkt_pts=148
+pkt_pts=149
+pkt_pts=150
+pkt_pts=151
+pkt_pts=152|tag:lavfi.freezedetect.freeze_start=4.08
+pkt_pts=153|tag:lavfi.freezedetect.freeze_duration=2.04|tag:lavfi.freezedetect.freeze_end=6.12
+pkt_pts=154
+pkt_pts=155
+pkt_pts=156
+pkt_pts=157
+pkt_pts=158
+pkt_pts=159
+pkt_pts=160
+pkt_pts=161
+pkt_pts=162
+pkt_pts=163
+pkt_pts=164
+pkt_pts=165
+pkt_pts=166
+pkt_pts=167
+pkt_pts=168
+pkt_pts=169
+pkt_pts=170
+pkt_pts=171
+pkt_pts=172
+pkt_pts=173
+pkt_pts=174
+pkt_pts=175
+pkt_pts=176
+pkt_pts=177
+pkt_pts=178
+pkt_pts=179
+pkt_pts=180
+pkt_pts=181
+pkt_pts=182
+pkt_pts=183
+pkt_pts=184
+pkt_pts=185
+pkt_pts=186
+pkt_pts=187
+pkt_pts=188
+pkt_pts=189
+pkt_pts=190
+pkt_pts=191
+pkt_pts=192
+pkt_pts=193
+pkt_pts=194
+pkt_pts=195
+pkt_pts=196
+pkt_pts=197
+pkt_pts=198
+pkt_pts=199
+pkt_pts=200
+pkt_pts=201
+pkt_pts=202
+pkt_pts=203|tag:lavfi.freezedetect.freeze_start=6.12
+pkt_pts=204|tag:lavfi.freezedetect.freeze_duration=2.04|tag:lavfi.freezedetect.freeze_end=8.16
+pkt_pts=205
+pkt_pts=206
+pkt_pts=207
+pkt_pts=208
+pkt_pts=209
+pkt_pts=210
+pkt_pts=211
+pkt_pts=212
+pkt_pts=213
+pkt_pts=214
+pkt_pts=215
+pkt_pts=216
+pkt_pts=217
+pkt_pts=218
+pkt_pts=219
+pkt_pts=220
+pkt_pts=221
+pkt_pts=222
+pkt_pts=223
+pkt_pts=224
+pkt_pts=225
+pkt_pts=226

[FFmpeg-devel] [PATCH v2 1/3] avfilter/vsrc_mptestsrc: add options to set the maximum number of frames

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/filters.texi |  3 +++
 libavfilter/vsrc_mptestsrc.c | 29 +
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc..902e5bf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20246,6 +20246,9 @@ Set the number or the name of the test to perform. 
Supported tests are:
 @item ring2
 @item all
 
+@item max_frames, m
+Set the maximum number of frames generated for each test, default value is 30.
+
 @end table
 
 Default value is "all", which will cycle through the list of all tests.
diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
index c5fdea7..4a2db18 100644
--- a/libavfilter/vsrc_mptestsrc.c
+++ b/libavfilter/vsrc_mptestsrc.c
@@ -54,6 +54,7 @@ typedef struct MPTestContext {
 const AVClass *class;
 AVRational frame_rate;
 int64_t pts, max_pts, duration;
+int64_t max_frames;
 int hsub, vsub;
 int test;   ///< test_type
 } MPTestContext;
@@ -79,6 +80,10 @@ static const AVOption mptestsrc_options[]= {
 { "ring1",   "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING1},   
INT_MIN, INT_MAX, FLAGS, "test" },
 { "ring2",   "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING2},   
INT_MIN, INT_MAX, FLAGS, "test" },
 { "all", "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_ALL}, 
INT_MIN, INT_MAX, FLAGS, "test" },
+{ "max_frames", "Set the maximum number of frames generated for each 
test", OFFSET(max_frames),
+AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
+{ "m",  "Set the maximum number of frames generated for each 
test", OFFSET(max_frames),
+AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
 { NULL }
 };
 
@@ -322,20 +327,20 @@ static int request_frame(AVFilterLink *outlink)
 memset(picref->data[2] + i*picref->linesize[2], 128, cw);
 }
 
-if (tt == TEST_ALL && frame%30) /* draw a black frame at the beginning of 
each test */
-tt = (frame/30)%(TEST_NB-1);
+if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at the 
beginning of each test */
+tt = (frame/test->max_frames)%(TEST_NB-1);
 
 switch (tt) {
-case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame%30); break;
-case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame%30); break;
-case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame%30); break;
-case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame%30); break;
-case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame%30); break;
-case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame%30); break;
+case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame%test->max_frames); break;
+case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame%test->max_frames); break;
+case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
+case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
+case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame%test->max_frames); break;
+case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
 }
 
 return ff_filter_frame(outlink, picref);
-- 
2.6.4

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

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

Re: [FFmpeg-devel] [PATCH V2] Fixes compiler bug - replace vec_lvsl/vec_perm with vec_xl

2019-08-12 Thread Carl Eugen Hoyos


> Am 12.08.2019 um 16:21 schrieb ckerchne :
> 
> How do I get someone to look at this patch?
> 
>> A bug exist with the gcc compilers for Power in versions 6.x and 7.x
>> (verified with 6.3 and 7.4). It was fixed in version 8.x (verified
>> with 8.3). I was using a Power 9 ppc64le machine for building and
>> testing.
>> This is to address ticket #7124.
>> It appears the compiler is generating the wrong code for little endian
>> machines for the vec_lvsl/vec_perm instruction combos in some cases.
>> If these instructions are replaced with vec_xl, the problem goes away
>> for all versions of the compilers.

As said, this commit message is not ok, please add information on how the issue 
can actually be reproduced.

And please avoid top-posting here.

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

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

Re: [FFmpeg-devel] [PATCH V2] Fixes compiler bug - replace vec_lvsl/vec_perm with vec_xl

2019-08-12 Thread ckerchne

How do I get someone to look at this patch?


A bug exist with the gcc compilers for Power in versions 6.x and 7.x
(verified with 6.3 and 7.4). It was fixed in version 8.x (verified
with 8.3). I was using a Power 9 ppc64le machine for building and
testing.
This is to address ticket #7124.

It appears the compiler is generating the wrong code for little endian
machines for the vec_lvsl/vec_perm instruction combos in some cases.
If these instructions are replaced with vec_xl, the problem goes away
for all versions of the compilers.

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

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

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

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale: Ensure scaled video is divisible by n

2019-08-12 Thread Lars Kiesow
Hi Michael,

> > + if (scale->force_divisible_by > 1) {
> > + w = ceil(w / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;
> > + h = ceil(h / (float)scale->force_divisible_by) *
> > scale->force_divisible_by;  
> 
> you dont need float here and its better not to use float when not
> needed so theres a chance less for platform bitexactness issues

Updated the patch so it's only using integers as well when rounding up.
I hope this works for you.

Best regards,
Lars
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] libavfilter/vf_scale: Ensure scaled video is divisible by n

2019-08-12 Thread Lars Kiesow
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer when used together
with `force_original_aspect_ratio`. This works similar to using `-n` in
the `w` and `h` options.

This option respects the value set for `force_original_aspect_ratio`,
increasing or decreasing the resolution accordingly.

The use case for this is to set a fixed target resolution using `w` and
`h`, to use the `force_original_aspect_ratio` option to make sure that
the video always fits in the defined bounding box regardless of aspect
ratio, but to also make sure that the calculated output resolution is
divisible by n so in can be encoded with certain encoders/options if
that is required.

Signed-off-by: Lars Kiesow 
---
 doc/filters.texi   | 12 
 libavfilter/vf_scale.c | 15 ++-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc7bc..01262d845e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15369,6 +15369,18 @@ Please note that this is a different thing than 
specifying -1 for @option{w}
 or @option{h}, you still need to specify the output resolution for this option
 to work.
 
+@item force_divisible_by Ensures that the output resolution is divisible by the
+given integer when used together with @option{force_original_aspect_ratio}. 
This
+works similar to using -n in the @option{w} and @option{h} options.
+
+This option respects the value set for @option{force_original_aspect_ratio},
+increasing or decreasing the resolution accordingly. This may slightly modify
+the video's aspect ration.
+
+This can be handy, for example, if you want to have a video fit within a 
defined
+resolution using the @option{force_original_aspect_ratio} option but have
+encoder restrictions when it comes to width or height.
+
 @end table
 
 The values of the @option{w} and @option{h} options are expressions
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 7aebf56ad8..bf340b8e7b 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -86,6 +86,7 @@ typedef struct ScaleContext {
 int in_v_chr_pos;
 
 int force_original_aspect_ratio;
+int force_divisible_by;
 
 int nb_slices;
 
@@ -237,7 +238,8 @@ static int config_props(AVFilterLink *outlink)
 goto fail;
 
 /* Note that force_original_aspect_ratio may overwrite the previous set
- * dimensions so that it is not divisible by the set factors anymore. */
+ * dimensions so that it is not divisible by the set factors anymore
+ * unless force_divisible_by is defined as well */
 if (scale->force_original_aspect_ratio) {
 int tmp_w = av_rescale(h, inlink->w, inlink->h);
 int tmp_h = av_rescale(w, inlink->h, inlink->w);
@@ -245,9 +247,19 @@ static int config_props(AVFilterLink *outlink)
 if (scale->force_original_aspect_ratio == 1) {
  w = FFMIN(tmp_w, w);
  h = FFMIN(tmp_h, h);
+ if (scale->force_divisible_by > 1) {
+ // round down
+ w = w / scale->force_divisible_by * scale->force_divisible_by;
+ h = h / scale->force_divisible_by * scale->force_divisible_by;
+ }
 } else {
  w = FFMAX(tmp_w, w);
  h = FFMAX(tmp_h, h);
+ if (scale->force_divisible_by > 1) {
+ // round up
+ w = (w + scale->force_divisible_by - 1) / 
scale->force_divisible_by * scale->force_divisible_by;
+ h = (h + scale->force_divisible_by - 1) / 
scale->force_divisible_by * scale->force_divisible_by;
+ }
 }
 }
 
@@ -600,6 +612,7 @@ static const AVOption scale_options[] = {
 { "disable",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 0 }, 0, 0, FLAGS, 
"force_oar" },
 { "decrease", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 1 }, 0, 0, FLAGS, 
"force_oar" },
 { "increase", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, 
"force_oar" },
+{ "force_divisible_by", "enforce that the output resolution is divisible 
by a defined integer when force_original_aspect_ratio is used", 
OFFSET(force_divisible_by), AV_OPT_TYPE_INT, { .i64 = 1}, 1, 256, FLAGS },
 { "param0", "Scaler param 0", OFFSET(param[0]),  
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
 { "param1", "Scaler param 1", OFFSET(param[1]),  
AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT  }, INT_MIN, INT_MAX, FLAGS },
 { "nb_slices", "set the number of slices (debug purpose only)", 
OFFSET(nb_slices), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, FLAGS },
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/hashenc: use an array of hashes

2019-08-12 Thread Paul B Mahol
On Mon, Aug 12, 2019 at 2:56 PM Moritz Barsnick  wrote:

> On Sun, Aug 11, 2019 at 15:57:46 +0200, Nicolas George wrote:
> > > +c->hashes = av_malloc_array(1, sizeof(c->hashes));
> > > +if (!c->hashes)
> > > +return AVERROR(ENOMEM);
> > > +res = av_hash_alloc(>hashes[0], c->hash_name);
> > > +if (res < 0) {
> > > +av_freep(>hashes);
> >
> > Maybe move all the freing code in a deinit() function?
>
> Sure, I'll have a look how the other muxers do it.
>
> The code is later allocating hashes av_hash_alloc() in a loop over
> nb_streams. If this fails (i.e. out of memory) along the way, do I need
> to remember how many succeeded before? (See patch 4/4.) Or can I just
> av_hash_freep() each one in the array, regardsless?
>
>
Use freep and make sure that arrray holding other arrays is initialized to
0 upon allocation.


> Grateful for any other reviews,
> thanks,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v1 1/2] avfilter/vsrc_mptestsrc: add option to set the max number frames generated for each tests

2019-08-12 Thread Moritz Barsnick
On Mon, Aug 12, 2019 at 19:21:45 +0800, lance.lmw...@gmail.com wrote:
> +Set the max number frames generated for each tests:

Grammar nit:
  Set the maximum number of frames generated for each test

(Note:
 - use the complete word maximum
 - "test", "not tests", when using "for each" singular
 - *of* frames.

> +{ "max_frames", "Set the max number frames generated for each tests", 
> OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
> +{ "m",  " Set the max number frames generated for each tests", 
> OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },

Same here. Also note that you introduced an additional space in the
second string which doesn't belong there.

> +if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at 
> the beginning of each test */
> +tt = (frame/test->max_frames)%(TEST_NB-1);
[...]
> +case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
> 256, 256, frame%test->max_frames); break;
> +case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
> 256, 256, frame%test->max_frames); break;
> +case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
[...]

frame%test->max_frames could probably be assigned to a variable, that
might avoid a lot of code, unless compilers know how to optimize this.
(Might not belong into this functional patch though.)

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/4] avformat/hashenc: use an array of hashes

2019-08-12 Thread Moritz Barsnick
On Sun, Aug 11, 2019 at 15:57:46 +0200, Nicolas George wrote:
> > +c->hashes = av_malloc_array(1, sizeof(c->hashes));
> > +if (!c->hashes)
> > +return AVERROR(ENOMEM);
> > +res = av_hash_alloc(>hashes[0], c->hash_name);
> > +if (res < 0) {
> > +av_freep(>hashes);
>
> Maybe move all the freing code in a deinit() function?

Sure, I'll have a look how the other muxers do it.

The code is later allocating hashes av_hash_alloc() in a loop over
nb_streams. If this fails (i.e. out of memory) along the way, do I need
to remember how many succeeded before? (See patch 4/4.) Or can I just
av_hash_freep() each one in the array, regardsless?

Grateful for any other reviews,
thanks,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH V1 1/2] lavf/avio: add a ffio_realloc_buf API for AVIO buffer realloc

2019-08-12 Thread myp...@gmail.com
On Sun, Aug 11, 2019 at 4:43 PM Steven Liu  wrote:
>
>
>
> > 在 2019年8月8日,19:32,Jun Zhao  写道:
> >
> > From: tomajsjiang 
> >
> > Add new API ffio_realloc_buf for AVIO buffer realloc.
> >
> > Signed-off-by: Zhongxing Jiang 
> > ---
> > libavformat/avio_internal.h |9 +
> > libavformat/aviobuf.c   |   31 +++
> > 2 files changed, 40 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
> > index 04c1ad5..eb628ac 100644
> > --- a/libavformat/avio_internal.h
> > +++ b/libavformat/avio_internal.h
> > @@ -87,6 +87,15 @@ int ffio_read_size(AVIOContext *s, unsigned char *buf, 
> > int size);
> > int ffio_set_buf_size(AVIOContext *s, int buf_size);
> >
> > /**
> > + * Reallocate a given buffer for AVIOContext.
> > + *
> > + * @param s the AVIOContext to realloc.
> > + * @param buf_size required new buffer size.
> > + * @return 0 on success, a negative AVERROR on failure.
> > + */
> > +int ffio_realloc_buf(AVIOContext *s, int buf_size);
> > +
> > +/**
> >  * Ensures that the requested seekback buffer size will be available
> >  *
> >  * Will ensure that when reading sequentially up to buf_size, seeking
> > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> > index 2d01102..3b59180 100644
> > --- a/libavformat/aviobuf.c
> > +++ b/libavformat/aviobuf.c
> > @@ -1093,6 +1093,37 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size)
> > return 0;
> > }
> >
> > +int ffio_realloc_buf(AVIOContext *s, int buf_size)
> > +{
> > +uint8_t *buffer;
> > +int data_size;
> > +
> > +if (!s->buffer_size)
> > +return ffio_set_buf_size(s, buf_size);
> > +
> > +if (buf_size <= s->buffer_size)
> > +return 0;
> > +
> > +buffer = av_malloc(buf_size);
> > +if (!buffer)
> > +return AVERROR(ENOMEM);
> > +
> > +data_size = s->write_flag ? (s->buf_ptr - s->buffer) : (s->buf_end - 
> > s->buf_ptr);
> > +if (data_size > 0)
> > +memcpy(buffer, s->write_flag ? s->buffer : s->buf_ptr, data_size);
> > +av_free(s->buffer);
> > +s->buffer = buffer;
> > +s->orig_buffer_size = buf_size;
> > +s->buffer_size = buf_size;
> > +s->buf_ptr = s->write_flag ? (s->buffer + data_size) : s->buffer;
> > +if (s->write_flag)
> > +s->buf_ptr_max = s->buffer + data_size;
> > +
> > +s->buf_end = s->write_flag ? (s->buffer + s->buffer_size) : 
> > (s->buf_ptr + data_size);
> > +
> > +return 0;
> > +}
> > +
> > static int url_resetbuf(AVIOContext *s, int flags)
> > {
> > av_assert1(flags == AVIO_FLAG_WRITE || flags == AVIO_FLAG_READ);
> > --
> > 1.7.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
>
> patchset LGTM
>
> btw, maybe this should bump version.h ?
>
ffio_realloc_buf is an internal function, I don't know is it needed to
bump the version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] mov: Support fake moov boxes disguised as hoov

2019-08-12 Thread Vittorio Giovara
On Thu, Aug 8, 2019 at 10:28 PM Vittorio Giovara 
wrote:

> Some broken apps generate files that have a fake box named 'hoov'
> instead of a proper 'moov' one. This is speculation but it seems like
> this box contains data to be modified later (eg as file grows in size,
> data gets re-written) and its name is supposed to be changed to 'moov'
> once it can be used as a 'moov', but for some reason this step is skipped.
>
> Since this is not the first time this happens ('moov' boxes can be found
> in 'free' ones) extend the existing hacks to search for the moov in such
> boxes and skip the moov_retry since it needs to be found right away.
> ---
>  libavformat/mov.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> This code is ugly, tips for improving it are welcome, or a full
> rejection is ok too. Unfortunately I cannot share the sample, but VLC
> is able to play it.
> Vittorio
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 24de5429d1..0c2986b72e 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6800,10 +6800,10 @@ static int mov_read_default(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  if (atom.size >= 8) {
>  a.size = avio_rb32(pb);
>  a.type = avio_rl32(pb);
> -if (a.type == MKTAG('f','r','e','e') &&
> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
> +  a.type == MKTAG('h','o','o','v')) &&
>  a.size >= 8 &&
> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT &&
> -c->moov_retry) {
> +c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
>  uint8_t buf[8];
>  uint32_t *type = (uint32_t *)buf + 1;
>  if (avio_read(pb, buf, 8) != 8)
> @@ -6811,7 +6811,7 @@ static int mov_read_default(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  avio_seek(pb, -8, SEEK_CUR);
>  if (*type == MKTAG('m','v','h','d') ||
>  *type == MKTAG('c','m','o','v')) {
> -av_log(c->fc, AV_LOG_ERROR, "Detected moov in a free
> atom.\n");
> +av_log(c->fc, AV_LOG_ERROR, "Detected moov in a free
> or hoov atom.\n");
>  a.type = MKTAG('m','o','o','v');
>  }
>  }
> --
>

ping?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.

2019-08-12 Thread Timo Rothenpieler

On 12/08/2019 12:35, Дмитрий Овчинников wrote:

Yes, it is possible, but it is required to implement separate patch with
selector dx9, dx11, vulkan. We could do it when this one is committed.
I will double check with opencl interop and will comeback.


There is no standardized OpenCL/Vulkan Interop as of now, but there are 
working group for it and it's probably gonna happen sooner or later, so 
it'd be nice to be prepared.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avfilter: add sierpinski video source filter

2019-08-12 Thread Paul B Mahol
Hi,

patch attached.


0001-avfilter-add-sierpinski-video-source.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v1 1/2] avfilter/vsrc_mptestsrc: add option to set the max number frames generated for each tests

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/filters.texi |  3 +++
 libavfilter/vsrc_mptestsrc.c | 27 +++
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc7bc..d3d468b445 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20246,6 +20246,9 @@ Set the number or the name of the test to perform. 
Supported tests are:
 @item ring2
 @item all
 
+@item max_frames, m
+Set the max number frames generated for each tests:
+
 @end table
 
 Default value is "all", which will cycle through the list of all tests.
diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
index c5fdea75dc..f399e43b0b 100644
--- a/libavfilter/vsrc_mptestsrc.c
+++ b/libavfilter/vsrc_mptestsrc.c
@@ -54,6 +54,7 @@ typedef struct MPTestContext {
 const AVClass *class;
 AVRational frame_rate;
 int64_t pts, max_pts, duration;
+int64_t max_frames;
 int hsub, vsub;
 int test;   ///< test_type
 } MPTestContext;
@@ -79,6 +80,8 @@ static const AVOption mptestsrc_options[]= {
 { "ring1",   "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING1},   
INT_MIN, INT_MAX, FLAGS, "test" },
 { "ring2",   "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING2},   
INT_MIN, INT_MAX, FLAGS, "test" },
 { "all", "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_ALL}, 
INT_MIN, INT_MAX, FLAGS, "test" },
+{ "max_frames", "Set the max number frames generated for each tests", 
OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
+{ "m",  " Set the max number frames generated for each tests", 
OFFSET(max_frames), AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
 { NULL }
 };
 
@@ -322,20 +325,20 @@ static int request_frame(AVFilterLink *outlink)
 memset(picref->data[2] + i*picref->linesize[2], 128, cw);
 }
 
-if (tt == TEST_ALL && frame%30) /* draw a black frame at the beginning of 
each test */
-tt = (frame/30)%(TEST_NB-1);
+if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at the 
beginning of each test */
+tt = (frame/test->max_frames)%(TEST_NB-1);
 
 switch (tt) {
-case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame%30); break;
-case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame%30); break;
-case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame%30); break;
-case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame%30); break;
-case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame%30); break;
-case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame%30); break;
-case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame%30); break;
+case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
256, 256, frame%test->max_frames); break;
+case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
256, 256, frame%test->max_frames); break;
+case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
+case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
frame%test->max_frames); break;
+case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
frame%test->max_frames); break;
+case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
+case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
frame%test->max_frames); break;
 }
 
 return ff_filter_frame(outlink, picref);
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH v1 2/2] FATE: add a test for freeezedetect

2019-08-12 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 tests/fate/filter-video.mak |   4 +
 tests/ref/fate/filter-metadata-freezedetect | 251 
 2 files changed, 255 insertions(+)
 create mode 100644 tests/ref/fate/filter-metadata-freezedetect

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 60c6be143b..5b44208838 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -742,6 +742,10 @@ FATE_METADATA_FILTER-$(call ALLYES, $(CROPDETECT_DEPS)) += 
fate-filter-metadata-
 fate-filter-metadata-cropdetect: SRC = $(TARGET_SAMPLES)/filter/cropdetect.mp4
 fate-filter-metadata-cropdetect: CMD = run $(FILTER_METADATA_COMMAND) 
"sws_flags=+accurate_rnd+bitexact;movie='$(SRC)',cropdetect=max_outliers=3"
 
+FREEZEDETECT_DEPS = FFPROBE AVDEVICE LAVFI_INDEV FREEZEDETECT_FILTER
+FATE_METADATA_FILTER-$(call ALLYES, $(FREEZEDETECT_DEPS)) += 
fate-filter-metadata-freezedetect
+fate-filter-metadata-freezedetect: CMD = run $(FILTER_METADATA_COMMAND) 
"sws_flags=+accurate_rnd+bitexact;mptestsrc=r=25:d=10:m=51,freezedetect"
+
 SILENCEDETECT_DEPS = FFPROBE AVDEVICE LAVFI_INDEV AMOVIE_FILTER TTA_DEMUXER 
TTA_DECODER SILENCEDETECT_FILTER
 FATE_METADATA_FILTER-$(call ALLYES, $(SILENCEDETECT_DEPS)) += 
fate-filter-metadata-silencedetect
 fate-filter-metadata-silencedetect: SRC = 
$(TARGET_SAMPLES)/lossless-audio/inside.tta
diff --git a/tests/ref/fate/filter-metadata-freezedetect 
b/tests/ref/fate/filter-metadata-freezedetect
new file mode 100644
index 00..a0ee38e458
--- /dev/null
+++ b/tests/ref/fate/filter-metadata-freezedetect
@@ -0,0 +1,251 @@
+pkt_pts=0
+pkt_pts=1
+pkt_pts=2
+pkt_pts=3
+pkt_pts=4
+pkt_pts=5
+pkt_pts=6
+pkt_pts=7
+pkt_pts=8
+pkt_pts=9
+pkt_pts=10
+pkt_pts=11
+pkt_pts=12
+pkt_pts=13
+pkt_pts=14
+pkt_pts=15
+pkt_pts=16
+pkt_pts=17
+pkt_pts=18
+pkt_pts=19
+pkt_pts=20
+pkt_pts=21
+pkt_pts=22
+pkt_pts=23
+pkt_pts=24
+pkt_pts=25
+pkt_pts=26
+pkt_pts=27
+pkt_pts=28
+pkt_pts=29
+pkt_pts=30
+pkt_pts=31
+pkt_pts=32
+pkt_pts=33
+pkt_pts=34
+pkt_pts=35
+pkt_pts=36
+pkt_pts=37
+pkt_pts=38
+pkt_pts=39
+pkt_pts=40
+pkt_pts=41
+pkt_pts=42
+pkt_pts=43
+pkt_pts=44
+pkt_pts=45
+pkt_pts=46
+pkt_pts=47
+pkt_pts=48
+pkt_pts=49
+pkt_pts=50
+pkt_pts=51
+pkt_pts=52
+pkt_pts=53
+pkt_pts=54
+pkt_pts=55
+pkt_pts=56
+pkt_pts=57
+pkt_pts=58
+pkt_pts=59
+pkt_pts=60
+pkt_pts=61
+pkt_pts=62
+pkt_pts=63
+pkt_pts=64
+pkt_pts=65
+pkt_pts=66
+pkt_pts=67
+pkt_pts=68
+pkt_pts=69
+pkt_pts=70
+pkt_pts=71
+pkt_pts=72
+pkt_pts=73
+pkt_pts=74
+pkt_pts=75
+pkt_pts=76
+pkt_pts=77
+pkt_pts=78
+pkt_pts=79
+pkt_pts=80
+pkt_pts=81
+pkt_pts=82
+pkt_pts=83
+pkt_pts=84
+pkt_pts=85
+pkt_pts=86
+pkt_pts=87
+pkt_pts=88
+pkt_pts=89
+pkt_pts=90
+pkt_pts=91
+pkt_pts=92
+pkt_pts=93
+pkt_pts=94
+pkt_pts=95
+pkt_pts=96
+pkt_pts=97
+pkt_pts=98
+pkt_pts=99
+pkt_pts=100
+pkt_pts=101
+pkt_pts=102
+pkt_pts=103
+pkt_pts=104
+pkt_pts=105
+pkt_pts=106
+pkt_pts=107
+pkt_pts=108
+pkt_pts=109
+pkt_pts=110
+pkt_pts=111
+pkt_pts=112
+pkt_pts=113
+pkt_pts=114
+pkt_pts=115
+pkt_pts=116
+pkt_pts=117
+pkt_pts=118
+pkt_pts=119
+pkt_pts=120
+pkt_pts=121
+pkt_pts=122
+pkt_pts=123
+pkt_pts=124
+pkt_pts=125
+pkt_pts=126
+pkt_pts=127
+pkt_pts=128
+pkt_pts=129
+pkt_pts=130
+pkt_pts=131
+pkt_pts=132
+pkt_pts=133
+pkt_pts=134
+pkt_pts=135
+pkt_pts=136
+pkt_pts=137
+pkt_pts=138
+pkt_pts=139
+pkt_pts=140
+pkt_pts=141
+pkt_pts=142
+pkt_pts=143
+pkt_pts=144
+pkt_pts=145
+pkt_pts=146
+pkt_pts=147
+pkt_pts=148
+pkt_pts=149
+pkt_pts=150
+pkt_pts=151
+pkt_pts=152
+pkt_pts=153|tag:lavfi.freezedetect.freeze_start=4.12|tag:lavfi.freezedetect.freeze_duration=2|tag:lavfi.freezedetect.freeze_end=6.12
+pkt_pts=154
+pkt_pts=155
+pkt_pts=156
+pkt_pts=157
+pkt_pts=158
+pkt_pts=159
+pkt_pts=160
+pkt_pts=161
+pkt_pts=162
+pkt_pts=163
+pkt_pts=164
+pkt_pts=165
+pkt_pts=166
+pkt_pts=167
+pkt_pts=168
+pkt_pts=169
+pkt_pts=170
+pkt_pts=171
+pkt_pts=172
+pkt_pts=173
+pkt_pts=174
+pkt_pts=175
+pkt_pts=176
+pkt_pts=177
+pkt_pts=178
+pkt_pts=179
+pkt_pts=180
+pkt_pts=181
+pkt_pts=182
+pkt_pts=183
+pkt_pts=184
+pkt_pts=185
+pkt_pts=186
+pkt_pts=187
+pkt_pts=188
+pkt_pts=189
+pkt_pts=190
+pkt_pts=191
+pkt_pts=192
+pkt_pts=193
+pkt_pts=194
+pkt_pts=195
+pkt_pts=196
+pkt_pts=197
+pkt_pts=198
+pkt_pts=199
+pkt_pts=200
+pkt_pts=201
+pkt_pts=202
+pkt_pts=203
+pkt_pts=204|tag:lavfi.freezedetect.freeze_start=6.16|tag:lavfi.freezedetect.freeze_duration=2|tag:lavfi.freezedetect.freeze_end=8.16
+pkt_pts=205
+pkt_pts=206
+pkt_pts=207
+pkt_pts=208
+pkt_pts=209
+pkt_pts=210
+pkt_pts=211
+pkt_pts=212
+pkt_pts=213
+pkt_pts=214
+pkt_pts=215
+pkt_pts=216
+pkt_pts=217
+pkt_pts=218
+pkt_pts=219
+pkt_pts=220
+pkt_pts=221
+pkt_pts=222
+pkt_pts=223
+pkt_pts=224
+pkt_pts=225
+pkt_pts=226
+pkt_pts=227
+pkt_pts=228
+pkt_pts=229
+pkt_pts=230
+pkt_pts=231
+pkt_pts=232
+pkt_pts=233
+pkt_pts=234
+pkt_pts=235
+pkt_pts=236
+pkt_pts=237
+pkt_pts=238
+pkt_pts=239
+pkt_pts=240
+pkt_pts=241
+pkt_pts=242
+pkt_pts=243
+pkt_pts=244
+pkt_pts=245
+pkt_pts=246
+pkt_pts=247

Re: [FFmpeg-devel] [PATCH 1/5] avcodec/vp56: Consider the alpha start as end of the prior header

2019-08-12 Thread Peter Ross
On Sun, Aug 11, 2019 at 05:02:47PM +0200, Michael Niedermayer wrote:
> On Sun, Aug 11, 2019 at 09:29:14AM +1000, Peter Ross wrote:
> > On Tue, Aug 06, 2019 at 11:30:02PM +0200, Michael Niedermayer wrote:
> > > Fixes: Timeout (23sec -> 71ms)
> > > Fixes: 
> > > 15661/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6A_fuzzer-6257865947348992
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/vp56.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> > > index 72fea3780e..695f37e972 100644
> > > --- a/libavcodec/vp56.c
> > > +++ b/libavcodec/vp56.c
> > > @@ -572,7 +572,7 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void 
> > > *data, int *got_frame,
> > >  VP56Context *s = avctx->priv_data;
> > >  AVFrame *const p = s->frames[VP56_FRAME_CURRENT];
> > >  int remaining_buf_size = avpkt->size;
> > > -int av_uninit(alpha_offset);
> > > +int alpha_offset = remaining_buf_size;
> > >  int i, res;
> > >  int ret;
> > >  
> > > @@ -585,7 +585,7 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void 
> > > *data, int *got_frame,
> > >  return AVERROR_INVALIDDATA;
> > >  }
> > >  
> > > -res = s->parse_header(s, buf, remaining_buf_size);
> > > +res = s->parse_header(s, buf, alpha_offset);
> > >  if (res < 0)
> > >  return res;
> > >  
> > 
> > hi michael, i am strugling to see a problem with the existing logic.
> > 
> > if (s->has_alpha) {
> > if (remaining_buf_size < 3)
> > return AVERROR_INVALIDDATA;
> > alpha_offset = bytestream_get_be24();
> > remaining_buf_size -= 3;
> > if (remaining_buf_size < alpha_offset)
> > return AVERROR_INVALIDDATA;
> > }
> > 
> > res = s->parse_header(s, buf, remaining_buf_size);
> > if (res < 0)
> > return res;
> > 
> > 
> > if the sample has alpha, remaining_buf_size is reduced in size.
> 
> > can you post the sanple that takes 23s to decode?
> 
> ill send the sample to you privatly

thanks, was able to reproduce. disregard my comment above regarding 
remaining_buf_size.

approve.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

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

Re: [FFmpeg-devel] [PATCH v2] libavcodec/amfenc: Vulkan initialization support for encoder.

2019-08-12 Thread Дмитрий Овчинников
Yes, it is possible, but it is required to implement separate patch with
selector dx9, dx11, vulkan. We could do it when this one is committed.
I will double check with opencl interop and will comeback.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/4xm: Check for end of input in decode_p_block()

2019-08-12 Thread Paul B Mahol
LGTM

On Mon, Aug 12, 2019 at 2:19 AM Michael Niedermayer 
wrote:

> Fixes: Timeout (81sec -> 0.2sec)
> Fixes:
> 16169/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5662570416963584
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/4xm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
> index 8382159bde..1f4e2aee24 100644
> --- a/libavcodec/4xm.c
> +++ b/libavcodec/4xm.c
> @@ -351,6 +351,8 @@ static int decode_p_block(FourXContext *f, uint16_t
> *dst, const uint16_t *src,
>  index = size2index[log2h][log2w];
>  av_assert0(index >= 0);
>
> +if (get_bits_left(>gb) < 1)
> +return AVERROR_INVALIDDATA;
>  h = 1 << log2h;
>  code  = get_vlc2(>gb, block_type_vlc[1 - (f->version >
> 1)][index].table,
>   BLOCK_TYPE_VLC_BITS, 1);
> --
> 2.22.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCHv2 1/3] avformat/avio: add avio_print_string_array and avio_print

2019-08-12 Thread Marton Balint
These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporary buffer is necessary.

Signed-off-by: Marton Balint 
---
 doc/APIchanges|  3 +++
 libavformat/avio.h| 17 +
 libavformat/aviobuf.c |  6 ++
 libavformat/version.h |  2 +-
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..ba35b847d9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2019-08-xx - xx - lavf 58.31.100 - avio.h
+  Add avio_print_string_array and avio_print.
+
 2019-07-27 - xx - lavu 56.33.100 - tx.h
   Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index dcb8dcdf93..910e4f1b48 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -574,6 +574,23 @@ int avio_feof(AVIOContext *s);
 /** @warning Writes up to 4 KiB per call */
 int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2, 3);
 
+/**
+ * Write a NULL terminated array of strings to the context.
+ * Usually you don't need to use this function directly but its macro wrapper,
+ * avio_print.
+ */
+void avio_print_string_array(AVIOContext *s, const char *strings[]);
+
+/**
+ * Write strings (const char *) to the context.
+ * This is a convenience macro around avio_print_string_array and it
+ * automatically creates the string array from the variable argument list.
+ * For simple string concatenations this function is more performant than using
+ * avio_printf since it does not need a temporary buffer.
+ */
+#define avio_print(s, ...) \
+avio_print_string_array(s, (const char*[]){__VA_ARGS__, NULL})
+
 /**
  * Force flushing of buffered data.
  *
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2d011027c9..be4c97f827 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1225,6 +1225,12 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
 return ret;
 }
 
+void avio_print_string_array(AVIOContext *s, const char *strings[])
+{
+for(; *strings; strings++)
+avio_write(s, (const unsigned char *)*strings, strlen(*strings));
+}
+
 int avio_pause(AVIOContext *s, int pause)
 {
 if (!s->read_pause)
diff --git a/libavformat/version.h b/libavformat/version.h
index 45efaff9b9..feceaedc08 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
-#define LIBAVFORMAT_VERSION_MINOR  30
+#define LIBAVFORMAT_VERSION_MINOR  31
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.16.4

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

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

Re: [FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229

2019-08-12 Thread Thilo Borgmann
Am 12.08.19 um 08:13 schrieb Zhong Li:
> Signed-off-by: Zhong Li 
> ---
> https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but not 
> found by fate, so add it.
> Test clip produced by:
> ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy 
> /fate-suite/mjpeg/mjpeg_field_order.avi
> 
>  tests/fate/video.mak| 3 +++
>  tests/ref/fate/mjpeg-ticket3229 | 8 
>  2 files changed, 11 insertions(+)
>  create mode 100644 tests/ref/fate/mjpeg-ticket3229
> [...]

LGTM & sample uploaded.

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

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

Re: [FFmpeg-devel] [PATCHv2 5/6] avformat/mpegtsenc: fix PCR generation intervals

2019-08-12 Thread Andreas Håkon
Hi Marton,


‐‐‐ Original Message ‐‐‐
On Sunday, 11 de August de 2019 22:14, Marton Balint  wrote:

> > > +/* For VBR we select the highest multiple of frame duration 
> > > which is less than 100 ms. */
> >
> > Don't you think it's a good idea to use the parameter "pcr_period" as the 
> > limit,
> > instead of a fixed value of 100ms?
>
> Yes, but I think it is better make that feature a separate patch.

OK. Waiting for it.


> > And I think you've forgotten the file "muxers.texi" in this v2 version of 
> > the patch.
> > (the original patch 5 has it).
>
> That is intentional. The existing behaviour is preserved, so no change is
> required in the docs. When I make a separate patch to add support for
> setting pcr_period for VBR (should be trivial to do on top of the existing
> patchset), then I will update the docs.

OK. Then no problem.

Regards.
A.H.

---

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

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

[FFmpeg-devel] Request for a resource

2019-08-12 Thread Abhinav Rao
Hello, everyone. I'm Abhinav Rao, a second-year undergrad from India. I
have some experience in working with C and Assembly, and would like to
contribute to FFmpeg. It would be great if someone could guide me to any
resource(s) that would help me get acquainted with the codebase.
Thank you,
Abhinav
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9 support

2019-08-12 Thread Guo, Yejun
example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M 
tmp.webm

Signed-off-by: Guo, Yejun 
---
 libavcodec/libvpxenc.c | 177 +
 1 file changed, 177 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 1a85bc6..09caf9e 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -116,6 +116,9 @@ typedef struct VPxEncoderContext {
 int tune_content;
 int corpus_complexity;
 int tpl_model;
+// If the driver does not support ROI then warn the first time we
+// encounter a frame with ROI side data.
+int roi_warned;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -1057,6 +1060,172 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
*pkt_out)
 return size;
 }
 
+static int set_roi_map(AVCodecContext *avctx, const AVFrameSideData *sd, int 
frame_width, int frame_height,
+   vpx_roi_map_t *roi_map, int block_size, int segment_cnt)
+{
+/* range of vpx_roi_map_t.delta_q[i] is [-63, 63] */
+#define MAX_DELTA_Q 63
+
+const AVRegionOfInterest *roi = NULL;
+int nb_rois;
+uint32_t self_size;
+int segment_id;
+
+/* record the mapping from delta_q to "segment id + 1" in 
segment_mapping[].
+ * the range of delta_q is [-MAX_DELTA_Q, MAX_DELTA_Q],
+ * and its corresponding array index is [0, 2 * MAX_DELTA_Q],
+ * and so the length of the mapping array is 2 * MAX_DELTA_Q + 1.
+ * "segment id + 1", so we can say there's no mapping if the value of 
array element is zero.
+ */
+int segment_mapping[2 * MAX_DELTA_Q + 1] = { 0 };
+
+memset(roi_map, 0, sizeof(*roi_map));
+
+/* segment id 0 in roi_map is reserved for the areas not covered by 
AVRegionOfInterest.
+ * segment id 0 in roi_map is also for the areas with 
AVRegionOfInterest.qoffset near 0.
+ * (delta_q of segment id 0 is 0).
+ */
+segment_mapping[MAX_DELTA_Q] = 1;
+/* roi_map has memset with zero, just explictly set it again for explict 
understanding. */
+roi_map->delta_q[0] = 0;
+segment_id = 1;
+
+roi = (const AVRegionOfInterest*)sd->data;
+self_size = roi->self_size;
+if (!self_size || sd->size % self_size != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AVRegionOfInterest.self_size.\n");
+return AVERROR(EINVAL);
+}
+nb_rois = sd->size / self_size;
+
+/* This list must be iterated from zero because regions are
+ * defined in order of decreasing importance. So discard less
+ * important areas if they exceed the segment count.
+ */
+for (int i = 0; i < nb_rois; i++) {
+int delta_q;
+int mapping_index;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+if (roi->qoffset.den == 0) {
+av_log(avctx, AV_LOG_ERROR, "AVRegionOfInterest.qoffset.den must 
not be zero.\n");
+return AVERROR(EINVAL);
+}
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_index = delta_q + MAX_DELTA_Q;
+if (!segment_mapping[mapping_index]) {
+if (segment_id == segment_cnt) {
+av_log(avctx, AV_LOG_WARNING,
+   "ROI only supports %d segments (and segment 0 is 
reserved for non-ROIs), skipping the left ones.\n",
+   segment_cnt);
+break;
+}
+
+segment_mapping[mapping_index] = segment_id + 1;
+roi_map->delta_q[segment_id] = delta_q;
+segment_id++;
+}
+}
+
+
+roi_map->rows = (frame_height + block_size - 1) / block_size;
+roi_map->cols = (frame_width  + block_size - 1) / block_size;
+roi_map->roi_map = av_mallocz_array(roi_map->rows * roi_map->cols, 
sizeof(*roi_map->roi_map));
+if (!roi_map->roi_map) {
+av_log(avctx, AV_LOG_ERROR, "roi_map alloc failed.\n");
+return AVERROR(ENOMEM);
+}
+
+/* This list must be iterated in reverse, so for the case that
+ * two regions overlapping, the more important area takes effect.
+ */
+for (int i = nb_rois - 1; i >= 0; i--) {
+int delta_q;
+int mapping_value;
+int starty, endy, startx, endx;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+
+starty = av_clip(roi->top / block_size, 0, roi_map->rows);
+endy   = av_clip((roi->bottom + block_size - 1) / block_size, 0, 
roi_map->rows);
+startx = av_clip(roi->left / block_size, 0, roi_map->cols);
+endx   = av_clip((roi->right + block_size - 1) / block_size, 0, 
roi_map->cols);
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_value = segment_mapping[delta_q + MAX_DELTA_Q];
+if 

Re: [FFmpeg-devel] [PATCH 1/3] tools/target_dec_fuzzer: Limit number off all pixels decoded

2019-08-12 Thread Michael Niedermayer
On Wed, Jul 31, 2019 at 10:52:32AM +0200, Michael Niedermayer wrote:
> This should reduces the number of uninteresting timeouts encountered
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

will apply with some improvment to allow better seperation of really slow
codecs from fast ones. A single threshold doenst work

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

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

[FFmpeg-devel] [PATCH V3] fate: add a case for ticket #3229

2019-08-12 Thread Zhong Li
Signed-off-by: Zhong Li 
---
https://patchwork.ffmpeg.org/patch/13725/ introduces a regression but not found 
by fate, so add it.
Test clip produced by:
ffmpeg -i tickets/3229/bad.avi -vframes 3 -c:v copy 
/fate-suite/mjpeg/mjpeg_field_order.avi

 tests/fate/video.mak| 3 +++
 tests/ref/fate/mjpeg-ticket3229 | 8 
 2 files changed, 11 insertions(+)
 create mode 100644 tests/ref/fate/mjpeg-ticket3229

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index be1458c..d2d43e5 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -232,6 +232,9 @@ fate-mimic: CMD = framecrc -idct simple -i 
$(TARGET_SAMPLES)/mimic/mimic2-womanl
 FATE_VIDEO-$(call DEMDEC, MOV, MJPEGB) += fate-mjpegb
 fate-mjpegb: CMD = framecrc -idct simple -fflags +bitexact -i 
$(TARGET_SAMPLES)/mjpegb/mjpegb_part.mov -an
 
+FATE_VIDEO-$(call DEMDEC, AVI, MJPEG) += fate-mjpeg-ticket3229
+fate-mjpeg-ticket3229: CMD = framecrc -idct simple -fflags +bitexact -i 
$(TARGET_SAMPLES)/mjpeg/mjpeg_field_order.avi -an
+
 FATE_VIDEO-$(call DEMDEC, MVI, MOTIONPIXELS) += fate-motionpixels
 fate-motionpixels: CMD = framecrc -i 
$(TARGET_SAMPLES)/motion-pixels/INTRO-partial.MVI -an -pix_fmt rgb24 -frames:v 
111
 
diff --git a/tests/ref/fate/mjpeg-ticket3229 b/tests/ref/fate/mjpeg-ticket3229
new file mode 100644
index 000..fc5a8dd
--- /dev/null
+++ b/tests/ref/fate/mjpeg-ticket3229
@@ -0,0 +1,8 @@
+#tb 0: 1/30
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 468x312
+#sar 0: 0/1
+0,  0,  0,1,   292032, 0x3af3a5f7
+0,  6,  6,1,   292032, 0xe97fb504
+0,  8,  8,1,   292032, 0xd448db04
-- 
2.7.4

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

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

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/hnm4video: Optimize postprocess_current_frame()

2019-08-12 Thread Michael Niedermayer
On Sat, Aug 03, 2019 at 04:07:22PM +0200, Tomas Härdin wrote:
> lör 2019-08-03 klockan 01:49 +0200 skrev Michael Niedermayer:
> > -uint32_t x, y, src_x, src_y;
> > +uint32_t x, y, src_y;
> > +int width = hnm->width;
> >  
> >  for (y = 0; y < hnm->height; y++) {
> > +uint8_t *dst = hnm->processed + y * width;
> > +const uint8_t *src = hnm->current;
> >  src_y = y - (y % 2);
> > -src_x = src_y * hnm->width + (y % 2);
> > -for (x = 0; x < hnm->width; x++) {
> > -hnm->processed[(y * hnm->width) + x] = hnm-
> > >current[src_x];
> > -src_x += 2;
> > +src += src_y * width + (y % 2);
> > +for (x = 0; x < width; x++) {
> > +dst[x] = *src;
> > +src += 2;
> 
> Looks OK. Maybe telling the compiler that src and dst don't alias would
> be worthwhile?

will apply (as discussed later without restrict as it doesnt help)

thx


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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

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