date:20181009

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Add support for AV_PIX_FMT_BGRA.

2018-10-09 Thread Li, Zhong

> From: Li, Zhong
> Sent: Thursday, September 6, 2018 5:25 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [PATCH] lavu/hwcontext_qsv: Add support for AV_PIX_FMT_BGRA.
> 
> RGB32(AV_PIX_FMT_BGRA on intel platforms) format may be used as
> overlay with alpha blending.
> So add AV_PIX_FMT_BGRA format support.
> 
> Rename RGB32 to be BGRA to make it clearer as Mark Thompson's
> suggestion.
> 
> V2: Add P010 format support else will introduce HEVC 10bit encoding
> regression.
> Thanks for LinJie's discovery.
> 
> Signed-off-by: Zhong Li 
> Verified-by: Fu, Linjie 
> ---
>  libavfilter/qsvvpp.c  |  2 +-
>  libavutil/hwcontext_qsv.c | 44
> ++--
>  2 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index 
> 7ee1e56..06efdf5
> 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -142,7 +142,7 @@ static int pix_fmt_to_mfx_fourcc(int format)
>  return MFX_FOURCC_NV12;
>  case AV_PIX_FMT_YUYV422:
>  return MFX_FOURCC_YUY2;
> -case AV_PIX_FMT_RGB32:
> +case AV_PIX_FMT_BGRA:
>  return MFX_FOURCC_RGB4;
>  }
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index
> 250091c..fa7459c 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -90,6 +90,7 @@ static const struct {
>  uint32_t   fourcc;
>  } supported_pixel_formats[] = {
>  { AV_PIX_FMT_NV12, MFX_FOURCC_NV12 },
> +{ AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
>  { AV_PIX_FMT_P010, MFX_FOURCC_P010 },
>  { AV_PIX_FMT_PAL8, MFX_FOURCC_P8   },
>  };
> @@ -731,6 +732,37 @@ static int
> qsv_transfer_data_child(AVHWFramesContext *ctx, AVFrame *dst,
>  return ret;
>  }
> 
> +static int map_frame_to_surface(const AVFrame *frame,
> mfxFrameSurface1
> +*surface) {
> +switch (frame->format) {
> +case AV_PIX_FMT_NV12:
> +case AV_PIX_FMT_P010:
> +surface->Data.Y  = frame->data[0];
> +surface->Data.UV = frame->data[1];
> +break;
> +
> +case AV_PIX_FMT_YUV420P:
> +surface->Data.Y = frame->data[0];
> +surface->Data.U = frame->data[1];
> +surface->Data.V = frame->data[2];
> +break;
> +
> +case AV_PIX_FMT_BGRA:
> +surface->Data.B = frame->data[0];
> +surface->Data.G = frame->data[0] + 1;
> +surface->Data.R = frame->data[0] + 2;
> +surface->Data.A = frame->data[0] + 3;
> +break;
> +
> +default:
> +return MFX_ERR_UNSUPPORTED;
> +}
> +surface->Data.Pitch = frame->linesize[0];
> +surface->Data.TimeStamp = frame->pts;
> +
> +return 0;
> +}
> +
>  static int qsv_transfer_data_from(AVHWFramesContext *ctx, AVFrame
> *dst,
>const AVFrame *src)  { @@
> -750,11 +782,7 @@ static int qsv_transfer_data_from(AVHWFramesContext
> *ctx, AVFrame *dst,
>  }
> 
>  out.Info = in->Info;
> -out.Data.PitchLow = dst->linesize[0];
> -out.Data.Y= dst->data[0];
> -out.Data.U= dst->data[1];
> -out.Data.V= dst->data[2];
> -out.Data.A= dst->data[3];
> +map_frame_to_surface(dst, );
> 
>  do {
>  err = MFXVideoVPP_RunFrameVPPAsync(s->session_download, in,
> , NULL, ); @@ -797,11 +825,7 @@ static int
> qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
>  }
> 
>  in.Info = out->Info;
> -in.Data.PitchLow = src->linesize[0];
> -in.Data.Y= src->data[0];
> -in.Data.U= src->data[1];
> -in.Data.V= src->data[2];
> -in.Data.A= src->data[3];
> +map_frame_to_surface(src, );
> 
>  do {
>  err = MFXVideoVPP_RunFrameVPPAsync(s->session_upload, ,
> out, NULL, );
> --
> 2.7.4

Ping? 
If nobody against it, I prefer to push it with an alpha blending overlay 
command example in the commit message. 

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

Re: [FFmpeg-devel] [PATCH 6/7] libavfilter/vf_sr.c: Removes uint8 -> float and float -> uint8 conversions.

2018-10-09 Thread Pedro Arthur

Hi,
Em seg, 8 de out de 2018 às 23:59, Liu Steven  escreveu:
>
>
>
> > 在 2018年8月15日，上午2:37，Pedro Arthur  写道：
> >
> > Patch pushed.
>
> How should i test it?
If you already performed the training (train_srcnn.sh/train_espcn.sh)
you can generate the model files using the script
'generate_header_and_model.py' provided in the repo. If not I'm
attaching my generated models.
Then
./ffmpeg -i img -vf sr=model=model_file_name output
or if you have TF
./ffmpeg -i img -vf sr=model=model_file_name:dnn_backend=tensorflow output


>
>
> bash generate_datasets.sh
> (py3k) [root@onvideo sr]# ls 
> logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100*
> logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100.ckpt.data-0-of-1
>   logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100.ckpt.index  
> logdir/srcnn_batch_32_lr_1e-3_decay_adam/train/model_100.ckpt.meta
> (py3k) [root@onvideo sr]#
>
> [root@onvideo nvidia]# ./ffmpeg
> ffmpeg version N-91943-g1b98bfb Copyright (c) 2000-2018 the FFmpeg developers
>   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
>   configuration: --enable-ffnvcodec --enable-libtensorflow 
> --extra-ldflags=-L/data/liuqi/tensorflow/bazel-bin/tensorflow/
>   libavutil  56. 19.101 / 56. 19.101
>   libavcodec 58. 30.100 / 58. 30.100
>   libavformat58. 18.100 / 58. 18.100
>   libavdevice58.  4.103 / 58.  4.103
>   libavfilter 7. 31.100 /  7. 31.100
>   libswscale  5.  2.100 /  5.  2.100
>   libswresample   3.  2.100 /  3.  2.100
> Hyper fast Audio and Video encoder
> usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] 
> outfile}...
>
> Use -h to get full help or, even better, run 'man ffmpeg'
> [root@onvideo nvidia]# pwd
> /data/liuqi/ffmpeg/nvidia
> [root@onvideo nvidia]#
>
>
> BTW, the GitHub link looks no body maintaining it. 
> https://github.com/HighVoltageRocknRoll/sr
Is there anything that is not working?

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

[FFmpeg-devel] [PATCH 2/2] avcodec/utils: keep CORRUPT and TRUSTED packet flags when parsing packets

2018-10-09 Thread Marton Balint

An FF_ macro got defined in avcodec.h to store the flags which need to be
propagated when parsers split packets so this won't be forgotten when a new
packet flag is introduced.

(I wonder if DISPOSABLE also fits here, or maybe some special handling is
needed like it is done for the keyframe flag?)
---
 libavcodec/avcodec.h | 9 -
 libavcodec/version.h | 2 +-
 libavformat/utils.c  | 2 +-
 tests/ref/fate/flv-demux | 2 +-
 tests/ref/fate/iv8-demux | 2 +-
 tests/ref/fate/segment-mp4-to-ts | 6 +++---
 tests/ref/fate/ts-demux  | 2 +-
 7 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 705a3ce4f3..9a3f9b6226 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1493,7 +1493,14 @@ typedef struct AVPacket {
  * be discarded by the decoder.  I.e. Non-reference frames.
  */
 #define AV_PKT_FLAG_DISPOSABLE 0x0010
-
+/**
+ * Packet flags which must always be kept when parsers split packets
+ */
+#define FF_PKT_FLAGS_KEEP_WHEN_PARSING (\
+AV_PKT_FLAG_CORRUPT | \
+AV_PKT_FLAG_DISCARD | \
+AV_PKT_FLAG_TRUSTED | \
+0)
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 97d134851f..79c5dc6773 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  32
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a8ac90213e..351bd88fa5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1511,7 +1511,7 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 out_pkt.pts  = st->parser->pts;
 out_pkt.dts  = st->parser->dts;
 out_pkt.pos  = st->parser->pos;
-out_pkt.flags   |= pkt->flags & AV_PKT_FLAG_DISCARD;
+out_pkt.flags   |= pkt->flags & FF_PKT_FLAGS_KEEP_WHEN_PARSING;
 
 if (st->need_parsing == AVSTREAM_PARSE_FULL_RAW)
 out_pkt.pos = st->parser->frame_offset;
diff --git a/tests/ref/fate/flv-demux b/tests/ref/fate/flv-demux
index 4a791754cb..0feac7a090 100644
--- a/tests/ref/fate/flv-demux
+++ b/tests/ref/fate/flv-demux
@@ -613,4 +613,4 @@
 0,  11612,  11612,   33, 1078, 0x501d1c72, F=0x0
 0,  11645,  11645,   33, 2600, 0xdf370d24, F=0x0
 1,  11656,  11656,   46,  346, 0x8899a188
-0,  11678,  11678,   33, 1190, 0xdc1e4c99, F=0x0
+0,  11678,  11678,   33, 1190, 0xdc1e4c99, F=0x2
diff --git a/tests/ref/fate/iv8-demux b/tests/ref/fate/iv8-demux
index 518f3de974..860a287d53 100644
--- a/tests/ref/fate/iv8-demux
+++ b/tests/ref/fate/iv8-demux
@@ -27,5 +27,5 @@
 0,  72000,  72000,0,20891, 0x3d064fd3
 0,  75600,  75600,0,20834, 0xcb774dbc
 0,  79200,  79200,0,20870, 0xbc536589
-0,  82800,  82800,0,21421, 0xc99a68e4
+0,  82800,  82800,0,21421, 0xc99a68e4, F=0x3
 0,  86400,  86400,0,12869, 0x5684e304
diff --git a/tests/ref/fate/segment-mp4-to-ts b/tests/ref/fate/segment-mp4-to-ts
index b5accb60f7..f54871b8a1 100644
--- a/tests/ref/fate/segment-mp4-to-ts
+++ b/tests/ref/fate/segment-mp4-to-ts
@@ -23,7 +23,7 @@
 0,  50400,  54000,0,  607, 0xc53c2339, F=0x0, S=1,
1, 0x00e000e0
 0,  54000,  72000,0, 4755, 0x2f642b58, F=0x0, S=1,
1, 0x00e000e0
 0,  57600,  64800,0, 1182, 0xbe1a4847, F=0x0, S=1,
1, 0x00e000e0
-0,  61200,  61200,0,  809, 0x8d948a4e, F=0x0, S=1,
1, 0x00e000e0
+0,  61200,  61200,0,  809, 0x8d948a4e, F=0x2, S=1,
1, 0x00e000e0
 0,  64800,  68400,0,  656, 0x4fa03c2b, F=0x0, S=1,
1, 0x00e000e0
 0,  68400,  86400,0,26555, 0x5629b584, S=1,1, 
0x00e000e0
 0,  72000,  79200,0, 1141, 0x761b31e8, F=0x0, S=1,
1, 0x00e000e0
@@ -95,7 +95,7 @@
 0, 309600, 313200, 3600,  829, 0xffd795cd, F=0x0, S=1,
1, 0x00e000e0
 0, 313200, 331200, 3600, 5352, 0x59997996, F=0x0, S=1,
1, 0x00e000e0
 0, 316800, 324000, 3600, 1501, 0xb3b8f001, F=0x0, S=1,
1, 0x00e000e0
-0, 320400, 320400, 3600,  941, 0x92b0cb18, F=0x0, S=1,
1, 0x00e000e0
+0, 320400, 320400, 3600,  941, 0x92b0cb18, F=0x2, S=1,
1, 0x00e000e0
 0, 324000, 327600, 3600,  823, 0x3d548355, F=0x0, S=1,
1, 0x00e000e0
 0, 327600,

[FFmpeg-devel] [PATCH 1/2] ffmpeg: log corrupted packets and frames

2018-10-09 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index aa495b5d9e..da4259a9a8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2110,10 +2110,12 @@ static void check_decode_result(InputStream *ist, int 
*got_output, int ret)
 if (ret < 0 && exit_on_error)
 exit_program(1);
 
-if (exit_on_error && *got_output && ist) {
+if (*got_output && ist) {
 if (ist->decoded_frame->decode_error_flags || 
(ist->decoded_frame->flags & AV_FRAME_FLAG_CORRUPT)) {
-av_log(NULL, AV_LOG_FATAL, "%s: corrupt decoded frame in stream 
%d\n", input_files[ist->file_index]->ctx->url, ist->st->index);
-exit_program(1);
+av_log(NULL, exit_on_error ? AV_LOG_FATAL : AV_LOG_WARNING,
+   "%s: corrupt decoded frame in stream %d\n", 
input_files[ist->file_index]->ctx->url, ist->st->index);
+if (exit_on_error)
+exit_program(1);
 }
 }
 }
@@ -4350,9 +4352,11 @@ static int process_input(int file_index)
 if (ist->discard)
 goto discard_packet;
 
-if (exit_on_error && (pkt.flags & AV_PKT_FLAG_CORRUPT)) {
-av_log(NULL, AV_LOG_FATAL, "%s: corrupt input packet in stream %d\n", 
is->url, pkt.stream_index);
-exit_program(1);
+if (pkt.flags & AV_PKT_FLAG_CORRUPT) {
+av_log(NULL, exit_on_error ? AV_LOG_FATAL : AV_LOG_WARNING,
+   "%s: corrupt input packet in stream %d\n", is->url, 
pkt.stream_index);
+if (exit_on_error)
+exit_program(1);
 }
 
 if (debug_ts) {
-- 
2.16.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

2018-10-09 Thread Banana M.

I've sent the patch again with some tweaks and fixed the test, please check
if it is satisfactory now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

2018-10-09 Thread Marton Balint




On Tue, 9 Oct 2018, Timo Rothenpieler wrote:


On 09/10/2018 02:32, Carl Eugen Hoyos wrote:

2018-10-08 21:59 GMT+02:00, Timo Rothenpieler :

So, to be able to use these hardware compatible formats, we need
definitions for them in ffmpeg. Right now, I need this for nvdec,
but Vulkan also uses the same format definitions.


Sorry if this was already done and I forgot but please explain why
you cannot use YUV444P16 for this use-case.

If the only thing missing is libavfilter understanding
bits_per_raw_sample
we should add it there: It is needed in any case and would save us a few
pix_fmts and could speed up many use cases compared to your solution.


It's pretty much all of ffmpeg and all client applications understanding
it.
First of all, bits_per_raw_sample, or an equivalent bit depth field, is
missing from AVFrame.
"In" avfilter it's primarily swscale I guess, but it also affects each
and every filter supporting YUV444P16.
Also, for encoders, it would mean they need a way to indicate what bit
depths they can take, and that also has to be per pix_fmt they support.
Then all of avcodec, ffmpeg.c, ... needs support for that.
It's quite a deep rabit hole of changes with quite a good chance of
something going horribly wrong in the process. Probably even in more
places than just the ones mentioned here.


This may or may not be true, unfortunately my question was not
how difficult it would be to fix this mess (I don't think it is), but
why you want to add more to the mess.

What would happen if you just use YUV444P16?


For example nvenc only supports 10 bit encoding, but takes it in the 
YUV444P16 format. The rest of ffmpeg has no idea it only supports 10 bit, and 
at times even up-converts 10 bit content to 16 bit via swscale due to that.


Isn't the same thing happening for audio with s24le codec?

What is the downside of extending the precision of the filtering pipeline 
to full 16 bit in cases like this? I don't think it affects most filters 
speedwise.


Also, it loses quality without the user noticing, as there is no outside 
indication it does in fact not support 16 bit.


It's up to the tool to be user friendly, not the framework.

I still think proper implementation is hard (even the YUVJ removal patch 
got abandoned), so I don't know how to move forward. Maybe we should come 
up with some issue and requirement list first, and decide after that.


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

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

2018-10-09 Thread Carl Eugen Hoyos

2018-10-10 1:15 GMT+02:00, bananaman...@gmail.com :
> From: bnnm 
>
> Improves trac issue #6722. Fixes truncated WMAPRO/XMA output due to delay
> samples and partially applies bitstream gapless info.
>
> This can be tested with files encoding a small nb_samples (like 400), which
> couldn't output anything due to missing delay at the end.
>
> Applying end_skip and partial delay samples would require some extra
> changes, so files are slightly bigger than what should be.
>
> Signed-off-by: bnnm 
> ---
>  libavcodec/wmaprodec.c | 100
> -
>  tests/fate/wma.mak |   1 +
>  2 files changed, 74 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
> index 9439bfa771..e18e2e438f 100644
> --- a/libavcodec/wmaprodec.c
> +++ b/libavcodec/wmaprodec.c
> @@ -216,9 +216,9 @@ typedef struct WMAProDecodeCtx {
>  GetBitContextgb;///< bitstream reader
> context
>  int  buf_bit_size;  ///< buffer size in
> bits
>  uint8_t  drc_gain;  ///< gain for the DRC
> tool
> -int8_t   skip_frame;///< skip output step
>  int8_t   parsed_all_subframes;  ///< all subframes
> decoded?
>  uint8_t  skip_packets;  ///< packets to skip to
> find next packet in a stream (XMA1/2)
> +int8_t   eof_done;  ///< set when EOF
> reached and extra subframe is written (XMA1/2)
>
>  /* subframe/block decode state */
>  int16_t  subframe_len;  ///< current subframe
> length
> @@ -379,12 +379,6 @@ static av_cold int decode_init(WMAProDecodeCtx *s,
> AVCodecContext *avctx, int nu
>  return AVERROR_PATCHWELCOME;
>  }
>
> -/** frame info */
> -if (avctx->codec_id != AV_CODEC_ID_WMAPRO)
> -s->skip_frame = 0;
> -else
> -s->skip_frame = 1; /* skip first frame */
> -
>  s->packet_loss = 1;
>  s->len_prefix  = (s->decode_flags & 0x40);
>
> @@ -1450,21 +1444,38 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame
> *frame, int *got_frame_ptr)
>  ff_dlog(s->avctx, "drc_gain %i\n", s->drc_gain);
>  }
>
> -/** no idea what these are for, might be the number of samples
> -that need to be skipped at the beginning or end of a stream */
> +/** read encoder delay/padding (gapless) info */
>  if (get_bits1(gb)) {
> -int av_unused skip;
> +int start_skip, end_skip;
> +
>
> -/** usually true for the first frame */
> +/** usually true for the first frame and equal to 1 frame */
>  if (get_bits1(gb)) {
> -skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "start skip: %i\n", skip);
> +start_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +start_skip = FFMIN(start_skip, s->samples_per_frame);
> +
> +/* must add for XMA to respect starting skip_samples */
> +s->avctx->internal->skip_samples += start_skip;
>  }
>
> -/** sometimes true for the last frame */
> +/** usually true for the last frame and less than 1 frame */
>  if (get_bits1(gb)) {
> -skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "end skip: %i\n", skip);
> +end_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +end_skip = FFMIN(end_skip, s->samples_per_frame);
> +
> +//TODO fix end_skip (also needs changes in XMA multistream's
> handling)
> +/* for XMA/WMAPRO end_skip may span last frame + final delay
> samples,
> + * so we'd need some counter to (possibly) skip some in this
> frame and
> + * rest after last frame (buf_size 0), so final samples would
> be:
> + * samples_per_frame + delay_samples - start_skip - end_skip
> + * (files with 1 packet are possible so both skips are
> considered).
> + *
> + * WMAPRO 5.1 in XWMA does't do this and audio is padded
> instead,
> + * and min packets is 2 (assumes only 1/2ch need it). */
> +
> +if (s->avctx->codec_id == AV_CODEC_ID_WMAPRO && s->nb_channels
>> 2) {
> +frame->nb_samples = s->samples_per_frame - end_skip;
> +}
>  }
>
>  }
> @@ -1500,13 +1511,9 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame
> *frame, int *got_frame_ptr)
> s->samples_per_frame * sizeof(*s->channel[i].out) >> 1);
>  }
>
> -if (s->skip_frame) {
> -s->skip_frame = 0;
> -*got_frame_ptr = 0;
> -av_frame_unref(frame);
> -} else {
> -*got_frame_ptr = 1;
> -}
> +/** frame may be partially discarded with gapless info in the bitstream
> */
> +*got_frame_ptr = 1;
> +
>
>  if (s->len_prefix) {
>

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning

2018-10-09 Thread Jan Ekström

On Wed, Oct 10, 2018 at 2:10 AM Jan Ekström  wrote:
>
> As libavformat should at this point be handling general input
> timestamp discontinuities for us - such as with MPEG-TS - the
> amount of messages from this case should be small, and if it
> does start spamming messages, that would be a sign that either
> the input, or the discontinuity handling code itself is broken.
>
> In other words, printing this on the warning level makes more
> sense than staying silent on most verbosity levels.
> ---
>  fftools/ffmpeg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

For context on this, please see trac issue #7482
(https://trac.ffmpeg.org/ticket/7482) .

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

[FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

2018-10-09 Thread bananaman255

From: bnnm 

Improves trac issue #6722. Fixes truncated WMAPRO/XMA output due to delay 
samples and partially applies bitstream gapless info.

This can be tested with files encoding a small nb_samples (like 400), which 
couldn't output anything due to missing delay at the end.

Applying end_skip and partial delay samples would require some extra changes, 
so files are slightly bigger than what should be.

Signed-off-by: bnnm 
---
 libavcodec/wmaprodec.c | 100 -
 tests/fate/wma.mak |   1 +
 2 files changed, 74 insertions(+), 27 deletions(-)

diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 9439bfa771..e18e2e438f 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -216,9 +216,9 @@ typedef struct WMAProDecodeCtx {
 GetBitContextgb;///< bitstream reader 
context
 int  buf_bit_size;  ///< buffer size in bits
 uint8_t  drc_gain;  ///< gain for the DRC tool
-int8_t   skip_frame;///< skip output step
 int8_t   parsed_all_subframes;  ///< all subframes decoded?
 uint8_t  skip_packets;  ///< packets to skip to 
find next packet in a stream (XMA1/2)
+int8_t   eof_done;  ///< set when EOF reached 
and extra subframe is written (XMA1/2)
 
 /* subframe/block decode state */
 int16_t  subframe_len;  ///< current subframe 
length
@@ -379,12 +379,6 @@ static av_cold int decode_init(WMAProDecodeCtx *s, 
AVCodecContext *avctx, int nu
 return AVERROR_PATCHWELCOME;
 }
 
-/** frame info */
-if (avctx->codec_id != AV_CODEC_ID_WMAPRO)
-s->skip_frame = 0;
-else
-s->skip_frame = 1; /* skip first frame */
-
 s->packet_loss = 1;
 s->len_prefix  = (s->decode_flags & 0x40);
 
@@ -1450,21 +1444,38 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame 
*frame, int *got_frame_ptr)
 ff_dlog(s->avctx, "drc_gain %i\n", s->drc_gain);
 }
 
-/** no idea what these are for, might be the number of samples
-that need to be skipped at the beginning or end of a stream */
+/** read encoder delay/padding (gapless) info */
 if (get_bits1(gb)) {
-int av_unused skip;
+int start_skip, end_skip;
+
 
-/** usually true for the first frame */
+/** usually true for the first frame and equal to 1 frame */
 if (get_bits1(gb)) {
-skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
-ff_dlog(s->avctx, "start skip: %i\n", skip);
+start_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
+start_skip = FFMIN(start_skip, s->samples_per_frame);
+
+/* must add for XMA to respect starting skip_samples */
+s->avctx->internal->skip_samples += start_skip;
 }
 
-/** sometimes true for the last frame */
+/** usually true for the last frame and less than 1 frame */
 if (get_bits1(gb)) {
-skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
-ff_dlog(s->avctx, "end skip: %i\n", skip);
+end_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
+end_skip = FFMIN(end_skip, s->samples_per_frame);
+
+//TODO fix end_skip (also needs changes in XMA multistream's 
handling)
+/* for XMA/WMAPRO end_skip may span last frame + final delay 
samples,
+ * so we'd need some counter to (possibly) skip some in this frame 
and
+ * rest after last frame (buf_size 0), so final samples would be:
+ * samples_per_frame + delay_samples - start_skip - end_skip
+ * (files with 1 packet are possible so both skips are considered).
+ *
+ * WMAPRO 5.1 in XWMA does't do this and audio is padded instead,
+ * and min packets is 2 (assumes only 1/2ch need it). */
+
+if (s->avctx->codec_id == AV_CODEC_ID_WMAPRO && s->nb_channels > 
2) {
+frame->nb_samples = s->samples_per_frame - end_skip;
+}
 }
 
 }
@@ -1500,13 +1511,9 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame 
*frame, int *got_frame_ptr)
s->samples_per_frame * sizeof(*s->channel[i].out) >> 1);
 }
 
-if (s->skip_frame) {
-s->skip_frame = 0;
-*got_frame_ptr = 0;
-av_frame_unref(frame);
-} else {
-*got_frame_ptr = 1;
-}
+/** frame may be partially discarded with gapless info in the bitstream */
+*got_frame_ptr = 1;
+
 
 if (s->len_prefix) {
 if (len != (get_bits_count(gb) - s->frame_offset) + 2) {
@@ -1609,7 +1616,35 @@ static int decode_packet(AVCodecContext *avctx, 
WMAProDecodeCtx *s,
 
 *got_frame_ptr = 0;
 
-if (s->packet_done || s->packet_loss) {
+if (!buf_size) {
+AVFrame *frame =

[FFmpeg-devel] [PATCH 2/2] ffmpeg: bump the intra stream discontinuity message to warning

2018-10-09 Thread Jan Ekström

As libavformat should at this point be handling general input
timestamp discontinuities for us - such as with MPEG-TS - the
amount of messages from this case should be small, and if it
does start spamming messages, that would be a sign that either
the input, or the discontinuity handling code itself is broken.

In other words, printing this on the warning level makes more
sense than staying silent on most verbosity levels.
---
 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index dfdee5100a..c20e998d86 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4471,7 +4471,7 @@ static int process_input(int file_index)
 delta >  1LL*dts_delta_threshold*AV_TIME_BASE ||
 pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)) {
 ifile->ts_offset -= delta;
-av_log(NULL, AV_LOG_DEBUG,
+av_log(NULL, AV_LOG_WARNING,
"timestamp discontinuity for stream #%d:%d "
"(id=%d, type=%s): %"PRId64", new offset= %"PRId64"\n",
ist->file_index, ist->st->index, ist->st->id,
-- 
2.17.2

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

[FFmpeg-devel] [PATCH 1/2] ffmpeg: improve the intra stream discontinuity message

2018-10-09 Thread Jan Ekström

Now it actually tells which stream from which input and of
which type had an absolute DTS discontinuity larger than
dts_delta_threshold.
---
 fftools/ffmpeg.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index aa495b5d9e..dfdee5100a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4472,7 +4472,10 @@ static int process_input(int file_index)
 pkt_dts + AV_TIME_BASE/10 < FFMAX(ist->pts, ist->dts)) {
 ifile->ts_offset -= delta;
 av_log(NULL, AV_LOG_DEBUG,
-   "timestamp discontinuity %"PRId64", new offset= 
%"PRId64"\n",
+   "timestamp discontinuity for stream #%d:%d "
+   "(id=%d, type=%s): %"PRId64", new offset= %"PRId64"\n",
+   ist->file_index, ist->st->index, ist->st->id,
+   av_get_media_type_string(ist->dec_ctx->codec_type),
delta, ifile->ts_offset);
 pkt.dts -= av_rescale_q(delta, AV_TIME_BASE_Q, 
ist->st->time_base);
 if (pkt.pts != AV_NOPTS_VALUE)
-- 
2.17.2

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

Re: [FFmpeg-devel] [PATCH 0/6] Improvements for EBU R128 plugin (third round)

2018-10-09 Thread Daniel Molkentin

On 09.10.2018 14:32, Daniel Molkentin wrote:
> Changes over second round:
>
>  - gauge option: Add 'm' and 's' as alias parameter for 
>momentary and short-term
>  - fix spelling error in documentation
>  - remove "mabsolute" documentation which was added to the range
>patch by accident
>  - fixed ranges for parameters
>  - bumped micro version for libavfilter
Is there anything left to do until this can go in?

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/h264: create AVFrame side data from H.264 timecodes

2018-10-09 Thread Michael Niedermayer

On Tue, Oct 09, 2018 at 02:32:02PM +0100, jos...@ob-encoder.com wrote:
> From: Devin Heitmueller 
> 
> Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
> info.
> 
> For framerates > 30 FPS, the field flag is used in conjunction with
> pairs of frames which contain the same frame timestamp in S12M.
> Ensure the field is properly set per the spec.
[...]

> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 9d57d6ce66..0061103894 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -123,6 +123,12 @@ enum AVFrameSideDataType {
>   */
>  AV_FRAME_DATA_GOP_TIMECODE,
>  
> +/**
> + * Timecode which conforms to SMPTE ST 12-1.  The data is a uint32_t 
> which
> + * can be found described in libavutil/timecode.h.

Thats not good enough for public API, the user wont even know what part of
timecode.h describes it


> + */
> +AV_FRAME_DATA_S12M_TIMECODE,

this cannot be added into the middle of the enum, that would break ABI

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-09 Thread Michael Niedermayer

On Tue, Oct 09, 2018 at 01:07:15PM +0100, jos...@ob-encoder.com wrote:
> From: Josh de Kock 
> 
> This test ensures that you are able to send N number of slice NALUs in slice 
> threaded mode to be decoded simultaneously
> ---
> 
>  Tested with `./configure --cc='cc -m32'` now, seems to be fine. Will send 
> sample to Michael on IRC.
> 
>  tests/api/Makefile  |   1 +
>  tests/api/api-h264-slice-test.c | 212 ++
>  tests/fate/api.mak  |   4 +
>  tests/ref/fate/api-h264-slice   | 309 
>  4 files changed, 526 insertions(+)
>  create mode 100644 tests/api/api-h264-slice-test.c
>  create mode 100644 tests/ref/fate/api-h264-slice

fails om mingw64 and mingw32

make -j12 fate-api-h264-slice 
TESTapi-h264-slice
--- tests/ref/fate/api-h264-slice   2018-10-09 21:53:49.339321988 +0200
+++ tests/data/fate/api-h264-slice  2018-10-09 23:25:00.511437251 +0200
@@ -1,309 +0,0 @@
-#format: frame checksums
-#version: 2
-#hash: MD5
-#tb 0: 1/30
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 352x288
...


wine  tests/api/api-h264-slice-test.exe 2 fate-suite//h264/crew_cif.nal 
api-h264-slice.h264
Couldn't read size: Success




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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Martin Vignali

>
> porting code and removing code sounds like 2 seperate things,
> that should not be in the same patch
>

Split patch in attach

Martin


0002-swscale-x86-rgb2rgb-remove-inline-mmx-mmxext-version.patch
Description: Binary data


0001-swscale-x86-rgb2rgb-port-shuffle-2103-mmxext-to-exte.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-09 Thread Tristan Matthews

On Tue, Oct 9, 2018 at 10:15 AM Derek Buitenhuis
 wrote:
>
> On 08/10/2018 16:36, Derek Buitenhuis wrote:
> > If we don't copy this value first, it is seen as 0 by 
> > h264_slice_header_init,
> > due to zero-allocation of the new context, triggering an old hack that
> > multiplied the denominator by 2 for files produced by old x264 versions, but
> > only if more than one thread was used.
> >
> > Fixes #7475.
> >
> > Signed-off-by: Derek Buitenhuis
> > ---
> >   libavcodec/h264_slice.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
>
> Pushed, thanks.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

BTW, looks like this bug isn't present in 4.0.2.

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/h264: create AVFrame side data from H.264 timecodes

2018-10-09 Thread Devin Heitmueller


> On Oct 9, 2018, at 4:02 PM, Carl Eugen Hoyos  wrote:
> 
> 2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
>> From: Devin Heitmueller 
>> 
>> Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
>> info.
>> 
>> For framerates > 30 FPS, the field flag is used in conjunction with
>> pairs of frames which contain the same frame timestamp in S12M.
>> Ensure the field is properly set per the spec.
> 
> I understand why you split the patches like this and I am slightly in
> favour of doing it this way but I believe most developers disagree
> and would prefer one patch "based on a patch by Devin" so give them
> a little time to comment.
> 

If Josh had written both patches I would agree with the sentiment that the 
patches should be compacted to a single patch.  However since they come from 
two different authors I would argue they should be separate.

That’s just my opinion though, and I may appear biased since I was the author 
of the first patch.

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/timecode: document SMPTE struct

2018-10-09 Thread Devin Heitmueller

> On Oct 9, 2018, at 4:07 PM, Carl Eugen Hoyos  wrote:
> 
> 2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
>> From: Devin Heitmueller 
>> 
>> There are a number of different binary representations in which
>> SMPTE timecodes can use.  Make clear that the specific representation
>> that ffmpeg refers to corresponds to the DV video spec, which is
>> SMPTE S314M:2005 for standard definition video and ST 370-2013 for
>> high definition video.
> 
> If this is correct - I have no idea - why is only one standard
> mentioned in the actual change?
> 
>> +/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */
> 

Yeah, I noticed this after I did the original commit and planned to fix it 
before I submitted the patch upstream.  Was reminded of it myself when I saw 
Josh submitted the patch on my behalf.

The information describing the structure is identical between the two specs, 
and thus referring to both doesn’t give you any additional information.  
However it’s possible that someone has access to one spec but not the other 
(since they are not freely available), and thus referring to both specs 
probably makes sense.

Josh, feel free to update the patch to refer to both specifications, or drop 
the patch from your series and I’ll include an updated patch in my next patch 
series.  Whatever works best for you.

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

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

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Michael Niedermayer

On Tue, Oct 09, 2018 at 09:51:16PM +0200, Martin Vignali wrote:
> > > >
> > > > Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> > > > be replaced with something more modern, but I'd at least drop the MMX
> > > > one.
> > > >
> > >
> > > This func already have SSSE3 version (AVX2 can be add easily, but doesn't
> > > find a command line where the speed is interesting in AVX2 (on my
> > > computer)).
> > > I can remove mmx, and only keep mmxext, or remove both (but seems like
> > not
> > > everyone is agree to remove mmx/mmxext, if SSxx version is available).
> > >
> >
> > If we don't want to drop both, then drop mmx and keep mmxext. Having
> > both serves no point in 2018, and is a nice artifact that shows how
> > old swscale really is.
> >
> > New patch in attach
> port only mmext to external asm
> Also fix, the number of xmm register (8 instead of 2)
> 
> Martin

>  rgb2rgb.c  |4 +++
>  rgb2rgb_template.c |   63 
> -
>  rgb_2_rgb.asm  |   63 
> +
>  3 files changed, 67 insertions(+), 63 deletions(-)
> 1a741cd21d922f65a0944336768410404257b1fc  
> 0001-swscale-x86-rgb2rgb-port-shuffle2103-to-external-asm.patch
> From 58ce1380d31cdc8fc80de6dec852bee919fb210d Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Tue, 9 Oct 2018 21:44:09 +0200
> Subject: [PATCH] swscale/x86/rgb2rgb : port shuffle2103 to external asm  for
>  mmext version
> 
> and remove the inline asm version (mmx and mmxext)

porting code and removing code sounds like 2 seperate things, 
that should not be in the same patch

also if anyone wants to remove more mmx functions, be carefull please
so this doesnt break the code on a codepath that is rarely tested.

thanks

[...]

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/timecode: document SMPTE struct

2018-10-09 Thread Carl Eugen Hoyos

2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
> From: Devin Heitmueller 
>
> There are a number of different binary representations in which
> SMPTE timecodes can use.  Make clear that the specific representation
> that ffmpeg refers to corresponds to the DV video spec, which is
> SMPTE S314M:2005 for standard definition video and ST 370-2013 for
> high definition video.

If this is correct - I have no idea - why is only one standard
mentioned in the actual change?

> +/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */

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

Re: [FFmpeg-devel] [PATCH 3/3] h264/pic_timing: support multiple timecodes

2018-10-09 Thread Carl Eugen Hoyos

2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
> From: Josh de Kock 

> -/* For SMPTE 12-M timecodes, frame count is a special case if > 30
> FPS.
> -   See SMPTE ST 12-1:2014 Sec 12.1 for more info. */
> -if (av_cmp_q(h->avctx->framerate, (AVRational) {30, 1}) == 1) {
> -frames = h->sei.picture_timing.tc_frames / 2;
> -if (h->sei.picture_timing.tc_frames % 2 == 1) {
> -if (av_cmp_q(h->avctx->framerate, (AVRational) {50, 1}) ==
> 0)
> -tc |= (1 << 7);
> -else
> -tc |= (1 << 23);
> +tc_sd = (uint32_t*)tcside->data;
> +tc_sd[0] = h->sei.picture_timing.timecode_cnt;
> +
> +for (int i = 0; i < tc_sd[0]; i++) {
> +uint32_t frames;
> +
> +/* For SMPTE 12-M timecodes, frame count is a special case if >
> 30 FPS.
> +   See SMPTE ST 12-1:2014 Sec 12.1 for more info. */
> +if (av_cmp_q(h->avctx->framerate, (AVRational) {30, 1}) == 1) {
> +frames = h->sei.picture_timing.timecode[i].frame / 2;
> +if (h->sei.picture_timing.timecode[i].frame % 2 == 1) {
> +if (av_cmp_q(h->avctx->framerate, (AVRational) {50, 1})
> == 0)
> +tc |= (1 << 7);
> +else
> +tc |= (1 << 23);
> +}
> +} else {
> +frames = h->sei.picture_timing.timecode[i].frame;
>  }
> -} else {
> -frames = h->sei.picture_timing.tc_frames;
> -}
>
> -tc |= h->sei.picture_timing.tc_dropframe << 30;
> -tc |= (frames / 10) << 28;
> -tc |= (frames % 10) << 24;
> -tc |= (h->sei.picture_timing.tc_seconds / 10) << 20;
> -tc |= (h->sei.picture_timing.tc_seconds % 10) << 16;
> -tc |= (h->sei.picture_timing.tc_minutes / 10) << 12;
> -tc |= (h->sei.picture_timing.tc_minutes % 10) << 8;
> -tc |= (h->sei.picture_timing.tc_hours / 10) << 4;
> -tc |= (h->sei.picture_timing.tc_hours % 10);
> +tc |= h->sei.picture_timing.timecode[i].dropframe << 30;
> +tc |= (frames / 10) << 28;
> +tc |= (frames % 10) << 24;
> +tc |= (h->sei.picture_timing.timecode[i].seconds / 10) << 20;
> +tc |= (h->sei.picture_timing.timecode[i].seconds % 10) << 16;
> +tc |= (h->sei.picture_timing.timecode[i].minutes / 10) << 12;
> +tc |= (h->sei.picture_timing.timecode[i].minutes % 10) << 8;
> +tc |= (h->sei.picture_timing.timecode[i].hours / 10) << 4;
> +tc |= (h->sei.picture_timing.timecode[i].hours % 10);
>
> -memcpy(tcside->data, , sizeof(uint32_t));
> -h->sei.picture_timing.fulltc_received = 0;
> +tc_sd[i + 1] = tc;
> +}
> +h->sei.picture_timing.timecode_cnt = 0;

If the first patch gets committed as-is, please split this one
in a functional and a cosmetic patch, above is unreviewable.

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/h264: create AVFrame side data from H.264 timecodes

2018-10-09 Thread Carl Eugen Hoyos

2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
> From: Devin Heitmueller 
>
> Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
> info.
>
> For framerates > 30 FPS, the field flag is used in conjunction with
> pairs of frames which contain the same frame timestamp in S12M.
> Ensure the field is properly set per the spec.

I understand why you split the patches like this and I am slightly in
favour of doing it this way but I believe most developers disagree
and would prefer one patch "based on a patch by Devin" so give them
a little time to comment.

Please see also my comment for 3.

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

Re: [FFmpeg-devel] [PATCH 1/3] avfilter/f_cue: always check the return value of ff_inlink_consume_frame

2018-10-09 Thread Marton Balint




On Sun, 7 Oct 2018, Nicolas George wrote:


Marton Balint (2018-10-07):

Fixes Coverity CID 1439936.

Signed-off-by: Marton Balint 
---
 libavfilter/f_cue.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)


LGTM, sorry for having missed it.


No worries. Pushed the series.

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

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Martin Vignali

> > >
> > > Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> > > be replaced with something more modern, but I'd at least drop the MMX
> > > one.
> > >
> >
> > This func already have SSSE3 version (AVX2 can be add easily, but doesn't
> > find a command line where the speed is interesting in AVX2 (on my
> > computer)).
> > I can remove mmx, and only keep mmxext, or remove both (but seems like
> not
> > everyone is agree to remove mmx/mmxext, if SSxx version is available).
> >
>
> If we don't want to drop both, then drop mmx and keep mmxext. Having
> both serves no point in 2018, and is a nice artifact that shows how
> old swscale really is.
>
> New patch in attach
port only mmext to external asm
Also fix, the number of xmm register (8 instead of 2)

Martin


0001-swscale-x86-rgb2rgb-port-shuffle2103-to-external-asm.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] UDP multicast and interface selection

2018-10-09 Thread Marton Balint




On Tue, 9 Oct 2018, Louis-Paul CORDIER wrote:


Hi all,

Trying to implement RTP communication in my application, I need to 
select on which interface I want to stream and/or retrieve the multicast 
feed. It is actually not possible to do to this today.


Apparently there are 2 main disccussions on this:

https://trac.ffmpeg.org/ticket/368

and

https://ffmpeg.org/pipermail/ffmpeg-devel/2012-January/118504.html

Any hope to see these 2 patches merged into the mainstream?


Unless you use IPv6 interface selection using the ?localaddr option should 
work just fine, relevant discussion seems outdated.


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

[FFmpeg-devel] UDP multicast and interface selection

2018-10-09 Thread Louis-Paul CORDIER


Hi all,

Trying to implement RTP communication in my application, I need to 
select on which interface I want to stream and/or retrieve the multicast 
feed. It is actually not possible to do to this today.


Apparently there are 2 main disccussions on this:

https://trac.ffmpeg.org/ticket/368

and

https://ffmpeg.org/pipermail/ffmpeg-devel/2012-January/118504.html

Any hope to see these 2 patches merged into the mainstream?

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

Re: [FFmpeg-devel] [PATCH] h264_slice: Copy the value of x264_build before calling h264_slice_header_init during thread init

2018-10-09 Thread Derek Buitenhuis

On 08/10/2018 16:36, Derek Buitenhuis wrote:
> If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
> due to zero-allocation of the new context, triggering an old hack that
> multiplied the denominator by 2 for files produced by old x264 versions, but
> only if more than one thread was used.
> 
> Fixes #7475.
> 
> Signed-off-by: Derek Buitenhuis
> ---
>   libavcodec/h264_slice.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Pushed, thanks.

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

[FFmpeg-devel] [PATCH 1/3] lavc/h264: create AVFrame side data from H.264 timecodes

2018-10-09 Thread joshdk

From: Devin Heitmueller 

Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
info.

For framerates > 30 FPS, the field flag is used in conjunction with
pairs of frames which contain the same frame timestamp in S12M.
Ensure the field is properly set per the spec.
---
 fftools/ffprobe.c   |  4 
 libavcodec/h264_sei.c   | 37 -
 libavcodec/h264_sei.h   |  9 +
 libavcodec/h264_slice.c | 38 ++
 libavutil/frame.c   |  1 +
 libavutil/frame.h   |  6 ++
 6 files changed, 78 insertions(+), 17 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 544786ec72..6cc3a4efc4 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2199,6 +2199,10 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 char tcbuf[AV_TIMECODE_STR_SIZE];
 av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
 print_str("timecode", tcbuf);
+} else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size >= 
4) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_smpte_tc_string(tcbuf, *(uint32_t 
*)(sd->data), 0);
+print_str("timecode", tcbuf);
 } else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) {
 AVMasteringDisplayMetadata *metadata = 
(AVMasteringDisplayMetadata *)sd->data;
 
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 43593d34d2..275224eabe 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -84,32 +84,35 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 return AVERROR_INVALIDDATA;
 
 num_clock_ts = sei_num_clock_ts_table[h->pic_struct];
-
 for (i = 0; i < num_clock_ts; i++) {
-if (get_bits(gb, 1)) {/* clock_timestamp_flag */
+if (get_bits(gb, 1)) {  /* 
clock_timestamp_flag */
 unsigned int full_timestamp_flag;
-
+unsigned int counting_type, cnt_dropped_flag;
 h->ct_type |= 1 << get_bits(gb, 2);
-skip_bits(gb, 1); /* nuit_field_based_flag */
-skip_bits(gb, 5); /* counting_type */
+skip_bits(gb, 1);   /* 
nuit_field_based_flag */
+counting_type = get_bits(gb, 5);/* counting_type */
 full_timestamp_flag = get_bits(gb, 1);
-skip_bits(gb, 1); /* discontinuity_flag */
-skip_bits(gb, 1); /* cnt_dropped_flag */
-skip_bits(gb, 8); /* n_frames */
+skip_bits(gb, 1);   /* discontinuity_flag 
*/
+cnt_dropped_flag = get_bits(gb, 1);  /* cnt_dropped_flag */
+if (cnt_dropped_flag && counting_type > 1 && counting_type < 7)
+h->tc_dropframe = 1;
+h->tc_frames = get_bits(gb, 8); /* n_frames */
 if (full_timestamp_flag) {
-skip_bits(gb, 6); /* seconds_value 0..59 */
-skip_bits(gb, 6); /* minutes_value 0..59 */
-skip_bits(gb, 5); /* hours_value 0..23 */
+h->fulltc_received = 1;
+h->tc_seconds = get_bits(gb, 6); /* seconds_value 0..59 */
+h->tc_minutes = get_bits(gb, 6); /* minutes_value 0..59 */
+h->tc_hours = get_bits(gb, 5);   /* hours_value 0..23 */
 } else {
-if (get_bits(gb, 1)) {/* seconds_flag */
-skip_bits(gb, 6); /* seconds_value range 0..59 
*/
-if (get_bits(gb, 1)) {/* minutes_flag */
-skip_bits(gb, 6); /* minutes_value 0..59 */
-if (get_bits(gb, 1))  /* hours_flag */
-skip_bits(gb, 5); /* hours_value 0..23 */
+if (get_bits(gb, 1)) { /* seconds_flag */
+h->tc_seconds = get_bits(gb, 6);
+if (get_bits(gb, 1)) { /* minutes_flag */
+h->tc_minutes = get_bits(gb, 6);
+if (get_bits(gb, 1))   /* hours_flag */
+h->tc_minutes = get_bits(gb, 5);
 }
 }
 }
+
 if (sps->time_offset_length > 0)
 skip_bits(gb,
   sps->time_offset_length); /* time_offset */
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 5b7c8ef9d8..3b8806be0a 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -87,6 +87,15 @@

[FFmpeg-devel] [PATCH 3/3] h264/pic_timing: support multiple timecodes

2018-10-09 Thread joshdk

From: Josh de Kock 

---
 libavcodec/h264_sei.c | 21 --
 libavcodec/h264_sei.h | 28 +--
 libavcodec/h264_slice.c   | 59 ++-
 libavfilter/vf_showinfo.c | 10 +++
 4 files changed, 75 insertions(+), 43 deletions(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 275224eabe..d4eb9c0dab 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -84,8 +84,10 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 return AVERROR_INVALIDDATA;
 
 num_clock_ts = sei_num_clock_ts_table[h->pic_struct];
+h->timecode_cnt = 0;
 for (i = 0; i < num_clock_ts; i++) {
 if (get_bits(gb, 1)) {  /* 
clock_timestamp_flag */
+H264SEITimeCode *tc = >timecode[h->timecode_cnt++];
 unsigned int full_timestamp_flag;
 unsigned int counting_type, cnt_dropped_flag;
 h->ct_type |= 1 << get_bits(gb, 2);
@@ -95,20 +97,21 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 skip_bits(gb, 1);   /* discontinuity_flag 
*/
 cnt_dropped_flag = get_bits(gb, 1);  /* cnt_dropped_flag */
 if (cnt_dropped_flag && counting_type > 1 && counting_type < 7)
-h->tc_dropframe = 1;
-h->tc_frames = get_bits(gb, 8); /* n_frames */
+tc->dropframe = 1;
+tc->frame = get_bits(gb, 8); /* n_frames */
 if (full_timestamp_flag) {
-h->fulltc_received = 1;
-h->tc_seconds = get_bits(gb, 6); /* seconds_value 0..59 */
-h->tc_minutes = get_bits(gb, 6); /* minutes_value 0..59 */
-h->tc_hours = get_bits(gb, 5);   /* hours_value 0..23 */
+tc->full = 1;
+tc->seconds = get_bits(gb, 6); /* seconds_value 0..59 */
+tc->minutes = get_bits(gb, 6); /* minutes_value 0..59 */
+tc->hours = get_bits(gb, 5);   /* hours_value 0..23 */
 } else {
+tc->seconds = tc->minutes = tc->hours = tc->full = 0;
 if (get_bits(gb, 1)) { /* seconds_flag */
-h->tc_seconds = get_bits(gb, 6);
+tc->seconds = get_bits(gb, 6);
 if (get_bits(gb, 1)) { /* minutes_flag */
-h->tc_minutes = get_bits(gb, 6);
+tc->minutes = get_bits(gb, 6);
 if (get_bits(gb, 1))   /* hours_flag */
-h->tc_minutes = get_bits(gb, 5);
+tc->hours = get_bits(gb, 5);
 }
 }
 }
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 3b8806be0a..a75c3aa175 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -67,6 +67,17 @@ typedef enum {
 H264_SEI_FPA_TYPE_2D  = 6,
 } H264_SEI_FpaType;
 
+typedef struct H264SEITimeCode {
+/* When not continuously receiving full timecodes, we have to reference
+   the previous timecode received */
+int full;
+int frame;
+int seconds;
+int minutes;
+int hours;
+int dropframe;
+} H264SEITimeCode;
+
 typedef struct H264SEIPictureTiming {
 int present;
 H264_SEI_PicStructType pic_struct;
@@ -88,14 +99,15 @@ typedef struct H264SEIPictureTiming {
  */
 int cpb_removal_delay;
 
-/* When not continuously receiving full timecodes, we have to reference
-   the previous timecode received */
-int fulltc_received;
-int tc_frames;
-int tc_seconds;
-int tc_minutes;
-int tc_hours;
-int tc_dropframe;
+/**
+ * Maximum three timecodes in a pic_timing SEI.
+ */
+H264SEITimeCode timecode[3];
+
+/**
+ * Number of timecode in use
+ */
+int timecode_cnt;
 } H264SEIPictureTiming;
 
 typedef struct H264SEIAFD {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 973f5761ef..aaf0006a32 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,42 +1287,49 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
-if (h->sei.picture_timing.fulltc_received) {
+if (h->sei.picture_timing.timecode_cnt > 0) {
 uint32_t tc = 0;
-uint32_t frames;
+uint32_t *tc_sd;
 
 AVFrameSideData *tcside = av_frame_new_side_data(cur->f,
  
AV_FRAME_DATA_S12M_TIMECODE,
- sizeof(uint32_t));
+ sizeof(uint32_t)*4);
 if (!tcside)

[FFmpeg-devel] [PATCH 0/3] Timecode support

2018-10-09 Thread joshdk

This set requires Derek's patch to h264 which fixes #7083.
'h264_slice: Copy the value of x264_build before calling h264_slice_header_init 
during thread init'

Josh


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

[FFmpeg-devel] [PATCH 2/3] lavf/timecode: document SMPTE struct

2018-10-09 Thread joshdk

From: Devin Heitmueller 

There are a number of different binary representations in which
SMPTE timecodes can use.  Make clear that the specific representation
that ffmpeg refers to corresponds to the DV video spec, which is
SMPTE S314M:2005 for standard definition video and ST 370-2013 for
high definition video.
---
 libavutil/timecode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index 60077ba0c0..5b2bf85caa 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -117,6 +117,7 @@ static unsigned bcd2uint(uint8_t bcd)
 
 char *av_timecode_make_smpte_tc_string(char *buf, uint32_t tcsmpte, int 
prevent_df)
 {
+/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */
 unsigned hh   = bcd2uint(tcsmpte & 0x3f);// 6-bit hours
 unsigned mm   = bcd2uint(tcsmpte>>8  & 0x7f);// 7-bit minutes
 unsigned ss   = bcd2uint(tcsmpte>>16 & 0x7f);// 7-bit seconds
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 4/6] libavfilter/ebur128: introduce target range

2018-10-09 Thread Daniel Molkentin

This eases meeting the target level during live mixing.

Signed-off-by: Daniel Molkentin 
Signed-off-by: Conrad Zelck 
---
 doc/filters.texi|  3 +++
 libavfilter/f_ebur128.c | 33 +++--
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 7f2baed9b5..3783a8a421 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19284,6 +19284,9 @@ short-term loudness (3 seconds of analysis), and the 
gauge on the right is for
 the momentary loudness (400 milliseconds), but can optionally be configured
 to instead display short-term loudness (see @var{gauge}).
 
+The green area marks a  +/- 1LU target range around the target loudness
+(-23LUFS by default, unless modified through @var{target}).
+
 More information about the Loudness Recommendation EBU R128 on
 @url{http://tech.ebu.ch/loudness}.
 
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index c74dac94da..688c7bf135 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -114,6 +114,8 @@ typedef struct EBUR128Context {
 int meter;  ///< select a EBU mode between +9 and +18
 int scale_range;///< the range of LU values according to 
the meter
 int y_zero_lu;  ///< the y value (pixel position) for 0 LU
+int y_opt_max;  ///< the y value (pixel position) for 1 LU
+int y_opt_min;  ///< the y value (pixel position) for -1 LU
 int *y_line_ref;///< y reference values for drawing the LU 
lines in the graph and the gauge
 
 /* audio */
@@ -188,22 +190,31 @@ static const AVOption ebur128_options[] = {
 AVFILTER_DEFINE_CLASS(ebur128);
 
 static const uint8_t graph_colors[] = {
-0xdd, 0x66, 0x66,   // value above 0LU non reached
-0x66, 0x66, 0xdd,   // value below 0LU non reached
-0x96, 0x33, 0x33,   // value above 0LU reached
-0x33, 0x33, 0x96,   // value below 0LU reached
-0xdd, 0x96, 0x96,   // value above 0LU line non reached
-0x96, 0x96, 0xdd,   // value below 0LU line non reached
-0xdd, 0x33, 0x33,   // value above 0LU line reached
-0x33, 0x33, 0xdd,   // value below 0LU line reached
+0xdd, 0x66, 0x66,   // value above 1LU non reached below -1LU (impossible)
+0x66, 0x66, 0xdd,   // value below 1LU non reached below -1LU
+0x96, 0x33, 0x33,   // value above 1LU reached below -1LU (impossible)
+0x33, 0x33, 0x96,   // value below 1LU reached below -1LU
+0xdd, 0x96, 0x96,   // value above 1LU line non reached below -1LU 
(impossible)
+0x96, 0x96, 0xdd,   // value below 1LU line non reached below -1LU
+0xdd, 0x33, 0x33,   // value above 1LU line reached below -1LU (impossible)
+0x33, 0x33, 0xdd,   // value below 1LU line reached below -1LU
+0xdd, 0x66, 0x66,   // value above 1LU non reached above -1LU
+0x66, 0xdd, 0x66,   // value below 1LU non reached above -1LU
+0x96, 0x33, 0x33,   // value above 1LU reached above -1LU
+0x33, 0x96, 0x33,   // value below 1LU reached above -1LU
+0xdd, 0x96, 0x96,   // value above 1LU line non reached above -1LU
+0x96, 0xdd, 0x96,   // value below 1LU line non reached above -1LU
+0xdd, 0x33, 0x33,   // value above 1LU line reached above -1LU
+0x33, 0xdd, 0x33,   // value below 1LU line reached above -1LU
 };
 
 static const uint8_t *get_graph_color(const EBUR128Context *ebur128, int v, 
int y)
 {
-const int below0  = y > ebur128->y_zero_lu;
+const int above_opt_max = y > ebur128->y_opt_max;
+const int below_opt_min = y < ebur128->y_opt_min;
 const int reached = y >= v;
 const int line= ebur128->y_line_ref[y] || y == ebur128->y_zero_lu;
-const int colorid = 4*line + 2*reached + below0;
+const int colorid = 8*below_opt_min+ 4*line + 2*reached + above_opt_max;
 return graph_colors + 3*colorid;
 }
 
@@ -337,6 +348,8 @@ static int config_video_output(AVFilterLink *outlink)
 
 /* draw graph */
 ebur128->y_zero_lu = lu_to_y(ebur128, 0);
+ebur128->y_opt_max = lu_to_y(ebur128, 1);
+ebur128->y_opt_min = lu_to_y(ebur128, -1);
 p = outpicref->data[0] + ebur128->graph.y * outpicref->linesize[0]
+ ebur128->graph.x * 3;
 for (y = 0; y < ebur128->graph.h; y++) {
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 3/6] libavfilter/ebur128: add gauge option

2018-10-09 Thread Daniel Molkentin

Allow to show short-term instead of momentary in gauge. Useful for monitoring
whilst live mixing.

Signed-off-by: Daniel Molkentin 
Signed-off-by: Conrad Zelck 
---
 doc/filters.texi|  9 -
 libavfilter/f_ebur128.c | 23 +--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 86ea25bda8..7f2baed9b5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19281,7 +19281,8 @@ time graph to observe the loudness evolution. The 
graphic contains the logged
 message mentioned above, so it is not printed anymore when this option is set,
 unless the verbose logging is set. The main graphing area contains the
 short-term loudness (3 seconds of analysis), and the gauge on the right is for
-the momentary loudness (400 milliseconds).
+the momentary loudness (400 milliseconds), but can optionally be configured
+to instead display short-term loudness (see @var{gauge}).
 
 More information about the Loudness Recommendation EBU R128 on
 @url{http://tech.ebu.ch/loudness}.
@@ -19364,6 +19365,12 @@ Set a specific target level (in LUFS) used as relative 
zero in the visualization
 This parameter is optional and has a default value of -23LUFS as specified
 by EBU R128. However, material published online may prefer a level of -16LUFS
 (e.g. for use with podcasts or video platforms).
+
+@item gauge
+Set the value displayed by the gauge. Valid values are @code{momentary} and s
+@code{shortterm}. By default the momentary value will be used, but in certain
+scenarios it may be more useful to observe the short term value instead (e.g.
+live mixing).
 @end table
 
 @subsection Examples
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 89bfcb0b3e..c74dac94da 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -143,6 +143,7 @@ typedef struct EBUR128Context {
 int dual_mono;  ///< whether or not to treat single 
channel input files as dual-mono
 double pan_law; ///< pan law value used to calculate 
dual-mono measurements
 int target; ///< target level in LUFS used to set 
relative zero LU in visualization
+int gauge_type; ///< whether gauge shows momentary or short
 } EBUR128Context;
 
 enum {
@@ -151,6 +152,12 @@ enum {
 PEAK_MODE_TRUE_PEAKS= 1<<2,
 };
 
+enum {
+GAUGE_TYPE_MOMENTARY = 0,
+GAUGE_TYPE_SHORTTERM = 1,
+};
+
+
 #define OFFSET(x) offsetof(EBUR128Context, x)
 #define A AV_OPT_FLAG_AUDIO_PARAM
 #define V AV_OPT_FLAG_VIDEO_PARAM
@@ -170,6 +177,11 @@ static const AVOption ebur128_options[] = {
 { "dualmono", "treat mono input files as dual-mono", OFFSET(dual_mono), 
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, A|F },
 { "panlaw", "set a specific pan law for dual-mono files", OFFSET(pan_law), 
AV_OPT_TYPE_DOUBLE, {.dbl = -3.01029995663978}, -10.0, 0.0, A|F },
 { "target", "set a specific target level in LUFS (-23 to 0)", 
OFFSET(target), AV_OPT_TYPE_INT, {.i64 = -23}, -23, 0, V|F },
+{ "gauge", "set gauge display type", OFFSET(gauge_type), AV_OPT_TYPE_INT, 
{.i64 = 0 }, GAUGE_TYPE_MOMENTARY, GAUGE_TYPE_SHORTTERM, V|F, "gaugetype" },
+{ "momentary",   "display momentary value",   0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_MOMENTARY}, INT_MIN, INT_MAX, V|F, "gaugetype" },
+{ "m",   "display momentary value",   0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_MOMENTARY}, INT_MIN, INT_MAX, V|F, "gaugetype" },
+{ "shortterm",   "display short-term value",  0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_SHORTTERM}, INT_MIN, INT_MAX, V|F, "gaugetype" },
+{ "s",   "display short-term value",  0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_SHORTTERM}, INT_MIN, INT_MAX, V|F, "gaugetype" },
 { NULL },
 };
 
@@ -741,9 +753,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 if (ebur128->do_video) {
 int x, y, ret;
 uint8_t *p;
+double gauge_value;
+
+if (ebur128->gauge_type == GAUGE_TYPE_MOMENTARY) {
+gauge_value = loudness_400 - ebur128->target;
+} else {
+gauge_value = loudness_3000 - ebur128->target;
+}
 
 const int y_loudness_lu_graph = lu_to_y(ebur128, loudness_3000 
- ebur128->target);
-const int y_loudness_lu_gauge = lu_to_y(ebur128, loudness_400  
- ebur128->target);
+const int y_loudness_lu_gauge = lu_to_y(ebur128, gauge_value);
 
 /* draw the graph using the short-term loudness */
 p = pic->data[0] + ebur128->graph.y*pic->linesize[0] + 
ebur128->graph.x*3;
@@ -755,7 +774,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 p += pic->linesize[0];
 }
 
-/* draw the gauge using the momentary loudness */
+/* draw the gauge using either

[FFmpeg-devel] [PATCH 0/6] Improvements for EBU R128 plugin (third round)

2018-10-09 Thread Daniel Molkentin

Changes over second round:

 - gauge option: Add 'm' and 's' as alias parameter for 
   momentary and short-term
 - fix spelling error in documentation
 - remove "mabsolute" documentation which was added to the range
   patch by accident
 - fixed ranges for parameters
 - bumped micro version for libavfilter

Daniel Molkentin (6):
  libavfilter/ebur128: add target level option for EBUR128 visualization
filter
  libavfilter/ebur128: add target value to statistics line
  libavfilter/ebur128: add gauge option
  libavfilter/ebur128: introduce target range
  libavfilter/ebur128: add scale parameter
  libavfilter: Bump micro version to 101

 doc/filters.texi|  23 -
 libavfilter/f_ebur128.c | 102 +++-
 libavfilter/version.h   |   2 +-
 3 files changed, 103 insertions(+), 24 deletions(-)

-- 
2.17.1

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

[FFmpeg-devel] [PATCH 5/6] libavfilter/ebur128: add scale parameter

2018-10-09 Thread Daniel Molkentin

This allows switching between absolute (LUFS) and relativ (LU) display
in the status line.

Signed-off-by: Daniel Molkentin 
Signed-off-by: Conrad Zelck 
---
 doc/filters.texi|  5 +
 libavfilter/f_ebur128.c | 42 -
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 3783a8a421..c0e785 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19374,6 +19374,11 @@ Set the value displayed by the gauge. Valid values are 
@code{momentary} and s
 @code{shortterm}. By default the momentary value will be used, but in certain
 scenarios it may be more useful to observe the short term value instead (e.g.
 live mixing).
+
+@item scale
+Sets the display scale for the loudness. Valid parameters are @code{absolute}
+(in LUFS) or @code{relative} (LU) relative to the target. This only affects the
+video output, not the summary or continuous log output.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 688c7bf135..d481e479b0 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -146,6 +146,7 @@ typedef struct EBUR128Context {
 double pan_law; ///< pan law value used to calculate 
dual-mono measurements
 int target; ///< target level in LUFS used to set 
relative zero LU in visualization
 int gauge_type; ///< whether gauge shows momentary or short
+int scale;  ///< display scale type of statistics
 } EBUR128Context;
 
 enum {
@@ -159,6 +160,10 @@ enum {
 GAUGE_TYPE_SHORTTERM = 1,
 };
 
+enum {
+SCALE_TYPE_ABSOLUTE = 0,
+SCALE_TYPE_RELATIVE = 1,
+};
 
 #define OFFSET(x) offsetof(EBUR128Context, x)
 #define A AV_OPT_FLAG_AUDIO_PARAM
@@ -184,6 +189,11 @@ static const AVOption ebur128_options[] = {
 { "m",   "display momentary value",   0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_MOMENTARY}, INT_MIN, INT_MAX, V|F, "gaugetype" },
 { "shortterm",   "display short-term value",  0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_SHORTTERM}, INT_MIN, INT_MAX, V|F, "gaugetype" },
 { "s",   "display short-term value",  0, AV_OPT_TYPE_CONST, 
{.i64 = GAUGE_TYPE_SHORTTERM}, INT_MIN, INT_MAX, V|F, "gaugetype" },
+{ "scale", "sets display method for the stats", OFFSET(scale), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, V|F, "scaletype" },
+{ "absolute",   "display absolute values (LUFS)",  0, 
AV_OPT_TYPE_CONST, {.i64 = SCALE_TYPE_ABSOLUTE}, INT_MIN, INT_MAX, V|F, 
"scaletype" },
+{ "LUFS",   "display absolute values (LUFS)",  0, 
AV_OPT_TYPE_CONST, {.i64 = SCALE_TYPE_ABSOLUTE}, INT_MIN, INT_MAX, V|F, 
"scaletype" },
+{ "relative",   "display values relative to target (LU)",  0, 
AV_OPT_TYPE_CONST, {.i64 = SCALE_TYPE_RELATIVE}, INT_MIN, INT_MAX, V|F, 
"scaletype" },
+{ "LU", "display values relative to target (LU)",  0, 
AV_OPT_TYPE_CONST, {.i64 = SCALE_TYPE_RELATIVE}, INT_MIN, INT_MAX, V|F, 
"scaletype" },
 { NULL },
 };
 
@@ -760,7 +770,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 loudness_3000 -= ebur128->pan_law;
 }
 
-#define LOG_FMT "TARGET:%d M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f 
LU"
+#define LOG_FMT "TARGET:%d LUFSM:%6.1f S:%6.1f I:%6.1f %s   
LRA:%6.1f LU"
 
 /* push one video frame */
 if (ebur128->do_video) {
@@ -798,10 +808,17 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 }
 
 /* draw textual info */
-drawtext(pic, PAD, PAD - PAD/2, FONT16, font_colors,
- LOG_FMT " ", // padding to erase trailing 
characters
- ebur128->target, loudness_400, loudness_3000,
- ebur128->integrated_loudness, 
ebur128->loudness_range);
+if (ebur128->scale == SCALE_TYPE_ABSOLUTE) {
+drawtext(pic, PAD, PAD - PAD/2, FONT16, font_colors,
+ LOG_FMT " ", // padding to erase trailing 
characters
+ ebur128->target, loudness_400, loudness_3000,
+ ebur128->integrated_loudness, "LUFS", 
ebur128->loudness_range);
+} else {
+drawtext(pic, PAD, PAD - PAD/2, FONT16, font_colors,
+ LOG_FMT " ", // padding to erase trailing 
characters
+ ebur128->target, loudness_400-ebur128->target, 
loudness_3000-ebur128->target,
+ ebur128->integrated_loudness-ebur128->target, 
"LU", ebur128->loudness_range);
+}
 
 /* set pts and push frame */
 pic->pts = pts;
@@ -841,10 +858,17 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)

[FFmpeg-devel] [PATCH 6/6] libavfilter: bump micro version to 101

2018-10-09 Thread Daniel Molkentin

---
 libavfilter/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/version.h b/libavfilter/version.h
index cde68fbdd5..30e961b999 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   7
 #define LIBAVFILTER_VERSION_MINOR  33
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 2/6] libavfilter/ebur128: add target value to statistics line

2018-10-09 Thread Daniel Molkentin

Signed-off-by: Daniel Molkentin 
Signed-off-by: Conrad Zelck 
---
 libavfilter/f_ebur128.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index dfccbff5ec..89bfcb0b3e 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -735,7 +735,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 loudness_3000 -= ebur128->pan_law;
 }
 
-#define LOG_FMT "M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f LU"
+#define LOG_FMT "TARGET:%d M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f 
LU"
 
 /* push one video frame */
 if (ebur128->do_video) {
@@ -768,7 +768,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 /* draw textual info */
 drawtext(pic, PAD, PAD - PAD/2, FONT16, font_colors,
  LOG_FMT " ", // padding to erase trailing 
characters
- loudness_400, loudness_3000,
+ ebur128->target, loudness_400, loudness_3000,
  ebur128->integrated_loudness, 
ebur128->loudness_range);
 
 /* set pts and push frame */
@@ -811,7 +811,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 
 av_log(ctx, ebur128->loglevel, "t: %-10s " LOG_FMT,
av_ts2timestr(pts, >time_base),
-   loudness_400, loudness_3000,
+   ebur128->target, loudness_400, loudness_3000,
ebur128->integrated_loudness, ebur128->loudness_range);
 
 #define PRINT_PEAKS(str, sp, ptype) do {\
-- 
2.17.1

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

[FFmpeg-devel] [PATCH 1/6] libavfilter/ebur128: add target level option for EBUR128 visualization filter

2018-10-09 Thread Daniel Molkentin

Signed-off-by: Daniel Molkentin 
Signed-off-by: Conrad Zelck 
---
 doc/filters.texi| 6 ++
 libavfilter/f_ebur128.c | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index b523877cf3..86ea25bda8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19358,6 +19358,12 @@ Multi-channel input files are not affected by this 
option.
 @item panlaw
 Set a specific pan law to be used for the measurement of dual mono files.
 This parameter is optional, and has a default value of -3.01dB.
+
+@item target
+Set a specific target level (in LUFS) used as relative zero in the 
visualization.
+This parameter is optional and has a default value of -23LUFS as specified
+by EBU R128. However, material published online may prefer a level of -16LUFS
+(e.g. for use with podcasts or video platforms).
 @end table
 
 @subsection Examples
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index a48d3629ce..dfccbff5ec 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -142,6 +142,7 @@ typedef struct EBUR128Context {
 int metadata;   ///< whether or not to inject loudness 
results in frames
 int dual_mono;  ///< whether or not to treat single 
channel input files as dual-mono
 double pan_law; ///< pan law value used to calculate 
dual-mono measurements
+int target; ///< target level in LUFS used to set 
relative zero LU in visualization
 } EBUR128Context;
 
 enum {
@@ -168,6 +169,7 @@ static const AVOption ebur128_options[] = {
 { "true",   "enable true-peak mode",   0, AV_OPT_TYPE_CONST, {.i64 = 
PEAK_MODE_TRUE_PEAKS},INT_MIN, INT_MAX, A|F, "mode" },
 { "dualmono", "treat mono input files as dual-mono", OFFSET(dual_mono), 
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, A|F },
 { "panlaw", "set a specific pan law for dual-mono files", OFFSET(pan_law), 
AV_OPT_TYPE_DOUBLE, {.dbl = -3.01029995663978}, -10.0, 0.0, A|F },
+{ "target", "set a specific target level in LUFS (-23 to 0)", 
OFFSET(target), AV_OPT_TYPE_INT, {.i64 = -23}, -23, 0, V|F },
 { NULL },
 };
 
@@ -740,8 +742,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 int x, y, ret;
 uint8_t *p;
 
-const int y_loudness_lu_graph = lu_to_y(ebur128, loudness_3000 
+ 23);
-const int y_loudness_lu_gauge = lu_to_y(ebur128, loudness_400  
+ 23);
+const int y_loudness_lu_graph = lu_to_y(ebur128, loudness_3000 
- ebur128->target);
+const int y_loudness_lu_gauge = lu_to_y(ebur128, loudness_400  
- ebur128->target);
 
 /* draw the graph using the short-term loudness */
 p = pic->data[0] + ebur128->graph.y*pic->linesize[0] + 
ebur128->graph.x*3;
-- 
2.17.1

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

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Hendrik Leppkes

On Tue, Oct 9, 2018 at 1:31 PM Martin Vignali  wrote:
>
> >
> > Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> > be replaced with something more modern, but I'd at least drop the MMX
> > one.
> >
>
> This func already have SSSE3 version (AVX2 can be add easily, but doesn't
> find a command line where the speed is interesting in AVX2 (on my
> computer)).
> I can remove mmx, and only keep mmxext, or remove both (but seems like not
> everyone is agree to remove mmx/mmxext, if SSxx version is available).
>

If we don't want to drop both, then drop mmx and keep mmxext. Having
both serves no point in 2018, and is a nice artifact that shows how
old swscale really is.

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

Re: [FFmpeg-devel] [PATCH] libavdevice: allow cropping avfoundation screen capture

2018-10-09 Thread Thilo Borgmann

Hi,

Am 17.09.18 um 05:53 schrieb alan.birt...@sony.com:
> 2018-09-13 17:52 GMT+02:00,
> alan.birt...@sony.com
> mailto:alan.birt...@sony.com>>:
> 
> 
> 
>> I've developed  a patch to add an option to allow cropping of the
> 
>> avfoundation screen capture.
> 
>> Note that if the captured width is not a multiple of 16 then
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ffmpeg.org_ticket_5654=DwIGaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=DZ-pOCz_nOIJfdxhe1zNBFwbfB1WJzA5E9fM05n7yCs=KjmPPiSi2W239ebqa6B1xWjvn3F0kSW7fSlmVx4n70s=1a0Z8KLo3pYG0TjLl0zZzlF3E68mO58ssmKjXnW9yYg=
>> will be triggered.

This had been fixed in a259501e5a6ed07d76ce5d615123148b9b68d9f8.


> From 96b9cd33022bb6f3147174085c9ff2417cd006bc Mon Sep 17 00:00:00 2001
> From: Alan Birtles 
> Date: Thu, 13 Sep 2018 15:56:55 +0100
> Subject: [PATCH] allow specifying "cropRect" for avfoundation screen capture
> 
> ---
>  libavdevice/avfoundation.m | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index fc6428a..c285984 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -97,6 +97,10 @@
>  
>  int capture_cursor;
>  int capture_mouse_clicks;

> +int capture_crop_x;
> +int capture_crop_y;
> +int capture_crop_width;
> +int capture_crop_height;

Please remove the "capture_" prefix - if you see it fit, please use something
like "screen_".


>  int list_devices;
>  int video_device_index;
> @@ -750,6 +754,13 @@ static int avf_read_header(AVFormatContext *s)
>  capture_screen_input.capturesMouseClicks = NO;
>  }
>  
> +if (ctx->capture_crop_x != 0 ||
> +ctx->capture_crop_y != 0 ||
> +ctx->capture_crop_width != 0 ||
> +ctx->capture_crop_height != 0) {
> +capture_screen_input.cropRect = 
> CGRectMake(ctx->capture_crop_x, ctx->capture_crop_y, ctx->capture_crop_width, 
> ctx->capture_crop_height);
> +}
> +

Unfortunately, AVFoundation does not allow for easily retrieving the screen
resolution before the capture session starts... So please add a warning if
crop_width or crop_height are 0 / unspecified. Also the if should check for >=1
in width and height, as well as >= 0 for x and y to avoid invalid cropping 
regions.

>  video_device = (AVCaptureDevice*) capture_screen_input;
>  capture_screen = 1;
>  #endif
> @@ -799,6 +810,13 @@ static int avf_read_header(AVFormatContext *s)
>  } else {
>  capture_screen_input.capturesMouseClicks = NO;
>  }
> +
> +if (ctx->capture_crop_x != 0 ||
> +ctx->capture_crop_y != 0 ||
> +ctx->capture_crop_width != 0 ||
> +ctx->capture_crop_height != 0) {
> +capture_screen_input.cropRect = 
> CGRectMake(ctx->capture_crop_x, ctx->capture_crop_y, ctx->capture_crop_width, 
> ctx->capture_crop_height);
> +}

Same here.

>  }
>  }
>  #endif
> @@ -1069,6 +1087,9 @@ static int avf_close(AVFormatContext *s)
>  { "video_size", "set video size", offsetof(AVFContext, width), 
> AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },
>  { "capture_cursor", "capture the screen cursor", offsetof(AVFContext, 
> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM 
> },
>  { "capture_mouse_clicks", "capture the screen mouse clicks", 
> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, 
> AV_OPT_FLAG_DECODING_PARAM },

> +{ "capture_crop_x", "crop the screen capture to the specified x offset", 
> offsetof(AVFContext, capture_crop_x), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "capture_crop_y", "crop the screen capture to the specified y offset", 
> offsetof(AVFContext, capture_crop_y), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX, 
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "capture_crop_size", "crop the screen capture to the specified size", 
> offsetof(AVFContext, capture_crop_width), AV_OPT_TYPE_IMAGE_SIZE,  {.str = 
> NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },

See naming suggestions from above. Also, please change to:

"crop the screen capture starting at the specified x offset"

for x and y. Also, please add a description of the new parameters to
doc/indevs.texi. Please add a warning in the code that these options are without
effect whenever a non-screen device is selected but these options are set
(results in unexpected output). You might suggest in the message to apply an
additional non-avfoundation crop filter in the filter chain.

Thanks,
Thilo
___
ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-09 Thread joshdk

From: Josh de Kock 

This test ensures that you are able to send N number of slice NALUs in slice 
threaded mode to be decoded simultaneously
---

 Tested with `./configure --cc='cc -m32'` now, seems to be fine. Will send 
sample to Michael on IRC.

 tests/api/Makefile  |   1 +
 tests/api/api-h264-slice-test.c | 212 ++
 tests/fate/api.mak  |   4 +
 tests/ref/fate/api-h264-slice   | 309 
 4 files changed, 526 insertions(+)
 create mode 100644 tests/api/api-h264-slice-test.c
 create mode 100644 tests/ref/fate/api-h264-slice

diff --git a/tests/api/Makefile b/tests/api/Makefile
index 759dd9d243..b5c4ccae23 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
 APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
 APITESTPROGS-yes += api-seek
 APITESTPROGS-yes += api-codec-param
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
new file mode 100644
index 00..114561f3aa
--- /dev/null
+++ b/tests/api/api-h264-slice-test.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2001 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#define MAX_SLICES 8
+
+// ./fate 2 ./crew_cif out.y4m
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static int header = 0;
+static FILE *ofd;
+
+static void decode(AVCodecContext *dec_ctx, AVFrame *frame,
+   AVPacket *pkt)
+{
+static uint64_t frame_cnt = 0;
+int ret;
+
+ret = avcodec_send_packet(dec_ctx, pkt);
+if (ret < 0) {
+fprintf(stderr, "Error sending a packet for decoding: %s\n", 
av_err2str(ret));
+exit(1);
+}
+
+while (ret >= 0) {
+const AVPixFmtDescriptor *desc;
+char *sum;
+struct AVHashContext *hash;
+
+ret = avcodec_receive_frame(dec_ctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+return;
+} else if (ret < 0) {
+fprintf(stderr, "Error during decoding: %s\n", av_err2str(ret));
+exit(1);
+}
+
+if (!header) {
+printf(
+"#format: frame checksums\n"
+"#version: 2\n"
+"#hash: MD5\n"
+"#tb 0: 1/30\n"
+"#media_type 0: video\n"
+"#codec_id 0: rawvideo\n"
+"#dimensions 0: 352x288\n"
+"#sar 0: 128/117\n"
+"#stream#, dts,pts, duration, size, hash\n");
+header = 1;
+}
+desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+av_hash_alloc(, "md5");
+av_hash_init(hash);
+sum = av_mallocz(av_hash_get_size(hash) * 2 + 1);
+
+for (int i = 0; i < frame->height; i++)
+av_hash_update(hash, >data[0][i * frame->linesize[0]], 
frame->width);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[1][i * frame->linesize[1]], 
frame->width >> desc->log2_chroma_w);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[2][i * frame->linesize[2]], 
frame->width >> desc->log2_chroma_w);
+
+av_hash_final_hex(hash, sum, av_hash_get_size(hash) * 2 + 1);
+printf("0, %10"PRId64", %10"PRId64",1, %8d, %s\n",
+frame_cnt, frame_cnt,
+(frame->width * frame->height + 2 * (frame->height >> 
desc->log2_chroma_h) * (frame->width >> desc->log2_chroma_w)), sum); 
+frame_cnt += 1;
+av_free(hash);
+av_free(sum);
+}
+}
+
+int main(int argc, char **argv)
+{
+const AVCodec *codec;
+AVCodecContext *c = NULL;
+AVFrame *frame;
+unsigned int threads;
+

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Martin Vignali

>
> Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> be replaced with something more modern, but I'd at least drop the MMX
> one.
>

This func already have SSSE3 version (AVX2 can be add easily, but doesn't
find a command line where the speed is interesting in AVX2 (on my
computer)).
I can remove mmx, and only keep mmxext, or remove both (but seems like not
everyone is agree to remove mmx/mmxext, if SSxx version is available).

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

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-09 Thread Henrik Gramner

On Mon, Oct 8, 2018 at 7:46 PM Martin Vignali  wrote:
>
> Hello,
>
> Patch in attach port inline asm shuffle 2103 func (mmx/mmxext) to external
> asm
> and remove the inline asm version
>
> Martin

Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
be replaced with something more modern, but I'd at least drop the MMX
one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale : add bitexact conv for grayf32 and gray16 to f32 conv

2018-10-09 Thread Michael Niedermayer

On Mon, Oct 08, 2018 at 05:04:43PM +0200, Martin Vignali wrote:
> >
> > also there are 2 divisions in this that you can trivially eliminate
> > /255 and /65535 (extra precission beyond IEEE float/double could change
> > these)
> >
> > also the whole could be done with fewer floats and no extra complexity
> > for example:
> > int64_t tmp2 = 16843009LL * i;
> > (float)((double)tmp2 / (1LL<<32))
> > and
> > int64_t tmp2 = 4295032833LL * i or uint64_t 281479271743489
> >
> >
> Still raise the assert for me.
> Maybe we can go back to the initial patch i propose.
> Let the simple initial code, for non bitexact conversion
> and use a dedicated calc for bit exact version, without float calc

does it fail on actual platforms to produce the same result ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 3/3] avformat:hlsenc.c: remove the useless variable - fmp4_init_mode.

2018-10-09 Thread Liu Steven



> 在 2018年10月9日，下午5:25，Charles Liu  写道：
> 
> Signed-off-by: Charles Liu 
> ---
> libavformat/hlsenc.c | 4 
> 1 file changed, 4 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index c322b5a48f..0fd5d2a995 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -147,7 +147,6 @@ typedef struct VariantStream {
> 
> char *fmp4_init_filename;
> char *base_output_dirname;
> -int fmp4_init_mode;
> 
> AVStream **streams;
> char codec_attr[128];
> @@ -733,7 +732,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
> *vs)
> vs->packets_written = 1;
> vs->start_pos = 0;
> vs->new_start = 1;
> -vs->fmp4_init_mode = 0;
> 
> if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> if (hls->max_seg_size > 0) {
> @@ -743,7 +741,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
> *vs)
> 
> vs->packets_written = 0;
> vs->init_range_length = 0;
> -vs->fmp4_init_mode = !byterange_mode;
> set_http_options(s, , hls);
> if ((ret = avio_open_dyn_buf(>pb)) < 0)
> return ret;
> @@ -2291,7 +2288,6 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> vs->start_pos += vs->size;
> }
> 
> -vs->fmp4_init_mode = 0;
> if (hls->flags & HLS_SINGLE_FILE) {
> vs->number++;
> } else if (hls->max_seg_size > 0) {
> -- 
> 2.19.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

patchset LGTM, waiting other reviewers comments.


Thanks

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

[FFmpeg-devel] [PATCH 3/3] avformat:hlsenc.c: remove the useless variable - fmp4_init_mode.

2018-10-09 Thread Charles Liu

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c322b5a48f..0fd5d2a995 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -147,7 +147,6 @@ typedef struct VariantStream {
 
 char *fmp4_init_filename;
 char *base_output_dirname;
-int fmp4_init_mode;
 
 AVStream **streams;
 char codec_attr[128];
@@ -733,7 +732,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 vs->packets_written = 1;
 vs->start_pos = 0;
 vs->new_start = 1;
-vs->fmp4_init_mode = 0;
 
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->max_seg_size > 0) {
@@ -743,7 +741,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 
 vs->packets_written = 0;
 vs->init_range_length = 0;
-vs->fmp4_init_mode = !byterange_mode;
 set_http_options(s, , hls);
 if ((ret = avio_open_dyn_buf(>pb)) < 0)
 return ret;
@@ -2291,7 +2288,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 vs->start_pos += vs->size;
 }
 
-vs->fmp4_init_mode = 0;
 if (hls->flags & HLS_SINGLE_FILE) {
 vs->number++;
 } else if (hls->max_seg_size > 0) {
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/3] avformat:hlsenc.c: fix memory leak in fmp4 mode.

2018-10-09 Thread Charles Liu

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3ccd8756f6..c322b5a48f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2205,6 +2205,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 avio_flush(oc->pb);
 range_length = avio_close_dyn_buf(oc->pb, );
 avio_write(vs->out, buffer, range_length);
+av_free(buffer);
 vs->init_range_length = range_length;
 avio_open_dyn_buf(>pb);
 vs->packets_written = 0;
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 1/3] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread Charles Liu

In fmp4 mode, the duration of the second m4s segment is unusually smaller than 
the expected segment time.

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 28c2dd62fc..3ccd8756f6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 }
 
-if (vs->fmp4_init_mode) {
-vs->number--;
-}
-
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->flags & HLS_SINGLE_FILE) {
 ret = flush_dynbuf(vs, _length);
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 3/3] avformat:hlsenc.c: remove the useless variable - fmp4_init_mode.

2018-10-09 Thread Charles Liu

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c322b5a48f..0fd5d2a995 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -147,7 +147,6 @@ typedef struct VariantStream {
 
 char *fmp4_init_filename;
 char *base_output_dirname;
-int fmp4_init_mode;
 
 AVStream **streams;
 char codec_attr[128];
@@ -733,7 +732,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 vs->packets_written = 1;
 vs->start_pos = 0;
 vs->new_start = 1;
-vs->fmp4_init_mode = 0;
 
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->max_seg_size > 0) {
@@ -743,7 +741,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
*vs)
 
 vs->packets_written = 0;
 vs->init_range_length = 0;
-vs->fmp4_init_mode = !byterange_mode;
 set_http_options(s, , hls);
 if ((ret = avio_open_dyn_buf(>pb)) < 0)
 return ret;
@@ -2291,7 +2288,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 vs->start_pos += vs->size;
 }
 
-vs->fmp4_init_mode = 0;
 if (hls->flags & HLS_SINGLE_FILE) {
 vs->number++;
 } else if (hls->max_seg_size > 0) {
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread Liu Steven



> 在 2018年10月9日，下午4:05，C.H.Liu  写道：
> 
> My test clip is big_buck_bunny_1080p_h264.mov with CMD: 
> 
> ./ffmpeg -i ~/Downloads/conversion/big_buck_bunny_1080p_h264.mov -t 50 -flags 
> +cgop -g 30 -preset superfast -f hls -hls_segment_type fmp4 
> -hls_playlist_type vod -hls_time 10 issue/pl.m3u8
> 
> The original result is:
> 
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:10
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXT-X-MAP:URI="init.mp4"
> #EXTINF:10.416667,
> pl0.m4s
> #EXTINF:1.25,
> pl1.m4s
> #EXTINF:9.08,
> pl2.m4s
> #EXTINF:9.791667,
> pl3.m4s
> #EXTINF:10.00,
> pl4.m4s
> #EXTINF:9.458333,
> pl5.m4s
> #EXT-X-ENDLIST
> 
> 
> 
> After apply the patch, the result become to:
> 
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:10
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-PLAYLIST-TYPE:VOD
> #EXT-X-MAP:URI="init.mp4"
> #EXTINF:10.416667,
> pl0.m4s
> #EXTINF:10.33,
> pl1.m4s
> #EXTINF:9.791667,
> pl2.m4s
> #EXTINF:10.00,
> pl3.m4s
> #EXTINF:9.458333,
> pl4.m4s
> #EXT-X-ENDLIST
> 
> 
> 
> Seems that the vs→number in function hls_write_packet() was minus once more. 
> Then “end_pts = hls->recording_time * vs→number;” was too small.
> 
> After having enough buffer (av_compare_ts() around line 2189), we generate 
> the init.mp4 firstly, then the first segment. It should be generate the 
> second segment, when we DO have enough buffer for the second time, . However, 
> the end_pts dons’t grow any, because the vs→number was subtracted 1.
Ok, you are right until now.
fmp4_init_mode maybe you can remove too.



> 
> 
> Liu Steven  于2018年10月9日周二 下午3:28写道：
> 
> 
> > 在 2018年10月9日，下午3:17，Liu Steven  写道：
> > 
> > 
> > 
> >> 在 2018年10月9日，下午2:56，Charles Liu  写道：
> >> 
> >> In fmp4 mode, the duration of the second m4s segment is unusually smaller 
> >> than the expected segment time.
> >> 
> >> Signed-off-by: Charles Liu 
> >> ---
> >> libavformat/hlsenc.c | 4 
> >> 1 file changed, 4 deletions(-)
> >> 
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index 28c2dd62fc..3ccd8756f6 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, 
> >> AVPacket *pkt)
> >>}
> >>}
> >> 
> >> -if (vs->fmp4_init_mode) {
> >> -vs->number--;
> >> -}
> > 
> > No, this is reserve, will be used by byterange mode
> 
> Ah, sorry my mistake, it is because the when the init.mp4 is not in the 
> sequence, so the start number should be 0.
> >> -
> >>if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> >>if (hls->flags & HLS_SINGLE_FILE) {
> >>ret = flush_dynbuf(vs, _length);
> >> -- 
> >> 2.19.1
> >> 
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > 
> > 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread C.H.Liu

My test clip is big_buck_bunny_1080p_h264.mov with CMD:

./ffmpeg -i ~/Downloads/conversion/big_buck_bunny_1080p_h264.mov -t 50
-flags +cgop -g 30 -preset superfast -f hls -hls_segment_type fmp4
-hls_playlist_type vod -hls_time 10 issue/pl.m3u8

The original result is:

#EXTM3U

#EXT-X-VERSION:7

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-MAP:URI="init.mp4"

#EXTINF:10.416667,

pl0.m4s

#EXTINF:1.25,

pl1.m4s

#EXTINF:9.08,

pl2.m4s

#EXTINF:9.791667,

pl3.m4s

#EXTINF:10.00,

pl4.m4s

#EXTINF:9.458333,

pl5.m4s

#EXT-X-ENDLIST



After apply the patch, the result become to:

#EXTM3U

#EXT-X-VERSION:7

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-MAP:URI="init.mp4"

#EXTINF:10.416667,

pl0.m4s

#EXTINF:10.33,

pl1.m4s

#EXTINF:9.791667,

pl2.m4s

#EXTINF:10.00,

pl3.m4s

#EXTINF:9.458333,

pl4.m4s

#EXT-X-ENDLIST



Seems that the vs→number in function hls_write_packet() was minus once
more. Then “end_pts = hls->recording_time * vs→number;” was too small.

After having enough buffer (av_compare_ts() around line 2189), we generate
the init.mp4 firstly, then the first segment. It should be generate the
second segment, when we DO have enough buffer for the second time, .
However, the end_pts dons’t grow any, because the vs→number was subtracted
1.

Liu Steven  于2018年10月9日周二 下午3:28写道：

>
>
> > 在 2018年10月9日，下午3:17，Liu Steven  写道：
> >
> >
> >
> >> 在 2018年10月9日，下午2:56，Charles Liu  写道：
> >>
> >> In fmp4 mode, the duration of the second m4s segment is unusually
> smaller than the expected segment time.
> >>
> >> Signed-off-by: Charles Liu 
> >> ---
> >> libavformat/hlsenc.c | 4 
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index 28c2dd62fc..3ccd8756f6 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> >>}
> >>}
> >>
> >> -if (vs->fmp4_init_mode) {
> >> -vs->number--;
> >> -}
> >
> > No, this is reserve, will be used by byterange mode
>
> Ah, sorry my mistake, it is because the when the init.mp4 is not in the
> sequence, so the start number should be 0.
> >> -
> >>if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> >>if (hls->flags & HLS_SINGLE_FILE) {
> >>ret = flush_dynbuf(vs, _length);
> >> --
> >> 2.19.1
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_LSB and YUV444P12_LSB pixel formats

2018-10-09 Thread Timo Rothenpieler


On 09/10/2018 02:32, Carl Eugen Hoyos wrote:

2018-10-08 21:59 GMT+02:00, Timo Rothenpieler :

So, to be able to use these hardware compatible formats, we need
definitions for them in ffmpeg. Right now, I need this for nvdec,
but Vulkan also uses the same format definitions.


Sorry if this was already done and I forgot but please explain why
you cannot use YUV444P16 for this use-case.

If the only thing missing is libavfilter understanding
bits_per_raw_sample
we should add it there: It is needed in any case and would save us a few
pix_fmts and could speed up many use cases compared to your solution.


It's pretty much all of ffmpeg and all client applications understanding
it.
First of all, bits_per_raw_sample, or an equivalent bit depth field, is
missing from AVFrame.
"In" avfilter it's primarily swscale I guess, but it also affects each
and every filter supporting YUV444P16.
Also, for encoders, it would mean they need a way to indicate what bit
depths they can take, and that also has to be per pix_fmt they support.
Then all of avcodec, ffmpeg.c, ... needs support for that.
It's quite a deep rabit hole of changes with quite a good chance of
something going horribly wrong in the process. Probably even in more
places than just the ones mentioned here.


This may or may not be true, unfortunately my question was not
how difficult it would be to fix this mess (I don't think it is), but
why you want to add more to the mess.

What would happen if you just use YUV444P16?


For example nvenc only supports 10 bit encoding, but takes it in the 
YUV444P16 format. The rest of ffmpeg has no idea it only supports 10 
bit, and at times even up-converts 10 bit content to 16 bit via swscale 
due to that.
Also, it loses quality without the user noticing, as there is no outside 
indication it does in fact not support 16 bit.




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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread Liu Steven



> 在 2018年10月9日，下午3:17，Liu Steven  写道：
> 
> 
> 
>> 在 2018年10月9日，下午2:56，Charles Liu  写道：
>> 
>> In fmp4 mode, the duration of the second m4s segment is unusually smaller 
>> than the expected segment time.
>> 
>> Signed-off-by: Charles Liu 
>> ---
>> libavformat/hlsenc.c | 4 
>> 1 file changed, 4 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 28c2dd62fc..3ccd8756f6 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>}
>>}
>> 
>> -if (vs->fmp4_init_mode) {
>> -vs->number--;
>> -}
> 
> No, this is reserve, will be used by byterange mode

Ah, sorry my mistake, it is because the when the init.mp4 is not in the 
sequence, so the start number should be 0.
>> -
>>if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>if (hls->flags & HLS_SINGLE_FILE) {
>>ret = flush_dynbuf(vs, _length);
>> -- 
>> 2.19.1
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH 2/2] avformat:hlsenc.c: fix memory leak in fmp4 mode.

2018-10-09 Thread Liu Steven



> 在 2018年10月9日，下午2:57，Charles Liu  写道：
> 
> Signed-off-by: Charles Liu 
> ---
> libavformat/hlsenc.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 3ccd8756f6..c322b5a48f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2205,6 +2205,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>avio_flush(oc->pb);
>range_length = avio_close_dyn_buf(oc->pb, );
>avio_write(vs->out, buffer, range_length);
> +av_free(buffer);
>vs->init_range_length = range_length;
>avio_open_dyn_buf(>pb);
>vs->packets_written = 0;
> -- 
> 2.19.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM

Thanks

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread Liu Steven



> 在 2018年10月9日，下午2:56，Charles Liu  写道：
> 
> In fmp4 mode, the duration of the second m4s segment is unusually smaller 
> than the expected segment time.
> 
> Signed-off-by: Charles Liu 
> ---
> libavformat/hlsenc.c | 4 
> 1 file changed, 4 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 28c2dd62fc..3ccd8756f6 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> }
> }
> 
> -if (vs->fmp4_init_mode) {
> -vs->number--;
> -}

No, this is reserve, will be used by byterange mode
> -
> if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> if (hls->flags & HLS_SINGLE_FILE) {
> ret = flush_dynbuf(vs, _length);
> -- 
> 2.19.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

[FFmpeg-devel] [PATCH 2/2] avformat:hlsenc.c: fix memory leak in fmp4 mode.

2018-10-09 Thread Charles Liu

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3ccd8756f6..c322b5a48f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2205,6 +2205,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 avio_flush(oc->pb);
 range_length = avio_close_dyn_buf(oc->pb, );
 avio_write(vs->out, buffer, range_length);
+av_free(buffer);
 vs->init_range_length = range_length;
 avio_open_dyn_buf(>pb);
 vs->packets_written = 0;
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix the duration of m4s segment is unusually smaller than expected.

2018-10-09 Thread Charles Liu

In fmp4 mode, the duration of the second m4s segment is unusually smaller than 
the expected segment time.

Signed-off-by: Charles Liu 
---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 28c2dd62fc..3ccd8756f6 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 }
 
-if (vs->fmp4_init_mode) {
-vs->number--;
-}
-
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->flags & HLS_SINGLE_FILE) {
 ret = flush_dynbuf(vs, _length);
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH] dns cache map key now hostname+port

2018-10-09 Thread Hendrik Leppkes

On Tue, Oct 9, 2018 at 3:50 AM Slavka  wrote:
>
> From: root 
>
> ---
>  libavformat/tcp.c | 16 
>  libavutil/dns_cache.c | 28 +++-
>  libavutil/dns_cache.h |  6 +++---
>  3 files changed, 30 insertions(+), 20 deletions(-)
>

This does not match any code currently present in our code base.

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

58 matches

Mail list logo