[Dave Haynie]

[William Beazley] “To me, most apple users are just too arrogant in their anti-Microsoft out look to understand that the market needs a user friendly interface with dive down ability for power users. The 3 button mouse brought up earlier is a perfect example. Jobs hated the 3 button mouse, so now Mac users have to get carpal tunnel searching around for the right menu to descend, rather than a simple right click for a drop down menu. It’s stupid and wasteful.
“

I completely agree there. I lean a bit toward what John said… I’m not sure anyone made really good use of buttons beyond three. And there’s the potential of adding touch sensitivity to a mouse — also not there yet, but both Apple and Microsoft are playing with it.

But the three button mouse with scroll wheel is extremely useful. And it is ultimately GUI driven. Apple’s GUI was written for a single button mouse, so they’re not using multiple buttons that well. Windows copied the OS/2 idea of one button for “select”, the other for “object menu” (well, it was a real object on OS/2), and the third button evolved very nicely to deal with scrolling.

[William Beazley] “I have arrived at this bake-off because I use a lot of Sony equipment and have a dual core PC so I am drawn to Vegas. I have, however, a lot of horse power for rendering in this super Mac 12 core so I am drawn to FCP. Regarding FCP I am considering FCP X for the easier UI as being better for occasional use. Vegas looks like an easier direction now for a PC laptop with small files to render and no restrictions to Quad Core.
“

Well, I’d not be happy with either of your systems as-is. The 2-core PC is not fast enough for HD video editing. Ok, technically you could … I have such a laptop, and it can be done. But I’m much happier editing on my six core desktop.

FCP7 certainly has a following, but I suspect some of that is simply that same Apple arrogance — the average FCP user may not be not aware of much else. It’s still a 32-bit program, and behind the times on many things. My daughter run it on her MacBook (a loner for kids in the Communications Academy at her HS), and I was actually quite floored on how poorly it handled native video editing. She used a couple of my camcorders on a project, and I handed her the video files… AVCCAM/AVCHD files from Panasonics. They loaded, but the speed (it’s like a dual-core 2GHz-ish i5 MacBook Pro… should be at least as fast as my 5-year-old HP) of editing made this completely useless. So I made her a set at qHD AVC.. still not enough horsepower for editing. Finally I tried qHD AVC-Intra, and we were good.

It was only later I found out that the standard practice at school for importing digital video from her camcorder (also an AVCHD-based Panny) was to feed video out at SD to a Canon XL-something-or-other, which converted it to DV for import. Oh well… anyway… very, very.

While that’s probably solved on a 12-core system, I don’t imagine a 32-bit program really has enough memory resources to make much use of a 12-core system. But that would totally rock with Vegas. FCP X certainly costs less than FCP7 (if you don’t already own FCP7), though they’ve removed features. Some are pro features you may not care about, but others… no real DVD authoring anymore, for example. But at least it’s a 64-bit program; that really does make a difference once you’re doing large HD projects, anyway.

There’s now a 30-day trial of FCP-X (you have to get it from Apple’s web site, not the Mac iTunes Store where you buy the paid version), always has been with Vegas. Sometimes the best tool is simply the one that fits your brain the best.

-Dave

[Dave Haynie]

[John Bean] “My bad @Dave. I mistakenly used 8 bpp when it is suppose to be 24 bpp (8 bits per RGB channel=8×3=24). A simple slip of the mind that that there 3 channels of color to account for.”

Actually, the calculations you did were at best for a monochrome image. You reported 345600 !BITS! for an SD frame. That’s the number of pixels, not the number of bits.

[John Bean] “Your claim that a 1920x1080p (23.976 fps, 24 bpp) video at 6 Mb/s is of higher quality than a 720x480p (23.976 fps, 24 bpp) video at 8 Mb/s would be correct … only if the compression was LOSSLESS.

But you cannot achieve LOSSLESS compression at those high rates for 1920x1080p-6Mb/s videos!”

I said absolutely nothing about lossless compression, other than the fact that you need about 200Mb/s for lossless SD and 1.2Gb/s for lossless HD. NO ONE IS DELIVERING LOSSLESSS VIDEO. Get over it. Outside of some very high end professional editing systems, or the output of your HDMI connector, you are never going to find lossless video.

Sure, you can render it from Vegas if you like, but unless it’s from a lossless source, there’s little point.

You still seem to have not the slightest clue about how psychovisual compression algorithms work, or much of anything else about video and compression. There is just far, far more you need to know to even start having a useful conversation about this here.

[John Bean] “If you follow, then there are just no way an encoder can compress a 1920x1080p (23.976 fps, 24 bpp) video to a bit-rate of 6 Mb/s without having to restrict the allowable BITS PER FRAME to a very small value. The compression ratio is just way too high!”

While you reproduced my uncompressed/RAW numbers properly this time (after being given the answer, twice), you still have no idea how MPEG, and in particular, AVC compression work. You really don’t, and you know it.

It is clearly pointless either suggesting to you where you can find real-world examples that refute your thesis, such as broadcast HD video (which is far better looking than DVD) or lower-bitrate modes on pretty much every AVCHD or MPEG camcorder, which often go as low as 6Mb/s, and still, on many subjects, will look better than upscaled SD. Not always… again, you really have to understand how MPEG works to understand why all of my claims are true.

Enough on this thread. Learn some things before speaking about them. There are a fair share of beginners here, and you’re already misleading them on numerous issues.

-Dave

[Dave Haynie]

[John Bean] “I understand very well how compression works and that AVC is a much better compressor than MPEG-2.
“

I don’t think y’do… otherwise, you wouldn’t come up with such horribly incorrect calculations.

[John Bean] “An *UNCOMPRESSED* 720x480p (23.976 fps, 8 bpp) video only needs a 8.236 Mb/s bit-rate! That is UNCOMPRESSED! This works out to be only 346 kb/frame. To compress this video to 8 Mb/s works out to be 334 kb/frame only!”

Nope. Full 720×480 video is 24bits/pixel (or more, but lest’s stick to the standard stuff), otherwise dubbed 4:4:4 color, at ~24fps. Each frame is 8,294,400 bits, 24 of these per seconds yields 199,065,600b/s, or ~200Mb/s, or 66MB/s for uncompressed video. This is a bit simplistic, since it’s leaving out format overhead and other things. So I can easily point you to existing uncompressed standards, which will illustrate this for you.

The first common uncompressed digital standard was SMPTE D1 (aka ITU-R 601, Rec. 601), which runs 720×480, 30fps NTSC video in a number of difference uncompressed (aside from color decimation) modes. The standard 4:2:2 D1 is 173Mb/s… a bit lower than my calculation due to the gain in size from 30fps versus the loss in size due to the 4:2:2 subsampling. Feel free to look this up… it’s normal, everyday stuff I suspect most folks here have been working with for years (I started in digital video back in the 80s… it wasn’t pretty). The peak D1 rate is around 275Mb/s for 4:2:2:4 video, this includes an alpha channel. There’s a PDF of the spec here: https://www2.rohde-schwarz.com/file_6272/7BM19_0E.pdf.

Take the D1 format, keep the 4:2:2 encoding, compress each frame using a mild JPEG-like compression of about 3.3x (yeah, a factor of 3.3, which is actually pretty small), and you get the DV50 standard used in many higher-end SD camcorders. D1 actually encodes a bit of the off-screen stuff you don’t actually need (it was intended to be exactly digital video, not computer video), so they cut that out for the camcorder formats, thus, the peak uncompressed rate is slightly lower than D1.

Now take that same 24-bit YCrCb SMPTE D1, subsample 4:1:1, compress using a JPEG-like intraframe compression algorithm (discrete cosine transform lossy filtering with Huffmann encoding.. I’m sure you know all this, right), and you get to the DV25 standard… 25Mb/s for standard 5:1 compressed digital video, the foundation of the camcorder industry prior to HD catching fire.

Which of course should lead you to realize that standard definition at 8Mb/s in MPEG-2 is compressed about 15:1 from RAW, or 25:1 from the original uncompressed source. That’s significant, sure, but once you really grok the difference between intraframe-only and interframe compression, it’s no huge surprise that DVD video, as we all know, can actually look better than DV video, when well encoded from higher resolution sources.

[John Bean] “A 1920x1080p (23.976 fps, 8 bpp) in its UNCOMPRESSED form contains 16588.8 kb/frame or 16.6 Mb/frame.”

As with the SD, you need to check you math here. A 1920×1080 frame with the usual 8-bits per color contains 49,766,400 bits per frame, or 1,194,393,600 bits/second worth of information, or roughly 1.2Gb/s. Easy math… 6x as much resolution as SD, 6 x 200Mb/s = 1.2Gb/s. The HDV specifications don’t encode full HD; the store 1440×1080/30p at 25Mb/s using MPEG-2… that’s a 48:1… almost twice the compression of DVD. And yet, there’s absolutely no question that HDV looks better on-screen than upscaled DV.

The US broadcast standard for ATSC MPEG-2 is 19.4Mb/s, though it’s rare that anyone actually broadcasts just one stream in that channel. So leaving room for an SD channel or two, that’s usually a max of about 15Mb/s, including an audio stream. So broadcast HDTV is roughly 80:1 compressed from the original source material… and again, no one’s going to argue that it doesn’t look better on-screen than upscaled SD. I assume you’ve watched broadcast HD and aren’t trying to debate this, either, even if you didn’t understand the math.

If you did nothing more than move from professionally encode MPEG-2 at 15Mb/s to equally well encoded AVC, you could drop to 7.5Mb/s with no visual difference. Not all AVC is necessarily that well done; in particular, camcorders don’t always have the compute budget to fully employ everything you can within the AVC specifications. But that’s not an issue when preparing material for broadcast, or even for YouTube, necessarily. AVC really does have twice the coding efficiency of MPEG-2, conservatively, if done right.

All this is about are psychovisual encoding… what does your brain care about, what doesn’t it care about. It’s certainly true that, all things equal, you will have more compression artifacts when you encode at 80:1 versus 25:1… no question about it. But all is not equal. When I run MPEG-2 on an SD image, I’ll get 45×30 macroblocks. On my 72″ screen, that means each macroblock in SD is 1.4″ x 1.1″. I’m going to very definitely see even a small bit of compression noise here. That full HD image delivers 120×68 macroblocks… each block is 0.5″ x 0.5″ … there could be far more per-block noise and it would be less visible. Not only that, but for the same image, each block is covering less area… so the likelihood of compression noise is far less.

And that’s all for MPEG-2… AVC can do far more complex things with macroblocks, very, very long GOPs (I-Frames only when you need them, etc). Thus, the same visual quality at half the bitrate.

-Dave

[Dave Haynie]

[John Bean] “”Based on *visual comparison* only, you can verify that a YouTube 1080p video will not *decode* to 1920×1080 as good as a DVD 480p video can *upscale* to 1920×1080 at bit-rates equal-to or greater than YouTube’s 6 Mb/s for 1080p.””

Actually, you can very much verify that a well encoded 1080p video at 6Mb/s in AVC will look better than a well encoded DVD/480p at the typical 6-8Mb/s upscaled to 1080p. That’s not to say you’ll find all that many videos on YouTube that compare in quality to commercially mastered DVDs, but that’s an entirely different issue.

[John Bean] “And this is because a 720x480p-8Mb/s video has *potentially* more information per frame to accurately decode to 720×480 and then up scale to a higher resolution like 1920×1080.”

I don’t think you understand how video compression works. A 6Mb/s AVC video has about as much useful information as a 12Mb/s MPEG-2 video. I can certainly present material that would look better on DVD in MPEG-2, and I can certainly present material that would look better in AVC/HD at a slightly lower bitrate. Obviously, the AVC encoding will break down a little sooner on high motion video, but MPEG-2 isn’t far behind.. that’s why amateur MPEG-2 or AVC nearly always looks terrible, while professional video mastering engineers will run a low pass filter over high motion parts of a video, crank up the bitrate (no commerical videos are encoded CBR), and maybe even apply motion blur, to eliminate visible macroblocks.

-Dave

[Dave Haynie]

Yup… I think an AF100 would be a good camera for certain styles of wedding videography — what I use my Canon HSDLRs for today. I would not use it as primary camcorder for any paid gig until I was very, very familiar with it. And, as suggested, I wouldn’t drop that kind of cash and move that far out of conventional camcorder space without trying it first.

For any paid shoot, I’m going to have the primary camera, a B-roll camera, probably at least one HDSLR, and backup for the prime camera. I’d love to try an AF100 in place of the HDSLR to start with, learn it in content, but only then I’d be comfortable even deciding if I was
happy with the shallow DOF film look as a main camera. So for me, I’d have to pretty much know that’s what I wanted before I bought.

-Dave

[Dave Haynie]

The MTS files are all you need. Doesn’t FCP7 or at least FCPX support native MTS use? Pretty much every other NLE does. Did you try just directly dropping them on your timeline (or however you’d normally
import a video file into FCP)? I have used AVCCAM camcorders for some time, and never once worried about anything but the .MTS files.

If that doesn’t work, I know that MP4 is widely supported on Macs. You can re-multiplex the MTS files (MTS is just an MPEG-2 Transport Stream, probably the most common video file container format in the world, the basis for digital television, DVD, Blu-ray, etc). I would use a freeware PC program called YAMB for this purpose; not sure it’s on the Mac, but pretty likely.

-Dave

[Dave Haynie]

I agree.

There was a time when Vegas was easily the most reliable piece of software I used. Even new releases, pretty much. That hasn’t been the case for awhile. Maybe there’s more pressure to get versions out at a specific time, rather than when they’re ready, maybe it’s lack of proper testing, whatever.

Regardless of the cause, this isn’t a necessary part of software development. You shouldn’t treat the customer as a beta tester. And yet, look at just one of my pet peeves, which occurred in Vegas 10. In Vegas 10, they used a new, private API to talk to Cineform. Ok, fine, maybe I get something out of that, I don’t know — the usual Video for Windows API was working just dandy for me. But they didn’t actually check for that new API being there, so when you ran with an older version of Cineform, Vegas crashed. Boom! Thus, two best practice rules broken at once: check the version, and offer the user a way to turn off that new but totally optional feature.

And so I updated Cineform… Vegas 10 still didn’t work properly with it. Neither did Vegas 10a, 10b, 10c… ok, 10c or 10d did actually, finally, open Cineform files correctly. Still crashed when rendering them. Jump ahead to the latest Vegas 11, and the Cineform interface is STILL screwed up; most recently, the video I render is substantially darker than what I see in Vegas. Only happens with Cineform, and I’ve basically moved on to using DNxHD for any intermediate video.

And this was all related to a feature that, far as I could tell, simply wasn’t broken in Vegas 9. And never did break in Vegas 9… I can render just dandy to Cineform, still, in Vegas 9. No problems.

This kind of thing is the result of insufficient testing, it’s not an inevitable part of the software development process. And yeah, I’m backing that with experience… I’ve been developing software, on and off with hardware, since the late 70s (I had my first commercial releases when I was in high school).

-Dave

[Dave Haynie]

Another thing about Windows 8, it’s not just the user interface. The most in your face chances are certainly this Metro user interface — the thing that seems to have survived the cancelled Zune media players.

But that’s just the surface. The real news is WinRT — essentially, a whole totally new OS under the hood. The Windows NT kernel was designed long ago to host multiple “API servers”, which are essentially nearly complete and separate operating systems. Everyone knows the Win32 parts that came over from Windows 98, and eventually grew into 64-bit versions as well. There has always been a second one, the POSIX API, which is a UNIX-like interface that made it easy to move UNIX programs over, primarily for Windows Server use, but it’s alive in every Windows system today.

So WinRT is yet another API, another nearly complete OS in fact. Microsoft is going to be pushing this as the future of Windows, though how much, I guess we’ll see. But they seem to have spent so much time on WinRT and merging the desktop with the not-yet-even-real tablet market (and their tiny phone market… Microsoft’s sales on Windows 7 Phone for 4Q2011 were beaten by both Apple and Android… just one good day’s worth of either system’s sales), that they don’t seem to have done much of anything for the existing desktop market.

I plan to try the preview at some point, just to be able to speak more intelligently about it, but I’m very skeptical about this being very useful for desktop users. I know that both Ubuntu Linux and Apple have been pushing “small computer” UI ideas onto the desktop. Ubuntu’s experiment, really more of a push for netbooks than tablets, has been pretty soundly rejected by most Ubuntu users. And Apple’s latest merging of iOS ideas, while not as severe as what Microsoft has been doing, has been praised with words like “hodge podge”, “train wreck”, and “has Apple lost their ability to innovate”… and those are from the Apple-friendly press.

Frankly, I have no need for my phone or tablet to run the same OS as my desktop. I also don’t need my power drill and my table saw to have the same user interface, or my lawnmower versus my bicycle. I think “the right tool for the job” is still an important concept.

-Dave

[Dave Haynie]

[John Bean] “Based on *visual comparison* only, you can verify that a YouTube 1080p video will not upscale as good as a DVD 480p (or i) video at bit-rates equal-to or greater than YouTube’s 6 Mb/s for 1080p.”

Not to be pedantic here, but check you math… a 6Mb/s YouTube 1080p video doesn’t get upscaled for display on a 1080p monitor… that’s it’s native resolution. And on most material, it’s going to look better on that 1080p display than anything you get from any 480p video, regardless of quality. This is why most pros shoot in HD today, even if the delivery is going to be SD… a decent HD camcorder will produce better video than the best SD camera that’s ever existed.. and at least match it when converted to SD.

You also need to stop doing that math… compression bitrates are only important comparing apples to apples. HDV at 25Mb/s isn’t going to look as good as DVCAM at 50Mb/s, which in turn isn’t going to look as good as DVCAM at 100Mb/s. You’re actually varying color decimation as well as bitrate there, but close enough. It’s apples vs. apples.

Going to MPEG-2 or AVC, it’s an entirely different story. This is why DVD at 5-9Mb/s looks at good, occasionally better, than DV at 25Mb/s… particularly when professionally mastered (eg, not left up to camcorder algorithms that have to run in realtime at 3W or less). The bitrates are simply not comparable at all.

As for lossless compression… no one’s doing that. It isn’t even necessary.. we humans don’t care about much of the information that could be captured. For uncompressed HD at 1080p24, you’re going to need about 1.2Gb/s… and that’s just for 24-bit color. Even digital cinema cameras aren’t usually recording uncompressed… there’s no reason consumers care about this. That’s 25x-50x more information than recorded by most professional camcorders or HDSLRs … and no one’s complaining.

-Dave

[Dave Haynie]

[Ron Whitaker] “1) First question: if I render out to MainConcept AVC/AAC (.mp4) or Sony AVC/MVC, those are containers, right? And I think/hope that the video codec each of those use is h264. Is my thinking correct?
“

Absolutely. And sure, if you have the right tool, you can re-mux the video from one container to another. Or even the same container… I used to have a “throw-away” camera, a Sanyo Xacti FH1, which recorded directly in AVC/AAC into MP4 containers. Only, it had bugs, like negative timecodes, which made Vegas lose its mind. Re-muxing to MP4 fixed the problem.

This is kind of a high-level thing… consumers don’t understand enough about the issue to even ask the question. So the 2,878 programs out there to produce .mov files are designed to get your video on an iPhone as simply as possible.

[Ron Whitaker] “The only reason why I’d like to find something other than ffmpeg is that ffmpeg looks like you basically enter commands like on an old DOS prompt. (I left the old DOS prompt behind 20+ years ago and would rather not go back to that! But if that’s all there is out there, then I guess that’s what I’ll have to use.)”

FFMPEG comes from the Linux/FOSS world. While the DOS prompt was left behind ages ago for consumers, professional software developers still use it for their own tools. It’s very efficient for things you do every day.

This is open source… free software. The good part is that you have some great, professional programmers working on this stuff… maybe they’re bored with the bill paying day job, maybe they just want a tool they can use for a hobby. The problem: nothing forcing the developer to put a nice, user-friendly GUI on top of it. Much of what’s done in free software is included in the VLC program, but I don’t find a real Quicktime output mode (on some occasions, you can rename “thing.mp4” to “thing.mov” and everyone’s happy, but this isn’t univeral… the .mp4 container started with Quicktime, but it has diverged as a separate standard).

[Ron Whitaker] “3) OK, one last question: my footage that comes from my camera (Panasonic GH2) is in AVCHD format. Is AVCHD compressed, or an uncompressed format? So, when I open my AVCHD clips in SV, do my editing, then render it out, it’s getting compressed again, no matter WHAT format I render to?”

Yes. AVCHD is a formal specification for AVC video (aka MPEG-4 Part 10, aka H.264) video, SMPTE AC-3 audio (aka “Dolby Digital”), in an MPEG-2 transport stream file wrapper. It puts boundaries on bitrates and GOP sequences and other things, to make it a “smaller” standard to target.

It’s very compressed.. but also state of the art in compression. A well compressed AVC video will look as good as an MPEG-2 video at twice the bitrate. Looking at it another way, the typical peak of 24Mb/s for AVCHD video is substantially higher quality than HDV video at 25Mb/s… much less DV video at 25Mb/s.

The penalty you pay is complexity. MPEG-2 at SD rates was decoded in software with a 133MHz Pentium (before that, you needed hardware acceleration). You need a dual core 2GHz-or-so processor to decode 1080/24p or 1080/60i AVC video at native frame rates (depends a bit on the specific processor). All mobile devices employ hardware acceleration to decode AVC; even PCs benefit greatly by getting the GPU involved (kind of the point of Vegas 11, BTW).

Back in the old days, I would edit DV video, and if I rendered back to DV, it has to recompress. At some point, Vegas learned to do “smart rendering”.. only the changed parts had to be recompressed. That was nice for repeated editing, but at some point, I have to render to the final delivery format, which isn’t DV. The same cycle took place with MPEG-2… if you match the input and output formats, MPEG-2 could get this same “smart rendering” support.

This is technically possible with AVC. But it’s not as if MPEG-2 is twice as complex as DV, and AVC is twice as complex as MPEG-2… these are orders of magnitude of increased complexity. When you make video compression 2x better, you may make it 10x or 100x more complex. So no idea if anyone’s going to get AVC smart rendering going well. You will recompress.

That’s not as bad as it sounds, though. In the audio and video compression industry, there’s been the concept of a “fragile” compression for some time. Early versions of MP3 and others, early versions of MPEG, had very sharp generation to generation degradation. I know that in the early days of MiniDisc, you would hear very noticable recompression artifacts after 4-5 generations of recompression. But by the time MD was over with, you could 25 generations of recompression without much in the way of audible recompression artifacts. Most modern compression engines have learned from these early experiments. Most…

-Dave