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.
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
