-
MPEG-2 Editing Myths
Found this article at Broadcast Engineering while researching a good layman’s description of Long GOP to help someone in the basics forum.
MPEG-2 editing mythsThe all too frequent claim that during the capture or import of long GOP MPEG-2, it must be converted to a “better” codec is false. All MPEG-2-based formats can, and generally should, be edited natively. Interframe source files require the least storage space and the least disk bandwidth.
Expanding file size during import in no way can improve or preserve image quality. Moreover, native editing typically enables more streams of video to be edited in real time. NLEs obtain YCrCb frames from uncompressed source files, on-the-fly decompressed intraframe source files, and on-the-fly decoded HDV, XDCAM HD, XDCAM EX and XDCAM HD 422 source files. (As part of a decode, 4:2:0 MPEG-2 video is upsampled to 4:2:2.) Therefore, no matter the source format on disk, exports are always made from 4:2:2 uncompressed video.
When you play back a timeline, you are viewing 4:2:2 uncompressed video that is output directly via HD-SDI or HDMI, or converted to RGB. When effects are rendered in real time, the render engine outputs 4:2:2 uncompressed video. When you manually render effects, the render engine’s uncompressed 4:2:2 output may either be sent directly to a file or compressed. Obviously, compressed files have the advantage of requiring far less space and typically do not require a RAID-based editing system.
For example, with HD MPEG-2 source video, Avid Xpress Pro HD and Media Composer can render effects to compressed DN×HD files. And, beginning with Apple Final Cut Pro 6, one can request that effects applied to MPEG-2 source video be rendered to ProRes 422 files. Moreover, you can request Apple’s Color application to render to ProRes 422 files.
Therefore, clips with applied effects will not be re-encoded to MPEG-2. Likewise, graphics are never encoded to MPEG-2 during editing. The only time MPEG-2 source files will be re-encoded to MPEG-2, or any interframe format, is when you request an export to MPEG-2 or H.264 to create DVD or Blu-ray optical discs.
Comments? I think the theory is alright, but the real-world application is completely unreasonable, unless you have a huge render farm or a lot of time on your hands.
Full article here:
https://broadcastengineering.com/hdtv/editing_longgop_video/index2.html -
2 Replies
-
Great in theory, but in practice I find editing longGop much more processor intensive and therefore much more painful.
I need to run some tests to make sure this isn’t just my setup, but my experience editing longGop XDCAM is that scrubbing through the timeline is like stepping back to 1991, or playing back from a firewire drive. You see a fraction of the frames as you scrub at high speed and it feels sluggish. As opposed to scrubbing through I-frame, which is like a hot knife through butter.
I’ve started throwing disk space at the problem, and now transcode anything that comes in longGop to ProRes.
FCP 6.06, OS 10.5.8, 2x3Ghz Intel Xeon, 5x750Gb striped eSata, Blackmagic Multibridge
Rob Tinworth
http://www.1021.tv -
[Dennis Leppell] “The all too frequent claim that during the capture or import of long GOP MPEG-2, it must be converted to a “better” codec is false.”
Obviously, this is where the basis of this argument stems from. In my opinion, converting to another codec is not for image quality purposes (the damage has already been done, so to speak) it’s for ease of editability, render and export.
The argument that it gets decoded to 4:2:2 is kind of silly too. So does everything that is not 4:2:2. DV, for example, when played out of a baseband video port does too. So what? The damage has been recorded in to the file, and you won’t get that back.
Also, from an application developers point of view, i-frame (intra-frame) codec are much easier to predict and therefore provide more direct access to the file. Meaning if you have a CBR, i-frame codec, you know where frame 1,001,000 is going to be by doing simple math and then allows a simple index for the entire file. With interframe (LongGop) formats, that frame will depend on the frames around it, the index has to constantly be rewritten. Here’s a good way to explain CBR vs VBR. and how it pertains to indexing.
https://mxf4mac.com/images/stories/downloads/principles_of_cbr_and_vbr.pdf
Jeremy
Reply to this Discussion! Login or Sign Up