>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of
>Jiaxun Yang
>Sent: Saturday, July 18, 2020 11:36 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Jiaxun Yang
>Subject: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection supp
On 7/19/20, Paul B Mahol wrote:
> On 7/19/20, Paul B Mahol wrote:
>> On 7/19/20, Steinar H. Gunderson wrote:
>>> On Sun, Jul 19, 2020 at 09:02:30PM +0200, Paul B Mahol wrote:
> Yes, this is the non-recursive version, which is O(n) in the number of
> samples. This is why I recommended the
Paul B Mahol (12020-07-21):
> Gonna apply this soon, as I'm happy with overall performance and output
> quality.
Did you get another developer to approve it? If not, the block still
stands.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-deve
On 7/21/20, Nicolas George wrote:
> Paul B Mahol (12020-07-21):
>> Gonna apply this soon, as I'm happy with overall performance and output
>> quality.
>
> Did you get another developer to approve it? If not, the block still
> stands.
You have just approved it with reply to this same thread.
>
>
On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
On Mon, Jul 20, 2020 at 11:04:38PM +0200, Marton Balint wrote:
50/60 fps timecode is using the field bit (which is the same as the phase
correction bit) to signal the least significant bit of a 50/60 fps timecode.
See SMPTE ST 12-1:2014 secti
On Tue, Jul 21, 2020 at 11:07:29AM +0200, Marton Balint wrote:
>
>
> On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Mon, Jul 20, 2020 at 11:04:38PM +0200, Marton Balint wrote:
> > > 50/60 fps timecode is using the field bit (which is the same as the phase
> > > correction bit) to si
On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
On Tue, Jul 21, 2020 at 11:07:29AM +0200, Marton Balint wrote:
On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
> On Mon, Jul 20, 2020 at 11:04:38PM +0200, Marton Balint wrote:
> > 50/60 fps timecode is using the field bit (which is the
On 7/21/20, Paul B Mahol wrote:
> On 7/21/20, Nicolas George wrote:
>> Paul B Mahol (12020-07-21):
>>> Gonna apply this soon, as I'm happy with overall performance and output
>>> quality.
>>
>> Did you get another developer to approve it? If not, the block still
>> stands.
>
> You have just appro
On 7/14/20, Rahul Lodha wrote:
> I wrote a code to mix two audio streams which is working. However,
> somehow `avfilter_graph_parse2` is not preserving the pad names
>
> For example, below is a filter spec
>
> ```
> filter_spec =
> "abuffer=time_base=1/48000:sample_rate=48000:sample_fmt=fltp:chann
On 7/21/20, Paul B Mahol wrote:
> On 7/14/20, Rahul Lodha wrote:
>> I wrote a code to mix two audio streams which is working. However,
>> somehow `avfilter_graph_parse2` is not preserving the pad names
>>
>> For example, below is a filter spec
>>
>> ```
>> filter_spec =
>> "abuffer=time_base=1/48
Paul B Mahol (12020-07-21):
> Also it is new patch.
All the more reason not to apply and wait for it to be reviewed and
tested. Fortunately, there is somebody both competent and interested
in the matter.
--
Nicolas George
signature.asc
Description: PGP signature
_
On Tue, Jul 21, 2020 at 02:41:16PM +0200, Nicolas George wrote:
>> Also it is new patch.
> All the more reason not to apply and wait for it to be reviewed and
> tested. Fortunately, there is somebody both competent and interested
> in the matter.
I don't intend to look more at this; Paul has made
Steinar H. Gunderson (12020-07-21):
> I don't intend to look more at this; Paul has made it clear what his position
> is, and I don't see the point in arguing further about it. Again, if someone
> else wants to approve the patch in this state, I'm fine by that, but I'm not
> doing it myself. (If a
On 7/21/20, Steinar H. Gunderson wrote:
> On Tue, Jul 21, 2020 at 02:41:16PM +0200, Nicolas George wrote:
>>> Also it is new patch.
>> All the more reason not to apply and wait for it to be reviewed and
>> tested. Fortunately, there is somebody both competent and interested
>> in the matter.
>
> I
On Tue, Jul 21, 2020 at 12:42:03PM +0200, Marton Balint wrote:
>
>
> On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Tue, Jul 21, 2020 at 11:07:29AM +0200, Marton Balint wrote:
> > >
> > >
> > > On Tue, 21 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Mon, Jul 20, 2020
Andreas Rheinhardt (12020-07-21):
> by setting the AVFMT_HEADER_CLEANUP flag.
>
> (Btw: concat_read_close() is not idempotent (it frees cat->files, but
> doesn't reset cat->nb_files), so this demuxer was incompatible with
> simply calling read_close generically upon read_header failure.)
If you t
On 7/20/20, Zachariah Brown wrote:
> I'm just an independent observer who has submitted just a single trivial
> patch that decided to stay subscribed to this mailing list to keep up to
> date with what is happening. I have no bone in this game but I feel like
> something needs to be said.
>
> Let
From: Gautam Ramakrishnan
This patch adds support to receive JPEG2000 RTP streams.
---
libavformat/Makefile | 1 +
libavformat/rtpdec.c | 1 +
libavformat/rtpdec_formats.h | 1 +
libavformat/rtpdec_jpeg2000.c | 116 ++
4 files changed, 119
How and when this was tested?
On 7/21/20, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds support to receive JPEG2000 RTP streams.
> ---
> libavformat/Makefile | 1 +
> libavformat/rtpdec.c | 1 +
> libavformat/rtpdec_formats.h | 1 +
> libav
On Tue, Jul 21, 2020 at 10:08 PM wrote:
>
> From: Gautam Ramakrishnan
>
> This patch adds support to receive JPEG2000 RTP streams.
> ---
> libavformat/Makefile | 1 +
> libavformat/rtpdec.c | 1 +
> libavformat/rtpdec_formats.h | 1 +
> libavformat/rtpdec_jpeg2000.c | 11
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 107 +++
1 file changed, 97 insertions(+), 10 deletions(-)
diff --git a/libavcod
From: Gautam Ramakrishnan
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to
From: Gautam Ramakrishnan
This patch sets a flag when the processing of the
main header is complete.
---
libavcodec/jpeg2000dec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 5e9e97eb6a..23792c15b2 100644
--- a/libavcodec/jpeg2
>
> 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
On 7/21/20, Kieran Kunhya wrote:
>>
>> 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
On 7/20/20, Michael Niedermayer wrote:
> On Thu, Jun 11, 2020 at 08:31:57PM +0200, Nicolas George wrote:
>> Paul B Mahol (12020-06-11):
>> > Signed-off-by: Paul B Mahol
>> > ---
>> > libavfilter/avfilter.c | 61 +-
>> > libavfilter/filters.h | 17
On Mon, Jul 20, 2020 at 9:04 PM James Almer wrote:
>
> On 7/20/2020 3:01 PM, James Zern wrote:
> > similar to:
> > 36e51c190b avcodec/libaomenc: use pix_fmt descriptors where useful
> >
> > Signed-off-by: James Zern
> > ---
> > libavcodec/libvpxenc.c | 13 +++--
> > 1 file changed, 3 ins
On Mon, Jul 20, 2020 at 11:04:38PM +0200, Marton Balint wrote:
> 50/60 fps timecode is using the field bit (which is the same as the phase
> correction bit) to signal the least significant bit of a 50/60 fps timecode.
> See SMPTE ST 12-1:2014 section 12.1.
>
> Let's add support for this by using t
28 matches
Mail list logo
