Re: [FFmpeg-devel] lavf/dashdec: Fix memleak

[Liu Steven]

> 在 2018年8月1日，下午6:03，jacek jogo  写道：
> 
> Hi.
> This fix memleak in dashdec.
> ==5033== HEAP SUMMARY:
> ==5033== in use at exit: 86,144 bytes in 2,848 blocks
> ==5033==   total heap usage: 10,089 allocs, 7,241 frees, 38,902,613 bytes
> allocated
> ==5033==
> ==5033== Searching for pointers to 2,848 not-freed blocks
> ==5033== Checked 9,139,304 bytes
> ==5033==
> ==5033== 528 bytes in 8 blocks are definitely lost in loss record 187 of 222
> ==5033==at 0x4C2CB5F: malloc (vg_replace_malloc.c:299)
> ==5033==by 0x6868D38: xmlBufCreateSize (in /usr/lib64/libxml2.so.2.9.8)
> ==5033==by 0x67F1029: xmlNodeGetContent (in /usr/lib64/libxml2.so.2.9.8)
> ==5033==by 0x41EA43: resolve_content_path (dashdec.c:757)
> ==5033==by 0x41EA43: parse_manifest_representation (dashdec.c:873)
> ==5033==by 0x41EA43: parse_manifest_adaptationset (dashdec.c:1095)
> ==5033==by 0x41EA43: parse_manifest (dashdec.c:1272)
> ==5033==by 0x420E2A: dash_read_header (dashdec.c:1927)
> ==5033==by 0x53CF77: avformat_open_input (utils.c:631)
> ==5033==by 0x2647F4: open_input_file (ffmpeg_opt.c:1069)
> ==5033==by 0x266121: open_files (ffmpeg_opt.c:3219)
> ==5033==by 0x266121: ffmpeg_parse_options (ffmpeg_opt.c:3259)
> ==5033==by 0x25E991: main (ffmpeg.c:4859)
> ==5033==
> ==5033== LEAK SUMMARY:
> ==5033==definitely lost: 528 bytes in 8 blocks
> ==5033==indirectly lost: 0 bytes in 0 blocks
> ==5033==  possibly lost: 0 bytes in 0 blocks
> ==5033==still reachable: 85,616 bytes in 2,840 blocks
> ==5033== suppressed: 0 bytes in 0 blocks
> ==5033== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==5033== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==5033==
> ==5033== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> ==5033== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> 
> Can be reproduced with:  valgrind  --leak-check=full  -v ffmpeg -i
> http://yt-dash-mse-test.commondatastorage.googleapis.com/media/motion-20120802-manifest.mpd
> <0001-lavf-dashdec-Fix-memleak.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

pushed



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

Re: [FFmpeg-devel] avformat/dashdec: fix for ticket #7336

[Liu Steven]

> 在 2018年8月1日，下午2:29，Liu Steven  写道：
> 
> 
> 
>> 在 2018年7月31日，下午11:52，jacek jogo  写道：
>> 
>> Hi.
>> fix for ticket #7336
>> <0001-fix-possible-segfault-if-dash-stream-have-only-audio.patch>___
> LGTM
> 
pushed
> 
> Thanks
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: expose qp of encoded frames

[James Almer]

On 7/26/2018 4:51 AM, Zhong Li wrote:
> Requirement from ticket #7254.
> Currently only H264 supported by MSDK.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc.c  | 43 +++
>  libavcodec/qsvenc.h  |  2 ++
>  libavcodec/qsvenc_h264.c |  5 +
>  3 files changed, 50 insertions(+)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 8096945..1294ed2 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1139,6 +1139,10 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  {
>  AVPacket new_pkt = { 0 };
>  mfxBitstream *bs;
> +#if QSV_VERSION_ATLEAST(1, 26)
> +mfxExtAVCEncodedFrameInfo *enc_info;
> +mfxExtBuffer **enc_buf;
> +#endif
>  
>  mfxFrameSurface1 *surf = NULL;
>  mfxSyncPoint *sync = NULL;
> @@ -1172,6 +1176,22 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  bs->Data  = new_pkt.data;
>  bs->MaxLength = new_pkt.size;
>  
> +#if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264) {
> +enc_info = av_mallocz(sizeof(*enc_info));
> +if (!enc_info)
> +return AVERROR(ENOMEM);
> +
> +enc_info->Header.BufferId = MFX_EXTBUFF_ENCODED_FRAME_INFO;
> +enc_info->Header.BufferSz = sizeof (*enc_info);
> +bs->NumExtParam = 1;
> +enc_buf = av_mallocz(sizeof(mfxExtBuffer *));

This allocation is unchecked, and also leaks. You free bs and enc_info
everywhere, but not enc_buf.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: expose qp of encoded frames

[James Almer]

On 8/7/2018 12:12 AM, James Almer wrote:
> On 7/26/2018 4:51 AM, Zhong Li wrote:
>> Requirement from ticket #7254.
>> Currently only H264 supported by MSDK.
>>
>> Signed-off-by: Zhong Li 
>> ---
>>  libavcodec/qsvenc.c  | 43 +++
>>  libavcodec/qsvenc.h  |  2 ++
>>  libavcodec/qsvenc_h264.c |  5 +
>>  3 files changed, 50 insertions(+)
>>
>> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
>> index 8096945..1294ed2 100644
>> --- a/libavcodec/qsvenc.c
>> +++ b/libavcodec/qsvenc.c
>> @@ -1139,6 +1139,10 @@ static int encode_frame(AVCodecContext *avctx, 
>> QSVEncContext *q,
>>  {
>>  AVPacket new_pkt = { 0 };
>>  mfxBitstream *bs;
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +mfxExtAVCEncodedFrameInfo *enc_info;
>> +mfxExtBuffer **enc_buf;
>> +#endif
>>  
>>  mfxFrameSurface1 *surf = NULL;
>>  mfxSyncPoint *sync = NULL;
>> @@ -1172,6 +1176,22 @@ static int encode_frame(AVCodecContext *avctx, 
>> QSVEncContext *q,
>>  bs->Data  = new_pkt.data;
>>  bs->MaxLength = new_pkt.size;
>>  
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +if (avctx->codec_id == AV_CODEC_ID_H264) {
>> +enc_info = av_mallocz(sizeof(*enc_info));
>> +if (!enc_info)
>> +return AVERROR(ENOMEM);
>> +
>> +enc_info->Header.BufferId = MFX_EXTBUFF_ENCODED_FRAME_INFO;
>> +enc_info->Header.BufferSz = sizeof (*enc_info);
>> +bs->NumExtParam = 1;
>> +enc_buf = av_mallocz(sizeof(mfxExtBuffer *));
>> +enc_buf[0] = (mfxExtBuffer *)enc_info;
>> +
>> +bs->ExtParam = enc_buf;
>> +}
>> +#endif
>> +
>>  if (q->set_encode_ctrl_cb) {
>>  q->set_encode_ctrl_cb(avctx, frame, _frame->enc_ctrl);
>>  }
>> @@ -1179,6 +1199,10 @@ static int encode_frame(AVCodecContext *avctx, 
>> QSVEncContext *q,
>>  sync = av_mallocz(sizeof(*sync));
>>  if (!sync) {
>>  av_freep();
>> + #if QSV_VERSION_ATLEAST(1, 26)
>> +if (avctx->codec_id == AV_CODEC_ID_H264)
>> +av_freep(_info);
>> + #endif
>>  av_packet_unref(_pkt);
>>  return AVERROR(ENOMEM);
>>  }
>> @@ -1195,6 +1219,10 @@ static int encode_frame(AVCodecContext *avctx, 
>> QSVEncContext *q,
>>  if (ret < 0) {
>>  av_packet_unref(_pkt);
>>  av_freep();
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +if (avctx->codec_id == AV_CODEC_ID_H264)
>> +av_freep(_info);
>> +#endif
>>  av_freep();
>>  return (ret == MFX_ERR_MORE_DATA) ?
>> 0 : ff_qsv_print_error(avctx, ret, "Error during encoding");
>> @@ -1211,6 +1239,10 @@ static int encode_frame(AVCodecContext *avctx, 
>> QSVEncContext *q,
>>  av_freep();
>>  av_packet_unref(_pkt);
>>  av_freep();
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +if (avctx->codec_id == AV_CODEC_ID_H264)
>> +av_freep(_info);
>> +#endif
>>  }
>>  
>>  return 0;
>> @@ -1230,6 +1262,9 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
>> *q,
>>  AVPacket new_pkt;
>>  mfxBitstream *bs;
>>  mfxSyncPoint *sync;
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +mfxExtAVCEncodedFrameInfo *enc_info;
>> +#endif
>>  
>>  av_fifo_generic_read(q->async_fifo, _pkt, sizeof(new_pkt), 
>> NULL);
>>  av_fifo_generic_read(q->async_fifo, ,sizeof(sync),
>> NULL);
>> @@ -1258,6 +1293,14 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>  FF_ENABLE_DEPRECATION_WARNINGS
>>  #endif
>>  
>> +#if QSV_VERSION_ATLEAST(1, 26)
>> +if (avctx->codec_id == AV_CODEC_ID_H264) {
>> +enc_info = (mfxExtAVCEncodedFrameInfo *)(*bs->ExtParam);
>> +av_log(avctx, AV_LOG_DEBUG, "QP is %d\n", enc_info->QP);
> 
> I think you should use ff_side_data_set_encoder_stats() for this instead.

I see you pushed this already. You didn't really give enough time after
you said you'd wait for other comments, and even went and pushed it
after i wrote the above email...

Use ff_side_data_set_encoder_stats() to export frame quality encoding
info instead of the above debug av_log() message as i requested. It's a
trivial change, and the proper way to export such stats.

> 
>> +q->sum_frame_qp += enc_info->QP;
>> +av_freep(_info);
>> +}
>> +#endif
>>  av_freep();
>>  av_freep();
>>  
>> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
>> index b2d6355..3784a82 100644
>> --- a/libavcodec/qsvenc.h
>> +++ b/libavcodec/qsvenc.h
>> @@ -102,6 +102,8 @@ typedef struct QSVEncContext {
>>  int width_align;
>>  int height_align;
>>  
>> +int sum_frame_qp;
>> +
>>  mfxVideoParam param;
>>  mfxFrameAllocRequest req;
>>  
>> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
>> index 5c262e5..b87bef6 100644
>> --- a/libavcodec/qsvenc_h264.c
>> +++ b/libavcodec/qsvenc_h264.c
>> @@ -95,6 +95,11 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>>  {
>>  

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: expose qp of encoded frames

[James Almer]

On 7/26/2018 4:51 AM, Zhong Li wrote:
> Requirement from ticket #7254.
> Currently only H264 supported by MSDK.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc.c  | 43 +++
>  libavcodec/qsvenc.h  |  2 ++
>  libavcodec/qsvenc_h264.c |  5 +
>  3 files changed, 50 insertions(+)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 8096945..1294ed2 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1139,6 +1139,10 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  {
>  AVPacket new_pkt = { 0 };
>  mfxBitstream *bs;
> +#if QSV_VERSION_ATLEAST(1, 26)
> +mfxExtAVCEncodedFrameInfo *enc_info;
> +mfxExtBuffer **enc_buf;
> +#endif
>  
>  mfxFrameSurface1 *surf = NULL;
>  mfxSyncPoint *sync = NULL;
> @@ -1172,6 +1176,22 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  bs->Data  = new_pkt.data;
>  bs->MaxLength = new_pkt.size;
>  
> +#if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264) {
> +enc_info = av_mallocz(sizeof(*enc_info));
> +if (!enc_info)
> +return AVERROR(ENOMEM);
> +
> +enc_info->Header.BufferId = MFX_EXTBUFF_ENCODED_FRAME_INFO;
> +enc_info->Header.BufferSz = sizeof (*enc_info);
> +bs->NumExtParam = 1;
> +enc_buf = av_mallocz(sizeof(mfxExtBuffer *));
> +enc_buf[0] = (mfxExtBuffer *)enc_info;
> +
> +bs->ExtParam = enc_buf;
> +}
> +#endif
> +
>  if (q->set_encode_ctrl_cb) {
>  q->set_encode_ctrl_cb(avctx, frame, _frame->enc_ctrl);
>  }
> @@ -1179,6 +1199,10 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  sync = av_mallocz(sizeof(*sync));
>  if (!sync) {
>  av_freep();
> + #if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264)
> +av_freep(_info);
> + #endif
>  av_packet_unref(_pkt);
>  return AVERROR(ENOMEM);
>  }
> @@ -1195,6 +1219,10 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  if (ret < 0) {
>  av_packet_unref(_pkt);
>  av_freep();
> +#if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264)
> +av_freep(_info);
> +#endif
>  av_freep();
>  return (ret == MFX_ERR_MORE_DATA) ?
> 0 : ff_qsv_print_error(avctx, ret, "Error during encoding");
> @@ -1211,6 +1239,10 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  av_freep();
>  av_packet_unref(_pkt);
>  av_freep();
> +#if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264)
> +av_freep(_info);
> +#endif
>  }
>  
>  return 0;
> @@ -1230,6 +1262,9 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext 
> *q,
>  AVPacket new_pkt;
>  mfxBitstream *bs;
>  mfxSyncPoint *sync;
> +#if QSV_VERSION_ATLEAST(1, 26)
> +mfxExtAVCEncodedFrameInfo *enc_info;
> +#endif
>  
>  av_fifo_generic_read(q->async_fifo, _pkt, sizeof(new_pkt), NULL);
>  av_fifo_generic_read(q->async_fifo, ,sizeof(sync),NULL);
> @@ -1258,6 +1293,14 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  
> +#if QSV_VERSION_ATLEAST(1, 26)
> +if (avctx->codec_id == AV_CODEC_ID_H264) {
> +enc_info = (mfxExtAVCEncodedFrameInfo *)(*bs->ExtParam);
> +av_log(avctx, AV_LOG_DEBUG, "QP is %d\n", enc_info->QP);

I think you should use ff_side_data_set_encoder_stats() for this instead.

> +q->sum_frame_qp += enc_info->QP;
> +av_freep(_info);
> +}
> +#endif
>  av_freep();
>  av_freep();
>  
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index b2d6355..3784a82 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -102,6 +102,8 @@ typedef struct QSVEncContext {
>  int width_align;
>  int height_align;
>  
> +int sum_frame_qp;
> +
>  mfxVideoParam param;
>  mfxFrameAllocRequest req;
>  
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> index 5c262e5..b87bef6 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -95,6 +95,11 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>  {
>  QSVH264EncContext *q = avctx->priv_data;
>  
> +#if QSV_VERSION_ATLEAST(1, 26)
> +av_log(avctx, AV_LOG_VERBOSE, "encoded %d frames, avarge qp is %.2f\n",
> +avctx->frame_number,(double)q->qsv.sum_frame_qp / 
> avctx->frame_number);
> +#endif
> +
>  return ff_qsv_enc_close(avctx, >qsv);
>  }


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

Re: [FFmpeg-devel] [PATCH] avs2: Correct expression error and simplify log

[James Almer]

On 8/6/2018 8:34 PM, Huiwen Ren wrote:
> 
> 在 2018-08-07 02:09:34，"James Almer"  写道：
>> On 8/6/2018 11:21 AM, Gyan Doshi wrote:
>>>
>>>
>>> On 06-08-2018 07:13 PM, hwren wrote:
>>>
 -    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE
 1857.4"),
 +    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for
 AVS2-P2/IEEE1857.4"),
>>>
>>> "Decoder for" is not needed. The flag indicates its role in `ffmpeg
>>> -codecs`.
>>
>> The correct string considering this is a decoder using an external
>> library would be something like "libdavs2 AVS2-P2/IEEE1857.4"
> 
> "AVS2-P2/IEEE1857.4 external decoder wrapper"?

No, look at libopenh264dec.c, libvpxdec.c, etc. They all have a
long_name field listing the name of the external library followed by the
codec they support.

OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
libvpx VP9
libaom AV1
Fraunhofer FDK AAC
libopus Opus

So "libdavs2 AVS2-P2/IEEE1857.4" would be the correct string here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Support negative value of the @r attrbute of S in SegmentTimeline element

[Liu Steven]

> 在 2018年8月7日，上午10:50，sanil  写道：
> 
> Hi,
> The following patch supports parsing negative value of the @r attribute of S 
> in SegmentTimeline element.
> 
> Example streams:
> 1. http://dash.edgesuite.net/dash264/TestCases/1c/qualcomm/1/MultiRate.mpd
> 2. http://dash.edgesuite.net/dash264/TestCases/1c/qualcomm/2/MultiRate.mpd
> 
> ---
> libavformat/dashdec.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 89f3ac2..ea960bc 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -262,6 +262,12 @@ static int64_t 
> get_segment_start_time_based_on_timeline(struct representation *p
> goto finish;
> 
> start_time += pls->timelines[i]->duration;
> +
> +if (pls->timelines[i]->repeat == -1) {
> +start_time = pls->timelines[i]->duration * cur_seq_no;
> +goto finish;
> +}
> +
> for (j = 0; j < pls->timelines[i]->repeat; j++) {
> num++;
> if (num == cur_seq_no)
> @@ -1341,9 +1347,15 @@ static int64_t calc_max_seg_no(struct representation 
> *pls, DASHContext *c)
> } else if (pls->n_timelines) {
> int i = 0;
> num = pls->first_seq_no + pls->n_timelines - 1;
> -for (i = 0; i < pls->n_timelines; i++) {
> -num += pls->timelines[i]->repeat;
> + for (i = 0; i < pls->n_timelines; i++) {
> +if (pls->timelines[i]->repeat == -1) {
> +int length_of_each_segment = 
> pls->timelines[i]->duration/pls->fragment_timescale;
> +num =  c->period_duration/length_of_each_segment;
> +} else {
> +num += pls->timelines[i]->repeat;
> +}
> }
> +
> } else if (c->is_live && pls->fragment_duration) {
> num = pls->first_seq_no + (((get_current_time_in_sec() - 
> c->availability_start_time)) * pls->fragment_timescale)  / 
> pls->fragment_duration;
> } else if (pls->fragment_duration) {
> @@ -1952,7 +1964,7 @@ static int dash_read_header(AVFormatContext *s)
> ++stream_index;
> }
> 
> -  c->is_init_section_common_audio = is_common_init_section_exist(c->audios, 
> c->n_audios);
> +c->is_init_section_common_audio = 
> is_common_init_section_exist(c->audios, c->n_audios);
> 
> for (i = 0; i < c->n_audios; i++) {
> struct representation *cur_audio = c->audios[i];
> -- 
> 
> Thanks,
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM


Thanks

Steven



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

[FFmpeg-devel] [PATCH] libavformat/dashdec: Support negative value of the @r attrbute of S in SegmentTimeline element

[sanil]

Hi,
The following patch supports parsing negative value of the @r attribute of S in 
SegmentTimeline element.

Example streams:
1. http://dash.edgesuite.net/dash264/TestCases/1c/qualcomm/1/MultiRate.mpd
2. http://dash.edgesuite.net/dash264/TestCases/1c/qualcomm/2/MultiRate.mpd

---
 libavformat/dashdec.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 89f3ac2..ea960bc 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -262,6 +262,12 @@ static int64_t 
get_segment_start_time_based_on_timeline(struct representation *p
 goto finish;
 
 start_time += pls->timelines[i]->duration;
+
+if (pls->timelines[i]->repeat == -1) {
+start_time = pls->timelines[i]->duration * cur_seq_no;
+goto finish;
+}
+
 for (j = 0; j < pls->timelines[i]->repeat; j++) {
 num++;
 if (num == cur_seq_no)
@@ -1341,9 +1347,15 @@ static int64_t calc_max_seg_no(struct representation 
*pls, DASHContext *c)
 } else if (pls->n_timelines) {
 int i = 0;
 num = pls->first_seq_no + pls->n_timelines - 1;
-for (i = 0; i < pls->n_timelines; i++) {
-num += pls->timelines[i]->repeat;
+ for (i = 0; i < pls->n_timelines; i++) {
+if (pls->timelines[i]->repeat == -1) {
+int length_of_each_segment = 
pls->timelines[i]->duration/pls->fragment_timescale;
+num =  c->period_duration/length_of_each_segment;
+} else {
+num += pls->timelines[i]->repeat;
+}
 }
+
 } else if (c->is_live && pls->fragment_duration) {
 num = pls->first_seq_no + (((get_current_time_in_sec() - 
c->availability_start_time)) * pls->fragment_timescale)  / 
pls->fragment_duration;
 } else if (pls->fragment_duration) {
@@ -1952,7 +1964,7 @@ static int dash_read_header(AVFormatContext *s)
 ++stream_index;
 }
 
-  c->is_init_section_common_audio = is_common_init_section_exist(c->audios, 
c->n_audios);
+c->is_init_section_common_audio = is_common_init_section_exist(c->audios, 
c->n_audios);
 
 for (i = 0; i < c->n_audios; i++) {
 struct representation *cur_audio = c->audios[i];
-- 

Thanks,
2.7.4

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/encode: fix frame_number double-counted

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Saturday, July 28, 2018 3:28 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/encode: fix frame_number
> double-counted
> 
> On Thu, Jul 26, 2018 at 03:51:07PM +0800, Zhong Li wrote:
> > Encoder frame_number may be double-counted if some frames are cached
> and then flushed.
> > Take qsv encoder (some frames are cached firsty for asynchronism) as
> > example, ./ffmpeg -loglevel verbose -hwaccel qsv -c:v h264_qsv -i
> > in.mp4 -vframes 100 -c:v h264_qsv out.mp4 frame_number passed to
> encoder is double-counted and larger than the accurate value.
> > Libx264 encoding with B frames can also reproduce it.
> >
> > Signed-off-by: Zhong Li 
> > ---
> >  libavcodec/encode.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> probably ok

Thanks for review. Will push it if without any other comments.


> [...]
> --
> Michael GnuPG fingerprint:
> 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Into a blind darkness they enter who follow after the Ignorance, they as if
> into a greater darkness enter who devote themselves to the Knowledge
> alone. -- Isha Upanishad
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining

[Ronald S. Bultje]

Hi,

On Mon, Aug 6, 2018 at 3:00 PM, Michael Niedermayer 
wrote:

> On Tue, Aug 07, 2018 at 01:05:51AM +0800, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Aug 5, 2018, 9:17 AM Michael Niedermayer  >
> > wrote:
> >
> > > Fixes: Timeout
> > > Fixes:
> > > 9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_
> VP9_fuzzer-5707345857347584
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by
> > >  ffmpegSigned-off-by>:
> > > Michael Niedermayer 
> > > ---
> > >  libavcodec/vp9.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > index b1178c9c0c..4ca51ec108 100644
> > > --- a/libavcodec/vp9.c
> > > +++ b/libavcodec/vp9.c
> > > @@ -1302,6 +1302,9 @@ static int decode_tiles(AVCodecContext *avctx,
> > >  memset(lflvl_ptr->mask, 0,
> > > sizeof(lflvl_ptr->mask));
> > >  }
> > >
> > > +if (td->c->end <= td->c->buffer && td->c->bits >=
> 0) {
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > >  if (s->pass == 2) {
> > >  decode_sb_mem(td, row, col, lflvl_ptr,
> > >yoff2, uvoff2, BL_64X64);
> > >
> >
> > I don't think this matches spec. Implementations could use this to store
> > auxiliary data.
>
> This checks, or rather is intended to check for a premature end of the
> input.
> Am i missing something? because a premature end of input seems not to lead
> to more (auxiliary or other) data in the input.


Hm, I misread it, sorry about that, my bad. Please ignore my first review.

Is end == buffer && bits == 0 something that can happen on valid input if
things just align properly? Otherwise looks OK.

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

[Sasi Inguva]

Attaching the fate file.

On Mon, Aug 6, 2018 at 4:33 PM  wrote:

> From: Sasi Inguva 
>
> Fixes vorbis mp4 audio files, with edit list specified. Since
> st->skip_samples is not set in case of vorbis , ffmpeg computes the
> start_time as negative.
>
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c  | 4 ++--
>  tests/fate/mov.mak | 5 +
>  tests/ref/fate/mov-neg-firstpts-discard-vorbis | 3 +++
>  3 files changed, 10 insertions(+), 2 deletions(-)
>  create mode 100644 tests/ref/fate/mov-neg-firstpts-discard-vorbis
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 82cd410a72..c0f90edef7 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3684,9 +3684,9 @@ static void mov_fix_index(MOVContext *mov, AVStream
> *st)
>  st->index_entries[i].timestamp -= msc->min_corrected_pts;
>  }
>  }
> -// Start time should be equal to zero or the duration of any
> empty edits.
> -st->start_time = empty_edits_sum_duration;
>  }
> +// Start time should be equal to zero or the duration of any empty
> edits.
> +st->start_time = empty_edits_sum_duration;
>
>  // Update av stream length, if it ends up shorter than the track's
> media duration
>  st->duration = FFMIN(st->duration, edit_list_dts_entry_end -
> start_dts);
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index 6f0e28d21e..3d9e4280bb 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -19,6 +19,7 @@ FATE_MOV = fate-mov-3elist \
> fate-mov-stream-shorter-than-movie \
>
>  FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
> +   fate-mov-neg-firstpts-discard-vorbis \
> fate-mov-aac-2048-priming \
> fate-mov-zombie \
> fate-mov-init-nonkeyframe \
> @@ -89,6 +90,10 @@ fate-mov-bbi-elst-starts-b: CMD = framemd5 -flags
> +bitexact -acodec aac_fixed -i
>  # Makes sure that the stream start_time is not negative when the first
> packet is a DISCARD packet with negative timestamp.
>  fate-mov-neg-firstpts-discard: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
> -show_entries stream=start_time -bitexact
> $(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard.mov
>
> +# Makes sure that the VORBIS audio stream start_time is not negative when
> the first few packets are DISCARD packets
> +# with negative timestamps (skip_samples is not set for Vorbis, so ffmpeg
> computes start_time as negative if not specified by demuxer).
> +fate-mov-neg-firstpts-discard-vorbis: CMD = run
> ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream=start_time -bitexact
> $(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard_vorbis.mp4
> +
>  # Makes sure that expected frames are generated for
> mov_neg_first_pts_discard.mov with -vsync 1
>  fate-mov-neg-firstpts-discard-frames: CMD = framemd5 -flags +bitexact -i
> $(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard.mov -vsync 1
>
> diff --git a/tests/ref/fate/mov-neg-firstpts-discard-vorbis
> b/tests/ref/fate/mov-neg-firstpts-discard-vorbis
> new file mode 100644
> index 00..2e295e3b68
> --- /dev/null
> +++ b/tests/ref/fate/mov-neg-firstpts-discard-vorbis
> @@ -0,0 +1,3 @@
> +[STREAM]
> +start_time=0.00
> +[/STREAM]
> --
> 2.18.0.597.ga71716f1ad-goog
>
>


mov_neg_first_pts_discard_vorbis.mp4
Description: video/mp4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov.c: Set start_time for audio too (in case of edit lists).

[isasi-at-google . com]

From: Sasi Inguva 

Fixes vorbis mp4 audio files, with edit list specified. Since
st->skip_samples is not set in case of vorbis , ffmpeg computes the
start_time as negative.

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c  | 4 ++--
 tests/fate/mov.mak | 5 +
 tests/ref/fate/mov-neg-firstpts-discard-vorbis | 3 +++
 3 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/mov-neg-firstpts-discard-vorbis

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 82cd410a72..c0f90edef7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3684,9 +3684,9 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
 st->index_entries[i].timestamp -= msc->min_corrected_pts;
 }
 }
-// Start time should be equal to zero or the duration of any empty 
edits.
-st->start_time = empty_edits_sum_duration;
 }
+// Start time should be equal to zero or the duration of any empty edits.
+st->start_time = empty_edits_sum_duration;
 
 // Update av stream length, if it ends up shorter than the track's media 
duration
 st->duration = FFMIN(st->duration, edit_list_dts_entry_end - start_dts);
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 6f0e28d21e..3d9e4280bb 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -19,6 +19,7 @@ FATE_MOV = fate-mov-3elist \
fate-mov-stream-shorter-than-movie \
 
 FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
+   fate-mov-neg-firstpts-discard-vorbis \
fate-mov-aac-2048-priming \
fate-mov-zombie \
fate-mov-init-nonkeyframe \
@@ -89,6 +90,10 @@ fate-mov-bbi-elst-starts-b: CMD = framemd5 -flags +bitexact 
-acodec aac_fixed -i
 # Makes sure that the stream start_time is not negative when the first packet 
is a DISCARD packet with negative timestamp.
 fate-mov-neg-firstpts-discard: CMD = run ffprobe$(PROGSSUF)$(EXESUF) 
-show_entries stream=start_time -bitexact 
$(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard.mov
 
+# Makes sure that the VORBIS audio stream start_time is not negative when the 
first few packets are DISCARD packets
+# with negative timestamps (skip_samples is not set for Vorbis, so ffmpeg 
computes start_time as negative if not specified by demuxer).
+fate-mov-neg-firstpts-discard-vorbis: CMD = run ffprobe$(PROGSSUF)$(EXESUF) 
-show_entries stream=start_time -bitexact 
$(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard_vorbis.mp4
+
 # Makes sure that expected frames are generated for 
mov_neg_first_pts_discard.mov with -vsync 1
 fate-mov-neg-firstpts-discard-frames: CMD = framemd5 -flags +bitexact -i 
$(TARGET_SAMPLES)/mov/mov_neg_first_pts_discard.mov -vsync 1
 
diff --git a/tests/ref/fate/mov-neg-firstpts-discard-vorbis 
b/tests/ref/fate/mov-neg-firstpts-discard-vorbis
new file mode 100644
index 00..2e295e3b68
--- /dev/null
+++ b/tests/ref/fate/mov-neg-firstpts-discard-vorbis
@@ -0,0 +1,3 @@
+[STREAM]
+start_time=0.00
+[/STREAM]
-- 
2.18.0.597.ga71716f1ad-goog

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

Re: [FFmpeg-devel] [PATCH] avs2: Correct expression error and simplify log

[Huiwen Ren]

在 2018-08-07 02:09:34，"James Almer"  写道：
>On 8/6/2018 11:21 AM, Gyan Doshi wrote:
>> 
>> 
>> On 06-08-2018 07:13 PM, hwren wrote:
>> 
>>> -    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE
>>> 1857.4"),
>>> +    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for
>>> AVS2-P2/IEEE1857.4"),
>> 
>> "Decoder for" is not needed. The flag indicates its role in `ffmpeg
>> -codecs`.
>
>The correct string considering this is a decoder using an external
>library would be something like "libdavs2 AVS2-P2/IEEE1857.4"

"AVS2-P2/IEEE1857.4 external decoder wrapper"?

>
>> 
>> Rest docs LGTM
>> 
>> 
>> Thanks,
>> Gyan
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Mixture of homographies video stabilization

[Michael Niedermayer]

On Mon, Aug 06, 2018 at 03:49:00PM +0100, Matthew Lai wrote:
> Sorry the matrices are actually 3x3, and most of the time will be spent on
> solving a 8x9 * 9x1 = 0 systems. And then all the feature points will have
> to be multiplied by the 9x1 matrix reshaped into 3x3.
> 
> The math is here:
> https://www.uio.no/studier/emner/matnat/its/UNIK4690/v16/forelesninger/lecture_4_3-estimating-homographies-from-feature-correspondences.pdf
> 

> Multiplying 3x3 matrices is trivial, but SVD isn't. SVD is the standard
> approach to decompose a homography matrix. I have not looked into
> alternative approaches.

Iam a bit puzzled.
IIUC SVD is the slowest part of the filter from what you write above and we
have no evidence that it is needed. And you did not look at alternatives ? ;)

Quoting "Calibration-Free Rolling Shutter Removal" from
   Matthias Grundmann1,2   Vivek Kwatra1  Daniel Castro2 
Irfan Essa1,2
...
Aggregating all linear constraints Ax for each feature match
(x, y) yields an homogenous linear system, which can be
solved for under the constraint ||h||2 = 1 using the SVD
of A. Alternatively, the system can be transformed into a
homogenous system by explicitly setting the bottom right
element of each homography to 1, i.e. hk (3, 3) = 1 for all k,
which is a reasonable choice for video, as the small inter-
frame motions are virtually free of degenerated cases.

this sounds like theres a very easy way to avoid
SVD.
from what i remember the main point of
SVD is its ability to work with unstable / degenerate cases.
But, in which case is such a degenrate case a good estimation for the
motion/transform ?


> 
> Cool! Will see re. ME. It's likely to be the performance-limiting part, and
> it would be nice to run that on GPU.

just a quick reference point, ME for encoding is many times real time.
for example a 720x576 video encodes here with 1227 fps on a many years old
box. That includes alot of other things like decoding and all the bitstream
encoding and transforms, not just ME. And this is 100% on the CPU

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

[FFmpeg-devel] [PATCH]lavf/mov: Force hevc codec_id for code-point hvc1 and hvcC extradata

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #7347 for me.

Please comment, Carl Eugen
From 4f2bed32efe641d2fe21899a0b1d724ef225936a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 7 Aug 2018 00:33:40 +0200
Subject: [PATCH] lavf/mov: Force HEVC codec_id for code-point dvh1 and an
 hvcC atom.

The mp4 registration authority accepted a code-point for Dolby Vision
hevc that was already used as a fourcc for DVCPRO 100.

Fixes ticket #7347.
---
 libavformat/mov.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 82cd410..6885ef3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1902,6 +1902,8 @@ static int mov_read_glbl(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 ret = ff_get_extradata(c->fc, st->codecpar, pb, atom.size);
 if (ret < 0)
 return ret;
+if (atom.type == MKTAG('h','v','c','C') && st->codecpar->codec_tag == MKTAG('d','v','h','1'))
+st->codecpar->codec_id = AV_CODEC_ID_HEVC;
 
 return 0;
 }
-- 
1.7.10.4

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

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

[Sergey Lavrushkin]

Updated patch.

2018-08-02 21:52 GMT+03:00 Sergey Lavrushkin :

> This patch removes conversions, declared inside the sr filter, and uses
> libswscale inside
> the filter to perform them for only Y channel of input. The sr filter
> still has uint
> formats as input, as it does not use chroma channels in models and these
> channels are
> upscaled using libswscale, float formats for input would cause unnecessary
> conversions
> during scaling for these channels.
>
> ---
>  libavfilter/vf_sr.c | 134 +++---
> --
>  1 file changed, 48 insertions(+), 86 deletions(-)
>
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 944a0e28e7..5ad1baa4c0 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -45,8 +45,8 @@ typedef struct SRContext {
>  DNNModel *model;
>  DNNData input, output;
>  int scale_factor;
> -struct SwsContext *sws_context;
> -int sws_slice_h;
> +struct SwsContext *sws_contexts[3];
> +int sws_slice_h, sws_input_linesize, sws_output_linesize;
>  } SRContext;
>
>  #define OFFSET(x) offsetof(SRContext, x)
> @@ -95,6 +95,10 @@ static av_cold int init(AVFilterContext *context)
>  return AVERROR(EIO);
>  }
>
> +sr_context->sws_contexts[0] = NULL;
> +sr_context->sws_contexts[1] = NULL;
> +sr_context->sws_contexts[2] = NULL;
> +
>  return 0;
>  }
>
> @@ -110,6 +114,7 @@ static int query_formats(AVFilterContext *context)
>  av_log(context, AV_LOG_ERROR, "could not create formats list\n");
>  return AVERROR(ENOMEM);
>  }
> +
>  return ff_set_common_formats(context, formats_list);
>  }
>
> @@ -140,21 +145,31 @@ static int config_props(AVFilterLink *inlink)
>  else{
>  outlink->h = sr_context->output.height;
>  outlink->w = sr_context->output.width;
> +sr_context->sws_contexts[1] = sws_getContext(sr_context->input.width,
> sr_context->input.height, AV_PIX_FMT_GRAY8,
> +
>  sr_context->input.width, sr_context->input.height, AV_PIX_FMT_GRAYF32,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_input_linesize = sr_context->input.width << 2;
> +sr_context->sws_contexts[2] = 
> sws_getContext(sr_context->output.width,
> sr_context->output.height, AV_PIX_FMT_GRAYF32,
> +
>  sr_context->output.width, sr_context->output.height, AV_PIX_FMT_GRAY8,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_output_linesize = sr_context->output.width << 2;
> +if (!sr_context->sws_contexts[1] || !sr_context->sws_contexts[2]){
> +av_log(context, AV_LOG_ERROR, "could not create SwsContext
> for conversions\n");
> +return AVERROR(ENOMEM);
> +}
>  switch (sr_context->model_type){
>  case SRCNN:
> -sr_context->sws_context = sws_getContext(inlink->w,
> inlink->h, inlink->format,
> - outlink->w,
> outlink->h, outlink->format, SWS_BICUBIC, NULL, NULL, NULL);
> -if (!sr_context->sws_context){
> -av_log(context, AV_LOG_ERROR, "could not create
> SwsContext\n");
> +sr_context->sws_contexts[0] = sws_getContext(inlink->w,
> inlink->h, inlink->format,
> + outlink->w,
> outlink->h, outlink->format,
> + SWS_BICUBIC,
> NULL, NULL, NULL);
> +if (!sr_context->sws_contexts[0]){
> +av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for scaling\n");
>  return AVERROR(ENOMEM);
>  }
>  sr_context->sws_slice_h = inlink->h;
>  break;
>  case ESPCN:
> -if (inlink->format == AV_PIX_FMT_GRAY8){
> -sr_context->sws_context = NULL;
> -}
> -else{
> +if (inlink->format != AV_PIX_FMT_GRAY8){
>  sws_src_h = sr_context->input.height;
>  sws_src_w = sr_context->input.width;
>  sws_dst_h = sr_context->output.height;
> @@ -184,13 +199,14 @@ static int config_props(AVFilterLink *inlink)
>  sws_dst_w = AV_CEIL_RSHIFT(sws_dst_w, 2);
>  break;
>  default:
> -av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for input pixel format");
> +av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for scaling for given input pixel format");
>  return AVERROR(EIO);
>  }
> -sr_context->sws_context = sws_getContext(sws_src_w,
> sws_src_h, AV_PIX_FMT_GRAY8,
> - sws_dst_w,
> sws_dst_h, AV_PIX_FMT_GRAY8, SWS_BICUBIC, NULL, NULL, NULL);
> -if (!sr_context->sws_context){
> -

[FFmpeg-devel] [PATCH] Documentation for sr filter

[Sergey Lavrushkin]

From f076c4be5455331958b928fcea6b3dd8da287527 Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin 
Date: Fri, 3 Aug 2018 17:24:00 +0300
Subject: [PATCH 9/9] doc/filters.texi: Adds documentation for sr filter.

---
 doc/filters.texi | 60 
 1 file changed, 60 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 0b0903e5a7..e2436a24e7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15394,6 +15394,66 @@ option may cause flicker since the B-Frames have often larger QP. Default is
 @code{0} (not enabled).
 @end table
 
+@section sr
+
+Scale the input by applying one of the super-resolution methods based on
+convolutional neural networks.
+
+Training scripts as well as scripts for model generation are provided in
+the repository @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+
+The filter accepts the following options:
+
+@table @option
+@item model
+Specify what super-resolution model to use. This option accepts the following values:
+
+@table @samp
+@item srcnn
+Super-Resolution Convolutional Neural Network model
+@url{https://arxiv.org/abs/1501.00092}.
+
+@item espcn
+Efficient Sub-Pixel Convolutional Neural Network model
+@url{https://arxiv.org/abs/1609.05158}.
+
+@end table
+
+Default value is @samp{srcnn}.
+
+@item dnn_backend
+Specify what DNN backend to use for model loading and execution. This option accepts
+the following values:
+
+@table @samp
+@item native
+Native implementation of DNN loading and execution.
+
+@item tensorflow
+TensorFlow backend @url{https://www.tensorflow.org/}. To enable this backend you
+need to install the TensorFlow for C library (see
+@url{https://www.tensorflow.org/install/install_c}) and configure FFmpeg with
+@code{--enable-libtensorflow}
+
+@end table
+
+Default value is @samp{native}.
+
+@item scale_factor
+Set scale factor for SRCNN model, for which custom model file was provided.
+Allowed values are @code{2}, @code{3} and @code{4}. Scale factor is neccessary
+for SRCNN model, because it accepts input upscaled using bicubic upscaling with
+proper scale factor.
+
+Default value is @code{2}.
+
+@item model_filename
+Set path to model file specifying network architecture and its parameters.
+Note that different backends use different file format. If path to model
+file is not specified, built-in models for 2x upscaling are used.
+
+@end table
+
 @anchor{subtitles}
 @section subtitles
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 7/7] libavfilter: Adds proper file descriptions to dnn_srcnn.h and dnn_espcn.h.

[Sergey Lavrushkin]

Updated patch.

2018-08-02 21:52 GMT+03:00 Sergey Lavrushkin :

> ---
>  libavfilter/dnn_espcn.h | 3 ++-
>  libavfilter/dnn_srcnn.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/dnn_espcn.h b/libavfilter/dnn_espcn.h
> index 9344aa90fe..e0013fe1dd 100644
> --- a/libavfilter/dnn_espcn.h
> +++ b/libavfilter/dnn_espcn.h
> @@ -20,7 +20,8 @@
>
>  /**
>   * @file
> - * Default cnn weights for x2 upscaling with espcn model.
> + * This file contains CNN weights for ESPCN model (
> https://arxiv.org/abs/1609.05158),
> + * auto generated by scripts provided in the repository:
> https://github.com/HighVoltageRocknRoll/sr.git.
>   */
>
>  #ifndef AVFILTER_DNN_ESPCN_H
> diff --git a/libavfilter/dnn_srcnn.h b/libavfilter/dnn_srcnn.h
> index 4f5332ce18..8bf563bd62 100644
> --- a/libavfilter/dnn_srcnn.h
> +++ b/libavfilter/dnn_srcnn.h
> @@ -20,7 +20,8 @@
>
>  /**
>   * @file
> - * Default cnn weights for x2 upscaling with srcnn model.
> + * This file contains CNN weights for SRCNN model (
> https://arxiv.org/abs/1501.00092),
> + * auto generated by scripts provided in the repository:
> https://github.com/HighVoltageRocknRoll/sr.git.
>   */
>
>  #ifndef AVFILTER_DNN_SRCNN_H
> --
> 2.14.1
>
>
From c2060d992664087fcfffa447768a6ad8f5e38623 Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin 
Date: Thu, 2 Aug 2018 19:56:23 +0300
Subject: [PATCH 8/9] libavfilter: Adds proper file descriptions to dnn_srcnn.h
 and dnn_espcn.h.

---
 libavfilter/dnn_espcn.h | 3 ++-
 libavfilter/dnn_srcnn.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavfilter/dnn_espcn.h b/libavfilter/dnn_espcn.h
index 9344aa90fe..e0013fe1dd 100644
--- a/libavfilter/dnn_espcn.h
+++ b/libavfilter/dnn_espcn.h
@@ -20,7 +20,8 @@
 
 /**
  * @file
- * Default cnn weights for x2 upscaling with espcn model.
+ * This file contains CNN weights for ESPCN model (https://arxiv.org/abs/1609.05158),
+ * auto generated by scripts provided in the repository: https://github.com/HighVoltageRocknRoll/sr.git.
  */
 
 #ifndef AVFILTER_DNN_ESPCN_H
diff --git a/libavfilter/dnn_srcnn.h b/libavfilter/dnn_srcnn.h
index 4f5332ce18..8bf563bd62 100644
--- a/libavfilter/dnn_srcnn.h
+++ b/libavfilter/dnn_srcnn.h
@@ -20,7 +20,8 @@
 
 /**
  * @file
- * Default cnn weights for x2 upscaling with srcnn model.
+ * This file contains CNN weights for SRCNN model (https://arxiv.org/abs/1501.00092),
+ * auto generated by scripts provided in the repository: https://github.com/HighVoltageRocknRoll/sr.git.
  */
 
 #ifndef AVFILTER_DNN_SRCNN_H
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 5/7] libavfilter/dnn_backend_tf.c: Fixes ff_dnn_free_model_tf.

[Sergey Lavrushkin]

Updated patch.
From 11186187d0b5a4725415a91947f38d5e166e024c Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin 
Date: Tue, 31 Jul 2018 18:40:24 +0300
Subject: [PATCH 6/9] libavfilter/dnn_backend_tf.c: Fixes ff_dnn_free_model_tf.

---
 libavfilter/dnn_backend_tf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
index bd21137a8a..971a914c67 100644
--- a/libavfilter/dnn_backend_tf.c
+++ b/libavfilter/dnn_backend_tf.c
@@ -571,7 +571,9 @@ void ff_dnn_free_model_tf(DNNModel **model)
 if (tf_model->input_tensor){
 TF_DeleteTensor(tf_model->input_tensor);
 }
-av_freep(_model->output_data->data);
+if (tf_model->output_data){
+av_freep(&(tf_model->output_data->data));
+}
 av_freep(_model);
 av_freep(model);
 }
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Sergey Lavrushkin]

I split patch to one for libavutil and another for libswscale,
also added LUT for unscaled conversion, added
conversions for scaling and updated fate tests.
From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin 
Date: Fri, 3 Aug 2018 18:02:49 +0300
Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.

---
 libavutil/pixdesc.c  | 22 ++
 libavutil/pixfmt.h   |  5 +
 libavutil/version.h  |  2 +-
 tests/ref/fate/sws-pixdesc-query |  3 +++
 4 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 96e079584a..970a83214c 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 .name  = "opencl",
 .flags = AV_PIX_FMT_FLAG_HWACCEL,
 },
+[AV_PIX_FMT_GRAYF32BE] = {
+.name = "grayf32be",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },   /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32be",
+},
+[AV_PIX_FMT_GRAYF32LE] = {
+.name = "grayf32le",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 },   /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32le",
+},
 };
 #if FF_API_PLUS1_MINUS1
 FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 2b3307845e..7b254732d8 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -337,6 +337,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_GRAY14BE,   ///

Re: [FFmpeg-devel] [PATCH 3/7] libavfilter: Fixes warnings for unused variables in dnn_srcnn.h, dnn_espcn.h, dnn_backend_tf.c.

[Sergey Lavrushkin]

Made variables static.

2018-08-06 21:19 GMT+03:00 Pedro Arthur :

> 2018-08-02 15:52 GMT-03:00 Sergey Lavrushkin :
> > ---
> >  libavfilter/dnn_backend_tf.c | 64 ++
> +-
> >  libavfilter/dnn_espcn.h  | 37 -
> >  libavfilter/dnn_srcnn.h  | 35 
> >  3 files changed, 63 insertions(+), 73 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> > index 6307c794a5..7a4ad72d27 100644
> > --- a/libavfilter/dnn_backend_tf.c
> > +++ b/libavfilter/dnn_backend_tf.c
> > @@ -374,9 +374,71 @@ DNNModel *ff_dnn_load_default_model_tf(DNNDefaultModel
> model_type)
> >  TFModel *tf_model = NULL;
> >  TF_OperationDescription *op_desc;
> >  TF_Operation *op;
> > -TF_Operation *const_ops_buffer[6];
> >  TF_Output input;
> >  int64_t input_shape[] = {1, -1, -1, 1};
> > +const char tanh[] = "Tanh";
> > +const char sigmoid[] = "Sigmoid";
> > +const char relu[] = "Relu";
> > +
> > +const float *srcnn_consts[] = {
> > +srcnn_conv1_kernel,
> > +srcnn_conv1_bias,
> > +srcnn_conv2_kernel,
> > +srcnn_conv2_bias,
> > +srcnn_conv3_kernel,
> > +srcnn_conv3_bias
> > +};
> > +const long int *srcnn_consts_dims[] = {
> > +srcnn_conv1_kernel_dims,
> > +srcnn_conv1_bias_dims,
> > +srcnn_conv2_kernel_dims,
> > +srcnn_conv2_bias_dims,
> > +srcnn_conv3_kernel_dims,
> > +srcnn_conv3_bias_dims
> > +};
> > +const int srcnn_consts_dims_len[] = {
> > +4,
> > +1,
> > +4,
> > +1,
> > +4,
> > +1
> > +};
> > +const char *srcnn_activations[] = {
> > +relu,
> > +relu,
> > +relu
> > +};
> > +
> > +const float *espcn_consts[] = {
> > +espcn_conv1_kernel,
> > +espcn_conv1_bias,
> > +espcn_conv2_kernel,
> > +espcn_conv2_bias,
> > +espcn_conv3_kernel,
> > +espcn_conv3_bias
> > +};
> > +const long int *espcn_consts_dims[] = {
> > +espcn_conv1_kernel_dims,
> > +espcn_conv1_bias_dims,
> > +espcn_conv2_kernel_dims,
> > +espcn_conv2_bias_dims,
> > +espcn_conv3_kernel_dims,
> > +espcn_conv3_bias_dims
> > +};
> > +const int espcn_consts_dims_len[] = {
> > +4,
> > +1,
> > +4,
> > +1,
> > +4,
> > +1
> > +};
> > +const char *espcn_activations[] = {
> > +tanh,
> > +tanh,
> > +sigmoid
> > +};
> >
> >  input.index = 0;
> >
> > diff --git a/libavfilter/dnn_espcn.h b/libavfilter/dnn_espcn.h
> > index a0dd61cd0d..9344aa90fe 100644
> > --- a/libavfilter/dnn_espcn.h
> > +++ b/libavfilter/dnn_espcn.h
> > @@ -5398,41 +5398,4 @@ static const long int espcn_conv3_bias_dims[] = {
> >  4
> >  };
> >
> > -static const float *espcn_consts[] = {
> > -espcn_conv1_kernel,
> > -espcn_conv1_bias,
> > -espcn_conv2_kernel,
> > -espcn_conv2_bias,
> > -espcn_conv3_kernel,
> > -espcn_conv3_bias
> > -};
> > -
> > -static const long int *espcn_consts_dims[] = {
> > -espcn_conv1_kernel_dims,
> > -espcn_conv1_bias_dims,
> > -espcn_conv2_kernel_dims,
> > -espcn_conv2_bias_dims,
> > -espcn_conv3_kernel_dims,
> > -espcn_conv3_bias_dims
> > -};
> > -
> > -static const int espcn_consts_dims_len[] = {
> > -4,
> > -1,
> > -4,
> > -1,
> > -4,
> > -1
> > -};
> > -
> > -static const char espcn_tanh[] = "Tanh";
> > -
> > -static const char espcn_sigmoid[] = "Sigmoid";
> > -
> > -static const char *espcn_activations[] = {
> > -espcn_tanh,
> > -espcn_tanh,
> > -espcn_sigmoid
> > -};
> > -
> >  #endif
> > diff --git a/libavfilter/dnn_srcnn.h b/libavfilter/dnn_srcnn.h
> > index 26143654b8..4f5332ce18 100644
> > --- a/libavfilter/dnn_srcnn.h
> > +++ b/libavfilter/dnn_srcnn.h
> > @@ -2110,39 +2110,4 @@ static const long int srcnn_conv3_bias_dims[] = {
> >  1
> >  };
> >
> > -static const float *srcnn_consts[] = {
> > -srcnn_conv1_kernel,
> > -srcnn_conv1_bias,
> > -srcnn_conv2_kernel,
> > -srcnn_conv2_bias,
> > -srcnn_conv3_kernel,
> > -srcnn_conv3_bias
> > -};
> > -
> > -static const long int *srcnn_consts_dims[] = {
> > -srcnn_conv1_kernel_dims,
> > -srcnn_conv1_bias_dims,
> > -srcnn_conv2_kernel_dims,
> > -srcnn_conv2_bias_dims,
> > -srcnn_conv3_kernel_dims,
> > -srcnn_conv3_bias_dims
> > -};
> > -
> > -static const int srcnn_consts_dims_len[] = {
> > -4,
> > -1,
> > -4,
> > -1,
> > -4,
> > -1
> > -};
> > -
> > -static const char srcnn_relu[] = "Relu";
> > -
> > -static const char *srcnn_activations[] = {
> > -srcnn_relu,
> > -srcnn_relu,
> > -srcnn_relu
> > -};
> > -
> >  #endif
> > --
> > 2.14.1
> >
> > ___
> > ffmpeg-devel mailing 

Re: [FFmpeg-devel] [PATCH 2/7] libavfilter: Code style fixes for pointers in DNN module and sr filter.

[Sergey Lavrushkin]

Updated patch.

2018-08-06 17:55 GMT+03:00 Pedro Arthur :

> 2018-08-02 15:52 GMT-03:00 Sergey Lavrushkin :
> > ---
> >  libavfilter/dnn_backend_native.c |  84 +++---
> >  libavfilter/dnn_backend_native.h |   8 +--
> >  libavfilter/dnn_backend_tf.c | 108 +++---
> -
> >  libavfilter/dnn_backend_tf.h |   8 +--
> >  libavfilter/dnn_espcn.h  |   6 +--
> >  libavfilter/dnn_interface.c  |   4 +-
> >  libavfilter/dnn_interface.h  |  16 +++---
> >  libavfilter/dnn_srcnn.h  |   6 +--
> >  libavfilter/vf_sr.c  |  60 +++---
> >  9 files changed, 150 insertions(+), 150 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_
> native.c
> > index 3e6b86280d..baefea7fcb 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -34,15 +34,15 @@ typedef enum {RELU, TANH, SIGMOID} ActivationFunc;
> >
> >  typedef struct Layer{
> >  LayerType type;
> > -float* output;
> > -void* params;
> > +float *output;
> > +void *params;
> >  } Layer;
> >
> >  typedef struct ConvolutionalParams{
> >  int32_t input_num, output_num, kernel_size;
> >  ActivationFunc activation;
> > -float* kernel;
> > -float* biases;
> > +float *kernel;
> > +float *biases;
> >  } ConvolutionalParams;
> >
> >  typedef struct InputParams{
> > @@ -55,16 +55,16 @@ typedef struct DepthToSpaceParams{
> >
> >  // Represents simple feed-forward convolutional network.
> >  typedef struct ConvolutionalNetwork{
> > -Layer* layers;
> > +Layer *layers;
> >  int32_t layers_num;
> >  } ConvolutionalNetwork;
> >
> > -static DNNReturnType set_input_output_native(void* model, DNNData*
> input, DNNData* output)
> > +static DNNReturnType set_input_output_native(void *model, DNNData
> *input, DNNData *output)
> >  {
> > -ConvolutionalNetwork* network = (ConvolutionalNetwork*)model;
> > -InputParams* input_params;
> > -ConvolutionalParams* conv_params;
> > -DepthToSpaceParams* depth_to_space_params;
> > +ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> > +InputParams *input_params;
> > +ConvolutionalParams *conv_params;
> > +DepthToSpaceParams *depth_to_space_params;
> >  int cur_width, cur_height, cur_channels;
> >  int32_t layer;
> >
> > @@ -72,7 +72,7 @@ static DNNReturnType set_input_output_native(void*
> model, DNNData* input, DNNDat
> >  return DNN_ERROR;
> >  }
> >  else{
> > -input_params = (InputParams*)network->layers[0].params;
> > +input_params = (InputParams *)network->layers[0].params;
> >  input_params->width = cur_width = input->width;
> >  input_params->height = cur_height = input->height;
> >  input_params->channels = cur_channels = input->channels;
> > @@ -88,14 +88,14 @@ static DNNReturnType set_input_output_native(void*
> model, DNNData* input, DNNDat
> >  for (layer = 1; layer < network->layers_num; ++layer){
> >  switch (network->layers[layer].type){
> >  case CONV:
> > -conv_params = (ConvolutionalParams*)network-
> >layers[layer].params;
> > +conv_params = (ConvolutionalParams *)network->layers[layer].
> params;
> >  if (conv_params->input_num != cur_channels){
> >  return DNN_ERROR;
> >  }
> >  cur_channels = conv_params->output_num;
> >  break;
> >  case DEPTH_TO_SPACE:
> > -depth_to_space_params = (DepthToSpaceParams*)network->
> layers[layer].params;
> > +depth_to_space_params = (DepthToSpaceParams
> *)network->layers[layer].params;
> >  if (cur_channels % (depth_to_space_params->block_size *
> depth_to_space_params->block_size) != 0){
> >  return DNN_ERROR;
> >  }
> > @@ -127,16 +127,16 @@ static DNNReturnType set_input_output_native(void*
> model, DNNData* input, DNNDat
> >  // layers_num,layer_type,layer_parameterss,layer_type,layer_
> parameters...
> >  // For CONV layer: activation_function, input_num, output_num,
> kernel_size, kernel, biases
> >  // For DEPTH_TO_SPACE layer: block_size
> > -DNNModel* ff_dnn_load_model_native(const char* model_filename)
> > +DNNModel *ff_dnn_load_model_native(const char *model_filename)
> >  {
> > -DNNModel* model = NULL;
> > -ConvolutionalNetwork* network = NULL;
> > -AVIOContext* model_file_context;
> > +DNNModel *model = NULL;
> > +ConvolutionalNetwork *network = NULL;
> > +AVIOContext *model_file_context;
> >  int file_size, dnn_size, kernel_size, i;
> >  int32_t layer;
> >  LayerType layer_type;
> > -ConvolutionalParams* conv_params;
> > -DepthToSpaceParams* depth_to_space_params;
> > +ConvolutionalParams *conv_params;
> > +DepthToSpaceParams *depth_to_space_params;
> >
> >  model = av_malloc(sizeof(DNNModel));
> >   

[FFmpeg-devel] Seeking consultancy for ffmpeg video embedding pipeline task

[Pi Tao]

Dear ffmpeg devs,

https://ffmpeg.org/consulting.html  
redirects to this mailing list (else I would hesitate to pester devs with a 
consultancy request).

I'm looking for someone that can guide me through a simple (Python) AV 
processing pipeline:

The basic task is:

- to receive a video track and an audio track
- to insert a certain length of black at the start of the video track
- if the audio is longer, to freeze the last frame of the video track until the 
audio has completed
- to insert content into the audio track
- to merge the audio track into the video track

There are a couple of complications:

- sometimes we receive just a video track, in which case we have to split off 
the audio Stream and use that
- the content is ultrasonic, so it's important this information is not lost (I 
believe we can use .aac with .mp4 & tune it)

I have everything coded (in Python) and it's working. However, it's taking a 
long time to process. I'm fairly sure we are not using ffmpeg optimally.

If there is anyone out there that would be willing to offer consultancy, please 
do get in touch!  To speed things up, please suggest a consultancy rate and let 
me know when you might be available (I'm in the UK). I would like to complete 
this task as soon as possible. We could work over IRC (I'm pi- on #ffmpeg) or 
Slack. The initial task may only be a couple of hours' work.

Best wishes, and I look forward to hearing from someone!

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

Re: [FFmpeg-devel] Regarding FFmpeg For Android

[Dominik 'Rathann' Mierzejewski]

Dear Michael,

On Monday, 06 August 2018 at 19:55, Michael De Marco wrote:
> 
>I am going to build FFMpeg on Unbuntu.  I have seen several
> online posts of how to do this but nothing has worked.

You did not point to any of those posts. Nor did you provide the
commands that you used or error messages that you saw. I can only
speak for myself, but I think there are no telepaths who can
read your mind here.

> Does anyone have a instruction guide on how to do this. I did
> download the NDK and essentially there is a build script where
> the sh file sits in the FFmpeg directory. In the sh file you
> specify where the NDK is located and then run the script. It
> did not appear to work.

Again, you didn't say what build script you mean or how you ran it
and what errors, if any, you saw.

Finally, this is the wrong place to ask. Per
https://ffmpeg.org/contact.html#MailingLists you should post your
question to ffmpeg-user mailing list. This list (ffmpeg-devel)
is for development of FFmpeg itself.

I recommend reading the excellent document by Eric S. Raymond
about asking questions the smart way before posting again:
http://catb.org/~esr/faqs/smart-questions.html

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Mark Thompson]

On 06/08/18 16:44, Jorge Ramirez-Ortiz wrote:
> On 08/04/2018 11:43 PM, Mark Thompson wrote:
>>> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
>>> index efcb0426e4..9457fadb1e 100644
>>> --- a/libavcodec/v4l2_context.c
>>> +++ b/libavcodec/v4l2_context.c
>>> @@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
>>>   struct v4l2_requestbuffers req = {
>>>   .memory = V4L2_MEMORY_MMAP,
>>>   .type = ctx->type,
>>> -    .count = 0, /* 0 -> unmaps buffers from the driver */
>>> +    .count = 0, /* 0 -> unmap all buffers from the driver */
>>>   };
>>> -    int i, j;
>>> +    int ret, i, j;
>>>     for (i = 0; i < ctx->num_buffers; i++) {
>>>   V4L2Buffer *buffer = >buffers[i];
>>>     for (j = 0; j < buffer->num_planes; j++) {
>>>   struct V4L2Plane_info *p = >plane_info[j];
>>> +
>>> +    if (V4L2_TYPE_IS_OUTPUT(ctx->type)) {
>>> +    /* output buffers are not EXPORTED */
>>> +    goto unmap;
>>> +    }
>>> +
>>> +    if (ctx_to_m2mctx(ctx)->output_drm) {
>>> +    /* use the DRM frame to close */
>>> +    if (buffer->drm_frame.objects[j].fd >= 0) {
>>> +    if (close(buffer->drm_frame.objects[j].fd) < 0) {
>>> +    av_log(logger(ctx), AV_LOG_ERROR, "%s close drm fd 
>>> "
>>> +    "[buffer=%2d, plane=%d, fd=%2d] - %s \n",
>>> +    ctx->name, i, j, 
>>> buffer->drm_frame.objects[j].fd,
>>> +    av_err2str(AVERROR(errno)));
>>> +    }
>>> +    }
>>> +    }
>>> +unmap:
>>>   if (p->mm_addr && p->length)
>>>   if (munmap(p->mm_addr, p->length) < 0)
>>> -    av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
>>> (%s))\n", ctx->name, av_err2str(AVERROR(errno)));
>>> +    av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane 
>>> (%s))\n",
>>> +    ctx->name, av_err2str(AVERROR(errno)));
>>>   }
>> (This whole function feels like it might fit better in v4l2_buffers.c?)
>>
>> To check my understanding here of what you've got currently (please correct 
>> me if I make a mistake here):
>> * When making a new set of buffers (on start or format change), 
>> VIDIOC_EXPBUF is called once for each V4L2 buffer to make a DRM PRIME fd for 
>> it.
>> * Whenever you want to return a buffer, return the fd instead if using DRM 
>> PRIME output.
>> * When returning a set of buffers (on close or format change), wait for all 
>> references to disappear and then close all of the fds before releasing the 
>> V4L2 buffers.
> 
> We kept it as a context operation since release_buffers is not a per buffer 
> operation (it just an operation that applies on all buffers, like all context 
> operations IIRC ).
> The problem is that even if we close the file descriptors when all references 
> have gone, the client might still have GEM objects associated so we would 
> fail at releasing the buffers.

Ok.

> This was noticed during testing (fixed in the test code with this commit) [1]
> [1] 
> https://github.com/BayLibre/ffmpeg-drm/commit/714288ab9d86397dd8230068fd9a7d3d4d76b802
> 
> And a reminder was added to ffmpeg below
> 
>>>   }
>>>   -    return ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, );
>>> +    ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, );
>>> +    if (ret < 0) {
>>> +    av_log(logger(ctx), AV_LOG_ERROR, "release all %s buffers 
>>> (%s)\n",
>>> +    ctx->name, av_err2str(AVERROR(errno)));
>>> +
>>> +    if (ctx_to_m2mctx(ctx)->output_drm)
>>> +    av_log(logger(ctx), AV_LOG_ERROR,
>>> +    "Make sure the DRM client releases all FB/GEM objects 
>>> before closing the codec (ie):\n"
>>> +    "for all buffers: \n"
>>> +    "  1. drmModeRmFB(..)\n"
>>> +    "  2. drmIoctl(.., DRM_IOCTL_GEM_CLOSE,... )\n");
>> Is it possible to hit this case?  Waiting for all references to disappear 
>> seems like it should cover it.  (And if the user has freed an object they 
>> are still using then that's certainly undefined behaviour, so if that's the 
>> only case here it would probably be better to abort() so that it's caught 
>> immediately.)
>>
> 
> yes (as per the above explanation)

Does errno indicate that we've hit this case specifically rather than e.g. some 
sort of hardware problem (decoder device physically disconnected or whatever)?

Since it's a use-after-free on the part of the API user and therefore undefined 
behaviour, we should av_assert0() that it doesn't happen if we can identify it.

(The KMS/GEM comments would also be rather confusing if the sink is something 
else - GL/EGL seems likely to be common, and OpenCL or Vulkan are certainly 
possible too.  Maybe make that more generic.)

- Mark

Re: [FFmpeg-devel] [PATCH 3/4] vf_tonemap_opencl: Move update_metadata() to a shared file

[James Almer]

On 8/6/2018 4:52 PM, Mark Thompson wrote:
> On 06/08/18 20:21, James Almer wrote:
>> On 7/25/2018 12:46 PM, Vittorio Giovara wrote:
>>> ---
>>>  libavfilter/colorspace.c| 17 +
>>>  libavfilter/colorspace.h|  1 +
>>>  libavfilter/vf_tonemap_opencl.c | 19 +--
>>>  3 files changed, 19 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
>>> index d6f6055401..c6682216d6 100644
>>> --- a/libavfilter/colorspace.c
>>> +++ b/libavfilter/colorspace.c
>>> @@ -118,3 +118,20 @@ double ff_determine_signal_peak(AVFrame *in)
>>>  
>>>  return peak;
>>>  }
>>> +
>>> +void ff_update_hdr_metadata(AVFrame *in, double peak)
>>> +{
>>> +AVFrameSideData *sd = av_frame_get_side_data(in, 
>>> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
>>> +
>>> +if (sd) {
>>> +AVContentLightMetadata *clm = (AVContentLightMetadata *)sd->data;
>>> +clm->MaxCLL = (unsigned)(peak * REFERENCE_WHITE);
>>> +}
>>> +
>>> +sd = av_frame_get_side_data(in, 
>>> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
>>> +if (sd) {
>>> +AVMasteringDisplayMetadata *metadata = (AVMasteringDisplayMetadata 
>>> *)sd->data;
>>> +if (metadata->has_luminance)
>>> +metadata->max_luminance = av_d2q(peak * REFERENCE_WHITE, 
>>> 1);
>>> +}
>> Frame side data is refcounted, so this is not correct. I'm not sure if a
>> side data element is ever modified in-place long after being created to
>> being with, aside from this function here.
>>
>> Easiest option is to call av_buffer_make_writable() on sd->buf and
>> updating the sd->data pointer before modifying the fields in question,
>> but such manual handling of side data seems improper and fragile.
>> I guess another option is av_mastering_display_metadata_alloc(), copy
>> the values, av_frame_remove_side_data(), av_buffer_create(), then
>> av_frame_new_side_data_from_buf().
>>
>> Honestly, i think we may have to add a make_writable() function for side
>> data for this.
> 
> The frame side-data was already copied for the output frame by 
> av_frame_copy_props(), so modifying it here is fine.  (I had exactly the same 
> thought when this code appeared in tonemap_opencl.)
> 
> - Mark

Ah, good. I guess the ff_update_hdr_metadata() doxy should in any case
point that the frame or at least its side data must be writable to
prevent other uses in the future where this may not be taken into
account, now that it's shared.

And an actual, generic solution like a make_writable function is imo
still a good idea, unless the user is expected to use
av_frame_make_writable() if they want to do *any* kind of in-place
change to the frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] vf_tonemap_opencl: Move update_metadata() to a shared file

[Mark Thompson]

On 06/08/18 20:21, James Almer wrote:
> On 7/25/2018 12:46 PM, Vittorio Giovara wrote:
>> ---
>>  libavfilter/colorspace.c| 17 +
>>  libavfilter/colorspace.h|  1 +
>>  libavfilter/vf_tonemap_opencl.c | 19 +--
>>  3 files changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
>> index d6f6055401..c6682216d6 100644
>> --- a/libavfilter/colorspace.c
>> +++ b/libavfilter/colorspace.c
>> @@ -118,3 +118,20 @@ double ff_determine_signal_peak(AVFrame *in)
>>  
>>  return peak;
>>  }
>> +
>> +void ff_update_hdr_metadata(AVFrame *in, double peak)
>> +{
>> +AVFrameSideData *sd = av_frame_get_side_data(in, 
>> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
>> +
>> +if (sd) {
>> +AVContentLightMetadata *clm = (AVContentLightMetadata *)sd->data;
>> +clm->MaxCLL = (unsigned)(peak * REFERENCE_WHITE);
>> +}
>> +
>> +sd = av_frame_get_side_data(in, 
>> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
>> +if (sd) {
>> +AVMasteringDisplayMetadata *metadata = (AVMasteringDisplayMetadata 
>> *)sd->data;
>> +if (metadata->has_luminance)
>> +metadata->max_luminance = av_d2q(peak * REFERENCE_WHITE, 1);
>> +}
> Frame side data is refcounted, so this is not correct. I'm not sure if a
> side data element is ever modified in-place long after being created to
> being with, aside from this function here.
> 
> Easiest option is to call av_buffer_make_writable() on sd->buf and
> updating the sd->data pointer before modifying the fields in question,
> but such manual handling of side data seems improper and fragile.
> I guess another option is av_mastering_display_metadata_alloc(), copy
> the values, av_frame_remove_side_data(), av_buffer_create(), then
> av_frame_new_side_data_from_buf().
> 
> Honestly, i think we may have to add a make_writable() function for side
> data for this.

The frame side-data was already copied for the output frame by 
av_frame_copy_props(), so modifying it here is fine.  (I had exactly the same 
thought when this code appeared in tonemap_opencl.)

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

Re: [FFmpeg-devel] [PATCH 3/4] vf_tonemap_opencl: Move update_metadata() to a shared file

[James Almer]

On 7/25/2018 12:46 PM, Vittorio Giovara wrote:
> ---
>  libavfilter/colorspace.c| 17 +
>  libavfilter/colorspace.h|  1 +
>  libavfilter/vf_tonemap_opencl.c | 19 +--
>  3 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
> index d6f6055401..c6682216d6 100644
> --- a/libavfilter/colorspace.c
> +++ b/libavfilter/colorspace.c
> @@ -118,3 +118,20 @@ double ff_determine_signal_peak(AVFrame *in)
>  
>  return peak;
>  }
> +
> +void ff_update_hdr_metadata(AVFrame *in, double peak)
> +{
> +AVFrameSideData *sd = av_frame_get_side_data(in, 
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
> +
> +if (sd) {
> +AVContentLightMetadata *clm = (AVContentLightMetadata *)sd->data;
> +clm->MaxCLL = (unsigned)(peak * REFERENCE_WHITE);
> +}
> +
> +sd = av_frame_get_side_data(in, 
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> +if (sd) {
> +AVMasteringDisplayMetadata *metadata = (AVMasteringDisplayMetadata 
> *)sd->data;
> +if (metadata->has_luminance)
> +metadata->max_luminance = av_d2q(peak * REFERENCE_WHITE, 1);
> +}
Frame side data is refcounted, so this is not correct. I'm not sure if a
side data element is ever modified in-place long after being created to
being with, aside from this function here.

Easiest option is to call av_buffer_make_writable() on sd->buf and
updating the sd->data pointer before modifying the fields in question,
but such manual handling of side data seems improper and fragile.
I guess another option is av_mastering_display_metadata_alloc(), copy
the values, av_frame_remove_side_data(), av_buffer_create(), then
av_frame_new_side_data_from_buf().

Honestly, i think we may have to add a make_writable() function for side
data for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining

[Michael Niedermayer]

On Tue, Aug 07, 2018 at 01:05:51AM +0800, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Aug 5, 2018, 9:17 AM Michael Niedermayer 
> wrote:
> 
> > Fixes: Timeout
> > Fixes:
> > 9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5707345857347584
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/vp9.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index b1178c9c0c..4ca51ec108 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -1302,6 +1302,9 @@ static int decode_tiles(AVCodecContext *avctx,
> >  memset(lflvl_ptr->mask, 0,
> > sizeof(lflvl_ptr->mask));
> >  }
> >
> > +if (td->c->end <= td->c->buffer && td->c->bits >= 0) {
> > +return AVERROR_INVALIDDATA;
> > +}
> >  if (s->pass == 2) {
> >  decode_sb_mem(td, row, col, lflvl_ptr,
> >yoff2, uvoff2, BL_64X64);
> >
> 
> I don't think this matches spec. Implementations could use this to store
> auxiliary data.

This checks, or rather is intended to check for a premature end of the input.
Am i missing something? because a premature end of input seems not to lead
to more (auxiliary or other) data in the input.

Of course in principle an encoder could use this and truncate the stream
if the result still matches. Is this allowed in the spec ?

Also i think this if() would be clearer with an error message or some
comment, for example it would have been clear that this is about a end
of input and not unknown additional input. But i omited the message as you
didnt like error messages in similar cases.

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

Re: [FFmpeg-devel] [PATCH 3/7] libavfilter: Fixes warnings for unused variables in dnn_srcnn.h, dnn_espcn.h, dnn_backend_tf.c.

[Pedro Arthur]

2018-08-02 15:52 GMT-03:00 Sergey Lavrushkin :
> ---
>  libavfilter/dnn_backend_tf.c | 64 
> +++-
>  libavfilter/dnn_espcn.h  | 37 -
>  libavfilter/dnn_srcnn.h  | 35 
>  3 files changed, 63 insertions(+), 73 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index 6307c794a5..7a4ad72d27 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -374,9 +374,71 @@ DNNModel *ff_dnn_load_default_model_tf(DNNDefaultModel 
> model_type)
>  TFModel *tf_model = NULL;
>  TF_OperationDescription *op_desc;
>  TF_Operation *op;
> -TF_Operation *const_ops_buffer[6];
>  TF_Output input;
>  int64_t input_shape[] = {1, -1, -1, 1};
> +const char tanh[] = "Tanh";
> +const char sigmoid[] = "Sigmoid";
> +const char relu[] = "Relu";
> +
> +const float *srcnn_consts[] = {
> +srcnn_conv1_kernel,
> +srcnn_conv1_bias,
> +srcnn_conv2_kernel,
> +srcnn_conv2_bias,
> +srcnn_conv3_kernel,
> +srcnn_conv3_bias
> +};
> +const long int *srcnn_consts_dims[] = {
> +srcnn_conv1_kernel_dims,
> +srcnn_conv1_bias_dims,
> +srcnn_conv2_kernel_dims,
> +srcnn_conv2_bias_dims,
> +srcnn_conv3_kernel_dims,
> +srcnn_conv3_bias_dims
> +};
> +const int srcnn_consts_dims_len[] = {
> +4,
> +1,
> +4,
> +1,
> +4,
> +1
> +};
> +const char *srcnn_activations[] = {
> +relu,
> +relu,
> +relu
> +};
> +
> +const float *espcn_consts[] = {
> +espcn_conv1_kernel,
> +espcn_conv1_bias,
> +espcn_conv2_kernel,
> +espcn_conv2_bias,
> +espcn_conv3_kernel,
> +espcn_conv3_bias
> +};
> +const long int *espcn_consts_dims[] = {
> +espcn_conv1_kernel_dims,
> +espcn_conv1_bias_dims,
> +espcn_conv2_kernel_dims,
> +espcn_conv2_bias_dims,
> +espcn_conv3_kernel_dims,
> +espcn_conv3_bias_dims
> +};
> +const int espcn_consts_dims_len[] = {
> +4,
> +1,
> +4,
> +1,
> +4,
> +1
> +};
> +const char *espcn_activations[] = {
> +tanh,
> +tanh,
> +sigmoid
> +};
>
>  input.index = 0;
>
> diff --git a/libavfilter/dnn_espcn.h b/libavfilter/dnn_espcn.h
> index a0dd61cd0d..9344aa90fe 100644
> --- a/libavfilter/dnn_espcn.h
> +++ b/libavfilter/dnn_espcn.h
> @@ -5398,41 +5398,4 @@ static const long int espcn_conv3_bias_dims[] = {
>  4
>  };
>
> -static const float *espcn_consts[] = {
> -espcn_conv1_kernel,
> -espcn_conv1_bias,
> -espcn_conv2_kernel,
> -espcn_conv2_bias,
> -espcn_conv3_kernel,
> -espcn_conv3_bias
> -};
> -
> -static const long int *espcn_consts_dims[] = {
> -espcn_conv1_kernel_dims,
> -espcn_conv1_bias_dims,
> -espcn_conv2_kernel_dims,
> -espcn_conv2_bias_dims,
> -espcn_conv3_kernel_dims,
> -espcn_conv3_bias_dims
> -};
> -
> -static const int espcn_consts_dims_len[] = {
> -4,
> -1,
> -4,
> -1,
> -4,
> -1
> -};
> -
> -static const char espcn_tanh[] = "Tanh";
> -
> -static const char espcn_sigmoid[] = "Sigmoid";
> -
> -static const char *espcn_activations[] = {
> -espcn_tanh,
> -espcn_tanh,
> -espcn_sigmoid
> -};
> -
>  #endif
> diff --git a/libavfilter/dnn_srcnn.h b/libavfilter/dnn_srcnn.h
> index 26143654b8..4f5332ce18 100644
> --- a/libavfilter/dnn_srcnn.h
> +++ b/libavfilter/dnn_srcnn.h
> @@ -2110,39 +2110,4 @@ static const long int srcnn_conv3_bias_dims[] = {
>  1
>  };
>
> -static const float *srcnn_consts[] = {
> -srcnn_conv1_kernel,
> -srcnn_conv1_bias,
> -srcnn_conv2_kernel,
> -srcnn_conv2_bias,
> -srcnn_conv3_kernel,
> -srcnn_conv3_bias
> -};
> -
> -static const long int *srcnn_consts_dims[] = {
> -srcnn_conv1_kernel_dims,
> -srcnn_conv1_bias_dims,
> -srcnn_conv2_kernel_dims,
> -srcnn_conv2_bias_dims,
> -srcnn_conv3_kernel_dims,
> -srcnn_conv3_bias_dims
> -};
> -
> -static const int srcnn_consts_dims_len[] = {
> -4,
> -1,
> -4,
> -1,
> -4,
> -1
> -};
> -
> -static const char srcnn_relu[] = "Relu";
> -
> -static const char *srcnn_activations[] = {
> -srcnn_relu,
> -srcnn_relu,
> -srcnn_relu
> -};
> -
>  #endif
> --
> 2.14.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


LGTM.
I'll push it by tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/7] libavfilter: Adds on the fly generation of default DNN models for tensorflow backend instead of storing binary model.

[Pedro Arthur]

2018-08-06 11:58 GMT-03:00 Gyan Doshi :
>
>
> On 06-08-2018 08:23 PM, Pedro Arthur wrote:
>>
>>
>>
>> I may push the patch with proposed changes by tomorrow.
>
>
> Please add an entry in docs/filter as well as one in docs/general for tf
> backend as applicable.
The student have a patch in the works for that.

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

Re: [FFmpeg-devel] [PATCH] avs2: Correct expression error and simplify log

[James Almer]

On 8/6/2018 11:21 AM, Gyan Doshi wrote:
> 
> 
> On 06-08-2018 07:13 PM, hwren wrote:
> 
>> -    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE
>> 1857.4"),
>> +    .long_name  = NULL_IF_CONFIG_SMALL("Decoder for
>> AVS2-P2/IEEE1857.4"),
> 
> "Decoder for" is not needed. The flag indicates its role in `ffmpeg
> -codecs`.

The correct string considering this is a decoder using an external
library would be something like "libdavs2 AVS2-P2/IEEE1857.4"

> 
> Rest docs LGTM
> 
> 
> Thanks,
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] Regarding FFmpeg For Android

[Michael De Marco]

   I am going to build FFMpeg on Unbuntu.  I have seen several online posts of 
how to do this but nothing has worked.  Does anyone have a instruction guide on 
how to do this. I did download the NDK

  and essentially there is a build script where the sh file sits in the FFmpeg 
directory. In the sh file you specify where the NDK is located and then run the 
script. It did not appear to work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining

[Ronald S. Bultje]

Hi,

On Sun, Aug 5, 2018, 9:17 AM Michael Niedermayer 
wrote:

> Fixes: Timeout
> Fixes:
> 9330/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5707345857347584
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/vp9.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index b1178c9c0c..4ca51ec108 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1302,6 +1302,9 @@ static int decode_tiles(AVCodecContext *avctx,
>  memset(lflvl_ptr->mask, 0,
> sizeof(lflvl_ptr->mask));
>  }
>
> +if (td->c->end <= td->c->buffer && td->c->bits >= 0) {
> +return AVERROR_INVALIDDATA;
> +}
>  if (s->pass == 2) {
>  decode_sb_mem(td, row, col, lflvl_ptr,
>yoff2, uvoff2, BL_64X64);
>

I don't think this matches spec. Implementations could use this to store
auxiliary data.

Ronald

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

Re: [FFmpeg-devel] [PATCH 2/4] libavcodec: v4l2m2m: output AVDRMFrameDescriptor

[Jorge Ramirez-Ortiz]

On 08/04/2018 11:43 PM, Mark Thompson wrote:

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..9457fadb1e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
  struct v4l2_requestbuffers req = {
  .memory = V4L2_MEMORY_MMAP,
  .type = ctx->type,
-.count = 0, /* 0 -> unmaps buffers from the driver */
+.count = 0, /* 0 -> unmap all buffers from the driver */
  };
-int i, j;
+int ret, i, j;
  
  for (i = 0; i < ctx->num_buffers; i++) {

  V4L2Buffer *buffer = >buffers[i];
  
  for (j = 0; j < buffer->num_planes; j++) {

  struct V4L2Plane_info *p = >plane_info[j];
+
+if (V4L2_TYPE_IS_OUTPUT(ctx->type)) {
+/* output buffers are not EXPORTED */
+goto unmap;
+}
+
+if (ctx_to_m2mctx(ctx)->output_drm) {
+/* use the DRM frame to close */
+if (buffer->drm_frame.objects[j].fd >= 0) {
+if (close(buffer->drm_frame.objects[j].fd) < 0) {
+av_log(logger(ctx), AV_LOG_ERROR, "%s close drm fd "
+"[buffer=%2d, plane=%d, fd=%2d] - %s \n",
+ctx->name, i, j, buffer->drm_frame.objects[j].fd,
+av_err2str(AVERROR(errno)));
+}
+}
+}
+unmap:
  if (p->mm_addr && p->length)
  if (munmap(p->mm_addr, p->length) < 0)
-av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane (%s))\n", 
ctx->name, av_err2str(AVERROR(errno)));
+av_log(logger(ctx), AV_LOG_ERROR, "%s unmap plane (%s))\n",
+ctx->name, av_err2str(AVERROR(errno)));
  }

(This whole function feels like it might fit better in v4l2_buffers.c?)

To check my understanding here of what you've got currently (please correct me 
if I make a mistake here):
* When making a new set of buffers (on start or format change), VIDIOC_EXPBUF 
is called once for each V4L2 buffer to make a DRM PRIME fd for it.
* Whenever you want to return a buffer, return the fd instead if using DRM 
PRIME output.
* When returning a set of buffers (on close or format change), wait for all 
references to disappear and then close all of the fds before releasing the V4L2 
buffers.


We kept it as a context operation since release_buffers is not a per 
buffer operation (it just an operation that applies on all buffers, like 
all context operations IIRC ).
The problem is that even if we close the file descriptors when all 
references have gone, the client might still have GEM objects associated 
so we would fail at releasing the buffers.


This was noticed during testing (fixed in the test code with this 
commit) [1]
[1] 
https://github.com/BayLibre/ffmpeg-drm/commit/714288ab9d86397dd8230068fd9a7d3d4d76b802


And a reminder was added to ffmpeg below


  }
  
-return ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, );

+ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_REQBUFS, );
+if (ret < 0) {
+av_log(logger(ctx), AV_LOG_ERROR, "release all %s buffers (%s)\n",
+ctx->name, av_err2str(AVERROR(errno)));
+
+if (ctx_to_m2mctx(ctx)->output_drm)
+av_log(logger(ctx), AV_LOG_ERROR,
+"Make sure the DRM client releases all FB/GEM objects before 
closing the codec (ie):\n"
+"for all buffers: \n"
+"  1. drmModeRmFB(..)\n"
+"  2. drmIoctl(.., DRM_IOCTL_GEM_CLOSE,... )\n");

Is it possible to hit this case?  Waiting for all references to disappear seems 
like it should cover it.  (And if the user has freed an object they are still 
using then that's certainly undefined behaviour, so if that's the only case 
here it would probably be better to abort() so that it's caught immediately.)



yes (as per the above explanation)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avformat/matroskaenc: update AV1 support

[James Almer]

On 8/6/2018 3:39 AM, Steve Lhomme wrote:
> On 31/07/2018 17:19, James Almer wrote:
>> On 7/31/2018 3:37 AM, Steve Lhomme wrote:
>>> On 30/07/2018 17:13, James Almer wrote:
 On 7/30/2018 2:03 AM, Steve Lhomme wrote:
> On 26/07/2018 03:11, James Almer wrote:
>> Make sure to not write forbidden OBUs to CodecPrivate, and do the
>> same
>> with
>> unnecessary OBUs for packets.
> Does this include reordering the OBUs ? The first one must be the
> Sequence Header OBU. Also it must be the only one of that kind.
 No, it doesn't. I can make that change, but why does it matter if it's
 the first? Why can't a metadata OBU be before a Seq Header? isobmff
>>> Because if the spec say it's the first and its enforced, the OBU parser
>>> needed at the container level may be simpler. The muxing side can have
>>> more complexity if needed.
>> Nothing in the spec says it's the first, afaics, just that in a temporal
>> unit if present it must prepend a frame. I may be misreading it, though.
> 
> As we're talking about the Matroska muxer the current document says:
> The first OBU MUST be the first |Sequence Header OBU| and be the only
> OBU of type |OBU_SEQUENCE_HEADER| in the |CodecPrivate|

Right, i misunderstood and thought you were talking about the av1 spec,
not the Matroska mapping.

> 
>>
>> In any case, my suggestion in the isobmff issue includes ordering of
>> OBUs in av1C.
> 
> Good. Otherwise we can create an ISOBMFF file with 100 metadata OBUs
> and then the Sequence Header OBU and it's still valid.
> 
>>
 doesn't care what's first, only what's in.
>>> I requested that the same constraint be applied in ISOBMFF
>>> https://github.com/AOMediaCodec/av1-isobmff/pull/47#issuecomment-408598719
>>>
>>>
 A parser is currently forced to know how to read OBUs anyway, and it
 could just skip any metadata obu before the sequence header.

 For that matter, i do agree with
 https://github.com/AOMediaCodec/av1-isobmff/issues/7#issuecomment-406257234


 and
 https://github.com/AOMediaCodec/av1-isobmff/issues/46#issuecomment-406516226


 that perhaps av1C should, much like hvcC, avcC and in it's own way also
 vpcC, contain a bunch of header bytes listing some basic information
 (and therefore the entire thing, sans atom size and fourcc, be included
 in CodecPrivate verbatim). Things like profile, level, and maybe number
 of OBUs, before the raw OBUs.
 As an extra benefit than simply removing the requirement for
 demuxers to
 parse OBUs that may even only be in sample data just to see if the file
 can be decoded (firing up a hardware decoder can be expensive), it
 would
 also give us a way to identify the source of the bitstream (mp4/mkv vs
 ivf/raw/annexb/etc), for example for the purpose of inserting the
 extradata Seq Header if not present on key frames (Matroska allows to
 remove it, but isobmff in section 2.5 seems to want a sync sample to be
 a fully compliant RAP without the need of extradata obus, despite the
 description in section 2.4.4), achieved by writing and using an
 av1_mp4tolobf bsf or similar, which would then be included where needed
 instead of the naive dump_extradata one from patch 2/5 of this set, for
 example.
>>> I totally support this. In the end storing OBUs in extra data is
>>> becoming a PITA, especially if it needs to be prepended to some frames
>>> but not all. If we stick to a simpler structure with what's needed to
>>> identify decoder properties (mostly the profile) it would make things a
>>> lot easier.
>> The process of assembling a bitstream for the purpose of decoding or
>> storing is up to the implementation. The requirement for the global Seq
>> Headers to be prepended to key frames for raw bitstream purposes is
>> essentially the same as sps/pps/vps from h264 and h265.
> 
> I did not know that.
> 
>>
>> ffmpeg's decoders keep global headers in extradata to use them as they
>> see fit (native decoders), or request the aid of bitstream filters like
>> h264_mp4toannexb to assemble the bitstream using said extradata if
>> required (hardware decoders, some external decoders). Similarly, muxers
>> for non global header containers (ivf, raw, etc) do the same on their
>> own, or with the aid of a bitstream filter.
> 
> It seems odd that it's done at the decoder level and not the container
> level, since it's a feature of a particular mapping. Or is it done
> through a flag that tells that the extradata need to be prepended for
> keyframes ?

AVFMT_GLOBALHEADER (muxers) and AV_CODEC_FLAG_GLOBAL_HEADER (encoders)
are used to signal that.
Demuxers propagate packets as they are stored, so for h264 raw
bitstreams the parameter sets will in any sane stream be part of them.
For containers like mp4/mkv, they will most likely not be there, but
will be propagated in extradata as extracted from avcC/CodecPrivate.
The internal decoder will always 

Re: [FFmpeg-devel] [PATCH 2/7] libavfilter: Code style fixes for pointers in DNN module and sr filter.

[Pedro Arthur]

2018-08-02 15:52 GMT-03:00 Sergey Lavrushkin :
> ---
>  libavfilter/dnn_backend_native.c |  84 +++---
>  libavfilter/dnn_backend_native.h |   8 +--
>  libavfilter/dnn_backend_tf.c | 108 
> +++
>  libavfilter/dnn_backend_tf.h |   8 +--
>  libavfilter/dnn_espcn.h  |   6 +--
>  libavfilter/dnn_interface.c  |   4 +-
>  libavfilter/dnn_interface.h  |  16 +++---
>  libavfilter/dnn_srcnn.h  |   6 +--
>  libavfilter/vf_sr.c  |  60 +++---
>  9 files changed, 150 insertions(+), 150 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c 
> b/libavfilter/dnn_backend_native.c
> index 3e6b86280d..baefea7fcb 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -34,15 +34,15 @@ typedef enum {RELU, TANH, SIGMOID} ActivationFunc;
>
>  typedef struct Layer{
>  LayerType type;
> -float* output;
> -void* params;
> +float *output;
> +void *params;
>  } Layer;
>
>  typedef struct ConvolutionalParams{
>  int32_t input_num, output_num, kernel_size;
>  ActivationFunc activation;
> -float* kernel;
> -float* biases;
> +float *kernel;
> +float *biases;
>  } ConvolutionalParams;
>
>  typedef struct InputParams{
> @@ -55,16 +55,16 @@ typedef struct DepthToSpaceParams{
>
>  // Represents simple feed-forward convolutional network.
>  typedef struct ConvolutionalNetwork{
> -Layer* layers;
> +Layer *layers;
>  int32_t layers_num;
>  } ConvolutionalNetwork;
>
> -static DNNReturnType set_input_output_native(void* model, DNNData* input, 
> DNNData* output)
> +static DNNReturnType set_input_output_native(void *model, DNNData *input, 
> DNNData *output)
>  {
> -ConvolutionalNetwork* network = (ConvolutionalNetwork*)model;
> -InputParams* input_params;
> -ConvolutionalParams* conv_params;
> -DepthToSpaceParams* depth_to_space_params;
> +ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> +InputParams *input_params;
> +ConvolutionalParams *conv_params;
> +DepthToSpaceParams *depth_to_space_params;
>  int cur_width, cur_height, cur_channels;
>  int32_t layer;
>
> @@ -72,7 +72,7 @@ static DNNReturnType set_input_output_native(void* model, 
> DNNData* input, DNNDat
>  return DNN_ERROR;
>  }
>  else{
> -input_params = (InputParams*)network->layers[0].params;
> +input_params = (InputParams *)network->layers[0].params;
>  input_params->width = cur_width = input->width;
>  input_params->height = cur_height = input->height;
>  input_params->channels = cur_channels = input->channels;
> @@ -88,14 +88,14 @@ static DNNReturnType set_input_output_native(void* model, 
> DNNData* input, DNNDat
>  for (layer = 1; layer < network->layers_num; ++layer){
>  switch (network->layers[layer].type){
>  case CONV:
> -conv_params = 
> (ConvolutionalParams*)network->layers[layer].params;
> +conv_params = (ConvolutionalParams 
> *)network->layers[layer].params;
>  if (conv_params->input_num != cur_channels){
>  return DNN_ERROR;
>  }
>  cur_channels = conv_params->output_num;
>  break;
>  case DEPTH_TO_SPACE:
> -depth_to_space_params = 
> (DepthToSpaceParams*)network->layers[layer].params;
> +depth_to_space_params = (DepthToSpaceParams 
> *)network->layers[layer].params;
>  if (cur_channels % (depth_to_space_params->block_size * 
> depth_to_space_params->block_size) != 0){
>  return DNN_ERROR;
>  }
> @@ -127,16 +127,16 @@ static DNNReturnType set_input_output_native(void* 
> model, DNNData* input, DNNDat
>  // layers_num,layer_type,layer_parameterss,layer_type,layer_parameters...
>  // For CONV layer: activation_function, input_num, output_num, kernel_size, 
> kernel, biases
>  // For DEPTH_TO_SPACE layer: block_size
> -DNNModel* ff_dnn_load_model_native(const char* model_filename)
> +DNNModel *ff_dnn_load_model_native(const char *model_filename)
>  {
> -DNNModel* model = NULL;
> -ConvolutionalNetwork* network = NULL;
> -AVIOContext* model_file_context;
> +DNNModel *model = NULL;
> +ConvolutionalNetwork *network = NULL;
> +AVIOContext *model_file_context;
>  int file_size, dnn_size, kernel_size, i;
>  int32_t layer;
>  LayerType layer_type;
> -ConvolutionalParams* conv_params;
> -DepthToSpaceParams* depth_to_space_params;
> +ConvolutionalParams *conv_params;
> +DepthToSpaceParams *depth_to_space_params;
>
>  model = av_malloc(sizeof(DNNModel));
>  if (!model){
> @@ -155,7 +155,7 @@ DNNModel* ff_dnn_load_model_native(const char* 
> model_filename)
>  av_freep();
>  return NULL;
>  }
> -model->model = (void*)network;
> +model->model = (void *)network;
>
>  network->layers_num = 1 + 

Re: [FFmpeg-devel] [PATCH 1/7] libavfilter: Adds on the fly generation of default DNN models for tensorflow backend instead of storing binary model.

[Gyan Doshi]

On 06-08-2018 08:23 PM, Pedro Arthur wrote:



I may push the patch with proposed changes by tomorrow.


Please add an entry in docs/filter as well as one in docs/general for tf 
backend as applicable.


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

Re: [FFmpeg-devel] [PATCH 1/7] libavfilter: Adds on the fly generation of default DNN models for tensorflow backend instead of storing binary model.

[Pedro Arthur]

2018-08-03 10:11 GMT-03:00 Michael Niedermayer :
> On Thu, Aug 02, 2018 at 09:52:42PM +0300, Sergey Lavrushkin wrote:
>> This patch provides on the fly generation of default DNN models for 
>> tensorflow backend,
>> that eliminates data duplication for model weights. Also, files with 
>> internal weights
>> were replaced with automatically generated files for models I trained. 
>> Scripts for
>> training and generating these files can be found here:
>> https://github.com/HighVoltageRocknRoll/sr
>>
>
> [...]
>> +static TF_Operation* add_conv_layers(TFModel* tf_model, const float** 
>> consts, const int64_t** consts_dims,
>> + const int* consts_dims_len, const 
>> char** activations,
>> + TF_Operation* input_op, int layers_num)
>> +{
>> +int i;
>> +TF_OperationDescription* op_desc;
>> +TF_Operation* op;
>> +TF_Operation* transpose_op;
>> +TF_Output input;
>> +int64_t strides[] = {1, 1, 1, 1};
>> +int32_t* transpose_perm;
>> +TF_Tensor* tensor;
>> +int64_t transpose_perm_shape[] = {4};
>> +char name_buffer[256];
>> +
>> +op_desc = TF_NewOperation(tf_model->graph, "Const", "transpose_perm");
>> +TF_SetAttrType(op_desc, "dtype", TF_INT32);
>> +tensor = TF_AllocateTensor(TF_INT32, transpose_perm_shape, 1, 4 * 
>> sizeof(int32_t));
>> +transpose_perm = (int32_t*)TF_TensorData(tensor);
>> +transpose_perm[0] = 1;
>> +transpose_perm[1] = 2;
>> +transpose_perm[2] = 3;
>> +transpose_perm[3] = 0;
>> +TF_SetAttrTensor(op_desc, "value", tensor, tf_model->status);
>> +if (TF_GetCode(tf_model->status) != TF_OK){
>> +return NULL;
>> +}
>> +transpose_op = TF_FinishOperation(op_desc, tf_model->status);
>> +if (TF_GetCode(tf_model->status) != TF_OK){
>> +return NULL;
>> +}
>> +
>> +input.index = 0;
>> +for (i = 0; i < layers_num; ++i){
>
>> +sprintf(name_buffer, "conv_kernel%d", i);
>
> sprintf() should normally not be used as its too easy to end up
> overwriting the output.
> snprintf() is a safer alternative
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


I may push the patch with proposed changes by tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Mixture of homographies video stabilization

[Matthew Lai]

Sorry the matrices are actually 3x3, and most of the time will be spent on
solving a 8x9 * 9x1 = 0 systems. And then all the feature points will have
to be multiplied by the 9x1 matrix reshaped into 3x3.

The math is here:
https://www.uio.no/studier/emner/matnat/its/UNIK4690/v16/forelesninger/lecture_4_3-estimating-homographies-from-feature-correspondences.pdf

Multiplying 3x3 matrices is trivial, but SVD isn't. SVD is the standard
approach to decompose a homography matrix. I have not looked into
alternative approaches.

Cool! Will see re. ME. It's likely to be the performance-limiting part, and
it would be nice to run that on GPU.

On Fri, Aug 3, 2018 at 8:27 PM Michael Niedermayer 
wrote:

> On Fri, Aug 03, 2018 at 01:29:27PM +0100, Matthew Lai wrote:
> > Hi Michael,
> >
> > The operations needed are multiplications, SVD, inversion, scaling, and
> > additions, as far as I can tell. Convolutions would probably also be
> > useful. They are certainly possible to implement directly, but it's
> > unlikely that any naive implementation will be within an order of
> magnitude
> > in performance to an optimized BLAS library. That may or may not matter
> - I
> > don't have a good idea of where the performance bottlenecks will be yet.
> > The matrices are 4x4.
>
> How do you intend to organize the data for these 4x4 matrices ?
> i mean if you have a rather large number of them and pass them all
> together to an external lib which then sends them to the GPU to process
> that should be faster than some native implementation (which would be CPU
> based presumably)
> OTOH one matrix at a time i dont see how the use of an external lib would
> make
> any sense.
> matrix addition, subtraction and scaling are just adding or scalin the
> 16 elements. i would expect a naive implementation to beat a external lib
> as long as both do at on the CPU. Because an external lib has to work with
> any NxM sized matrix we would implement this for just 4x4 so its trivial
> to fully unroll the loop or just do 4 load, add, store in SIMD or even
> skip the load/store and keep things in SIMD registers.
> about SVD. do you really need SVD? I mean is that the correct tool here and
> not just slower than alternatives ?
> These 4x4 matrixes are general matrixes or these have some other properties
> like being positive definite of something ?
> I guess i should read the paper, i might do that later ...
>
>
>
>
> >
> > Motion estimation is one way, but most state of the art implementations
> > don't use it because it's too noisy (motion from low contrast regions).
> > Most use something like a corner detector to find sharp feature points,
> and
> > track them (this can potentially be implemented using motion estimation,
> > but only around those points).
>
> Thats what i meant. The area that you want to matchup could use the
> existing
> code or share something with it.
> Other people had previously complained loudly about duplication of ME code.
> And while its not always possible to avoid "duplication", i think this
> should
> be looked into if it can be done in this case.
>
> thx
>
>
> >
> > Matthew
> >
> > On Fri, Aug 3, 2018 at 2:05 AM Michael Niedermayer
> 
> > wrote:
> >
> > > On Thu, Aug 02, 2018 at 05:24:08PM +0100, Matthew Lai wrote:
> > > > Ah ok thanks! I'm surprised no one has need a linear algebra
> library. I
> > > > guess there's OpenCV and people use it to do the heavy lifting?
> > > >
> > > > Will look into the API more.
> > >
> > > alot ot linear algebra we needed has been implemented directly.
> > > Some of it is shared and available from libavutil, like lls.*
> > >
> > > Can you elaboarte what exact linear algebra operations are needed?
> > > also what amounts of data (matrix types/sizes) and speed requirements
> this
> > > has
> > >
> > > Also IIUC (please correct me if iam wrong) this uses motion estimation
> > > at one step. IIRC ronald and others) want motion estimation to be
> > > factored and shared and not duplicated. The current motion estimation
> is
> > > in libavcodec/motion_est*.
> > >
> > > Thanks
> > >
> > > >
> > > > Thanks
> > > > matthew
> > > >
> > > > On Thu, Aug 2, 2018 at 3:31 PM Paul B Mahol 
> wrote:
> > > >
> > > > > On 8/2/18, Matthew Lai 
> wrote:
> > > > > > Hello!
> > > > > >
> > > > > > I want to write a more advanced video stabilizer for libavfilter
> (*),
> > > > > > implementing the algorithm described here -
> > > > > >
> > > > >
> > >
> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37744.pdf
> > > > > > The focus of the paper is rolling shutter removal, but it builds
> on
> > > top
> > > > > of
> > > > > > another algorithm that does full frame stabilization, and the new
> > > > > algorithm
> > > > > > does that as well.
> > > > > >
> > > > > > This is the algorithm used in YouTube's stabilizing filter, and
> is
> > > state
> > > > > of
> > > > > > the art. Adobe calls it Warp Stabilizer (it's the same thing as
> far
> > > as I
> > > > > > can tell from 

[FFmpeg-devel] [PATCH v2] avs2: Correct expression error and simplify log

[hwren]

Signed-off-by: hwren 
---
 doc/decoders.texi| 2 +-
 doc/general.texi | 2 +-
 libavcodec/avs2_parser.c | 2 +-
 libavcodec/codec_desc.c  | 2 +-
 libavcodec/libdavs2.c| 5 ++---
 5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 9439b7b..31e96fb 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -49,7 +49,7 @@ top-field-first is assumed
 
 @section libdavs2
 
-AVS2/IEEE 1857.4 video decoder wrapper.
+AVS2-P2/IEEE1857.4 video decoder wrapper.
 
 This decoder allows libavcodec to decode AVS2 streams with davs2 library.
 
diff --git a/doc/general.texi b/doc/general.texi
index cd725bb..3d15840 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -19,7 +19,7 @@ explicitly requested by passing the appropriate flags to
 
 @section libdavs2
 
-FFmpeg can make use of the davs2 library for AVS2/IEEE 1857.4 video decoding.
+FFmpeg can make use of the davs2 library for AVS2-P2/IEEE1857.4 video decoding.
 
 Go to @url{https://github.com/pkuvcl/davs2} and follow the instructions for
 installing the library. Then pass @code{--enable-libdavs2} to configure to
diff --git a/libavcodec/avs2_parser.c b/libavcodec/avs2_parser.c
index 520e98a..1c9b342 100644
--- a/libavcodec/avs2_parser.c
+++ b/libavcodec/avs2_parser.c
@@ -1,5 +1,5 @@
 /*
- * AVS2/IEEE 1857.4 video parser.
+ * AVS2-P2/IEEE1857.4 video parser.
  * Copyright (c) 2018  Huiwen Ren 
  *
  * This file is part of FFmpeg.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 2fe4aaa..1cbb241 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1398,7 +1398,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .id= AV_CODEC_ID_AVS2,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "avs2",
-.long_name = NULL_IF_CONFIG_SMALL("AVS2/IEEE 1857.4"),
+.long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
 .props = AV_CODEC_PROP_LOSSY,
 },
 {
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 12db1f9..76e345a 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -51,7 +51,7 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 
 /* init the decoder */
 cad->param.threads  = avctx->thread_count;
-cad->param.info_level   = 0;
+cad->param.info_level   = DAVS2_LOG_WARNING;
 cad->decoder= davs2_decoder_open(>param);
 
 if (!cad->decoder) {
@@ -59,7 +59,6 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "decoder created. %p\n", cad->decoder);
 return 0;
 }
 
@@ -163,7 +162,7 @@ static int davs2_decode_frame(AVCodecContext *avctx, void 
*data,
 
 AVCodec ff_libdavs2_decoder = {
 .name   = "libdavs2",
-.long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE 1857.4"),
+.long_name  = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_AVS2,
 .priv_data_size = sizeof(DAVS2Context),
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: correct units for raw pts in -progress report

[Nicolas George]

Gyan Doshi (2018-08-06):
> >Ah yes, Sorry, this is used for parsing. What protocol do you suggest for
> >correcting this?
> 
> Any thoughts on this?

Not really. I suppose you could add the field with the correct name and
remove the bogus one later. But your thoughts on this are probably
better than mine.

> I see that there were two changes made to value fields of the progress
> report earlier this year - a194e9c4159 and 1322b00060

It is true, but past mistakes cannot be used to justify new ones.

Also, it seems to me theses changes are much less serious: 1322b00060
only changes the precision in a compatible way, while the second only
changes anything when the required value is unavailable.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avs2: Correct expression error and simplify log

[Gyan Doshi]

On 06-08-2018 07:13 PM, hwren wrote:


-.long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE 1857.4"),
+.long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2-P2/IEEE1857.4"),


"Decoder for" is not needed. The flag indicates its role in `ffmpeg 
-codecs`.


Rest docs LGTM


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

Re: [FFmpeg-devel] First Patch for hlsenc.c for https://trac.ffmpeg.org/ticket/7281

[Steven Liu]

> On Aug 6, 2018, at 19:29, Ronak Patel  
> wrote:
> 
>> 
>> On Aug 6, 2018, at 7:19 AM, Liu Steven  wrote:
>> 
>> 
>> 
 在 2018年8月6日，下午7:12，Ronak Patel  写道：
 
 
 On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
 
 
 
> 在 2018年8月4日，上午2:17，Ronak  写道：
> 
>>> I have read this patch some problem for this patch.
>>> 
>>> 1. maybe there will have a problem when duration is not same when 
>>> every fragment, for example:
>>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i 
>>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>>> -hls_list_size 0 output_test.m3u8
>>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>>> #EXTM3U
>>> #EXT-X-VERSION:3
>>> #EXT-X-TARGETDURATION:8
>>> #EXT-X-MEDIA-SEQUENCE:0
>>> #EXTINF:3.87,
>>> output_test0.ts
>>> #EXTINF:7.30,
>>> output_test1.ts
>>> #EXTINF:8.33,
>>> output_test2.ts
>>> 
>>> the output_test0.ts’s duration is short than output_test1.ts, the 
>>> #EXT-X-TARGETDURATION need update to the longest duration.
>>> this operation (check the longest duration) will happen at every 
>>> fragment write complete.
>>> it will not update when move the update option to the 
>>> hls_write_header,
>>> 
>> 
>> This is a problem in the code that splits the mpegts files. I've 
>> filed a separate issue for this here: 
>> https://trac.ffmpeg.org/ticket/7341. Mpegts segmentation should be 
>> following the hls_time parameter (or the default length).
> This is whatever hls_time, is decide by keyframe position, this is 
> happen when GOP size is not a permanent t position.
> 
>> 
>> This is happening now with fMP4 assets, but not with mpegts.
> Whatever fmp4 or mpegts, all of them need fix the problem of duration 
> refresh.
> 
> for example:
> 
> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss -v quiet -i 
> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:8
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-MAP:URI="init.mp4"
> #EXTINF:3.87,
> output_test0.m4s
> #EXTINF:7.30,
> output_test1.m4s
> #EXTINF:8.33,
> liuqideMacBook-Pro:xxx liuqi$
 
 This is after your patch:
 liuqideMacBook-Pro:xxx liuqi$  ./ffmpeg -ss 17 -v quiet -i 
 ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
 -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
 liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
 #EXTM3U
 #EXT-X-VERSION:7
 #EXT-X-TARGETDURATION:3
 #EXT-X-MEDIA-SEQUENCE:0
 #EXT-X-MAP:URI="init.mp4"
 #EXTINF:3.87,
 output_test0.m4s
 #EXTINF:7.30,
 output_test1.m4s
 #EXTINF:8.33,
 
 The RFC https://www.rfc-editor.org/rfc/rfc8216.txt describe:
 
 4.3.3.1.  EXT-X-TARGETDURATION
 
 The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
 duration.  The EXTINF duration of each Media Segment in the Playlist
 file, when rounded to the nearest integer, MUST be less than or equal
 to the target duration; longer segments can trigger playback stalls
 or other errors.  It applies to the entire Playlist file.  Its format
 is:
 
 #EXT-X-TARGETDURATION:
 
 where s is a decimal-integer indicating the target duration in
 seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
 
 your patch make the EXT-X-TARGETDURATION less than EXTINF:7.30 
 EXTINF:8.33
>>> 
>>> 
>>> 2. the version maybe will update when use hls_segment_type or 
>>> append_list etc. when the operation is support from different 
>>> version m3u8.
>> 
>> I don't follow what you mean here. The version number is known up 
>> front, based on the options that were passed in. It should be 
>> illegal to switch between versions when trying to update an existing 
>> manifest. When can this legitimately happen?
> there maybe have some player cannot support high version of m3u8, for 
> example old parser or player just support the VERSION 3,
> this must think about all of the player or parser, because ffmpeg is 
> not used only by myself.
> 
> Or what about get the #EXT-X-VERSION position, to update 

[FFmpeg-devel] [PATCH] avs2: Correct expression error and simplify log

[hwren]

Signed-off-by: hwren 
---
 doc/decoders.texi| 2 +-
 doc/general.texi | 2 +-
 libavcodec/avs2_parser.c | 2 +-
 libavcodec/codec_desc.c  | 2 +-
 libavcodec/libdavs2.c| 5 ++---
 5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 9439b7b..31e96fb 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -49,7 +49,7 @@ top-field-first is assumed
 
 @section libdavs2
 
-AVS2/IEEE 1857.4 video decoder wrapper.
+AVS2-P2/IEEE1857.4 video decoder wrapper.
 
 This decoder allows libavcodec to decode AVS2 streams with davs2 library.
 
diff --git a/doc/general.texi b/doc/general.texi
index cd725bb..3d15840 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -19,7 +19,7 @@ explicitly requested by passing the appropriate flags to
 
 @section libdavs2
 
-FFmpeg can make use of the davs2 library for AVS2/IEEE 1857.4 video decoding.
+FFmpeg can make use of the davs2 library for AVS2-P2/IEEE1857.4 video decoding.
 
 Go to @url{https://github.com/pkuvcl/davs2} and follow the instructions for
 installing the library. Then pass @code{--enable-libdavs2} to configure to
diff --git a/libavcodec/avs2_parser.c b/libavcodec/avs2_parser.c
index 520e98a..1c9b342 100644
--- a/libavcodec/avs2_parser.c
+++ b/libavcodec/avs2_parser.c
@@ -1,5 +1,5 @@
 /*
- * AVS2/IEEE 1857.4 video parser.
+ * AVS2-P2/IEEE1857.4 video parser.
  * Copyright (c) 2018  Huiwen Ren 
  *
  * This file is part of FFmpeg.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 2fe4aaa..1cbb241 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1398,7 +1398,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .id= AV_CODEC_ID_AVS2,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "avs2",
-.long_name = NULL_IF_CONFIG_SMALL("AVS2/IEEE 1857.4"),
+.long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
 .props = AV_CODEC_PROP_LOSSY,
 },
 {
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 12db1f9..80c2e2b 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -51,7 +51,7 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 
 /* init the decoder */
 cad->param.threads  = avctx->thread_count;
-cad->param.info_level   = 0;
+cad->param.info_level   = DAVS2_LOG_WARNING;
 cad->decoder= davs2_decoder_open(>param);
 
 if (!cad->decoder) {
@@ -59,7 +59,6 @@ static av_cold int davs2_init(AVCodecContext *avctx)
 return AVERROR(EINVAL);
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "decoder created. %p\n", cad->decoder);
 return 0;
 }
 
@@ -163,7 +162,7 @@ static int davs2_decode_frame(AVCodecContext *avctx, void 
*data,
 
 AVCodec ff_libdavs2_decoder = {
 .name   = "libdavs2",
-.long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2/IEEE 1857.4"),
+.long_name  = NULL_IF_CONFIG_SMALL("Decoder for AVS2-P2/IEEE1857.4"),
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_AVS2,
 .priv_data_size = sizeof(DAVS2Context),
-- 
2.7.4

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

[FFmpeg-devel] [PATCH] lavc/extract_extradata_bsf.c: add AVS2

[hwren]

Signed-off-by: hwren 
---
 libavcodec/extract_extradata_bsf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/extract_extradata_bsf.c 
b/libavcodec/extract_extradata_bsf.c
index 6deb663..f37427c 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -331,6 +331,7 @@ static const struct {
uint8_t **data, int *size);
 } extract_tab[] = {
 { AV_CODEC_ID_AV1,extract_extradata_av1 },
+{ AV_CODEC_ID_AVS2,   extract_extradata_mpeg4   },
 { AV_CODEC_ID_CAVS,   extract_extradata_mpeg4   },
 { AV_CODEC_ID_H264,   extract_extradata_h2645   },
 { AV_CODEC_ID_HEVC,   extract_extradata_h2645   },
@@ -397,6 +398,7 @@ static void extract_extradata_close(AVBSFContext *ctx)
 
 static const enum AVCodecID codec_ids[] = {
 AV_CODEC_ID_AV1,
+AV_CODEC_ID_AVS2,
 AV_CODEC_ID_CAVS,
 AV_CODEC_ID_H264,
 AV_CODEC_ID_HEVC,
-- 
2.7.4

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

Re: [FFmpeg-devel] First Patch for hlsenc.c for https://trac.ffmpeg.org/ticket/7281

[Ronak Patel]

> On Aug 6, 2018, at 7:19 AM, Liu Steven  wrote:
> 
> 
> 
>>> 在 2018年8月6日，下午7:12，Ronak Patel  写道：
>>> 
>>> 
>>> On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
>>> 
>>> 
>>> 
 在 2018年8月4日，上午2:17，Ronak  写道：
 
>> I have read this patch some problem for this patch.
>> 
>> 1. maybe there will have a problem when duration is not same when 
>> every fragment, for example:
>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i 
>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>> -hls_list_size 0 output_test.m3u8
>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>> #EXTM3U
>> #EXT-X-VERSION:3
>> #EXT-X-TARGETDURATION:8
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXTINF:3.87,
>> output_test0.ts
>> #EXTINF:7.30,
>> output_test1.ts
>> #EXTINF:8.33,
>> output_test2.ts
>> 
>> the output_test0.ts’s duration is short than output_test1.ts, the 
>> #EXT-X-TARGETDURATION need update to the longest duration.
>> this operation (check the longest duration) will happen at every 
>> fragment write complete.
>> it will not update when move the update option to the 
>> hls_write_header,
>> 
> 
> This is a problem in the code that splits the mpegts files. I've 
> filed a separate issue for this here: 
> https://trac.ffmpeg.org/ticket/7341. Mpegts segmentation should be 
> following the hls_time parameter (or the default length).
 This is whatever hls_time, is decide by keyframe position, this is 
 happen when GOP size is not a permanent t position.
 
> 
> This is happening now with fMP4 assets, but not with mpegts.
 Whatever fmp4 or mpegts, all of them need fix the problem of duration 
 refresh.
 
 for example:
 
 liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss -v quiet -i 
 ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
 -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
 liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
 #EXTM3U
 #EXT-X-VERSION:7
 #EXT-X-TARGETDURATION:8
 #EXT-X-MEDIA-SEQUENCE:0
 #EXT-X-MAP:URI="init.mp4"
 #EXTINF:3.87,
 output_test0.m4s
 #EXTINF:7.30,
 output_test1.m4s
 #EXTINF:8.33,
 liuqideMacBook-Pro:xxx liuqi$
>>> 
>>> This is after your patch:
>>> liuqideMacBook-Pro:xxx liuqi$  ./ffmpeg -ss 17 -v quiet -i 
>>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
>>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>>> #EXTM3U
>>> #EXT-X-VERSION:7
>>> #EXT-X-TARGETDURATION:3
>>> #EXT-X-MEDIA-SEQUENCE:0
>>> #EXT-X-MAP:URI="init.mp4"
>>> #EXTINF:3.87,
>>> output_test0.m4s
>>> #EXTINF:7.30,
>>> output_test1.m4s
>>> #EXTINF:8.33,
>>> 
>>> The RFC https://www.rfc-editor.org/rfc/rfc8216.txt describe:
>>> 
>>> 4.3.3.1.  EXT-X-TARGETDURATION
>>> 
>>> The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>>> duration.  The EXTINF duration of each Media Segment in the Playlist
>>> file, when rounded to the nearest integer, MUST be less than or equal
>>> to the target duration; longer segments can trigger playback stalls
>>> or other errors.  It applies to the entire Playlist file.  Its format
>>> is:
>>> 
>>> #EXT-X-TARGETDURATION:
>>> 
>>> where s is a decimal-integer indicating the target duration in
>>> seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>>> 
>>> your patch make the EXT-X-TARGETDURATION less than EXTINF:7.30 
>>> EXTINF:8.33
>> 
>> 
>> 2. the version maybe will update when use hls_segment_type or 
>> append_list etc. when the operation is support from different 
>> version m3u8.
> 
> I don't follow what you mean here. The version number is known up 
> front, based on the options that were passed in. It should be illegal 
> to switch between versions when trying to update an existing 
> manifest. When can this legitimately happen?
 there maybe have some player cannot support high version of m3u8, for 
 example old parser or player just support the VERSION 3,
 this must think about all of the player or parser, because ffmpeg is 
 not used only by myself.
 
 Or what about get the #EXT-X-VERSION position, to update it? looks 
 like flvenc.c or movenc.c date shift
 
> 
>> 3. need update segments vs->segments when hls_list_size option is 
>> set.

Re: [FFmpeg-devel] First Patch for hlsenc.c for https://trac.ffmpeg.org/ticket/7281

[Liu Steven]

> 在 2018年8月6日，下午7:12，Ronak Patel  写道：
> 
>> 
>> On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
>> 
>> 
>> 
>>> 在 2018年8月4日，上午2:17，Ronak  写道：
>>> 
> I have read this patch some problem for this patch.
> 
> 1. maybe there will have a problem when duration is not same when 
> every fragment, for example:
> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i 
> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
> -hls_list_size 0 output_test.m3u8
> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
> #EXTM3U
> #EXT-X-VERSION:3
> #EXT-X-TARGETDURATION:8
> #EXT-X-MEDIA-SEQUENCE:0
> #EXTINF:3.87,
> output_test0.ts
> #EXTINF:7.30,
> output_test1.ts
> #EXTINF:8.33,
> output_test2.ts
> 
> the output_test0.ts’s duration is short than output_test1.ts, the 
> #EXT-X-TARGETDURATION need update to the longest duration.
> this operation (check the longest duration) will happen at every 
> fragment write complete.
> it will not update when move the update option to the 
> hls_write_header,
> 
 
 This is a problem in the code that splits the mpegts files. I've filed 
 a separate issue for this here: https://trac.ffmpeg.org/ticket/7341. 
 Mpegts segmentation should be following the hls_time parameter (or the 
 default length).
>>> This is whatever hls_time, is decide by keyframe position, this is 
>>> happen when GOP size is not a permanent t position.
>>> 
 
 This is happening now with fMP4 assets, but not with mpegts.
>>> Whatever fmp4 or mpegts, all of them need fix the problem of duration 
>>> refresh.
>>> 
>>> for example:
>>> 
>>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss -v quiet -i 
>>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
>>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>>> #EXTM3U
>>> #EXT-X-VERSION:7
>>> #EXT-X-TARGETDURATION:8
>>> #EXT-X-MEDIA-SEQUENCE:0
>>> #EXT-X-MAP:URI="init.mp4"
>>> #EXTINF:3.87,
>>> output_test0.m4s
>>> #EXTINF:7.30,
>>> output_test1.m4s
>>> #EXTINF:8.33,
>>> liuqideMacBook-Pro:xxx liuqi$
>> 
>> This is after your patch:
>> liuqideMacBook-Pro:xxx liuqi$  ./ffmpeg -ss 17 -v quiet -i 
>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>> #EXTM3U
>> #EXT-X-VERSION:7
>> #EXT-X-TARGETDURATION:3
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXT-X-MAP:URI="init.mp4"
>> #EXTINF:3.87,
>> output_test0.m4s
>> #EXTINF:7.30,
>> output_test1.m4s
>> #EXTINF:8.33,
>> 
>> The RFC https://www.rfc-editor.org/rfc/rfc8216.txt describe:
>> 
>> 4.3.3.1.  EXT-X-TARGETDURATION
>> 
>> The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>> duration.  The EXTINF duration of each Media Segment in the Playlist
>> file, when rounded to the nearest integer, MUST be less than or equal
>> to the target duration; longer segments can trigger playback stalls
>> or other errors.  It applies to the entire Playlist file.  Its format
>> is:
>> 
>> #EXT-X-TARGETDURATION:
>> 
>> where s is a decimal-integer indicating the target duration in
>> seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>> 
>> your patch make the EXT-X-TARGETDURATION less than EXTINF:7.30 
>> EXTINF:8.33
> 
> 
> 2. the version maybe will update when use hls_segment_type or 
> append_list etc. when the operation is support from different version 
> m3u8.
 
 I don't follow what you mean here. The version number is known up 
 front, based on the options that were passed in. It should be illegal 
 to switch between versions when trying to update an existing manifest. 
 When can this legitimately happen?
>>> there maybe have some player cannot support high version of m3u8, for 
>>> example old parser or player just support the VERSION 3,
>>> this must think about all of the player or parser, because ffmpeg is 
>>> not used only by myself.
>>> 
>>> Or what about get the #EXT-X-VERSION position, to update it? looks like 
>>> flvenc.c or movenc.c date shift
>>> 
 
> 3. need update segments vs->segments when hls_list_size option is set.
> 
 
 What do you mean by this and where should I do it?
>>> for example, hls_list_size is 4, the m3u8 list should refresh every 
>>> time when make a new fragment.

Re: [FFmpeg-devel] First Patch for hlsenc.c for https://trac.ffmpeg.org/ticket/7281

[Ronak Patel]

> On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
> 
> 
> 
>> 在 2018年8月4日，上午2:17，Ronak  写道：
>> 
 I have read this patch some problem for this patch.
 
 1. maybe there will have a problem when duration is not same when 
 every fragment, for example:
 liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i 
 ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
 -hls_list_size 0 output_test.m3u8
 liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
 #EXTM3U
 #EXT-X-VERSION:3
 #EXT-X-TARGETDURATION:8
 #EXT-X-MEDIA-SEQUENCE:0
 #EXTINF:3.87,
 output_test0.ts
 #EXTINF:7.30,
 output_test1.ts
 #EXTINF:8.33,
 output_test2.ts
 
 the output_test0.ts’s duration is short than output_test1.ts, the 
 #EXT-X-TARGETDURATION need update to the longest duration.
 this operation (check the longest duration) will happen at every 
 fragment write complete.
 it will not update when move the update option to the hls_write_header,
 
>>> 
>>> This is a problem in the code that splits the mpegts files. I've filed 
>>> a separate issue for this here: https://trac.ffmpeg.org/ticket/7341. 
>>> Mpegts segmentation should be following the hls_time parameter (or the 
>>> default length).
>> This is whatever hls_time, is decide by keyframe position, this is 
>> happen when GOP size is not a permanent t position.
>> 
>>> 
>>> This is happening now with fMP4 assets, but not with mpegts.
>> Whatever fmp4 or mpegts, all of them need fix the problem of duration 
>> refresh.
>> 
>> for example:
>> 
>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss -v quiet -i 
>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
>> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
>> #EXTM3U
>> #EXT-X-VERSION:7
>> #EXT-X-TARGETDURATION:8
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXT-X-MAP:URI="init.mp4"
>> #EXTINF:3.87,
>> output_test0.m4s
>> #EXTINF:7.30,
>> output_test1.m4s
>> #EXTINF:8.33,
>> liuqideMacBook-Pro:xxx liuqi$
> 
> This is after your patch:
> liuqideMacBook-Pro:xxx liuqi$  ./ffmpeg -ss 17 -v quiet -i 
> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls 
> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8
> liuqideMacBook-Pro:xxx liuqi$ head -n 10  output_test.m3u8
> #EXTM3U
> #EXT-X-VERSION:7
> #EXT-X-TARGETDURATION:3
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-MAP:URI="init.mp4"
> #EXTINF:3.87,
> output_test0.m4s
> #EXTINF:7.30,
> output_test1.m4s
> #EXTINF:8.33,
> 
> The RFC https://www.rfc-editor.org/rfc/rfc8216.txt describe:
> 
> 4.3.3.1.  EXT-X-TARGETDURATION
> 
> The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
> duration.  The EXTINF duration of each Media Segment in the Playlist
> file, when rounded to the nearest integer, MUST be less than or equal
> to the target duration; longer segments can trigger playback stalls
> or other errors.  It applies to the entire Playlist file.  Its format
> is:
> 
> #EXT-X-TARGETDURATION:
> 
> where s is a decimal-integer indicating the target duration in
> seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
> 
> your patch make the EXT-X-TARGETDURATION less than EXTINF:7.30 
> EXTINF:8.33
 
 
 2. the version maybe will update when use hls_segment_type or 
 append_list etc. when the operation is support from different version 
 m3u8.
>>> 
>>> I don't follow what you mean here. The version number is known up 
>>> front, based on the options that were passed in. It should be illegal 
>>> to switch between versions when trying to update an existing manifest. 
>>> When can this legitimately happen?
>> there maybe have some player cannot support high version of m3u8, for 
>> example old parser or player just support the VERSION 3,
>> this must think about all of the player or parser, because ffmpeg is not 
>> used only by myself.
>> 
>> Or what about get the #EXT-X-VERSION position, to update it? looks like 
>> flvenc.c or movenc.c date shift
>> 
>>> 
 3. need update segments vs->segments when hls_list_size option is set.
 
>>> 
>>> What do you mean by this and where should I do it?
>> for example, hls_list_size is 4, the m3u8 list should refresh every time 
>> when make a new fragment.
>> 
>> first time:
>> 1.m4s
>> 2.m4s
>> 3.m4s
>> 4.m4s
>> 
>> sencond time:
>> 2.m4s
>> 3.m4s
>> 4.m4s
>> 5.m4s
> 
> after 

[FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add IMM4 decoder

[Paul B Mahol]

Hi,

patch attached.


0001-avcodec-add-IMM4-decoder.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] libavcodec: v4l2m2m: fix error handling during buffer init

[Jorge Ramirez-Ortiz]

On 08/04/2018 02:40 AM, Lukas Rusak wrote:

From: Jorge Ramirez-Ortiz 

Signed-off-by: Jorge Ramirez-Ortiz 
---
  libavcodec/v4l2_context.c | 19 ---
  libavcodec/v4l2_m2m_dec.c |  9 +++--
  2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 9457fadb1e..fd3161ce2f 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -263,6 +263,12 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
  /* if we are draining and there are no more capture buffers queued in the 
driver we are done */
  if (!V4L2_TYPE_IS_OUTPUT(ctx->type) && ctx_to_m2mctx(ctx)->draining) {
  for (i = 0; i < ctx->num_buffers; i++) {
+/* catpture buffer initialization happens during decode hence


could you amend the typo (/s/catpture/capture) when you resubmit please ^^


+ * detection happens at runtime
+ */
+if (!ctx->buffers)
+break;
+
  if (ctx->buffers[i].status == V4L2BUF_IN_DRIVER)
  goto start;
  }
@@ -724,9 +730,8 @@ int ff_v4l2_context_init(V4L2Context* ctx)
  ctx->buffers[i].context = ctx;
  ret = ff_v4l2_buffer_initialize(>buffers[i], i);
  if (ret < 0) {
-av_log(logger(ctx), AV_LOG_ERROR, "%s buffer initialization (%s)\n", 
ctx->name, av_err2str(ret));
-av_free(ctx->buffers);
-return ret;
+av_log(logger(ctx), AV_LOG_ERROR, "%s buffer[%d] initialization 
(%s)\n", ctx->name, i, av_err2str(ret));
+goto error;
  }
  }
  
@@ -739,4 +744,12 @@ int ff_v4l2_context_init(V4L2Context* ctx)

  V4L2_TYPE_IS_MULTIPLANAR(ctx->type) ? 
ctx->format.fmt.pix_mp.plane_fmt[0].bytesperline : 
ctx->format.fmt.pix.bytesperline);
  
  return 0;

+
+error:
+v4l2_release_buffers(ctx);
+
+av_free(ctx->buffers);
+ctx->buffers = NULL;
+
+return ret;
  }
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 29d894492f..c4f4f7837f 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -92,8 +92,8 @@ static int v4l2_try_start(AVCodecContext *avctx)
  if (!capture->buffers) {
  ret = ff_v4l2_context_init(capture);
  if (ret) {
-av_log(avctx, AV_LOG_DEBUG, "can't request output buffers\n");
-return ret;
+av_log(avctx, AV_LOG_ERROR, "can't request capture buffers\n");
+return AVERROR(ENOMEM);
  }
  }
  
@@ -157,6 +157,11 @@ static int v4l2_receive_frame(AVCodecContext *avctx, AVFrame *frame)

  ret = v4l2_try_start(avctx);
  if (ret) {
  av_packet_unref();
+
+/* cant recover */
+if (ret == AVERROR(ENOMEM))
+return ret;
+
  return 0;
  }
  }


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

[FFmpeg-devel] [PATCH] Fix: Branch condition of KLV metadata AU header remover.

[Motoki Shimizu]

KLV metadata access unit header remover has an effect on the other unrelated 
Packetized metadata.
Branch condition code should be modified to check the codec_id.
---
 libavformat/mpegts.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index a5cb17a..bc6bdc6 
100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1208,7 +1208,9 @@ skip:
 p += sl_header_bytes;
 buf_size -= sl_header_bytes;
 }
-if (pes->stream_type == 0x15 && buf_size >= 5) {
+if (pes->stream_type == 0x15 &&
+pes->st->codecpar->codec_id == AV_CODEC_ID_SMPTE_KLV &&
+buf_size >= 5) {
 /* skip metadata access unit header */
 pes->pes_header_size += 5;
 p += 5;
--
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/scpr: Check for min > max in decompress_p()

[Paul B Mahol]

On 8/5/18, Michael Niedermayer  wrote:
> On Sun, Aug 05, 2018 at 10:08:31AM +0200, Paul B Mahol wrote:
>> On 8/5/18, Michael Niedermayer  wrote:
>> > Fixes: Timeout
>> > Fixes:
>> > 9342/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-4795990841229312
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavcodec/scpr.c | 3 +++
>> >  1 file changed, 3 insertions(+)
>> >
>> > diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
>> > index 72f59d5917..d1e47b09ac 100644
>> > --- a/libavcodec/scpr.c
>> > +++ b/libavcodec/scpr.c
>> > @@ -525,6 +525,9 @@ static int decompress_p(AVCodecContext *avctx,
>> >  if (ret < 0)
>> >  return ret;
>> >
>> > +if (min > max)
>> > +return AVERROR_INVALIDDATA;
>> > +
>>
>> Shouldn't this check be actually bellow?
>
> yes, fixed, locally
>
>
>> You sure this does not break valid files?
>
> i found no file that it breaks, beyond this, no iam not sure.
> It mostly based on logic thinking that these would not be ordered the
> other way, as that seems not usefull
>
> Is there some specification or more files i can test ?

It should be fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avformat/matroskaenc: update AV1 support

[Steve Lhomme]

On 31/07/2018 17:19, James Almer wrote:

On 7/31/2018 3:37 AM, Steve Lhomme wrote:

On 30/07/2018 17:13, James Almer wrote:

On 7/30/2018 2:03 AM, Steve Lhomme wrote:

On 26/07/2018 03:11, James Almer wrote:

Make sure to not write forbidden OBUs to CodecPrivate, and do the same
with
unnecessary OBUs for packets.

Does this include reordering the OBUs ? The first one must be the
Sequence Header OBU. Also it must be the only one of that kind.

No, it doesn't. I can make that change, but why does it matter if it's
the first? Why can't a metadata OBU be before a Seq Header? isobmff

Because if the spec say it's the first and its enforced, the OBU parser
needed at the container level may be simpler. The muxing side can have
more complexity if needed.

Nothing in the spec says it's the first, afaics, just that in a temporal
unit if present it must prepend a frame. I may be misreading it, though.


As we're talking about the Matroska muxer the current document says:
The first OBU MUST be the first |Sequence Header OBU| and be the only 
OBU of type |OBU_SEQUENCE_HEADER| in the |CodecPrivate|




In any case, my suggestion in the isobmff issue includes ordering of
OBUs in av1C.


Good. Otherwise we can create an ISOBMFF file with 100 metadata OBUs 
and then the Sequence Header OBU and it's still valid.





doesn't care what's first, only what's in.

I requested that the same constraint be applied in ISOBMFF
https://github.com/AOMediaCodec/av1-isobmff/pull/47#issuecomment-408598719


A parser is currently forced to know how to read OBUs anyway, and it
could just skip any metadata obu before the sequence header.

For that matter, i do agree with
https://github.com/AOMediaCodec/av1-isobmff/issues/7#issuecomment-406257234

and
https://github.com/AOMediaCodec/av1-isobmff/issues/46#issuecomment-406516226

that perhaps av1C should, much like hvcC, avcC and in it's own way also
vpcC, contain a bunch of header bytes listing some basic information
(and therefore the entire thing, sans atom size and fourcc, be included
in CodecPrivate verbatim). Things like profile, level, and maybe number
of OBUs, before the raw OBUs.
As an extra benefit than simply removing the requirement for demuxers to
parse OBUs that may even only be in sample data just to see if the file
can be decoded (firing up a hardware decoder can be expensive), it would
also give us a way to identify the source of the bitstream (mp4/mkv vs
ivf/raw/annexb/etc), for example for the purpose of inserting the
extradata Seq Header if not present on key frames (Matroska allows to
remove it, but isobmff in section 2.5 seems to want a sync sample to be
a fully compliant RAP without the need of extradata obus, despite the
description in section 2.4.4), achieved by writing and using an
av1_mp4tolobf bsf or similar, which would then be included where needed
instead of the naive dump_extradata one from patch 2/5 of this set, for
example.

I totally support this. In the end storing OBUs in extra data is
becoming a PITA, especially if it needs to be prepended to some frames
but not all. If we stick to a simpler structure with what's needed to
identify decoder properties (mostly the profile) it would make things a
lot easier.

The process of assembling a bitstream for the purpose of decoding or
storing is up to the implementation. The requirement for the global Seq
Headers to be prepended to key frames for raw bitstream purposes is
essentially the same as sps/pps/vps from h264 and h265.


I did not know that.



ffmpeg's decoders keep global headers in extradata to use them as they
see fit (native decoders), or request the aid of bitstream filters like
h264_mp4toannexb to assemble the bitstream using said extradata if
required (hardware decoders, some external decoders). Similarly, muxers
for non global header containers (ivf, raw, etc) do the same on their
own, or with the aid of a bitstream filter.


It seems odd that it's done at the decoder level and not the container 
level, since it's a feature of a particular mapping. Or is it done 
through a flag that tells that the extradata need to be prepended for 
keyframes ?





Signed-off-by: James Almer 
---
    libavformat/matroskaenc.c | 6 ++
    1 file changed, 6 insertions(+)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b7ff1950d3..816ddd059a 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -21,6 +21,7 @@
      #include 
    +#include "av1.h"
    #include "avc.h"
    #include "hevc.h"
    #include "avformat.h"
@@ -769,6 +770,9 @@ static int
mkv_write_native_codecprivate(AVFormatContext *s, AVIOContext *pb,
    ff_isom_write_hvcc(dyn_cp, par->extradata,
   par->extradata_size, 0);
    return 0;
+    case AV_CODEC_ID_AV1:
+    return ff_isom_write_av1c(dyn_cp, par->extradata,
+  par->extradata_size);
    case AV_CODEC_ID_ALAC:
    if (par->extradata_size < 36) {