XVBA, VDPAU,...

[mean]

Just a few words to give some status

The simple XVBA support ported from xbmc_pvr is almost finished.
It is a bit too crude as it will crash if it runs into a non simple stream, but it is simple to fix, i'll do it afterward.
For info, only the read-back the decoded frame is not working.

It will give a small increase in speed as the whole pipepline is not done (yet).

Vdpau is fast because the decoded image stays as long as possible in the video card memory.
For example if you do decode + display, internally the bitstream will be uploaded to the video  and displayed from here
If you do decode + vdpau resize + encoder, the bistream will be read back only after resize
Reading back is expensive, that's why the vdpau filters must be in the first in the pipeline. Else you upload/download from the video card memory everytime.

Xvba does not have processing or displaying capabilities built-in, so at first there will be some back and forth between the video card and memory, hence the probably small speed increase

Later on, an openGL type will be added to the picture type avidemux will be able to deal with. So if you do XVBA decode + openGL display, or XVBA decode + openGL filters, it will be fast.

So wait for my go before activating XVBA decoding, should be not too far in the future.

[Nik]

sounds great! thanks

if you don't mind this question here:
in the old 2.5 builds we were able to still see the "encoded" video after playing it was stopped in "output" mode
also it didn't jump back to the starting point if you played and stopped the video, but stayed at the stopping point (like it does when you play and stop the video using the "input view")
is this a bug or is that a "problem" caused by the needed change in the way avidemux processes the video stream?

[mean]

Should be mostly working. The only 2 know bugs so far are :
* Does not work well with TS HD capture (multislice ?/ No IDR ?)
* Jerkyness as the frames are displayed out of order. Not sure if it is a bug in gflrx or not. Seems only 12.10 is working fine and i'm using a later version.

[Jan Gruuthuse]

no amd hardware to test, amd has released new drivers linux for Linux 3.11-kernel opensource this week.
- AMD Has Massive Radeon Patch Set - Power Management!
- [PATCH 000/165] radeon drm-next patches
off topic:
Building on ubuntu 12.10 and 13.04, can anything been done in bootStrap.bash regarding this:
When installing avidemux debs:

The package is of bad quality
The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath.
Details:
Lintian check results for /home/jan/avidemux_2.6_branch_mean/debs/avidemux3-core-2.6.4-8754-Linux.deb:
E: avidemux3-core: control-file-has-bad-permissions md5sums 0664 != 0644
E: avidemux3-core: maintainer-address-missing mean

I would understand not providing real e-mail, could this not be solved by using: mean@127.0.0.1?

[mean]

XVBA put on hold, X11 decided not to work any longer
Switching to va api (i.e; intel hw decoding support)

[Jan Gruuthuse]

X11 decided not to work any longer

When Video display: x11 is selected: seems to be working.

[mean]

I meant the (ATI) video driver committed suicide out of the blue

[Jan Gruuthuse]

Ok, had some time last week only green screens on x11. Now is ok again. Believed it was related to above message.

[Jan Gruuthuse]

did come across this one: Phoronix: AMD Releases Open-Source UVD Video Support

This open-source AMD UVD support will allow for accelerated playback of H.264, VC-1, and MPEG variants on the HD 4000 through HD 7000 series GPUs. Interestingly, and to much pleasure, the UVD support is being exposed over VDPAU.

[mean]

@jan : Only works with opensource AMD drivers from what i've understood

LibVA is working (seems to), but the speedup is low
It will be better when the VA Display is done, so the data wont need to be copied back and forth between video card and CPU (like the way it is done for VDPAU)

[mean]

VAdisplay is done but at the moment it only works with H264 content decoded by libva
Speed up is small though
On core i5 :
* libVa alone               : 70% cpu
* LibVa + display libva : 55% cpu
* pure software+xv      : 78 % cpu

[mean]

Should display fine now (this morning commit)
Intel only, dont really know if it works or not with other libva backend

[Jan Gruuthuse]

yes it does on:

Code Select Expand

vainfo

libva: VA-API version 0.32.0
Xlib:  extension "XFree86-DRI" missing on display ":0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.3
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :   VAEntrypointVLD
      VAProfileMPEG2Main              :   VAEntrypointVLD
      VAProfileMPEG4Simple            :   VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    :   VAEntrypointVLD
      VAProfileH264Main               :   VAEntrypointVLD
      VAProfileH264High               :   VAEntrypointVLD
      VAProfileVC1Simple              :   VAEntrypointVLD
      VAProfileVC1Main                :   VAEntrypointVLD
      VAProfileVC1Advanced            :   VAEntrypointVLD

at start it shows:

[displayXError]  LibVA Error : <vaDeriveImage (ADM_coreLibVA::display, dest->surface,&vaImage):operation failed>
  [uploadToSurface]  Va Derive failed
  [displayImage]  VaRender] Failed to upload pic

but video is showing/playing on avidemux canvas (nvidia GT-520, core i7 377K gpu not active/connected)

[mean]

Depending on the driver you have 2 ways to upload an image to screen
Avidemux always tries version 1, then do version 2 (should be smarter and try only once)

Seems nvidia only provides version 2

[Nik]

stupid question: how do I  use it?
If I'm right it's not implemented in the nightly builds for windows?