XvBA tools frustrations

[markg85]

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!

Read https://bugs.launchpad.net/ubuntu/+s...ve/+bug/496122 and the last few log entry here http://changelogs.ubuntu.com/changel...ntu2/changelog .. So, it turns out that the library needs to be updated.. no biggy right? WRONG! the framewave stuff in the repo is freaking 14 months old and the current 1.3.1 release has the bug!

I am on archlinux and i can't use that package from ubuntu.. nor can i compile the trunk... so how do i proceed now, AMD?

Ahh, glad that's out

[markg85]

FINALLY, i got it working. Want to know what i did? it's ugly!

- 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!

These are my device caps according to xvbainfo

.decode_caps_list = {
{
.size = 16,
.capability_id = XVBA_H264,
.flags = XVBA_H264_HIGH,
.surface_type = XVBA_NV12
},
{
.size = 16,
.capability_id = XVBA_VC1,
.flags = XVBA_VC1_ADVANCED,
.surface_type = XVBA_NV12
},
{
.size = 16,
.capability_id = XVBA_MPEG2_IDCT,
.flags = XVBA_NOFLAG,
.surface_type = XVBA_NV12
},
{
.size = 16,
.capability_id = XVBA_MPEG2_VLD,
.flags = XVBA_NOFLAG,
.surface_type = XVBA_NV12
}
},

But seeing that list it does make me wonder what the xvba-video (for vaapi) does since in there i only have:

libva: libva version 0.31.1
libva: User requested driver 'xvba'
libva: Trying to open /usr/lib/dri//xvba_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.7.8
vainfo: Supported profile and entrypoints
VAProfileH264High : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD

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)..

[monraaf]

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.

[markg85]

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.

[twriter]

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.

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

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

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 suggest you use something like:

./xvbaplay --video-codec jmba --video-width $WIDTH --video-height $HEIGHT --video-output gl $CLIP

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.

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.

- Then it requires a fixed version of boost

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.

- Then when it finally "runs" it crashes when i use any output.

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

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

[markg85]

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.

I suggest you use something like:

./xvbaplay --video-codec jmba --video-width $WIDTH --video-height $HEIGHT --video-output gl $CLIP

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)

1. Release a new framewave that doesn't have link errors
2. Require a minimal BOOST version and not one specific version
3. Put the play arguments in the --help and README
4. Also list the possible codecs (example --codec-list shows supported codecs)
5. Fix the segfaults! Demonstration code certainly shouldn't segfault.

I think you can use this reply

Regards,
Mark

[popper]

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.

I suggest you use something like:

./xvbaplay --video-codec jmba --video-width $WIDTH --video-height $HEIGHT --video-output gl $CLIP

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

[popper]

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.

Tim

ooh and as regards this , clearly you need to provide far better and above all clear tested, and full example command lines , such as x264 do here
http://sites.google.com/site/x264bluray/home/1080i-p
Authoring a professional Blu-Ray Disc with x264 "

1080p25

x264 --bitrate XXXXX --preset veryslow --tune film --weightp 1 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --b-pyramid strict --open-gop bluray --slices 4 --fake-interlaced --pic-struct --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file

x264 --bitrate XXXXX --preset veryslow --tune film --weightp 1 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --b-pyramid strict --open-gop bluray --slices 4 --fake-interlaced --pic-struct --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file"

etc, but made for your prototype application and even included inside the app's --fullhelp page directly

[twriter]

Well, i did read the readme and the xvbaplay code and it's not in there

I was referring to doc/html/index.html in the XvBA Tools tree whereas I think you're referring to the README in the XvBA SDK.

There's no README in XvBA Tools and I agree there should be one. Sorry, that was a last minute oversight. I will add a README with a pointer to the Doxygen generated documentation.

(the readme should certainly have an example and xvbaplay --help should also indicate it)

I agree the help could be more useful.

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.

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.

Like I said, I didn't look into it in detail. I agree that the Framewave dependency is less than ideal and I'll look into removing it.

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)

1. Release a new framewave that doesn't have link errors
2. Require a minimal BOOST version and not one specific version
3. Put the play arguments in the --help and README
4. Also list the possible codecs (example --codec-list shows supported codecs)
5. Fix the segfaults! Demonstration code certainly shouldn't segfault.

Thanks,

Tim

[twriter]

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.

Tim