If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

XvBA tools frustrations

03-07-2011, 04:39 PM

Oh good, XvBA is finally released.. you just forgot to mention that the tools WON'T BUILD! Why? well, you use some SPECIAL AMD performance library (framewave) and the current STABLE release doesn't LINK!

- Take the ubuntu packages and extract them
- Create a archlinux package from it

BUT after that i got another unpleasant surprise.. A FIXED boost version requirement while i had a newer one! It wants libboost_thread.so.1.42.0 while i had libboost_thread.so.1.46.0 and since i was absolutely sick of this i just made a symbolic link from libboost_thread.so.1.46.0 to libboost_thread.so.1.42.0 which even works! it compiles fine now and runs!

I obviously miss the IDCT and VLD ones.. don't know what they do though
And i wonder.. how do i see if i have divx and xvid hardware decoding capabilities? since according to the wikipedia UVD page i should have that (UVD 3.0)..

Comment

There's a mailing list for xvba-tools, see the sourceforge project page. You may have more success in getting answers to your questions there.

Probably, but as they on their page: NO SUPPORT! so i'm not even gonna try.

Anyway, lets try xvbaplay.. surely they got that tested and working perfectly.. right..?WRONG. Segmentation fault for both x11 and gl.

I used this line:
xvbaplay --video-output=x11 <my_movie>
and (just to be sure the "=" isn't causing anything odd)
xvbaplay --video-output x11 <my_movie>

I do have to say that my GPU is AMD 6870 (yeah, i upgraded from my 5770)

To sum it up a bit.
- First it's not compiling due to some special AMD lib that itself is not working
- Then it requires a fixed version of boost
- Then when it finally "runs" it crashes when i use any output.

Sorry, but i have to say this to AMD. You have finally released XvBA but you severely lack in code quality and documentation on how to use it! In fact, it only has TODO items! So please AMD, give your code some proper testing and at the very least prevent segmentation faults! Oh and just ONE simple example on how to run it would be nice.. right now it's guesswork to know what should be given to --video-output in fact it isn't even clear that option should be given!

Oh well, that was my 5 cent on this one.

Comment

Probably, but as they on their page: NO SUPPORT! so i'm not even gonna try.

NO SUPPORT just means AMD is not obligated to provide support. I encourage everyone to post feedback directly to the xvbat-devel mailing last. That way, we'll get a better sense of the kinds of issues people are facing.

I used this line:
xvbaplay --video-output=x11 <my_movie>
and (just to be sure the "=" isn't causing anything odd)
xvbaplay --video-output x11 <my_movie>

Since you didn't specify a codec, the above uses FFmpeg by default (i.e. software decoding) and requires colour space conversion of each decoded frame. That's important because xvbaplay uses Framewave for colour space conversion and this sounds like you're hitting a bug in Framewave and/or Framewave's use of Boost.

I do have to say that my GPU is AMD 6870 (yeah, i upgraded from my 5770)

To sum it up a bit.
- First it's not compiling due to some special AMD lib that itself is not working

Originally, I used img_convert from FFmpeg for colour space conversion. However, img_convert has been removed from FFmpeg and replaced with the GPL (not LGPL) swscale. I chose Framewave to replace img_convert because of its permissive license (Apache License 2.0). That Framewave originated from AMD is just a happy coincidence. If you know of another library with similar functionality and a permissive open source license, I'd be happy to consider integrating it into XvBA Tools.

Sorry, but i have to say this to AMD. You have finally released XvBA but you severely lack in code quality and documentation on how to use it! In fact, it only has TODO items! So please AMD, give your code some proper testing and at the very least prevent segmentation faults!

XvBA Tools is sample code intended as a guide for developers using XvBA. It's not production quality and, yes, it does have a lot of TODO items. Building a real media player is a big task and the open source community has already done a good job with MPlayer, Xine, VLC, Totem, and so on. Rather than duplicating those efforts and working to make xvbaplay a real player, I'm currently focused on trying to understand how to assist the community to add XvBA support to existing players.

Oh and just ONE simple example on how to run it would be nice.. right now it's guesswork to know what should be given to --video-output in fact it isn't even clear that option should be given!

The command line above is taken directly from the documentation. It's not as clear or comprehensive as I would like and I apologize if you found it insufficient. Perhaps you can provide some suggestions on how to improve it.

Tim

Comment

NO SUPPORT just means AMD is not obligated to provide support. I encourage everyone to post feedback directly to the xvbat-devel mailing last. That way, we'll get a better sense of the kinds of issues people are facing.

To be fair, the documentation states that limited testing was done. We didn't test on Arch.

I know and i take that for granted. That is my choise and risk to take.

Since you didn't specify a codec, the above uses FFmpeg by default (i.e. software decoding) and requires colour space conversion of each decoded frame. That's important because xvbaplay uses Framewave for colour space conversion and this sounds like you're hitting a bug in Framewave and/or Framewave's use of Boost.

as documented in the Doxygen generated documentation. This will give you best performance and bypass colour space conversion since it's done on the GPU.

Well, i did read the readme and the xvbaplay code and it's not in there (the readme should certainly have an example and xvbaplay --help should also indicate it)

Originally, I used img_convert from FFmpeg for colour space conversion. However, img_convert has been removed from FFmpeg and replaced with the GPL (not LGPL) swscale. I chose Framewave to replace img_convert because of its permissive license (Apache License 2.0). That Framewave originated from AMD is just a happy coincidence. If you know of another library with similar functionality and a permissive open source license, I'd be happy to consider integrating it into XvBA Tools.

I don't mind you use an "exotic" library like framewave but i do mind that i have to use the framewave SVN to get it compiling! In other words, release a new, fixed!!, framewave package to fix this issue. (the linking issue)

To be honest, I didn't drill down into the Framewave packaging issue. I was just happy to find fixed packages for my development and test platforms.

You talk about framewave here while you reply on boost.. Just don't specify a boost version (or a minimal version) and this issue is fixed as well.

See my suggestions above and let me know if they help.

see above

XvBA Tools is sample code intended as a guide for developers using XvBA. It's not production quality and, yes, it does have a lot of TODO items. Building a real media player is a big task and the open source community has already done a good job with MPlayer, Xine, VLC, Totem, and so on. Rather than duplicating those efforts and working to make xvbaplay a real player, I'm currently focused on trying to understand how to assist the community to add XvBA support to existing players.

Very true indeed, but as demonstration code it certainly shouldn't segfault and it should be clear what the user needs to give as arguments to get it running. Oke, doxygen might be "good" but the first place people go is the obvious place: the README so put some vital info in there to get it running please. As for the player part. I don't expect you to make a full featured player, but the parts that you do make should at least run.

The command line above is taken directly from the documentation. It's not as clear or comprehensive as I would like and I apologize if you found it insufficient. Perhaps you can provide some suggestions on how to improve it.

Tim

Tim, thanx for posting such a constructive message even though my messages where more in the "i bash ati for this" category

Here is my list of suggestions for you to make it better. (same as above only summed up)

Comment

NO SUPPORT just means AMD is not obligated to provide support. I encourage everyone to post feedback directly to the xvbat-devel mailing last. That way, we'll get a better sense of the kinds of issues people are facing.

To be fair, the documentation states that limited testing was done. We didn't test on Arch.

Since you didn't specify a codec, the above uses FFmpeg by default (i.e. software decoding) and requires colour space conversion of each decoded frame. That's important because xvbaplay uses Framewave for colour space conversion and this sounds like you're hitting a bug in Framewave and/or Framewave's use of Boost.

as documented in the Doxygen generated documentation. This will give you best performance and bypass colour space conversion since it's done on the GPU.

Originally, I used img_convert from FFmpeg for colour space conversion. However, img_convert has been removed from FFmpeg and replaced with the GPL (not LGPL) swscale. I chose Framewave to replace img_convert because of its permissive license (Apache License 2.0). That Framewave originated from AMD is just a happy coincidence. If you know of another library with similar functionality and a permissive open source license, I'd be happy to consider integrating it into XvBA Tools.

To be honest, I didn't drill down into the Framewave packaging issue. I was just happy to find fixed packages for my development and test platforms.

See my suggestions above and let me know if they help.

XvBA Tools is sample code intended as a guide for developers using XvBA. It's not production quality and, yes, it does have a lot of TODO items. Building a real media player is a big task and the open source community has already done a good job with MPlayer, Xine, VLC, Totem, and so on. Rather than duplicating those efforts and working to make xvbaplay a real player, I'm currently focused on trying to understand how to assist the community to add XvBA support to existing players.

The command line above is taken directly from the documentation. It's not as clear or comprehensive as I would like and I apologize if you found it insufficient. Perhaps you can provide some suggestions on how to improve it.

Tim

its not very likely that many people will join yet another mailing list , when virtually all the people, dev's and users alike testing this are already here on the phoronix message board and are already vocal on many things UVD/XvBA so perhaps you should rethink that and just stay here.

hmm, let me get this right, you choose not to use the currently maintained and expanding swscale support that virtually every single OSS player is using directly today in whole or part because you want a LGPL rather than a GPL licence for "sample code intended as a guide for developers" so pick a really obscure thing virtually no one has hear of , never mind uses today ?

why not just ask on the ffmpeg mailing list or IRC channel to re-licence the swscale, im pretty sure virtually all the devs already agreed to have it licensed so anyway, for instance the LGPL x264 uses it extensively today.

then all your code and the any future HW assisted patches can be git patch submitted to ffmpeg for easy inclusion for all them players to use with no thought, if you intend for XvBA to be widely used in the future forget using obscure dead code and bring everything to ffmpeg today is my thought

Comment

NO SUPPORT just means AMD is not obligated to provide support. I encourage everyone to post feedback directly ...
...

The command line above is taken directly from the documentation. It's not as clear or comprehensive as I would like and I apologize if you found it insufficient. Perhaps you can provide some suggestions on how to improve it.

I don't mind you use an "exotic" library like framewave but i do mind that i have to use the framewave SVN to get it compiling! In other words, release a new, fixed!!, framewave package to fix this issue. (the linking issue)

I empathize because I ran into this too. Fortunately for me, I was able to find fixed packages for my preferred development platform and I documented installation of those packages.

I'm not the maintainer of the Framewave source or the packages for any platform. As I said, it's just a coincidence that Framewave was contributed by AMD. AMD is a large company; I don't know any of the original developers or any of the current maintainers.

Comment

its not very likely that many people will join yet another mailing list , when virtually all the people, dev's and users alike testing this are already here on the phoronix message board and are already vocal on many things UVD/XvBA so perhaps you should rethink that and just stay here.

When commenting on, submitting bug reports for, or participating in the development of an open source project it's common to use the mailing list or forums of the project in question. I setup the mailing lists in the hope that people would find them useful.

hmm, let me get this right, you choose not to use the currently maintained and expanding swscale support that virtually every single OSS player is using directly today in whole or part because you want a LGPL rather than a GPL licence for "sample code intended as a guide for developers" so pick a really obscure thing virtually no one has hear of , never mind uses today ?

why not just ask on the ffmpeg mailing list or IRC channel to re-licence the swscale, im pretty sure virtually all the devs already agreed to have it licensed so anyway, for instance the LGPL x264 uses it extensively today.

While I enjoy a good argument about licenses as much as the next guy, I can't discuss AMD's choice of license in any further detail except to say that swcale did not meet AMD's licensing requirements for XvBA Tools.

then all your code and the any future HW assisted patches can be git patch submitted to ffmpeg for easy inclusion for all them players to use with no thought, if you intend for XvBA to be widely used in the future forget using obscure dead code and bring everything to ffmpeg today is my thought

The release of the XvBA SDK and sample code (XvBA Tools) was a necessary first step. I'd like to see XvBA adopted by open source players and multimedia frameworks and would appreciate constructive feedback and suggestions about that, here on Phoronix, to the XvBA Tools mailing lists, or in private e-mail.