[Bug 785085] multiple vaapi encoding pipelines on radeonsi segfault

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785085

--- Comment #14 from Julien Isorce <julien.isorce at gmail.com> ---
(In reply to Tomas Rataj from comment #13)
> Lets start with the invalid read. I am not very familiar with g_array but it
> seems that it is reallocating the data when new elements are added. Than the
> access using pointers YV12_fip and I420_fip is wrong. It can be done using
> array indexes for example. Please take a look on it.

According to the doc
https://developer.gnome.org/glib/stable/glib-Arrays.html#g-array-index it looks
ok so I am not sure what could be wrong.

I have not got the chance to try but since you are at it could you please try
to see what happen if you change the for loop end condition from i < n to i <
(n > 0) ? 1 : 0 ? Also can you check if ->len is > 0 ?
And what value has n when returning from vaQueryImageFormats in that same file
? Thx!

> 
> When I run pipeline with vaapipostproc as you suggested:
> 
> videotestsrc is-live=true !
> video/x-raw,width=1280,height=1024,framerate=20/1,format=BGRA !
> vaapipostproc ! vaapih264enc ! testsink
> 
> I am getting following error and SEGV right after that:
> 
> 0x15ef37c0 ERROR          vaapipostproc
> gstvaapipostproc.c:810:gst_vaapipostproc_process_vpp:<vaapipostproc0> failed
> to apply VPP filters (error 2)
> ==925== Thread 10 videotestsrc2:sr:
> ==925== Invalid write of size 8
> ==925==    at 0x41E8199: ??? (in /run/user/1000/orcexec.teOKWB (deleted))
> ==925==    by 0x82A44DA: video_orc_pack_BGRA (tmp-orc.c:4653)
> ==925==    by 0xA3689E5: convert_hline_generic (videotestsrc.c:1289)
> ==925==    by 0xA368697: videotestsrc_convert_tmpline (videotestsrc.c:273)
> ==925==    by 0xA368FAD: gst_video_test_src_smpte (videotestsrc.c:351)
> ==925==    by 0xA3663E3: gst_video_test_src_fill (gstvideotestsrc.c:1152)
> ==925==    by 0x6E055DE: gst_base_src_default_create (gstbasesrc.c:1474)
> ==925==    by 0x6E0896E: gst_base_src_get_range (gstbasesrc.c:2453)
> ==925==    by 0x6E0A2EE: gst_base_src_loop (gstbasesrc.c:2729)
> ==925==    by 0x558E240: gst_task_func (gsttask.c:332)
> ==925==    by 0x5AC8EED: g_thread_pool_thread_proxy (gthreadpool.c:307)
> ==925==    by 0x5AC84F4: g_thread_proxy (gthread.c:784)
> ==925==  Address 0x4035000 is not stack'd, malloc'd or (recently) free'd

This other issue looks like https://bugzilla.gnome.org/show_bug.cgi?id=779642

> When I comment out direct upload flag as you suggested in comment#7 it
> starts working and it also stops printing this error that was always there:
> 
> 0x9c76500 ERROR       vaapivideomemory
> gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot create
> a VA derived image from surface 0x9ee5b60

Could this is because the tiled format does not get mapped as linear as it is
on intel/vaapi. Maybe we can force linear when using mesa/vaapi. I think for
the download case there is an env var something like that. So yes you can leave
it as linear.

> 
> But it is still quite unstable under heavy load (>10 pipelines) with random
> crashes on different places. I will put here some traces after I will
> analyze it a bit more. What about the direct upload flag? Should I leave it
> commented out? Thanks a lot.

I think it has not been tested with many decoder and encoder instances in the
same process so we will have to solve all issues one by one I am afraid.
Any chance that you can compile mesa and gstreamer-vaapi with less
optimizations, like -O0.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.