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;
- alignment requirements will evolve
(the 16->32 bump is still recent);
-
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
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
>
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
>
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
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
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
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
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
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;
>
> -
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;
- alignment requirements will evolve
(the 16->32 bump is still recent);
-
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
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
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,
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
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
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
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
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
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
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 be wasteful;
- alignment requirements will evolve
(the 16->32
22 matches
Mail list logo