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

Fri Apr 4 16:25:17 UTC 2014

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.
\----

At 4/4/2014 03:44 AM Friday, Katie Jankowski wrote:
>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
>
>On Wednesday, August 31, 2011 10:01:02 PM UTC+9, Benny Liebold wrote:
>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 â EURO oevideo jumpingâ EURO .
>
>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â EURO  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â EURO (tm)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â EURO (tm)s ability to hyperthread and itâ EURO (tm)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 â EURO oemsconfigâ EURO ; go to services;
>mark â EURO oehide windows servicesâ EURO  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 â EURO oeâ EURO oestretch videoâ EURO  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 â EURO oestop afterâ EURO  to â EURO oenoâ EURO  if you 
>donâ EURO (tm)t need the function (donâ EURO (tm)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Ã 1/4 ringer Weg 11, 09126 Chemnitz, Germany

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/533edcf1.4294320a.31aa.193aSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.