Announcement

Collapse
No announcement yet.

Ubuntu Will Not Enable Open-Source VDPAU Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    *on card X

    Comment


    • #47
      Originally posted by Ericg View Post
      You miss the point Bacon, its 8MB's they save on the LiveCD's, which they apparently are still trying to force onto an 800mb CD..
      The problem is that this argument falls flat on its face when you realize that there are *TONS* of packages that ubuntu DOES NOT INSTALL on their livecd.
      If you look at that discussion, +ajax = redhat. He was talking about how Fedora might go ahead and add it to the LIVECD -- just because, you know, it would be really cool.

      IT IS ALREADY IN FEDORA REPOSITORIES FOR GENERAL INSTALLATION!!!!

      Ubuntu *could* just do what Redhat does, and there is not a single reason in the world why they don't.

      Comment


      • #48
        Originally posted by 0xBADCODE View Post
        My wish to Canonical: fire all morons responsible for this idiocy.
        Ok, so just so we are clear, this basically means shutting the doors and going out of business....

        Comment


        • #49
          Originally posted by gigaplex View Post
          Why is everyone saying it's as simple as enabling a configuration option? It's not. If they ship it, they have to support it.
          Actually, no, they don't have to support anything unless there is a support contract between them and their "customers", which doesn't exist.

          Comment


          • #50
            Come on guys, it's not really about if they support it on the live CD (which of course not everyone will agree on that this is important, a basic necessity or whatever). But from what it reads, it will not be installable through the standard ubuntu repos, be it the supported parts, nor the unsupported uni/multiverse parts. And that really isn't necessary as they can easily the libg3dvl-mesa outside the live CD but inside main, uni- or multiverse.

            Comment


            • #51
              Debian still hasn't enabled VDPAU either

              I wonder if Ubuntu is really waiting for Debian? Bug here:

              https://bugs.debian.org/cgi-bin/bugr...cgi?bug=656719

              I'm running Debian Sid packages built with patches in that bug report, and VPDAU works OK. I wonder why the patches haven't been applied in Debian yet. Bug report does not state any reasons for not enabling VDPAU by default.

              On the other hand, after I enabled VDPAU, pause/resume and rewind works somewhat flakily on my AMD laptop with AMD GPU with mplayer. If I pause/unpause it starts stuttering for ~10 seconds. CPU usage is MUCH lower though, especially playing high definition videos... As far as I know, VLC is unable to use open-source VDPAU support at all? Something about how Radeon VDPAU reports its capabilities?

              I hope VDPAU gets enabled in Debian before next release is frozen. But it needs a bit more work IMO.

              --Coder

              Comment


              • #52
                Funny, cause I have similar stuttering effect with my Kabini (E1-2500) laptop under Windows 8.1 using MPC-HC (and VLC IIRC): Flashing for several (might be around 10) seconds without sound while the player seems to get sound and video part to sync, then continues with sound and vid in sync.

                Using the oibaf repo, under Kubuntu 13.10 +3.13.3 from kernel-ppa it works very well with mplayer and mpv, with VLC (which is able to use that OSS vdpau) and xine (same) I get to see the video, but with display errors. Just the upper left quarter of the vid is being displayed well, the rest shows an opaque overlay of the first frame (I think), the overlay is proportionally being resized with the player window and the content. And the players tend to freeze when skipping forth and back several times. Thus, I've set them both to opengl2 output which makes them play SD content (upto 576p and perheaps above) just fine. So I can watch 720p and 1080p vids on that notebook, which are not running smoothly withoud radeon's vdpau. That's why I opt for libg3dvl-mesa to be an optional package inside one of the unsupported repos.

                Comment


                • #53
                  Originally posted by Andrecorreia View Post
                  another non theme. windows don t come with drivers pre installer, if you need it install yourself, if you will install nvidia non free(almost every people who use nvidia) vdpau installs, intel use vaapi. amd... well no buy amd hardware
                  Yes, but this isn't Windows. We expect much better hardware support out of the box from Linux distributions.

                  Sorry, that's an asshole move from Canonical and they deserve all the scorn and ridicule they will get. It pisses me off almost as much as distributions that withheld things like mp3 playback support when it's clearly not (and never really has been, for playback) a problem.

                  One thing we can probably be sure of is that it's not just because of 8 Mb larger Mesa packages.

                  Comment


                  • #54
                    Originally posted by coder111 View Post
                    On the other hand, after I enabled VDPAU, pause/resume and rewind works somewhat flakily on my AMD laptop with AMD GPU with mplayer. If I pause/unpause it starts stuttering for ~10 seconds. CPU usage is MUCH lower though, especially playing high definition videos... As far as I know, VLC is unable to use open-source VDPAU support at all? Something about how Radeon VDPAU reports its capabilities?

                    I hope VDPAU gets enabled in Debian before next release is frozen. But it needs a bit more work IMO.

                    --Coder
                    Originally posted by edgar_wibeau View Post
                    Funny, cause I have similar stuttering effect with my Kabini (E1-2500) laptop under Windows 8.1 using MPC-HC (and VLC IIRC): Flashing for several (might be around 10) seconds without sound while the player seems to get sound and video part to sync, then continues with sound and vid in sync.

                    Using the oibaf repo, under Kubuntu 13.10 +3.13.3 from kernel-ppa it works very well with mplayer and mpv, with VLC (which is able to use that OSS vdpau) and xine (same) I get to see the video, but with display errors. Just the upper left quarter of the vid is being displayed well, the rest shows an opaque overlay of the first frame (I think), the overlay is proportionally being resized with the player window and the content. And the players tend to freeze when skipping forth and back several times. Thus, I've set them both to opengl2 output which makes them play SD content (upto 576p and perheaps above) just fine. So I can watch 720p and 1080p vids on that notebook, which are not running smoothly withoud radeon's vdpau. That's why I opt for libg3dvl-mesa to be an optional package inside one of the unsupported repos.
                    Did you guys try REPORTING the bugs? (try searching in bugs.freedesktop.org for similar bugs before doing it, make sure to describe your setup and give verbose logs)
                    @edgar_wibeau are you sure vlc works? the last time I tried it, it supposedly had support for VDPAU, but... it didn't use it, so I simply removed vlc.

                    The argument that the driver "has not been tested enough" is BS, I think, as the driver has been used by lots of people in lots of distros (remember, arch users are our alpha testers..), including XBMC ( http://forum.xbmc.org/showthread.php?tid=174854 ), and the user themselves are usually told to report bugs, so by now (in kernel 3.14), almost everything should work just fine for most people.

                    Again people, go to ubuntu forums, go to ubuntu support channels in IRC, bitch and whine there to ubuntu maintainers for support, don't let this stupidity pass.

                    Comment


                    • #55
                      An additional, important fact is that deciding to not make VDPAU available to a wide audience will not at all help with getting the remaining VDPAU issues fixed.

                      Comment


                      • #56
                        Originally posted by asdfblah View Post
                        @edgar_wibeau are you sure vlc works? the last time I tried it, it supposedly had support for VDPAU, but... it didn't use it, so I simply removed vlc
                        Not edgar_wibeau, but anyways, in Slackware VLC 2.1.3 uses VDPAU, but it comes with heavy stuttering and artifacts, so I wouldn't say it works. On the same setup MPlayer works fine with VDPAU, so I wouldn't consider this a driver issue, but a problem of VLC.

                        Comment


                        • #57
                          Come down people... its easy the ubuntu die hards some said it, everybody must use binary blobs or is a murron anyway ^^ so they have no problem.

                          For everybody else all this trolls that buy amd hardware even they should hate freedom and buy nvidia hardware, there is a easy fix, download something else like fedora/archlinux/opensuse... put it on a usb-stick, boot it, format your ubuntu partitions / harddisk install.

                          Believe me, thats only a example from what ubuntu "defends" you, stuff like ramfs or tmpfs for /tmp and profile-sync-deamon that puts your browser-profile/cache into ram and not only speeds your browsing experience up, but if you use a ssd also reduces the amounts of writes so your ssd will most likely stay longer alive.

                          Yes yes there is also a ppa for that... first you have to know/learn about it, and the ramfs is preinstalled in every normal (non-ubuntu) distro.


                          But donīt belive me, I am a cracy retard... but then be happy with your gnu/linux fork distro.

                          Have fun with it


                          p.s.: sadly Canonical failed right now in creating the worst distro ever because they "lost" in the fight for upstart and now they dont reach perfection it worst distro ever... sad...

                          Comment


                          • #58
                            Originally posted by Vim_User View Post
                            Not edgar_wibeau, but anyways, in Slackware VLC 2.1.3 uses VDPAU, but it comes with heavy stuttering and artifacts, so I wouldn't say it works. On the same setup MPlayer works fine with VDPAU, so I wouldn't consider this a driver issue, but a problem of VLC.
                            Yeah, exactly.
                            What I meant is, VLC (< 2.2?) doesn't seem to use VDPAU at all, and you can check that simply by looking at cpu usage. The debugging output when using the -v flag is almost cryptic... but you can see there that it isn't using VDPAU.
                            Anyway, VLC itself seems to be buggy as hell. mpv is great.

                            Comment


                            • #59
                              Originally posted by blackiwid View Post
                              Believe me, thats only a example from what ubuntu "defends" you, stuff like ramfs or tmpfs for /tmp and profile-sync-deamon that puts your browser-profile/cache into ram and not only speeds your browsing experience up, but if you use a ssd also reduces the amounts of writes so your ssd will most likely stay longer alive.
                              SSD writes are a false problem. Most so-called optimizations, apart of TRIM and not defragging, are useless, if not hurting.

                              Comment


                              • #60
                                Originally posted by Calinou View Post
                                SSD writes are a false problem. Most so-called optimizations, apart of TRIM and not defragging, are useless, if not hurting.
                                how can reducing of write calls hurt a ssd?

                                And even if it would be true, still the advantage in speed rocks. And even if you dont use a ssd this advantage is even bigger.

                                Comment

                                Working...
                                X