Hello here!
A simple ping about this patch
If you have any question, feel free to ask!
Regards,
Olivier
On Wed, Jun 19, 2019 at 3:38 PM Olivier Maignial
wrote:
> === PROBLEM ===
>
> I was trying to record h264 + aac streams from an RTSP server to mp4 file.
> using this command line:
> ffmp
> 在 2019年6月28日,上午4:36,Bodecs Bela 写道:
>
> 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
> -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 a/li
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 8dbad71..9bf85
> 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, Jun
> -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
>
> 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. Jun
> -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 Y210/AY
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 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
> -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: ffmpeg-de
> -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
>
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 insertions(+)
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 pa
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 a/lib
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, and
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 VAAP
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 peak_table(in
> 在 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
> 在 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 is
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
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
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 dec
---
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)
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
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 first
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;
> +
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
>
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 && !s->siz
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 be
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 m
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
__
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 1006
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 2:12
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
> 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: Lin
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
> -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 a/lib
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 VA
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 +-
libavutil/hwcontex
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 b/libavcodec/qsv
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 -hwac
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 @@ sta
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
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 e
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 ff_h264_decode_mb_cab
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,
--
>
> 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
> situatio
> 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: S
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
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 GSO
> 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 see
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
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
+++ b/liba
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 and
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 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), b
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 10
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
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 an
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,
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 w
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 remo
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 yo
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 com
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, 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 a/libav
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 unchang
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
---
doc/filte
> 在 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
>>> inde
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 +2115
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
+++ b/libavcodec/mj
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
>> --- a/libavcodec/cf
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
> @@ -136,20
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 init_video_param(AVCodecCo
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 *
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
---
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
@@ -15
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
ffmpeg-devel@ffmpeg.org
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 f
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
> https://github.com/google/oss-fuz
81 matches
Mail list logo