the
reins and I've wasted enough of my life on it.
--
Anton Khirnov
___
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
asking more people to volunteer, because we didn't have enough
candidates (which by the way you did as well).
And the cherry on the cake is that after spuriously accusing me of fraud
you claim that we need friendly smiles and mutual respect. How about you
start?
[1] https://lists.ffmpeg.org
s your way.
Or put differently, all our democracy is just pretend and in the end
it's you personally who calls the shots. In that case you should have
the guts to come out and say so directly instead of hiding behind
walls of fallacious arguments. Then I wouldn't need to waste time
7;s not "unfriendly people". It's you. It's always been
you. Other projects do not have these problems at such a regular basis.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/lis
Quoting compn (2024-12-19 17:32:26)
> On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote:
>
> > Quoting James Almer (2024-12-19 14:04:53)
> > > On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > > > Quoting Kieran Kunhya via ffmpeg-devel (2024
ixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc.
>
> Fixes: ticket #11239
> Signed-off-by: Niklas Haas
> Sponsored-by: Sovereign Tech Fund
> ---
> libswscale/swscale_unscaled.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-
Quoting James Almer (2024-12-19 14:04:53)
> On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> >> Hello,
> >>
> >> My messages are being blocked on the mailing list. How is this fair that
> >
subscribed people).
--
Anton Khirnov
___
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".
is could really use some more explanation.
--
Anton Khirnov
___
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".
Quoting James Almer (2024-12-16 00:13:43)
> On 12/14/2024 5:49 PM, Timo Rothenpieler wrote:
> > On 14.12.2024 10:16, Anton Khirnov wrote:
> >> This could use some explanation.
> >
> > I unfortunately don't remember the exact reason, but it ran into this
>
Quoting Timo Rothenpieler (2024-12-14 22:48:17)
> On 14.12.2024 10:17, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2024-12-12 20:55:27)
> >> From: Dennis Sädtler
> >>
> >> Based on enhanced-rtmp v2 spec published by Veovera:
> >> https://
Hi all,
the poll has concluded, with 30 votes out of 52. Results are available
at [1], the winning committee is:
* Martin Storsjö
* Michael Niedermayer
* Anton Khirnov
* Niklas Haas
* Jan Ekström
Raw ballots in CSV format are attached for posterity.
CCing root - please update the tc@ mailbox
Quoting Marton Balint (2024-12-16 09:47:39)
>
>
> On Mon, 16 Dec 2024, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2024-12-15 01:02:42)
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/APIchanges | 3 +++
> >> liba
Hi all,
the vote has been started. If you are in the GA (the
tools/general_assembly.pl script lists your name), you should have
received an email by now. If you did not, complain in this thread.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg
dd AV_FRAME_FLAG_LOSSLESS.
I feel ambivalent about this. This is really a decoder property, and
attaching it to frames allows it propagate far away to places where it
makes no sense (the same holds for other existing AVFrame fields, but
I'd prefer for them to be removed).
--
Anton Khirno
Hi all,
this is a reminder that the CC election starts tomorrow morning (CET),
with the following candidates:
* Vittorio Giovara
* James Almer
* Marth64
* Anton Khirnov
* compn
* Jean-Baptiste Kempf
* Rémi Denis-Courmont
Cheers,
--
Anton Khirnov
Quoting Gyan Doshi (2024-12-14 13:43:52)
>
>
> On 2024-12-14 06:00 pm, Anton Khirnov wrote:
> > Hi all,
> > this is a reminder that the vote closes some time after Sunday midnight
> > (CET). So far we have just 24 votes out of 52, so please vote ASAP if
> > y
Hi all,
this is a reminder that the vote closes some time after Sunday midnight
(CET). So far we have just 24 votes out of 52, so please vote ASAP if
you have not done so yet.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel
tests.
This seems like a hack to me.
We should not be testing for bitexact output from code that is not under
our control and does not guarantee bitexactness.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
> libavfilter/af_amix: fixed amix format when graph load
This needs a better explanation of what is being done and why.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
).
>
> This commit fixes libavutil\tests\file.c test, which would crash when
> trying to write to a read-only memory page.
>
> Signed-off-by: Kacper Michajłow
> ---
> libavutil/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Queued, will push
alpha_channel_clip_flag;
> +uint8_t alpha_channel_clip_type_flag;
We generally prefer not to duplicate the bitstream values/spec names
verbatim, because they are optimized for a different purpose.
Specifically
* 'alpha' in names is redundant with the struct name
* _flag is redundant
* store
ary
picture with AuxId=AUX_ALPHA.
Also, I'd prefer the interaction with multiview to be clearer, with e.g.
a warning message when both are present, and fewer assumptions about
only one of them being present spread over the code.
--
Anton Khirnov
ly appreciate it if someone could help implement it.
Do we need a complete implementation, when we do not intend to support
all the possible combinations of all the possible multi-layer types? I'd
prefer not to handle all the insanity until we really need to.
--
Anton Khirnov
_
Quoting Timo Rothenpieler (2024-12-13 20:17:07)
> I intend to push this series soon.
> It's been tested to work, and no major changes to the spec have happened.
Some tests sure would be nice.
--
Anton Khirnov
___
ffmpeg-devel mailing list
f
XTRADATA,
> + flv->mt_extradata[track_idx],
> + flv->mt_extradata_sz[track_idx]);
> +if (ret >= 0) {
This should fail when ret < 0
--
Anton Khirnov
___
This could use some explanation.
--
Anton Khirnov
___
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
ytes.
>
> I think it is reasonable to concatenate the CC data until a frame can be
> exported.
> Since I don't know if there is a frame exported when all of the video
> frame's data slices
> have been skipped (e.g. B frame with open GOP),
what exactly do you mean by &#x
Quoting Martin Storsjö (2024-12-12 18:40:27)
> On Thu, 12 Dec 2024, Anton Khirnov wrote:
>
> > pthread_t is currently defined as a struct, which gets placed into
> > caller's memory and filled by pthread_create() (which accepts a
> > pthread_t*).
> >
> &g
pthread_t is currently defined as a struct, which gets placed into
caller's memory and filled by pthread_create() (which accepts a
pthread_t*).
The problem with this approach is that pthread_join() accepts pthread_t
itself rather than a pointer to it, so it gets a _copy_ of this
structure. This ca
Hi Nicolas,
Quoting Nicolas Gaullier (2024-12-06 10:37:03)
> >De : Anton Khirnov
> >Envoyé : jeudi 5 décembre 2024 15:06
> >Hi,
> >I believe a similar approach was tried by Gyan earlier this year and
> >unanimously rejected by the TC [1-3].
> >
> >[1
Quoting James Almer (2024-11-30 14:41:20)
> with no speaker location implied
Also, is it really the case that no speaker location is implied? I'd
think mono (as opposed to just "1 channel") does carry the implication
is is the center channel.
Quoting Scott Theisen (2024-12-10 21:42:06)
> On 12/9/24 02:31, Anton Khirnov wrote:
> > Quoting Scott Theisen (2024-11-30 08:38:54)
> >> On 11/25/24 00:42, Anton Khirnov wrote:
> >>> Quoting Scott Theisen (2024-11-14 05:37:49)
> >>>>
---
doc/APIchanges | 3 +++
libavcodec/packet.c | 33 +
libavcodec/packet.h | 7 +++
libavcodec/version.h | 2 +-
4 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 5d75b6077d..31b9ed175b 100644
--- a/
This can be useful in other places, e.g. it can replace objpool in
fftools.
The API is modified in the following nontrivial ways:
* opaque pointers can be passed through to all user callbacks
* read and write were previously separate callbacks in order to
accomodate the caller wishing to write a
Remove now-unused objpool.
---
fftools/Makefile | 1 -
fftools/objpool.c| 131 ---
fftools/objpool.h| 37
fftools/sync_queue.c | 93 ++
4 files changed, 29 insertions(+), 233 deletions(-)
delete mode
The queue needs to track each frame/packet's stream index, this is
achieved by maintaining a parallel AVFifo instance for that purpose.
This is simpler than implementing custom AVContainerFifo callbacks.
---
fftools/ffmpeg_sched.c | 14 ++---
fftools/ffmpeg_utils.h | 10 --
fftools/thread_
RC, and she's working on removing
the need for that from vulkan decoding, which should be a more proper
fix here.
--
Anton Khirnov
___
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".
Hi all,
the vote has been started (with a slight delay due to server issues). If
you are in the GA (the tools/general_assembly.pl script lists your
name), you should receive an email soon. If you do not, complain in this
thread.
--
Anton Khirnov
Looks good, thank you.
--
Anton Khirnov
___
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".
Quoting Scott Theisen (2024-11-30 08:38:54)
> On 11/25/24 00:42, Anton Khirnov wrote:
> > Quoting Scott Theisen (2024-11-14 05:37:49)
> >> @@ -85,7 +85,13 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
> >> if (s->h
= sr;
> > av_channel_layout_uninit(&avctx->ch_layout);
> > -av_channel_layout_default(&avctx->ch_layout,
> > channels);
> > +if (dual_mono) {
> > +
Quoting James Almer (2024-12-08 17:46:18)
> On 12/7/2024 9:25 PM, Lynne via ffmpeg-devel wrote:
> > On 06/12/2024 02:01, Lynne via ffmpeg-devel wrote:
> >> On 28/11/2024 23:29, Anton Khirnov wrote:
> >>> Hi all,
> >>> the current Technical Commit
Hi all,
we currently have 5 candidates for CC:
- Vittorio Giovara
- James Almer
- Marth64
- Anton Khirnov
- compn
A the number of candidates equals the number of CC members, there is no
point in holding a vote. I therefore propose to wait a week. If any new
candidates appear in that time, we hold
Hi all,
since yesterday, one candidacy was withdrawn and one added, so we are
still at 6 candidates:
- Michael Niedermayer
- Martin Storsjö
- Anton Khirnov
- Niklas Haas
- Jan Ekström
- Alexander Strasser
I intend to start the vote tomorrow (2024-12-09) morning (CET). Current
GA as generated by
Hi all,
we only have 4 volunteers for the CC so far, so need at least one more
person. Ideally several, since elections are better when they are
competitive.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Hi all,
we have 6 volunteers for the TC, so I think the vote can start on Monday
as previously announced.
If someone else still wants to volunteer, please do so ASAP.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
matter who it comes from.
2) CC should look at patterns of behaviour rather than strictly focus on
individual infractions.
3) Enforcement should be consistent and publicly announced.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321564.html
[3] Message-Id <20240412122920.gb3...@haasn.xyz>
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325588.html
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
Mention they are always owned and freed by the codec, except when using
deprecated avcodec_close().
Reported-By: DEATH on IRC
---
libavcodec/avcodec.h | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/a
I hereby volunteer for the TC.
--
Anton Khirnov
___
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".
a "property", like captions or film grain parameters. Therefore it's
> not a field used for initialization.
That semantics would be useless, since you can just as well extract the
same information from the frame itself.
--
Anton Khirnov
_
Quoting Manuel Lauss (2024-11-28 21:58:09)
> On Thu, Nov 28, 2024 at 3:19 PM Anton Khirnov wrote:
> >
> > Quoting Manuel Lauss (2024-11-26 15:25:30)
> > > Hello,
> > >
> > > I'd like to add some audio support for the old libavformat/smush
>
ublic list. Suggestions
> anyone
> how/where to handle that ?
A text file in a git repo accessible to e.g.
* current GA members
* current TC and CC members
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpe
e with the relevant pointer being NULL.
If you have a way of actually triggering any of these, I'd like to see
it.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
conduct
violationd and other personal conflicts in the project. If you would
like to be a CC member, please say so in a reply to this email.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
technical disputes. If
you would like to be a TC member, please say so in a reply to this
email.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
frame).
>
> What is the best way to support this scenario?
Meaning you have to parse the coded bytestream to get the audio? Is
there at least some signalling that audio is present at al?
The options I can think of are:
* parse the bytestream in the demuxer
* write a bitstream filter
--
Anto
ei.h | 129 +++-
> 5 files changed, 583 insertions(+), 25 deletions(-)
This seems like way too much complexity for what essentially seems to be
just weave inside a decoder.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
vember/335757.html
>
> Cover letter with links to videos showing before/after:
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-November/335755.html
Pushed all of these.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
Quoting Michael Niedermayer (2024-11-27 23:18:25)
> Hi
>
> On Tue, Nov 26, 2024 at 11:48:54AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-10-15 00:46:50)
> > > +@item qtable
> > > +-1 (default, automatic), 0 use 8bit default, 1, use >8bit
Quoting Nicolas Gaullier (2024-10-27 01:01:23)
> Signed-off-by: Nicolas Gaullier
> ---
> libavcodec/ac3dec_fixed.c | 3 +++
> libavcodec/ac3dec_float.c | 2 ++
> 2 files changed, 5 insertions(+)
Will push soonish.
--
Anton Khirnov
_
Quoting James Almer (2024-11-28 13:58:46)
> On 11/28/2024 9:57 AM, Anton Khirnov wrote:
> > Quoting James Almer (2024-11-27 14:31:35)
> >> @@ -222,10 +223,25 @@ static int dovi_rpu_init(AVBSFContext *bsf)
> >>
> >> s-&g
; +ret = avcodec_parameters_from_context(bsf->par_out, avctx);
This still seems a bit too scorched-earth to me. I'd prefer to give
ff_dovi_configure_ext() a side data list as a parameter and have it
modify that.
--
Anton Khirnov
s to the gas-preprocessor repo.)
>
> github is a little messy it seems. We have a members team that gives write
> access
> to 5 repositories but even though we have 3 "members" only one was in the
> members team, sorry about that. everyone on github should now have write
> access
> to teh repositories (if they did not have already).
> btbn has further admin access as he needed that for some things
Sounds like something that should be documented in infra.txt.
--
Anton Khirnov
___
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".
we called
> pthread_mutex_unlock(), and then called pthread_cond_signal(); that is, we
> first unlocked
> the mutex associated with the shared variable, and then signaled the
> corresponding
> condition variable. We could have reversed these two steps; SUSv3 permits
> them to
&
Quoting Tomas Härdin (2024-11-22 17:10:10)
> fre 2024-11-22 klockan 15:50 +0100 skrev Anton Khirnov:
> > Quoting Tomas Härdin (2024-11-22 10:51:21)
> > > Hi all
> > >
> > > So after looking at options for how to better deal with ID3v2 I'm
> > &
Quoting Thilo Borgmann via ffmpeg-devel (2024-11-15 19:52:05)
> Am 21.06.24 um 13:52 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2024-06-21 12:43:17)
> >> From: Thilo Borgmann via ffmpeg-devel
> >>
> >&g
queueOutputBuffer(codec, out_info,
> timeout_us);
> +return 0;
> +}
> +
> +ff_mutex_lock(&s->output_mutex);
> +
> +n = -1;
> +while (n < 0 && !s->encode_status) {
> +if (av_fifo_can_read(s->output_index)) {
&g
this silently errors on the ones it doesnt ignore, it was more informative
> > before
>
> It still prints the error message after returning AVERROR_INVALIDDATA
> from mjpeg_decode_app():
> [mjpeg @ 0x7fc4a0002dc0] unable to decode APP fields: Invalid data
> found when proces
d, 6 insertions(+), 1 deletion(-)
Approved by Niklas on IRC, will push soonish.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
Quoting Michael Niedermayer (2024-10-15 00:46:50)
> +@item qtable
> +-1 (default, automatic), 0 use 8bit default, 1, use >8bit default
int seems like the wrong type then.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
ion (nb_samples / s->chs[ch].uv) is the inverse of MSE.
> Therefore, when the error is larger, the final logarithm result will be
> lower. This is backwards from the usual interpretation that more error has
> a lower signal-to-noise ratio.
>
> Is there interest in changing the
_layout_uninit(&avctx->ch_layout);
> -av_channel_layout_default(&avctx->ch_layout,
> channels);
> +if (dual_mono) {
> +av_channel_layout_custom_init(&avctx->ch_layout,
> 2);
This can fai
al files and using the PSNR value in FATE
> > will be an option.
>
> The original files are approximately 10 MB. Any objection/concerns to
> adding them to FATE, which can then apply the conformance requirements
> specified in the standard?
IMO it should not be a problem,
o:=-
:_\/_:'.:::. /)\*''* .|.* '.\'/.'_\(/_'.':'.'
: /\ : : '*_\/_* | | -= o =- /)\' *
'..' ':::' * /\ * |'| .'/.\'. '._
*__*..* | | : |. |' .---"|
_* .-' '-. | | .--'| || | _||
.-'| _.| |||
> > index 161442df95..97e4c47d45 100644
> > --- a/libavcodec/version_major.h
> > +++ b/libavcodec/version_major.h
> > @@ -57,5 +57,9 @@
> >
> > // reminder to remove CrystalHD decoders on next major bump
> > #define FF_CODEC_CRYSTAL_HD(LIBAVCODEC_VERSION_MAJ
Your mailer mangled the newlines in the patch. Consider a different
mailer or sending it as an attachment.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Your patch seems to be against something other than git master, and
fails to apply.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
d like to use the project's resources while
avoiding scrutiny and oversight.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffm
mythical beast?
--
Anton Khirnov
___
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".
would scan ~/.ffmpeg/plugins/ or something like that
> and load all compatible ones.
> A restriction to a simple 1 input link, 1 output link with possibility of
> future extension would already cover likely 90% of use cases.
>
> anton, would you be interrested to implement something
Avoids a useless -stats_period wait before exiting.
Reported-by: names_are_hard
---
fftools/ffmpeg_sched.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 318ec44b73..6a58661a5c 100644
--- a/fftools/ff
Their semantics will be changed in the following commit to not be
limited to muxing.
---
fftools/ffmpeg_sched.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index b8ed8ae3f8..318ec44b73 100644
--- a/f
To be used at their own request, when they do not wish to receive vote
emails.
---
tools/general_assembly.pl | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index 0dafa82e27..7e0f46093c 100755
--- a/tools/general_assembly.pl
+++ b/
At his own request, he can remove the entry whenever he likes.
---
tools/general_assembly.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index 7e0f46093c..bfcb67d988 100755
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
the semantics of
the codec ID. I suppose it's not a problem in practice as nobody is
likely to be using it, but it probably deserves at least a minor bump.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
d this
improve for our callers.
--
Anton Khirnov
___
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".
ame thought when looking at that thread, and the only
reason I did not send it to ML was my being on vacation. So let me
correct that now:
Splitting out libpostproc is easy and not worth even remotely close to
5K euro.
--
Anton Khirnov
___
ffmpeg-dev
te
> access to
> the specific repository.
>
> +In actively maintained areas, the maintainer has the last word in case of a
> technical disagreement.
Strongly against. It would lead to the project partitioning into walled
gardens each w
am in favor of this patch.
--
Anton Khirnov
___
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".
ncoder
> > instance,
> > right?
>
>
> x265 already crashes when trying to run two encodes with different settings
> in
> the same process, because it's storing some instance specific data in
> global variables
> that are overwr
chanism for giving such people voting power, but it's not
obvious how to make it automatic. Practical suggestions are welcome, I
guess.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpe
frame.h | 7 ---
> 2 files changed, 7 insertions(+), 4 deletions(-)
I think this warrants a micro bump and an APIchanges entry, so external
callers can reliably depend on this.
Otherwise looks good.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg
surprise
you that noone spends their time on work that will not be appreciated.
> Also to ask people to come, not even knowing why specific people dont come.
> And then assume everyone not coming, did so by their 100% free choice is
> anoth
raise the point that our infrastructure situation is
highly opaque
* you reply to it saying that everything is perfectly clear
Consider the possibility that it only looks clear to you because you are
the sole person with full access to everything.
Consider also that because thise keeps getting raised r
Should have no functional effect on its own, but will be useful in
following commits.
---
libavcodec/pthread_frame.c | 253 +++--
1 file changed, 155 insertions(+), 98 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 1b1b96623
Propagating decoder state between per-thread contexts with frame
threading currently works as follows:
0) Every frame thread has its own "child" decoder context,
1) Frame thread T0 decodes the frame header and updates its context
accordingly. At most one frame thread can be in this stage at a
Will be useful in following commits.
---
libavcodec/cfhd.c | 4 +++-
libavcodec/ffv1dec.c | 4 +++-
libavcodec/h263dec.c | 14 ++
libavcodec/h264dec.c | 5 -
libavcodec/hevc/hevcdec.c | 7 +--
libavcodec/mimic.c | 4 +++-
libavcodec/mpeg
a open dialoge, a calm discussion about what the underlaying
> issues are (if there are any). And to work towards correcting them.
How can we have a discussion that includes you when you refuse to
acknowledge there is something to discuss?
--
Anton Khirnov
___
1 - 100 of 1627 matches
Mail list logo
