This commit fixes mixed declarations and code introduced in 1889e316.
Signed-off-by: Andreas Rheinhardt
---
Sorry for the oversight.
libavformat/mux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 5e1ecd8485..21f10caf53
On Thu, 27 Jun 2019, Andreas Håkon wrote:
Hi Reimar,
Minor note: I'd suggest a different name, "delayer" is too easily read as e.g.
"de-layer".
Could be something like add_delay for example.
Good point! Or perhaps "timer" will be preferable. Ideas?
Maybe it's too much work for little
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
> +/* return the 8 bit start code value and update the search
> + state. Return -1 if no start code found */
> +static int find_frame_header_marker(const uint8_t **pbuf_ptr, const uint8_t
> *buf_end)
> +{
> +const uint8_t *buf_ptr;
> +
Signed-off-by: Cameron Cawley
---
doc/general.texi| 1 +
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 14 ++
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/utils.c | 1 +
7 files changed, 26
---
libavformat/rpl.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index dbbcd13b41..b4859320f4 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -121,6 +121,7 @@ static int rpl_read_header(AVFormatContext *s)
On 27.06.2019, at 17:35, Vittorio Giovara wrote:
> On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote:
>
>> Kieran Kunhya (12019-06-27):
>>> I'm happy to do it now that I am aware of the issue. I will do it when I
>> am
>>> at home in a few days.
>>
>> Thanks. I am sure Steven will not mind
Hi Reimar,
> Minor note: I'd suggest a different name, "delayer" is too easily read as
> e.g. "de-layer".
> Could be something like add_delay for example.
Good point! Or perhaps "timer" will be preferable. Ideas?
Regards.
A.H.
---
___
ffmpeg-devel
Am Do., 27. Juni 2019 um 16:28 Uhr schrieb Linjie Fu :
>
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image
> is produced in packed format.
(The question "why" and the answer "because Windows expects it"
come to
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
> -if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt && !size_change) {
> +if (!(s->got_picture && s->interlaced && (s->bottom_field ==
> !s->interlace_polarity))) {
> +if (s->avctx->pix_fmt == s->hwaccel_sw_pix_fmt &&
Am Do., 27. Juni 2019 um 14:59 Uhr schrieb Zhong Li :
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/mjpeg_parser.c | 158
> +-
> 1 file changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
>
ping
2019.06.24. 18:01 keltezéssel, Bodecs Bela írta:
Dear All,
currently master playlist and subtitle playlist creation does not use
temporary files even when temp_file flag is set. Most of the use cases
it is not a problem because master playlist creation happens once on the
beginning of the
Am Do., 27. Juni 2019 um 16:31 Uhr schrieb Linjie Fu :
>
> Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
>
> Modify to choose ChromaFormat according to fourCC.
Sorry if I misunderstand:
Doesn't 3/5 depend on this patch?
Carl Eugen
On 11/25/18, Paul B Mahol wrote:
> On 7/4/18, Baptiste Coudurier wrote:
>> ---
>> libavformat/sccdec.c | 100 ---
>> 1 file changed, 56 insertions(+), 44 deletions(-)
>>
>
> Will those scc patches be applied?
>
This one breaks FATE.
Forcing positive
On Thu, Jun 27, 2019 at 10:26:46PM -0400, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> produced in packed format.
>
> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext
On 6/27/2019 10:44 AM, Nicolas George wrote:
> Kieran Kunhya (12019-06-27):
>> I'm happy to do it now that I am aware of the issue. I will do it when I am
>> at home in a few days.
>
> Thanks. I am sure Steven will not mind waiting a few days.
>
>> This absolutism is absurd.
>
> Do you have an
On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote:
> Kieran Kunhya (12019-06-27):
> > I'm happy to do it now that I am aware of the issue. I will do it when I
> am
> > at home in a few days.
>
> Thanks. I am sure Steven will not mind waiting a few days.
>
> > This absolutism is absurd.
>
> Do
On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote:
>
> On 6/26/19 4:37 PM, Michael Niedermayer wrote:
> >On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote:
> >>On 6/26/19, Michael Niedermayer wrote:
> >>>On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote:
> On 6/25/19
>
> If it is so easy, you could do it instead of arguing. If it is not so
> easy, you cannot demand somebody do it.
>
I'm happy to do it now that I am aware of the issue. I will do it when I am
at home in a few days.
> > It is beyond comprehension how removing more code and making the
>
Kieran Kunhya (12019-06-27):
> I'm happy to do it now that I am aware of the issue. I will do it when I am
> at home in a few days.
Thanks. I am sure Steven will not mind waiting a few days.
> This absolutism is absurd.
Do you have an example of situation where dead code is good?
Regards,
--
Add support for YUV422P/YUV422P10, YUV444P/YUV444P10 in qsv_map_pixfmt.
Allow qsv to choose correct fourc from format.
Add support for YUYV422/Y210/AYUV/Y410 to map frame to surface and
allowed hwdownload.
HEVC Rext decode is supported on ICL+ platform.
Cmdline for 444 8 bit decode:
ffmpeg
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Thursday, June 27, 2019 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] lavu/pixfmt: add Y210/AYUV/Y410
> pixel formats
>
> > diff --git
On 6/27/2019 3:01 AM, Adrian Tong wrote:
> Anyone interested in reviewing this patch ?
>
> Thanks
> -Adrian
>
> On Mon, 24 Jun 2019 at 13:57, wrote:
>
>> From: Adrian Tong
>>
>> On internal benchmark, I see a noisy-level difference (more likely to be
>> an improvement) in
Previously, media driver provided planar format(like 420 8 bit), but
for HEVC Range Extension (422/444 8/10 bit), the decoded image is
produced in packed format.
Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
for both VAAPI and QSV:
- Y210: 422 10 BIT
- AYUV: 444
Signed-off-by: Linjie Fu
---
libavutil/hwcontext_vaapi.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4227c3c..6378d0e 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -116,6 +116,14 @@
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Friday, June 28, 2019 10:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
>
> Signed-off-by:
Currently, Info.Shift in libmfx is set according to the depth of the
pixfmt. As QSV now supports Y410 (depth > 8 but shift = 0), it doesn't
work any more.
Modify to set Info.Shift according to the setting in desc.
Signed-off-by: Linjie Fu
---
libavcodec/qsvdec.c | 2 +-
Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
Modify to choose ChromaFormat according to fourCC.
Signed-off-by: Linjie Fu
---
libavcodec/qsvdec.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsvdec.c
On 6/27/2019 11:26 PM, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> produced in packed format.
>
> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
> for both
> 在 2019年6月28日，04:36，Bodecs Bela 写道：
>
> ping
Wait, i’m testing it.
>
> 2019.06.24. 18:01 keltezéssel, Bodecs Bela írta:
>> Dear All,
>>
>> currently master playlist and subtitle playlist creation does not use
>> temporary files even when temp_file flag is set. Most of the use cases
>> it
On 6/27/2019 2:47 PM, Andreas Rheinhardt wrote:
> This commit fixes mixed declarations and code introduced in 1889e316.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for the oversight.
>
> libavformat/mux.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
On Fri, Jun 28, 2019 at 1:26 AM James Darnley wrote:
>
> On 2019-06-28 04:26, Linjie Fu wrote:
> > Previously, media driver provided planar format(like 420 8 bit), but
> > for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> > produced in packed format.
> >
> > Y210/AYUV/Y410 are
Hi all:
Add an option to split the rest of stream after the segment_times is set.
It's very useful to set the first some segments to a little small, and then
split with a clear duration.
Signed-off-by: hectorqin
---
doc/muxers.texi | 5 +
libavformat/segment.c | 21
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Linjie Fu
> Sent: Friday, June 28, 2019 10:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..1e2ab28dfb 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,6 +136,11 @@ static inline void
On 2019-06-28 04:26, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit), but
> for HEVC Range Extension (422/444 8/10 bit), the decoded image is
> produced in packed format.
>
> Y210/AYUV/Y410 are packed formats which are needed in HEVC Rext decoding
> for both
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 09:09
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
On Thu, Jun 27, 2019 at 4:31 PM Linjie Fu wrote:
>
> Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
>
> Modify to choose ChromaFormat according to fourCC.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvdec.c | 20 +++-
> 1 file changed, 19
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, June 27, 2019 20:32
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, June 28, 2019 02:43
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> 在 2019年6月28日，04:25，Reimar Döffinger 写道：
>
> On 27.06.2019, at 17:35, Vittorio Giovara wrote:
>
>> On Thu, Jun 27, 2019 at 9:44 AM Nicolas George wrote:
>>
>>> Kieran Kunhya (12019-06-27):
I'm happy to do it now that I am aware of the issue. I will do it when I
>>> am
at home in
> -Original Message-
> From: Li, Zhong
> Sent: Thursday, June 27, 2019 23:41
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
>
> > From:
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, June 28, 2019 2:56 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function
> ff_mjpeg_decode_header
>
> Am Do., 27.
On Thu, Jun 27, 2019 at 1:56 PM Linjie Fu wrote:
>
> Currently in ff_thread_decode_frame, context is updated from child thread
> to user thread, and user thread releases the context in avcodec_close()
> when decode finishes.
>
> However, when resolution/format changes, ff_get_format is called,
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 9:09 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> support for YUV422/YUV444
>
> On Thu,
Reported-by：Maggie Sun
Signed-off-by: Zhong Li
---
V2: bump an new micro version since it changes the API usage.
libavcodec/qsvenc.c | 2 +-
libavcodec/version.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index
> -Original Message-
> From: Zhou, Zachary
> Sent: Friday, June 28, 2019 11:33
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
> > diff --git
Nicolas George:
> Paul B Mahol (12019-06-27):
>> No, code is not dead and should be kept, ask maintainer for confirmation.
>
> The compiler says it is. I am sorry, but your statement without any
> proof seems less reliable than the diagnostics of the compiler and
> Steven's judgement.
>
> As is,
Currently in ff_thread_decode_frame, context is updated from child thread
to user thread, and user thread releases the context in avcodec_close()
when decode finishes.
However, when resolution/format changes, ff_get_format is called, and
hwaccel_uninit() and hwaccel_init will be used to destroy
Signed-off-by: Zhong Li
---
libavcodec/mjpeg_parser.c | 158 +-
1 file changed, 157 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
index 07a6b2b..f59aa3e 100644
--- a/libavcodec/mjpeg_parser.c
+++
It will be reused in the following mjpeg_parser patch
Signed-off-by: Zhong Li
---
Mark Thompson: This seems suspicious - MJPEG is generally 4:2:2 (e.g. UVC
requires it), so I would expect a 4:2:2 format to be the default here? (Or
maybe a longer list - VAAPI certainly supports 4:2:2, 4:2:0
Liu Steven (12019-06-27):
> I remove it because i cannot found the caller for this API.
> I think there should have one caller for this API, It will not be used if
> there have no caller, Isn’t it?
I suppose you built the code and the compiler did not complain.
I see no reason to keep dead code
On 6/27/19, Paul B Mahol wrote:
> On 6/27/19, Nicolas George wrote:
>> Liu Steven (12019-06-27):
>>> I remove it because i cannot found the caller for this API.
>>> I think there should have one caller for this API, It will not be used
>>> if
>>> there have no caller, Isn’t it?
>>
>> I suppose
> 在 2019年6月27日，下午4:37，Paul B Mahol 写道：
>
> On 6/27/19, Paul B Mahol wrote:
>> On 6/27/19, Steven Liu wrote:
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavcodec/cfhd.c | 14 --
>>> 1 file changed, 14 deletions(-)
>>>
>>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>>>
On Thu, Jun 27, 2019 at 09:40:22AM +0200, Moritz Barsnick wrote:
> On Thu, Jun 27, 2019 at 10:12:35 +0800, lance.lmw...@gmail.com wrote:
> > +This filter takes in two video input, the first input is considered
> ^ inputs
> > +the "main" source and is passed
Am Do., 27. Juni 2019 um 13:56 Uhr schrieb Linjie Fu :
> libavcodec/internal.h | 7 +++
> libavcodec/pthread_frame.c | 21 ++---
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 5096ffa..a85
On Thu, 27 Jun 2019 at 20:01, Nicolas George wrote:
> Andreas Rheinhardt (12019-06-27):
> > The code is indeed dead atm. To quote myself from ticket 7886:
> > "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for
> > alpha channel decoding in Cineform HD (thereby fixing #6265),
> From: Li, Zhong
> Sent: Thursday, June 27, 2019 8:59 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header
>
> It will be reused in the following mjpeg_parser patch
>
> Signed-off-by: Zhong Li
> ---
> Mark Thompson: This
On 6/27/19, Paul B Mahol wrote:
> On 6/27/19, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> libavcodec/cfhd.c | 14 --
>> 1 file changed, 14 deletions(-)
>>
>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>> index 846d334b9b..616f5af193 100644
>> ---
On 6/27/19, Liu Steven wrote:
>
>
>> 在 2019年6月27日，下午4:37，Paul B Mahol 写道：
>>
>> On 6/27/19, Paul B Mahol wrote:
>>> On 6/27/19, Steven Liu wrote:
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 14 --
1 file changed, 14 deletions(-)
diff --git
Andreas Rheinhardt (12019-06-27):
> The code is indeed dead atm. To quote myself from ticket 7886:
> "Commit c64c97b972c7325a71440a352a7d541a8c92b2da has added support for
> alpha channel decoding in Cineform HD (thereby fixing #6265), but
> commit 9cefb9e7ec508900ba147e6977590f03456aa15c broke it
Kieran Kunhya (12019-06-27):
> Why can this not be fixed properly?
It can. If you have time and motivation to do it, please go ahead.
Barring that, removing dead code is still an improvement.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
On 6/27/19, Nicolas George wrote:
> Liu Steven (12019-06-27):
>> I remove it because i cannot found the caller for this API.
>> I think there should have one caller for this API, It will not be used if
>> there have no caller, Isn’t it?
>
> I suppose you built the code and the compiler did not
On 27/06/2019 05:16, Steven Liu wrote:
> LGTM
>
Pushed. Thanks!
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Steven Liu
> Sent: Thursday, June 27, 2019 3:38 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Steven Liu
> Subject: [FFmpeg-devel] [PATCH 3/3] avutil/hwcontext_vaapi: move
> kernel_driver into CONFIG_LIBDRM
>
> Signed-off-by:
On 6/27/19, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> libavcodec/cfhd.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 846d334b9b..616f5af193 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@
From: Limin Wang
Please using the below command for the testing:
./ffmpeg -i input.ts -i ref.png -filter_complex
find_rect,cover_rect=cover.jpg:mode=cover output.ts
I have updated the help document for the function change.
Reviewed-by: Moritz Barsnick
Signed-off-by: Limin Wang
---
Paul B Mahol (12019-06-27):
> No, code is not dead and should be kept, ask maintainer for confirmation.
The compiler says it is. I am sorry, but your statement without any
proof seems less reliable than the diagnostics of the compiler and
Steven's judgement.
As is, the code can and should be
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 8dbad71..9bf8574 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -577,7 +577,7 @@ static int
Signed-off-by: Zhong Li
---
libavcodec/mjpegdec.c | 450 +-
1 file changed, 225 insertions(+), 225 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1030861..a65bc8d 100644
--- a/libavcodec/mjpegdec.c
+++
Make it easier to read.
Signed-off-by: Zhong Li
---
libavcodec/mjpegdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 20eeb96..1030861 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2115,7
Only baseline profile and NV12 output format supported right now.
---
Changelog | 1 +
configure | 2 ++
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 2 ++
libavcodec/qsvdec.c | 2 ++
libavcodec/qsvdec.h
On Thu, 27 Jun 2019 at 20:52, Nicolas George wrote:
> Kieran Kunhya (12019-06-27):
> > Why can this not be fixed properly?
>
> It can. If you have time and motivation to do it, please go ahead.
> Barring that, removing dead code is still an improvement.
>
> Regards,
>
It's not dead code, the
Kieran Kunhya (12019-06-27):
> It's not dead code,
Right now, yes, it is dead.
> the GSOC student last year removed the call to the
> function by accident.
If it is so easy, you could do it instead of arguing. If it is not so
easy, you cannot demand somebody do it.
> It is beyond comprehension
The previous calculation code did not account for the fact that the
copy_offset for the start of the frame array is at index 0, yet the
scan line number from the rfc4175 RTP header starts at 1.
This caused 2 issues to appear:
- The first scan line was being copied into the array where the second
Anyone interested in reviewing this patch ?
Thanks
-Adrian
On Mon, 24 Jun 2019 at 13:57, wrote:
> From: Adrian Tong
>
> On internal benchmark, I see a noisy-level difference (more likely to be
> an improvement) in ff_h264_decode_mb_cabac which calls this function.
> ---
>
On 6/27/19, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 61 + 2147483647 cannot be represented in
> type 'int'
> Fixes:
> 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504
>
> Found-by: continuous fuzzing process
>
On Thu, Jun 27, 2019 at 10:12:35 +0800, lance.lmw...@gmail.com wrote:
> +This filter takes in two video input, the first input is considered
^ inputs
> +the "main" source and is passed unchanged to the output. The "second"
> +input is used as a rectangular object
On Thu, Jun 27, 2019 at 09:40:22 +0200, Moritz Barsnick wrote:
> I can't just on most of the rest of your changes.
Whot?
Meant to say: I can't judge most of the rest of your changes.
M.
___
ffmpeg-devel mailing list
Signed-off-by: Steven Liu
---
libavutil/hwcontext_vaapi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 4227c3c090..cf117640f2 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@
Signed-off-by: Steven Liu
---
libavcodec/videotoolboxenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 3665581283..67faca4751 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2395,8 +2395,6
Signed-off-by: Steven Liu
---
libavcodec/cfhd.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 846d334b9b..616f5af193 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -136,20 +136,6 @@ static inline void peak_table(int16_t
81 matches
Mail list logo
