FFmpeg Moves Closer To 1.0 Release

[phoronix]

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

[johnc]

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

[popper]

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.

[bridgman]

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 ?

[popper]

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

[AnonymousCoward]

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?

[bridgman]

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 ?

well clearly if you John as the head of the AMD Linux projects

I'm not the "head of AMD Linux" and never have been - part of my job includes managing the open source graphics effort and being part of a group which helps with proposals for releasing information to the open source community. The other parts of my job tend to be cross-OS rather than being Linux-specific.

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)

Programming language has nothing to do with it - the internal APIs of different operating systems are significantly different, it's not a "scan replace" effort to port code to a totally different OS and video framework. It's not a few hundred lines, or even a few thousand.

I think I can safely reveal that the code is not written in MS Basic

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, we could pick our battles, prioritize the ones where we can deliver useful benefit to our customers relatively quickly (eg display & 3D engine) and continue to release new information there, while working on the harder problems (open source video decode is the poster child for hard problems) in the background, and releasing code and programming information in other areas like GPU compute where we can. I'm sure it all looks boring and terribly slow from the outside, but you seem much more willing to give up on this area than we are.

Things might be more clear (although not as simple) if you didn't write off some of AMD's efforts as "third party", btw...

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

I guess this is what I don't get. We released the XvBA API and some sample "how to use it" code a year or so ago. That API info is finally starting to be used (which is great news !), and AFAIK Tim is talking with the developers about issues they found (eg Tim was investigating a reported issue with thread safety under certain conditions).

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 ?

[DaemonFC]

Until we can release UVD programming info, what patches to avconf/ffmpeg do you think we should be writing and sending ?

Seeing as how Nvidia's vdpau is going to work with your hardware before your own UVD, just keep it.

Nothing like putting the last nail in the coffin of your own specification due to hangups over imaginary property.

[chithanh]

Using UVD is preferable especially in mobile devices, as it is more energy efficient than decoding in shaders.

[johnc]

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.