Sony EX .mp4 vs Mainconcept .m2t

GatorBait wrote on 1/4/2011, 11:30 PM

Hi everyone...I hope everyone had a great New Year's!

Ive been archiving video shot on tape from my JVC HD200 (720p HDV1). Decided its time to burn the files on data Blu-rays. Originally Ive been trimming clips on the timeline and then smart rendering then out with MainConcept codec. I trim the clips so I can save space obviously. I've always noticed that it renders the first frame of each event in the timeline. So one day I was curious about that and reimported the rendered clip back into the timeline and saw that it noticeably compresses that first frame or two. I put them on separate track on top of each matched by frame and would mute one to expose the other. This started to bother me because I have smart rendered several projects out and now I realize that the first frame of each cut degraded.

So I started to experiemeny (love doing that...lol). So I thought Id try XDCAM EX. I changed the default bit rate in the settings to 18.3 CBR...which is the same bitrate my camera records at. It actually smart rendered and I wasn't surprised at all about it. Even the first frame was not recompressed...at least when I import that rendered EX file into the timeline there is practically no visual difference in the image quality in that first frame. However, it is now in and .mp4 wrapper..but still the same HDV codec. I am considering on smart rendering all the clips using the XDCAM EX settings. So basically my question is...is it recommended to do so and what how compatible will the .mp4 wrapper be in that form. Can it be wrapped back to .m2t somehow? Rendering the file back out with Mainconcept will yield the same original results...first frame compressed.

BTW...I rendered out a non-HDV clip using MainConcept mpeg2 and Sony XDCAM EX and the EX render blows the MC render away. The EX file looks almost exactly the same as the original, but the MC render visually looks like it eliminated a color shade. This is why I am thinking about sticking with XDCAM EX from now on when rendering...but wondering about compatibility or any other problems I might run into like editing or stuff like that. I never tried it before because I thought that setting would render out using an mpeg4 codec and not and mpeg2 considering the wrapper and extention of the file.

-Alan

Back to post

Comments

Laurence wrote on 3/12/2011, 6:28 AM

Coming back to this subject: I have found that XDcam mp4 clips that contain mpeg2 video will only smart-render on the simplest timeline: that is a single track of video with transitions. Add a second track of audio (like a music bed or a voice over) and the video will no longer smart-render. XDcam mxf will smart-render regardless of what is happening with the audio below it. An mxf smart-render takes longer because it is fully processing the audio and only smart-rendering the video. XDcam mp4 looks at both the audio and video and only smartrenders if neither one has changed.

NickHope wrote on 3/12/2011, 6:52 AM

Thanks Laurence. That's saved me an annoying re-conversion somewhere down the line. So it looks like mxf instead of mp4 (or m2t) for me as a future archive format for HDV.

Laurence wrote on 3/12/2011, 8:12 AM

Well XDcam mp4 will smart-render into mxf so it wouldn't be that bad a problem. I can see XDcam mp4 being a good format to batch convert m2t into because it would be almost as fast as a file copy. I usually normalize and clean up dialog parts and smart-render into larger sections with markers though, so XDcam mp4 won't be that useful to me. I smart-render into these larger sections because Vegas handles a smaller number of larger long GOP files a heck of a lot better than it does hundreds of small long GOP clips. Way better in fact. With intra-frame codecs like Cineform or SD DV it doesn't matter, but with long GOP the smaller number of longer files are way more efficient. I could do the longer chunks with XDcam mp4 if I wasn't cleaning up and normalizing the audio at the same time.

NickHope wrote on 10/10/2011, 11:30 PM

Laurence, I am not sure whether your problem is with smart rendering to or from XDCAM EX mp4, but I am finding no such problem here. I can smart render both to and from it when I add extra audio events below the original event. VP 10.0e.

Laurence wrote on 10/11/2011, 9:38 AM

My problem is smart-rendering to XDCam mp4 when the audio is altered in any way. Smart-rendering from XDCam mp4 works fine. Lossy renders always work. It is the smart-rendering I was trying to preserve.

One thing that does work and that I do regularly now is to render video with no useable audio to XDCam mp4 with the audio tab unchecked. Mxf has to include audio but mp4 does not. I am using XDCam mp4 regularly for MOS b-roll.

I find that even on AVCHD source material I am using XDCam .mxf and .mp4 formats because they are so much more compact than Cineform (and yet I can see no noticeable difference). Maybe if I was doing more color correction it would matter more. It's amazing really. I am doing 1080p HD with about the file size and CPU overhead of a SD DV codec project!

Laurence wrote on 10/11/2011, 11:35 AM

OK, I just tried rendering to XDCam .mp4 again with several layers of audio. It worked fine! I'll have to figure out why it didn't before. Maybe it has to do with deleting the audio track associated with the video track (which I did when I tested it before).

Anyway, a couple of things I notice right off the bat:

1/ An XDCam .mp4 file works perfectly with Handbrake. With .mxf you have to choose either the right or left audo track. It won't let you input both sides as a stereo pair. XDcam mp4 works great with Handbrake.

2/ With XDCam .mxf, any transitions or other parts that were rerendered before rerender yet again. With XDCam .mp4 these parts that were rerendered before now smart-render like they are supposed to.

3/ Smart-renders are WAY faster with XDCam .mp4. Mxf smart-renders are slightly faster during the smart-rendered parts than a regular render, but XDCam .mp4 smart-renders fly through smart-rendered sections at file copy speeds!

Laurence wrote on 10/11/2011, 11:48 AM

OK, two more advantages of XDCam .mp4 over .mxf:

4. XDCam .mp4 files are slightly smaller than .mxf
5. XDCam .mp4 files uses slightly less CPU than .mxf.

I believe I have found me a new working format! Thanks Nick for revisiting this. :-)

FrigidNDEditing wrote on 10/11/2011, 12:24 PM

You guys do know that the .mp4 is just a wrapper, and it's really XDCam MPEG2 footage being housed in there right ( as far as I understand it ). So you're not really using the Mpeg4 compression that you might think you're using. Just a heads up as (unless I'm mistaken but I really don't think I am).

Dave

NickHope wrote on 10/11/2011, 12:34 PM

Yeah Dave we know. That's the whole point... to smart render from HDV footage in a better way than the MainConcept MPEG-2 encoder. But thanks for repeating it in case others are confused.

Laurence wrote on 10/11/2011, 1:00 PM

> You guys do know that the .mp4 is just a wrapper, and it's really XDCam MPEG2 footage being housed in there right ( as far as I understand it ). So you're not really using the Mpeg4 compression that you might think you're using. Just a heads up as (unless I'm mistaken but I really don't think I am).

That is exactly the mistake I made until I read Alan's (GatorBait) post, and exactly why I never tried smart-rendering to it until that time.

Yes, it is the same mpeg2 encoded video that exists in the .m2t container that HDV shoots. The audio is uncompressed however, and this means that you aren't degrading the audio with each successive smart-render. Also, the bits that aren't smart-rendered look noticeably better. I don't know why and it doesn't really make sense, but it is easy to see the difference.

NickHope wrote on 10/11/2011, 1:56 PM

Also, the bits that aren't smart-rendered look noticeably better. I don't know why and it doesn't really make sense, but it is easy to see the difference.

My wild guess is that it's actually a different MPEG-2 codec under the hood. Sony's own perhaps? But then why wouldn't they start using it for regular MPEG-2 as well, instead of MC?

Laurence wrote on 10/11/2011, 6:19 PM

You see it too right?

PeterDuke wrote on 10/11/2011, 9:07 PM

With regard to confusion about the .MP4 name and the connection to MPEG-4, Wikipedia says:

"MPEG-4 Part 14 or MP4 (formally ISO/IEC 14496-14:2003) is a multimedia container format standard specified as a part of MPEG-4. It is most commonly used to store digital video and digital audio streams, especially those defined by MPEG, but can also be used to store other data such as subtitles and still images. Like most modern container formats, MPEG-4 Part 14 allows streaming over the Internet. A separate hint track is used to include streaming information in the file. The only official filename extension for MPEG-4 Part 14 files is .mp4."

http://en.wikipedia.org/wiki/MPEG-4_Part_14

The MPEG-4 standard covers audio encoding, video encoding and container definitions, in different parts. AVC (H.264) is MPEG-4 part 10.

NickHope wrote on 10/11/2011, 11:28 PM

You see it too right?

Yes, re-rendered parts are better quality with MXF or or XDCAM-EX mp4 than they are with MainConcept MPEG-2.

So, if SCS are reading, any chance of engineering the speed and quality of the MPEG-2-in-XDCAM-EX render into regular MPEG-2 rendering, including HDV and DVDA-compliant Blu-ray renders?

Laurence wrote on 10/12/2011, 7:11 AM

And don't forget that any parts that parts that aren't smart-rendered will get rerendered again on each successive smartrender in .mxf but not in XDCam .mp4. This alone is a very good reason to choose XDCam .mp4 over .mxf.