View Full Version : How to run 444 Mbps file smoothly?


Julian Ott
March 7th, 2014, 05:45 AM
We have this prores 3840 x 1080 file that jitters no matter what system we put it on. It's a video file of extremely consistent movement and projected using two HD projectors running from a matrox unit that splits the file into two 1920 x 1080 files. The projectors are positioned so that they line up seamlessly (almost). Because of the consistent movement and large projection, slight jitters are extremely noticeable at 30 fps.

It needs to be prores 444 because of the detail. It needs to be 30 fps for smoothness; 60 would be better. We have tried lower prores formats and they are unacceptable in terms of quality.

The jittering happens even before it gets to the matrox unit. For example, displaying it on one monitor does not improve jittering in any way. Jittering is not constant, just randomly sometimes after a minute. Because of the slow movement, the jittering can be described as hesitating / slowing down.

If I export it to h264 it jitters more, but lower prores exports *do not* jitter.

On blackmagic, my 2012 MBP gets ~400 MB/s read speeds off its SSDs. It jitters. A 2010 Mac Pro and PC with RAID SSD also jitter. I calculate that the file uses 55 MB/s basing that it's 28 minutes long and 93 GB large. I'm including the MediaInfo Mac log file below which says it uses 444 Mbps (which is roughly 55MB/s). That should rule out hard drives being the bottleneck, right?

Questions:

Any ideas on the bottleneck?
Any ideas what other tests I should run?
Any idea what kind of system we need to run this?
We can use pretty much any machine to run this.
I'd be really excited to hear any interesting ideas because this has been really killing us. If the bottleneck is my intelligence I'd be more than happy to hear that too :)

Thanks!


General / Container Stream #1
Total Video Streams for this File.................1
Total Audio Streams for this File.................1
Video Codecs Used.................................apch
Audio Codecs Used.................................PCM
File Format.......................................MPEG-4
Play Time.........................................28mn 3s
Total File Size...................................87.0 GiB
Total Stream BitRate..............................444 Mbps
Encoding Library..................................Apple QuickTime
Video Stream #1
Codec (Human Name)................................ProRes
Codec (FourCC)....................................apch
Frame Width.......................................3 840 pixels
Frame Height......................................1 080 pixels
Frame Rate........................................30.000 fps
Total Frames......................................50502
Display Aspect Ratio..............................3.556
Color Space.......................................YUV
QF (like Gordian Knot)............................3.555
Video Stream Length...............................28mn 3s 400ms
Video Stream BitRate..............................442 Mbps
Video Stream BitRate Mode.........................VBR
Video Stream Size.................................86.7 GiB (100%)
Video Stream Language.............................English
Date of Original Encoding.........................UTC 2013-07-29 11:20:39
Audio Stream #1
Codec.............................................PCM
Codec (FourCC)....................................sowt
Audio Stream Length...............................28mn 3s 456ms
Audio Stream BitRate..............................1 536 Kbps
Audio Stream BitRate Mode.........................CBR
Number of Audio Channels..........................2
Audio Channel's Positions.........................Front: L R
Sampling Rate.....................................48.0 KHz
Bit Depth.........................................16 bits
Audio Stream Size.................................308 MiB (0%)
Audio Stream Language.............................English
Date of Original Encoding.........................UTC 2013-07-29 11:20:39
Menu / Chapters Stream #1

Andrew Smith
March 9th, 2014, 11:03 AM
Hi Julian,

Firstly, congrats on the detailed post and question. Also, for not blaming the Matrox gear as I have seen a lot of people do. You already have my respect.

Based on what you have said thus far, I think one of the immediate problems will be a comparative lack of CPU resources for what is being expected. This is most evident when playing back the h264 version which requires more CPU resources to decode for playback. There may be a similar issue (to a lesser extent) with playing back the dual-HD ProRes file, and the success of the lower (but unacceptable quality) data rate ProRes file would further indicate this.

Are you able to note CPU usage whilst playing back both h264 and ProRes versions? That would be good to know.

Also, what is the exact model of the Matrox gear that you are using? This might be handy for later.

A possible secondary issue that I can think of is the bandwidth for data that the CPU can handle. Not for the incoming 55MB/sec but the amount of outgoing data from the decoding / decompression function. It's a bit of a long shot, but worth considering. (Ditto for your motherboard infrastructure.)

Lastly, what app are you using to play back your ProRes video file? Software such as Premiere Pro utilises the GPU (graphics card) to handle the image intensive decompression workload, leading to a much smoother playback, scrubbing and editing experience as the comparatively slower CPU method is not being used for this function.

Two further things to suggest:

1. A get-the-job-done possibility for action is to play both of two 1920 x 1080 files (left and right sides of your current finished product) as separate HD streams from two physical computers. Just have to be able to find a suitably accurate mechanism for triggering both to start their playback at the same time.

2. Talk to the support guys at Matrox and ask them for their thoughts. They are reachable by phone and will possibly have gone through similar computing power issues when developing and testing the hardware that you are using. Plus, they're really great value people.

All the best with this, and I look forward to hearing back from you.

Andrew

Julian Ott
March 10th, 2014, 09:36 PM
Andrew thanks so much for your advice.

"the success of the lower (but unacceptable quality) data rate ProRes file would further indicate this."

Agreed.

"Are you able to note CPU usage whilst playing back both h264 and ProRes versions? That would be good to know."

Forgot to include that. I remember mine being around 60% and 50% respectively but will run tests on all the machines later this week.

"Also, what is the exact model of the Matrox gear that you are using? This might be handy for later."

DualHead2Go Digital ME but as I mentioned already it doesn't have to do with the Matrox unit itself. It's out at an installation right now so I can't test with it anyway.

"A possible secondary issue that I can think of is the bandwidth for data that the CPU can handle. Not for the incoming 55MB/sec but the amount of outgoing data from the decoding / decompression function. It's a bit of a long shot, but worth considering. (Ditto for your motherboard infrastructure.)"

Yes, I would like to know more about how to get into this information. Any suggestions on a program that could measure important areas of throughput to get a better understanding of what kind of resources are being heavily taxed within the computer's "workflow" (decoding, graphic processing, etc)? Does such a thing exist?

"Lastly, what app are you using to play back your ProRes video file? Software such as Premiere Pro utilises the GPU (graphics card) to handle the image intensive decompression workload, leading to a much smoother playback, scrubbing and editing experience as the comparatively slower CPU method is not being used for this function."

Quicktime because of the supposed hardware decoding with prores. Just read into it though and it seems to only take advantage of multicore processing which is old news. VLC jitters too, though. This thing basically sits in a museum and runs 8 hours a day for 3 months, so we can use any program. Is there a program that will utilize the GPU as well?

"1. A get-the-job-done possibility for action is to play both of two 1920 x 1080 files (left and right sides of your current finished product) as separate HD streams from two physical computers. Just have to be able to find a suitably accurate mechanism for triggering both to start their playback at the same time."

We are considering this in the future, perhaps with Brightsign units. We have to use the Matrox for the time being. Any good ideas on how to trigger, anyone?

"2. Talk to the support guys at Matrox and ask them for their thoughts."

That is such a good idea and I don't know why I didn't do that. They know better than anyone the limitations of the hardware going into their units.

Thanks so much! This community is so helpful.


julian

Shaun Roemich
March 14th, 2014, 04:47 PM
"2. Talk to the support guys at Matrox and ask them for their thoughts."

That is such a good idea and I don't know why I didn't do that. They know better than anyone the limitations of the hardware going into their units.

Thanks so much! This community is so helpful.


julian

+1 for the Matrox technical support team being INCREDIBLE.

I accidentally overwrote the firmware on my MXO2LE a year out of warranty and they still spent an hour on the phone with me working through it.

Andrew Smith
March 22nd, 2014, 01:21 AM
Hi Julian,

Just wondering how you are progressing with a solution to your above issue.

andrew

Julian Ott
March 25th, 2014, 08:51 PM
Hi guys,

We've been busy on other products but we're purchasing another matrox unit and then I will contact matrox to see if they have any ideas. Thanks for your suggestions, and I'll let you know how it goes.

Julian Ott
March 27th, 2014, 08:12 PM
Matrox seems to think it's the graphics card, without being too specific. It's probably hard for them to guess, especially when this problem doesn't have anything to do with their system specifically.

Is there any kind of program out there to benchmark your system's bottlenecks for video more concretely than activity monitors? We really can't seem to find a solution, and this problem will be cropping up more and more. It seems like there must be a way to find balance between a format, a video card / processor's decoding ability, and output quality.

Andrew Smith
March 28th, 2014, 06:33 AM
This might be the sort of thing you are looking for.

SiSoftware Sandra Lite 2014 SP1c 20.25 Download - TechSpot (http://www.techspot.com/downloads/160-sisoftware-sandra-lite.html)

Andrew

Julian Ott
March 28th, 2014, 07:34 AM
sisoft sandra. i remember that from my PC days :P Thanks Andrew. New version is nice on the PC. Anyone know of something nice like this for the mac? We pretty much just run things off macs even for installs. I will use it to test files in a PC environment though!

Warren Kawamoto
March 30th, 2014, 01:02 PM
Is there a way to play an uncompressed file? mp4 compression chokes your computer's processors at that resolution. The only drawback to playing uncompressed will be huge mounds of terabytes storage.

Julian Ott
July 23rd, 2014, 01:08 AM
Warren,

Just found this thread again and saw your post. Thanks for the reply.

It's totally fine to play uncompressed from a data / visual perspective. Proress 444 or HQ is much better in fact. The problem is that less compressed doesn't actually play better than the more compressed data. I imagine it's disk access speeds. We need it to be really sharp.

Totally uncompressed....now I can't remember if we tried that. Wouldn't that need like RAID SSD at that resolution, lol?

Roger Keay
July 24th, 2014, 03:59 PM
Mr.Ott, you mentioned that you are using two projectors and a Matrox unit to split the 3840 wide image in two. As an alternative, have you considered splitting the image into separate 1920x1080 streams using editing software and treating the left and right segments as if they were left and right in a 3D stereo pair? The stereo pair treatment would keep them in sync. If suitable stereo playback software is available you could use two graphics cards which should get round the GPU processing limitations.

Just an idea. Maybe it will help.

Julian Ott
July 24th, 2014, 08:10 PM
Interesting idea Roger.

Anyone else tried this? And can you assign a GPU to a single stream in any operating system? I don't have experience with that. It would definitely run smoothly that way.

Just did a google of this and found some open source solutions. Will check out this weekend. Thanks!