Build without gstreamer0.10
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Wine |
Fix Released
|
Wishlist
|
|||
wine (Debian) |
Fix Released
|
Unknown
|
|||
wine1.6 (Ubuntu) |
Fix Released
|
Medium
|
Timo Jyrinki |
Bug Description
It's a general goal to drop dependencies on gstreamer0.10 and Wine upstream doesn't seem to think enabling gst0.10 in it's current state is useful. See https:/
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #6 |
Created attachment 48035
initial work toward gstreamer 1.0, non-working
So, following patch isn't working yet and might still be buggy, but it should be a good starting point toward gstreamer 1.0.
Notes about this patch:
- I think I've got all the caps ported, but somebody should recheck
- it seems that in the old code gst_pad_
- the parts definitely done done yet are those for gst_pad_
- as for that little bit around GST_SEEK_TYPE_CUR: given the notes in gstreamer 0.10 docs, I strongly suspect this is broken in the current code, though I'm not sure if my way is the proper fix (and it would be better to query position only once, but that would complicate the later code)
Anyway, before anything here is done for real, bug 30557 needs to be fixed.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #7 |
Created attachment 48036
previous patch, corrected a bit
Just minor corrections of the previous version - no real changes, mostly stuff I've noticed thanks to colored diff of bugzilla.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #8 |
Created attachment 48037
same patch, anothe minor corection
...OK, I think this is it for trivial changes...
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #9 |
Created attachment 48148
next version, still unworking
OK, I'm not sure some of these changes are correct, but it's almost done...
except for those bufferalloc functions, which I'm can't really say just how they need to be rewritten - that GST_QUERY_
In Wine Bugzilla #31836, Mike-cchtml (mike-cchtml) wrote : | #10 |
@Rafał, are you still working on this?
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #11 |
(In reply to Michael Cronenworth from comment #5)
> @Rafał, are you still working on this?
Not really.
Given that:
- I don't know all that much about GStreamer for more than trivial ports
- I'm just about sure I've made mistakes in this patch
- some of the GStreamer 0.10 doc comments suggest that the current code is not quite correct (or at least not really working)
- I got not feedback from the devs here
I kind of given up.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #12 |
...
PS: pity this wasn't given as a GSoC idea - it's about right complexity and size for it.
In Wine Bugzilla #31836, T-tim-0 (t-tim-0) wrote : | #13 |
Hello, GStreamer developer here. If you have any particular questions about how to port some particular code, I'm happy to have a look. Do also feel free to pop into the #gstreamer IRC channel on freenode to ask questions. Some of the answers will depend on the context of the code in question of course; we don't know WINE very well or windows API, but if you point us to the code in git we should be able to figure it out.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #14 |
Hi, Tim.
Besides the (yet to be addressed) problem from bug 30557, GStreamer use in wine is contained in dlls/winegstrea
While the doc situation has improved a little bit since the time I whined about it on IRC, there's still very little live code examples of allocation queries, mostly due to most gstreamer code redirecting the issue to handlers in abstract plugins (well, base classes, if you want to get technical).
While at this time there *is* a section in http://
On a not really related note: kind of sorry, that I didn't pursue https:/
In Wine Bugzilla #31836, T-tim-0 (t-tim-0) wrote : | #15 |
Rafał, do you have any *specific* questions about the ALLOCATION query? I think you can pretty much ignore it for a first port, especially for audio it's not really that useful at all. Just use gst_buffer_new*() and be done with it. It's mostly useful for video to avoid memory copies between decode and video sinks.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #16 |
It seems I need to clarify a point - as soon as I came to conclusion, that I won't be able to port this on my own, I've pretty much dropped it. I'm chiming in here just to explain the history.
Having that said, from what little I remember about this code, gstreamer 0.10 here was using bufferalloc functions to prevent copying of allocated memory too.
Therefore gst_buffer_new*() might be insufficient, especially that this code needs to assign additional data to the buffer (IMediaSample pointer) that's being used in other callbacks.
In Wine Bugzilla #31836, Ivan Baldo (ibaldo) wrote : | #17 |
Just to note that Debian started building WINE without GStreamer support because the plan is to drop GStreamer 0.10 from the next Debian release, see https:/
Maybe GStreamer support in WINE isn't critical?
What is lost from WINE if it is built without GStreamer?
Thanks!
In Wine Bugzilla #31836, Dimesio (dimesio) wrote : | #18 |
(In reply to Ivan Baldo from comment #12)
> What is lost from WINE if it is built without GStreamer?
Winegstreamer doesn't work anyway because of bug 30557, and the workaround for apps that crash because of that bug is to disable winegstreamer, so AFAICT, nothing will be lost.
In Wine Bugzilla #31836, Marcan-l (marcan-l) wrote : | #19 |
Some apps don't work without winegstreamer. The workaround for bug 30557 for those apps is to apply one of the patches linked in that bug that fixes the issue. Just disabling winegstreamer only turns one crash/nonworking bug into another crash/nonworking bug.
Some apps may fail gracefully without the support and just not play video (which is not ideal anyway), but others refuse to work properly if video playback fails. Both bugs need fixing.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #20 |
@comment 14:
Well, of course *both* bugs need to be fixed, but till this one gets fixed, the fix for the other will get only minimal exposure in major distros, as the clock keeps ticking since EOS of 0.10.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #21 |
Created attachment 53265
Patch sequence to update gstreamer usage to 1.0
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #22 |
(In reply to Andrew Eikum from comment #16)
> Created attachment 53265 [details]
> Patch sequence to update gstreamer usage to 1.0
This is a 5-patch sequence to update winegstreamer to use the gstreamer 1.0 API, based on Rafał's previous work. The first few patches are identical to those from Bug 30557.
While it seems to work in the few cases I tested it, it still needs lots of testing to verify that I didn't break anything.
The pixellation issue that Rosanne found with videos embedded in Powerpoint is also present with this patch series.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #23 |
I forgot to mention, please be aware that there may be a problem with gstreamer 1.0 and seeking with MPGv1 videos. See https:/
Bryan Quigley (bryanquigley) wrote : | #1 |
Looks like this makes sense to do for 1.8/Xenial. Alternatively there are untested patches for gst1.0.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #24 |
Thanks for the credit, though I don't consider it fully earned.
Anyway, the patch builds - it might even work, but I'm not sure which apps were using it.
Only one I'm sure about isn't working (is just crashing) due to bug 9127...
I've tried to cargo-cult around it using some of YUV pieces, but it looks like I just don't sufficiently understand DirectShow.
(on that note: how do you get width/height/rate from MEDIASUBTYPE_
Though a couple minor points:
- it seems new GST_QUERY_ types should be added to switch, query_function, so that "Unknown query" are printed only for *unknown* values
- not quite sure if it's generic or app specific, but sometimes if a video fails to play due to a missing codec ("err:msvideo:
- not sure if it can be helped, but I wonder if some kind of null input can be provided, so that the apps don't crash if a needed gst plugin isn't installed
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #25 |
Created attachment 53318
mciqtz32: Support MCI_DGV_
(In reply to Andrew Eikum from comment #17)
> The pixellation issue that Rosanne found with videos embedded in Powerpoint
> is also present with this patch series.
This patch fixes this problem in Office 2007.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #26 |
(In reply to Rafał Mużyło from comment #19)
> Thanks for the credit, though I don't consider it fully earned.
>
I can remove the credit if you want, but I really did start with your patch and build on top of it. You had done much of the groundwork.
> Anyway, the patch builds - it might even work, but I'm not sure which apps
> were using it.
>
I've been testing mostly with a program called Graph Studio. Once that was working, I tested with GTA:VC, Echoes, Lego Designer, and PowerPoint and all seem to work.
> Though a couple minor points:
>
> - it seems new GST_QUERY_ types should be added to switch, query_function,
> so that "Unknown query" are printed only for *unknown* values
>
Sure, I'll make this a little better.
> - not quite sure if it's generic or app specific, but sometimes if a video
> fails to play due to a missing codec ("err:msvideo:
> codec 'vidc I420' not found!), on a retry the app crashes
>
I'll test the failure cases (missing gstreamer plugins) better and make sure we're handling the problem correctly.
> - not sure if it can be helped, but I wonder if some kind of null input can
> be provided, so that the apps don't crash if a needed gst plugin isn't
> installed
This could maybe be a future improvement.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #27 |
Created attachment 53327
Rebased without new ntdll export
Here's another version without using the ntdll export as described in Bug 30557. This tarball also includes the fix for Powerpoint. Unless I hear of something broken or get review feedback, this is what I'll be submitting upstream soon.
In Wine Bugzilla #31836, Dimesio (dimesio) wrote : | #28 |
(In reply to Andrew Eikum from comment #22)
> Created attachment 53327 [details]
> Rebased without new ntdll export
>
> Here's another version without using the ntdll export as described in Bug
> 30557. This tarball also includes the fix for Powerpoint. Unless I hear of
> something broken or get review feedback, this is what I'll be submitting
> upstream soon.
With those patches, when I try to insert either of the two videos, Powerpoint hangs with this in the console:
(wine:10444): GStreamer-WARNING **: Failed to load plugin '/usr/lib/
(wine:10444): GStreamer-WARNING **: Failed to load plugin '/usr/lib/
fixme:gstreamer
** (wine:10444): CRITICAL **: gst_video_
fixme:gstreamer
fixme:gstreamer
In Wine Bugzilla #31836, Dimesio (dimesio) wrote : | #29 |
I got past the errors in comment 23 by updating libgstcodecparsers. I can insert the videos in Powerpoint, but they don't play.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #30 |
(In reply to Rosanne DiMesio from comment #24)
> I got past the errors in comment 23 by updating libgstcodecparsers. I can
> insert the videos in Powerpoint, but they don't play.
You use OpenSUSE, right? I'll install that in a VM and see if I can reproduce. In the meantime, can you upload a log with both
WINEDEBUG=
and
GST_DEBUG=
set during the run?
In Wine Bugzilla #31836, Dimesio (dimesio) wrote : | #31 |
Created attachment 53356
+tid,+seh,
Attached is the log. I opened Powerpoint, inserted the Ikea video and set it to play automatically, then played the slide show.
I am on 64 bit openSUSE 13.1, using the Gstreamer 1.6.1 packages from the Packman repository.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #32 |
Created attachment 53379
Update winegstreamer to 1.0, including better workaround for gst<1.7 bug
Thanks, Rosanne. The problem was caused by a bug that is fixed in gstreamer 1.7. I had a workaround for it in the patch, but it only fixed some situations. I've updated the workaround to be more robust, and this seems to fix the problem in PowerPoint for me. Can you try again?
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #33 |
(In reply to Andrew Eikum from comment #27)
> Created attachment 53379 [details]
> Update winegstreamer to 1.0, including better workaround for gst<1.7 bug
>
> Thanks, Rosanne. The problem was caused by a bug that is fixed in gstreamer
> 1.7. I had a workaround for it in the patch, but it only fixed some
> situations. I've updated the workaround to be more robust, and this seems to
> fix the problem in PowerPoint for me. Can you try again?
Oh, note that pausing/restarting videos in powerpoint seems in poor shape. See Bug 30687. But I was at least able to get the video preview to work, and it worked in a slideshow if I didn't try to restart it after pausing.
In Wine Bugzilla #31836, Dimesio (dimesio) wrote : | #34 |
(In reply to Andrew Eikum from comment #28)
>
> Oh, note that pausing/restarting videos in powerpoint seems in poor shape.
> See Bug 30687. But I was at least able to get the video preview to work, and
> it worked in a slideshow if I didn't try to restart it after pausing.
Other than the pause/restart issue, it works great.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #35 |
Wine is now using the gstreamer 1.0 API. Please file new bugs if you encounter problems with our gstreamer support. I'll send a mail to the mailing lists to update packagers about the dependency change.
commit e8311270ab7e01b
Author: Andrew Eikum <email address hidden>
Date: Thu Jan 14 13:23:04 2016 -0600
winegstreamer: Update to use gstreamer-1.0.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #36 |
Just before this bug gets closed, a question:
What exactly is the purpose of
AC_COMPILE_
check ?
Cause, unless I'm missing something, that check was bogus even before glib 2.0.0.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #37 |
The above question is wrt. some of the responses to the mail to the packagers, where I strongly suspect the errors are simply cases of incorrect toolchain setup.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #38 |
(In reply to Rafał Mużyło from comment #31)
> Just before this bug gets closed, a question:
> What exactly is the purpose of
> AC_COMPILE_
> a[sizeof(gint64) > 4 ? 1 : -1]; if (a[0]) return 0;]])
>
> check ?
>
> Cause, unless I'm missing something, that check was bogus even before glib
> 2.0.0.
The problem here is glib and gstreamer have different header files for 32- and 64-bit, but pkgconfig doesn't have a mechanism to specify which architecture's headers you should get. This is really glib/gstreamer's fault. The vast majority of libraries write their headers so the same header files work on either architecture, and there is no need to configure pkg-config.
For most (all?) distros, the 64-bit glib/gstreamer headers are in the default location, while the 32-bit ones are in some special location (in /usr/lib32/ on Arch Linux). So pkg-config always gives the 64-bit headers, even when building 32-bit Wine, and this results in broken winegstreamer.
That check was added in b113af1b13455 to avoid building gstreamer if the headers are for the wrong architecture.
This was discussed a bit on the ML in this thread:
https:/
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #39 |
(In reply to Andrew Eikum from comment #33)
> The problem here is glib and gstreamer have different header files for 32-
> and 64-bit, but pkgconfig doesn't have a mechanism to specify which
> architecture's headers you should get. This is really glib/gstreamer's
> fault. The vast majority of libraries write their headers so the same header
> files work on either architecture, and there is no need to configure
> pkg-config.
>
Not quite correct and Gentoo here, so I kind of know about arch-specific headers. While almost exclusively a spectator, I did watch the growing pains of multilib-minimal and related eclases and did notice some packages started wrapping some of their headers (those, that weren't already using /usr/lib{32,64} for that purpose). While some of the used solutions weren't technically quite correct (like passing '-m32' as a tail of CC/CXX instead of in C{,XX}FLAGS), sme were quite interesting.
> For most (all?) distros, the 64-bit glib/gstreamer headers are in the
> default location, while the 32-bit ones are in some special location (in
> /usr/lib32/ on Arch Linux). So pkg-config always gives the 64-bit headers,
> even when building 32-bit Wine, and this results in broken winegstreamer.
>
...unless you've got a real 32bit machine or using such vm...but kind of off-topic.
Anyway, even if you don't have a host-prefixed pkg-config (which is the most simple way of making pkg-config "just work"), there's still PKG_CONFIG_LIBDIR, which, again, is a mater of a proper toolchain setup.
> That check was added in b113af1b13455 to avoid building gstreamer if the
> headers are for the wrong architecture.
>
That check is nevertheless bogus - sizeof(gint64) by design is *always* 8.
> This was discussed a bit on the ML in this thread:
>
> https:/
...and this was the thread I was referring to when I've said "the errors are simply cases of incorrect toolchain setup".
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #40 |
...
I'm not completely dismissing the mail you've referenced, but saying that the content of the relevant config.log might be slightly different than you'd expect.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #41 |
(In reply to Rafał Mużyło from comment #34)
> That check is nevertheless bogus - sizeof(gint64) by design is *always* 8.
>
With the correct glib headers for your architecture, yes, it is always 8. But without setting PKG_CONFIG_PATH to pick up the correct glib-2.0.pc file, it will be wrong. This is what the configure check is for.
[aeikum@aeikum ~]$ cat test.c
#include <stdio.h>
#include <glib-2.0/glib.h>
int main(int argc, char **argv)
{
printf("%u\n", sizeof(gint64));
return 0;
}
[aeikum@aeikum ~]$ gcc $(pkg-config --cflags --libs glib-2.0) -o test test.c
[aeikum@aeikum ~]$ ./test
8
[aeikum@aeikum ~]$ gcc -m32 $(pkg-config --cflags --libs glib-2.0) -o test test.c
[aeikum@aeikum ~]$ ./test
4
[aeikum@aeikum ~]$ gcc -m32 $(PKG_CONFIG_
[aeikum@aeikum ~]$ ./test
8
[aeikum@aeikum ~]$
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #42 |
The way I read wine's configure.ac and glibconfig.h, the check you really want here is slightly different and in a slightly different position.
Namely, first the checks AC_CHECK_
Then, if they succeed, the next check to run would be AC_COMPILE_IFELSE for 'GLIB_SIZEOF_LONG == sizeof(long)'.
If that fails, you want to AC_MSG_ERROR right here, cause this would mean exactly that the mentioned toolchain mistake took place.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #43 |
(In reply to Rafał Mużyło from comment #37)
> The way I read wine's configure.ac and glibconfig.h, the check you really
> want here is slightly different and in a slightly different position.
>
> Namely, first the checks AC_CHECK_
> Then, if they succeed, the next check to run would be AC_COMPILE_IFELSE for
> 'GLIB_SIZEOF_LONG == sizeof(long)'.
> If that fails, you want to AC_MSG_ERROR right here, cause this would mean
> exactly that the mentioned toolchain mistake took place.
I'd happily approve of a patch to improve this detection and its diagnostic message. I'd probably go with a warning instead of an error, since many distros don't ship 32-bit gstreamer and I don't want to kill those builds because they happen to have 64-bit gstreamer installed.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #44 |
...ah, OK, now I see how that exactly works...
Kind of fragile.
Still, what I've wrote earlier about the conditions of the check holds - the mismatch should AC_MSG_ERROR, as it indicates an incorrect toolchain setup.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #45 |
> I'd probably go with a warning instead of an error, since many distros don't ship 32-bit gstreamer and I don't want to kill those builds because they happen to have 64-bit gstreamer installed.
This is the part we keep misunderstanding each other - I don't see how you could construct such case.
I'd put AC_MSG_ERROR only in case gstreamer is detected, but is mismatched.
If it's not detected, we're not in the branch.
If we're building wine64, gstreamer is detected and mismatch happens, toolchain is incorrect.
If we're building wine32, gstreamer is detected and mismatch happens, toolchain is incorrect.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #46 |
(In reply to Rafał Mużyło from comment #40)
> > I'd probably go with a warning instead of an error, since many distros don't ship 32-bit gstreamer and I don't want to kill those builds because they happen to have 64-bit gstreamer installed.
>
> This is the part we keep misunderstanding each other - I don't see how you
> could construct such case.
>
> I'd put AC_MSG_ERROR only in case gstreamer is detected, but is mismatched.
>
> If it's not detected, we're not in the branch.
>
You're right. I was thinking the headers were sufficient to get into the branch, but the error will only occur if 32-bit gstreamer SO files are present. Do you want to write a patch, or shall I add this to my TODO list?
In Wine Bugzilla #31836, Alexandre Julliard (julliard) wrote : | #47 |
Aborting configure with AC_MSG_ERROR is very unfriendly, and should only be used for cases that would make the resulting build useless. A broken gstreamer doesn't qualify. A simple notice message would be enough.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #48 |
(In reply to Alexandre Julliard from comment #42)
> Aborting configure with AC_MSG_ERROR is very unfriendly, and should only be
> used for cases that would make the resulting build useless. A broken
> gstreamer doesn't qualify. A simple notice message would be enough.
The catch is next to noone will notice such notice in the flood of the configure messages, unless this check will only set a var and the warning is only printed at the conclusion of the configure process.
That's not about my workflow, but about my experience with people's approach to the content of build logs, non-failing configure parts specifically. That's the common variant of "if it builds, it works".
That's just a personal preference, but I'd prefer to abort as soon as I know something is broken, cause if I care, I want to fix it and if I don't, I'd know I'd need to add '--disable-
With your approach, you might just as well scrap the check altogether and build a broken gstreamer in such case - the resulting build wouldn't be useless then, just the gstreamer part.
In Wine Bugzilla #31836, Rafał Mużyło (galtgendo) wrote : | #49 |
Created attachment 53467
minor configure check tweak
This is basically what I was talking about.
Mind I haven't tested it, so I might have mismatched the braces, but it's more to show the concept (the message is badly worded too).
As I've said, instead of dieing, it could set a var here and report it at the end of the process, but again, in my experience, non-dieing *fails* are a mistake.
In Wine Bugzilla #31836, Alexandre Julliard (julliard) wrote : | #50 |
(In reply to Rafał Mużyło from comment #43)
> The catch is next to noone will notice such notice in the flood of the
> configure messages, unless this check will only set a var and the warning is
> only printed at the conclusion of the configure process.
That's how it's done for all such warnings. Check the WINE_NOTICE macro.
Launchpad Janitor (janitor) wrote : | #2 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in wine1.6 (Ubuntu): | |
status: | New → Confirmed |
In Wine Bugzilla #31836, Alexandre Julliard (julliard) wrote : | #51 |
Closing bugs fixed in 1.9.2.
In Wine Bugzilla #31836, Andrew Eikum (aeikum) wrote : | #52 |
Rafał, commit 049412a48c should help users with this problem.
Changed in wine1.8 (Ubuntu): | |
status: | New → Confirmed |
Bryan Quigley (bryanquigley) wrote : | #4 |
This was done in Debian - http://
"* Disable gstreamer since 1.0 support is not yet available."
Changed in wine: | |
importance: | Unknown → Wishlist |
status: | Unknown → Fix Released |
Bryan Quigley (bryanquigley) wrote : | #53 |
- wine1.6_1.6.2-0ubuntu14.debdiff Edit (1.0 KiB, text/plain)
Here is a patch. Apparently it works fine if you just remove it from depends. (Tested only in 1.6 branch ~ which is the only one in archive right now)
Tested it with building in 32-bit pbuilder, and music plays so audio does work.
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #54 |
The attachment "wine1.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]
tags: | added: patch |
Changed in wine (Debian): | |
status: | Unknown → Fix Released |
Changed in wine1.6 (Ubuntu): | |
importance: | Undecided → Medium |
Changed in wine1.8 (Ubuntu): | |
importance: | Undecided → Medium |
Changed in wine1.6 (Ubuntu): | |
status: | Confirmed → In Progress |
assignee: | nobody → Timo Jyrinki (timo-jyrinki) |
Timo Jyrinki (timo-jyrinki) wrote : | #55 |
Thanks Bryan! The patch seems reasonable. According to upstream omitting the GStreamer support does remove some video playback functionality, but the said functionality is also currently broken until 1.9 series it seems so having it in Wine 1.6 does not help anything.
The wine 1.8 issue remains open, since there's no Wine 1.8 in Ubuntu yet. Unless someone steps up to do what's needed for 1.8, 16.04 LTS is probably going to stay at 1.6.
If the Ubuntu Wine team is starting to be stagnant, would there be a point to merge with Debian to drop Ubuntu's wine1.x source packages and use Debian's wine source package as is or as much as is as possible? I'm not sure what's the long term history with the delta.
Maarten has packaged wine1.8 1:1.8.0-0ubuntu1 up in December though in the PPA, so maybe we'll see wine1.8 as well later on.
Bryan Quigley (bryanquigley) wrote : | #56 |
>Thanks Bryan! The patch seems reasonable.
Thanks!
>If the Ubuntu Wine team is starting to be stagnant, would there be a point to merge with Debian to drop Ubuntu's wine1.x source packages and use Debian's wine source package as is or as much as is as possible?
I think that might be the better option at this point (or for 16.10?) and I did try my hand at it. There are two bugs about moving to 1.8:
1558480 - Just go to debian packaging, see Marc's comment #2 for why it's difficult - upgrades. It's a cross-architecture upgrade story which I wasn't able to figure out.
1556344 - Add wine1.8 with Ubuntu packaging.
Launchpad Janitor (janitor) wrote : | #57 |
This bug was fixed in the package wine1.6 - 1:1.6.2-0ubuntu14
---------------
wine1.6 (1:1.6.2-0ubuntu14) xenial; urgency=medium
* Disable gstreamer support as it isn't used. (LP: #1530229)
-- Bryan Quigley <email address hidden> Mon, 21 Mar 2016 13:58:27 -0400
Changed in wine1.6 (Ubuntu): | |
status: | In Progress → Fix Released |
no longer affects: | wine1.8 (Ubuntu) |
GStreamer 1.0 was released. gstreamer. freedesktop. org/
http://
GStreamer 1.0 has a different API and ABI as GStreamer 0.10,
but both versions should be usable in parallel for a while.
Announcement: lists.freedeskt op.org/ archives/ gstreamer- announce/ 2012-September/ 000265. html
http://
GStreamer 0.10 to 1.0 porting guide: cgit.freedeskto p.org/gstreamer /gstreamer/ tree/docs/ random/ porting- to-1.0. txt
http://
--
By by ... Detlef