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

Fri Apr 4 07:44:39 UTC 2014

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 “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

-- 
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/235aa47d-f910-47eb-adc2-cba4b8cbbc16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20140404/ff50b6b5/attachment.htm>