Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 again.) Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 with your patch: mkdir libmp3lame0-with-static-var; cd libmp3lame0-with-static-var apt-get source libmp3lame0 wget https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=117;filename=lame-static-vecfloat-msse.patch;bug=786438; -O lame-static-vecfloat-msse.patch cd lame-3.99.5+repack1/ patch -p1 ../lame-static-vecfloat-msse.patch dpkg-buildpackage -b -uc -us cd .. su -c dpkg -i libmp3lame0_3.99.5+repack1-7_i386.deb libmp3lame-dev_3.99.5+repack1-7_i386.deb ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 when calling libmp3lame0 from lame executable (gcc) this works just fine. But calling from liquidsoap (ocaml) we end up calling libmp3lame0 with a unaligned stack therefore getting the SIGSEGV on the movaps %xmm0,0x20(%esp). (See the second stack and the address of vec_xrpow_max in [2].) But until now I could not fully proove my theory because: - OCaml version 4.02 is just in experimental. Using this version would need to compile also all the packages depending on ocaml. - Just using this patch in [1] is also not binary compatible with the packages depending on ocaml, therefore needing them all to recompile too. For this reason chances for such a change to OCaml to enter Jessie are low? One thing did avoid the crash, that was adding __attribute__((aligned(0x20))) to the vecfloat_union used inside libmp3lame0 [3]. Requesting an alignment of 0x10 seems without effect. (Probably because GCC does this already and is therefore removed.) Options we have, if above could be proven right: - change libmp3lame0 [3] (at least for stable), even when it is not guilty - test rebuilding OCaml and all dependents with the patch in [1] - wait if problem vanishes when OCaml 4.02 enters unstable/testing. - get someone from debian-ocaml-maint involved. [1] http://caml.inria.fr/mantis/view.php?id=6038#c11630 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#22 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#87 Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 crash does not appear anymore.
Nevertheless, as I experimented with bigger align values it stopped crashing.
Following worked inside qemu VM:
--- ./libmp3lame/vector/xmm_quantize_sub.c.orig 2011-05-07 18:05:17.0
+0200
+++ ./libmp3lame/vector/xmm_quantize_sub.c 2015-06-02 11:50:01.76800
+0200
@@ -40,7 +40,7 @@ typedef union {
int32_t _i_32[4]; /* unions are initialized by its first member */
float _float[4];
__m128 _m128;
-} vecfloat_union;
+} __attribute__((aligned(0x20))) vecfloat_union;
#define TRI_SIZE (5-1) /* 1024 = 4**5 */
static const FLOAT costab[TRI_SIZE * 2] = {
Kind regards,
Bernhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 the definition of the vecfloat_union so
that _m128 is its first member, i.e.
typedef union {
__m128 _m128;
int32_t _i_32[4]; /* unions are initialized by its first member */
float _float[4];
} vecfloat_union;
This is how these unions are used in most examples that I found.
With _m128 being the first line the crash still happens with
or without the attribute.
Also, do you have any idea what this comment in there wants to tell us?
I guess this is a hint for this initialization:
-const vecfloat_union fabs_mask = {{ 0x7FFF, 0x7FFF, 0x7FFF,
0x7FFF }};
This could be probably more explicit (but less portable)
by doing something like this:
+const vecfloat_union fabs_mask = { ._i_32 = { 0x7FFF, 0x7FFF,
0x7FFF, 0x7FFF } };
With this, reordering the members of the union does not affect audio output.
You could even drop the _i_32[] member, it is not used in the code.
Maybe the compiler recognized that and somehow optimized that out,
messing the alignment thereby?
Removing _i_32 seems to initialize the union differently and therefore
the result is different.
With _i_32 removed (and the alignment 0x20) audio is not working anymore.
Kind regards,
Bernhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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, 0x7FFF, 0x7FFF }};
const __m128 vec_fabs_mask __attribute__((aligned(16),packed)) =
_mm_loadu_ps(fabs_mask._float[0]);
vecfloat_union vec_xrpow_max __attribute__((aligned(16),packed));
vecfloat_union vec_sum __attribute__((aligned(16),packed));
vecfloat_union vec_tmp __attribute__((aligned(16),packed));
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I.
-I../../libmp3lame -I../../mpglib -I../.. -D_FORTIFY_SOURCE=2 -msse -O3
-fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -fschedule-insns2
-fbranch-count-reg -fforce-addr -march=i586 -mtune=native -Wall -pipe -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -c xmm_quantize_sub.c
-fPIC -DPIC -o .libs/liblamevectorroutines_la-xmm_quantize_sub.o
xmm_quantize_sub.c: In function 'init_xrpow_core_sse':
xmm_quantize_sub.c:64:5: warning: 'packed' attribute ignored [-Wattributes]
const vecfloat_union fabs_mask __attribute__((aligned(16),packed)) =
{{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
^
xmm_quantize_sub.c:65:5: warning: 'packed' attribute ignored [-Wattributes]
const __m128 vec_fabs_mask __attribute__((aligned(16),packed)) =
_mm_loadu_ps(fabs_mask._float[0]);
^
xmm_quantize_sub.c:66:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_xrpow_max __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c:67:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_sum __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c:68:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_tmp __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c: In function 'fht_SSE2':
xmm_quantize_sub.c:172:20: warning: variable 'v_s2' set but not used
[-Wunused-but-set-variable]
__m128 v_s2;
^
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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/pkg-multimedia-maintainers
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 - enable and start icecast2 (/etc/default/icecast2) - get a mp3 file and put it to current directory as test.mp3 - create test.sh - start liquidsoap in debugger gdb --args /usr/bin/liquidsoap test.sh content of test.sh: #!/usr/bin/liquidsoap set(log.file.path,/dev/stdout) myplaylist = single(test.mp3) output.icecast(%mp3, host = localhost, port = 8000, password = hackme, mount = basic-radio.ogg, myplaylist) (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #1 0xb76d2ebf in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #2 0xb76d65e6 in CBR_iteration_loop () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #3 0xb76c3e27 in lame_encode_mp3_frame () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #4 0xb76c8e4f in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #5 0xb76c9b48 in lame_encode_buffer_float () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #6 0xb781cf77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #7 0xb781b72f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0x0820b06f in camlOutput__f_1354 () #9 0x0820b0c5 in camlOutput__fun_1740 () #10 0x0820b7dd in camlOutput__fun_1600 () #11 0x08257c6f in camlClock__fun_1848 () #12 0x08310b3c in camlList__fold_left_1073 () #13 0x08258740 in camlClock__fun_1813 () #14 0x082582a5 in camlClock__loop_1351 () #15 0x08258daa in camlClock__fun_2074 () #16 0x082703e3 in camlTutils__fun_1346 () #17 0x08307ac8 in camlThread__fun_1081 () #18 0x083612fa in caml_start_program () #19 0x0834a675 in ?? () #20 0xb7f1befb in start_thread (arg=0x79e8b781) at pthread_create.c:309 #21 0xcde0b850 in ?? () #22 0x79e8b781 in ?? () #23 0x8350b45b in ?? () #24 0x8dc314c4 in ?? () #25 0x00b6 in ?? () #26 0x27bc8d00 in ?? () #27 0x in ?? () Building libmp3lame0 with debug information: - export DEB_BUILD_OPTIONS=nostrip - apt-get build-dep libmp3lame0 - apt-get source libmp3lame0 - dpkg-buildpackage -b - dpkg -i libmp3lame0_*.deb - gdb --args /usr/bin/liquidsoap test.sh Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb49ffb40 (LWP 20251)] init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 73 vec_xrpow_max._m128 = _mm_set_ps1(0); (gdb) bt #0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 #1 0xb76cf71f in init_xrpow (gfc=0x87318d0, cod_info=0x8731a00, xrpow=0xb49fa6f4) at quantize.c:127 #2 0xb76d2cc6 in CBR_iteration_loop (gfc=0x87318d0, pe=0xb49fb0c4, ms_ener_ratio=0xb49fb09c, ratio=0xb49fd06c) at quantize.c:2034 #3 0xb76c0c37 in lame_encode_mp3_frame (gfc=gfc@entry=0x87318d0, inbuf_l=0x873e48c, inbuf_r=0x87422cc, mp3buf=mp3buf@entry=0xb4a081b9 , mp3buf_size=mp3buf_size@entry=8988) at encoder.c:518 #4 0xb76c5a22 in lame_encode_buffer_sample_t (mp3buf_size=9405, mp3buf=0xb4a081b9 , nsamples=optimized out, gfc=optimized out) at lame.c:1786 #5 lame_encode_buffer_template (gfp=gfp@entry=0x865f580, buffer_l=buffer_l@entry=0xb4a048e8, buffer_r=buffer_r@entry=0xb4a06480, nsamples=nsamples@entry=1764, mp3buf=mp3buf@entry=0xb4a08018 \377\373\220D, mp3buf_size=mp3buf_size@entry=9405, pcm_type=pcm_type@entry=pcm_float_type, aa=aa@entry=1, norm=norm@entry=1) at lame.c:1897 #6 0xb76c6648 in lame_encode_buffer_float (gfp=0x865f580, pcm_l=0xb4a048e8, pcm_r=0xb4a06480, nsamples=1764, mp3buf=0xb4a08018 \377\373\220D, mp3buf_size=9405) at lame.c:1918 #7 0xb7819f77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0xb781872f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #9 0x0820b07f in camlOutput__f_1354 () #10 0x0820b0d5 in camlOutput__fun_1740 () #11 0x0820b7ed in camlOutput__fun_1600 () #12 0x08257c7f in camlClock__fun_1848 () #13 0x08310b4c in camlList__fold_left_1073 () #14 0x08258750 in camlClock__fun_1813 () #15 0x082582b5 in camlClock__loop_1351 () #16 0x08258dba in camlClock__fun_2074 () #17 0x082703f3 in camlTutils__fun_1346 () #18 0x08307ad8 in camlThread__fun_1081 () at thread.ml:37 #19 0x08360506 in caml_start_program () #20 0x0834a6b4 in caml_thread_start () #21 0xb7f18efb in start_thread (arg=0x85e8b781) at pthread_create.c:309 #22 0x9de0b850 in ?? () #23 0x85e8b781 in ?? () #24 0x8350b47d in ?? () #25 0x8dc314c4 in ?? () #26 0x00b6 in ?? () #27 0x27bc8d00 in ?? () #28 0x in ?? () (gdb) bt full 1 #0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 i = optimized out tmp_max = 0 tmp_sum = 0 upper4 = 572
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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) versions 20 days ago. (amd64 did not show the fault) Ack, I couldn't reproduce it on my amd64 system as well. I tried a little further and was able to reproduce the crash in a Jessie i386 chroot on a 64bit-kernel too, so probably we can rule out a qemu bug. (Had proc not bind-mounted into chroot.) (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 So, this seems to be a bug in SSE code. Which means that either the code itself is buggy or your system does not support SSE instructions at all (though the latter should throw a SIGILL instead of a SIGSEGV). = 0xb76df6c9 init_xrpow_core_sse+105:movaps %xmm0,0x20(%esp) Yes, this movaps seems to be a SSE instruction. Also the changes in the previous patch should not change the instructions but only the alignment of the memory the instructions operate on. And if that is the case, with proper alignment it is working. But probably there is a better way to convince gcc to align the memory ... Would both of you please tell my the content of /proc/cpuinfo? In the qemu VM (qemu-system-x86_64 --enable-kvm -cpu host): benutzer@debian:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 microcode : 0x165 cpu MHz : 2600.000 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow extd_apicid pni cx16 x2apic hypervisor lahf_lm cmp_legacy svm cr8_legacy 3dnowprefetch vmmcall bogomips: 5200.00 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: On the host not inside chroot: root@rechner:/home/bernhard# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 cpu MHz : 2600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv vmmcall bogomips: 5223.84 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps (the same for the second core) Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#783082: video players crash with 'illegal instruction' on i586
Hello Fabian, hello Sebastian,
as I tried to get a minimal example which shows this impossible
constraints error I saw that a removal of a seemingly unrelated memset
made the error go away.
Therefore I tried replacing this memset by a for loop and an assignment
and that worked too. At least a package built in my i386-chroot compiled
successfully and the package did not lead to a crash inside the
i386-qemu-VM (not tested on real hardware).
So probably this could be a better workaround.
Attached you find for completeness all three changes, the first 2 are
the same as the last time.
Kind regards,
Bernhard
PS.: If you think this is relevant to the upstream libav bug #850, could
you please forward it?
--- libav-11.3/debian/confflags 2015-01-17 18:25:07.0 +
+++ try2/libav-11.3/debian/confflags 2015-04-23 23:27:54.279081295 +
@@ -180,7 +180,7 @@ shared_build_confflags += --enable-share
shared_build_confflags += --disable-static
# i386 shared builds must be optimized for 586, cf. #728928, #688384
ifeq ($(DEB_HOST_ARCH),i386)
-shared_build_confflags += --cpu=586
+shared_build_confflags += --cpu='i586'
endif
## specific to arm architectures
From 9030c58a780a02fb8256cb75cd39275eaad786d1 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka miku...@artax.karlin.mff.cuni.cz
Date: Mon, 15 Sep 2014 05:11:21 -0700
Subject: [PATCH] configure: Disable i686 for i586 and lower CPUs
---
configure |1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 6e210bb..a7b3c55 100755
--- a/configure
+++ b/configure
@@ -3296,6 +3296,7 @@ elif enabled x86; then
case $cpu in
i[345]86|pentium)
cpuflags=-march=$cpu
+disable i686
disable mmx
;;
# targets that do NOT 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 bernha...@vr-web.de
---
Bug-Debian: https://bugs.debian.org/783082
Last-Update: 2015-04-28
--- libav-11.3.orig/libavcodec/h264_cabac.c
+++ libav-11.3/libavcodec/h264_cabac.c
@@ -2020,7 +2020,11 @@ decode_intra_mb:
// In deblocking, the quantizer is 0
h-cur_pic.qscale_table[mb_xy] = 0;
// All coeffs are present
-memset(h-non_zero_count[mb_xy], 16, 48);
+/*memset(h-non_zero_count[mb_xy], 16, 48);*/
+/* avoiding this memset because it leads at least with gcc4.9.2 to error: 'asm' operand has impossible constraints */
+for (size_t i = 0; i 48; i++) {
+( (unsigned char*)(h-non_zero_count[mb_xy]) ) [i] = 16;
+}
h-cur_pic.mb_type[mb_xy] = mb_type;
h-last_qscale_diff = 0;
return 0;
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#783082: video players crash with 'illegal instruction' on i586
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/libavcodec.so.56.1.0 (at least the same qemu VM started with '-cpu athlon' took the version from i686/cmov) So for modern cpu users it should make no difference. Unfortunately I did all testing just in qemu, so some real hardware tests would be good. Kind regards, Bernhard Am 27.04.2015 um 12:23 schrieb Fabian Greffrath: Am Sonntag, den 26.04.2015, 14:17 +0200 schrieb Fabian Greffrath: I think we should apply them to the libav package for a stable point release. Opinions? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#783082: Aw: Re: linux-image-3.16.0-4-586: video players/browsers crash with 'illegal instruction' on i586
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. Kind regards, Bernhard --- libav-11.3/debian/confflags 2015-01-17 18:25:07.0 + +++ try2/libav-11.3/debian/confflags 2015-04-23 23:27:54.279081295 + @@ -180,7 +180,7 @@ shared_build_confflags += --enable-share shared_build_confflags += --disable-static # i386 shared builds must be optimized for 586, cf. #728928, #688384 ifeq ($(DEB_HOST_ARCH),i386) -shared_build_confflags += --cpu=586 +shared_build_confflags += --cpu='i586' endif ## specific to arm architectures Description: Workaround to build libav for i586 with GCC 4.9 Author: Bernhard Ãbelacker bernha...@vr-web.de --- Bug: https://bugzilla.libav.org/show_bug.cgi?id=850 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783082 Last-Update: 2015-04-24 --- libav-11.3.orig/configure +++ libav-11.3/configure @@ -3941,6 +3941,15 @@ EOF check_inline_asm ebx_available '::b(0)' check_inline_asm ebx_available ':::%ebx' +# workaround for bug debian#783082 / libav#850 +# (by setting ebx unavailable we get HAVE_7REGS defined as 0 +# and C implementation of get_cabac_inline gets used) +case $cpu in +i586) +disable ebx_available +;; +esac + # check whether xmm clobbers are supported check_inline_asm xmm_clobbers ':::%xmm0' From 9030c58a780a02fb8256cb75cd39275eaad786d1 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka miku...@artax.karlin.mff.cuni.cz Date: Mon, 15 Sep 2014 05:11:21 -0700 Subject: [PATCH] configure: Disable i686 for i586 and lower CPUs --- configure |1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 6e210bb..a7b3c55 100755 --- a/configure +++ b/configure @@ -3296,6 +3296,7 @@ elif enabled x86; then case $cpu in i[345]86|pentium) cpuflags=-march=$cpu +disable i686 disable mmx ;; # targets that do NOT support nopl and conditional mov (cmov) -- 1.7.10.4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#783082: Aw: Re: linux-image-3.16.0-4-586: video players/browsers crash with 'illegal instruction' on i586
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-share shared_build_confflags += --disable-static # i386 shared builds must be optimized for 586, cf. #728928, #688384 ifeq ($(DEB_HOST_ARCH),i386) -shared_build_confflags += --cpu=586 +shared_build_confflags += --cpu='i586' endif ## specific to arm architectures But then build of libav fails for me: .../libav-11.3/libavcodec/h264_cabac.c: In function 'ff_h264_decode_mb_cabac': .../libav-11.3/libavcodec/x86/cabac.h:173:5: error: 'asm' operand has impossible constraints Also installing the -dbg packages for the shared objects shown in your backtraces would give even better results: libjavascriptcoregtk-1.0-0-dbg libqtwebkit4-dbg Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
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 current ffmpeg dev packages from unstable. Starting with an empty .xbmc and the xbmc-pvr-tvheadend-hts from testing this combination did _not_ show me a picture at all from LiveTV. Either started in windowed or full screen. From the log it seems it tries to use vdpau but could not find an obvious error for it. Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
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 now if I could get the SetFullScreen/CDecoder::OnResetDevice from kodi into xbmc, but was not successfull on it (probably one with deeper knowledge could do ...). So in the end we have these options: - turn off xrandr: affecting every video usage of xbmc (even affect non-binary-nvidia-driver users.) - switch PVR to software decoding: just affecting PVR, but probably problematic on devices not fast enough for software (raspberry?) - Let affected users change it via the confiruation interface: (at least Settings level Advanced) Settings - Video - Acceleration - Allow hardware acceleration (VDPAU) (guisettings.xml:usevdpau=false) Kind regards, Bernhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
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::CreateContext - creating decoder context And by getting to fullscreen the decoder is still destroyed, but later recreated: OnKey: backslash (0xf05c) pressed, action is ToggleFullScreen ... CVDPAU::OnLostDevice event (VDPAU) FiniVDPAUOutput ... CWinSystemX11::RefreshGlxContext: refreshing context CVDPAU::OnResetDevice event ... VDPAU::CreateContext - creating decoder context I attached a debugger to see where we come from for this OnResetDevice: (gdb) bt #0 VDPAU::CDecoder::OnResetDevice (this=0x7f5c180017e0) at VDPAU.cpp:694 #1 0x00e88458 in CWinSystemX11::SetWindow (this=this@entry=0x1b39a80, width=1680, height=optimized out, fullscreen=fullscreen@entry=true, output=DVI-D-0) at WinSystemX11.cpp:1234 #2 0x00e89235 in CWinSystemX11::SetFullScreen (this=this@entry=0x1b39a80, fullScreen=fullScreen@entry=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11.cpp:313 #3 0x00e8f5ff in CWinSystemX11GL::SetFullScreen (this=0x1b39a80, fullScreen=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11GL.cpp:212 #4 0x007ce58e in CGraphicContext::SetVideoResolutionInternal (this=this@entry=0x1b387a0, res=optimized out, res@entry=RES_DESKTOP, forceUpdate=forceUpdate@entry=false) at GraphicContext.cpp:466 #5 0x007cee56 in CGraphicContext::SetVideoResolution (this=0x1b387a0, res=RES_DESKTOP, forceUpdate=optimized out) at GraphicContext.cpp:371 #6 0x006ffa24 in CDisplaySettings::OnSettingChanging (this=0x18e90c0 CDisplaySettings::Get()::sDisplaySettings, setting=0x10) at DisplaySettings.cpp:248 #7 0x00c66a91 in CSettingsManager::OnSettingChanging (this=optimized out, setting=0x1d087a0) at SettingsManager.cpp:732 #8 0x00c5172c in CSettingString::SetValue (this=0x1d087a0, value=DESKTOP) at Setting.cpp:1272 #9 0x00c643d8 in CSettingsManager::SetString (this=0x1bb2410, id=videoscreen.screenmode, value=DESKTOP) at SettingsManager.cpp:601 #10 0x006ee169 in CSettings::SetString (this=optimized out, id=videoscreen.screenmode, value=DESKTOP) at Settings.cpp:396 #11 0x006fe083 in CDisplaySettings::SetCurrentResolution (this=0x18e90c0 CDisplaySettings::Get()::sDisplaySettings, resolution=resolution@entry=RES_DESKTOP, save=save@entry=true) at DisplaySettings.cpp:358 #12 0x007cf1df in CGraphicContext::ToggleFullScreenRoot (this=0x1b387a0) at GraphicContext.cpp:1004 #13 0x00cb3ea2 in CApplication::OnAction (this=0x1b35c90, action=...) at Application.cpp:2541 ... 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 ... --- The commit message for xbmc-13 you mentioned reads like the exact opposite what I observed? --- I build a package xbmc-13 with these changes to debian/rules: - --enable-xrandr \ + --disable-xrandr \ And indeed, this version works like expected, for my short test. Kind regards, Bernhard Am 28.12.2014 um 16:32 schrieb Bálint Réczey: Hi Bernhard, 2014-12-28 14:28 GMT+01:00 Bernhard Ãbelacker bernha...@vr-web.de: 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. Well, if this was OK for DVD streams, it should be OK for PVR streams as well. BTW the original commit adding hint.software = true;: commit d75a46a9f9626be12cc486c8e7c7d9be9d216922 Author: elupus elupus@svn Date: Fri Apr 9 18:59:15 2010 + changed: only use libmpeg2 for dvd playback Side effect that vaapi/vdpau is now allowed for all mpeg2 content. git-svn-id: https://xbmc.svn.sourceforge.net/svnroot/xbmc/trunk@29147 568bbfeb-2a22-0410-94d2-cc84cf5bfa90 ... I will try to build a kodi package from your repo and report back. 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/ Kind regards, Bernhard One think were I am undecided is, my proposal is to set set software=true. But I don't know if then someone would still be able to watch via xbmc-pvr-tvheadend-hts on e.g. on a raspberry I'm hesitant a bit, too to upload the change. You may have hit a different manifestation of #769057. Looking at the code it seems compiling with xrandr disabled may make XBMC skip the
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
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 report back. Kind regards, Bernhard One think were I am undecided is, my proposal is to set set software=true. But I don't know if then someone would still be able to watch via xbmc-pvr-tvheadend-hts on e.g. on a raspberry On Sun, 28 Dec 2014 11:17:44 +0100 =?UTF-8?B?QsOhbGludCBSw6ljemV5?= bal...@balintreczey.hu wrote: Control: tags -1 pending upstream confirmed Bernhard, 2014-12-27 22:07 GMT+01:00 Bernhard Ãbelacker bernha...@vr-web.de: 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 are relevant (as far as I think): - using a VDPAU enabled graphics card with needed vdpau libraries installed - having no .xbmc directory in home directory (just for reproducability) - starting xbmc - activating Tvheadend HTSP Client addon - playing a broadcast through LiveTv in windowed mode (in my case no HD channel) (plays fine in the partial screen with channels on the side as filling the whole window too.) - switching to fullscreen mode (e.g. altgr+backslash) - video stays black, audio still playing, other menus and control elements also visible. I did some further investigations: ... I opened it as important, but probably you want to increase it to serious if you see fit. If yes probably on way of action for jessie would be to add this hint.software = true; in DVDPlayer.cpp:3003 as it is already the case for DVD playback. Thank you for the detailed investigation and the proposed fix. The fix will be included in the next upload. There is no need for increasing severity. I will ask for a freeze exception and I think Release Managers will approve it. I also checked latest upstream code but the patched part has been removed and without the HW to test the change I'm not comfortable with adapting the patch. I have packaged Kodi already [1] but it is waiting in the NEW queue right now. Could you please check if Kodi needs the fix, too and adapt the patch if needed? If you could upstream the Kodi fix yourself and ping me to back-port the fix I would be happy, too. Cheers, Balint [1] https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
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 are relevant (as far as I think): - using a VDPAU enabled graphics card with needed vdpau libraries installed - having no .xbmc directory in home directory (just for reproducability) - starting xbmc - activating Tvheadend HTSP Client addon - playing a broadcast through LiveTv in windowed mode (in my case no HD channel) (plays fine in the partial screen with channels on the side as filling the whole window too.) - switching to fullscreen mode (e.g. altgr+backslash) - video stays black, audio still playing, other menus and control elements also visible. I did some further investigations: when changing videoplayer.usevdpau to false (e.g. .xbmc/userdata/guisettings.xml, usevdpaufalse/usevdpau) then the video plays normal after switching to fullscreen. I compared it to playing a DVD and I think in CDVDPlayer::OpenVideoStream (which is also used for my non HD channel) the hint.software = true; makes the difference. (DVDPlayer.cpp:2991, if DVDSTREAM_TYPE_DVD.) I made a version which adds this hint.software = true; also to the next paragraph relevant for the addon. (DVDPlayer.cpp:3003, if DVDSTREAM_TYPE_PVRMANAGER) Then this black screen issue is not visible anymore. I think this happens because on switching to fullscreen some X11 resources get notifed in CWinSystemX11::OnLostDevice and therefore the VDPAU::CDecoder::FiniVDPAUOutput method is called. Later every CDecoder::Decode call returns VC_ERROR because m_vdpauConfigured get never true again. (gdb) bt #0 VDPAU::CDecoder::FiniVDPAUOutput (this=0x7f6a840a48c0) at VDPAU.cpp:814 #1 0x008bc091 in VDPAU::CDecoder::OnLostDevice (this=0x7f6a840a48c0) at VDPAU.cpp:700 #2 0x00eb2b0e in CWinSystemX11::OnLostDevice (this=this@entry=0x28b0680) at WinSystemX11.cpp:531 #3 0x00eb3152 in CWinSystemX11::SetFullScreen (this=this@entry=0x28b0680, fullScreen=fullScreen@entry=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11.cpp:204 #4 0x00eaa808 in CWinSystemX11GL::SetFullScreen (this=0x28b0680, fullScreen=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11GL.cpp:208 #5 0x007d106e in CGraphicContext::SetVideoResolution (this=0x28aeec0, res=optimized out, forceUpdate=optimized out) at GraphicContext.cpp:450 #6 0x007024bc in CDisplaySettings::OnSettingChanging (this=0x18f8800 CDisplaySettings::Get()::sDisplaySettings, setting=0x10) at DisplaySettings.cpp:248 #7 0x00c960ad in CSettingsManager::OnSettingChanging (this=optimized out, setting=0x2a78520) at SettingsManager.cpp:716 #8 0x00c8427c in CSettingString::SetValue (this=0x2a78520, value=DESKTOP) at Setting.cpp:1182 #9 0x00c945a8 in CSettingsManager::SetString (this=0x2926d80, id=videoscreen.screenmode, value=DESKTOP) at SettingsManager.cpp:585 #10 0x006f2519 in CSettings::SetString (this=optimized out, id=videoscreen.screenmode, value=DESKTOP) at Settings.cpp:562 #11 0x0070123a in CDisplaySettings::SetCurrentResolution (this=0x18f8800 CDisplaySettings::Get()::sDisplaySettings, resolution=resolution@entry=RES_DESKTOP, save=save@entry=true) at DisplaySettings.cpp:308 #12 0x007d1a3f in CGraphicContext::ToggleFullScreenRoot (this=0x28aeec0) at GraphicContext.cpp:988 #13 0x00cdf702 in CApplication::OnAction (this=0x28acb80, action=...) at Application.cpp:2569 #14 0x00ce1848 in CApplication::OnKey (this=0x28acb80, key=...) at Application.cpp:2517 #15 0x00ce2a34 in CApplication::OnEvent (newEvent=...) at Application.cpp:473 #16 0x01290848 in CWinEventsSDL::MessagePump (this=optimized out) at WinEventsSDL.cpp:390 #17 0x00ce3c93 in CApplication::FrameMove (this=0x28acb80, processEvents=optimized out, processGUI=optimized out) at Application.cpp:2953 #18 0x00d87b3a in CXBApplicationEx::Run (this=0x28acb80) at XBApplicationEx.cpp:140 #19 0x00d8e43b in XBMC_Run (renderGUI=optimized out) at xbmc.cpp:69 #20 0x006903a8 in main (argc=1, argv=0x7fffcdba4418) at main.cpp:76 1099return VC_ERROR; (gdb) print m_vdpauConfigured $1 = false (gdb) bt #0 VDPAU::CDecoder::Decode (this=0x7f448950, avctx=0x7f448402ad00, pFrame=0x7f448402d820) at VDPAU.cpp:1099 #1 0x008b51f2 in CDVDVideoCodecFFmpeg::Decode (this=0x7f448402ab80, pData=optimized out, iSize=optimized out, dts=optimized out, pts=optimized out) at DVDVideoCodecFFmpeg.cpp:544 #2 0x01073c0d in CDVDPlayerVideo::Process (this=0x44e9fb8) at DVDPlayerVideo.cpp:550 #3 0x0132d35f in CThread::Action (this=0x44e9fb8) at Thread.cpp:220 #4 0x0132d619 in CThread::staticThread (data=0x44e9fb8) at Thread.cpp:130 #5 0x7f44e62a80a4 in start_thread
Bug#753528: Fwd: Bug#753528: libav-tools: Floating point exception is raised when recording vom video4linux2
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#715590: [Mayhem] Bug report on m2vrequantiser: M2VRequantiser crashes with exit status 139
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[])
if (argc 5) { USAGE }
delta_bright = atoi(argv[4]);
#else
- if (argc 2) { USAGE }
+ if (argc 3) { USAGE }
#endif
fact_x = atof(argv[1]);
sscanf(argv[2], %lld, orim2vsize);
The sscanf above accesses argv on index 2 (third element) - this way it it
crashing.
This is intended to be prevented in the changed line where I think the
comparison
with argc is off by one.
Kind regards,
Bernhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#753528: libav-tools: Floating point exception is raised when recording vom video4linux2
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.
A Workaround is to specify the norm as prefix to the target (instead -target
dvd use -target pal-dvd).
Attached patch avoids the exception so avconv can print the message that the
user have to specify manualle the norm.
Console output:
$ export LANG=C
$ avconv -f alsa -i hw:0,0 -f video4linux2 -channel 2 -i /dev/video0 -qscale 8
-target dvd out.mpeg
avconv version 10.2-6:10.2-1, Copyright (c) 2000-2014 the Libav developers
built on Jun 28 2014 13:45:13 with gcc 4.9 (Debian 4.9.0-9)
[alsa @ 0x20f5900] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, alsa, from 'hw:0,0':
Duration: N/A, start: 90.295177, bitrate: N/A
Stream #0.0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
[video4linux2 @ 0x2106720] Estimating duration from bitrate, this may be
inaccurate
Input #1, video4linux2, from '/dev/video0':
Duration: N/A, start: 90.796022, bitrate: 124416 kb/s
Stream #1.0: Video: rawvideo, yuv420p, 720x576, 124416 kb/s, 25 fps, 1000k
tbn
Floating point exception
$ gdb --args avconv -f alsa -i hw:0,0 -f video4linux2 -channel 2 -i /dev/video0
-qscale 8 -target dvd out.mpeg
(gdb) run
Program received signal SIGFPE, Arithmetic exception.
0x0040c4bb in opt_target (optctx=0x7fffda90, opt=optimized out,
arg=optimized out) at /build/libav-KCSjC9/libav-10.2/avconv_opt.c:1731
1731/build/libav-KCSjC9/libav-10.2/avconv_opt.c: No such file or directory.
(gdb) bt
#0 0x0040c4bb in opt_target (optctx=0x7fffda90, opt=optimized
out, arg=optimized out) at /build/libav-KCSjC9/libav-10.2/avconv_opt.c:1731
#1 0x00409f07 in write_option (arg=0x7fffe49f dvd,
opt=optimized out, po=0x6212c0 options+1600, optctx=0x7fffda90) at
/build/libav-KCSjC9/libav-10.2/cmdutils.c:287
#2 parse_optgroup (optctx=0x7fffda90, g=0x6ba350) at /build/libav-
KCSjC9/libav-10.2/cmdutils.c:387
#3 0x00410088 in open_files (l=optimized out, l=optimized out,
open_file=optimized out, inout=optimized out) at /build/libav-
KCSjC9/libav-10.2/avconv_opt.c:2083
#4 avconv_parse_options (argc=0, argv=0x0) at /build/libav-
KCSjC9/libav-10.2/avconv_opt.c:2135
#5 0x00405785 in main (argc=16, argv=0x7fffe0d8) at /build/libav-
KCSjC9/libav-10.2/avconv.c:2455
(gdb) info locals
c = 0x6d1b40
i = optimized out
j = optimized out
fr = optimized out
o = 0x7fffda90
norm = UNKNOWN
frame_rates = {0x41a5de 25, 0x41a977 3/1001, 0x41a982 24000/1001}
(gdb) display c-time_base
1: c-time_base = {num = 0, den = 1}
Patch:
--- libav-10.2.orig/avconv_opt.c
+++ libav-10.2/avconv_opt.c
@@ -1728,6 +1728,8 @@ static int opt_target(void *optctx, cons
AVCodecContext *c =
input_files[j]-ctx-streams[i]-codec;
if (c-codec_type != AVMEDIA_TYPE_VIDEO)
continue;
+if (!c-time_base.num)
+continue;
fr = c-time_base.den * 1000 / c-time_base.num;
if (fr == 25000) {
norm = PAL;
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (990, 'testing-updates'), (990, 'testing'), (500,
'testing-proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libav-tools depends on:
ii dpkg 1.17.10
ii libavcodec55 6:10.2-1
ii libavdevice546:10.2-1
ii libavfilter4 6:10.2-1
ii libavformat556:10.2-1
ii libavresample1 6:10.2-1
ii libavutil53 6:10.2-1
ii libc62.19-4
ii libsdl1.2debian 1.2.15-9
ii libswscale2 6:10.2-1
ii libvdpau10.7-2
ii libx11-6 2:1.6.2-2
libav-tools recommends no packages.
Versions of packages libav-tools suggests:
ii frei0r-plugins 1.4-3
-- no debconf information
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
