On Wed, May 10, 2017 at 06:46:41PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, May 10, 2017 at 5:02 PM, Michael Niedermayer > wrote:
>
> > On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> > > Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > > > fixed, and
Hi,
On Wed, May 10, 2017 at 5:02 PM, Michael Niedermayer wrote:
> On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> > Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > > fixed, and now your patchset seems to cause a 1% slowdown of the
> > > example above
> >
> >
On Wed, May 10, 2017 at 10:28 PM, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
>> fixed, and now your patchset seems to cause a 1% slowdown of the
>> example above
>
> Thanks. The slowdown is to be expected, since this filter used
> non-aligned frames whic
On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > fixed, and now your patchset seems to cause a 1% slowdown of the
> > example above
>
> Thanks. The slowdown is to be expected, since this filter used
> non-aligned f
On 5/10/17, Michael Niedermayer wrote:
> On Wed, May 10, 2017 at 05:49:20PM +0200, Nicolas George wrote:
>> Le primidi 21 floreal, an CCXXV, Michael Niedermayer a ecrit :
>> > breaks (green stuff on edges)
>> > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5 -vf uspp=4:8
>> > -qscale 1
Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> fixed, and now your patchset seems to cause a 1% slowdown of the
> example above
Thanks. The slowdown is to be expected, since this filter used
non-aligned frames which are now realigned. I guess you can get back the
previous speed b
On Wed, May 10, 2017 at 05:49:20PM +0200, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > breaks (green stuff on edges)
> > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5 -vf uspp=4:8
> > -qscale 1 -y file.avi
>
> It is a bug in vf_uspp:
>
Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> breaks (green stuff on edges)
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5 -vf uspp=4:8
> -qscale 1 -y file.avi
It is a bug in vf_uspp:
diff --git a/libavfilter/vf_uspp.c b/libavfilter/vf_uspp.c
index ef493b860f..
On Wed, May 10, 2017 at 04:16:25AM +0200, Michael Niedermayer wrote:
> On Tue, May 09, 2017 at 03:19:43PM +0200, Nicolas George wrote:
> > A lot of codecs require aligned frame data, but do not document it.
> > It can result in crashes with perfectly valid uses of the API.
> >
> > Design rationale
On Tue, May 09, 2017 at 03:19:43PM +0200, Nicolas George wrote:
> A lot of codecs require aligned frame data, but do not document it.
> It can result in crashes with perfectly valid uses of the API.
>
> Design rationale:
>
> - requiring frame data to be always aligned would be wasteful;
>
> - al
Hi,
On Sun, May 7, 2017 at 2:55 PM, Hendrik Leppkes wrote:
> On Sun, May 7, 2017 at 7:17 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Sun, May 7, 2017 at 11:15 AM, Hendrik Leppkes
> > wrote:
> >
> >> Ronald suggested on IRC that the only parts suffering from this are
> >> the ASM DSP compo
On Sun, May 7, 2017 at 7:17 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, May 7, 2017 at 11:15 AM, Hendrik Leppkes
> wrote:
>
>> Ronald suggested on IRC that the only parts suffering from this are
>> the ASM DSP components, and we should just make checkasm tests for all
>> of them and let checkas
Hi,
On Sun, May 7, 2017 at 11:15 AM, Hendrik Leppkes
wrote:
> Ronald suggested on IRC that the only parts suffering from this are
> the ASM DSP components, and we should just make checkasm tests for all
> of them and let checkasm test the alignment they claim to support, but
> alas this won't be
On Sat, May 6, 2017 at 8:34 PM, Nicolas George wrote:
>
> Encouraging the applications to be aware of the issue for performances
> reasons is a good thing.
>
> Forcing them to do so when it is not convenient, on pain of crash, when
> it can be done for them just as easily, not so much.
>
>> There
Le septidi 17 floréal, an CCXXV, Hendrik Leppkes a écrit :
> I don't think this is very practical. We have a bunch of generic DSPs
> and if a codec uses those it would need to be constantly updated if
> the requirements of those DSPs change. Today it may only use SSE and
> be happy with 16-byte ali
Le septidi 17 floréal, an CCXXV, Ronald S. Bultje a écrit :
> I agree it's likely that one codec (e.g. h264) would need 32-byte alignment
> on a particular system (e.g. x86/haswell), whereas another codec on the
> same system (e.g. wmavoice) might not.
>
> However, I find it unlikely that one code
On Sat, 6 May 2017, Ronald S. Bultje wrote:
Hi,
On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote:
+/**
+ * Minimum alignment of frame data required by the codec.
+ * All frame data pointers must have the alignment lower bits cleared,
+ * i.e. be a multiple of 1<
I agre
Hi,
On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote:
> +/**
> + * Minimum alignment of frame data required by the codec.
> + * All frame data pointers must have the alignment lower bits cleared,
> + * i.e. be a multiple of 1< + * - encoding: set by the encoder and used b
On Sat, May 6, 2017 at 11:20 AM, Nicolas George wrote:
> A lot of codecs require aligned frame data, but do not document it.
> It can result in crashes with perfectly valid uses of the API.
>
> TODO Implementation missing.
>
> Design rationale:
>
> - requiring frame data to be always aligned would
19 matches
Mail list logo
