[Dave Haynie]

[Allan Boes] “My prblem is that the noise is at the entire clip(it’s an old VHS recording) and it seem like neat video is working pretty great to remove a graet deal of the noise.”

A good deal of VHS noise is random. You will probably find that, if you capture the same video a couple of times, and composite them together evenly, you may see a very nice noise reduction with absolutely no softening of the video. This will also take time, but only N x for the separate captures. I’d try this first with any noisy analog tape capture… use different VHS decks, too, if possible (assuming you have access to more than one good one).

[Allan Boes] “But are there any other plugins that can do the same,but dosent drag my computer to it’s knees 🙂 and do’sent cost to much?”

The noise reduction process is inherently CPU intensive, and Neat does a very nice job. I used it on a wedding I shot last year, the whole thing was in a dark nightclub. For that, I just pre-processed the whole thing, ran Neat on the AVC video, output to Cineform, edited from there… just did without that PC for a few days. Once processed, I had instant access to both processed and unprocessed video from both cameras — made editing much, much faster. And that’s where time is money.

The key is that you pretty much want to process with the noise reduction first, before you do any color grading or other editing, but you have a big bill to pay in CPU up-front if you do that.

As for cost, you kind of get what you pay for. I know there are a half dozen or so VirtualDub plug-ins that do noise reduction. I used one of these, ages ago, and it was certainly better than nothing. You might hunt these up, get VirtualDub (AVISynth and Wax also run VDub filters), and try it out. This can get involved, but if you have more time than money, it does extend your video tool box.

-Dave

[Dave Haynie]

[Mark Petersen] “I currently created a project with both .mod file clips (which are mainconcept mpeg-2’s), and xvid encoded .avi’s (so mpeg-4’s here). I’m editing in multi camera mode, and everything works just fine except that the clip name and number overlaid in the multicam preview window is HUGE for the MOD file “cameras”.”

MOD files are usually some kind of MPEG-1 or MPEG-2 produced by a camcorder. Did you create these? What is the resolution of the MOD files versus the XViD files? That could have something to do with it.

Watch using AVI with any advanced format (anything with interframe compression) as an editing format. While it’s true that DiVX and others embed MPEG-4/ASP or even MPEG-4/AVC within the AVI wrapper, and that’s not much of an issue for players. But most video editors, Vegas included, will trip up on those files. Try it if you like, but I’d convert these to something else before getting too deep into a project.

-Dave

[Dave Haynie]

[John Allen] “Vegas tells me the original file is 1920x1080x12 25 fps interlaced AVC. Incidentally, its about 35 mins long, and I am editing out about 4 mins, ie editing in trimmer, dragging to the bottom of the time line, then rendering.”

I missed that part… whoops!

If you’re shooting in AVC on a typical camcorder, you’ll be encoding probably in Main or High Profile, 1920×1080, averaging 21Mb/s, peaking to 24Mb/s, for 25p or 50i.

When rendering out, you must use Main Concept to re-create the VBR, and even that’s optional. Sony AVC and any HDV format is always constant bitrate. Nothing wrong with that, but it will deliver a larger file for the quality set.

(1) No surprise that plays well.. MPEG-2 has been kind of a “done deal” for about a decade or more. It’s the standard for DVD, for original DVB, and of course, ATSC high def TV here in the USA. An HDV at 1080/50i is going to be 1440×1080, a bit downrezzed from the 1920×1080 of your original video.

(2) The Sony MP4 file’s quality and possibly play-ability will depend on the specific settings, which you won’t see unless you got to the “custom” panel. If you’re using the supplied “Internet 1920×1080-50i” or “25p” preset, you should see about the same quality as that 25Mb/s MPEG-2, but of course higher resolution. Ideally, AVC encodes at about twice the quality per bitrate of MPEG-2. As always, it’s dependent on the encoder.

(3) That’s demonstrating the same problem I found — Sony AVC does something weird in the transport stream. Doesn’t affect everything, but VLC didn’t like it. And as my theory suggest, the TS reading code in VLC is likely to be directly related to the TS reading code in most Linux-based media players.

(4) Back to MPEG-2, but you have a better set of settings. Same encoder, so you’re pretty likely going to play if you fix the container. The Blu-ray setting makes a stream between 20Mb/s and 30Mb/s, variable bitrate. Since it’s thinking Blu-ray, it’s output as an elemental stream, but that’s not what you want. So go to the “Render As…” dialog, select your Blu-ray MPEG-2 setting, then click on “Custom”. Go to the “System” tab and uncheck “Save as separate elemental streams”. Leave the stream type as “Transport”, everything else alone. Now, go to the “Audio” tab and check “Include audio stream”. For even better quality, go to the Video tab and click the “Two-pass” box, just above the maximum bitrate box. This will deliver a better quality overall MPEG-2 at the same bitrate as your HDV.

Of course, you could also try the MainConcept MPEG-4/AVC encoder, but you’d have to build your own encoding, there are no preset for HD stuff.

The main reason to go to AVC would be storage… it uses less. There’s no technical problem with MPEG-2. Though if you’re playing back from SDHC or USB stick, higher bitrates could be an issue depending on the speed of the memory card.

-Dave

[Dave Haynie]

That’s no better than changing the file extension from .mxf to .avi or anything else. Materials Exchange Format has nothing to do with Quicktime, it’s related a bit to AAF (Advanced Authoring Format).

When you load a complex file format like MXF, MOV (Quicktime), AVI, or MP4, the application you’re using (Vegas, for example) has to find a particular CODEC within the framework of that specific multimedia subsystem. If it’s not there, it just doesn’t work. Manually changing a .MOV to .MP4, or vice-versa, can work if you’re lucky, but only because the MPEG-4 container format was derived from .MOV.

My guess is that MXF lives within Vegas as a fairly fixed thing… the CODECs you get with Vegas are the ones you keep. Unlike Quicktime or VfW/DirectShow, far as I know there’s no system-wide support for MXF. Maybe you could extend Vegas’s support of MXF via a custom Vegas plug-in (same way Vegas gets MPEG-4, in fact), but I don’t believe such a thing for MXF and DNxHD exist.

Quicktime and AVI (Video for Windows or DirectShow) live outside Vegas as independent, system-wide media carriers. Thus, it’s pretty common for 3rd party plug-ins to support one or more of these; that makes them functional in any application. For example, the Cineform CODEC works as a plug-in to both Quicktime and AVI, but far as I know, the Avid DNxHD plug-in only runs under Quicktime.

Another possible means of support in the system: DirectShow. You can apparently write a DirectShow filter to support any native container class — MPEG-2, Quicktime, MXF, etc. So its possible that someone has written a DirectShow filter for MXF and DNxHD. I found the latest version of the increasingly mis-named open source ffMPEG subsystem reportedly contains support for DNxHD in an MXF wrapper, 8-bit only. You could certainly use this on a command-line to re-mux to something else, but that’s a bit more complex than just adding another CODEC to Windows.

I also read an article that suggests that Avid’s version of MXF is tweaked compared to everyone else’s. “The great thing about standards — there are so many”… kind of stuff, I guess. Anyway, you might read this: https://michaelkammes.com/avid/play-avid-mxf-for-free

-Dave

[Dave Haynie]

[John Allen] “1) I experimented with rendering to mkv and mp4 as you suggested. Both of these formats worked. I cld change the size of the mkv file over progressive renders. The quality was nowhere near as good as the original m2ts as you wld expect. I’m trying to maintain quality. The mp4 on the other had was scarcely distinguishable from the original m2ts file. So I guess that’s a happy ending. So again, thank you.”

Did you just re-multiplex these, or render them? What I suggested was taking the Vegas output, then trying a different file wrapper… using something like YAMB to re-mux the Vegas transport stream to .MP4, or … hmm… not sure about .mkv tools, I haven’t done much with that (they should get more popular, Google’s WebM wrapper is derived from the Matroska open container format). If you’re re-multiplexing, it’s exactly the same video, so unless there’s something wrong with your player, the output quality should be the same.

I did notice something weird with Sony’s transport stream format, some months ago… it had some issues as a proper streaming format (even those that’s what MPEG-2 Transport Stream is for.. sure, it’s used on Blu-ray, but it was primarily developed for serial transmissions, such as DVB and ATSC television standards). I used the freeware tsmuxer software to re-mux my Sony-created output. After that, it streamed just dandy (this was for a digital radio demo… I was demonstrating that my radio could handle multiple bitstreams. But it had to play well over the simple streaming stuff in VLC, which is always a bit of a challenge).

[John Allen] “(2) I have had access to WD TV Live, Seagate Theatre+, and AC Ryan PlayOn HD2 media players. All three of them exhibit this playback behaviour. I find that a bit strange, a bit coincidental. As you say, pretty easy to demonstrate.”

I don’t really know if it was Vegas/Sony or the player at fault here. But it’s very likely that, for most of these media players, they’re based on the same open source decoders as found in VLC and other common freeware… if you look at the origins of VLC, even, you find most of these things all share code back to some single source. Warts and all. And in fact, most of these media players are running Linux, so it’s quite possible they’re running exactly the same MPEG-2 Transport Stream decoder software.

One easy test if it’s just the multiplexing, as mentioned: remux. Make the MPEG-4/AVC output as an MPEG-2 Transport Stream, using the Sony CODEC. See that it has that problem. Next, try remuxing back to .m2ts or .ts using tsmuxer, try that one. Once again, start with the Sony video, try remuxing to .mp4 using something like YAMB. In all cases, the video is identical.

Of course, you can have the Sony CODEC produce .MP4 output directly, rather than .m2ts. If you want identical quality, take the Sony template you were happy with, then just change the file wrapper type, on the “System” page (double-check that doesn’t mess with any of the other settings).

[John Allen] “(3) This is the bit that I don’t understand. The original m2ts file recorded on a Panasonic DMR-BW850 HD recorder plays perfectly on all three media players. However, the edited (on Vegas Pro), and then rendered, verson to an m2ts file, slightly smaller (about a gig) than the original, doesn’t play on the media players. That suggests to me that the rendering spec in Vegas may not be the same as that of the Panasonic HD recorder??”

The gigabyte difference is what tells me you’re not rendering out at the same format you’re using as input. It’s likely you’re not rendering out at the same bitrate as you’re accepting. That doesn’t mean it’s worse, depending on the specifics of the encoder.

But the playback, that’s very likely the effect of some disagreement, some problem in the way the transport stream is constructed. As described, the way to prove this is to re-mux the existing bad-playing file to another format, see if that plays. A possible way to just avoid the problem is to rendering out directly to .MP4 rather than .M2TS. Your recorded videos play because, presumably, they do not have whatever aspect of the Sony transport stream is tripping up the media players.

-Dave

[Dave Haynie]

[Casey Menninger] “Somehow, I did not know you could make a 24 frame NTSC DVD. I thought that was the frame rate for PAL.

[video_geek_mode]
Nope. PAL does fields at 50Hz, frames at 25Hz. This goes back to the dawn of AC Power… in the USA, AC power was first pushed by Nikola Tesla, as the best means of power distribution. The key was that by using alternating current, Tesla (backed by Westinghouse in the USA, several other companies in Europe, versus Thomas Edison who backed DC power) could use his newly developed transformer, to send power long distances at very, very high voltages (power loss over wires is proportional to current, not voltage… a transformer can trade off high voltage/low current for low voltage/high current).

So power at the wall changes direction at some rate… alternating current. In the USA, it was done at 60Hz… Tesla came up with the 60Hz and three-phase 220V power (split to most outlets to 60Hz 110V single phase) we still use today… he determined 60Hz transmissions would be more efficient. In Europe, German firm AEG became a near monopoly in power generation, and set their cycle to 50Hz, claiming it better fit metric standards (one of the few instances of stupidity around the generally superior metric system). They were originally 110V, but given that 50Hz is about 20% less efficient to generate and 10% lossier in transmissions, they boosted the power to 220V single phase/440V dual phase.

So enter TV. The television inventors, here and in Europe, recognized that electric lights actually do flicker, though too fast for your eye to usually see. However, this flicker would create a visible beat frequency against any video display of a different (and particularly, lower) frame rate… particularly given the way CRTs worked, counting on the persistance of phosphors. So the USA set their field rate to 60fps, their frame rate to 30fps (interlacing was needed to keep the signal relatively small), Europe to 50fps fields and 25fps frames.

With the advent of color TV, NTSC was tweaked to a 29.97fps frame rate. This kept the added color signal out of phase with the audio signal. The NTSC color signal actually gets very close to the space reserved for the audio signal, as well as mucking around with the luma signal, so, particularly in the days before multi-line motion adaptive comb filters, they put in a couple of magic tricks like this to make it easier to break the signal apart in the TV. But anyone who remebers the good old days of analog TV will recall how easily a slightly mistuned channel put video noise into the audio.
[/video_geek_mode]

[Casey Menninger]
Assuming the source is progressive, it is indeed better to render as 24p as opposed to 60i (using the top parameters that Dave mentioned in his post)? I always have flickering issues with interlaced footage. 24p will play alright on NTSC DVD players? “

I think some of the other guys covered this pretty well, but basically, it’s your choice. NTSC DVDs support 480/60i or 480/24p only. From your 1080/60p video, you can encode to 480/24p, but there’s going to be some frame blending or uneven frame dropping to deliver the proper 24p cadence. You can also render directly to 480/60i, which if done correctly will map 60p fields to 60i frames with no interpolation. Or you can drop every other 60p frame, and essentially create a 30p result packaged as 60i. This will play as 60i on any old TV, but a modern television nearly always does full field to frame conversion (if for not other reason than most modern displays, like LCD and DLP, cannot actually do interlacing), so this may look like real 30p playback on most displays (this is more commonly used for 1080/30p video put on Blu-ray, but it’s the same “trick”).

Which is correct? Depends on the material.

The 24p encoding for DVD is also called NTSCfilm… it’s really 23.976 fps, or something like that. The goal was to enable the best possible movie film encoding, based on the 24fps standard used for film.

This is very similar to the “24p in a 60i wrapper” some HD camcorders use for their 24p mode. What actually goes on disc is the 24fps run through a very specific cadence of 3:2 pulldown. For smart devices that can do something cool with 24p, the player knows which fields to toss out to reconstruct a proper 24p. For players less skilled in the art of playback, the video can be played at plain old 60i, and it looks line any other film telecined for TV use. This is and has always been part of the DVD spec.

To produce DVD compliant 24p, use the “DVD Architect 24p” or “DVD Architect 24p Widescreen” presets in Vegas.

[Casey Menninger]
Finally, if I use AC3 audio, how far up can I pump the max and average bit rate in VBR for MPEG rendering?

The total raw bitrate for DVD is 11.08Mb/s. There’s about 1Mb/s of encoding overhead in this, leaving 10.08Mb/s to work with. Of that, some is reserved for subtitles, leaving a maximum rate of 9.80Mb/s for the combined audio and video track. If you’re encoding multiple angle video, the maxium bitrate becomes 8.0Mb/s per angle. Typical audio in AC-3 is 192kb/s for stereo, 448kb/s for 5.1 surround, leaving 9.32Mb/s for video without having to worry about your audio track.

Of course, at this rate, you’re going to fit just over an hour’s worth of video on a DVD5, or two hours on a DVD9… in practice, less if you have other things on the disc (menus, etc). Plus, it’s rarely necessary to encode at full possible speed to get the best out of your video. I recommend a variable bitrate, but that’s also often necessary just to fit your project in the space available on disc.

It’s less of an issue today, but realize that some older players may not really support full speed video, at least on DVD-R. No real excuses, just lazy engineering far as I can tell. But another argument to back off a bit. There may also be a few players out there (PCs, PS3s, BD players) that would handle a slight higher rate just fine, if your software permitted it. But that would fail outright on most dedicated players.

-Dave

[Dave Haynie]

A little perspective here: 1080/60p video contains about 12 times as much information as anything that’ll fit on DVD. You have 1920×1080 at 60 frames per second. An NTSC DVD can have a maximum resolution of 720×480 at 60fps interlaced, or 24fps progressive. That’s your choice… DVDs are standard definition. DVD-class standard definition is going to look very, very soft compared to the better-than-Blu-ray quality video you get from 1080/60p.

-Dave

[Dave Haynie]

If you lose A/V sync, that’s usually a player problem. The likely cause is that your player can’t keep up with the video format, and should be dropping frames to maintain audio sync. But the fool who wrote that media player doesn’t know how to write media player software (appropriate responses are [a] quietly drop frames to maintain sync, or [b] warn the user that the hardware cannot support this format).

You’ll find this on pretty much any Android video player, for example (at least up to Android 2.2).

And in playing around with Android, I have found that Sony AVC is more difficult for the dedicated AVC/H.264 decoders to decode (specifically, on a Tegra2 based tablet) than Main Concept AVC, even at the same bitrate and profile type. I did experiments in Base, Main, and High profile at 6Mb/s, 720/24p. The Main Concept encoding (AAC audio, MP4 file wrapper) encoded just dandy, while the Sony file, same exact specs, didn’t play right… the audio walked away from the video.

Again, the player should either warn you or correct for this… losing audio sync is the result of lazy media player coding. But in your specific case, you might at least try rendering using Main Concept rather than Sony for your AVC. I still have no idea why Sony would be more difficult to decode than Main Concept, but it’s pretty easy to demonstrate.

At 720/24p and 4Mb/s, both decoders played back correctly — also kind of odd, since I’d expect the bottleneck to be in the AVC decoder proper, not really related to the bitrate. And I saw no difference going from Base to Main to High profile (Main Concept, as I recall, doesn’t do High profile… you don’t want that anyway if you’re having decoding problems).

MPEG-2 Transport Stream and AC-3 should be slightly easier to decode than AAC audio and MP4 file wrappers, but you might play around with container formats. Some media players have bad code for one file wrapper versus another — I’ve read of folks fixing their playback problems just by remuxing (eg, change from MPEG-2 TS to MP4 or MKV or something else, see what happens).

-Dave

[Dave Haynie]

[Frederic Baumann] “as far as I know, Canon DSLRs encode to AVCHD, which is highly CPU-intensive to decode, so it makes Vegas and the CPU work hard while handling such files. AVCHD is highly compressed video. It can be encoded quickly (which is cool for DSLRs embedded CPUs), but the counterpart is that it requires lots of computing to decode.”

Actually, AVC is very CPU intensive to encode, too. It’s just that all camcorders have dedicated AVC compression engines. The main reason for using AVC is that it has a very high encoding efficiency — when well encoded, it delivers about twice the visual of quality of MPEG-2 for the same bitrate (or the same quality at half the bitrate). Not all camcorders or HDSLRs encode AVC using all of the bells and whistles, either… and you can’t expect these devices to encode in realtime what a really fast PC might take 2x-4x realtime to accomplish.

[Frederic Baumann] “For that reason, it might be better to transcode it to another format easier to process while decoding. For instance Cineform does that. I have also read that it was able to improve the quality, by making RGB channels more accurate, but I have never understood how this could be possible – the data is in the file, so if Cineform can find hidden bits, Vegas should be able to do it as well 🙂 Explanations welcome btw.”

Ok, what you’re talking about here is color compression. Knowing that the human eye is less sensitive to color than luma, most video compression tosses out a great deal of the color. Consumer/prosumer formats are nearly always doing 4:2:0 or 4:1:1 subsampling… short explanation is that they’re tossing 3/4 of the color information. But hey, it still looks pretty good, eh?

When you convert AVCHD to Cineform, the conversion process interpolates your 4:2:0 subsampled AVC to 4:2:2 subsampled Cineform.. it’s making an intelligent guess about the “missing” color samples, but in a straight forward enough way that you don’t see anything different. And if that’s all you ever do with the video, it’s going to be ever-so-slightly lower quality than the AVC video was, thanks to the additional re-encoding process.

But when you manipulate video, there’s only so much resolution in the color. Editing in Cineform vs. AVCHD, you have in essence twice the effective color resolution… so color mathematics are just a bit less “fragile” than when operating directly on AVC.

This is similar to, though not identical to, adding guard bits in mathematical calculations, or editing a lower resolution image in Photoshop by first blowing it up a couple of times. In both cases, you’re not actually adding any usefully new information, but in duplicating and interpolating the existing information, you’re building an artificially higher resolution intermediate form, which is less subject to repeated errors in the process of manipulation.

This basic idea is also why you might do Photoshop manipulations in 16-bits/pixel, even if you’re just dealing with an 8-10-bit/pixel original, or why you pretty much always edit audio in 48-bit or floating point, even though you don’t likely have samples with more than 24-bit (if you’re lucky) actual resolution.

-Dave

[Dave Haynie]

I translate “used as a thumb drive” to mean “plain old DVD-ROM, not a DVD-Video disc”. Yes, of course he can store any computer data he likes on a DVD, if the goal is not to get a set-top DVD player to pay that video.

-Dave