[FFmpeg-devel] [PATCH] avframe: add (a)copyprops filter
Hi, patch attached. 0001-avfilter-add-a-copyprops-filter.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: fix a codecpar non use
On Fri, Aug 26, 2016 at 03:49:55PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ 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
On Fri, Aug 26, 2016 at 02:37:42PM -0700, Brett Harrison wrote:
> Allows expr evaluation in the fontsize parameter for drawtext.
>
> examples (fontsize 1/3 of video height):
>
> ffmpeg -i http://i.giphy.com/kwAi4WrChkSfm.gif -vf
> "drawtext=fontfile=/Library/Fonts/Verdana
> Bold.ttf:text='HI':fontcolor=yellow:x=(w-tw)/2:y=(h-th)/1.3:fontsize=h/3"
> out.gif
>
> ffmpeg -i http://i.giphy.com/3o6ozzX4mAcwkkgzG8.gif -vf
> "drawtext=fontfile=/Library/Fonts/Verdana
> Bold.ttf:text='HI':fontcolor=yellow:x=(w-tw)/2:y=(h-th)/1.3:fontsize=h/3"
> out.gif
>
> ---
> libavfilter/vf_drawtext.c | 89
> +++
> 1 file changed, 82 insertions(+), 7 deletions(-)
The patch is corrupted by newlines
Applying: Allows expr evaluation in the fontsize parameter for drawtext.
fatal: patch fragment without header at line 20: @@ -209,7 +211,7 @@ static
const AVOption drawtext_options[]= {
error: could not build fake ancestor
Patch failed at 0001 Allows expr evaluation in the fontsize parameter for
drawtext.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add max value output option to psnr stats log.
On Fri, Aug 26, 2016 at 12:10:17PM -0700, Lucas Cooper wrote:
> This allows retroactive calculation/aggregation of PSNR from the stats
> log.
> ---
> libavfilter/vf_psnr.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
> index 3bec747..9ad1423 100644
> --- a/libavfilter/vf_psnr.c
> +++ b/libavfilter/vf_psnr.c
> @@ -45,6 +45,7 @@ typedef struct PSNRContext {
> char *stats_file_str;
> int stats_version;
> int stats_header_written;
> +int stats_add_max;
> int max[4], average_max;
> int is_rgb;
> uint8_t rgba_map[4];
> @@ -63,6 +64,7 @@ static const AVOption psnr_options[] = {
> {"stats_file", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0,
> FLAGS },
> {"f", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0,
> FLAGS },
> {"stats_version", "Set the format version for the stats file.",
> OFFSET(stats_version), AV_OPT_TYPE_INT,{.i64=1},1, 2, FLAGS },
> +{"output_max", "Add raw stats (max values) to the output log.",
>OFFSET(stats_add_max), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> { NULL }
> };
>
> @@ -182,6 +184,12 @@ static AVFrame *do_psnr(AVFilterContext *ctx, AVFrame
> *main,
> for (j = 0; j < s->nb_components; j++) {
> fprintf(s->stats_file, ",psnr_%c", s->comps[j]);
> }
> +if (s->stats_add_max) {
> +fprintf(s->stats_file, ",max_avg");
> +for (j = 0; j < s->nb_components; j++) {
> +fprintf(s->stats_file, ",max_%c", s->comps[j]);
> +}
> +}
> fprintf(s->stats_file, "\n");
> s->stats_header_written = 1;
> }
> @@ -196,6 +204,13 @@ static AVFrame *do_psnr(AVFilterContext *ctx, AVFrame
> *main,
> fprintf(s->stats_file, "psnr_%c:%0.2f ", s->comps[j],
> get_psnr(comp_mse[c], 1, s->max[c]));
> }
> +if (s->stats_version == 2 && s->stats_add_max) {
> +fprintf(s->stats_file, "max_avg:%d ", s->average_max);
> +for (j = 0; j < s->nb_components; j++) {
> +c = s->is_rgb ? s->rgba_map[j] : j;
> +fprintf(s->stats_file, "max_%c:%d ", s->comps[j], s->max[c]);
> +}
> +}
> fprintf(s->stats_file, "\n");
if the user sets output_max without stats_version 2 this would just
silently ignore the option
also missing doc/*.texi update
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
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] add option hls_init_time to set init hls window segment
On Sat, Aug 27, 2016 at 07:44:01AM +0800, Steven Liu wrote:
> 2016-08-27 4:49 GMT+08:00 Michael Niedermayer :
>
> > On Fri, Aug 26, 2016 at 05:30:41PM +0800, Steven Liu wrote:
> > > recover segments duration time by hls_time after init hls window.
> > > This is reuqested by Ibrahim Tachijian
> > >
> > > Signed-off-by: LiuQi
> > > ---
> > > libavformat/hlsenc.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > [...]
> > > hlsenc.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > > f38066079d46206d1bc970f026a7a9de25ace8d1 0001-add-option-hls_init_time-
> > to-set-init-hls-window-segm.patch
> > > From 937e5301414f1c43c4c564ee59a4dfeee690293c Mon Sep 17 00:00:00 2001
> > > From: Steven Liu
> > > Date: Fri, 26 Aug 2016 14:34:58 +0800
> > > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
> > segment
> > > duration
> > >
> > > And recover segments duration time by hls_time after init hls window.
> > > This is reuqested by Ibrahim Tachijian
> > >
> > > Signed-off-by: LiuQi
> > > ---
> > > libavformat/hlsenc.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > > index e65f002..f5ceb60 100644
> > > --- a/libavformat/hlsenc.c
> > > +++ b/libavformat/hlsenc.c
> > > @@ -85,6 +85,7 @@ typedef struct HLSContext {
> > > AVFormatContext *vtt_avf;
> > >
> > > float time;// Set by a private option.
> > > +float init_time;// Set by a private option.
> > > int max_nb_segments; // Set by a private option.
> > > int wrap; // Set by a private option.
> >
> > the comment looks oddly aligned, it should be at the same horizontal
> > position as teh others
> >
> >
> > > uint32_t flags;// enum HLSFlags
> > > @@ -706,7 +707,7 @@ static int hls_write_header(AVFormatContext *s)
> > > int vtt_basename_size;
> > >
> > > hls->sequence = hls->start_sequence;
> > > -hls->recording_time = hls->time * AV_TIME_BASE;
> > > +hls->recording_time = (hls->init_time ? hls->init_time : hls->time)
> > * AV_TIME_BASE;
> > > hls->start_pts = AV_NOPTS_VALUE;
> > >
> > > if (hls->format_options_str) {
> > > @@ -860,9 +861,19 @@ static int hls_write_packet(AVFormatContext *s,
> > AVPacket *pkt)
> > > AVStream *st = s->streams[pkt->stream_index];
> > > int64_t end_pts = hls->recording_time * hls->number;
> > > int is_ref_pkt = 1;
> >
> > > +int init_list_dur = 0;
> > > +int after_init_list_dur = 0;
> >
> > the initialized value is not used
> > also the declaration can be moved into the if() below
> >
> > > int ret, can_split = 1;
> > > int stream_index = 0;
> > >
> > > +if (hls->sequence - hls->nb_entries > hls->start_sequence &&
> > hls->init_time > 0) {
> > > +/* reset end_pts, hls->recording_time at end of the init hls
> > list */
> > > +init_list_dur = hls->init_time * hls->nb_entries * AV_TIME_BASE;
> > > +after_init_list_dur = (hls->sequence - hls->nb_entries ) *
> > hls->time * AV_TIME_BASE;
> > > +hls->recording_time = hls->time * AV_TIME_BASE;
> > > +end_pts = init_list_dur + after_init_list_dur ;
> > > +}
> > > +
> > > if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE ) {
> > > oc = hls->vtt_avf;
> > > stream_index = 0;
> > > @@ -972,6 +983,7 @@ static int hls_write_trailer(struct AVFormatContext
> > *s)
> > [...]
> >
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Let us carefully observe those good qualities wherein our enemies excel us
> > and endeavor to excel them, by avoiding what is faulty, and imitating what
> > is excellent in them. -- Plutarch
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > Update patch
> hlsenc.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 2feb683487b70430f2ea423d2678d7f30d0c3079
> 0001-add-option-hls_init_time-to-set-init-hls-window-segm.patch
> From dfadb857714867613afebe1a740a8e7fccaa5443 Mon Sep 17 00:00:00 2001
> From: Steven Liu
> Date: Sat, 27 Aug 2016 07:32:40 +0800
> Subject: [PATCH 1/2] add option hls_init_time to set init hls window segment
> duration
>
> recover segments duration time by hls_time after init hls window.
> This is reuqested by Ibrahim Tachijian
>
> Reviewed-by: Michael Niedermayer
> Signed-off-by: LiuQi
> ---
> libavformat/hlsenc.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e65f002..95da86c 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -85,6 +85,7 @@ typedef struct HLSContext {
> AVFormatContext *vtt_avf;
>
> float time;// Set by a privat
Re: [FFmpeg-devel] Possible long(er?) term support
On Fri, Aug 26, 2016 at 12:59:53PM -0600, Orion Poplawski wrote: > On 08/25/2016 04:05 AM, Michael Niedermayer wrote: > > On Wed, Aug 24, 2016 at 12:11:47PM -0600, Orion Poplawski wrote: > >> On 08/24/2016 11:54 AM, Carl Eugen Hoyos wrote: > >>> Hi! > >>> > >>> 2016-08-24 18:51 GMT+02:00 Orion Poplawski : > Would the ffmpeg developers be willing treat any particular release as > a > long-term-support release and try to do security updates for it? > >>> > >>> Could you define "long-term"? > >>> > >>> Carl Eugen > >> > >> Well, EL7 itself will be around for a long time (till 2024), but we don't > >> expect any open-source project to have support for that long. But > >> something in > >> the 2-3 year range would be very helpful. > > > > Calling one of our releases from time to time LTS certainly makes > > sense from a marketing point of view ... > > Doing that with a consistent shedule and clearly stated timeframe > > also makes sense > > Also synchronizing such shedule with distros and user applications > > would make sense > > > > To support a release better, longer or with more clearly stated shedule > > requires someone with the will and time to stand > > behind it though. Is there someone this applies to ? > > Do you know someone this applies to ? > > > > Thanks > > I'm not sure who the questions are addressed to. But in any case, it looks > like rpmfusion will be shipping ffmpeg 2.8 in their epel7 release. So it > would be helpful to try to support that for as long as it is reasonable. I'm > sure everyone involved will try to help out where possible. Thanks. which other distros use 2.8 ? (that is distro releases which will not/ cannot upgrade to 3.*) we can add "LTS" to the next 2.8 point release and announce this if the community agrees and is willing to help support the effort If we do this, we should clearly state how long LTS support will last that is basically how long people are willing to commit themselfs to backporting security fixes. how long would you help doing that for example? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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/3] vf_colorspace: Check av_frame_copy_props() return value
On Fri, Aug 26, 2016 at 12:59:34AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara <
> vittorio.giov...@gmail.com> wrote:
>
> > This function can potentially allocate memory.
> > ---
> > Please keep me in CC.
> > Vittorio
> >
> > libavfilter/vf_colorspace.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> > index 3d39f13..bf51c83 100644
> > --- a/libavfilter/vf_colorspace.c
> > +++ b/libavfilter/vf_colorspace.c
> > @@ -861,7 +861,11 @@ static int filter_frame(AVFilterLink *link, AVFrame
> > *in)
> > av_frame_free(&in);
> > return AVERROR(ENOMEM);
> > }
> > -av_frame_copy_props(out, in);
> > +res = av_frame_copy_props(out, in);
> > +if (res < 0) {
> > +av_frame_free(&in);
> > +return res;
> > +}
> >
> > out->color_primaries = s->user_prm == AVCOL_PRI_UNSPECIFIED ?
> > default_prm[FFMIN(s->user_all, CS_NB)] :
> > s->user_prm;
> > --
> > 2.9.3
>
>
> OK.
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] vf_colorspace: Add support for full range yuv
On Fri, Aug 26, 2016 at 01:01:09AM -0400, Ronald S. Bultje wrote: > Hi, > > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > > Whenever a full range video is input, since the YUVJ* formats are not > > listed as supported for this filter, a range reduction takes place > > through the auto-inserted format filter, forcing the conversion to > > operate on a limited range, > > > > However the filter handles full range videos perfectly fine, so adding > > support to YUVJ* formats will allow skipping a conversion step, while > > providing completely identical results. > > > > Signed-off-by: Vittorio Giovara > > --- > > Please keep me in CC. > > Vittorio > > > > libavfilter/vf_colorspace.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c > > index bf51c83..37e77d1 100644 > > --- a/libavfilter/vf_colorspace.c > > +++ b/libavfilter/vf_colorspace.c > > @@ -960,6 +960,7 @@ static int query_formats(AVFilterContext *ctx) > > AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, > > AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10, > > AV_PIX_FMT_YUV420P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12, > > +AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, > > AV_PIX_FMT_NONE > > }; > > int res; > > -- > > 2.9.3 > > > I guess this is OK, I thought they were deprecated but I guess there is > natural conversion mechanism in place (passthrough to re-stamp yuvjN as > yuvN,range=full)... applied thnx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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] add option hls_init_time to set init hls window segment
2016-08-27 18:25 GMT+08:00 Michael Niedermayer :
> On Sat, Aug 27, 2016 at 07:44:01AM +0800, Steven Liu wrote:
> > 2016-08-27 4:49 GMT+08:00 Michael Niedermayer :
> >
> > > On Fri, Aug 26, 2016 at 05:30:41PM +0800, Steven Liu wrote:
> > > > recover segments duration time by hls_time after init hls window.
> > > > This is reuqested by Ibrahim Tachijian
> > > >
> > > > Signed-off-by: LiuQi
> > > > ---
> > > > libavformat/hlsenc.c | 14 +-
> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > > [...]
> > > > hlsenc.c | 14 +-
> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > > > f38066079d46206d1bc970f026a7a9de25ace8d1
> 0001-add-option-hls_init_time-
> > > to-set-init-hls-window-segm.patch
> > > > From 937e5301414f1c43c4c564ee59a4dfeee690293c Mon Sep 17 00:00:00
> 2001
> > > > From: Steven Liu
> > > > Date: Fri, 26 Aug 2016 14:34:58 +0800
> > > > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
> > > segment
> > > > duration
> > > >
> > > > And recover segments duration time by hls_time after init hls window.
> > > > This is reuqested by Ibrahim Tachijian
> > > >
> > > > Signed-off-by: LiuQi
> > > > ---
> > > > libavformat/hlsenc.c | 14 +-
> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > > > index e65f002..f5ceb60 100644
> > > > --- a/libavformat/hlsenc.c
> > > > +++ b/libavformat/hlsenc.c
> > > > @@ -85,6 +85,7 @@ typedef struct HLSContext {
> > > > AVFormatContext *vtt_avf;
> > > >
> > > > float time;// Set by a private option.
> > > > +float init_time;// Set by a private option.
> > > > int max_nb_segments; // Set by a private option.
> > > > int wrap; // Set by a private option.
> > >
> > > the comment looks oddly aligned, it should be at the same horizontal
> > > position as teh others
> > >
> > >
> > > > uint32_t flags;// enum HLSFlags
> > > > @@ -706,7 +707,7 @@ static int hls_write_header(AVFormatContext *s)
> > > > int vtt_basename_size;
> > > >
> > > > hls->sequence = hls->start_sequence;
> > > > -hls->recording_time = hls->time * AV_TIME_BASE;
> > > > +hls->recording_time = (hls->init_time ? hls->init_time :
> hls->time)
> > > * AV_TIME_BASE;
> > > > hls->start_pts = AV_NOPTS_VALUE;
> > > >
> > > > if (hls->format_options_str) {
> > > > @@ -860,9 +861,19 @@ static int hls_write_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > > AVStream *st = s->streams[pkt->stream_index];
> > > > int64_t end_pts = hls->recording_time * hls->number;
> > > > int is_ref_pkt = 1;
> > >
> > > > +int init_list_dur = 0;
> > > > +int after_init_list_dur = 0;
> > >
> > > the initialized value is not used
> > > also the declaration can be moved into the if() below
> > >
> > > > int ret, can_split = 1;
> > > > int stream_index = 0;
> > > >
> > > > +if (hls->sequence - hls->nb_entries > hls->start_sequence &&
> > > hls->init_time > 0) {
> > > > +/* reset end_pts, hls->recording_time at end of the init hls
> > > list */
> > > > +init_list_dur = hls->init_time * hls->nb_entries *
> AV_TIME_BASE;
> > > > +after_init_list_dur = (hls->sequence - hls->nb_entries ) *
> > > hls->time * AV_TIME_BASE;
> > > > +hls->recording_time = hls->time * AV_TIME_BASE;
> > > > +end_pts = init_list_dur + after_init_list_dur ;
> > > > +}
> > > > +
> > > > if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE ) {
> > > > oc = hls->vtt_avf;
> > > > stream_index = 0;
> > > > @@ -972,6 +983,7 @@ static int hls_write_trailer(struct
> AVFormatContext
> > > *s)
> > > [...]
> > >
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > Let us carefully observe those good qualities wherein our enemies
> excel us
> > > and endeavor to excel them, by avoiding what is faulty, and imitating
> what
> > > is excellent in them. -- Plutarch
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > Update patch
>
> > hlsenc.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 2feb683487b70430f2ea423d2678d7f30d0c3079 0001-add-option-hls_init_time-
> to-set-init-hls-window-segm.patch
> > From dfadb857714867613afebe1a740a8e7fccaa5443 Mon Sep 17 00:00:00 2001
> > From: Steven Liu
> > Date: Sat, 27 Aug 2016 07:32:40 +0800
> > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
> segment
> > duration
> >
> > recover segments duration time by hls_time after init hls window.
> > This is reuqested by Ibrahim Tachijian
> >
> > Reviewed-by: Michael Niedermayer
> > Signed-off-by: LiuQi
> > ---
> > libavformat/hlsenc.c | 14 +-
> > 1 file changed, 13 inse
Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support
On 8/25/2016 7:56 PM, Oliver Collyer wrote: > Hi Timo > > Thankyou for the clarification. > > Attached are what should be the final versions of these patches then, with > the support for YUV420P10 (and related conversion code) now dropped. While testing these patches, I noticed that you now have to go through a lenghty registration and confirmation process(read: I wasn't able to get the Version 7 Header/SDK yet, waiting for manual approval of my Video SDK registration). I definitely hope the nvEncodeApi header is still MIT licensed, otherwise it would force me to reject these patches, or re-introduce the non-free flag for nvenc. Either way this is a horrible situation, as bumping the SDK requirement to version 7 forces every user to go through the same registration process. I'll push for another attempt of including the header in ffmpeg once I get it. Provided it is still MIT licensed. Until that is somehow sorted, I'll wait with merging these patches. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support
Hi Timo Well the copyright message at the top of nvEncodeAPI.h in the 7.0 SDK is identical to that for 6.0 so it looks ok in that respect. I agree it’s an inconvenience to have to register and wait for approval (although mine came immediately and automatically). Regards Oliver > On 27 Aug 2016, at 14:49, Timo Rothenpieler wrote: > > On 8/25/2016 7:56 PM, Oliver Collyer wrote: >> Hi Timo >> >> Thankyou for the clarification. >> >> Attached are what should be the final versions of these patches then, with >> the support for YUV420P10 (and related conversion code) now dropped. > > While testing these patches, I noticed that you now have to go through a > lenghty registration and confirmation process(read: I wasn't able to get > the Version 7 Header/SDK yet, waiting for manual approval of my Video > SDK registration). > > I definitely hope the nvEncodeApi header is still MIT licensed, > otherwise it would force me to reject these patches, or re-introduce the > non-free flag for nvenc. > > Either way this is a horrible situation, as bumping the SDK requirement > to version 7 forces every user to go through the same registration process. > I'll push for another attempt of including the header in ffmpeg once I > get it. Provided it is still MIT licensed. > > Until that is somehow sorted, I'll wait with merging these patches. > > ___ > 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] [GSoC] Motion Interpolation
On Thu, Aug 25, 2016 at 10:28 PM, Davinder Singh wrote: > On Thu, Aug 25, 2016 at 5:01 AM Andy Furniss wrote: > > > > > > > I am testing with a somewhat artificial sample in that it's a framerate > > de-interlace + scale down of a 1080i master, though it is "real" in the > > sense that I may want to repair similar files where people have produced > > a juddery mess by using yadif=0. > > > > thanks for testing. > > > > > It's very fast and my old (2010 Panasonic plasma) TV can't interpolate > > it without artifacting in a few places, it can interpolate a field rate > > version flawlessly and both mcfps and minterpolate do a lot better with > > a 50fps master version -> 100fps, though they are still not perfect. > > > > As well as being fast it has overlays of varying opacity and some > > repeating patterns just to make things even harder. > > > > Some observations while trying to get the best result - given the number > > of options only a small subset could be tested: > > > > aobmc vs ombc, vsbmc 0 or 1 = no real difference. > > > > now our main focus will be on "better" motion estimation that removes > artifacts in fast motion, rather than little tweaks like these. > > > > Any me method other than epzs had far too many artifacts to be used. > > > > Raising search_param to 48 or 64 or 128 just causes new artifacts. > > > > that hopefully could be fixed. working on it. > > > > > > Reducing mb_size causes new artifacts. > > > > yes for higher resolution. for very smaller, it could be essential. > > > > bilat vs bidir - similar but bilat has some artifacts on a still shot > > near the end of the defaults sample uploaded. bidir sometimes has green > > near the top of the screen. > > > > i see that green line in other samples too. investigating. > > > > > > There are of course many small artifacts, to be seen by slowmo/framestep > > for both minterpolate and mcfps. Viewing fullspeed mcfps artifacts less > > on the car when it touches the edges than minterpolate. Frame stepping > > shows mcfps doesn't blend/blur as much on really fast moving background > > as minterpolate does. > > > > Included in the link below (which is a tar to stop google drive making > > terrible low quality/fps previews) are the 25fps master file, mcfps > > interpolation to 50fps, minterpolate with default options and > > minterpolate with defaults + bidir. > > > > > > https://drive.google.com/file/d/0BxP5-S1t9VEEM2VrTzlVdGZURVk/view? > usp=sharing > > > thanks :) > > DSM_ > > what is the way to best contribute with test cases? I have two samples that I use for testing, so far the results look very, very promising but there are still a few artefact problems, so these could maybe serve as a good test case. In some cases the artefacts almost certainly look like there is a bug in motion vector calculation as a very large area suddenly begins to move in which really only a small part is/should be moving. How do I make this available to you or other devs at this stage? Just trac tickets or is it too early for that and you would like to work on this differently? After all it is always a grey area, when this can be considered solved, as it is a process of gradual improvements, so maybe it's not well-suited for a ticket. Let me know. Happy to contribute samples and some testing time here and there. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 8/27/2016 3:07 PM, Thomas Volkert wrote: > Hi, > > On 27.08.2016 14:58, Timo Rothenpieler wrote: >> As Nvidia has put the most recent Video Codec SDK behind a double >> registration wall, of which one needs manual approval of a lenghty >> application, bundling this header saves everyone trying to use NVENC >> from that headache. >> >> The header is still MIT licensed and thus fine to bundle with ffmpeg. >> >> Not bundling this header would get ffmpeg stuck at SDK v6, which is >> still freely available, holding back future development of the NVENC >> encoder. >> --- >> compat/nvenc/nvEncodeAPI.h | 3219 >> >> configure | 22 +- >> libavcodec/nvenc.h |2 +- >> 3 files changed, 3237 insertions(+), 6 deletions(-) >> create mode 100644 compat/nvenc/nvEncodeAPI.h >> > > But this approach assumes to have SDK version 7 in every case - > independent from the actually available revision at runtime? > Is it possible to check the actually available version during runtime? The header is all SDK the nvenc encoder needs, there is no runtime component except for the Nvidia driver. > > And I think there are some deprecated comments in nvenc.c: > - references to only H.264 (HEVC was already added) > - references to version 5 as "current SDK revision" There might be some outdated comments left over, but nothing that's a major documentation issue. Or do you have something specific in mind? > > Best regards, > Thomas. > signature.asc Description: OpenPGP digital signature ___ 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
On Fri, Aug 26, 2016 at 14:37:42 -0700, Brett Harrison wrote:
> +if (diff != 0) {
> + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> +}
If diff != 0, it can only be >0 or <0, nothing else:
if (diff != 0)
return diff > 0 ? 1 : -1;
(And you can drop the curly brackets.)
> +else {
> + int64_t diff = (int64_t)a->fontsize - (int64_t)bb->fontsize;
> + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> +}
There's a macro for this:
else
return FFDIFFSIGN((int64_t)a->fontsize, (int64_t)bb->fontsize);
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 27 August 2016 at 23:12, Timo Rothenpieler wrote: > On 8/27/2016 3:07 PM, Thomas Volkert wrote: > > Hi, > > > > On 27.08.2016 14:58, Timo Rothenpieler wrote: > >> As Nvidia has put the most recent Video Codec SDK behind a double > >> registration wall, of which one needs manual approval of a lenghty > >> application, bundling this header saves everyone trying to use NVENC > >> from that headache. > >> > >> The header is still MIT licensed and thus fine to bundle with ffmpeg. > >> > >> Not bundling this header would get ffmpeg stuck at SDK v6, which is > >> still freely available, holding back future development of the NVENC > >> encoder. > >> --- > >> compat/nvenc/nvEncodeAPI.h | 3219 ++ > ++ > >> configure | 22 +- > >> libavcodec/nvenc.h |2 +- > >> 3 files changed, 3237 insertions(+), 6 deletions(-) > >> create mode 100644 compat/nvenc/nvEncodeAPI.h > >> > > > > But this approach assumes to have SDK version 7 in every case - > > independent from the actually available revision at runtime? > > Is it possible to check the actually available version during runtime? > > The header is all SDK the nvenc encoder needs, there is no runtime > component except for the Nvidia driver. > > > > > And I think there are some deprecated comments in nvenc.c: > > - references to only H.264 (HEVC was already added) > > - references to version 5 as "current SDK revision" > > There might be some outdated comments left over, but nothing that's a > major documentation issue. > Or do you have something specific in mind? > > > > > Best regards, > > Thomas. > > With the new registration wall Im actually in favor of adding this to the repo as only the header is needed and the header can no longer be downloaded easily with build bots or similar which breaks online build/CI systems. Having this available in the repo would make things a lot easier for a lot of people. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
>> And I think there are some deprecated comments in nvenc.c: >> - references to only H.264 (HEVC was already added) >> - references to version 5 as "current SDK revision" > There are no references to version 5 of the SDK that I can see in nvenc.c following my patch. There was one next to where it set the encoding profile which said something like “SDK 5 only allows the Main profile” but I got rid of that when I placed the switch statement that sets the profile to Main or Main 10 according to the parameters supplied. Is that what you are referring to? Regarding the use of “H.264” do you mean the first line of the file where the comment says “H.264 hardware encoding using nvidia nvenc”? I agree this should be updated to read “H.264 and HEVC hardware encoding...” or something. Maybe next time ;o) Regards Oliver ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: fix a codecpar non use
On 8/27/2016 6:24 AM, Michael Niedermayer wrote: > On Fri, Aug 26, 2016 at 03:49:55PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavformat/utils.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM > > thx Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] add option hls_init_time to set init hls window segment
2016-08-27 19:15 GMT+08:00 Steven Liu :
>
>
> 2016-08-27 18:25 GMT+08:00 Michael Niedermayer :
>
>> On Sat, Aug 27, 2016 at 07:44:01AM +0800, Steven Liu wrote:
>> > 2016-08-27 4:49 GMT+08:00 Michael Niedermayer :
>> >
>> > > On Fri, Aug 26, 2016 at 05:30:41PM +0800, Steven Liu wrote:
>> > > > recover segments duration time by hls_time after init hls window.
>> > > > This is reuqested by Ibrahim Tachijian
>> > > >
>> > > > Signed-off-by: LiuQi
>> > > > ---
>> > > > libavformat/hlsenc.c | 14 +-
>> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
>> > > [...]
>> > > > hlsenc.c | 14 +-
>> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
>> > > > f38066079d46206d1bc970f026a7a9de25ace8d1
>> 0001-add-option-hls_init_time-
>> > > to-set-init-hls-window-segm.patch
>> > > > From 937e5301414f1c43c4c564ee59a4dfeee690293c Mon Sep 17 00:00:00
>> 2001
>> > > > From: Steven Liu
>> > > > Date: Fri, 26 Aug 2016 14:34:58 +0800
>> > > > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
>> > > segment
>> > > > duration
>> > > >
>> > > > And recover segments duration time by hls_time after init hls
>> window.
>> > > > This is reuqested by Ibrahim Tachijian
>> > > >
>> > > > Signed-off-by: LiuQi
>> > > > ---
>> > > > libavformat/hlsenc.c | 14 +-
>> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> > > > index e65f002..f5ceb60 100644
>> > > > --- a/libavformat/hlsenc.c
>> > > > +++ b/libavformat/hlsenc.c
>> > > > @@ -85,6 +85,7 @@ typedef struct HLSContext {
>> > > > AVFormatContext *vtt_avf;
>> > > >
>> > > > float time;// Set by a private option.
>> > > > +float init_time;// Set by a private option.
>> > > > int max_nb_segments; // Set by a private option.
>> > > > int wrap; // Set by a private option.
>> > >
>> > > the comment looks oddly aligned, it should be at the same horizontal
>> > > position as teh others
>> > >
>> > >
>> > > > uint32_t flags;// enum HLSFlags
>> > > > @@ -706,7 +707,7 @@ static int hls_write_header(AVFormatContext *s)
>> > > > int vtt_basename_size;
>> > > >
>> > > > hls->sequence = hls->start_sequence;
>> > > > -hls->recording_time = hls->time * AV_TIME_BASE;
>> > > > +hls->recording_time = (hls->init_time ? hls->init_time :
>> hls->time)
>> > > * AV_TIME_BASE;
>> > > > hls->start_pts = AV_NOPTS_VALUE;
>> > > >
>> > > > if (hls->format_options_str) {
>> > > > @@ -860,9 +861,19 @@ static int hls_write_packet(AVFormatContext
>> *s,
>> > > AVPacket *pkt)
>> > > > AVStream *st = s->streams[pkt->stream_index];
>> > > > int64_t end_pts = hls->recording_time * hls->number;
>> > > > int is_ref_pkt = 1;
>> > >
>> > > > +int init_list_dur = 0;
>> > > > +int after_init_list_dur = 0;
>> > >
>> > > the initialized value is not used
>> > > also the declaration can be moved into the if() below
>> > >
>> > > > int ret, can_split = 1;
>> > > > int stream_index = 0;
>> > > >
>> > > > +if (hls->sequence - hls->nb_entries > hls->start_sequence &&
>> > > hls->init_time > 0) {
>> > > > +/* reset end_pts, hls->recording_time at end of the init
>> hls
>> > > list */
>> > > > +init_list_dur = hls->init_time * hls->nb_entries *
>> AV_TIME_BASE;
>> > > > +after_init_list_dur = (hls->sequence - hls->nb_entries ) *
>> > > hls->time * AV_TIME_BASE;
>> > > > +hls->recording_time = hls->time * AV_TIME_BASE;
>> > > > +end_pts = init_list_dur + after_init_list_dur ;
>> > > > +}
>> > > > +
>> > > > if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE ) {
>> > > > oc = hls->vtt_avf;
>> > > > stream_index = 0;
>> > > > @@ -972,6 +983,7 @@ static int hls_write_trailer(struct
>> AVFormatContext
>> > > *s)
>> > > [...]
>> > >
>> > >
>> > > --
>> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
>> 87040B0FAB
>> > >
>> > > Let us carefully observe those good qualities wherein our enemies
>> excel us
>> > > and endeavor to excel them, by avoiding what is faulty, and imitating
>> what
>> > > is excellent in them. -- Plutarch
>> > >
>> > > ___
>> > > ffmpeg-devel mailing list
>> > > ffmpeg-devel@ffmpeg.org
>> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > >
>> > > Update patch
>>
>> > hlsenc.c | 14 +-
>> > 1 file changed, 13 insertions(+), 1 deletion(-)
>> > 2feb683487b70430f2ea423d2678d7f30d0c3079
>> 0001-add-option-hls_init_time-to-set-init-hls-window-segm.patch
>> > From dfadb857714867613afebe1a740a8e7fccaa5443 Mon Sep 17 00:00:00 2001
>> > From: Steven Liu
>> > Date: Sat, 27 Aug 2016 07:32:40 +0800
>> > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
>> segment
>> > duration
>> >
>> > recover segments duration time by hls_time after init hls window.
>> > This is
[FFmpeg-devel] [PATCH]lavf/httpauth: Do case-insensitive http header checks.
Hi!
Attached patch fixes ticket #5786.
Please comment, Carl Eugen
From 3b9380e0a4e715dcbc3ff508235ccad14a01ad37 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 27 Aug 2016 17:27:48 +0200
Subject: [PATCH] lavf/httpauth: Do case-insensitive http header checks.
Fixes ticket #5786.
---
libavformat/httpauth.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 18cf36b..2d42ab2 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -90,7 +90,7 @@ static void choose_qop(char *qop, int size)
void ff_http_auth_handle_header(HTTPAuthState *state, const char *key,
const char *value)
{
-if (!strcmp(key, "WWW-Authenticate") || !strcmp(key,
"Proxy-Authenticate")) {
+if (!av_strcasecmp(key, "WWW-Authenticate") || !av_strcasecmp(key,
"Proxy-Authenticate")) {
const char *p;
if (av_stristart(value, "Basic ", &p) &&
state->auth_type <= HTTP_AUTH_BASIC) {
@@ -112,7 +112,7 @@ void ff_http_auth_handle_header(HTTPAuthState *state, const
char *key,
if (!av_strcasecmp(state->digest_params.stale, "true"))
state->stale = 1;
}
-} else if (!strcmp(key, "Authentication-Info")) {
+} else if (!av_strcasecmp(key, "Authentication-Info")) {
ff_parse_key_value(value, (ff_parse_key_val_cb) handle_digest_update,
state);
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] examples/transcoding: convert to codecpar
Signed-off-by: James Almer
---
This example is kinda broken, before and after this patch. The files it
creates are not always correct, at least with video using the most common
containers.
If i were to guess, it's probably why ffmpeg.c has so many container and
codec specific workarounds beyond what the libraries themselves do.
doc/examples/transcoding.c | 94 --
1 file changed, 65 insertions(+), 29 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 8633362..5a648e4 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -45,6 +45,12 @@ typedef struct FilteringContext {
} FilteringContext;
static FilteringContext *filter_ctx;
+typedef struct StreamContext {
+AVCodecContext *dec_ctx;
+AVCodecContext *enc_ctx;
+} StreamContext;
+static StreamContext *stream_ctx;
+
static int open_input_file(const char *filename)
{
int ret;
@@ -61,22 +67,41 @@ static int open_input_file(const char *filename)
return ret;
}
+stream_ctx = av_mallocz_array(ifmt_ctx->nb_streams, sizeof(*stream_ctx));
+if (!stream_ctx)
+return AVERROR(ENOMEM);
+
for (i = 0; i < ifmt_ctx->nb_streams; i++) {
-AVStream *stream;
+AVStream *stream = ifmt_ctx->streams[i];
+AVCodec *dec = avcodec_find_decoder(stream->codecpar->codec_id);
AVCodecContext *codec_ctx;
-stream = ifmt_ctx->streams[i];
-codec_ctx = stream->codec;
+if (!dec) {
+av_log(NULL, AV_LOG_ERROR, "Failed to find decoder for stream
#%u\n", i);
+return AVERROR_DECODER_NOT_FOUND;
+}
+codec_ctx = avcodec_alloc_context3(dec);
+if (!codec_ctx) {
+av_log(NULL, AV_LOG_ERROR, "Failed to allocate the decoder context
for stream #%u\n", i);
+return AVERROR(ENOMEM);
+}
+if ((ret = avcodec_parameters_to_context(codec_ctx, stream->codecpar))
< 0) {
+av_log(NULL, AV_LOG_ERROR, "Failed to copy decoder parameters to
input decoder context "
+ "for stream #%u\n", i);
+return ret;
+}
/* Reencode video & audio and remux subtitles etc. */
if (codec_ctx->codec_type == AVMEDIA_TYPE_VIDEO
|| codec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
+if (codec_ctx->codec_type == AVMEDIA_TYPE_VIDEO)
+codec_ctx->framerate = av_guess_frame_rate(ifmt_ctx, stream,
NULL);
/* Open decoder */
-ret = avcodec_open2(codec_ctx,
-avcodec_find_decoder(codec_ctx->codec_id), NULL);
+ret = avcodec_open2(codec_ctx, dec, NULL);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Failed to open decoder for stream
#%u\n", i);
return ret;
}
}
+stream_ctx[i].dec_ctx = codec_ctx;
}
av_dump_format(ifmt_ctx, 0, filename, 0);
@@ -108,8 +133,7 @@ static int open_output_file(const char *filename)
}
in_stream = ifmt_ctx->streams[i];
-dec_ctx = in_stream->codec;
-enc_ctx = out_stream->codec;
+dec_ctx = stream_ctx[i].dec_ctx;
if (dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO
|| dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
@@ -119,6 +143,11 @@ static int open_output_file(const char *filename)
av_log(NULL, AV_LOG_FATAL, "Necessary encoder not found\n");
return AVERROR_INVALIDDATA;
}
+enc_ctx = avcodec_alloc_context3(encoder);
+if (!enc_ctx) {
+av_log(NULL, AV_LOG_FATAL, "Failed to allocate the encoder
context\n");
+return AVERROR(ENOMEM);
+}
/* In this example, we transcode to same properties (picture size,
* sample rate etc.). These properties can be changed for output
@@ -133,7 +162,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = dec_ctx->time_base;
+enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
enc_ctx->channel_layout = dec_ctx->channel_layout;
@@ -149,22 +178,28 @@ static int open_output_file(const char *filename)
av_log(NULL, AV_LOG_ERROR, "Cannot open video encoder for
stream #%u\n", i);
return ret;
}
+if ((ret = avcodec_parameters_from_context(out_stream->codecpar,
enc_ctx)) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Failed to copy encoder parameters
to output stream #%u\n", i);
+return ret;
+}
+if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
[FFmpeg-devel] [PATCH] avfilter nb_threads better control
Hi, patches attached. 0001-avfilter-add-nb_threads-to-AVFilterContext.patch Description: Binary data 0002-avfilter-add-ff_filter_get_nb_threads.patch Description: Binary data 0003-avfilter-make-use-of-ff_filter_get_nb_threads.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On Sat, Aug 27, 2016 at 02:58:53PM +0200, Timo Rothenpieler wrote: > As Nvidia has put the most recent Video Codec SDK behind a double > registration wall, of which one needs manual approval of a lenghty > application, bundling this header saves everyone trying to use NVENC > from that headache. > > The header is still MIT licensed and thus fine to bundle with ffmpeg. > > Not bundling this header would get ffmpeg stuck at SDK v6, which is > still freely available, holding back future development of the NVENC > encoder. > --- > compat/nvenc/nvEncodeAPI.h | 3219 > > configure | 22 +- > libavcodec/nvenc.h |2 +- > 3 files changed, 3237 insertions(+), 6 deletions(-) > create mode 100644 compat/nvenc/nvEncodeAPI.h fails fate-source --- ./tests/ref/fate/source 2016-08-27 02:28:45.044102422 +0200 +++ tests/data/fate/source 2016-08-27 22:55:02.881652505 +0200 @@ -26,3 +26,4 @@ compat/avisynth/windowsPorts/windows2linux.h compat/float/float.h compat/float/limits.h +compat/nvenc/nvEncodeAPI.h Test source failed. Look at tests/data/fate/source.err for details. make: *** [fate-source] Error 1 make: *** Waiting for unfinished jobs [...] -- 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] Possible long(er?) term support
On Saturday, 27 August 2016 at 12:48, Michael Niedermayer wrote: > On Fri, Aug 26, 2016 at 12:59:53PM -0600, Orion Poplawski wrote: > > On 08/25/2016 04:05 AM, Michael Niedermayer wrote: > > > On Wed, Aug 24, 2016 at 12:11:47PM -0600, Orion Poplawski wrote: > > >> On 08/24/2016 11:54 AM, Carl Eugen Hoyos wrote: > > >>> Hi! > > >>> > > >>> 2016-08-24 18:51 GMT+02:00 Orion Poplawski : > > Would the ffmpeg developers be willing treat any particular release > > as a > > long-term-support release and try to do security updates for it? > > >>> > > >>> Could you define "long-term"? > > >>> > > >>> Carl Eugen > > >> > > >> Well, EL7 itself will be around for a long time (till 2024), but we don't > > >> expect any open-source project to have support for that long. But > > >> something in > > >> the 2-3 year range would be very helpful. > > > > > > Calling one of our releases from time to time LTS certainly makes > > > sense from a marketing point of view ... > > > Doing that with a consistent shedule and clearly stated timeframe > > > also makes sense > > > Also synchronizing such shedule with distros and user applications > > > would make sense > > > > > > To support a release better, longer or with more clearly stated shedule > > > requires someone with the will and time to stand > > > behind it though. Is there someone this applies to ? > > > Do you know someone this applies to ? > > > > > > Thanks > > > > I'm not sure who the questions are addressed to. But in any case, it looks > > like rpmfusion will be shipping ffmpeg 2.8 in their epel7 release. So it > > would be helpful to try to support that for as long as it is reasonable. > > I'm > > sure everyone involved will try to help out where possible. Thanks. > > which other distros use 2.8 ? (that is distro releases which will not/ > cannot upgrade to 3.*) I can see 2.8.6 in Gentoo (marked as stable, with 3.x as testing). Debian has 0.8.17 in oldstable, 3.0.2 in backports and 3.1.2 in testing and unstable. Ubuntu has 2.7.6, 2.8.6 and 3.0.2. Arch has 0.10.16, 2.8.7 and 3.1.2. openSUSE has 2.8.6 and 3.1.2. RPMFusion (for Fedora) has 2.8.7, 3.0.2 and 3.1.2. So, it looks like 2.8.x is present in 5 out of 6 major distributions. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
On Fri, Aug 26, 2016 at 5:55 PM, Michael Niedermayer wrote: > On Fri, Aug 26, 2016 at 12:49:19PM -0700, Sasi Inguva wrote: > > I think there is some bug in mp3 decoder which is making skip > > samples -1431655766 for ~/tickets/5528/fire.mp3 . For now I have removed > > the assert from the 3rd commit. > > For the file one.mov , I think the audio has edit list with start time > > correspending to the second sample - (which should be media time 1024 if > I > > guess correctly). This indicates that the first sample be used for > encoder > > delay. > > Previously without edit list parsing , we used to offset the start_dts > by > > -1024 to make the second sample timestamp start from zero. > > sc->time_offset = start_time - empty_duration; > > -current_dts = -sc->time_offset; > > if (sc->ctts_count>0 && sc->stts_count>0 && > > > > But now edit list parsing handles the rebasing of timestamps to zero, > > because it will assign increasing timestamps starting from zero, to > > samples present in the edit list. > > > Because the first sample is not in the > > edit list, we mark it as DISCARD, which flag av_decode_audio4 will look > at > > and decode-and-discard that frame. So it wouldn't matter what the first > > sample timestamp should be assigned because it is anyway discarded after > > decode. > > current applications using libavformat have no knowledge of the > discard flag you can add the DISCARD flag, you can set it on packets but > applications written or built for libavformat 57 dont have to know > this flag and can treat the packets like any other packet. > Yes. they can treat the packet like any other packet. They don't have to know about the discard flag. Adding this feature without a major version bump requires things to > still work reasonable with the old semantics that apps are build > around. That should be possible unless iam missing something As I have pointed out earlier this code will change the timestamps of the packets. In the case of multiple edit lists, the code will also repeat some packets, and might make the timestamps non-monotonous. I don't know if the last behavior is not an acceptable expectation from av_read_frame. However as I've pointed out, we are already showing the wrong packets for videos with multiple edit lists by not parsing the edit lists currently, which will introduce AVSync issues. So this patch wont make things any worse for those cases in my view. I've tested remuxing (-c copy) the MOV files with edit lists to other containers. I see that ffmpeg actually modifies DTS to be monotonous in case of non monotonic DTS http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=bad311d57561e8ce2e790d733ae0fc81809ce585;hb=HEAD#l729 , so the remuxing operation never fails at least. > > > > > I am sure when you do ./ffprobe -show_frames -print_format compact > one.mov > > , you won't get the first audio sample at all and second audio sample > will > > start from zero timestamp. If I can get a link to the file, I can get a > > deeper look but I am almost sure that this is what is happening. > > heres a direct link > http://trac.ffmpeg.org/raw-attachment/ticket/5528/fire.mp3 > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is dangerous to be right in matters on which the established authorities > are wrong. -- Voltaire > > ___ > 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] added expr evaluation to drawtext - fontsize
Fixed patch based on comments.
This time attaching patch file.
On Sat, Aug 27, 2016 at 6:21 AM, Moritz Barsnick wrote:
> On Fri, Aug 26, 2016 at 14:37:42 -0700, Brett Harrison wrote:
>
> > +if (diff != 0) {
> > + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > +}
>
> If diff != 0, it can only be >0 or <0, nothing else:
>if (diff != 0)
> return diff > 0 ? 1 : -1;
> (And you can drop the curly brackets.)
>
> > +else {
> > + int64_t diff = (int64_t)a->fontsize - (int64_t)bb->fontsize;
> > + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > +}
>
> There's a macro for this:
>else
>return FFDIFFSIGN((int64_t)a->fontsize, (int64_t)bb->fontsize);
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
0001-added-expr-evaluation-to-drawtext-fontsize.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] [PATCH 2/2] mlpenc: Working MLP/TrueHD encoder
On Tue, Aug 23, 2016 at 02:33:00AM +0530, Jai Luthra wrote:
> * Multichannel support for TrueHD is experimental
>
> There should be downmix substreams present for 2+ channel bitstreams,
> but ffmpeg decoder doesn't need it. Will add support for this soon.
>
> * There might be lossless check failures on LFE channels
>
> * 32-bit sample support has been removed for now, will add it later
>
> While testing, some samples gave lossless check failures when enforcing
> s32. Probably this will also get solved with other lossless issues.
>
> Signed-off-by: Jai Luthra
> ---
> libavcodec/Makefile|2 +
> libavcodec/allcodecs.c |4 +-
> libavcodec/mlp.c | 21 +
> libavcodec/mlp.h | 40 +
> libavcodec/mlpenc.c| 2416
>
> 5 files changed, 2481 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/mlpenc.c
[...]
> +static av_cold int mlp_encode_init(AVCodecContext *avctx)
> +{
> +MLPEncodeContext *ctx = avctx->priv_data;
> +unsigned int substr, index;
> +unsigned int sum = 0;
> +unsigned int size;
> +
> +ctx->avctx = avctx;
> +
> +switch (avctx->sample_rate) {
> +case 44100 << 0:
> +avctx->frame_size = 40 << 0;
> +ctx->coded_sample_rate[0] = 0x08 + 0;
> +ctx->fs = 0x08 + 1;
> +break;
> +case 44100 << 1:
> +avctx->frame_size = 40 << 1;
> +ctx->coded_sample_rate[0] = 0x08 + 1;
> +ctx->fs = 0x0C + 1;
> +break;
> +case 44100 << 2:
> +ctx->substream_info |= SUBSTREAM_INFO_HIGH_RATE;
> +avctx->frame_size = 40 << 2;
> +ctx->coded_sample_rate[0] = 0x08 + 2;
> +ctx->fs = 0x10 + 1;
> +break;
> +case 48000 << 0:
> +avctx->frame_size = 40 << 0;
> +ctx->coded_sample_rate[0] = 0x00 + 0;
> +ctx->fs = 0x08 + 2;
> +break;
> +case 48000 << 1:
> +avctx->frame_size = 40 << 1;
> +ctx->coded_sample_rate[0] = 0x00 + 1;
> +ctx->fs = 0x0C + 2;
> +break;
> +case 48000 << 2:
> +ctx->substream_info |= SUBSTREAM_INFO_HIGH_RATE;
> +avctx->frame_size = 40 << 2;
> +ctx->coded_sample_rate[0] = 0x00 + 2;
> +ctx->fs = 0x10 + 2;
> +break;
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Unsupported sample rate %d. Supported "
> +"sample rates are 44100, 88200, 176400, 48000, "
> +"96000, and 192000.\n", avctx->sample_rate);
> +return -1;
> +}
> +ctx->coded_sample_rate[1] = -1 & 0xf;
> +
> +/* TODO Keep count of bitrate and calculate real value. */
> +ctx->coded_peak_bitrate = mlp_peak_bitrate(960, avctx->sample_rate);
> +
> +/* TODO support more channels. */
> +if (avctx->channels > 2) {
> +av_log(avctx, AV_LOG_WARNING,
> + "Only mono and stereo are supported at the moment.\n");
> +}
> +
> +ctx->substream_info |= SUBSTREAM_INFO_ALWAYS_SET;
> +if (avctx->channels <= 2) {
> +ctx->substream_info |= SUBSTREAM_INFO_MAX_2_CHAN;
> +}
> +
> +switch (avctx->sample_fmt) {
> +case AV_SAMPLE_FMT_S16:
> +ctx->coded_sample_fmt[0] = BITS_16;
> +ctx->wordlength = 16;
> +avctx->bits_per_raw_sample = 16;
> +break;
> +/* TODO 20 bits: */
> +case AV_SAMPLE_FMT_S32:
> +ctx->coded_sample_fmt[0] = BITS_24;
> +ctx->wordlength = 24;
> +avctx->bits_per_raw_sample = 24;
> +break;
> +default:
> +av_log(avctx, AV_LOG_ERROR, "Sample format not supported. "
> + "Only 16- and 24-bit samples are supported.\n");
> +return -1;
> +}
> +ctx->coded_sample_fmt[1] = -1 & 0xf;
> +
> +ctx->dts = -avctx->frame_size;
> +
> +ctx->num_channels = avctx->channels + 2; /* +2 noise channels */
> +ctx->one_sample_buffer_size = avctx->frame_size
> +* ctx->num_channels;
> +/* TODO Let user pass major header interval as parameter. */
> +ctx->max_restart_interval = MAJOR_HEADER_INTERVAL;
> +
> +ctx->max_codebook_search = 3;
> +ctx->min_restart_interval = MAJOR_HEADER_INTERVAL;
> +ctx->restart_intervals = ctx->max_restart_interval /
> ctx->min_restart_interval;
> +
> +/* TODO Let user pass parameters for LPC filter. */
> +
> +size = sizeof(int32_t) * avctx->frame_size * ctx->max_restart_interval;
> +
> +ctx->lpc_sample_buffer = av_malloc(size);
av_malloc_array()
> +if (!ctx->lpc_sample_buffer) {
> +av_log(avctx, AV_LOG_ERROR,
> + "Not enough memory for buffering samples.\n");
> +return -1;
AVERROR(ENOMEM)
> +}
> +
> +size = sizeof(int32_t)
> + * ctx->one_sample_buffer_size * ctx->max_r
Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support
On Sat, 27 Aug 2016 13:49:25 +0200 Timo Rothenpieler wrote: >I'll push for another attempt of including the header in ffmpeg including nvidia header in linux kernel was a no-go ? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On Sat, 27 Aug 2016 14:58:53 +0200 Timo Rothenpieler wrote: > As Nvidia has put the most recent Video Codec SDK behind a double > registration wall, of which one needs manual approval of a lenghty > application, bundling this header saves everyone trying to use NVENC > from that headache. > > The header is still MIT licensed and thus fine to bundle with ffmpeg. is ok with me. but i am not maintainer. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
