Sony X70 4K - Lowest bit rate in the industry!

[David Heath]

Originally Posted by Paul Anderegg

And we al know XAVC of the same flavor is always fully compatible with the various NLE's. :-)

Paul

But it may be for the reasons I say, it will rely on any NLE having the level 5.2 H264 ability for decoding amongst other things. And may need a given standard of hardware as well.

If a given NLE version states it's "XAVC compliant", then given adequate hardware that should be that. But no one should expect XAVC to work with earlier versions of the software.

Unfortunately it's a fact of life of going for " the latest and best" whether it be 4K, a new codec or whatever. The price you have to pay is a period of waiting for other factors to catch up.

And it reinforces what I said above about why a manufacturer can't tweak the spec of any existing codec like AVC-Intra or XAVC once finalised. It may be bad enough if you are running a system based on AVC-Intra to find it won't run XAVC - but just imagine the confusion if it would run AVC-Intra files from some cameras but not other (newer) ones.

[Paul Anderegg]

I meant Sony just "modified" the XAVC-L in the X70 to make it work......obviously, people are messing with the internals of the levels, and ARE in fact messing up compatibility.

Paul

[Cliff Totten]

Originally Posted by David Heath

I don't disagree with what you're saying in general, but aren't you forgetting about the concept of levels, which I believe go a long way to counter exactly the problem you describe?

So decoders are split into various "levels" - a given level of decoder will decode all levels below it, but not above. See https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

By standardising their H264 implementation relatively late, Sony (with XAVC) have been able to take advantage of the latest tricks, those corresponding to (I believe) level 5.2.

So in your above example, it's quite true if you tried to decode XAVC with a version of a decoder which only supported level up to 4.2 it wouldn't end well. Which is why if you want to use XAVC any NLE etc has to be "XAVC compliant". This is one reason why even if it will deal fine with another H264 variant, it may not handle XAVC or any other level 5.2 encoded H264.

If you like, a level 5.2 capable decoder is a version of your dictionary reprinted with the definitions of "bruniwafllop", "gronoklipop" and "grunubvicaton"! ( :-) )

It's worth then thinking about other forms of encoding based on H264. Can manufacturers not just incorporate the latest "tricks" in their latest products? The problem is that you could then end up with a state of affairs where consumers wouldn't know if their existing equipment could or could not work with a given product.

To take AVC-Intra as example, then I believe it's spec DEFINES it as being based on H264 level 4. If Panasonic was to now bring out a new camera and take advantage of level 5 "tricks" then it would be a recipe for confusion if it was still to be described as AVC-Intra. A broadcaster with a large AVC-Intra based post infra structure would suddenly find that any files produced by the newer camera wouldn't be usable by their existing system. Imagine they employing a freelancer with a newer camera - "is your camera capable of AVC-Intra recording?" - "yes" - ........ "your files appear to be faulty......."

And the same would apply to XAVC if some even newer techniques were to be developed - a "level 6" if you like. If such as Sony wanted to use them, the result wouldn't be XAVC. That's the whole point - "AVC-Intra" or "XAVC" etc defines which level is used, as well as a host of other factors.

No, not true. Try decoding XAVC with an original H264 decoder from 2003 and you won't get very far! It has to have the capability of "knowing about" H264 level 5.2, which software from 2003 wouldn't have. (Though the converse would be true - a new version of a decoder should be able to play back a file created with a 2003 encoder.) And all this is before we even start to think about different H264 profiles........

Now just how much difference level 5.2 abilities etc do make I can't quantify. Would it, for example, at least make up for a drop from 100Mbs to 60Mbs, if the 100Mbs material was level 4 compliant? I can't give a direct answer to that, but as regards your comment that "Yet, it's a statistical fast that no other company, Panasonic, Canon or JVC use 60Mbp/s for 4k recording.", then whilst it may be factually accurate, it doesn't really tell the whole story. If those companies are using encoders which comply to a lower level, any 60:100 comparison tells you nothing in isolation. (Other than that 60Mbs will be far more tolerant of media write speed, and give smaller file sizes. :-) )

I think you might be accidentally interchanging "profiles" with "levels".

"Levels" determine the restrictions for frame rate, frame size, chroma sub-sampling, and overall bit rate and stuff like that.

"Profiles" determine the amount of MPEG "tools" (calculation types) that the video is allowed to have from the established MPEG tool list. This is where the actual analysis and compression is done.

Many of the changes that have happened over recent years involve raising the "level " constraints. Each level is less and less "restricted", the higher it goes. A level 5.1 video does NOT mean that it's more "complex" than a level 5.0 video. It just means that it's less "constrained" and is allowed to exist in larger parameters if necessary. Larger frame sizes and faster frame rates means more calculations per second and certainly requires more CPU horsepower and data throughput.

Theoretically, MPEG could release a new level "6.0". This level could allow for 8k frame sizes with a new frame rate at 240p. with 2 gigabit maximum bit rate. The core tools in the chosen the MPEG "profile" are then simply scaled proportionally higher into the new "level" parameters. (Same calculations, just more of them per second) The h.264 CODEC tool sets aren't exactly "changing" it's just being scaled to a larger, higher level. Yes, "6.0" will prolly never happen, (because HEVC is taking it over from here on in). I'm just saying for the sake of discussion.

Changing "levels" is less difficult than changing "profiles". The heart of the CODEC is really in the "profiles" because that is where the meat and potatoes of the mathematics live. The "levels" are mostly just "scaling" the mathematics that is being done to fit into in the proper "level" restrictions.

Think of "levels" increases as a mathematical "restriction" or limit that has been raised. It allows the "profile" math to function inside larger parameters.

Again, the majority of the compression tool sets (all those crazy mathematics that do the magic...or "profiles") was done 10+ years ago. Throughout all the years, the "levels" have been raised higher and higher to allow those "profiles" and tools to exist and operate in bigger spaces. (higher levels) The changes in the past 10 years have mostly been minor. Things like frame packing 3D and multiview and lot's of size and bit rate increases.

Interesting enough,..h.264 is being replaced with h.265 (HEVC). H.265 is built directly on top of h.264. It contains many of h.264's existing tools and math but expands them much further and adds in new tools and even higher new levels limitations. MPEG could never have called this h.264 - Profile @"Super-Ultra-High" and Level 6.0. Why? Because it "breaks" the original h.264 tool and profile set. It not only exceeds 5.2 level limitations (no big deal) but it also "alters" the original CODEC profile math. Once you do that, you have just created a new codec.

Sorry if I stated the exact same thing in 3 different ways. I tend to be redundant sometimes. ;-)

All of this is a wonderful discussion but it doesn't change the fact that the Sony PXW-X70 "XDCAM" 4k/UHD camcorder sit's at the bottom of the industry list (along side the GoPro 4) in terms of bit rate. ;-)

60Mbp/s is just WAY too low. Sony, you are better than this. Show some respect for yourself and please fix this.....

[Cliff Totten]

Originally Posted by Paul Anderegg

I meant Sony just "modified" the XAVC-L in the X70 to make it work......obviously, people are messing with the internals of the levels, and ARE in fact messing up compatibility.

Paul

Interesting about the X70. If you inspect the original X70 firmware video files that it created...the METADATA was literally missing!!! It was "blank" and completely empty! No media flags at all.

Some NLE's require and read that metadata before you can decode it.Sony Vegas is one. If you completely strip the metadata from a video file, it cant play it.

Sony fixed this in the last X70 camera firmware. Now the files have the proper metadata included...total screw up on Sony's part. And, the fact that it too Sony 6 months to fix it?...wow, that is sad.

Remember, unpacking the file wrapper is an important part of playback. Unpacking .mp4 and playing the video is different than unpacking it in .mxf. (even though the h.264 codec inside is completely the same)

So yeah,..no h.264 codec problem there. It was totally an .MXF container screw up.

CT

[Christopher Young]

Cliff

Sorry to correct you on this. You are not far off but I knew what the issue was back in early April but because of confidentiality requests from Sony I couldn't at the time mention what the problem was. I am frequently in a feedback loop with SCS on the software side. This stems from years back having been involved on their Beta test team. Now that the issue of X70 footage being accepted by most NLEs is resolved I feel I can quote verbatim information from a heads up I received in early April.

-------------------------

"Update: We found out that the camera team was aware of this and that it is a problem with the SMDK (development kit). They are building a new release that among other things will: "Remove assertion failure when parsing invalid descriptive metadata."

Which is what we were experiencing – invalid metadata from the older SMDK. Once we get that it will have to be implemented and then go through QA again to make sure there are no regressions. So, not a quick turn-around but hopefully this update will fix the problem.

-------------------------

So the metadata wasn't 'blank' its just an unfortunate fact that in the case of the X70 its development was done with an older version of the SMDK and some of the metadata involved with that meant that the later software developments would see this data as invalid. This causing the importation of the X70 files to be aborted.

I'll also add that David is very much on track with his comments about the later implementation of levels such as 5.2. and the compliance issues surrounding the use of these levels across various platforms and software. In consumer equipment where manufactures don't have to worry too much about cross platform, equipment and software compatibility manufactures have a freedom to introduce changes fairly quickly. Changes that cannot happen as quickly when SMPTE ratified standards such as AVC-Intra and XAVC are involved. All changes to ratified SMPTE standards have to be tested, accepted and ratified again by SMPTE before they can be brought to the broadcast market. Well that's generally the case if the manufacture wants their equipment to be accepted as 'meeting' the standard.

As David alluded to this ensures that there is full compatibility across all equipment and software platforms. This of course all takes time and is one of the reasons that changes and development in cameras such as the X70, the baby of the broadcast family, will lag behind their cousins that run in that juggernaut that is the retail consumer camera market which is driven by very competitive 'one jump ahead of the competition' marketing.

Chris Young
CYV Productions
Sydney

[Barry J. Weckesser]

Originally Posted by Cliff Totten

lol,..yes, I stand corrected! ;-)

So the professional market Sony "XDCAM" PXW-X70 sit's at the bottom of the 4k camera industry bit rate list along side it's 60Mbp/s buddy,...the GoPro Hero 4.

Still,...very embarrassing, indeed!

Cliff - I just came across this while searching for a better (less complicated) upgrade installation pathway for the 4K X70 upgrade. This is from the UK Sony website describing various software upgrades for Sony cameras. Please note the footnote down at the bottom.

PXW-X70 Firmware V2.0
Upgrade includes chargeable element and will be available June 2015

New Features & Improvements:

Support for 4K (QFHD) Recording (optional)
This 4K recording update provides support for QFHD shooting at 30p/25p/24p, allowing the X70 to capture scenes with stunning quality and at high resolution*. Furthermore, for projects finalized in HD, 4K recording greatly expands the creative possibilities by enabling digital panning, camera-shake correction and other post-production effects. NOTE: 4K recording requires purchase of the 4K Upgrade License (CBKZ-X70FX).

Format

Resolution

Wrap

Quality

Frame Rate

Bit Rate

XAVC-L

3840x 2160

MXF

4:2:08bit

29.97p

60Mbps

23.98p

60Mbps25p

60Mbps

*We are looking to support a higher bit-rate recording mode than 60 Mbps for 3840x2160 XAVC-L in the future.



So there is hope - if the AX100 already has 100Mbps then it should be 100 on the X70 - maybe even 150 unless there are mechanical limitations like overheating etc.

Pardon my ignorance but does the flavor of XAVC used in the X70 allow for 10 bit and 4:2:2 for 4K ?

[Cliff Totten]

Nope, UHD/4K on the X70 is only 4:2:0. 8 bit. (supposedly the HDMI is 4:2:2, 8 bit though)

Yes, I have known about their "possible, maybe, might, could someday have a chance of higher bitrate" statement. It's not very reassuring and is no way any actual commitment on Sony's part.

If they do manage to get a higher bitrate, I'd be shocked if they did anything other than 100Mbp/s. (Even though Sony's direct JVC competitor does 150Mbp/s)

It's just sad to see a professional market "XDCAM" CODEC getting passed by cheap "HandyCams" and "Action Cam" CODECs

I'd love to see Sony fix this so we can all forget about this screw up and try to pretend that it never happened and never speak of it again.

It's literally a disgrace today.

[Paul Anderegg]

But you forget it is wrapped in "professional" MXF wrapper. The consumer models are wrapped in civilian non professional mp4 wrappers. How does that saying go......you can polish a turd?

Paul

[Cliff Totten]

I'll take the .mp4 wrapper over .mxf any day. .Mp4 is practically universal. Everything can play it. .Mxf?..a complety different story.

I'm not even sure why .mxf is considered the more desirable container. .mp4 is used professionly on other cameras like JVC and even on SxS cards with XDCAM.

[Piotr Wozniacki]

Originally Posted by Cliff Totten

60Mbp/s is just WAY too low. Sony, you are better than this. Show some respect for yourself and please fix this.....

While I totally agree with the above statement (and not just basing on the "more is better" rule) - I wonder about several things. We all remember the time when nanoFlash unleashed very high bitrates to the average Joe cameraman, making it possible to record as high as 180 Mbps (L-GOP) or even 280 Mbps (I-frame) for the first time, using practically any camera with SDI/HDMI output. What happened then was a big disappointment in the actual quality of that high data rate material - I remember endless discussions on how the 180 Mbps version of the (then a top quality) EX1 became even more noisy than its internally compressed and recorded, 35 Mbps, version... The bottom line being that - with too much noise to start with - a more compression recording acted as sort of a filter, apparently making the image a tad softer but at the same time, more than a tad noise-free! At least this has been my conclusion of in-depth testing the high bitrate nanoFlash files...

So, a question now comes to my mind: did any of you - AX100 and X70 owners - compare the AX100, 100 Mbps stuff with the 60 Mbps X70 material with the above in mind? With a mediocre camera systems like those two, a very fine line exists somewhere that separates the low bitrate, compression artefact prone and difficult to grade stuff - from that with higher bitrate, less compression artefact, easier to grade but perhaps more noisy in the first place... I'm just asking, as I never had the opportunity to watch any of them like it should be watched - large display with full UHD support.

Doesn't the 60 Mbps stuff show less noise than its 100 Mbps version? With just a little penalty of compression artefacts that many don't even see at all?!!

[Christopher Young]

One has to compare apples with apples. I don't know the details about the 4K implementation on the X70 as yet but comparing the technical difference between the MP4 50-mbit HD of the JVC GY-LS300 and the MXF 50-mbit HD off the X70 shows a world of difference just between those two examples not withstanding that one is 8-bit and the other 10-bit.

The JVC:

Video

Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
Overall bit rate mode : Variable
Overall bit rate : 49.8 Mbps
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.2
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : M=3, N=24
Codec ID : avc1
Codec ID/Info : Advanced Video Coding

The Sony:

Video

Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
Overall bit rate mode : Variable
Overall bit rate : 54.2 Mbps
Writing application : Sony Mem 2.00
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.2
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=3, N=12
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201316001

On the JVC you will notice two major and I mean in the terms of H.264 encoding major differences.
Firstly the JVC does not appear to be employing Context-Based Adaptive Binary Arithmetic Coding, CABAC in other words, the Sony is. The JVC Long GOP is encoding an 'I' frame at every 24 (N=24) frames whereas the Sony is encoding an 'I' frame every 12 (N=12) frames which is twice as efficient in terms of prediction accuracy between 'I' frames.

A brief overview of CABAC efficiency over the VLC (Variable Length Code) that the JVC seems to be employing:

CABAC entropy coding method is part of the Main Profile of H.264/AVC and has found its way into video streaming, broadcast and storage applications within this profile.

Results have shown the superior performance of CABAC in comparison to the baseline entropy coding method of VLC/CAVLC. For typical test sequences in broadcast applications. Averaged bit-rate savings of 9% to 14% corresponding to a range of acceptable video quality of about 30–38 dB were obtained.

For the real background on CABAC go Fraunhofer the inventors of the scheme:

CABAC

Also bear in mind that the X70 is part of the Sony XDCam lineup and therefore uses the broadcast Material Exchange Format for its wrapper. Sony's AX100 uses the much simpler .MP4 wrapper but that no longer cuts it today in the XAVC broadcast world. XAVC-S in the consumer market is wrapped as .MP4.

In other words we all have to be careful not to put a too simplistic analysis on codec bit rates vis-a-vis one another when there are many other serious considerations that go into configuring an efficient and bit rate economical codec and its wrapper. it will be interesting to see what Sony have done with its UHD version for the X70. For me the X70 25/30p UHD holds very little interest. If I was to go that way it it would have to be a 50p version for me to be of any real benefit.

A full breakdown of the JVC and Sony 50-mbit codecs are attached in TXT form.

Chris Young
CYV Productions
Sydney

[Brian Murphy]

Many thanks Christopher for your post. I have taken the liberty of printing it out and intend to win a few beers with it someday soon.
Cheers
Brian

[Cliff Totten]

Originally Posted by Christopher Young

One has to compare apples with apples. I don't know the details about the 4K implementation on the X70 as yet but comparing the technical difference between the MP4 50-mbit HD of the JVC GY-LS300 and the MXF 50-mbit HD off the X70 shows a world of difference just between those two examples not withstanding that one is 8-bit and the other 10-bit.

The JVC:

Video

Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
Overall bit rate mode : Variable
Overall bit rate : 49.8 Mbps
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.2
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Format settings, GOP : M=3, N=24
Codec ID : avc1
Codec ID/Info : Advanced Video Coding

The Sony:

Video

Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
Overall bit rate mode : Variable
Overall bit rate : 54.2 Mbps
Writing application : Sony Mem 2.00
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L4.2
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=3, N=12
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201316001

On the JVC you will notice two major and I mean in the terms of H.264 encoding major differences.
Firstly the JVC does not appear to be employing Context-Based Adaptive Binary Arithmetic Coding, CABAC in other words, the Sony is. The JVC Long GOP is encoding an 'I' frame at every 24 (N=24) frames whereas the Sony is encoding an 'I' frame every 12 (N=12) frames which is twice as efficient in terms of prediction accuracy between 'I' frames.

A brief overview of CABAC efficiency over the VLC (Variable Length Code) that the JVC seems to be employing:

CABAC entropy coding method is part of the Main Profile of H.264/AVC and has found its way into video streaming, broadcast and storage applications within this profile.

Results have shown the superior performance of CABAC in comparison to the baseline entropy coding method of VLC/CAVLC. For typical test sequences in broadcast applications. Averaged bit-rate savings of 9% to 14% corresponding to a range of acceptable video quality of about 30–38 dB were obtained.

For the real background on CABAC go Fraunhofer the inventors of the scheme:

CABAC

Also bear in mind that the X70 is part of the Sony XDCam lineup and therefore uses the broadcast Material Exchange Format for its wrapper. Sony's AX100 uses the much simpler .MP4 wrapper but that no longer cuts it today in the XAVC broadcast world. XAVC-S in the consumer market is wrapped as .MP4.

In other words we all have to be careful not to put a too simplistic analysis on codec bit rates vis-a-vis one another when there are many other serious considerations that go into configuring an efficient and bit rate economical codec and its wrapper. it will be interesting to see what Sony have done with its UHD version for the X70. For me the X70 25/30p UHD holds very little interest. If I was to go that way it it would have to be a 50p version for me to be of any real benefit.

A full breakdown of the JVC and Sony 50-mbit codecs are attached in TXT form.

Chris Young
CYV Productions
Sydney

It was common for manufacturers to use CALVC entropy scheme when h.264 was considered "difficult" to work with in the early years of the CODEC. CALVC required less CPU horsepower to use than CABAC did. However, today, I'm not sure why CALVC is still being used. Modern processors have caught up to CABAC and it's not longer a big issue to work with any more.

Totally spit-balling here but I'm wondering if CABAC requires and more expensive MPEG LA licensing fee to employ it? Maybe not. I have no idea why JVC is not using it. It's always been available to all manufacturers. You just needed the extra CPU power to work with it.

Sony has been using CABAC since the old AVCHD days of h.264....very strange on JVC's part.

As far as .mp4 vs .mxf. I still fail to see why the .mxf container is more "pro" than .mp4. Any company can pack the exact same CODEC specs and achieve the EXACT same image quality in either container. The image quality lies in the CODEC used. The container or wrapper has nothing to do with image quality at all.

.Mp4 is a pretty universal standard with extremely wide support. .MXF?...well yeah, it holds certain metadata in certain places but that is no benefit to me. In my opinion, .mp4 is just as "pro" as .mxf...so I don't know why Sony likes .MXF for XDCAM and .mp4 for Handycams and Alphas.

I don't know, it seems to be Sony marketing illusion?

[Christopher Young]

Cliff no not quite.

"I don't know, it seems to be Sony marketing illusion?"

I think this misses the point about MXF. It goes way deeper than that. The prime reasons Sony and Panasonic use the MXF container is that:

"The Material eXchange Format (MXF) is a container format for professional digital video and audio media defined by a set of SMPTE standards.

The MXF is a "container" or "wrapper" format which supports a number of different streams of coded "essence", encoded in any of a variety of video and audio compression formats, together with a metadata wrapper which describes the material contained within the MXF file.

MXF has been designed to address a number of problems with non-professional formats. MXF has full time code and metadata support that is not supported in the generic MP4 container. MXF is intended as a platform-agnostic stable standard for future professional video and audio applications.

MXF was developed to carry a subset of the Advanced Authoring Format (AAF) data model, under a policy known as the Zero Divergence Directive (ZDD). This theoretically enables MXF/AAF workflows between non-linear editing (NLE) systems using AAF and cameras, servers, and other devices using MXF."

If you have ever had to export AAF (Advanced Authoring Format) files from an edit session for further work in Pro Tools you would then appreciate the ease of doing this when working with MXF files.

MXF was developed for the professional broadcast world. The reason why the X70 records MXF files is this little camera was dropped into the broadcast XDCam HD lineup. I am the first to agree that for users of this camera who aren't using the camera in a broadcast environment and who's footage isn't being used in a broadcast workflow then MXF wrapped files are totally unnecessary. MP4 is the way to go and that is exactly what you will find on the Sony AX100, MP4. On the other hand if you buy into a SMPTE ratified standard such as MXF you have to expect all that goes with that even if it's of little use to any particular user outside the broadcast industry.

As for the 4K upgrade on this camera it doesn't meet any broadcast UHD Tier 1 or Tier 2 camera requirement and therefore requires no ratification. Just look at its UHD '4K' as an an added bonus if you wish to make use of it. The primary purpose of this camera was to have a broadcast compliant MXF HD and I stress HD camera that was cheap, used cheap media, was easy to use and that could be put into the hands of video-journos, news self shooters etc of which there are more of these days.

If you are interested in the usefulness of MXF in the broadcast world it's pretty well covered in the attached PDFs. I found these docs fairly informative as we do sport and documentary work for broadcast. MXF is all we use for broadcast acquisition plus all our imported archive material for docs is converted to MXF on the fly via Blackmagic cards using Sony Vegas as Vegas can do real-time conversions to MXF. For our corporate work AVCHD with its basic .MTS wrapper is more than sufficient.

Chris Young
CYV Productions
Sydney

[Cliff Totten]

Yup. .MXF does have allot of metadata advantages over .MP4, no doubt. And, if you have a specific work flow built around .mxf, than yeah, you are in heaven with it. (For me as an event and corporate shooter, I'm just as fine with .mp4)

Ironically, the X70's original firmware screwed up it's .mxf implementation. I was shocked when I tried to pull a "MediaInfo" metadata list and saw that my .mxf files almost no data displayed at all. Sony did fix this in it's last X70 update. I'm still shocked as to how that one slipped through the Sony cracks. (and took sooooooo long to fix)

I think most of us know that the wrapper has no impact on the visual quality of the CODEC used. However, I still have people coming up to me and saying, "I think .MXF looks better than .MP4" I still have to shake my head and tell people "It's just a container, it's NOT the actual video CODEC"

Christopher, maybe you can shed some light on this about .MXF:

I don't know this as a fact but I have read that the container format DOES have an affect on the playback processing overhead. I have read that "unpacking" the CODEC form the file is not the same process across the different container formats. In other words, reading h.264 or MPEG2 from an .MOV, or MP4 or MTS or M2TS or any other of the dozen containers results in different amounts of CPU playback overhead. I have been told that MTS is the simplest but I know that supports muxing ability so I don't know.

Can anybody out there answer that? I have also read that reading a CODEC inside .MXF is a bit more processor taxing than other container formats.

I have always wondered the truth that question.....

CT