[FFmpeg-devel] [PATCH] avformat/hls: make different warning message between open url and parse playlist

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/hls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 4e38d25678..f4e449880b 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -658,7 +658,7 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 } else if (ret < 0) {
 if (ret != AVERROR_EOF)
 av_log(s, AV_LOG_WARNING,
-"keepalive request failed for '%s', retrying with new 
connection: %s\n",
+"keepalive request failed for '%s' when opening url, 
retrying with new connection: %s\n",
 url, av_err2str(ret));
 ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
 }
@@ -715,7 +715,7 @@ static int parse_playlist(HLSContext *c, const char *url,
 } else if (ret < 0) {
 if (ret != AVERROR_EOF)
 av_log(c->ctx, AV_LOG_WARNING,
-"keepalive request failed for '%s', retrying with new 
connection: %s\n",
+"keepalive request failed for '%s' when parsing playlist, 
retrying with new connection: %s\n",
 url, av_err2str(ret));
 in = NULL;
 }
-- 
2.17.2 (Apple Git-113)



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

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

Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode GPU copy sample

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Wednesday, March 27, 2019 12:05 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> GPU copy sample
> 
> On Tue, Mar 26, 2019 at 01:39:49PM +0800, Linjie Fu wrote:
> > Usage is:
> >   ./qsvdec_gpucopy on/off input_stream output_stream
> >
> > For example:
> >  - enable/disable gpu copy:
> >   ./qsvdec_gpucopy on input.h264 output.yuv
> >   ./qsvdec_gpucopy off input.h264 output.yuv
> >
> > Generate fps per second.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  configure |   2 +
> >  doc/examples/Makefile |   1 +
> >  doc/examples/qsvdec_gpucopy.c | 276
> > ++
> >  3 files changed, 279 insertions(+)
> >  create mode 100644 doc/examples/qsvdec_gpucopy.c
> 
> breaks examples build on arm
> 
> In file included from src/doc/examples/qsvdec_gpucopy.c:43:0:
> src/libavcodec/qsv.h:24:26: fatal error: mfx/mfxvideo.h: No such file or
> directory compilation terminated.
> make: *** [doc/examples/qsvdec_gpucopy.o] Error 1
> make: *** Waiting for unfinished jobs

It is caused by libmfx is not checked to configure this example in configure 
file. 
It is checked for doc/examples/qsvdec.c: qsvdec_example_deps="avcodec avutil 
libmfx h264_qsv_decoder" 
Similar checking is needed for this example. 

However, I would like to suggestion to add gpu_copy option based on current 
qsvdec.c example (working in system memory path should be added too). 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Timo Rothenpieler
> Sent: Monday, March 25, 2019 6:21 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as
> vaapi header search
> 
> On 20/03/2019 08:57, Zhong Li wrote:
> > Currectly just standard header path and be found, check_type/struct
> > will fail if vaapi is installed somewhere else.
> > ---
> >   configure | 18 ++
> >   1 file changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/configure b/configure
> > index eaf543df96..0e3c2d24bf 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> "ID3D11VideoDecoder"
> >   check_type "windows.h d3d11.h" "ID3D11VideoContext"
> >   check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> > -D_WIN32_WINNT=0x0602
> >
> > -check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> > -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > rotation_flags -check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> > -check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> > -check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> > -check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> > -
> >   check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> >
> >   if enabled cuda_sdk; then
> > @@ -6469,6 +6461,16 @@ if enabled vaapi; then
> >   check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0,
> 0)"
> >   fi
> >
> > +if enabled vaapi; then
> > +check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> > +check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> bit_depth
> > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> rotation_flags
> > +check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> > +check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> > +check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> > +check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> > +fi
> > +
> >   if enabled_all opencl libdrm ; then
> >   check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
> >   enable opencl_drm_beignet
> >
> 
> Do I understand this right, that the desired effect is achieved by putting
> those check_* behind the pkgconfig check, which is in between the old and
> the new location?
> 
> If so, this looks OK to me.

Yes, you are right. Probably would better to make it clear in the commit 
message. 
Will update commit message and apply it during next 24 hours if nobody against. 
 

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

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

[FFmpeg-devel] [PATCH 4/4] lavc/qsvenc: get vps extradata from MSDK

[Zhong Li]

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c  | 48 +---
 libavcodec/qsvenc.h  |  3 +++
 libavcodec/qsvenc_hevc.c | 10 +
 3 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7903235db9..5072f3ba88 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -818,6 +818,16 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 };
 #endif
 
+#if QSV_HAVE_CO_VPS
+uint8_t vps_buf[128];
+mfxExtCodingOptionVPS extradata_vps = {
+.Header.BufferId = MFX_EXTBUFF_CODING_OPTION_VPS,
+.Header.BufferSz = sizeof(extradata_vps),
+.VPSBuffer   = vps_buf,
+.VPSBufSize  = sizeof(vps_buf),
+};
+#endif
+
 mfxExtBuffer *ext_buffers[] = {
 (mfxExtBuffer*),
 (mfxExtBuffer*),
@@ -826,11 +836,14 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 #endif
 #if QSV_HAVE_CO3
 (mfxExtBuffer*),
+#endif
+#if QSV_HAVE_CO_VPS
+(mfxExtBuffer*)_vps,
 #endif
 };
 
 int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
-int ret;
+int ret, extradata_offset = 0;
 
 q->param.ExtParam= ext_buffers;
 q->param.NumExtParam = FF_ARRAY_ELEMS(ext_buffers);
@@ -842,20 +855,39 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx, 
QSVEncContext *q)
 
 q->packet_size = q->param.mfx.BufferSizeInKB * 
q->param.mfx.BRCParamMultiplier * 1000;
 
-if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)) {
+q->hevc_vps = (avctx->codec_id == AV_CODEC_ID_HEVC) && 
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 17);
+
+if (!extradata.SPSBufSize || (need_pps && !extradata.PPSBufSize)
+#if QSV_HAVE_CO_VPS
+|| (q->hevc_vps && !extradata_vps.VPSBufSize)
+#endif
+) {
 av_log(avctx, AV_LOG_ERROR, "No extradata returned from libmfx.\n");
 return AVERROR_UNKNOWN;
 }
 
-avctx->extradata = av_malloc(extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize +
- AV_INPUT_BUFFER_PADDING_SIZE);
+avctx->extradata_size = extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize;
+#if QSV_HAVE_CO_VPS
+avctx->extradata_size += q->hevc_vps * extradata_vps.VPSBufSize;
+#endif
+
+avctx->extradata = av_malloc(avctx->extradata_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!avctx->extradata)
 return AVERROR(ENOMEM);
 
-memcpy(avctx->extradata,sps_buf, 
extradata.SPSBufSize);
-if (need_pps)
-memcpy(avctx->extradata + extradata.SPSBufSize, pps_buf, 
extradata.PPSBufSize);
-avctx->extradata_size = extradata.SPSBufSize + need_pps * 
extradata.PPSBufSize;
+#if QSV_HAVE_CO_VPS
+if (q->hevc_vps) {
+memcpy(avctx->extradata, vps_buf, extradata_vps.VPSBufSize);
+extradata_offset += extradata_vps.VPSBufSize;
+}
+#endif
+
+memcpy(avctx->extradata + extradata_offset, sps_buf, extradata.SPSBufSize);
+extradata_offset += extradata.SPSBufSize;
+if (need_pps) {
+memcpy(avctx->extradata + extradata_offset, pps_buf, 
extradata.PPSBufSize);
+extradata_offset += extradata.PPSBufSize;
+}
 memset(avctx->extradata + avctx->extradata_size, 0, 
AV_INPUT_BUFFER_PADDING_SIZE);
 
 cpb_props = ff_add_cpb_side_data(avctx);
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 28d873210f..3030e4413f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -36,6 +36,7 @@
 
 #define QSV_HAVE_CO2 QSV_VERSION_ATLEAST(1, 6)
 #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
+#define QSV_HAVE_CO_VPS  QSV_VERSION_ATLEAST(1, 17)
 
 #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
 #define QSV_HAVE_MAX_SLICE_SIZE QSV_VERSION_ATLEAST(1, 9)
@@ -137,6 +138,8 @@ typedef struct QSVEncContext {
 
 mfxVersion  ver;
 
+int hevc_vps;
+
 // options set by the caller
 int async_depth;
 int idr_interval;
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index edc9a8ab54..23552a3a26 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -195,10 +195,12 @@ static av_cold int qsv_enc_init(AVCodecContext *avctx)
 if (ret < 0)
 return ret;
 
-ret = generate_fake_vps(>qsv, avctx);
-if (ret < 0) {
-ff_qsv_enc_close(avctx, >qsv);
-return ret;
+if (!q->qsv.hevc_vps) {
+ret = generate_fake_vps(>qsv, avctx);
+if (ret < 0) {
+ff_qsv_enc_close(avctx, >qsv);
+return ret;
+}
 }
 
 return 0;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 3/4] lavc/qsvenc: make the queried libmfx version easily reused

[Zhong Li]

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 17 -
 libavcodec/qsvenc.h |  2 ++
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index afeb0f7b10..7903235db9 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -477,13 +477,6 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 int target_bitrate_kbps, max_bitrate_kbps, brc_param_multiplier;
 int buffer_size_in_kilobytes, initial_delay_in_kilobytes;
 int ret;
-mfxVersion ver;
-
-ret = MFXQueryVersion(q->session,);
-if (ret != MFX_ERR_NONE) {
-av_log(avctx, AV_LOG_ERROR, "Error getting the session handle\n");
-return AVERROR_UNKNOWN;
-}
 
 ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
 if (ret < 0)
@@ -539,7 +532,7 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 // If the minor version is greater than or equal to 19,
 // then can use the same alignment settings as H.264 for HEVC
 q->width_align = (avctx->codec_id != AV_CODEC_ID_HEVC ||
-  QSV_RUNTIME_VERSION_ATLEAST(ver, 1, 19)) ? 16 : 32;
+  QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 19)) ? 16 : 32;
 q->param.mfx.FrameInfo.Width = FFALIGN(avctx->width, q->width_align);
 
 if (avctx->flags & AV_CODEC_FLAG_INTERLACED_DCT) {
@@ -738,7 +731,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
 #if QSV_HAVE_MF
-if (QSV_RUNTIME_VERSION_ATLEAST(ver, 1, 25)) {
+if (QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 25)) {
 q->extmfp.Header.BufferId = MFX_EXTBUFF_MULTI_FRAME_PARAM;
 q->extmfp.Header.BufferSz = sizeof(q->extmfp);
 
@@ -1005,6 +998,12 @@ int ff_qsv_enc_init(AVCodecContext *avctx, QSVEncContext 
*q)
 if (ret < 0)
 return ret;
 
+ret = MFXQueryVersion(q->session,>ver);
+if (ret < 0) {
+return ff_qsv_print_error(avctx, ret,
+  "Error querying mfx version");
+}
+
 // in the mfxInfoMFX struct, JPEG is different from other codecs
 switch (avctx->codec_id) {
 case AV_CODEC_ID_MJPEG:
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index ca1bb44c62..28d873210f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -135,6 +135,8 @@ typedef struct QSVEncContext {
 
 QSVFramesContext frames_ctx;
 
+mfxVersion  ver;
+
 // options set by the caller
 int async_depth;
 int idr_interval;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/4] lavc/qsvenc: fix hevc vps extradata issues

[Zhong Li]

cbs trace qsv vps header failed due to some reasons:
1. vps_temporal_id_nesting_flag is not set but spec required it must to
   be 1 when vps_max_sub_layers_minus1 is equal to 0.
2. vps_num_hrd_parameters is not set and written.
3. other issues in ff_hevc_encode_nal_vps() (have fixed in pervious commit).

Reproduce: ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i 
bbb_sunflower_1080p_30fps_normal.mp4 -vframes 1
-c:v hevc_qsv  -bsf:v trace_headers -f null -

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc_hevc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 3d7e9cfba4..edc9a8ab54 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -107,6 +107,7 @@ static int generate_fake_vps(QSVEncContext *q, 
AVCodecContext *avctx)
 /* generate the VPS */
 vps.vps_max_layers = 1;
 vps.vps_max_sub_layers = sps.max_sub_layers;
+vps.vps_temporal_id_nesting_flag = sps.temporal_id_nesting_flag;
 memcpy(, , sizeof(vps.ptl));
 vps.vps_sub_layer_ordering_info_present_flag = 1;
 for (i = 0; i < HEVC_MAX_SUB_LAYERS; i++) {
@@ -120,7 +121,8 @@ static int generate_fake_vps(QSVEncContext *q, 
AVCodecContext *avctx)
 vps.vps_num_units_in_tick   = sps.vui.vui_num_units_in_tick;
 vps.vps_time_scale  = sps.vui.vui_time_scale;
 vps.vps_poc_proportional_to_timing_flag = 
sps.vui.vui_poc_proportional_to_timing_flag;
-vps.vps_num_ticks_poc_diff_one  = 
sps.vui.vui_num_ticks_poc_diff_one_minus1 + 1;
+vps.vps_num_ticks_poc_diff_one  = 
sps.vui.vui_num_ticks_poc_diff_one_minus1 + 1;
+vps.vps_num_hrd_parameters = 0;
 
 /* generate the encoded RBSP form of the VPS */
 ret = ff_hevc_encode_nal_vps(, sps.vps_id, vps_rbsp_buf, 
sizeof(vps_rbsp_buf));
@@ -138,12 +140,12 @@ static int generate_fake_vps(QSVEncContext *q, 
AVCodecContext *avctx)
 bytestream2_put_byte(, 1); // header
 
 while (bytestream2_get_bytes_left()) {
-uint32_t b = bytestream2_peek_be24();
-if (b <= 3) {
-bytestream2_put_be24(, 3);
-bytestream2_skip(, 2);
-} else
-bytestream2_put_byte(, bytestream2_get_byte());
+   if (bytestream2_get_bytes_left() >= 3 &&
+   bytestream2_peek_be24() <= 3) {
+   bytestream2_put_be24(, 3);
+   bytestream2_skip(, 2);
+   } else
+   bytestream2_put_byte(, bytestream2_get_byte());
 }
 
 vps_size = bytestream2_tell_p();
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/4] lavc/hevc_ps_enc: fix vps nal issues

[Zhong Li]

1. write vps_num_hrd_parameters element
2. flush left bits

Signed-off-by: Zhong Li 
---
 libavcodec/hevc_ps_enc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/hevc_ps_enc.c b/libavcodec/hevc_ps_enc.c
index 4c71cf41ca..78a73a5c0a 100644
--- a/libavcodec/hevc_ps_enc.c
+++ b/libavcodec/hevc_ps_enc.c
@@ -67,7 +67,7 @@ int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
uint8_t *buf, int buf_size)
 {
 PutBitContext pb;
-int i;
+int i, data_size;
 
 init_put_bits(, buf, buf_size);
 put_bits(,  4, id);
@@ -103,6 +103,7 @@ int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
 if (vps->vps_poc_proportional_to_timing_flag)
 set_ue_golomb(, vps->vps_num_ticks_poc_diff_one - 1);
 
+set_ue_golomb(, vps->vps_num_hrd_parameters);
 if (vps->vps_num_hrd_parameters) {
 avpriv_report_missing_feature(NULL, "Writing HRD parameters");
 return AVERROR_PATCHWELCOME;
@@ -114,5 +115,8 @@ int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
 put_bits(, 1, 1);// stop bit
 avpriv_align_put_bits();
 
-return put_bits_count() / 8;
+data_size = put_bits_count() / 8;
+flush_put_bits();
+
+return data_size;
 }
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Jing Sun]

Signed-off-by: Zhengxu Huang 
Signed-off-by: Hassene Tmar 
Signed-off-by: Jun Zhao 
Signed-off-by: Jing Sun 
---
 configure|   4 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/libsvt_hevc.c | 502 +++
 4 files changed, 508 insertions(+)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index 938ff10..2aabac4 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1784,6 +1785,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3173,6 +3175,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6209,6 +6212,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc EbApi.h 
EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8..c93e545 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -987,6 +987,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b26aeca..e93f66f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -703,6 +703,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..ca6e37b
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,502 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2018 Intel Corporation
+*
+* This file is part of FFmpeg.
+*
+* FFmpeg is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* FFmpeg is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+
+typedef enum eos_status {
+EOS_NOT_REACHED = 0,
+EOS_REACHED,
+EOS_TOTRIGGER
+}EOS_STATUS;
+
+typedef struct SvtContext {
+AVClass *class;
+
+EB_H265_ENC_CONFIGURATION enc_params;
+EB_COMPONENTTYPE *svt_handle;
+EB_BUFFERHEADERTYPE in_buf;
+EOS_STATUS eos_flag;
+
+// User options.
+int vui_info;
+   

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/hevcdec: Avoid only partly skiping duplicate first slices

[James Almer]

On 3/26/2019 9:17 PM, Michael Niedermayer wrote:
> Fixes: NULL pointer dereference and out of array access
> Fixes: 
> 13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
> Fixes: 
> 13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5650370728034304
> 
> This also fixes the return code for explode mode
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevcdec.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 86adab0ae1..857c10dd12 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -488,6 +488,11 @@ static int hls_slice_header(HEVCContext *s)
>  
>  // Coded parameters
>  sh->first_slice_in_pic_flag = get_bits1(gb);
> +if (s->ref && sh->first_slice_in_pic_flag) {
> +av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the first 
> in the same frame.\n");
> +return 1; // This slice will be skiped later, do not corrupt state
> +}
> +
>  if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
>  s->seq_decode = (s->seq_decode + 1) & 0xff;
>  s->max_ra = INT_MAX;
> @@ -2918,6 +2923,11 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  ret = hls_slice_header(s);
>  if (ret < 0)
>  return ret;
> +if (ret == 1) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> +
>  
>  if (
>  (s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == 
> HEVC_SLICE_B) ||
> @@ -2927,10 +2937,6 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  }
>  
>  if (s->sh.first_slice_in_pic_flag) {
> -if (s->ref) {
> -av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being 
> the first in the same frame.\n");
> -goto fail;
> -}
>  if (s->max_ra == INT_MAX) {
>  if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
>  s->max_ra = s->poc;

LGTM. Please also backport it. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] configure: Do not enable both OpenCL-VAAPI interop modes simultaneously

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Wednesday, March 27, 2019 7:39 AM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH] configure: Do not enable both OpenCL-VAAPI
> interop modes simultaneously
> 
> Beignet offers a far more flexiable and complete interface, so choose it
> by default if available.
Sorry I missed your last mail. Sure, I agree Beignet sharing is far more 
flexible.
The patch LGTM.

Thanks!
Ruiling
> ---
> On 23/03/2019 12:27, Mark Thompson wrote:
> > On 22/03/2019 01:40, Ruiling Song wrote:
> >> ffmpeg | branch: master | Ruiling Song  | Fri Nov 
> >> 23
> 13:39:12 2018 +0800| [61cb505d18b8a335bd118d88c05b9daf40eb5f9b] |
> committer: Ruiling Song
> >>
> >> lavu/opencl: replace va_ext.h with standard name
> >>
> >> Khronos OpenCL header (https://github.com/KhronosGroup/OpenCL-Headers)
> >> uses cl_va_api_media_sharing_intel.h. And Intel's official OpenCL driver
> >> for Intel GPU (https://github.com/intel/compute-runtime) was compiled
> >> against Khronos OpenCL header. So it's better to align with Khronos.
> >>
> >> Signed-off-by: Ruiling Song 
> >>
> >>>
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=61cb505d18b8a335
> bd118d88c05b9daf40eb5f9b
> >> ---
> >>
> >>  configure| 2 +-
> >>  libavutil/hwcontext_opencl.c | 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/configure b/configure
> >> index a817479559..331393f8d5 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -6472,7 +6472,7 @@ fi
> >>
> >>  if enabled_all opencl vaapi ; then
> >>  enabled opencl_drm_beignet && enable opencl_vaapi_beignet
> >> -check_type "CL/cl.h CL/va_ext.h"
> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> >> +check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h"
> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> >>  enable opencl_vaapi_intel_media
> >>  fi
> >>
> >> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> >> index d3df6221c4..b116c5b708 100644
> >> --- a/libavutil/hwcontext_opencl.c
> >> +++ b/libavutil/hwcontext_opencl.c
> >> @@ -50,7 +50,7 @@
> >>  #include 
> >>  #endif
> >>  #include 
> >> -#include 
> >> +#include 
> >>  #include "hwcontext_vaapi.h"
> >>  #endif
> >>
> >
> > This broke the build when both are available.
> >
> > $ make
> > CC  libavutil/hwcontext_opencl.o
> > src/libavutil/hwcontext_opencl.c: In function ‘opencl_device_derive’:
> > src/libavutil/hwcontext_opencl.c:1236:5: error: duplicate case value
> >  case AV_HWDEVICE_TYPE_VAAPI:
> >  ^~~~
> > src/libavutil/hwcontext_opencl.c:1205:5: note: previously used here
> >  case AV_HWDEVICE_TYPE_VAAPI:
> >  ^~~~
> > src/libavutil/hwcontext_opencl.c: In function ‘opencl_map_to’:
> > src/libavutil/hwcontext_opencl.c:2831:5: error: duplicate case value
> >  case AV_PIX_FMT_VAAPI:
> >  ^~~~
> > src/libavutil/hwcontext_opencl.c:2825:5: note: previously used here
> >  case AV_PIX_FMT_VAAPI:
> >  ^~~~
> > src/libavutil/hwcontext_opencl.c: In function ‘opencl_frames_derive_to’:
> > src/libavutil/hwcontext_opencl.c:2873:5: error: duplicate case value
> >  case AV_HWDEVICE_TYPE_VAAPI:
> >  ^~~~
> > src/libavutil/hwcontext_opencl.c:2866:5: note: previously used here
> >  case AV_HWDEVICE_TYPE_VAAPI:
> >  ^~~~
> > make: *** [ffbuild/common.mak:60: libavutil/hwcontext_opencl.o] Error 1
> > make: Target 'all' not remade because of errors.
> >
> > $ cat config.h | grep HAVE_OPENCL
> > #define HAVE_OPENCL_D3D11 0
> > #define HAVE_OPENCL_DRM_ARM 0
> > #define HAVE_OPENCL_DRM_BEIGNET 1
> > #define HAVE_OPENCL_DXVA2 0
> > #define HAVE_OPENCL_VAAPI_BEIGNET 1
> > #define HAVE_OPENCL_VAAPI_INTEL_MEDIA 1
> >
> >
> > I think in general the Beignet mapping is more useful if present since it 
> > has far
> fewer constraints, so perhaps disable this one if Beignet is there?
> 
>  configure | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 331393f8d5..c94f516224 100755
> --- a/configure
> +++ b/configure
> @@ -6471,9 +6471,12 @@ if enabled_all opencl libdrm ; then
>  fi
> 
>  if enabled_all opencl vaapi ; then
> -enabled opencl_drm_beignet && enable opencl_vaapi_beignet
> -check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h"
> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> -enable opencl_vaapi_intel_media
> +if enabled opencl_drm_beignet ; then
> +enable opencl_vaapi_beignet
> +else
> +check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h"
> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> +enable opencl_vaapi_intel_media
> +fi
>  fi
> 
>  if enabled_all opencl dxva2 ; then
> --
> 2.19.2
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To 

[FFmpeg-devel] [PATCH v3] avcodec: add AV1 frame split bitstream filter

[James Almer]

This will be needed by the eventual native AV1 decoder.

Signed-off-by: James Almer 
---
Now propagating the Temporal Unit unchanged if splitting can't be performed.

 configure|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/av1_frame_split_bsf.c | 252 +++
 libavcodec/bitstream_filters.c   |   1 +
 4 files changed, 255 insertions(+)
 create mode 100644 libavcodec/av1_frame_split_bsf.c

diff --git a/configure b/configure
index 331393f8d5..ed33490797 100755
--- a/configure
+++ b/configure
@@ -3076,6 +3076,7 @@ vc1_parser_select="vc1dsp"
 
 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
+av1_frame_split_select="cbs_av1"
 av1_metadata_bsf_select="cbs_av1"
 eac3_core_bsf_select="ac3_parser"
 filter_units_bsf_select="cbs"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8a6a..27f326247d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1065,6 +1065,7 @@ OBJS-$(CONFIG_XMA_PARSER)  += xma_parser.o
 # bitstream filters
 OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += aac_adtstoasc_bsf.o mpeg4audio.o
 OBJS-$(CONFIG_AV1_METADATA_BSF)   += av1_metadata_bsf.o
+OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= av1_frame_split_bsf.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
diff --git a/libavcodec/av1_frame_split_bsf.c b/libavcodec/av1_frame_split_bsf.c
new file mode 100644
index 00..ce1ae81c42
--- /dev/null
+++ b/libavcodec/av1_frame_split_bsf.c
@@ -0,0 +1,252 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * This bitstream filter splits AV1 Temporal Units into packets containing
+ * just one frame, plus any leading and trailing OBU that may be present.
+ *
+ * Temporal Units already containing only one frame will be passed through
+ * unchanged, as will those where splitting couldn't be performed.
+ *
+ */
+
+#include "libavutil/avassert.h"
+
+#include "avcodec.h"
+#include "bsf.h"
+#include "cbs.h"
+#include "cbs_av1.h"
+
+typedef struct AV1FSplitContext {
+AVPacket *buffer_pkt;
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment temporal_unit;
+
+int nb_frames;
+int cur_frame;
+int cur_frame_idx;
+int last_frame_idx;
+} AV1FSplitContext;
+
+static int av1_frame_split_filter(AVBSFContext *ctx, AVPacket *out)
+{
+AV1FSplitContext *s = ctx->priv_data;
+CodedBitstreamFragment *td = >temporal_unit;
+int i, ret;
+int split = !!s->buffer_pkt->data;
+
+if (!s->buffer_pkt->data) {
+int nb_frames = 0;
+
+ret = ff_bsf_get_packet_ref(ctx, s->buffer_pkt);
+if (ret < 0)
+return ret;
+
+ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
+if (ret < 0) {
+av_log(ctx, AV_LOG_WARNING, "Failed to parse temporal unit.\n");
+goto passthrough;
+}
+
+for (i = 0; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = >units[i];
+
+if (unit->type == AV1_OBU_FRAME ||
+unit->type == AV1_OBU_FRAME_HEADER)
+nb_frames++;
+else if (unit->type == AV1_OBU_TILE_LIST) {
+av_log(ctx, AV_LOG_VERBOSE, "Large scale tiles are 
unsupported.\n");
+goto passthrough;
+}
+}
+if (nb_frames > 1) {
+s->cur_frame = 0;
+s->cur_frame_idx = s->last_frame_idx = 0;
+s->nb_frames = nb_frames;
+split = 1;
+}
+}
+
+if (split) {
+AV1RawFrameHeader *frame = NULL;
+int cur_frame_type = -1, size = 0;
+
+for (i = s->cur_frame_idx; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = >units[i];
+
+size += unit->data_size;
+if (unit->type == AV1_OBU_FRAME) {
+AV1RawOBU *obu = unit->content;
+
+if (frame) {
+av_log(ctx, AV_LOG_WARNING, "Frame OBU found when Tile 
data for a "
+"previous frame was 
expected.\n");
+goto passthrough;
+}
+
+

Re: [FFmpeg-devel] [PATCH v3 1/1] lavc/h264_levels: add MaxMBPS checking and update fate test.

[Mark Thompson]

On 20/03/2019 09:14, Decai Lin wrote:
> 1. add MaxMBPS checking for level idc setting to align with AVC spec
>AnnexA table A-1/A-6 level limits.
> 2. update h264 level fate test.
> 
> Signed-off-by: Decai Lin 
> ---
>  libavcodec/h264_levels.c   |  4 +++
>  libavcodec/h264_levels.h   |  1 +
>  libavcodec/h264_metadata_bsf.c |  9 ++-
>  libavcodec/tests/h264_levels.c | 58 
> +++---
>  libavcodec/vaapi_encode_h264.c |  7 +
>  5 files changed, 75 insertions(+), 4 deletions(-)
> 
> ...
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index a17987a..0f6ce26 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -223,6 +223,7 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>  const H264LevelDescriptor *desc;
>  int64_t bit_rate;
>  int width, height, dpb_frames;
> +int framerate;
>  
>  if (sps->vui.nal_hrd_parameters_present_flag) {
>  bit_rate = 
> (sps->vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) *
> @@ -244,7 +245,13 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>  height = 16 * (sps->pic_height_in_map_units_minus1 + 1) *
>  (2 - sps->frame_mbs_only_flag);
>  
> -desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> +if (sps->vui.timing_info_present_flag) {
> +framerate = sps->vui.time_scale / sps->vui.num_units_in_tick;

This calculated number is the fieldrate, not the framerate.  I fixed that by 
adding the missing factor 2.

> +} else {
> +framerate = 0;
> +}
> +
> +desc = ff_h264_guess_level(sps->profile_idc, bit_rate, framerate,
> width, height, dpb_frames);
>  if (desc) {
>  level_idc = desc->level_idc;

LGTM with that, and applied.

Thanks,

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/hevcdec: Fix return code for explode mode

[Michael Niedermayer]

On Sun, Mar 24, 2019 at 11:17:37AM -0300, James Almer wrote:
> On 3/24/2019 7:55 AM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevcdec.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index fe4b5fdb5b..b7e2d68f5e 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -2923,6 +2923,7 @@ static int decode_nal_unit(HEVCContext *s, const 
> > H2645NAL *nal)
> >  return ret;
> >  if (ret == 1) {
> >  av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
> > first in the same frame.\n");
> > +ret = AVERROR_INVALIDDATA;
> >  goto fail;
> >  }
> 
> I'd prefer if you squash all the patches before pushing, with or without
> my suggested changes for patch 1/2.

changed and new patch posted
will apply after sleeping a few hours if there are no suggestions for
more changes by then

thx

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

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


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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/hevcdec: Avoid only partly skiping duplicate first slices

[Michael Niedermayer]

Fixes: NULL pointer dereference and out of array access
Fixes: 
13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
Fixes: 
13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5650370728034304

This also fixes the return code for explode mode

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

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 86adab0ae1..857c10dd12 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -488,6 +488,11 @@ static int hls_slice_header(HEVCContext *s)
 
 // Coded parameters
 sh->first_slice_in_pic_flag = get_bits1(gb);
+if (s->ref && sh->first_slice_in_pic_flag) {
+av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the first 
in the same frame.\n");
+return 1; // This slice will be skiped later, do not corrupt state
+}
+
 if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
 s->seq_decode = (s->seq_decode + 1) & 0xff;
 s->max_ra = INT_MAX;
@@ -2918,6 +2923,11 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 ret = hls_slice_header(s);
 if (ret < 0)
 return ret;
+if (ret == 1) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
 
 if (
 (s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == 
HEVC_SLICE_B) ||
@@ -2927,10 +2937,6 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 }
 
 if (s->sh.first_slice_in_pic_flag) {
-if (s->ref) {
-av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
first in the same frame.\n");
-goto fail;
-}
 if (s->max_ra == INT_MAX) {
 if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
 s->max_ra = s->poc;
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/truemotion2: Fix integer overflow in tm2_decode_blocks()

[Michael Niedermayer]

Fixes: signed integer overflow: 255 + 2147483634 cannot be represented in type 
'int'
Fixes: 
13472/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5712444142387200

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

diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index 18719dae1c..100880c257 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -837,7 +837,7 @@ static int tm2_decode_blocks(TM2Context *ctx, AVFrame *p)
 dst = p->data[0];
 for (j = 0; j < h; j++) {
 for (i = 0; i < w; i++) {
-int y = Y[i], u = U[i >> 1], v = V[i >> 1];
+unsigned y = Y[i], u = U[i >> 1], v = V[i >> 1];
 dst[3*i+0] = av_clip_uint8(y + v);
 dst[3*i+1] = av_clip_uint8(y);
 dst[3*i+2] = av_clip_uint8(y + u);
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Carl Eugen Hoyos]

2019-03-26 23:44 GMT+01:00, Mark Thompson :

> * Run exhaustively in tsan/valgrind/other race detectors and fix every
> problem it finds, then provide evidence from that to help with review.

In addition to issues you mention, I wonder if this wouldn't trigger
many unresolved issues in existing (library) code, making the
task even more difficult.

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

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

[FFmpeg-devel] [PATCH] configure: Do not enable both OpenCL-VAAPI interop modes simultaneously

[Mark Thompson]

Beignet offers a far more flexiable and complete interface, so choose it
by default if available.
---
On 23/03/2019 12:27, Mark Thompson wrote:
> On 22/03/2019 01:40, Ruiling Song wrote:
>> ffmpeg | branch: master | Ruiling Song  | Fri Nov 23 
>> 13:39:12 2018 +0800| [61cb505d18b8a335bd118d88c05b9daf40eb5f9b] | committer: 
>> Ruiling Song
>>
>> lavu/opencl: replace va_ext.h with standard name
>>
>> Khronos OpenCL header (https://github.com/KhronosGroup/OpenCL-Headers)
>> uses cl_va_api_media_sharing_intel.h. And Intel's official OpenCL driver
>> for Intel GPU (https://github.com/intel/compute-runtime) was compiled
>> against Khronos OpenCL header. So it's better to align with Khronos.
>>
>> Signed-off-by: Ruiling Song 
>>
>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=61cb505d18b8a335bd118d88c05b9daf40eb5f9b
>> ---
>>
>>  configure| 2 +-
>>  libavutil/hwcontext_opencl.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index a817479559..331393f8d5 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6472,7 +6472,7 @@ fi
>>  
>>  if enabled_all opencl vaapi ; then
>>  enabled opencl_drm_beignet && enable opencl_vaapi_beignet
>> -check_type "CL/cl.h CL/va_ext.h" 
>> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
>> +check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h" 
>> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
>>  enable opencl_vaapi_intel_media
>>  fi
>>  
>> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
>> index d3df6221c4..b116c5b708 100644
>> --- a/libavutil/hwcontext_opencl.c
>> +++ b/libavutil/hwcontext_opencl.c
>> @@ -50,7 +50,7 @@
>>  #include 
>>  #endif
>>  #include 
>> -#include 
>> +#include 
>>  #include "hwcontext_vaapi.h"
>>  #endif
>>  
> 
> This broke the build when both are available.
> 
> $ make
> CC  libavutil/hwcontext_opencl.o
> src/libavutil/hwcontext_opencl.c: In function ‘opencl_device_derive’:
> src/libavutil/hwcontext_opencl.c:1236:5: error: duplicate case value
>  case AV_HWDEVICE_TYPE_VAAPI:
>  ^~~~
> src/libavutil/hwcontext_opencl.c:1205:5: note: previously used here
>  case AV_HWDEVICE_TYPE_VAAPI:
>  ^~~~
> src/libavutil/hwcontext_opencl.c: In function ‘opencl_map_to’:
> src/libavutil/hwcontext_opencl.c:2831:5: error: duplicate case value
>  case AV_PIX_FMT_VAAPI:
>  ^~~~
> src/libavutil/hwcontext_opencl.c:2825:5: note: previously used here
>  case AV_PIX_FMT_VAAPI:
>  ^~~~
> src/libavutil/hwcontext_opencl.c: In function ‘opencl_frames_derive_to’:
> src/libavutil/hwcontext_opencl.c:2873:5: error: duplicate case value
>  case AV_HWDEVICE_TYPE_VAAPI:
>  ^~~~
> src/libavutil/hwcontext_opencl.c:2866:5: note: previously used here
>  case AV_HWDEVICE_TYPE_VAAPI:
>  ^~~~
> make: *** [ffbuild/common.mak:60: libavutil/hwcontext_opencl.o] Error 1
> make: Target 'all' not remade because of errors.
> 
> $ cat config.h | grep HAVE_OPENCL
> #define HAVE_OPENCL_D3D11 0
> #define HAVE_OPENCL_DRM_ARM 0
> #define HAVE_OPENCL_DRM_BEIGNET 1
> #define HAVE_OPENCL_DXVA2 0
> #define HAVE_OPENCL_VAAPI_BEIGNET 1
> #define HAVE_OPENCL_VAAPI_INTEL_MEDIA 1
> 
> 
> I think in general the Beignet mapping is more useful if present since it has 
> far fewer constraints, so perhaps disable this one if Beignet is there?

 configure | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 331393f8d5..c94f516224 100755
--- a/configure
+++ b/configure
@@ -6471,9 +6471,12 @@ if enabled_all opencl libdrm ; then
 fi
 
 if enabled_all opencl vaapi ; then
-enabled opencl_drm_beignet && enable opencl_vaapi_beignet
-check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h" 
"clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
-enable opencl_vaapi_intel_media
+if enabled opencl_drm_beignet ; then
+enable opencl_vaapi_beignet
+else
+check_type "CL/cl.h CL/cl_va_api_media_sharing_intel.h" 
"clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
+enable opencl_vaapi_intel_media
+fi
 fi
 
 if enabled_all opencl dxva2 ; then
-- 
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Mark Thompson]

On 26/03/2019 22:07, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
> 
> ...
> ---
> The patch will only effect on multiple SIMPLE filter graphs pipeline,
> Passed fate and refine the possible data race,
> AFL tested, without introducing extra crashs/hangs
> 
>  fftools/ffmpeg.c | 172 
> +--
>  fftools/ffmpeg.h |  13 +
>  2 files changed, 169 insertions(+), 16 deletions(-)

On further thought, I don't think this patch should continue in its present 
form.

The fundamental problem is that the bolted-on parallelism renders it pretty 
much unreviewable - the codebase here was not designed with any parallelism in 
mind, so it does not follow the usual rules expected of such code.  In 
particular, there are global variables in many places accessed without regard 
for data races, and that becomes fatal undefined behaviour once parallelism is 
added.  While in theory every one of those can be fixed (by adding more locks, 
or one big lock covering many instances together), it will be very hard to 
verify that all cases have been covered and the code will suffer significantly 
in readability/maintainability for the change.

To give an explicit example of the sort of problems you are hitting, the 
-benchmark_all option is entirely broken in the current proposed version.  It 
invokes undefined behaviour by writing to the current_time global in every 
thread.  Even if that were avoided by moving the value to a thread-local 
structure, it also gives wrong results - getrusage(RUSAGE_SELF) returns values 
for the whole process, so it won't say anything useful once there are multiple 
threads looking at the value in parallel.  Perhaps that is fixable by using 
some sort of per-thread storage and RUSAGE_THREAD (and some equivalent on 
Windows), but whatever that is certainly requires more investigation and 
probably a separate patch.

Three possible thoughts on where to go from here:

* Start by refactoring the code to make it easier to verify.  This would entail 
something like removing all global variable accesses from parallel paths, and 
then ensuring that each thread only ever writes to its own local working set 
(e.g. OutputStream structure) while marking all other structures as const.  
After such refactoring has happened, a new version of the present patch would 
then be possible to assess.

* Run exhaustively in tsan/valgrind/other race detectors and fix every problem 
it finds, then provide evidence from that to help with review.  Since these 
issues can be hidden behind specific option combinations (as the benchmark one 
is), this would need a lot of care to ensure full coverage, and some parts 
(like the benchmark one) would need rewriting anyway.  As noted above I'm not 
sure this would be very good for the code, but we could at least have some 
amount of confidence that the result was correct.

* Reconsider whether the patch is worth pursuing.  While I agree that a correct 
implementation of this would help in the specific use-cases you describe, I'm 
not sure that the set of users who gain from it is actually particularly large 
- most people wanting to maximise throughput in the way this change can help 
with already run multiple FFmpeg instances (or their own programs using the 
libraries) because the serial limitations of FFmpeg are well-known.


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 23:33 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
 Please elaborate.
>>> It seems I'm doing something wrong:
>>>
>>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
>> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -
> Thanks. With "-t 1000" it loops endless

Unlikely.

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>>> Please elaborate.
>> It seems I'm doing something wrong:
>>
>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -
Thanks. With "-t 1000" it loops endless, but it works fine with:

$ ffmpeg -f rawvideo -s 300x200 -i /dev/zero -vf ... -frames 1024 -f null -

-Ulf

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

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

[FFmpeg-devel] [PATCH 2/2] libavcodec/zmbvenc: add support for 24-bit encoding, using pix_fmt BGR24.

[Matthew Fearnley]

Support is #ifdef'd out at this stage, using ZMBV_ENABLE_24BPP (like in
the zmbv.c decoder)
---
 libavcodec/zmbvenc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 98029de5f6..48871758e0 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -340,6 +340,12 @@ static av_cold int encode_init(AVCodecContext *avctx)
 c->fmt = ZMBV_FMT_16BPP;
 c->bypp = 2;
 break;
+#ifdef ZMBV_ENABLE_24BPP
+case AV_PIX_FMT_BGR24:
+c->fmt = ZMBV_FMT_24BPP;
+c->bypp = 3;
+break;
+#endif //ZMBV_ENABLE_24BPP
 case AV_PIX_FMT_BGR0:
 c->fmt = ZMBV_FMT_32BPP;
 c->bypp = 4;
@@ -434,6 +440,9 @@ AVCodec ff_zmbv_encoder = {
 .pix_fmts   = (const enum AVPixelFormat[]) { AV_PIX_FMT_PAL8,
  AV_PIX_FMT_RGB555LE,
  AV_PIX_FMT_RGB565LE,
+#ifdef ZMBV_ENABLE_24BPP
+ AV_PIX_FMT_BGR24,
+#endif //ZMBV_ENABLE_24BPP
  AV_PIX_FMT_BGR0,
  AV_PIX_FMT_NONE },
 };
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/2] libavcodec/zmbv: change 24-bit decoder channel order, from RGB24 to BGR24

[Matthew Fearnley]

This brings the channel order in line with that used in 32-bit mode (BGR0).

24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and no
prior encoders or sample videos are known to exist for this bit depth, so
I consider this change in implementation is unlikely to affect anyone.

The decision has been made in agreement with the DOSBox Development Team
(dosbox.c...@gmail.com), specifically with harekiet, who wrote the original
codec.

Additional minor fix: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`.
Other bit depths saw this change in ced0d6c14d, but this instance was
missed, presumably because of the #ifdef block.
---
 libavcodec/zmbv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/zmbv.c b/libavcodec/zmbv.c
index e07009d0fb..898b62d065 100644
--- a/libavcodec/zmbv.c
+++ b/libavcodec/zmbv.c
@@ -303,7 +303,7 @@ static int zmbv_decode_xor_24(ZmbvContext *c)
 prev += stride * c->bh;
 }
 if (src - c->decomp_buf != c->decomp_len)
-av_log(c->avctx, AV_LOG_ERROR, "Used %i of %i bytes\n",
+av_log(c->avctx, AV_LOG_ERROR, "Used %"PTRDIFF_SPECIFIER" of %i 
bytes\n",
src-c->decomp_buf, c->decomp_len);
 return 0;
 }
@@ -473,7 +473,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame, AVPac
 c->bpp = 24;
 decode_intra = zmbv_decode_intra;
 c->decode_xor = zmbv_decode_xor_24;
-avctx->pix_fmt = AV_PIX_FMT_RGB24;
+avctx->pix_fmt = AV_PIX_FMT_BGR24;
 c->stride = c->width * 3;
 break;
 #endif //ZMBV_ENABLE_24BPP
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH] Fix loss of precision for silencedetect on large files

[Allan Cady via ffmpeg-devel]

When the silencedetect filter is run against very large files, the
output timestamps gradually lose precision as the scan proceeds
further into the file. This is because the output is formatted (in
libavutil/timestamp.h) as "%.6g", which limits the total field length.
Eventually, for offsets greater than 10 seconds (about 28 hours),
fractions of a second disappear altogether, and the timestamps
are logged as whole integers. This is insufficient precision for
my purposes.

I propose changing the format to "%.3f", which will give millisecond
precision for all timestamps regardless of offset.

Patch file is attached.

EXAMPLE

For a sample scan on a file that's about 35 hours (126000 seconds) length:

$ ffmpeg -i input.mp3 -filter_complex 
silencedetect=n=-30dB:d=3,ametadata=mode=print:file=silence-out.txt -f null -

The output looks like this near the beginning:

frame:83085 pts:47856431 pts_time:2170.36
lavfi.silence_start=2166.86
frame:83139 pts:47887535 pts_time:2171.77
lavfi.silence_end=2171.77
lavfi.silence_duration=4.91061

Further on we get this:

frame:2450348 pts:1411399919 pts_time:64009.1
lavfi.silence_start=64005.6
frame:2450371 pts:1411413167 pts_time:64009.7
lavfi.silence_end=64009.7
lavfi.silence_duration=4.10082

Eventually after it passes 10 seconds:

frame:4738029 pts:2729104175 pts_time:123769
lavfi.silence_start=123765
frame:4738055 pts:2729119151 pts_time:123770
lavfi.silence_end=123770
lavfi.silence_duration=4.17918

The start and end times are now in whole integers (seconds).

After making this patch and building the code myself, I now get this
output near the end:

frame:4738029 pts:2729104175 pts_time:123768.897
lavfi.silence_start=123765.411
frame:4738055 pts:2729119151 pts_time:123769.576
lavfi.silence_end=123769.584
lavfi.silence_duration=4.173

This gives me the output I want.

Thank you,

Allan Cady
Seattle WA


0001-Fix-loss-of-precision-for-silencedetect-on-large-fil.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 06:07:21PM -0400, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
> 
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)
> 
> For 1:N transcode by GPU acceleration with vaapi:
> ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
> -hwaccel_output_format vaapi \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
> -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null
> 
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved   6.1%6.9%   5.5%
> 
> For 1:N transcode by GPU acceleration with QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
> -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
> 
> test results:
> 2 encoders  5 encoders 10 encoders
> Improved   6%   4% 15%
> 
> For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null 
> /dev/null \
> -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null 
> /dev/null
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   12% 21%21%
> 
> For CPU only 1 decode to N scaling:
> ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
> -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   25%107%   148%
> 
> Signed-off-by: Wang, Shaofei 
> ---
> The patch will only effect on multiple SIMPLE filter graphs pipeline,
> Passed fate and refine the possible data race,
> AFL tested, without introducing extra crashs/hangs
> 
>  fftools/ffmpeg.c | 172 
> +--
>  fftools/ffmpeg.h |  13 +
>  2 files changed, 169 insertions(+), 16 deletions(-)

this still fails with some (fuzzed) samples
valgrind does not seem to produce much usefull though
...
Error while decoding stream #0:0: Invalid data found when processing input
[rv40 @ 0x25829f40] marking unfished frame as finished
[rv40 @ 0x25829f40] concealing 27 DC, 27 AC, 27 MV errors in B frame
[rv40 @ 0x2584f000] Slice indicates MB offset 142, got 140
[rv40 @ 0x2584f000] Dquant for P-frame
[rv40 @ 0x2584f000] concealing 2 DC, 2 AC, 2 MV errors in P frame
Error while decoding stream #0:0: Invalid data found when processing input
[rv40 @ 0x256dfb40] Slice indicates MB offset 140, got 135
[rv40 @ 0x256dfb40] concealing 5 DC, 5 AC, 5 MV errors in B frame
[rv40 @ 0x25701940] concealing 112 DC, 112 AC, 112 MV errors in P frame
Error while decoding stream #0:0: Invalid data found when processing input=N/A  
  
Last message repeated 1 times
[rv40 @ 0x25804e80] First slice header is incorrect
[rv40 @ 0x256dfb40] Slice indicates MB offset 187, got 140
[rv40 @ 0x256dfb40] Dquant for P-frame
[rv40 @ 0x256dfb40] concealing 47 DC, 47 AC, 47 MV errors in P frame
[rv40 @ 0x25726a00] Dquant for B-frame
[rv40 @ 0x25770b80] concealing 115 DC, 115 AC, 115 MV errors in P frame
Error while decoding stream #0:0: Invalid data found when processing input=N/A  
  
[rv40 @ 0x25804e80] Dquant for P-frame
[rv40 @ 0x257dfdc0] Dquant for P-framee=-577014:32:22.77 bitrate=N/A speed=N/A  
  
[rv40 @ 0x25804e80] Dquant for B-frame
Too many packets buffered for output stream 0:0.
pthread_join failed with error: Resource deadlock avoided

gdb output:
pthread_join failed with error: Resource deadlock avoided

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe4def700 (LWP 13350)]
0x7fffefeaec37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
Python Exception  No module named gdb.frames: 
#0  0x7fffefeaec37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fffefeb2028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0042bea1 in strict_pthread_join (thread=140737033205504, 
value_ptr=0x0) at ./libavutil/thread.h:55
#3  0x0042d342 in ffmpeg_cleanup (ret=1) at fftools/ffmpeg.c:526
#4  0x004250d8 in exit_program (ret=1) at fftools/cmdutils.c:139
#5  0x0042dfd4 in write_packet (of=0x231b780, pkt=0x7fffe4dee680, 
ost=0x237f680, unqueue=0) at fftools/ffmpeg.c:738
#6  0x0042eb39 in output_packet (of=0x231b780, pkt=0x7fffe4dee680, 
ost=0x237f680, eof=0) at fftools/ffmpeg.c:903
#7  0x00430c30 in do_video_out (of=0x231b780, ost=0x237f680, 

Re: [FFmpeg-devel] [PATCH v2] swscale: Remove duplicated code

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 08:58:34AM +0200, Lauri Kasanen wrote:
> In this function, the exact same clamping happens both in the if and 
> unconditionally.
> 
> Signed-off-by: Lauri Kasanen 
> ---
>  libswscale/output.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> v2: Remove the unconditional instead of the if'd clipping.
> I'll leave changing the bit pattern to others, there's so many funcs using 
> 0x100.
> 
> diff --git a/libswscale/output.c b/libswscale/output.c
> index d7c53e6..d3401f0 100644
> --- a/libswscale/output.c
> +++ b/libswscale/output.c

should be ok

thanks

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

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

[FFmpeg-devel] [PATCH 0/1] avformat/dashenc: Prevent writing manifest files multiple times

[joepadmiraal]

When using multiple output streams the playlists are written for each video 
output.
For example when we have 3 video qualities, the playlists are written 3 times 
per segement duration.
I would expect each playlist to be written exactly once per segment duration.
I created a little patch that waits until all streams are flushed before 
writing the playlists.
Please review and let me know if something needs to change.

Regards,
Joep Admiraal

joepadmiraal (1):
  Prevent writing manifest files multiple times

 libavformat/dashenc.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

--
2.17.0

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

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

[FFmpeg-devel] [PATCH 1/1] Prevent writing manifest files multiple times

[joepadmiraal]

---
 libavformat/dashenc.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1b74bce060..e4f7843e03 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -144,6 +144,8 @@ typedef struct DASHContext {
 int ignore_io_errors;
 int lhls;
 int master_publish_rate;
+int nr_of_streams_to_flush;
+int nr_of_streams_flushed;
 } DASHContext;
 
 static struct codec_string {
@@ -1079,6 +1081,7 @@ static int dash_init(AVFormatContext *s)
 char *ptr;
 char basename[1024];
 
+c->nr_of_streams_to_flush = 0;
 if (c->single_file_name)
 c->single_file = 1;
 if (c->single_file)
@@ -1274,12 +1277,18 @@ static int dash_init(AVFormatContext *s)
 os->max_pts = AV_NOPTS_VALUE;
 os->last_dts = AV_NOPTS_VALUE;
 os->segment_index = 1;
+
+if (s->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
+c->nr_of_streams_to_flush++;
 }
 
 if (!c->has_video && c->seg_duration <= 0) {
 av_log(s, AV_LOG_WARNING, "no video stream and no seg duration set\n");
 return AVERROR(EINVAL);
 }
+
+c->nr_of_streams_flushed = 0;
+
 return 0;
 }
 
@@ -1565,8 +1574,14 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 }
 }
 
-if (ret >= 0)
+if (ret >= 0) {
+c->nr_of_streams_flushed++;
+if (c->nr_of_streams_flushed != c->nr_of_streams_to_flush)
+return ret;
+
+c->nr_of_streams_flushed = 0;
 ret = write_manifest(s, final);
+}
 return ret;
 }
 
-- 
2.17.0

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec Adding ff_v210_planar_unpack AVX2

[Mike Stoner via ffmpeg-devel]

Hello,
I’ve accounted for all feedback on this so far, I’m wondering if it is ready to 
be pushed upstream?

Here are my results from ‘checkasm’ (lower is better):

v210_unpack_c: 1636
v210_unpack_ssse3: 611
v210_unpack_avx: 601
v210_unpack_avx2: 423

I ran it 5 times and averaged the middle 3 results for each CPU target 
(ignoring the highest and lowest time).

https://patchwork.ffmpeg.org/patch/12325/


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

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

Re: [FFmpeg-devel] [PATCH]lavc/bmp: Avoid a heap buffer overwrite for 1bpp

[Carl Eugen Hoyos]

2019-03-26 20:51 GMT+01:00, Michael Niedermayer :
> On Tue, Mar 26, 2019 at 01:38:14PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch intends to fix a buffer overwrite reported today.
>>
>> Please comment, Carl Eugen
>
>>  bmp.c |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> ab9b89481fc3c93d4a631fb1d6b25dddbdd4bb50
>> 0001-lavc-bmp-Avoid-a-heap-buffer-overwrite-for-1bpp-inpu.patch
>> From bd0dfa740f879eca6b13bb841e3b8d37718460ea Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Tue, 26 Mar 2019 13:32:11 +0100
>> Subject: [PATCH] lavc/bmp: Avoid a heap buffer overwrite for 1bpp input.
>>
>> Found by Mingi Cho, Seoyoung Kim, and Taekyoung Kwon
>> of the Information Security Lab, Yonsei University.
>> ---
>>  libavcodec/bmp.c |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> LGTM

Patch applied.

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

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

Re: [FFmpeg-devel] [PATCH]lavc/bmp: Avoid a heap buffer overwrite for 1bpp

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 01:38:14PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch intends to fix a buffer overwrite reported today.
> 
> Please comment, Carl Eugen

>  bmp.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> ab9b89481fc3c93d4a631fb1d6b25dddbdd4bb50  
> 0001-lavc-bmp-Avoid-a-heap-buffer-overwrite-for-1bpp-inpu.patch
> From bd0dfa740f879eca6b13bb841e3b8d37718460ea Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Tue, 26 Mar 2019 13:32:11 +0100
> Subject: [PATCH] lavc/bmp: Avoid a heap buffer overwrite for 1bpp input.
> 
> Found by Mingi Cho, Seoyoung Kim, and Taekyoung Kwon
> of the Information Security Lab, Yonsei University.
> ---
>  libavcodec/bmp.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

LGTM

thx

[...]

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

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

Re: [FFmpeg-devel] scaling option

[Dennis Mungai]

On Tue, Mar 26, 2019, 21:20 Yufei He  wrote:

> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> > On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
> >
> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> >> On 26/03/2019 13:47, Yufei He wrote:
> >> Hi
> >>
> >> Is there option for scaling on transcoding ?
> >>
> >> e.g. transcoding from a quadhd file to 640 * 480.
> >>
> >> Thanks.
> >>
> >> Yufei.
> >>
> >>
> >> Yes there is, but this is ffmpeg-devel, so not the place to ask user
> >> questions.
> >>
> >> Yes, I see the option of -vf scale=width:height
> >> We can do scaling on decoding or encoding, my question was to check if
> >> there is scaling option for codec.
> >> I'll add special scaling option to our codec.
> >>
> >>
> > Hello there,
> >
> > Scaling comes in two forms (correct me if I'm wrong):
> >
> > 1. Specific video filters, such as the scale filters, and other
> > hardware-accelerated implementations, such as scale_npp, scale_cuda,
> > scale_vaapi, etc.
> > 2. Decoders (Not too sure if equating the private -resize option provided
> > by these decoders is equivalent to "scaling"):
> >
> > See the example provided by the likes of the cuvid implementations, such
> as
> > h264_cuvid, etc:
> >
> > ffmpeg -h decoder=h264_cuvid
> >
> > The -resize option therein acts as a scaler.
> >
> > Are you planning to implement a codec-specific hardware (or
> software-based)
> > scaler (implemented as a video filter or a decoder), with similar
> > functionality?
> Hi Dennis
> Our hardware m264 supports scaling and encoding or decoding at the same
> time, this saves memory copy time between host and card if it's scaled
> in host or in other separate filter.
> I'm trying to make it work in FFmpeg.
>
> Yufei.
>


Here's what you'll need to implement:

1. A hwaccel of the type equivalent to the accelerator backend you're
creating, and

2. The actual hwaccel implementation. This will be an encoder (or set of
encoders) targeting the codecs you're after.

3. Based on the two above, create video filters that can take advantage of
hwupload, hwdownload, etc to create filter chains that will allow to move
(and map) textures, etc from system to device memory . Take a look at how
CUDA based hwaccels are implemented. That's a good crash course on what
needs to be done.

4. Understand how the FFmpeg development process works. Patches are
welcome, but the review process and adherence to coding standards matters
even more. See the wikis on what's expected regarding the development
process. I'd suggest being aware of the subsystem maintainers and the roles
they play.

5. On vendor specific libraries: I'd suggest releasing this as an open
implementation such that it can be hosted in a manner similar to how the
ffnvcodec headers are handled. Trust me, you'll greatly lower the
maintainance overhead on time.

Hope that helps.

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

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

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
>
>> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> On 26/03/2019 13:47, Yufei He wrote:
>> Hi
>>
>> Is there option for scaling on transcoding ?
>>
>> e.g. transcoding from a quadhd file to 640 * 480.
>>
>> Thanks.
>>
>> Yufei.
>>
>>
>> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> questions.
>>
>> Yes, I see the option of -vf scale=width:height
>> We can do scaling on decoding or encoding, my question was to check if
>> there is scaling option for codec.
>> I'll add special scaling option to our codec.
>>
>>
> Hello there,
>
> Scaling comes in two forms (correct me if I'm wrong):
>
> 1. Specific video filters, such as the scale filters, and other
> hardware-accelerated implementations, such as scale_npp, scale_cuda,
> scale_vaapi, etc.
> 2. Decoders (Not too sure if equating the private -resize option provided
> by these decoders is equivalent to "scaling"):
>
> See the example provided by the likes of the cuvid implementations, such as
> h264_cuvid, etc:
>
> ffmpeg -h decoder=h264_cuvid
>
> The -resize option therein acts as a scaler.
>
> Are you planning to implement a codec-specific hardware (or software-based)
> scaler (implemented as a video filter or a decoder), with similar
> functionality?
Hi Dennis
Our hardware m264 supports scaling and encoding or decoding at the same 
time, this saves memory copy time between host and card if it's scaled 
in host or in other separate filter.
I'm trying to make it work in FFmpeg.

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Paul B Mahol]

On 3/26/19, Ulf Zibis  wrote:
>
> Am 26.03.19 um 17:39 schrieb Carl Eugen Hoyos:
>>
>>> 1.) There may be a shortcut in CPU architecture for copying nulls in
>>> series (fillborders.c essentially does that) and more important ...
>> I am curious:
>> Which architecture are you thinking about that interprets
>> FFmpeg's inner structure?
> I was inspired of your suspicion. ;-) From Java code I know, that such
> things happen as cause of the JIT "just in time compiler" optimization,
> don't know, if modern C compilers assemble similar effects.
>
>>> 2.) Additionally I want to test on different ...
>>> - number of planes
>>> - color model /resolution
>>> - bit depth
>> Use the input option -pix_fmt
>
> Ok, I'll look on that.
>
> And I'm still curious to read something on my initial question
> (following your suggestion from 19.03.19, 17:31 CET to use "-loop"):
> ... I ask, because I want to understand the purpose of the shorter
> options "-loop number" and "-stream_loop number" (or how to apply them
> correctly in the command line to get the wanted effect on single picture
> input).

If you want to work on ffmpeg, you certainly need to learn how to use.
You showed very little skills.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 17:39 schrieb Carl Eugen Hoyos:
>
>> 1.) There may be a shortcut in CPU architecture for copying nulls in
>> series (fillborders.c essentially does that) and more important ...
> I am curious:
> Which architecture are you thinking about that interprets
> FFmpeg's inner structure?
I was inspired of your suspicion. ;-) From Java code I know, that such
things happen as cause of the JIT "just in time compiler" optimization,
don't know, if modern C compilers assemble similar effects.

>> 2.) Additionally I want to test on different ...
>> - number of planes
>> - color model /resolution
>> - bit depth
> Use the input option -pix_fmt

Ok, I'll look on that.

And I'm still curious to read something on my initial question
(following your suggestion from 19.03.19, 17:31 CET to use "-loop"):
... I ask, because I want to understand the purpose of the shorter
options "-loop number" and "-stream_loop number" (or how to apply them
correctly in the command line to get the wanted effect on single picture
input).

-Ulf

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 17:36 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 17:20 schrieb Carl Eugen Hoyos:
>> 2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>>
>>> I'm trying to benchmark -vf fillborders (added the timer
>>> code in vf_fillborders.c), so Carl Eugen's suggestion
>>> to use /dev/zero as input would not make sense.
>> Please elaborate.
> It seems I'm doing something wrong:
>
> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
 $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -

 It may be that the performance of the filter cannot be
 tested like this, I don't know.
>>> I suspect, you are right on not suitable for performance test.
>> (I did not claim that, on the contrary.)
>> Why not?

> 1.) There may be a shortcut in CPU architecture for copying nulls in
> series (fillborders.c essentially does that) and more important ...

I am curious:
Which architecture are you thinking about that interprets
FFmpeg's inner structure?

> 2.) Additionally I want to test on different ...
> - number of planes
> - color model /resolution
> - bit depth

Use the input option -pix_fmt

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 17:20 schrieb Carl Eugen Hoyos:
> 2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>>> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
 Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>
>> I'm trying to benchmark -vf fillborders (added the timer
>> code in vf_fillborders.c), so Carl Eugen's suggestion
>> to use /dev/zero as input would not make sense.
> Please elaborate.
 It seems I'm doing something wrong:

 ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
 -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
>>> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -
>>>
>>> It may be that the performance of the filter cannot be
>>> tested like this, I don't know.
>> I suspect, you are right on not suitable for performance test.
> (I did not claim that, on the contrary.)
> Why not?
1.) There may be a shortcut in CPU architecture for copying nulls in
series (fillborders.c essentially does that) and more important ...
2.) Additionally I want to test on different ...
- number of planes
- color model /resolution
- bit depth

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 17:17 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
>> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
 2019-03-26 15:56 GMT+01:00, Ulf Zibis :

> I'm trying to benchmark -vf fillborders (added the timer
> code in vf_fillborders.c), so Carl Eugen's suggestion
> to use /dev/zero as input would not make sense.
 Please elaborate.
>>> It seems I'm doing something wrong:
>>>
>>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
>> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -
>>
>> It may be that the performance of the filter cannot be
>> tested like this, I don't know.

> I suspect, you are right on not suitable for performance test.

(I did not claim that, on the contrary.)
Why not?

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos:
> 2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>>>
 I'm trying to benchmark -vf fillborders (added the timer
 code in vf_fillborders.c), so Carl Eugen's suggestion
 to use /dev/zero as input would not make sense.
>>> Please elaborate.
>> It seems I'm doing something wrong:
>>
>> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
>> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -
> $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -
>
> It may be that the performance of the filter cannot be
> tested like this, I don't know.

Thanks for your help!

I suspect, you are right on not suitable for performance test.
... and for sure not for algorithmic tests.

Unfortunately my initial question is still open:
... but I ask, because I want to understand the purpose of the shorter
options "-loop number" and "-stream_loop number" (or how to apply them
correctly in the command line to get the wanted effect).

-Ulf

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 17:09 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:34 schrieb Carl Eugen Hoyos:
>> 2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>>> Am 26.03.19 um 16:00 schrieb Nicolas George:
 Using the "color" filter source may be a little more
 efficient, and is much more convenient.
>>> With
>>> ffplay -f lavfi color=green
>>> I only see a monotone picture. This is not apropriate
>>> to test the fillborders filter with mode=mirror.
>> Why not?
> Well, it may be good for the performance test

I was under the impression that we exchanged all
these emails today only because you still hadn't
found a way to measure the performance of your
patch.
I hoped you had already tested the functional
correctness.

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:34 schrieb Carl Eugen Hoyos:
> 2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>> Am 26.03.19 um 16:00 schrieb Nicolas George:
>>> Using the "color" filter source may be a little more
>>> efficient, and is much more convenient.
>> With
>> ffplay -f lavfi color=green
>> I only see a monotone picture. This is not apropriate
>> to test the fillborders filter with mode=mirror.
> Why not?
Well, it may be good for the performance test, but can't test the
algorithmic correctness of the tweaked vf_fillborders.c code.
Additionally I want to test on different ...
- number of planes
- color model
- bit depth

-Ulf


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

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

Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode GPU copy sample

[Michael Niedermayer]

On Tue, Mar 26, 2019 at 01:39:49PM +0800, Linjie Fu wrote:
> Usage is:
>   ./qsvdec_gpucopy on/off input_stream output_stream
> 
> For example:
>  - enable/disable gpu copy:
>   ./qsvdec_gpucopy on input.h264 output.yuv
>   ./qsvdec_gpucopy off input.h264 output.yuv
> 
> Generate fps per second.
> 
> Signed-off-by: Linjie Fu 
> ---
>  configure |   2 +
>  doc/examples/Makefile |   1 +
>  doc/examples/qsvdec_gpucopy.c | 276 ++
>  3 files changed, 279 insertions(+)
>  create mode 100644 doc/examples/qsvdec_gpucopy.c

breaks examples build on arm

In file included from src/doc/examples/qsvdec_gpucopy.c:43:0:
src/libavcodec/qsv.h:24:26: fatal error: mfx/mfxvideo.h: No such file or 
directory
compilation terminated.
make: *** [doc/examples/qsvdec_gpucopy.o] Error 1
make: *** Waiting for unfinished jobs


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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:26 schrieb Nicolas George:
>
> Try testsrc2.
Bad news:

ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b testsrc2 -loop 1024 -vf
fillborders=25:25:25:25:mirror -f null -
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
[NULL @ 0x5636e78ba900] Unable to find a suitable output format for
'testsrc2'
testsrc2: Invalid argument
ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -f lavfi testsrc2 -loop
1024 -vf fillborders=25:25:25:25:mirror -f null -
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
[NULL @ 0x564b7e1fb940] Requested output format 'lavfi' is not a
suitable output format
testsrc2: Invalid argument

Anyway this test video is not really appropriate for my tests with
fillborders filter:
1.) The edges are mostly monotone, so I would hardly see an effect after
mirroring the borders
2.) I still want to see the performance on single pictures.

-Ulf

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 16:23 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:00 schrieb Nicolas George:
>> Using the "color" filter source may be a little more
>> efficient, and is much more convenient.
> With
> ffplay -f lavfi color=green
> I only see a monotone picture. This is not apropriate
> to test the fillborders filter with mode=mirror.

Why not?

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 16:28 GMT+01:00, Ulf Zibis :
>
> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>>
>>> I'm trying to benchmark -vf fillborders (added the timer
>>> code in vf_fillborders.c), so Carl Eugen's suggestion
>>> to use /dev/zero as input would not make sense.
>> Please elaborate.
>
> It seems I'm doing something wrong:
>
> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024
> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null -

$ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t 1000 -f null -

It may be that the performance of the filter cannot be
tested like this, I don't know.

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

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

Re: [FFmpeg-devel] scaling option

[Dennis Mungai]

On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:

> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> On 26/03/2019 13:47, Yufei He wrote:
> Hi
>
> Is there option for scaling on transcoding ?
>
> e.g. transcoding from a quadhd file to 640 * 480.
>
> Thanks.
>
> Yufei.
>
>
> Yes there is, but this is ffmpeg-devel, so not the place to ask user
> questions.
>
> Yes, I see the option of -vf scale=width:height
> We can do scaling on decoding or encoding, my question was to check if
> there is scaling option for codec.
> I'll add special scaling option to our codec.
>
>
Hello there,

Scaling comes in two forms (correct me if I'm wrong):

1. Specific video filters, such as the scale filters, and other
hardware-accelerated implementations, such as scale_npp, scale_cuda,
scale_vaapi, etc.
2. Decoders (Not too sure if equating the private -resize option provided
by these decoders is equivalent to "scaling"):

See the example provided by the likes of the cuvid implementations, such as
h264_cuvid, etc:

ffmpeg -h decoder=h264_cuvid

The -resize option therein acts as a scaler.

Are you planning to implement a codec-specific hardware (or software-based)
scaler (implemented as a video filter or a decoder), with similar
functionality?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Nicolas George]

Ulf Zibis (12019-03-26):
> It seems I'm doing something wrong:
> 
> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024 -i
> /dev/zero -vf fillborders=25:25:25:25:mirror -f null -

Obviously. Please stop putting options randomly together and wasting
everybody's time when they do not work. Instead take the necessary time
to learn how ffmpeg works.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos:
> 2019-03-26 15:56 GMT+01:00, Ulf Zibis :
>
>> I'm trying to benchmark -vf fillborders (added the timer
>> code in vf_fillborders.c), so Carl Eugen's suggestion
>> to use /dev/zero as input would not make sense.
> Please elaborate.

It seems I'm doing something wrong:

ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024 -i
/dev/zero -vf fillborders=25:25:25:25:mirror -f null -
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
/dev/zero: Invalid data found when processing input
ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -i /dev/zero -loop 1024
-vf fillborders=25:25:25:25:mirror -f null -
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
/dev/zero: Invalid data found when processing input

-Ulf

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Nicolas George]

Ulf Zibis (12019-03-26):
> With
> ffplay -f lavfi color=green
> I only see a monotone picture. This is not apropriate to test the
> fillborders filter with mode=mirror.

Ok. Then it is not suitable. And neither would be /dev/zero.

> Also yuvtestsrc is not really helpfull on that.

Try testsrc2.

And if it is satisfactory, prepare a rawvideo clip with a lightweight
muxer.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 16:00 schrieb Nicolas George:
> Using the "color" filter source may be a little more efficient, and is
> much more convenient.
With
ffplay -f lavfi color=green
I only see a monotone picture. This is not apropriate to test the
fillborders filter with mode=mirror.

Also yuvtestsrc is not really helpfull on that.

-Ulf


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

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

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
On 26/03/2019 13:47, Yufei He wrote:
Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.


Yes there is, but this is ffmpeg-devel, so not the place to ask user questions.

Yes, I see the option of -vf scale=width:height
We can do scaling on decoding or encoding, my question was to check if there is 
scaling option for codec.
I'll add special scaling option to our codec.




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

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 15:56 GMT+01:00, Ulf Zibis :

> I'm trying to benchmark -vf fillborders (added the timer
> code in vf_fillborders.c), so Carl Eugen's suggestion
> to use /dev/zero as input would not make sense.

Please elaborate.

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Nicolas George]

Ulf Zibis (12019-03-26):
> Again only 1 runs (also with "-stream_loop 1024").

You are obviously doing something wrong.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Nicolas George]

Ulf Zibis (12019-03-26):
> I'm trying to benchmark -vf fillborders (added the timer code in
> vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input
> would not make sense. I'll try with "-f null -".

Using the "color" filter source may be a little more efficient, and is
much more convenient.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 15:56 schrieb Ulf Zibis:
> I'm trying to benchmark -vf fillborders (added the timer code in
> vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input
> would not make sense. I'll try with "-f null -".

Again only 1 runs (also with "-stream_loop 1024").

-Ulf

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 15:48 schrieb Nicolas George:
> Ulf Zibis (12019-03-26):
>> Do you mean the following option? Unfortunately I still see only 1 run.
>>
>> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
>> ask, because I want to understand the purpose of the shorter option
>> "-loop number".
>>
>> ./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf
>> fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg
> Are you trying to benchmark the JPEG encoder? If not, do not use the
> JPEG encoder, use no encoder at all.
>
> Are you trying to benchmark the image2 muxer? If not, do not use the
> image2 muxer, use no muxer at all.
>
> Are you trying to benchmark the JPEG decoder? If not, do not use the
> JPEG decoder, use the "color" filter source, or, if the test requires
> non-trivial content to be relevant, prepare a rawvideo input.

Thanks for your hints.

I'm trying to benchmark -vf fillborders (added the timer code in
vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input
would not make sense. I'll try with "-f null -".

-Ulf


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Am 26.03.19 um 15:42 schrieb Ulf Zibis:
> Hi again,
>
> Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
>>>  122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>>> 1 runs,  0 skips
>> One run is not good.
>> Either use the loop option to filter the same frame again and
>> again or feed a video to ffmpeg.
> Do you mean the following option? Unfortunately I still see only 1 run.
>
> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
> ask, because I want to understand the purpose of the shorter option
> "-loop number".

Also  "-stream_loop 1024" doesn't work as I would expect.

-Ulf


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Nicolas George]

Ulf Zibis (12019-03-26):
> Do you mean the following option? Unfortunately I still see only 1 run.
> 
> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
> ask, because I want to understand the purpose of the shorter option
> "-loop number".
> 
> ./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf
> fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg

Are you trying to benchmark the JPEG encoder? If not, do not use the
JPEG encoder, use no encoder at all.

Are you trying to benchmark the image2 muxer? If not, do not use the
image2 muxer, use no muxer at all.

Are you trying to benchmark the JPEG decoder? If not, do not use the
JPEG decoder, use the "color" filter source, or, if the test requires
non-trivial content to be relevant, prepare a rawvideo input.

Most of all: use common sense!

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Carl Eugen Hoyos]

2019-03-26 15:42 GMT+01:00, Ulf Zibis :

> Do you mean the following option? Unfortunately I still see only 1 run.
>
> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
> ask, because I want to understand the purpose of the shorter option
> "-loop number".

> ./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf

loop is an input option, consider using rawvideo (possibly /dev/zero)
as input to increase performance (and reduce measurement error).

> fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg

and output to "-f null -".

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

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

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

[Ulf Zibis]

Hi again,

Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
>>  122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>> 1 runs,  0 skips
> One run is not good.
> Either use the loop option to filter the same frame again and
> again or feed a video to ffmpeg.

Do you mean the following option? Unfortunately I still see only 1 run.

I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I
ask, because I want to understand the purpose of the shorter option
"-loop number".

./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf
fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
Input #0, image2, from 'debug/8.jpg':
  Duration: 00:00:00.04, start: 0.00, bitrate: 39119 kb/s
    Stream #0:0: Video: mjpeg (Lossless), gray(bt470bg/unknown/unknown),
640x480 [SAR 96:96 DAR 4:3], lossless, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> mjpeg (native))
Press [q] to stop, [?] for help
[swscaler @ 0x560c9b036400] deprecated pixel format used, make sure you
did set range correctly
 968130 decicycles in fillborders=25:25:25:25:mirror 1p-8bit-0x0,  
1 runs,  0 skips
Output #0, image2, to 'debug/ZZ_8_mirror-25-25-25-25.jpg':
  Metadata:
    encoder : Lavf58.26.101
    Stream #0:0: Video: mjpeg, yuvj444p(pc), 640x480 [SAR 1:1 DAR 4:3],
q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
  encoder : Lavc58.47.105 mjpeg
    Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1
frame=    1 fps=0.0 q=6.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=1.69x   
video:34kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown

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

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

Re: [FFmpeg-devel] scaling option

[Timo Rothenpieler]

On 26/03/2019 13:47, Yufei He wrote:

Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.



Yes there is, but this is ffmpeg-devel, so not the place to ask user 
questions.





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

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

Re: [FFmpeg-devel] Added support for XV video files

[Michael Niedermayer]

On Mon, Mar 25, 2019 at 04:19:37PM +0530, Shivam Goyal wrote:
> 
> On 3/25/19 3:59 PM, Michael Niedermayer wrote:
> >On Sun, Mar 24, 2019 at 04:35:40PM +0530, Shivam Goyal wrote:
> >>The attached patch is for ticket #3720
> >>
> >>     https://trac.ffmpeg.org/ticket/3720
> >>
> >>I have tested this demuxer on the files 1.xv and 5.xv attached with the
> >>ticket
> >>
> >>http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3720/
> >>
> >>
> >>  It is working on both of these files.
> >>
> >>As XV video files are flv files with some encrypted data. These can be
> >>converted to flv without loosing video quality (and it would be really
> >>fast). I have also tried this and it is working "ffmpeg -i 1.xv -c copy
> >>converted.flv".
> >>
> >>
> >>Please suggest any improvements
> >>
> >>
> >[...]
> >
> >>diff --git a/libavformat/xvtools.h b/libavformat/xvtools.h
> >>new file mode 100644
> >>index 00..42c2c65c46
> >>--- /dev/null
> >>+++ b/libavformat/xvtools.h
> >>@@ -0,0 +1,95 @@
> >>+int flvid = 0x46;
> >>+
> >>+
> >>+int byte_shift(int byte,int shift);
> >>+int find_rot(AVIOContext *pb);
> >>+int xvio_r8(AVIOContext *pb, int rot);
> >>+unsigned int xvio_rb16(AVIOContext *s, int rot);
> >>+unsigned int xvio_rb24(AVIOContext *s, int rot);
> >>+unsigned int xvio_rb32(AVIOContext *s, int rot);
> >>+uint64_t xvio_rb64(AVIOContext *s, int rot);
> >>+int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot);
> >>+
> >>+
> >>+
> >>+int byte_shift(int byte,int shift){
> >>+return ((byte + shift)&0xff);
> >>+}
> >>+
> >>+
> >>+int find_rot(AVIOContext *pb){
> >>+int64_t curr_pos = avio_tell(pb);
> >>+avio_seek(pb,0x20,SEEK_SET);
> >>+int rot = flvid - avio_r8(pb);
> >>+avio_seek(pb,curr_pos, SEEK_SET);
> >>+return rot;
> >>+}
> >>+
> >>+
> >>+
> >>+int xvio_r8(AVIOContext *pb, int rot){
> >>+int64_t curr_pos = avio_tell(pb);
> >>+if(curr_pos < 0x200400){
> >>+int ret=avio_r8(pb);
> >>+if(ret == 0)return 0;
> >>+ret = byte_shift(ret,rot);
> >>+return ret;
> >>+}
> >>+int ret=avio_r8(pb);
> >>+return ret;
> >>+}
> >There is so much wrong with this code
> >global variables are not ok in a demuxer that can have multiple instances
> >global variables do not belong in headers either
> >also non static inline functions do not belong in headers
> >
> >this xvio stuff all looks like a bad idea.
> >Do i guess correctly that this fileformat is flv but scrambled at the IO
> >layer ?
> >if this is true it may be possible to implement a xv demuxer as a
> >descrambler which than passes the data on to a unchanged flv demuxer.
> >If that how this xv fundamentally works then that would be much
> >cleaner.
> >Also theflv demuxer duplication is not ok
> 
> Yeah The XV file is a flv file which starts from 0x20 byte and its
> _next__0x400_ bytes are encrypted by something like caesar cipher (the bytes
> after 0x200400 till the end of the file are not encrypted) . So, Please
> suggest what would be best solution for this situation and how can i change
> this.

look at the KUX format patch

for the IO stuff, there are 2 obvious ways
1. if this is limited to the only once read header, it should be possible
to just allocate an array, read the bytes for the header decrypt it create
a avio context on it and pass this to the header decode code. This also
assumes that the size is limited and never too large
2. if this is not limited to the once read header but can extend into the
flv frames, a avio context can be created that passes its read calls on to
the parent and decrypts as needed. so there are always 2 avio contexts and 
the flv demuxer code would see "virtual" data that has been decrypted

there are many other ways. You can probably as the one working on this
better decide as ou work on it what path makes sense. But please try to
keep the implementation cleaner than the initial patch was

Thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

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

[FFmpeg-devel] scaling option

[Yufei He]

Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.


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

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

[FFmpeg-devel] [PATCH]lavc/bmp: Avoid a heap buffer overwrite for 1bpp

[Carl Eugen Hoyos]

Hi!

Attached patch intends to fix a buffer overwrite reported today.

Please comment, Carl Eugen
From bd0dfa740f879eca6b13bb841e3b8d37718460ea Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 26 Mar 2019 13:32:11 +0100
Subject: [PATCH] lavc/bmp: Avoid a heap buffer overwrite for 1bpp input.

Found by Mingi Cho, Seoyoung Kim, and Taekyoung Kwon
of the Information Security Lab, Yonsei University.
---
 libavcodec/bmp.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/bmp.c b/libavcodec/bmp.c
index 65d239e..40010ac 100644
--- a/libavcodec/bmp.c
+++ b/libavcodec/bmp.c
@@ -291,7 +291,7 @@ static int bmp_decode_frame(AVCodecContext *avctx,
 case 1:
 for (i = 0; i < avctx->height; i++) {
 int j;
-for (j = 0; j < n; j++) {
+for (j = 0; j < avctx->width >> 3; j++) {
 ptr[j*8+0] =  buf[j] >> 7;
 ptr[j*8+1] = (buf[j] >> 6) & 1;
 ptr[j*8+2] = (buf[j] >> 5) & 1;
@@ -301,6 +301,9 @@ static int bmp_decode_frame(AVCodecContext *avctx,
 ptr[j*8+6] = (buf[j] >> 1) & 1;
 ptr[j*8+7] =  buf[j]   & 1;
 }
+for (j = 0; j < (avctx->width & 7); j++) {
+ptr[avctx->width - (avctx->width & 7) + j] = buf[avctx->width >> 3] >> (7 - j) & 1;
+}
 buf += n;
 ptr += linesize;
 }
-- 
1.7.10.4

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

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

Re: [FFmpeg-devel] [PATCH] avformat/avformat.h: Update the comment for AVInputFormat.flags

[Michael Niedermayer]

On Mon, Mar 25, 2019 at 04:43:27PM +0800, Jun Zhao wrote:
> From: Jun Zhao 
> 
> AVFMT_NOTIMESTAMPS may be using AVInputFormat.flags for demuxing
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/avformat.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

LGTM

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

[Carl Eugen Hoyos]

2019-03-26 12:28 GMT+01:00, Moritz Barsnick :
> On Tue, Mar 26, 2019 at 11:22:58 +0100, Carl Eugen Hoyos wrote:
>> > While trying to see if the proposed XV demuxer[1] can be simplified, I
>> > tripped over the fact that this KUX patch introduces a new demuxer for
>> > what looks like "only" a minor variant of FLV. Could the patch not just
>> > as well extend the flv probe and the extension list?
>>
>> What would be the advantage?
>
> Not exploding the list of supported formats by many minor subvariants.
> (It seems KUX is 99% FLV, with a different header tag and an offset.)

> I know it's a special example, but imagine "mov,mp4,m4a,3gp,3g2,mj2"
> implemented as six separate formats, six separate probes, ...

Not sure how easy it would be to separate them via probe.

Did you receive my private mail?

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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

[Moritz Barsnick]

On Tue, Mar 26, 2019 at 11:22:58 +0100, Carl Eugen Hoyos wrote:
> > While trying to see if the proposed XV demuxer[1] can be simplified, I
> > tripped over the fact that this KUX patch introduces a new demuxer for
> > what looks like "only" a minor variant of FLV. Could the patch not just
> > as well extend the flv probe and the extension list?
>
> What would be the advantage?

Not exploding the list of supported formats by many minor subvariants.
(It seems KUX is 99% FLV, with a different header tag and an offset.)
I know it's a special example, but imagine "mov,mp4,m4a,3gp,3g2,mj2"
implemented as six separate formats, six separate probes, ...

Just my $0.02.

> Minor is what is usually done for a new demuxer.

Okay, I will do so for XV as well.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

[Moritz Barsnick]

On more remark:

On Tue, Mar 19, 2019 at 22:41:32 +0530, swarajhota...@gmail.com wrote:
> +static int kux_probe(AVProbeData *p)

I get a warning if this isn't declared "const AVProbeData *p".

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

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

Re: [FFmpeg-devel] [PATCH V1 1/2] lavf/flvdec: add AMF date type support

[Steven Liu]

> 在 2019年3月26日，19:04，Jun Zhao  写道：
> 
> From: Jun Zhao 
> 
> Support AMF date type when parse the FLV metadata.
> 
> Signed-off-by: Jun Zhao 
> ---
> libavformat/flvdec.c |   24 ++--
> 1 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index c4d5278..b1e13da 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -30,6 +30,7 @@
> #include "libavutil/opt.h"
> #include "libavutil/intfloat.h"
> #include "libavutil/mathematics.h"
> +#include "libavutil/time_internal.h"
> #include "libavcodec/bytestream.h"
> #include "libavcodec/mpeg4audio.h"
> #include "avformat.h"
> @@ -77,6 +78,12 @@ typedef struct FLVContext {
> int64_t time_pos;
> } FLVContext;
> 
> +/* AMF date type */
> +typedef struct amf_date {
> +double   milliseconds;
> +int16_t  timezone;
> +} amf_date;
> +
> static int probe(const AVProbeData *p, int live)
> {
> const uint8_t *d = p->buf;
> @@ -471,6 +478,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
> *astream,
> AMFDataType amf_type;
> char str_val[1024];
> double num_val;
> +amf_date date;
> 
> num_val  = 0;
> ioc  = s->pb;
> @@ -542,7 +550,9 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
> *astream,
> }
> break;
> case AMF_DATA_TYPE_DATE:
> -avio_skip(ioc, 8 + 2);  // timestamp (double) and UTC offset (int16)
> +// timestamp (double) and UTC offset (int16)
> +date.milliseconds = av_int2double(avio_rb64(ioc));
> +date.timezone = avio_rb16(ioc);
> break;
> default:// unsupported type, we couldn't skip
> av_log(s, AV_LOG_ERROR, "unsupported amf type %d\n", amf_type);
> @@ -641,8 +651,18 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
> *astream,
> } else if (amf_type == AMF_DATA_TYPE_NUMBER) {
> snprintf(str_val, sizeof(str_val), "%.f", num_val);
> av_dict_set(>metadata, key, str_val, 0);
> -} else if (amf_type == AMF_DATA_TYPE_STRING)
> +} else if (amf_type == AMF_DATA_TYPE_STRING) {
> av_dict_set(>metadata, key, str_val, 0);
> +} else if (amf_type == AMF_DATA_TYPE_DATE) {
> +time_t time;
> +struct tm t;
> +char datestr[128];
> +time =  date.milliseconds / 1000; // to seconds
> +localtime_r(, );
> +strftime(datestr, sizeof(datestr), "%a, %d %b %Y %H:%M:%S %z", 
> );
> +
> +av_dict_set(>metadata, key, datestr, 0);
> +}
> }
> 
> return 0;
> -- 
> 1.7.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

LGTM

Thanks
Steven





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

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Paul B Mahol]

On 3/26/19, Carl Eugen Hoyos  wrote:
> 2019-03-26 11:34 GMT+01:00, Paul B Mahol :
>> On 3/26/19, Carl Eugen Hoyos  wrote:
>>> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
 Signed-off-by: Paul B Mahol 
 ---
  libavcodec/get_bits.h   | 82 +
  libavcodec/utvideodec.c |  4 +-
  2 files changed, 60 insertions(+), 26 deletions(-)
>>>
>>> How can the issue be reproduced?
>>>
>>> Would my patch - that does not increase the number
>>> of lines in the source tree - also fix the issue?
>>
>> I never saw your patch so answer is no.
>
> No, you don't know how to reproduce the issue?
>
> You gave a very extensive comment on the patch:
> https://patchwork.ffmpeg.org/patch/4784/

This is about using both endianess versions from same file.
That patch changes that for usage of single endianess in file.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH V1 1/2] lavf/flvdec: add AMF date type support

[Jun Zhao]

From: Jun Zhao 

Support AMF date type when parse the FLV metadata.

Signed-off-by: Jun Zhao 
---
 libavformat/flvdec.c |   24 ++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c4d5278..b1e13da 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -30,6 +30,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/intfloat.h"
 #include "libavutil/mathematics.h"
+#include "libavutil/time_internal.h"
 #include "libavcodec/bytestream.h"
 #include "libavcodec/mpeg4audio.h"
 #include "avformat.h"
@@ -77,6 +78,12 @@ typedef struct FLVContext {
 int64_t time_pos;
 } FLVContext;
 
+/* AMF date type */
+typedef struct amf_date {
+double   milliseconds;
+int16_t  timezone;
+} amf_date;
+
 static int probe(const AVProbeData *p, int live)
 {
 const uint8_t *d = p->buf;
@@ -471,6 +478,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 AMFDataType amf_type;
 char str_val[1024];
 double num_val;
+amf_date date;
 
 num_val  = 0;
 ioc  = s->pb;
@@ -542,7 +550,9 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 }
 break;
 case AMF_DATA_TYPE_DATE:
-avio_skip(ioc, 8 + 2);  // timestamp (double) and UTC offset (int16)
+// timestamp (double) and UTC offset (int16)
+date.milliseconds = av_int2double(avio_rb64(ioc));
+date.timezone = avio_rb16(ioc);
 break;
 default:// unsupported type, we couldn't skip
 av_log(s, AV_LOG_ERROR, "unsupported amf type %d\n", amf_type);
@@ -641,8 +651,18 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 } else if (amf_type == AMF_DATA_TYPE_NUMBER) {
 snprintf(str_val, sizeof(str_val), "%.f", num_val);
 av_dict_set(>metadata, key, str_val, 0);
-} else if (amf_type == AMF_DATA_TYPE_STRING)
+} else if (amf_type == AMF_DATA_TYPE_STRING) {
 av_dict_set(>metadata, key, str_val, 0);
+} else if (amf_type == AMF_DATA_TYPE_DATE) {
+time_t time;
+struct tm t;
+char datestr[128];
+time =  date.milliseconds / 1000; // to seconds
+localtime_r(, );
+strftime(datestr, sizeof(datestr), "%a, %d %b %Y %H:%M:%S %z", );
+
+av_dict_set(>metadata, key, datestr, 0);
+}
 }
 
 return 0;
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V1 2/2] lavf/flvdec: Cosmetics: Fix indentation for flv_read_packet

[Jun Zhao]

From: Jun Zhao 

Commit e34ba5ec53b missed the indent

Signed-off-by: Jun Zhao 
---
 libavformat/flvdec.c |  244 +-
 1 files changed, 122 insertions(+), 122 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b1e13da..445d58d 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -986,144 +986,144 @@ static int flv_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 retry:
 /* pkt size is repeated at end. skip it */
-pos  = avio_tell(s->pb);
-type = (avio_r8(s->pb) & 0x1F);
-orig_size =
-size = avio_rb24(s->pb);
-flv->sum_flv_tag_size += size + 11;
-dts  = avio_rb24(s->pb);
-dts |= (unsigned)avio_r8(s->pb) << 24;
-av_log(s, AV_LOG_TRACE, "type:%d, size:%d, last:%d, dts:%"PRId64" 
pos:%"PRId64"\n", type, size, last, dts, avio_tell(s->pb));
-if (avio_feof(s->pb))
-return AVERROR_EOF;
-avio_skip(s->pb, 3); /* stream id, always 0 */
-flags = 0;
-
-if (flv->validate_next < flv->validate_count) {
-int64_t validate_pos = flv->validate_index[flv->validate_next].pos;
-if (pos == validate_pos) {
-if (FFABS(dts - flv->validate_index[flv->validate_next].dts) <=
-VALIDATE_INDEX_TS_THRESH) {
-flv->validate_next++;
-} else {
-clear_index_entries(s, validate_pos);
-flv->validate_count = 0;
-}
-} else if (pos > validate_pos) {
+pos  = avio_tell(s->pb);
+type = (avio_r8(s->pb) & 0x1F);
+orig_size =
+size = avio_rb24(s->pb);
+flv->sum_flv_tag_size += size + 11;
+dts  = avio_rb24(s->pb);
+dts |= (unsigned)avio_r8(s->pb) << 24;
+av_log(s, AV_LOG_TRACE, "type:%d, size:%d, last:%d, dts:%"PRId64" 
pos:%"PRId64"\n", type, size, last, dts, avio_tell(s->pb));
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+avio_skip(s->pb, 3); /* stream id, always 0 */
+flags = 0;
+
+if (flv->validate_next < flv->validate_count) {
+int64_t validate_pos = flv->validate_index[flv->validate_next].pos;
+if (pos == validate_pos) {
+if (FFABS(dts - flv->validate_index[flv->validate_next].dts) <=
+VALIDATE_INDEX_TS_THRESH) {
+flv->validate_next++;
+} else {
 clear_index_entries(s, validate_pos);
 flv->validate_count = 0;
 }
+} else if (pos > validate_pos) {
+clear_index_entries(s, validate_pos);
+flv->validate_count = 0;
 }
+}
 
-if (size == 0) {
-ret = FFERROR_REDO;
-goto leave;
-}
+if (size == 0) {
+ret = FFERROR_REDO;
+goto leave;
+}
 
-next = size + avio_tell(s->pb);
-
-if (type == FLV_TAG_TYPE_AUDIO) {
-stream_type = FLV_STREAM_TYPE_AUDIO;
-flags= avio_r8(s->pb);
-size--;
-} else if (type == FLV_TAG_TYPE_VIDEO) {
-stream_type = FLV_STREAM_TYPE_VIDEO;
-flags= avio_r8(s->pb);
-size--;
-if ((flags & FLV_VIDEO_FRAMETYPE_MASK) == FLV_FRAME_VIDEO_INFO_CMD)
-goto skip;
-} else if (type == FLV_TAG_TYPE_META) {
-stream_type=FLV_STREAM_TYPE_SUBTITLE;
-if (size > 13 + 1 + 4) { // Header-type metadata stuff
-int type;
-meta_pos = avio_tell(s->pb);
-type = flv_read_metabody(s, next);
-if (type == 0 && dts == 0 || type < 0) {
-if (type < 0 && flv->validate_count &&
-flv->validate_index[0].pos > next &&
-flv->validate_index[0].pos - 4 < next
-) {
-av_log(s, AV_LOG_WARNING, "Adjusting next position due 
to index mismatch\n");
-next = flv->validate_index[0].pos - 4;
-}
-goto skip;
-} else if (type == TYPE_ONTEXTDATA) {
-avpriv_request_sample(s, "OnTextData packet");
-return flv_data_packet(s, pkt, dts, next);
-} else if (type == TYPE_ONCAPTION) {
-return flv_data_packet(s, pkt, dts, next);
-} else if (type == TYPE_UNKNOWN) {
-stream_type = FLV_STREAM_TYPE_DATA;
+next = size + avio_tell(s->pb);
+
+if (type == FLV_TAG_TYPE_AUDIO) {
+stream_type = FLV_STREAM_TYPE_AUDIO;
+flags= avio_r8(s->pb);
+size--;
+} else if (type == FLV_TAG_TYPE_VIDEO) {
+stream_type = FLV_STREAM_TYPE_VIDEO;
+flags= avio_r8(s->pb);
+size--;
+if ((flags & FLV_VIDEO_FRAMETYPE_MASK) == FLV_FRAME_VIDEO_INFO_CMD)
+goto skip;
+} else if (type == FLV_TAG_TYPE_META) {

Re: [FFmpeg-devel] [PATCH v3 1/2] vf_crop: Add support for cropping hardware frames

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Sunday, March 24, 2019 12:19 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v3 1/2] vf_crop: Add support for cropping
> hardware frames
> 
> Set the cropping fields in the AVFrame.
> ---
>  libavfilter/vf_crop.c | 74 +--
>  1 file changed, 51 insertions(+), 23 deletions(-)
> 
> There is the slightly unfortunate effect the filter links don't carry the 
> cropping
> information, so we don't know how big the cropped output is in following links
> until we actually get a frame.
> 
> For example, to get the middle ninth of a stream:
> 
> ./ffmpeg_g -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -
> hwaccel_output_format vaapi -i in.mp4 -an -vf
> "crop=iw/3:ih/3:iw/3:ih/3,scale_vaapi=iw/3:ih/3" -c:v h264_vaapi out.mp4
Hi Mark,

I tested the command against the patch, it works.
But for people who have no idea of implementation details, I think the 
”scale_vaapi=iw/3:ih/3“ will be very confusing.
I think we need to make scale_vaapi evaluate input dimensions considering crop 
information. What do you think?
People would just think that the input buffer to the scale_vaapi is the cropped 
size.
And do we need to add warning message against crop information in encoder if 
user failed to add some vaapi filter after crop?
Seems that vaapi encoder does not encode correctly with crop?

Thanks!
Ruiling
> 
> Without the extra arguments to scale it will take the cropped part correctly 
> but
> then scale it to the original size.
> 
> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> index 84be4c7d0d..7f6b0f03d3 100644
> --- a/libavfilter/vf_crop.c
> +++ b/libavfilter/vf_crop.c
> @@ -98,9 +98,17 @@ static int query_formats(AVFilterContext *ctx)
> 
>  for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> -if (!(desc->flags & (AV_PIX_FMT_FLAG_HWACCEL |
> AV_PIX_FMT_FLAG_BITSTREAM)) &&
> -!((desc->log2_chroma_w || desc->log2_chroma_h) && !(desc->flags &
> AV_PIX_FMT_FLAG_PLANAR)) &&
> -(ret = ff_add_format(, fmt)) < 0)
> +if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM)
> +continue;
> +if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
> +// Not usable if there is any subsampling but the format is
> +// not planar (e.g. YUYV422).
> +if ((desc->log2_chroma_w || desc->log2_chroma_h) &&
> +!(desc->flags & AV_PIX_FMT_FLAG_PLANAR))
> +continue;
> +}
> +ret = ff_add_format(, fmt);
> +if (ret < 0)
>  return ret;
>  }
> 
> @@ -157,8 +165,14 @@ static int config_input(AVFilterLink *link)
>  s->var_values[VAR_POS]   = NAN;
> 
>  av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
> -s->hsub = pix_desc->log2_chroma_w;
> -s->vsub = pix_desc->log2_chroma_h;
> +
> +if (pix_desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +s->hsub = 1;
> +s->vsub = 1;
> +} else {
> +s->hsub = pix_desc->log2_chroma_w;
> +s->vsub = pix_desc->log2_chroma_h;
> +}
> 
>  if ((ret = av_expr_parse_and_eval(, (expr = s->w_expr),
>var_names, s->var_values,
> @@ -237,9 +251,15 @@ fail_expr:
>  static int config_output(AVFilterLink *link)
>  {
>  CropContext *s = link->src->priv;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
> 
> -link->w = s->w;
> -link->h = s->h;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +// Hardware frames adjust the cropping regions rather than
> +// changing the frame size.
> +} else {
> +link->w = s->w;
> +link->h = s->h;
> +}
>  link->sample_aspect_ratio = s->out_sar;
> 
>  return 0;
> @@ -252,9 +272,6 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *frame)
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
>  int i;
> 
> -frame->width  = s->w;
> -frame->height = s->h;
> -
>  s->var_values[VAR_N] = link->frame_count_out;
>  s->var_values[VAR_T] = frame->pts == AV_NOPTS_VALUE ?
>  NAN : frame->pts * av_q2d(link->time_base);
> @@ -285,22 +302,33 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *frame)
>  (int)s->var_values[VAR_N], s->var_values[VAR_T], s-
> >var_values[VAR_POS],
>  s->x, s->y, s->x+s->w, s->y+s->h);
> 
> -frame->data[0] += s->y * frame->linesize[0];
> -frame->data[0] += s->x * s->max_step[0];
> -
> -if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags & FF_PSEUDOPAL))
> {
> -for (i = 1; i < 3; i ++) {
> -if (frame->data[i]) {
> -frame->data[i] += (s->y >> s->vsub) * frame->linesize[i];
> -frame->data[i] += (s->x * s->max_step[i]) >> s->hsub;
> +  

Re: [FFmpeg-devel] [PATCH 2/5] libavformat/avisynth: enable additional pix_fmts

[Carl Eugen Hoyos]

2019-03-25 2:13 GMT+01:00, Stephen Hutchinson :
> On 3/24/2019 7:07 PM, Carl Eugen Hoyos wrote:
>> 2019-03-24 21:25 GMT+01:00, Stephen Hutchinson :
>>> These pix_fmts have been added to FFmpeg in the 31 months since
>>> commit 92916e8542e425ca20daddb490261a5818643206 added support for
>>> the larger number of pix_fmts that AviSynth+ can use. They were
>>> present in AviSynth+ even then, just not in libavutil.
>>> +/* Single precision floating point Planar RGB (AviSynth+) */
>>> +case AVS_CS_RGBPS:
>>> +st->codecpar->format = AV_PIX_FMT_GBRPF32;
>>> +/* Single precision floating point Planar RGB with Alpha (AviSynth+)
>>> */
>>> +case AVS_CS_RGBAPS:
>>> +st->codecpar->format = AV_PIX_FMT_GBRAPF32;
>> Were you able to test these two in any way?
>> Is there absolutely no danger that they mean something
>> completely different in avisynth?
> There shouldn't be any danger whatsoever.

Thank you for the extensive explanation!

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

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

Re: [FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Carl Eugen Hoyos]

2019-03-25 6:42 GMT+01:00, Sun, Jing A :
> Friday, March 22, 2019 5:54 PM, Carl Eugen Hoyos:
>
>>What I meant is:
>>I don't understand the comment (and your mail), it says above the
>> functionality has to be disabled but you write it works fine.
>>The comment is (still) unclear imo.
>
>>Carl Eugen
>
> Hi Carl, it works functionally, but there is something that can be done, and
> will be done in the further, to improve its performance a little.

Then my suggestion would be add "which adds a performance penalty"
(or similar) to the comment.
I do understand it now but it seems difficult to parse without the
extra information.

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

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

Re: [FFmpeg-devel] Patch request to timestamp.h for silencedetect filter

[Carl Eugen Hoyos]

2019-03-26 0:49 GMT+01:00, Allan Cady via ffmpeg-devel
:
>  Noob here. I would like to suggest a simple change to
> libavutil\timestamp.h

Please provide a patch (as attachment) that you created
with "git format-patch HEAD^"

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Carl Eugen Hoyos]

2019-03-26 11:26 GMT+01:00, Carl Eugen Hoyos :
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/get_bits.h   | 82 +
>>  libavcodec/utvideodec.c |  4 +-
>>  2 files changed, 60 insertions(+), 26 deletions(-)
>
> How can the issue be reproduced?
>
> Would my patch - that does not increase the number of lines
> in the source tree - also fix the issue?

Please ignore, I misremembered.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Carl Eugen Hoyos]

2019-03-26 11:34 GMT+01:00, Paul B Mahol :
> On 3/26/19, Carl Eugen Hoyos  wrote:
>> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavcodec/get_bits.h   | 82 +
>>>  libavcodec/utvideodec.c |  4 +-
>>>  2 files changed, 60 insertions(+), 26 deletions(-)
>>
>> How can the issue be reproduced?
>>
>> Would my patch - that does not increase the number
>> of lines in the source tree - also fix the issue?
>
> I never saw your patch so answer is no.

No, you don't know how to reproduce the issue?

You gave a very extensive comment on the patch:
https://patchwork.ffmpeg.org/patch/4784/

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Hendrik Leppkes]

On Tue, Mar 26, 2019 at 11:32 AM Carl Eugen Hoyos  wrote:
>
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/get_bits.h   | 82 +
> >  libavcodec/utvideodec.c |  4 +-
> >  2 files changed, 60 insertions(+), 26 deletions(-)
>
> How can the issue be reproduced?
>

Try to play https://files.1f0.de/samples/ut-test-t2-umrg.mkv in a 64-bit build.

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

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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Carl Eugen Hoyos]

2019-03-26 23:07 GMT+01:00, Shaofei Wang :
> It enabled MULTIPLE SIMPLE filter graph concurrency, which
> bring above about 4%~20% improvement in some 1:N
> scenarios by CPU or GPU acceleration

Which version of the patch did you test to get this numbers?

The following is not an actual review, feel free to ignore all comments.

> -/* Reap all buffers present in the buffer sinks */
> +/* Reap all buffers present in the buffer sinks or just reap specified
> + * buffer which related with the filter graph who got ifilter as
> input*/

/* Reap all buffers present in the buffer sinks */
/* or just reap specified buffer which related */
/* with the filter graph who got ifilter as input */

> +if (ifilter && abr_threads_enabled)
> +if (ost != ifilter->graph->outputs[0]->ost)
> +continue;

if (filter && abr_threads_enabled && ost != ifilter->graph->outputs[0]->ost)
  continue;

> -ret = reap_filters(1);
> +ret = (HAVE_THREADS && abr_threads_enabled) ? reap_filters(1,
> ifilter) : reap_filters(1, NULL);

ret = reap_filters(1, HAVE_THREADS && abr_threads_enabled ? ifilter, NULL);

Same below.

> +if (ret == AVERROR_EOF)
> +ret = 0;
> +else if (ret < 0) {

Please add "{" and "}".

> +av_log(NULL, AV_LOG_ERROR,
> +   "Failed to inject frame into filter network: %s\n",
> av_err2str(ret));
> +} else {

>  static int send_frame_to_filters(InputStream *ist, AVFrame *decoded_frame)
>  {
> -int i, ret;
> +int i, ret = 0;
>  AVFrame *f;
>
>  av_assert1(ist->nb_filters > 0); /* ensure ret is initialized */
> +

No.

>  for (i = 0; i < ist->nb_filters; i++) {
>  if (i < ist->nb_filters - 1) {
> -f = ist->filter_frame;
> +f = (HAVE_THREADS && abr_threads_enabled) ?
> ist->filters[i]->input_frm : ist->filter_frame;

See above.

> -ret = ifilter_send_frame(ist->filters[i], f);
> -if (ret == AVERROR_EOF)
> -ret = 0; /* ignore */
> -if (ret < 0) {
> -av_log(NULL, AV_LOG_ERROR,
> -   "Failed to inject frame into filter network: %s\n",
> av_err2str(ret));
> -break;
> +if (!HAVE_THREADS || !abr_threads_enabled) {
> +ret = ifilter_send_frame(ist->filters[i], f);
> +if (ret == AVERROR_EOF)
> +ret = 0; /* ignore */
> +if (ret < 0) {
> +av_log(NULL, AV_LOG_ERROR,
> +   "Failed to inject frame into filter network: %s\n",
> av_err2str(ret));
> +break;

Some people here (including me) find the patch much easier
to read if you do the re-indentation in a separate patch.

> @@ -2334,7 +2442,6 @@ static int decode_audio
>(AVRational){1,
> avctx->sample_rate});
>  ist->nb_samples = decoded_frame->nb_samples;
>  err = send_frame_to_filters(ist, decoded_frame);
> -

No.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Paul B Mahol]

On 3/26/19, Carl Eugen Hoyos  wrote:
> 2019-03-26 11:13 GMT+01:00, Paul B Mahol :
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/get_bits.h   | 82 +
>>  libavcodec/utvideodec.c |  4 +-
>>  2 files changed, 60 insertions(+), 26 deletions(-)
>
> How can the issue be reproduced?
>
> Would my patch - that does not increase the number of lines
> in the source tree - also fix the issue?
>

I never saw your patch so answer is no.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Carl Eugen Hoyos]

2019-03-26 11:13 GMT+01:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/get_bits.h   | 82 +
>  libavcodec/utvideodec.c |  4 +-
>  2 files changed, 60 insertions(+), 26 deletions(-)

How can the issue be reproduced?

Would my patch - that does not increase the number of lines
in the source tree - also fix the issue?

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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

[Carl Eugen Hoyos]

2019-03-26 11:18 GMT+01:00, Moritz Barsnick :
> On Tue, Mar 26, 2019 at 00:24:40 +0100, Carl Eugen Hoyos wrote:
>> > Fixes ticket #4519.
>> I will push this if there are no objections.
>
> While trying to see if the proposed XV demuxer[1] can be simplified, I
> tripped over the fact that this KUX patch introduces a new demuxer for
> what looks like "only" a minor variant of FLV. Could the patch not just
> as well extend the flv probe and the extension list?

What would be the advantage?

[...]

> And I personally would have only bumped micro, not minor, but that's
> just a gut feeling, I haven't checked what is usually done.

Minor is what is usually done for a new demuxer.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: added support for KUX container

[Moritz Barsnick]

On Tue, Mar 26, 2019 at 00:24:40 +0100, Carl Eugen Hoyos wrote:
> > Fixes ticket #4519.
> I will push this if there are no objections.

While trying to see if the proposed XV demuxer[1] can be simplified, I
tripped over the fact that this KUX patch introduces a new demuxer for
what looks like "only" a minor variant of FLV. Could the patch not just
as well extend the flv probe and the extension list?

Of course, this would need to be implemented differently (perhaps a
flag within the Class?):

> if(!strcmp(s->iformat->name, "kux"))

Or is the difference between "a variant" and "a demuxer of its own" too
small to justify the former? Just wondering.

And I personally would have only bumped micro, not minor, but that's
just a gut feeling, I haven't checked what is usually done.

Cheers,
Moritz

P.S.: I will subsequently propose a similar initial XV patch. Either as
this KUX patch does, or as I suggested above.

[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241483.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/get_bits: unbreak get_bits_le() with cached reader

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/get_bits.h   | 82 +
 libavcodec/utvideodec.c |  4 +-
 2 files changed, 60 insertions(+), 26 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index c2f267186e..c4ab607744 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -226,34 +226,32 @@ static inline int get_bits_count(const GetBitContext *s)
 }
 
 #if CACHED_BITSTREAM_READER
-static inline void refill_32(GetBitContext *s)
+static inline void refill_32(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
 if (s->index >> 3 >= s->buffer_end - s->buffer)
 return;
 #endif
 
-#ifdef BITSTREAM_READER_LE
+if (is_le)
 s->cache   = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
s->bits_left | s->cache;
-#else
+else
 s->cache   = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3)) 
<< (32 - s->bits_left);
-#endif
 s->index += 32;
 s->bits_left += 32;
 }
 
-static inline void refill_64(GetBitContext *s)
+static inline void refill_64(GetBitContext *s, int is_le)
 {
 #if !UNCHECKED_BITSTREAM_READER
 if (s->index >> 3 >= s->buffer_end - s->buffer)
 return;
 #endif
 
-#ifdef BITSTREAM_READER_LE
+if (is_le)
 s->cache = AV_RL64(s->buffer + (s->index >> 3));
-#else
+else
 s->cache = AV_RB64(s->buffer + (s->index >> 3));
-#endif
 s->index += 64;
 s->bits_left = 64;
 }
@@ -385,7 +383,11 @@ static inline unsigned int get_bits(GetBitContext *s, int 
n)
 
 av_assert2(n>0 && n<=32);
 if (n > s->bits_left) {
-refill_32(s);
+#ifdef BITSTREAM_READER_LE
+refill_32(s, 1);
+#else
+refill_32(s, 0);
+#endif
 if (s->bits_left < 32)
 s->bits_left = n;
 }
@@ -420,7 +422,7 @@ static inline unsigned int get_bits_le(GetBitContext *s, 
int n)
 #if CACHED_BITSTREAM_READER
 av_assert2(n>0 && n<=32);
 if (n > s->bits_left) {
-refill_32(s);
+refill_32(s, 1);
 if (s->bits_left < 32)
 s->bits_left = n;
 }
@@ -446,7 +448,11 @@ static inline unsigned int show_bits(GetBitContext *s, int 
n)
 register unsigned int tmp;
 #if CACHED_BITSTREAM_READER
 if (n > s->bits_left)
-refill_32(s);
+#ifdef BITSTREAM_READER_LE
+refill_32(s, 1);
+#else
+refill_32(s, 0);
+#endif
 
 tmp = show_val(s, n);
 #else
@@ -474,7 +480,11 @@ static inline void skip_bits(GetBitContext *s, int n)
 n -= skip;
 s->index += skip;
 }
-refill_64(s);
+#ifdef BITSTREAM_READER_LE
+refill_64(s, 1);
+#else
+refill_64(s, 0);
+#endif
 if (n)
 skip_remaining(s, n);
 }
@@ -489,7 +499,11 @@ static inline unsigned int get_bits1(GetBitContext *s)
 {
 #if CACHED_BITSTREAM_READER
 if (!s->bits_left)
-refill_64(s);
+#ifdef BITSTREAM_READER_LE
+refill_64(s, 1);
+#else
+refill_64(s, 0);
+#endif
 
 #ifdef BITSTREAM_READER_LE
 return get_val(s, 1, 1);
@@ -605,16 +619,8 @@ static inline int check_marker(void *logctx, GetBitContext 
*s, const char *msg)
 return bit;
 }
 
-/**
- * Initialize GetBitContext.
- * @param buffer bitstream buffer, must be AV_INPUT_BUFFER_PADDING_SIZE bytes
- *larger than the actual read bits because some optimized bitstream
- *readers read 32 or 64 bit at once and could read over the end
- * @param bit_size the size of the buffer in bits
- * @return 0 on success, AVERROR_INVALIDDATA if the buffer_size would overflow.
- */
-static inline int init_get_bits(GetBitContext *s, const uint8_t *buffer,
-int bit_size)
+static inline int init_get_bits_xe(GetBitContext *s, const uint8_t *buffer,
+   int bit_size, int is_le)
 {
 int buffer_size;
 int ret = 0;
@@ -634,12 +640,32 @@ static inline int init_get_bits(GetBitContext *s, const 
uint8_t *buffer,
 s->index  = 0;
 
 #if CACHED_BITSTREAM_READER
-refill_64(s);
+s->cache  = 0;
+s->bits_left  = 0;
+refill_64(s, is_le);
 #endif
 
 return ret;
 }
 
+/**
+ * Initialize GetBitContext.
+ * @param buffer bitstream buffer, must be AV_INPUT_BUFFER_PADDING_SIZE bytes
+ *larger than the actual read bits because some optimized bitstream
+ *readers read 32 or 64 bit at once and could read over the end
+ * @param bit_size the size of the buffer in bits
+ * @return 0 on success, AVERROR_INVALIDDATA if the buffer_size would overflow.
+ */
+static inline int init_get_bits(GetBitContext *s, const uint8_t *buffer,
+int bit_size)
+{
+#ifdef BITSTREAM_READER_LE
+return init_get_bits_xe(s, buffer, bit_size, 1);
+#else
+return init_get_bits_xe(s, buffer, bit_size, 0);
+#endif
+}
+
 /**
  * Initialize GetBitContext.
  * @param buffer bitstream buffer, must be AV_INPUT_BUFFER_PADDING_SIZE bytes
@@ -656,6 +682,14 @@ static inline int 

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Jean-Baptiste Kempf]

On Tue, 26 Mar 2019, at 10:03, Tomas Härdin wrote:
> You can include LGPL code in a proprietary library if you provide the
> object files for the proprietary parts, such that you can modify the
> LGPL part and still link together a functioning library. I don't think
> I've ever seen that done however

Google release of Sparrow on iOS is a clear case of this: to allow effective 
changing of the LGPL library in it, they gave all the objects pre-linking. So 
you could recompile the LGPL library part completely, and relink and reship on 
your device.

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

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

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Jean-Baptiste Kempf]

On Tue, 26 Mar 2019, at 09:45, Tobias Rapp wrote:
> > I know that means that you can do more or less the same feature, but that 
> > means the architecture must be different.
> 
> I thought that section 7 would allow to combine a 3rd party library with 
> a LGPL library to create a new library but now when reading it again I 
> stumble over the word "side-by-side" which indicates that the two parts 
> should not interact with each other.

Yep, you can have program A that includes both library B LGPL and library C 
whatever-license.
You cannot have program A that includes library B, which itself would include C.

> So yes, your interpretation looks correct to me (IANAL).

I got bitten by it, in the past, that's why I now know.

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

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

[FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Shaofei Wang]

It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration

Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD driver - 16.9.00100, CentOS 7)

For 1:N transcode by GPU acceleration with vaapi:
./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
-hwaccel_output_format vaapi \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
-vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null

test results:
2 encoders 5 encoders 10 encoders
Improved   6.1%6.9%   5.5%

For 1:N transcode by GPU acceleration with QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
-vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null

test results:
2 encoders  5 encoders 10 encoders
Improved   6%   4% 15%

For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
./ffmpeg -hwaccel qsv -c:v h264_qsv \
-i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null 
/dev/null \
-vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null 
/dev/null

test results:
2 scale  5 scale   10 scale
Improved   12% 21%21%

For CPU only 1 decode to N scaling:
./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
-vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
-vf "scale=720:480" -pix_fmt nv12 -f null /dev/null

test results:
2 scale  5 scale   10 scale
Improved   25%107%   148%

Signed-off-by: Wang, Shaofei 
---
The patch will only effect on multiple SIMPLE filter graphs pipeline,
Passed fate and refine the possible data race,
AFL tested, without introducing extra crashs/hangs

 fftools/ffmpeg.c | 172 +--
 fftools/ffmpeg.h |  13 +
 2 files changed, 169 insertions(+), 16 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 544f1a1..5f6e712 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -164,7 +164,13 @@ static struct termios oldtty;
 static int restore_tty;
 #endif
 
+/* enable abr threads when there were multiple simple filter graphs*/
+static int abr_threads_enabled = 0;
+
 #if HAVE_THREADS
+pthread_mutex_t fg_config_mutex;
+pthread_mutex_t ost_init_mutex;
+
 static void free_input_threads(void);
 #endif
 
@@ -509,6 +515,17 @@ static void ffmpeg_cleanup(int ret)
 }
 av_fifo_freep(>inputs[j]->ist->sub2video.sub_queue);
 }
+#if HAVE_THREADS
+if (abr_threads_enabled) {
+av_frame_free(>inputs[j]->input_frm);
+pthread_mutex_lock(>inputs[j]->process_mutex);
+fg->inputs[j]->waited_frm = NULL;
+fg->inputs[j]->t_end = 1;
+pthread_cond_signal(>inputs[j]->process_cond);
+pthread_mutex_unlock(>inputs[j]->process_mutex);
+pthread_join(fg->inputs[j]->abr_thread, NULL);
+}
+#endif
 av_buffer_unref(>inputs[j]->hw_frames_ctx);
 av_freep(>inputs[j]->name);
 av_freep(>inputs[j]);
@@ -1419,12 +1436,13 @@ static void finish_output_stream(OutputStream *ost)
  *
  * @return  0 for success, <0 for severe errors
  */
-static int reap_filters(int flush)
+static int reap_filters(int flush, InputFilter * ifilter)
 {
 AVFrame *filtered_frame = NULL;
 int i;
 
-/* Reap all buffers present in the buffer sinks */
+/* Reap all buffers present in the buffer sinks or just reap specified
+ * buffer which related with the filter graph who got ifilter as input*/
 for (i = 0; i < nb_output_streams; i++) {
 OutputStream *ost = output_streams[i];
 OutputFile*of = output_files[ost->file_index];
@@ -1432,13 +1450,25 @@ static int reap_filters(int flush)
 AVCodecContext *enc = ost->enc_ctx;
 int ret = 0;
 
+if (ifilter && abr_threads_enabled)
+if (ost != ifilter->graph->outputs[0]->ost)
+continue;
+
 if (!ost->filter || !ost->filter->graph->graph)
 continue;
 filter = ost->filter->filter;
 
 if (!ost->initialized) {
 char error[1024] = "";
+#if HAVE_THREADS
+if (abr_threads_enabled)
+pthread_mutex_lock(_init_mutex);
+#endif
 ret = init_output_stream(ost, error, sizeof(error));
+#if HAVE_THREADS
+if (abr_threads_enabled)
+pthread_mutex_unlock(_init_mutex);
+#endif
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Error initializing output stream 

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Tomas Härdin]

tis 2019-03-26 klockan 09:45 +0100 skrev Tobias Rapp:
> On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:
> > On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
> > > > Most of those hardware libraries are glorified ioctls around
> > > > the driver and shipped with the drivers.
> > > > And I see this with nVidia, Intel MFX and Decklink (lots of
> > > > "acquire C++ interface, set param" there, release the C++
> > > > interface).
> > > > 
> > > > Matrox seems to do something else, though, introducing a
> > > > special library for FFmpeg consumption, and I doubt that feels
> > > > like a driver...
> > > 
> > > The GPL is mentioned a lot in this thread. Maybe it would make
> > > sense to
> > > distinguish the two cases where FFmpeg is compiled with --enable-
> > > gpl and
> > > without it -- as the LGPL applies in that case.
> > 
> > That does not change a thing, sorry.
> > The section 6 of the LGPLv2.1 is similar to the section 3 of the
> > GPL, and mentions exactly the same limitations and exceptions for
> > major components of the OS.
> > 
> > The fact that you can combine the library with a 3rd party library
> > inside your program does not allow you to ship non-LGPL-compatible
> > code inside the library. (The library must be changeable +
> > redistributable by the user).
> > 
> > I know that means that you can do more or less the same feature,
> > but that means the architecture must be different.
> 
> I thought that section 7 would allow to combine a 3rd party library with 
> a LGPL library to create a new library but now when reading it again I 
> stumble over the word "side-by-side" which indicates that the two parts 
> should not interact with each other.

You can include LGPL code in a proprietary library if you provide the
object files for the proprietary parts, such that you can modify the
LGPL part and still link together a functioning library. I don't think
I've ever seen that done however

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

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

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Tobias Rapp]

On 25.03.2019 18:02, Jean-Baptiste Kempf wrote:

On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:

Most of those hardware libraries are glorified ioctls around the driver and 
shipped with the drivers.
And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface, 
set param" there, release the C++ interface).

Matrox seems to do something else, though, introducing a special library for 
FFmpeg consumption, and I doubt that feels like a driver...


The GPL is mentioned a lot in this thread. Maybe it would make sense to
distinguish the two cases where FFmpeg is compiled with --enable-gpl and
without it -- as the LGPL applies in that case.


That does not change a thing, sorry.
The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and 
mentions exactly the same limitations and exceptions for major components of 
the OS.

The fact that you can combine the library with a 3rd party library inside your 
program does not allow you to ship non-LGPL-compatible code inside the library. 
(The library must be changeable + redistributable by the user).

I know that means that you can do more or less the same feature, but that means 
the architecture must be different.


I thought that section 7 would allow to combine a 3rd party library with 
a LGPL library to create a new library but now when reading it again I 
stumble over the word "side-by-side" which indicates that the two parts 
should not interact with each other.


So yes, your interpretation looks correct to me (IANAL).

Regards,
Tobias

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

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

[FFmpeg-devel] [PATCH v2] swscale: Remove duplicated code

[Lauri Kasanen]

In this function, the exact same clamping happens both in the if and 
unconditionally.

Signed-off-by: Lauri Kasanen 
---
 libswscale/output.c | 10 --
 1 file changed, 10 deletions(-)

v2: Remove the unconditional instead of the if'd clipping.
I'll leave changing the bit pattern to others, there's so many funcs using 
0x100.

diff --git a/libswscale/output.c b/libswscale/output.c
index d7c53e6..d3401f0 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -853,11 +853,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0,
 V  = av_clip_uint8(V);
 }

-Y1 = av_clip_uint8(Y1);
-Y2 = av_clip_uint8(Y2);
-U  = av_clip_uint8(U);
-V  = av_clip_uint8(V);
-
 output_pixels(i * 4, Y1, U, Y2, V);
 }
 } else {
@@ -875,11 +870,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0,
 V  = av_clip_uint8(V);
 }

-Y1 = av_clip_uint8(Y1);
-Y2 = av_clip_uint8(Y2);
-U  = av_clip_uint8(U);
-V  = av_clip_uint8(V);
-
 output_pixels(i * 4, Y1, U, Y2, V);
 }
 }
--
2.6.2

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

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