Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Steven Liu]

2016-09-09 9:59 GMT+08:00 Aman Gupta :

> Yea this doesn't work at all. I wish someone had bothered to check before
> the patch was proposed or merged.
>
> With "-ss 20 -i file -segment_time 2 -segment_start_number 10
> -initial_offset 20":
>
> #EXTM3U
> #EXT-X-VERSION:3
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-ALLOW-CACHE:YES
> #EXT-X-TARGETDURATION:3
> #EXTINF:2.023344,
> out10.ts
> #EXTINF:2.002011,
> out11.ts
> #EXTINF:2.002011,
> out12.ts
>
>
> With "-ss 20 -i file -segment_time 2 -segment_start_number 10
> -output_ts_offset 20":
>
> #EXTM3U
> #EXT-X-VERSION:3
> #EXT-X-MEDIA-SEQUENCE:0
> #EXT-X-ALLOW-CACHE:YES
> #EXT-X-TARGETDURATION:21
> #EXTINF:20.200211,
> out10.ts
> #EXTINF:0.200211,
> out11.ts
> #EXTINF:0.200211,
> out12.ts
>
>
> The TARGETDURATION as well as the duration of the segments themselves is
> incorrect.
>
> I've send a new patch to fix this issue, check it please,  i have check it
, no problem.

> Aman
>
> On Thu, Sep 8, 2016 at 6:48 PM, Aman Gupta  wrote:
>
> > I tried to switch from -initial_offset to -output_ts_offset, but it does
> > not work as expected. In Safari, the generated HLS stream stalls out and
> > stops playing after the first segment.
> >
> > Aman
> >
> > On Thu, Sep 8, 2016 at 5:54 PM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> >> On Fri, Sep 09, 2016 at 02:59:52AM +0800, Steven Liu wrote:
> >> > 2016-09-08 22:52 GMT+08:00 Carl Eugen Hoyos :
> >> >
> >> > > 2016-09-08 16:01 GMT+02:00 Steven Liu :
> >> > >
> >> > > > +if (seg->initial_offset > 0) {
> >> > > > +av_log(s, AV_LOG_WARNING, "NOTE: the option
> initial_offset
> >> will
> >> > > be
> >> > > > deprecated soon,"
> >> > >
> >> > > "is deprecated" even if you decide not to ignore the value set.
> >> > >
> >> > > Carl Eugen
> >> > >
> >> >
> >> > Sorry for my poor English,
> >>
> >> fixed the english and applied
> >>
> >>
> >> > What about "be removed"?
> >>
> >> that would have worked too
> >>
> >> the option is deprecated
> >> see https://en.wiktionary.org/wiki/deprecate#English
> >> "To declare something obsolescent; to recommend against a function,
> >> technique, command, etc. that still works but has been replaced. "
> >>
> >> [...]
> >> --
> >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >>
> >> Many things microsoft did are stupid, but not doing something just
> because
> >> microsoft did it is even more stupid. If everything ms did were stupid
> >> they
> >> would be bankrupt already.
> >>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4] lavf : scale_vaapi : add denoise/sharpless support

[Jun Zhao]

v4 : - fix sharpless typo(sharpless -> sharpness)
 - when don't support denoise/sharpness, report the error and return
 - fix denoise/sharpness params buffer leak in error handle
v3 : fix sharpless mapping issue
v2 : fix filter support flag check logic issue
From d1f0b556bdd6be4dffcd3b1b93cba5cd1098908a Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 30 Aug 2016 14:36:00 +0800
Subject: [PATCH v4] lavf : scale_vaapi : add denoise/sharpless support.

add denoise/sharpless support, used scope [-1, 100] as the input
scope.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_scale_vaapi.c | 112 +++
 1 file changed, 112 insertions(+)

diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index 8dd5acf..e48e201 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -53,6 +53,14 @@ typedef struct ScaleVAAPIContext {
 int output_width;
 int output_height;
 
+VAProcFilterCap denoise_caps;
+int denoise; // enable denoise algo. level is the optional
+ // value from the interval [-1, 100], -1 means 
disabled
+
+VAProcFilterCap sharpness_caps;
+int sharpness;   // enable sharpness. level is the optional value
+ // from the interval [-1, 100], -1 means disabled
+
 } ScaleVAAPIContext;
 
 
@@ -117,6 +125,8 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 AVVAAPIFramesContext *va_frames;
 VAStatus vas;
 int err, i;
+unsigned int num_denoise_caps = 1;
+unsigned int num_sharpness_caps = 1;
 
 scale_vaapi_pipeline_uninit(ctx);
 
@@ -225,6 +235,28 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 goto fail;
 }
 
+if (ctx->denoise != -1) {
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterNoiseReduction,
+ >denoise_caps, 
_denoise_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to query denoise caps "
+   "context: %d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+}
+
+if (ctx->sharpness != -1) {
+vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
+ VAProcFilterSharpening,
+ >sharpness_caps, 
_sharpness_caps);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR, "Failed to query sharpness caps "
+   "context: %d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+}
+
 av_freep();
 av_hwframe_constraints_free();
 return 0;
@@ -250,6 +282,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace 
av_cs)
 }
 }
 
+static float map_to_range(
+int input, int in_min, int in_max,
+float out_min, float out_max)
+{
+return (input - in_min) * (out_max - out_min) / (in_max - in_min) + 
out_min;
+}
+
+
 static int scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame *input_frame)
 {
 AVFilterContext *avctx = inlink->dst;
@@ -259,6 +299,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 VASurfaceID input_surface, output_surface;
 VAProcPipelineParameterBuffer params;
 VABufferID params_id;
+VABufferID denoise_id;
+VABufferID sharpness_id;
+VABufferID filter_bufs[8];
+int num_filter_bufs = 0;
 VAStatus vas;
 int err;
 
@@ -290,6 +334,43 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 av_log(ctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
 
+if (ctx->denoise != -1) {
+VAProcFilterParameterBuffer denoise;
+denoise.type  = VAProcFilterNoiseReduction;
+denoise.value =  map_to_range(ctx->denoise, 0, 100,
+  ctx->denoise_caps.range.min_value,
+  ctx->denoise_caps.range.max_value);
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+   VAProcFilterParameterBufferType, sizeof(denoise), 1,
+   , _id);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(ctx, AV_LOG_ERROR,  "Failed to create denoise parameter 
buffer: "
+   "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+filter_bufs[num_filter_bufs++] = denoise_id;
+}
+
+if (ctx->sharpness != -1) {
+VAProcFilterParameterBuffer sharpness;
+sharpness.type  = VAProcFilterSharpening;
+sharpness.value = map_to_range(ctx->sharpness,
+   0, 100,
+   ctx->sharpness_caps.range.min_value,
+ 

[FFmpeg-devel] Fwd: Re: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support

[Jun Zhao]

cc Mark


 Forwarded Message 
Subject: Re: [FFmpeg-devel] [PATCH v3] lavf : scale_vaapi : add 
denoise/sharpless support
Date: Mon, 5 Sep 2016 09:52:22 +0800
From: Jun Zhao 
To: FFmpeg development discussions and patches 



On 2016/8/31 6:48, Mark Thompson wrote:
> On 30/08/16 09:00, Jun Zhao wrote:
>> v3 : fix sharpless mapping issue
>> v2 : fix filter support flag check logic issue
> 
> Hi,
> 
> A general remark to start: vf_scale_vaapi is named to be a scaling filter 
> (i.e. it replaces vf_scale/swscale for AV_PIX_FMT_VAAPI) - is this therefore 
> really the right place to be adding other operations unrelated to scaling?
> 
> Do use-cases for these operations actually make sense to add here rather than 
> in a separate filter?  (I'm not sure what the answer to this should be - I 
> would definitely argue that the deinterlacer should be a separate filter, but 
> these other operations are unclear.)
> 
> 

As you know, VPP use the pipeline mode, split the scale/denoise/sharpness/... 
in 
different filter maybe is not good idea, I guess nobody want to call 
vaRenderPicture()/
vaEndpicture/... again and again in 
vf_scale_vaapi.c/vf_denosie_vaapi.c/vf_sharpness_vaapi.c/...

 
>> From 415b00c6157d8311cc18713e6347400895f7333c Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 30 Aug 2016 14:36:00 +0800
>> Subject: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support.
>>
>> add denoise/sharpless support, used scope [-1, 100] as the input
>> scope.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vf_scale_vaapi.c | 115 
>> +++
>>  1 file changed, 115 insertions(+)
>>
>> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
>> index 8dd5acf..5658746 100644
>> --- a/libavfilter/vf_scale_vaapi.c
>> +++ b/libavfilter/vf_scale_vaapi.c
>> @@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
>>  int output_width;
>>  int output_height;
>>
>> +VAProcFilterCap denoise_caps;
>> +int support_denoise;
>> +int denoise; // enable denoise algo. level is the optional
>> + // value from the interval [-1, 100], -1 means 
>> disabled
>> +
>> +VAProcFilterCap sharpless_caps;
>> +int support_sharpless;
>> +int sharpless;   // enable sharpless. level is the optional value
>> + // from the interval [-1, 100], -1 means disabled
> 
> "sharpless"?  "sharpness" or "sharpen", might be better.  (The filter is 
> called "sharpening", though maybe it can also blur the image?)
> 
>> +
>>  } ScaleVAAPIContext;
>>
>>
>> @@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink 
>> *outlink)
>>  AVVAAPIFramesContext *va_frames;
>>  VAStatus vas;
>>  int err, i;
>> +unsigned int num_denoise_caps = 1;
>> +unsigned int num_sharpless_caps = 1;
>>
>>  scale_vaapi_pipeline_uninit(ctx);
>>
>> @@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink 
>> *outlink)
>>  goto fail;
>>  }
>>
>> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
>> + VAProcFilterNoiseReduction,
>> + >denoise_caps, _denoise_caps);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
>> +   "context: %d (%s).\n", vas, vaErrorStr(vas));
>> +ctx->support_denoise = 0;
>> +} else {
>> +ctx->support_denoise = 1;
>> +}
>> +
>> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
>> + VAProcFilterSharpening,
>> + >sharpless_caps, 
>> _sharpless_caps);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
>> +   "context: %d (%s).\n", vas, vaErrorStr(vas));
>> +ctx->support_sharpless = 0;
>> +} else {
>> +ctx->support_sharpless = 1;
>> +}
> 
> If the user explicitly requests these filters that can still be ignored if 
> they not supported?  Maybe it would be better to just give up with an error 
> message at that point.
> 
> Similarly, the warning that they are not supported is unhelpful if the user 
> didn't ask for them.
> 
>> +
>> +
>>  av_freep();
>>  av_hwframe_constraints_free();
>>  return 0;
>> @@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace 
>> av_cs)
>>  }
>>  }
>>
>> +static float map_to_range(
>> +int input, int in_min, int in_max,
>> +float out_min, float out_max)
>> +{
>> +return (input - in_min) * (out_max - out_min) / (in_max - in_min) + 
>> out_min;
>> +}
>> +
>> +
>>  static int scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame 
>> *input_frame)
>>  {
>>  AVFilterContext *avctx = inlink->dst;

[FFmpeg-devel] Fwd: Re: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support

[Jun Zhao]

cc Mark

 Forwarded Message 
Subject: Re: [FFmpeg-devel] [PATCH v3] lavf : scale_vaapi : add 
denoise/sharpless support
Date: Mon, 5 Sep 2016 09:33:43 +0800
From: Jun Zhao 
To: ffmpeg-devel@ffmpeg.org



On 2016/8/31 6:48, Mark Thompson wrote:
> On 30/08/16 09:00, Jun Zhao wrote:
>> v3 : fix sharpless mapping issue
>> v2 : fix filter support flag check logic issue
> 
> Hi,
> 
> A general remark to start: vf_scale_vaapi is named to be a scaling filter 
> (i.e. it replaces vf_scale/swscale for AV_PIX_FMT_VAAPI) - is this therefore 
> really the right place to be adding other operations unrelated to scaling?
> 
> Do use-cases for these operations actually make sense to add here rather than 
> in a separate filter?  (I'm not sure what the answer to this should be - I 
> would definitely argue that the deinterlacer should be a separate filter, but 
> these other operations are unclear.)
> 
> 
>> From 415b00c6157d8311cc18713e6347400895f7333c Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 30 Aug 2016 14:36:00 +0800
>> Subject: [PATCH v3] lavf : scale_vaapi : add denoise/sharpless support.
>>
>> add denoise/sharpless support, used scope [-1, 100] as the input
>> scope.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vf_scale_vaapi.c | 115 
>> +++
>>  1 file changed, 115 insertions(+)
>>
>> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
>> index 8dd5acf..5658746 100644
>> --- a/libavfilter/vf_scale_vaapi.c
>> +++ b/libavfilter/vf_scale_vaapi.c
>> @@ -53,6 +53,16 @@ typedef struct ScaleVAAPIContext {
>>  int output_width;
>>  int output_height;
>>
>> +VAProcFilterCap denoise_caps;
>> +int support_denoise;
>> +int denoise; // enable denoise algo. level is the optional
>> + // value from the interval [-1, 100], -1 means 
>> disabled
>> +
>> +VAProcFilterCap sharpless_caps;
>> +int support_sharpless;
>> +int sharpless;   // enable sharpless. level is the optional value
>> + // from the interval [-1, 100], -1 means disabled
> 
> "sharpless"?  "sharpness" or "sharpen", might be better.  (The filter is 
> called "sharpening", though maybe it can also blur the image?)
> 
agree, sharpless is a typo for sharpness

>> +
>>  } ScaleVAAPIContext;
>>
>>
>> @@ -117,6 +127,8 @@ static int scale_vaapi_config_output(AVFilterLink 
>> *outlink)
>>  AVVAAPIFramesContext *va_frames;
>>  VAStatus vas;
>>  int err, i;
>> +unsigned int num_denoise_caps = 1;
>> +unsigned int num_sharpless_caps = 1;
>>
>>  scale_vaapi_pipeline_uninit(ctx);
>>
>> @@ -225,6 +237,29 @@ static int scale_vaapi_config_output(AVFilterLink 
>> *outlink)
>>  goto fail;
>>  }
>>
>> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
>> + VAProcFilterNoiseReduction,
>> + >denoise_caps, _denoise_caps);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_WARNING, "Failed to query denoise caps "
>> +   "context: %d (%s).\n", vas, vaErrorStr(vas));
>> +ctx->support_denoise = 0;
>> +} else {
>> +ctx->support_denoise = 1;
>> +}
>> +
>> +vas = vaQueryVideoProcFilterCaps(ctx->hwctx->display, ctx->va_context,
>> + VAProcFilterSharpening,
>> + >sharpless_caps, 
>> _sharpless_caps);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_WARNING, "Failed to query sharpless caps "
>> +   "context: %d (%s).\n", vas, vaErrorStr(vas));
>> +ctx->support_sharpless = 0;
>> +} else {
>> +ctx->support_sharpless = 1;
>> +}
> 
> If the user explicitly requests these filters that can still be ignored if 
> they not supported?  Maybe it would be better to just give up with an error 
> message at that point.
> 
> Similarly, the warning that they are not supported is unhelpful if the user 
> didn't ask for them.

agree, I will change the logic when can't supported

> 
>> +
>> +
>>  av_freep();
>>  av_hwframe_constraints_free();
>>  return 0;
>> @@ -250,6 +285,14 @@ static int vaapi_proc_colour_standard(enum AVColorSpace 
>> av_cs)
>>  }
>>  }
>>
>> +static float map_to_range(
>> +int input, int in_min, int in_max,
>> +float out_min, float out_max)
>> +{
>> +return (input - in_min) * (out_max - out_min) / (in_max - in_min) + 
>> out_min;
>> +}
>> +
>> +
>>  static int scale_vaapi_filter_frame(AVFilterLink *inlink, AVFrame 
>> *input_frame)
>>  {
>>  AVFilterContext *avctx = inlink->dst;
>> @@ -259,6 +302,10 @@ static int scale_vaapi_filter_frame(AVFilterLink 
>> *inlink, AVFrame *input_frame)
>>  VASurfaceID input_surface, output_surface;
>>  VAProcPipelineParameterBuffer params;
>>  VABufferID 

[FFmpeg-devel] [PATCH] avformat/segment: fix the duration error of use output_ts_offset

[Steven Liu]

This patch can merge with 1da00be009aa74400042bf470b9a5ffbd82a1c5e
i have checked this modify:

./ffmpeg -i ~/facebook.mp4 -c copy -f segment -segment_time 2
-output_ts_offset 80 -segment_list output-test.m3u8 -v debug
output-test-%03d.ts

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:10
#EXTINF:4.12,
output-test-000.ts
#EXTINF:7.84,
output-test-001.ts
#EXTINF:4.20,
output-test-002.ts
#EXTINF:2.92,
output-test-003.ts
#EXTINF:1.84,
output-test-004.ts
#EXTINF:2.24,
output-test-005.ts
#EXTINF:2.00,
output-test-006.ts
#EXTINF:3.56,


[root@localhost linux]# ffmpeg -i output-test.m3u8
ffmpeg version N-80917-ga1a240b Copyright (c) 2000-2016 the FFmpeg
developers
  built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
  configuration: --prefix=/usr/ --libdir=/usr/lib64 --enable-libx264
--enable-libfaac --enable-gpl --enable-nonfree
  libavutil  55. 28.100 / 55. 28.100
  libavcodec 57. 48.102 / 57. 48.102
  libavformat57. 41.100 / 57. 41.100
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 47.100 /  6. 47.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc54.  0.100 / 54.  0.100
Input #0, hls,applehttp, from 'output-test.m3u8':
  Duration: 00:03:21.04, start: 81.40, bitrate: 0 kb/s
  Program 0
Metadata:
  variant_bitrate : 0
Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p,
720x528 [SAR 1:1 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side),
fltp, 384 kb/s
At least one output file must be specified



[root@localhost linux]# ffmpeg -i output-test-000.ts -i output-test-001.ts
ffmpeg version N-80917-ga1a240b Copyright (c) 2000-2016 the FFmpeg
developers
  built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
  configuration: --prefix=/usr/ --libdir=/usr/lib64 --enable-libx264
--enable-libfaac --enable-gpl --enable-nonfree
  libavutil  55. 28.100 / 55. 28.100
  libavcodec 57. 48.102 / 57. 48.102
  libavformat57. 41.100 / 57. 41.100
  libavdevice57.  0.102 / 57.  0.102
  libavfilter 6. 47.100 /  6. 47.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc54.  0.100 / 54.  0.100
Input #0, mpegts, from 'output-test-000.ts':
  Duration: 00:00:04.12, start: 81.40, bitrate: 1299 kb/s
  Program 1
Metadata:
  service_name: Service01
  service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B),
yuv420p, 720x528 [SAR 1:1 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101](und): Audio: ac3 ([129][0][0][0] / 0x0081), 48000
Hz, 5.1(side), fltp, 384 kb/s
Input #1, mpegts, from 'output-test-001.ts':
  Duration: 00:00:07.90, start: 85.464000, bitrate: 1679 kb/s
  Program 1
Metadata:
  service_name: Service01
  service_provider: FFmpeg
Stream #1:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B),
yuv420p, 720x528 [SAR 1:1 DAR 15:11], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #1:1[0x101](und): Audio: ac3 ([129][0][0][0] / 0x0081), 48000
Hz, 5.1(side), fltp, 384 kb/s
At least one output file must be specified
[root@localhost linux]#




this commit is used for fix commit 1da00be009aa74400042bf470b9a5ffbd82a1c5e
because the option initial_offset will deprecated

Signed-off-by: Steven Liu 
---
 libavformat/segment.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 33a5cf0..252f8b1 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -885,6 +885,11 @@ calc_times:
 av_log(s, AV_LOG_VERBOSE, "segment:'%s' starts with packet
stream:%d pts:%s pts_time:%s frame:%d\n",
seg->avf->filename, pkt->stream_index,
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts,
>time_base), seg->frame_count);
+seg->cut_pending = 0;
+seg->cur_entry.index = seg->segment_idx + seg->segment_idx_wrap *
seg->segment_idx_wrap_nb;
+seg->cur_entry.start_time = (double)pkt->pts *
av_q2d(st->time_base);
+seg->cur_entry.start_pts = av_rescale_q(pkt->pts, st->time_base,
AV_TIME_BASE_Q);
+seg->cur_entry.end_time = seg->cur_entry.start_time;
 }

 av_log(s, AV_LOG_DEBUG, "stream:%d start_pts_time:%s pts:%s
pts_time:%s dts:%s dts_time:%s",
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable stream parsing for VP9.

[Ronald S. Bultje]

Hi,

On Wed, Sep 7, 2016 at 7:37 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Tue, Sep 6, 2016 at 10:39 PM, Matthew Gregan  wrote:
>
>> At 2016-09-06T22:18:18-0400, Ronald S. Bultje wrote:
>> > I think the patch is fine, but I wonder if it should set it to _FULL
>> (the
>> > parser ignores the option, but it is semantically more correct).
>>
>> Good point, thanks for the feedback.  Updated (simpler!) patch attached.
>
>
> LGTM.
>

Sorry about delay - pushed.

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

Re: [FFmpeg-devel] [PATCH 1/2] Parse VP9 when coming out of MP4.

[Ronald S. Bultje]

Hi,

On Thu, Sep 8, 2016 at 9:50 PM, James Almer  wrote:

> On 9/8/2016 8:41 PM, Alex Converse wrote:
> > Fixes Netflix VP9 DASH samples.
> > ---
> >  libavformat/mov.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index a7595c5..6e80b93 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c,
> AVIOContext *pb,
> >  case AV_CODEC_ID_EAC3:
> >  case AV_CODEC_ID_MPEG1VIDEO:
> >  case AV_CODEC_ID_VC1:
> > +case AV_CODEC_ID_VP9:
> >  st->need_parsing = AVSTREAM_PARSE_FULL;
> >  break;
> >  default:
>
> Already submitted and approved (Just not committed yet).
>
> See https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199029.html


Pushed now, sorry about that...

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

Re: [FFmpeg-devel] [PATCH 1/2] Parse VP9 when coming out of MP4.

[James Almer]

On 9/8/2016 8:41 PM, Alex Converse wrote:
> Fixes Netflix VP9 DASH samples.
> ---
>  libavformat/mov.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a7595c5..6e80b93 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, 
> AVIOContext *pb,
>  case AV_CODEC_ID_EAC3:
>  case AV_CODEC_ID_MPEG1VIDEO:
>  case AV_CODEC_ID_VC1:
> +case AV_CODEC_ID_VP9:
>  st->need_parsing = AVSTREAM_PARSE_FULL;
>  break;
>  default:

Already submitted and approved (Just not committed yet).

See https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199029.html

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Aman Gupta]

Yea this doesn't work at all. I wish someone had bothered to check before
the patch was proposed or merged.

With "-ss 20 -i file -segment_time 2 -segment_start_number 10
-initial_offset 20":

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:3
#EXTINF:2.023344,
out10.ts
#EXTINF:2.002011,
out11.ts
#EXTINF:2.002011,
out12.ts


With "-ss 20 -i file -segment_time 2 -segment_start_number 10
-output_ts_offset 20":

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:21
#EXTINF:20.200211,
out10.ts
#EXTINF:0.200211,
out11.ts
#EXTINF:0.200211,
out12.ts


The TARGETDURATION as well as the duration of the segments themselves is
incorrect.

Aman

On Thu, Sep 8, 2016 at 6:48 PM, Aman Gupta  wrote:

> I tried to switch from -initial_offset to -output_ts_offset, but it does
> not work as expected. In Safari, the generated HLS stream stalls out and
> stops playing after the first segment.
>
> Aman
>
> On Thu, Sep 8, 2016 at 5:54 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Fri, Sep 09, 2016 at 02:59:52AM +0800, Steven Liu wrote:
>> > 2016-09-08 22:52 GMT+08:00 Carl Eugen Hoyos :
>> >
>> > > 2016-09-08 16:01 GMT+02:00 Steven Liu :
>> > >
>> > > > +if (seg->initial_offset > 0) {
>> > > > +av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset
>> will
>> > > be
>> > > > deprecated soon,"
>> > >
>> > > "is deprecated" even if you decide not to ignore the value set.
>> > >
>> > > Carl Eugen
>> > >
>> >
>> > Sorry for my poor English,
>>
>> fixed the english and applied
>>
>>
>> > What about "be removed"?
>>
>> that would have worked too
>>
>> the option is deprecated
>> see https://en.wiktionary.org/wiki/deprecate#English
>> "To declare something obsolescent; to recommend against a function,
>> technique, command, etc. that still works but has been replaced. "
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Many things microsoft did are stupid, but not doing something just because
>> microsoft did it is even more stupid. If everything ms did were stupid
>> they
>> would be bankrupt already.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Aman Gupta]

I tried to switch from -initial_offset to -output_ts_offset, but it does
not work as expected. In Safari, the generated HLS stream stalls out and
stops playing after the first segment.

Aman

On Thu, Sep 8, 2016 at 5:54 PM, Michael Niedermayer 
wrote:

> On Fri, Sep 09, 2016 at 02:59:52AM +0800, Steven Liu wrote:
> > 2016-09-08 22:52 GMT+08:00 Carl Eugen Hoyos :
> >
> > > 2016-09-08 16:01 GMT+02:00 Steven Liu :
> > >
> > > > +if (seg->initial_offset > 0) {
> > > > +av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset
> will
> > > be
> > > > deprecated soon,"
> > >
> > > "is deprecated" even if you decide not to ignore the value set.
> > >
> > > Carl Eugen
> > >
> >
> > Sorry for my poor English,
>
> fixed the english and applied
>
>
> > What about "be removed"?
>
> that would have worked too
>
> the option is deprecated
> see https://en.wiktionary.org/wiki/deprecate#English
> "To declare something obsolescent; to recommend against a function,
> technique, command, etc. that still works but has been replaced. "
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> 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] lavc/videotoolboxenc: implement a53cc

[Aman Gupta]

On Thu, Sep 8, 2016 at 9:18 AM, Carl Eugen Hoyos  wrote:

> 2016-09-08 15:48 GMT+02:00 Aman Gupta :
> > On Thursday, September 8, 2016, Carl Eugen Hoyos 
> wrote:
> >
> >> 2016-09-08 10:19 GMT+02:00 Aman Gupta >:
> >>
> >> > +{ "a53cc", "Use A53 Closed Captions (if available)",
> >> OFFSET(a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE },
> >>
> >> Why is this disabled by default?
> >
> > I copied this from the libx264 and qsv encoders, which also disable by
> > default. Not sure why.
>
> If you believe it should be enabled by default, please send a patch that
> enables the function by default.
> (If there is no issue, the others can be fixed.)
>

I don't have a good enough understanding of the possible consequences to
feel comfortable enabling it by default yet.


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

Re: [FFmpeg-devel] [PATCH 2/2] Normalize VP8 and VP9 tags when writing IVF.

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 04:41:03PM -0700, Alex Converse wrote:
> VP9-in-ISOM uses vp08 and vp09 tags, while ivf uses VP80 and VP90.
> ---
>  libavformat/ivfenc.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> index 5dbcd97..1735606 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -26,6 +26,17 @@ typedef struct IVFEncContext {
>  uint64_t last_pts, sum_delta_pts;
>  } IVFEncContext;
>  
> +static const int canonical_tag_vp8 = MKTAG('V', 'P', '8', '0');
> +static const int canonical_tag_vp9 = MKTAG('V', 'P', '9', '0');

unused


> +
> +static uint32_t canonicalize_tag(AVCodecParameters *par) {
> +  switch (par->codec_id) {
> +  case AV_CODEC_ID_VP8: return  MKTAG('V', 'P', '8', '0');
> +  case AV_CODEC_ID_VP9: return  MKTAG('V', 'P', '9', '0');
> +  default: return par->codec_tag;
> +  }
> +}
> +
>  static int ivf_write_header(AVFormatContext *s)
>  {
>  AVCodecParameters *par;
> @@ -44,7 +55,7 @@ static int ivf_write_header(AVFormatContext *s)
>  avio_write(pb, "DKIF", 4);
>  avio_wl16(pb, 0); // version
>  avio_wl16(pb, 32); // header length
> -avio_wl32(pb, par->codec_tag ? par->codec_tag : par->codec_id == 
> AV_CODEC_ID_VP9 ? AV_RL32("VP90") : AV_RL32("VP80"));
> +avio_wl32(pb, canonicalize_tag(par));

a better solution is to set
AVOutputFormat.codec_tag correctly
that way the tag is also shown correctly durng muxing

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Michael Niedermayer]

On Fri, Sep 09, 2016 at 02:59:52AM +0800, Steven Liu wrote:
> 2016-09-08 22:52 GMT+08:00 Carl Eugen Hoyos :
> 
> > 2016-09-08 16:01 GMT+02:00 Steven Liu :
> >
> > > +if (seg->initial_offset > 0) {
> > > +av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset will
> > be
> > > deprecated soon,"
> >
> > "is deprecated" even if you decide not to ignore the value set.
> >
> > Carl Eugen
> >
> 
> Sorry for my poor English,

fixed the english and applied


> What about "be removed"?

that would have worked too

the option is deprecated
see https://en.wiktionary.org/wiki/deprecate#English
"To declare something obsolescent; to recommend against a function, technique, 
command, etc. that still works but has been replaced. "

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add myself for hlsenc

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 12:56:19AM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

maybe the entry should be split between
encryption for hlsenc and the rest of hlsenc

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 04:18:26PM +0200, Matthieu Bouron wrote:
> On Thu, Sep 8, 2016 at 2:28 PM, Michael Niedermayer 
> wrote:
> 
> > On Wed, Sep 07, 2016 at 04:53:53PM +0200, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > >
> > > ---
> > >  libavcodec/hevc.h|  9 +
> > >  libavcodec/hevc_ps.c | 27 +++
> > >  2 files changed, 36 insertions(+)
> > >
> > > diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> > > index be91010..6a3c750 100644
> > > --- a/libavcodec/hevc.h
> > > +++ b/libavcodec/hevc.h
> > > @@ -387,6 +387,9 @@ typedef struct HEVCVPS {
> > >  uint8_t vps_poc_proportional_to_timing_flag;
> > >  int vps_num_ticks_poc_diff_one; ///< 
> > > vps_num_ticks_poc_diff_one_minus1
> > + 1
> > >  int vps_num_hrd_parameters;
> > > +
> > > +uint8_t data[4096];
> > > +int data_size;
> > >  } HEVCVPS;
> > >
> > >  typedef struct ScalingList {
> > > @@ -483,6 +486,9 @@ typedef struct HEVCSPS {
> > >  int vshift[3];
> > >
> > >  int qp_bd_offset;
> > > +
> > > +uint8_t data[4096];
> > > +int data_size;
> > >  } HEVCSPS;
> > >
> > >  typedef struct HEVCPPS {
> > > @@ -557,6 +563,9 @@ typedef struct HEVCPPS {
> > >  int *tile_pos_rs;   ///< TilePosRS
> > >  int *min_tb_addr_zs;///< MinTbAddrZS
> > >  int *min_tb_addr_zs_tab;///< MinTbAddrZS
> > > +
> > > +uint8_t data[4096];
> > > +int data_size;
> > >  } HEVCPPS;
> > >
> > >  typedef struct HEVCParamSets {
> > > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > > index 83f2ec2..629e454 100644
> > > --- a/libavcodec/hevc_ps.c
> > > +++ b/libavcodec/hevc_ps.c
> > > @@ -408,6 +408,15 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > >
> > >  av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
> > >
> > > +vps->data_size = gb->buffer_end - gb->buffer;
> >
> > This theoretically could overflow, data_size is only an int the pointer
> > difference might be larger
> >
> 
> Updated patch attached.
> 
> [...]

>  hevc.h|9 +
>  hevc_ps.c |   36 
>  2 files changed, 45 insertions(+)
> 74a311a04fc12daab6f9dc4dc228d3e2d574b12f  
> 0001-lavc-hevc-store-VPS-SPS-PPS-data.patch
> From e25cc9920accb43dd4af152358b78160e85d64a2 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Wed, 7 Sep 2016 11:36:10 +0200
> Subject: [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 04:49:12PM +0300, Ligverd Haer wrote:
> > Please send your updated patch as attachment to a
> > reply in this mailing list thread,
> > 
> > Please tell us if documentation pointed you to github or trac to
> > post patches, we try hard to have patch submission (only) on
> > this mailing list.
> > 
> > Carl Eugen
> 

>  dashenc.c |   18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 83ed4ba290c20a1467b1da80c326e0025de564fe  dash_valid_dynamic.patch
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c

missing commit mesage / not a proper git patch


> index 519f9c4..ea96f71 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -498,17 +498,15 @@ static int write_manifest(AVFormatContext *s, int final)
>  OutputStream *os = >streams[0];
>  int start_index = FFMAX(os->nb_segments - c->window_size, 0);
>  int64_t start_time = av_rescale_q(os->segments[start_index]->time, 
> s->streams[0]->time_base, AV_TIME_BASE_Q);
> -avio_printf(out, "\t +avio_printf(out, "\t  write_time(out, start_time);
>  avio_printf(out, "\">\n");
>  } else {
> -avio_printf(out, "\t\n");
> +avio_printf(out, "\t\n",final?"":" 
> id=\"0\"");
>  }
>  
>  if (c->has_video) {
>  avio_printf(out, "\t\t segmentAlignment=\"true\" bitstreamSwitching=\"true\"");
> -if (c->max_frame_rate.num && !c->ambiguous_frame_rate)
> -avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(c->min_frame_rate, 
> c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate", 
> c->max_frame_rate.num, c->max_frame_rate.den);
>  avio_printf(out, ">\n");
>  
>  for (i = 0; i < s->nb_streams; i++) {
> @@ -598,11 +596,15 @@ static int dash_write_header(AVFormatContext *s)
>  AVDictionary *opts = NULL;
>  char filename[1024];
>  
> -os->bit_rate = s->streams[i]->codecpar->bit_rate;
> +os->bit_rate = s->streams[i]->codecpar->bit_rate ? 
> s->streams[i]->codecpar->bit_rate :  s->bit_rate;
> +
>  if (os->bit_rate) {
>  snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
>   " bandwidth=\"%d\"", os->bit_rate);
>  } else {
> +snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
> + " bandwidth=\"%d\"", 0);
> +
>  int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
>  AV_LOG_ERROR : AV_LOG_WARNING;
>  av_log(s, level, "No bit rate set for stream %d\n", i);

> @@ -654,7 +656,7 @@ static int dash_write_header(AVFormatContext *s)
>  goto fail;
>  os->init_start_pos = 0;
>  
> -av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 0);
> +av_dict_set(, "movflags", 
> "dash+frag_keyframe+empty_moov+separate_moof+delay_moov", 0);
>  if ((ret = avformat_write_header(ctx, )) < 0) {
>   goto fail;
>  }

this looks unrelated, unrelated changes need to be in separate patches

please explain in the commit messages of the patch(es) what each
patch does, why it does it and if you have at hand any reference to
specs feel free to include them


> @@ -858,6 +860,10 @@ static int dash_flush(AVFormatContext *s, int final, int 
> stream)
>  if (ret < 0)
>  break;
>  }
> +
> +os->bit_rate = (int)( (float)range_length*8 / ((float)(os->max_pts - 
> os->start_pts) / 1) );
> +snprintf(os->bandwidth_str, sizeof(os->bandwidth_str)," 
> bandwidth=\"%i\"", os->bit_rate);

floats make the binary output code platform dependant, theres no
need to use floats here


> +
>  add_segment(os, filename, os->start_pts, os->max_pts - 
> os->start_pts, start_pos, range_length, index_length);
>  av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d 
> written to: %s\n", i, os->segment_index, full_path);
>  }

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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

[FFmpeg-devel] [PATCH 1/2] Parse VP9 when coming out of MP4.

[Alex Converse]

Fixes Netflix VP9 DASH samples.
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a7595c5..6e80b93 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, 
AVIOContext *pb,
 case AV_CODEC_ID_EAC3:
 case AV_CODEC_ID_MPEG1VIDEO:
 case AV_CODEC_ID_VC1:
+case AV_CODEC_ID_VP9:
 st->need_parsing = AVSTREAM_PARSE_FULL;
 break;
 default:
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 2/2] Normalize VP8 and VP9 tags when writing IVF.

[Alex Converse]

VP9-in-ISOM uses vp08 and vp09 tags, while ivf uses VP80 and VP90.
---
 libavformat/ivfenc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 5dbcd97..1735606 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -26,6 +26,17 @@ typedef struct IVFEncContext {
 uint64_t last_pts, sum_delta_pts;
 } IVFEncContext;
 
+static const int canonical_tag_vp8 = MKTAG('V', 'P', '8', '0');
+static const int canonical_tag_vp9 = MKTAG('V', 'P', '9', '0');
+
+static uint32_t canonicalize_tag(AVCodecParameters *par) {
+  switch (par->codec_id) {
+  case AV_CODEC_ID_VP8: return  MKTAG('V', 'P', '8', '0');
+  case AV_CODEC_ID_VP9: return  MKTAG('V', 'P', '9', '0');
+  default: return par->codec_tag;
+  }
+}
+
 static int ivf_write_header(AVFormatContext *s)
 {
 AVCodecParameters *par;
@@ -44,7 +55,7 @@ static int ivf_write_header(AVFormatContext *s)
 avio_write(pb, "DKIF", 4);
 avio_wl16(pb, 0); // version
 avio_wl16(pb, 32); // header length
-avio_wl32(pb, par->codec_tag ? par->codec_tag : par->codec_id == 
AV_CODEC_ID_VP9 ? AV_RL32("VP90") : AV_RL32("VP80"));
+avio_wl32(pb, canonicalize_tag(par));
 avio_wl16(pb, par->width);
 avio_wl16(pb, par->height);
 avio_wl32(pb, s->streams[0]->time_base.den);
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Sven C. Dack wrote:

On 08/09/16 15:17, Andy Furniss wrote:

Carl Eugen Hoyos wrote:

2016-09-08 12:01 GMT+02:00 Andy Furniss :


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


In case it got mistaken...

The following is what gives the 100 fp/s (with a GTX 960):
$ ffmpeg -f x11grab -framerate 200 -s hd1080 -i :0.0 -c:v hevc_nvenc -y
test.mkv

The mentioned 100 fp/s refers to the HEVS/H.265 hardware encoder
(nvenc). X11grab is here only the input device.

Without the encoder does it give me 160 fp/s:
$ ffmpeg -f x11grab -s hd1080 -framerate 500 -i :0.0 -f null -

Different sizes then give different results:

- For hd720 is it 200 fp/s (with nvenc) and 420 fp/s (without nvenc).
- For hd480 is it 460 fp/s (with nvenc) and 890 fp/s (without nvenc).

Can you compare gstreamer to those numbers?


With gstreamer 1080p I can get around 350 fps testing like -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 
endy=1079 num-buffers=5000 ! queue ! videoconvert ! 
video/x-raw,framerate=500/1,format=BGRx ! fakesink

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.205120141
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

5000/14.205120141 = 351.98

Of course I don't know if that's "real" as such.

I do know that I have really grabbed and encoded 1080p60 with my AMD h/w
and including nv12 conversion gives a sane looking result -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 
endy=1079 num-buffers=1000 ! queue ! videoconvert ! 
video/x-raw,framerate=100/1,format=NV12  ! fakesink

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.419928745
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

1000/14.419928745 = 69.3

I also tried (fake) 2160p and got around 90fps BGRx and 17 nv12.

My PC is old = Phenom II x4 965 3.4GHz Cpus, 1333 ram.


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/alsdec: Fix reading 0 mantisse bits

[James Almer]

> ffmpeg | branch: master | Michael Niedermayer  | 
> Thu Sep  8 22:02:44 2016 +0200| [037422178d7f1d0dd09e1ce424dd61a69e77668b] | 
> committer: Michael Niedermayer
>
> avcodec/alsdec: Fix reading 0 mantisse bits
>
> Fixes assertion failure
> Fixes: 
> 848c24abc1721c9e3d1ba7bfee8d9fcc/asan_heap-oob_1d99eca_3709_567bba70d67e7d62714dcf56f26fb1da.mp4
>
> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
> Signed-off-by: Michael Niedermayer 
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=037422178d7f1d0dd09e1ce424dd61a69e77668b
> ---
>
>  libavcodec/alsdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
> index 1bb71f5..8c4ff53 100644
> --- a/libavcodec/alsdec.c
> +++ b/libavcodec/alsdec.c
> @@ -1527,7 +1527,7 @@ static int read_diff_float_data(ALSDecContext *ctx, 
> unsigned int ra_frame) {
>  if (!get_bits1(gb)) { //uncompressed
>  for (i = 0; i < frame_length; ++i) {
>  if (ctx->raw_samples[c][i] != 0) {
> -raw_mantissa[c][i] = get_bits(gb, nbits[i]);
> +raw_mantissa[c][i] = nbits[i] ? get_bits(gb, 
> nbits[i]) : 0;

No point changing it now, but keep in mind for future reference that there's a 
get_bitsz()
function. It in fact expands to this same code you wrote.

>  }
>  }
>  } else { //compressed
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: don't reconfigure terminal if we're not taking input from stdin

[Rodger Combs]

> On Sep 8, 2016, at 07:49, Nicolas George  wrote:
> 
> Le duodi 22 fructidor, an CCXXIV, Rodger Combs a écrit :
>> ---
>> ffmpeg.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index d858407..1d793fe 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -366,7 +366,7 @@ static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
>> void term_init(void)
>> {
>> #if HAVE_TERMIOS_H
>> -if(!run_as_daemon){
>> +if (!run_as_daemon && stdin_interaction) {
>> struct termios tty;
>> if (tcgetattr (0, ) == 0) {
>> oldtty = tty;
>> @@ -4328,6 +4328,10 @@ int main(int argc, char **argv)
>> 
>> show_banner(argc, argv, options);
>> 
> 
>> +ret = locate_option(argc, argv, options, "stdin");
>> +if (ret && !strcmp(argv[ret], "-nostdin"))
>> +stdin_interaction = 0;
>> +
>> term_init();
> 
> I think it would be more elegant to move the term_init() call a few lines
> down, after ffmpeg_parse_options(), rather than parse -nostdin out of order.

Agreed in principle; I did it this way because I'm not entirely sure if there 
would be negative consequences to parsing options (and thus opening I/O) before 
setting up signal handlers. If you think that's not an issue, I'll make the 
change you suggest.

> 
> Apart from that, both patches looks right to me.
> 
>> 
>> /* parse options and open all input/output files */
> 
> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Steven Liu]

2016-09-08 22:52 GMT+08:00 Carl Eugen Hoyos :

> 2016-09-08 16:01 GMT+02:00 Steven Liu :
>
> > +if (seg->initial_offset > 0) {
> > +av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset will
> be
> > deprecated soon,"
>
> "is deprecated" even if you decide not to ignore the value set.
>
> Carl Eugen
>

Sorry for my poor English,
What about "be removed"?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/mlz: Check output chars before using it

[Michael Niedermayer]

Fixes hypothetical integer overflow

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mlz.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mlz.c b/libavcodec/mlz.c
index 039635d..a2d1b89 100644
--- a/libavcodec/mlz.c
+++ b/libavcodec/mlz.c
@@ -153,12 +153,27 @@ int ff_mlz_decompression(MLZ* mlz, GetBitContext* gb, int 
size, unsigned char *b
 mlz->bump_code = mlz->current_dic_index_max - 1;
 } else {
 if (string_code >= mlz->next_code) {
-output_chars += decode_string(mlz, 
[output_chars], last_string_code, _code, size - output_chars);
-output_chars += decode_string(mlz, 
[output_chars], char_code, _code, size - output_chars);
+int ret = decode_string(mlz, [output_chars], 
last_string_code, _code, size - output_chars);
+if (ret < 0 || ret > size - output_chars) {
+av_log(mlz->context, AV_LOG_ERROR, "output chars 
overflow\n");
+return output_chars;
+}
+output_chars += ret;
+ret = decode_string(mlz, [output_chars], 
char_code, _code, size - output_chars);
+if (ret < 0 || ret > size - output_chars) {
+av_log(mlz->context, AV_LOG_ERROR, "output chars 
overflow\n");
+return output_chars;
+}
+output_chars += ret;
 set_new_entry_dict(dict, mlz->next_code, 
last_string_code, char_code);
 mlz->next_code++;
 } else {
-output_chars += decode_string(mlz, 
[output_chars], string_code, _code, size - output_chars);
+int ret = decode_string(mlz, [output_chars], 
string_code, _code, size - output_chars);
+if (ret < 0 || ret > size - output_chars) {
+av_log(mlz->context, AV_LOG_ERROR, "output chars 
overflow\n");
+return output_chars;
+}
+output_chars += ret;
 if (output_chars <= size && !mlz->freeze_flag) {
 if (last_string_code != -1) {
 set_new_entry_dict(dict, mlz->next_code, 
last_string_code, char_code);
-- 
2.9.3

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Nicolas George]

Le tridi 23 fructidor, an CCXXIV, Carl Eugen Hoyos a écrit :
> xcb is slower?

Looking at the code, I see that xcbgrab allocates and frees the shared
memory segment for each frame, while x11grab only allocates it once at the
beginning. xcbgrab does that so that it can wrap the segment in a refcounted
buffer.

On the other hand, x11grab seems to be returning the shared memory segment
as the packet payload as is. If I am not mistaken, this is just invalid, and
works just by luck. It could be tested with the following procedure: grab a
packet, dump it, grab a second packet, dump the first one again.

Still, it is probably possible to do something faster than xcbgrab while
still correct: only allocate a new segment if the first one is still in use.

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] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 19:16 GMT+02:00 Andy Furniss :


It is a bit faster


xcb is slower?


Yes (unless I am mixing things up)

--disable-libxcb --enable-x11grab is faster than autodetect

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

2016-09-08 19:16 GMT+02:00 Andy Furniss :

> It is a bit faster

xcb is slower?

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 16:17 GMT+02:00 Andy Furniss :

Carl Eugen Hoyos wrote:


2016-09-08 12:01 GMT+02:00 Andy Furniss :


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


Then please test if this is a regression over x11grab, use:
configure --disable-libxcb --enable-x11grab --enable-gpl

(It is very likely that nobody ever tested.)


It is a bit faster, comparing results I posted on users to new build -

(vsync 2 for consistency as that's how the old tests were done
it isn't really needed/makes no difference for -f null but was used
as I previously also tested -f rawvideo -y /dev/null and when
using -framerate with that it is essential).

xcb -> x11grab.

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -f null -


138 -> 179 fps

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -pix_fmt yuv420p -f null -


47 -> 56 fps

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -pix_fmt nv12 -f null -


33 -> 37 fps



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

Re: [FFmpeg-devel] [PATCH] fate/als: add floating point decoding test

[Michael Niedermayer]

On Sun, Jul 17, 2016 at 07:25:31PM +0530, Umair Khan wrote:
> On Sun, Jul 17, 2016 at 1:50 PM, Thilo Borgmann  
> wrote:
> > Hi,
> >
> >> From e172e333807b4b3b2558a1ffa735ade79a3f3e36 Mon Sep 17 00:00:00 2001
> >> From: Umair Khan 
> >> Date: Sun, 17 Jul 2016 13:05:49 +0530
> >> Subject: [PATCH 1/1] fate/als: add floating point decoding test
> >>
> >> Signed-off-by: Umair Khan 
> >> ---
> >>  tests/fate/als.mak | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/tests/fate/als.mak b/tests/fate/als.mak
> >> index ff2badf..2847a8d 100644
> >> --- a/tests/fate/als.mak
> >> +++ b/tests/fate/als.mak
> >> @@ -7,5 +7,8 @@ endef
> >>
> >>  $(foreach N,$(ALS_SUITE),$(eval $(call FATE_ALS_SUITE,$(N
> >>
> >> ++FATE_ALS += fate-mpeg4-als-conformance-07
> >
> > Just add "07" to the ALS_SUITE.
> >
> > You also need to add a new "tests/ref/fate/mpeg4-als-conformance-07"
> > file containing the correct CRC for that conformance file.
> >
> > Please setup a local FATE suite and test your patch before resubmitting.
> 
> Tested.
> Updated patch attached.
> 
> -Umair

>  fate/als.mak  |3 +++
>  ref/fate/mpeg4-als-conformance-07 |1 +
>  2 files changed, 4 insertions(+)
> 1a677b6670ab1214c568ea495efd182a285dc6e3  
> 0001-fate-als-add-floating-point-decoding-test.patch
> From 4295fc1a5f56d81e9b498bece4aed36197328763 Mon Sep 17 00:00:00 2001
> From: Umair Khan 
> Date: Sun, 17 Jul 2016 13:05:49 +0530
> Subject: [PATCH 1/1] fate/als: add floating point decoding test
> 
> Signed-off-by: Umair Khan 
> ---
>  tests/fate/als.mak  | 3 +++
>  tests/ref/fate/mpeg4-als-conformance-07 | 1 +
>  2 files changed, 4 insertions(+)
>  create mode 100644 tests/ref/fate/mpeg4-als-conformance-07
> 
> diff --git a/tests/fate/als.mak b/tests/fate/als.mak
> index ff2badf..a67302c 100644
> --- a/tests/fate/als.mak
> +++ b/tests/fate/als.mak
> @@ -7,5 +7,8 @@ endef
>  
>  $(foreach N,$(ALS_SUITE),$(eval $(call FATE_ALS_SUITE,$(N
>  
> +FATE_ALS += fate-mpeg4-als-conformance-07
> +fate-mpeg4-als-conformance-07: CMD = crc -i 
> $(TARGET_SAMPLES)/lossless-audio/als_07_2ch192k32bF.mp4

fails on arm

--- tests/ref/fate/mpeg4-als-conformance-07 2016-09-08 18:36:16.095167935 
+0200
+++ tests/data/fate/mpeg4-als-conformance-072016-09-08 18:49:32.219184707 
+0200
@@ -1 +1 @@
-CRC=0x01503df3
+CRC=0x81b53f05
Test mpeg4-als-conformance-07 failed. Look at 
tests/data/fate/mpeg4-als-conformance-07.err for details.
make: *** [fate-mpeg4-als-conformance-07] Error 1

interrestingly it does not fail on mips

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Carl Eugen Hoyos]

2016-09-08 15:48 GMT+02:00 Aman Gupta :
> On Thursday, September 8, 2016, Carl Eugen Hoyos  wrote:
>
>> 2016-09-08 10:19 GMT+02:00 Aman Gupta >:
>>
>> > +{ "a53cc", "Use A53 Closed Captions (if available)",
>> OFFSET(a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE },
>>
>> Why is this disabled by default?
>
> I copied this from the libx264 and qsv encoders, which also disable by
> default. Not sure why.

If you believe it should be enabled by default, please send a patch that
enables the function by default.
(If there is no issue, the others can be fixed.)

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

Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 10:27:24AM -0700, Brett Harrison wrote:
> This patch addresses your concerns.
> 
> On Fri, Sep 2, 2016 at 5:05 PM, Michael Niedermayer 
> wrote:
> 
> > On Fri, Sep 02, 2016 at 03:31:21PM -0700, Brett Harrison wrote:
> > > Addressed the following concerns.
> > >
> > > ===
> > >
> > > >libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
> > > >libavfilter/vf_drawtext.c:422:5: warning: ISO C90 forbids mixed
> > declarations and code [->Wdeclaration-after-statement]
> > >
> > > Fixed this.
> > >
> > > >also patch breaks:
> > > >./ffmpeg -i m.mpg  -vf >drawtext=fontfile=/usr/share/
> > fonts/truetype/msttcorefonts/arial.ttf:text=a -f null -
> > >
> > > >[AVFilterGraph @ 0x37a6960] Error initializing filter 'drawtext' with
> > args >'fontfile=/usr/share/fonts/truetype/msttcorefonts/arial.ttf:text=a'
> > >
> > > This is fixed.
> > >
> > > ===
> > >
> > > >>* +av_log(ctx, AV_LOG_ERROR, "Font not open\n");
> > > *
> > > >I was wondering: Was does this message tell the user?
> > >
> > > I changed this error to read "Unable to initialize font".  This error
> > > should only be seen if set_fontsize() is called before the font is
> > > loaded.  I don't think a user would be able to cause this because if
> > > the font fails to load ffmpeg would error out before this.  It is a
> > > sanity check.
> > >
> > > ===
> > >
> > > For the concerns about multiple to many brackets on "if ((ret =
> > > update_fontsize(ctx)))",
> > >
> > > I removed the "ret =" part as I wasn't using the value anyway.
> > >
> > >
> > > On Fri, Sep 2, 2016 at 6:13 AM, Nicolas George  wrote:
> > >
> > > > Le septidi 17 fructidor, an CCXXIV, Moritz Barsnick a écrit :
> > > > > *Assuming* he means "assign update_fontsize()'s return value to ret,
> > > > > and check whether ret is != 0", which would correspond to the more
> > > > > verbose
> > > > >   if ((ret = update_fontsize(ctx)) != 0) {
> > > > >
> > > > > is it sufficient to say:
> > > > >   if (ret = update_fontsize(ctx)) {
> > > > >
> > > > > or is it required, or is it more readable or even desired by "style
> > > > > guide" to say:
> > > > >   if ((ret = update_fontsize(ctx))) {
> > > > > (to clarify it's a check of an assignment) - this is what Brett used,
> > > >
> > > > Ah. Parentheses over the whole expression are always optional, but in
> > this
> > > > particular case, there is a good reason:
> > > >
> > > > :4:1: warning: suggest parentheses around assignment used as
> > truth
> > > > value [-Wparentheses]
> > > >
> > > > Forgetting to double the equal in a comparison is a common mistake,
> > > > compilers detect it. But then you need a way of stating when it is
> > > > intentional.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > >   Nicolas George
> > > >
> > > > ___
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@ffmpeg.org
> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >
> > > >
> >
> > >  vf_drawtext.c |  125 ++
> > +---
> > >  1 file changed, 112 insertions(+), 13 deletions(-)
> > > 311d60f04d959ddfd47ed8ea66d0f015725dd511  0001-added-expr-evaluation-to-
> > drawtext-fontsize.patch
> > > From 665b3f1c458222d64a9ba4f1c71d343766ee9e6b Mon Sep 17 00:00:00 2001
> > > From: Brett Harrison 
> > > Date: Fri, 26 Aug 2016 14:29:34 -0700
> > > Subject: [PATCH] added expr evaluation to drawtext - fontsize
> > >
> > > ---
> > >  libavfilter/vf_drawtext.c | 125 ++
> > +++-
> > >  1 file changed, 112 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > > index 214aef0..a483679 100644
> > > --- a/libavfilter/vf_drawtext.c
> > > +++ b/libavfilter/vf_drawtext.c
> > > @@ -156,7 +156,10 @@ typedef struct DrawTextContext {
> > >  int max_glyph_h;///< max glyph height
> > >  int shadowx, shadowy;
> > >  int borderw;///< border width
> > > +char *fontsize_expr;///< expression for fontsize
> > > +AVExpr *fontsize_pexpr; ///< parsed expressions for fontsize
> > >  unsigned int fontsize;  ///< font size to use
> > > +unsigned int default_fontsize;  ///< default font size to use
> > >
> > >  short int draw_box; ///< draw box around text - true or
> > false
> > >  int boxborderw; ///< box border width
> > > @@ -209,7 +212,7 @@ static const AVOption drawtext_options[]= {
> > >  {"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),
> >  AV_OPT_TYPE_COLOR,  {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > >  {"box", "set box",  OFFSET(draw_box),
> >  AV_OPT_TYPE_BOOL,   {.i64=0}, 0,1   , FLAGS},
> > >  {"boxborderw",  "set box border width", OFFSET(boxborderw),
> >  AV_OPT_TYPE_INT,{.i64=0},  

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Aman Gupta]

On Thursday, September 8, 2016, Carl Eugen Hoyos  wrote:

> 2016-09-08 10:19 GMT+02:00 Aman Gupta >:
>
> > +{ "a53cc", "Use A53 Closed Captions (if available)",
> OFFSET(a53_cc), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE },
>
> Why is this disabled by default?


I copied this from the libx264 and qsv encoders, which also disable by
default. Not sure why.


>
> Carl Eugen
> ___
> 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] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 08/09/16 15:17, Andy Furniss wrote:

Carl Eugen Hoyos wrote:

2016-09-08 12:01 GMT+02:00 Andy Furniss :


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


In case it got mistaken...

The following is what gives the 100 fp/s (with a GTX 960):
$ ffmpeg -f x11grab -framerate 200 -s hd1080 -i :0.0 -c:v hevc_nvenc -y test.mkv

The mentioned 100 fp/s refers to the HEVS/H.265 hardware encoder (nvenc). 
X11grab is here only the input device.


Without the encoder does it give me 160 fp/s:
$ ffmpeg -f x11grab -s hd1080 -framerate 500 -i :0.0 -f null -

Different sizes then give different results:

- For hd720 is it 200 fp/s (with nvenc) and 420 fp/s (without nvenc).
- For hd480 is it 460 fp/s (with nvenc) and 890 fp/s (without nvenc).

Can you compare gstreamer to those numbers?

Is anyone also capable of running this in a true 4K display with a Pascal card? 
There the speed matters the most.


Sven

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Carl Eugen Hoyos]

2016-09-08 16:01 GMT+02:00 Steven Liu :

> +if (seg->initial_offset > 0) {
> +av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset will be
> deprecated soon,"

"is deprecated" even if you decide not to ignore the value set.

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

2016-09-08 16:17 GMT+02:00 Andy Furniss :
> Carl Eugen Hoyos wrote:
>>
>> 2016-09-08 12:01 GMT+02:00 Andy Furniss :
>>
>>> I don't know what it is about x11grab/CSC with ffmpeg, but
>>> on my old CPU gstreamer is twice as fast.
>>
>> x11grab or xcb?
>
> I guess xcb as I don't --enable anything related with configure.

Then please test if this is a regression over x11grab, use:
configure --disable-libxcb --enable-x11grab --enable-gpl

(It is very likely that nobody ever tested.)

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

[Matthieu Bouron]

On Thu, Sep 8, 2016 at 2:28 PM, Michael Niedermayer 
wrote:

> On Wed, Sep 07, 2016 at 04:53:53PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> >
> > ---
> >  libavcodec/hevc.h|  9 +
> >  libavcodec/hevc_ps.c | 27 +++
> >  2 files changed, 36 insertions(+)
> >
> > diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> > index be91010..6a3c750 100644
> > --- a/libavcodec/hevc.h
> > +++ b/libavcodec/hevc.h
> > @@ -387,6 +387,9 @@ typedef struct HEVCVPS {
> >  uint8_t vps_poc_proportional_to_timing_flag;
> >  int vps_num_ticks_poc_diff_one; ///< vps_num_ticks_poc_diff_one_minus1
> + 1
> >  int vps_num_hrd_parameters;
> > +
> > +uint8_t data[4096];
> > +int data_size;
> >  } HEVCVPS;
> >
> >  typedef struct ScalingList {
> > @@ -483,6 +486,9 @@ typedef struct HEVCSPS {
> >  int vshift[3];
> >
> >  int qp_bd_offset;
> > +
> > +uint8_t data[4096];
> > +int data_size;
> >  } HEVCSPS;
> >
> >  typedef struct HEVCPPS {
> > @@ -557,6 +563,9 @@ typedef struct HEVCPPS {
> >  int *tile_pos_rs;   ///< TilePosRS
> >  int *min_tb_addr_zs;///< MinTbAddrZS
> >  int *min_tb_addr_zs_tab;///< MinTbAddrZS
> > +
> > +uint8_t data[4096];
> > +int data_size;
> >  } HEVCPPS;
> >
> >  typedef struct HEVCParamSets {
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 83f2ec2..629e454 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -408,6 +408,15 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> >
> >  av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
> >
> > +vps->data_size = gb->buffer_end - gb->buffer;
>
> This theoretically could overflow, data_size is only an int the pointer
> difference might be larger
>

Updated patch attached.

[...]
From e25cc9920accb43dd4af152358b78160e85d64a2 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Wed, 7 Sep 2016 11:36:10 +0200
Subject: [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

---
 libavcodec/hevc.h|  9 +
 libavcodec/hevc_ps.c | 36 
 2 files changed, 45 insertions(+)

diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index be91010..6a3c750 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -387,6 +387,9 @@ typedef struct HEVCVPS {
 uint8_t vps_poc_proportional_to_timing_flag;
 int vps_num_ticks_poc_diff_one; ///< vps_num_ticks_poc_diff_one_minus1 + 1
 int vps_num_hrd_parameters;
+
+uint8_t data[4096];
+int data_size;
 } HEVCVPS;
 
 typedef struct ScalingList {
@@ -483,6 +486,9 @@ typedef struct HEVCSPS {
 int vshift[3];
 
 int qp_bd_offset;
+
+uint8_t data[4096];
+int data_size;
 } HEVCSPS;
 
 typedef struct HEVCPPS {
@@ -557,6 +563,9 @@ typedef struct HEVCPPS {
 int *tile_pos_rs;   ///< TilePosRS
 int *min_tb_addr_zs;///< MinTbAddrZS
 int *min_tb_addr_zs_tab;///< MinTbAddrZS
+
+uint8_t data[4096];
+int data_size;
 } HEVCPPS;
 
 typedef struct HEVCParamSets {
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 83f2ec2..d08ba34 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -399,6 +399,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
 {
 int i,j;
 int vps_id = 0;
+ptrdiff_t nal_size;
 HEVCVPS *vps;
 AVBufferRef *vps_buf = av_buffer_allocz(sizeof(*vps));
 
@@ -408,6 +409,17 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
 
+nal_size = gb->buffer_end - gb->buffer;
+if (nal_size > sizeof(vps->data)) {
+av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
+   "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
+   nal_size, sizeof(vps->data));
+vps->data_size = sizeof(vps->data);
+} else {
+vps->data_size = nal_size;
+}
+memcpy(vps->data, gb->buffer, vps->data_size);
+
 vps_id = get_bits(gb, 4);
 if (vps_id >= MAX_VPS_COUNT) {
 av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", vps_id);
@@ -1177,6 +1189,7 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
 AVBufferRef *sps_buf = av_buffer_allocz(sizeof(*sps));
 unsigned int sps_id;
 int ret;
+ptrdiff_t nal_size;
 
 if (!sps_buf)
 return AVERROR(ENOMEM);
@@ -1184,6 +1197,17 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
 
+nal_size = gb->buffer_end - gb->buffer;
+if (nal_size > sizeof(sps->data)) {
+av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
+   "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
+   nal_size, sizeof(sps->data));
+sps->data_size = sizeof(sps->data);
+} else {
+sps->data_size = nal_size;
+

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 12:01 GMT+02:00 Andy Furniss :


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


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

Re: [FFmpeg-devel] [RFC] marking non developer tickets

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 03:23:36PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-07 13:31 GMT+02:00 Michael Niedermayer :
> 
> > Can type = task be used for non devel tasks
> 
> No objections although I don't understand how #5832 can be "fixed"
> and I don't like tickets that by definition are unfixable.

we have someone who monitors all mailing lists for non subscriber
mails.
Finding someone to moitors fate similarly for new failures may be hard
but its not an impossible task.
Also purely from a man-hours point of view what we do currently
is everyone looks at fate a bit which has to duplicate alot of looking
as its unsynchronized and at the same time alot is not looked at
It should be less man hours if this done by a single person in some
semi automatic/manual way.
new failures can be detected automatically, some unstable tests and
unstable clients may need to be filtered the rest then could
potentially be sent to #ffmpeg-devel.
The human in this case would only need to maintain the list of
unstable tests/clients, some limits to avoid a failing test to trigger
a seperate message for every single fate client. And (s)he would have
to contact people who are known not to follow IRC (for example a
fate client maintainer whos client went out of disk space)

Its not that noone is doing this currently but someone doing this
semi-official and lifting the work from everyone else would be nice
and ATM noone feels responsible to attempt to automate this more
where possible, even though everyone would benefit from more automation
...

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

[FFmpeg-devel] [PATCH 1/2] avformat/segment: give a warning message for remove initial_offset option

[Steven Liu]

ffmpeg have a generic solution working with all muxer named
output_ts_offset, output_ts_offset will instead of initial_offset

Signed-off-by: LiuQi 
---
 libavformat/segment.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index bf29ef8..23e1abf 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -651,6 +651,11 @@ static int seg_init(AVFormatContext *s)
 seg->individual_header_trailer = 0;
 }

+if (seg->initial_offset > 0) {
+av_log(s, AV_LOG_WARNING, "NOTE: the option initial_offset will be
deprecated soon,"
+   "you can use output_ts_offset instead of it\n");
+}
+
 if (!!seg->time_str + !!seg->times_str + !!seg->frames_str > 1) {
 av_log(s, AV_LOG_ERROR,
"segment_time, segment_times, and segment_frames options "
-- 
2.7.4 (Apple Git-66)


0001-avformat-segment-give-a-warning-message-for-remove-i.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Ligverd Haer]

> Please send your updated patch as attachment to a
> reply in this mailing list thread,
> 
> Please tell us if documentation pointed you to github or trac to
> post patches, we try hard to have patch submission (only) on
> this mailing list.
> 
> Carl Eugen

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 519f9c4..ea96f71 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -498,17 +498,15 @@ static int write_manifest(AVFormatContext *s, int final)
 OutputStream *os = >streams[0];
 int start_index = FFMAX(os->nb_segments - c->window_size, 0);
 int64_t start_time = av_rescale_q(os->segments[start_index]->time, s->streams[0]->time_base, AV_TIME_BASE_Q);
-avio_printf(out, "\t\n");
 } else {
-avio_printf(out, "\t\n");
+avio_printf(out, "\t\n",final?"":" id=\"0\"");
 }
 
 if (c->has_video) {
 avio_printf(out, "\t\tmax_frame_rate.num && !c->ambiguous_frame_rate)
-avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(c->min_frame_rate, c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate", c->max_frame_rate.num, c->max_frame_rate.den);
 avio_printf(out, ">\n");
 
 for (i = 0; i < s->nb_streams; i++) {
@@ -598,11 +596,15 @@ static int dash_write_header(AVFormatContext *s)
 AVDictionary *opts = NULL;
 char filename[1024];
 
-os->bit_rate = s->streams[i]->codecpar->bit_rate;
+os->bit_rate = s->streams[i]->codecpar->bit_rate ? s->streams[i]->codecpar->bit_rate :  s->bit_rate;
+
 if (os->bit_rate) {
 snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
  " bandwidth=\"%d\"", os->bit_rate);
 } else {
+snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
+ " bandwidth=\"%d\"", 0);
+
 int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
 AV_LOG_ERROR : AV_LOG_WARNING;
 av_log(s, level, "No bit rate set for stream %d\n", i);
@@ -654,7 +656,7 @@ static int dash_write_header(AVFormatContext *s)
 goto fail;
 os->init_start_pos = 0;
 
-av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 0);
+av_dict_set(, "movflags", "dash+frag_keyframe+empty_moov+separate_moof+delay_moov", 0);
 if ((ret = avformat_write_header(ctx, )) < 0) {
  goto fail;
 }
@@ -858,6 +860,10 @@ static int dash_flush(AVFormatContext *s, int final, int stream)
 if (ret < 0)
 break;
 }
+
+os->bit_rate = (int)( (float)range_length*8 / ((float)(os->max_pts - os->start_pts) / 1) );
+snprintf(os->bandwidth_str, sizeof(os->bandwidth_str)," bandwidth=\"%i\"", os->bit_rate);
+
 add_segment(os, filename, os->start_pts, os->max_pts - os->start_pts, start_pos, range_length, index_length);
 av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d written to: %s\n", i, os->segment_index, full_path);
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] doc/muxers: remove initial_offset from segment muxer

[Carl Eugen Hoyos]

2016-09-08 15:33 GMT+02:00 Steven Liu :
> -@item initial_offset @var{offset}
> -Specify timestamp offset to apply to the output packet timestamps. The
> -argument must be a time duration specification, and defaults to 0.

This should be merged with the other patch.
(If the option gets deprecated it could get removed from documentation
immediately.)

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/segment: remove initial_offset option from segment.c

[Carl Eugen Hoyos]

2016-09-08 15:33 GMT+02:00 Steven Liu :

> -{ "initial_offset", "set initial timestamp offset",
> OFFSET(initial_offset), AV_OPT_TYPE_DURATION,
> {.i64 = 0}, -INT64_MAX, INT64_MAX, E },

You generally cannot simply remove options from FFmpeg.
(I did not look if the option is very new or imposes a security
issue or if there is another reason that makes the removal
acceptable.)

Alternatives are to ignore the option (instead of failing),
only print a warning or make sure that the option still
works if the new / general option isn't used.
I don't know which is best here but command lines that
used to work should not suddenly start to fail.

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

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Carl Eugen Hoyos]

2016-09-08 15:34 GMT+02:00 Ligverd Haer :
> В письме от четверг, 8 сентября 2016 г. 14:35:27 MSK пользователь Michael 
> Niedermayer написал:
>
>> patches should be sent to the mailing list, patches on trac tend to
>> be missed and forgotten
>
> Don't want to clog the ffmpeg-devel mailing list.

Please send your updated patch as attachment to a
reply in this mailing list thread,

Please tell us if documentation pointed you to github or trac to
post patches, we try hard to have patch submission (only) on
this mailing list.

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

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Ligverd Haer]

В письме от четверг, 8 сентября 2016 г. 14:35:27 MSK пользователь Michael 
Niedermayer написал:
 
> patches should be sent to the mailing list, patches on trac tend to
> be missed and forgotten

Don't want to clog the ffmpeg-devel mailing list.
I made a pull request on github, I was sent to ffmpeg-devel mailing list, I 
sent a patch to the ffmpeg-devel mailing list, mene redirected to 
trac.ffmpeg.org

I agree the patch is not critical, and may be not worthy of attention.
In any case I tried. :(
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] doc/muxers: remove initial_offset from segment muxer

[Steven Liu]

Signed-off-by: LiuQi 
---
 doc/muxers.texi | 4 
 1 file changed, 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index c39a6a0..4fd4133 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1355,10 +1355,6 @@ will start with near-zero timestamps. It is meant to
ease the playback
 of the generated segments. May not work with some combinations of
 muxers/codecs. It is set to @code{0} by default.

-@item initial_offset @var{offset}
-Specify timestamp offset to apply to the output packet timestamps. The
-argument must be a time duration specification, and defaults to 0.
-
 @item write_empty_segments @var{1|0}
 If enabled, write an empty segment if there are no packets during the
period a
 segment would usually span. Otherwise, the segment will be filled with the
next
-- 
2.7.4 (Apple Git-66)


0002-doc-muxers-remove-initial_offset-from-segment-muxer.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avformat/segment: remove initial_offset option from segment.c

[Steven Liu]

ffmpeg have a generic solution working with all muxer named
output_ts_offset

Signed-off-by: LiuQi 
---
 libavformat/segment.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index bf29ef8..2fc380e 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -114,7 +114,6 @@ typedef struct SegmentContext {
 char *header_filename;  ///< filename to write the output header to

 int reset_timestamps;  ///< reset timestamps at the begin of each
segment
-int64_t initial_offset;///< initial timestamps offset, expressed
in microseconds
 char *reference_stream_specifier; ///< reference stream specifier
 int   reference_stream_index;
 int   break_non_keyframes;
@@ -802,7 +801,7 @@ static int seg_write_packet(AVFormatContext *s,
AVPacket *pkt)
 {
 SegmentContext *seg = s->priv_data;
 AVStream *st = s->streams[pkt->stream_index];
-int64_t end_pts = INT64_MAX, offset;
+int64_t end_pts = INT64_MAX;
 int start_frame = INT_MAX;
 int ret;
 struct tm ti;
@@ -888,19 +887,7 @@ calc_times:
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, >time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, >time_base));

-/* compute new timestamps */
-offset = av_rescale_q(seg->initial_offset - (seg->reset_timestamps ?
seg->cur_entry.start_pts : 0),
-  AV_TIME_BASE_Q, st->time_base);
-if (pkt->pts != AV_NOPTS_VALUE)
-pkt->pts += offset;
-if (pkt->dts != AV_NOPTS_VALUE)
-pkt->dts += offset;
-
-av_log(s, AV_LOG_DEBUG, " -> pts:%s pts_time:%s dts:%s dts_time:%s\n",
-   av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, >time_base),
-   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, >time_base));
-
-ret = ff_write_chained(seg->avf, pkt->stream_index, pkt, s,
seg->initial_offset || seg->reset_timestamps);
+ret = ff_write_chained(seg->avf, pkt->stream_index, pkt, s,
seg->reset_timestamps);

 fail:
 if (pkt->stream_index == seg->reference_stream_index) {
@@ -998,7 +985,6 @@ static const AVOption options[] = {
 { "individual_header_trailer", "write header/trailer to each segment",
OFFSET(individual_header_trailer), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, E },
 { "write_header_trailer", "write a header to the first segment and a
trailer to the last one", OFFSET(write_header_trailer), AV_OPT_TYPE_BOOL,
{.i64 = 1}, 0, 1, E },
 { "reset_timestamps", "reset timestamps at the begin of each segment",
OFFSET(reset_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
-{ "initial_offset", "set initial timestamp offset",
OFFSET(initial_offset), AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX,
INT64_MAX, E },
 { "write_empty_segments", "allow writing empty 'filler' segments",
OFFSET(write_empty), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
 { NULL },
 };
-- 
2.7.4 (Apple Git-66)


0001-avformat-segment-remove-initial_offset-option-from-s.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Carl Eugen Hoyos]

2016-09-08 10:19 GMT+02:00 Aman Gupta :

> +{ "a53cc", "Use A53 Closed Captions (if available)", OFFSET(a53_cc), 
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE },

Why is this disabled by default?

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

2016-09-08 12:01 GMT+02:00 Andy Furniss :

> I don't know what it is about x11grab/CSC with ffmpeg, but
> on my old CPU gstreamer is twice as fast.

x11grab or xcb?

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 08:42:05PM +0800, Steven Liu wrote:
> 2016-09-08 20:31 GMT+08:00 Michael Niedermayer :
> 
> > On Thu, Sep 08, 2016 at 05:10:14AM -0700, Aman Gupta wrote:
> > > On Thu, Sep 8, 2016 at 2:55 AM, Steven Liu 
> > wrote:
> > >
> > > > 2016-09-08 17:46 GMT+08:00 Michael Niedermayer  > >:
> > > >
> > > > > On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> > > > > > From: Aman Gupta 
> > > > > >
> > > > > > ---
> > > > > >  doc/muxers.texi  |  4 
> > > > > >  libavformat/hlsenc.c | 13 +++--
> > > > > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > > > >
> > > > > Isnt this redundant with
> > > > > -output_ts_offset
> > > > > ?
> > > > > or how do they differ ?
> > > > >
> > > > > [...]
> > > > > --
> > > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > 87040B0FAB
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > Maybe just copy the code from segment.c to hlsenc.c .
> > > >
> > >
> > > Yes, I copied directly from segment.c because I wanted the same feature
> > in
> > > the hls encoder.
> > >
> > > Was not aware of -output_ts_offset. Perhaps that supersedes the
> > > -initial_offset option?
> >
> > does output_ts_offset work as replacement for initial_offset ?
> > a generic solution working with all muxer would be better/simper
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > The bravest are surely those who have the clearest vision
> > of what is before them, glory and danger alike, and yet
> > notwithstanding go out to meet it. -- Thucydides
> >
> >
> Aha, new version have output_ts_offset in mux.c, perhaps this option should
> be ignored.
> 

> And segment.c give a deprecated message and replace by output_ts_offset?

yes if t works

[...]
-- 
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


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

Re: [FFmpeg-devel] [PATCH] [RFC] libavfilter HRTF/room acoustics filter [2/2]

[Michael Niedermayer]

On Tue, Aug 02, 2016 at 06:18:33AM -0700, Yue Shi Lai wrote:
> This is 2/2 of the patch.

>  af_hrtf_mitkemar.c |14076 
> +
>  1 file changed, 14076 insertions(+)
> c4c72f78adf6aebf20ccd1883388bb69d07b9bf9  
> 0002-HRTF-filter-ported-from-MPlayer-2-2.patch
> From ffc3cb3d4b4d3192e6284b7cfbfff3c34ab8e54c Mon Sep 17 00:00:00 2001
> From: Yue Shi Lai 
> Date: Tue, 2 Aug 2016 06:15:33 -0700
> Subject: [PATCH 2/2] HRTF filter ported from MPlayer [2/2]

why is this in 2 patches ?
it should be one patch
if its too big for the ML lou will likely approve the mail within a
day or 2

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: don't reconfigure terminal if we're not taking input from stdin

[Nicolas George]

Le duodi 22 fructidor, an CCXXIV, Rodger Combs a écrit :
> ---
>  ffmpeg.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index d858407..1d793fe 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -366,7 +366,7 @@ static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
>  void term_init(void)
>  {
>  #if HAVE_TERMIOS_H
> -if(!run_as_daemon){
> +if (!run_as_daemon && stdin_interaction) {
>  struct termios tty;
>  if (tcgetattr (0, ) == 0) {
>  oldtty = tty;
> @@ -4328,6 +4328,10 @@ int main(int argc, char **argv)
>  
>  show_banner(argc, argv, options);
>  

> +ret = locate_option(argc, argv, options, "stdin");
> +if (ret && !strcmp(argv[ret], "-nostdin"))
> +stdin_interaction = 0;
> +
>  term_init();

I think it would be more elegant to move the term_init() call a few lines
down, after ffmpeg_parse_options(), rather than parse -nostdin out of order.

Apart from that, both patches looks right to me.

>  
>  /* parse options and open all input/output files */

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] avformat/hlsenc: implement initial_offset

[Steven Liu]

2016-09-08 20:31 GMT+08:00 Michael Niedermayer :

> On Thu, Sep 08, 2016 at 05:10:14AM -0700, Aman Gupta wrote:
> > On Thu, Sep 8, 2016 at 2:55 AM, Steven Liu 
> wrote:
> >
> > > 2016-09-08 17:46 GMT+08:00 Michael Niedermayer  >:
> > >
> > > > On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> > > > > From: Aman Gupta 
> > > > >
> > > > > ---
> > > > >  doc/muxers.texi  |  4 
> > > > >  libavformat/hlsenc.c | 13 +++--
> > > > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > > >
> > > > Isnt this redundant with
> > > > -output_ts_offset
> > > > ?
> > > > or how do they differ ?
> > > >
> > > > [...]
> > > > --
> > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > Maybe just copy the code from segment.c to hlsenc.c .
> > >
> >
> > Yes, I copied directly from segment.c because I wanted the same feature
> in
> > the hls encoder.
> >
> > Was not aware of -output_ts_offset. Perhaps that supersedes the
> > -initial_offset option?
>
> does output_ts_offset work as replacement for initial_offset ?
> a generic solution working with all muxer would be better/simper
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The bravest are surely those who have the clearest vision
> of what is before them, glory and danger alike, and yet
> notwithstanding go out to meet it. -- Thucydides
>
>
Aha, new version have output_ts_offset in mux.c, perhaps this option should
be ignored.

And segment.c give a deprecated message and replace by output_ts_offset?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: don't reconfigure terminal if we're not taking input from stdin

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 07:17:59PM -0500, Rodger Combs wrote:
> ---
>  ffmpeg.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

ill leave these 2 patches for nicolas to review ...

thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 09:58:02AM +0300, Ligverd Haer wrote:
> > > Common attributes for AdaptationSet and Representation shall either be in
> > > one of the elements but not in both.
> > > 
> > > in particular, the attribute frameRate is duplicated in the node
> > > Representation
> > 
> > There is a bug report outstanding for this:
> > https://trac.ffmpeg.org/ticket/5087
> 
> Thank you Reuben, i posted in https://trac.ffmpeg.org/ticket/5087

patches should be sent to the mailing list, patches on trac tend to
be missed and forgotten

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 05:10:14AM -0700, Aman Gupta wrote:
> On Thu, Sep 8, 2016 at 2:55 AM, Steven Liu  wrote:
> 
> > 2016-09-08 17:46 GMT+08:00 Michael Niedermayer :
> >
> > > On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> > > > From: Aman Gupta 
> > > >
> > > > ---
> > > >  doc/muxers.texi  |  4 
> > > >  libavformat/hlsenc.c | 13 +++--
> > > >  2 files changed, 15 insertions(+), 2 deletions(-)
> > >
> > > Isnt this redundant with
> > > -output_ts_offset
> > > ?
> > > or how do they differ ?
> > >
> > > [...]
> > > --
> > > 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
> > >
> > >
> > >
> > Maybe just copy the code from segment.c to hlsenc.c .
> >
> 
> Yes, I copied directly from segment.c because I wanted the same feature in
> the hls encoder.
> 
> Was not aware of -output_ts_offset. Perhaps that supersedes the
> -initial_offset option?

does output_ts_offset work as replacement for initial_offset ?
a generic solution working with all muxer would be better/simper

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 04:53:53PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libavcodec/hevc.h|  9 +
>  libavcodec/hevc_ps.c | 27 +++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> index be91010..6a3c750 100644
> --- a/libavcodec/hevc.h
> +++ b/libavcodec/hevc.h
> @@ -387,6 +387,9 @@ typedef struct HEVCVPS {
>  uint8_t vps_poc_proportional_to_timing_flag;
>  int vps_num_ticks_poc_diff_one; ///< vps_num_ticks_poc_diff_one_minus1 + 
> 1
>  int vps_num_hrd_parameters;
> +
> +uint8_t data[4096];
> +int data_size;
>  } HEVCVPS;
>  
>  typedef struct ScalingList {
> @@ -483,6 +486,9 @@ typedef struct HEVCSPS {
>  int vshift[3];
>  
>  int qp_bd_offset;
> +
> +uint8_t data[4096];
> +int data_size;
>  } HEVCSPS;
>  
>  typedef struct HEVCPPS {
> @@ -557,6 +563,9 @@ typedef struct HEVCPPS {
>  int *tile_pos_rs;   ///< TilePosRS
>  int *min_tb_addr_zs;///< MinTbAddrZS
>  int *min_tb_addr_zs_tab;///< MinTbAddrZS
> +
> +uint8_t data[4096];
> +int data_size;
>  } HEVCPPS;
>  
>  typedef struct HEVCParamSets {
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 83f2ec2..629e454 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -408,6 +408,15 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, 
> AVCodecContext *avctx,
>  
>  av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
>  
> +vps->data_size = gb->buffer_end - gb->buffer;

This theoretically could overflow, data_size is only an int the pointer
difference might be larger

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Aman Gupta]

On Thu, Sep 8, 2016 at 2:55 AM, Steven Liu  wrote:

> 2016-09-08 17:46 GMT+08:00 Michael Niedermayer :
>
> > On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > ---
> > >  doc/muxers.texi  |  4 
> > >  libavformat/hlsenc.c | 13 +++--
> > >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > Isnt this redundant with
> > -output_ts_offset
> > ?
> > or how do they differ ?
> >
> > [...]
> > --
> > 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
> >
> >
> >
> Maybe just copy the code from segment.c to hlsenc.c .
>

Yes, I copied directly from segment.c because I wanted the same feature in
the hls encoder.

Was not aware of -output_ts_offset. Perhaps that supersedes the
-initial_offset option?

Aman



> ___
> 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] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Sven C. Dack]

Just a guess, but you are using nv_surface->height, which appears to have been 
rounded up to 1088 while the actual size is 1080. The 1088 is then passed on to 
av_image_copy() where it probably tries to read 1920x1088 pixels from the 
source, but the source might not have that much memory and so it segfaults.


If you change it like this:

--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1311,7 +1311,7 @@ static int nvenc_copy_frame(AVCodecContext *avctx, 
NvencSurface *nv_surface,


 av_image_copy(dst_data, dst_linesize,
   (const uint8_t**)frame->data, frame->linesize, frame->format,
-  nv_surface->width, nv_surface->height);
+  avctx->width, avctx->height);

 return 0;
 }

... then it's again working for me.

Sven




On 08/09/16 11:00, Sven C. Dack wrote:

Hallo,

ich schicke Dir noch einen weitere Backtrace mit etwas mehr Details:

(gdb) bt
#0  0x7f19eb8e3a3e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00fbc63e in av_image_copy_plane (height=8, bytewidth=7680, 
src_linesize=, src=0x7f19ea08f000 "", dst_linesize=out>, dst=) at src/libavutil/imgutils.c:296
#2  av_image_copy (dst_data=dst_data@entry=0x7ffe7ef4c720, 
dst_linesizes=dst_linesizes@entry=0x7ffe7ef4c710, 
src_data=src_data@entry=0x402c340, 
src_linesizes=src_linesizes@entry=0x402c380, pix_fmt=AV_PIX_FMT_BGR0, width=1920,

height=1088) at src/libavutil/imgutils.c:334
#3  0x00e37321 in nvenc_copy_frame (avctx=0x395af00, 
nv_surface=0x3dff560, nv_surface=0x3dff560, lock_buffer_params=0x7ffe7ef4c740, 
lock_buffer_params=0x7ffe7ef4c740, frame=0x402c340) at 
src/libavcodec/nvenc.c:1312
#4  nvenc_upload_frame (nvenc_frame=0x3dff560, frame=0x402c340, 
avctx=0x395af00) at src/libavcodec/nvenc.c:1430
#5  ff_nvenc_encode_frame (avctx=0x395af00, pkt=0x7ffe7ef4dc90, 
frame=0x402c340, got_packet=0x7ffe7ef4db4c) at src/libavcodec/nvenc.c:1660
#6  0x00a8c9c3 in avcodec_encode_video2 (avctx=avctx@entry=0x395af00, 
avpkt=avpkt@entry=0x7ffe7ef4dc90, frame=frame@entry=0x402c340, 
got_packet_ptr=got_packet_ptr@entry=0x7ffe7ef4db4c) at 
src/libavcodec/utils.c:1961
#7  0x00496448 in do_video_out (s=0x39592c0, ost=ost@entry=0x395ad00, 
next_picture=next_picture@entry=0x402c340, sync_ipts=, 
sync_ipts@entry=-7.62939453125e-06) at src/ffmpeg.c:1175

#8  0x00498d7f in reap_filters (flush=flush@entry=0) at 
src/ffmpeg.c:1366
#9  0x0049a940 in transcode_step () at src/ffmpeg.c:4117
#10 transcode () at src/ffmpeg.c:4161
#11 0x0047d11c in main (argc=, argv=0x7ffe7ef4e5d8) at 
src/ffmpeg.c:4356


..

#3  0x00e37321 in nvenc_copy_frame (avctx=0x395af00, 
nv_surface=0x3dff560, nv_surface=0x3dff560, lock_buffer_params=0x7ffe7ef4c740, 
lock_buffer_params=0x7ffe7ef4c740, frame=0x402c340) at 
src/libavcodec/nvenc.c:1312

1312av_image_copy(dst_data, dst_linesize,
(gdb) list
1307return ret;
1308
1309if (frame->format == AV_PIX_FMT_YUV420P)
1310FFSWAP(uint8_t*, dst_data[1], dst_data[2]);
1311
1312av_image_copy(dst_data, dst_linesize,
1313  (const uint8_t**)frame->data, frame->linesize, 
frame->format,

1314  nv_surface->width, nv_surface->height);
1315
1316return 0;
(gdb) ins dst_data
$10 = {0x2049e "\352", , 0x0, 0x0, 0x0}
(gdb) ins dst_linesize
$11 = {7680, 7680, 7680, 7680}
(gdb) ins frame
$12 = (const AVFrame *) 0x402c340
(gdb) ins *frame
$13 = {data = {0x7f19e98a6000 "\352", , 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, linesize = {7680, 0, 0, 0, 0, 0, 0, 0}, 
extended_data = 0x402c340, width = 1920, height = 1080, nb_samples = 0, format 
= 298,
  key_frame = 1, pict_type = AV_PICTURE_TYPE_NONE, sample_aspect_ratio = {num 
= 0, den = 1}, pts = 0, pkt_pts = 0, pkt_dts = 0, coded_picture_number = 0, 
display_picture_number = 0, quality = 0, opaque = 0x0, error = {0, 0, 0, 0, 0, 0,
0, 0}, repeat_pict = 0, interlaced_frame = 0, top_field_first = 0, 
palette_has_changed = 0, reordered_opaque = -9223372036854775808, sample_rate 
= 0, channel_layout = 0, buf = {0x402b9c0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
  extended_buf = 0x0, nb_extended_buf = 0, side_data = 0x0, nb_side_data = 0, 
flags = 0, color_range = AVCOL_RANGE_UNSPECIFIED, color_primaries = 
AVCOL_PRI_UNSPECIFIED, color_trc = AVCOL_TRC_UNSPECIFIED,
  colorspace = AVCOL_SPC_UNSPECIFIED, chroma_location = 
AVCHROMA_LOC_UNSPECIFIED, best_effort_timestamp = 0, pkt_pos = -1, 
pkt_duration = 0, metadata = 0x0, decode_error_flags = 0, channels = 0, 
pkt_size = 8294400, qscale_table = 0x0,

  qstride = 0, qscale_type = 0, qp_table_buf = 0x0, hw_frames_ctx = 0x0}
(gdb) ins nv_surface
$14 = (NvencSurface *) 0x3dff560
(gdb) ins *nv_surface
$15 = {input_surface = 0x3e0c090, in_ref = 0x0, in_map = {version = 0, 
subResourceIndex = 0, inputResource = 0x0, registeredResource = 0x0, 
mappedResource = 0x0, mappedBufferFmt = NV_ENC_BUFFER_FORMAT_UNDEFINED, 
reserved1 = {
  0 }, reserved2 = {0x0 }}, 

Re: [FFmpeg-devel] [PATCH] ffprobe: add -show_headers_first option

[Stefano Sabatini]

On date Sunday 2016-09-04 19:09:32 +0200, Nicolas George encoded:
> Le nonidi 19 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> > This is meant to be used for generating output suitable for the
> > ffprobe_default demuxer.
> > ---
> >  ffprobe.c | 30 ++
> >  1 file changed, 26 insertions(+), 4 deletions(-)
> 
> I find the naming a bit clumsy. It says what it says, but what it the next
> step? -show_format_after_frames_but_before_streams?
> 
> I would like to suggest another avenue, a little more work but not by much:
> deprecate all the -show_ options, and replace them by a single
> -show option that takes the sections name in order:
> 
> ffprobe -show packets,streams,format
> 
> would be equivalent to the current "ffprobe -show_frames -show_streams
> -show_format", but:
> 

> ffprobe -show format,streams,packets

We have the -show_entries option, and we can extend it to consider
order. The equivalent syntax will then be:

ffprobe -show_entries format,streams,packets

> 
> would yield the same result as with -show_headers_first.
> 
> The syntax could later be updated for various extra features:
> 

> ffprobe -show format,streams,packets,rewind,packets+frames=silent=1,streams

Now the problem with this idea is the interaction with
-read_packets. The option was useful to force reading of packets so
that the gained information was also available in the streams and
format sections (but without showing the packets output).

I can think about extending the -show_entries syntax, so that we could
have:

-show_entries !packets,format,streams

What I don't like is that this special syntax will only work with
packets (it makes no sense for the other sections).

[...]
-- 
FFmpeg = Fast Fiendish Monstrous Perfectionist Encoding/decoding Gorilla
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 10:07:26PM -0300, James Almer wrote:
> On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
> >>  libavformat/utils.c  |4 +++-
> >> >  tests/ref/fate/copy-trac4914 |4 ++--
> >> >  tests/ref/fate/copy-trac4914-avi |4 ++--
> >> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> >> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> >> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> >> > From: Michael Niedermayer 
> >> > Date: Tue, 6 Sep 2016 18:10:41 +0200
> >> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> >> > 
> >> > Suggested-by: Hendrik Leppkes
> >> > Signed-off-by: Michael Niedermayer 
> > applied
> > 
> > with this we have restored the functionality to prior bug/regression
> > so it should serve better as a reference.
> 
> Should be backported to the 3.1 branch.

done locally


> 
> Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
> add both fields (merged or as is) to codecpar as Clément suggested, but
> as internal/hack/nonpublic instead at least until we find a proper way
> to solve the stream copy case?

> I know adding private-but-not-really fields suck, but so does being stuck
> here because AVI is a crappy format.
> 

> Alternatively, since until now ffmpeg.c's stream copy has been using the
> initialized AVCodecContext from AVStream, can't we alloc, initialize and
> use a separate one, much like it's done for actual transcoding? Would
> that be enough for the decoder to set the two fields?

currently the 2 fields are filled in by avformat_find_stream_info()
parsing and or decoding headers and packets and these can require many
packets. The 2 fields really arent special, avformat_find_stream_info()
fills in alot of little bits and pieces from informative over occasional
useful to critical things.
What avformat_find_stream_info() does could be moved into applications
But that would duplicate the code in many user applications and make
it impossible to centrally fix bugs or add features. It could be moved
under a different API too of course. This would raise the question of
"Why" we again reimplement the API. Theres also a general lack of
discussions about design changes and API deprecations on ffmpeg-devel,
which may be part of the problem

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Sven C. Dack wrote:


It is not an issue. x11grab produces BGR0 and nvenc can handle it
with the patch. It's giving me 100fp/s (up from 47fp/s) with a
1920x1080 monitor. I'd imagine people with 4K displays will be happy,
too, although they will have to live with lower speeds of perhaps 30
fp/s. Would be interesting to know how it performs on 4K though.


Maybe

xrandr --output   --fb 3840x2160 --panning 3840x2160

I don't know what it is about x11grab/CSC with ffmpeg, but on my
old CPU gstreamer is twice as fast.

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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Sven C. Dack]

Hallo,

ich schicke Dir noch einen weitere Backtrace mit etwas mehr Details:

(gdb) bt
#0  0x7f19eb8e3a3e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00fbc63e in av_image_copy_plane (height=8, bytewidth=7680, 
src_linesize=, src=0x7f19ea08f000 "", dst_linesize=out>, dst=) at src/libavutil/imgutils.c:296
#2  av_image_copy (dst_data=dst_data@entry=0x7ffe7ef4c720, 
dst_linesizes=dst_linesizes@entry=0x7ffe7ef4c710, 
src_data=src_data@entry=0x402c340, src_linesizes=src_linesizes@entry=0x402c380, 
pix_fmt=AV_PIX_FMT_BGR0, width=1920,

height=1088) at src/libavutil/imgutils.c:334
#3  0x00e37321 in nvenc_copy_frame (avctx=0x395af00, 
nv_surface=0x3dff560, nv_surface=0x3dff560, lock_buffer_params=0x7ffe7ef4c740, 
lock_buffer_params=0x7ffe7ef4c740, frame=0x402c340) at src/libavcodec/nvenc.c:1312
#4  nvenc_upload_frame (nvenc_frame=0x3dff560, frame=0x402c340, avctx=0x395af00) 
at src/libavcodec/nvenc.c:1430
#5  ff_nvenc_encode_frame (avctx=0x395af00, pkt=0x7ffe7ef4dc90, frame=0x402c340, 
got_packet=0x7ffe7ef4db4c) at src/libavcodec/nvenc.c:1660
#6  0x00a8c9c3 in avcodec_encode_video2 (avctx=avctx@entry=0x395af00, 
avpkt=avpkt@entry=0x7ffe7ef4dc90, frame=frame@entry=0x402c340, 
got_packet_ptr=got_packet_ptr@entry=0x7ffe7ef4db4c) at src/libavcodec/utils.c:1961
#7  0x00496448 in do_video_out (s=0x39592c0, ost=ost@entry=0x395ad00, 
next_picture=next_picture@entry=0x402c340, sync_ipts=, 
sync_ipts@entry=-7.62939453125e-06) at src/ffmpeg.c:1175

#8  0x00498d7f in reap_filters (flush=flush@entry=0) at 
src/ffmpeg.c:1366
#9  0x0049a940 in transcode_step () at src/ffmpeg.c:4117
#10 transcode () at src/ffmpeg.c:4161
#11 0x0047d11c in main (argc=, argv=0x7ffe7ef4e5d8) at 
src/ffmpeg.c:4356


..

#3  0x00e37321 in nvenc_copy_frame (avctx=0x395af00, 
nv_surface=0x3dff560, nv_surface=0x3dff560, lock_buffer_params=0x7ffe7ef4c740, 
lock_buffer_params=0x7ffe7ef4c740, frame=0x402c340) at src/libavcodec/nvenc.c:1312

1312av_image_copy(dst_data, dst_linesize,
(gdb) list
1307return ret;
1308
1309if (frame->format == AV_PIX_FMT_YUV420P)
1310FFSWAP(uint8_t*, dst_data[1], dst_data[2]);
1311
1312av_image_copy(dst_data, dst_linesize,
1313  (const uint8_t**)frame->data, frame->linesize, 
frame->format,

1314  nv_surface->width, nv_surface->height);
1315
1316return 0;
(gdb) ins dst_data
$10 = {0x2049e "\352", , 0x0, 0x0, 0x0}
(gdb) ins dst_linesize
$11 = {7680, 7680, 7680, 7680}
(gdb) ins frame
$12 = (const AVFrame *) 0x402c340
(gdb) ins *frame
$13 = {data = {0x7f19e98a6000 "\352", , 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0}, linesize = {7680, 0, 0, 0, 0, 0, 0, 0}, extended_data 
= 0x402c340, width = 1920, height = 1080, nb_samples = 0, format = 298,
  key_frame = 1, pict_type = AV_PICTURE_TYPE_NONE, sample_aspect_ratio = {num = 
0, den = 1}, pts = 0, pkt_pts = 0, pkt_dts = 0, coded_picture_number = 0, 
display_picture_number = 0, quality = 0, opaque = 0x0, error = {0, 0, 0, 0, 0, 0,
0, 0}, repeat_pict = 0, interlaced_frame = 0, top_field_first = 0, 
palette_has_changed = 0, reordered_opaque = -9223372036854775808, sample_rate = 
0, channel_layout = 0, buf = {0x402b9c0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
  extended_buf = 0x0, nb_extended_buf = 0, side_data = 0x0, nb_side_data = 0, 
flags = 0, color_range = AVCOL_RANGE_UNSPECIFIED, color_primaries = 
AVCOL_PRI_UNSPECIFIED, color_trc = AVCOL_TRC_UNSPECIFIED,
  colorspace = AVCOL_SPC_UNSPECIFIED, chroma_location = 
AVCHROMA_LOC_UNSPECIFIED, best_effort_timestamp = 0, pkt_pos = -1, pkt_duration 
= 0, metadata = 0x0, decode_error_flags = 0, channels = 0, pkt_size = 8294400, 
qscale_table = 0x0,

  qstride = 0, qscale_type = 0, qp_table_buf = 0x0, hw_frames_ctx = 0x0}
(gdb) ins nv_surface
$14 = (NvencSurface *) 0x3dff560
(gdb) ins *nv_surface
$15 = {input_surface = 0x3e0c090, in_ref = 0x0, in_map = {version = 0, 
subResourceIndex = 0, inputResource = 0x0, registeredResource = 0x0, 
mappedResource = 0x0, mappedBufferFmt = NV_ENC_BUFFER_FORMAT_UNDEFINED, 
reserved1 = {
  0 }, reserved2 = {0x0 }}, reg_idx = 
0, width = 1920, height = 1088, pitch = 7680, output_surface = 0x3d97f20, format 
= NV_ENC_BUFFER_FORMAT_ARGB, size = 1048576, lockCount = 1}




On 08/09/16 10:30, Timo Rothenpieler wrote:

for fmt in yuv420p nv12 bgr0 rgb0; do
 ./ffmpeg -f lavfi -i "testsrc=size=1920x1080:duration=10:rate=30"
-c:v h264_nvenc -global_quality 20 -pix_fmt "$fmt" -y out_"${fmt}".mkv
done

You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.

pix_fmt should make sure it's properly converted, and according to the
output, it does:


Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248),
yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k
tbn, 30 tbc

Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248), nv12,
1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k tbn, 30 

Re: [FFmpeg-devel] questions about multi-thread issues for ffmpeg

[Ronald S. Bultje]

Hi Andrew,

On Thu, Sep 8, 2016 at 3:59 AM, qw  wrote:

> I have made one simple transcoding program by using ffmpeg lib, where
> several av transcoding tasks are done in one process and each task
> corresponds to one thread.
>
> But some ffmpeg function will report error, and sometimes the multi-thread
> version of transcoding program will crash abnormally.
>
> For example, av_guess_format("mp4", NULL, NULL) returns error accidentally
> with several concurrent tasks. And transcoding program will crash, when
> calling av_interleaved_write_frame ().
>

Have you tried running this under valgrind? It is typically very helpful to
see what causes the crash.

does ffmpeg support multi-thread in this case? If not, which ffmpeg
> functions should be synchronized by application developer?


Yes, ffmpeg supports multi-threading (internally), it is tested
continuously and is considered very safe.

Can you show some code? I'm wondering if your use is unusual.

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Steven Liu]

2016-09-08 17:46 GMT+08:00 Michael Niedermayer :

> On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  doc/muxers.texi  |  4 
> >  libavformat/hlsenc.c | 13 +++--
> >  2 files changed, 15 insertions(+), 2 deletions(-)
>
> Isnt this redundant with
> -output_ts_offset
> ?
> or how do they differ ?
>
> [...]
> --
> 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
>
>
>
Maybe just copy the code from segment.c to hlsenc.c .
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 10:47:42AM +0900, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  doc/muxers.texi  |  4 
>  libavformat/hlsenc.c | 13 +++--
>  2 files changed, 15 insertions(+), 2 deletions(-)

Isnt this redundant with
-output_ts_offset
?
or how do they differ ?

[...]
-- 
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


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

Re: [FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 02:38:48PM -0700, Sergey Volk wrote:
> I just realized that count+1 itself might overflow if count==UINT_MAX, so I
> guess it's better to subtract 1 from the right-hand side. Attached updated
> patch.
> 
> On Wed, Sep 7, 2016 at 2:21 PM, Sergey Volk  wrote:
> 
> > Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
> > we need to check that (count + 1) won't cause overflow.
> >
> >

>  mov.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 5f372bd81ec31f48d8a4b78f82a4ab9c82a9bb43  
> 0001-Fix-potential-integer-overflow-in-mov_read_keys.patch
> From 87a7a2e202ebb63362715054773a89ce1fc71743 Mon Sep 17 00:00:00 2001
> From: Sergey Volk 
> Date: Wed, 7 Sep 2016 14:05:35 -0700
> Subject: [PATCH] Fix potential integer overflow in mov_read_keys
> 
> Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
> we need to check that (count + 1) won't cause overflow.
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Nicolas George]

Le tridi 23 fructidor, an CCXXIV, Paul B Mahol a écrit :
> You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.

That would be more efficient, but with testsrc, lavfi inserts the scale
filter to convert into the requested format anyway.

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] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Timo Rothenpieler]

>> for fmt in yuv420p nv12 bgr0 rgb0; do
>> ./ffmpeg -f lavfi -i "testsrc=size=1920x1080:duration=10:rate=30"
>> -c:v h264_nvenc -global_quality 20 -pix_fmt "$fmt" -y out_"${fmt}".mkv
>> done
> 
> You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.

pix_fmt should make sure it's properly converted, and according to the
output, it does:


Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248),
yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k
tbn, 30 tbc

Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248), nv12,
1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k tbn, 30 tbc

Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248), bgr0,
1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k tbn, 30 tbc

Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248), rgb0,
1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 2000 kb/s, 30 fps, 1k tbn, 30 tbc

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

On Wed, Sep 07, 2016 at 10:07:26PM -0300, James Almer wrote:
> On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
> >>  libavformat/utils.c  |4 +++-
> >> >  tests/ref/fate/copy-trac4914 |4 ++--
> >> >  tests/ref/fate/copy-trac4914-avi |4 ++--
> >> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> >> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> >> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> >> > From: Michael Niedermayer 
> >> > Date: Tue, 6 Sep 2016 18:10:41 +0200
> >> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> >> > 
> >> > Suggested-by: Hendrik Leppkes
> >> > Signed-off-by: Michael Niedermayer 
> > applied
> > 
> > with this we have restored the functionality to prior bug/regression
> > so it should serve better as a reference.
> 
> Should be backported to the 3.1 branch.
> 

> Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
> add both fields (merged or as is) to codecpar as Clément suggested, but
> as internal/hack/nonpublic instead at least until we find a proper way
> to solve the stream copy case?

There might be another way. If this is moved to lavf/utils, the code will
have access to AVStream->internal->avctx, which is (still) legit. AFAICT,
this will require a function such as avformat_remux_copy_timebase().

But is this what we really want?

Also, we need to clarify the use of copy_tb. Currently, according to the
doc, 0=demuxer, 1=decoder, -1=auto but 2 is not documented (maybe it's
time to move the cli options to an AVOption system to have constants).

> I know adding private-but-not-really fields suck, but so does being stuck
> here because AVI is a crappy format.
> 

This is not only for avi, see eed7e08 cf9500a ba96a2a

> Alternatively, since until now ffmpeg.c's stream copy has been using the
> initialized AVCodecContext from AVStream, can't we alloc, initialize and
> use a separate one, much like it's done for actual transcoding? Would
> that be enough for the decoder to set the two fields?

And re-do the probe somehow to fill its parameters?

> I'm throwing shit at the wall to see what sticks, because i barely know
> half of what this whole problem entails. But i do know that the more we
> bikeshed the less chances it will be resolved in a timely and adequate
> manner.

Yes, and this is really hindering any progress with the merge (ETA: ~300
commits, twice as worse as a few weeks ago).

> For that matter, libav clearly didn't have this issue. Does that means
> avconv is creating broken files in these specific cases with stream copy?

AFAIK, yes

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Paul B Mahol]

On 9/8/16, Timo Rothenpieler  wrote:
> Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
>> On 08/09/16 00:57, Hendrik Leppkes wrote:
>>> The image copying code was refactored in an earlier patch to be
>>> generic and not rely on hard-coding format info, hence the second part
>>> is not needed anymore.
>>>
>>
>> This is not quite accurate. It doesn't explain the seg. fault. This
>> didn't happen in my patch and I am currently using my own version of
>> nvenc.c where it's working fine and without the re-factoring. I will not
>> make a second patch, but see Timo being in charge of this as he is the
>> one who signed it off. I am going to "do the Pope" and have a little
>> faith.
>>
>> Sven
>
> Here's the output from my tests
>
> for fmt in yuv420p nv12 bgr0 rgb0; do
> ./ffmpeg -f lavfi -i "testsrc=size=1920x1080:duration=10:rate=30"
> -c:v h264_nvenc -global_quality 20 -pix_fmt "$fmt" -y out_"${fmt}".mkv
> done

You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/videotoolboxenc: implement a53cc

[Aman Gupta]

From: Aman Gupta 

---
 libavcodec/videotoolboxenc.c | 76 ++--
 1 file changed, 67 insertions(+), 9 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 4345ca3..859dde9 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -32,6 +32,7 @@
 #include "libavutil/pixdesc.h"
 #include "internal.h"
 #include 
+#include "h264.h"
 
 #if !CONFIG_VT_BT2020
 # define kCVImageBufferColorPrimaries_ITU_R_2020   CFSTR("ITU_R_2020")
@@ -55,8 +56,14 @@ typedef enum VTH264Entropy{
 
 static const uint8_t start_code[] = { 0, 0, 0, 1 };
 
+typedef struct ExtraSEI {
+  void *data;
+  size_t size;
+} ExtraSEI;
+
 typedef struct BufNode {
 CMSampleBufferRef cm_buffer;
+ExtraSEI *sei;
 struct BufNode* next;
 int error;
 } BufNode;
@@ -94,6 +101,7 @@ typedef struct VTEncContext {
 bool flushing;
 bool has_b_frames;
 bool warned_color_range;
+bool a53_cc;
 } VTEncContext;
 
 static int vtenc_populate_extradata(AVCodecContext   *avctx,
@@ -136,7 +144,7 @@ static void set_async_error(VTEncContext *vtctx, int err)
 pthread_mutex_unlock(>lock);
 }
 
-static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef *buf)
+static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef *buf, 
ExtraSEI **sei)
 {
 BufNode *info;
 
@@ -173,6 +181,12 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool wait, 
CMSampleBufferRef *buf)
 pthread_mutex_unlock(>lock);
 
 *buf = info->cm_buffer;
+if (sei && *buf) {
+*sei = info->sei;
+} else if (info->sei) {
+if (info->sei->data) av_free(info->sei->data);
+av_free(info->sei);
+}
 av_free(info);
 
 vtctx->frame_ct_out++;
@@ -180,7 +194,7 @@ static int vtenc_q_pop(VTEncContext *vtctx, bool wait, 
CMSampleBufferRef *buf)
 return 0;
 }
 
-static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer)
+static void vtenc_q_push(VTEncContext *vtctx, CMSampleBufferRef buffer, 
ExtraSEI *sei)
 {
 BufNode *info = av_malloc(sizeof(BufNode));
 if (!info) {
@@ -190,6 +204,7 @@ static void vtenc_q_push(VTEncContext *vtctx, 
CMSampleBufferRef buffer)
 
 CFRetain(buffer);
 info->cm_buffer = buffer;
+info->sei = sei;
 info->next = NULL;
 
 pthread_mutex_lock(>lock);
@@ -420,6 +435,7 @@ static void vtenc_output_callback(
 {
 AVCodecContext *avctx = ctx;
 VTEncContext   *vtctx = avctx->priv_data;
+ExtraSEI *sei = sourceFrameCtx;
 
 if (vtctx->async_error) {
 if(sample_buffer) CFRelease(sample_buffer);
@@ -440,7 +456,7 @@ static void vtenc_output_callback(
 }
 }
 
-vtenc_q_push(vtctx, sample_buffer);
+vtenc_q_push(vtctx, sample_buffer, sei);
 }
 
 static int get_length_code_size(
@@ -1258,7 +1274,8 @@ static int copy_replace_length_codes(
 static int vtenc_cm_to_avpacket(
 AVCodecContext*avctx,
 CMSampleBufferRef sample_buffer,
-AVPacket  *pkt)
+AVPacket  *pkt,
+ExtraSEI  *sei)
 {
 VTEncContext *vtctx = avctx->priv_data;
 
@@ -1269,6 +1286,7 @@ static int vtenc_cm_to_avpacket(
 size_t  header_size = 0;
 size_t  in_buf_size;
 size_t  out_buf_size;
+size_t  sei_nalu_size = 0;
 int64_t dts_delta;
 int64_t time_base_num;
 int nalu_count;
@@ -1298,9 +1316,14 @@ static int vtenc_cm_to_avpacket(
 if(status)
 return status;
 
+if (sei) {
+sei_nalu_size = sizeof(start_code) + 3 + sei->size + 1;
+}
+
 in_buf_size = CMSampleBufferGetTotalSampleSize(sample_buffer);
 out_buf_size = header_size +
in_buf_size +
+   sei_nalu_size +
nalu_count * ((int)sizeof(start_code) - 
(int)length_code_size);
 
 status = ff_alloc_packet2(avctx, pkt, out_buf_size, out_buf_size);
@@ -1317,7 +1340,7 @@ static int vtenc_cm_to_avpacket(
 length_code_size,
 sample_buffer,
 pkt->data + header_size,
-pkt->size - header_size
+pkt->size - header_size - sei_nalu_size
 );
 
 if (status) {
@@ -1325,6 +1348,19 @@ static int vtenc_cm_to_avpacket(
 return status;
 }
 
+if (sei_nalu_size > 0) {
+uint8_t *sei_nalu = pkt->data + pkt->size - sei_nalu_size;
+memcpy(sei_nalu, start_code, sizeof(start_code));
+sei_nalu += sizeof(start_code);
+sei_nalu[0] = NAL_SEI;
+sei_nalu[1] = SEI_TYPE_USER_DATA_REGISTERED;
+sei_nalu[2] = sei->size;
+sei_nalu += 3;
+memcpy(sei_nalu, sei->data, sei->size);
+sei_nalu += sei->size;
+sei_nalu[0] = 1; // RBSP
+}
+
 if (is_key_frame) {
 pkt->flags |= AV_PKT_FLAG_KEY;
 }
@@ -1707,6 +1743,7 @@ static int vtenc_send_frame(AVCodecContext *avctx,
 CMTime time;
 CFDictionaryRef frame_dict;
 CVPixelBufferRef cv_img = NULL;
+ExtraSEI *sei = NULL;
 int status = 

[FFmpeg-devel] questions about multi-thread issues for ffmpeg

[qw]

Hi,


I have made one simple transcoding program by using ffmpeg lib, where several 
av transcoding tasks are done in one process and each task corresponds to one 
thread.


But some ffmpeg function will report error, and sometimes the multi-thread 
version of transcoding program will crash abnormally.


For example, av_guess_format("mp4", NULL, NULL) returns error accidentally with 
several concurrent tasks. And transcoding program will crash, when calling 
av_interleaved_write_frame ().


does ffmpeg support multi-thread in this case? If not, which ffmpeg functions 
should be synchronized by application developer?


Thanks!


Regards


Andrew



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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Timo Rothenpieler]

Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
> On 08/09/16 00:57, Hendrik Leppkes wrote:
>> The image copying code was refactored in an earlier patch to be
>> generic and not rely on hard-coding format info, hence the second part
>> is not needed anymore.
>>
> 
> This is not quite accurate. It doesn't explain the seg. fault. This
> didn't happen in my patch and I am currently using my own version of
> nvenc.c where it's working fine and without the re-factoring. I will not
> make a second patch, but see Timo being in charge of this as he is the
> one who signed it off. I am going to "do the Pope" and have a little faith.
> 
> Sven

Here's the output from my tests

for fmt in yuv420p nv12 bgr0 rgb0; do
./ffmpeg -f lavfi -i "testsrc=size=1920x1080:duration=10:rate=30"
-c:v h264_nvenc -global_quality 20 -pix_fmt "$fmt" -y out_"${fmt}".mkv
done

->

https://bpaste.net/show/e934dd308c36

They all work and look propperly, with no segfault.
Also tested the 10bit formats and hevc, but I don't have access to my
Pascal-Card from here, but it worked there as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Timo Rothenpieler]

Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
> On 08/09/16 00:57, Hendrik Leppkes wrote:
>> The image copying code was refactored in an earlier patch to be
>> generic and not rely on hard-coding format info, hence the second part
>> is not needed anymore.
>>
> 
> This is not quite accurate. It doesn't explain the seg. fault. This
> didn't happen in my patch and I am currently using my own version of
> nvenc.c where it's working fine and without the re-factoring. I will not
> make a second patch, but see Timo being in charge of this as he is the
> one who signed it off. I am going to "do the Pope" and have a little faith.
> 
> Sven

Can you send a full backtrace of your segfault?
I tested all possible input formats and they all worked fine without
crashing and with the expected visual outcome.



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

Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Ligverd Haer]

> > Common attributes for AdaptationSet and Representation shall either be in
> > one of the elements but not in both.
> > 
> > in particular, the attribute frameRate is duplicated in the node
> > Representation
> 
> There is a bug report outstanding for this:
> https://trac.ffmpeg.org/ticket/5087

Thank you Reuben, i posted in https://trac.ffmpeg.org/ticket/5087


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