and produced some beautiful (though shakey) video while running and gunning around Tokyo:
The video is on Vimeo, but the guys kindly also made the 1080p source available here. I downloaded the gigantic 1.8GB Torrent from here. That is 1.8GB for six minutes and ten seconds of video. Wow!
Linux Playback
I wanted to see which media players could handle such a large file. Here were my results on my Fedora 7 x86-64 system:
- dual quad core, 1.6Ghz
- 2GB
- NVidia 8800GT dual head system with twin Dell FP1905 monitors
mplayer played the file cleanly if the application window was stretched to a max of about 1400 pixels wide. Any wider, and mplayer would stutter.
xine couldn't play the file as it seems I do not have the correct codec installed. I got the dreaded "file uses an unsupported codec" error:
ffplay played it with slight audio stutters and the following error:
[mpeg4aac @ 0x3947e23ca0]faac: frame decoding failed: Gain control not yet implemented
I will have to investigate this.
Update 2008/11/23
Reviewing Google for this error, most of the suggestions for fixing the problem state that you should have the latest version of faad2/faac. According to the developer at www.audiocoding.com, I do:
faac x86_64 1.26-3.fc9 installed 182 k
faac-devel x86_64 1.26-3.fc9 installed 49 k
faad2 x86_64 1:2.6.1-10.fc9 installed 344 k
faad2-devel x86_64 1:2.6.1-10.fc9 installed 414 k
So, I'm at a loss why these messages are occurring.
end update
I converted Tokyo Reality using mjpeg as the video compression method:
ffmpeg -i Tokyo-Reality-h264-1080p.mp4 -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec mpeg4aac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 tokyo.mp4
On my Dell SC1430, 1.6Ghz with eight cores, the conversion took about the same time as the file was long, about 6 minutes, 10 seconds. The size of the original was 1.8GB; the size of the conversion was 1.6GB. Not much difference there.
Update 2008/11/22
I compared the output of the original to the output of the MJPEG conversion. On the left of the below screengrab is the original from Akihabara. On the right is my conversion. You'll notice that the converted image on the right is slightly more saturated than the one on the left. I'll have to play with the conversion parameters to get the colors a little more like the original.
end update
When I replayed this video, within about four minutes, I exhausted 2GB of RAM and 4GB of swap. Holy crap! The normal Cinelerra editing functions (cutting/pasting) did not exacerbate this memory issue. Only the replay function seemed to suck up all my memory:
The replay was a little choppy at the beginning, but ran at 30fps. However, as RAM filled up, playback performance dropped to 12fps, as RAM was exhausted and swap was being utilized. Once swap was exhausted, the entire box locked up! Scary!!
Update 2008/11/17
I had been planning on upgrading my system to Fedora 9 and the above memory leak was enough for me to say "fuck it" and just do the upgrade. Upgrades are increasingly complex as I've added four RAID drives to my setup. Well, just when you think it is going to be a nightmare, along comes Fedora and actually made the process pretty seemless. Within two hours, I had Fedora 9 installed, all my Cinelerra source dependencies installed, Cinelerra compiled and up and running. Of course, this is from a guy who has been doing this for how many years now? But still..two hours..I hardly believe it myself.
The icing on the cake is that my memory leak is no longer present! The below chart show CPU utilization and memory while the video plays:
So far, the system is much more responsive than the old Fedora 7, 64-bit. I guess I had some old/outdated/corrupted libraries in there. Now playback of Tokyo Reality in Cinelerra is more consistent, albeit at a slower 19fps.
end update
MacBook Pro Playback
I next copied the file to my 2GB, dual core Intel 2.2Ghz MacBook Pro 17". I attached my 42inch display to the second head on the MacBook's video card. The file played in QuickTime. It played without errors when I manually enlarged the Quicktime window to fill the screen; however, QuickTime stuttered when the video was maximized to Full Screen using the 42" monitor as the output display.
Finally, I tried to play the file on my MediaGate to absolutely no avail.
So, it looks like the only reliable players are mplayer on Fedora 7 and QuickTime on my MacBook Pro.
I think I need to upgrade my Fedora 7 system to a newer OS. Hopefully, a more recent OS and supporting encoders/decoders will do a better job of playing these large files back.
The Mule
No comments:
Post a Comment