[Intel-gfx] Multiple Instances of h264encode: Corruption and Cross-process interference

[Bruce]

*System from vainfo*


 *libva info: VA-API version 0.34.0*

*libva info: va_getDriverName() returns 0*

*libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so*

*libva info: Found init function __vaDriverInit_0_34*

*libva info: va_openDriver() returns 0*

*vainfo: VA-API version: 0.34 (libva 1.2.2.pre1)*

*vainfo: Driver version: Intel i965 driver - 1.2.1*

*vainfo: Supported profile and entrypoints*

*      VAProfileNone                   : VAEntrypointVideoProc*

*      VAProfileMPEG2Simple            : VAEntrypointVLD*

*      VAProfileMPEG2Simple            : VAEntrypointEncSlice*

*      VAProfileMPEG2Main              : VAEntrypointVLD*

*      VAProfileMPEG2Main              : VAEntrypointEncSlice*

*      VAProfileH264Baseline           : VAEntrypointVLD*

*      VAProfileH264Baseline           : VAEntrypointEncSlice*

*      VAProfileH264Main               : VAEntrypointVLD*

*      VAProfileH264Main               : VAEntrypointEncSlice*

*      VAProfileH264High               : VAEntrypointVLD*

*      VAProfileH264High               : VAEntrypointEncSlice*

*      VAProfileVC1Simple              : VAEntrypointVLD*

*      VAProfileVC1Main                : VAEntrypointVLD*

*      VAProfileVC1Advanced            : VAEntrypointVLD*

*      VAProfileJPEGBaseline           : VAEntrypointVLD*



*How to produce a video corruption with h264encode*
*Background*
When encoding two files, there are four significant events:
  A. Begin encoding first file
  B. Finish encoding first file
  C. Begin encoding second file
  D. Finish encoding second file

There are three possible orderings for these four events:


ABCD (no overlap - first file is finished before second begins) **No
corruption observed
    A----------B         C----------D


ACDB (complete overlap - the second file begins after and finishes before
the first)  **No corruption observed
   A----------------B
         C----D

ACBD (partial overlap - the second file begins before the first file
finishes)
   A----------B
          C----------D


The last case ACBD (partial overlap) always results in video corruption.
The video output of second file is correct up to event B. Beyond that
point, the video is corrupt.


*Procedure To Reproduce*You will need to start with a yuv formatted input
file. If you don't have one, you can create one with ffmpeg from any source
video.

1.  Determine how long it takes to encode the file
  # time /root/libva-1.2.1/test/encode/h264encode --srcyuv in.yuv
-framecount 0 -f 25 -o out1.mp4 > /dev/null 2> /dev/null

  real    0m14.984s
  user    0m6.690s
  sys    0m10.115s

So, in this example, my file takes 15 seconds to encode so I will start the
second video encoding about 7 seconds after the first to make
sure they overlap in the ACBD order described above.

2. Open two separate terminals.  Run these commands, one in each terminal,
with the 2nd command executed about 7 seconds after the first (this delay
is to ensure the right overlap)

  # date ; time /root/libva-1.2.1/test/encode/h264encode --srcyuv in.yuv
-framecount 0 -f 25 -o out1.mp4 >/dev/null 2>/dev/null ; date
  # date ; time /root/libva-1.2.1/test/encode/h264encode --srcyuv in.yuv
-framecount 0 -f 25 -o out2.mp4 >/dev/null 2>/dev/null ; date

Here is sample output (Note: h264encode output is suppressed):


*Terminal 1:*  # date ; time /root/libva-1.2.1/test/encode/h264encode
--srcyuv in.yuv -framecount 0 -f 25 -o out1.mp4 >/dev/null 2>/dev/null ;
date
  Wed Feb 12 16:44:08 CST 2014

  real    0m15.084s
  user    0m5.698s
  sys    0m9.601s
  Wed Feb 12 16:44:23 CST 2014


*Terminal 2:*  # date ; time /root/libva-1.2.1/test/encode/h264encode
--srcyuv in.yuv -framecount 0 -f 25 -o out2.mp4 >/dev/null 2> /dev/null ;
date
  Wed Feb 12 16:44:15 CST 2014

  real    0m9.097s
  user    0m3.431s
  sys    0m5.660s
  Wed Feb 12 16:44:24 CST 2014

Note that the second encoding finishes only one second after the first
despite being started 7 seconds later. Testing with different offsets
confirms the second encoding always finishes immediately after the first,
regardless of start time.



*Verify Corruption Exists*



1.      Use the file compare utility cmp to compare files:

#cmp - b out1.mp4 out2.mp4

2.      If the files are identical, there will be no output. What I see is
the files begin showing differences at a position relatively proportional
to my start offset. For example, starting 7.5 seconds after the first
video, using 15 second videos, the corruption appears in the middle of the
file.

If you were to play the file, you would observe the file plays correctly to
the point of corruption. At that point, the video freezes or flickers
between 2 frames.



Note: We're observing these corruptions in our own code, which is unrelated
to h264encode. We used h264encode to eliminate all variables and exonerate
our code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140213/45181e5b/attachment.html>