> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Thursday, 9 September 2021 22:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Running FATE
>
> On 9/9/2021 5:04 PM, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From:
It is possible that an IRAP frame in input AVPacket has SPS and PPS, and
these headers should take effect. Hence we should not prepend extra data
to IRAP frame in this case, otherwise an IRAP frame in output AVPacket
will have 2 SPS/PPS when extra data also has SPS and PPS, the second
SPS/PPS will
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Thursday, September 9, 2021 8:48 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: fix a bug for
> mapping qsv frame to vaapi
>
> On 9/9/2021 6:13 AM, Wenbin Chen
Hayden Myers
Principal Software Engineer
t: (410) 590-2027
From: ffmpeg-devel on behalf of Hayden Myers
Sent: Monday, August 23, 2021 7:23 PM
To: FFmpeg development discussions and patches
Subject: [FFmpeg-devel] [PATCH] libavformat/rtpdec_jpeg.c: quantization table
headers not sent in
On Thu, 2021-09-09 at 12:54 -0300, James Almer wrote:
> On 9/9/2021 12:41 PM, Xiang, Haihao wrote:
> > On Thu, 2021-09-09 at 12:32 -0300, James Almer wrote:
> > > On 1/6/2021 12:12 AM, Xu Guangxin wrote:
> > > > fixes #8857
> > > >
> > > > If we do not clear the enc_ctrl, we will reuse previous
9 Sept 2021, 22:18 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> 9 Sept 2021, 21:15 by geo...@nsup.org:
>>
>>> Lynne (12021-09-09):
>>>
No, you don't, there's nothing special about this!
>>>
>>> There is no need for something special, it is an universal fact of
>>> programming that
Lynne:
> 9 Sept 2021, 21:15 by geo...@nsup.org:
>
>> Lynne (12021-09-09):
>>
>>> No, you don't, there's nothing special about this!
>>>
>>
>> There is no need for something special, it is an universal fact of
>> programming that if several redundant pieces of information are supposed
>> to be in
On 9/9/2021 5:04 PM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Gyan Doshi
Sent: Thursday, 9 September 2021 09:24
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] Running FATE
On 2021-09-09 11:03 am, Soft Works wrote:
Hi,
I have a few questions
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Thursday, 9 September 2021 09:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Running FATE
>
>
>
> On 2021-09-09 11:03 am, Soft Works wrote:
> > Hi,
> >
> > I have a few questions regarding
Lynne (12021-09-09):
> It's a necessary piece of information pertinent to the correct
> presenting of each frame. Moreover, it simplifies the API,
That piece of information is already present along with all the other
pieces of information necessary to make sense of a frame.
> which new users are
On Thu, 9 Sep 2021, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
tests/fate/filter-audio.mak | 5 +--
tests/ref/fate/filter-silenceremove | 67 ++---
2 files changed, 35 insertions(+), 37 deletions(-)
Thanks, this does seem to fix the test on aarch64 at
9 Sept 2021, 21:15 by geo...@nsup.org:
> Lynne (12021-09-09):
>
>> No, you don't, there's nothing special about this!
>>
>
> There is no need for something special, it is an universal fact of
> programming that if several redundant pieces of information are supposed
> to be in sync, unless there
Paul B Mahol (12021-09-09):
> Such people should than leave project.
I will chose to ignore that useless remark.
> I read this as personal attack.
This was not my intent, I am sorry you took it that way. If you would
please explain to me how you read a personal attack in a sentence that
affirms
On Thu, Sep 9, 2021 at 9:18 PM Lynne wrote:
> 9 Sept 2021, 19:40 by one...@gmail.com:
>
> > On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
> >
> >> Lynne (12021-09-09):
> >> > That's fine, no argument about this. We talked about this on IRC
> >> > and I agreed that duration fields on
9 Sept 2021, 19:40 by one...@gmail.com:
> On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
>
>> Lynne (12021-09-09):
>> > That's fine, no argument about this. We talked about this on IRC
>> > and I agreed that duration fields on frames make no sense and
>> > are difficult to guarantee.
>>
Lynne (12021-09-09):
> No, you don't, there's nothing special about this!
There is no need for something special, it is an universal fact of
programming that if several redundant pieces of information are supposed
to be in sync, unless there are strong systems to keep them in sync,
they will
Signed-off-by: Paul B Mahol
---
tests/fate/filter-audio.mak | 5 +--
tests/ref/fate/filter-silenceremove | 67 ++---
2 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index
9 Sept 2021, 15:53 by geo...@nsup.org:
> Lynne (12021-09-09):
>
>> Because all of our codecs pass their frames through a wrapper function before
>> they get to the user. So, we just set the field there, add a FATE test, and
>> now
>> they're guaranteed to be correctly kept updated.
>>
>
> This
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wenbin Chen
> Sent: Thursday, 9 September 2021 11:13
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wenbin Chen
> Subject: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: fix a bug
> for mapping qsv frame to vaapi
>
> Command below
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Thursday, 9 September 2021 11:50
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
>
> Soft Works:
> > Test seek-lavf-asf failed. Look at
On Thu, Sep 9, 2021 at 12:51 PM Nicolas George wrote:
> Lynne (12021-09-09):
> > That's fine, no argument about this. We talked about this on IRC
> > and I agreed that duration fields on frames make no sense and
> > are difficult to guarantee.
>
> Thank you for mentioning this.
>
> Not everybody
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Thursday, 9 September 2021 09:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Running FATE
>
>
>
> On 2021-09-09 11:03 am, Soft Works wrote:
> > Hi,
> >
> > I have a few questions regarding
Do this by allocating AVFormatContext together with the data that is
currently in AVFormatInternal; or rather: Put AVFormatContext at the
beginning of a new structure called FFFormatContext (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the
Dead since commit 93016f5d1d280f9cb7856883af287fa66affc04c
which ensured that the packets received by encoders are always blank.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/qsvenc.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/libavcodec/qsvenc.c
Fixes leaks in case the allocation of the H.264-specific stuff fails.
Fixes Coverity issues #1442911 and #1442914.
Signed-off-by: Andreas Rheinhardt
---
Sending this as part of the other patchset so that fate doesn't fail.
It is of course completely separate.
libavcodec/qsvenc.c | 49
These are internal fields.
Signed-off-by: Andreas Rheinhardt
---
show_program() is only entered by three tests: mpegts-probe-pmt-merge,
mpegts-probe-program and mpegts-probe-latm. Even mpegts-probe-latm does
not print detailed information about programs, hence the lack of
FATE-updates.
Signed-off-by: Andreas Rheinhardt
---
libavformat/internal.h | 4 ++--
libavformat/utils.c| 14 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index d14dee5422..cc8c8f4b43 100644
--- a/libavformat/internal.h
+++
Signed-off-by: Andreas Rheinhardt
---
libavformat/demux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 267ebce07f..7bcd23ed62 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -319,8 +319,8 @@ int
libavformat/utils.c has over 5500 lines and is supposed to contain
"various utility functions for use within FFmpeg". In reality it
contains all that and the whole demuxing+seeking core of libavformat.
This is especially bad, because said file includes the FFMPEG_VERSION
(the git commit sha) so
Signed-off-by: Andreas Rheinhardt
---
libavformat/utils.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9c174425d3..25285f62ab 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4289,19
This gets rid of ugly "->internal" and is in preparation for removing
AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 131 ---
libavformat/utils.c | 885 +++-
2 files changed, 542 insertions(+), 474
This gets rid of ugly "->internal" and is in preparation for removing
AVFormatInternal altogether.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c| 105 ++
libavformat/mxfenc.c | 15 ++--
libavformat/utils.c | 173 +--
Signed-off-by: Andreas Rheinhardt
---
Now also including asfenc because I don't like that there is an
AVCodecParameters in asf_write_header1 in the outer function block
although all AVCodecParameters in said function have smaller scope.
libavformat/asfenc.c | 54
libavformat/mux.c
Signed-off-by: Andreas Rheinhardt
---
If it were documented that a non-NULL AVDictionary is always nonempty
this could be simplified. But I don't know whether we want to document
that.
libavformat/mp3dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c
Signed-off-by: Andreas Rheinhardt
---
libavformat/mp3dec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 195d89814e..9205abebc4 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -171,7 +171,8 @@ static
On 9/9/2021 12:41 PM, Xiang, Haihao wrote:
On Thu, 2021-09-09 at 12:32 -0300, James Almer wrote:
On 1/6/2021 12:12 AM, Xu Guangxin wrote:
fixes #8857
If we do not clear the enc_ctrl, we will reuse previous frames' data like
FrameType.
---
libavcodec/qsvenc.c | 2 ++
1 file changed, 2
This reverts commits 3b331468dae2e88ee6c87c257ac159ad662efcac
and 8a42ee6697317d0a30438df5905dfc0247cd28e7. They broke
the filter-silenceremove FATE-test, as they were pushed without
updating the reference file. Worse, the new output is not bitexact
across all arches, as the diff on aarch64 is
On Thu, 2021-09-09 at 12:32 -0300, James Almer wrote:
> On 1/6/2021 12:12 AM, Xu Guangxin wrote:
> > fixes #8857
> >
> > If we do not clear the enc_ctrl, we will reuse previous frames' data like
> > FrameType.
> > ---
> > libavcodec/qsvenc.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> >
On 1/6/2021 12:12 AM, Xu Guangxin wrote:
fixes #8857
If we do not clear the enc_ctrl, we will reuse previous frames' data like
FrameType.
---
libavcodec/qsvenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 2bd2a56227..94473c4eab
On Mon, 2021-08-30 at 08:04 +, Xiang, Haihao wrote:
> On Mon, 2021-08-30 at 05:52 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Xiang, Haihao
> > > Sent: Monday, 30 August 2021 06:20
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re:
On Wed, 2021-01-06 at 06:53 +, Xiang, Haihao wrote:
> On Wed, 2021-01-06 at 11:12 +0800, Xu Guangxin wrote:
> > fixes #8857
> >
> > If we do not clear the enc_ctrl, we will reuse previous frames' data like
> > FrameType.
> > ---
> > libavcodec/qsvenc.c | 2 ++
> > 1 file changed, 2
Lynne (12021-09-09):
> Because all of our codecs pass their frames through a wrapper function before
> they get to the user. So, we just set the field there, add a FATE test, and
> now
> they're guaranteed to be correctly kept updated.
This is wrong and not enough. Codecs are not the only origin
Lynne (12021-09-09):
> NAK.
> Patches that use the field have been posted, but have not been merged yet.
Pointers please.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
9 Sept 2021, 14:53 by geo...@nsup.org:
> Lynne (12021-09-09):
>
>> It's not a maintenance nightmare, it's a single optional field. Please don't
>>
>
> Then please answer this simple question: How do you guarantee that this
> new field will always be correctly kept updated?
>
Because all of our
9 Sept 2021, 15:34 by geo...@nsup.org:
> The contents of AVPacket can only make sense with some extra information.
> In FFmpeg, this information is carried by AVStream. Applications can use
> AVStream or define their own data structure for that. There is no reason
> to carry one of these
On 9/9/2021 5:46 AM, Peter Ross wrote:
---
Thanks for suggestion. I will apply in a couple days if no objections.
libavcodec/siren.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/libavcodec/siren.c b/libavcodec/siren.c
index
The contents of AVPacket can only make sense with some extra information.
In FFmpeg, this information is carried by AVStream. Applications can use
AVStream or define their own data structure for that. There is no reason
to carry one of these informations everywhere along with the packet.
Lynne (12021-09-09):
> It's not a maintenance nightmare, it's a single optional field. Please don't
Then please answer this simple question: How do you guarantee that this
new field will always be correctly kept updated?
> reject my ideas and needs outright, I'm not the only API user who would
>
On 9/9/2021 6:13 AM, Wenbin Chen wrote:
Command below failed.
ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128
-init_hw_device qsv=qs@va -hwaccel qsv -hwaccel_device qs
-filter_hw_device va -c:v h264_qsv
-i 1080P.264 -vf "hwmap,format=vaapi" -c:v h264_vaapi output.264
Cause:
9 Sept 2021, 12:48 by geo...@nsup.org:
> Lynne (12021-09-09):
>
>> Did you read what I wrote? I think I was very clear.
>>
>
> I did. And you, did you read what I wrote? You are only answering one of
> the questions.
>
>> It's an output, unless a specific flag is set to accept it as an input.
>>
Lynne (12021-09-09):
> That's fine, no argument about this. We talked about this on IRC
> and I agreed that duration fields on frames make no sense and
> are difficult to guarantee.
Thank you for mentioning this.
Not everybody can spend time synchronously on IRC.
> One thing though, "Speaking
Lynne (12021-09-09):
> Did you read what I wrote? I think I was very clear.
I did. And you, did you read what I wrote? You are only answering one of
the questions.
> It's an output, unless a specific flag is set to accept it as an input.
> API users don't have to maintain it without the flag
9 Sept 2021, 12:02 by geo...@nsup.org:
> Speaking as the maintainer of libavfilter, and without closing any
> further discussion, I say: the duration of a frame is currently defined
> as the difference with the timestamp of the next frame, and it should
> continue to be. If a duration field is
9 Sept 2021, 12:02 by geo...@nsup.org:
> Marton Balint (12021-09-08):
>
>> So how this is going to work? Will e.g. avcodec_send_frame check the time
>> base of the frame and recalculate pts/duration to the encoder time base?
>> Same goes for every function which is receiving frames?
>>
>
>
>
9 Sept 2021, 10:46 by pr...@xvid.org:
> ---
>
> Thanks for suggestion. I will apply in a couple days if no objections.
>
> libavcodec/siren.c | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/siren.c b/libavcodec/siren.c
> index
Martin Storsjö:
> On Wed, 8 Sep 2021, Paul B Mahol wrote:
>
>> ffmpeg | branch: master | Paul B Mahol | Wed Sep 8
>> 13:06:43 2021 +0200| [3b331468dae2e88ee6c87c257ac159ad662efcac] |
>> committer: Paul B Mahol
>>
>> avfilter/af_silenceremove: fix processing of periods > 1
>>
>>>
On Wed, 8 Sep 2021, Paul B Mahol wrote:
ffmpeg | branch: master | Paul B Mahol | Wed Sep 8 13:06:43
2021 +0200| [3b331468dae2e88ee6c87c257ac159ad662efcac] | committer: Paul B Mahol
avfilter/af_silenceremove: fix processing of periods > 1
Marton Balint (12021-09-08):
> So how this is going to work? Will e.g. avcodec_send_frame check the time
> base of the frame and recalculate pts/duration to the encoder time base?
> Same goes for every function which is receiving frames?
Thanks for raising this question.
If we add this field
Soft Works:
> Test seek-lavf-asf failed. Look at tests/data/fate/seek-lavf-asf.err for
> details.
> make: *** [/build/ffmpeg-git/tests/Makefile:256: fate-seek-lavf-asf] Error 139
>
> $ cat tests/data/fate/seek-lavf-asf.err
> /build/ffmpeg-git/tests/fate-run.sh: line 78: 21786 Segmentation fault
Command below failed.
ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128
-init_hw_device qsv=qs@va -hwaccel qsv -hwaccel_device qs
-filter_hw_device va -c:v h264_qsv
-i 1080P.264 -vf "hwmap,format=vaapi" -c:v h264_vaapi output.264
Cause: Assign pair->first directly to data[3] in vaapi
---
Thanks for suggestion. I will apply in a couple days if no objections.
libavcodec/siren.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/libavcodec/siren.c b/libavcodec/siren.c
index 2161b29a2c..40910f34e5 100644
--- a/libavcodec/siren.c
On 2021-09-09 11:03 am, Soft Works wrote:
Hi,
I have a few questions regarding FATE:
- Is it possible to run FATE in a way that it doesn't stop on error?
make -k fate
- Is there a better way to exclude certain tests other than commenting
them in the mak files?
Don't enable/compile
62 matches
Mail list logo
