Announcement

Collapse
No announcement yet.

FFmpeg Moves Closer To 1.0 Release

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

  • FFmpeg Moves Closer To 1.0 Release

    Phoronix: FFmpeg Moves Closer To 1.0 Release

    The FFmpeg project has moved closer to its 1.0 release with the Sunday release of FFmpeg 0.9...

    http://www.phoronix.com/vr.php?view=MTAyNjY

  • #2
    That laundry list of changes and yet still no mkv ordered chapters support.

    Comment


    • #3
      Originally posted by phoronix View Post
      Phoronix: FFmpeg Moves Closer To 1.0 Release

      The FFmpeg project has moved closer to its 1.0 release with the Sunday release of FFmpeg 0.9...

      http://www.phoronix.com/vr.php?view=MTAyNjY
      "The FFmpeg project encourages everyone to upgrade to version 0.9 unless they are followers of Git master."
      actually they say, and have for some time "unless they use current git master." as in , everyone that can,is recommended to use GIT over a point release.

      i noticed you apparently finally went and got the 0.8.7 (and GIT x264) the other day to replace your antiquated version after one of my posts, and imported it to your test suite ,i hope you go and do the same really soon with this newer version, and every version hence , preferably GIT as they recommend so you don't end up having yourself and your test suite users running older slower code before you even start 2011 retrospect and 2012 tests.

      and OC, change or add a real life 1080 or at least 720P sample encode ( using CRF 18 not two pass) test to your test suite product to reflect what people do today not some usless and ineffective vcd that no one today uses...
      Last edited by popper; 12-12-2011, 09:34 AM.

      Comment


      • #4
        Originally posted by johnc View Post
        That laundry list of changes and yet still no mkv ordered chapters support.
        so go and write and submit the patch then, if you want it native to the app rather than an external app that manipulates the containers orders chapters and many other things etc,

        personally id like to see UVD being usable inside avconv/ffmpeg , but that's never going to happen is it as AMD don't and wont write and send the required patches to avconv/fmpeg devs never mind work with them and their OSS code base to make AMD/ATI look and perform better in future tests.

        Comment


        • #5
          Originally posted by popper View Post
          personally id like to see UVD being usable inside avconv/ffmpeg , but that's never going to happen is it as AMD don't and wont write and send the required patches to avconv/fmpeg devs never mind work with them and their OSS code base to make AMD/ATI look and perform better in future tests.
          Until we can release UVD programming info, what patches to avconf/ffmpeg do you think we should be writing and sending ?

          Comment


          • #6
            Originally posted by popper View Post
            so go and write and submit the patch then
            I think it was submitted three decades ago, but they didn't want any part of it.

            meh. Maybe it's just being handled at the player level at this point.

            Comment


            • #7
              Originally posted by popper View Post
              i noticed you apparently finally went and got the 0.8.7 (and GIT x264) the other day to replace your antiquated version after one of my posts, and imported it to your test suite ,i hope you go and do the same really soon with this newer version, and every version hence , preferably GIT as they recommend so you don't end up having yourself and your test suite users running older slower code before you even start 2011 retrospect and 2012 tests.

              and OC, change or add a real life 1080 or at least 720P sample encode ( using CRF 18 not two pass) test to your test suite product to reflect what people do today not some usless and ineffective vcd that no one today uses...
              Originally posted by popper View Post
              so go and write and submit the patch then,
              Thanks!
              Michael Larabel
              http://www.michaellarabel.com/

              Comment


              • #8
                "popper said:so go and write and submit the patch then,"

                Originally posted by Michael View Post
                Thanks!
                LOL., remember Michael, its YOUR "test suite" you wanted it to go/be used commercially, so that's your responsibility to write those patches, and OC accept anything the PHP web devs can be bothered to write, patch and test for you if its suitable....

                fair enough if you cant be bothered to make a patch for your "test suite" to make the data it produces more relevant to today's mass 1080/720 users of your product that provide you with this valuable data you wish to profit from OC, and no problem.
                Last edited by popper; 12-12-2011, 11:35 AM.

                Comment


                • #9
                  Not following the "scene" actively, what's the latest state of ffmpeg and libav?

                  Comment


                  • #10
                    Originally posted by popper View Post
                    "popper said:so go and write and submit the patch then,"



                    LOL., remember Michael, its YOUR "test suite" you wanted it to go/be used commercially, so that's your responsibility to write those patches, and OC accept anything the PHP web devs can be bothered to write, patch and test for you if its suitable....

                    fair enough if you cant be bothered to make a patch for your "test suite" to make the data it produces more relevant to today's mass 1080/720 users of your product that provide you with this valuable data you wish to profit from OC, and no problem.
                    If any of my commercial customers (or large number of community users) requested such a change, of course I would do it. As far as I know you're not associated with any of my commercial customers, but you're the one wanting a change, so feel free to submit a patch or even become a commercial customer then.
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #11
                      Originally posted by bridgman View Post
                      Until we can release UVD programming info, what patches to avconf/ffmpeg do you think we should be writing and sending ?
                      well clearly if you John as the head of the AMD Linux projects cant walk into the board room (or know someone above you that can) and put a good case to release this antiquated UVD programming data (cant do L5.1 etc) by now, and not actually get them to write the OpenCL OpenVideo driver library for Linux as you say they havent even bothered to do that yet after far more then a year..... ( so you imply the windows version is not written in standard C99 code !then", perhaps its written in MS basic and doesnt conform to the spec so cant be simply conpiled and change where needed for the generic linux framework as is usual)

                      THEN it seems clear YOU as the head of the AMD Linux projects NEED to do one of two things... say fuck it , we cant help Linux end users use any form of AMD/ATI hardware assisted video decode directly other than whats available from 3rd party's...

                      or get the board to stop fuckin about and give you same money and resources (if that really is the problem) to write something (at this point i suppose users don't really care "what it is" as long as it works in ffmpeg and can be openly ported from there everywhere else as usual) that the users can use and you and legal can be happy with , end of story really.... but that's your choice as the head of Linux to do something or not as is the case for way more than a year
                      Last edited by popper; 12-12-2011, 12:27 PM.

                      Comment


                      • #12
                        Originally posted by curaga View Post
                        Not following the "scene" actively, what's the latest state of ffmpeg and libav?
                        same as it always was since they split, the libav devs write the bulk of the patches you might use today, AVX,SIMD speed ups,audio ,new ARM code etc, ffmpeg/Michael runs a script to pull these patches now and again into ffmpeg , and pretty much ffmpeg/carl is the main contributor of patches to ffmpeg with help from other random devs .... or so it seems


                        http://lists.libav.org/pipermail/libav-devel/
                        Last edited by popper; 12-12-2011, 12:54 PM.

                        Comment


                        • #13
                          Originally posted by popper View Post
                          so you imply the windows version is not written in standard C99 code
                          Of course it isn't written in C99. MSVC can't understand that. And he did not so much imply but explicitly mention (in another thread, but in reply to you - maybe you should read a bit more than you write) Windows having different APIs than Linux. Does that surprise you?

                          Comment


                          • #14
                            Originally posted by AnonymousCoward View Post
                            Of course it isn't written in C99. MSVC can't understand that. And he did not so much imply but explicitly mention (in another thread, but in reply to you - maybe you should read a bit more than you write) Windows having different APIs than Linux. Does that surprise you?
                            (i did read it, he's right it was OT there and much better here so....) yeah sure , OC they have different API's but the code is written for windows it runs, and there cant be that much difference that a simple replace cant handle for the bulk of the code if its written properly and isn't just a few 100 lines not worth bothering about porting, but that's not the point as you well know, he as much as said the Linux open decode code isn't even started yet and thats what really matters, you cant use it if they don't make it and so what's the point of buying their kit if HW decoding is what you want, Intel and ARM have it, AMD don't and wont any time soon on linux/non windows platforms
                            Last edited by popper; 12-12-2011, 01:17 PM.

                            Comment


                            • #15
                              Originally posted by popper View Post
                              he as much as said the Linux open decode code isn't even started yet and thats what really matters, you cant use it if they don't make it and so what's the point of buying their kit if HW decoding is what you want, Intel and ARM have it, AMD don't and wont any time soon on linux/non windows platforms
                              This might not be entirely true, because I read that UVD will be divided in GCN. One part for decode another one for DRM. So when I read that article I was like: it sounds something like what bridgman keeps telling for years.

                              Obviously, it was phrased something like: this new architecture will allow us to better serve customer demand by handling DRM better. So PR stuff but we actually know that this is for Linux.

                              Comment

                              Working...
                              X