In ticket #8754 there is discourse surrounding the error
message which is printed upon a mismatched aspect ratio in
derived encodings. This should make it clearer to the user
as to the issues which they are experiencing.
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Fixes memleaks with some encoders that don't unref the packet before
returning.
This is consistent with the behavior of AVCodec.encode()
implementations in encode_simple_internal().
Found-by: mkver
Signed-off-by: James Almer
---
libavcodec/encode.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
Dear all，
I am new to ffmpeg and x264. I find that “extended” standard supports fmo and
data participation. But I didn’t find the information about how to set FMO mode
(such as fore-ground with left-over) and data partition mode. Could you give me
some suggestions? Thank you so much!
Best re
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年8月27日 12:17
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] dnn/tensorflow: add log error message
>
> Signed-off-by: Ting Fu
> ---
> libavfilter/dnn/dnn_backend_tf.c | 59 ++
This is based on the encoder and a small number of CFHD sample files
It should make the decoder more robust against crafted input.
Due to the lack of a proper specification it is possible that this
may be too strict and may need to be tuned as files not following this
ordering are found.
Signed-of
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 6 --
libavfilter/vf_alphamerge.c | 136 +---
2 files changed, 63 insertions(+), 79 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index b0cdf92845..6d2c234b37 100644
--- a/doc/filters.
Am So., 30. Aug. 2020 um 21:39 Uhr schrieb Paul B Mahol :
>
> On 8/30/20, Carl Eugen Hoyos wrote:
> > Am So., 30. Aug. 2020 um 19:28 Uhr schrieb Rémi Achard
> > :
> >
> >> As you are probably aware, the libopenjpeg decoder is not able
> >> to interpret cinema jp2k mxf correctly, the pixel format b
Am So., 30. Aug. 2020 um 19:28 Uhr schrieb Rémi Achard :
> As you are probably aware, the libopenjpeg decoder is not able
> to interpret cinema jp2k mxf correctly, the pixel format being
> assigned as rgb48 instead of xyz12 as it should.
Do you have a cinema xyz12 sample that does not work with
t
This is based on the encoder and a small number of CFHD sample files
It should make the decoder more robust against crafted input.
Due to the lack of a proper specification it is possible that this
may be too strict and may need to be tuned as files not following this
ordering are found.
Signed-of
On 8/30/20, Carl Eugen Hoyos wrote:
> Am So., 30. Aug. 2020 um 19:28 Uhr schrieb Rémi Achard
> :
>
>> As you are probably aware, the libopenjpeg decoder is not able
>> to interpret cinema jp2k mxf correctly, the pixel format being
>> assigned as rgb48 instead of xyz12 as it should.
>
> Do you have
Am So., 30. Aug. 2020 um 19:28 Uhr schrieb Rémi Achard :
> As you are probably aware, the libopenjpeg decoder is not able
> to interpret cinema jp2k mxf correctly, the pixel format being
> assigned as rgb48 instead of xyz12 as it should.
Do you have a sample that does not work with the native dec
On 8/25/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/src_movie.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
LGTM
> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> index 64d82e9df1..eeb8609855 100644
> --- a/libavfilter
On 8/30/20, Andreas Rheinhardt wrote:
> This avoids keeping potentially dangling pointers in the context,
> beautifies the code (by replacing "&ri->gb" by gb for every access to
> the GetByteContext) and also highlights the GetByteContext's short-lived
> nature better.
>
> Signed-off-by: Andreas R
On 8/29/20, Andreas Rheinhardt wrote:
> The comment referred to the INIT_VLC_USE_STATIC flag which has been
> removed in 2009 in 595324e143b57a52e2329eb47b84395c70f93087; the
> function it referred to was removed even earlier in commit
> 83422c1940d963d395a64bee0cbb9c637192ce8c in 2008.
>
> Signed
On 8/25/20, Andreas Rheinhardt wrote:
> The amerge filter uses a variable number of inpads and allocates them
> in its init function; if all goes well, the number of inpads coincides
> with a number stored in the filter's private context. Yet if allocating a
> subsequent inpad fails, the uninit fu
Signed-off-by: Aman Verma
---
This is a revision of the previous patch taking Jim's comments into
consideration. Thanks to him and Gyan for the help.
doc/decoders.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 9005714..8649f83
On Sun, Aug 30, 2020 at 05:07:03PM +0800, Guangxin Xu wrote:
> thanks, James and Michael.
> Are we ready to merge this?
ive applied the avctx change patch which should fix this
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know th
Hi,
As you are probably aware, the libopenjpeg decoder is not able to interpret
cinema jp2k mxf correctly, the pixel format being assigned as rgb48 instead
of xyz12 as it should. Note that ffmpeg native jp2k decoder parse the RSIZ
descriptor from the jp2k bitstream and is able to correctly assign
On 8/30/20, Andreas Rheinhardt wrote:
> av_new_packet() already sets the size. And if the packet is not
> allocated by av_new_packet() (which seems to be impossible atm), both
> pkt->size as well as size are 0, so setting it again is unnecessary in
> this scenario, too.
>
> Signed-off-by: Andreas
On 8/30/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavdevice/lavfi.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
probably ok
> diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
> index 2a95cb013c..5e814eada8 100644
> --- a/libavdevic
On 8/30/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> Stange that compilers didn't warn about this. Probably because it is an
> array.
>
probably ok
> libavcodec/roqvideodec.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/roqvideodec.c b/liba
Since bae8844e35147f92e612a9e0b44e939a293e5bc9, the AVPacket that is
intended to be used to return the demuxed packet is automatically
unreferenced when the demuxer returns an error. This makes an
av_packet_unref() in the lavfi demuxer redundant.
Signed-off-by: Andreas Rheinhardt
---
libavdevice
av_new_packet() already sets the size. And if the packet is not
allocated by av_new_packet() (which seems to be impossible atm), both
pkt->size as well as size are 0, so setting it again is unnecessary in
this scenario, too.
Signed-off-by: Andreas Rheinhardt
---
libavdevice/lavfi.c | 1 -
1 file
Signed-off-by: Andreas Rheinhardt
---
av_packet_pack_dictionary() returns NULL in case the dictionary's count
is zero; but given that the dict API does not return such dicts at all,
I have not added any check for this.
libavdevice/lavfi.c | 25 -
1 file changed, 8 inserti
Signed-off-by: Andreas Rheinhardt
---
libavdevice/lavfi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index c949ff7e12..2a95cb013c 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -392,10 +392,7 @@ static int lavfi
Signed-off-by: Andreas Rheinhardt
---
libavdevice/lavfi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 2a95cb013c..5e814eada8 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -362,16 +362,12 @@ static int
On Fri, Aug 28, 2020 at 01:00:41PM -0700, Xiaohan Wang (王消寒) wrote:
> Resend with @chromium.org account. Sorry for the noise.
i think clearing the array is a good idea independant of the bug.
It makes bugs like this more repeatable and easier to debug for
example and this should have 0 speed effec
On Sat, Aug 29, 2020 at 10:53:21PM +0200, Paul B Mahol wrote:
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: PGP signature
On Fri, Aug 28, 2020 at 12:15:33AM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch makes the tag_tree_zero() and tag_tree_size()
> functions non static and callable from other files.
> ---
> libavcodec/jpeg2000.c | 12 ++--
> libavcodec/jpeg2000.h | 3 +++
>
On Sat, Aug 29, 2020 at 05:36:45PM +0100, Kieran Kunhya wrote:
> On Sat, 29 Aug 2020 at 13:27, Marvin Scholz wrote:
>
> > ---
> > libavformat/adtsenc.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
>
> Ok
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147E
On Sun, Aug 30, 2020 at 11:50:25AM +0200, Paul B Mahol wrote:
> On 8/25/20, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mpegvideo_enc.c | 56 +++---
> > 1 file changed, 28 insertions(+), 28 deletions(-)
> >
>
> Give so
This avoids keeping potentially dangling pointers in the context,
beautifies the code (by replacing "&ri->gb" by gb for every access to
the GetByteContext) and also highlights the GetByteContext's short-lived
nature better.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/roqvideo.h| 1 -
l
Signed-off-by: Andreas Rheinhardt
---
Stange that compilers didn't warn about this. Probably because it is an
array.
libavcodec/roqvideodec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/roqvideodec.c b/libavcodec/roqvideodec.c
index 93c6e9ddf3..36b4ddf755 100644
--- a/libavc
On 8/23/20, Nicolas George wrote:
> Michael Niedermayer (12020-08-23):
>> > +if (buf->pts == AV_NOPTS_VALUE) {
>> > +av_log(ctx, AV_LOG_ERROR, "Frame without timestamp on input
>> > %d\n", in_no);
>> > +return AVERROR(EINVAL);
>> > +}
>>
>> what if the timestamp is "AV_NOPT
On 8/23/20, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> doc/ffmpeg.texi | 10 ++
> fftools/ffmpeg.h| 1 +
> fftools/ffmpeg_filter.c | 2 ++
> fftools/ffmpeg_opt.c| 3 +++
> 4 files changed, 16 insertions(+)
>
LGTM
On 8/25/20, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mpegvideo_enc.c | 56 +++---
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
Give some explantation in commit log what this is required.
Otherwise LGTM.
> diff -
thanks, James and Michael.
Are we ready to merge this?
thanks
On Wed, Aug 26, 2020 at 5:51 AM Michael Niedermayer
wrote:
> On Tue, Aug 25, 2020 at 11:37:59AM -0300, James Almer wrote:
> > On 8/25/2020 6:35 AM, Xu Guangxin wrote:
> > > Steps to reproduce:
> > > 1. ./configure --enable-debug=3 --d
On 8/30/20, Andreas Rheinhardt wrote:
[...]
>> +static int read_hufftable(AVCodecContext *avctx, VLC *vlc)
>> +{
>> +PhotoCDContext *s = avctx->priv_data;
>> +GetByteContext *gb = &s->gb;
>> +int start = s->streampos;
>> +int count, ret;
>> +
>> +bytestream2_seek(gb, start, SEE
38 matches
Mail list logo
