Hi Alexander,
‐‐‐ Original Message ‐‐‐
On Thursday, 8 de August de 2019 1:43, Alexander Strasser
wrote:
> On 2019-08-07 15:51 +, Andreas Håkon wrote:
>
> > Hi,
> > This new version changes the name of the filter, and implements all
> > suggestions.
>
> Thanks for renaming; "timesh
> 发件人: "Michael Niedermayer"
> 发送时间: 2019-08-08 07:05:13 (星期四)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
>
> On Wed, Aug 07, 2019 at 05:52:00PM +0800, gxw wrote:
> > Changing details as following:
> > 1.
From: Thomas Volkert
---
libavutil/hwcontext_d3d11va.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6670c47579..0204407330 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11v
> 在 2019年8月8日，上午12:32，Jun Zhao 写道：
>
> From: Jun Zhao
>
> Add http_seekable option for HTTP partial requests, when The
> EXT-X-BYTERANGE tag indicates that a Media Segment is a sub-range
> of the resource identified by its URI, we can use HTTP partial
> requests to get the Media Segment.
>
>
On 2019-08-07 15:51 +, Andreas Håkon wrote:
> Hi,
>
> This new version changes the name of the filter, and implements all
> suggestions.
Sorry, I couldn't reply earlier.
Thanks for renaming; "timeshift" sounds better to me, compared to
the previous "timer".
Other suggestions which I came up
On Tue, Aug 06, 2019 at 11:30:05PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (Infinite->Finite)
> Fixes:
> 15706/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5114674904825856
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/proje
On Wed, Aug 07, 2019 at 05:52:00PM +0800, gxw wrote:
> Changing details as following:
> 1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in
>source vector.
> 2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'.
>Performance of VP8 decoding has spe
On 2019-08-07 21:28 +0200, Marton Balint wrote:
>
> On Wed, 7 Aug 2019, Alexander Strasser wrote:
>
> > Hi Marton!
> >
> > Not really sure if we need the API, but it definitely looks
> > handy. Just not sure how often it will used and really result
> > in clearer or shorter code.
>
> It has better
Aug 7, 2019, 11:46 PM by juandl-at-google@ffmpeg.org:
> On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
>
>> This should be in libavcodec, not libavutil - it relates directly to
>> codecs. (Indeed, you've ended up having to define a special non-libavcodec
>> enum of codecs below to make
On Tue, Aug 6, 2019 at 5:07 PM Mark Thompson wrote:
> This should be in libavcodec, not libavutil - it relates directly to
> codecs. (Indeed, you've ended up having to define a special non-libavcodec
> enum of codecs below to make it work in libavutil at all.)
>
If this belongs in avcodec I can
On Wed, Aug 07, 2019 at 06:27:12PM +0300, velocit...@gmail.com wrote:
> From: Nick Renieris
>
> Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
>
> This commit adds support for:
> - DNG tiles
> - DNG tile huffman lossless JPEG decoding
> - DNG 8-bpp ("packed" as dcraw cal
On Wed, Aug 07, 2019 at 06:27:14PM +0300, velocit...@gmail.com wrote:
> From: Nick Renieris
>
> Signed-off-by: Nick Renieris
> ---
> libavcodec/tiff.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index c
These functions can be used to print a variable number of strings consecutively
to the IO context. Unlike av_bprintf, no temporary buffer is necessary.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 17 +
libavformat/aviobuf.c | 12 ++
On Wed, 7 Aug 2019, Alexander Strasser wrote:
Hi Marton!
Not really sure if we need the API, but it definitely looks
handy. Just not sure how often it will used and really result
in clearer or shorter code.
It has better performance than using av_printf because it does not need a
temporary
Am 07.08.19 um 21:18 schrieb Michael Niedermayer:
> The awnser which most people will seek is put first
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/fate.texi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 2be61d639c..c3550785a1 100644
>
The awnser which most people will seek is put first
Signed-off-by: Michael Niedermayer
---
doc/fate.texi | 4
1 file changed, 4 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2be61d639c..c3550785a1 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -149,6 +149,8 @@ the synch
On Wed, Aug 07, 2019 at 12:59:33AM +0100, Mark Thompson wrote:
> On 05/08/2019 20:20, Juan De León wrote:
[...]
>
> > +/**
> > + * Stores an id corresponding to one of the supported codecs
> > + */
> > +enum AVExtractQPSupportedCodecs codec_id;
>
> enum AVCodecID, with this in lib
On Wed, Aug 7, 2019, at 14:28, Moritz Barsnick wrote:
> On Tue, Aug 06, 2019 at 17:55:35 +0200, Daniel Kolesa wrote:
> > The first of these patches fixes the original report as described in
> > https://trac.ffmpeg.org/ticket/7861. The second of the patches fixes
> > the second report in the same ti
While this technically compiles in current ffmpeg, this is only
because ffmpeg is compiled in strict ISO C mode, which disables
the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
replaced with a macro inside altivec.h, which defines vector to
be actually __vector, which accepts random
Updated commit messages.
Daniel Kolesa (2):
swscale: Replace illegal vector keyword usage in altivec code
swscale: Fix AltiVec/VSX build with recent GCC
libswscale/ppc/swscale_altivec.c | 36 +-
libswscale/ppc/swscale_vsx.c | 894 ---
2 files changed, 467 ins
The argument to vec_splat_u16 must be a literal. By making the
function always inline and marking the arguments const, gcc can
turn those into literals, and avoid build errors like:
swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal
Fixes #7861.
Signed-off-by: Daniel Kolesa
From: Aman Gupta
Signed-off-by: Aman Gupta
---
libavcodec/vaapi_encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e69b59fa37..2fb43cf1a4 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
On Thu, Dec 20, 2018 at 12:46 PM Mark Thompson wrote:
> This attaches the logic of picking the mode of for the next picture to
> the output, which simplifies some choices by removing the concept of
> the picture for which input is not yet available. At the same time,
> we allow more complex refe
Hi,
patch attached.
0001-avcodec-h264_refs-do-not-use-invalid-mmco-values-in-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
From: Jun Zhao
Add http_seekable option for HTTP partial requests, when The
EXT-X-BYTERANGE tag indicates that a Media Segment is a sub-range
of the resource identified by its URI, we can use HTTP partial
requests to get the Media Segment.
Signed-off-by: Jun Zhao
---
doc/demuxers.texi |4 +
Am 07.08.19 um 16:57 schrieb Li, Zhong:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Michael Niedermayer
>> Sent: Tuesday, August 6, 2019 1:07 AM
>> To: FFmpeg development discussions and patches
>>
>> Subject: [FFmpeg-devel] [PATCH] doc/fate: Document how to requ
Hi Alexander,
‐‐‐ Original Message ‐‐‐
On Wednesday, 7 de August de 2019 10:01, Andreas Håkon
wrote:
> Hi Alexander,
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, 7 de August de 2019 0:24, Alexander Strasser eclip...@gmx.net
> wrote:
>
> > Hi Andreas!
> > On 2019-08-05 17:25 +0
Hi,
This new version changes the name of the filter, and implements all suggestions.
Supersedes:
https://patchwork.ffmpeg.org/patch/14195/
https://patchwork.ffmpeg.org/patch/13743/
https://patchwork.ffmpeg.org/patch/13699/
Regards.
A.H.
---From 9e036e0a1dc20fd5c41686a48a5a0c2142f91de4 Mon Sep 17
From: Nick Renieris
Sample file:
https://drive.google.com/open?id=0B4JyRT3Lth5HVndyOTVOdWktM3J4TFEydTk1MnY3RWlpSzVB
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff
From: Nick Renieris
In an image [1], the height was equal to the tile length (full-height
tile) and after `height % tile_length` was applied to them with the
current code, it resulted in the operating tile_length to be 0. This
commit makes this leftover logic only applies if it's necessary.
Sig
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 8db42d2bc5..7b9d7574c8 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1035,6 +1035,18 @@ static int in
From: Nick Renieris
Samples:
- Embedded JPEG images in the DNG images here:
https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c b
From: Nick Renieris
This enables decoding of DNG and CinemaDNG images generated by 'DJI Zenmuse X7'
Samples: https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 61 +++
1 file changed, 51 insertions(+
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 6391107f78..94cf73549d 100644
--- a/libavcodec/mjpegdec.c
+++
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c7e2adb3ae..b6f626daca 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -679,6 +
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d1d2e15f45..c7e2adb3ae 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index f577639dfa..8db42d2bc5 100644
--- a/libavcodec/tiff.c
+++ b/libavco
From: Nick Renieris
Some JPEGs [1] have incorrect DHT entries that map 2 codes to
the same value.
The second (last) mapping does not ever actually appear in the
code stream, therefore ignoring any mappings after the first one
fixes this.
Without this, an "mjpeg_decode_dc: bad vlc: 0:0" error is
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs witho
From: Nick Renieris
DNG samples here can now be decoded:
- https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 79 +++
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/libavcod
Going to post a new patchset with my latest work. It includes these 2
commits (one slightly modified) and 11 more.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 7, 2019 22:36
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
>
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Tuesday, August 6, 2019 1:07 AM
> To: FFmpeg development discussions and patches
>
> Subject: [FFmpeg-devel] [PATCH] doc/fate: Document how to request
> samples upload access
>
> Signed-off-by
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 7, 2019 10:36 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
> support for QSV transpose filter"
>
> On
On Wed, Aug 7, 2019 at 4:34 PM Li, Zhong wrote:
> > From: Nicolas George [mailto:geo...@nsup.org]
> > Sent: Wednesday, August 7, 2019 10:31 PM
> > To: FFmpeg development discussions and patches
> >
> > Cc: Li, Zhong
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
> > su
On Wed, Aug 7, 2019 at 4:31 PM Nicolas George wrote:
> Zhong Li (12019-08-07):
> > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e.
> >
> > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi"
>
> The damage to the git log is done, this will just make it worse, IMHO.
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Wednesday, August 7, 2019 10:31 PM
> To: FFmpeg development discussions and patches
>
> Cc: Li, Zhong
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
> support for QSV transpose filter"
>
> Zhong Li (12019-08-07):
> >
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 7, 2019 10:08 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
> > Applied with
Zhong Li (12019-08-07):
> This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e.
>
> Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi"
The damage to the git log is done, this will just make it worse, IMHO.
Regards,
--
Nicolas George
signature.asc
Description: PGP
From: Linjie Fu
Add transpose support for qsv_vpp with rotate and hflip:
- rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
- hflip: [0, 1] support horizontal flip;
Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
CMD:
ffmpeg -hwac
This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e.
Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi"
---
libavfilter/vf_vpp_qsv.c | 101 +--
1 file changed, 2 insertions(+), 99 deletions(-)
diff --git a/libavfilter/vf_vpp_
On Wed, Aug 7, 2019 at 4:04 PM Li, Zhong wrote:
> > From: Fu, Linjie
> > Sent: Monday, July 15, 2019 12:30 PM
> > To: Li, Zhong ; FFmpeg development discussions and
> > patches
> > Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> > QSV transpose filter
> >
> > > -Or
> From: Fu, Linjie
> Sent: Monday, July 15, 2019 12:30 PM
> To: Li, Zhong ; FFmpeg development discussions and
> patches
> Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
>
> > -Original Message-
> > From: Li, Zhong
> > Sent: Sunday, July 14
On Tue, Aug 06, 2019 at 17:55:35 +0200, Daniel Kolesa wrote:
> The first of these patches fixes the original report as described in
> https://trac.ffmpeg.org/ticket/7861. The second of the patches fixes
> the second report in the same ticket (by leigh123linux).
If so, each of the commit messages s
Moritz Barsnick (12019-08-07):
> On Wed, Aug 07, 2019 at 00:14:06 +0200, Alexander Strasser wrote:
> > Nicolas, changes to the coding style should be discussed and not
> > be tunneled through documentation patches. Though I don't think
> > the latter was the intention of the OP.
>
> It was probabl
Hi Michael,
The given patch is expected to break compliance because there is no support for
frame-doubling (pic_struct=7) and frame-tripling (pic_struct=8) in the HM
decoder. I have verified this on the HM Decoder v16.8 incl RExt.
In HM's TDecTop::xActivateParameterSets(), only the pic_struct v
LGTM.
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of gxw
>Sent: Wednesday, August 7, 2019 5:52 PM
>To: ffmpeg-devel@ffmpeg.org
>Subject: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
>
>Changing details
Changing details as following:
1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in
source vector.
2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'.
Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x).
Performance of H264 d
Changing details as following:
1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in
source vector.
2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'.
Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x).
3. Remove redundant macr
Hi Phil,
Unfortunately I cannot share the sample we use internally, but it should be
reproducible with any h.263/mpeg-4 encoded file & hw accelerated decoding.
Thanks
Stefan
-Original Message-
From: ffmpeg-devel On Behalf Of Philip
Langdale
Sent: Saturday, August 3, 2019 08:57
To: FFm
Changing details as following:
1. Remove the local variable out_m in CLIP_SH. Results are assigned
to input vector, reduced the data replication.
2. Reimplement the macro CLIP_SH/Wn_0_255. The VP8 decoding performance
has improved by 1.1%(7.03x to 7.11x, tested on loongson 3A4000).
3. Remove
> -Original Message-
> From: Song, Ruiling
> Sent: Wednesday, July 31, 2019 3:54 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling
> Subject: [PATCH V2] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
>
> Tested using a simple command (apply edge enhance):
> ./ffmpeg_g -i ~/Down
Hi Alexander,
‐‐‐ Original Message ‐‐‐
On Wednesday, 7 de August de 2019 0:24, Alexander Strasser
wrote:
> Hi Andreas!
>
> On 2019-08-05 17:25 +, Andreas Håkon wrote:
>
> > On Monday, 5 de August de 2019 17:31, Moritz Barsnick barsn...@gmx.net
> > wrote:
>
> [...]
>
> > > > +stati
On Wed, Aug 07, 2019 at 00:14:06 +0200, Alexander Strasser wrote:
> Nicolas, changes to the coding style should be discussed and not
> be tunneled through documentation patches. Though I don't think
> the latter was the intention of the OP.
It was probably caused by different reviews:
- "Please re
65 matches
Mail list logo
