On 2021-04-06 16:03, V Subhash [FFMPEG Quick Hacks] wrote:
> I'm talking about starting a page on the wiki and listing all books
*there*. No patch required.
I will add the books to wiki but while the two old books are there at
https://ffmpeg.org/documentation.html, I would like you to add
It is not a problem for pointers to VLA used to compute sizes and
offsets in an isolated function, so we can remove this flag.
We still need to keep in mind not to use actual VLAs on the stack.
Signed-off-by: Nicolas George
Signed-off-by: Guo, Yejun
---
configure | 1 -
1 file changed, 1 delet
On Tue, Apr 6, 2021 at 6:45 PM Nicolas George wrote:
>
> Guo, Yejun (12021-04-06):
> > compile error on ubuntu 18.04 with default setting:
> > error: ISO C90 forbids variable length array ‘boxes’ [-Werror=vla]
> > AVBoundingBox boxes[nb_bboxes];
>
> This warning is explicitly added by config
On Wed, Apr 7, 2021 at 10:44 AM Guo, Yejun wrote:
>
> It is not a problem for pointers to VLA used to compute sizes and
> offsets in an isolated function, so we can remove this flag.
>
> We still need to keep in mind not to use actual VLAs on the stack.
>
As noted in the other thread, VLAs are no
Hendrik Leppkes (12021-04-07):
> Unfortunately, this is not correct. I don't know about optimization
> problems, but I do know that compilers we do support, which are C11
> compliant (where VLAs are optional), do not implement them (just
> confirmed this with a test, as well, to make sure).
Too ba
Nicolas George:
> Hendrik Leppkes (12021-04-07):
>> Unfortunately, this is not correct. I don't know about optimization
>> problems, but I do know that compilers we do support, which are C11
>> compliant (where VLAs are optional), do not implement them (just
>> confirmed this with a test, as well,
Andreas Rheinhardt (12021-04-07):
> Why a backup implementation?
Because:
> And a generic alignment of (say) 8 can be used as a fallback.
I believe using a pointer to VLA is more elegant than reimplementing the
compiler's feature using _Alignof and clumsy arithmetic, but it is
eventually for who
For both the RealMedia as well as the IVR demuxer (which share the same
context) each AVStream's priv_data contains an AVPacket that might
contain data (even when reading the header) and therefore needs to be
unreferenced. Up until now, this has not always been done:
The RealMedia demuxer didn't d
Signed-off-by: Andreas Rheinhardt
---
libavformat/rmdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 1dec70e95b..fc3bff4859 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -1312,7 +1312,7 @@ static int ivr_read
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: 2021年4月7日 18:06
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V6 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Andreas Rheinhardt (12021-04-07):
> > Why
---
libavfilter/dnn/dnn_backend_openvino.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index 9a47d74c15..66845fbd51 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_op
---
libavfilter/dnn/dnn_backend_native.c | 8
libavfilter/dnn/dnn_backend_openvino.c | 8
libavfilter/dnn/dnn_backend_tf.c | 8
libavfilter/dnn_filter_common.c| 7 +++
libavfilter/dnn_filter_common.h| 1 +
libavfilter/dnn_interface.h
---
libavfilter/dnn/dnn_backend_openvino.c | 30 --
libavfilter/dnn_filter_common.c| 6 ++
libavfilter/dnn_filter_common.h| 1 +
libavfilter/dnn_interface.h| 3 +++
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/libavfilte
Signed-off-by: Guo, Yejun
---
doc/APIchanges | 2 +
libavutil/Makefile | 2 +
libavutil/boundingbox.c | 73 +
libavutil/boundingbox.h | 114
libavutil/frame.c | 1 +
libavutil/frame.h | 7 +++
6 fi
Signed-off-by: Guo, Yejun
---
libavfilter/f_sidedata.c | 2 ++
libavfilter/vf_showinfo.c | 30 ++
2 files changed, 32 insertions(+)
diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
index 3757723375..912fb0d881 100644
--- a/libavfilter/f_sidedata.c
++
Below are the example steps to do object detection:
1. download and install l_openvino_toolkit_p_2021.1.110.tgz from
https://software.intel.com/content/www/us/en/develop/tools/openvino-toolkit/download.html
or, we can get source code (tag 2021.1), build and install.
2. export LD_LIBRARY_PATH wit
Guo, Yejun:
> Signed-off-by: Guo, Yejun
> ---
> doc/APIchanges | 2 +
> libavutil/Makefile | 2 +
> libavutil/boundingbox.c | 73 +
> libavutil/boundingbox.h | 114
> libavutil/frame.c | 1 +
> libavutil/f
Andreas Rheinhardt (12021-04-07):
> > +ret->header.bboxes_offset = (char *)&ret->boxes - (char *)&ret->header;
>
> Using offsetof would be clearer (for this you have to declare a proper
> type).
I find this version rather clearer. offsetof is good we we do not have a
pointer to do the actual
On Wed, Apr 07, 2021 at 12:42:50AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: out of array read
> > Fixes:
> > 32968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSP2_fuzzer-5315296027082752
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/o
On 07/04/2021 10:02, Hendrik Leppkes wrote:
> As noted in the other thread, VLAs are not supported by all compilers
> we support, so they cannot be used.
We should not be using them as a matter of good practice, as well, IMO.
- Derek
___
ffmpeg-devel ma
Derek Buitenhuis (12021-04-07):
> We should not be using them as a matter of good practice, as well, IMO.
Please follow the discussion. Good practice decourages VLA on the stack,
not pointers to VLA.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
On 07/04/2021 16:29, Derek Buitenhuis wrote:
> I must have missed the discussion as it may be hidden in another thread.
>
> A reference would be good for those of us who have not read every single email
> that has ever come into this mailing list.
>
> My 2 cents anyway is that VLA use on the stac
Derek Buitenhuis (12021-04-07):
> Sorry, misread - but I struggle to understand where pointers to VLA are
> considered
> not bad practice either.
To answer that, I need to know why you think VLAs are considered bad
practice.
VLAs on the stack are a bad practice because (1) they may use too much
On 07/04/2021 16:14, Nicolas George wrote:
> Please follow the discussion. Good practice decourages VLA on the stack,
> not pointers to VLA.
I must have missed the discussion as it may be hidden in another thread.
A reference would be good for those of us who have not read every single email
that
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年4月7日 22:44
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Guo, Yejun:
> > Signed-off-by: Guo, Yejun
> > ---
> > d
On Wed, 7 Apr 2021, at 10:32, Guo, Yejun wrote:
> It is not a problem for pointers to VLA used to compute sizes and
> offsets in an isolated function, so we can remove this flag.
I don't think this is a good idea.
> We still need to keep in mind not to use actual VLAs on the stack.
If it is not
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年4月7日 22:44
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
>> AV_FRAME_DATA_BOUNDING_BOXES
>>
>> Guo, Yejun:
>>> Signed-off-by: Gu
Jean-Baptiste Kempf (12021-04-07):
> I don't think this is a good idea.
Can you explain the problems about VLA that I do not know about?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel
On 07/04/2021 16:34, Nicolas George wrote:
> To answer that, I need to know why you think VLAs are considered bad
> practice.
>
> VLAs on the stack are a bad practice because (1) they may use too much
> of the stack in an unexpected way, and (2) they require extra registers
> that ruin optimizatio
Please ask someone else to apply it.
On Tue, Apr 6, 2021 at 9:14 AM Tobias Rapp wrote:
> On 26.03.2021 13:58, Tobias Rapp wrote:
> > Avoids empty "Channel" or "Overall" header lines added to log output
> > when measurement is restricted to one scope using
> > "measure_perchannel=none" or "measur
Apparently for various image sequences libavformat/utils.c can
calculate rather fancy r_frame_rate values, such as `186/1921`,
and since ffmpeg.c utilizes r_frame_rate for the filter chain
time base, this can quite deteriorate the output frame timing - even
though the user has requested the image s
On Sat, Apr 03, 2021 at 09:48:18AM +0200, Anton Khirnov wrote:
> Quoting James Almer (2021-04-02 16:54:47)
> > On 4/2/2021 11:40 AM, Anton Khirnov wrote:
> > > Saves an allocation+free and two frame copies per each frame.
> > > ---
> > > libavcodec/pngdec.c | 51 +-
On Wed, Apr 7, 2021 at 12:48 AM Carl Eugen Hoyos wrote:
> Am Di., 6. Apr. 2021 um 21:51 Uhr schrieb Vittorio Giovara
> :
> >
> > without my patch the sample is shown at a 16:9
> > AR (which I assume was the original fix), with my patch the sample uses
> an
> > AR of 1:1 and it is therefore square
Quoting Michael Niedermayer (2021-04-07 21:21:39)
> On Sat, Apr 03, 2021 at 09:48:18AM +0200, Anton Khirnov wrote:
> > Quoting James Almer (2021-04-02 16:54:47)
> > > On 4/2/2021 11:40 AM, Anton Khirnov wrote:
> > > > Saves an allocation+free and two frame copies per each frame.
> > > > ---
> > > >
On Mon, Apr 05, 2021 at 03:44:33AM +0200, Andreas Rheinhardt wrote:
> The RealVideo 3.0 and 4.0 decoders call ff_mpv_common_init() only during
> their init function and not during decode_frame(); when the size of the
> frame changes, they call ff_mpv_common_frame_size_change(). Yet upon
> error, sa
On Mon, Apr 05, 2021 at 03:28:52AM +0200, Andreas Rheinhardt wrote:
> From: Andreas Rheinhardt
>
> This mostly reverts commit 4b2863ff01b1fe93d9a518523c9098d17a9d8c6f.
> Said commit removed the freeing code from ff_mpv_common_init(),
> ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc
On 07/04/2021 19:56, Vittorio Giovara wrote:
> My OS doesn't even let me install Quicktime 7, if anybody could chime in
> and help solve this point it would be much appreciated.
> Alternatively, I'd say we shouldn't cargo cult broken files generated by 11
> year old software, but if people disagree
On Tue, 6 Apr 2021, Marton Balint wrote:
Ugly, but a lot less broken than it was.
Fixes ticket #9166.
Ok, it seems there were no interest, so I just applied the series, so
maybe this can make it into 4.4 as well.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavformat/url.c | 24
Apr 7, 2021, 16:17 by yejun@intel.com:
> Signed-off-by: Guo, Yejun
> ---
> doc/APIchanges | 2 +
> libavutil/Makefile | 2 +
> libavutil/boundingbox.c | 73 +
> libavutil/boundingbox.h | 114
> libavutil/fram
On Tue, Apr 06, 2021 at 11:55:09PM +0200, Andreas Rheinhardt wrote:
> The (deprecated) field AVCodecContext.mpeg_quant has no range
> restriction; MpegEncContext.mpeg_quant is restricted to 0..1.
> If the former is set, the latter is overwritten with it without
> checking the range. This can trigge
Michael Niedermayer:
> On Tue, Apr 06, 2021 at 11:55:09PM +0200, Andreas Rheinhardt wrote:
>> The (deprecated) field AVCodecContext.mpeg_quant has no range
>> restriction; MpegEncContext.mpeg_quant is restricted to 0..1.
>> If the former is set, the latter is overwritten with it without
>> checking
The ProRes encoder allocates huge worst-case buffers just to be safe;
and for huge resolutions (8k in this case) these can be so big that the
number of bits does no longer fit into a (signed 32-bit) int; this means
that one must no longer use the parts of the PutBits API that deal with
bit counters
On Wed, Apr 07, 2021 at 11:07:54PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, Apr 06, 2021 at 11:55:09PM +0200, Andreas Rheinhardt wrote:
> >> The (deprecated) field AVCodecContext.mpeg_quant has no range
> >> restriction; MpegEncContext.mpeg_quant is restricted to 0..1.
>
Michael Niedermayer:
> On Wed, Apr 07, 2021 at 11:07:54PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Tue, Apr 06, 2021 at 11:55:09PM +0200, Andreas Rheinhardt wrote:
The (deprecated) field AVCodecContext.mpeg_quant has no range
restriction; MpegEncContext.mpeg_quant i
On Sat, Apr 03, 2021 at 10:32:13PM +0200, Lynne wrote:
> Apr 3, 2021, 20:12 by mich...@niedermayer.cc:
>
> > On Sat, Apr 03, 2021 at 03:01:16PM +0200, Lynne wrote:
> >
> >> Apr 2, 2021, 23:28 by mich...@niedermayer.cc:
> >>
> >> > On Mon, Mar 29, 2021 at 11:03:16PM +0300, Jan Ekström wrote:
> >> >
On Thu, Apr 08, 2021 at 12:17:04AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Wed, Apr 07, 2021 at 11:07:54PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Tue, Apr 06, 2021 at 11:55:09PM +0200, Andreas Rheinhardt wrote:
> The (deprecated) field AVCode
ff_vc1_decode_init_alloc_tables() had one error path that forgot to free
already allocated buffers; these would then be overwritten on the next
allocation attempt (or they would just not be freed in case this
happened during init, as the decoders for which it is used do not have
the FF_CODEC_CAP_IN
Andreas Rheinhardt:
> For both the RealMedia as well as the IVR demuxer (which share the same
> context) each AVStream's priv_data contains an AVPacket that might
> contain data (even when reading the header) and therefore needs to be
> unreferenced. Up until now, this has not always been done:
>
fre 2021-04-02 klockan 16:35 +0530 skrev Gyan Doshi:
>
> On 2021-04-02 15:29, Michael Niedermayer wrote:
> > Hi all
> >
> > We still need to choose the name for 4.4
> > previous unused suggestions where:
> > Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> > Viterbi, Darwin
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年4月8日 0:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> F
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: 2021年4月8日 5:04
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Apr 7, 2021, 16:17 by yejun@intel.com:
>
> > Sig
Dear:
In doc/example/resampling_audio.c
/* buffer is going to be directly written to a rawaudio file, no alignment
*/
dst_nb_channels = av_get_channel_layout_nb_channels(dst_ch_layout);
ret = av_samples_alloc_array_and_samples(&dst_data, &dst_linesize,
dst_nb_channels,
Apr 8, 2021, 04:48 by yejun@intel.com:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Lynne
>> Sent: 2021年4月8日 5:04
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
>> AV_FRAME_DATA_BOUNDING_BOXES
>>
>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: 2021年4月8日 12:14
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Apr 8, 2021, 04:48 by yejun@intel.com:
>
> >> >
On 07.04.2021 19:25, Paul B Mahol wrote:
Please ask someone else to apply it.
I can technically commit the patches but would prefer if some second
pair of eyes could take a look. So will apply them in a week from now if
nobody objects.
Regards,
Tobias
__
55 matches
Mail list logo
