Kieran Kunhya (12024-02-20):
> This isn't the same thing. The TC is more like a jury where a juror can
> have an opinion and their opinion can be swayed by arguments during private
In a jury trial, the defense can recuse any juror they want.
--
Nicolas George
>
> i disagree
>
> A TC member who wants to block a patch and wants to decide if a patch
> should be
> blocked is in the same situation as
>
> a Judge who wants to sue someone and wants to judge that someone.
>
Whilst I am not getting into a whole philosophical legal discussion about
this (to
On Mon, Feb 19, 2024 at 10:37:15PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-18 23:34:39)
[...]
> > > > But I think it is reasonable that parties of a disagreement cannot be
> > > > the judge of the disagreement.
> > >
> > > Why not? This is one of those truthy-sounding
On Mon, Feb 19, 2024 at 4:40 PM Gyan Doshi wrote:
>
>
> On 2024-02-19 08:00 pm, Vittorio Giovara wrote:
> > On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote:
> >
> >> The TC is invoked when there's an intractable dispute. So the dispute
> >> precedes the TC activity hence the parties to the
Anton Khirnov (12024-02-19):
> I am explaining all this in such detail because people in this thread
> keep using this term apparently without realizing that in order to have
> a conflict of interest there must in fact be multiple interests that are
> in conflict, not just a person having multiple
Quoting Michael Niedermayer (2024-02-18 23:34:39)
> More formally, you could define a "party to a disagreement" as
> all minimal sets of people whos non existence would resolve the disagreement
That is a useless definition in practice, because it is unknowable. It
is very common that developers
On 2024-02-19 08:00 pm, Vittorio Giovara wrote:
On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote:
The TC is invoked when there's an intractable dispute. So the dispute
precedes the TC activity hence the parties to the dispute are the main
opposing participants at the venue of the dispute
Vittorio Giovara (12024-02-19):
> > By that reasoning, it could be argued that someone proposed the inclusion of
> > this rule being discussed only to set up a backdoor in the process and
> > thwart any chance of a functioning process for the community
> As mentioned, it's just a hyperbole,
On Mon, Feb 19, 2024 at 3:28 PM Nicolas George wrote:
> Vittorio Giovara (12024-02-19):
> > By that reasoning, someone could argue that you forced the inclusion of
> > this rule being discussed only to set up a backdoor in the process and
> > thwart any chance of a functioning process for the
Vittorio Giovara (12024-02-19):
> There are many in the section snipped below the original email.
You are making accusations. You know what it implies.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, Feb 19, 2024 at 3:30 PM Nicolas George wrote:
> Vittorio Giovara (12024-02-19):
> > I understand your concerns regarding the potential consequences of
> changing
> > this rule, and I acknowledge the importance of upholding the principles
> > that underpin our project's governance.
On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote:
>
>
> On 2024-02-19 03:16 am, Vittorio Giovara wrote:
> > On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote:
> >
> >>
> >> On 2024-02-18 11:33 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2024-02-18 05:06:30)
> b) what "maximalist"
Vittorio Giovara (12024-02-19):
> I understand your concerns regarding the potential consequences of changing
> this rule, and I acknowledge the importance of upholding the principles
> that underpin our project's governance. However, I must express my
> disappointment in the insinuation that I am
Vittorio Giovara (12024-02-19):
> By that reasoning, someone could argue that you forced the inclusion of
> this rule being discussed only to set up a backdoor in the process and
> thwart any chance of a functioning process for the community
Can you explain the part of your reasoning where you
On Mon, Feb 19, 2024 at 9:54 AM Nicolas George wrote:
> Vittorio Giovara (12024-02-18):
> > While I understand that you're referencing the existing rules that we've
> > collectively agreed upon, I believe it's crucial for us to periodically
> > review and refine these rules to ensure they remain
On Mon, Feb 19, 2024 at 9:45 AM Nicolas George wrote:
> Vittorio Giovara (12024-02-18):
> > If it helps, I'll block the patch so that Anton can vote in the TC.
> > Do you see how slippery (and insane) this interpretation of the rule
> > becomes?
>
> The rules are written assuming people in the
Vittorio Giovara (12024-02-18):
> While I understand that you're referencing the existing rules that we've
> collectively agreed upon, I believe it's crucial for us to periodically
> review and refine these rules to ensure they remain aligned with our
> evolving community values and goals.
This
Vittorio Giovara (12024-02-18):
> If it helps, I'll block the patch so that Anton can vote in the TC.
> Do you see how slippery (and insane) this interpretation of the rule
> becomes?
The rules are written assuming people in the project are working in good
faith for the benefit of the project.
On 2024-02-19 03:16 am, Vittorio Giovara wrote:
On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote:
On 2024-02-18 11:33 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-18 05:06:30)
b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
On Mon, Feb 19, 2024 at 2:17 AM Michael Niedermayer
wrote:
> On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote:
> > On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
> > wrote:
> > >
> > > * A disagreement implies that there are 2 parties
> > > * And we assume here that what
On 17 Feb 2024, at 13:31, Rémi Denis-Courmont wrote:
> Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit :
>> As a TC member who is part of the disagreement, I believe your
>> participation is recused.
>
> Obviously not. We don't want to get into a situation whence TC members
Hi,
On Sun, Feb 18, 2024 at 5:34 PM Michael Niedermayer
wrote:
> More formally, you could define a "party to a disagreement" as
> all minimal sets of people whos non existence would resolve the
> disagreement
>
I think I agree with this interpretation of the rules.
Ronald
On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote:
> On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
> wrote:
> >
> > * A disagreement implies that there are 2 parties
> > * And we assume here that what one party wants is better for FFmpeg than
> > what the other wants.
> > *
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
wrote:
>
> * A disagreement implies that there are 2 parties
> * And we assume here that what one party wants is better for FFmpeg than what
> the other wants.
> * The TC needs to find out which partys choice is better or suggest a 3rd
>
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
wrote:
> Hi
>
> On Sun, Feb 18, 2024 at 07:20:43PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-18 01:43:14)
> > > "If the disagreement involves a member of the TC"
> > > does IMHO not preclude commenting on a patch.
>
Hi
On Sun, Feb 18, 2024 at 07:20:43PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-18 01:43:14)
> > "If the disagreement involves a member of the TC"
> > does IMHO not preclude commenting on a patch.
> >
> > For a disagreement we need 2 parties. For example one party who
>
On Sun, Feb 18, 2024 at 10:25 PM Nicolas George wrote:
> Vittorio Giovara (12024-02-18):
> > While I value your insights, I'd like to offer a different
> > viewpoint regarding the practice of recusing oneself from discussions.
>
>
>
> That might be your viewpoint, but that is not what
On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote:
>
>
> On 2024-02-18 11:33 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-02-18 05:06:30)
> >> b) what "maximalist" interpretation?
> > A non-maximalist interpretation would be that a TC member is only
> > excluded from voting when they
Vittorio Giovara (12024-02-18):
> While I value your insights, I'd like to offer a different
> viewpoint regarding the practice of recusing oneself from discussions.
That might be your viewpoint, but that is not what the rules we all
agreed upon say.
--
Nicolas George
On Sun, Feb 18, 2024 at 7:40 PM Nicolas George wrote:
> Anton Khirnov (12024-02-18):
> > That is absurd and makes no sense.
>
> That makes absolute sense, unless you consider your opinion is worth
> more than the opinion of the other people in the project.
>
> A spot on the TC is
Rémi Denis-Courmont (12024-02-18):
> I trust that you do know the meaning of the auxillary "should". That very
> definitely and very obviously eliminates any "maximalist" interpretations.
Indeed. And I repeat what I already said in another mail:
If somebody dishonest wants to exploit that
Le sunnuntaina 18. helmikuuta 2024, 20.40.14 EET Nicolas George a écrit :
> The world is “involves”, its meaning is inherently maximalist.
The wording is very clear (emphasis added): "If the disagreement involves a
member of the TC, that member SHOULD recuse themselves from the decision."
I
On 2024-02-18 11:33 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-18 05:06:30)
b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
excluded from voting when they authored the patch that is being
disputed.
If the promulgators meant
Rémi Denis-Courmont (12024-02-18):
> This is an utterly absurd interpretation. By that logic, a TC member would
> automatically become party to the disagreement by expressing an opinion
> within
> even the TC itself.
This is the most hypocritical argument put forward in this discussion
yet.
>
Le sunnuntaina 18. helmikuuta 2024, 2.43.14 EET Michael Niedermayer a écrit :
> > > You clearly are one of the parties to the disagreement, and "recuse
> > > themselves from the decision" is self-explanatory.
> >
> > Such a maximalist interpretation makes no sense - why should my opinion
> >
Anton Khirnov (12024-02-18):
> A non-maximalist interpretation would be that a TC member is only
> excluded from voting when they authored the patch that is being
> disputed.
If the rules were meant to be interpreted that way, they would have been
written “if the patch was proposed by a member of
Quoting Michael Niedermayer (2024-02-18 01:43:14)
> "If the disagreement involves a member of the TC"
> does IMHO not preclude commenting on a patch.
>
> For a disagreement we need 2 parties. For example one party who
> wants a patch in and one who blocks the patch. or 2 parties where both
>
Quoting Gyan Doshi (2024-02-18 05:06:30)
> b) what "maximalist" interpretation?
A non-maximalist interpretation would be that a TC member is only
excluded from voting when they authored the patch that is being
disputed.
> - I think the current patch is fine, you don't. That's a disagreement
>
On 2024-02-18 01:25 am, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-17 13:37:38)
On 2024-02-17 05:52 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-17 12:46:27)
As a TC member who is part of the disagreement, I believe your
participation is recused.
No, I do not think "TC
On Sat, Feb 17, 2024 at 08:55:43PM +0100, Anton Khirnov wrote:
> Quoting Gyan Doshi (2024-02-17 13:37:38)
> > On 2024-02-17 05:52 pm, Anton Khirnov wrote:
> > > Quoting Gyan Doshi (2024-02-17 12:46:27)
> > >> As a TC member who is part of the disagreement, I believe your
> > >> participation is
Quoting Gyan Doshi (2024-02-17 13:37:38)
> On 2024-02-17 05:52 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-02-17 12:46:27)
> >> As a TC member who is part of the disagreement, I believe your
> >> participation is recused.
> > No, I do not think "TC members who commented on a patch lose
On 2024-02-17 05:52 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-17 12:46:27)
As a TC member who is part of the disagreement, I believe your
participation is recused.
No, I do not think "TC members who commented on a patch lose their right
to vote" is a reasonable interpretation of
Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit :
> As a TC member who is part of the disagreement, I believe your
> participation is recused.
Obviously not. We don't want to get into a situation whence TC members have an
incentive not to participate in regular code reviews
Quoting Gyan Doshi (2024-02-17 12:46:27)
> As a TC member who is part of the disagreement, I believe your
> participation is recused.
No, I do not think "TC members who commented on a patch lose their right
to vote" is a reasonable interpretation of that rule.
--
Anton Khirnov
On 2024-02-16 02:33 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-15 17:47:49)
This patch facilitates a certain productive use of ffmpeg with respect
to processing of live inputs that wasn't possible earlier,
and which currently is being used successfully by multiple people over
the
On 2024-02-16 07:25 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
On 2024-01-28 04:24 pm, Anton Khirnov wrote:
a) it
Quoting Gyan Doshi (2024-02-15 17:47:49)
> This patch facilitates a certain productive use of ffmpeg with respect
> to processing of live inputs that wasn't possible earlier,
> and which currently is being used successfully by multiple people over
> the past few weeks.
> It applies a processing
On 2024-02-16 01:56 am, Kieran Kunhya wrote:
On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote:
On 2024-02-15 09:40 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-15 13:31:59)
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the
On Thu, 15 Feb 2024 at 16:48, Gyan Doshi wrote:
>
>
> On 2024-02-15 09:40 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2024-02-15 13:31:59)
> >> On 2024-02-15 04:17 pm, Anton Khirnov wrote:
> >>> Hi,
> >>> sorry for the delay, I've been busy fixing things for the release
> >>> Quoting Gyan
On 2024-02-15 09:40 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2024-02-15 13:31:59)
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
On 2024-01-28 04:24 pm, Anton
Quoting Gyan Doshi (2024-02-15 13:31:59)
> On 2024-02-15 04:17 pm, Anton Khirnov wrote:
> > Hi,
> > sorry for the delay, I've been busy fixing things for the release
> > Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
> >> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> a) it would
On 2024-02-15 04:17 pm, Anton Khirnov wrote:
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
On 2024-01-28 04:24 pm, Anton Khirnov wrote:
a) it would mean essentially inlining this decoder in the demuxer.
Why
Hi,
sorry for the delay, I've been busy fixing things for the release
Quoting Gyan Doshi via ffmpeg-devel (2024-01-29 05:00:33)
> On 2024-01-28 04:24 pm, Anton Khirnov wrote:
> >> a) it would mean essentially inlining this decoder in the demuxer.
> > Why is that a problem? This decoder seems like
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
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-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM
>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-25 10:29 am, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> Set up framework for non-PCM decoding in-place
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-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Set up framework for non-PCM decoding in-place and
add support for Dolby-E
>
> 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
Quoting Gyan Doshi (2024-01-26 05:23:50)
>
>
> On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> >>
> >> On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
> >>> Gyan Doshi:
> Set up framework for non-PCM decoding in-place and
> add support for Dolby-E decoding.
>
On 2024-01-25 06:47 pm, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
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.
---
configure
On 2024-01-25 10:29 am, Andreas Rheinhardt wrote:
Gyan Doshi:
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.
---
configure | 1 +
doc/decoders.texi | 40 +++
On Tue, Jan 23, 2024 at 9:54 AM Kieran Kunhya wrote:
> Quite the opposite, Dolby E by design is cotimed with the video frame and
> S302M PTS is also cotimed with the video frame.
> The ambiguity is when Dolby E is misaligned, is it misaligned to the next
> video frame, or the previous one.
I
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 the previous PTS or the next
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 the previous PTS or the next one.
Isn't the correct behavior to determine the offset within the raw PCM
payload, and use that
On 2024-01-23 03:58 pm, Nicolas Gaullier wrote:
+#define IS_NONPCMSYNC_16(state) ((state & 0x00) ==
NONPCMSYNC_16MARKER)
Is this single 32 bits marker enough to avoid a fake detection ?
It will have to do. The modal number of payload packets expected in a
single s302m
>+#define IS_NONPCMSYNC_16(state) ((state & 0x00) ==
>NONPCMSYNC_16MARKER)
Is this single 32 bits marker enough to avoid a fake detection ?
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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.
> >>
> >> Useful for direct transcoding of
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.
Useful for direct transcoding of non-PCM audio in live inputs.
Does this handle a Dolby E packet spanning
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
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.
---
configure | 1 +
doc/decoders.texi | 40 +++
libavcodec/s302m.c | 609 +
3 files
70 matches
Mail list logo
