Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Slow performance - Red MXF

Christoffer Glans

Well-known member
Joined
Jun 11, 2007
Messages
4,993
Reaction score
36
Points
48
Age
42
Location
Stockholm, Sweden
I did my first shoot using MXFs as editorial proxies in-camera (SQ quality) and when I'm editing the footage on my macbook pro, the fans start to spin up and it gets hot. The footage also plays very sluggish, scrolling sometimes just freeze before working. I've been trying to tell both Red and Avid about using the same kind of codec system as before for DNxHD, i.e DNxHD 36 instead of DNxHD SQ but I've yet to get any feedback on this. DNxHD SQ seem to perform way under the performance of regular DNxHD 36 which should work without my Macbook breaking a sweat. (I have the latest Avid)
 
What resolution are you recording DNxHR SQ at? DNxHR LB at UHD resolution is exactly 4x the data rate of DNxHD 36. Anything larger than UHD and at SQ quality is a much larger data rate than DNxHD 36 and can explain the sluggishness. To compare, do a test with the same R3D file linked and transcoded to DNxHR SQ at it's original source size and see if you have the same experience.

Michael
 
What resolution are you recording DNxHR SQ at? DNxHR LB at UHD resolution is exactly 4x the data rate of DNxHD 36. Anything larger than UHD and at SQ quality is a much larger data rate than DNxHD 36 and can explain the sluggishness. To compare, do a test with the same R3D file linked and transcoded to DNxHR SQ at it's original source size and see if you have the same experience.

Michael

These are just proxies, regular proxies on par with 1080p DNxHD 36. DNxHD is not DNxHR. The problem is that the renaming of the different datarates for DNxHD seem to have come with a general change to their behavior. DNxHD SQ is NOT DNxHD 120 and DNxHD LB is NOT DNxHD36. The quality of DNxHD 36 is enough for editorial and client approval, but LB is so extremely low in quality with blocky artifacts all over while SQ seems to be a bit too high for proxy-work. I wished they stayed with the datarate naming because something isn't right in this new system.
 
I upgraded the software (minor update) and codecs in order to try and speed up the sluggish behavior I had with editing the SQ files from my Weapon, but now they won't work at all. Avid wants to quarantine them and they won't work.
What is going on here? Red needs to spank Avid and get their lazy techs fixing this. The new naming system is screwing up everything with Avid.
 
I blogged about the naming convention being confusing, but that was done at Avid's request.
http://24p.com/wordpress/?p=331

Try AMA linking to the OPAtom DNx material and consolidate rather than moving them directly to the Avid MediaFiles folder. The updated RED AMA plug-in supports both R3D and MXF. As far as development goes:

Redcine X Pro is developed by RED using Avid's AMT for MXF/DNxHD/HR codecs
Red AMA plug-in is developed by Avid using RED's SDK
In Camera recording is developed by RED using... ???

I have some sample files I have tested with via the RED AMA to MXF and it worked other than spanned files had 1 frame offset at the split. Red is aware of this.

Michael
 
Back
Top