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
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 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 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
>
> 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
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
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 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
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
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
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
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
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 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
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
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 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
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 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
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/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 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 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 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 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.
>
>
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/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
>-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
28 matches
Mail list logo
