Bug#734100: Fixed in VLC 3.0
Hello, Sekmadienis 01 Lapkritis 2015 18:10:54 rašė: > tags 734100 + fixed-upstream > thanks > > This should be fixed in upstream VLC 3.0. Thanks a lot. Could this package be backported to current packages? This problem has been annoying me for a long time and lately it got only worse. Unfortunately, increasing dmix buffer has some unwanted side effects in other apps (audio-video desync). -- Modestas Vainius <modes...@vainius.eu> ___ 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#734100: Fixed in VLC 3.0
Hello,
Sekmadienis 01 Lapkritis 2015 22:43:17 rašė:
> reopen 734100
> thanks
>
> On Sunday 01 November 2015 22:03:41 Modestas Vainius wrote:
> > Hello,
> >
> > Sekmadienis 01 Lapkritis 2015 18:10:54 rašė:
> > > tags 734100 + fixed-upstream
> > > thanks
> > >
> > > This should be fixed in upstream VLC 3.0.
> >
> > Thanks a lot. Could this package be backported to current packages?
>
> VLC 3.0 is nowhere near release at this point in time. This is up to the
> Debian Multimedia team, not me, but I would not advise uploading it to
> unstable. And I do not know if there are enough human resources to maintain
> an extra VLC 3.0 in experimental.
What I really meant was backporting of those patches to 2.2.1 packages.
Patches seemed pretty "short" at the glance hence I tried to do that myself.
47f74a83c161173b0d15e95dab8ceb7c97de51b4.patch was strightforward, applies
cleanly.
Unfortunately, 6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a wasn't that
strightforward. Had to do some modifications: 1st hunk already there in 2.2.1,
adapt DecoderPlayAudio hunks and remove the last 2 hunks (from DecoderThread
routine) since those locks are not present there in 2.2.1 codebase. I attach
both patches.
The end result builds fine and seems to fix the problem on my machine. Not
sure if patches break anything on 2.2.1 (i.e. if they need anything else from
3.0.0 to work properly). Rémi, maybe you could comment on that?
>
> > This
> > problem has been annoying me for a long time and lately it got only worse.
> > Unfortunately, increasing dmix buffer has some unwanted side effects in
> > other apps (audio-video desync).
>
> Either those other apps are buggy, or dmix is buggy. The audio delay value
> should account for the dmix buffer.
>
> Also, PulseAudio is better at mixing multiple apps.
Well, yeah, but I kind of dislike PulseAudio since its inception. I'm slowly
warming up to the idea that I may have to use it one day but that time has not
come yet...
--
Modestas Vainius <modes...@vainius.eu>diff --git a/modules/audio_output/alsa.c b/modules/audio_output/alsa.c
index 2d1f99e..4e9fd53 100644
--- a/modules/audio_output/alsa.c
+++ b/modules/audio_output/alsa.c
@@ -495,6 +495,15 @@ static int Start (audio_output_t *aout, audio_sample_format_t *restrict fmt)
}
sys->rate = fmt->i_rate;
+#if 1 /* work-around for period-long latency outputs (e.g. PulseAudio): */
+param = AOUT_MIN_PREPARE_TIME;
+val = snd_pcm_hw_params_set_period_time_near (pcm, hw, , NULL);
+if (val)
+{
+msg_Err (aout, "cannot set period: %s", snd_strerror (val));
+goto error;
+}
+#endif
/* Set buffer size */
param = AOUT_MAX_ADVANCE_TIME;
val = snd_pcm_hw_params_set_buffer_time_near (pcm, hw, , NULL);
@@ -503,14 +512,22 @@ static int Start (audio_output_t *aout, audio_sample_format_t *restrict fmt)
msg_Err (aout, "cannot set buffer duration: %s", snd_strerror (val));
goto error;
}
-
-param = AOUT_MIN_PREPARE_TIME;
+#if 0
+val = snd_pcm_hw_params_get_buffer_time (hw, , NULL);
+if (val)
+{
+msg_Warn (aout, "cannot get buffer time: %s", snd_strerror(val));
+param = AOUT_MIN_PREPARE_TIME;
+}
+else
+param /= 2;
val = snd_pcm_hw_params_set_period_time_near (pcm, hw, , NULL);
if (val)
{
msg_Err (aout, "cannot set period: %s", snd_strerror (val));
goto error;
}
+#endif
/* Commit hardware parameters */
val = snd_pcm_hw_params (pcm, hw);
--- a/src/input/decoder.c
+++ b/src/input/decoder.c
@@ -1180,6 +1180,8 @@ static void DecoderPlayAudio( decoder_t
if( unlikely(p_owner->b_paused != b_paused) )
continue; /* race with input thread? retry... */
+vlc_mutex_unlock( _owner->lock );
+
if( p_aout == NULL )
b_reject = true;
@@ -1199,7 +1201,6 @@ static void DecoderPlayAudio( decoder_t
break;
}
-vlc_mutex_unlock( _owner->lock );
}
static void DecoderDecodeAudio( decoder_t *p_dec, block_t *p_block )
@@ -1961,11 +1962,10 @@ static int aout_update_format( decoder_t
/* Parameters changed, restart the aout */
vlc_mutex_lock( _owner->lock );
-
-aout_DecDelete( p_owner->p_aout );
p_owner->p_aout = NULL;
-
vlc_mutex_unlock( _owner->lock );
+aout_DecDelete( p_owner->p_aout );
+
input_resource_PutAout( p_owner->p_resource, p_aout );
}
___
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#802886: vlc: QT Interface wont full screen or renders only a small portion of the video
Control: tags -1 upstream Hello, Šeštadienis 24 Spalis 2015 11:34:11 rašė: > When using the QT interface in VLC, I can no longer doubleclick a video and > full screen it. When playing a video parts of it are masked off/cropped . > So only a small area approximatly 530x290 is visable. I've disabled overlay > with no effect. Resizing the video into the small visable area is the only > way to see the entire video uncropped. > > If I however run the command cvlc the video the full size and > have no issue fullscreening the video. It seems that the issue might be > with QT, but I am unsure how to figure out what the offending package > maybe. This was caused by upgrade from Qt 5.4 to 5.5. It is either vlc [1] or Qt 5.5 [2] issue (latter being more likely). I leave it up to maintainer to decide whether to reassign. However, from a user POV, vlc is basically unusable for video with this bug in place. There are two bugs here though: 1) double-click not working for full-screening. Can be worked around by setting QT_XCB_NO_XI2_MOUSE=1 when starting vlc [3]: $ QT_XCB_NO_XI2_MOUSE=1 vlc 2) video is only partially visible. Not aware of any workarounds yet. [1] https://trac.videolan.org/vlc/ticket/15663 [2] https://bugreports.qt.io/browse/QTBUG-48321 [3] https://trac.videolan.org/vlc/ticket/15663#comment:3 -- Modestas Vainius <modes...@vainius.eu> ___ 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#679542: Each upload (even -2 -3 etc) is a transition?
Source: libav Version: 6:0.8.3-4 Severity: important Hello, could you explain why each -2 -3 etc. upload bumps shlibs to the current debian revision as opposed to the current upstream version? This effectly makes each debian revision of libav a small transition. For example, now amarok [1] will have to wait and depend on libav to migrate testing for no good reason at all. I highly recommend at least replacing dh_makeshlibs -p$$pkg -V$$pkg (= $(DEB_VERSION)); with dh_makeshlibs -p$$pkg -V in debian/rules or better bringing everything to the next level with symbol files. [1] http://packages.qa.debian.org/a/amarok.html -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (110, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ 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#615742: binutils gold fix for libdrumstick
Hello, On antradienis 01 Kovas 2011 08:06:18 Pedro Lopez-Cabanillas wrote: You are wrong assuming that the variable QT_X11_X11_LIBRARY is deprecated in CMake 2.8.1, or it is not available anymore. The CMake macros were reorganized, and now this variable is set in Qt4ConfigDependentSettings.cmake [2] (lines 259-271) which is included from FindQt4.cmake [3], line 1035, and it is also documented [4]. The attached CMakeLists.txt test file should work as expected. Here is the output in my development machine: $ cmake . -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found. -- Found Qt-Version 4.6.3 (using /usr/bin/qmake) -- Looking for _POSIX_TIMERS -- Looking for _POSIX_TIMERS - found -- QT_X11_X11_LIBRARY contains: /usr/lib/libX11.so -- Configuring done -- Generating done I don't see anything in the code you referred to which would define QT_X11_X11_LIBRARY variable. If anything it shows that X11_X11_LIB is being used. You're right that current debian patch (courtesy by ubuntu) is a pure hack and you nailed its deficiencies well. But you have the bug on your hands nevertheless, it's not debian-specific bug. In order to fix this properly, do find_package(X11) and use a proper variable which expands to X11 library (iirc, X11_X11_lib). I don't agree with that. You are proposing to patch this package, but every build system depending on CMake and the variable QT_X11_X11_LIBRARY would need a similar patch. Won't be better a common solution that works for all of them? In my opinion it would be preferred to patch Debian's CMake package. Oh please. Debian DOES NOT patch cmake in this Qt4 code or anything remotely related. Period. We actively push cmake patches upstream and our 2.8.4 is an almost pure vanilla version with a couple of minor changes now. QT_X11_X11_LIBRARY was removed in favour of X11_X11_LIB and that's how it is (I don't feel like chasing when). Just get over it. I feel like you are not listening, but it's your right. So until you wake up, Debian maintainer will have to patch libdrumstick. However, I just suggest him doing s/QT_X11_X11_LIBRARY/X11_X11_LIB/ instead of current patch-hack that is of really poor quality and has some bad side effects. Sorry for a bit rude tone, but I really feel that I spent more time on this I have on my hands. Such a long debate for a single variable? Uch... -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#615742: binutils gold fix for libdrumstick
Hello, On antradienis 01 Kovas 2011 17:28:25 Adrian Knoth wrote: On Tue, Mar 01, 2011 at 11:57:13AM +0200, Modestas Vainius wrote: Hi! I feel like you are not listening, but it's your right. So until you wake up, Debian maintainer will have to patch libdrumstick. However, I just suggest him doing s/QT_X11_X11_LIBRARY/X11_X11_LIB/ instead of current patch-hack that is of really poor quality and has some bad side effects. I've crafted a libdrumstick patch as you suggested: http://git.debian.org/?p=pkg-multimedia/libdrumstick.git;a=commitdiff;h=08 a4577b83269785de0fd2dcd7587a890fdfd6fd It works, though I'm by far no cmake expert, so this might not be the best solution. You can omit find_package(X11) as Qt4ConfigDependentSettings.cmake should call it [1]. Other than that, it's ok. Ship it! [1] See /usr/share/cmake-2.8/Modules/Qt4ConfigDependentSettings.cmake:98 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#615742: binutils gold fix for libdrumstick
Hello, On antradienis 01 Kovas 2011 01:06:22 Pedro Lopez-Cabanillas wrote: I've wrote Drumstick, and I know for sure that the target vpiano uses QT_X11_X11_LIBRARY for linking. The bug report says that when linking this target in Debian, it fails saying that -lX11 is required. I suspect that there may be a problem in Debian around this matter. It works fine in some other distros. Nop, you misunderstood the bug a bit. It does link on Debian or 0.5.0-1 would not be in Debian testing. gold linker enables --no-add-needed by default and that's typically the reason for packages to fail linking with it. Now ubuntu enabled --as-needed by default and gcc maintainer is pushing this to debian proper too. So yes, the reason it's failing is that QT_X11_X11_LIBRARY is undefined and -- no-add-needed no longer looks the library up recursively. The code which sets this variable was removed in cmake 2.8.1 by [1]. QT_X11_X11_LIBRARY falls out of FindQt4.cmake scope. You're right that current debian patch (courtesy by ubuntu) is a pure hack and you nailed its deficiencies well. But you have the bug on your hands nevertheless, it's not debian-specific bug. In order to fix this properly, do find_package(X11) and use a proper variable which expands to X11 library (iirc, X11_X11_lib). 1.http://cmake.org/gitweb?p=cmake.git;a=commit;h=0f457937f4f5cbdaedaaec00849cb7a050bbc0f4 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
