Re: [FFmpeg-devel] FFmpeg 6.0

[Reto Kromer]

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.org/wiki/Willem_de_Sitter) is intended
>the correct name would be "de Sitter"

There is another Dutch gentleman I would like to suggest:
Dijkstra. He was very influential for today's IT, but is little
known.

Best regards from Reto

___
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] 5.0 release

[Reto Kromer]

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 ... for pain and profit!

Best regards, Reto

___
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 v3] pixfmt: fixed wrong fix of comment

[Reto Kromer]

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
>primaries and white point while 170 uses BT.601 derived from BT.470
>System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too.
>---
> libavutil/pixfmt.h | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)

LGTM

Best regards, Reto

___
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 v2] pixfmt: fixed wrong fix of comment

[Reto Kromer]

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, ISO/IEC 23091-2:2019
and ISO/IEC 23091-3:2018.

___
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] 4.4 Release Name

[Reto Kromer]

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, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] 4.4 Release Name

[Reto Kromer]

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.

>version 4.4 Plandemic

LOL +1

... and +1 for von Neumann.

Best regards, Reto

___
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] FFmpeg 4.4

[Reto Kromer]

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 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: add colortemperature filter

[Reto Kromer]

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://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 2/4] avdevice/decklink: add AV_OPT_FLAG_DEPRECATED flag for list_devices

[Reto Kromer]

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 subject "unsubscribe".

___
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] avcodec/cfhd: Check transform type

[Reto Kromer]

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.
>>
>>I suspect the decoder has more issues. I was hoping that there
>>is a specification that i could base validity and tag ordering
>>checks on.
>
>Look at encoder, it follows tag order, note that some tags are
>purely optional.

Behind their paywall there are:

  - SMPTE ST 2073-1:2014
  - SMPTE RP 2073-2:2014

which do not include all the relevant information.

The official SDK code by GoPro on GitHub is hard to read, at
least for me. Emeric Grange did a cleanup and published an
alternate code on his own repo.

Best regards, Reto

___
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] avcodec/cfhd: add 3d transform support

[Reto Kromer]

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
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] cineform CFHD encoder addition and decoder improvements

[Reto Kromer]

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 link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavfi/hflip: Support Bayer pixel formats

[Reto Kromer]

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 attached.

I am afraid, I still experience the same behaviour:

- the original image (*) has an yellow tinting
- hflip,vflip together gives the correct image texture but with
  a blue tinting
- hflip and vplip individually give a light magenta colour and a
  pattern which I consider to be a Bayer phase error

Thank you and best regards, Reto


* the clip is number 3 at https://avpres.net/CineForm/ (I could
not upload at ticket #8819 because it's 22.3 MB)

___
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] release/4.3

[Reto Kromer]

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
person's name.

Best regards, Reto

___
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] FFmpeg 4.2.3

[Reto Kromer]

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 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] FFmpeg 4.2.3

[Reto Kromer]

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

___
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] ffmpeg version differences

[Reto Kromer]

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

___
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] [RFC] How to become release maintainer

[Reto Kromer]

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 availability of new features and deployment of a new
version would be a few months, such as one release per season.
Hope this input is useful for the discussion.

Best regards, Reto

___
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] FFmpeg 4.2

[Reto Kromer]

>> 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 above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_lut3d: increase MAX_LEVEL

[Reto Kromer]

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, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]download: Fix the release link

[Reto Kromer]

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 email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Bug in YUV decoder

[Reto Kromer]

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
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat:matroskadec: use a define to mark the EBML length is unknown

[Reto Kromer]

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

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

Re: [FFmpeg-devel] [PATCH] Makefile: delete unneeded escape

[Reto Kromer]

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 handled
differently. Anyway, sorry for the noise! And best regards, Reto

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

[FFmpeg-devel] [PATCH] Makefile: delete unneeded escape

[Reto Kromer]

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

[FFmpeg-devel] [PATCH] doc/muxers: fix typo

[Reto Kromer]

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] doc/muxers: fix typo

[Reto Kromer]

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://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/muxers: fix typo

[Reto Kromer]

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

[FFmpeg-devel] [PATCH] doc/faq: update macOS and URLs

[Reto Kromer]

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

[FFmpeg-devel] doc/snow: fix typos

[Reto Kromer]

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

[FFmpeg-devel] [PATCH] doc/filters: fix typos

[Reto Kromer]

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

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

[Reto Kromer]

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

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

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

[Reto Kromer]

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/listinfo/ffmpeg-devel

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

[Reto Kromer]

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 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.

In addition, I would like to add that the version 2 of Homebrew
works not only on macOS, but also on Linux and even on Windows
running Linux. The proposal made would offer again an easy way
to install a parametrable FFmpeg to the end user.

I guess the discussion is "only" on: should this happen inside
or outside the official FFmpeg. My personal preference would be
inside.

Hoping this is useful! Reto

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

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

[Reto Kromer]

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
>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.

I would be happy to help.

Best regards, Reto

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

Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)

[Reto Kromer]

> 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://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresdec : add 12b decoding support

[Reto Kromer]

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-devel

Re: [FFmpeg-devel] avcodec/prores_aw : add support for alpha encoding

[Reto Kromer]

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
>encoding.

In my opinion, this is indeed the way to go.

>I only choose to support 16b alpha (not the 8 bit version (and
>don't plan to add it))

I agree. More important than 8-bit alpha would be 12-bit Y'CbCr
which is generated by many modern cameras (and the the same
sensors are used in some film scanners as well).

Hope this is helpful! Reto

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

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH]lavf/webvttenc: Always write hours in timestamps with two characters

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Reto Kromer]

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

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Reto Kromer]

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 myself and IIRC reto, and iam sure there are many more who
>would like to see more discussions about improving and
>extending the codecs in more fundamental ways.

Indeed, you remember correctly.

>also, you get more comments and testing on IETF/CELLAR
>and for work beyond ffv1v3/4 to be successfull a critical mass
>of people / time is needed. If everyone works seperate, which
>it seems a bit to me thats what is happening, it would be
>harder to move such an effort to completion

I plenty agree with you! The reason why I worked more alone is
the not welcoming environment. I am really too ill now and I do
not have anymore the energy for just ignoring the insults.

If you have any concrete idea how the environment could be made
more welcoming, I would be more than happy. (I am not thinking
about another code of conduct ;-) I would like to continue the
FFV1 journey with you and other interested people, because it
could be a fascinating one!

Best regards, Reto

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

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Reto Kromer]

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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Reto Kromer]

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 faster, if it's acceptable to have
>a LUT for 16bit entries)

In my experience, a LUT in bit exact mode is indeed faster. To
me the proposed addition would be useful. And I guess LUTs for
16-bit entries will become necessary anyway at some point...

Thank you! Reto

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

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Reto Kromer]

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 experience, LUTs are often the faster
solution.

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_hue: 10bit support

[Reto Kromer]

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


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web:  | Twitter: @retoch

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

Re: [FFmpeg-devel] [PATCH v2][GSOC] avfilter: added colorconstancy

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH 1/2] cmdutils: print missing caps in print_codec().

[Reto Kromer]

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.c
>@@ -1414,6 +1414,16 @@ static void print_codec(const AVCodec *c)
>AV_CODEC_CAP_SLICE_THREADS |
>AV_CODEC_CAP_AUTO_THREADS))
> printf("threads ");
>+if (c->capabilities & AV_CODEC_CAP_AVOID_PROBING)
>+printf("avoidprob ");
>+if (c->capabilities & AV_CODEC_CAP_INTRA_ONLY)
>+printf("intraonly ");
>+ if (c->capabilities & AV_CODEC_CAP_LOSSLESS)
>+printf("lossless ");

nit: alignment

>+if (c->capabilities & AV_CODEC_CAP_HARDWARE)
>+printf("hardware ");
>+if (c->capabilities & AV_CODEC_CAP_HYBRID)
>+printf("hybrid ");
> if (!c->capabilities)
> printf("none");
> printf("\n");

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

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Reto Kromer]

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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.5 / 4.0

[Reto Kromer]

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 your right to say it. -- Voltaire

Voltaire (some Voltaire is useful those days).

Best regards, Reto

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

Re: [FFmpeg-devel] [Cellar] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

[Reto Kromer]

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
>implementation with more high depth support.

The issue is that in the real world we need to use the format
now. Otherwise the film archives must use MXF/DPX instead of
Матрёшка/FFV1. That's the point!

I presented to the industry this solution in August 2016 at "The
Reel Thing" technical symposium in Hollywood, and an article on
it was published in April 2017 in FIAF's "Journal of Film
Preservation". The archives cannot wait forever! And they are
indeed important users of FFmpeg, in my opinion.

I already paid EUR 7000 for the FFV1 use in the archival world,
and will pay EUR 5000 additionally in the next months.

>IIUC people created such files somehow beliving that the IMO
>clear warning somehow suggested that this was stable. And with
>that we are a bit stuck with this for v3

I presented last November at the "No Time to Wait" symposium
(nomen est omen) in Vienna - i.e. in your city - how we have to
work today and how we hope to modify container and codec during
the next data migration.

Last but not least, since almost two years now it's impossible
to work on the development of FFV1 v4. It's always the wrong
time and/or the wrong place every time I am doing something for
this cause. Why? This is extremely frustrating.

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

[Reto Kromer]

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 missing
something?

Some of us are indeed trying to work on v4, but this is another
topic, I guess.

Best regards, Reto

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

Re: [FFmpeg-devel] GSoC 2018

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Reto Kromer]

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 changed, so we
>need to be really sure the design is optimal first.
>Are we ?
>who has checked alternatives? what where the reasons why the 
>alternatives were not choosen?
>for example consider get_context(), what it does with >8bit may
>or may not be optimal
>iam interrested to work on that in fact, ive a quite long and
>growing list of other volunteer jobs to do though ...

Hmm... I am a little surprised about this, as I paid EUR 2000 in
2016 for implementing the RGB48 support in FFV1. And I didn't it
just for having less money in my pocket, but explicitly for the
benefit of the community.

As I already said in other contexts, the experimental flag is
actually avoiding a larger use of FFV1 in the archival
community. As long as this flag is present, many film archives
simply cannot adopt FFV1 for film preservation. That's my point.
Therefore I support making the RGB48 support non-experimental.

For the wider context regarding an important category of FFmpeg
users, I wrote this – and I apologise for mentioning myself:

  https://retokromer.ch/publications/JFP_96.html

Best regards, Reto

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

Re: [FFmpeg-devel] Public and private structs and fields (was: lavc: add new API for iterating codecs) and codec parsers

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

[Reto Kromer]

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

Re: [FFmpeg-devel] FFmpeg 3.4

[Reto Kromer]

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

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

Re: [FFmpeg-devel] [PATCH 8/8] doc: update filter_design.txt.

[Reto Kromer]

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
>--- a/doc/filter_design.txt
>+++ b/doc/filter_design.txt

>+The typical task of an activate callback is to fisrt check the 
>backward

tiny typo: first

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

Re: [FFmpeg-devel] Snapping ffmpeg

[Reto Kromer]

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 regards, Reto

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

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3

[Reto Kromer]

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 correct, but *NOT* nesting  into .

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

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 3.3

[Reto Kromer]

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 has been invented the k++
possibility in the i.j.k versioning schema...

In the real world of audio-visual archives, witch I know best,
it is indeed important to be able to tell to the users to keep
updated with the last release. (BTW: They are often unable to
deal with the HEAD.)

The final goal should to be to have FFmpeg used widely, I guess.

Best regards, Reto

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

Re: [FFmpeg-devel] [RFC] FFmpeg 3.3

[Reto Kromer]

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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

[Reto Kromer]

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 think backporting format identifers, fourccs and such is
>safe.
>And this one should be back ported

I fully agree that this one should be back-ported.

Best regards, Reto

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

Re: [FFmpeg-devel] GSoC 2017

[Reto Kromer]

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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

[Reto Kromer]

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 main table could be
>a viable approach. Similarly this could be done for the
>decoder so that color properties are not lost during a
>dpx->dpx conversion maybe.

+1

In my opinion, this is important. I guess to implement an
additional conversion table would be the best solution.

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument

[Reto Kromer]

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

Re: [FFmpeg-devel] FFmpeg 3.3

[Reto Kromer]

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 releases (the
last update has been made on 2016-04-30).

Best regards, Reto

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

Re: [FFmpeg-devel] [PATCH] Support limiting the number of pixels per image

[Reto Kromer]

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 resolution. We are
more than happy that FFmpeg is a such valuable tool!

Best regards, Reto

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

Re: [FFmpeg-devel] FFmpeg 2.8.9, 3.1.6, 3.0.5

[Reto Kromer]

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

Re: [FFmpeg-devel] [PATCH] ffserver: set format bitexact flag, eliminate warnings about it not being set

[Reto Kromer]

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://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Reto Kromer]

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

Re: [FFmpeg-devel] bans

[Reto Kromer]

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.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos

[Reto Kromer]

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://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos

[Reto Kromer]

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, Reto

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