Originally posted by Aleve Sicofante
View Post
Announcement
Collapse
No announcement yet.
FFmpeg Moves Closer To 1.0 Release
Collapse
X
-
Originally posted by Aleve Sicofante View PostI'm reading at some places that ffmpeg development is getting faster than libav's. How can that be possible if they're just importing the other team's work?
As always with free software, you can pick what you want as long as the license permits it. Even from a non-friendly fork.Originally posted by Aleve Sicofante View PostI'm genuinely asking. I have no preference in any party "winning". I do have some interest in knowing who's "winning", though. In a few months time I'm planning to start a project based on these libs and I'd rather go with "the winners".
Comment
-
Originally posted by bridgman View PostUntil we can release UVD programming info, what patches to avconf/ffmpeg do you think we should be writing and sending ?
Nothing like putting the last nail in the coffin of your own specification due to hangups over imaginary property.
Comment
-
Originally posted by chithanh View PostUsing UVD is preferable especially in mobile devices, as it is more energy efficient than decoding in shaders.
Comment
-
I was under the impression that VP8 is sufficiently similar to H.264 that it could at least partially be decoded by H.264 decoders.
VDPAU is the analog to XvBA. It makes no sense to compare it with UVD (which would be the analog to PureVideo).
Comment
-
Originally posted by popper View Postand the key point you make "telling" rather than showing and using the (non existent) code for a full generation of the older GPU/UVD products, but a direct URL to this new "Graphic Card Next" text you read might be useful as a context reference so if you have it, add it somewhere perhaps....
Btw, the site was not even in English, so apologies.
Comment
-
Wow. Looks like I missed an entire page of posts in this thread.
Popper, I often have trouble responding to your posts because you make "statements of fact" where not only the statement is incorrect but the assumptions on which you base your statement appear to be wrong as well. It makes it really hard to respond with anything smaller than a white paper, and it's been years since I've had time for something like that.
In the same way that kernel maintainers like big changes to be broken up into a set of smaller patches (reviewable-sized chunks) would it be possible for you to take a bit more of a bottom-up approach and validate your assumptions first ?
Originally posted by popper View Postwell clearly if you John as the head of the AMD Linux projects
Originally posted by popper View Postcant 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)
I think I can safely reveal that the code is not written in MS Basic
Originally posted by popper View PostTHEN 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...
Things might be more clear (although not as simple) if you didn't write off some of AMD's efforts as "third party", btw...
Originally posted by popper View Postor 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
Is your point that we somehow snubbed the ffmpeg community by not treating them as "special", or that we should have written all the patches ourselves rather than just providing API information, sample code, a mailing list, and a bit of support ?Last edited by bridgman; 18 December 2011, 01:13 PM.Test signature
Comment
Comment