Re: [FFmpeg-devel] [PATCH] doc/filters: update SITI description

2023-03-02 Thread Werner Robitza 
On Thu, Mar 2, 2023 at 7:02 PM Thilo Borgmann  wrote:
>
> Am 01.03.23 um 08:46 schrieb Werner Robitza:
> > On Wed, Mar 1, 2023 at 1:15 AM Thilo Borgmann  
> > wrote:
> >>
> >> Am 28.02.23 um 18:12 schrieb Werner Robitza:
> >>> On Tue, Feb 28, 2023 at 2:16 PM Thilo Borgmann  
> >>> wrote:
> >>>>
> >>>> Am 28.02.23 um 14:13 schrieb Thilo Borgmann:
> >>>>> Am 28.02.23 um 12:42 schrieb Werner Robitza:
> >>>>>> The filter implements the 'legacy' version from a superseded 
> >>>>>> recommendation.
> >>>>>> ---
> >>>>>> doc/filters.texi | 8 +---
> >>>>>> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>>>>>
> >>>>>> diff --git a/doc/filters.texi b/doc/filters.texi
> >>>>>> index 47e92b9269..25574cd55c 100644
> >>>>>> --- a/doc/filters.texi
> >>>>>> +++ b/doc/filters.texi
> >>>>>> @@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv 
> >>>>>> -filter_complex "[0:v][1:v] signature=nb_inpu
> >>>>>> @anchor{siti}
> >>>>>> @section siti
> >>>>>> -Calculate Spatial Info (SI) and Temporal Info (TI) scores for a 
> >>>>>> video, as defined
> >>>>>> -in ITU-T P.910: Subjective video quality assessment methods for 
> >>>>>> multimedia
> >>>>>> -applications. Available PDF at 
> >>>>>> @url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
> >>>>>> +Calculate Spatial Information (SI) and Temporal Information (TI) 
> >>>>>> scores for a video,
> >>>>>> +as defined in ITU-T Rec. P.910 (11/21): Subjective video quality 
> >>>>>> assessment methods
> >>>>>> +for multimedia applications. Available PDF at 
> >>>>>> @url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
> >>>>>> +Note that this is a legacy implementation that corresponds to a 
> >>>>>> superseded recommendation.
> >>>>>> +Refer to ITU-T Rec. P.910 (07/22) for the latest version.
> >>>>>> It accepts the following option:
> >>>>>
> >>>>> Ok.
> >>>>
> >>>> You might want to add the URL of the current spec, though:
> >>>> https://www.itu.int/rec/T-REC-P.910-202207-I/en
> >>>
> >>> Sure, patch attached.
> >>
> >> Looks better but wait - why did you change the implemented version from 
> >> 09/99 to 11/21 in the first place?
> >> (Does this not even make it more wrong?)
> >
> > No, as the (legacy) definition of SI/TI is the same, no matter if you
> > are using the version from '99 or '21. It was only changed in '22.
> > But it is common practice to refer to the latest versions of ITU-T
> > recommendations where possible.
> > (If only to avoid people looking at really outdated versions and then
> > citing/using something from those.)
>
> Pushed.

Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] doc/filters: update SITI description

2023-02-28 Thread Werner Robitza 
On Wed, Mar 1, 2023 at 1:15 AM Thilo Borgmann  wrote:
>
> Am 28.02.23 um 18:12 schrieb Werner Robitza:
> > On Tue, Feb 28, 2023 at 2:16 PM Thilo Borgmann  
> > wrote:
> >>
> >> Am 28.02.23 um 14:13 schrieb Thilo Borgmann:
> >>> Am 28.02.23 um 12:42 schrieb Werner Robitza:
> >>>> The filter implements the 'legacy' version from a superseded 
> >>>> recommendation.
> >>>> ---
> >>>>doc/filters.texi | 8 +---
> >>>>1 file changed, 5 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/doc/filters.texi b/doc/filters.texi
> >>>> index 47e92b9269..25574cd55c 100644
> >>>> --- a/doc/filters.texi
> >>>> +++ b/doc/filters.texi
> >>>> @@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv 
> >>>> -filter_complex "[0:v][1:v] signature=nb_inpu
> >>>>@anchor{siti}
> >>>>@section siti
> >>>> -Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, 
> >>>> as defined
> >>>> -in ITU-T P.910: Subjective video quality assessment methods for 
> >>>> multimedia
> >>>> -applications. Available PDF at 
> >>>> @url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
> >>>> +Calculate Spatial Information (SI) and Temporal Information (TI) scores 
> >>>> for a video,
> >>>> +as defined in ITU-T Rec. P.910 (11/21): Subjective video quality 
> >>>> assessment methods
> >>>> +for multimedia applications. Available PDF at 
> >>>> @url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
> >>>> +Note that this is a legacy implementation that corresponds to a 
> >>>> superseded recommendation.
> >>>> +Refer to ITU-T Rec. P.910 (07/22) for the latest version.
> >>>>It accepts the following option:
> >>>
> >>> Ok.
> >>
> >> You might want to add the URL of the current spec, though:
> >> https://www.itu.int/rec/T-REC-P.910-202207-I/en
> >
> > Sure, patch attached.
>
> Looks better but wait - why did you change the implemented version from 09/99 
> to 11/21 in the first place?
> (Does this not even make it more wrong?)

No, as the (legacy) definition of SI/TI is the same, no matter if you
are using the version from '99 or '21. It was only changed in '22.
But it is common practice to refer to the latest versions of ITU-T
recommendations where possible.
(If only to avoid people looking at really outdated versions and then
citing/using something from those.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] doc/filters: update SITI description

2023-02-28 Thread Werner Robitza 
On Tue, Feb 28, 2023 at 2:16 PM Thilo Borgmann  wrote:
>
> Am 28.02.23 um 14:13 schrieb Thilo Borgmann:
> > Am 28.02.23 um 12:42 schrieb Werner Robitza:
> >> The filter implements the 'legacy' version from a superseded 
> >> recommendation.
> >> ---
> >>   doc/filters.texi | 8 +---
> >>   1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/doc/filters.texi b/doc/filters.texi
> >> index 47e92b9269..25574cd55c 100644
> >> --- a/doc/filters.texi
> >> +++ b/doc/filters.texi
> >> @@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv 
> >> -filter_complex "[0:v][1:v] signature=nb_inpu
> >>   @anchor{siti}
> >>   @section siti
> >> -Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
> >> defined
> >> -in ITU-T P.910: Subjective video quality assessment methods for multimedia
> >> -applications. Available PDF at 
> >> @url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
> >> +Calculate Spatial Information (SI) and Temporal Information (TI) scores 
> >> for a video,
> >> +as defined in ITU-T Rec. P.910 (11/21): Subjective video quality 
> >> assessment methods
> >> +for multimedia applications. Available PDF at 
> >> @url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
> >> +Note that this is a legacy implementation that corresponds to a 
> >> superseded recommendation.
> >> +Refer to ITU-T Rec. P.910 (07/22) for the latest version.
> >>   It accepts the following option:
> >
> > Ok.
>
> You might want to add the URL of the current spec, though:
> https://www.itu.int/rec/T-REC-P.910-202207-I/en

Sure, patch attached.


0001-doc-filters-update-SITI-description.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] doc/filters: update SITI description

2023-02-28 Thread Werner Robitza 
The filter implements the 'legacy' version from a superseded recommendation.
---
 doc/filters.texi | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 47e92b9269..25574cd55c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21593,9 +21593,11 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex 
"[0:v][1:v] signature=nb_inpu
 @anchor{siti}
 @section siti
 
-Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
defined
-in ITU-T P.910: Subjective video quality assessment methods for multimedia
-applications. Available PDF at 
@url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
+Calculate Spatial Information (SI) and Temporal Information (TI) scores for a 
video,
+as defined in ITU-T Rec. P.910 (11/21): Subjective video quality assessment 
methods
+for multimedia applications. Available PDF at 
@url{https://www.itu.int/rec/T-REC-P.910-202111-S/en}.
+Note that this is a legacy implementation that corresponds to a superseded 
recommendation.
+Refer to ITU-T Rec. P.910 (07/22) for the latest version.
 
 It accepts the following option:
 
-- 
2.39.2

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale: fix deprecation message for JPEG

2021-12-05 Thread Werner Robitza 
On Wed, Nov 24, 2021 at 12:57 PM Werner Robitza
 wrote:
>
> This message frequently confuses end users, making them think that they are
> doing something wrong [1].
>
> The fact that the "J" format itself is deprecated should not be bothering
> the end users.
>
> Since the format can only be changed when the handle_jpeg() function is
> called, this means we can tell the users about the fact that the JPEG
> conversion is causing this, and that they should check the range.
>
> [1]: https://superuser.com/q/1273920/48078
> [2]: https://superuser.com/q/1663477/48078
>
> Signed-off-by: Werner Robitza 
> ---
>  libswscale/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index c726922527..78f84d990a 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -1291,7 +1291,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter 
> *srcFilter,
>  c->dstRange |= handle_jpeg(>dstFormat);
>
>  if(srcFormat!=c->srcFormat || dstFormat!=c->dstFormat)
> -av_log(c, AV_LOG_WARNING, "deprecated pixel format used, make sure 
> you did set range correctly\n");
> +av_log(c, AV_LOG_WARNING, "pixel format was changed automatically 
> for JPEG, make sure the color range is set correctly\n");
>
>  if (!c->contrast && !c->saturation && !c->dstFormatBpp)
>  sws_setColorspaceDetails(c, ff_yuv2rgb_coeffs[SWS_CS_DEFAULT], 
> c->srcRange,
> --
> 2.33.1
>

Any feedback would be much appreciated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] swscale: fix deprecation message for JPEG

2021-11-24 Thread Werner Robitza 
This message frequently confuses end users, making them think that they are
doing something wrong [1].

The fact that the "J" format itself is deprecated should not be bothering
the end users.

Since the format can only be changed when the handle_jpeg() function is
called, this means we can tell the users about the fact that the JPEG
conversion is causing this, and that they should check the range.

[1]: https://superuser.com/q/1273920/48078
[2]: https://superuser.com/q/1663477/48078

Signed-off-by: Werner Robitza 
---
 libswscale/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswscale/utils.c b/libswscale/utils.c
index c726922527..78f84d990a 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1291,7 +1291,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter 
*srcFilter,
 c->dstRange |= handle_jpeg(>dstFormat);
 
 if(srcFormat!=c->srcFormat || dstFormat!=c->dstFormat)
-av_log(c, AV_LOG_WARNING, "deprecated pixel format used, make sure you 
did set range correctly\n");
+av_log(c, AV_LOG_WARNING, "pixel format was changed automatically for 
JPEG, make sure the color range is set correctly\n");
 
 if (!c->contrast && !c->saturation && !c->dstFormatBpp)
 sws_setColorspaceDetails(c, ff_yuv2rgb_coeffs[SWS_CS_DEFAULT], 
c->srcRange,
-- 
2.33.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
On Thu, Feb 25, 2021 at 12:47 PM Nicolas George  wrote:
> Werner Robitza (12021-02-25):
> > After fiddling around a bit, when I run:
> >
> > ffprobe -loglevel error -f lavfi -i "testsrc,signalstats"
> > -show_entries tags -of csv=nk=0 | head -n 1
> >
> > I get a line like:
> >
> > packet,tag:lavfi.signalstats.YMIN=16,tag:lavfi.signalstats.YLOW=16,…
>
> I doubt ffprobe did output an ellipsis character on its own.

That's why I wrote "like" – I am sure you were able to interpret the
meaning of the ellipsis in this example.

> For simpler parsing, use a different writer than csv. I would recommend
> flat.

That seems to be a custom format, so parsing is inherently more
complex, and there's no support for simply loading this in whatever
tool you have for data analysis (Excel, MATLAB, R, Python, …). Hence
the usefulness of semantically meaningfully structured CSV.

I guess I could live with replacing the "flat" output dots with
commas, and the equal sign with another comma, but that's bound to
break with some metadata value contents.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
On Thu, Feb 25, 2021 at 11:26 AM Nicolas George  wrote:
> Werner Robitza (12021-02-24):
> > I didn't really duplicate anything; this was mostly from scratch. The
> > case could be made that a function for escaping CSV could be shared.
>
> The variable names seemed quite similar. Anyway, duplicating a feature
> is just as bad as duplicating code.

Would you accept this patch if this particular function was extracted
to an API and re-used by ffprobe? (And potentially segment.c …)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
On Thu, Feb 25, 2021 at 11:25 AM Nicolas George  wrote:
>
> Werner Robitza (12021-02-25):
> > If you are referring to:
> >
> > -vf your_filter,metadata=mode=print
> >
> > That does not work in ffprobe.
>
> Of course, since ffprobe does the printing for you.

At the risk of repeating the same question, could you please show a
command with ffprobe that achieves the same kind of parsable output
that this patch generates?

After fiddling around a bit, when I run:

ffprobe -loglevel error -f lavfi -i "testsrc,signalstats"
-show_entries tags -of csv=nk=0 | head -n 1

I get a line like:

packet,tag:lavfi.signalstats.YMIN=16,tag:lavfi.signalstats.YLOW=16,…

which is not semantically meaningful, since both keys and values are
contained in the individual cells. This makes parsing incredibly more
complex than it has to be.

> > For instance, using the patch I submitted, I can get easy to parse output 
> > like:
>
> Parsing the standard output of any program is bad design and bound to
> break at some point.

That was just an example on the CLI. The filter has a file option with
which you can output to a well-formatted CSV file, so parsing is not
an issue there.

> Also, I wonder why you chose CSV, which is one of the worse possible
> formats.

I feel this is only tangential to the discussion, but: It's
well-defined, easy to parse by numerous libraries, can be modified
easily, and is a de-facto standard for sharing data in certain
communities (. It wouldn't even occur to me why you'd want another
format for certain kinds of applications. In particular with data that
isn't nested, it's much easier to use in data analysis procedures than
JSON or others.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
On Thu, Feb 25, 2021 at 1:32 AM Paul B Mahol  wrote:
> On Wed, Feb 24, 2021 at 9:48 PM Werner Robitza  
> wrote:
>> Could please show an example on how to achieve this with ffprobe?
> See same thread where I replied or use search.

If you are referring to:

-vf your_filter,metadata=mode=print

That does not work in ffprobe.

For instance, using the patch I submitted, I can get easy to parse output like:

$ ffmpeg -f lavfi -i testsrc -frames:v 1 -filter:v
signalstats,metadata=mode=print:format=csv -f null /dev/null
frame,pts,pts_time,key,value
0,0,0,lavfi.signalstats.YMIN,4
…

How would I get the same with ffprobe?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
On Thu, Feb 25, 2021 at 9:34 AM Werner Robitza  wrote:
>
> This adds a new option to the metadata filter that allows outputting CSV data.
> The separator can be set via another option.
> Special characters are handled via escaping.

Fixed a newline bug and removed unused function.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-25 Thread Werner Robitza 
This adds a new option to the metadata filter that allows outputting CSV data.
The separator can be set via another option.
Special characters are handled via escaping.

Signed-off-by: Werner Robitza 
---
 doc/filters.texi |  14 
 libavfilter/f_metadata.c | 155 ---
 2 files changed, 158 insertions(+), 11 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 426cb158da..0b56d73565 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -25134,6 +25134,20 @@ with AV_LOG_INFO loglevel.
 @item direct
 Reduces buffering in print mode when output is written to a URL set using 
@var{file}.
 
+@item format
+Set the output format for the print mode.
+
+@table @samp
+@item default
+Default output format
+
+@item csv
+Comma-separated output
+@end table
+
+@item csv_sep
+Set the CSV separator (only valid for CSV format). Default is @code{,}. Must be
+one character and cannot be a period (@code{.}).
 @end table
 
 @subsection Examples
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 598257b15b..45f5eeddcd 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -58,6 +58,11 @@ enum MetadataFunction {
 METADATAF_NB
 };
 
+enum MetadataFormat {
+METADATA_FORMAT_DEFAULT,
+METADATA_FORMAT_CSV
+};
+
 static const char *const var_names[] = {
 "VALUE1",
 "VALUE2",
@@ -85,6 +90,9 @@ typedef struct MetadataContext {
 AVIOContext* avio_context;
 char *file_str;
 
+int format;
+char *csv_sep;
+
 int (*compare)(struct MetadataContext *s,
const char *value1, const char *value2);
 void (*print)(AVFilterContext *ctx, const char *msg, ...) 
av_printf_format(2, 3);
@@ -114,6 +122,10 @@ static const AVOption filt_name##_options[] = { \
 { "expr", "set expression for expr function", OFFSET(expr_str), 
AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, FLAGS }, \
 { "file", "set file where to print metadata information", 
OFFSET(file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS }, \
 { "direct", "reduce buffering when printing to user-set file or pipe", 
OFFSET(direct), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS }, \
+{ "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT, {.i64 = 
0 }, 0, METADATAF_NB-1, FLAGS, "format" }, \
+{   "default", "default format",  0, AV_OPT_TYPE_CONST, {.i64 = 
METADATA_FORMAT_DEFAULT }, 0, 0, FLAGS, "format" }, \
+{   "csv", "comma-separated", 0, AV_OPT_TYPE_CONST, {.i64 = 
METADATA_FORMAT_CSV }, 0, 0, FLAGS, "format" }, \
+{ "csv_sep", "set CSV separator (only valid for CSV format)", 
OFFSET(csv_sep), AV_OPT_TYPE_STRING, {.str=","},  0, 0, FLAGS }, \
 { NULL } \
 }
 
@@ -202,6 +214,58 @@ static void print_file(AVFilterContext *ctx, const char 
*msg, ...)
 va_end(argument_list);
 }
 
+static void print_csv_escaped(AVFilterContext *ctx, const char *src)
+{
+MetadataContext *s = ctx->priv;
+
+char meta_chars[] = {s->csv_sep[0], '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+// allocate space for two extra quotes and possibly every char escaped
+char buf[strlen(src) * 2 + 2];
+
+int pos = 0;
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++) {
+if (src[i] == '"')
+buf[pos++] = '\"';
+buf[pos++] = src[i];
+}
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+buf[pos] = '\0';
+
+s->print(ctx, "%s", buf);
+}
+
+static void csv_escape(const char *src, char **dst, const char csv_sep)
+{
+char meta_chars[] = {csv_sep, '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+int pos = 0;
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++)
+{
+if (src[i] == '"')
+*dst[pos++] = '\"';
+*dst[pos++] = src[i];
+}
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+*dst[pos] = '\0';
+}
+
 static av_cold int init(AVFilterContext *ctx)
 {
 MetadataContext *s = ctx->priv;
@@ -282,6 +346,33 @@ static av_cold int init(AVFilterContext *ctx)
 s->avio_context->direct = AVIO_FLAG_DIRECT;
 }
 
+if (s->format == METADATA_FORMAT_CSV) {
+if (strlen(s->csv_sep) == 0) {
+av_log(ctx, AV_LOG_ERROR,
+   "No CSV separator supplied\n");
+return AVERROR(EINVAL);
+}
+if (strlen(s->csv_sep) > 1) {
+av_log(ctx, AV_LOG_ERROR,
+   "CSV separator must be one character only\n");
+return AVERROR(EINVAL);
+}
+if (s->

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-24 Thread Werner Robitza 
On Wed, Feb 24, 2021 at 9:51 PM Nicolas George  wrote:
> I never told you to duplicate code. Code duplication is almost always a
> motive for rejection.
>
> If you are tempted to duplicate code, what you need to do is to share it
> between the various places that use it. Making it a proper API if
> relevant.

I didn't really duplicate anything; this was mostly from scratch. The
case could be made that a function for escaping CSV could be shared.
There are at least two such functions already in the code base.

> Ideally, all the writers of ffprobe should be turned into a single
> libavutil API for use in all components that need to output data.

That'd make sense.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-24 Thread Werner Robitza 
On Wed, Feb 24, 2021 at 9:11 PM Paul B Mahol  wrote:
>
> Why duplicating code that would give same output as ffprobe?

I was told to here:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/275510.html

Could please show an example on how to achieve this with ffprobe?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] filters/metadata: add CSV output support

2021-02-24 Thread Werner Robitza 
This adds a new option to the metadata filter that allows outputting CSV data.
The separator can be set via another option.
Special characters are handled via escaping.

Signed-off-by: Werner Robitza 
---
 doc/filters.texi |  14 
 libavfilter/f_metadata.c | 155 ---
 2 files changed, 158 insertions(+), 11 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 426cb158da..0b56d73565 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -25134,6 +25134,20 @@ with AV_LOG_INFO loglevel.
 @item direct
 Reduces buffering in print mode when output is written to a URL set using 
@var{file}.
 
+@item format
+Set the output format for the print mode.
+
+@table @samp
+@item default
+Default output format
+
+@item csv
+Comma-separated output
+@end table
+
+@item csv_sep
+Set the CSV separator (only valid for CSV format). Default is @code{,}. Must be
+one character and cannot be a period (@code{.}).
 @end table
 
 @subsection Examples
diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 598257b15b..45f5eeddcd 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -58,6 +58,11 @@ enum MetadataFunction {
 METADATAF_NB
 };
 
+enum MetadataFormat {
+METADATA_FORMAT_DEFAULT,
+METADATA_FORMAT_CSV
+};
+
 static const char *const var_names[] = {
 "VALUE1",
 "VALUE2",
@@ -85,6 +90,9 @@ typedef struct MetadataContext {
 AVIOContext* avio_context;
 char *file_str;
 
+int format;
+char *csv_sep;
+
 int (*compare)(struct MetadataContext *s,
const char *value1, const char *value2);
 void (*print)(AVFilterContext *ctx, const char *msg, ...) 
av_printf_format(2, 3);
@@ -114,6 +122,10 @@ static const AVOption filt_name##_options[] = { \
 { "expr", "set expression for expr function", OFFSET(expr_str), 
AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, FLAGS }, \
 { "file", "set file where to print metadata information", 
OFFSET(file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS }, \
 { "direct", "reduce buffering when printing to user-set file or pipe", 
OFFSET(direct), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS }, \
+{ "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT, {.i64 = 
0 }, 0, METADATAF_NB-1, FLAGS, "format" }, \
+{   "default", "default format",  0, AV_OPT_TYPE_CONST, {.i64 = 
METADATA_FORMAT_DEFAULT }, 0, 0, FLAGS, "format" }, \
+{   "csv", "comma-separated", 0, AV_OPT_TYPE_CONST, {.i64 = 
METADATA_FORMAT_CSV }, 0, 0, FLAGS, "format" }, \
+{ "csv_sep", "set CSV separator (only valid for CSV format)", 
OFFSET(csv_sep), AV_OPT_TYPE_STRING, {.str=","},  0, 0, FLAGS }, \
 { NULL } \
 }
 
@@ -202,6 +214,58 @@ static void print_file(AVFilterContext *ctx, const char 
*msg, ...)
 va_end(argument_list);
 }
 
+static void print_csv_escaped(AVFilterContext *ctx, const char *src)
+{
+MetadataContext *s = ctx->priv;
+
+char meta_chars[] = {s->csv_sep[0], '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+// allocate space for two extra quotes and possibly every char escaped
+char buf[strlen(src) * 2 + 2];
+
+int pos = 0;
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++) {
+if (src[i] == '"')
+buf[pos++] = '\"';
+buf[pos++] = src[i];
+}
+
+if (needs_quoting)
+buf[pos++] = '"';
+
+buf[pos] = '\0';
+
+s->print(ctx, "%s", buf);
+}
+
+static void csv_escape(const char *src, char **dst, const char csv_sep)
+{
+char meta_chars[] = {csv_sep, '"', '\n', '\r', '\0'};
+int needs_quoting = !!src[strcspn(src, meta_chars)];
+
+int pos = 0;
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+for (int i = 0; i < strlen(src); i++)
+{
+if (src[i] == '"')
+*dst[pos++] = '\"';
+*dst[pos++] = src[i];
+}
+
+if (needs_quoting)
+*dst[pos++] = '"';
+
+*dst[pos] = '\0';
+}
+
 static av_cold int init(AVFilterContext *ctx)
 {
 MetadataContext *s = ctx->priv;
@@ -282,6 +346,33 @@ static av_cold int init(AVFilterContext *ctx)
 s->avio_context->direct = AVIO_FLAG_DIRECT;
 }
 
+if (s->format == METADATA_FORMAT_CSV) {
+if (strlen(s->csv_sep) == 0) {
+av_log(ctx, AV_LOG_ERROR,
+   "No CSV separator supplied\n");
+return AVERROR(EINVAL);
+}
+if (strlen(s->csv_sep) > 1) {
+av_log(ctx, AV_LOG_ERROR,
+   "CSV separator must be one character only\n");
+return AVERROR(EINVAL);
+}
+if (s->

Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter

2021-02-19 Thread Werner Robitza 
On Fri, Feb 19, 2021 at 9:02 PM Werner Robitza  wrote:
> In particular, such output should be tidy [1]. For instance, you don't
> want to output "frame, key, value" with lines "1, si, 53.999", but
> rather "frame, si, ti". Such transformations to useful/parsable output
> must be done in the filter itself, not vf_metadata …

Well, looking at it again, one could transform per-frame values,
turning each key into a column, so it could work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter

2021-02-19 Thread Werner Robitza 
On Mon, Feb 1, 2021 at 4:57 PM Nicolas George  wrote:
>
> Werner Robitza (12021-01-22):
> > Thanks, I know this, but this is not a known format that can be easily
> > parsed like a plain CSV file.
>
> What you need to do is to extend the metadata filter so that it lets
> output to a file and choose the format.

I suppose that would be the best option, yes. However, metadata comes
in all kinds of shapes, so it's not easy to map arbitrary metadata
(that any filter can generate) to a meaningful output format, in
particular when the result should be CSV.

In particular, such output should be tidy [1]. For instance, you don't
want to output "frame, key, value" with lines "1, si, 53.999", but
rather "frame, si, ti". Such transformations to useful/parsable output
must be done in the filter itself, not vf_metadata …

[1]: https://cran.r-project.org/web/packages/tidyr/vignettes/tidy-data.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter

2021-01-22 Thread Werner Robitza 
On Fri, Jan 22, 2021 at 12:28 PM Paul B Mahol  wrote:
> > As an end user I would find an output file with a known format much
> > easier to work with.
> > This works very well for the libvmaf filter, for example.
> > Could you please explain how to achieve the same kind of output with
> > the metadata injection?
> >
>
> -vf your_filter,metadata=mode=print

Thanks, I know this, but this is not a known format that can be easily
parsed like a plain CSV file. At least the way the SITI filter is
used, regular users just want simple output in a file that they can
directly load into Excel, Python, whatever. (Just like for VMAF.)

I understand why you wouldn't want each filter to have its own IO
functionality, but in terms of usability, only having the metadata
option would be extremely bad.

(Perhaps the real solution would be to have the metadata filter
generate different kinds of known output formats.)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter

2021-01-22 Thread Werner Robitza 
On Tue, Jan 19, 2021 at 5:49 AM Lynne  wrote:
> > I'm already adding the data to the frame's metadata, is the suggestion to 
> > remove the file option altogether?
> >
>
> Yes. We want to avoid filters having their own file in/out options rather
> than using generic ones.

As an end user I would find an output file with a known format much
easier to work with.
This works very well for the libvmaf filter, for example.
Could you please explain how to achieve the same kind of output with
the metadata injection?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add audio soft clip filter

2019-05-28 Thread Werner Robitza 
On Fri, Apr 19, 2019 at 3:21 PM Paul B Mahol  wrote:

> +@item param
> +Set additional parameter which controls sigmoid function.

Could you perhaps add some more info about the range of possible
values and their meaning?

Thanks,
Werner
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] PATCH: doc/swscaler: explain default Lanczos parameter

2019-05-26 Thread Werner Robitza 
On Sun, May 26, 2019 at 6:09 PM Gyan  wrote:
> Do you want to update it for all algorithms with missing parameter details?

Not at this stage – would be a lot of guesswork since I didn't
implement the filters. Also, at least from research I've seen, the
Lanczos parameter seems to be used often with different values. So
it's a little more important IMO.

I can give it a shot if I see something obvious, but I'd be happy for
this to be merged in the meantime.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] PATCH: doc/swscaler: explain default Lanczos parameter

2019-05-26 Thread Werner Robitza 



0001-doc-swscaler-explain-default-Lanczos-parameter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]

2019-05-17 Thread Werner Robitza 
On Fri, May 17, 2019 at 11:16 AM Gyan  wrote:
> One change, from,
>
>  If value is set to @code{1}, enable full range for source. Default
> value is @code{0}, which enables limited range.
>
> to
>
>  If value is set to @code{1}, indicates source is full range.
> Default value is @code{0}, which indicates source as limited range.

Fixed and wrapped text at 80 chars.

Werner


0001-doc-swscaler-explain-values-for-src_range-dst_range.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]

2019-05-17 Thread Werner Robitza 
On Fri, May 17, 2019 at 9:41 AM Gyan  wrote:
> Strictly speaking, the doc page isn't for CLI use only. A note has been
> added to indicate which options are API only.

That definitely clears things up, thanks.

But coming back to what you wrote initially:

> Sure, if the option name was is_src_range_full. But src_range allows you
> to specify a range. So, even though there are only two, better to
> mention the allowed values and their meaning.

Changed the patch now. Please have a look.

Werner


0001-doc-swscaler-explain-values-for-src_range-dst_range.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]

2019-05-16 Thread Werner Robitza 
On Wed, May 15, 2019 at 11:23 PM Michael Niedermayer
 wrote:
>
> On Wed, May 15, 2019 at 11:13:57PM +0200, Werner Robitza wrote:
> > On Wed, May 15, 2019 at 4:55 PM Gyan  wrote:
> > > On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > > > On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> > > >> Which lines in the CLI help?
> > > > SWScaler AVOptions:
> > > >-sws_flags   E..V. scaler flags (default 
> > > > bicubic)
> > > > ...
> > > >-src_formatE..V. source format (default 
> > > > yuv420p)
> > > >-dst_formatE..V. destination format 
> > > > (default yuv420p)
> > > >-src_range E..V. source is full range 
> > > > (default false)
> > > >-dst_range E..V. destination is full range
> > > > (default false)
> > > >
> > > >> I don't see any constants set in the AVOptions struct. Can you share a 
> > > >> command line where you could set this option using a string?
> > > > I was just going by the help printed above, including the default. If
> > > > a string is not valid, which values are?
> > > The help function fetches the string name for the default value but the
> > > user has to input an integer.
> > >
> > > The pixel formats are declared in an enum in libavutil/pixfmt.h. The
> > > integers correspond to their index in that list.
> >
> > That seems very bad in terms of usability. Is there a particular
> > reason why the "-pix_fmt" option can parse these values, but swscaler
> > not? In fact, most (if not all) other options that accept a finite set
> > of arguments don't use numbers in that way, but strings.
> > I can add the integers to the documentation as a lookup table, but it
> > feels weird doing so.
>
> where exactly is a end user facing interface using integers for pix_fmt
> in place of named identifers, can you show an example command line ?

I checked again, and when you try this, this is printed:

> Directly using swscale dimensions/format options is not supported, please use 
> the -s or -pix_fmt options
> Error parsing option 'src_format' with argument 'yuv420p'.

So this should actually be removed from the CLI options entirely, or?
(And the documentation.)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]

2019-05-15 Thread Werner Robitza 
On Wed, May 15, 2019 at 4:55 PM Gyan  wrote:
> On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> >> Which lines in the CLI help?
> > SWScaler AVOptions:
> >-sws_flags   E..V. scaler flags (default bicubic)
> > ...
> >-src_formatE..V. source format (default yuv420p)
> >-dst_formatE..V. destination format (default 
> > yuv420p)
> >-src_range E..V. source is full range (default 
> > false)
> >-dst_range E..V. destination is full range
> > (default false)
> >
> >> I don't see any constants set in the AVOptions struct. Can you share a 
> >> command line where you could set this option using a string?
> > I was just going by the help printed above, including the default. If
> > a string is not valid, which values are?
> The help function fetches the string name for the default value but the
> user has to input an integer.
>
> The pixel formats are declared in an enum in libavutil/pixfmt.h. The
> integers correspond to their index in that list.

That seems very bad in terms of usability. Is there a particular
reason why the "-pix_fmt" option can parse these values, but swscaler
not? In fact, most (if not all) other options that accept a finite set
of arguments don't use numbers in that way, but strings.
I can add the integers to the documentation as a lookup table, but it
feels weird doing so.

> >>> +If set to 1, source range will be full range.
> >> Mention the range of values possible and their meaning.
> > I don't understand, as no other values are possible. Well, 0 is
> > possible but meaningless since it's default; 1 indicates "true".
> Sure, if the option name was is_src_range_full. But src_range allows you
> to specify a range. So, even though there are only two, better to
> mention the allowed values and their meaning.

Ok. Will send an update.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]

2019-05-15 Thread Werner Robitza 
On Wed, May 15, 2019 at 11:36 AM Gyan  wrote:
> Which lines in the CLI help?

SWScaler AVOptions:
  -sws_flags   E..V. scaler flags (default bicubic)
   ...
  -src_formatE..V. source format (default yuv420p)
  -dst_formatE..V. destination format (default yuv420p)
  -src_range E..V. source is full range (default false)
  -dst_range E..V. destination is full range
(default false)

> I don't see any constants set in the AVOptions struct. Can you share a 
> command line where you could set this option using a string?

I was just going by the help printed above, including the default. If
a string is not valid, which values are?
Or am I looking in the wrong place?

> > +If set to 1, source range will be full range.
>
> Mention the range of values possible and their meaning.

I don't understand, as no other values are possible. Well, 0 is
possible but meaningless since it's default; 1 indicates "true".

Werner

PS: Sorry for missing the subject line in this email.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]

2019-05-15 Thread Werner Robitza 
This fixes documentation for swscaler which is not reflecting what is
shown when running ffmpeg -h full.

Best regards,
Werner


0001-doc-swscaler-fix-documentation-of-pixel-format-and-r.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-21 Thread Werner Robitza 
On Wed, Feb 20, 2019 at 11:36 PM Carl Eugen Hoyos  wrote:
>
> 2019-02-20 20:56 GMT+01:00, Lou Logan :
> > On Wed, Feb 6, 2019, at 11:48 AM, Werner Robitza wrote:
> >>
> >> I propose that FFmpeg maintains its own ffmpeg formula under its
> >> GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
> >> This will ensure that there's one formula users will discover when
> >> they look for an alternative tap, thus improving discoverability and
> >> avoiding fragmentation. We could use the above link as a starting
> >> point.
> >
> > The alternative tap originally proposed by Werner went ahead independently
> > and has been implemented at:
> > https://github.com/varenc/homebrew-ffmpeg
>
> Great!
> Should we add this link to the download page?

I'd wait until we have a proper CI pipeline in place. Right now we're
testing manually. I wouldn't want to directly link to a build script
that has not fully been automatically tested on macOS/Linux. Once that
is done, I'll provide a patch to add the link.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-11 Thread Werner Robitza 
On Sun, Feb 10, 2019 at 7:40 PM Jean-Baptiste Kempf  wrote:
>
> On Sun, 10 Feb 2019, at 19:37, Werner Robitza wrote:
> > > Those options are just for non-free cases, and to be honest, I don't see 
> > > why FFmpeg should advertise those.
> >
> > That is not correct. The following options/dependencies are not
> > present in Homebrew core:
> >
> > chromaprint, fdk-aac, game-music-emu, libbs2b, libcaca, libgsm,
> > libmodplug, librsvg, libssh, libvidstab, libvmaf, openh264, openssl,
> > srt, two-lame, wavpack, webp, zeromq, zimg
>
> Fair enough.
> I still object to an official recipe activating non-free options.

If that is the major concern, I suggest to remove these two options
from the formula as a way forward.

Of course, anyone would be free to provide their own non-free
repository if they desire so.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-10 Thread Werner Robitza 
On Sat, Feb 9, 2019 at 11:59 PM Jean-Baptiste Kempf  wrote:
>
> On Sat, 9 Feb 2019, at 11:59, Werner Robitza wrote:
> > Then the only consequence can be to remove these options or support
> > for these libraries altogether, because you'll find plenty of guides
> > and recommendations on how to build ffmpeg with non-free libs on the
> > Internet – even supplied by members who are very active in the FFmpeg
> > community. It is certainly your prerogative to be against explicit
> > advertising, but where do you draw the line? Has there been any
> > precedent with this, or is this going to be decided on a case-by-case
> > basis?
> >
> > The only consequence would be a formula that is not owned and
> > controlled by FFmpeg, and people will continue to build non-free
> > binaries.
>
> But then, it is not the project, doing it, but someone else.

The project won't be building non-free binaries and ship those to
people. It's the users who will do it on their machine.

> To come back to the main topic, you can have a full FFmpeg in homebrew with 
> all the libraries activated by default, if you want, without any issue.

No, that's not the case.

> I therefore do not see at all the need for options.

They are needed since not everyone wants or needs a full-featured
ffmpeg with all third-party libraries. There can be sane defaults,
like there have been for years, and some libraries can be enabled
optionally.

> Those options are just for non-free cases, and to be honest, I don't see why 
> FFmpeg should advertise those.

That is not correct. The following options/dependencies are not
present in Homebrew core:

chromaprint, fdk-aac, game-music-emu, libbs2b, libcaca, libgsm,
libmodplug, librsvg, libssh, libvidstab, libvmaf, openh264, openssl,
srt, two-lame, wavpack, webp, zeromq, zimg
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-09 Thread Werner Robitza 
On Fri, Feb 8, 2019 at 10:18 PM Jean-Baptiste Kempf  wrote:
>
> On Fri, 8 Feb 2019, at 22:08, Lou Logan wrote:
> > On Fri, Feb 8, 2019, at 11:27 AM, Jean-Baptiste Kempf wrote:
> > >
> > > Also, the AUR recipe does not push for non-free packages.
> >
> > The proposed homebrew formulae will not push for non-free packages. It
> > will simply provide the options for the user to enable two non-free
> > components (openssh and fdk-aac currently) if they desire. They have to
> > be explicitly enabled by the user by manually including the appropriate
> > option, such as "--with-fdk-aac".
>
> Yes, and this is exactly what I am objecting against.
> It silently enables non-free, when you ask either. See L 146 and following.

You could print an even more obvious warning message when these
options are used.
If that is a big concern, it can be easily dealt with.

> And yes, I strongly advise against the project advertising those non-free 
> options.

Then the only consequence can be to remove these options or support
for these libraries altogether, because you'll find plenty of guides
and recommendations on how to build ffmpeg with non-free libs on the
Internet – even supplied by members who are very active in the FFmpeg
community. It is certainly your prerogative to be against explicit
advertising, but where do you draw the line? Has there been any
precedent with this, or is this going to be decided on a case-by-case
basis?

The only consequence would be a formula that is not owned and
controlled by FFmpeg, and people will continue to build non-free
binaries.

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

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Werner Robitza 
Hello,

Thanks for your comments.

On Fri, Feb 8, 2019 at 10:03 AM Jean-Baptiste Kempf  wrote:
> Why do something special for homebrew, and not for all the other 
> distributions?
> Why is homebrew different? Are you going to merge all .spec files from all 
> Linux distributions too?

I don't think it's really productive to talk about other Linux
distributions in this thread. That is really a different topic.

> > That creates a bit of a messy situation, as users are expecting to be
> > able to build ffmpeg with additional libraries, including nonfree ones
> > such as fdk-aac. This is no longer easily doable.
>
> Helping people to build non-free distributions of FFmpeg is a very weird and 
> dubious goal.
> This is just helping other people violate the FFmpeg license.

That is a matter of personal viewpoint contrasted with general opinion
about non-free FFmpeg, which I am 1) probably not the right person to
discuss with, given my lack of presence on this mailing list and 2)
the fact that the proposed formula simply mirrors what is already
possible. I may be missing the full picture or developer consensus
about how to handle this. I understand that there are folks who are
very passionate about this topic, and that others are not. I can only
observe that end users have the technical possibilities to build
FFmpeg in a non-free and non-redistributable fashion. I don't see why
it would be necessary to artificially restrict users in doing so.

> Do not use Github to develop. Github is not-free. Use Github to mirror, if 
> you want, but not to develop.

This formula could of course be mirrored from git.ffmpeg.org or
wherever if there were a policy of not developing on GitHub. That
said, I do see other repos on https://github.com/FFmpeg that are not
mirrored, so I assume there is no such rule.

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

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-08 Thread Werner Robitza 
On Thu, Feb 7, 2019 at 11:11 PM Lou Logan  wrote:
>
> On Thu, Feb 7, 2019, at 12:49 PM, Carl Eugen Hoyos wrote:
> >
> > This sounds like a strong reason not to add it to an FFmpeg
> > repository: It was claimed in the past that I am the only one
> > not supporting releases but the same was now repeated by
> > other developers.
>
> We can simply provide a note that recommends using git master by instructing 
> the user to include the homebrew --HEAD option.

That could easily be added to the formula's README and caveat section,
yes. I don't see that as a major roadblock. If you have a specific
text in mind that would emphasize that one or the other kind of
installation is not supported/recommended, feel free to suggest that
for inclusion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Werner Robitza 
On Thu, Feb 7, 2019 at 9:29 PM Michael Niedermayer
 wrote:
> I can setup a repo on github and or on git.ffmpeg.org (where ffmpeg-web is)
> https://github.com/FFmpeg/web currently is a mirror of git.ffmpeg.org
> assuming there is consensus that such a thing should be created

GitHub would be preferred since that allows the user to simply run:

brew tap-pin ffmpeg/ffmpeg
brew install ffmpeg

See also: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

> Its important that someone maintains this though, that is for example
> someone needs to take care of reported bugs.

Yes, that is absolutely clear. I think that bugs will reflect either
general build errors that should be discussed here or posted on trac,
or bugs in third party libraries (e.g., x265 breaking an ffmpeg
build), or those which are related to Homebrew, which should be posted
on their issue tracker.

> It was not mentioned in this thread but i think it should be clear that
> if this ends up not being maintained (well) then we should remove it again.

That would be the best solution, rather than providing something that
doesn't work (well).

> Also we should aim toward having a good relation with everyone who
> maintains a different solution.
> The way i see it this is being created out of a technical need (the
> removial of easy user configuration support)
> Iam just saying this as ffmpeg-devel has sometimes been a bit toxic.
> I think we should make double sure this does not degenerate into some
> sort of hostile fork ...

The idea would really be to to provide a clean formula the way it was
before Homebrew removed all the options. This would also reflect what
we're recommending people to do in the compilation guides
(https://trac.ffmpeg.org/wiki/CompilationGuide/).

The good thing about taps is that everyone can create a formula for
their own needs, and it is my understanding that people may want to
keep a formula that installs all dependencies by default, or have some
special build flags. So I don't see a potential issue with "hostile
forks".

> and i probably should also say that i do not know exactly who maintains
> which alternative where ...

Until now, not many, since there was no real need for it. Now this
need has suddenly come up, hence my initiative to provide a single
good source rather than having users do a web search for whatever
formula might work.

Thanks for your thoughts – good points.

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

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Werner Robitza 
On Thu, Feb 7, 2019 at 8:50 PM Carl Eugen Hoyos  wrote:
> Please send an initial version of the formula

Sure! Attached to this email.

> please understand
> that since we do not offer release support, release builds can't
> be the default.

Homebrew always points to release versions, the latest one being 4.1
for the official ffmpeg formula. There is an option --HEAD that
fetches the latest Git version though. See
https://docs.brew.sh/Manpage#install-options-formula

--

class Ffmpeg < Formula
  desc "Play, record, convert, and stream audio and video"
  homepage "https://ffmpeg.org/;
  url "https://ffmpeg.org/releases/ffmpeg-4.1.tar.xz;
  sha256 "a38ec4d026efb58506a99ad5cd23d5a9793b4bf415f2c4c2e9c1bb444acd1994"
  version "4.1-custom"
  head "https://github.com/FFmpeg/FFmpeg.git;

  option "with-aom", "Enable AV1 video codec"
  option "with-chromaprint", "Enable the Chromaprint audio
fingerprinting library"
  option "with-fdk-aac", "Enable the Fraunhofer FDK AAC library"
  option "with-libass", "Enable ASS/SSA subtitle format"
  option "with-librsvg", "Enable SVG files as inputs via librsvg"
  option "with-libsoxr", "Enable the soxr resample library"
  option "with-libssh", "Enable SFTP protocol via libssh"
  option "with-libvidstab", "Enable vid.stab support for video stabilization"
  option "with-libvmaf", "Enable libvmaf scoring library"
  option "with-opencore-amr", "Enable Opencore AMR NR/WB audio format"
  option "with-openh264", "Enable OpenH264 library"
  option "with-openjpeg", "Enable JPEG 2000 image format"
  option "with-openssl", "Enable SSL support"
  option "with-rtmpdump", "Enable RTMP protocol"
  option "with-rubberband", "Enable rubberband library"
  option "with-srt", "Enable SRT library"
  option "with-tesseract", "Enable the tesseract OCR engine"
  option "with-webp", "Enable using libwebp to encode WEBP images"
  option "with-zeromq", "Enable using libzeromq to receive commands
sent through a libzeromq client"
  option "with-zimg", "Enable z.lib zimg library"

  depends_on "nasm" => :build
  depends_on "pkg-config" => :build
  depends_on "texi2html" => :build

  depends_on "lame"
  depends_on "libvorbis"
  depends_on "libvpx"
  depends_on "opus"
  depends_on "sdl2"
  depends_on "snappy"
  depends_on "theora"
  depends_on "x264"
  depends_on "x265"
  depends_on "xvid"
  depends_on "xz"

  depends_on "aom" => :optional
  depends_on "chromaprint" => :optional
  depends_on "fdk-aac" => :optional
  depends_on "fontconfig" => :optional
  depends_on "freetype" => :optional
  depends_on "frei0r" => :optional
  depends_on "game-music-emu" => :optional
  depends_on "libass" => :optional
  depends_on "libbluray" => :optional
  depends_on "libbs2b" => :optional
  depends_on "libcaca" => :optional
  depends_on "libgsm" => :optional
  depends_on "libmodplug" => :optional
  depends_on "librsvg" => :optional
  depends_on "libsoxr" => :optional
  depends_on "libssh" => :optional
  depends_on "libvidstab" => :optional
  depends_on "libvmaf" => :optional
  depends_on "opencore-amr" => :optional
  depends_on "openh264" => :optional
  depends_on "openjpeg" => :optional
  depends_on "openssl" => :optional
  depends_on "rtmpdump" => :optional
  depends_on "rubberband" => :optional
  depends_on "speex" => :optional
  depends_on "srt" => :optional
  depends_on "tesseract" => :optional
  depends_on "two-lame" => :optional
  depends_on "wavpack" => :optional
  depends_on "webp" => :optional
  depends_on "zeromq" => :optional
  depends_on "zimg" => :optional

  def install
args = %W[
  --prefix=#{prefix}
  --enable-shared
  --enable-pthreads
  --enable-version3
  --enable-hardcoded-tables
  --enable-avresample
  --cc=#{ENV.cc}
  --host-cflags=#{ENV.cflags}
  --host-ldflags=#{ENV.ldflags}
  --enable-ffplay
  --enable-gpl
  --enable-libmp3lame
  --enable-libopus
  --enable-libsnappy
  --enable-libtheora
  --enable-libvorbis
  --enable-libvpx
  --enable-libx264
  --enable-libx265
  --enable-libxvid
  --enable-lzma
  --disable-libjack
  --disable-indev=jack
]

args << "--enable-chromaprint" if build.with? "chromaprint"
args << "--enable-frei0r" if build.with? "frei0r"
args << "--enable-libaom" if build.with? "aom"
args << "--enable-libass" if build.with? "libass"
args << "--enable-libbluray" if build.with? "libbluray"
args << "--enable-libbs2b" if build.with? "libbs2b"
args << "--enable-libcaca" if build.with? "libcaca"
args << "--enable-libfdk-aac" if build.with? "fdk-aac"
args << "--enable-libfontconfig" if build.with? "fontconfig"
args << "--enable-libfreetype" if build.with? "freetype"
args << "--enable-libgme" if build.with? "game-music-emu"
args << "--enable-libgsm" if build.with? "libgsm"
args << "--enable-libmodplug" if build.with? "libmodplug"
args << "--enable-libopencore-amrnb" <<
"--enable-libopencore-amrwb" if build.with? "opencore-amr"
args <<

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Werner Robitza 
On Thu, Feb 7, 2019 at 5:21 PM Derek Buitenhuis
 wrote:
> I guess my question is: Who amongst the devs here wants to write it?

Several people have already volunteered in this thread (Reto, Kyle and
me), as well as the author of this formula (with whom I've had offline
discussions), which we can use as a starting point:
https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb
(mentioned in my original post).

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

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Werner Robitza 
On Thu, Feb 7, 2019 at 9:18 AM Reto Kromer  wrote:
> I guess the discussion is "only" on: should this happen inside
> or outside the official FFmpeg. My personal preference would be
> inside.

Yes, that was the main point – I see others have this preference as
well. And several people have already volunteered to help maintain
this formula. Thank you for the feedback so far!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-07 Thread Werner Robitza 
On Wed, Feb 6, 2019 at 10:51 PM Kyle Swanson  wrote:
> On Wed, Feb 6, 2019 at 1:43 PM Helmut K. C. Tessarek
>  wrote:
> > Anyhow, I don't think that adding a formula to the ffmpeg src tree is
> > the right approach.
>
> I don't think that's the suggestion. Separate Github repo belonging to
> the FFmpeg Github organization.

Correct. No modification in the source tree.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-06 Thread Werner Robitza 
On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos  wrote:
> Why don't you put your "formula" into your own github repository?

I could do that, but as I've mentioned, providing an official formula
(within a separate repository, not in the source tree!) would make it
easier for end users to discover, and it would ensure that there's
some authority over the build process. If we sent off users to
third-party taps from unknown sources, that could lead to bad end user
experience with Homebrew and FFmpeg, neither of which is wanted –
think about outdated taps or potentially even malicious intent.

> We already provide a build script and we believe that it works
> very well, in addition a kind supporter offers osx binaries.

That's all true, but not all users want to build manually (or have the
technical skills to understand what's going on) and take care of a
dozen dependencies. The build scripts and guides are quite
straightforward but it still takes more time than just running "brew
install ffmpeg". Just for context, in the last 90 days, there have
been over a quarter million installs of ffmpeg through Homebrew.
That's a considerable amount.

Also, the binaries do not contain all third-party dependencies one
might want, such as non-free software or larger libraries. I've
mentioned this in my post as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-06 Thread Werner Robitza 
Dear all,

Homebrew has, with its 2.0 release, removed all options for its core
formulae [1], including ffmpeg. This means users can no longer add
non-default dependencies that aren't included in the core formula [2].
That creates a bit of a messy situation, as users are expecting to be
able to build ffmpeg with additional libraries, including nonfree ones
such as fdk-aac. This is no longer easily doable.

The Homebrew maintainers suggest to provide an alternative third-party
tap with an ffmpeg formula, such as this one created by another user
[3].

I propose that FFmpeg maintains its own ffmpeg formula under its
GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
This will ensure that there's one formula users will discover when
they look for an alternative tap, thus improving discoverability and
avoiding fragmentation. We could use the above link as a starting
point.

Homebrew's lead maintainer also noted that this repo ("tap") could be
indexed [4] – he was reluctant to point to it in the official
formula's caveat section though, as they will not endorse third-party
taps.

I am happy to maintain this formula – and maybe there are other
community members who want to support this effort. The maintenance
effort would basically be: bumping the formula everytime there's an
official release, and testing its build.

Please let me know your thoughts.

Best regards,
Werner

[1] https://github.com/Homebrew/homebrew-core/issues/31510
[2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/ffmpeg.rb
[3] 
https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb
[4] https://docs.brew.sh/Interesting-Taps-and-Forks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

2018-11-25 Thread Werner Robitza 
On Sat, Nov 24, 2018 at 2:23 PM René J.V. Bertin  wrote:
> I have had my ML subscriptions set to not receive emails for a few years now. 
> So when I got the invitation to vote (which I don't consider Spam btw) my 
> first reflex was to confirm that I do not have any current issues with 
> perceived hostility in the community.
>
> Then, when I checked the few replies to this thread before replying myself to 
> explain my vote (and suggest that maybe this survey shouldn't have gone out 
> to inactive members) I wondered if I shouldn't have voted yes...

To be honest, I was surprised the survey was a single yes/no
selection. I voted "no", but I'd have loved to be able to say "no, but
…" and provide some more context.

The way the survey is set up, I wouldn't be surprised if you get a lot
of "no" answers by people who had a first-hand experience with
hostility in this project, but would not want to generalize.

That being said, thanks for initiating the discussion, Thilo.

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

[FFmpeg-devel] [PATCH] doc/hls: fix grammar for HLS options

2018-10-30 Thread Werner Robitza 



0001-doc-hls-fix-grammar-for-HLS-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/filters.texi: explain infinite looping

2017-11-23 Thread Werner Robitza 
Explain how to achieve infinite looping with the loop / aloop filters.

Signed-off-by: Werner Robitza <werner.robi...@gmail.com>
---
 doc/filters.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 04a8139c6d..b8a4d032e0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1144,7 +1144,7 @@ The filter accepts the following options:
 
 @table @option
 @item loop
-Set the number of loops.
+Set the number of loops. Setting this value to -1 will result in infinite 
loops.
 
 @item size
 Set maximal number of samples.
@@ -9991,7 +9991,7 @@ The filter accepts the following options:
 
 @table @option
 @item loop
-Set the number of loops.
+Set the number of loops. Setting this value to -1 will result in infinite 
loops.
 
 @item size
 Set maximal size in number of frames.
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] doc/faq: replace "Mo" with Bytes

2017-09-20 Thread Werner Robitza 
On Mon, Sep 18, 2017 at 6:57 PM, Nicolas George  wrote:
> I would not mind a patch that expands Mo into mega-octet.

Attached with that change.

(Sorry, earlier mail didn't go to the entire mailing list.)


0001-doc-faq-replace-Mo-with-mega-octet.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/faq: replace "Mo" with Bytes

2017-09-18 Thread Werner Robitza 
On Mon, Sep 18, 2017 at 5:06 PM, Nicolas George <geo...@nsup.org> wrote:
>
> Le jour du Génie, an CCXXV, Werner Robitza a écrit :
> > Replaces French "Mo" with "Bytes".
> >
> > Signed-off-by: Werner Robitza <werner.robi...@gmail.com>
> > ---
> >  doc/faq.texi | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
>
> No. "Octet" originated from French but has been imported to English
> because "byte" causes a lot of confusion with "bit". RFCs and other
> texts where accuracy matters have started to adopt it since long ago
> (although not all of them did consistently, of course). With audio-video
> tools, the confusion with bits is quite frequent, that makes a good
> reason to take all steps to avoid it.

Hum, okay. Didn't think this was a conscious decision. I frequently
see speakers of French using "Mo" without knowing that (most of) the
rest of the world barely has an idea what this is. And I do understand
that octets are used in networking and RFCs – but then as "octet" –,
and that you may want to avoid ambiguity.

But this is literally the only place in FFmpeg's documentation where
this abbreviation is used, with more than 50 mentions of "Byte" in
http://ffmpeg.org/ffmpeg-all.html alone. So… is "-probesize" is doing
something special?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/faq: replace "Mo" with Bytes

2017-09-18 Thread Werner Robitza 
On Mon, Sep 18, 2017 at 3:45 PM, Ricardo Constantino  wrote:
> Why not MB instead? It's still more readable than Bytes/B.

Because -probesize takes the number of Bytes by default.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/faq: replace "Mo" with Bytes

2017-09-18 Thread Werner Robitza 
Replaces French "Mo" with "Bytes".

Signed-off-by: Werner Robitza <werner.robi...@gmail.com>
---
 doc/faq.texi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/faq.texi b/doc/faq.texi
index ff35c89..07af0d9 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -450,8 +450,9 @@ work with streams that were detected during the initial 
scan; streams that
 are detected later are ignored.
 
 The size of the initial scan is controlled by two options: @code{probesize}
-(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For
-the subtitle stream to be detected, both values must be large enough.
+(default 500 Bytes) and @code{analyzeduration} (default 5,000,000 µs =
+5 s). For the subtitle stream to be detected, both values must be large
+enough.
 
 @section Why was the @command{ffmpeg} @option{-sameq} option removed? What to 
use instead?
 
-- 
2.7.4

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

[FFmpeg-devel] filters.texi: explain audio upsampling in loudnorm

2017-08-16 Thread Werner Robitza 
Explains that audio in the loudnorm filter will be upsampled to 192 kHz,
which some users were confused about. Addresses issues mentioned in issue
6570.

Please CC for responses, as I'm not subscribing to the list.

Thanks,
Werner


0001-filters.texi-explain-audio-upsampling-in-loudnorm.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: allow .264 as extension for raw H.264 stream

2015-01-22 Thread Werner Robitza 
In addition to .h264, .264 is also commonly used by people to name raw H.264
streams. Enables automatic recognition of the h264 format for the .264
extension.

Signed-off-by: Werner Robitza werner.robi...@gmail.com
---
 libavformat/rawenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 8b50fe1..9b77cdc 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -205,7 +205,7 @@ AVOutputFormat ff_h263_muxer = {
 AVOutputFormat ff_h264_muxer = {
 .name  = h264,
 .long_name = NULL_IF_CONFIG_SMALL(raw H.264 video),
-.extensions= h264,
+.extensions= h264,264,
 .audio_codec   = AV_CODEC_ID_NONE,
 .video_codec   = AV_CODEC_ID_H264,
 .write_header  = force_one_stream,
-- 
1.9.3 (Apple Git-50)

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

[FFmpeg-devel] [PATCH] doc/ffmpeg: mention both ffpreset/avpreset in documentation, remove superfluous example

2015-01-02 Thread Werner Robitza 
ffmpeg looks for both .ffpreset and .avpreset files depending on whether the
-[avsf]pre or -pre option is used. Added two sections for each type of preset
including the rules according to which files are searched.

(Notably, the lookup order is swapped for avpreset files, because it first
looks for codec_arg.avpreset and then for arg.avpreset.)

This removes the section explaining -pre only, which was under Examples,
where it did not really make sense.

Signed-off-by: Werner Robitza werner.robi...@gmail.com
---
 doc/ffmpeg.texi | 40 
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6de5004..396c623 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1214,7 +1214,10 @@ awkward to specify on the command line. Lines starting 
with the hash
 ('#') character are ignored and are used to provide comments. Check
 the @file{presets} directory in the FFmpeg source tree for examples.
 
-Preset files are specified with the @code{vpre}, @code{apre},
+There are two types of preset files: ffpreset and avpreset files.
+
+@subsection ffpreset files
+ffpreset files are specified with the @code{vpre}, @code{apre},
 @code{spre}, and @code{fpre} options. The @code{fpre} option takes the
 filename of the preset instead of a preset name as input and can be
 used for any kind of codec. For the @code{vpre}, @code{apre}, and
@@ -1239,6 +1242,26 @@ directories, where @var{codec_name} is the name of the 
codec to which
 the preset file options will be applied. For example, if you select
 the video codec with @code{-vcodec libvpx} and use @code{-vpre 1080p},
 then it will search for the file @file{libvpx-1080p.ffpreset}.
+
+@subsection avpreset files
+avpreset files are specified with the @code{pre} option. They work similar to
+ffpreset files, but they only allow encoder- specific options. Therefore, an
+@var{option}=@var{value} pair specifying an encoder cannot be used.
+
+When the @code{pre} option is specified, ffmpeg will look for files with the
+suffix .avpreset in the directories @file{$AVCONV_DATADIR} (if set), and
+@file{$HOME/.avconv}, and in the datadir defined at configuration time (usually
+@file{PREFIX/share/ffmpeg}), in that order.
+
+First ffmpeg searches for a file named @var{codec_name}-@var{arg}.avpreset in
+the above-mentioned directories, where @var{codec_name} is the name of the 
codec
+to which the preset file options will be applied. For example, if you select 
the
+video codec with @code{-vcodec libvpx} and use @code{-pre 1080p}, then it will
+search for the file @file{libvpx-1080p.avpreset}.
+
+If no such file is found, then ffmpeg will search for a file named
+@var{arg}.avpreset in the same directories.
+
 @c man end OPTIONS
 
 @chapter Tips
@@ -1285,21 +1308,6 @@ quality).
 @chapter Examples
 @c man begin EXAMPLES
 
-@section Preset files
-
-A preset file contains a sequence of @var{option=value} pairs, one for
-each line, specifying a sequence of options which can be specified also on
-the command line. Lines starting with the hash ('#') character are ignored and
-are used to provide comments. Empty lines are also ignored. Check the
-@file{presets} directory in the FFmpeg source tree for examples.
-
-Preset files are specified with the @code{pre} option, this option takes a
-preset name as input.  FFmpeg searches for a file named 
@var{preset_name}.avpreset in
-the directories @file{$AVCONV_DATADIR} (if set), and @file{$HOME/.ffmpeg}, and 
in
-the data directory defined at configuration time (usually 
@file{$PREFIX/share/ffmpeg})
-in that order.  For example, if the argument is @code{libx264-max}, it will
-search for the file @file{libx264-max.avpreset}.
-
 @section Video and Audio grabbing
 
 If you specify the input format and device then ffmpeg can grab video
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH] doc/ffmpeg mention both ffpreset/avpreset in documentation, remove superfluous example

2015-01-02 Thread Werner Robitza 
On Fri, Jan 2, 2015 at 12:13 AM, Michael Niedermayer michae...@gmx.at wrote:
 its not as simple,
 -pre uses .avpreset and -apre/-fpre/-vpre/-spre uses ffpreset
 they work differently, avpreset only allows encoder options
 so for example you cannot put vcodec=libvpx in it

New patch on the way.

(By the way, should I use in-reply-to or do you want separate threads
for new patches? The developer doc doesn't say.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/ffmpeg mention both ffpreset/avpreset in documentation, remove superfluous example

2015-01-01 Thread Werner Robitza 
ffmpeg looks for both .ffpreset and .avpreset files in addition to
checking the FFMPEG_DATADIR and AVCONV_DATADIR.

Added a paragraph explaining that both are included for compatibility
reasons.

Removed a superfluous section from Examples (7.1) which mentioned
AVCONV_DATADIR and .avpreset. It was not an example, really, and was
confusing, since it did not mention FFMPEG_DATADIR (which on the other
hand is mentioned a few sections above under Presets).

Now everything is mentioned under Presets.

Signed-off-by: Werner Robitza werner.robi...@gmail.com
---
 doc/ffmpeg.texi | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6de5004..4498c5f 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1239,6 +1239,11 @@ directories, where @var{codec_name} is the name of the 
codec to which
 the preset file options will be applied. For example, if you select
 the video codec with @code{-vcodec libvpx} and use @code{-vpre 1080p},
 then it will search for the file @file{libvpx-1080p.ffpreset}.
+
+If no preset is found in the above locations, ffmpeg will also look in
+@file{$AVCONV_DATADIR}, @file{$HOME/.avconv} and for files with an
+@file{.avpreset} suffix in the datadir defined at configuration time.
+
 @c man end OPTIONS
 
 @chapter Tips
@@ -1285,21 +1290,6 @@ quality).
 @chapter Examples
 @c man begin EXAMPLES
 
-@section Preset files
-
-A preset file contains a sequence of @var{option=value} pairs, one for
-each line, specifying a sequence of options which can be specified also on
-the command line. Lines starting with the hash ('#') character are ignored and
-are used to provide comments. Empty lines are also ignored. Check the
-@file{presets} directory in the FFmpeg source tree for examples.
-
-Preset files are specified with the @code{pre} option, this option takes a
-preset name as input.  FFmpeg searches for a file named 
@var{preset_name}.avpreset in
-the directories @file{$AVCONV_DATADIR} (if set), and @file{$HOME/.ffmpeg}, and 
in
-the data directory defined at configuration time (usually 
@file{$PREFIX/share/ffmpeg})
-in that order.  For example, if the argument is @code{libx264-max}, it will
-search for the file @file{libx264-max.avpreset}.
-
 @section Video and Audio grabbing
 
 If you specify the input format and device then ffmpeg can grab video
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: fix suffix of preset files

2015-01-01 Thread Werner Robitza 
On Thu, Jan 1, 2015 at 9:14 PM, Michael Niedermayer michae...@gmx.at wrote:
 i hope our docs are correct, we do support avpreset  AVCONV_DATADIR
 as well for compatibility with libav

I see, thanks. Then it should probably mention both. I'll send a new patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] apache-spark 1.2.0

2014-12-31 Thread Werner Robitza 
From: Kashif Rasul kashif.ra...@gmail.com

Closes #35158.

Signed-off-by: Tim D. Smith g...@tim-smith.us
---
 Library/Formula/apache-spark.rb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Library/Formula/apache-spark.rb b/Library/Formula/apache-spark.rb
index b79385b..95e6d90 100644
--- a/Library/Formula/apache-spark.rb
+++ b/Library/Formula/apache-spark.rb
@@ -3,9 +3,9 @@ require formula
 class ApacheSpark  Formula
   homepage http://spark.apache.org/;
   head https://github.com/apache/spark.git;
-  url http://d3kbcqa49mib13.cloudfront.net/spark-1.1.1-bin-hadoop2.4.tgz;
-  version 1.1.1
-  sha1 d1ef3edfe9174010c66ed39fbbc961b7db765a35
+  url http://d3kbcqa49mib13.cloudfront.net/spark-1.2.0-bin-hadoop2.4.tgz;
+  version 1.2.0
+  sha1 57d19d43aa058acefbde32b2304678a8b07eaa80
 
   conflicts_with 'hive', :because = 'both install `beeline` binaries'
 
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH] apache-spark 1.2.0

2014-12-31 Thread Werner Robitza 
Sorry about that, I sent the wrong commit.

On Wed, Dec 31, 2014 at 10:08 PM, Werner Robitza werner.robi...@gmail.com
wrote:

 From: Kashif Rasul kashif.ra...@gmail.com

 Closes #35158.

 Signed-off-by: Tim D. Smith g...@tim-smith.us
 ---
  Library/Formula/apache-spark.rb | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/Library/Formula/apache-spark.rb
 b/Library/Formula/apache-spark.rb
 index b79385b..95e6d90 100644
 --- a/Library/Formula/apache-spark.rb
 +++ b/Library/Formula/apache-spark.rb
 @@ -3,9 +3,9 @@ require formula
  class ApacheSpark  Formula
homepage http://spark.apache.org/;
head https://github.com/apache/spark.git;
 -  url http://d3kbcqa49mib13.cloudfront.net/spark-1.1.1-bin-hadoop2.4.tgz
 
 -  version 1.1.1
 -  sha1 d1ef3edfe9174010c66ed39fbbc961b7db765a35
 +  url http://d3kbcqa49mib13.cloudfront.net/spark-1.2.0-bin-hadoop2.4.tgz
 
 +  version 1.2.0
 +  sha1 57d19d43aa058acefbde32b2304678a8b07eaa80

conflicts_with 'hive', :because = 'both install `beeline` binaries'

 --
 1.9.3 (Apple Git-50)


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

[FFmpeg-devel] [PATCH] doc/ffmpeg: fix suffix of preset files

2014-12-31 Thread Werner Robitza 
Probably something from Libav that got carried over. ffmpeg uses .ffpreset
files instead of .avpreset, and it uses $FFMPEG_DATADIR instead of
$AVCONV_DATADIR.

Signed-off-by: Werner Robitza werner.robi...@gmail.com
---
 doc/ffmpeg.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6de5004..bc18cfe 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1294,11 +1294,11 @@ are used to provide comments. Empty lines are also 
ignored. Check the
 @file{presets} directory in the FFmpeg source tree for examples.
 
 Preset files are specified with the @code{pre} option, this option takes a
-preset name as input.  FFmpeg searches for a file named 
@var{preset_name}.avpreset in
-the directories @file{$AVCONV_DATADIR} (if set), and @file{$HOME/.ffmpeg}, and 
in
+preset name as input.  FFmpeg searches for a file named 
@var{preset_name}.ffpreset in
+the directories @file{$FFMPEG_DATADIR} (if set), and @file{$HOME/.ffmpeg}, and 
in
 the data directory defined at configuration time (usually 
@file{$PREFIX/share/ffmpeg})
 in that order.  For example, if the argument is @code{libx264-max}, it will
-search for the file @file{libx264-max.avpreset}.
+search for the file @file{libx264-max.ffpreset}.
 
 @section Video and Audio grabbing
 
-- 
1.9.3 (Apple Git-50)

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