On 9/20/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v210_template.c | 20
> libavcodec/v210enc.c | 8 +---
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/v210_template.c b/
Rodger Combs:
> This allows reading packets linearly, which prevents large numbers of
> unnecessary seeks in poorly-interleaved files with consumer software that
> handles those cases well on its own.
> ---
Did you test whether this fixes tickets #7592 and #7891?
- Andreas
__
> On Sep 22, 2019, at 03:19, Andreas Rheinhardt
> wrote:
>
> Rodger Combs:
>> This allows reading packets linearly, which prevents large numbers of
>> unnecessary seeks in poorly-interleaved files with consumer software that
>> handles those cases well on its own.
>> ---
>
> Did you test whet
James Almer:
> Demuxers may have allocated a packet before encountering an error and
> aborting.
>
> Fixes ticket #8150
>
> Signed-off-by: James Almer
> ---
> It may also fix other tickets as well, since i recall seeing other reports
> about
> leaks in ff_read_packet() on malformed input in th
Michael Niedermayer:
> This avoids some invalid shifts
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/truespeech.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/truespeech.c b/libavcodec/truespeech.c
> index d4ddfcbf9c..54352851b3 100644
>
On Sat, Sep 21, 2019 at 10:12:10AM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> need to free the header in error path
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/4xm.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> inde
Fixes CID 1453867, CID 1453866, CID 1453865.
Signed-off-by: Moritz Barsnick
---
libavformat/hashenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 8e090731ae..34a8fd1f50 100644
--- a/libavformat/hashenc.c
+++ b/liba
On Sat, Sep 21, 2019 at 10:07:25 +0530, Gyan wrote:
[...]
> Coverity reports three issues arising from this patchset, actually one
> issue, having an instance in each of the three init () functions.
[...]
> c->hashes = av_mallocz_array(1, sizeof(c->hashes));
[...]
> "Passing argument "8UL /* s
On Sun, Sep 22, 2019 at 10:05:10AM +0200, Paul B Mahol wrote:
> On 9/20/19, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/v210_template.c | 20
> > libavcodec/v210enc.c | 8 +---
> > 2 files changed, 2
On Sat, Sep 21, 2019 at 11:04:27PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> > On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > > > From: Lim
On Fri, Sep 20, 2019 at 10:39:08PM +0200, Andreas Rheinhardt wrote:
> ff_read_packet had several potential memleaks:
> 1. If av_packet_make_refcounted fails, it means that the packet is not
> refcounted, but it could nevertheless carry side data and therefore
> needs to be unreferenced.
> 2. If a p
Is this gonna be applied at all?
On 12/3/18, Mina wrote:
> Hi,
>
>This patch was part of GSoC Color Constancy filter. It introduces an
> improved color constancy filter(weighted_greyedge) based on the already
> pushed greyedge. I'm sending it again after updating it against latest
> version o
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079..f144406 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -365,7 +365,7 @@ fa
On 9/22/2019 11:06 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/dnxhdenc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> index 41b8079..f144406 100644
> --- a
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 47 ++-
libavcodec/dnxhdenc.h | 2 --
2 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079..6be3c43 100644
On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/dnxhdenc.c | 47 ++-
> libavcodec/dnxhdenc.h | 2 --
> 2 files changed, 10 insertions(+), 39 deletions(-)
Err, what? I think you
On Sun, Sep 22, 2019 at 11:15:51AM -0300, James Almer wrote:
> On 9/22/2019 11:06 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/dnxhdenc.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavc
On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote:
> On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/dnxhdenc.c | 47 ++-
> > libavcodec/dnxhdenc.h | 2 --
>
On 9/22/2019 1:01 PM, Limin Wang wrote:
> On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote:
>> On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote:
>>> From: Limin Wang
>>>
>>> Signed-off-by: Limin Wang
>>> ---
>>> libavcodec/dnxhdenc.c | 47 ++-
On Sat, Sep 21, 2019 at 05:11:57PM +0200, Paul B Mahol wrote:
> lgtm
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
signature.asc
Description: P
On Sat, Sep 21, 2019 at 07:00:41PM +0200, Paul B Mahol wrote:
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liber
On Sat, Sep 21, 2019 at 06:57:26PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/sunrast.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictat
>
> This means that several of your big-name experts should consider the
> global design,
> improve the current system framework, and solve the actual needs, rather
> than simply
> rejecting the performance improvement of different modules. I believe that
> the kernel
> zero copy technology is also
On Sat, Sep 21, 2019 at 10:49:21PM -0400, Devin Heitmueller wrote:
>
> > On Sep 21, 2019, at 4:44 PM, Michael Niedermayer
> > wrote:
> >
> >> The patch just expands 4:2:0 to 4:2:2 while properly supporting interlaced
> >> chroma.
> >
> > 4:2:0 and 4:2:2 have a chroma plane with different re
On 22/09/2019 17:18, Kieran Kunhya wrote:
> And just like in the kernel, zero copy technology is maintained outside.
> Good design is separation of different functionality, otherwise the
> combinations of codepaths is exponentiated.
Agreed with everyone else here, this code doesn't belong in an en
On Sat, 21 Sep 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/filters.texi | 2 ++
libavfilter/vf_framerate.c | 17 +++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bb
WwawwewzA XX,$_2*#$5$2
On Sat, Sep 21, 2019, 7:28 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/adtsenc.c | 2 +-
> libavformat/isom.c| 4 ++--
> libavformat/latmenc.c | 2 +-
> libavformat/matroskaenc.c | 3 +--
> 4 files changed, 5 inserti
Hi,
I have been very busy last year but recently things are settling down
and I would be glad to resume contributing.
FYI, a contest was held earlier this year that resulted in some great
papers/variations, so I can either resend an updated patch or refactor
the filter to accommodate for tho
On Sun, Sep 22, 2019 at 01:04:01PM -0300, James Almer wrote:
> On 9/22/2019 1:01 PM, Limin Wang wrote:
> > On Sun, Sep 22, 2019 at 12:45:48PM -0300, James Almer wrote:
> >> On 9/22/2019 12:43 PM, lance.lmw...@gmail.com wrote:
> >>> From: Limin Wang
> >>>
> >>> Signed-off-by: Limin Wang
> >>> ---
On Sun, Sep 22, 2019 at 07:15:53PM +0100, Derek Buitenhuis wrote:
> On 22/09/2019 17:18, Kieran Kunhya wrote:
> > And just like in the kernel, zero copy technology is maintained outside.
> > Good design is separation of different functionality, otherwise the
> > combinations of codepaths is exponen
On Sun, Sep 22, 2019 at 08:54:36PM +0200, Marton Balint wrote:
>
>
> On Sat, 21 Sep 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Signed-off-by: Limin Wang
> >---
> >doc/filters.texi | 2 ++
> >libavfilter/vf_framerate.c | 17 +++--
> >2 files changed, 1
Signed-off-by: Guo, Yejun
---
libavcodec/libx264.c | 16 ++--
libavcodec/libx265.c | 11 ++-
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 86e3530..8788286 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/li
> From: Li, Zhong
> Sent: Friday, September 20, 2019 4:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [PATCH 2/3] lavc/qsv: Fix MSDK initialization failure in system
> memory
> mode
>
> MSDK does not create internal acceleration device on Linux, So
> MFXVideoCORE_SetHandle() is
This can happen when av_bsf_free() is called on av_bsf_alloc() failure.
Signed-off-by: James Almer
---
libavcodec/bsf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 71915dea85..c1653cddb0 100644
--- a/libavcodec/bsf.c
+++ b/libav
> 在 2019年9月20日，下午8:20，vectronic 写道：
>
>
>
>> On 16 Sep 2019, at 11:55, Liu Steven wrote:
>>
>>
>>
>>> 在 2019年9月16日，下午6:44，vectronic 写道：
>>>
>>> prevent attempt to call xmlFree if val was not allocated
>>>
>>> fixes: 8135
>>> Signed-off-by: vectronic
>>> ---
>>> libavformat/dashdec.c |
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/dnxhdenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 41b8079a09..c82c5d5140 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -542,6 +542,8 @@ FF_ENABLE_DEPR
Hi,
Recently, I met a case of wrong audio duration when ffprobe a mp4 file use
FFmpeg 4.0, but right in FFmpeg 4.1.3.
In moov, the audio duration was right, the format duration (in mvhd) was
wrong. But the probe output showed that the audio duration was set to the wrong
format duratio
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: Wednesday, September 18, 2019 03:06 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V2 2/3] avfilter/x86/vf_eq: Change inline
> assembly into nasm code
Ping?
>
> Signed-off-by: Ting Fu
> ---
> liba
On Sun, Sep 22, 2019 at 7:45 PM Michael Niedermayer
wrote:
>
> On Sat, Sep 21, 2019 at 10:12:10AM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > need to free the header in error path
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/4xm.c |1 +
> > 1 files changed, 1 insertions(+),
39 matches
Mail list logo
