GNOME Bugzilla – Bug 599105
[baseaudiosink] Remove pulsesink < 0.10.17 hack after gst-plugins-good release
Last modified: 2009-10-29 06:24:04 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/456016 "1) Open video 2) Play it, finish watching it 3) Hit play again 4) No audio, just video 1) Open video 2) Finish watching 1, go to next item in playlist 3) Video plays, no audio libgstreamer0.10-0 0.10.25-2" The bug happens on current karmic
Created attachment 145894 [details] GST_DEBUG=3 debug log
Confirming the issue there on karmic, the second video seems to start playing sound with a delay of some seconds and the audio and video stayed desynchonized with that delay
I've found that commit 42ee5e22 (removal of the ringbuffer compensation code) breaks the pulse output plugin. in gst-plugins-good. I'm using the latest released version of gstreamer/-base (0.10.25) so the companion commit for adding the ringbuffer code to the baseaudiosink is there, but it's not helping. The symptoms are: Fist track in totem will play fine, and allow seeking happily. If you skip (or it advances naturally) there is a massive delay before it starts playing (if at all), when it is playing if you try and seek, you get the massive delay again (and you cannot hear the blip-de-blip-de-blip of fast forwarded audio as you did on the first track. Reverting this commit solves the problem. I'm not sure if this is the same problem you're getting in Karmic tho', because it does not say whether the pulse plugin has had some of the upstream commits backported into the official package. Certainly when I looked and tested the upstream commits when pulling in some changes for Mandriva, this commit stood out as being a problem as soon as I tested it. Hope this helps.
Created attachment 145967 [details] [review] 01_baseaudiosink-remove-pulsesink-hack.patch Most probably this will be fixed by this patch. Problem was, that the code that was removed by the above mentioned commit will only be enabled in baseaudiosink if a new enough pulsesink is found and disabled for older versions. Thus backporting the pulsesink changes without adjusting baseaudiosink will break. Please someone confirm this, I can't reproduce the problem anymore but I couldn't reproduce it reliable before neither.
*** Bug 599150 has been marked as a duplicate of this bug. ***
confirming the fix solves the issue described there and dvd playing issues
*** Bug 599107 has been marked as a duplicate of this bug. ***
Great, then this is not really a bug ;) But let's move this to gst-plugins-base and mark it as blocker for 0.10.26 to make sure that the pulsesink hack gets removed after gst-plugins-good 0.10.17 was released.
> But let's move this to gst-plugins-base and mark it as blocker for 0.10.26 to > make sure that the pulsesink hack gets removed after gst-plugins-good 0.10.17 > was released. I'm not sure if we can really do this. Shouldn't it be possible to drop in a core/base 0.10.26/27/28 with an older gst-plugins-good? Also, in retrospect I think maybe we should have worked around this differently, by making pulsesink use g_object_set_user_data(pulsesink, "skip-timestamp-offsetting", GINT_TO_POINTER(1)) or something like that, but I guess there's not much reason to change that now.
(In reply to comment #9) > > But let's move this to gst-plugins-base and mark it as blocker for 0.10.26 to > > make sure that the pulsesink hack gets removed after gst-plugins-good 0.10.17 > > was released. > > I'm not sure if we can really do this. Shouldn't it be possible to drop in a > core/base 0.10.26/27/28 with an older gst-plugins-good? Yes - the intention was that the 'hack' would stick around until 1.0. > Also, in retrospect I think maybe we should have worked around this > differently, by making pulsesink use g_object_set_user_data(pulsesink, > "skip-timestamp-offsetting", GINT_TO_POINTER(1)) or something like that, but I > guess there's not much reason to change that now. You're right - that's a nicer way to handle this stuff in the future.
So can we close this as OBSOLETE then?
*** Bug 599670 has been marked as a duplicate of this bug. ***
If distros could get some warning about work-arounds like that in the future, it would be appreciated.
(In reply to comment #11) > So can we close this as OBSOLETE then? Well, I would say NOTGNOME in this case. On our side everything is good, distros backported patches that broke something. (And yes, this stuff should really be in the release notes in the future)
*** Bug 599474 has been marked as a duplicate of this bug. ***