I believe shipping wayland-drm-client-protocol.h is wrong: The header
should always be generated by the wayland-scanner that matches the
runtime wayland version. Currently when someone clones the repo and
builds, the shipped version is used.

Yocto recipes for libva are still pointing to FDO. Maybe we could file a bug with them or submit an updated recipe.

Wayland protocol is only used to open/authenticate the DRM device and determine the correct driver. There is no reason to keep the Wayland protocol objects beyond that and will only lead to events being queued on them that take up memory and are never dispatched.

One coding mistake lets it happen. Add thd- as the prefix of thread id back into the tracing file name

This appears to be a regression in 4dc07b2

Previously I could use two parallel processes both using vaapi to do hardware h264 encoding. After that commit, the second process fails to initialize with the following error:

libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 1
libva error: va_getDriverName() failed with operation failed,driver_name=i965

cc @evelikov @seanvk

The libva version fail to retrieve in vainfo after libva-utils split from libva.
Only manage to retrieve libva API version use $PKG_CONFIG --modversion libva.
With add in this new variable, can retrieve using LIBVA_VERSION=$PKG_CONFIG --variable=libva_version libva.

See: https://github.com/01org/libva/blob/master/va/va.h#L588

The definitions are most confusing. The documentation for VA_ENC_SLICE_STRUCTURE_ARBITRARY_ROWS and VA_ENC_SLICE_STRUCTURE_ARBITRARY_MACROBLOCKS is the same and VA_ENC_SLICE_STRUCTURE_ARBITRARY_ROWS has the value 0 so it can't be tested for unless it is meant to be an exclusive option. I.e. It is either that or any combination of the other flags.

Code in libva-utils is affected: https://github.com/01org/libva-utils/blob/master/encode/h264encode.c#L1246 (Report: intel/libva-utils#54)

For the next release (1.8.0), I'm going to need us to only use version only in the
tag. That means if the release is 1.8.0 then that is the actual tag we will apply.
The reason is that on libva we've been appending the name to the tag and as a
result Github doubles the name of the tag.
So to give you an expample:

Next Release: 1.8.0
Previous Release: libva-1.7.3

We are simply removing the name from the tag for future releases. This makes libva consistent with libva-utils and intel-vaapi-driver for release tagging.

Thanks,

Sean

We can run the script in the top-level directory to unify the coding style.

After build new version 1.8.1 (before i haved 1.7.3) is /usr/bin/vainfo missing. Bug or just removed?

log: http://www.spaste.com/p/?c=hRJQyT8673

I am implementing miracast source side functionality, the idr_request needs this kind of hacks.

There are several warnings raised when compiling with clang-3.8

make[3]: Entering directory '/opt/gst/master/libva/va/glx'                                               
  CC       va_glx.lo      
  CC       va_glx_impl.lo 
va_glx_impl.c:208:19: warning: passing 'const GLubyte *' (aka 'const unsigned char *') to parameter of ty
pe 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign]        
        if(strcmp(strExtension, (const GLubyte *)name) == 0)                                             
                  ^~~~~~~~~~~~                                                                           
/usr/include/string.h:140:32: note: passing argument to parameter '__s1' here                            
extern int strcmp (const char *__s1, const char *__s2)                                                   
                               ^                                                                         
va_glx_impl.c:208:33: warning: passing 'const GLubyte *' (aka 'const unsigned char *') to parameter of ty
pe 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign]        
        if(strcmp(strExtension, (const GLubyte *)name) == 0)                                             
                                ^~~~~~~~~~~~~~~~~~~~~                                                    
/usr/include/string.h:140:50: note: passing argument to parameter '__s2' here                            
extern int strcmp (const char *__s1, const char *__s2)                                                   
                                                 ^  
2 warnings generated.     

make[3]: Entering directory '/opt/gst/master/libva/va'                                                   
 CC       va.lo                                                                                         
 CC       va_compat.lo   
 CC       va_fool.lo                                                                                    
 CC       va_trace.lo    
 CC       va_tpi.lo      
va_trace.c:343:25: warning: unused variable 'valid' [-Wunused-variable]                                  
   int i = 0, idx = 0, valid = 0;                                                                       
                       ^                                                                                
va_trace.c:738:11: warning: unused variable 'tmp' [-Wunused-variable]                                    
   FILE *tmp;                                                                                           
         ^                                                                                              
va_trace.c:737:20: warning: unused variable 'suffix' [-Wunused-variable]                                 
   unsigned short suffix = 0xffff & ((unsigned int)time(NULL));                                         
                  ^                                                                                     
va_trace.c:826:16: warning: unused variable 'j' [-Wunused-variable]                                      
   int i = 0, j = 0;                                                                                    
              ^                                                                                         
va_trace.c:3566:9: warning: unused variable 'i' [-Wunused-variable]                                      
   int i;                                          
       ^                 
5 warnings generated.                             

migrated from Bugzilla #90200
status NEEDINFO severity normal in component core for ---
Reported in version unspecified on platform Other
Assigned to: haihao

Original attachment names and IDs:

• 0001-wayland-Use-a-private-queue-and-free-registry-proxy.patch (ID 115381)
• 0001-wayland-Use-private-queue-and-free-proxy.patch (ID 115382)

On 2015-04-27 18:21:27 +0000, Olivier Crête wrote:

Created attachment 115381
libva: wayland: Use a private queue and free registry proxy

both libva and the intel driver's wayland integration use the global queue. This is not thread safe and may be problematic for some applications. Also, it doesn't clear the proxies and queue correctly before unloading the libEGL.so, which leads to segfaults as libwayland-client tries to access the static wl_interface in the bit that has been unloaded!

On 2015-04-27 18:21:56 +0000, Olivier Crête wrote:

Created attachment 115382
intel-driver: Basically the same patch for the driver

On 2015-04-30 01:03:44 +0000, haihao wrote:

The old version of wayland-client.h doesn't have wl_display_roundtrip_queue. Could you update the dependency on wayland in configure.ac too ?

On 2015-11-24 04:43:38 +0000, haihao wrote:

Could you update your patch to check wayland version? otherwise your patch might break driver building.

On 2016-08-31 04:03:06 +0000, Gautham Kantharaju wrote:

Using vaapisink for video playback, trying to stop/start the video playback or switch video files.

SIGSEGV is caught in libwayland-client. Pulled in the patches w.r.t libva and libva-intel-driver. Still the issue exists.

Can you let me know, if anything needs to be changed the vaapi gstreamer plugin also in order to resolve the issue?

On 2016-09-05 01:50:46 +0000, haihao wrote:

Someone also reported crash issue when using wayland, the issue disappears after upgrading wanyland-drm in the driver. Could you have a try with the following patches:

libva:
https://lists.freedesktop.org/archives/libva/2016-September/004356.html
https://lists.freedesktop.org/archives/libva/2016-September/004357.html

libva-intel-driver:
https://lists.freedesktop.org/archives/libva/2016-September/004361.html
https://lists.freedesktop.org/archives/libva/2016-September/004362.html

[VAAPI encoder]: "vaEndPicture(q->display, q->context)": invalid parameter

It seems that with obs-studio and the linux-vaapi plugin, if a user is using a newer driver than 1.7.1 they get the above as soon as they try to record. The plugin and driver work fine, with Ubuntu 16.10 or any system really using drivers before 1.7.3.

I'm trying to debug the source code for the plugin for obs-studio but unforately the error information I get back doesn't give me enough information on what Parameter is invalid or what is actually wrong.

Some additional information:

device_type : X11
device: Intel i965 driver for Intel(R) Haswell Mobile - 1.8.0
device_path: (null)
fps_num: 30
fps_den: 1
width: 1280
height: 720
profile: main
keyint: 2 (s)
rc_type: CBR
bitrate: 2500 (kbit)
use_custom_cpb: no

Not sure what needs to be changed, the only difference here is upgrading systems.

When compiling C++ code which includes va_enc_h264.h, this warning is emitted (marked error below because of -Werror):

.../va_enc_h264.h:577:13: error: empty union has size 0 in C, size 1 in C++ [-Werror,-Wextern-c-compat]
            union {
            ^

Just deleting the empty bits union should fix this without affecting ABI compatibility.

Upstream maintainers for debian based packaging do not use the control files in the project. They are poorly maintained and conflict with upstream packaging. Remove them.

Why do we include it? Package maintainers create and maintain their own. Remove it.

vaInitialize fails when Xwayland is running. So VA-API never works at all in Gnome Shell on Wayland.

It appears the problem is libva only supports DRI2. And Xwayland only supports DRI3.

I understand you could call this a bug in the video player apps for not choosing native wayland first, but this problem is prevalent in every single video player app that supports VA-API I have encountered (gst-play-1.0, totem, mpv). So trying to fix each video player isn't really a solution that scales (also my first attempt at doing so was rejected by mpv).

Create a gh pages script for deployment of doxygen files to the gh pages branch

see issue #14

Sorry, I haven't found libva-vdpau-driver repository in this organization, thus filling the bug here:

/var/tmp/portage/x11-libs/libva-vdpau-driver-0.7.4-r4/work/libva-vdpau-driver-0.7.4/src/sysdeps.h:52:13:
warning: implicit declaration of function "vdpau_error_message" [-Wimplicit-function-declaration]

This issue was initially reported downstream at https://bugzilla.redhat.com/show_bug.cgi?id=1455101

Description of problem:
When trying to run any libVA based application on wayland, they always fail.

Version-Release number of selected component (if applicable):
totem-3.24.0-1.fc26.x86_64
gstreamer1-vaapi-1.12.0-1.fc26.x86_64
libva-1.8.2-1.fc26.x86_64
libva-intel-driver-1.8.2-1.fc26.x86_64

How reproducible:
always. Ever since I started using wayland (about 2 years ago).

Steps to Reproduce:

1. have the packages installed as noted above
2. run a gnome/wayland session
3. start totem
4. play video file

Actual results:
Green screen, no video output.
Output of totem:

VA error: wayland: failed to identify /dev/dri/card0: Permission denied (errno 13)
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)

Expected results:
Work fine

Additional info:
This renders libva completely useless on wayland.

The warning (first line) is printed from drm_handle_device in libva/va/wayland/va_wayland_drm.c.

$ ls -al /dev/dri
drwxr-xr-x.  3 root root       100 23. Mai 06:53 .
drwxr-xr-x. 19 root root      4240 24. Mai 09:54 ..
drwxr-xr-x.  2 root root        80 23. Mai 06:53 by-path
crw-rw----+  1 root video 226,   0 23. Mai 06:53 card0
crw-rw----+  1 root video 226, 128 23. Mai 06:53 renderD128

$ vainfo 
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva )
vainfo: Driver version: Intel i965 driver for Intel(R) Ironlake Desktop - 1.8.2
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

Should I add myself to the video group? If yes, shouldn't that be the default for any user?

see 739

May be useful for tracking API/ABI symbols in the library: https://abi-laboratory.pro/tracker/timeline/libva/

The report is created with the help of open-source abi-tracker tool: https://github.com/lvc/abi-tracker

Thank you.

Environment

• Linux x86_64
• GCC 4.9
• libva 1.0.7 and higher

Hello there,

The current ffmpeg master branch now exposes a new VP9 VAAPI encoder:

However, it seems one would need the latest Intel Kabylake-based Integrated GPU to take advantage of this feature.

Encoder options now available:

ffmpeg -h vp9_vaapi

Output:

Encoder vp9_vaapi [VP9 (VAAPI)]:
    General capabilities: delay 
    Threading capabilities: none
    Supported pixel formats: vaapi_vld
vp9_vaapi AVOptions:
  -loop_filter_level <int>        E..V.... Loop filter level (from 0 to 63) (default 16)
  -loop_filter_sharpness <int>        E..V.... Loop filter sharpness (from 0 to 15) (default 4)

I have installed the intel-hybrid-driver package on a Skylake test bed hoping to get some form of Hybrid encode support for VP9 to no avail. See below:

See the sample output below:

[Parsed_format_0 @ 0x42cb500] compat: called with args=[nv12]
[Parsed_format_0 @ 0x42cb500] Setting 'pix_fmts' to value 'nv12'
[Parsed_scale_vaapi_2 @ 0x42cc300] Setting 'w' to value '1920'
[Parsed_scale_vaapi_2 @ 0x42cc300] Setting 'h' to value '1080'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'video_size' to value '3840x2026'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'pix_fmt' to value '0'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'time_base' to value '1/1000'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'pixel_aspect' to value '1/1'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'sws_param' to value 'flags=2'
[graph 0 input from stream 0:0 @ 0x42cce00] Setting 'frame_rate' to value '24000/1001'
[graph 0 input from stream 0:0 @ 0x42cce00] w:3840 h:2026 pixfmt:yuv420p tb:1/1000 fr:24000/1001 sar:1/1 sws_param:flags=2
[format @ 0x42cba40] compat: called with args=[vaapi_vld]
[format @ 0x42cba40] Setting 'pix_fmts' to value 'vaapi_vld'
[auto_scaler_0 @ 0x42cd580] Setting 'flags' to value 'bicubic'
[auto_scaler_0 @ 0x42cd580] w:iw h:ih flags:'bicubic' interl:0
[Parsed_format_0 @ 0x42cb500] auto-inserting filter 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and the filter 'Parsed_format_0'
[AVFilterGraph @ 0x42ca360] query_formats: 6 queried, 4 merged, 1 already done, 0 delayed
[auto_scaler_0 @ 0x42cd580] w:3840 h:2026 fmt:yuv420p sar:1/1 -> w:3840 h:2026 fmt:nv12 sar:1/1 flags:0x4
[hwupload @ 0x42cbcc0] Surface format is nv12.
[AVHWFramesContext @ 0x42ccbc0] Created surface 0x4000000.
[AVHWFramesContext @ 0x42ccbc0] Direct mapping possible.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000001.
[AVHWFramesContext @ 0x42c3e40] Direct mapping possible.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000002.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000003.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000004.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000005.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000006.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000007.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000008.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x4000009.
[AVHWFramesContext @ 0x42c3e40] Created surface 0x400000a.
[vp9_vaapi @ 0x409da40] Encoding entrypoint not found (19 / 6).
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[AVIOContext @ 0x40fdac0] Statistics: 0 seeks, 0 writeouts
[aac @ 0x40fcb00] Qavg: -nan
[AVIOContext @ 0x409f820] Statistics: 32768 bytes read, 0 seeks
Conversion failed!

The interesting bits are the entrypoint warnings for VP9 encoding being absent on this particular platform, as confirmed by vainfo's output:

libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.8.4.pre1 (glk-alpha-71-gc3110dc)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileVP9Profile0            :	VAEntrypointVLD

The VLD (for Variable Length Decode) entry point for VP9 profile 0 is the furthest that Skylake comes to in terms of VP9 hardware-acceleration.

Is this the intended result for Skylake, or can we expect Hybrid encode to work somewhere in the future?

Regards,

Brainiarc7

It's not maintained and as such new codec profiles are rarely added. Original intent was for memory leak/performance profiling for driver problems through VA_FOOL testing.

Begin

dmesg

[三 9月 6 11:00:27 2017] [drm] GPU HANG: ecode 9:0:0x85dffffb, in chameleon [1296], reason: Hang on render ring, action: reset
[三 9月 6 11:00:27 2017] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[三 9月 6 11:00:27 2017] [drm] Please file a new bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[三 9月 6 11:00:27 2017] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[三 9月 6 11:00:27 2017] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[三 9月 6 11:00:27 2017] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[三 9月 6 11:00:27 2017] drm/i915: Resetting chip after gpu hang
[三 9月 6 11:00:27 2017] [drm] RC6 on
[三 9月 6 11:00:27 2017] [drm] GuC firmware load skipped
[三 9月 6 11:00:33 2017] drm/i915: Resetting chip after gpu hang
[三 9月 6 11:00:33 2017] [drm] RC6 on
[三 9月 6 11:00:33 2017] [drm] GuC firmware load skipped

surveil@41:/opt/goldenrod/plugins> lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 94
Model name: Intel(R) Celeron(R) CPU G3900 @ 2.80GHz
Stepping: 3
CPU MHz: 899.780
CPU max MHz: 2800.0000
CPU min MHz: 800.0000
BogoMIPS: 5616.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 2048K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust erms invpcid rdseed smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp

root@41:/opt/goldenrod> lspci -vv
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07)
Subsystem: Intel Corporation Device 2015
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=10 <?>
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 2212
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 123
Region 0: Memory at de000000 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c <?>
Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Process Address Space ID (PASID)
PASIDCap: Exec+ Priv-, Max PASID Width: 14
PASIDCtl: Enable- Exec- Priv-
Capabilities: [200 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable-, Smallest Translation Unit: 00
Capabilities: [300 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped-
Page Request Capacity: 00008000, Page Request Allocation: 00000000
Kernel driver in use: i915
Kernel modules: i915

root@41:/opt/goldenrod> uname -a
Linux localhost 4.9.11-1-default #1 SMP PREEMPT Sat Feb 18 17:59:27 UTC 2017 (cf9c670) x86_64 x86_64 x86_64 GNU/Linux

I decode the same video using the same program libva and libva-intel-driver,Opensuse ,CPU N3150

kernel 4.3.3

render busy: 32%: ██████▌ render space: 30/131072

                      task  percent busy
                       GAM:  41%: ████████▎               vert fetch: 0 (0/sec)
                        CS:  34%: ██████▉                 prim fetch: 0 (0/sec)
                        VF:   7%: █▌                   VS invocations: 0 (0/sec)
                        VS:   7%: █▌                   GS invocations: 0 (0/sec)
                        SF:   7%: █▌                        GS prims: 0 (0/sec)
                        CL:   7%: █▌                   CL invocations: 0 (0/sec)
                      GAFS:   7%: █▌                        CL prims: 0 (0/sec)
                        GS:   7%: █▌                   PS invocations: 0 (0/sec)
                       SOL:   7%: █▌                   PS depth pass: 0 (0/sec)
                        DS:   7%: █▌                  
                       TSG:   0%:                     
                       VFE:   0%:                     
                        RS:   0%:                     
                       SDE:   0%:                     
                       SVG:   0%:                     
                        HS:   0%:                     
                      GAFM:   0%:                     
                        TE:   0%: 

kernel 4.6.3 or above

render busy: 60%: ████████████ render space: 46/16384

                      task  percent busy
                       GAM:  68%: █████████████▋          vert fetch: 0 (0/sec)
                        CS:  61%: ████████████▎           prim fetch: 0 (0/sec)
                       SDE:   8%: █▋                   VS invocations: 0 (0/sec)
                        RS:   0%:                      GS invocations: 0 (0/sec)
                        VF:   0%:                           GS prims: 0 (0/sec)
                      GAFM:   0%:                      CL invocations: 0 (0/sec)
                       SOL:   0%:                           CL prims: 0 (0/sec)
                       TSG:   0%:                      PS invocations: 0 (0/sec)
                        VS:   0%:                      PS depth pass: 0 (0/sec)
                       VFE:   0%:                     
                       SVG:   0%:                     
                        SF:   0%:                     
                        CL:   0%:                     
                        GS:   0%:

In my .xsession-errors I found this messages:

libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0

I'd like to have the ability to disable those messages.
This will avoid to make the file grow in machines that runs kodi and are not rebooted often.

Currently the data type of slice_data_flag in VASliceParameterBufferHEVC is uint16_t while it is uint32_t for other codecs.(VASliceParameterBufferAVC/VP8/VP9). In such case it is not consistent.
In fact as the memory is allocated as aligned, it still allocates four bytes for slice_data_flag.
So it will be better to use the consistent data type.

It's not actively maintained

Begin

Currently, configure silently disables wayland support if requirements cannot be met, even when the user explicitly requests it via --enable-wayland. If the user does not explicitly request it, then silently disabling it is ok. However, when the user explicitly provides --enable-wayland to configure, configure should fail if wayland requirements/dependencies can't be met.

Events on wl_drm can get lost because the listener is not added immediately after bind.

Because we are not testing Android build with it and yet the makefile is still there and we continue to add new files to it with the presumption someone is actually building with it...I'd honestly prefer to see that maintained at the packaging level of an android project.

Begin

The wl_registry global_remove handler is set to NULL, which is not allowed and will crash the program if it is invoked.

Hi

I need to access the motion vectors generated during H.264 encoding and from the archived messages I see that access to such extra information has been patched https://lists.freedesktop.org/archives/libva/2014-May/002249.html . However, I am unable to see if this is stil supported. Is there a reason for not supporting the side information?

I would like to know if the low level driver and/or other components still support the side information such as motion vectors is still available. I would like to try applying the patch myself but would appreciate to know if there reasons where this patch is not recommended and should be avoided.

Thanks

$ vainfo
libva info: VA-API version 0.40.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
$ ls /usr/lib64/dri/
dummy_drv_video.so     nouveau_dri.so         r300_dri.so            radeonsi_dri.so        vmwgfx_dri.so
i915_dri.so            nouveau_drv_video.so   r600_dri.so            radeonsi_drv_video.so  
i965_dri.so            nouveau_vieux_dri.so   r600_drv_video.so      swrast_dri.so          
kms_swrast_dri.so      r200_dri.so            radeon_dri.so          virtio_gpu_dri.so  

I'm on Fedora 26 KDE Beta which is running Xorg (by default).

Installed Packages
mesa-dri-drivers.x86_64                                                17.1.1-2.fc26                                       @System        
mesa-filesystem.x86_64                                                 17.1.1-2.fc26                                       @System        
mesa-libEGL.x86_64                                                     17.1.1-2.fc26                                       @System        
mesa-libEGL-devel.x86_64                                               17.1.1-2.fc26                                       @System        
mesa-libGL.x86_64                                                      17.1.1-2.fc26                                       @System        
mesa-libGL-devel.x86_64                                                17.1.1-2.fc26                                       @System        
mesa-libGLES.x86_64                                                    17.1.1-2.fc26                                       @System        
mesa-libGLES-devel.x86_64                                              17.1.1-2.fc26                                       @System        
mesa-libGLU.x86_64                                                     9.0.0-11.fc26                                       @System        
mesa-libGLU-devel.x86_64                                               9.0.0-11.fc26                                       @System        
mesa-libOpenCL.x86_64                                                  17.1.1-2.fc26                                       @System        
mesa-libOpenCL-devel.x86_64                                            17.1.1-2.fc26                                       @System        
mesa-libgbm.x86_64                                                     17.1.1-2.fc26                                       @System        
mesa-libglapi.x86_64                                                   17.1.1-2.fc26                                       @System        
mesa-libwayland-egl.x86_64                                             17.1.1-2.fc26                                       @System        
mesa-libwayland-egl-devel.x86_64                                       17.1.1-2.fc26                                       @System        
mesa-libxatracker.x86_64                                               17.1.1-2.fc26                                       @System        
mesa-vulkan-devel.x86_64                                               17.1.1-2.fc26                                       @System        
mesa-vulkan-drivers.x86_64                                             17.1.1-2.fc26                                       @System

Installed Packages
libva.x86_64                                                       1.8.2-1.fc26                                            @System        
libva-devel.x86_64                                                 1.8.2-1.fc26                                            @System        
libva-utils.x86_64                                                 1.8.2-1.fc26                                            @System     

Test support has been moved to libva-utils, so remove it.

NEWS file is not up to date.
Can it be filled with info about 1.8.0 and 1.8.1 changes ?

Thank you

Intel(R) Core(TM) i7 CPU L 620 @ 2.00GHz here.

VO: [vaapi] 10000x10000 yuv420p
mpv: /var/tmp/paludis/x11-libs-libva-1.8.1/work/libva-1.8.1/va/x11/dri2_util.c:133: union dri_buffer *dri2GetRenderingBuffer(VADriverContextP, struct dri_drawable *): Assertion `buffers' failed.
/home/l29ah/bin//listen: line 10: 26979 Aborted (core dumped) mpv

Hi all,

We are planning to bump the VA-API major version from 0.40.0 to 1.0.0. In the new version, we will

• fix errors in API/data structure definition, e.g. https://github.com/01org/libva/issues/32
• add new features, e.g. https://github.com/01org/libva/pull/69,
• deprecate some useless API/data structures, e.g. libva-tpi, libva-egl.
• provide other improvement, e.g. use portable type to define data structure.

I have created https://github.com/01org/libva/tree/v2.0-branch for the new version bumping. You are welcome if you have any comment / suggestion or patch to improve the api

Thanks
Haihao

When I try to compile source which include va.h with -Wpedantic, I got following compiler warning:
va/va.h:1221:24: warning: ISO C++ forbids zero-size array ‘data’ [-Wpedantic] unsigned int data[0];

Compiler: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406.

migrated from Bugzilla #98285
status ASSIGNED severity enhancement in component core for ---
Reported in version unspecified on platform Other
Assigned to: Sean V Kelley

On 2016-10-17 10:10:12 +0000, Julien Isorce wrote:

Currently the work-flow is:

VASurface -> vaDeriveImage -> VAImageBufferType -> VABufferID -> vaAcquireBufferHandle -> 1 dmabuf FD value.

This only work if the underlying memory is contiguous. But if the VASurface is backed by at least 2 non-contiguous memory (for example one for each NV12 plane) then it would require to export each plane with a different dmabuf FD value.

I think a solution could be to create to either create a new equivalent function vaAcquireBufferHandle2 that takes a plane id into parameter. Or a new member in VABufferInfo. Or a new function that vaGetPlaneBufferID(VAImageID img, int plane, VABufferID *out_buf).

Note that in vdpau it is supported:

struct VdpSurfaceDMABufDesc {
/* DMA-buf file descriptor /
uint32_t handle;
/ Width in pixel /
uint32_t width;
/ Height in pixel /
uint32_t height;
/ Offset in bytes /
uint32_t offset;
/ Stride in bytes /
uint32_t stride;
/ VDP_RGBA_FORMAT_* as defined in the VDPAU spec and above. */
uint32_t format;
};

VdpStatus VdpVideoSurfaceDMABuf(
VdpVideoSurface surface,
VdpVideoSurfacePlane plane,
struct VdpSurfaceDMABufDesc * result)

On 2016-10-24 23:01:10 +0000, Sean V Kelley wrote:

Yes, this is an isssue for use cases where we split off the y/u/v into separate planes and then we require three FD. It's on my list of changes.

I agree, this is a needed change.

On 2016-10-25 02:07:01 +0000, haihao wrote:

(In reply to Julien Isorce from comment # 0)

Currently the work-flow is:

VASurface -> vaDeriveImage -> VAImageBufferType -> VABufferID ->
vaAcquireBufferHandle -> 1 dmabuf FD value.

This only work if the underlying memory is contiguous. But if the VASurface
is backed by at least 2 non-contiguous memory (for example one for each NV12
plane) then it would require to export each plane with a different dmabuf FD
value.

Do you mean a VA surface is backed with two different buffer objects in your driver? In libva-intel-driver each surface is created with only one GEM buffer object, so the same dmabuf FD is exported for all planes. You can get the layer out via the derived image.

On 2016-10-26 09:06:47 +0000, Julien Isorce wrote:

(In reply to Sean V Kelley from comment # 1)

Yes, this is an isssue for use cases where we split off the y/u/v into
separate planes and then we require three FD. It's on my list of changes.

I agree, this is a needed change.

I am glad to hear that. Thx

(In reply to haihao from comment # 2)

Do you mean a VA surface is backed with two different buffer objects in your
driver? In libva-intel-driver each surface is created with only one GEM
buffer object, so the same dmabuf FD is exported for all planes. You can get
the layer out via the derived image.

Yes

On 2016-10-27 18:14:07 +0000, Sean V Kelley wrote:

Julien,

Can you work under the existing constraints of VA Surface or do you need something more?

My requirements are different as they pertain to ChromeOS.

Thanks,

Sean

On 2016-10-27 20:31:32 +0000, Julien Isorce wrote:

(In reply to Sean V Kelley from comment # 4)

Julien,

Can you work under the existing constraints of VA Surface or do you need
something more?

Hi, I currently workaround it with an extra step: gstvaapipostproc to convert it to RGB since I know it will be one contiguous memory in that case. Then I export it a dmabuf and import into an EGLImage later on through gstglimagesink.

So currently in vaapi mesa gallium I only allow to derive_image for RGB surfaces.

My requirements are different as they pertain to ChromeOS.

Thanks,

Sean

I still need this change. What has changed since # 1 ? :)

Thx!

On 2016-10-28 21:11:42 +0000, Sean V Kelley wrote:

Hi Julien,

In ChromeOS we would always have to convert a decoded video surface (YUV) to RGB format for composition. That in itself incurs a cost. Hardware overlays which supported YUV and newer platforms with display out support for YUV needed ways to work with graphics stack and video stack for textures. So we looked into Sub-bo handling for planar fb formats. It was an idea about the kernel exposing the buffer objects of rendered surfaces (Y and UV) as contiguous in memory. This would avoid conversion on the export side and also make GL import easier with existing hardware. However, short the kernel managing that, we could modify the UMD to better expose the planes with non-contiguous memory.

The fundamental requirement was that we be able to import a single buffer into EGL so we can do texture sampling on it, but we also need to be able to reference
individual buffers in the YUV buffer for the video decoder.

Your issue is quite similar.

What we need are multi-planar functions/access for different bo handles in the sharing of non-contiguous memory by the UMD.

Sean

I think roi_rc_qp_delat_support should be fixed to roi_rc_qp_delta_support.
But I'm not sure how to do this without API-break.

Github has built-in support for mapping a well named gh-pages branch to github pages. Create an orphaned branch.

Older AMD (for newer AMD see issue #24) and Nvidia should be mapped to the drivers "r600" and "nouveau" respectively.

See:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=0c0f841e5de27d01312f8857641668ca439b1ab1
https://cgit.freedesktop.org/mesa/mesa/commit/?h=12.0&id=c01ebdc83e03307fa1373f3364131ed0c2d380ee

Tarball downloaded from https://www.freedesktop.org/software/vaapi/releases/libva/

$ md5sum libva-1.8.2.tar.bz2
beeaf50f0049692542ad9468d8b7d36f libva-1.8.2.tar.bz2
$ tar xf libva-1.8.2.tar.bz2

bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Child returned status 2
tar: Error is not recoverable: exiting now

Hi,

I'm using libfreenect2 which is using libva for hardware encoding/decoding AFAIK, and I've opened an issue there as well.
System is Ubuntu 16.04 amd64, and I've got libva installed from apt-get, version 1.7.0-1.

I keep getting random segmentation faults:

[New Thread 0x7fffd178a700 (LWP 23148)]
[Info] [Freenect2Impl] enumerating devices...
[Info] [Freenect2Impl] 8 usb devices connected
[Info] [Freenect2Impl] found valid Kinect v2 @2:5 with serial 001680660547
[Info] [Freenect2Impl] found 1 devices

Thread 1 "mario_node" received signal SIGSEGV, Segmentation fault.
0x00007fffeeda3347 in vaDisplayIsValid () from /usr/lib/x86_64-linux-gnu/libva.so.1
(gdb) bt
#0  0x00007fffeeda3347 in vaDisplayIsValid () from /usr/lib/x86_64-linux-gnu/libva.so.1
#1  0x00007ffff576a5c7 in libfreenect2::VaapiRgbPacketProcessorImpl::initializeVaapi() () from /home/mario/freenect2/lib/libfreenect2.so.0.2
#2  0x00007ffff5769408 in libfreenect2::VaapiRgbPacketProcessor::VaapiRgbPacketProcessor() () from /home/mario/freenect2/lib/libfreenect2.so.0.2
#3  0x00007ffff5756ee5 in libfreenect2::CpuPacketPipeline::CpuPacketPipeline() () from /home/mario/freenect2/lib/libfreenect2.so.0.2
#4  0x0000000000413e60 in freenect2::freenect2() ()

I took a look into their code, and the offending code appear to be:

  bool initializeVaapi()
  {
    /* Open display */
    static const char *drm_devices[] = {
      "/dev/dri/renderD128",
      "/dev/dri/card0",
      NULL,
    };
    for (int i = 0; drm_devices[i]; i++) {
      drm_fd = open(drm_devices[i], O_RDWR);
      if (drm_fd < 0)
        continue;
      display = vaGetDisplayDRM(drm_fd);
      if (vaDisplayIsValid(display))
        break;
      close(drm_fd);
      drm_fd = -1;
      display = NULL;
    }
    CHECK_COND(vaDisplayIsValid(display));

Please bear in mind the code (library) is executing under ssh but there is a gdm running, drivers are loaded, and the /dev/dri/* do exist.

Can someone please update the NEWS file ... for package maintainer it is good to know what did change and not to spend extra time in doing research ...
Many thanks and kind regards
Chris