On Mon, Oct 29, 2018 at 11:29 AM Ruiling Song
wrote:
> Signed-off-by: Ruiling Song
> ---
> doc/filters.texi | 96
>
> 1 file changed, 96 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 83df460..f884ba4 100644
>
On Mon, Oct 29, 2018 at 10:50 AM Ruiling Song
wrote:
> Signed-off-by: Danil Iashchenko
> Signed-off-by: Ruiling Song
> ---
> Seems like Danil is not working on this recently.
> So I re-submit this patch to address the comment over overlay_opencl.
>
Looks good for a push now. I'll make any chan
On Mon, Oct 29, 2018 at 10:58 PM James Zern wrote:
>
> On Sat, Oct 27, 2018 at 1:54 PM James Almer wrote:
> >
> > On 10/27/2018 5:52 PM, James Zern wrote:
> > > a thread count of 0 is treated the same as 1, use av_cpu_count() to get
> > > the correct thread count when auto threads is requested.
>
On Sat, Oct 27, 2018 at 1:54 PM James Almer wrote:
>
> On 10/27/2018 5:52 PM, James Zern wrote:
> > a thread count of 0 is treated the same as 1, use av_cpu_count() to get
> > the correct thread count when auto threads is requested.
> >
> > this matches the fix in libvpxenc:
> > 27df34bf1f avcodec
On Tue, Oct 30, 2018 at 11:41 AM Eoff, Ullysses A
wrote:
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:[email protected]] On Behalf Of
> > [email protected]
> > Sent: Monday, October 29, 2018 8:10 PM
> > To: FFmpeg development discussions and patches
> > Cc: Zhao,
fix slice number check logic.
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 2fe8501..bf8f37b 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi
> -Original Message-
> From: ffmpeg-devel [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Monday, October 29, 2018 8:10 PM
> To: FFmpeg development discussions and patches
> Cc: Zhao, Jun ; Lin, Decai
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: f
Liu Steven 于2018年10月16日周二 上午11:17写道：
>
>
>
> > 在 2018年10月11日，下午4:56，Charles Liu 写道：
> >
> > In fmp4 & sub-range mode, the output's duration always smaller than
> > expected, because the size of the last #EXT-X-BYTERANGE is too small.
> >
> > Signed-off-by: Charles Liu
> > ---
> > libavformat/hl
On Tue, Oct 30, 2018 at 10:41 AM Li, Zhong wrote:
>
> > From: ffmpeg-devel [mailto:[email protected]] On Behalf
> > Of [email protected]
> > Sent: Tuesday, October 30, 2018 9:02 AM
> > To: FFmpeg development discussions and patches
> >
> > Cc: Zhao, Jun ; Lin, Decai
> > Subject: Re:
> From: ffmpeg-devel [mailto:[email protected]] On Behalf
> Of [email protected]
> Sent: Tuesday, October 30, 2018 9:02 AM
> To: FFmpeg development discussions and patches
>
> Cc: Zhao, Jun ; Lin, Decai
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> decoding
On Tue, Oct 30, 2018 at 9:50 AM Carl Eugen Hoyos wrote:
>
> 2018-10-29 11:26 GMT+01:00, Jun Zhao :
> > From: Jun Zhao
> >
> > Now VA-API HWAccel MJPEG decoding uninitialized huffman
> > table, it's will lead to the decoding error like"Failed to sync surface
> > 0x5: 23 (internal decoding error)."
If a http resource is not streamed, it can seek to the end of this resouce.
I add the detail information at https://trac.ffmpeg.org/ticket/6885
Fixes ticket #6885.
Signed-off-by: shenqichao
---
libavformat/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/h
2018-10-29 11:26 GMT+01:00, Jun Zhao :
> From: Jun Zhao
>
> Now VA-API HWAccel MJPEG decoding uninitialized huffman
> table, it's will lead to the decoding error like"Failed to sync surface
> 0x5: 23 (internal decoding error)." in iHD open source driver.
This sounds as if the issue you want to fi
2018-10-29 10:42 GMT+01:00, shenqichao :
> Signed-off-by: shenqichao
The first line of the commit message should not be too long
(<80 chars?), then there should be an empty line, then more
info if useful (like the ticket number).
Your commit message is only one line, but too long.
Carl Eugen
___
On Mon, Oct 29, 2018 at 6:39 PM Li, Zhong wrote:
>
> > From: ffmpeg-devel [mailto:[email protected]] On Behalf
> > Of Jun Zhao
> > Sent: Monday, October 29, 2018 6:26 PM
> > To: [email protected]
> > Cc: Zhao, Jun ; Lin, Decai
> > Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec:
On Mon, Oct 29, 2018 at 11:20 PM Michael Niedermayer
wrote:
>
> On Sun, Oct 28, 2018 at 11:05:47AM +0800, Jun Zhao wrote:
> > Add error handle if av_image_fill_pointers fail.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavutil/frame.c | 10 ++
> > 1 files changed, 6 insertions(+), 4
> On Fri, Oct 26, 2018 at 4:00 PM James Almer wrote:
>
>> On 10/26/2018 7:50 PM, Dale Curtis wrote:
>>> One more piece of feedback, this is not obeying the
>>> AVCodecContext.get_buffer2 API.
>>
>> It's not using it on purpose, wrapping the buffers dav1d allocated
>> itself instead. Hence the lac
On 10/29/2018 7:33 PM, Chris Cunningham wrote:
> Thanks for pushing the profile part. Turns out I'm also interested in
> pixel format, but I follow your comments about dropping the rest of
> patch. With the code as-is, how busted are we when parsing a super
> frame. Does it correctly grab the profi
Thanks for pushing the profile part. Turns out I'm also interested in pixel
format, but I follow your comments about dropping the rest of patch. With
the code as-is, how busted are we when parsing a super frame. Does it
correctly grab the profile of the first frame?
Chrome actually has a fairly co
From: "Ronald S. Bultje"
Originally written by Ronald S. Bultje, with fixes, optimizations and
improvements by James Almer.
Signed-off-by: James Almer
---
- s.n_frame_threads is now mapped to avctx->thread_count.
- colorspace, color_primaries and color_trc are now cast to avutil enums to
sile
Hi Mark,
see my comments bellow.
вт, 30 окт. 2018 г. в 0:23, Mark Thompson :
> On 29/10/18 11:45, Alexander Kravchenko wrote:
> > Hi, Mark.
> > Thanks for review.
> > Could you please check the following comments/questions?
> >
> >> +
> >>> +static const AVClass amflib_class = {
> >>> +.class
On Mon, 2018-10-29 at 21:34 +, Mark Thompson wrote:
> On 29/10/18 21:29, Rogozhkin, Dmitry V wrote:
> > On Mon, 2018-10-29 at 21:06 +, Mark Thompson wrote:
> > > On 25/10/18 13:36, Zhong Li wrote:
> > > > This option can be used to repect original input I/IDR frame
> > > > type.
> > > >
>
On 29/10/18 21:29, Rogozhkin, Dmitry V wrote:
> On Mon, 2018-10-29 at 21:06 +, Mark Thompson wrote:
>> On 25/10/18 13:36, Zhong Li wrote:
>>> This option can be used to repect original input I/IDR frame type.
>>>
>>> Signed-off-by: Zhong Li
>>> ---
>>> libavcodec/qsvenc.c | 7 +++
>>> lib
On Mon, 2018-10-29 at 21:06 +, Mark Thompson wrote:
> On 25/10/18 13:36, Zhong Li wrote:
> > This option can be used to repect original input I/IDR frame type.
> >
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/qsvenc.c | 7 +++
> > libavcodec/qsvenc.h | 2 ++
> > 2 files changed, 9
On Mon, 2018-10-29 at 20:54 +, Derek Buitenhuis wrote:
> On 29/10/2018 20:51, Rogozhkin, Dmitry V wrote:
> > Should not the option be named 'force_idr' as well? It makes better
> > sense to me in that way...
>
> That would be inconsistent with the rest of the options for various
> encoders
> i
On 29/10/18 11:45, Alexander Kravchenko wrote:
> Hi, Mark.
> Thanks for review.
> Could you please check the following comments/questions?
>
>> +
>>> +static const AVClass amflib_class = {
>>> +.class_name = "amf",
>>> +.item_name = av_default_item_name,
>>> +.version = LIBAVUTIL_VERSI
On 10/29/18, Carl Eugen Hoyos wrote:
> 2018-10-29 10:27 GMT+01:00, Paweł Wegner :
>
>> + --enable-mf enable decoding via MediaFoundation [no]
>
> Should be auto-detected.
Why? I do not want this to be auto-enabled on my Windows builds.
___
2018-10-29 10:27 GMT+01:00, Paweł Wegner :
> + --enable-mf enable decoding via MediaFoundation [no]
Should be auto-detected.
Carl Eugen
___
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2018-10-29 15:49 GMT+01:00, [email protected] :
> while(1) {
> uint16_t size = 0;
> -ssize_t ret = fread(&size, 1, sizeof(uint16_t), fd);
> -if (ret < 0) {
> -perror("Couldn't read size");
> -exit(1);
> -} else if (ret != sizeof(uin
Hi!
Attached untested patch is supposed to fix ticket #7521.
Please comment, Carl Eugen
From ad5a9de93a8cfe261636993532246befddea984d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 29 Oct 2018 22:11:54 +0100
Subject: [PATCH] tests/api-h264-slice-test: fread returns size_t, not
ssize
On Mon, 29 Oct 2018, Derek Buitenhuis wrote:
On 25/10/2018 13:58, Martin Storsjö wrote:
+x4->nb_reordered_opaque = x264_encoder_maximum_delayed_frames(x4->enc) + 1;
Is it possible this changes when the encoder is reconfigured (e.g. to
interlaced)?
Good point. I'm sure it's possible tha
On Thu, 2018-10-25 at 20:36 +0800, Zhong Li wrote:
> This option can be used to repect original input I/IDR frame type.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 7 +++
> libavcodec/qsvenc.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c b/li
On 25/10/18 13:36, Zhong Li wrote:
> This option can be used to repect original input I/IDR frame type.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 7 +++
> libavcodec/qsvenc.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.
On 29/10/2018 20:51, Rogozhkin, Dmitry V wrote:
> Should not the option be named 'force_idr' as well? It makes better
> sense to me in that way...
That would be inconsistent with the rest of the options for various encoders
in FFmpeg, all named forced_idr.
- Derek
On Fri, 2018-10-26 at 13:46 +0200, Moritz Barsnick wrote:
> On Thu, Oct 25, 2018 at 20:36:07 +0800, Zhong Li wrote:
> > +{ "forced_idr", "Forcing I frames as IDR
> > frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_INT, {
> > .i64 = -1 }, -1, 1, VE }, \
On 25/10/2018 13:58, Martin Storsjö wrote:
> +x4->nb_reordered_opaque = x264_encoder_maximum_delayed_frames(x4->enc) +
> 1;
Is it possible this changes when the encoder is reconfigured (e.g. to
interlaced)?
- Derek
___
ffmpeg-devel mailing list
ff
On 29/10/2018 20:10, Martin Storsjö wrote:
> Sorry, I think you've misunderstood this patch altogether.
>
> It's not about reviving this field or not, it's all in full use
> already. It was never deprecated with any active plan to remove it, the
> only steps were a few doxygen comments, never any
On Sat, Oct 20, 2018 at 12:42:35PM +0200, Michael Niedermayer wrote:
> Hi
>
> 2 alternative patchsets are attached to fix $SUBJ
>
> The 2 alternatives should behave similar.
>
> The first adds a function to check if the next range coder symbol read would
> trigger the end of input case.
> We the
On Mon, 29 Oct 2018, Derek Buitenhuis wrote:
On 29/10/2018 14:10, Martin Storsjö wrote:
I don't understand why this is being used in favour of a proper
pointer field? An integer field is just ascting to be misused.
Even the doxygen is really sketchy on it.
It's essentially meant to be used as
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_graphmonitor.c | 417 +++
3 files changed, 421 insertions(+)
create mode 100644 libavfilter/f_graphmonitor.c
diff --git a/libavfilter/Makefil
On Sun, Oct 28, 2018 at 11:15:08AM -0300, James Almer wrote:
> On 10/28/2018 11:04 AM, Michael Niedermayer wrote:
> > Fixes: Timeout (139sec -> 102sec)
> > Fixes:
> > 9642/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-6676767875006464
> >
> > Found-by: continuous fuzzing process
>
On Sun, Oct 28, 2018 at 11:05:47AM +0800, Jun Zhao wrote:
> Add error handle if av_image_fill_pointers fail.
>
> Signed-off-by: Jun Zhao
> ---
> libavutil/frame.c | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128
On Sun, Oct 28, 2018 at 11:09:58PM +0200, Martin Storsjö wrote:
> ---
> Removed the option and made this behaviour the default.
> ---
> libavformat/flv.h| 1 +
> libavformat/flvdec.c | 18 ++
> 2 files changed, 15 insertions(+), 4 deletions(-)
should be ok
thanks
[...]
--
On 29/10/2018 14:10, Martin Storsjö wrote:
>> I don't understand why this is being used in favour of a proper
>> pointer field? An integer field is just ascting to be misused.
>> Even the doxygen is really sketchy on it.
>
> It's essentially meant to be used as union { ptr; int64_t } assuming you
From: Josh de Kock
---
tests/api/api-h264-slice-test.c | 85 +++--
1 file changed, 48 insertions(+), 37 deletions(-)
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
index 57e7dc79c3..b3f9f91ab3 100644
--- a/tests/api/api-h264-slice-test
On 10/29/2018 10:57 AM, [email protected] wrote:
> From: Josh de Kock
>
> ---
> tests/api/api-h264-slice-test.c | 74 +++--
> 1 file changed, 43 insertions(+), 31 deletions(-)
>
> diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
> in
On Mon, 29 Oct 2018, Derek Buitenhuis wrote:
On 25/10/2018 13:58, Martin Storsjö wrote:
This was marked as deprecated (but only in the doxygen, not with an
actual deprecation attribute) in 81c623fae05 in 2011, but was
undeprecated in ad1ee5fa7.
---
libavutil/frame.h | 1 -
libavutil/versio
From: Josh de Kock
---
tests/api/api-h264-slice-test.c | 74 +++--
1 file changed, 43 insertions(+), 31 deletions(-)
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
index 57e7dc79c3..08d5d57941 100644
--- a/tests/api/api-h264-slice-test
On 25/10/2018 13:58, Martin Storsjö wrote:
> This was marked as deprecated (but only in the doxygen, not with an
> actual deprecation attribute) in 81c623fae05 in 2011, but was
> undeprecated in ad1ee5fa7.
> ---
> libavutil/frame.h | 1 -
> libavutil/version.h | 2 +-
> 2 files changed, 1 ins
This looks like a (strange) hack to me.
First, you cannot just throw some pids out - that will make a non-standard
compliant stream. PMT will signal missing streams; PCR pid will be missing
also. So let's assume that your tool can also rewrite PMT.
Secondly, there is supposed to be one and only one
Signed-off-by: Anton Platov
---
doc/indevs.texi | 17 +
libavdevice/libndi_newtek_dec.c | 4 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 9a9cb69..c75c4b1 100644
--- a/doc/indevs.texi
+++ b/doc
Hi, Mark.
Thanks for review.
Could you please check the following comments/questions?
> +
> > +static const AVClass amflib_class = {
> > +.class_name = "amf",
> > +.item_name = av_default_item_name,
> > +.version = LIBAVUTIL_VERSION_INT,
> > +};
>
> This class shouldn't be needed - the
> From: ffmpeg-devel [mailto:[email protected]] On Behalf
> Of Jun Zhao
> Sent: Monday, October 29, 2018 6:26 PM
> To: [email protected]
> Cc: Zhao, Jun ; Lin, Decai
> Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding
> uninitialized huffman table
>
> Fr
From: Jun Zhao
Now VA-API HWAccel MJPEG decoding uninitialized huffman table, it's
will lead to the decoding error like"Failed to sync surface 0x5: 23
(internal decoding error)." in iHD open source driver.
Signed-off-by: dlin2
Signed-off-by: Jun Zhao
---
libavcodec/mjpegdec.c | 19 +
Signed-off-by: shenqichao
---
libavformat/http.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 3a35bc7eac..9401a5c63e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1669,7 +1669,7 @@ static int64_t http_seek_interna
Thanks for the tip; I took Media Foundation support from PLEX's FFmpeg fork.
The newer patch revision contains hw decoding through Media Foundation.
Paweł Wegner (1):
avcodec/mf: implemented Media Foundation wrapper
configure | 48 +-
fftools/Makefile |
> -Original Message-
> From: ffmpeg-devel [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Monday, October 29, 2018 9:58 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V2] libavfilter/vaapi: enable vaapi
> rotation
57 matches
Mail list logo
