[Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface

Andy Furniss adf.lists at gmail.com
Mon Oct 3 21:53:51 UTC 2016


Zhang, Boyuan wrote:
> Hi Andy,
>
> Thanks for the testings.
>
> Regarding to the inconsistencies, the current Vaapi dual instances
> encoding behaviour is random. Whether or not the dual instances is
> being used depends on how early the player calls sync_surface
> function according to the current gstreamer-vaapi's mechanism. e.g.
> if the player calls sync_surface too early, then we don't have
> enough time to receive and process the 2nd frame and we can only end
> up with single instance encoding for this frame as a result. And the
> random player behaviours depends on the current environment, for
> example cpufreq might be one factor. As a result, we don't guarantee
> the consistency especially when rate control is enabled for dual
> instances Vaapi encoding, since the randomness could result
> different calculations.

OK, I guess OMX is less dependent on player, because I can't reproduce
with that and speed suggests I get dual instance.

So far I can only get the low bitrate files with vbr. cbr always at
least seems to come out the correct size.

cpq is also affected by the issue = different md5sums and sometimes out
of order.

> For the corruption/wrong frame order issue, could you please provide
> more detailed information for reproduction? e.g. the clips and
> commands that can reproduce the issue. Does this issue only happen
> after enabling dual instance patch?

The corruption I mentioned was due to low bitrate sometimes for vbr.

The out of order seems quite easy to produce with 1080p input.
I tend to use raw video, but transcoding can also reproduce (just I
prefer raw as at least I know it's the enc rather that the dec).

Resetting mesa onto this commit (+applying patch 2 and later fix patch +
firmware patch) reproduces the issue. I also previously tested last
firmware (md5sum only) and it had the issue.

Resetting mesa on the commit before or just disabling dual instance on
head does not have the issue.

The exact command for this test was -

for x in $(seq 1 20); do gst-launch-1.0 -f filesrc 
location=/mnt/ramdisk/raw-1000f-1080p.nv12 blocksize=3110400 ! 
video/x-raw,format=NV12,width=1920,height=1080,framerate=50/1 ! queue ! 
vaapih264enc ! video/x-h264, profile=baseline ! filesink 
location=/mnt/ramdisk/out-$x.264; done

Not all of these will have the reversal and the 5fd5c....
match single inst but here's a bad one out of this run
reversal and some corruption.

out-2.264 - 
https://drive.google.com/file/d/0BxP5-S1t9VEENjFkME1WTktiSUE/view?usp=sharing


  md5sum /mnt/ramdisk/out-*
80430ea3dcffff361dd9fe57a8c7746b  /mnt/ramdisk/out-10.264
a68f7218e81a6cdf9f3d20eaaf57a48a  /mnt/ramdisk/out-11.264
68d6de4f53f73c72f48f42a08b56a78b  /mnt/ramdisk/out-12.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-1.264
6be1f7bcea99194f59d7feaf827fe4e2  /mnt/ramdisk/out-13.264
d8a184f149f59ab308f0deec9bc9f53c  /mnt/ramdisk/out-14.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-15.264
4a4b2dbeef4a6ef2e6327b455f7c8b87  /mnt/ramdisk/out-16.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-17.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-18.264
20f53e73ba5bc47f05531ddef7e9a849  /mnt/ramdisk/out-19.264
c1f6df236900bece57853dbec54718d1  /mnt/ramdisk/out-20.264
e61428d61ff5673dbed8f11a4c347ac7  /mnt/ramdisk/out-2.264
3106e03284b9dbf687f9a46a1c526ba7  /mnt/ramdisk/out-3.264
53c104d68ddd90e9414ca9be4dc47c40  /mnt/ramdisk/out-4.264
dae66f3dfea8edec2c6862782b007a0e  /mnt/ramdisk/out-5.264
910cdc32770ce3c78e84300fa851986a  /mnt/ramdisk/out-6.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-7.264
700112ae272d52985948052efe345245  /mnt/ramdisk/out-8.264
03857eddbabfc4747cd6450d58350548  /mnt/ramdisk/out-9.264

Before dual inst

md5sum /mnt/ramdisk/out-*
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-10.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-11.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-12.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-1.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-13.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-14.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-15.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-16.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-17.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-18.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-19.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-20.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-2.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-3.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-4.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-5.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-6.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-7.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-8.264
5fd5c5496a26e13158e31fbdb3c68e7b  /mnt/ramdisk/out-9.264



More information about the mesa-dev mailing list