Skip to content
This repository has been archived by the owner on Oct 23, 2023. It is now read-only.

VP9 decoder produce video frames whith rendering artifacts #837

Open
angelo-p opened this issue Mar 23, 2018 · 13 comments
Open

VP9 decoder produce video frames whith rendering artifacts #837

angelo-p opened this issue Mar 23, 2018 · 13 comments

Comments

@angelo-p
Copy link

Hello,
I am running with libyami tag 1.2.0-RC1 on an Apollo Lake board 1BN-E ES4.1 and I am seeing a lot of rendering artifacts/frame corruptions when playing vp9 video files.
example test file:
feelings_vp9-640x360.webm

What is the status of the VP9 decoding support?
Would updating to tag 1.3.0-RC1 fix the issue?

Thanks,
Angelo

@uartie
Copy link
Contributor

uartie commented Mar 23, 2018

It could be a driver issue. If you are using intel-vaapi-driver (i965), there were several VP9 issues fixed recently (https://github.com/intel/intel-vaapi-driver/issues?utf8=%E2%9C%93&q=is%3Aissue+VP9)

@xuguangxin
Copy link
Contributor

@angelo-p , @uartie the vp9 decoder in good shape for a long time, we have 3300+ test clips includes 8/10 bits. We checked decoded frame with libvpx, 99.73% are bit match.
@angelo-p , could you share the stream with us. So we can check what's wrong.
also which driver you used?

@angelo-p
Copy link
Author

I uploaded the file to my drobbox account.
you can access at:
https://www.dropbox.com/s/cimapj5d0z66kz0/feelings_vp9-640x360.webm?dl=0

we are using intel-vaapi-driver at version 1.8.4
vainfo
libva info: VA-API version 0.40.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/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 0.40.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.8.4.pre1 (1.8.4.pre1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
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
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD

Thanks,
Angelo

@chivakker
Copy link
Contributor

chivakker commented Mar 23, 2018 via email

@xuguangxin
Copy link
Contributor

Thanks, @chivakker help to test.@angelo-p could you try latest vaapi and libyami.

thanks

@angelo-p
Copy link
Author

xuguangxin,

I cannot go to libva-2.1.0.
our graphics group is currently lock with libva-1.8.0

@chivakker
Copy link
Contributor

@angelo-p which kernel version are you using? Depending on that you'd need to carry some patches on your environment.

@xuguangxin
Copy link
Contributor

if you check driver release notes, no big changes for vp9 decoder.
@chivakker 's point is good, it may related to kernel or something.
@angelo-p, is it possible to try libva 2.0 on your side, It will help us isolate the problem. If it also failed, it appears a kernel issue. If it's ok, maybe you can cherry-pick some patch from libva.

thanks

@angelo-p
Copy link
Author

angelo-p commented Jun 1, 2018

@xuguangxin,
we updated libva to version 2.0.0 and I still can see macroblocking issues on the vp9 stream.
see vainfo putput below:
vainfo
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.0.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 2.1.1.pre1 (2.1.1.pre1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
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
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD

I also have a 1920x800 AVC stream that shows some macroblocking issue.
I put the stream at:
https://www.dropbox.com/s/ozzsepl90f6epd1/vobsub_sample.mkv?dl=0
A screenshot exposing the problem is at:
https://www.dropbox.com/s/yvcpwpa9dtr0rqg/screenshot.jpg?dl=0
Can you please take a look?
Thanks,
Angelo

@xuguangxin
Copy link
Contributor

Hi @angelo-p ,
Sorry I can't reproduce your issue.
I tried your stream on BXT.

Could you help reproduce my steps.
./tests/yamidecode -i vobsub_sample.mkv -m -2, you will get md5 at output 08dc6f4627328bdd20afe81674ca7b52
ffmpeg -i vobsub_sample.mkv t.yuv && md5sum 5.yuv, you will get md5 08dc6f4627328bdd20afe81674ca7b52
this means the yami's output same as ffmpeg sw output.

my libva version is

commit b3be72a5a110880f70626d7c3bed953cdde124b2
Author: Mark Thompson <[email protected]>
Date:   Thu Apr 26 20:24:32 2018 +0100

    Add missing rate control parameters to trace output

    Signed-off-by: Mark Thompson <[email protected]>

driver version is

commit 40b15a5c6c0103c23a5db810aef27cf75d0b6723
Author: Mark Thompson <[email protected]>
Date:   Wed Apr 25 23:44:33 2018 +0100

    Use f_code to determine max MV length

    The motion vector length is constrained by the level but not set by it -
    we should instead use the f_code values to set the max MV length.

    This fixes encoding when the f_code values are not set to the highest
    allowed for the level, and also adds support for intermediate levels such
    as High 1440 which were not previously handled here.

    Signed-off-by: Mark Thompson <[email protected]>

@angelo-p
Copy link
Author

angelo-p commented Jun 4, 2018

Hi @xuguangxin
You are right, I got the same md5:
yamidecode -i /amedia/vobsub_sample.mkv -m -2
libva info: VA-API version 0.40.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
1426 frame decoded, fps = 30.32. fps after 5 frames = 30.33.
The whole frames MD5:
08dc6f4627328bdd20afe81674ca7b52

@xuguangxin
Copy link
Contributor

if you got the same md5, it proves the decoder is good, any bad thing happened in the display?
One thing I should mention, you can't modify the output frame, we will use output frame as a reference for future frames

@angelo-p
Copy link
Author

angelo-p commented Jun 8, 2018

Hi xuguangxin,
Can you explain what you mean by "you can't modify the output frame" ?
We are using libyami External Allocator scheme and as long as libyami call the putSurface() callback, our software will release to our surface pool for reuse the output frame as soon as it has been rendered.
Am I correct in assuming that when libyami jas called the putSurface callback, our software is free to do whatever it want with the just release surface ?
Thanks,
Angelo

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants