On 25/06/17 00:40, Philip Langdale wrote:
> Second try.
>
> Feedback on first proposal was lack of interest in having default behaviour
> vary between hwaccels, despite their other differences.
>
> In this patch series, I instead force the user to confront the change in
> command line semantics w
Signed-off-by: Paul B Mahol
---
libavfilter/f_sendcmd.c | 1 -
libavfilter/f_zmq.c | 1 -
libavfilter/graphdump.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index 1e53465..b8740e8 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilte
On Sun, 25 Jun 2017 12:43:12 +0100
Mark Thompson wrote:
> Point (2) is somewhat more subtle. The default hwaccel behaviour is
> made for the real hwaccels attached to the normal decoder, and won't
> do the right thing for the dummy ones. The specific case that we
> strongly want to avoid is som
On Sat, 24 Jun 2017 21:42:23 -0400
"Ronald S. Bultje" wrote:
> Hi Philip,
>
> On Sat, Jun 24, 2017 at 7:40 PM, Philip Langdale
> wrote:
>
> > Feedback on first proposal was lack of interest in having default
> > behaviour vary between hwaccels, despite their other differences.
>
>
> I thin
vp9_diag_downright_32x32_12bpp_c: 429.7
vp9_diag_downright_32x32_12bpp_sse2: 158.9
vp9_diag_downright_32x32_12bpp_ssse3: 144.6
vp9_diag_downright_32x32_12bpp_avx: 141.0
vp9_diag_downright_32x32_12bpp_avx2: 73.8
Almost 50% faster than avx implementation
---
libavcodec/x86/vp9dsp_init_16bpp.c|
Also fix undefined left shift of negative variable.
Signed-off-by: Paul B Mahol
---
libavcodec/proresenc_kostya.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 090dfa5..25f7fcb 100644
--- a/libavcodec/pr
On 25 June 2017 at 16:38, Paul B Mahol wrote:
> Also fix undefined left shift of negative variable.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/proresenc_kostya.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/prores
On Sat, Jun 24, 2017 at 06:30:26PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Jun 24, 2017 at 3:27 PM, Michael Niedermayer > wrote:
>
> > On Mon, Jun 19, 2017 at 05:11:03PM +0200, James Darnley wrote:
> > > Includes add/put functions
> > >
> > > Rounding contributed by Ronald S. Bultje
> >
Changes since V1:
* Implemented fixes suggested by Moritz Barsnick (if/else whitespace)
* Strict checking on overread of the IP packet data
* Fixed checking the size of the IP packet header size (6 vs 8)
Changes since V2:
* Correct the header size check found by Paul B Mahol
This patch series
Interplay MVE movies have a SEND_BUFFER operation. Only after this
command does the current decoding buffer get displayed. This is required
for the other frame formats. They are fixed-size and can't always encode
a full frame worth of pixeldata.
This code prevents half-finished frames from being e
Interplay MVE can contain up to three different frame formats. They
require different streams of information to render a frame. This patch
changes the IP packet format to prepare for the extra frame formats.
Signed-off-by: Hein-Pieter van Braam
---
libavcodec/interplayvideo.c | 33 ++
This implements the 0x06 frame format for Interplay MVE movies. The
format is relatively simple. The video data consists of two parts:
16 bits per 8x8 block movement data
a number of 8x8 blocks of pixel data
For each 8x8 block of pixel data the movement data is consulted. There
are 3 possible mea
Signed-off-by: Hein-Pieter van Braam
---
Changelog | 1 +
1 file changed, 1 insertion(+)
diff --git a/Changelog b/Changelog
index 4f46eda..24d2255 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version :
- roberts video filter
- The x86 assembler default switched from yasm to nasm, p
This implements the 0x10 frame format for Interplay MVE movies. The
format is a variation on the 0x06 format with some changes. In addition
to the decoding map there's also a skip map. This skip map is used to
determine what 8x8 blocks can change in a particular frame.
This format expects to be ab
The patch is correct, please apply.
Reviewed-by:vta...@mobibase.com
--
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Sorry, gmail refused to send the In-Reply-To header.
The concerned patch is:
https://patchwork.ffmpeg.org/patch/2206/
This is a confirmed error, patch can be applied. Thanks!
On 25/06/2017 22:47, Vlad Tarca wrote:
The patch is correct, please apply.
Reviewed-by:vta...@mobibase.com
--
_
Dummy hwaccels, of which cuvid is the best example, behave differently
from real hwaccels. In the past, one of these behaviours was that
selecting the hwaccel would automatically cause the decoder (and
remember it's a dedicated decoder) to use the native hardware output
format.
This meant that tra
Third time's a charm.
Based on feedback from Mark, I've reworked my v1 change to explicitly reflect
that we are differentiating behaviour based on whether the hwaccel is real
or a dummy. In the dummy case, we want to set the default output format to
maintain the same semantics as we had before gen
With generic hwaccel, it is additionally necessary to specify the
output format. If this is not done, we'll end up downloading the
frames back and then re-uploading them.
For example:
ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda \
-c:v h264_cuvid -i sample.mp4 \
-c:v h264_nv
On Sat, Jun 24, 2017 at 11:39:03PM +0300, Ivan Kalvachev wrote:
[...]
> diff --git a/libavcodec/x86/opus_pvq_search.asm
> b/libavcodec/x86/opus_pvq_search.asm
> new file mode 100644
> index 00..36b679b75e
> --- /dev/null
> +++ b/libavcodec/x86/opus_pvq_search.asm
> @@ -0,0 +1,628 @@
> +;
On Sat, Jun 24, 2017 at 10:39 PM, Ivan Kalvachev wrote:
> +%define HADDPS_IS_FAST 0
> +%define PHADDD_IS_FAST 0
[...]
> +haddps %1, %1
> +haddps %1, %1
[...]
> + phaddd xmm%1,xmm%1
> + phaddd xmm%1,xmm%1
You can safely assume that those instru
Yasm:
src/libavfilter/x86/af_volume.asm:24: warning: Standard COFF does not support
read-only data sections
src/libavfilter/x86/af_volume.asm:24: warning: Unrecognized qualifier `align'
Nasm:
src/libavfilter/x86/af_volume.asm:24: error: standard COFF does not support
section alignment specificat
22 matches
Mail list logo
