Hello Fabian,
can confirm that both variants are fixing the issue.
I would prefer the function level fix, but as there is already a change
to the build system that does exclusively apply to this file, I think
both are equally good.
(And when OCaml 4.02 enters Stretch we can try removing it ag
Hello Fabian,
your patch fixes the issue.
But I fear by using static we potentially introduce a race condition,
if there are any applications encoding in two threads?
(May I ask if there are any reasons against "__attribute__((aligned(0x20)))"?)
Kind regards,
Bernhard
I used following to build
Hello Fabian,
after some more searching and testing here is my "opinion" on this issue:
- OCaml versions 4.01 (used in Jessie) and before are not doing stack
alignment on 16 byte boundaries [1].
- GCC does 16 byte stack alignment (at least when using SSE instructions)
at compile time.
- Now
Hello Fabian,
Am 02.06.2015 um 12:11 schrieb Fabian Greffrath:
> but that shouldn't make a difference, because the code already worked
> correctly when you forced it to 16-bit boundaries by using
> posix_memalign().
I just wanted to have a less invasive change.
> What happens if you re-arrange
Hello Fabian,
Am 02.06.2015 um 06:25 schrieb Fabian Greffrath:
> Hm, are we missing a specific compiler flag in addition to -msse or are
> we probably hunting down a compiler bug here?
Could it be also some linker flag of the .so or liquidsoap? I tried to build
a minimal example but then the cras
Hello Fabian,
unfortunately this did not work too (with or without "packed").
Kind regards,
Bernhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
Hello Fabian,
did the test inside the i386 VM.
But it did not help either. The "packed" gets ignored.
(But I am not sure if I use the __attribute__ the right way?)
Kind regards,
Bernhard
---
const vecfloat_union fabs_mask __attribute__((aligned(16),packed)) = {{
0x7FFF, 0x7FFF,
Hello Fabian, hello Detrick,
Am 29.05.2015 um 22:02 schrieb Fabian Greffrath:
>> I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions:
> is this on a fresh Jessie install?
Is a Jessie-Testing installation from 30th November 2014.
At least upgraded to the latest (Jessie) versio
Hello Fabian, hello Detrick,
I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions:
(amd64 did not show the fault)
- apt-get install icecast2 liquidsoap liquidsoap-plugin-icecast
liquidsoap-plugin-lame liquidsoap-plugin-mad liquidsoap-plugin-ogg
liquidsoap-plugin-vorbis
- ena
support nopl and conditional mov (cmov)
--
1.7.10.4
Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding memset
Author: Bernhard Übelacker
---
Bug-Debian: https://bugs.debian.org/783082
Last-Update: 2015-04-28
--- libav-11.3.orig/libavcodec/h264_cabac.c
+++ libav-11.3/l
Hello,
sorry for the delay.
Yes, I would vote for getting these 3 changes into Jessie (if it is up
to me?).
This 3 changes should only affect the file:
/usr/lib/i386-linux-gnu/libavcodec.so.56.1.0
But I think most users today would use this version:
/usr/lib/i386-linux-gnu/i686/cmov/libavcode
Hello hikaru,
(I have tried to split the browser issue into a different bug #783293.)
When libav is built with this 3 attached changes then vlc and mplayer2
are not crashing anymore.
This would need some more tests as I had only my qemu VM (which was way
too slow) with one video file inside.
Hello hikaru,
additional to the patch above it looks like there is also a
flaw in debian/confflags:
--- libav-11.3.orig/debian/confflags2015-01-17 18:25:07.0 +
+++ libav-11.3/debian/confflags 2015-04-22 22:35:12.616951338 +
@@ -180,7 +180,7 @@ shared_build_confflags += --enable
Hello Bálint,
> This kodi-14 stack is nearly equal to the stack of xbmc-13 when we call the
> VDPAU::CDecoder::FiniVDPAUOutput.
> The difference starts in CWinSystemX11::SetFullScreen.
> Will do some more testing, probably we need only to make a call to
> CWinSystemX11::SetWindow too ...
Tried
Hello Bálint,
sorry for the late reply.
Am 28.12.2014 um 16:32 schrieb Bálint Réczey:
> It would also be interesting to check an xbmc build using FFmpeg, it
> may make a difference:
> http://snapshot.debian.org/package/xbmc/2%3A13.2%2Bdfsg1-2~exp1/
I build a xbmc package from the link above using
Hello Bálint,
I was successful in creating a package for kodi from you git
and some ffmpeg packages from unstable, and then building and
using axbmc-pvr-addons zip from it.
The issue I described I could not reproduce with kodi-14.
>From the logfile I assume that vdpau is in use:
VDPAU::Crea
Hello Bálint Réczey,
thanks for your fast response.
One thing I am uncomfortable with my proposal is, if it would affect
people using some low spec computer which are not able to decode fast
enough in software and not having vdpau at all.
I will try to build a kodi package from your repo and repo
Package: xbmc
Version: 2:13.2+dfsg1-4
Severity: important
Dear Maintainer,
when playing with xbmc from current jessie with activated xbmc-pvr-tvheadend-
hts
from some satellite broadcasts I get only a black screen when switching from
windowed to fullscreen mode.
These are the circumstances which
Hello,
patch got applied upstream [1] and is contained in new release version 10.3.
There are already packages for 10.3 in unstable.
[1]
http://git.libav.org/?p=libav.git;a=commit;h=dc71f1958846bb1d96de43a4603983dc8450cfcc
Kind regards,
Bernhard
___
p
Dear Maintainer,
this crash happens when only one command line argument is given.
(e.g. "M2VRequantiser --help" or as from the bug opener "M2VRequantiser --NN)
--- m2vrequantiser-1.1.orig/main.c
+++ m2vrequantiser-1.1/main.c
@@ -2315,7 +2315,7 @@ int main (int argc, const char * argv[])
i
Package: libav-tools
Version: 6:10.2-1
Severity: minor
Tags: patch
Dear Maintainer,
tried to record some old analog tapes from tv card to DVD compatible files.
In avconv_opt.c:opt_target it is tried to determine the norm.
For this the streams are evaluated.
This leads in my case to this exception
21 matches
Mail list logo