> On Wed, 2021-10-27 at 16:57 +0800, Wenbin Chen wrote:
> > Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> > decrease. The reason is that vaRenderPicture() and vaSyncSurface() are
> > called at the same time (vaRenderPicture() always followed by a
> > vaSyncSurface()). W
On Wed, 2021-10-27 at 16:57 +0800, Wenbin Chen wrote:
> Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> decrease. The reason is that vaRenderPicture() and vaSyncSurface() are
> called at the same time (vaRenderPicture() always followed by a
> vaSyncSurface()). When we enc
> On Dec 27, 2021, at 2:38 PM, zhilizhao(赵志立) wrote:
>
>> On Dec 27, 2021, at 1:57 PM, Gyan Doshi wrote:
>>
>> As per ISO 14496-12, sample duration of 0 is invalid except for
>> the last entry.
>>
>> In addition, also catch 0 value for sample count.
>> ---
>> libavformat/mov.c | 12 +
> On Dec 27, 2021, at 1:57 PM, Gyan Doshi wrote:
>
> As per ISO 14496-12, sample duration of 0 is invalid except for
> the last entry.
>
> In addition, also catch 0 value for sample count.
> ---
> libavformat/mov.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavfo
On Tue, 14. Dec 02:12, Cameron Gutman wrote:
> The V4L2M2M API operates asynchronously, so multiple packets can
> be enqueued before getting a batch of frames back. Since it was
> only possible to receive a frame by submitting another packet,
> there wasn't a way to drain those excess output frames
On 2021-12-27 05:21 am, Michael Niedermayer wrote:
On Sun, Dec 26, 2021 at 09:30:44PM +0530, Gyan Doshi wrote:
Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit int
As per ISO 14496-12, sample duration of 0 is invalid except for
the last entry.
In addition, also catch 0 value for sample count.
---
libavformat/mov.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..fb7406cdd6 100644
--- a
On Mon, 2021-12-27 at 03:13 +, Chen, Wenbin wrote:
> > On Fri, 2021-12-10 at 13:38 +0800, Wenbin Chen wrote:
> > > From: nyanmisaka
> > >
> > > mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> > > Now the following commandline works:
> > >
> > > ffmpeg -v verbose -i
On Sat, 2021-12-25 at 11:48 +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> I haven't tested it for no build environment for qsv.
>
> libavcodec/qsvenc_hevc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsve
> On Fri, 2021-12-10 at 13:38 +0800, Wenbin Chen wrote:
> > From: nyanmisaka
> >
> > mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> > Now the following commandline works:
> >
> > ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
> > -init_hw_device qsv=qs
On Thu, 2021-12-23 at 14:01 +, Xiang, Haihao wrote:
> On Fri, 2021-11-26 at 19:29 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of Anton
> > > Khirnov
> > > Sent: Friday, November 26, 2021 8:12 PM
> > > To: FFmpeg development discussions and patch
On Sun, Dec 26, 2021 at 04:37:54PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote:
>
> > I'm not sure. My interpretation of Lance' and Steven's comments would
> > be that they'd prefer to stick to the ML.
> >
>
> No, it's not strictly related to that -
On Fri, Dec 24, 2021 at 4:08 PM Zane van Iperen wrote:
>
> Looks mostly alright, just some style nits. Once they're fixed, lgtm.
>
> On Wednesday, 22 December 2021 4:42:08 AM AEST p...@sandflow.com wrote:
>
> > +
> > +int ff_imf_xml_read_uuid(xmlNodePtr element, uint8_t uuid[16])
> > +{
> > +x
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
Tests for the IMF demuxer.
libavformat/Makefile | 1 +
libavformat/tests/imf.c| 526 +
tests/fate/libavformat.mak | 4 +
tests/ref/fate/imf | 54
4
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
The IMF demuxer accepts as input an IMF CPL. The assets referenced by the
CPL can be
contained in multiple deliveries, each defined by an ASSETMAP file:
ffmpeg -assetmaps ,,... -i
If -asset
Signed-off-by: Marton Balint
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a78797ef57..23e81bda9d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2085,7 +2085,7 @@ int ff_format_shift_data
Signed-off-by: Marton Balint
---
libavformat/segafilmenc.c | 51 ---
1 file changed, 5 insertions(+), 46 deletions(-)
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
index ff8cb66aca..737805faa6 100644
--- a/libavformat/segafilmenc.c
+++ b/l
add_keyframe_index seems to generate a corrupted index even before this change.
Signed-off-by: Marton Balint
---
libavformat/flvenc.c | 59 +---
1 file changed, 6 insertions(+), 53 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
inde
And move data shift function from movenc to utils.
Signed-off-by: Marton Balint
---
libavformat/internal.h | 7 ++
libavformat/movenc.c | 55 ++---
libavformat/utils.c| 56 ++
3 files changed, 65 insertions(+)
This makes sure the error condition is kept in AVIOContext even if the user
does not check the return value of avio_read_to_bprint or
ff_read_line_to_bprint.
Signed-off-by: Marton Balint
---
libavformat/aviobuf.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavfo
On Thu, 16 Dec 2021, Tomas Härdin wrote:
tis 2021-12-14 klockan 16:27 +0100 skrev Nicolas Gaullier:
Signed-off-by: Nicolas Gaullier
---
libavformat/mxfenc.c | 2 +-
tests/ref/lavf/mxf_opatom | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/l
On Sun, Dec 26, 2021 at 09:30:44PM +0530, Gyan Doshi wrote:
> Very high stts sample deltas may occasionally be intended but usually
> they are written in error or used to store a negative value for dts correction
> when treated as signed 32-bit integers.
>
> This option lets the user set an upper
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ronald S.
> Bultje
> Sent: Sunday, December 26, 2021 10:38 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] GitHub Integration
>
> Hi,
>
> On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote:
>
> >
Hi,
On Sun, Dec 26, 2021 at 3:21 PM Soft Works wrote:
> I'm not sure. My interpretation of Lance' and Steven's comments would
> be that they'd prefer to stick to the ML.
>
No, it's not strictly related to that - they want something that is CLI
accessible. Gitlab has this here: https://glab.read
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: Sunday, December 26, 2021 5:49 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] GitHub Integration
>
> 26 Dec 2021, 02:03 by l...@chinaffmpeg.org:
>
> >
> >
> >> 在 2021年12月26日，上午8:55，
> On Dec 27, 2021, at 12:00 AM, Gyan Doshi wrote:
>
> Very high stts sample deltas may occasionally be intended but usually
> they are written in error or used to store a negative value for dts correction
> when treated as signed 32-bit integers.
>
> This option lets the user set an upper limi
As per discussion on the list (
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html),
to resolve the the unholy ABI-relationship between libavdevice and
libavformat and allow easier working on the part of th
26 Dec 2021, 02:03 by l...@chinaffmpeg.org:
>
>
>> 在 2021年12月26日，上午8:55，lance.lmw...@gmail.com 写道：
>>
>> On Sat, Dec 25, 2021 at 05:15:19PM +, Soft Works wrote:
>>
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of Lynne
Sent: Saturday, December 25, 2021 5:50 P
Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit integers.
This option lets the user set an upper limit, beyond which the delta is clamped
to 1.
Values greater than th
Hi,
(I was asked to respond since I'm listed as HTTP maintainer, not sure I
should be since I'm mostly working on video codecs nowadays.)
On Tue, Nov 2, 2021 at 9:00 AM Eran Kornblau
wrote:
> The motivation for this feature is S3 signatures – currently we have a
> problem where S3 signatures ca
No speex samples with non default frame sizes are known (to me)
the official speexenc seems to only generate the 3 default ones.
Thus it may be that the fuzzer samples where the first non default
values encountered by the decoder.
Possibly the "<" should be "!="
If someone has a valid speex file w
On Sun, Dec 26, 2021 at 09:50:28AM +0100, Paul B Mahol wrote:
> Please confirm you are not breaking tile files in any way.
Ive tested both strip and tile dng/tiff files
Thats what i tested with:
1_1.1.1.dpx
1_1.2.1.dpx
1_1.3.1.dpx
A001_C022_20171009_R00100.dng
Footage_01/A003_C001_20170717_R
Please confirm you are not breaking tile files in any way.
On Sat, Dec 25, 2021 at 11:43 PM Michael Niedermayer
wrote:
> The whole concept is just not correct, also as it seems not to be needed
> at all, all dng files i have decode without this.
>
> Fixes: various crashes
> Fixes:
> 42937/cluste
33 matches
Mail list logo
