Re: [Mesa-dev] VAAPI encoder and OpenGL

2020-08-11 Thread Daniel Gomez
Hi Thong,


Thanks for the support.

I think the problem is on the mesa vaapi driver (libva-vaapi-driver) somehow
but I tried your firmware anyway and the problem persists in regards to the
encoder.

Now, I have updated my system and I'm running the following:

root@qt5122:/mnt# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.8 (libva 2.8.0)
vainfo: Driver version: Mesa Gallium driver 20.0.2 for AMD Radeon R7
Graphics (CARRIZO, DRM 3.36.0, 5.5.0-qtec-standard, LLVM 8.0.0)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

As you can see, I'm using mesa 20.0.2 and libva 2.8.0.

Running the following gstreamer pipelines I can see how the vaapi driver fails:

gstreamer pipelines:

Gst.parse_launch(
"udpsrc address=224.1.1.1 port=5000
multicast-iface=enx24f5a2f1ba7a ! " \

"application/x-rtp,media=video,payload=33,clock-rate=9,encoding-name=MP2T
! " \
"rtpmp2tdepay ! tsdemux name=td td.video_0_0041 ! multiqueue !
h264parse ! " \
"queue ! vaapidecodebin !
video/x-raw,format=NV12,width=1920,height=1080 ! queue ! " \
"vaapih264enc ! queue ! fakesink dump=1"
)
Gst.parse_launch(
"filesrc name=fsrc location=/mnt/tmp/theoffice.ts ! " \
"tsdemux name=td td.video_0_0041 ! h264parse ! " \
"queue name=qvaapidec2in ! vaapidecodebin ! " \
"video/x-raw,format=NV12,width=1920,height=1080 ! " \
"queue name=qvaapidec2out ! intervideosink channel=chv1"
)

pipeline2 = Gst.parse_launch(
"intervideosrc channel=chv1 ! videoconvert ! " \
"video/x-raw,format=NV12,width=1920,height=1080 ! " \
"queue name=qvaapienc2in ! vaapih264enc name=enc " \
"rate-control=4 bitrate=25000 ! video/x-h264,profile=high ! " \
"queue name=qvaapienc2out ! " \
"fakesink dump={}".format(encdump)
)

Note: I can send the script if you want so, it's easier to replicate it.

GStreamer log:

0:00:00.464680040   948 0x55f0ec6b4b70 ERROR   vaapivideomemory
gstvaapivideomemory.c:741:gst_video_info_update_from_surface: Cannot
create a VA derived image from surface 0x55f0ec6de4a0
0:00:00.502405919   948 0x55f0ec6b4f20 FIXMEdefault
gstutils.c:3981:gst_pad_create_stream_id_internal:
Creating random stream-id, consider implementing a deterministic way
of creating a stream-id
0:00:00.528549645   948 0x55f0ec6b4d90 ERROR   vaapivideomemory
gstvaapivideomemory.c:741:gst_video_info_update_from_surface: Cannot
create a VA derived image from surface 0x55f0ec6e0b20
0:00:00.529446550   948 0x55f0ec6b4d90 TRACE GST_TRACER
:0:: queuelevel, queue=(string)qvaapienc2in, size_bytes=(uint)0,
max_size_bytes=(uint)10485760, size_buffers=(uint)0,
max_size_buffers=(uint)200, size_time=(string)0:00:00.0,
max_size_time=(string)0:00:01.0;
0:00:00.529557834   948 0x55f0ec6b4d90 ERROR  vaapi
gstvaapiencoder.c:543:gst_vaapi_encoder_put_frame: failed to encode
frame (status = -1)
0:00:00.529575486   948 0x55f0ec6b4d90 ERRORvaapiencode
gstvaapiencode.c:722:gst_vaapiencode_handle_frame: failed to encode
frame 0 (status -1)

So, I guess that's the reason I was seeing at the beginning how the queue
previous to the encoder was filled up to the maximum and therefore,
buffers were never consumed by the vaapi encoder.


At the same time, I tried to replicate the same environment in my laptop
by using the VAAPI driver provided by intel (intel-vaapi-driver) instead of
the one provided by mesa (libva-mesa-driver) with the same gstreamer-vaapi,
gstreamer and libva versions and the problem only occurs on the setup where
I'm running the mesa vaapi driver.

Any ideas?

Thanks

On Thu, 6 Aug 2020 at 23:42, Thai, Thong  wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> Hi Daniel,
>
>
>
> Can you try the attached firmware file and see if it works, and/or fixes your 
> iss

Re: [Mesa-dev] Gitlab Labels

2020-08-11 Thread Roman Gilg
On Tue, Aug 11, 2020 at 2:21 PM Mike Blumenkrantz
 wrote:
>
> Hi All,
>
> I was thinking it'd be nice to have labels in Mesa for difficulty in order to 
> help both newer and more experienced contributors choose issues/MRs which fit 
> their level of comfort and available time. This might look like:
>
> * easy
> * challenging
> * impossible

I think that's a good idea and as an example I created a system like
this in KWinFT [1]. There I'm using scoped labels which are to my
knowledge at the moment not yet available in the open source version
of GitLab, but it can also be done without this feature.

I chose also three levels and named them:
* beginner
* intermediate
* expert

In the hope that these terms are easy to understand and also to some
degree are motivating but sound neither condescending nor pretentious
(expert maybe but it fitted the other ones).

Colors are light blue, yellow, dark-orange and the label description
is always "difficulty to solve the issue is estimated to be {low,
middle, high}".

With good label descriptions I don't think there needs to be separate
documentation. One problem that might arise is that these labels only
are useful when people actually use them and you can forget easily
about them. I also always have to remind myself to add them to new
issues.

Cheers
Roman

[1] https://gitlab.com/groups/kwinft/-/issues

> Naturally we could then also create a task to document these labels, which I 
> assume we would tag as "impossible".
>
>
> Regards,
> Mike
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] Gitlab Labels

2020-08-11 Thread Mike Blumenkrantz
Hi All,

I was thinking it'd be nice to have labels in Mesa for difficulty in order
to help both newer and more experienced contributors choose issues/MRs
which fit their level of comfort and available time. This might look like:

* easy
* challenging
* impossible

Naturally we could then also create a task to document these labels, which
I assume we would tag as "impossible".


Regards,
Mike
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev