myp...@gmail.com:
> On Tue, Aug 20, 2019 at 6:11 AM Andreas Rheinhardt
> wrote:
>>
>> Up until now, avformat_find_stream_info had a potential for memleaks:
>> When everything is fine, it read packets and (depending upon whether
>> AVFMT_FLAG_NOBUFFER was set) put them in a packet list or
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jean-Baptiste Kempf
> Sent: Monday, August 19, 2019 2:18 PM
> To: ffmpeg-devel
> Subject: Re: [FFmpeg-devel] [CALL] New FFmpeg developers meeting
>
> On Sat, Aug 17, 2019, at 11:48, Paul B Mahol wrote:
> > When and how
On Tue, Aug 20, 2019 at 6:11 AM Andreas Rheinhardt
wrote:
>
> Up until now, avformat_find_stream_info had a potential for memleaks:
> When everything is fine, it read packets and (depending upon whether
> AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
> them when they were
On Tue, 20. Aug 01:01, Michael Niedermayer wrote:
> On Sun, Aug 18, 2019 at 10:37:57PM -0400, Andriy Gelman wrote:
> [...]
> > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> > index 559c3898bc..46f130f4d1 100644
> > --- a/tests/fate/hevc.mak
> > +++ b/tests/fate/hevc.mak
> > @@ -238,7
On Mon, Aug 19, 2019 at 6:55 PM James Almer wrote:
> On 8/19/2019 10:39 PM, Jun Li wrote:
> > On Mon, Aug 19, 2019 at 3:45 PM James Almer wrote:
> >
> >> On 8/18/2019 10:41 PM, Jun Li wrote:
> >>> Fix #6591
> >>> The content has no rbsp_stop_one_bit for ending the SPS, that
> >>> causes the
Fix #6591
The content has no rbsp_stop_one_bit for ending the SPS, that
causes the decoding SPS failure, results decoding frame failure as well.
The patch is just adding a retry with complete NALU, copied from the retry in
decode_nal_unit()
---
libavcodec/h264_parse.c | 11 +--
1 file
Am Di., 20. Aug. 2019 um 03:37 Uhr schrieb Nikolas Bowe
:
>
> Fixes "Invalid data found when processing input" on some JPEGs.
>
> Some large extensionless JPEGs can get probe score collisions.
> eg
> $ ffprobe -loglevel trace /tmp/foo
> [NULL @ 0x55c130ab04c0] Opening '/tmp/foo' for reading
>
On Tue, Aug 20, 2019 at 9:31 AM Guo, Yejun wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Jun Zhao
> > Sent: Monday, August 19, 2019 9:01 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao
> > Subject: [FFmpeg-devel]
On Tue, Aug 20, 2019 at 9:14 AM Guo, Yejun wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Jun Zhao
> > Sent: Monday, August 19, 2019 9:01 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao
> > Subject: [FFmpeg-devel]
On Mon, Aug 19, 2019 at 9:14 PM Paul B Mahol wrote:
>
> LGTM
>
Will apply, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Mon, Aug 19, 2019 at 9:09 PM Paul B Mahol wrote:
>
> LGTM
>
Will apply, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 8/19/2019 10:39 PM, Jun Li wrote:
> On Mon, Aug 19, 2019 at 3:45 PM James Almer wrote:
>
>> On 8/18/2019 10:41 PM, Jun Li wrote:
>>> Fix #6591
>>> The content has no rbsp_stop_one_bit for ending the SPS, that
>>> causes the decoding SPS failure, results decoding frame failure as well.
>>> The
On Mon, Aug 19, 2019 at 3:45 PM James Almer wrote:
> On 8/18/2019 10:41 PM, Jun Li wrote:
> > Fix #6591
> > The content has no rbsp_stop_one_bit for ending the SPS, that
> > causes the decoding SPS failure, results decoding frame failure as well.
> > The patch is just adding a retry with
> 在 2019年8月19日，上午11:14，Liu Steven 写道：
>
>
>
>> 在 2019年8月19日，上午9:42，lance.lmw...@gmail.com 写道：
>>
>> From: Limin Wang
>>
>> Signed-off-by: Limin Wang
>> ---
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/hlsenc.c
> 在 2019年8月19日，下午9:01，Jun Zhao 写道：
>
> From: Jun Zhao
>
> free the old_filname to avoid memory leak in error handle
> path.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/hlsenc.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/hlsenc.c
Fixes "Invalid data found when processing input" on some JPEGs.
Some large extensionless JPEGs can get probe score collisions.
eg
$ ffprobe -loglevel trace /tmp/foo
[NULL @ 0x55c130ab04c0] Opening '/tmp/foo' for reading
[file @ 0x55c130ab0f40] Setting default whitelist 'file,crypto'
Probing
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Monday, August 19, 2019 9:01 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao
> Subject: [FFmpeg-devel] [PATCH V1 3/5] lavfi/dnn/dnn_backend_native: Refine
> the coding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Monday, August 19, 2019 9:01 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao
> Subject: [FFmpeg-devel] [PATCH V1 4/5] lavfi/dnn/dnn_backend_native: fix
> memory leak in
Extracts quantization parameters data from AVEncodeInfoFrame side data,
if available, then calculates min/max/avg and outputs the results in a log file.
Signed-off-by: Juan De León
---
doc/filters.texi | 40 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1
Juan De León (12019-08-19):
> > > +size_t size = sizeof(AVEncodeInfoFrame) +
> > sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
> >
> > (Commenting from my phone because urgent.)
> > This line do not make sense to me. Can you explain the reason for the
> > cast and how you avoid
Proposed changes to use AVEncodeInfoFrame and AVencodeInfoBlock
data types as AVFrameSideData, including the changes tothe h264
decoder as well as a filter to output the data extracted.
Filter can be called using:
ffmpeg -debug extractqp -i -lavfi extractqp=extractqp.log -f null -
More options
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
Added extractqp flag as an argument to the -debug flag to enable qp extraction
for the h264 decoder using AVEncodeInfo as AVFrameSideData.
Signed-off-by: Juan De León
---
libavcodec/avcodec.h | 1 +
libavcodec/h264dec.c | 40 ++
On Sun, Aug 18, 2019 at 10:37:57PM -0400, Andriy Gelman wrote:
[...]
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index 559c3898bc..46f130f4d1 100644
> --- a/tests/fate/hevc.mak
> +++ b/tests/fate/hevc.mak
> @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER
>
On 8/18/2019 10:41 PM, Jun Li wrote:
> Fix #6591
> The content has no rbsp_stop_one_bit for ending the SPS, that
> causes the decoding SPS failure, results decoding frame failure as well.
> The patch is just adding a retry with complete NALU.
> ---
> libavcodec/h264_parse.c | 10 --
> 1
Andreas Rheinhardt:
> 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 packet happens to have an illegal stream index
1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2.
The documentation of ff_packet_list_get currently didn't match the
actual usage:
1. It said that the destination packet is supposed to be initialized.
But this makes no sense given that it will be overwritten completely and
flacenc, mp3enc and ttaenc ignored this.
2. ff_packet_list_get returns an
Up until now, avformat_find_stream_info had a potential for memleaks:
When everything is fine, it read packets and (depending upon whether
AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
them when they were no longer needed. But upon failure, said packets
would leak if they
Up until now, read_frame_internal always initialized the packet it
received. But since the recent changes to ff_read_packet, this is no
longer needed: If the parsing queue is initially empty upon entering
read_frame_internal, the packet will now either contain content upon
success or be blank upon
Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of
When AVFMT_FLAG_GENPTS is set, av_read_frame would put a reference to a
packet in the packet list (via av_packet_ref) and then immediately
thereafter unreference the original packet. This has been changed to
move the reference instead. Given that the packet originated from
read_frame_internal, it
Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been
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 packet happens to have an illegal stream index (i.e. one that
does not
Hi!
Attached patch fixes tickets #4799 and #8081, thanks to Paul for his help.
Please comment, Carl Eugen
From 8af0b279ad0c25425d075498f60b0770528687a2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 19 Aug 2019 23:34:37 +0200
Subject: [PATCH] lavc/g729dec: Support decoding Sipro
On 8/13/2019 10:14 PM, Eugene Lyapustin wrote:
> Signed-off-by: Eugene Lyapustin
> ---
> doc/filters.texi | 137 +++
> libavfilter/Makefile |1 +
> libavfilter/allfilters.c |1 +
> libavfilter/vf_v360.c| 1847 ++
> 4 files changed,
Minor changes in v3:
1. Removed tab character from as per feedback
2. Removed unused timeout variable from ZMQContext
Andriy
>From 66c11c12fcfa8a7fbb3c8c09d23c017992229a99 Mon Sep 17 00:00:00 2001
From: Andriy Gelman
Date: Tue, 30 Jul 2019 14:39:32 -0400
Subject: [PATCH] libavformat: Add
On Mon, Aug 19, 2019 at 05:09:37PM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
> > On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> >> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> >>> There seems to be no limit in the specification and
Hi Marton,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Friday, 16 de August de 2019 10:27, Andreas Håkon
wrote:
> Hi Marton,
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, 14 de August de 2019 23:31, Marton Balint c...@passwd.hu wrote:
>
> > I pushed this
Hi,
This is the third version of my patch for an "interleaved MPEG-TS muxer".
This new version includes all recommendations and rebases the fix of the
incorrect PCR with multiple programs (fixed in collaboration with Marton
Balint).
Supersedes: https://patchwork.ffmpeg.org/patch/13745/
How to
On Sat, Aug 17, 2019 at 7:00 AM Nicolas George wrote:
> > +#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
> > +
> > +static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int
> nb_blocks) {
> > +info->nb_blocks = nb_blocks;
> > +info->block_size = sizeof(AVEncodeInfoBlock);
> >
Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin :
> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
> > > :
> > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > > Hi Tomas,
> > > >
> >
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/hlsenc.c | 50 ++-
libavformat/hlsplaylist.c | 4 ++--
libavformat/hlsplaylist.h | 4 ++--
3 files changed, 19 insertions(+), 39 deletions(-)
diff --git a/libavformat/hlsenc.c
This patch extends aphasemeter to detect out of phase or mono sequences in
stereo streams, with its associated documentation.
From dce30e5a978ff5296fa1c0013bbd78fd27ecec2a Mon Sep 17 00:00:00 2001
From: Romane Lafon
Date: Fri, 16 Aug 2019 14:14:11 +0200
Subject: [PATCH] avfilter/avf_aphasemeter:
Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
> On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
>> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
>>> There seems to be no limit in the specification and upto 64k could be stored
>>> 64 is chooses as limit as thats also used
Em sex, 16 de ago de 2019 às 11:20, Li, Zhong escreveu:
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Guo, Yejun
> > Sent: Wednesday, August 7, 2019 10:44 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Guo, Yejun
> > Subject: [FFmpeg-devel] [PATCH V2] FATE/dnn:
Em qui, 15 de ago de 2019 às 23:40, Guo, Yejun escreveu:
>
> if it is initialized randomly, the tensorflow lib will report
> error message such as:
> Attempt to add output -7920 of depth_to_space4 not in range [0, 1) to node
> with type Identity
>
> Signed-off-by: Guo, Yejun
> ---
>
Em qui, 15 de ago de 2019 às 23:41, Guo, Yejun escreveu:
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn/dnn_backend_tf.c | 48
>
> 1 file changed, 19 insertions(+), 29 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_tf.c
>
Hi Marton,
I want to confirm that we get correctly synced TCs when leaving out the
format_code parameter and using an ffmpeg build from head (not with Gyan's
patch). However, I was under the impression that we need the format_code so
that we can capture different content types, in the original
LGTM
On Mon, Aug 19, 2019 at 3:08 PM Jun Zhao wrote:
> From: Jun Zhao
>
> ff_filter_frame fail will free the frame, so we just returen after this
> function fail.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/af_adeclick.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
From: Jun Zhao
We perfer the coding style like:
/* some stuff */
if (error) {
/* error handling */
return -(errorcode);
}
/* normal actions */
do_something()
Signed-off-by: Jun Zhao
---
libavfilter/dnn/dnn_backend_native.c | 24
LGTM
On Mon, Aug 19, 2019 at 3:08 PM Jun Zhao wrote:
> From: Jun Zhao
>
> ff_merge_samplerates will be deallocate a or b in some case, so
> add a check before free the format.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/avfiltergraph.c |6 --
> 1 files changed, 4 insertions(+), 2
From: Jun Zhao
fix memory leak in error path
Signed-off-by: Jun Zhao
---
libavfilter/dnn/dnn_backend_native.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index 7b489d0..2619463 100644
From: Jun Zhao
ff_filter_frame fail will free the frame, so we just returen after this
function fail.
Signed-off-by: Jun Zhao
---
libavfilter/af_adeclick.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavfilter/af_adeclick.c b/libavfilter/af_adeclick.c
index
From: Jun Zhao
ff_merge_samplerates will be deallocate a or b in some case, so
add a check before free the format.
Signed-off-by: Jun Zhao
---
libavfilter/avfiltergraph.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavfilter/avfiltergraph.c
From: Jun Zhao
free the old_filname to avoid memory leak in error handle
path.
Signed-off-by: Jun Zhao
---
libavformat/hlsenc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f6f9c81..9099c84 100644
---
On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> > There seems to be no limit in the specification and upto 64k could be stored
> > 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> > can handle
> >
>
On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> > There seems to be no limit in the specification and upto 64k could be stored
> > 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> > can handle
> >
>
mån 2019-08-19 klockan 11:19 +0200 skrev Jean-Baptiste Kempf:
>
> On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote:
> > mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> > > You need to explain why. A "NAK" is not enough.
> > >
> > > 16k pixels x 16k is a large size already for
On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote:
> mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> > You need to explain why. A "NAK" is not enough.
> >
> > 16k pixels x 16k is a large size already for vc1.
>
> Why not fix the calculation? 16K is a thing, and larger
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Thursday, August 15, 2019 3:43 PM
> To: FFmpeg development discussions and patches
>
> Cc: Rogozhkin, Dmitry V
> Subject: Re: [FFmpeg-devel] [PATCH 3/6] lavc/qsvdec: Replace current parser
> with
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 14, 2019 5:38 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter
>
> On Wed, Aug 14, 2019 at 9:01 AM Li,
mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> You need to explain why. A "NAK" is not enough.
>
> 16k pixels x 16k is a large size already for vc1.
Why not fix the calculation? 16K is a thing, and larger resolutions are
inevitable..
/Tomas
sön 2019-08-18 klockan 19:04 +0200 skrev Michael Niedermayer:
> On Sun, Aug 18, 2019 at 02:49:39PM +0200, Tomas Härdin wrote:
> > sön 2019-08-18 klockan 14:18 +0200 skrev Michael Niedermayer:
> > > On Sun, Aug 18, 2019 at 01:40:01PM +0200, Tomas Härdin wrote:
> > > > sön 2019-08-18 klockan 12:19
> 在 2019年8月19日，下午2:18，Jean-Baptiste Kempf 写道：
>
> On Sat, Aug 17, 2019, at 11:48, Paul B Mahol wrote:
>> When and how to organize this?
>
> You have the choice:
> - IBC
> - GSoC summit
> - VDD
And welcome to LiveVideoStack at China.
Jun Zhao, Zhong Li and some developers are here :D
>
>
On Mon, Aug 19, 2019 at 9:46 AM Jean-Baptiste Kempf wrote:
>
>
> On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote:
> > On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf
> wrote:
> >
> > > You need to explain why. A "NAK" is not enough.
> > >
> > > 16k pixels x 16k is a large size already
On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote:
> On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf wrote:
>
> > You need to explain why. A "NAK" is not enough.
> >
> > 16k pixels x 16k is a large size already for vc1.
> >
>
> And for any other codecs
Sure.
In VLC we limit to 8k x
On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf wrote:
> You need to explain why. A "NAK" is not enough.
>
> 16k pixels x 16k is a large size already for vc1.
>
And for any other codecs
>
> On Sun, Aug 18, 2019, at 12:45, Paul B Mahol wrote:
> > NAK
> >
> > On Thu, Aug 15, 2019 at
On Sat, Aug 17, 2019, at 11:48, Paul B Mahol wrote:
> When and how to organize this?
You have the choice:
- IBC
- GSoC summit
- VDD
Best,
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
You need to explain why. A "NAK" is not enough.
16k pixels x 16k is a large size already for vc1.
On Sun, Aug 18, 2019, at 12:45, Paul B Mahol wrote:
> NAK
>
> On Thu, Aug 15, 2019 at 11:51 PM Michael Niedermayer
> wrote:
>
> > Fixes: overflow in aspect ratio calculation
> > Fixes: signed
70 matches
Mail list logo
