> x264 is practically feature complete, but x262 still miss some things,
> like 4:2:2 interlaced. Sure, x262 can work well enough for some use cases,
> but it is still not packaged in e.g. Ubuntu, so users are stuck with the
> - in some ways - inferior mpeg2 encoder of ffmpeg.
>
> The point I am tr
> > People aren't using it because people don't use MPEG-2.
> > There is no maintenance to be done on a format that's 25 years old, do
> > you want me to randomly change cosmetics to make you feel happy?
>
> If you'd get off your high horse for once, that would make me feel happy.
Please let me kn
branch sprawl is
not great but it's better than now.
It has inline patch reviews which are nice.
Whether we like it or not web interfaces are the way 95% of the world
does Git and we have to move with the times.
Kieran
On Sun, Jul 5, 2020 at 5:38 PM Kieran Kunhya wrote:
>
> > >
On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya wrote:
>
> Going back to the original point in hand.
> Many patches aren't getting reviewed and pushed any more.
>
> In part this is because in 2020 whether we like it or not mailing
> lists are not the way to do Git based devel
> Is it? It works easily for me just using msmtp or a similar
> sendmail implementation that speaks SMTP.
> No need for a mail server.
> If you think it's an issue, maybe it needs to be documented?
See the comments about Gmail above from a few people.
Yes it can be done but it's another barrier t
On Tue, 7 Jul 2020 at 12:13, Anton Khirnov wrote:
> Quoting Nicolas George (2020-07-07 12:46:39)
> >
> > * GMail's warnings about "less secure" applications are scare tactics to
> > get you to exclusively use their products, because they cannot feed
> > you advertisement when you use a real m
On Wed, 15 Jul 2020 at 00:36, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/h264_slice.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index c7b2764..db720de 100644
> --- a/libavcodec/h264_s
On Wed, 15 Jul 2020 at 02:19, wrote:
> On Wed, Jul 15, 2020 at 12:54:35AM +0100, Kieran Kunhya wrote:
> > On Wed, 15 Jul 2020 at 00:36, wrote:
> >
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libav
If you look a few lines above, we already set the timecode side data.
Sent from my mobile device
On Wed, 15 Jul 2020, 14:44 , wrote:
> On Wed, Jul 15, 2020 at 09:16:16AM +0100, Kieran Kunhya wrote:
> > On Wed, 15 Jul 2020 at 02:19, wrote:
> >
> > > On Wed, Jul 15,
On Wed, 15 Jul 2020 at 16:52, wrote:
> On Wed, Jul 15, 2020 at 04:16:38PM +0100, Kieran Kunhya wrote:
> > If you look a few lines above, we already set the timecode side data.
> >
>
> are you saying av_frame_new_side_data() above? that's total different, in
> fact,
On Thu, 16 Jul 2020 at 16:25, Marvin Scholz wrote:
> ---
>
> This stills lacks docs, as I first want an overall opinion on this
> approach or possible other solutions I should choose for this.
>
What uses this?
Kieran
___
ffmpeg-devel mailing list
ffm
During glitching or looping streams, old frames remain in the DPB.
The decoder incorrectly thinks that the DPB contains the right number of
buffered frames to output and reordering breaks badly
Any non-cosmetic comments welcome.
Kieran
0001-RFC-libavcodec-hevc_refs-Clear-DPB-of-old-frames.patch
>
> This is not about peer review code or better quality code overall.
> If it was about that, mentioned parties would show their pseudo code
> to improve current proposed code already.
>
> But instead you all seems to prefer silent non action and to tolerate
> such behavior of no pushing important
Hi,
I notice that some encoders adjust the PTS with initial_padding and some
don't.
Is this intentional and should we decide that all encoders should do this?
Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > Hi,
> >
> > I notice that some encoders adjust the PTS with initial_padding and some
> > don't.
> > Is this intentional and should we decide that all enc
On Tue, 28 Jul 2020 at 16:04, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/APIchanges| 3 +++
> libavcodec/avpacket.c | 1 +
> libavcodec/packet.h | 7 +++
> libavcodec/version.h | 2 +-
> 4 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/d
> /* Geometric progression with ratio 42. */
>
> Or, if you used a one-liner in whatever language of your choice, just
> copy-paste it into the comment:
>
> /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
>
This is completely unrealistic for reverse engineered tables such as VLCs
On Mon, 3 Aug 2020 at 09:18, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-16 21:32:34)
> > During glitching or looping streams, old frames remain in the DPB.
> > The decoder incorrectly thinks that the DPB contains the right number of
> > buffered frames to output
On Mon, 3 Aug 2020 at 08:16, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-27 20:15:17)
> > On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
> >
> > > Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > > > Hi,
> > > >
> &g
On Mon, 3 Aug 2020 at 10:48, Paul B Mahol wrote:
> Hi,
>
> patch attached.
>
>
Seems fine if tested.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
On Tue, 28 Jul 2020 at 16:31, wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
>
Hi,
There is already libdvbpsi or bitstream for these kind of applications, it
should not go in FFmpeg, nor in public API.
Kieran
___
ffmpeg-devel mailing
On Wed, 5 Aug 2020 at 12:54, wrote:
> On Wed, Aug 05, 2020 at 11:14:39AM +0100, Kieran Kunhya wrote:
> > On Tue, 28 Jul 2020 at 16:31, wrote:
> >
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > >
> >
>
> It's audio descriptor information although it's stored in PSI table, but
> it'll map to
> specific audio packet in the end, so I don't think it's hacky. I have
> tested
> with mpts with multiple audio stream, it's pass-by if copy specifc audio
> stream.
>
Why not just parse the AC-3 packet hea
On Thu, 6 Aug 2020 at 15:48, wrote:
> On Thu, Aug 06, 2020 at 07:51:55AM +0100, Kieran Kunhya wrote:
> > >
> > > It's audio descriptor information although it's stored in PSI table,
> but
> > > it'll map to
> > > specific audio packet in
On Thu, 6 Aug 2020 at 17:28, Paul B Mahol wrote:
> Hi,
>
> patches attached.
>
Seems ok if tested on various samples.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
>
> > @@ -4169,6 +4189,11 @@ static int mov_open_dref(MOVContext *c,
> AVIOContext **pb, const char *src, MOVDr
> > if (!c->fc->io_open(c->fc, pb, filename, AVIO_FLAG_READ,
> NULL))
> > return 0;
> > }
> > +} else if (ref->location) {
> > +av_log(c->f
On Sun, 9 Aug 2020 at 13:20, Paul B Mahol wrote:
> Hi,
>
> patches 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...@ff
On Wed, 12 Aug 2020 at 00:00, Michal Rybarik wrote:
> Hello,
>
> I am using ffmpeg to transcode video in live stream - both input and
> output are MPEG-TS multicasts (single program transport stream). Input
> MPEG-TS contains EIT (EPG) and I want to copy it to the output.
>
> Current ffmpeg treat
On Sat, 29 Aug 2020 at 13:27, Marvin Scholz wrote:
> ---
> libavformat/adtsenc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Not really "deinterlacing", it would be "add interlaced file support" or
similar.
On Mon, 21 May 2018 at 20:17 Gagandeep Singh
wrote:
> +static inline void peak_table(int16_t *band, Peak *peak, int length)
> +{
> +int i;
> +for (i = 0; i < length; i++)
> +if (abs(band[i]) > peak
>
> +static inline void interlaced_vertical_filter(int16_t *output, int16_t
> *low, int16_t *high,
> + int width, int linesize, int plane)
> +{
> +int i;
> +int16_t even, odd;
> +for (i = 0; i < width; i++) {
> + even = (*low - *high)/2;
> + odd = (*lo
Hi
On Thu, 31 May 2018 at 12:25 Gagandeep Singh
wrote:
> ---
> libavcodec/cfhd.c | 462
> ++
> libavcodec/cfhd.h | 15 +-
> 2 files changed, 411 insertions(+), 66 deletions(-)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 051
On Sat, 14 Jul 2018 at 00:14 Michael Niedermayer
wrote:
> This fixes out of array accesses
> No testcase known
>
> Signed-off-by: Michael Niedermayer
>
Looks ok if Gagandeep is ok
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On Thu, 19 Jul 2018 at 14:04 Paul B Mahol wrote:
> Hi,
>
> I want that FFmpeg community sponsor addition of new code I gonna
> develop in following days/months.
>
> Thanks.
>
What code?
I am happy to sponsor cleanup of libavfilter to be usable outside of
ffmpeg.c and in a realtime environment.
On Tue, 14 Aug 2018 at 08:43 Gagandeep Singh
wrote:
> Second patch for fixing decompanding in table 9.
>
> Gagandeep Singh
>
Seems ok
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
$subj
Depends on Michael's patch.
I have a FATE sample 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
On Wed, 22 Aug 2018 at 10:44 Carl Eugen Hoyos wrote:
> 2018-08-22 1:29 GMT+02:00, Kieran Kunhya :
> > $subj
>
> Please split the re-indentation and please fix the indentation of "else".
>
Would you mind explaining th
On Mon, 18 Dec 2023 at 14:59, Petr Matousek
wrote:
> Before this patch being applied the ffprobe just tells the user whether
> the H.26[45] User Data Unregistered SEI message is present in the frame
> side data
> or not. After the patch being appliend it also dumps the contents of the
> data
> si
On Fri, 22 Dec 2023, 00:36 Michael Niedermayer,
wrote:
> On Thu, Dec 21, 2023 at 03:22:20AM +0100, Michael Niedermayer wrote:
> > Hi all
> >
> > My main development machiene died today, so expect increased delays
> > about things that involve me/it until thats fixed
> >
> > Rest of the mail is ju
On Fri, 22 Dec 2023 at 08:05, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2023-12-22 02:40:55)
> > On Fri, 22 Dec 2023, 00:36 Michael Niedermayer,
> > wrote:
> >
> > > On Thu, Dec 21, 2023 at 03:22:20AM +0100, Michael Niedermayer wrote:
> > > >
On Tue, 2 Jan 2024 at 09:21, Nuo Mi wrote:
> On Mon, Jan 1, 2024 at 11:50 PM Lynne wrote:
>
> > Jan 1, 2024, 16:26 by jamr...@gmail.com:
> >
> > > On 1/1/2024 12:16 PM, Lynne wrote:
> > >
> > >> Jan 1, 2024, 15:13 by nuomi2...@gmail.com:
> > >>
> > >>> libavcodec/vvc/Makefile | 16
On Tue, 2 Jan 2024 at 11:27, Stefano Sabatini wrote:
> On date Monday 2023-12-18 19:06:10 +0000, Kieran Kunhya wrote:
> > On Mon, 18 Dec 2023 at 14:59, Petr Matousek <
> petr.matou...@comprimato.com>
> > wrote:
> >
> > > Before this patch being applied
> > > +static void FUNC(put_pixels)(int16_t *dst,
> > > +const uint8_t *_src, const ptrdiff_t _src_stride,
> > > +const int height, const int8_t *hf, const int8_t *vf, const int
> > width)
> > > +{
> > > +const pixel *src= (const pixel *)_src;
> > > +const ptrdiff_t src_
>
> > and not the CLI (something this project is unable to understand).
>
> What is exposed by the API is exercised by the CLI (which is a good
> thing for scripting and for testing).
>
The CLI can't just write random binary data to the terminal. What next, raw
frames available via JSON? I'm sure
>
> My point is that we might opt-out the verbose dump if we have a clear
> criterion for opting-in/out. For example -show_data is off by default,
> and we could mark special side-data fields with some flags to opt them
> out by default.
Again, for unregistered SEI you don't have a choice. Some e
Sent from my mobile device
On Wed, 3 Jan 2024, 03:30 Lynne, wrote:
> Jan 3, 2024, 04:04 by d...@lynne.ee:
>
> > Jan 3, 2024, 02:22 by jamr...@gmail.com:
> >
> >> On 1/2/2024 9:56 PM, Lynne wrote:
> >>
> >>> As some of you know, my laptop died nearly 2 years ago, and
> >>> I've been working on a
On Wed, 3 Jan 2024 at 15:44, Stefano Sabatini wrote:
> On date Tuesday 2024-01-02 22:08:54 +0000, Kieran Kunhya wrote:
> [...]
> > The OP wants to test an implementation they have and they should do it
> > using the API, not using ffprobe to test their third party implementatio
On Fri, 5 Jan 2024 at 10:50, Anton Khirnov wrote:
> ---
> src/index | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/index b/src/index
> index a2536ff..98cc516 100644
> --- a/src/index
> +++ b/src/index
> @@ -35,6 +35,14 @@
> News
>
>
> + January 3rd, 2024, native V
On Fri, 5 Jan 2024, 17:25 Rémi Denis-Courmont, wrote:
> Le keskiviikkona 3. tammikuuta 2024, 2.56.12 EET Lynne a écrit :
> > As some of you know, my laptop died nearly 2 years ago, and
> > I've been working on a desktop machine, which is currently a Zen 3.
> > AVX512 has become more popular in th
On Sat, 6 Jan 2024 at 02:35, Nuo Mi wrote:
> On Sat, Jan 6, 2024 at 9:13 AM James Almer wrote:
>
> > On 1/5/2024 10:09 PM, Nuo Mi wrote:
> > > On Sat, Jan 6, 2024 at 5:09 AM James Almer wrote:
> > >
> > >> On 1/3/2024 9:19 PM, James Almer wrote:
> > >>> Signed-off-by: James Almer
> > >>> ---
>
On Sat, 6 Jan 2024, 16:06 Lynne, wrote:
> Jan 6, 2024, 21:15 by r...@remlab.net:
>
> >
> >
> > Le 6 janvier 2024 20:26:42 GMT+02:00, Michael Niedermayer <
> mich...@niedermayer.cc> a écrit :
> >
> >>
> >>
> > >I think some kind of remotely usable system does make sense for every
> volunteer
> > >
On Sat, 6 Jan 2024, 19:00 Lynne, wrote:
> Jan 7, 2024, 00:36 by kier...@obe.tv:
>
> > On Sat, 6 Jan 2024, 16:06 Lynne, wrote:
> >
> >> Jan 6, 2024, 21:15 by r...@remlab.net:
> >>
> >> >
> >> >
> >> > Le 6 janvier 2024 20:26:42 GMT+02:00, Michael Niedermayer <
> >> mich...@niedermayer.cc> a écrit
On Sat, 6 Jan 2024, 20:55 Lynne, wrote:
> Jan 7, 2024, 01:40 by kier...@obe.tv:
>
> > On Sat, 6 Jan 2024, 19:00 Lynne, wrote:
> >
> >> Jan 7, 2024, 00:36 by kier...@obe.tv:
> >>
> >> > On Sat, 6 Jan 2024, 16:06 Lynne, wrote:
> >> >
> >> >> Jan 6, 2024, 21:15 by r...@remlab.net:
> >> >>
> >> >>
On Sat, 6 Jan 2024 at 05:10, Martin Storsjö wrote:
> On Sat, 6 Jan 2024, Kieran Kunhya wrote:
>
> > On Sat, 6 Jan 2024 at 02:35, Nuo Mi wrote:
> >
> >> On Sat, Jan 6, 2024 at 9:13 AM James Almer wrote:
> >>
> >> > On 1/5/2024 10:09 PM, Nuo M
On Sun, 14 Jan 2024, 17:24 Lynne, wrote:
> Jan 9, 2024, 19:57 by d...@lynne.ee:
>
> > Jan 3, 2024, 04:30 by d...@lynne.ee:
> >
> >> Jan 3, 2024, 04:04 by d...@lynne.ee:
> >>
> >>> Jan 3, 2024, 02:22 by jamr...@gmail.com:
> >>>
> On 1/2/2024 9:56 PM, Lynne wrote:
>
> > As some of you
>
> If you think it's reasonable, you shouldn't block it.
> If you have conditions, you should concisely state them.
> If you think this is entirely unreasonable and falls outside of the scope
> of
> the project's donation funds, then I would expect you to apply the
> same pragmatic standards when
>
> A ticket doesn't have durability.
>
A Ryzen 5 vs Ryzen 7 in the same laptop chassis doesn't change its
durability, it only doubles the laptop's price.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/f
On Tue, 16 Jan 2024, 11:50 Paul B Mahol, wrote:
> On Tue, Jan 16, 2024 at 11:06 AM Kieran Kunhya wrote:
>
> > >
> > > A ticket doesn't have durability.
> > >
> >
> > A Ryzen 5 vs Ryzen 7 in the same laptop chassis doesn't change
> >> It's a high-spec 4-core machine with 16Gb of RAM, and still very
> >> usable these days, but it'll take around 400 dollars to repair,
> >> as a new original screen is expensive (290), battery isn't cheap (60),
> >> and parts are in general in demand as it's out of support by now.
> >>
> >
> >
On Thu, 18 Jan 2024 at 09:55, Paul B Mahol wrote:
> On Thu, Jan 18, 2024 at 10:53 AM Kieran Kunhya wrote:
>
> > > >> It's a high-spec 4-core machine with 16Gb of RAM, and still very
> > > >> usable these days, but it'll take around 400 dollars t
On Tue, 23 Jan 2024 at 06:50, Gyan Doshi wrote:
> Set up framework for non-PCM decoding in-place and
> add support for Dolby-E decoding.
>
> Useful for direct transcoding of non-PCM audio in live inputs.
>
Does this handle a Dolby E packet spanning multiple S302M packets? I'm not
saying you shou
On Tue, 23 Jan 2024 at 08:33, Gyan Doshi wrote:
>
>
> On 2024-01-23 01:26 pm, Kieran Kunhya wrote:
> > On Tue, 23 Jan 2024 at 06:50, Gyan Doshi wrote:
> >
> >> Set up framework for non-PCM decoding in-place and
> >> add support for Dolby-E decoding.
>
On Tue, 23 Jan 2024 at 14:51, Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:
> On Tue, Jan 23, 2024 at 4:05 AM Kieran Kunhya wrote:
> > Yes, and the other uncertainty is that the PTS must be cotimed with the
> > video so you have to guess whether it's th
>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
>
Is VVC being run through oss-fuzz yet? I think it would be a shame for 7.0
to be released then a ton of CVEs come out and the security community
hysterically saying FFmpeg
ce of open source projects,
not just another GSoC wishlist.
So work like Anton's threading, YUVJ removal etc, that couldn't be funded
via bounties as they have no direct commercial value but require expertise
in the codebase.
Statements of Work and milestones (by definition) are for
>
> > Statements of Work and milestones (by definition) are for features.
>
> The SoW suggestion/need came from a lawyer that jonatas asked IIUC.
> so i can just suggest to put work like what you list above into a SOW like
> framework. Or maybe Jonatas can clarify, in case i misunderstood
>
My poi
On Sun, 28 Jan 2024 at 19:20, Jonatas L. Nogueira
wrote:
> That's not a problem at all; because you can divide the work into discrete
> pieces after it's done (on the invoice), just like liberal professionals
> (eg. accountants, lawyers, administrators, etc.)
>
As an open source project we can't
>
> Also it has to be said, that the example is hypothetical, you are not
> going to
> do that work. You seem more interrested in arguing against anything
> related to SPI
>
This is a completely false accusation. I have no issues with SPI as an
organisation. The hardware I bought and host was reim
> > infrastructure etc which all lends itself to salaried work.
>
> employment & salary is one way to pay someone. Sending invoices and doing
> some paperwork before is the other.
>
> Both work fine really. For example iam not employed by FFlabs and the work
> i did for them is just by sending invo
>
> Both work fine really. For example iam not employed by FFlabs and the work
> i did for them is just by sending invoices, while what i do qualifies
> maintenance probably close to 100%.
>
Fflabs is a private company that can choose however it likes how to
distribute its funds. STF/SPI/FFmpeg ar
On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote:
> Both work fine really. For example iam not employed by FFlabs and the work
>> i did for them is just by sending invoices, while what i do qualifies
>> maintenance probably close to 100%.
>>
>
> Fflabs is a private comp
>
> Why is that a problem? This decoder seems like it shouldn't be a
> decoder.
>
> I agree with Andreas that this seems like it's a demuxer pretending to
> be a decoder.
>
The framing is in the PCM layer itself, you have the same issue repeated in
every container that accepts PCM (and Dolby E doe
On Sun, 28 Jan 2024 at 21:19, Jonatas L. Nogueira
wrote:
> While it's true a traditional SOW breaks work into milestones, we're going
> for a simplified one here out of need. Think on when you ask for
> consulting, not when you ask for a feature. You should not assume we want
> to write eg. "Fini
> I would cry ;)
>
> seriously, I have said very clearly in my first mail that there can be NO
> late
> objections to a STF/SPI Project. objections must be before its submitted to
> STF. So theres no way the GA could object to an invoice, the GA could
> object to
> the project before its started on
On Mon, 29 Jan 2024 at 10:17, Gyan Doshi wrote:
>
>
> On 2024-01-29 02:57 pm, Nicolas Gaullier wrote:
> >> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2024-01-26 05:23:50)
> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >>> On 2024-01-
>
>
> >> [...] the GA definitly cannot object to an invoice for a project that
> the GA approved previously.
> > "The General Assembly is sovereign and legitimate for all its decisions
> regarding the FFmpeg project."
>
> When working with a contract (and a SOW), the General Assembly won't be
> abl
ney
for community purposes.
You're not doing SPI any favours here with these comments.
Kieran
On Mon, Jan 29, 2024, 12:02 Kieran Kunhya wrote:
>
>>
>>> >> [...] the GA definitly cannot object to an invoice for a project that
>>> the GA approved previousl
>
> Mysteriously, there was a total absence of similar drama there.
> I wonder how it could have been possible to do that for over a decade
> with not one instance of drama or problems like here.
>
> We had students passing the mentors review, being paid but code was
> found not be clean enough yet
On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer
wrote:
> Hi Kieran
>
> On Sun, Jan 28, 2024 at 08:42:00PM +0000, Kieran Kunhya wrote:
> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote:
> >
> > > Both work fine really. For example iam not employed by FFlabs a
On Mon, 29 Jan 2024, 18:54 Michael Niedermayer,
wrote:
>
> > You weren't willing to compromise last time
> > for your hobby, what makes you willing to compromise in that situation?
>
> This insult is unacceptable.
> I just a few days ago stated that i intend to implement SDR within what the
> com
On Mon, 29 Jan 2024, 22:23 Cosmin Stejerean via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Jan 28, 2024, at 7:54 AM, Kieran Kunhya wrote:
> >
> > So work like Anton's threading, YUVJ removal etc, that couldn't be funded
> > via bounti
>
> I guess that conculdes the "most serious schism in the project since the
> fork"
> until the next most serious ?
>
If you think that was the sole consequence of your attempt to ram SDR into
ffmpeg then I have no words.
Kieran
>
___
ffmpeg-devel mai
On Tue, 30 Jan 2024 at 10:12, Nicolas George wrote:
> Kieran Kunhya (12024-01-29):
> > A commercial SOW with a private company that took the commercial risk on
> > that contract taking longer or being more difficult than anticipated or
> > someone else doing the work
On Tue, 30 Jan 2024 at 10:31, Nicolas George wrote:
> Kieran Kunhya (12024-01-30):
> > The patches were on the mailing list for months, there was a presentation
> > at VDD (livestreamed too).
>
> “But Mr. Dent, the plans have been available in the local planning
> office
On Tue, 30 Jan 2024 at 10:46, Nicolas George wrote:
> Kieran Kunhya (12024-01-30):
> > So you agree the proposed Statement of Work idea in this thread isn't
> going
> > to fly as it won't cover actual code review?
>
> If that is what you read in what I wrote, I
On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> > IMO hasty actions and avoidable drama may cause damage to the project
>
> What would be a hasty action? I've seen far too much people calling action
> over stuff discussed for weeks/months as "
On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer
wrote:
> Hi Jonatas, Remi
>
> _THIS_ reply shows why i LOVE SPI
>
> I mean this is transparency, anyone try to get something similar from a
> corporation
>
> Just in the last 48h i have seen a reminder from a CEO about "shareholder
> agreement"
>
On Wed, 31 Jan 2024 at 18:40, Jonatas L. Nogueira
wrote:
> I assume you don't mean National Association of Broadcasters by "NAB", so
> I would need to know what booth you're talking about.
>
That is what I mean.
Kieran
> On Wed, Jan 31, 2024 at 3:22 PM Kieran
On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Jan 31, 2024, at 11:07 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> >
> > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya w
On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer
wrote:
> On Wed, Jan 31, 2024 at 08:19:04PM +0000, Kieran Kunhya wrote:
> > On Wed, 31 Jan 2024 at 19:17, Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> [...]
> > > This is most likely
On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis
wrote:
> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>
> Not to derail this fine thread, but what forks does the Merge Forks
> project refer to?
>
> - Derek
>
I also added a note that
On Wed, 31 Jan 2024, 22:40 Michael Niedermayer,
wrote:
> On Wed, Jan 31, 2024 at 09:54:05PM +0000, Kieran Kunhya wrote:
> > On Wed, 31 Jan 2024 at 21:43, Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Jan 31, 2024 at 08:19:04PM
I have no relation and none of the above.
There were some large items of piping that needed carrying and I did that
to help my fellow human being through love of humankind.
Kieran
On Fri, 2 Feb 2024 at 14:52, Michael Niedermayer
wrote:
> On Wed, Jan 31, 2024 at 10:45:50PM +0000, Kieran Kun
> Either way, iam interrested in helping with coverity work while
> at the same time this environment where peole finger point and say
> "is way too much" is something i dont feel comfortable to work in.
>
So you make an RFC but you only want comments that agree with you?
> maybe doing it per ho
On Tue, 6 Feb 2024 at 10:58, Nicolas Gaullier
wrote:
> >Envoyé : vendredi 2 février 2024 16:24
> >À : ffmpeg-devel@ffmpeg.org
> >Objet : [PATCH 0/1] avformat/mpegts: fix first NAL start code splited in
> two different packets
> >
> >This issue happens in the following case:
> >- unaligned PES and
On Tue, 6 Feb 2024 at 11:39, Nicolas Gaullier
wrote:
> >> If you think it would be better to have a related trac ticket, just
> >> tell me, I can do this of course.
> >> Nicolas
> >>
> >
> >I think it's ok. I wish it were less ugly but I guess it can't be.
> >
> >Kieran
>
> Yes, of course! I am r
$subj
As discussed at FOSDEM.
Kieran
0001-vvcdec-Mark-as-experimental.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
ffm
On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
> On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
>
> > $subj
> >
> > As discussed at FOSDEM.
> >
>
> Author of this patch above is forced to FUZZ this decoder until
> experimental flag is removed.
&
On Thu, 8 Feb 2024 at 06:01, Nuo Mi wrote:
> On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote:
>
> > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
> >
> > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
> > >
> > > &
Hello,
I would like to know if fate-suite.ffmpeg.org is very slow to sync for
anyone else?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-d
601 - 700 of 800 matches
Mail list logo
