Am So., 21. März 2021 um 06:13 Uhr schrieb Nuo Mi :
>
> Magic number 124 and ^= are not listed on the spec.
> Strictly following the spec will make a reader's life much easier. See (9-6)
> for details
But FFmpeg is not providing a reference application for the reader,
this is software actually us
Am So., 21. März 2021 um 02:04 Uhr schrieb James Almer :
>
> On 3/20/2021 3:30 PM, Carl Eugen Hoyos wrote:
> > Am Sa., 20. März 2021 um 19:06 Uhr schrieb James Almer :
> >>
> >> On 3/20/2021 2:51 PM, Carl Eugen Hoyos wrote:
> >>> Hi!
> >>>
> >>> Attached patch fixes lossless aom encoding in some ca
Hello Steven,
Eagerly waiting for your reply.
Piyush
On Sat, 20 Mar 2021 at 02:20, Piyush Chauhan
wrote:
> 15 Mar 2021, 07:14, Steven Liu :
>
> Hi Piyushi Chanuhan,
>>
>> 1st. You could try understand these rules under the link:
>> https://summerofcode.withgoogle.com/get-started/
>>
>> 2nd. An
> 2021年3月21日 下午5:27，Piyush Chauhan 写道：
>
> Hello Steven,
>
> Eagerly waiting for your reply.
You looks rush to finish this project and finish it, but I think we should in
the timeline of GSoC.
And there have rule of GSoC, but I cannot sure you have read all of the content
which I leaved.
I
Please make log message consistent with other commits to this file.
Also make set of patches to be applied all at once instead each single one.
On Fri, Mar 19, 2021 at 1:08 PM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> This changes the iflat_range and flat_range values for the
On Sun, Mar 21, 2021 at 10:35 AM Steven Liu wrote:
>
>
> > 2021年3月21日 下午5:27，Piyush Chauhan 写道：
> >
> > Hello Steven,
> >
> > Eagerly waiting for your reply.
> You looks rush to finish this project and finish it, but I think we should
> in the timeline of GSoC.
> And there have rule of GSoC, but
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 48 +++-
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 2f3896dcc4..3088d2ff3f 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec
Our "get name" functions can return NULL for invalid/unknown
arguments. So check for this.
Signed-off-by: Andreas Rheinhardt
---
av_get_colorspace_name() can even return NULL for supported colorspaces.
libavcodec/avcodec.c | 33 +
1 file changed, 17 insertions(+)
If the numerical constants for colorspace, transfer characteristics
and color primaries coincide, the current code presumes the
corresponding names to be identical and prints only one of them obtained
via av_get_colorspace_name(). There are two issues with this: The first
is that the underlying ass
It automatically records the current length of the string,
whereas the current code contains lots of instances of
snprintf(buf + strlen(buf), buf_size - strlen(buf), ...).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 133 +--
1 file changed
Contrary to av_color_space_name() it doesn't even support newer
colorspaces.
Signed-off-by: Andreas Rheinhardt
---
doc/APIchanges | 4
libavutil/frame.c | 3 ++-
libavutil/frame.h | 5 -
libavutil/version.h | 5 -
4 files changed, 14 insertions(+), 3 deletions(-)
diff --gi
> 2021年3月21日 下午5:42，Paul B Mahol 写道：
>
>
>
> On Sun, Mar 21, 2021 at 10:35 AM Steven Liu wrote:
>
>
> > 2021年3月21日 下午5:27，Piyush Chauhan 写道：
> >
> > Hello Steven,
> >
> > Eagerly waiting for your reply.
> You looks rush to finish this project and finish it, but I think we should in
> t
On Sun, Mar 21, 2021 at 10:58 AM Steven Liu wrote:
>
>
> > 2021年3月21日 下午5:42，Paul B Mahol 写道：
> >
> >
> >
> > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu wrote:
> >
> >
> > > 2021年3月21日 下午5:27，Piyush Chauhan 写道：
> > >
> > > Hello Steven,
> > >
> > > Eagerly waiting for your reply.
> > You look
> 2021年3月21日 下午6:03，Paul B Mahol 写道：
>
>
>
> On Sun, Mar 21, 2021 at 10:58 AM Steven Liu wrote:
>
>
> > 2021年3月21日 下午5:42，Paul B Mahol 写道：
> >
> >
> >
> > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu wrote:
> >
> >
> > > 2021年3月21日 下午5:27，Piyush Chauhan 写道：
> > >
> > > Hello Steven
On Sun, Mar 21, 2021 at 11:10 AM Steven Liu wrote:
>
>
> > 2021年3月21日 下午6:03，Paul B Mahol 写道：
> >
> >
> >
> > On Sun, Mar 21, 2021 at 10:58 AM Steven Liu wrote:
> >
> >
> > > 2021年3月21日 下午5:42，Paul B Mahol 写道：
> > >
> > >
> > >
> > > On Sun, Mar 21, 2021 at 10:35 AM Steven Liu
> wrote:
> > >
Also avoid a potential race with frame threading, where a frame's
metadata could be modified concurrently with that frame being passed to
another thread.
Fixes #8972
Found-by: Andreas Rheinhardt
---
libavcodec/pngdec.c | 27 ++-
1 file changed, 18 insertions(+), 9 deleti
---
tests/fate/apng.mak| 4 +
tests/ref/fate/apng-frame-metadata | 270 +
2 files changed, 274 insertions(+)
create mode 100644 tests/ref/fate/apng-frame-metadata
diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak
index 0a5f542f19..0d8f191359 100
> 2021年3月21日 下午6:10，Steven Liu 写道：
>
>
>
>> 2021年3月21日 下午6:03，Paul B Mahol 写道：
>>
>>
>>
>> On Sun, Mar 21, 2021 at 10:58 AM Steven Liu wrote:
>>
>>
>>> 2021年3月21日 下午5:42，Paul B Mahol 写道：
>>>
>>>
>>>
>>> On Sun, Mar 21, 2021 at 10:35 AM Steven Liu wrote:
>>>
>>>
2021年3月21日 下
Anton Khirnov:
> ---
> tests/fate/apng.mak| 4 +
> tests/ref/fate/apng-frame-metadata | 270 +
> 2 files changed, 274 insertions(+)
> create mode 100644 tests/ref/fate/apng-frame-metadata
>
> diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak
> i
Pushed as 36a5ae619a7d255c27f66a343a7861108d789159
On 2021-03-20 19:28, Gyan Doshi wrote:
Will apply tomorrow.
On 2021-03-18 17:56, Gyan Doshi wrote:
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index f0ac719d2d..be9c5b4b1c 100755
--- a/configure
+
Pushed as 75fd3e15190cf72ffcfa15f0fb00f1d9a7ac5b6e
On 2021-03-20 19:28, Gyan Doshi wrote:
Will apply tomorrow.
On 2021-03-18 18:04, Gyan Doshi wrote:
---
libavformat/rtpenc_mpegts.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/rtpenc_mpegts.c
Anton Khirnov:
> Also avoid a potential race with frame threading, where a frame's
> metadata could be modified concurrently with that frame being passed to
> another thread.
>
> Fixes #8972
>
> Found-by: Andreas Rheinhardt
> ---
> libavcodec/pngdec.c | 27 ++-
> 1 file
Hi Fei,
On Mon, Mar 15, 2021 at 1:13 PM Fei Wang wrote:
>
> Async depth will allow qsv filter cache few frames, and avoid force
> switch and end filter task frame by frame. This change will improve
> performance for some multi-task case, for example 1:N transcode(
> decode + vpp + encode) with al
Am So., 21. März 2021 um 11:15 Uhr schrieb Anton Khirnov :
>
> Also avoid a potential race with frame threading, where a frame's
> metadata could be modified concurrently with that frame being passed to
> another thread.
>
> Fixes #8972
Ticket #8972 is definitely reproducible with versions older t
>
> You looks rush to finish this project and finish it, but I think we should
> in the timeline of GSoC.
> And there have rule of GSoC, but I cannot sure you have read all of the
> content which I leaved.
> I think if will not so rush to finish this project if you really read that.
>
My apologies,
> 2021年3月21日 下午6:09，Piyush Chauhan 写道：
>
>>
>> You looks rush to finish this project and finish it, but I think we should
>> in the timeline of GSoC.
>> And there have rule of GSoC, but I cannot sure you have read all of the
>> content which I leaved.
>> I think if will not so rush to finish t
>
> 21 Mar 2021, 17:01, Steven Liu
>
Yes, that is ok if you want, and other students can post their code too.
> I think I need clarify that you have half chance for the qualification.
> And I have not seen your name on the dashboard, of course I have not seen
> this project on the dashboard too no
> 2021年3月21日 下午8:00，Piyush Chauhan 写道：
>
>>
>> 21 Mar 2021, 17:01, Steven Liu
>>
> Yes, that is ok if you want, and other students can post their code too.
>> I think I need clarify that you have half chance for the qualification.
>> And I have not seen your name on the dashboard, of course
> 2021年3月21日 下午8:07，Steven Liu 写道：
>
>>
>> 2021年3月21日 下午8:00，Piyush Chauhan 写道：
>>
>>>
>>> 21 Mar 2021, 17:01, Steven Liu
>>>
>> Yes, that is ok if you want, and other students can post their code too.
>>> I think I need clarify that you have half chance for the qualification.
>>> And I h
Quoting James Almer (2021-03-05 17:32:52)
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 7da2f3d98e..783cc1b591 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -954,7 +954,11 @@ typedef struct AVStream {
> * decoding: set by libavformat, must
This was previously incorrect, so that passing only id_fov or d_fov
resulted in incorrect transformation.
Signed-off-by: Daniel Playfair Cal
---
libavfilter/vf_v360.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index 944
This changes the iflat_range and flat_range values for the fisheye
projection to match their meaning for the flat/rectilinear projection.
That is, the range is between the two x or two y coordinates of the
outermost points above/below or left/right of the center, in the
flat/rectilinear projection.
Previously the visibility test referred to a circle in the input. This
changes it so that it refers accurately to the entire area in the input.
Signed-off-by: Daniel Playfair Cal
---
libavfilter/vf_v360.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_v360.c b
This resulted in the default aspect ratio being doubled relative to most
input formats like flat/rectilinear. After this patch the default aspect
ratio is the same as a rectilinear input.
Signed-off-by: Daniel Playfair Cal
---
libavfilter/vf_v360.c | 4 ++--
1 file changed, 2 insertions(+), 2 de
Sure, I've done so. I'm pretty new to sending patches by email so sorry if
it's a bit messy!
On Sun, Mar 21, 2021 at 8:14 PM Paul B Mahol wrote:
> Please make log message consistent with other commits to this file.
>
> Also make set of patches to be applied all at once instead each single one.
>
On Sun, Mar 21, 2021 at 4:33 PM Carl Eugen Hoyos wrote:
> Am So., 21. März 2021 um 06:13 Uhr schrieb Nuo Mi :
> >
> > Magic number 124 and ^= are not listed on the spec.
> > Strictly following the spec will make a reader's life much easier. See
> (9-6) for details
>
> But FFmpeg is not providing
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:32:52)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -954,7 +954,11 @@ typedef struct AVStream {
*
Quoting James Almer (2021-03-21 14:54:22)
> On 3/21/2021 9:28 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-03-05 17:32:52)
> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> index 7da2f3d98e..783cc1b591 100644
> >> --- a/libavformat/avformat.h
> >> +++ b/libavformat/av
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:32:52)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..783cc1b591 100644
--- a/libavformat/avformat
Quoting James Almer (2021-03-21 15:24:35)
> On 3/21/2021 11:16 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-03-21 14:54:22)
> >> On 3/21/2021 9:28 AM, Anton Khirnov wrote:
> >>> Quoting James Almer (2021-03-05 17:32:52)
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>
On 18/03/2021 16:14, Derek Buitenhuis wrote:
> When extended atom size support was added to probing in
> fec4a2d232d7ebf6d1084fb568d4d84844f25abc, the buffer
> size check was backwards, but probing continued to work
> because there was no minimum size check yet, so despite
> size being 1 on these a
Sorry, but I cannot apply this set as is, It makes at least one serious
regression.
For example try this filtergraph:
v360=input=e:output=fisheye:h_fov=180:v_fov=180,v360=input=fisheye:output=e:ih_fov=180:iv_fov=180
On Sun, Mar 21, 2021 at 1:45 PM Daniel Playfair Cal <
daniel.playfair@gmail.
It can be removed once the field becomes a pointer.
Signed-off-by: James Almer
---
libavformat/apetag.c | 9 -
libavformat/asfdec_f.c | 13 +++--
libavformat/asfdec_o.c | 13 +++--
libavformat/flac_picture.c | 14 --
libavformat/hls.c |
And mention how the field is not being removed but changed, with instructions
for library users to migrate their code.
Signed-off-by: James Almer
---
libavformat/avformat.h | 8
libavformat/utils.c| 4
2 files changed, 12 insertions(+)
diff --git a/libavformat/avformat.h b/lib
Hello everyone!
I'm He Yang, a college student from FuZhou University, China, now major in
Computer Science. I've been using ffmpeg for years, and I'm interested in
the
GSoC idea "Windows Screen Capture via Desktop Duplication".
I've successfully attened GSoC as a student of ReactOS last yea
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:32:52)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..
Marton Balint (12021-03-21):
> Same what I did with AVFormat->filename / AVFormat->url.
By the way, about that: at some point, we will need to clarify what part
of our API uses real URLs and what parts uses fake URLs.
Because as it is, a lot of code looks like it uses URLs but really it
does not.
On 3/21/2021 3:15 PM, Marton Balint wrote:
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:32:52)
diff --git a/libavformat/avformat.h
Nicolas George (12021-03-21):
> By the way, about that: at some point, we will need to clarify what part
> of our API uses real URLs and what parts uses fake URLs.
>
> Because as it is, a lot of code looks like it uses URLs but really it
> does not. The worst offender is "file:" it looks like an U
On 3/21/2021 2:08 PM, James Almer wrote:
diff --git a/libavformat/options.c b/libavformat/options.c
index 07403b533e..bd4056caa1 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -220,11 +220,21 @@ AVFormatContext *avformat_alloc_context(void)
av_free(ic);
retu
On 3/21/2021 3:37 PM, James Almer wrote:
On 3/21/2021 3:15 PM, Marton Balint wrote:
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:3
On 3/21/2021 3:37 PM, James Almer wrote:
On 3/21/2021 3:15 PM, Marton Balint wrote:
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:3
Andreas Rheinhardt:
> Read it directly into AVStream.attached_pic.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/apetag.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavformat/apetag.c b/libavformat/apetag.c
> index 454c6c688b..23ee6b516d 100644
> -
Andreas Rheinhardt:
> Our "get name" functions can return NULL for invalid/unknown
> arguments. So check for this.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> av_get_colorspace_name() can even return NULL for supported colorspaces.
>
> libavcodec/avcodec.c | 33 +--
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 3:37 PM, James Almer wrote:
On 3/21/2021 3:15 PM, Marton Balint wrote:
On Sun, 21 Mar 2021, James Almer wrote:
On 3/21/2021 11:16 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-21 14:54:22)
On 3/21/2021 9:28 AM, Anton Khirnov
Because the properties of frames returned from ff_get/reget_buffer
are not reset at all, lots of returned frames had palette_has_changed
wrongly set to 1. This has been changed, too.
Signed-off-by: Andreas Rheinhardt
---
Moved it to decode.h as requested.
libavcodec/8bps.c | 12 ++
I do not recommend this patch for inclusion in master.
I used this implementation to quantify the floating pointing error
introduced by my next patch, which I think is better suited for
general usage, because the it is much faster and the error is
very small.
Adds 16-bit depth compatibility to th
On Sun, Mar 21, 2021 at 3:24 PM James Almer wrote:
>
> How about adding the deprecation attribute to prompt people to read the
> doxy, where we state the field is not going away, just changing types?
> Otherwise i don't think people will notice.
I really don't like such solutions. You get warning
This filter originally quantized OpenCL float images fetchs in 256 levels,
and computed the integral image of squared differences in 32 bit integers.
This had two consequences:
1) it could overflow if the image resolution was big enough (I got overflows
in a 4K video);
2) it dropped precision from
On 3/21/2021 8:13 PM, Hendrik Leppkes wrote:
On Sun, Mar 21, 2021 at 3:24 PM James Almer wrote:
How about adding the deprecation attribute to prompt people to read the
doxy, where we state the field is not going away, just changing types?
Otherwise i don't think people will notice.
I really
Fixes decoding of https://samples.ffmpeg.org/V-codecs/KMVC/LOGO2.AVI
Signed-off-by: Andreas Rheinhardt
---
libavcodec/kmvc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index cd9e32f443..8d9f0a9693 100644
--- a/libavcodec/kmvc.c
Reduces codesize because the offset in pointer+offset addressing
requires less bytes to encode. Reduces the size of .text from 8871B
to 8146B (GCC 10, -O3, x64).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/kmvc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavc
Signed-off-by: Andreas Rheinhardt
---
libavcodec/kmvc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavcodec/kmvc.c b/libavcodec/kmvc.c
index dd1ae05f2d..56c1977254 100644
--- a/libavcodec/kmvc.c
+++ b/libavcodec/kmvc.c
@@ -345,13 +345,7 @@ static int decode_frame
I've tried that filtergraph and a few other similar ones and I'm not sure
what you mean - what exactly is the regression?
I tried it on this image with an equirectangular projection:
https://wiki.panotools.org/images/0/01/Big_ben_equirectangular.jpg
The only difference I can see is that there are
From: "Chen,Wenbin"
FFmpeg-qsv decoder reinit codec when width and height change, but there
are not only resolution change need to reinit codec. I change it to use
return value from DecodeFrameAsync() to decide whether decoder need to
be reinitialized.
Signed-off-by Wenbin Chen
---
libavcodec/
From: "Chen,Wenbin"
MSDK recognizes both yuv420p10 and yuv420p9 as MFX_FOURCC_P010, but param
are different. When decode yuv420p9 video, ffmpeg-qsv will use
yuv420p10le to configure surface which is different with param from
DecoderHeader and this will lead to error. Now change it use
param from
88d80cb97528d52dac3178cf5393d6095eca6200 changed the type of
PutBitContext.BitBuf to uint64_t; it used to be an uint32_t.
While said structure is not public, it is nevertheless used by
certain avpriv functions and therefore crosses library boundaries:
avpriv_align_put_bits and avpriv_copy_bits were
From: "Chen,Wenbin"
ChromaForamt for mjpeg-qsv is always set to yuv420, and this will be
wrong when encode other pixel format (for example yuyv422). I change
this assignment to be adaptive to pix_fmt.
Signed-off-by: Wenbin Chen
---
libavcodec/qsvenc.c | 3 ++-
1 file changed, 2 insertions(+),
From: "Chen,Wenbin"
qsvvpp align the width and height with 16, and that may lead to error.
For example, when we use qsvvpp to resize frame to 1080p, qsvvpp will
align frame to 1088 which is different from the height of
encoder (1080) and this will be treated as resolution change. Now I
assign th
On Wednesday, January 20, 2021 09:48 GMT, "Raghavendra Rao Sidlagatta"
wrote:
On Tuesday, October 06, 2020 08:18 BST, raghavendra
wrote:
Print the SRT streamid at the client.
Logged to info.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 9 +
1 file changed, 9 insertions(+)
On Mon, Mar 22, 2021 at 5:09 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> I've tried that filtergraph and a few other similar ones and I'm not sure
> what you mean - what exactly is the regression?
>
> I tried it on this image with an equirectangular projection:
> https://wiki.
71 matches
Mail list logo
