Announcement

Collapse
No announcement yet.

Flash Player 10.1 RC Arrives But Still Not In Tune

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

  • #21
    So basically you want NV to buy AMD, what would not be the worst idea, when it would not be a tiny bit expensive

    Comment


    • #22
      Originally posted by Kano View Post
      So basically you want NV to buy AMD, what would not be the worst idea, when it would not be a tiny bit expensive
      That would be a bad idea (less competition). Also, what would become of our nice specsheets we recieve from AMD, huh?

      Comment


      • #23
        Originally posted by Kano View Post
        It seems to work better with newer firefox, did you try the 3.6.x pre series?

        http://ftp.mozilla.org/pub/mozilla.o...firefox-3.6.x/
        Currently I'm using :
        Code:
        Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4pre) Gecko/20100407 Ubuntu/9.10 (karmic) Namoroka/3.6.4pre
        but I didn't noticed any changes since 3.5.x :/

        Comment


        • #24
          I haven't giving it much testing, just a bit of YouTube, but 64-bit Flash seems to work 'fine' here. No crashes and freezing so far, just the regular high cpu usage and tearing in videos.

          Comment


          • #25
            not at all necessary

            Originally posted by Kano View Post
            So basically you want NV to buy AMD, what would not be the worst idea, when it would not be a tiny bit expensive
            to unify the video api wouldn't mean hardware changes. They just have to agree on an api for their graphics drivers to receive all the video data to decode. I just want it so adobe, VLC, and MPlayer don't the excuse of needing to write for both video decoding API to write good video software. They just need to make a driver for it like they did with opencl and opengl.

            Comment


            • #26
              r u sure?

              Originally posted by monraaf View Post
              I haven't giving it much testing, just a bit of YouTube, but 64-bit Flash seems to work 'fine' here. No crashes and freezing so far, just the regular high cpu usage and tearing in videos.
              are you sure you're using 64 bit flash?

              Comment


              • #27
                Originally posted by dacresbu View Post
                are you sure you're using 64 bit flash?
                Yep.

                Code:
                $ lsof -p `pidof firefox-bin`|grep flash
                (...) /home/monraaf/.mozilla/plugins/libflashplayer.so
                
                $ file /home/monraaf/.mozilla/plugins/libflashplayer.so
                (...) ELF 64-bit LSB shared object, x86-64, version 1 (...)

                Comment


                • #28
                  Originally posted by dacresbu View Post
                  to unify the video api wouldn't mean hardware changes. They just have to agree on an api for their graphics drivers to receive all the video data to decode. I just want it so adobe, VLC, and MPlayer don't the excuse of needing to write for both video decoding API to write good video software. They just need to make a driver for it like they did with opencl and opengl.
                  I've apparently completely missed on these threads the reason for OpenGL video accel rendering not being a good API in comparison to the others. Windows almost exclusively uses D3D for video accel, don't they? I'm just surprised then that OGL hasn't tried to become the dominant video accel API in response to that. What does VA and VDPAU have that OGL lacks?

                  Competition is great, but it would also be great if a solid leader was largely agreed upon so that a lot of weight would be placed behind it to cause wide adoption by Linux programs to make that easier on everyone.

                  Comment


                  • #29
                    BTW, Gnash and Swifdec rock for playing flash files.

                    On the subject of YouTube, first off I don't expect either program to ever work for it as Google stays up-to-date with Flash and I'm sure that breaks Gnash and Swifdec every time. Secondly, hopefully there will be a greater push for HTML5 which will do away with the YouTube dilemma for the most part, then those lingering flash things can hopefully be dealt with by Swiftdec and/or Gnash.

                    Comment


                    • #30
                      Yay for 1 minute edits!

                      It will do away with the YouTube dilemma except for the fact that the patented H264/MP4 codec is what Google wants to use for YouTube, which will never be supported by Firefox. It's a shame Google is supporting that closed standard instead of pushing for and helping alternatives like Dirac, Snow, and Theora out, not to mention pushing for the abolishment of software/math/art/idea patents in the U.S..

                      Comment

                      Working...
                      X