Bug 97970 - i965 driver does not free buffers after they are passed to vaRenderPicture()
Summary: i965 driver does not free buffers after they are passed to vaRenderPicture()
Status: REOPENED
Alias: None
Product: libva
Classification: Unclassified
Component: intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: haihao
QA Contact: Sean V Kelley
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-29 07:51 UTC by Harri Syrja
Modified: 2017-05-29 08:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harri Syrja 2016-09-29 07:51:27 UTC
ffmpeg based hw accelerated encoding cause huge memory leagake by VA buffers due to a difference behaviour between the i965 driver implementation and the VAAPI specification.

See the bug: https://trac.ffmpeg.org/ticket/5871
Comment 1 Sean V Kelley 2016-11-03 21:28:32 UTC
We do not support FFMPEG Harri VAAPI software.  Please test with Gstreamer or Libyami if you want to test media stacks.
Comment 2 Harri Syrja 2016-11-03 22:29:03 UTC
Support or not technically that issue has nothing to do with ffmpeg or testing. Issue is the difference between VAAPI specification and Intel VAAPI implementation i965_video, if that is okay then bug report was irrelevant?
Comment 3 Sean V Kelley 2016-11-04 00:37:51 UTC
Harri,

If you can duplicate with a supported project like Libyami or Gstreamer, feel free to contribute your testing.

Thanks,

Sean
Comment 4 Harri Syrja 2016-11-04 19:49:12 UTC
I don't know about libyami, but at least Gstreamer manually releases these buffers so there is no similar issue. I could request if ffmpeg community implements same thing in their code, but I think then the VA-API spec should be fixed.

Harri
Comment 5 sreerenj 2016-11-04 20:57:22 UTC
It is true that gstreamer-vaapi releasing all the buffers manually, not trusting the driver :) Probably libyami is also doing the same since the initial code base was based on gstreamer-vaapi.

I would prefer to keep this bug open so that some can investigate at least in future.
Comment 6 Víctor Jáquez 2016-11-07 11:15:09 UTC
(In reply to sreerenj from comment #5)
> I would prefer to keep this bug open so that some can investigate at least
> in future.

I agree with Sree. There should be a unit test to check the comply with the spec.

But in this case, I thing we should change the spec :/
Comment 7 PengChen 2016-11-08 00:56:54 UTC
In my opinion, it is not suitable to automatically free buffers by the driver. those buffers may also be used for next frame rendering by the APP and driver knows nothing about it. I suggest to update the spec of those APIs and let APP to free those buffers by themselves. Or add a new API to tell driver to free it or not and keep the default as not free
Comment 8 Sean V Kelley 2016-11-08 01:04:33 UTC
I agree with Peng Chen.  We can simply update the Spec, which is what I told Haihao to do.

Thanks,

Sean
Comment 9 Sean V Kelley 2016-11-08 01:07:27 UTC
By the way, I am upstreaming a VAAPI conformance test framework.  Probably later this week.
Comment 10 sreerenj 2016-11-08 10:16:40 UTC
I am reopening this bug , we can close this, once the corresponding VA spec changes land in master. Hope it is fine for all :)
Comment 11 Josep Torra 2017-01-05 13:31:11 UTC
See this https://lists.freedesktop.org/archives/libva/2012-July/000952.html discussion related to this topic.
Comment 12 haihao 2017-01-09 07:46:01 UTC
I updated the spec and no effort is needed for the driver.
Comment 13 nfxjfg 2017-05-29 08:43:10 UTC
Congratulations, you broke everything!

http://ffmpeg.org/pipermail/ffmpeg-user/2017-May/036232.html

If I read this right, you now have the choice between:
- memory leaks
- random crashes

Your fix is partial at best.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.