Julien Isorce wrote:
Hi Christian,
I have 2 remarks:
1: I am sure you have the clear answer to the following questions, so
maybe add a comment in the commit message: Isn't the thread safety
delegated to the application that use vaapi ? like it is designed for
many libraries. I tried to find answer in vaapi-intel-driver and
libva but it is not obvious. I'll try the mailing list. For vdpau you
are right: "All VDPAU functionality is fully thread-safe; any number
of threads may call into any VDPAU functions at any time. VDPAU may
not be called from signal-handlers." I could not find something
equivalent for vaapi but I guess it would make sense if it was the
same.
Oh, interesting as ffmpeg recently decided hwdec should be forced to
single thread for some reason. It hurts perf for using ffmpeg cli.
2: Sometimes lock/unlock is just surrounding the "get". Shouldn't the
mutex be kept locked until the function is done accessing the
resources returned by this "get". (if it was refcounted you would not
unref before you continue to access it) (Also I cannot see any
lock/unlock in vlVaQueryVideoProcPipelineCaps)
On vaapi - well I can lock mt h/w with gstreamer - but then that may
just be my setup or an amd thing.
Slightly unrelated question = with vaapi using mpeg2 do you get the same
result as vdpau or s/w?
I can't get either to be the same md5sum as s/w (I can with h264).
Visually vaapi is noticeably worse than vdpau on my h/w so I wondered
whether this was a s/w mesa/vl thing rather than h/w specific and
whether you saw it on different h/w.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
