On Sat, Aug 8, 2020 at 12:56 PM Gyan Doshi wrote:
>
>
>
> On 07-08-2020 07:06 pm, Jun Zhao wrote:
> > From: tomajsjiang
> >
> > Update filter buffer/abuffer interface file name, from
> > libavfilter/{vsrc|asrc_buffer.h} to libavfilter/buffersrc.h
> >
> > Signed-off-by: Jun Zhao
> > Signed-off-by
All files I've seen are identical, irregardless of version.
Until shown otherwise, assume unknown ones are too.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 37 +++--
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/libavformat/argo_as
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index beec46a0d4..52e37f9c10 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -63,11 +63,11 @
Preparation for options.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 52e37f9c10..1770192aad 100644
--- a/libavforma
Only when the user hasn't manually specified one.
Matches the original files more closely.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 34
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 1770192aad..9845cb955b 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/a
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 9845cb955b..3499519903 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -69,6 +69,7
Zane van Iperen:
> Preparation for options.
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_asf.c | 42 +-
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
> index 52e37f9c10.
Zane van Iperen:
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_asf.c | 37 +++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
> index 1770192aad..9845cb955b 100644
> --- a/libavform
Zane van Iperen:
> Signed-off-by: Zane van Iperen
> ---
> libavformat/argo_asf.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
> index 9845cb955b..3499519903 100644
> --- a/libavformat/argo_asf.c
> +++ b/li
Hi Zane!
Am 8. August 2020 10:01:07 MESZ schrieb Zane van Iperen
:
>Signed-off-by: Zane van Iperen
>---
> libavformat/argo_asf.c | 37 +++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
>diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
>index 1
On 08.08.2020 02:48, Linjie Fu wrote:
On Fri, Aug 7, 2020 at 4:19 PM leozhang wrote:
Allow dynamic resolution change, this is useful for real time video
communication application.
Use below commands to test it,
ffmpeg -i reinit-large_420_8-to-small_420_8.h264 -noautoscale -c:v hevc_nvenc
ou
On 07.08.2020 10:18, leozhang wrote:
Allow dynamic resolution change, this is useful for real time video
communication application.
Use below commands to test it,
ffmpeg -i reinit-large_420_8-to-small_420_8.h264 -noautoscale -c:v hevc_nvenc
out.265 -loglevel verbose -y
ffmpeg -i reinit-large_4
On Sat, 8 Aug 2020 11:46:55 +0200
"Andreas Rheinhardt" wrote:
> >
> There is no point keeping data only used once in your context which is
> not what these contexts are there for. Coupled with patch 4/6 you are
> adding a const AVClass * to the context of the demuxer although the
> demuxer doesn'
On Sat, 8 Aug 2020 12:15:01 +0200
"Andreas Rheinhardt" wrote:
> The version fields in the structure mimic the way the header is set up:
> They are uint16_t. Yet the fields will be written with a pointer to int
> (that's a consequence of using AV_OPT_TYPE_INT). This means that (most
> likely) an u
On Sat, 08 Aug 2020 13:05:28 +0200
"Alexander Strasser" wrote:
>
> Hi Zane!
>
Hello!
> >@@ -296,8 +298,7 @@ static int argo_asf_write_header(AVFormatContext
> >*s)
> > ArgoASFContext *ctx = s->priv_data;
> >
> > ctx->fhdr.magic = ASF_TAG;
> >-ctx->fhdr.version
On Sat, 8 Aug 2020 12:20:32 +0200
"Andreas Rheinhardt" wrote:
> > #if CONFIG_ARGO_ASF_DEMUXER
> > @@ -301,7 +302,10 @@ static int argo_asf_write_header(AVFormatContext *s)
> > /* version_{major,minor} set by options. */
> > ctx->fhdr.num_chunks = 1;
> > ctx->fhdr.chunk_off
Zane van Iperen:
> On Sat, 8 Aug 2020 12:20:32 +0200
> "Andreas Rheinhardt" wrote:
>
>>> #if CONFIG_ARGO_ASF_DEMUXER
>>> @@ -301,7 +302,10 @@ static int argo_asf_write_header(AVFormatContext *s)
>>> /* version_{major,minor} set by options. */
>>> ctx->fhdr.num_chunks = 1;
>>>
All files I've seen are identical, irregardless of version.
Until shown otherwise, assume unknown ones are too.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 37 +++--
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/libavformat/argo_as
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index c693cfd045..7eaf2fec73 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -74,6 +74,7
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 47 +++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index beec46a0d4..c693cfd045 100644
--- a/libavformat/argo_asf.c
+++ b/libavfor
Only when the user hasn't manually specified one.
Matches the original files more closely.
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 7ea
It is unused since 8cbb055760c725d0fb99fb759caabb5f4e37e340 and it
actually coincides with avfilter_make_format64_list().
Signed-off-by: Andreas Rheinhardt
---
libavfilter/formats.c | 11 ---
libavfilter/formats.h | 3 ---
2 files changed, 14 deletions(-)
diff --git a/libavfilter/forma
Despite its name, this function is not part of the public API, as
formats.h, the header containing its declaration, is a private header.
The formats API was once public API, but that changed long ago
(b74a1da49db5ebed51aceae6cacc2329288a92c1, the commit scheduling it to
become private, is from 2012
Signed-off-by: Andreas Rheinhardt
---
libavfilter/avf_showcqt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index cb0dca505f..990db3143b 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -1
ff_merge_formats(), ff_merge_samplerates() and ff_merge_channel_layouts()
share common semantics: If merging succeeds, a non-NULL pointer is
returned and both input lists (of type AVFilterFormats resp.
AVFilterChannelLayouts) are to be treated as if they had been freed;
the owners of the input para
Now that the output's refs-array is only allocated once, it is NULL in
any error case and therefore needn't be freed at all. Furthermore, it is
unnecessary to av_freep(&ptr) when ptr == NULL.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/formats.c | 9 +++--
1 file changed, 3 insertions(
This reverts commit f156f4ab2317f22bfef33c7eaead0d5d5f162903.
The checks added by said commit are nonsense because they did not help
in case ff_merge_samplerates() or ff_merge_formats() returned NULL
while freeing one of its arguments: Said freeing does not change
the local variables of can_merge_
On 8/8/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avf_showcqt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index cb0dca505f..990db3143b 100644
> --- a/libavfilte
On Sat, Aug 8, 2020 at 7:21 PM Timo Rothenpieler wrote:
>
> On 08.08.2020 02:48, Linjie Fu wrote:
> > On Fri, Aug 7, 2020 at 4:19 PM leozhang wrote:
> >>
> >> Allow dynamic resolution change, this is useful for real time video
> >> communication application.
> >>
> >> Use below commands to test
Andreas Rheinhardt (12020-08-08):
> Now that the output's refs-array is only allocated once, it is NULL in
> any error case and therefore needn't be freed at all. Furthermore, it is
> unnecessary to av_freep(&ptr) when ptr == NULL.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/format
Andreas Rheinhardt (12020-08-08):
> This reverts commit f156f4ab2317f22bfef33c7eaead0d5d5f162903.
>
> The checks added by said commit are nonsense because they did not help
> in case ff_merge_samplerates() or ff_merge_formats() returned NULL
> while freeing one of its arguments: Said freeing does
Nicolas George:
> Andreas Rheinhardt (12020-08-08):
>> Now that the output's refs-array is only allocated once, it is NULL in
>> any error case and therefore needn't be freed at all. Furthermore, it is
>> unnecessary to av_freep(&ptr) when ptr == NULL.
>>
>> Signed-off-by: Andreas Rheinhardt
>> --
On Wed, 05. Aug 14:37, Moritz Barsnick wrote:
> On Mon, Jul 20, 2020 at 09:18:55 +0200, Alexander Strasser wrote:
> > On 2020-07-19 19:47 -0400, Andriy Gelman wrote:
> > > > > This check seems dead code. Looking at xcb sources, cursor is just an
> > > > > offset in
> > > > > memory from ci so I do
Unacceptable as it contains multiple typos.
On 7/31/20, Nicolas George wrote:
> Tables that were not just written by the code author are
> not actually source code, otherwise,
> "recode data..x1 < proprietary.o > source.c"
> would be enough to launder a proprietary blob into
> the source code.
>
Andreas Rheinhardt (12020-08-08):
> PS: Is the order of the formats/channel_layouts arrays actually important?
IIRC, there are parts of the code that selects best formats and put them
in the front of the list. I need to dig back into all this to refresh my
memory, it is complex and it will need to
At 2020-08-06 05:21:43, "James Almer" wrote:
>On 8/5/2020 1:18 PM, hwr...@126.com wrote:
>> From: hwren
>>
>> Signed-off-by: hbj
>> Signed-off-by: hwren
>> ---
>> Changelog | 1 +
>> configure | 4 +
>> doc/decoders.texi | 21 +++
>> doc/
Nicolas George:
> Andreas Rheinhardt (12020-08-08):
>> PS: Is the order of the formats/channel_layouts arrays actually important?
>
> IIRC, there are parts of the code that selects best formats and put them
> in the front of the list. I need to dig back into all this to refresh my
> memory, it is
Tables that were not just written by the code author are
not actually source code, otherwise,
"recode data..x1 < proprietary.o > source.c"
would be enough to launder a proprietary blob into
the source code.
Documenting the origin of the tables or the methods
for their generation is necessary to le
On 08/08/2020 12:22, Timo Rothenpieler wrote:
On 07.08.2020 10:18, leozhang wrote:
Allow dynamic resolution change, this is useful for real time video
communication application.
Use below commands to test it,
ffmpeg -i reinit-large_420_8-to-small_420_8.h264 -noautoscale -c:v hevc_nvenc
out.26
On 08/08/2020 18:57, Nicolas George wrote:
Tables that were not just written by the code author are
not actually source code, otherwise,
"recode data..x1 < proprietary.o > source.c"
would be enough to launder a proprietary blob into
the source code.
Documenting the origin of the tables or the me
On 26/07/2020 13:26, Jun Zhao wrote:
From: Jun Zhao
Export choosen pict_type.
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 6766641..2352fdd 100
On 26/07/2020 13:26, Jun Zhao wrote:
From: Jun Zhao
Export choosen pict_type and qp.
Signed-off-by: Jun Zhao
---
libavcodec/libkvazaar.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index 71c9c8f..9032
On Sat, 8 Aug 2020 19:57:09 +0200
"Nicolas George" wrote:
>
> Tables that were not just written by the code author are
> not actually source code, otherwise,
> "recode data..x1 < proprietary.o > source.c"
> would be enough to launder a proprietary blob into
> the source code.
>
> Documenting th
Previously, the only way to input the master display and content light metadata
required for HDR10 was through x265-params. Obviously, that only worked with
x265. If you wanted to use a different encoder like nvenc, you were out of
luck. The options specified are written to the container (mov or
After adding a copy pass through path inside MSDK, x2rgb10 is now
available as an output of VPP.
Command line for CSC:
ffmpeg -hwaccel qsv -v verbose -c:v hevc_qsv -i
p010.h265 -vf scale_qsv=format=x2rgb10,hwdownload,format=x2rgb10
-vframes 1 out.yuv
Signed-off-by: Linjie Fu
---
[1]Issue
Hi,
Would someone be willing to help me with this? This is the first patch I’ve
submitted. Patchwork shows that two tests are failing. However, when I run
“make fate” locally, I don’t see any failures. Is there some other make or
configure command that I can run to make my results match tho
47 matches
Mail list logo
