e 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(+),
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-
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 (defa
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.
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:
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_rang
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}, w
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...@f
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
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
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
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
> perceive
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 let
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/
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
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?
__
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
>
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
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 unu
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,meta
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 f
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 se
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
>
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 bui
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,
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 FF
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
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 us
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 on
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 preferr
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 repe
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
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
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
> >
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.
> >
> > T
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 organizati
Explain how to achieve infinite looping with the loop / aloop filters.
Signed-off-by: Werner Robitza
---
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
Replaces French "Mo" with "Bytes".
Signed-off-by: Werner Robitza
---
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 @@ wo
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/mai
On Mon, Sep 18, 2017 at 5:06 PM, Nicolas George wrote:
>
> Le jour du Génie, an CCXXV, Werner Robitza a écrit :
> > Replaces French "Mo" with "Bytes".
> >
> > Signed-off-by: Werner Robitza
> > ---
> > doc/faq.texi | 5 +++--
> >
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
_
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
Descr
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 fi
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 metad
From: Kashif Rasul
Closes #35158.
Signed-off-by: Tim D. Smith
---
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/apac
Sorry about that, I sent the wrong commit.
On Wed, Dec 31, 2014 at 10:08 PM, Werner Robitza
wrote:
> From: Kashif Rasul
>
> Closes #35158.
>
> Signed-off-by: Tim D. Smith
> ---
> Library/Formula/apache-spark.rb | 6 +++---
> 1 file changed, 3 insertions(+), 3 delet
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
---
doc/ffmpeg.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc
On Thu, Jan 1, 2015 at 9:14 PM, Michael Niedermayer 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.
___
ffmp
preset. 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
---
doc/ffmpeg.texi | 2
for _.avpreset and then for .avpreset.)
This removes the section explaining -pre only, which was under "Examples",
where it did not really make sense.
Signed-off-by: Werner Robitza
---
doc/ffmpeg.texi | 40
1 file changed, 24 insertions(+), 16
On Fri, Jan 2, 2015 at 12:13 AM, Michael Niedermayer 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,
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
---
libavformat/rawenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat
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.
>
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
@@ -21
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.
> >>
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
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
57 matches
Mail list logo
