My Experiences with Video in E-Prime - freezing and jumping issues

[Benny Liebold]

After having read at lot in this group and the forum I feel the need
to share the experiences I made in the past few days regarding two
video issues.

For my trial I wanted to use 180 video stimuli (each about 5 s) that
were presented in a pre-randomized order. After intense testing of my
trial I experienced two major issues regarding the presentation of the
video stimuli. (1) Some test machines crashed during the trial with a
frozen picture and an audio loop or simply displayed an error that
should not be related to the design of the trial. (2) Some videos were
aborted after about 700ms of playtime and the script jumped to the
next one. I will refer to the latter one as “video jumping”.

Those two issues gave quite me a headache … especially because the
machine I used to design the trial did not produce any of these errors
at all. But at that point I realized, that I used quite a potent
machine for the trial design, being a 27” iMac with a 3.3 GHz Intel
Core i7, 8GB Ram and a Radeon 4870 with 1 GB of video memory running
Windows 7 x64 (fully updated). The test machines were not slow at all
(AMD 64 X2 with 2.7 GHz, 4 GB Ram and a onboard Video Card with 256 MB
of video memory running Windows 7 x86, fully updated), but the
difference is quite significant. So this really had to be the cause
for both issues I mentioned above. Consequently I had to deal with the
video codec I used as I already used the latest build of E-Prime 2.0,
the DivX codec packet and the K-Lite codec packet. The movie display
did work, but it was quite unstable as mentioned above.

At the beginning I used 720p-material (1280x720, 29,97 fps) and the h.
264 codec as it is know for its superb compression abilities. The
other side of the coin is the high CPU usage it produces when decoding
the videos. Speaking of CPU-usage: I realized that E-Prime only uses
one CPU-core! This really is a problem when you have quite potent
multi-core CPUs but with a poor single-core performance. In fact the
iMac’s Core i7 should be at least twice as fast as the AMDs in the
test machines when using a single core. This is due to the higher CPU-
clock, the i7’s ability to hyperthread and it’s Turbo mode which
boosts the clock to 3.6 GHz when using only one core. The architecture
is way ahead of the AMDs as well. So this really was on the one hand
the Problem of my trial and on the other hand the weakness of the
current E-Prime build. Why not using the full capabilities of current
CPUs?

Back to my trial: Consequently I had to lower the CPU-usage during
video playback. So I re-encoded my files into MPEG1 as stated by many
forum threads and built a small trial only running the stimuli in a
randomized order. Additionally I logged the Start and Finish Times of
the slides. After some testing with various video resolutions and bit
rates I came to the following conclusions.

1. the most important: take some time for intense testing and maxing
out the stimulus quality (if necessary as in my case)
2. and probably the second most important: use very fast machines/CPUs
with high single-core capabilities (i.e. Intel Core i5 and i7; an
older 3 GHz Intel Quadcore worked flawless as well) for the trial to
avoid performance issues and video jumping
3. preparation: deactivate any unnecessary services to maximize the
machine performance (Windows-Key+A; type “msconfig”; go to services;
mark “hide windows services” and deactivate all unnecessary services;
go to system start and deactivate any unnecessary programs that would
run in the background otherwise); also deinstall your virus scanning
program and deactivate the Windows Defender (and its real time
scanning ability); deactivate Windows 7 Aero; pluck out your network
cable to avoid viruses ☺
4. use MPEG1: this codec really IS CPU-friendly
5. in Codec Config I finally used the standard MPEG-codecs; only for
audio I used ffdshow-Audio as provided by the K-lite codec packet
6. do NOT – under any circumstances – use the “stretch video” function
if you experience issues related to poor performance; instead aim for
higher resolutions in the initial conversion process and display the
videos 1:1
7. set “stop after” to “no” if you don’t need the function (don’t know
if that really helped though …)
8. the freezing-script-issue seemed to be related to the available
video ram; every time the overall file size reached about 230 MB there
was a 50% chance a system would freeze; so keep your file sizes small!
Alternative: Use dedicated video cards with at least 512 MB of video
ram
9. try to experiment with the bit rate; for me bit rates between 800
kbps and 1300 kbps worked quite well; every thing higher would lead to
a freezing script; every thing lower lead to poor video quality; aim
for a bitrate as high as possible (in fact the iMacs Core i7 could
handle 6000 kbps in h.264 easily without any mistake; I settled with
1024x576 at 1000 fps for the AMDs, this led to 0,625 jumped videos in
average per trial, nothing the final data could not handle)
10. video jumping can be observed by calculating the difference
between the finish time and the start time of a slide; values lower
than a threshold you have to define indicate jumped videos
11. run theses tests on all of your test systems at the same time to
compare the results and write down any crashes and video jumps per
system to compare individual system stability as well
12. finally, important to avoid losing cases: split your Experiment
into the smallest possible count of parts; this way crashed parts can
be re-initiated without starting allover again or loosing the
participants data

I really hope this helps! So good luck and interesting data for future
experiments.

---

Benny Liebold, B.A.
Academic Assistant

Chair of Media Psychology
Institute of Media Research

Faculty of Humanities
Chemnitz University of Technology
Thüringer Weg 11, 09126 Chemnitz, Germany

[Katie Jankowski]

Hi Benny,

Thanks for your post. I have been having some video issues as well, which I may have resolved finally, thanks to the great help of this google group (thank you David Mcfarlane!) and the EPRIME support staff.

A few of your recommendations were counter to either what I was recommended by the EPRIME support staff, or what I used on my own, so I thought I would ask for more information to better understand what these settings do and which might be best for my task.

1. Why do you suggest not using stretching? Originally, my videos only displayed a small portion of the video itself (videos are of a person standing but the video zoomed in to only display the person's nose). Stretching helped resolve this problem so that the entire video was displayed. Why do you recommend not using this option?

2. Why do you recommend deselecting the "stop after" command? The EPRIME staff had suggested selecting "yes" and specifying to stop after "next onset time". I would like to better understand when this is a good and when this is a poor option.

3. Why do you recommend changing to mp1? I have never worked with video files until now, so I am very ignorant. My first thought would be bigger/more advanced is better (i.e., use mp4 files). What are the pros and cons of using mp1 vs mp4 movie files with EPRIME?

Thanks for your help,

Katie

[David McFarlane]

Katie,

Benny might well speak for himself here, but I
would like to step in with a few comments myself...

1. Benny says not to use Stretch "if you
experience issues related to poor performance",
and to "aim for higher resolutions in the initial
conversion process". So first, you may well use
Stretch if it does not result in performance
problems. That said, using Stretch puts a
greater processing load on E-Prime during your
task, everytime you run it, so all things
considered I would rather do that processing once
on all my movie files outside of E-Prime, and
then run them unstretched in E-Prime. Second, I
think Benny was referring to using Stretch to
*enlarge* the movie display, which could result
in visible pixelation problems. In this case,
definitely better to find some way to enlarge
your movie to higher resolution outside of
E-Prime. In your case, however, you want to
*reduce* the movie frame to make it fit on your
monitor, so you might not suffer that loss in
image quality with Stretch. But then, your movie
files just take up more disk space and require
longer load times than you really need for the
display resolution that you end up using. So if
you care about fine efficiency matters like that,
or would rather not cede that bit of stimulus
quality control to E-Prime, then you might want
to convert those files the resolution you want,
otherwise if everything works on your machines
then you might as a matter of convenience just leave everything as is.

2. "Stop After" has a specific use, and should be
set to "Yes" (the default) or "No" as appropriate
-- see further discussion at
https://groups.google.com/d/topic/e-prime/LHq3Niv1zfk
. Indeed, "Yes" could pose a problem if you have
"Stop After Mode" set to OffsetTime, and
PreRelease set to "same as duration" -- in this
case, movie playback would be stopped almost as
soon as it began! Perhaps Benny ran into this,
and just found it easier to set "Stop After" to
"No" for his use. If you *do* want movie
playback to be stopped at some time depending on
the Duration of your MovieDisplay object, then of
course you would want to set "Stop After" to
"Yes", and then pay attention to "Stop After Mode" and PreRelease.

3. MPEG-1 may not give the best "performance",
but has just been found to be the plainest,
safest codec to use for the best possibility of
getting your movies to work at all in E-Prime
(note that the movie files for the MovieRT
example program that comes with E-Prime use this
codec). I like it when things Just Work, so I
like MPEG-1 unless we really need better
"performance". In that case, DivX comes
recommended (and you should find other
discussions about this). In particular, here (as
in much of life), "bigger/more advanced" is often
*not* better (I find that in this modern age
"progress" often means "regress" -- e.g., Windows
8!), and when it *is* better it often means
"bleeding edge", not well supported yet, use at
your own peril as long as you like being a
technology pioneer (which may or may not fit with
your mission to be a scientific pioneer).

Finally, I want to strongly second Benny's advice
to test, test, and test some more, working up
from several *small* demo programs to your actual experiment program!

Hope that helps.

-----
David McFarlane
E-Prime training
online: http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster )

/----
Stock reminder: 1) I do not work for PST. 2)
PST's trained staff take any and all questions at
https://support.pstnet.com , and they strive to
respond to all requests in 24-48 hours, so make
full use of it. 3) In addition, PST offers
several instructional videos on their YouTube
channel (http://www.youtube.com/user/PSTNET
). 4) If you do get an answer from PST staff,
please extend the courtesy of posting their reply
back here for the sake of others.
\----

>next one. I will refer to the latter one as “video jumping†.

>
>Those two issues gave quite me a headache … especially because the
>machine I used to design the trial did not produce any of these errors
>at all. But at that point I realized, that I used quite a potent

>machine for the trial design, being a 27†iMac with a 3.3 GHz Intel

>Core i7, 8GB Ram and a Radeon 4870 with 1 GB of video memory running
>Windows 7 x64 (fully updated). The test machines were not slow at all
>(AMD 64 X2 with 2.7 GHz, 4 GB Ram and a onboard Video Card with 256 MB
>of video memory running Windows 7 x86, fully updated), but the
>difference is quite significant. So this really had to be the cause
>for both issues I mentioned above. Consequently I had to deal with the
>video codec I used as I already used the latest build of E-Prime 2.0,
>the DivX codec packet and the K-Lite codec packet. The movie display
>did work, but it was quite unstable as mentioned above.
>
>At the beginning I used 720p-material (1280x720, 29,97 fps) and the h.
>264 codec as it is know for its superb compression abilities. The
>other side of the coin is the high CPU usage it produces when decoding
>the videos. Speaking of CPU-usage: I realized that E-Prime only uses
>one CPU-core! This really is a problem when you have quite potent
>multi-core CPUs but with a poor single-core performance. In fact the

>iMac’s Core i7 should be at least twice as fast as the AMDs in the

>test machines when using a single core. This is due to the higher CPU-

>clock, the i7’s ability to hyperthread and it’s Turbo mode which

>boosts the clock to 3.6 GHz when using only one core. The architecture
>is way ahead of the AMDs as well. So this really was on the one hand
>the Problem of my trial and on the other hand the weakness of the
>current E-Prime build. Why not using the full capabilities of current
>CPUs?
>
>Back to my trial: Consequently I had to lower the CPU-usage during
>video playback. So I re-encoded my files into MPEG1 as stated by many
>forum threads and built a small trial only running the stimuli in a
>randomized order. Additionally I logged the Start and Finish Times of
>the slides. After some testing with various video resolutions and bit
>rates I came to the following conclusions.
>
>1. the most important: take some time for intense testing and maxing
>out the stimulus quality (if necessary as in my case)
>2. and probably the second most important: use very fast machines/CPUs
>with high single-core capabilities (i.e. Intel Core i5 and i7; an
>older 3 GHz Intel Quadcore worked flawless as well) for the trial to
>avoid performance issues and video jumping
>3. preparation: deactivate any unnecessary services to maximize the

>machine performance (Windows-Key+A; type “msconfig†; go to services;
>mark “hide windows services†and deactivate all unnecessary services;

>go to system start and deactivate any unnecessary programs that would
>run in the background otherwise); also deinstall your virus scanning
>program and deactivate the Windows Defender (and its real time
>scanning ability); deactivate Windows 7 Aero; pluck out your network

>cable to avoid viruses ☺

>4. use MPEG1: this codec really IS CPU-friendly
>5. in Codec Config I finally used the standard MPEG-codecs; only for
>audio I used ffdshow-Audio as provided by the K-lite codec packet

>6. do NOT – under any circumstances – use the ““stretch video†function

>if you experience issues related to poor performance; instead aim for
>higher resolutions in the initial conversion process and display the
>videos 1:1

>7. set “stop after†to “no†if you
>don’t need the function (don’t know

>Thüringer Weg 11, 09126 Chemnitz, Germany