Michael Niedermayer wrote:
>i think we should probably make a new major release ...
+1
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
Paul B Mahol wrote:
>Found 65x65x65 3D LUT in wild
FYI: 128x128x128 3D LUTs do also exist in film production.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vi
>> FFMPEG 4.2 PANDORA?
>
> FFmpeg 4.2 CARLS CANS
Ada
(She deserves much better than that horrible programming language!)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
James Almer wrote:
>>> master nb_commits % 1500 == 0.
>And if you make the cut as strict as you suggest, you'll surely
>get broken releases.
I fully agree that such an orthodoxy would result in broken
releases.
Seen this from a user of releases perspective, a good compromise
between availabilit
Paul B Mahol wrote:
>So we already have 3 FFV2 variants.
>
>Which of them are actually useful?
Useful for what? E.g. 1 is a great source of inspiration! (At
least to me, since Dave Rice tweeted it on 2016-07-15.)
Best regards, Reto
___
ffmpeg-devel ma
Michael Niedermayer wrote:
>I think future work should be done as FFV1v5 v6 v7 on
>CELLAR/IETF
That is how it should be, in my opinion.
>why you ask ?
>because that way
>its on its way to be a proper IETF standard from day 1
>there are already people who are interrested in this there,
>like mys
Paul B Mahol wrote:
>Byte Order: Little Endian
I will check the mixed endian on my PDP-11 ;-)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos wrote:
>Attached patch fixes ticket #7442 for me.
LGTM
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Martin Vignali wrote:
>if avtc->profile < 0 or > 4, return an error.
Should 5 not become ProRes XQ (ap4x) as in prores_ks?
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Martin Vignali wrote:
>prores_ks take care about alpha data size, for yuv encoding (in
>other word reduce quality of yuv data if there is alpha), but
>it's seems that this is not the case of the official encoder
No, it isn't.
>So for prores_aw, i choose to separate yuv encoding and alpha
>encodi
Martin Vignali wrote:
>Only enable 12b decoding if the codec tag is Prores or XQ
>let 10b decoding for 422 codecs tag.
Indeed! Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-d
> On 26 Nov 2018, at 15:28, Martin Vignali wrote:
>
> (alpha 12b encoding is probably
> easy to add)
Are you sure alpha is 12 bit? As long as I remember, it is 16 bit.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffm
Michael Niedermayer wrote:
>I will branch release/4.4 soon
>then like always leave some time for testing, bugfixes, ... and then
>make FFmeg 4.4 from release/4.4, its too long since 4.3
Good news! Thank you very much indeed! Reto
___
ffmpeg-devel mail
RADSL wrote:
>On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
>> We still need to choose the name for 4.4
>> previous unused suggestions where:
>> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss,
>> Galois, Viterbi, Darwin
Willem de Sitter? If so, then I would write it in two words.
Jan Ekström wrote:
>K. R. Rao +1
Yep, I changes my mind (thank you Michael for the hint!)
+1 Rao
-1 Plandemic
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, v
Michael Niedermayer wrote:
>Its quite a while since 4.2.2 so i intend to make 4.2.3 soon
>if you want something backported, backport it now
Good news, thank you!
Out of curiosity, are you also preparing the 4.3 major release?
Best regards, Reto
___
f
Michael Niedermayer wrote:
>4.3 is on my todo list, i should have made that already but i
>didnt.
>realistically 4.3 might happen in 1-2 weeks, if nothing
>interferes and nothing unexpected happens.
Thank you, most appreciated! Reto
___
ffmpeg-devel ma
Michael Niedermayer wrote:
>>Is there any chance that the naming system could be changed
>>for this one release so it's 4:3 instead?
>
>thats a funny idea but we would be causing pain with that to
>anyone trying to grep or sort releases
You could have the release 4.3 named "4:3" rather than a
per
Mehta, Krishnakant wrote:
>Kindly let us know what are major differences in ffmpeg ver 4.2
>and 2.8.11
Please check the informations available on the homepage:
https://ffmpeg.org/
You should post such questions on the FFmpeg user mailing list,
not the developer's one.
Hope this helps! Reto
Valerii Zapodovnikov wrote:
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
+ * These values match the ones defined by ISO/IEC
23001-8_2013 § 7.1 and ITU-T H.273.
FYI: ISO/IEC 23001-8:2016 has been withdrawn. Its information
can be found now in ISO/IEC 23091-1:2018, I
Valerii Zapodovnikov wrote:
>This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
>But I also added some clarifications so that nobody mixes primaries
>with matrix again. SMPTE 240 and 170 primaires are the same, while
>matrix coeff. are different, because 240 is derived from 170's new
>p
Werner Robitza wrote:
>I propose that FFmpeg maintains its own ffmpeg formula under
>its GitHub organization
I second the idea.
(Homebrew works now on any modern x86_64 architecture running
Linux, macOS and Windows with Linux.)
>I am happy to maintain this formula – and maybe there are other
>c
Werner Robitza wrote:
>On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos
> wrote:
>>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 skill
Gerion Entrup wrote:
>do the dependencies of the options need to be maintained in the
>repo as well?
I guess, this is out of the scope of FFmpeg.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listin
Carl Eugen Hoyos wrote:
>The question is what happens if one of the dependencies
>in FFmpeg's formula does not work or disappears.
Then the formula will be updated accordingly, as this has
been done during all the last years.
Best regards, Reto
___
ff
Hello,
The attached patch should fix nits in the doc.
Best regards, Reto
0001-ffprobe-fix-typo-and-update-URL-in-man.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Should fix a few nits in man. Best regards, Reto
0001-doc-filters-fix-typos.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Best regards, Reto
0001-doc-snow-fix-typos.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Best regards, Reto
0001-doc-faq-update-macOS-and-URLs.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Best regards, Reto
0001-doc-muxers-fix-typo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos wrote:
>> +Any hexadecimal value between @code{0x01} to @code{0xff} as defined in
>
>Shouldn't this be "between 0x01 and 0xff"?
Yep, of course. I will fix this. Thank you! Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Best regards, Reto
0001-doc-muxers-fix-typo.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Best regards, Reto
0001-Makefile-delete-unneeded-escape.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael Niedermayer wrote:
>if someone adds a line after this he would have to change the
>previous line (adding the \ back)
>that would make such a patch less tidy (2 lines changed instead
>of 1)
>i suspect that was the reason why all lines have a \
Possibly. The two other similar instances are
Steve Lhomme wrote:
> libavformat/matroskadec.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
>diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>index 5aa8a105dc..0e3a6890c1 100644
Should be fine. Best regards, Reto
__
Ben Hutchinson wrote:
>What is top posting? I'll try to avoid it if I know what it is.
Then please "google" it. Thanks!
https://ffmpeg.org/contact.html#MailingLists
https://en.wikipedia.org/wiki/Posting_style#Top-posting
___
ffmpeg-devel mailing list
Steven Liu wrote:
>> should we make a 3.3 release from
>>0bab78f7e729a76ea7a8cbec7f1de033c52494e8
>> that is 3 weeks ago with backports ?
>>
>I think this point maybe better, and stable than another
>two.
+1
___
ffmpeg-devel mailing list
ffmpeg-devel@f
James Almer wrote:
>IMO, since the "we strongly recommend" line has been a constant
>in all releases, removing it now will (for those that notice
>it) rise quite a few red flags and make people come to the
>conclusion they should probably skip it altogether.
+1
And as for bug report/fixing there
Michael Niedermayer wrote:
>> + April 13th, 2017, FFmpeg 3.3 "Hilbert"
>> +
>> +FFmpeg 3.3 "Hilbert",
>>a new
>> +major release, is now available! Some of the highlights:
>> +
>
>> +
>> +
>
>is this valid html ?
No!
Either a list:
. . .
or simply the text:
. . .
is cor
Alan Pope wrote:
>Snaps are universal Linux packages.
On number of Linux distributions you can use Linuxbrew:
brew install ffmpeg --with-the-parameters-you-wish
It works pretty well! We use it on Ubuntu and on Slackware.
Most of the Homebrew packages are available also on Linuxbrew.
Best reg
Dave Rice wrote:
>As required by Apple’s TN2162.
>---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Nicolas George wrote:
>Happy days-getting-longer to you all!
Is FFmpeg not working in the Southern Hemisphere? Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Nicolas George wrote:
>Signed-off-by: Nicolas George
>---
> doc/filter_design.txt | 251
>+++---
> 1 file changed, 135 insertions(+), 116 deletions(-)
>
>diff --git a/doc/filter_design.txt b/doc/filter_design.txt
>index e8a7c53ee9..90fa53367b 100644
>--
Michael Niedermayer wrote:
>Of course if the majority wants me to wait with the release,
>its easy to wait for as long as people want me to wait ...
Form an user's perspective, I would be delighted to have a new
release. Thank you very much indeed! Reto
__
Michael Niedermayer wrote:
>I intend to make new releases for the 3.0, 3.1 and 2.8
>branches
>if you want to backport something, do so soon
>Plan is 2.8 first as its longest since its last release
Thank you very much for maintaining these branches!
May I suggest to move the 2.5 and 2.6 branches
I'm also very strongly for keeping ffserver.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael Niedermayer wrote:
>+
>+if (src->codec->flags & AV_CODEC_FLAG_BITEXACT)
>+c->pfmt_ctx->flags |= AVFMT_FLAG_BITEXACT;
Works fine here. Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
Michael Niedermayer wrote:
>moved 2.5 and 2.6 to olddownloads
>
>and 2.8.9 release made
Thank you!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
wm4 wrote:
>Surely not really a worry for ffmpeg, since it's concerned
>about video, and 16K video is still "a bit" in the future.
If by "video" you mean "YUV", then may I disagree with you?
We use daily FFmpeg, and mainly in a "film" ("RGB") context
and often with a 5K or 6.6K horizontal resolut
Michael Niedermayer wrote:
>also a name needs to be choosen
Bryce and/or Bayer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thilo Borgmann wrote:
>Am 13.06.16 um 10:23 schrieb Paul B Mahol:
>> On 6/13/16, Ivan Kalvachev wrote:
[...]
>>> Feel free to prove me wrong, with quotes.
>>
>> If you want quotes, ask Carl to give you all his private
>> emails.
>
>Do you even realize what you are saying? The accused person
>h
Paul B Mahol wrote:
>As requested in the IRC meeting I hereby request for the
>voting committee to begin voting on whatever to ban Carl
>Eugen Hoyos from mailing list, trac and IRC for 4 months,
>starting after the voting has finished.
If I have the right to vote, then I vote no.
Best regards, R
Paul B Mahol wrote:
>Looks like you prefer to loose valuable developers instead
>of punishing bad behaviour, so be it.
We like to loose nobody, neither you nor Carl.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
Michael Niedermayer wrote:
>1. ban carl for 24h
>2. ban derek for ~24h
>3. ban myself for ~24h
May I suggest to stop the Kindergarten for the next 24
years?
Kindest regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
Michael Niedermayer wrote:
>Its a while since the last relase so ill make 3.3 within
>the next week(s)
Thank you, Michael!
>I also intend to make some new point releases from the
>currently maintained branches if someone wants to backport
>something
I suggest to switch "Nash" 2.7.7 to the old r
Michael Niedermayer wrote:
>But id like to ask everyone to NOT escalate this further,
>iam sure that nothing good would come out of that.
+
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Vittorio Giovara wrote:
>I think the code looks fine. I am just wondering if we
>should also offer the possibility to set these flags from
>the standard context options (-color_trc and others). I'm
>aware that not all values match or are valid but maybe a
>small conversion table or extending the
Michael Niedermayer wrote:
>also in absence of any other ideas, YCoCg support may be a
>qualification task. Maybe not the best choice but certainly
>usefull on its own
+1
Y'CoCg support would be useful indeed.
Best regards, Reto
___
ffmpeg-devel mail
Michael Niedermayer wrote:
>> FFV1 didn't have any mapping in matroska before this, so
>> what exactly is there to support?
>
>mkv supports all avi identifers, i assume that is what was
>used before
>
>> Also, format support is technically a feature, so back-
>> porting seems ill-advised.
>
>I th
Michael Niedermayer wrote:
>>Resulting bitstream was tested with a conformance checker
>>using the last draft of FFV1 specifications.
>
>But has the way this is stored been optimized ?
>
>Once its marked as non exerimental all future decoders must
>support the exact way. It can no longer then be c
Thilo Borgmann wrote:
>Should I?
Yes, please! Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael Niedermayer wrote:
>I would prefer if the algorithm would be tuned to 16bit data
>before adding more formats to the encoder which require all
>decoders to support them.
>
>Dont you agree that this would be the better strategy ?
To my understanding FFV1 v3 is actually stable. Or am I missi
Michael Niedermayer wrote:
>To clarify my suggestion,
>the algorithm should be tuned for high bit depth before using
>it for long term storage. This would be v4 (or later).
>Personally i would wait for v4 and not use v3 for high bit
>depth. Which is why i think its not smart to extend the v3
>impl
Michael Niedermayer wrote:
>Is 4.0 or 3.5 preferred ?
I would prefer 4.0 for the reasons already mentioned by others.
I suggest as well to move the 2.8 branch from the Releases to
the Old Releases.
>Any name suggestions ?
>I do not agree with what you have to say, but I'll defend to
>the death
Reto Kromer wrote:
>I suggest as well to move the 2.8 branch from the Releases to
>the Old Releases.
I just noticed that the day before yesterday 2.8.14 has been
released, therefore please ignore my suggestion. Thank you!
___
ffmpeg-devel mailin
Engi Gang wrote:
>unsubscribe
Please follow the instruction given at the end of each single
message:
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>To unsubscribe, visit link above, or email
>ffmpeg-devel-requ...@ffmpeg.org with sub
Paul B Mahol wrote:
>+@item temperature
>+Set the temperature in Kelvins. Allowed range is from 1000 to 4.
>+Default value is 6500 K.
I would use the singular "Kelvin", otherwise LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
Carl Eugen Hoyos wrote:
>Am So., 26. Juli 2020 um 21:28 Uhr schrieb Paul B Mahol
>:
>>
>> On 7/26/20, Carl Eugen Hoyos wrote:
>> > Hi!
>> >
>> > Attached patch fixes a part of ticket #8819.
>> >
>> > Please comment, Carl Eugen
>> >
>>
>> Looks good, but variable name is unfortunate.
>
>New patch
Paul B Mahol wrote:
>Added yuv422p10 support to encoder and some comments to tables.
LGTM
Thank you and best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit li
Kieran Kunhya wrote:
>On Thu, 6 Aug 2020 at 17:28, Paul B Mahol
>wrote:
>
>> patches attached.
>>
>
>Seems ok if tested on various samples.
Tested with a few samples only, LGTM. Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Paul B Mahol wrote:
>On 8/28/20, Michael Niedermayer wrote:
Is there some specification for this ?
i was looking yesterday but google failed to point me to one
>>>
>>> No specifications, just SDK on github.
>>>
>>> Also I'm unsure if that is sufficient fix for the underline
>>>issue
Jun Zhao wrote:
>print full caps type in print_codec().
>
>Signed-off-by: Jun Zhao
>---
> fftools/cmdutils.c | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
>index 8ffc9d2..4f2e0a2 100644
>--- a/fftools/cmdutils.c
>+++ b/fftools/cmdutils.
Hello Mina,
I noticed a typo in the documentation:
>@item difford
>The order of diffrentation
diffrentation -> differentiation
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael Niedermayer wrote:
>Signed-off-by: Michael Niedermayer
>---
> libavfilter/vf_hue.c | 103 +++
> +++-
> 1 file changed, 92 insertions(+), 11 deletions(-)
On my side it works fine, but don't have any official status in
the project.
Best regards, Reto
A
Sergey Lavrushkin wrote:
>2018-08-03 16:07 GMT+03:00 Michael Niedermayer
>:
[...]
>>division is slow. This should either be a multiplication with
>>the inverse or a LUT with 8bit index changing to float.
>>
>>The faster of them should be used
>
>LUT seems to be faster.
I am not surprised. In my
Martin Vignali wrote:
>But maybe to make tests simpler, we can use/add bit exact
>conversion for uint8 to float, we can generate a LUT without
>float calc and for uint16 to float, we can add a uint16 to
>float conversion without float calc, or maybe, generate a LUT
>in bit exact mode (probably fas
Jean-Baptiste Kempf wrote:
>On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
>> previous unused suggestions where:
>> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss,
>> Galois, Viterbi, Darwin
>
>I'd love a "Lorentz" release :)
+1
"Bayer", the inventor of a filter mosaic ..
Gijs Peskens wrote:
>> Here are some previously suggested names:
>> Darwin, De broglie, Desitter, Galois, Gauss, Heaviside,
>> Jacobi, Maxwell, Mellin, Perelman, Poincaré, Ramanujan,
>> Sagan, Viterbi, Voltaire, Von Neumann
>
>Assuming with Desitter the Dutch mathematician
>(https://en.wikipedia.
+1 for Rózsa Péter
Best regards, Reto
> On 24 Sep 2024, at 21:09, martin schitter wrote:
>
> sorry -- I had the impression, that physics count, but in the field of
> mathematics and computer sciences I would definitely vote for:
>
> "peters" (https://en.wikipedia.org/wiki/R%C3%B3zsa_P%C3%A9te
79 matches
Mail list logo
