Re: [FFmpeg-devel] IRC meeting summary for Outeachy Fundraising (Item No.5)
Hi Ngassa, On Sun, Sep 13, 2015 at 10:33 PM, Ngassa Finjap wrote: > Hi Yayoi, > > Thank you for writing a summary of the IRC Meeting which took place > yesterday regarding the upcoming Outreachy program. Yaaay! ^_^ [ Sadness > levels drop. ] I am glad to hear that. > > IMHO, It's fine leaving discussions concerning Outreachy on this mailing > list since it also concerns development of FFmpeg. Please continue to keep > the community informed on upcoming Outreachy meetings on IRC as you've > always done. :) Not really... but I will definitely keep informing upcoming Outreachy things for the best of my knowledge! I think next stuff will be news update. (last years Outreachy summary etc..) > > Best of luck with Outreachy Organization. Thank you! -Yayoi > > Regards, > Ngassa Amalia. > > On Mon, Sep 14, 2015, 6:10 AM Yayoi Ukai wrote: > >> Hello everyone, >> >> Here is the meeting summary for yesterday meeting (Item No.5 about >> Outreachy). >> I also added possible future agenda. And please let me know if you >> have any questions. Also, I will probably start a separate mailing >> list for just regarding outreachy related issues, unless I should keep >> writing here. So please let me know if you want to subscribe or I >> should just keep writing it here. >> >> But in any cases, if you are very sad that you missed the meeting and >> especially about the discussion item No.5 of yesterday's meeting, >> Here is the summary. (So you know what happened in this topic at >> least! So don't be sad! Also, you can read the log as well) Please let >> me know that if you want to help, or you want to know what's going on >> more! >> >> Also, >> >> Meeting Summary: >> (Start of the summary) >> >> Action Items: >> >> 1. FFmpeg will participate Outreachy >> >> 2. FFmpeg has a money to support intern but prefer to raise funds >> >> 3. Micheal will be a mentor (tentative). Developers will discuss the >> idea of the project and will be determined. (possibly more mentor >> candidates and Mentors need to commit 5 hours a week during the >> internship period.) >> >> 4. Lou will review the email template that Yayoi wrote last week and will >> be >> decided on the final template >> >> 5. Yayoi will ask to Outreach Organizer about the deadline for the >> Ffmpeg participation >> >> 6. Yayoi will start emailing to companies once we are set on email template >> >> Other Topics: >> >> 1. Micheal and Stafano oversees Outreachy budget and continue to be so. >> >> 2. Yayoi's logistical question about fundraising will be answered >> separately >> >> (End of Summary) >> >> Future agenda (Suggestion): >> >> 1. Candidate recruiting >> >> 2. Mentor/Intern happiness >> >> Cheers, >> >> Yayoi >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting summary for Outeachy Fundraising (Item No.5)
I missed a very very important point from the summary I wrote. Action Item: Raynald: He will write a news entry about last Outreachy project. Also, thanking Samsung to fund at least two interns in the past rounds. THANK YOU SAMSUNG! I am terribly sorry for missing this!! I was super nervous on IRC meeting. Also, please let me know if I missed something else or any comments. Cheers, Yayoi On Sun, Sep 13, 2015 at 10:33 PM, Ngassa Finjap wrote: > Hi Yayoi, > > Thank you for writing a summary of the IRC Meeting which took place > yesterday regarding the upcoming Outreachy program. Yaaay! ^_^ [ Sadness > levels drop. ] > > IMHO, It's fine leaving discussions concerning Outreachy on this mailing > list since it also concerns development of FFmpeg. Please continue to keep > the community informed on upcoming Outreachy meetings on IRC as you've > always done. :) > > Best of luck with Outreachy Organization. > > Regards, > Ngassa Amalia. > > On Mon, Sep 14, 2015, 6:10 AM Yayoi Ukai wrote: > >> Hello everyone, >> >> Here is the meeting summary for yesterday meeting (Item No.5 about >> Outreachy). >> I also added possible future agenda. And please let me know if you >> have any questions. Also, I will probably start a separate mailing >> list for just regarding outreachy related issues, unless I should keep >> writing here. So please let me know if you want to subscribe or I >> should just keep writing it here. >> >> But in any cases, if you are very sad that you missed the meeting and >> especially about the discussion item No.5 of yesterday's meeting, >> Here is the summary. (So you know what happened in this topic at >> least! So don't be sad! Also, you can read the log as well) Please let >> me know that if you want to help, or you want to know what's going on >> more! >> >> Also, >> >> Meeting Summary: >> (Start of the summary) >> >> Action Items: >> >> 1. FFmpeg will participate Outreachy >> >> 2. FFmpeg has a money to support intern but prefer to raise funds >> >> 3. Micheal will be a mentor (tentative). Developers will discuss the >> idea of the project and will be determined. (possibly more mentor >> candidates and Mentors need to commit 5 hours a week during the >> internship period.) >> >> 4. Lou will review the email template that Yayoi wrote last week and will >> be >> decided on the final template >> >> 5. Yayoi will ask to Outreach Organizer about the deadline for the >> Ffmpeg participation >> >> 6. Yayoi will start emailing to companies once we are set on email template >> >> Other Topics: >> >> 1. Micheal and Stafano oversees Outreachy budget and continue to be so. >> >> 2. Yayoi's logistical question about fundraising will be answered >> separately >> >> (End of Summary) >> >> Future agenda (Suggestion): >> >> 1. Candidate recruiting >> >> 2. Mentor/Intern happiness >> >> Cheers, >> >> Yayoi >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] policy on "necro-bumping" patches
Hi all, What is ffmpeg's policy on "necro-bumping" old patches? Or more precisely, what is the policy of requesting a patch to be merged where all objections raised have been addressed via discussion/updated patches, and which have not been merged in over 2 weeks due to unknown reasons? In particular, there are 2 patchsets I would like to get merged: 1. This I consider an important patch, simply because it solves a trac ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964, which also contains links to the patches. A lot of discussion went on around it on the mailing lists, and it is supported strongly by Nicolas and me. Michael seemed initially hesitant but later became convinced of (at least one of the set's) utility, and one of the patches was applied. The only objection I recall was from Hendrik, which was addressed by Nicolas in a follow-up. 2. This I consider much more trivial, but in this case there are no remaining objections. However, I still consider it important enough for a request to re-examine, as I am doing here. The patchset is more recent, https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html and https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html. Regards, Ganesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] README.md: avoid Github pull requests
On Mon, Sep 14, 2015 at 5:26 PM, Lou Logan wrote: > Signed-off-by: Lou Logan > --- > README.md | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/README.md b/README.md > index 58e1eff..962cef3 100644 > --- a/README.md > +++ b/README.md > @@ -40,3 +40,9 @@ Coding examples are available in the **doc/examples** > directory. > > FFmpeg codebase is mainly LGPL-licensed with optional components licensed > under > GPL. Please refer to the LICENSE file for detailed information. > + > +## Contributing > + > +Patches should be submitted to the ffmpeg-devel mailing list using `git > format-patch` > +or `git send-email`. Github pull requests should be avoided because they are > not part > +of our review process. perhaps add after "...our review process" -> "...and will therefore not be acted upon." This makes it clearer that we do not entertain them, and is a "harder" stance as opposed to the "softer" "should be avoided". > -- > 2.5.0 > > ___ > 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] avfilter/vf_vidstabdetect: use the name 's' for the pointer to the private context
On Mon, Sep 7, 2015 at 10:10 AM, Ganesh Ajjanagadde
wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/vf_vidstabdetect.c | 60
> +-
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
> index d8f70f9..4742949 100644
> --- a/libavfilter/vf_vidstabdetect.c
> +++ b/libavfilter/vf_vidstabdetect.c
> @@ -62,21 +62,21 @@ AVFILTER_DEFINE_CLASS(vidstabdetect);
>
> static av_cold int init(AVFilterContext *ctx)
> {
> -StabData *sd = ctx->priv;
> +StabData *s = ctx->priv;
> ff_vs_init();
> -sd->class = &vidstabdetect_class;
> +s->class = &vidstabdetect_class;
> av_log(ctx, AV_LOG_VERBOSE, "vidstabdetect filter: init %s\n",
> LIBVIDSTAB_VERSION);
> return 0;
> }
>
> static av_cold void uninit(AVFilterContext *ctx)
> {
> -StabData *sd = ctx->priv;
> -VSMotionDetect *md = &(sd->md);
> +StabData *s = ctx->priv;
> +VSMotionDetect *md = &(s->md);
>
> -if (sd->f) {
> -fclose(sd->f);
> -sd->f = NULL;
> +if (s->f) {
> +fclose(s->f);
> +s->f = NULL;
> }
>
> vsMotionDetectionCleanup(md);
> @@ -102,9 +102,9 @@ static int query_formats(AVFilterContext *ctx)
> static int config_input(AVFilterLink *inlink)
> {
> AVFilterContext *ctx = inlink->dst;
> -StabData *sd = ctx->priv;
> +StabData *s = ctx->priv;
>
> -VSMotionDetect* md = &(sd->md);
> +VSMotionDetect* md = &(s->md);
> VSFrameInfo fi;
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
>
> @@ -125,30 +125,30 @@ static int config_input(AVFilterLink *inlink)
> }
>
> // set values that are not initialized by the options
> -sd->conf.algo = 1;
> -sd->conf.modName = "vidstabdetect";
> -if (vsMotionDetectInit(md, &sd->conf, &fi) != VS_OK) {
> +s->conf.algo = 1;
> +s->conf.modName = "vidstabdetect";
> +if (vsMotionDetectInit(md, &s->conf, &fi) != VS_OK) {
> av_log(ctx, AV_LOG_ERROR, "initialization of Motion Detection
> failed, please report a BUG");
> return AVERROR(EINVAL);
> }
>
> -vsMotionDetectGetConfig(&sd->conf, md);
> +vsMotionDetectGetConfig(&s->conf, md);
> av_log(ctx, AV_LOG_INFO, "Video stabilization settings (pass 1/2):\n");
> -av_log(ctx, AV_LOG_INFO, " shakiness = %d\n", sd->conf.shakiness);
> -av_log(ctx, AV_LOG_INFO, " accuracy = %d\n", sd->conf.accuracy);
> -av_log(ctx, AV_LOG_INFO, " stepsize = %d\n", sd->conf.stepSize);
> -av_log(ctx, AV_LOG_INFO, " mincontrast = %f\n",
> sd->conf.contrastThreshold);
> -av_log(ctx, AV_LOG_INFO, "tripod = %d\n",
> sd->conf.virtualTripod);
> -av_log(ctx, AV_LOG_INFO, " show = %d\n", sd->conf.show);
> -av_log(ctx, AV_LOG_INFO, "result = %s\n", sd->result);
> -
> -sd->f = fopen(sd->result, "w");
> -if (sd->f == NULL) {
> -av_log(ctx, AV_LOG_ERROR, "cannot open transform file %s\n",
> sd->result);
> +av_log(ctx, AV_LOG_INFO, " shakiness = %d\n", s->conf.shakiness);
> +av_log(ctx, AV_LOG_INFO, " accuracy = %d\n", s->conf.accuracy);
> +av_log(ctx, AV_LOG_INFO, " stepsize = %d\n", s->conf.stepSize);
> +av_log(ctx, AV_LOG_INFO, " mincontrast = %f\n",
> s->conf.contrastThreshold);
> +av_log(ctx, AV_LOG_INFO, "tripod = %d\n", s->conf.virtualTripod);
> +av_log(ctx, AV_LOG_INFO, " show = %d\n", s->conf.show);
> +av_log(ctx, AV_LOG_INFO, "result = %s\n", s->result);
> +
> +s->f = fopen(s->result, "w");
> +if (s->f == NULL) {
> +av_log(ctx, AV_LOG_ERROR, "cannot open transform file %s\n",
> s->result);
> return AVERROR(EINVAL);
> } else {
> -if (vsPrepareFile(md, sd->f) != VS_OK) {
> -av_log(ctx, AV_LOG_ERROR, "cannot write to transform file %s\n",
> sd->result);
> +if (vsPrepareFile(md, s->f) != VS_OK) {
> +av_log(ctx, AV_LOG_ERROR, "cannot write to transform file %s\n",
> s->result);
> return AVERROR(EINVAL);
> }
> }
> @@ -158,15 +158,15 @@ static int config_input(AVFilterLink *inlink)
> static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> {
> AVFilterContext *ctx = inlink->dst;
> -StabData *sd = ctx->priv;
> -VSMotionDetect *md = &(sd->md);
> +StabData *s = ctx->priv;
> +VSMotionDetect *md = &(s->md);
> LocalMotions localmotions;
>
> AVFilterLink *outlink = inlink->dst->outputs[0];
> VSFrame frame;
> int plane;
>
> -if (sd->conf.show > 0 && !av_frame_is_writable(in))
> +if (s->conf.show > 0 && !av_frame_is_writable(in))
> av_frame_make_writable(in);
>
> for (plane = 0; plane < md->fi.planes; plane++) {
> @@ -177,7 +177,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> av_log(ctx, AV_LOG_ERROR, "motion detection failed");
>
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
On 9/14/2015 7:49 PM, Carl Eugen Hoyos wrote: > But nobody wants to send a patch with an updated commit message afaict. How is that important? If you're talking about stating somewhere that we're dropping ABI compatibility then the correct place is changelog, RELEASE_NOTES and/or APIChanges, not a random commit message. This patch can go in as is, but it would be preferable if you just drop the incompatible abi check and simply make the fields 64bits. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Print large lists in more columns if the screen size allows
On Mon, Sep 14, 2015 at 7:46 PM, Timothy Gu wrote:
> ---
> configure | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index da18e70..3dfbb91 100755
> --- a/configure
> +++ b/configure
> @@ -425,7 +425,10 @@ if test -t 1 && which tput >/dev/null; then
> error_color=$(tput setaf 1)
> reset_color=$(tput sgr0)
> fi
> +# 72 used instead of 80 since that's the default of pr
> +ncols=$(tput cols)
> fi
> +: ${ncols:=72}
>
> log(){
> echo "$@" >> $logfile
> @@ -3042,7 +3045,8 @@ die_unknown(){
> }
>
> print_3_columns() {
> -cat | tr ' ' '\n' | sort | pr -r -3 -t
> +cols=$(expr $ncols / 24)
> +cat | tr ' ' '\n' | sort | pr -r "-$cols" -w $ncols -t
> }
Shouldn't this function be renamed, since it no longer necessarily
prints in 3 columns?
>
> show_list() {
> --
> 1.9.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: Print large lists in more columns if the screen size allows
---
configure | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index da18e70..3dfbb91 100755
--- a/configure
+++ b/configure
@@ -425,7 +425,10 @@ if test -t 1 && which tput >/dev/null; then
error_color=$(tput setaf 1)
reset_color=$(tput sgr0)
fi
+# 72 used instead of 80 since that's the default of pr
+ncols=$(tput cols)
fi
+: ${ncols:=72}
log(){
echo "$@" >> $logfile
@@ -3042,7 +3045,8 @@ die_unknown(){
}
print_3_columns() {
-cat | tr ' ' '\n' | sort | pr -r -3 -t
+cols=$(expr $ncols / 24)
+cat | tr ' ' '\n' | sort | pr -r "-$cols" -w $ncols -t
}
show_list() {
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
On Tue, Sep 15, 2015 at 12:49:31AM +0200, Carl Eugen Hoyos wrote:
> On Monday 14 September 2015 04:31:56 pm Michael Niedermayer wrote:
> > On Mon, Sep 14, 2015 at 01:16:34AM +0200, Carl Eugen Hoyos wrote:
> > > On Monday 14 September 2015 12:48:27 am Michael Niedermayer wrote:
> > > > the entries in avcodec_options are wrong
> > >
> > > New patch attached.
> >
> > [...]
> >
> > > diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> > > index d6a5c69..f92bc25 100644
> > > --- a/libavcodec/options_table.h
> > > +++ b/libavcodec/options_table.h
> > > @@ -42,8 +42,8 @@
> > > #define AV_CODEC_DEFAULT_BITRATE 200*1000
> > >
> > > static const AVOption avcodec_options[] = {
> > > -{"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT,
> > > {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E}, -{"ab", "set
> > > bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = 128*1000
> > > }, 0, INT_MAX, A|E}, +{"b", "set bitrate (in bits/s)", OFFSET(bit_rate),
> > > AV_OPT_TYPE_INT64, {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX,
> > > A|V|E}, +{"ab", "set bitrate (in bits/s)", OFFSET(bit_rate),
> > > AV_OPT_TYPE_INT64, {.i64 = 128*1000 }, 0, INT_MAX, A|E}, {"bt", "Set
> > > video bitrate tolerance (in bits/s). In 1-pass mode, bitrate tolerance
> > > specifies how far " "ratecontrol is willing to deviate from the target
> > > average bitrate value. This is not related " "to minimum/maximum bitrate.
> > > Lowering tolerance too much has an adverse effect on quality.",
> >
> > [...]
> >
> > > diff --git a/libavformat/rdt.c b/libavformat/rdt.c
> > > index 046d273..79c0314 100644
> > > --- a/libavformat/rdt.c
> > > +++ b/libavformat/rdt.c
> > > @@ -448,7 +448,7 @@ real_parse_asm_rule(AVStream *st, const char *p,
> > > const char *end) {
> > > do {
> > > /* can be either averagebandwidth= or AverageBandwidth= */
> > > -if (sscanf(p, " %*1[Aa]verage%*1[Bb]andwidth=%d",
> > > &st->codec->bit_rate) == 1) +if (sscanf(p, "
> > > %*1[Aa]verage%*1[Bb]andwidth=%"SCNd64, (int64_t *)&st->codec->bit_rate)
> > > == 1)
> >
> > if the type is not already int64 then this is broken
>
> New patch attached.
>
> > also noone objected to droping ABI compatibility either on the ML
> > nor on IRC when it was asked. Thus there is currently a unanimous
> > consent to droping it.
>
> But nobody wants to send a patch with an updated commit message afaict.
maybe we should hire a scribe
>
> > I dont understand why you modify this patch to support a case you
> > conset to be removed
>
> Because at some point our API should be stable again.
>
> > that said, the patches are fine, the bugs are just in cases that
> > the there exist unanimous consent that they should be dropped
>
> Second patch attached that fixes ticket #2089 for me.
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffprobe -debug 1: Output for FFV1 inconsistent
On 09/13/2015 11:48 PM, Michael Niedermayer wrote: >> - What is "keyframe"? > a random access point I'm not sure what your answer means. I understand that "A keyframe" is a random access point. The flag in ffprobe's output seems to always be "1". I thought it might be the same as "intra" in FFV1.3's ffprobe output, but it doesn't go to "0" when GOP>1. >> - FFV1.1 has "slices"? > one could argue that any codec without slices has 1 slice per frame True. I just found it a bit confusing to have "slices" mentioned in FFV1 < version 2. >> - "colorspace" only in FFV1.3 >> - "intra" only in FFV1.3 >> - "alpha" only in FFV1.3 >> - keyword "global:" only in FFV1.3 >> >> >> Why is that so? > The code parsing the headers differs and so does the debug printout > i think noone thought about / noticed these differences before Thanks for clearing that up. Regards, Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2
I wanted to check what happens if someone uses an invalid parameter combination: "-c:v ffv1 -level 1 -slices 2" I expected an error message about invalid slice number, but the code selected FFV1.2: "[ffv1 @ 0x391b060] Version 2 needed for requested features but version 2 is experimental and not enabled" Regards, Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFV1: version 0 vs 1?
On 09/14/2015 12:25 AM, Michael Niedermayer wrote: > the encoder chooses the lowest version that supports the requested > features well to maximize compatibility Thanks for the explanation. Sounds reasonable. If I read [1] correcly, FFV1.0 does not store "bits_per_raw_sample". I'd be interested in any downsides FFV1.0 would have over FFV1.1? Thanks, Pb == References: [1] http://ffmpeg.org/~michael/ffv1.html#toc-Subsubsection-4.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
On Monday 14 September 2015 04:31:56 pm Michael Niedermayer wrote:
> On Mon, Sep 14, 2015 at 01:16:34AM +0200, Carl Eugen Hoyos wrote:
> > On Monday 14 September 2015 12:48:27 am Michael Niedermayer wrote:
> > > the entries in avcodec_options are wrong
> >
> > New patch attached.
>
> [...]
>
> > diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> > index d6a5c69..f92bc25 100644
> > --- a/libavcodec/options_table.h
> > +++ b/libavcodec/options_table.h
> > @@ -42,8 +42,8 @@
> > #define AV_CODEC_DEFAULT_BITRATE 200*1000
> >
> > static const AVOption avcodec_options[] = {
> > -{"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT,
> > {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E}, -{"ab", "set
> > bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = 128*1000
> > }, 0, INT_MAX, A|E}, +{"b", "set bitrate (in bits/s)", OFFSET(bit_rate),
> > AV_OPT_TYPE_INT64, {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX,
> > A|V|E}, +{"ab", "set bitrate (in bits/s)", OFFSET(bit_rate),
> > AV_OPT_TYPE_INT64, {.i64 = 128*1000 }, 0, INT_MAX, A|E}, {"bt", "Set
> > video bitrate tolerance (in bits/s). In 1-pass mode, bitrate tolerance
> > specifies how far " "ratecontrol is willing to deviate from the target
> > average bitrate value. This is not related " "to minimum/maximum bitrate.
> > Lowering tolerance too much has an adverse effect on quality.",
>
> [...]
>
> > diff --git a/libavformat/rdt.c b/libavformat/rdt.c
> > index 046d273..79c0314 100644
> > --- a/libavformat/rdt.c
> > +++ b/libavformat/rdt.c
> > @@ -448,7 +448,7 @@ real_parse_asm_rule(AVStream *st, const char *p,
> > const char *end) {
> > do {
> > /* can be either averagebandwidth= or AverageBandwidth= */
> > -if (sscanf(p, " %*1[Aa]verage%*1[Bb]andwidth=%d",
> > &st->codec->bit_rate) == 1) +if (sscanf(p, "
> > %*1[Aa]verage%*1[Bb]andwidth=%"SCNd64, (int64_t *)&st->codec->bit_rate)
> > == 1)
>
> if the type is not already int64 then this is broken
New patch attached.
> also noone objected to droping ABI compatibility either on the ML
> nor on IRC when it was asked. Thus there is currently a unanimous
> consent to droping it.
But nobody wants to send a patch with an updated commit message afaict.
> I dont understand why you modify this patch to support a case you
> conset to be removed
Because at some point our API should be stable again.
> that said, the patches are fine, the bugs are just in cases that
> the there exist unanimous consent that they should be dropped
Second patch attached that fixes ticket #2089 for me.
Carl Eugen
diff --git a/doc/APIchanges b/doc/APIchanges
index 958035c..e5cd3e4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
API changes, most recent first:
+2015-09-15 - lavc 57.2.100 - avcodec.h
+ bit_rate/rc_max_rate/rc_min_rate were changed to 64bit, make sure you update
+ any printf() or other type sensitive code
+
2015-xx-xx - lavu 55.0.100 / lavu 55.0.0
xxx - Change type of AVPixFmtDescriptor.flags from uint8_t to uint64_t.
xxx - Change type of AVComponentDescriptor fields from uint16_t to int
diff --git a/ffserver.c b/ffserver.c
index 73ede87..f9e40b5 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -1787,9 +1787,9 @@ static inline void print_stream_params(AVIOContext *pb,
FFServerStream *stream)
abort();
}
-avio_printf(pb, "%d%s%d"
+avio_printf(pb, "%d%s%"PRId64
"%s%s\n",
-i, type, st->codec->bit_rate/1000,
+i, type, (int64_t)st->codec->bit_rate/1000,
codec ? codec->name : "", parameters);
}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 6e3edaa..aac5198 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1532,7 +1532,11 @@ typedef struct AVCodecContext {
* - decoding: Set by user, may be overwritten by libavcodec
* if this info is available in the stream
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int bit_rate;
+#else
+int64_t bit_rate;
+#endif
/**
* number of bits the bitstream is allowed to diverge from the reference.
@@ -2463,14 +2467,22 @@ typedef struct AVCodecContext {
* - encoding: Set by user.
* - decoding: Set by user, may be overwritten by libavcodec.
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int rc_max_rate;
+#else
+int64_t rc_max_rate;
+#endif
/**
* minimum bitrate
* - encoding: Set by user.
* - decoding: unused
*/
+#if AV_HAVE_INCOMPATIBLE_LIBAV_ABI
int rc_min_rate;
+#else
+int64_t rc_min_rate;
+#endif
#if FF_API_MPV_OPT
/**
diff --git a/libavcodec/cook.c b/libavcodec/cook.c
index 673896d..d8fb736 100644
--- a/libavcodec/cook.c
+++ b/libavcodec/cook.c
@@ -1028,7 +1028,7 @@ static void dump_cook_context(COOKContext *q)
}
ff_dlog(q->avctx, "COOKContext\n");
PRINT("nb_channels", q->avct
Re: [FFmpeg-devel] [PATCH] README.md: avoid Github pull requests
On Mon, Sep 14, 2015 at 01:26:34PM -0800, Lou Logan wrote: > Signed-off-by: Lou Logan > --- > README.md | 6 ++ > 1 file changed, 6 insertions(+) LGTM 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] [PATCH 1/6] lavc/ass_split: Fix parser bugs
On Thu, Sep 10, 2015 at 11:12:14AM -0500, Rodger Combs wrote: > Specifically: > - Skip writing drawings as text > - Parse \h correctly > - Handle comments and unknown tags correctly > --- do you have a testcase for these ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add unit tests for v210enc
On 9/5/2015 8:13 PM, Henrik Gramner wrote: > --- > libavcodec/v210enc.c | 15 +--- > libavcodec/v210enc.h | 2 + > tests/checkasm/Makefile | 1 + > tests/checkasm/checkasm.c | 3 ++ > tests/checkasm/checkasm.h | 1 + > tests/checkasm/v210enc.c | 94 > +++ > 6 files changed, 111 insertions(+), 5 deletions(-) > create mode 100644 tests/checkasm/v210enc.c gcc asan complains about this change. http://fate.ffmpeg.org/report.cgi?time=20150914152533&slot=x86_64-archlinux-gcc-asan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/6] lavu/avstring: switch AV_ESCAPE_FLAGs to shift-based formatting
On Thu, Sep 10, 2015 at 11:12:15AM -0500, Rodger Combs wrote: > --- > libavutil/avstring.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] README.md: avoid Github pull requests
Signed-off-by: Lou Logan --- README.md | 6 ++ 1 file changed, 6 insertions(+) diff --git a/README.md b/README.md index 58e1eff..962cef3 100644 --- a/README.md +++ b/README.md @@ -40,3 +40,9 @@ Coding examples are available in the **doc/examples** directory. FFmpeg codebase is mainly LGPL-licensed with optional components licensed under GPL. Please refer to the LICENSE file for detailed information. + +## Contributing + +Patches should be submitted to the ffmpeg-devel mailing list using `git format-patch` +or `git send-email`. Github pull requests should be avoided because they are not part +of our review process. -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: switch min_tile_cols location so it shifts up instead of down.
This fixes cases where the shifted number is 64, but we shifted non- zero numbers away in the shift. The change makes behaviour consistent with libvpx. --- libavcodec/vp9.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c index a357a5f..f1183e8 100644 --- a/libavcodec/vp9.c +++ b/libavcodec/vp9.c @@ -823,7 +823,7 @@ static int decode_frame_header(AVCodecContext *ctx, return res; } for (s->tiling.log2_tile_cols = 0; - (s->sb_cols >> s->tiling.log2_tile_cols) > 64; + s->sb_cols > (64 << s->tiling.log2_tile_cols); s->tiling.log2_tile_cols++) ; for (max = 0; (s->sb_cols >> max) >= 4; max++) ; max = FFMAX(0, max - 1); -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] rtpdec: add a trace when jitter buffer is full
This commit adds an error trace when jitter buffer is full. It helps to understand leading decoding issues. Signed-off-by: Eloi BAIL --- libavformat/rtpdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c index fee9547..225b77e 100644 --- a/libavformat/rtpdec.c +++ b/libavformat/rtpdec.c @@ -710,6 +710,9 @@ static void enqueue_packet(RTPDemuxContext *s, uint8_t *buf, int len) packet->next = *cur; *cur = packet; s->queue_len++; +if (s->queue_len >= s->queue_size) +av_log(s->st ? s->st->codec : NULL, AV_LOG_ERROR, +"jitter buffer full\n"); } static int has_next_packet(RTPDemuxContext *s) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] rtpdec: inform jitter buffer size
This commit print as AV_LOG_INFO the jitter buffer
size. It might be the default value or the value set by application.
Signed-off-by: Eloi BAIL
---
libavformat/rtpdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 225b77e..de01403 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -520,6 +520,10 @@ RTPDemuxContext *ff_rtp_parse_open(AVFormatContext *s1,
AVStream *st,
s->ic = s1;
s->st = st;
s->queue_size = queue_size;
+
+av_log(s->st ? s->st->codec : NULL, AV_LOG_INFO,
+"setting jitter buffer size to %d\n", s->queue_size);
+
rtp_init_statistics(&s->statistics, 0);
if (st) {
switch (st->codec->codec_id) {
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] rtpdec: add traces about RTP jitter buffer
This patchset adds information about jitter buffer used in rtpdec. The first patch prints as error when jitter buffer is full. The second patch prints as information jitter buffer size set by default in ffmpeg headers or by application. Both traces are helpful to know the origin of decoding issues. Indeed a jitter buffer full will lead to packet reordering failure and then to video decoding failure. Eloi BAIL (2): rtpdec: add a trace when jitter buffer is full rtpdec: inform jitter buffer size libavformat/rtpdec.c | 7 +++ 1 file changed, 7 insertions(+) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Voting committee
L'octidi 28 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit : > Looks mostly good to me. One thing I think that should be clarified is > the meaning of "linear combination" - I assume you meant a non-trivial > (exclude all zeros) linear combination over the nonnegative integers? Thanks. You are right, this was imprecise. I meant linear combination with total coefficients one; barycenter in other words. For example: 10 commits are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too. Of course, the value I have put are rather arbitrary. Please people feel free to propose other values. 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] Voting committee
On Mon, Sep 14, 2015 at 11:53 AM, Nicolas George wrote: > L'octidi 28 fructidor, an CCXXIII, Nicolas George a écrit : >> I have been thinking of a practical proposal myself, I will word it and post >> it shortly. > > Here it is. Please comment. Looks mostly good to me. One thing I think that should be clarified is the meaning of "linear combination" - I assume you meant a non-trivial (exclude all zeros) linear combination over the nonnegative integers? As you rightly point out; any criterion can be gamed. However, I still think it is important to be precise about the criterion. > >> I strongly think that we will able to reach unanimous consensus about the >> members of the second stage list, and clear consensus about the decision >> rules. If that happens, there is no doubt this is legitimate. > > Better comparison: bootstraping a compiler rather than an OS. Unanimous > consensus on the list of current developers is like reaching the fixed point > where the compiler can compile itself into the exact same binary. > > I really think we can achieve it. We just need to keep minor personal > dislikes for ourselves. Maybe I think that Someone is a complete idiot, but > if the other developers that I trust and respect do not think so, I should > shut up for the sake of unity; after all, it's just one person, it will not > derail the project. Just to add to this: I think it is important for all of us to remember that almost everyone here wants to improve something/get something fixed, and AFAIK we don't have trolls who would derail the project. Sure; some methods of achieving the respective goals might be bad, but there could be a variety of benign reasons for this such as ignorance of some finer aspects. > > 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] Voting committee
L'octidi 28 fructidor, an CCXXIII, Nicolas George a écrit : > I have been thinking of a practical proposal myself, I will word it and post > it shortly. Here it is. Please comment. > I strongly think that we will able to reach unanimous consensus about the > members of the second stage list, and clear consensus about the decision > rules. If that happens, there is no doubt this is legitimate. Better comparison: bootstraping a compiler rather than an OS. Unanimous consensus on the list of current developers is like reaching the fixed point where the compiler can compile itself into the exact same binary. I really think we can achieve it. We just need to keep minor personal dislikes for ourselves. Maybe I think that Someone is a complete idiot, but if the other developers that I trust and respect do not think so, I should shut up for the sake of unity; after all, it's just one person, it will not derail the project. Regards, -- Nicolas George Important decisions about FFmpeg are made following a due process ensuring fairness and legitimacy. These decisions are hereafter called Decisions with a capital. Principles and college of Decision makers = The Decisions are made by the current Active FFmpeg Developers, preferably unanimously after discussion, or at least with a clear majority, but if all that fails with a simple majority. The Decisions and decision process are public, on the mailing list. [ NdCigaes: I do not think that we need special cases, like 2/3 majority. ] The list of current FFmpeg Developers is maintained on the website under version control; it is not always updated for active/inactive status. The initial list of FFmpeg developers has been decided by unanimous consensus on the public mailing list. [ NdC: I expect some people will think "$person is a fraud, he/she should not be in the list", but I hope that they will realize that having them on the list is not a severe problem and, for the good of the project ambiance, keep their opinion for themselves. ] The present decision process was approved the same way and can be updated by later Decisions. It is kept under revision control too. New FFmpeg developers can be added to the list by a Decision of the current developers, ideally by unanimous consensus. [ NdC: if someone thinks "$person is a fraud", it is better they keep it to themselves, but if a lot of persons think so, then maybe $person should not be considered a FFmpeg developer. For that reason, the best course of action is probably to discuss the addition in private first, and propose it publicly only when it has become obvious that the Decision will pass and those against will shut up. I do not know if it must be made a rule or not. ] A Decision can also remove a member from the list, but we hope it will never need to happen. A FFmpeg Developer is considered Active if he or she has at least 10 commits, 20 messages on the devel mailing list or 40 answers on the users mailing lists, or any linear combination of this, in the last 365 days, and inactive otherwise. If a developer rises above the activity threshold after less than 365 days inactivity, he or she is automatically reinstated; after that delay, he or she is by right removed from the list, but can of course ask to be reinstated through a Decision like anybody else. The Active/inactive status is considered at the exact time where the call for a Decision is posted on the mailing list. [ NdC: this criterion can easily be gamed, but I do not think it matters. Also, I do not know how to count IRC or Trac; are there people who are only active there and should be considered Active Developers? ] Decision process Decisions are made by calling for a consultation on the devel mailing list. Calls for a Decision must include the "[DECISION]" tag in their subject. People answering to the call on the mailing list should try to remember to remove the tag. A mail thread, as defined by the References and In-Reply-To headers, can contain only one call for Decision at most. If a new related one must be posted, it needs to be in a new thread. [ NdC: rationale: avoid developers missing calls amongst an unrelated subthread with the tag. ] Calls for decisions should include a deadline, by default and at least 7 days starting from the arrival of the call on the mailing list archive. The deadline can be selected longer if circumstances suggest it (holidays, important developer known to be temporarily unreachable, etc.). Calls for Decisions can be either by clear consensus or formal vote. The person calling for a Decision is responsible for summarising the outcome. Several calls for Decisions can be bundled together if they are related. The call must be worded very clearly, and the replies as well. Clear consensus --- Clear consensus can happen when the issue has already been discussed and a choice seems to be accepted by most people. The call must include t
Re: [FFmpeg-devel] [PATCH] mpjpeg: trim header name/value of MIME headers while probing
On Mon, Sep 14, 2015 at 05:34:27PM +0200, Michael Niedermayer wrote: > On Mon, Sep 14, 2015 at 05:27:01PM +0200, Michael Niedermayer wrote: > > On Sat, Sep 12, 2015 at 07:07:53PM -0400, Alex Agranovsky wrote: > > > Attached. > > > > > > -- > > > Alex Agranovsky > > > Sighthound, Inc > > > www.sighthound.com > > > > > > On September 12, 2015 at 5:41:56 PM, Michael Niedermayer > > > (michae...@gmx.at) wrote: > > > > > > On Sat, Sep 12, 2015 at 05:10:06PM -0400, Alex Agranovsky wrote: > > > > libavformat/mpjpegdec.c | 15 +++ > > > > 1 file changed, 15 insertions(+) > > > > > > patching file libavformat/mpjpegdec.c > > > patch: malformed patch at line 6: return 0; > > > > > > it seems the patches have been corrupted somewhere in the mail > > > processing, can you send the as attachment ? > > > > > > [...] > > > -- > > > 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 > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > mpjpegdec.c | 15 +++ > > > 1 file changed, 15 insertions(+) > > > e73ea2692f818d5c79d336a0eeb7027957af8f62 patch3.diff > > > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c > > > > applied > > from IRC: > michaelni: please tell the guy to fix his style next time > he's making a mess out of the file > (mjpegdec) also: wellitslackingsomelittlespaceabit [...] -- 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] mpjpeg: trim header name/value of MIME headers while probing
On Mon, Sep 14, 2015 at 05:27:01PM +0200, Michael Niedermayer wrote: > On Sat, Sep 12, 2015 at 07:07:53PM -0400, Alex Agranovsky wrote: > > Attached. > > > > -- > > Alex Agranovsky > > Sighthound, Inc > > www.sighthound.com > > > > On September 12, 2015 at 5:41:56 PM, Michael Niedermayer (michae...@gmx.at) > > wrote: > > > > On Sat, Sep 12, 2015 at 05:10:06PM -0400, Alex Agranovsky wrote: > > > libavformat/mpjpegdec.c | 15 +++ > > > 1 file changed, 15 insertions(+) > > > > patching file libavformat/mpjpegdec.c > > patch: malformed patch at line 6: return 0; > > > > it seems the patches have been corrupted somewhere in the mail > > processing, can you send the as attachment ? > > > > [...] > > -- > > 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 > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > mpjpegdec.c | 15 +++ > > 1 file changed, 15 insertions(+) > > e73ea2692f818d5c79d336a0eeb7027957af8f62 patch3.diff > > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c > > applied from IRC: michaelni: please tell the guy to fix his style next time he's making a mess out of the file (mjpegdec) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: trim header name/value of MIME headers while probing
On Sat, Sep 12, 2015 at 07:07:53PM -0400, Alex Agranovsky wrote: > Attached. > > -- > Alex Agranovsky > Sighthound, Inc > www.sighthound.com > > On September 12, 2015 at 5:41:56 PM, Michael Niedermayer (michae...@gmx.at) > wrote: > > On Sat, Sep 12, 2015 at 05:10:06PM -0400, Alex Agranovsky wrote: > > libavformat/mpjpegdec.c | 15 +++ > > 1 file changed, 15 insertions(+) > > patching file libavformat/mpjpegdec.c > patch: malformed patch at line 6: return 0; > > it seems the patches have been corrupted somewhere in the mail > processing, can you send the as attachment ? > > [...] > -- > 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 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > mpjpegdec.c | 15 +++ > 1 file changed, 15 insertions(+) > e73ea2692f818d5c79d336a0eeb7027957af8f62 patch3.diff > diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: probe should require same constraints as packet reader - both proper content-type and content-size must be present
On Mon, Sep 14, 2015 at 05:00:54PM +0200, Michael Niedermayer wrote: > On Sun, Sep 13, 2015 at 05:09:50PM -0400, Alex Agranovsky wrote: > > A slightly improved version … > > > > > > On September 13, 2015 at 4:56:21 PM, Alex Agranovsky (a...@sighthound.com) > > wrote: > > > > > > > mpjpegdec.c | 32 +--- > > 1 file changed, 13 insertions(+), 19 deletions(-) > > 13abef8e7d1127eda0247b285f75b5ffd1037a57 > > 0001-mpjpeg-probe-should-require-same-constraints-as-pack.patch > > From 7772bd91987c224640e74e9e93b372af7dddeb89 Mon Sep 17 00:00:00 2001 > > From: Alex Agranovsky > > Date: Sun, 13 Sep 2015 16:47:54 -0400 > > Subject: [PATCH] mpjpeg: probe should require same constraints as packet > > reader - both proper content-type and content-size must be present > > > > mpjpeg: probe should require same constraints as packet reader - both > > proper content-type and content-size must be present (return > > AVPROBE_SCORE_MAX, rather than random positive number on success) > > applied + with some changes and simplifications [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpjpeg: probe should require same constraints as packet reader - both proper content-type and content-size must be present
On Sun, Sep 13, 2015 at 05:09:50PM -0400, Alex Agranovsky wrote: > A slightly improved version … > > > On September 13, 2015 at 4:56:21 PM, Alex Agranovsky (a...@sighthound.com) > wrote: > > > mpjpegdec.c | 32 +--- > 1 file changed, 13 insertions(+), 19 deletions(-) > 13abef8e7d1127eda0247b285f75b5ffd1037a57 > 0001-mpjpeg-probe-should-require-same-constraints-as-pack.patch > From 7772bd91987c224640e74e9e93b372af7dddeb89 Mon Sep 17 00:00:00 2001 > From: Alex Agranovsky > Date: Sun, 13 Sep 2015 16:47:54 -0400 > Subject: [PATCH] mpjpeg: probe should require same constraints as packet > reader - both proper content-type and content-size must be present > > mpjpeg: probe should require same constraints as packet reader - both proper > content-type and content-size must be present (return AVPROBE_SCORE_MAX, > rather than random positive number on success) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Switch bitrate to 64bit with the bump
On Mon, Sep 14, 2015 at 01:16:34AM +0200, Carl Eugen Hoyos wrote:
> On Monday 14 September 2015 12:48:27 am Michael Niedermayer wrote:
> > the entries in avcodec_options are wrong
>
> New patch attached.
[...]
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index d6a5c69..f92bc25 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -42,8 +42,8 @@
> #define AV_CODEC_DEFAULT_BITRATE 200*1000
>
> static const AVOption avcodec_options[] = {
> -{"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 =
> AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E},
> -{"ab", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 =
> 128*1000 }, 0, INT_MAX, A|E},
> +{"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT64, {.i64
> = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E},
> +{"ab", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT64, {.i64
> = 128*1000 }, 0, INT_MAX, A|E},
> {"bt", "Set video bitrate tolerance (in bits/s). In 1-pass mode, bitrate
> tolerance specifies how far "
> "ratecontrol is willing to deviate from the target average bitrate
> value. This is not related "
> "to minimum/maximum bitrate. Lowering tolerance too much has an
> adverse effect on quality.",
[...]
> diff --git a/libavformat/rdt.c b/libavformat/rdt.c
> index 046d273..79c0314 100644
> --- a/libavformat/rdt.c
> +++ b/libavformat/rdt.c
> @@ -448,7 +448,7 @@ real_parse_asm_rule(AVStream *st, const char *p, const
> char *end)
> {
> do {
> /* can be either averagebandwidth= or AverageBandwidth= */
> -if (sscanf(p, " %*1[Aa]verage%*1[Bb]andwidth=%d",
> &st->codec->bit_rate) == 1)
> +if (sscanf(p, " %*1[Aa]verage%*1[Bb]andwidth=%"SCNd64, (int64_t
> *)&st->codec->bit_rate) == 1)
if the type is not already int64 then this is broken
also noone objected to droping ABI compatibility either on the ML
nor on IRC when it was asked. Thus there is currently a unanimous
consent to droping it.
I dont understand why you modify this patch to support a case you
conset to be removed
that said, the patches are fine, the bugs are just in cases that
the there exist unanimous consent that they should be dropped
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips/aaccoder_mips: Sync with generic aaccoder file.
On Fri, Sep 11, 2015 at 03:16:16PM +0200, Nedeljko Babic wrote: > Code in aaccoder_mips.c was not synced with changes in aaccoder.c for > some time. > > That was cause for some fate-aac tests failing. > > This patch fixes the problems. > > Optimizations disabled in 933309a are enabled again. > > Signed-off-by: Nedeljko Babic > --- > libavcodec/mips/aaccoder_mips.c | 89 > ++--- > 1 file changed, 48 insertions(+), 41 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Optimize nvenc parameters, add 3 more presets: fast, medium, slow
Yes you're right, another typo. Fix by attached patch (Based on Timo's branch, others seem fine to me). Agatha Hu Applied and merged, thanks. Timo signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avformat: access AVFormatContext.filename[] filed via getter/setter.
2015-09-14 18:54 GMT+08:00 Nicolas George : > L'octidi 28 fructidor, an CCXXIII, Zhang Rui a écrit : >> I'd like to know if this API-change could happen, since it will break >> many things. > > It depends on the decision about ABI compatibility, that itself depends on > the decision about the decision process. > > Assuming we will stop ABI compatibility, I am rather for replacing the fixed > buffer by a mallocated one with a setter function. OTOH, I am not very fond > of a getter. Getter or not getter is not a matter to me, just need a convention to follow. :) BTW: This patch is not intented to be merged, At least, not before the decision being made. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: draw text optionally
Hi,
On Tue, Sep 1, 2015 at 8:33 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/avf_showcqt.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index 85f9ea9..a70c4b0 100644
> --- a/libavfilter/avf_showcqt.c
> +++ b/libavfilter/avf_showcqt.c
> @@ -93,6 +93,7 @@ typedef struct {
> float gamma2; /* gamma of bargraph */
> int fps;/* the required fps is so strict, so it's enough
> to be int, but 24000/1001 etc cannot be encoded */
> int count; /* fps * count = transform rate */
> +int draw_text;
> } ShowCQTContext;
>
> #define OFFSET(x) offsetof(ShowCQTContext, x)
> @@ -110,6 +111,7 @@ static const AVOption showcqt_options[] = {
> { "count", "set number of transform per frame", OFFSET(count),
> AV_OPT_TYPE_INT, { .i64 = 6 }, 1, 30, FLAGS },
> { "fontfile", "set font file", OFFSET(fontfile), AV_OPT_TYPE_STRING,
> { .str = NULL }, CHAR_MIN, CHAR_MAX, FLAGS },
> { "fontcolor", "set font color", OFFSET(fontcolor),
> AV_OPT_TYPE_STRING, { .str = FONTCOLOR_DEFAULT }, CHAR_MIN, CHAR_MAX, FLAGS
> },
> +{ "text", "draw text", OFFSET(draw_text), AV_OPT_TYPE_INT, { .i64 = 1
> }, 0, 1, FLAGS },
AV_OPT_TYPE_BOOL?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: change fft left-right separation
On Mon, Sep 14, 2015 at 04:23:58PM +0700, Muhammad Faiz wrote: > > From c1b58d43c8940efcdea3e30d91d8fde0a0ab6551 Mon Sep 17 00:00:00 2001 > From: Muhammad Faiz > Date: Sun, 13 Sep 2015 21:52:17 +0700 > Subject: [PATCH] avfilter/avf_showcqt: change fft left-right separation applied with slightly more elaborate commit message also if you want to have git write access, send me your public SSH key thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avformat: access AVFormatContext.filename[] filed via getter/setter.
L'octidi 28 fructidor, an CCXXIII, Zhang Rui a écrit : > I'd like to know if this API-change could happen, since it will break > many things. It depends on the decision about ABI compatibility, that itself depends on the decision about the decision process. Assuming we will stop ABI compatibility, I am rather for replacing the fixed buffer by a mallocated one with a setter function. OTOH, I am not very fond of a getter. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] avformat: access AVFormatContext.filename[] filed via getter/setter.
2015-09-14 17:48 GMT+08:00 Zhang Rui : > URLs longer than 1024 could be truncated by AVFormatContext. > The field filename[1024] should be replaced with allocated string in future. I'd like to know if this API-change could happen, since it will break many things. And there is one direct usage of filename left in libavformat/rtspenc.c which I'm not quite sure how to modify /* We create the SDP based on the RTSP AVFormatContext where we * aren't allowed to change the filename field. (We create the SDP * based on the RTSP context since the contexts for the RTP streams * don't exist yet.) In order to specify a custom URL with the actual * peer IP instead of the originally specified hostname, we create * a temporary copy of the AVFormatContext, where the custom URL is set. * * FIXME: Create the SDP without copying the AVFormatContext. * This either requires setting up the RTP stream AVFormatContexts * already here (complicating things immensely) or getting a more * flexible SDP creation interface. */ sdp_ctx = *s; ff_url_join(sdp_ctx.filename, sizeof(sdp_ctx.filename), "rtsp", NULL, addr, -1, NULL); If the API-change could happen, I will take more investigation into this. > --- > ffmpeg.c | 8 +++ > ffmpeg_opt.c | 8 +++ > ffplay.c | 20 +- > ffprobe.c| 2 +- > ffserver.c | 20 +++--- > libavdevice/avfoundation.m | 2 +- > libavdevice/lavfi.c | 2 +- > libavdevice/qtkit.m | 8 +++ > libavdevice/sdl.c| 2 +- > libavformat/avformat.h | 9 +--- > libavformat/concatdec.c | 4 ++-- > libavformat/dashenc.c| 12 +-- > libavformat/gxfenc.c | 4 ++-- > libavformat/hdsenc.c | 24 ++--- > libavformat/hls.c| 2 +- > libavformat/hlsenc.c | 45 > +--- > libavformat/img2dec.c| 4 ++-- > libavformat/img2enc.c| 4 ++-- > libavformat/matroskadec.c| 4 ++-- > libavformat/mlvdec.c | 4 ++-- > libavformat/mov.c| 2 +- > libavformat/movenc.c | 10 - > libavformat/mpeg.c | 4 ++-- > libavformat/mpegtsenc.c | 2 +- > libavformat/mux.c| 2 +- > libavformat/nsvdec.c | 2 +- > libavformat/rtsp.c | 10 - > libavformat/rtspdec.c| 4 ++-- > libavformat/sapdec.c | 2 +- > libavformat/sapenc.c | 4 ++-- > libavformat/sdp.c| 4 ++-- > libavformat/segment.c| 36 ++-- > libavformat/smoothstreamingenc.c | 12 +-- > libavformat/tee.c| 6 +++--- > libavformat/utils.c | 17 +-- > libavformat/webm_chunk.c | 12 ++- > 36 files changed, 174 insertions(+), 143 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] avformat: access AVFormatContext.filename[] filed via getter/setter.
URLs longer than 1024 could be truncated by AVFormatContext.
The field filename[1024] should be replaced with allocated string in future.
---
ffmpeg.c | 8 +++
ffmpeg_opt.c | 8 +++
ffplay.c | 20 +-
ffprobe.c| 2 +-
ffserver.c | 20 +++---
libavdevice/avfoundation.m | 2 +-
libavdevice/lavfi.c | 2 +-
libavdevice/qtkit.m | 8 +++
libavdevice/sdl.c| 2 +-
libavformat/avformat.h | 9 +---
libavformat/concatdec.c | 4 ++--
libavformat/dashenc.c| 12 +--
libavformat/gxfenc.c | 4 ++--
libavformat/hdsenc.c | 24 ++---
libavformat/hls.c| 2 +-
libavformat/hlsenc.c | 45 +---
libavformat/img2dec.c| 4 ++--
libavformat/img2enc.c| 4 ++--
libavformat/matroskadec.c| 4 ++--
libavformat/mlvdec.c | 4 ++--
libavformat/mov.c| 2 +-
libavformat/movenc.c | 10 -
libavformat/mpeg.c | 4 ++--
libavformat/mpegtsenc.c | 2 +-
libavformat/mux.c| 2 +-
libavformat/nsvdec.c | 2 +-
libavformat/rtsp.c | 10 -
libavformat/rtspdec.c| 4 ++--
libavformat/sapdec.c | 2 +-
libavformat/sapenc.c | 4 ++--
libavformat/sdp.c| 4 ++--
libavformat/segment.c| 36 ++--
libavformat/smoothstreamingenc.c | 12 +--
libavformat/tee.c| 6 +++---
libavformat/utils.c | 17 +--
libavformat/webm_chunk.c | 12 ++-
36 files changed, 174 insertions(+), 143 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index e31a2c6..048a46d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1447,7 +1447,7 @@ static void print_final_stats(int64_t total_size)
uint64_t total_packets = 0, total_size = 0;
av_log(NULL, AV_LOG_VERBOSE, "Input file #%d (%s):\n",
- i, f->ctx->filename);
+ i, av_format_get_filename(f->ctx));
for (j = 0; j < f->nb_streams; j++) {
InputStream *ist = input_streams[f->ist_index + j];
@@ -1481,7 +1481,7 @@ static void print_final_stats(int64_t total_size)
uint64_t total_packets = 0, total_size = 0;
av_log(NULL, AV_LOG_VERBOSE, "Output file #%d (%s):\n",
- i, of->ctx->filename);
+ i, av_format_get_filename(of->ctx));
for (j = 0; j < of->ctx->nb_streams; j++) {
OutputStream *ost = output_streams[of->ost_index + j];
@@ -3220,7 +3220,7 @@ static int transcode_init(void)
/* dump the file output parameters - cannot be done before in case
of stream copy */
for (i = 0; i < nb_output_files; i++) {
-av_dump_format(output_files[i]->ctx, i,
output_files[i]->ctx->filename, 1);
+av_dump_format(output_files[i]->ctx, i,
av_format_get_filename(output_files[i]->ctx), 1);
}
/* dump the stream mapping */
@@ -3636,7 +3636,7 @@ static int process_input(int file_index)
}
if (ret < 0) {
if (ret != AVERROR_EOF) {
-print_error(is->filename, ret);
+print_error(av_format_get_filename(is), ret);
if (exit_on_error)
exit_program(1);
}
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 55818e1..746dd50 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1118,7 +1118,7 @@ static void choose_encoder(OptionsContext *o,
AVFormatContext *s, OutputStream *
MATCH_PER_STREAM_OPT(codec_names, str, codec_name, s, ost->st);
if (!codec_name) {
-ost->st->codec->codec_id = av_guess_codec(s->oformat, NULL,
s->filename,
+ost->st->codec->codec_id = av_guess_codec(s->oformat, NULL,
av_format_get_filename(s),
NULL,
ost->st->codec->codec_type);
ost->enc = avcodec_find_encoder(ost->st->codec->codec_id);
} else if (!strcmp(codec_name, "copy"))
@@ -2179,7 +2179,7 @@ loop_end:
}
if (!oc->nb_streams && !(oc->oformat->flags & AVFMT_NOSTREAMS)) {
-av_dump_format(oc, nb_output_files - 1, oc->filename, 1);
+av_dump_format(oc, nb_output_files - 1, av_format_get_filename(oc), 1);
av_log(NULL, AV_LOG_ERROR, "Output file #%d does not contain any
stream\n", nb_output_files - 1);
exit_program(1);
}
@@ -2239,8 +2239,8 @@ loop_end:
/* check filename in case of an image number is expected */
if (oc->oformat->flags & AVFMT_NEEDNUMBER) {
-if (!av_filename_number_test(oc->filename)) {
-print_error(oc->filename, AVERROR(EINVAL));
+if (!av_filename_number_test(av_format_get_filename(oc))) {
+print_error
[FFmpeg-devel] [PATCH] avfilter/avf_showcqt: change fft left-right separation
From c1b58d43c8940efcdea3e30d91d8fde0a0ab6551 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz
Date: Sun, 13 Sep 2015 21:52:17 +0700
Subject: [PATCH] avfilter/avf_showcqt: change fft left-right separation
---
libavfilter/avf_showcqt.c | 56 ++-
1 file changed, 21 insertions(+), 35 deletions(-)
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 85f9ea9..7719c7b 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -68,8 +68,7 @@ typedef struct {
AVFrame *outpicref;
FFTContext *fft_context;
FFTComplex *fft_data;
-FFTComplex *fft_result_left;
-FFTComplex *fft_result_right;
+FFTComplex *fft_result;
uint8_t *spectogram;
SparseCoeff *coeff_sort;
SparseCoeff *coeffs[VIDEO_WIDTH];
@@ -125,8 +124,7 @@ static av_cold void uninit(AVFilterContext *ctx)
for (k = 0; k < VIDEO_WIDTH; k++)
av_freep(&s->coeffs[k]);
av_freep(&s->fft_data);
-av_freep(&s->fft_result_left);
-av_freep(&s->fft_result_right);
+av_freep(&s->fft_result);
av_freep(&s->coeff_sort);
av_freep(&s->spectogram);
av_freep(&s->font_alpha);
@@ -345,11 +343,10 @@ static int config_output(AVFilterLink *outlink)
s->fft_data = av_malloc_array(fft_len, sizeof(*s->fft_data));
s->coeff_sort = av_malloc_array(fft_len, sizeof(*s->coeff_sort));
-s->fft_result_left = av_malloc_array(fft_len,
sizeof(*s->fft_result_left));
-s->fft_result_right = av_malloc_array(fft_len,
sizeof(*s->fft_result_right));
+s->fft_result = av_malloc_array(fft_len + 1, sizeof(*s->fft_result));
s->fft_context = av_fft_init(s->fft_bits, 0);
-if (!s->fft_data || !s->coeff_sort || !s->fft_result_left ||
!s->fft_result_right || !s->fft_context)
+if (!s->fft_data || !s->coeff_sort || !s->fft_result || !s->fft_context)
return AVERROR(ENOMEM);
#if CONFIG_LIBFREETYPE
@@ -541,43 +538,32 @@ static int plot_cqt(AVFilterLink *inlink)
int font_height = (FONT_HEIGHT/2) * video_scale;
/* real part contains left samples, imaginary part contains right samples
*/
-memcpy(s->fft_result_left, s->fft_data, fft_len * sizeof(*s->fft_data));
-av_fft_permute(s->fft_context, s->fft_result_left);
-av_fft_calc(s->fft_context, s->fft_result_left);
-
-/* separate left and right, (and multiply by 2.0) */
-s->fft_result_right[0].re = 2.0f * s->fft_result_left[0].im;
-s->fft_result_right[0].im = 0;
-s->fft_result_left[0].re = 2.0f * s->fft_result_left[0].re;
-s->fft_result_left[0].im = 0;
-for (x = 1; x <= fft_len >> 1; x++) {
-FFTSample tmpy = s->fft_result_left[fft_len-x].im -
s->fft_result_left[x].im;
-
-s->fft_result_right[x].re = s->fft_result_left[x].im +
s->fft_result_left[fft_len-x].im;
-s->fft_result_right[x].im = s->fft_result_left[x].re -
s->fft_result_left[fft_len-x].re;
-s->fft_result_right[fft_len-x].re = s->fft_result_right[x].re;
-s->fft_result_right[fft_len-x].im = -s->fft_result_right[x].im;
-
-s->fft_result_left[x].re = s->fft_result_left[x].re +
s->fft_result_left[fft_len-x].re;
-s->fft_result_left[x].im = tmpy;
-s->fft_result_left[fft_len-x].re = s->fft_result_left[x].re;
-s->fft_result_left[fft_len-x].im = -s->fft_result_left[x].im;
-}
+memcpy(s->fft_result, s->fft_data, fft_len * sizeof(*s->fft_data));
+av_fft_permute(s->fft_context, s->fft_result);
+av_fft_calc(s->fft_context, s->fft_result);
+s->fft_result[fft_len] = s->fft_result[0];
/* calculating cqt */
for (x = 0; x < VIDEO_WIDTH; x++) {
int u;
-FFTComplex l = {0,0};
-FFTComplex r = {0,0};
+FFTComplex v = {0,0};
+FFTComplex w = {0,0};
+FFTComplex l, r;
for (u = 0; u < s->coeffs_len[x]; u++) {
FFTSample value = s->coeffs[x][u].value;
int index = s->coeffs[x][u].index;
-l.re += value * s->fft_result_left[index].re;
-l.im += value * s->fft_result_left[index].im;
-r.re += value * s->fft_result_right[index].re;
-r.im += value * s->fft_result_right[index].im;
+v.re += value * s->fft_result[index].re;
+v.im += value * s->fft_result[index].im;
+w.re += value * s->fft_result[fft_len - index].re;
+w.im += value * s->fft_result[fft_len - index].im;
}
+
+/* separate left and right, (and multiply by 2.0) */
+l.re = v.re + w.re;
+l.im = v.im - w.im;
+r.re = w.im + v.im;
+r.im = w.re - v.re;
/* result is power, not amplitude */
result[x][0] = l.re * l.re + l.im * l.im;
result[x][2] = r.re * r.re + r.im * r.im;
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adding ffv1 help reference for "coder" parameter.
On 13.09.2015 19:13, Peter B. wrote:
libavcodec/ffv1enc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 265ced1..d210692 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -1345,6 +1345,7 @@ static av_cold int encode_close(AVCodecContext *avctx)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{ "slicecrc", "Protect slices with CRCs", OFFSET(ec), AV_OPT_TYPE_INT, {
.i64 = -1 }, -1, 1, VE },
+{ "coder", "Coder used: 0 (Golomb Rice), 1 (Range coder), 2 (Range coder with
custom state transition table)", OFFSET(ac), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE },
{ NULL }
};
I guess this won't work. From a brief look at encode_init() in ffv1enc.c
it seems that the ac value is derived from AVCodecContext->coder_type so
the "coder" doc would be found in the global codec options:
http://ffmpeg.org/ffmpeg-codecs.html#Codec-Options
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Voting committee
L'octidi 28 fructidor, an CCXXIII, Michael Niedermayer a écrit :
> saying "no" to a candidate here does not require prior problems or
> hate between the people but it will lead to that afterwards at least
> to some extend. very little in some, quite a bit in others.
> people have different points of view, and two people can differ
> easily in oppinion if someone is a active contributor or not
Yes, people have different opinion about that like about anything else.
NOT ASKING THE QUESTION DOES NOT SOLVE THE PROBLEM.
Any works made by several people will sometimes make decisions that
displease some of the members, that is unavoidable. Members should realize
that and accept it. If they can not accept it, that means they are unable to
work with others without being the project's dictator. We all know a few
libre software projects that work that way.
If the project is strongly and evenly split on an issue and no side is
willing to compromise, the project will fork again. There is no avoiding
that, that is in the nature of libre software projects.
The purpose of this voting system is to avoid that as much as possible: if
the project is strongly split on an issue, it gives a way of reaching a
decision that can not be contested. If a minority can still not accept it,
we can not force them, but that is their problem for being unable to
compromise, and they are free to leave.
Anyway, let us not confuse the immediate issue of the initial list with the
more long term issue of designating "active FFmpeg developers". For the long
term issue, feel free to draft a practical proposal that can be approved by
the other members of the project.
I have been thinking of a practical proposal myself, I will word it and post
it shortly.
For the immediate issue of the initial list: think of it as a bootstrap
problem. The bootloader has to work with limited resources and services, but
as long as it manages to load the kernel, everything is fine eventually.
You, members of the initial list, are the first stage of the bootloader:
your only task is to load the second stage, i.e. agree on a complete list of
current active FFmpeg developers.
We, members of that second stage ("we", assuming I am on it), will have to
load the kernel, i.e. write and approve rules for all later formal decision
making.
I strongly think that we will able to reach unanimous consensus about the
members of the second stage list, and clear consensus about the decision
rules. If that happens, there is no doubt this is legitimate. Do not forget:
you are on the list, so if the list is unanimous about itself, that means
you agree too.
If we do not manage to reach unanimous consensus about the members of the
second stage list, we have a deep problem.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
