And you think "Corona" is better somehow?
Kieran
Sent from my mobile device
On Sat, 3 Apr 2021, 11:15 Zane van Iperen, wrote:
>
>
> On 3/4/21 7:04 pm, Kieran Kunhya wrote:
> > You seriously think it's worth joking about the deaths of 3 million
> people?
> &g
Hey code of conduct committee, can we ban this person?
Kieran
Sent from my mobile device
On Sat, 3 Apr 2021, 22:06 RADSL, wrote:
>
> On 4/3/2021 12:47 PM, Kieran Kunhya wrote:
> > Who are you and what on earth are you talking about?
> >
> > Why on earth is it appro
Who are you and what on earth are you talking about?
Why on earth is it appropriate to name an ffmpeg release after a disease
that has killed millions?
Kieran
Sent from my mobile device
On Sat, 3 Apr 2021, 20:25 RADSL, wrote:
>
> On 4/3/2021 8:11 AM, Derek Buitenhuis wrote:
> > On 03/04/2021
On Sun, 28 Feb 2021 at 13:30, Kieran Kunhya wrote:
> Hi,
>
> Please email me privately with your ssh public key and desired username if
> you would like access to the second Apple M1 Mac Mini which we bought for
> development purposes.
>
> Regards,
> Kieran Kunhya
>
Hi,
Please email me privately with your ssh public key and desired username if
you would like access to the second Apple M1 Mac Mini which we bought for
development purposes.
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, 7 Feb 2021, 14:21 Nicolas George, wrote:
> Marton Balint (12021-02-07):
> > av_gettime_relative() is using the monotonic clock therefore more
> suitable as a
> > timestamp source and for relative time calculations.
> >
> > Probably fixes ticket #9089.
>
> Not ok.
>
> This is a
On Fri, 19 Feb 2021 at 17:41, Nicolas George wrote:
> Lynne (12021-02-19):
> > You poll it in a busy loop in a thread in an event.
>
> Yeah. Events loop are supposed to avoid busy loops. So no.
>
> > Or you find a solution to use libuv's polling instead via a "hacker
> > solution".
>
> This is
On Fri, 19 Feb 2021 at 19:04, Nicolas George wrote:
> Kieran Kunhya (12021-02-19):
> > I don't have a strong opinion on either. But I think you can use
> > container_of on the fd.
>
> Thanks. I find no trace of it in the docs:
>
>
> http://docs.l
On Mon, 16 Aug 2021, 02:26 Wu, Jianhua, wrote:
> Paul B Mahol Wrote:
> > will apply if nobody complains.
>
> Hi Paul,
>
> It seemed that there is no more objection to the patches. Is it able to
> get to the next step?
> Feel free to let me know if there is any other problem.
>
> Best regards.
>
>
> Feel free to let me know if you have different perspectives or if I
> neglected something.
>
Yes, but we don't want to use AVX512 on hardware that downclocks heavily.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, 13 Jul 2021, 02:45 James Almer, wrote:
> On 7/12/2021 10:01 PM, Kieran Kunhya wrote:
> >>
> >> Because it isn't something that should be marked as a keyframe as coded
> >> bitstream in any kind of container, like it's the case of mp4 sync
> samples.
&
On Wed, 11 Aug 2021 at 08:23, Paul B Mahol wrote:
> will apply if nobody complains.
>
Is this really a good idea considering the heavy downclocking of avx512 on
server SKUs?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
>
>
> # Thanks for your proposal. Your input will not be considered because it
> # contains obvious and easily avoided flaws:
> # [x] not following mailing-list rules;
> # [x] not following coding style conventions;
> # [ ] mangled or misformatted patch;
> # [ ] problems of code hygiene;
> # [x]
On Thu, 12 Aug 2021, 13:23 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Thank you for confirming you need to setup a mail server to use git
> > send-email.
>
> Can you clarify: is your problem that you do not know the difference
> between a client and a serve
On Wed, 11 Aug 2021 at 13:31, James Almer wrote:
> You can disable AVX512 at both runtime and compile time. I don't think
> that because there's one CPU arch out there that sees a hit in
> performance for one instruction set we should stop applying code other
> CPUs will benefit from.
>
Gramner
On Thu, 12 Aug 2021, 13:11 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > It is practically impossible to use git send-email without running your
> own
> > mail server and having all the problems that entails (managing spam,
> making
> > sure you are not bl
On Thu, 12 Aug 2021, 13:41 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Thank you for confirming security features must be disabled. As you know
> > email is quite important for societal records such as vaccination
> > certificates and so I (and many others)
On Thu, 12 Aug 2021, 13:29 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > Can you first clarify where this SMTP server comes from as you
> conveniently
> > ignored this point?
>
> I already wrote: "the SMTP server of your mail provider".
>
And h
On Thu, 12 Aug 2021, 13:35 Nicolas George, wrote:
> Kieran Kunhya (12021-08-12):
> > And how do the 1.5 billion Gmail users use SMTP without disabling
> security
> > features?
>
> Do I need to do tech support for Google too?
>
> https://support.google.com/mai
On Mon, 8 Nov 2021 at 06:35, Maksym Veremeyenko wrote:
> Hi,
>
> Attached patch implement muxing SCTE-35 and EPG packets into mpegts stream.
>
SCTE Markers need timestamping, no?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, 8 Nov 2021 at 15:17, Maksym Veremeyenko wrote:
> On 08.11.2021 16:41, Kieran Kunhya wrote:
> > On Mon, 8 Nov 2021 at 06:35, Maksym Veremeyenko
> wrote:
> >
> >> Hi,
> >>
> >> Attached patch implement muxing SCTE-35 and EPG packets into mp
On Wed, 26 Jan 2022 at 21:35, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Fixes visual corruptions on two macroblocks from two frames from
>
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4447/A003C003_SR_422_23.98p.mxf
>
> Signed-off-by: Andreas Rheinhardt
> ---
>
>
> Not gonna happen, not gonna block progress because of whim of single random
> contributor.
>
Agreed, this patch series is as important as buffer referencing. We can't
let holdouts block progress.
Kieran
___
ffmpeg-devel mailing list
On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow wrote:
> On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
> wrote:
> >
> > On 9/6/2023 6:31 PM, Kacper Michajlow wrote:
> > > What would be a downside of preferring CXX always if it exists?
> >
> > FFmpeg runs in a multitude of environments with a
On Fri, 8 Sept 2023 at 18:39, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Sep 8, 2023, at 6:09 AM, Michael Niedermayer
> wrote:
> >
> > modern video encoders where no longer added to ffmpeg
>
> Writing a good modern video encoder is a massive undertaking, and i
On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote:
> On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote:
> >
> > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow
> wrote:
> >
> > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis
> > > wrote:
&
On Tue, 29 Aug 2023 at 21:58, Leo Izen wrote:
> The word "monotonous" means "spoken in a monotone" which is not what we
> mean here. We mean "monotonic" i.e. nondecreasing.
>
> Signed-off-by: Leo Izen
> ---
> fftools/ffmpeg_mux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Thu, 31 Aug 2023 at 15:12, Carotti, Elias via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> Hi
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Stefano
> Sabatini
> Sent: Friday, August 25, 2023 12:01 PM
> To: FFmpeg development discussions and patches
> Cc: Stefano
On Thu, 31 Aug 2023 at 15:30, Kieran Kunhya wrote:
>
>
> On Thu, 31 Aug 2023 at 15:12, Carotti, Elias via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>> Hi
>>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Stefano
On Wed, 6 Sept 2023 at 15:24, Alan Kelly via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> ---
> libswscale/x86/swscale.c| 7 +++
> libswscale/x86/yuv2yuvX.asm | 19 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
Could you include benchmarks below the main
into what we
> have
> SPI for in the first place - an independant entity that handles the
> community
> funds with absolute objectivity and no intrinsic interest whatsoever. In
> contrast to any company, including (my own-ish) FFlabs.
>
If there is disagreement (which will be inev
bout this for the last five or more years). Nor
would any company fund it as a bounty as it provides no benefit to them.
This is the complete opposite of "some flashy FFmpeg project".
Kieran Kunhya
___
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".
On Fri, 27 Oct 2023 at 03:23, Thilo Borgmann via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> Am 27.10.23 um 03:28 schrieb Kieran Kunhya:
> > Hi,
> >
> > On Thu, 26 Oct 2023 at 12:41, Thilo Borgmann via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org>
$subj
0001-libavfilter-vf_hqdn3d-Remove-emms.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
On Sat, 28 Oct 2023 at 18:21, Michael Niedermayer
wrote:
> Hi ronald
>
> On Sat, Oct 28, 2023 at 12:43:15PM -0400, Ronald S. Bultje wrote:
> > Hi Thilo,
> >
> > On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > What this is about, is
costs what you think it does in your head plus two
zeroes on the end.
These elements cost more than the booth itself.
Note also in the US there are strictly enforced rules on unions building
booths so you have to hire in union labour.
Regards,
Kieran Kunhya
Regards,
Kieran Kunhya
>
> so if we have someone do some payed development work be that one time or
> continous. There would be a contract that says what is going to be done.
> That also would have been approved by the community or GA or whatver and
> the company paying would have a say in whats in that contract, really
$subj as discussed at VDD
Kieran
0001-libavcodec-mpeg12-Remove-fast-mode.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
On Mon, 30 Oct 2023 at 06:41, Matthias Dressel
wrote:
> On 29.10.23 16:43, Kieran Kunhya wrote:
> > $subj as discussed at VDD
> >
> > Kieran
>
> IMHO the commit message should have contained some reason as to *why*
> this was removed.
> Now, someone looking at
>
> * If you have some flashy FFmpeg project you want to work on with a cost of
> between 5-15k $ then propose it on the mailing list, make yourself ready
> for
> some paperwork complexities and some public debate as thats the first
> time we
> try this, there will be extra issues likely.
On Mon, 6 Nov 2023 at 15:19, Michael Riedl
wrote:
> Whitespaces after semicolon breaks some servers
>
Are you sure this patch doesn't break other servers? SDP is a painfully
fragile format.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, 30 Oct 2023 at 13:10, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Section 7.4.4 of the MPEG-2 specifications requires that the
> last bit of the last coefficient be toggled so that the sum
> of all coefficients is odd; both our decoder and encoder
> did this only if the
On Thu, 21 Sept 2023, 13:17 Clément Péron, wrote:
> 4I have a project where I need to synchronize multiple RTSP cameras with
> other
> network sensors (sync with NTP or PTP).
>
Just be aware the clock of the vast majority of cameras have no relation to
NTP or PTP so you will have drift and
On Fri, 29 Sept 2023 at 15:46, Paul B Mahol wrote:
> Attached.
ok
___
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
Sent from my mobile device
On Sun, 1 Oct 2023, 20:01 Michael Niedermayer,
wrote:
> EAGAIN causes an assertion failure when it is returned from the decoder
>
> Fixes: Assertion consumed != (-(11)) failed at libavcodec/decode.c:462
> Fixes: assertion_IOT_instruction_decode_c_462/poc
>
> Found-by:
>
> also iam not sure "experimental" is the right flag for code that has
> possible security issues. People might turn experimental on not realizing
> the security aspect.
>
We should make this clear in the docs then.
Kieran
___
ffmpeg-devel mailing
>
> I dont suggest merging more EVC code before the release. I meant the
> EVC code already in git, is reading alot of things with no checks.
> It maybe doesnt matter in most cases, as its not used in most cases without
> more EVC code but still
> Also ATM other things are blocking so EVC still
On Sun, 24 Sept 2023, 18:34 Paul B Mahol, wrote:
> On 9/24/23, Nicolas George wrote:
> > Paul B Mahol (12023-09-24):
> >> libavdevice is abusing libavformat.
> >>
> >> It should have own API or be removed.
> >
> > libavdevice works.
>
> Define 'works'.
>
> It is clearly sub-optimal.
>
Why
On Fri, 13 Oct 2023 at 00:28, Michael Niedermayer
wrote:
> Fixes: out of array access
> Fixes:
> 62678/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4858264984354816
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
>
rstand internally, there are lots of different
codepaths and randomly you'll end up with a buggy or slow one and have no
idea how to fix it.
It's probably easier to start from scratch than to try and understand and
then fix swscale (years of work).
Regards,
Kieran Kunhya
On Sat, 14 Oct 2023, 18:00 Michael Niedermayer,
wrote:
> On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote:
> > On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > >
> > >
> >
On Sun, 13 Aug 2023 at 18:36, Timo Rothenpieler
wrote:
> Did you actually get this to work?
> I'm testing it right now, and at stupid low values like 10 bytes I get a
> working but heavily artifacted video.
> If I set it to something like 2048 all I get is a full size video that
> VLC decodes to
On Sat, 26 Aug 2023 at 07:32, Jun Zhao wrote:
> replace ITU-T T35(A/53 CC) SEI type by enum value
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/libx264.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index
On Fri, 27 May 2022 at 09:30, Gyan Doshi wrote:
> Support for 'libx262' was added in e56f14659f by merging
> Libav e1319aa1c1.
>
> The Libav commit author believed that "x262 is a subfeature of x264"
> but this is not the case. Kieran Kuhnya added support for MPEG-2
> encoding in *his fork* of
On Thu, 26 May 2022 at 09:09, ffmpegagent wrote:
> But that doesn't help. Those bugs exist and I'm sharing my workarounds,
> which are empirically determined by testing a range of files. If someone is
> interested, I can provide private access to a repository where we have been
> testing this.
>
> Captions aren’t exactly “frame accurate” anyway as each frame has just a
> very small piece
>
> of information and only when a certain sequence is complete, it leads to
> some new letters
>
> or line being ready for display.
>
In many use-cases, you want them to be frame-accurate. Final
On Sat, 28 May 2022, 11:20 softworkz, wrote:
> From: softworkz
>
> These tests:
>
> - vsynth2-mpeg2-422
> - vsynth1-mpeg2-422
> - vsynth_lena-mpeg2-422
>
> were failing on newer CPUs where av_cpu_max_align() returns
> values > 32. This patch sets cpuflags to disable avx512
> extensions for
>
> for libxml2 these problems are less likely to hit us as we likely never
> need a
> "new xml feature" but for a (de)muxer we quite likely will need the
> latests version on every platform.
> Also we have regression tests, external libs make that impossible
> as the version of external libs can
> > You will never fit all the features of complex
> > containers like MXF, MP4, TS (and for argument's sake XML) inside a
> > generalised framework like FFmpeg.
>
> Maybe true but the reason is not that it cant be dont just that there are
> features noone uses and noone needs.
> I do know some
On Sat, 3 Sept 2022 at 11:06, Paul B Mahol wrote:
> Attached.
>
Ok
___
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
benchmarks on Intel(R) Xeon(R) D-2123IT:
Before:
v210_planar_pack_8_ssse3: 316.5
v210_planar_pack_8_avx: 319.0
v210_planar_pack_8_avx2: 223.0
After:
v210_planar_pack_8_ssse3: 321.0
v210_planar_pack_8_avx: 326.0
v210_planar_pack_8_avx2: 217.0
v210_planar_pack_8_avx512: 211.0
Regards,
Kieran
uld be optimised using multiple unrolled tables or SIMD
or other approaches.
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmp
On Fri, 28 Oct 2022 at 19:57, James Darnley wrote:
> Negligible speed difference for avx2 on Zen 2 (Ryzen 5700X) and
> Broadwell (Xeon E5-2620 v4):
> 1690±4.3 decicycles vs. 1693±78.4
> 1439±31.1 decicycles vs 1429±16.7
>
Just to avoid confusion for anyone who decides to review this
>
> Great opinion you 2, 0 constructiveness.
> That doesn't help at all.
>
> Please try again in a constructive manner that convinces me of your
> undoubtedly great arguments!
>
Please let me know what IPFS has to do with Interplanetary Communications.
(hint: none).
Kieran
On Fri, 12 Aug 2022 at 15:22, Vittorio Giovara
wrote:
> On Fri, Aug 12, 2022 at 12:51 AM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
> > As it exists right now though, I don't really see why lavf needs what
> > amounts to a URL builder for a service as a "protocol" - this totally
>
On Fri, 12 Aug 2022 at 15:48, Derek Buitenhuis
wrote:
> On 8/12/2022 3:34 PM, Mark Gaiser wrote:
> > Great opinion you 2, 0 constructiveness.
> > That doesn't help at all.
>
> Your tone has been pretty rude in this whole thread.
>
> > Please try again in a constructive manner that convinces me
On Sun, 18 Dec 2022 at 10:41, Stefano Sabatini wrote:
> On Sat, Dec 17, 2022 at 9:46 PM Michael Niedermayer
> wrote:
> >
> > On Sat, Dec 17, 2022 at 07:57:06PM +0000, Kieran Kunhya wrote:
> > > On Sat, 10 Dec 2022 at 18:12, Carl Eugen Hoyos
> wrote:
> > >
Hello,
I have not received a reply from "fate-ad...@ffmpeg.org" and would like to
know which individuals are behind this email address?
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
$subj
0001-libavutil-Remove-TOMI-CPU.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
On Sat, 10 Dec 2022 at 18:12, Carl Eugen Hoyos wrote:
> Am Fr., 9. Dez. 2022 um 18:07 Uhr schrieb Michael Niedermayer
> :
> >
> > On Thu, Dec 08, 2022 at 09:40:12PM +0000, Kieran Kunhya wrote:
> > > I intend to buy this RAM:
> > >
> https://www.amazon.
On Sat, 17 Dec 2022 at 23:44, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Is this code broken or stand in the way of progress?
>
> - Andreas
>
I believe this CPU only exists on paper.
Kieran
___
ffmpeg-devel mailing list
£1500 total I would estimate.
I am happy to host these (as with the M1s) but as these are NUCs anyone can
buy and host them easily.
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
at 22:20, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Dec 4, 2022 at 1:08 PM Kieran Kunhya wrote:
> >
> >> Hello,
> >>
> >> As discussed at the developer meeting it would be good to have an
> AVX-512
> >> (ICL) FATE machine and also
On Thu, 24 Nov 2022 at 22:51, Carl Eugen Hoyos wrote:
> Hi!
>
> Our V210 encoder limits the written values, so do not mark the codec
> as lossless.
>
> Please comment, Carl Eugen
>
Technically true so this patch is fine.
Kieran
___
ffmpeg-devel
On Sun, 27 Nov 2022 at 22:34, Michael Niedermayer
wrote:
> Fixes: Timeout
> Fixes:
> 53599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IPU_fuzzer-4950102511058944
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
>
to let you know, the FOSDEM Open Media Room is open for talk proposals.
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
>
> As far as I know, this codec never had the AV_CODEC_CAP_DRAW_HORIZ_BAND
> flag set (the commented out flag was removed in
> e0c01a62adf59d1866ec53dcd76e4d4c815c5d58). Are you sure it ever worked?
> Do you know someone who uses draw_horiz_band?
> (Given the lack of the flag, ut would have been
On Wed, 15 Mar 2023 at 18:07, Kieran Kunhya wrote:
> (Given the lack of the flag, ut would have been either illegal for the
>> caller to set draw_horiz_band or for the decoder to call it.)
>>
>
> This is not a documented restriction:
> https://github.com/FFmpeg/FFmpe
On Wed, 15 Mar 2023 at 17:17, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Andreas Rheinhardt:
> > The H.264 decoder does not support draw_horiz_band (it does not have
> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> > practically dead.
> >
> >
>
> (Given the lack of the flag, ut would have been either illegal for the
> caller to set draw_horiz_band or for the decoder to call it.)
>
This is not a documented restriction:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L637
Kieran
>
> Obviously, if we merge it now, and big enough issues are found
> which we couldn't fix immediately, I'd have no problem reverting
> the Vulkan patches from the 6.0 branch.
A major LTS release is not your development sandbox.
Kieran
___
On Sun, 19 Feb 2023 at 17:36, Kieran Kunhya wrote:
> Obviously, if we merge it now, and big enough issues are found
>> which we couldn't fix immediately, I'd have no problem reverting
>> the Vulkan patches from the 6.0 branch.
>
>
> A major LTS release is not your develop
On Sun, 19 Feb 2023 at 15:40, Michael Niedermayer
wrote:
> ok that works, that said
> is there consensus that i should create the release branch "now"?
> It seems no review is going on in public of these patches and we should do
> the release "soon", i am asking as i dont want to just surprise
On Fri, 17 Feb 2023 at 09:09, Jean-Baptiste Kempf wrote:
> Hello,
>
> On Fri, 17 Feb 2023, at 04:43, Lynne wrote:
> > This small patchset mostly rewrites Vulkan to enable using multiplane
> images,
>
> This is not small. We're talking about thousands of lines of code;
>
> And this changes
On Sun, 19 Feb 2023 at 18:46, Lynne wrote:
> Feb 19, 2023, 18:43 by kier...@obe.tv:
>
> > On Sun, 19 Feb 2023 at 17:36, Kieran Kunhya wrote:
> >
> >> Obviously, if we merge it now, and big enough issues are found
> >>
> >>> which we couldn'
On Fri, 24 Feb 2023 at 03:00, Felix LeClair
wrote:
> Fixes: Compilation of Sobel with AVX512ICL
> Caused: Comment left without deleniator in AVX512ICL version of SOBEL
>
> Testing:Confirmed working on AVX512 Alderlake (AKA SPR without AMX)
>
Seems fine, bit weird that FATE didn't pick it up.
This is a very bad idea.
What's next, ffmpeg implementing userspace TCP? Are we going to add support
for parsing filesystems as well?
Regards,
Kieran Kunhya
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo
On Tue, 21 Feb 2023, 11:38 Michael Niedermayer,
wrote:
> On Fri, Feb 10, 2023 at 06:47:03PM +0100, Michael Niedermayer wrote:
> > Hi all
> >
> > i plan to branch off release/6.0 from master in the next days
> > If theres something blocking and i should wait, please reply here
> >
> > 6.0 release
On Sat, 29 Apr 2023 at 05:07, Derek Buitenhuis
wrote:
> On 4/29/2023 10:41 AM, Anton Khirnov wrote:
> > ffprobe:
> > * is not one of the libraries, but rather their caller
> > * we are not in business of providing random non-multimedia-related
> > services to callers, unless they are useful in
> There are many projects which use libavcodec, format, filter
> Human users use these projects
>
> If the standarization is at a C struct level only then the human interface
> for each application can be different.
> Thats fine if the 2 cases use fundamentally different interfaces like a
> GUI
On Mon, 6 Feb 2023 at 15:43, Le Bao Tin Ha
wrote:
> I hope this email finds you well. I am currently working on the Toradex
> Apalis iMX8QM board and I am trying to perform a hardware decode using the
> Amphion driver with ffmpeg h264_v4l2m2m codec. The decoder outputs a pixel
> format
$subj
Probably others as well
0001-vf_yadif-Remove-unused-emms_c.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
On Wed, 15 Feb 2023 at 08:49, Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff
Engineer/Samsung Electronics wrote:
>
> Dear Kieran,
>
> While I appreciate your concerns, I must point out that the issues you
> mentioned regarding the maintenance of third-party libraries are not
> limited
> to
of the
> EVC code.
>
I appreciate your sincerity but history shows that patches to third-party
libs from corporate contributors are not maintained (as Ronald said).
People change jobs, work focus changes etc etc. A good example of this is
libyami. Even more so for EVC which has had very limited u
On Thu, 6 Jul 2023, 08:52 Anton Khirnov, wrote:
>
> We are not claiming that. We are claiming that the random numbers
> generated are (to the best of our ability, and that of the underlying
> libraries we rely on) cryptographically secure. This means suitable for
> use in state of the art
On Fri, 14 Jul 2023 at 14:03, James Almer wrote:
> On 7/14/2023 9:59 AM, Kieran Kunhya wrote:
> >> +#if ARCH_X86_64 && HAVE_AVX512_EXTERNAL
> >> +if (EXTERNAL_AVX512(cpu_flags))
> >> +c->yuv2planeX = yuv2yuvX_avx512;
> >>
> +#if ARCH_X86_64 && HAVE_AVX512_EXTERNAL
> +if (EXTERNAL_AVX512(cpu_flags))
> +c->yuv2planeX = yuv2yuvX_avx512;
> #endif
>
You want EXTERNAL_AVX512ICL here.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, 4 Jul 2023 at 06:54, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-07-04 01:50:57)
> > On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> > > Quoting Marton Balint (2023-07-03 22:54:41)
> > > > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > > > My patch use
On Tue, 4 Jul 2023, 11:18 John Cox, wrote:
> On Mon, 3 Jul 2023 00:14:16 +0300 (EEST), you wrote:
>
> >[snip]
> >It's a bit of a shame that this only tests things for 8 bit, not 10, but
> I
> >guess that's better than nothing. The way the current code is set up to
> >template both variants of
On Mon, 29 May 2023 at 12:51, Steven Liu wrote:
> Co-authored-by: winlin
> Co-authored-by: yangrtc
> Co-authored-by: cloudwebrtc
> Co-authored-by: Haibo Chen <495810...@qq.com>
> Signed-off-by: Steven Liu
> ---
> configure|1 +
> doc/muxers.texi | 50 +
>
501 - 600 of 753 matches
Mail list logo
