Re: [FFmpeg-devel] [PATCH] avfilter/af_amerge: add reorder_inputs option to be able to turn off reordering
On 05.09.2016 16:43, Nicolas George wrote: Le decadi 20 fructidor, an CCXXIV, Marton Balint a écrit : The order of the channels to remain unchanged regardless of the input channel layout (which is often guessed only). Filtering in ffmpeg is unfortunately forcing you to use channel layouts, even if you don't want to, even if you only want to say: this track has 2 channels, that stream track has 1 channels. Don't assume anything else. I feel Carl Eugen has the right of it. libavfilter can work with streams with unknown layouts, but some individual filters may not. To make them work is relatively easy. First, make sure they do not use the channel layout: most filters from the fork will use the channel layout to know the number of channels, we have a separated field for that. Then declare accordingly the list of formats in query formats. The real problem is ffmpeg.c: it will try to guess the channel layout when none is specified. I think I added an option to avoid that, but it may have been lost at some point. -guess_layout_max 0 But indeed when using it I stumbled over similar filter issues (amerge or pan?). In the end I stopped using it and let the guessing do its work, instead I added "-write_channel_mask off" on AVI output side. And there seems to be no option to explicitly set an unknown input channel layout (as Marton noted). And of course, most of the time, there is a channel layout, you just have to make sure it is properly set at input and let the logic do its work. Another example: You have a file, with mono tracks. Some tracks have correct metadata describing the channel layout of the files, others don't. This is what needs fixing. You wan't the channels in file-order, regardless of the correctness of the input channel layout metadata in the file. Not true. Codecs work with the channel layouts, for inter-channel correlation, for the cutoff frequency on the subwoofer, etc. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]doc/showspectrum*: Change options order to reflect numeric values.
Hi!
Attached patch fixes ticket #5823.
Please comment, Carl Eugen
From 89c6b4034e24d76db2202008ffdd97770fed93f8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 6 Sep 2016 11:16:19 +0200
Subject: [PATCH] doc/showspectrum*: Change options order to reflect numeric
values.
Fixes ticket #5823.
---
doc/filters.texi | 12 ++--
libavfilter/avf_showspectrum.c | 10 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 99f07a6..a3a6abd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16980,10 +16980,10 @@ It accepts the following values:
the samples start again on the left when they reach the right
@item scroll
the samples scroll from right to left
-@item rscroll
-the samples scroll from left to right
@item fullframe
frames are only produced when the samples reach the right
+@item rscroll
+the samples scroll from left to right
@end table
Default value is @code{replace}.
@@ -17039,12 +17039,12 @@ linear
square root, default
@item cbrt
cubic root
+@item log
+logarithmic
@item 4thrt
4th root
@item 5thrt
5th root
-@item log
-logarithmic
@end table
Default value is @samp{sqrt}.
@@ -17187,12 +17187,12 @@ linear
square root, default
@item cbrt
cubic root
+@item log
+logarithmic
@item 4thrt
4th root
@item 5thrt
5th root
-@item log
-logarithmic
@end table
Default value is @samp{log}.
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index e65db4f..f63fbe8 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -94,8 +94,8 @@ static const AVOption showspectrum_options[] = {
{ "slide", "set sliding mode", OFFSET(sliding), AV_OPT_TYPE_INT, {.i64 =
0}, 0, NB_SLIDES-1, FLAGS, "slide" },
{ "replace", "replace old columns with new", 0, AV_OPT_TYPE_CONST,
{.i64=REPLACE}, 0, 0, FLAGS, "slide" },
{ "scroll", "scroll from right to left", 0, AV_OPT_TYPE_CONST,
{.i64=SCROLL}, 0, 0, FLAGS, "slide" },
-{ "rscroll", "scroll from left to right", 0, AV_OPT_TYPE_CONST,
{.i64=RSCROLL}, 0, 0, FLAGS, "slide" },
{ "fullframe", "return full frames", 0, AV_OPT_TYPE_CONST,
{.i64=FULLFRAME}, 0, 0, FLAGS, "slide" },
+{ "rscroll", "scroll from left to right", 0, AV_OPT_TYPE_CONST,
{.i64=RSCROLL}, 0, 0, FLAGS, "slide" },
{ "mode", "set channel display mode", OFFSET(mode), AV_OPT_TYPE_INT,
{.i64=COMBINED}, COMBINED, NB_MODES-1, FLAGS, "mode" },
{ "combined", "combined mode", 0, AV_OPT_TYPE_CONST, {.i64=COMBINED},
0, 0, FLAGS, "mode" },
{ "separate", "separate mode", 0, AV_OPT_TYPE_CONST, {.i64=SEPARATE},
0, 0, FLAGS, "mode" },
@@ -110,12 +110,12 @@ static const AVOption showspectrum_options[] = {
{ "fruit", "fruit based coloring",0,
AV_OPT_TYPE_CONST, {.i64=FRUIT}, 0, 0, FLAGS, "color" },
{ "cool", "cool based coloring", 0,
AV_OPT_TYPE_CONST, {.i64=COOL}, 0, 0, FLAGS, "color" },
{ "scale", "set display scale", OFFSET(scale), AV_OPT_TYPE_INT,
{.i64=SQRT}, LINEAR, NB_SCALES-1, FLAGS, "scale" },
+{ "lin", "linear", 0, AV_OPT_TYPE_CONST, {.i64=LINEAR}, 0, 0,
FLAGS, "scale" },
{ "sqrt", "square root", 0, AV_OPT_TYPE_CONST, {.i64=SQRT}, 0, 0,
FLAGS, "scale" },
{ "cbrt", "cubic root", 0, AV_OPT_TYPE_CONST, {.i64=CBRT}, 0, 0,
FLAGS, "scale" },
+{ "log", "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=LOG},0, 0,
FLAGS, "scale" },
{ "4thrt","4th root",0, AV_OPT_TYPE_CONST, {.i64=FOURTHRT}, 0, 0,
FLAGS, "scale" },
{ "5thrt","5th root",0, AV_OPT_TYPE_CONST, {.i64=FIFTHRT}, 0, 0,
FLAGS, "scale" },
-{ "log", "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=LOG},0, 0,
FLAGS, "scale" },
-{ "lin", "linear", 0, AV_OPT_TYPE_CONST, {.i64=LINEAR}, 0, 0,
FLAGS, "scale" },
{ "saturation", "color saturation multiplier", OFFSET(saturation),
AV_OPT_TYPE_FLOAT, {.dbl = 1}, -10, 10, FLAGS },
{ "win_func", "set window function", OFFSET(win_func), AV_OPT_TYPE_INT,
{.i64 = WFUNC_HANNING}, 0, NB_WFUNC-1, FLAGS, "win_func" },
{ "rect", "Rectangular", 0, AV_OPT_TYPE_CONST,
{.i64=WFUNC_RECT}, 0, 0, FLAGS, "win_func" },
@@ -944,12 +944,12 @@ static const AVOption showspectrumpic_options[] = {
{ "fruit", "fruit based coloring",0,
AV_OPT_TYPE_CONST, {.i64=FRUIT}, 0, 0, FLAGS, "color" },
{ "cool", "cool based coloring", 0,
AV_OPT_TYPE_CONST, {.i64=COOL}, 0, 0, FLAGS, "color" },
{ "scale", "set display scale", OFFSET(scale), AV_OPT_TYPE_INT,
{.i64=LOG}, 0, NB_SCALES-1, FLAGS, "scale" },
+{ "lin", "linear", 0, AV_OPT_TYPE_CONST, {.i64=LINEAR}, 0, 0,
FLAGS, "scale" },
{ "sqrt", "square root", 0, AV_OPT_TYPE_CONST, {.i64=SQRT}, 0, 0,
FLAGS, "scale" },
{ "cbrt", "cubic root", 0, AV_OPT_TYPE_CONST, {.i64=CBRT}, 0, 0,
Re: [FFmpeg-devel] [PATCH]doc/showspectrum*: Change options order to reflect numeric values.
On 9/6/16, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #5823. > > Please comment, Carl Eugen > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]doc/showspectrum*: Change options order to reflect numeric values.
2016-09-06 11:23 GMT+02:00 Paul B Mahol : > On 9/6/16, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes ticket #5823. >> >> Please comment, Carl Eugen > > ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_amerge: add reorder_inputs option to be able to turn off reordering
2016-09-05 20:51 GMT+02:00 Marton Balint : > Can/will I do this with -channel_layout 0 or > something like that? This (-channel_layout 0) was broken in 2012. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/matroskaenc: skip writing "duration" tags
2016-09-06 5:26 GMT+02:00 Rodger Combs : > --- > libavformat/matroskaenc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c > index decb66d..7deccaa 100644 > --- a/libavformat/matroskaenc.c > +++ b/libavformat/matroskaenc.c > @@ -1314,6 +1314,7 @@ static int mkv_check_tag_name(const char *name, > unsigned int elementid) > av_strcasecmp(name, "stereo_mode") && > av_strcasecmp(name, "creation_time") && > av_strcasecmp(name, "encoding_tool") && > + av_strcasecmp(name, "duration") && Could you elaborate? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/fifo: Make independent of the channel layout
On Tue, Sep 06, 2016 at 01:34:19AM +0200, Paul B Mahol wrote: > On 9/6/16, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/fifo.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > should be ok applied thx [...] -- 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] typo in file ffmpeg_vaapi.c at line 305
2016-09-05 14:23 GMT+02:00 Mihai Chindea : > https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_vaapi.c#L305 > i imagine it should test with ctx->output_format, not ctx->decode_format > which is always AV_PIX_FMT_NONE due to previous assignment ... Please consider to send a patch made with git format-patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit
2016-09-05 13:18 GMT+02:00 Burt P : > * use the actual sample rate Is hdcd supposed to work for sample_rates different from 44100? > * use a more sensible frequency for the tone > * update fate test result Can't this be split? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_amix: make independent of the channel layout
On Tue, Sep 06, 2016 at 12:59:12AM +0200, Paul B Mahol wrote: > On 9/6/16, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/af_amix.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > lgtm applied 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] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
2016-09-05 12:47 GMT+02:00 Ligverd Haer :
> Create valide manifest.
> Calculate current bandwidth for eath chunk.
> Now works correctly with dash.sj
> -avio_printf(out, "\t\t segmentAlignment=\"true\" bitstreamSwitching=\"true\"");
> -if (c->max_frame_rate.num && !c->ambiguous_frame_rate)
> -avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(c->min_frame_rate,
> c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate",
> c->max_frame_rate.num, c->max_frame_rate.den);
> -avio_printf(out, ">\n");
> +avio_printf(out, "\t\t segmentAlignment=\"true\" bitstreamSwitching=\"true\">\n");
This hunk is not ok because it is needlessly difficult to understand
what you are changing:
Leave the first ("AdaptionSet") and last ("\n") line unchanged -
unless I misread the patch.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_atempo: Make independent of the channel layout
On Mon, Sep 05, 2016 at 10:25:47PM -0600, Pavel Koshevoy wrote: > On Sep 5, 2016 4:41 PM, "Michael Niedermayer" > wrote: > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/af_atempo.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c > > index 7b3d57c..d5d29b3 100644 > > --- a/libavfilter/af_atempo.c > > +++ b/libavfilter/af_atempo.c > > @@ -1044,9 +1044,8 @@ static int config_props(AVFilterLink *inlink) > > > > enum AVSampleFormat format = inlink->format; > > int sample_rate = (int)inlink->sample_rate; > > -int channels = av_get_channel_layout_nb_channels(inlink->channel_ > layout); > > > > -return yae_reset(atempo, format, sample_rate, channels); > > +return yae_reset(atempo, format, sample_rate, inlink->channels); > > } > > > > static int push_samples(ATempoContext *atempo, > > -- > > 2.9.3 > > > Looks good to me, applied thx to all [...] -- 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
[FFmpeg-devel] [PATCH]ffmpeg_opt: Suggest to use "file:..." if a protocol was not found
Hi!
Attached patch tries to fix Debian bug 785690.
Please comment, Carl Eugen
From fd0391ac4cefffe15da42ac1e14aafc5b3a9dbaf Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 6 Sep 2016 12:47:34 +0200
Subject: [PATCH] ffmpeg_opt: Suggest to use "file:..." if a protocol was not
found.
Fixes Debian bug 785690.
---
ffmpeg_opt.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 2ea09cf..0c0d3a6 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -982,6 +982,8 @@ static int open_input_file(OptionsContext *o, const char *filename)
err = avformat_open_input(&ic, filename, file_iformat, &o->g->format_opts);
if (err < 0) {
print_error(filename, err);
+if (err == AVERROR_PROTOCOL_NOT_FOUND)
+av_log(NULL, AV_LOG_ERROR, "Did you mean file:%s?\n", filename);
exit_program(1);
}
if (scan_all_pmts_set)
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]ffmpeg_opt: Suggest to use "file:..." if a protocol was not found
On Tue, Sep 06, 2016 at 12:51:05PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch tries to fix Debian bug 785690. > > Please comment, Carl Eugen > ffmpeg_opt.c |2 ++ > 1 file changed, 2 insertions(+) > 7ea4c9b62c1fa94707e3d88143bb2df73cf501c6 > 0001-ffmpeg_opt-Suggest-to-use-file-.-if-a-protocol-was-n.patch > From fd0391ac4cefffe15da42ac1e14aafc5b3a9dbaf Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Tue, 6 Sep 2016 12:47:34 +0200 > Subject: [PATCH] ffmpeg_opt: Suggest to use "file:..." if a protocol was not > found. > > Fixes Debian bug 785690. > --- > ffmpeg_opt.c |2 ++ > 1 file changed, 2 insertions(+) LGTM please give others a day to comment before applying 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] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
В письме от вторник, 6 сентября 2016 г. 12:26:49 MSK пользователь Carl Eugen
Attributes
profiles
width
height
sar
frameRate
audioSamplingRate
mimeType
segmentProfiles
codecs
maximumSAPPeriod
startWithSAP
maxPlayoutRate
codingDependency
scanType
Common attributes for AdaptationSet and Representation shall either be in one
of the elements but not in both.
in particular, the attribute frameRate is duplicated in the node
Representation
> > -avio_printf(out, "\t\t > segmentAlignment=\"true\" bitstreamSwitching=\"true\"");
> > -if (c->max_frame_rate.num && !c->ambiguous_frame_rate)
> > -avio_printf(out, " %s=\"%d/%d\"",
> > (av_cmp_q(c->min_frame_rate,
> > c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate",
> > c->max_frame_rate.num, c->max_frame_rate.den);
> > -avio_printf(out, ">\n");
> > +avio_printf(out, "\t\t > segmentAlignment=\"true\" bitstreamSwitching=\"true\">\n");
>
> This hunk is not ok because it is needlessly difficult to understand
> what you are changing:
> Leave the first ("AdaptionSet") and last ("\n") line unchanged -
> unless I misread the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
2016-09-06 12:56 GMT+02:00 Ligverd Haer : > in particular, the attribute frameRate is duplicated in the node > Representation If this is the case, remove the offending line, do not change the adjacent lines to make your intention easier to understand. Please do not top-post here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
В письме от вторник, 6 сентября 2016 г. 13:02:42 MSK пользователь Carl Eugen
Hoyos написал:
> If this is the case, remove the offending line, do not
> change the adjacent lines to make your intention easier
> to understand.
Well, if that's clearer
if (c->has_video) {
avio_printf(out, "\t\tmax_frame_rate.num && !c->ambiguous_frame_rate)
-avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(c->min_frame_rate,
c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate", c->max_frame_rate.num,
c->max_frame_rate.den);
avio_printf(out, ">\n");
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
2016-09-06 13:05 GMT+02:00 Ligverd Haer : > В письме от вторник, 6 сентября 2016 г. 13:02:42 MSK пользователь Carl Eugen > Hoyos написал: >> If this is the case, remove the offending line, do not >> change the adjacent lines to make your intention easier >> to understand. > > Well, if that's clearer If you think it is not clearer, please ignore my suggestion! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit
On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote: > 2016-09-05 13:18 GMT+02:00 Burt P : >> * use the actual sample rate > > Is hdcd supposed to work for sample_rates > different from 44100? As I understand it, yes. The PM Model 2 supported code insertion at all CD and DVD-Audio sample rates, so: 44.1, 48, 88.2, 96, 176.4, and 192 kHz. If any DVD-Audio was ever actually released with HDCD encoding, I do not know. >> * use a more sensible frequency for the tone >> * update fate test result > > Can't this be split? It could, if you would like it to be. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit
2016-09-06 13:02 GMT+02:00 Burt P. : > On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote: >> 2016-09-05 13:18 GMT+02:00 Burt P : >>> * use the actual sample rate >> >> Is hdcd supposed to work for sample_rates >> different from 44100? > > As I understand it, yes. The PM Model 2 supported code > insertion at all CD and DVD-Audio sample rates, so: > 44.1, 48, 88.2, 96, 176.4, and 192 kHz. > If any DVD-Audio was ever actually released with HDCD > encoding, I do not know. Is there a test if the sample_rate is any of the above? >>> * use a more sensible frequency for the tone >>> * update fate test result >> >> Can't this be split? > > It could, if you would like it to be. You are the maintainer;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META
Hi, (Cc'ing as it's been some time.) On 08/31/2016 04:42 PM, Carl Eugen Hoyos wrote: I meant "defaulting to an additional track in the output mov file if the input file contains such a data track (instead of ignoring this track of the input file by default)". So I looked into it and indeed the data tracks end up with the enabled flag enabled. If this affects anything is a bit unclear to me, perhaps in some players? It seems to me they would unlikely try to play something they don't know how to - in a worse case perhaps the can stop or crash. It seems also 'tmcd' tracks end up being enabled (but not by this function). I imagine this is by design. I can remove the enabled-flag for the next patch set for the AVMEDIA_TYPE_DATA tracks (this does not include tmcd as it doesn't have a corresponding stream). Or perhaps the appropriate solution would be to not write such data tracks into QuickTime video files in the first place and only support them in .mp4 by reverting the codec support for MOV with these kind of codecs. Thanks for input! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META
(Oops, sorry about the subject, our MTA helpfully prepended it.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/gif: dont honor transparency if palette changed
It generally does not work. Signed-off-by: Paul B Mahol --- libavcodec/gif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/gif.c b/libavcodec/gif.c index 6af1f4a..d9c99d5 100644 --- a/libavcodec/gif.c +++ b/libavcodec/gif.c @@ -83,7 +83,7 @@ static int gif_image_write_image(AVCodecContext *avctx, GIFContext *s = avctx->priv_data; int len = 0, height = avctx->height, width = avctx->width, x, y; int x_start = 0, y_start = 0, trans = s->transparent_index; -int honor_transparency = (s->flags & GF_TRANSDIFF) && s->last_frame; +int honor_transparency = (s->flags & GF_TRANSDIFF) && s->last_frame && !palette; const uint8_t *ptr; /* Crop image */ -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/gif: dont honor transparency if palette changed
2016-09-06 13:30 GMT+02:00 Paul B Mahol : > It generally does not work. Shouldn't a warning be printed in this case? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META
Hi! 2016-09-06 13:13 GMT+02:00 Erkki Seppälä : > (Cc'ing as it's been some time.) Please don't. > On 08/31/2016 04:42 PM, Carl Eugen Hoyos wrote: >> >> I meant "defaulting to an additional track in the output mov file if the >> input file contains such a data track (instead of ignoring this track >> of the input file by default)". > > So I looked into it and indeed the data tracks end up with the enabled > flag enabled. If this affects anything is a bit unclear to me, perhaps in > some players? It seems to me they would unlikely try to play something > they don't know how to - in a worse case perhaps the can stop or crash. Sorry, that is not what I meant (although it may or may not be an issue). I meant that for the same ffmpeg command line and the same input file, I believe that with your patch, the output file (suddenly) has one track more than before (because the data codec is now listed in AVOutputFormat, the ffmpeg cli will try to add this track if the input file provides such a codec). Maybe this is wrong because the data codec does not produce a new track if it is passed to the muxer? Iirc, my question was equivalent to: Can you just remove the additional ".data_codec=" lines or is it intended that they are now default codecs? (Or am I simply wrong and they either do not lead to a new track and / or ffmpeg simply ignores them because it only fills video, audio and subtitle tracks?) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit
On Tue, Sep 6, 2016 at 6:12 AM, Carl Eugen Hoyos wrote: > 2016-09-06 13:02 GMT+02:00 Burt P. : >> On Tue, Sep 6, 2016 at 5:22 AM, Carl Eugen Hoyos wrote: >>> 2016-09-05 13:18 GMT+02:00 Burt P : * use the actual sample rate >>> >>> Is hdcd supposed to work for sample_rates >>> different from 44100? >> >> As I understand it, yes. The PM Model 2 supported code >> insertion at all CD and DVD-Audio sample rates, so: >> 44.1, 48, 88.2, 96, 176.4, and 192 kHz. >> If any DVD-Audio was ever actually released with HDCD >> encoding, I do not know. > > Is there a test if the sample_rate is any of the above? > Right now, query_formats only accepts 44100. I don't have any higher rate samples to test, I don't know if it is a good idea to just add the other rates to the accepted list if I can't test the results. In this patch, I took the opportunity to remove a hard-coded rate and use one from the framework. I did the same in patch 4/5 in this set. hdcd_reset() already uses a variable rate to set the cdt period. All that is left is to make whatever changes to hdcd_envelope(), if any. So, perhaps in the future it will be possible to support the higher rates. I don't have any HDCD-encoded DVD-Audio (or any DVD-Audio), and I also don't have a PM Model Two to generate some. For now anyway, I can't test it. -- Burt ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit
2016-09-06 14:01 GMT+02:00 Burt P. : > In this patch, I took the opportunity to remove a hard-coded rate and > use one from the framework. Thanks for explaining! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote: > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote: > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > > >> From: Clément Bœsch > > >> > > >> These adjusted codec fields do not seem to be in use anymore and prevent > > >> the convert of ffmpeg*.c to codecpar. > > > > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf > > > fails, no output anymore > > > > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi > > > the output now has 600fps > > > > Even with this code in place the resulting stream in the avi is reported > > as 100 fps. > > that seems to be a regression since > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 > > IIRC the intended timebase is 1/50 for this kind of content > (allowing the support of interlaced and field duplicated content to > appear later) > > > > And with or without the code, the resulting files play the > > same with the players i tried. > > Higher framerates / finer timebases need noticably more space to > be stored in avi, thats not the case for other formats and thats > one reason why avi is treated as a special case. > > ill try to look tomorrow why its 100fps since the previous > codecpar patches. Though 100fps is not nearly as bad as 600fps > 600 has ~6 times the overhead This regression is caused by ticks_per_frame beiing incorrect Ill send a patch to fix this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > > >> From: Clément Bœsch
> > > >>
> > > >> These adjusted codec fields do not seem to be in use anymore and
> > > >> prevent
> > > >> the convert of ffmpeg*.c to codecpar.
> > > >
> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> > > > fails, no output anymore
> > > >
> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > > > the output now has 600fps
> > >
> > > Even with this code in place the resulting stream in the avi is reported
> > > as 100 fps.
> >
> > that seems to be a regression since
> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> >
> > IIRC the intended timebase is 1/50 for this kind of content
> > (allowing the support of interlaced and field duplicated content to
> > appear later)
> >
> >
> > > And with or without the code, the resulting files play the
> > > same with the players i tried.
> >
> > Higher framerates / finer timebases need noticably more space to
> > be stored in avi, thats not the case for other formats and thats
> > one reason why avi is treated as a special case.
> >
> > ill try to look tomorrow why its 100fps since the previous
> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> > 600 has ~6 times the overhead
>
> This regression is caused by ticks_per_frame beiing incorrect
>
> Ill send a patch to fix this
patch attached
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
From 66b4f6da72ca7867b9d1c6c7936161cf1482a73b Mon Sep 17 00:00:00 2001
From: Michael Niedermayer
Date: Tue, 6 Sep 2016 13:39:36 +0200
Subject: [PATCH] avcodec: Add ticks_per_frame to AVCodecParameters
Fixes regressions in stream copy timebase handling
(for example with AVI output being incorrectly 100fps)
Signed-off-by: Michael Niedermayer
---
libavcodec/avcodec.h| 8
libavcodec/utils.c | 3 +++
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 | 2 +-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 2 +-
7 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e2dad5d..3ec8814 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4091,6 +4091,14 @@ typedef struct AVCodecParameters {
* Audio only. Number of samples to skip after a discontinuity.
*/
int seek_preroll;
+/**
+ * For some codecs, the time base is closer to the field rate than the frame rate.
+ * Most notably, H.264 and MPEG-2 specify time_base as half of frame duration
+ * if no telecine is used ...
+ *
+ * Set to time_base ticks per frame. Default 1, e.g., H.264/MPEG-2 set it to 2.
+ */
+int ticks_per_frame;
} AVCodecParameters;
/**
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 0f6d0e7..da24f92 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -4043,6 +4043,7 @@ static void codec_parameters_reset(AVCodecParameters *par)
par->sample_aspect_ratio = (AVRational){ 0, 1 };
par->profile = FF_PROFILE_UNKNOWN;
par->level = FF_LEVEL_UNKNOWN;
+par->ticks_per_frame = 1;
}
AVCodecParameters *avcodec_parameters_alloc(void)
@@ -4098,6 +4099,7 @@ int avcodec_parameters_from_context(AVCodecParameters *par,
par->bits_per_raw_sample = codec->bits_per_raw_sample;
par->profile = codec->profile;
par->level = codec->level;
+par->ticks_per_frame = codec->ticks_per_frame;
switch (par->codec_type) {
case AVMEDIA_TYPE_VIDEO:
@@ -4153,6 +4155,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
codec->bits_per_raw_sample = par->bits_per_raw_sample;
codec->profile = par->profile;
codec->level = par->level;
+codec->ticks_per_frame = par->ticks_per_frame;
switch (par->codec_type) {
case AVMEDIA_TYPE_VIDEO:
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index b894938..677a354 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-0aa1ca6ff6e2e5aa926454d22fdaecd5 *tests/data/fate/concat-demuxer-extended-lavf-mxf.ffprobe
+7038d2a9b336799a9
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer wrote: > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote: >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote: >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote: >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: >> > > >> From: Clément Bœsch >> > > >> >> > > >> These adjusted codec fields do not seem to be in use anymore and >> > > >> prevent >> > > >> the convert of ffmpeg*.c to codecpar. >> > > > >> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf >> > > > fails, no output anymore >> > > > >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi >> > > > the output now has 600fps >> > > >> > > Even with this code in place the resulting stream in the avi is reported >> > > as 100 fps. >> > >> > that seems to be a regression since >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 >> > >> > IIRC the intended timebase is 1/50 for this kind of content >> > (allowing the support of interlaced and field duplicated content to >> > appear later) >> > >> > >> > > And with or without the code, the resulting files play the >> > > same with the players i tried. >> > >> > Higher framerates / finer timebases need noticably more space to >> > be stored in avi, thats not the case for other formats and thats >> > one reason why avi is treated as a special case. >> > >> > ill try to look tomorrow why its 100fps since the previous >> > codecpar patches. Though 100fps is not nearly as bad as 600fps >> > 600 has ~6 times the overhead >> >> This regression is caused by ticks_per_frame beiing incorrect >> >> Ill send a patch to fix this > > patch attached > We don't have time_base in codecpar, so why do we need ticks per frame in it? Which time_base does it modify the interpretation of? The field should be bundled with that, then. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote: > On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer > wrote: > > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote: > >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: > >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote: > >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote: > >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > >> > > >> From: Clément Bœsch > >> > > >> > >> > > >> These adjusted codec fields do not seem to be in use anymore and > >> > > >> prevent > >> > > >> the convert of ffmpeg*.c to codecpar. > >> > > > > >> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf > >> > > > fails, no output anymore > >> > > > > >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi > >> > > > the output now has 600fps > >> > > > >> > > Even with this code in place the resulting stream in the avi is > >> > > reported > >> > > as 100 fps. > >> > > >> > that seems to be a regression since > >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 > >> > > >> > IIRC the intended timebase is 1/50 for this kind of content > >> > (allowing the support of interlaced and field duplicated content to > >> > appear later) > >> > > >> > > >> > > And with or without the code, the resulting files play the > >> > > same with the players i tried. > >> > > >> > Higher framerates / finer timebases need noticably more space to > >> > be stored in avi, thats not the case for other formats and thats > >> > one reason why avi is treated as a special case. > >> > > >> > ill try to look tomorrow why its 100fps since the previous > >> > codecpar patches. Though 100fps is not nearly as bad as 600fps > >> > 600 has ~6 times the overhead > >> > >> This regression is caused by ticks_per_frame beiing incorrect > >> > >> Ill send a patch to fix this > > > > patch attached > > > > We don't have time_base in codecpar, so why do we need ticks per frame in it? > > Which time_base does it modify the interpretation of? The field should > be bundled with that, then. When do we have a mismatch of st->time_base and that "codec time base"? What if the ticks_per_frame was at AVStream level? -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META
On 09/06/2016 02:37 PM, Carl Eugen Hoyos wrote: I meant that for the same ffmpeg command line and the same input file, I believe that with your patch, the output file (suddenly) has one track more than before (because the data codec is now listed in AVOutputFormat, the ffmpeg cli will try to add this track if the input file provides such a codec). Ok, so now I finally understood the case and indeed if I have a file with video+data, converting it to a .mov without any particular mapping options results in a video+data track, instead of just video as what would happen if the .data_codecs are not defined. (I used ffmpeg -i foo.mp4 -codec copy bar.mp4 (or .mov) for testing where foo.mp4 has a data track.) A curiosity: if I copy a file with two video tracks and two data tracks I end up with a file with one video track and two data tracks (unless I use -map : to copy all). Would it be even better to not copy the data tracks at all by default, so not set the .data_codec field for any format? Or another view is that it would seem useful though that all the data tracks would be copied (but so does copying all video tracks). Or it could copy all the tracks that have track references to tracks copied by default.. Can you just remove the additional ".data_codec=" lines or is it intended that they are now default codecs? (Or am I simply wrong and they either do not lead to a new track and / or ffmpeg simply ignores them because it only fills video, audio and subtitle tracks?) This seems the correct solution. My next patch set will remove the .data_codec at least from output formats other than the .mp4. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] swscale: add unscaled conversion from yuv420p to p010
applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On 9/6/2016 9:57 AM, Clément Bœsch wrote: >> We don't have time_base in codecpar, so why do we need ticks per frame in it? >> > >> > Which time_base does it modify the interpretation of? The field should >> > be bundled with that, then. > When do we have a mismatch of st->time_base and that "codec time base"? st->time_base can be anything. Matroska for example is always 1/1000, and mpegps 1/9. "Codec time_base" seems to be codec frame_rate * ticks_per_frame, so usually the same as frame_rate, except for codecs like h264 and mpeg2 where it's twice that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote:
> On 9/6/2016 9:57 AM, Clément Bœsch wrote:
> >> We don't have time_base in codecpar, so why do we need ticks per frame in
> >> it?
> >> >
> >> > Which time_base does it modify the interpretation of? The field should
> >> > be bundled with that, then.
> > When do we have a mismatch of st->time_base and that "codec time base"?
>
> st->time_base can be anything. Matroska for example is always 1/1000,
> and mpegps 1/9.
> "Codec time_base" seems to be codec frame_rate * ticks_per_frame, so
> usually the same as frame_rate, except for codecs like h264 and mpeg2
> where it's twice that.
But you could deduce one from another if you have ticks per frame? That
means we could have only AVStream.{time_base,ticks_per_frame} and we will
be able to deal with all the situations were lavf/mux* need such info, and
thus not need to transmit anything in AVCodecParameters?
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_palettegen: add mode for generating palette for each input frame
On Fri, Sep 02, 2016 at 10:42:09PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_palettegen.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
> index fccc5ca..3018b06 100644
> --- a/libavfilter/vf_palettegen.c
> +++ b/libavfilter/vf_palettegen.c
> @@ -53,6 +53,7 @@ struct hist_node {
> enum {
> STATS_MODE_ALL_FRAMES,
> STATS_MODE_DIFF_FRAMES,
> +STATS_MODE_SINGLE_FRAMES,
> NB_STATS_MODE
> };
>
> @@ -80,9 +81,10 @@ typedef struct {
> static const AVOption palettegen_options[] = {
> { "max_colors", "set the maximum number of colors to use in the
> palette", OFFSET(max_colors), AV_OPT_TYPE_INT, {.i64=256}, 4, 256, FLAGS },
> { "reserve_transparent", "reserve a palette entry for transparency",
> OFFSET(reserve_transparent), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
> -{ "stats_mode", "set statistics mode", OFFSET(stats_mode),
> AV_OPT_TYPE_INT, {.i64=STATS_MODE_ALL_FRAMES}, 0, NB_STATS_MODE, FLAGS,
> "mode" },
> +{ "stats_mode", "set statistics mode", OFFSET(stats_mode),
> AV_OPT_TYPE_INT, {.i64=STATS_MODE_ALL_FRAMES}, 0, NB_STATS_MODE-1, FLAGS,
> "mode" },
> { "full", "compute full frame histograms", 0, AV_OPT_TYPE_CONST,
> {.i64=STATS_MODE_ALL_FRAMES}, INT_MIN, INT_MAX, FLAGS, "mode" },
> { "diff", "compute histograms only for the part that differs from
> previous frame", 0, AV_OPT_TYPE_CONST, {.i64=STATS_MODE_DIFF_FRAMES},
> INT_MIN, INT_MAX, FLAGS, "mode" },
> +{ "single", "compute new histogram for each frame", 0,
> AV_OPT_TYPE_CONST, {.i64=STATS_MODE_SINGLE_FRAMES}, INT_MIN, INT_MAX, FLAGS,
> "mode" },
> { NULL }
> };
>
> @@ -480,8 +482,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> {
> AVFilterContext *ctx = inlink->dst;
> PaletteGenContext *s = ctx->priv;
> -const int ret = s->prev_frame ? update_histogram_diff(s->histogram,
> s->prev_frame, in)
> - : update_histogram_frame(s->histogram, in);
> +int ret = s->prev_frame ? update_histogram_diff(s->histogram,
> s->prev_frame, in)
> +: update_histogram_frame(s->histogram, in);
> +int64_t in_pts = in->pts;
>
> if (ret > 0)
> s->nb_refs += ret;
> @@ -493,6 +496,22 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> av_frame_free(&in);
> }
>
> +if (s->stats_mode == STATS_MODE_SINGLE_FRAMES) {
> +AVFrame *out;
> +int i;
> +
> +out = get_palette_frame(ctx);
> +out->pts = in_pts;
> +ret = ff_filter_frame(ctx->outputs[0], out);
> +for (i = 0; i < HIST_SIZE; i++)
> +av_freep(&s->histogram[i].entries);
> +av_freep(&s->refs);
> +s->nb_refs = 0;
> +s->nb_boxes = 0;
> +memset(s->boxes, 0, sizeof(s->boxes));
> +memset(s->histogram, 0, sizeof(s->histogram));
> +}
> +
I'd prefer:
if (s->stats_mode == STATS_MODE_DIFF_FRAMES) {
av_frame_free(&s->prev_frame);
s->prev_frame = in;
if (s->stats_mode == STATS_MODE_SINGLE_FRAMES) {
// ...
out->pts = in->pts;
// ...
av_frame_free(&in);
} else {
av_frame_free(&in);
}
[...]
otherwise LGTM, thanks
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_paletteuse: add option to use new palette for each output frame
On Fri, Sep 02, 2016 at 10:42:10PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_paletteuse.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index dece05a..ed51cfe 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -86,6 +86,7 @@ typedef struct PaletteUseContext {
> uint32_t palette[AVPALETTE_COUNT];
> int palette_loaded;
> int dither;
> +int new;
> set_frame_func set_frame;
> int bayer_scale;
> int ordered_dither[8*8];
> @@ -122,6 +123,7 @@ static const AVOption paletteuse_options[] = {
> { "bruteforce","brute-force into the palette", 0,
> AV_OPT_TYPE_CONST, {.i64=COLOR_SEARCH_BRUTEFORCE},INT_MIN, INT_MAX,
> FLAGS, "search" },
> { "mean_err", "compute and print mean error", OFFSET(calc_mean_err),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
> { "debug_accuracy", "test color search accuracy",
> OFFSET(debug_accuracy), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
> +{ "new", "take new palette for each output frame", OFFSET(new),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
> { NULL }
> };
>
> @@ -928,8 +930,15 @@ static void load_palette(PaletteUseContext *s, const
> AVFrame *palette_frame)
> const uint32_t *p = (const uint32_t *)palette_frame->data[0];
> const int p_linesize = palette_frame->linesize[0] >> 2;
>
> -i = 0;
> -for (y = 0; y < palette_frame->height; y++) {
> +if (s->new) {
> +memset(s->palette, 0, sizeof(s->palette));
> +memset(s->map, 0, sizeof(s->map));
> +for (i = 0; i < CACHE_SIZE; i++)
> +av_freep(&s->cache[i].entries);
> +memset(s->cache, 0, sizeof(s->cache));
> +}
> +
> +for (i = 0, y = 0; y < palette_frame->height; y++) {
Please keep the i=0 out of the loop; this line doesn't need to change.
Rest LGTM, thanks
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/gif: dont honor transparency if palette changed
On Tue, Sep 06, 2016 at 01:30:17PM +0200, Paul B Mahol wrote: > It generally does not work. > > Signed-off-by: Paul B Mahol > --- > libavcodec/gif.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/gif.c b/libavcodec/gif.c > index 6af1f4a..d9c99d5 100644 > --- a/libavcodec/gif.c > +++ b/libavcodec/gif.c > @@ -83,7 +83,7 @@ static int gif_image_write_image(AVCodecContext *avctx, > GIFContext *s = avctx->priv_data; > int len = 0, height = avctx->height, width = avctx->width, x, y; > int x_start = 0, y_start = 0, trans = s->transparent_index; > -int honor_transparency = (s->flags & GF_TRANSDIFF) && s->last_frame; > +int honor_transparency = (s->flags & GF_TRANSDIFF) && s->last_frame && > !palette; > const uint8_t *ptr; > LGTM -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: fix SODB escaping
From: Matthieu Bouron
Fixes escaping of consecutive 0x00, 0x00, 0x0{0-3} sequences.
---
libavcodec/mediacodecdec_h264.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index a141174..4f9d737 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -104,9 +104,9 @@ static int h264_ps_to_nalu(const uint8_t *src, int
src_size, uint8_t **out, int
}
*out = p = new;
-i = i + 3;
-memmove(p + i, p + i - 1, *out_size - i);
-p[i - 1] = 0x03;
+i = i + 2;
+memmove(p + i + 1, p + i, *out_size - (i + 1));
+p[i] = 0x03;
}
}
done:
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote: > On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer > wrote: > > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote: > >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: > >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote: > >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote: > >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > >> > > >> From: Clément Bœsch > >> > > >> > >> > > >> These adjusted codec fields do not seem to be in use anymore and > >> > > >> prevent > >> > > >> the convert of ffmpeg*.c to codecpar. > >> > > > > >> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf > >> > > > fails, no output anymore > >> > > > > >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi > >> > > > the output now has 600fps > >> > > > >> > > Even with this code in place the resulting stream in the avi is > >> > > reported > >> > > as 100 fps. > >> > > >> > that seems to be a regression since > >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 > >> > > >> > IIRC the intended timebase is 1/50 for this kind of content > >> > (allowing the support of interlaced and field duplicated content to > >> > appear later) > >> > > >> > > >> > > And with or without the code, the resulting files play the > >> > > same with the players i tried. > >> > > >> > Higher framerates / finer timebases need noticably more space to > >> > be stored in avi, thats not the case for other formats and thats > >> > one reason why avi is treated as a special case. > >> > > >> > ill try to look tomorrow why its 100fps since the previous > >> > codecpar patches. Though 100fps is not nearly as bad as 600fps > >> > 600 has ~6 times the overhead > >> > >> This regression is caused by ticks_per_frame beiing incorrect > >> > >> Ill send a patch to fix this > > > > patch attached > > > > We don't have time_base in codecpar, so why do we need ticks per frame in it? We need both in some form probably For this regression ticks_per_frame ATM is enough. For time_base theres code to copy/access it bypassing codecpar The way it seems to be currently is that there are fields which are needed and either they are in codecpar or theres some tricks to access them from code sheduled to be removed (which will work only as long as the code isnt removed) or things just dont work. > > Which time_base does it modify the interpretation of? The field should > be bundled with that, then. the AVCodecContext one, ticks_per_frame is already in AVCodecContext the AVCodecContext ticks_per_frame though is not exported after codecpar while the codec timebase still is just not vissibly through codecpar [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote: > On 9/6/2016 9:57 AM, Clément Bœsch wrote: > >> We don't have time_base in codecpar, so why do we need ticks per frame in > >> it? > >> > > >> > Which time_base does it modify the interpretation of? The field should > >> > be bundled with that, then. > > When do we have a mismatch of st->time_base and that "codec time base"? > > st->time_base can be anything. Matroska for example is always 1/1000, > and mpegps 1/9. > "Codec time_base" seems to be codec frame_rate * ticks_per_frame, so > usually the same as frame_rate, except for codecs like h264 and mpeg2 > where it's twice that. this only works when codecs use the frame or field rate as basis for their timebase With some codecs that is syntactically not even possible MPEG4 (ISO/IEC 14496-2) stores its timebase as 1/N not M/N for vfr with for example 3/1001 that would be different (1/3) than the frame rate (3/1001) (which may be variable) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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/4] tests/fate-run: add transcode() as a simplified enc_dec()
On Mon, Sep 05, 2016 at 07:58:36PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > tests/fate-run.sh | 15 +++ > 1 file changed, 15 insertions(+) Approved-by: on IRC applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer wrote: > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote: >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer >> wrote: >> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote: >> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: >> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote: >> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote: >> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: >> >> > > >> From: Clément Bœsch >> >> > > >> >> >> > > >> These adjusted codec fields do not seem to be in use anymore and >> >> > > >> prevent >> >> > > >> the convert of ffmpeg*.c to codecpar. >> >> > > > >> >> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf >> >> > > > fails, no output anymore >> >> > > > >> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi >> >> > > > the output now has 600fps >> >> > > >> >> > > Even with this code in place the resulting stream in the avi is >> >> > > reported >> >> > > as 100 fps. >> >> > >> >> > that seems to be a regression since >> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 >> >> > >> >> > IIRC the intended timebase is 1/50 for this kind of content >> >> > (allowing the support of interlaced and field duplicated content to >> >> > appear later) >> >> > >> >> > >> >> > > And with or without the code, the resulting files play the >> >> > > same with the players i tried. >> >> > >> >> > Higher framerates / finer timebases need noticably more space to >> >> > be stored in avi, thats not the case for other formats and thats >> >> > one reason why avi is treated as a special case. >> >> > >> >> > ill try to look tomorrow why its 100fps since the previous >> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps >> >> > 600 has ~6 times the overhead >> >> >> >> This regression is caused by ticks_per_frame beiing incorrect >> >> >> >> Ill send a patch to fix this >> > >> > patch attached >> > >> >> We don't have time_base in codecpar, so why do we need ticks per frame in it? > > We need both in some form probably > For this regression ticks_per_frame ATM is enough. > For time_base theres code to copy/access it bypassing codecpar > > The way it seems to be currently is that there are fields which > are needed and either they are > in codecpar or > theres some tricks to access them from code sheduled to be removed > (which will work only as long as the code isnt removed) > or things just dont work. > > >> >> Which time_base does it modify the interpretation of? The field should >> be bundled with that, then. > > the AVCodecContext one, ticks_per_frame is already in AVCodecContext > the AVCodecContext ticks_per_frame though is not exported after codecpar > while the codec timebase still is just not vissibly through codecpar > Maybe that part should be fixed then, wherever we export that to AVCodecContext, also set its ticks_per_frame properly? It just feels bad to export a property here that standing alone doesn't mean anything. So fix the export of ticks_per_frame for AVCodecContext, and if later on we decide we really do need time_base in AVCodecParameters, and can't fix whatever needs it differently, we can then include both in there. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] test/fate: Add Ticket 236 / mov stream copy test
On Mon, Sep 05, 2016 at 03:20:27PM -0300, James Almer wrote: > On 9/5/2016 2:58 PM, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > tests/fate/ffmpeg.mak | 5 + > > tests/ref/fate/copy-236 | 2 ++ > > 2 files changed, 7 insertions(+) > > create mode 100644 tests/ref/fate/copy-236 > > > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > > index 3b91c12..e896d05 100644 > > --- a/tests/fate/ffmpeg.mak > > +++ b/tests/fate/ffmpeg.mak > > @@ -51,6 +51,11 @@ fate-unknown_layout-ac3: CMD = md5 \ > >-guess_layout_max 0 -f s16le -ac 1 -ar 44100 -i $(TARGET_PATH)/$(AREF) \ > >-f ac3 -flags +bitexact -c ac3_fixed > > > > +FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER MOV_MUXER) += fate-copy-236 > > +fate-copy-236: $(TARGET_SAMPLES)/mov/fcp_export8-236.mov > > trac236? Otherwise the name gives no hints about what it's testing. > We already named some tests like this. See vpx.mak > > This also applies for Patch 3/4. fixed and applied thx [...] -- 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] ffmpeg: drop format specific stream copy heuristics
On Tue, Sep 06, 2016 at 05:45:46PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
> wrote:
> > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> >> wrote:
> >> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> >> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> >> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> >> >> > > >> From: Clément Bœsch
> >> >> > > >>
> >> >> > > >> These adjusted codec fields do not seem to be in use anymore and
> >> >> > > >> prevent
> >> >> > > >> the convert of ffmpeg*.c to codecpar.
> >> >> > > >
> >> >> > > > ./ffmpeg -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy
> >> >> > > > out.mxf
> >> >> > > > fails, no output anymore
> >> >> > > >
> >> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> >> >> > > > the output now has 600fps
> >> >> > >
> >> >> > > Even with this code in place the resulting stream in the avi is
> >> >> > > reported
> >> >> > > as 100 fps.
> >> >> >
> >> >> > that seems to be a regression since
> >> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> >> >> >
> >> >> > IIRC the intended timebase is 1/50 for this kind of content
> >> >> > (allowing the support of interlaced and field duplicated content to
> >> >> > appear later)
> >> >> >
> >> >> >
> >> >> > > And with or without the code, the resulting files play the
> >> >> > > same with the players i tried.
> >> >> >
> >> >> > Higher framerates / finer timebases need noticably more space to
> >> >> > be stored in avi, thats not the case for other formats and thats
> >> >> > one reason why avi is treated as a special case.
> >> >> >
> >> >> > ill try to look tomorrow why its 100fps since the previous
> >> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> >> >> > 600 has ~6 times the overhead
> >> >>
> >> >> This regression is caused by ticks_per_frame beiing incorrect
> >> >>
> >> >> Ill send a patch to fix this
> >> >
> >> > patch attached
> >> >
> >>
> >> We don't have time_base in codecpar, so why do we need ticks per frame in
> >> it?
> >
> > We need both in some form probably
> > For this regression ticks_per_frame ATM is enough.
> > For time_base theres code to copy/access it bypassing codecpar
> >
> > The way it seems to be currently is that there are fields which
> > are needed and either they are
> > in codecpar or
> > theres some tricks to access them from code sheduled to be removed
> > (which will work only as long as the code isnt removed)
> > or things just dont work.
> >
> >
> >>
> >> Which time_base does it modify the interpretation of? The field should
> >> be bundled with that, then.
> >
> > the AVCodecContext one, ticks_per_frame is already in AVCodecContext
> > the AVCodecContext ticks_per_frame though is not exported after codecpar
> > while the codec timebase still is just not vissibly through codecpar
> >
>
> Maybe that part should be fixed then, wherever we export that to
> AVCodecContext, also set its ticks_per_frame properly?
> It just feels bad to export a property here that standing alone
> doesn't mean anything.
>
> So fix the export of ticks_per_frame for AVCodecContext, and if later
> on we decide we really do need time_base in AVCodecParameters, and
> can't fix whatever needs it differently, we can then include both in
> there.
attached
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
From: Michael Niedermayer
Date: Tue, 6 Sep 2016 18:10:41 +0200
Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
Suggested-by: Hendrik Leppkes
Signed-off-by: Michael Niedermayer
---
libavformat/utils.c | 4 +++-
tests/ref/fate/copy-trac4914 | 4 ++--
tests/ref/fate/copy-trac4914-avi | 4 ++--
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7d23c4a..76cbff4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3825,8 +3825,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
st->codec->height = st->internal->avctx->height;
}
-if (st->codec->codec_tag != MKTAG('t','m','c','d'))
+if (st->codec->codec_tag != MKTAG('t','m','c','d')) {
st->codec->time_base = st->internal->avctx->time_base;
+st->codec->ticks_per_frame = st->internal->avctx->ticks_per_frame;
+}
st->codec->framerate = st->avg_frame_rate;
if (st->internal->avctx->subtitle_header) {
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
[FFmpeg-devel] [PATCHv2] lavc/audiotoolboxdec: fix OSX SDK detection
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs
Signed-off-by: Dmitry Kalinkin
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 1097668..bf06cf9 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -32,7 +32,7 @@
#include "libavutil/opt.h"
#include "libavutil/log.h"
-#ifndef __MAC_10_11
+#if __MAC_OS_X_VERSION_MIN_REQUIRED < 101100
#define kAudioFormatEnhancedAC3 'ec-3'
#endif
--
2.7.4 (Apple Git-66)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/audiotoolboxdec: fix OSX SDK detection
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs
Signed-off-by: Dmitry Kalinkin
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 1097668..bba6913 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -32,7 +32,7 @@
#include "libavutil/opt.h"
#include "libavutil/log.h"
-#ifndef __MAC_10_11
+#ifndef __MAC_OS_X_VERSION_MIN_REQUIRED >= 101100
#define kAudioFormatEnhancedAC3 'ec-3'
#endif
--
2.7.4 (Apple Git-66)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/audiotoolboxdec: fix OSX SDK detection
> On 06 Sep 2016, at 00:05, Rodger Combs wrote:
>
>
>> On Sep 5, 2016, at 22:58, Dmitry Kalinkin wrote:
>>
>> __MAC_10_11 can be present in updated revision of an older SDK so it
>> can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
>>
>> Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
>> Cc: Rodger Combs
>> Signed-off-by: Dmitry Kalinkin
>> ---
>> libavcodec/audiotoolboxdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
>> index 1097668..bba6913 100644
>> --- a/libavcodec/audiotoolboxdec.c
>> +++ b/libavcodec/audiotoolboxdec.c
>> @@ -32,7 +32,7 @@
>> #include "libavutil/opt.h"
>> #include "libavutil/log.h"
>>
>> -#ifndef __MAC_10_11
>> +#ifndef __MAC_OS_X_VERSION_MIN_REQUIRED >= 101100
>> #define kAudioFormatEnhancedAC3 'ec-3'
>> #endif
>>
>> --
>> 2.7.4 (Apple Git-66)
>>
>
> We shouldn't use the MIN_REQUIRED macro here, since the runtime availability
> isn't affected by the minimum version we're building against.
> There might be a better macro available for this, but since the original
> definition is in an enum, our best bet might just be to make this #define
> unconditional.
My understanding was that MIN_REQUIRED is defined by -mmacosx-version-min and
SDK is chosen accordingly. Also if it’s a macro it can’t depend on runtime.
___
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
This patch addresses your concerns.
On Fri, Sep 2, 2016 at 5:05 PM, Michael Niedermayer
wrote:
> On Fri, Sep 02, 2016 at 03:31:21PM -0700, Brett Harrison wrote:
> > Addressed the following concerns.
> >
> > ===
> >
> > >libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
> > >libavfilter/vf_drawtext.c:422:5: warning: ISO C90 forbids mixed
> declarations and code [->Wdeclaration-after-statement]
> >
> > Fixed this.
> >
> > >also patch breaks:
> > >./ffmpeg -i m.mpg -vf >drawtext=fontfile=/usr/share/
> fonts/truetype/msttcorefonts/arial.ttf:text=a -f null -
> >
> > >[AVFilterGraph @ 0x37a6960] Error initializing filter 'drawtext' with
> args >'fontfile=/usr/share/fonts/truetype/msttcorefonts/arial.ttf:text=a'
> >
> > This is fixed.
> >
> > ===
> >
> > >>* +av_log(ctx, AV_LOG_ERROR, "Font not open\n");
> > *
> > >I was wondering: Was does this message tell the user?
> >
> > I changed this error to read "Unable to initialize font". This error
> > should only be seen if set_fontsize() is called before the font is
> > loaded. I don't think a user would be able to cause this because if
> > the font fails to load ffmpeg would error out before this. It is a
> > sanity check.
> >
> > ===
> >
> > For the concerns about multiple to many brackets on "if ((ret =
> > update_fontsize(ctx)))",
> >
> > I removed the "ret =" part as I wasn't using the value anyway.
> >
> >
> > On Fri, Sep 2, 2016 at 6:13 AM, Nicolas George wrote:
> >
> > > Le septidi 17 fructidor, an CCXXIV, Moritz Barsnick a écrit :
> > > > *Assuming* he means "assign update_fontsize()'s return value to ret,
> > > > and check whether ret is != 0", which would correspond to the more
> > > > verbose
> > > > if ((ret = update_fontsize(ctx)) != 0) {
> > > >
> > > > is it sufficient to say:
> > > > if (ret = update_fontsize(ctx)) {
> > > >
> > > > or is it required, or is it more readable or even desired by "style
> > > > guide" to say:
> > > > if ((ret = update_fontsize(ctx))) {
> > > > (to clarify it's a check of an assignment) - this is what Brett used,
> > >
> > > Ah. Parentheses over the whole expression are always optional, but in
> this
> > > particular case, there is a good reason:
> > >
> > > :4:1: warning: suggest parentheses around assignment used as
> truth
> > > value [-Wparentheses]
> > >
> > > Forgetting to double the equal in a comparison is a common mistake,
> > > compilers detect it. But then you need a way of stating when it is
> > > intentional.
> > >
> > > Regards,
> > >
> > > --
> > > Nicolas George
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > >
>
> > vf_drawtext.c | 125 ++
> +---
> > 1 file changed, 112 insertions(+), 13 deletions(-)
> > 311d60f04d959ddfd47ed8ea66d0f015725dd511 0001-added-expr-evaluation-to-
> drawtext-fontsize.patch
> > From 665b3f1c458222d64a9ba4f1c71d343766ee9e6b Mon Sep 17 00:00:00 2001
> > From: Brett Harrison
> > Date: Fri, 26 Aug 2016 14:29:34 -0700
> > Subject: [PATCH] added expr evaluation to drawtext - fontsize
> >
> > ---
> > libavfilter/vf_drawtext.c | 125 ++
> +++-
> > 1 file changed, 112 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index 214aef0..a483679 100644
> > --- a/libavfilter/vf_drawtext.c
> > +++ b/libavfilter/vf_drawtext.c
> > @@ -156,7 +156,10 @@ typedef struct DrawTextContext {
> > int max_glyph_h;///< max glyph height
> > int shadowx, shadowy;
> > int borderw;///< border width
> > +char *fontsize_expr;///< expression for fontsize
> > +AVExpr *fontsize_pexpr; ///< parsed expressions for fontsize
> > unsigned int fontsize; ///< font size to use
> > +unsigned int default_fontsize; ///< default font size to use
> >
> > short int draw_box; ///< draw box around text - true or
> false
> > int boxborderw; ///< box border width
> > @@ -209,7 +212,7 @@ static const AVOption drawtext_options[]= {
> > {"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),
> AV_OPT_TYPE_COLOR, {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"box", "set box", OFFSET(draw_box),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
> > {"boxborderw", "set box border width", OFFSET(boxborderw),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> > -{"fontsize","set font size",OFFSET(fontsize),
> AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
> > +{"fontsize","set font size",OFFSET(fontsize_expr),
> AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN, CHAR_MAX , FLAGS},
> > {"x", "set x expression", OFFSET(x_expr),
> AV_OPT_TYPE_STRING,
Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META
2016-09-06 15:07 GMT+02:00 Erkki Seppälä : > Would it be even better to not copy the data tracks at > all by default, so not set the .data_codec field for any > format? This was my original question for which I do not know the answer: If you feel it doesn't hurt not to copy the track I am all for not changing behaviour. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/matroskaenc: move skipped metadata keys to separate function
On Mon, Sep 05, 2016 at 10:26:26PM -0500, Rodger Combs wrote: > --- > libavformat/matroskaenc.c | 17 +++-- > 1 file changed, 11 insertions(+), 6 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/matroskaenc: skip writing "duration" tags
> On Sep 6, 2016, at 05:10, Carl Eugen Hoyos wrote: > > 2016-09-06 5:26 GMT+02:00 Rodger Combs : >> --- >> libavformat/matroskaenc.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c >> index decb66d..7deccaa 100644 >> --- a/libavformat/matroskaenc.c >> +++ b/libavformat/matroskaenc.c >> @@ -1314,6 +1314,7 @@ static int mkv_check_tag_name(const char *name, >> unsigned int elementid) >>av_strcasecmp(name, "stereo_mode") && >>av_strcasecmp(name, "creation_time") && >>av_strcasecmp(name, "encoding_tool") && >> + av_strcasecmp(name, "duration") && > > Could you elaborate? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 31852540 and 70c1647a add support for writing durations in the native matroska format. In the case of the global duration, this reads the value out of metadata when present (so writing it there as well would be redundant) and the metadata "duration" value in an actual MKV isn't read by anything anyway; for the stream durations, they're written as tags, so writing one from the metadata dict as well would create duplicate keys. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavf/matroskaenc: use mkv_check_tag_name consistently; update test
On Mon, Sep 05, 2016 at 10:26:28PM -0500, Rodger Combs wrote:
> ---
> libavformat/matroskaenc.c | 10 +-
> tests/fate/matroska.mak | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 7deccaa..3eeb09b 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1342,12 +1342,12 @@ static int mkv_write_tag(AVFormatContext *s,
> AVDictionary *m, unsigned int eleme
> return 0;
> }
>
> -static int mkv_check_tag(AVDictionary *m)
> +static int mkv_check_tag(AVDictionary *m, unsigned int elementid)
> {
> AVDictionaryEntry *t = NULL;
>
> while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX)))
> -if (av_strcasecmp(t->key, "title") && av_strcasecmp(t->key,
> "stereo_mode"))
> +if (mkv_check_tag_name(t->key, elementid))
> return 1;
>
> return 0;
> @@ -1361,7 +1361,7 @@ static int mkv_write_tags(AVFormatContext *s)
>
> ff_metadata_conv_ctx(s, ff_mkv_metadata_conv, NULL);
>
> -if (mkv_check_tag(s->metadata)) {
> +if (mkv_check_tag(s->metadata, 0)) {
> ret = mkv_write_tag(s, s->metadata, 0, 0, &tags);
> if (ret < 0) return ret;
> }
> @@ -1369,7 +1369,7 @@ static int mkv_write_tags(AVFormatContext *s)
> for (i = 0; i < s->nb_streams; i++) {
> AVStream *st = s->streams[i];
>
> -if (!mkv_check_tag(st->metadata))
> +if (!mkv_check_tag(st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID))
> continue;
>
> ret = mkv_write_tag(s, st->metadata,
> MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, &tags);
> @@ -1398,7 +1398,7 @@ static int mkv_write_tags(AVFormatContext *s)
> for (i = 0; i < s->nb_chapters; i++) {
> AVChapter *ch = s->chapters[i];
>
> -if (!mkv_check_tag(ch->metadata))
> +if (!mkv_check_tag(ch->metadata, MATROSKA_ID_TAGTARGETS_CHAPTERUID))
> continue;
>
> ret = mkv_write_tag(s, ch->metadata,
> MATROSKA_ID_TAGTARGETS_CHAPTERUID, ch->id + mkv->chapter_id_offset, &tags);
> diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
> index 8cf1734..8e4a1e8 100644
> --- a/tests/fate/matroska.mak
> +++ b/tests/fate/matroska.mak
> @@ -4,6 +4,6 @@
> FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
> fate-matroska-remux: CMD = md5 -i
> $(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v
> copy -fflags +bitexact -strict -2 -f matroska
> fate-matroska-remux: CMP = oneline
> -fate-matroska-remux: REF = 5ebcfaa8e3d534f8a800a58fd2b0aca6
> +fate-matroska-remux: REF = f08b20b90f158a4de5a02a52c25596b9
Please explain in the commit message why the checksum changes as well
as what effect this commit has
the commit message is a bit terse ...
[...]
--
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 2/3] lavf/matroskaenc: skip writing "duration" tags
On Mon, Sep 05, 2016 at 10:26:27PM -0500, Rodger Combs wrote: > --- > libavformat/matroskaenc.c | 1 + > 1 file changed, 1 insertion(+) no objection from me [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] af_hdcd: some types renamed to remove _t
On Mon, Sep 05, 2016 at 06:18:41AM -0500, Burt P wrote: > Following a suggestion by Diego Biurrun. > _t is reserved for POSIX, apparently. > > Signed-off-by: Burt P > --- > libavfilter/af_hdcd.c | 58 > +-- > 1 file changed, 29 insertions(+), 29 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- 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 3/5] af_hdcd: fix possible integer overflow
On Mon, Sep 05, 2016 at 06:18:43AM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
> index c8bda82..c249589 100644
> --- a/libavfilter/af_hdcd.c
> +++ b/libavfilter/af_hdcd.c
> @@ -1004,16 +1004,15 @@ AVFILTER_DEFINE_CLASS(hdcd);
> static void hdcd_reset(hdcd_state *state, unsigned rate, unsigned cdt_ms)
> {
> int i;
> +uint64_t sustain_reset = cdt_ms * rate / 1000;
this can still overflow
cdt_ms and rate are 32bit their product is 32bit divided by 1000
its around 22 bit, the 64bit is too late
>
> state->window = 0;
> state->readahead = 32;
> state->arg = 0;
> state->control = 0;
> -
> state->running_gain = 0;
> -
> +state->sustain_reset = sustain_reset;
> state->sustain = 0;
> -state->sustain_reset = cdt_ms*rate/1000;
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] af_hdcd: hdcd_analyze_gen() using int instead of float
On Mon, Sep 05, 2016 at 06:18:42AM -0500, Burt P wrote:
> Signed-off-by: Burt P
> ---
> libavfilter/af_hdcd.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
> index cde2340..c8bda82 100644
> --- a/libavfilter/af_hdcd.c
> +++ b/libavfilter/af_hdcd.c
> @@ -1316,11 +1316,10 @@ static void hdcd_analyze_prepare(hdcd_state *state,
> int32_t *samples, int count,
> /** encode a value in the given sample by adjusting the amplitude */
> static int32_t hdcd_analyze_gen(int32_t sample, unsigned int v, unsigned int
> maxv)
> {
> -float sflt = sample, vv = v;
> -vv /= maxv;
> -if (vv > 1.0) vv = 1.0;
> -sflt *= 1.0 + (vv * 18);
> -return (int32_t)sflt;
> +static const int r = 18, m = 1024;
> +int64_t s64 = sample;
> +v = m + (v * r * m / maxv);
maxv is always a constant (for each call) and division is slow, maybe
you want to replace it by multiplication by its inverse and adjust
the /m later (that is fast as m is a constant power of 2 in unsigned
context)
[...[
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/matroskaenc: use mkv_check_tag_name consistently
Previously, we used a different list of checks when deciding whether to
write a set of tags at all than we did when deciding whether to write an
individual tag in the set. This resulted in sometimes writing an empty
tag master and seekhead. Now we use mkv_check_tag_name everywhere, so
if a dictionary is entirely composed of tags we skip, we don't write a
tag master at all.
This affected the test file, since "language" was on one list but not
the other, so we were writing an empty tag master there. The test hash
is updated to reflect that change.
---
libavformat/matroskaenc.c | 10 +-
tests/fate/matroska.mak | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7deccaa..3eeb09b 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1342,12 +1342,12 @@ static int mkv_write_tag(AVFormatContext *s,
AVDictionary *m, unsigned int eleme
return 0;
}
-static int mkv_check_tag(AVDictionary *m)
+static int mkv_check_tag(AVDictionary *m, unsigned int elementid)
{
AVDictionaryEntry *t = NULL;
while ((t = av_dict_get(m, "", t, AV_DICT_IGNORE_SUFFIX)))
-if (av_strcasecmp(t->key, "title") && av_strcasecmp(t->key,
"stereo_mode"))
+if (mkv_check_tag_name(t->key, elementid))
return 1;
return 0;
@@ -1361,7 +1361,7 @@ static int mkv_write_tags(AVFormatContext *s)
ff_metadata_conv_ctx(s, ff_mkv_metadata_conv, NULL);
-if (mkv_check_tag(s->metadata)) {
+if (mkv_check_tag(s->metadata, 0)) {
ret = mkv_write_tag(s, s->metadata, 0, 0, &tags);
if (ret < 0) return ret;
}
@@ -1369,7 +1369,7 @@ static int mkv_write_tags(AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
AVStream *st = s->streams[i];
-if (!mkv_check_tag(st->metadata))
+if (!mkv_check_tag(st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID))
continue;
ret = mkv_write_tag(s, st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID,
i + 1, &tags);
@@ -1398,7 +1398,7 @@ static int mkv_write_tags(AVFormatContext *s)
for (i = 0; i < s->nb_chapters; i++) {
AVChapter *ch = s->chapters[i];
-if (!mkv_check_tag(ch->metadata))
+if (!mkv_check_tag(ch->metadata, MATROSKA_ID_TAGTARGETS_CHAPTERUID))
continue;
ret = mkv_write_tag(s, ch->metadata,
MATROSKA_ID_TAGTARGETS_CHAPTERUID, ch->id + mkv->chapter_id_offset, &tags);
diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
index 8cf1734..8e4a1e8 100644
--- a/tests/fate/matroska.mak
+++ b/tests/fate/matroska.mak
@@ -4,6 +4,6 @@
FATE_MATROSKA-$(call DEMMUX, MATROSKA, MATROSKA) += fate-matroska-remux
fate-matroska-remux: CMD = md5 -i
$(TARGET_SAMPLES)/vp9-test-vectors/vp90-2-2pass-akiyo.webm -color_trc 4 -c:v
copy -fflags +bitexact -strict -2 -f matroska
fate-matroska-remux: CMP = oneline
-fate-matroska-remux: REF = 5ebcfaa8e3d534f8a800a58fd2b0aca6
+fate-matroska-remux: REF = f08b20b90f158a4de5a02a52c25596b9
FATE_SAMPLES_AVCONV += $(FATE_MATROSKA-yes)
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskaenc: use mkv_check_tag_name consistently
On Tue, Sep 06, 2016 at 05:13:52PM -0500, Rodger Combs wrote: > Previously, we used a different list of checks when deciding whether to > write a set of tags at all than we did when deciding whether to write an > individual tag in the set. This resulted in sometimes writing an empty > tag master and seekhead. Now we use mkv_check_tag_name everywhere, so > if a dictionary is entirely composed of tags we skip, we don't write a > tag master at all. > > This affected the test file, since "language" was on one list but not > the other, so we were writing an empty tag master there. The test hash > is updated to reflect that change. > --- > libavformat/matroskaenc.c | 10 +- > tests/fate/matroska.mak | 2 +- > 2 files changed, 6 insertions(+), 6 deletions(-) excelent commit message LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] adding RGBA and BGRA to nvenc.c
Hello,
I haven't been sending patches in ages. Can somebody walk me through?
The patch is a "low hanging fruit" and simply adds the pixel formats RGBA and
BGRA to the Nvidia encoder "nvenc", which supports these two formats natively.
The gain here is that when one grabs the screen with x11grab and chains it
through the encoder does it no longer require a RGB->YUV conversion and so
speeds up live streaming (i.e. from 47fp/s to 62fp/s).
Note the twist in AV_PIX_FMT_RGBA versus NV_ENC_BUFFER_FORMAT_ABGR. This is
intentionally.
Thanks,
Sven
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,8 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
AV_PIX_FMT_P010,
AV_PIX_FMT_YUV444P,
AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
#if CONFIG_CUDA
AV_PIX_FMT_CUDA,
#endif
@@ -1032,6 +1034,14 @@ static av_cold int nvenc_alloc_surface(AVCodecContext
*avctx, int idx)
ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
break;
+case AV_PIX_FMT_RGBA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
+case AV_PIX_FMT_BGRA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
default:
av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
return AVERROR(EINVAL);
@@ -1350,6 +1360,14 @@ static int nvenc_copy_frame(AVCodecContext *avctx,
NvencSurface *inSurf,
av_image_copy_plane(buf, lockBufferParams->pitch,
frame->data[2], frame->linesize[2],
avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGBA) {
+ av_image_copy_plane(buf, lockBufferParams->pitch,
+ frame->data[0], frame->linesize[0],
+ avctx->width << 2, avctx->height);
+} else if (frame->format == AV_PIX_FMT_BGRA) {
+ av_image_copy_plane(buf, lockBufferParams->pitch,
+ frame->data[0], frame->linesize[0],
+ avctx->width << 2, avctx->height);
} else {
av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
return AVERROR(EINVAL);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c
Hi! 2016-09-07 1:02 GMT+02:00 Sven C. Dack : > +case AV_PIX_FMT_RGBA: Should be AV_PIX_FMT_RGB0... > +ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR; > +break; > + > +case AV_PIX_FMT_BGRA: ... and AV_PIX_FMT_BGR0 > +ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB; Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c
On 07/09/16 00:43, Carl Eugen Hoyos wrote: Should be AV_PIX_FMT_RGB0... ... and AV_PIX_FMT_BGR0 I was wondering about that. The 0 means undefined/unused and I didn't want to open a can of worms with it. Should I add BGR0 and RGB0, too? Does the 0 mean it is reliably 0? Sven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c
On 07/09/16 01:08, Sven C. Dack wrote:
On 07/09/16 00:43, Carl Eugen Hoyos wrote:
Should be AV_PIX_FMT_RGB0...
... and AV_PIX_FMT_BGR0
I was wondering about that. The 0 means undefined/unused and I didn't want to
open a can of worms with it. Should I add BGR0 and RGB0, too? Does the 0 mean
it is reliably 0?
Just tested it with BGR0 and RGB0 and it does encode at ~100 fp/s from the
screen with it.
$ ffmpeg -f x11grab -framerate 333 -s 1920x1080 -i :0.0 -c:v hevc_nvenc -b:v
4096k -y test.mkv
Sven
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,10 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
AV_PIX_FMT_P010,
AV_PIX_FMT_YUV444P,
AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_RGB0,
+AV_PIX_FMT_BGR0,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
#if CONFIG_CUDA
AV_PIX_FMT_CUDA,
#endif
@@ -1032,6 +1036,16 @@ static av_cold int nvenc_alloc_surface(AVCodecContext
*avctx, int idx)
ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
break;
+case AV_PIX_FMT_RGB0:
+case AV_PIX_FMT_RGBA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
+case AV_PIX_FMT_BGR0:
+case AV_PIX_FMT_BGRA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
default:
av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
return AVERROR(EINVAL);
@@ -1350,6 +1364,14 @@ static int nvenc_copy_frame(AVCodecContext *avctx,
NvencSurface *inSurf,
av_image_copy_plane(buf, lockBufferParams->pitch,
frame->data[2], frame->linesize[2],
avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGBA || frame->format ==
AV_PIX_FMT_RGB0) {
+ av_image_copy_plane(buf, lockBufferParams->pitch,
+ frame->data[0], frame->linesize[0],
+ avctx->width << 2, avctx->height);
+} else if (frame->format == AV_PIX_FMT_BGRA || frame->format ==
AV_PIX_FMT_BGR0) {
+ av_image_copy_plane(buf, lockBufferParams->pitch,
+ frame->data[0], frame->linesize[0],
+ avctx->width << 2, avctx->height);
} else {
av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
return AVERROR(EINVAL);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: Enable header parsing for VP9.
Hi, The attached patch fixes playback of MP4/VP9 media containing superframes when using the built-in VP9 decoder. As an example, https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv plays with corrupted frames using ffplay without this patch and works fine with the patch applied (or with libvpx built with --enable-vp9-highbitdepth forced via -vcodec libvpx). Cheers, >From 561c7e9ad45384437124d2d7293c15bfa3712ebb Mon Sep 17 00:00:00 2001 From: Matthew Gregan Date: Wed, 7 Sep 2016 13:58:30 +1200 Subject: avformat/mov: Enable header parsing for VP9. MP4 media containing VP9 using superframes (such as https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv) does not decode correctly with the built-in VP9 decoder because superframes are passed to the decoder whole rather than split into individual frames. Signed-off-by: Matthew Gregan diff --git a/libavformat/mov.c b/libavformat/mov.c index f499906..faa682a 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2163,6 +2163,9 @@ static int mov_finalize_stsd_codec(MOVContext *c, AVIOContext *pb, case AV_CODEC_ID_VC1: st->need_parsing = AVSTREAM_PARSE_FULL; break; +case AV_CODEC_ID_VP9: +st->need_parsing = AVSTREAM_PARSE_HEADERS; +break; default: break; } -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable header parsing for VP9.
Hi Matthew, On Tue, Sep 6, 2016 at 10:10 PM, Matthew Gregan wrote: > Hi, > > The attached patch fixes playback of MP4/VP9 media containing superframes > when using the built-in VP9 decoder. > > As an example, > https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_ > 0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv > plays with corrupted frames using ffplay without this patch and works fine > with the patch applied (or with libvpx built with --enable-vp9-highbitdepth > forced via -vcodec libvpx). I think the patch is fine, but I wonder if it should set it to _FULL (the parser ignores the option, but it is semantically more correct). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable stream parsing for VP9.
At 2016-09-06T22:18:18-0400, Ronald S. Bultje wrote: > I think the patch is fine, but I wonder if it should set it to _FULL (the > parser ignores the option, but it is semantically more correct). Good point, thanks for the feedback. Updated (simpler!) patch attached. Cheers, >From a9d69f145bb92939c1ffce11a0522d76857f Mon Sep 17 00:00:00 2001 From: Matthew Gregan Date: Wed, 7 Sep 2016 13:58:30 +1200 Subject: avformat/mov: Enable stream parsing for VP9. MP4 media containing VP9 using superframes (such as https://github.com/Netflix/vp9-dash/raw/master/DASH-Samples/Fountain_2997_0560kbps_640x480_4x3PAR.ivf_DashUnencrypted.ismv) does not decode correctly with the built-in VP9 decoder because superframes are passed to the decoder whole rather than split into individual frames. Signed-off-by: Matthew Gregan diff --git a/libavformat/mov.c b/libavformat/mov.c index f499906..fa4e016 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2161,6 +2161,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, AVIOContext *pb, case AV_CODEC_ID_EAC3: case AV_CODEC_ID_MPEG1VIDEO: case AV_CODEC_ID_VC1: +case AV_CODEC_ID_VP9: st->need_parsing = AVSTREAM_PARSE_FULL; break; default: -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
