>
> 2018-06-14 9:36 GMT+02:00, Shiyou Yin :
> > From: gxw
> >
> > Optimize vp8 decoding with mmi in function:
> > 1. ff_vp8_h_loop_filter8uv_mmi.
> > 2. ff_vp8_v_loop_filter8uv_mmi.
> > 3. ff_vp8_h_loop_filter16_mmi.
> > 4. ff_vp8_v_loop_filter16_mmi.
>
> Please add some numbers about the
ons 2018-06-13 klockan 22:16 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > > Signed-off-by: Marton Balint
> > >
> > > ---
> > > libavformat/mxfdec.c | 18 ++
> > > 1 file changed, 10
Hi!
Attached patch makes debugging a little easier (ticket #7257, could
somebody who knows the concat demuxer confirm that this is unavoidable
- or isn't it? 33854 seeks with concat and five seeks with original
file input, four seeks after remuxing the input file, no matter if
file or concat
2018-06-14 9:36 GMT+02:00, Shiyou Yin :
> From: gxw
>
> Optimize vp8 decoding with mmi in function:
> 1. ff_vp8_h_loop_filter8uv_mmi.
> 2. ff_vp8_v_loop_filter8uv_mmi.
> 3. ff_vp8_h_loop_filter16_mmi.
> 4. ff_vp8_v_loop_filter16_mmi.
Please add some numbers about the speedup, overall and / or
This patch makes qt-faststart output errors to stderr instead of stdout,
following a discussion with Michael on another thread...
Thanks!
Eran
0001-qt-faststart-print-errors-to-stderr.patch
Description: 0001-qt-faststart-print-errors-to-stderr.patch
ons 2018-06-13 klockan 21:58 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > Also compute the correct essence_offset and essence_length for all clip
> > > wrapped
> > > essences.
> > >
> > > >
ons 2018-06-13 klockan 22:11 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > Also use common code with opAtom.
> > >
> > > Fixes ticket #2776.
> > > Partially fixes ticket #5671.
> > > Fixes ticket
2018-06-14 5:08 GMT+02:00, Li, Zhong :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: Wednesday, June 13, 2018 6:11 PM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [PATCH
Signed-off-by: Wang Cao
---
fftools/ffmpeg.c | 45 +++--
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d4ac6903cc..1eaf344552 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1530,17
On Thu, Jun 7, 2018 at 11:51 AM Jacob Trimble wrote:
>
> On Thu, May 31, 2018 at 5:50 PM Jacob Trimble wrote:
> >
> > On Thu, May 31, 2018 at 9:40 AM Jacob Trimble wrote:
> > >
> > > On Fri, May 25, 2018 at 6:13 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > [...]
> > > >
> > > > > Added
On Thu, Jun 14, 2018 at 09:13:19AM -0700, Sasi Inguva wrote:
> looks good to me
thx, will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: PGP
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type
'int'
Fixes:
8697/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5197148130902016
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Hi,
The current build system is a rather large, and complex monolithic build
system. The configure script takes a sizeable amount of time to execute,
making improving, and modifying it a pain. It is completely written
custom from scratch, while this may not sound terrible it definitely
makes
Jun Zhao (2018-06-13):
> need to call av_bprint_finalize to free the memory source to match
> av_bprint_init.
As you may have seen, in this case too, the buffer is never allocated
dynamically.
The av_bprint_finalize() already present is thus useless (I think the
mistake is mine), but not harmful
Cf. comment. Restart the VT session when the APP goes from foreground to
background and vice versa.
---
libavcodec/videotoolboxenc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an
unsigned type to negate this value to itself
Fixes:
8521/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5639024952737792
Found-by: continuous fuzzing process
Fixes: signed integer overflow: 1195517 * 2048 cannot be represented in type
'int'
Fixes:
8636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-4695836326887424
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
STRIDE_ALIGN is not known in libavutil so av_image_check_size* cannot consider
it
Fixes: OOM
Fixes:
8291/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5176528009691136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
looks good to me
On Wed, Jun 13, 2018 at 10:11 AM Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 5d9ffa69a3..0acf981aef 100644
>
Fixes: Timeout
Fixes:
8638/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5132046098759680
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/lagarith.c | 7 +++
1 file
On 14 June 2018 at 19:56, Nicolas George wrote:
> Josh de Kock (2018-06-14):
> > As such, I'd like to propose adopting a new build system to FFmpeg,
> namely
> > Meson[1].
>
> I am very strongly against this.
>
> I loathe make and all it has to do with it, but really, for a project
> like this,
Josh de Kock (2018-06-14):
> As such, I'd like to propose adopting a new build system to FFmpeg, namely
> Meson[1].
I am very strongly against this.
I loathe make and all it has to do with it, but really, for a project
like this, it is the only viable option. The principles of make are
already
Hendrik Leppkes (2018-06-14):
> I don't mind make itself, for me its configure thats the real problem.
> Its extremely slow (we're talking minutes), for me often taking longer
> then the actual compilation (especially with ccache) - and that is
> really extremely painful.
IIRC, a change from the
On Thu, Jun 14, 2018 at 9:05 PM Nicolas George wrote:
>
> Hendrik Leppkes (2018-06-14):
> > I don't mind make itself, for me its configure thats the real problem.
> > Its extremely slow (we're talking minutes), for me often taking longer
> > then the actual compilation (especially with ccache) -
On Thu, Jun 14, 2018, at 1:39 PM, Lou Logan wrote:
> Makes v4l2 indev name consistent with the v4l2 indev.
Should say:
Makes v4l2 outdev name consistent with the v4l2 indev.
I changed this locally before sending, but forgot to re-make the updated patch.
On Thu, 14 Jun 2018, Tomas Härdin wrote:
ons 2018-06-13 klockan 22:11 +0200 skrev Marton Balint:
On Wed, 13 Jun 2018, Tomas Härdin wrote:
> sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > Also use common code with opAtom.
> >
> > Fixes ticket #2776.
> > Partially fixes ticket
Makes v4l2 indev name consistent with the v4l2 indev.
Signed-off-by: Lou Logan
---
libavdevice/v4l2enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index 85200d0a36..1c36f81f90 100644
--- a/libavdevice/v4l2enc.c
+++
I've created a thread in the Libav-user list asking if it was possible for
an application to obtain the info of lost packets sent by RTCP during
streams (http://ffmpeg.org/pipermail/libav-user/2018-June/011193.html).
Carl answered me that this is not exposed by the external API, it is
implemented
On Thu, Jun 14, 2018 at 8:56 PM Nicolas George wrote:
>
> Josh de Kock (2018-06-14):
> > As such, I'd like to propose adopting a new build system to FFmpeg, namely
> > Meson[1].
>
> I am very strongly against this.
>
> I loathe make and all it has to do with it, but really, for a project
> like
On Thu, 14 Jun 2018, Tomas Härdin wrote:
[...]
> > +} else {
> > +int64_t op1a_essence_offset =
> > +p->this_partition +
> > +round_to_kag(p->pack_length, p->kag_size) +
> > +round_to_kag(p->header_byte_count,
Rostislav Pehlivanov (2018-06-14):
> No, it isn't. Maybe if you took a moment to look at the proposed branches
> you'd notice NONE Of them remove ./configure. In fact that's precisely the
> plan - to leave and still support the script for the forseeable future.
> Hence your predjudice is
On 6/14/18, Nicolas George wrote:
> Rostislav Pehlivanov (2018-06-14):
>> No, it isn't. Maybe if you took a moment to look at the proposed branches
>> you'd notice NONE Of them remove ./configure. In fact that's precisely
>> the
>> plan - to leave and still support the script for the forseeable
On Friday, June 15, 2018 12:45:53 AM CEST Jean-Baptiste Kempf wrote:
> Hello,
>
> On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote:
> > As such, I'd like to propose adopting a new build system to FFmpeg,
> > namely Meson[1]. There has already been a fair amount of work (not by
>
> I think this
On Wed, May 09, 2018 at 07:50:23AM +0200, Jerome Borsboom wrote:
> Contrary to VC-1 spec, VAAPI expects the row address of the first
> macroblock row in the first slice to start from zero for the second
> field in a field interlaced picture.
>
> Signed-off-by: Jerome Borsboom
> ---
> This patch
On 6/15/18, James Almer wrote:
> On 6/14/2018 7:10 PM, Paul B Mahol wrote:
>> On 6/14/18, Nicolas George wrote:
>>> Rostislav Pehlivanov (2018-06-14):
No, it isn't. Maybe if you took a moment to look at the proposed
branches
you'd notice NONE Of them remove ./configure. In fact
2018-06-14 23:50 GMT+02:00, Rostislav Pehlivanov :
> On 14 June 2018 at 19:56, Nicolas George wrote:
>
>> Josh de Kock (2018-06-14):
>> > As such, I'd like to propose adopting a new build system to FFmpeg,
>> namely
>> > Meson[1].
>>
>> I am very strongly against this.
>>
>> I loathe make and all
On Fri, Jun 15, 2018 at 5:56 AM Lou Logan wrote:
>
> On Thu, Jun 14, 2018, at 1:39 PM, Lou Logan wrote:
> > Makes v4l2 indev name consistent with the v4l2 indev.
>
> Should say:
> Makes v4l2 outdev name consistent with the v4l2 indev.
>
> I changed this locally before sending, but forgot to
On Thu, Jun 14, 2018 at 9:44 PM Nicolas George wrote:
>
> Jun Zhao (2018-06-13):
> > need to call av_bprint_finalize to free the memory source to match
> > av_bprint_init.
>
> As you may have seen, in this case too, the buffer is never allocated
> dynamically.
>
> The av_bprint_finalize() already
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> configure | 2 +
> libavcodec/Makefile | 1 +
> libavcodec/cbs.c | 6 +
> libavcodec/cbs_internal.h | 1 +
> libavcodec/cbs_jpeg.c
Hello,
On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote:
> As such, I'd like to propose adopting a new build system to FFmpeg,
> namely Meson[1]. There has already been a fair amount of work (not by
I think this is a great idea.
Custom buildsystem are almost always wrong and/or broken.
2018-06-15 2:16 GMT+02:00, Martin Herkt :
> FFmpeg’s build system is unique because despite its lack
> of caching, one must sometimes make clean and
> reconfigure everything when bisecting for bugs.
Yes, this is unavoidable (make cannot know about new
features without running configure).
>
On 06/13/2018 07:39 AM, Pavel Koshevoy wrote:
On Thu, Jun 7, 2018 at 8:16 PM Pavel Koshevoy wrote:
---
doc/filters.texi| 17 ++---
libavfilter/af_atempo.c | 6 +++---
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
2018-06-13 14:24 GMT+02:00, Carl Eugen Hoyos :
> Attached patch fixes decoding of two files (width 999) that Piotr
> kindly provided, uploaded to
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5639/
Patch applied.
Carl Eugen
___
ffmpeg-devel
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Also adds greyscale, 4:2:2, 4:4:4 and RGB support.
> ---
> configure | 2 +-
> doc/encoders.texi | 17 +-
> libavcodec/vaapi_encode_mjpeg.c | 529 +
> ---
> 3 files
On 12 June 2018 at 10:20, Ruiling Song wrote:
> Signed-off-by: Ruiling Song
> ---
> I am not sure whether do you think this would be useful?
> the main purpose is to make OpenCL error check code simpler.
> If we think this is good, I can go to replace current
> OpenCL filters to use this macro.
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Set profile compatibility/constraint flags properly (including the
> constraint flags used for RExt profiles, as all streams we can currently
> generate are RExt-compatible), and use that to add support for the "Main
> Intra" and "Main 10
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Sets the level based on the stream properties if it is not explicitly
> set by the user. Also add a tier option to set general_tier_flag, since
> that affects the level choice.
> ---
> doc/encoders.texi | 4
>
Is your VAAPI library and VAAPI driver new enough? You need at least
libva-2.1.0 (VA-API version 1.1.0) and intel-vaapi-driver-2.1.0 for
interlaced VC-1 decoding. From the output, I think you are using an
older version and the error is just the libva library bailing out for
not supporting
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> libavcodec/vaapi_encode_h264.c | 34 ++
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> doc/bitstream_filters.texi | 9 +
> libavcodec/h264_metadata_bsf.c | 90
> ++
> 2 files changed, 99 insertions(+)
>
> diff --git a/doc/bitstream_filters.texi
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> The max and default values are 15, not 16.
I guessed you mixed both h264 and h265. The h264 doc i have specifies the range
for log2_max_mv_length_vertical/log2_max_mv_length_horizontal is [0, 16] and the
value of
---
Hi!
I like your idea with OCL_FAIL_ON_ERR(), but still do not know which one is
better.
My idea relies on fact, that there are only few OpenCL functions which are used
multiple times in filters:
clSetKernelArg, clCreateKernel(in case when there are multiple kernels) and
maybe
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> libavcodec/cbs_h264_syntax_template.c | 42
> +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Add a larger warning more clearly explaining the consequences of missing
> packed header support in the driver. Also only write the extradata if the
> user actually requests it via the GLOBAL_HEADER flag.
> ---
> libavcodec/vaapi_encode.c
Remove useless variable addr.
Change-Id: I0e91e6052dc5b44da3c0825d965ecba3dd1c9595
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mips/hpeldsp_mmi.c
Failed case: mss2-wmv
In ff_vc1_inv_trans series functions, pmullh instrunction was used to do the
multiplication of 16 bits data. It will cause overflow problem.
Change-Id: I9e37e9764d1858b9713be4cafd5c78bf75ee14f7
Signed-off-by: Shiyou Yin
---
libavcodec/mips/vc1dsp_mmi.c | 1493
Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi
v2.
Change-Id: If24813daec2c625c9901d047f6a05ff6b8153383
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264chroma_mmi.c | 740 ---
1 file changed, 454 insertions(+), 286
Optimized memset with mmi in function:
1. ff_h264_add_pixels4_8_mmi.
2. ff_h264_idct_add_8_mmi.
3. ff_h264_idct8_add_8_mmi.
Change-Id: Ifde1dd36c053970e33ac9cfc660cb21b17b1bd6d
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264dsp_mmi.c | 36 +---
1 file changed,
Optimize function get_cabac_inline with asm.
Change-Id: I67f5e96b30589d925fa13c5a4595f1f2924f17e1
Signed-off-by: Shiyou Yin
---
libavcodec/cabac_functions.h | 3 ++
libavcodec/mips/cabac.h | 119 +++
2 files changed, 122 insertions(+)
create mode
Reoptimize following functions with mmi:
1. ff_put_pixels4_8_mmi.
2. ff_put_pixels8_8_mmi.
3. ff_put_pixels16_8_mmi.
4. ff_add_pixels_clamped_mmi.
Change-Id: I80bf76b4d8d79c32c6c1913fe80fd5a828e937f1
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 133
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Xiang, Haihao
> Sent: Thursday, June 14, 2018 2:08 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 16/36] vaapi_encode: Clean up rate
> control configuration
>
> On
From: gxw
Optimize vp8 decoding with mmi in function:
1. ff_vp8_h_loop_filter8uv_mmi.
2. ff_vp8_v_loop_filter8uv_mmi.
3. ff_vp8_h_loop_filter16_mmi.
4. ff_vp8_v_loop_filter16_mmi.
Change-Id: Iba567c7ab4c6a284b5e8ccbc567575448a508350
Signed-off-by: gxw
Signed-off-by: Shiyou Yin
---
On Wed, 2018-06-13 at 23:42 +0100, Mark Thompson wrote:
> On 13/06/18 08:03, Xiang, Haihao wrote:
> > On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> > > Query which modes are supported and select between VBR and CBR based
> > > on that - this removes all of the codec-specific rate
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Choose what types of reference frames will be used based on what types
> are available, and make the intra-only mode explicit (GOP size one,
> which must be used for MJPEG).
> ---
> libavcodec/vaapi_encode.c | 83
Make ffmpeg to output stats for each video/audio streams and each ouptut file
ffmpeg output log in print_report. The report of video/audio sizes is clear now
as previously all output video/audio sizes were combined to report and it is
unclear such stats is for one output files or aggregates for
I may confirm that the error is returned from the old version of libva and vaapi
driver w/wo this patch, the command below works well for me if using the new
version of libva and vaapi driver.
Thanks
Haihao
> Is your VAAPI library and VAAPI driver new enough? You need at least
> libva-2.1.0
On 6/14/2018 7:10 PM, Paul B Mahol wrote:
> On 6/14/18, Nicolas George wrote:
>> Rostislav Pehlivanov (2018-06-14):
>>> No, it isn't. Maybe if you took a moment to look at the proposed branches
>>> you'd notice NONE Of them remove ./configure. In fact that's precisely
>>> the
>>> plan - to leave
67 matches
Mail list logo
