In this project we prefer internal decoders to external libs.
On Fri, 17 May 2024, 18:20 Cosmin Stejerean via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> >
> > On 14/05/2024 17:09, Christian Bart
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
https://ffm
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 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
>
to understand 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:
> >
> > >
> > >
> >
>
> * 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. And
a SPI fits perfectly 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
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>
e have talked about 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 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
$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
f
>
> 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
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 th
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 b
$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
ffmpeg-devel-requ...@ffmpeg.or
hat 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
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
> I think you where root on the trac server you provided and where hosting
> for us.
> but you kicked FFmpeg out and shut that down around the time of the
> vote to ban carl. But its long ago and maybe i misremember. We had a backup
> server and recovered with noone noticing the trac server moved.
On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote:
> tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > Whitespaces after semicolon breaks some servers
>
> Which servers? If the spec allows whitespace then the onus is on them
> to fix their implementations.
>
> /Tomas
>
Poor Tomas, you a
On Tue, 14 Nov 2023, 21:54 Tomas Härdin, wrote:
> tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya:
> > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote:
> >
> > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl:
> > > > Whitespaces
On Wed, 22 Nov 2023, 19:49 James Almer, wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/ac3dsp.h | 4 ++--
> libavcodec/ac3enc_template.c | 2 +-
> libavcodec/x86/ac3dsp.asm| 28 ++--
> libavcodec/x86/ac3dsp_init.c | 4
> 4 files changed, 33 i
Dear FFmpeg community.
Please see FOSDEM Open Media Devroom invite:
Hey all,
The Open Media devroom returns at FOSDEM 2024, and we are looking for
propositions of talks and panels. FOSDEM is one of the largest (8,000+
hackers!) gatherings of Free and Open Source Software contributors in
the world
>
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html
There are numerous inactive people in the voting committee, some for years.
Why are they arbitrarily allowed to vote on this?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-deve
On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote:
>
> On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
>
> > (In this case, NDI plugin is already open source).
This is untrue.
Furthermore, I am amazed you are all ignoring the fact this is an Open
Source hostile company, actively sending
>
>
> Kieran,
>
> Can you point to evidence on the same? An active legal threat to "a
> developer writing an open source implementation of NDI"?
>
> With that in place, it wouldn't be ignored as a material fact, would it?
>
https://trac.ffmpeg.org/ticket/7589
Discussed in there. A few people in t
>
> if you dont return 3 fields you break the normative specification. This
> speaks
> about the "output of the decoding process" not how to interpret the output.
>
> I bring MPEG2 up here because we dont do what the normative spec says
> because it doesnt make sense for us. It does make sense if y
On Tue, 14 May 2019 at 20:42, Michael Niedermayer
wrote:
> Fixes: Timeout (33sec -> 78ms)
> Fixes:
> 14668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5767073352908800
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Sig
On Thu, 27 Jun 2019 at 20:01, Nicolas George wrote:
> Andreas Rheinhardt (12019-06-27):
> > The code is indeed dead atm. To quote myself from ticket 7886:
> > "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for
> > alpha channel decoding in Cineform HD (thereby fixing #6265), b
On Thu, 27 Jun 2019 at 20:52, Nicolas George wrote:
> Kieran Kunhya (12019-06-27):
> > Why can this not be fixed properly?
>
> It can. If you have time and motivation to do it, please go ahead.
> Barring that, removing dead code is still an improvement.
>
> Regards,
&g
>
> If it is so easy, you could do it instead of arguing. If it is not so
> easy, you cannot demand somebody do it.
>
I'm happy to do it now that I am aware of the issue. I will do it when I am
at home in a few days.
> > It is beyond comprehension how removing more code and making the
> situatio
On Sat, 29 Jun 2019 at 08:09, Paul B Mahol wrote:
> Fixes #7886.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/cfhd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..49a5a2c30a 100644
> --- a/libavcodec/cfhd.c
> +++ b/lib
I would ignore what Paul says and perhaps start a Github project with your
patch.
I think it would be useful for developers using the NetBeans IDE.
Kieran
On Fri, 5 Jul 2019 at 23:33, Paul B Mahol wrote:
> If this is meant to be applied to our tree I'm against.
> We do not need this bloat.
>
>
>
> What was the cause of the slow decoding? Does this actually fix it, or
> does it just swipe it "under the carpet"?
> If someone ever found a sample with a different solution, how would they
> know that they shouldn't just remove this again? Without any kind of
> comment on the point of this cal
On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer
wrote:
> Hi all
>
> It seems we do not have a list of people volunteering to do uploads to
> samples. And no place to send such requests to except here, where they
> sometimes get ignored.
>
Just give everyone with push access right to upload.
Ki
On Mon, 5 Aug 2019 at 17:10, Michael Niedermayer
wrote:
> On Thu, Jun 27, 2019 at 06:06:22AM +, Jacob Siddall wrote:
> > The previous calculation code did not account for the fact that the
> > copy_offset for the start of the frame array is at index 0, yet the
> > scan line number from the rf
>
> You argue that it does not NEED to be in lavu, but not that it SHOULD
> note.
>
> > Plus, its not really common av code, and don't let its name mislead
> > you, its more of a hack.
>
> I will disregard the insulting subtext of this sentence.
>
There is nothing insulting about this sentence. IM
On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Up until now, the H.264 parser has allocated a new buffer for every
> frame in order to store the unescaped RBSP in case the part of the RBSP
> that will be unescaped contains 0x03 escape bytes. This is expen
On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Kieran Kunhya:
> > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Up until now, the H.264 parser has allocated
On Tue, 20 Aug 2019 at 14:16, Carl Eugen Hoyos wrote:
> Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol >:
>
> > I kindly ask that following commit:
> d702769213487923c0fb0abe4b61f4d9ebddb88b
>
> I still believe what the patch does is a very good idea and a revert would
> hurt FFmpeg.
>
On Tue, 20 Aug 2019 at 18:06, Michael Niedermayer
wrote:
> On Tue, Aug 20, 2019 at 05:09:51PM +0100, Kieran Kunhya wrote:
> > On Tue, 20 Aug 2019 at 14:16, Carl Eugen Hoyos
> wrote:
> >
> > > Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol <
> one...@g
On Thu, 22 Aug 2019 at 23:55, Michael Niedermayer
wrote:
> Fixes: signed integer overflow: 24023040 * 112 cannot be represented in
> type 'int'
> Fixes:
> 16570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5173275211071488
>
> Found-by: continuous fuzzing process
> https://githu
>
> "time of origin, capture" is clearly a timecode, not a timestamp in
> the sense we're talking about here (plus that the bitstream codes it
> in hours/minutes/seconds). I expect you know the difference.
> If these timecodes are considered useful it would be trivial to expose
> them from the deco
>
>
> Lets check H264
> claim "They do not have a timestamp"
> immedeatly after the pic_struct field which tells you about the repeating
> behavior there is a loop for each repeated value with a timestamp.
> This timestamp is lost, if at CFR one can call it that way.
>
> about "Every encoded frame
0001-mpeg4video-Add-Studio-DPCM-support.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
0001-mpeg4video-Add-SStP-FATE-test.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-- Forwarded message -
From: Zohar Babin
Date: Fri, 12 Oct 2018 at 12:50
Subject: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers
participation
To: FOSDEM , Open Media devroom <
open-media-devr...@lists.fosdem.org>
Hi all,
Join us on February 2, 2019 in Brussels for
>
> > What if a majority of the committee is biased and bans everyone they
> disagree with to take over the project? They certainly could.
> What if the committee's decision is something the majority of the
> developers disagree with?
>
> This is why I'm against formalizing such prodecures. They're
On Tue, 10 Mar 2020 at 12:07, Hendrik Leppkes wrote:
> On Tue, Mar 10, 2020 at 10:37 AM Jianhui Dai
> wrote:
> >
> > Avoid constant N frames latency in video streaming.
> >
>
> Personally, I'm off the opinion that a predictable constant delay in
> this case is better then a variable ever-changin
On Wed, 11 Mar 2020 at 02:29, Dai, Jianhui J
wrote:
> Thanks, I will update the commit message.
>
> I test it with FFmpeg native sw H264 decoder.
> In previous FF_THREAD_FRAME, the latency is constant as N ( =
> thread_count - 1) frames.
> It won't sync thread state until no idle threads availab
On Wed, 11 Mar 2020 at 02:59, Dai, Jianhui J
wrote:
> It does not break FFmpeg output frames management logic (e.g.
> h264_select_output_frame), just enter that phase earlier.
>
> Perhaps my understanding is not correct.
> In my opinions, render should be the one considering variable latency
> is
>
> Regardless of the actual proposed patch, I think the author's use of
> wallclock time to describe the problem is very reasonable. I do a
> large amount of work where I'm measuring "glass-to-glass" latency,
> where I am interested in the total pipeline (encode/network/decode),
> and I definitel
On Tue, 17 Mar 2020 at 11:25, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
>
I've seen whole planes (e.g Alpha) taking up 10s or 100s of KB put in SEI,
do we really want to export this all as side data?
Kieran
___
ffmpeg-devel mailing lis
On Wed, 18 Mar 2020 at 02:38, Limin Wang wrote:
> On Wed, Mar 18, 2020 at 12:13:33AM +, Derek Buitenhuis wrote:
> > On 17/03/2020 23:11, Limin Wang wrote:
> > > The user data unregistered allows arbitrary data to be carried in the
> bitstream,
> > > for example, ROI info, time info etc. For t
On Fri, 13 Mar 2020 at 10:32, Anton Khirnov wrote:
> Those SEIs refer to the currently active SPS. However, since the SEI
> NALUs precede the coded picture data in the bitstream, the active SPS is
> in general not known when we are decoding the SEI.
>
The spec disagrees with this statement (7.4.
>
> I don't think you read that section carefully enough. What it says (in
> my interpretation) is that an SPS can be activated only by:
> - buffering period SEI
> - a PPS (which is itself activated by picture data)
> Picture timing SEI is neither of those.
>
The contents of pic-struct do not affe
On Thu, 2 Apr 2020 at 08:53, Paul B Mahol wrote:
> On 4/1/20, Thierry Foucu wrote:
> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos
> wrote:
> >
> >> Hi!
> >>
> >> It seems to me that this was forgotten when the codec was originally
> >> ported.
> >>
> >
> > why removing "stdbool.h"?
> > it
On Thu, 2 Apr 2020 at 14:24, Paul B Mahol wrote:
> On 4/2/20, Derek Buitenhuis wrote:
> > On 02/04/2020 10:41, Paul B Mahol wrote:
> >> I do not care, bool is evil and should never be used.
> >
> > Why? 'We don't like it' isn't a technical reason.
> >
> > Also, FFmpeg already uses plenty of C99
On Fri, 3 Apr 2020 at 22:07, Carl Eugen Hoyos wrote:
> Am Fr., 3. Apr. 2020 um 22:42 Uhr schrieb FRÉDÉRIC RECOULES
> :
>
> > we are academic researchers working in automated program analysis.
> > We are currently interested in checking compliance of inline asm chunks
> > as found in C programs.
>
gt;> >> You reviewed it on irc and correctly pointed out the missing
> > >> >> >> >> bits.
> > >> >> >> >
> > >> >> >> > Lies, I was against that idea from start.
> > >> >> >> >
>
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 user-visibl
Sent from my mobile device
On Sun, 7 Feb 2021, 16:31 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It is wrong to suggest that the clock of an IP webcam has any relation at
> > all to the PC clock both absolute or relative.
>
> It is not wrong to let use
Sent from my mobile device
On Sun, 7 Feb 2021, 16:55 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Give the user the option not to use the monotonic clock.
>
> So this should be an option. Thank you very much.
Yes the montonic clock should be the default.
> Th
On Sun, 7 Feb 2021, 17:15 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes the montonic clock should be the default.
>
> Changing the default is acceptable to me. Probably after a transition
> period.
>
> > You misunderstand greatly. How does the clock
On Sun, 7 Feb 2021, 17:29 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > You do care because different sources generated either by a PC or
> different
> > physical cameras will drift. E.g at 25fps after one hour you might get
> > 9 frames from one and 90002
Sent from my mobile device
On Sun, 7 Feb 2021, 17:35 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes and thus you need a monotonic clock as a starting point for proper
> > filtering. Ffmpeg has neither.
>
> The kernel provides timestamps that are accu
On Sun, 7 Feb 2021, 18:34 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > This time can jump forward or backwards. It is trivial to do this.
>
> Not on a correctly configured system, it does not.
>
NTP is allowed to jump when it wants for example. It's not
Sent from my mobile device
On Sun, 7 Feb 2021, 19:21 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > NTP is allowed to jump when it wants for example. It's not trivial for
> the
> > user to guarantee this.
>
> In practice, it does not.
>
Read the doc
On Sun, 7 Feb 2021, 20:20 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Your scenario is contrived. Its impossible to sync exactly between
> > different machines for all the reasons I explained and you didn't
> > understand.
>
> I understand very wel
Sent from my mobile device
On Sun, 7 Feb 2021, 20:27 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It doesn't work in practice.
> > It's why every Android phone captures video at 29.970fps ± jitter instead
> > of the correct 3/1001
>
> Go
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 wh
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.libuv.org
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, 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,
On Tue, 23 Mar 2021 at 16:01, Alireza Heidar-Barghi <
arhdr-at-yahoo@ffmpeg.org> wrote:
> Hello,
> I am wondering how I can obtain documentation on the detail of FFmpeg's
> threading architecture?
> Thank you in advance.
> Regards,
> Alireza
>
https://github.com/FFmpeg/FFmpeg/blob/maste
I would like to suggest:
https://en.m.wikipedia.org/wiki/Kizzmekia_Corbett
Sent from my mobile device
On Fri, 2 Apr 2021, 12:34 RADSL, wrote:
>
> On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > We still need to choose the name for 4.4
> > previous unused suggestions where:
>
You seriously think it's worth joking about the deaths of 3 million people?
Kieran
Sent from my mobile device
On Sat, 3 Apr 2021, 11:02 Zane van Iperen, wrote:
>
>
> On 3/4/21 6:53 pm, Michael Niedermayer wrote:
>
> >> Plandemic sounds cool.
> >
> > it does until you google what it refers too
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
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
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
On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
> > > c9153590e5f167e41910d867639eb887164e28d2
> 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > > From: rogerdpack
> > > Date: Tue, 28 Apr 2020 05:15:
On Fri, 1 May 2020 at 04:59, Roger Pack wrote:
> On Thu, Apr 30, 2020 at 4:30 AM Kieran Kunhya wrote:
> >
> > On Thu, 30 Apr 2020 at 07:22, Roger Pack wrote:
> >
> > > > > c9153590e5f167e41910d867639eb887164e28d2
> > > 0001-closed-captio
On Mon, 18 May 2020 at 09:33, Anton Khirnov wrote:
> Quoting Tao Zhang (2020-05-18 08:00:55)
> > If no more comments, I will try to code something to create a pseudo
> > encoder which run the actual encoding in the separate thread. Thanks
>
> I do not think it is a good idea to have the library c
On Tue, 26 May 2020 at 15:14, Josh de Kock wrote:
> To prepare for using the cached bitstream reader, which only defines the
> inline functions rather than the macros, with CAVLC decoding.
>
> Signed-off-by: Josh de Kock
IMO you should provide cached reader benchmarks on real world CAVLC conte
On Wed, 27 May 2020 at 22:53, Michael Niedermayer
wrote:
> On Sun, Mar 15, 2020 at 10:20:56PM +0100, Michael Niedermayer wrote:
> > This combination skips allocating large padding which can read out of
> array
> >
> > Fixes:
> 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-57
>
> More generally though (outside this unsafe flag case)
> i do disagree with your argument a bit, performance does matter.
> Iam regularly reminded of that for example, so much software becomes
> slower on each upgrade with few if any features added the real users
> care about. Just to pick one,
On Fri, 29 May 2020 at 14:11, Michael Niedermayer
wrote:
> On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote:
> > >
> > > More generally though (outside this unsafe flag case)
> > > i do disagree with your argument a bit, performance does matter.
> &
On Mon, 1 Jun 2020 at 14:02, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-05-29 18:46:18)
> > I see no aggression at all here.
>
> Same here. People have disagreeing opinions and are expressing them.
> That does not imply aggression or uncivility.
>
There is no aggression here.
If anything
$subj
fasterthanlight.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscr
On Thu, 4 Jun 2020 at 00:05, Michael Niedermayer
wrote:
> On Wed, Jun 03, 2020 at 06:23:27PM +0100, Kieran Kunhya wrote:
> > $subj
>
> > fftools/ffplay.c |5
> > libavcodec/avcodec.h |4
> > libavcodec/h264_slice.c|6
> >
Needs some more explanation IMO
Sent from my mobile device
On Sun, 7 Jun 2020, 21:27 Michael Niedermayer,
wrote:
> On Thu, May 28, 2020 at 02:12:34PM +0200, Michael Niedermayer wrote:
> > Fixes: assertion failure
> > Fixes:
> 22178/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fu
On Sun, 7 Jun 2020 at 23:33, Michael Niedermayer
wrote:
> On Sun, Jun 07, 2020 at 11:07:13PM +0100, Kieran Kunhya wrote:
> > Needs some more explanation IMO
>
> If you look at the code which sets the outputed picture
> in slice_end()
> if (s->pict_type == AV_PICTUR
On Mon, 1 Jun 2020 at 22:23, Daniel Loman wrote:
> Added seperate side data field to allow adding per packet side data
> message to support MISB 604 encoding
>
Are you aware that this is not going to be frame accurate for the non-SPS
frame because of reordering?
Kieran
_
On Tue, 9 Jun 2020 at 22:26, Daniel Loman wrote:
> KK>>Are you aware that this is not going to be frame accurate for the
> non-SPS
> KK>>frame because of reordering?
>
> reordering of the frame in terms of pts versus dts?
>
> these are attached to the AVPackets not AVFrame. They data should
> cor
>
> >> Against, release name as always should be George or Carl.
> >
> > Quit it.
>
> You are against my vote for release name?
> How unfortunate.
>
Give it a rest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo
>
> It still seems to me that this is a solution in search of a problem. If
> I understand you correctly, the case you have in mind is a codec where
> there is an internal implementation that only supports intra frames
> and an external implementation that also supports inter frames.
> But that see
.
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
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> +if (av_sscanf(line, "%d:%d:%d:%d", &hh, &mm, &ss, &fs) != 4)
>
+continue;
>
Maybe worth a comment saying you're converting a timecode to a PTS here.
These are often not the same.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel
Hi,
> Problem 1
> you have a mean of around 2100 and Stdev of about between 55 and 80 so if
> by
> statistically significant you man 2 Stdev, then with the mean you have.
> You would declare every optimization of less than 6% to be statistically
> insignificant.
> So by what you say here, it seem
On Sun, 14 Jun 2020 at 13:22, Paul B Mahol wrote:
> Fixes #4616.
>
> Signed-off-by: Paul B Mahol
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
1 - 100 of 926 matches
Mail list logo
