Forum Replies Created

Page 85 of 110
  • Dave Haynie

    January 28, 2011 at 8:10 am in reply to: Conceptual: Stereo AVCHD on a Red Laser DVD

    3DBD technology is still in beta…it will be sometime before you see anything on the prosumer level

    That’s incorrect. Blu-ray Profile 5 was officially released, in final form, on December 17, 2009. This adds the 3D support, via MVC, as well as upping the peak data rate from 48Mb/s to 72Mb/s. Naturally, it takes awhile for manufacturers and software vendors to respond to a new spec, but look around.. most new BD players support 3D. The PS3 got a 3D software upgrade last summer.

    It’s a specification — there’s no “beta” on a spec. It’s either official, or still in development, but there’s no testing phase. Any given implementation of that spec might be in beta testing. But in fact, there are several high-end professional BD3D authoring systems in full commercial release already. There are many discs already released… again, not something you would be doing based on a spec in flux.

    Home 3D itself is still very much a work in progress. But that’s on the television technology. The Blu-ray stuff was designed to allow players to reformat based on the evolving viewing solutions. I’m still waiting for something worthwhile… or a 4K television. That’s the upgrade after 3D.

    MVC isn’t only of use to BD. I looked around and found this: https://research.nokia.com/page/5092. Didn’t compile it, the intent is to let you create MVC AVC files for Nokia smart phones running Maemo, created from a Windows or Linux shell. Maybe it scales up to BD size? Anyway, the source code is included, so in theory, it COULD with some work.

    -Dave

  • Dave Haynie

    January 27, 2011 at 9:25 pm in reply to: Conceptual: Stereo AVCHD on a Red Laser DVD

    Yup. Plus, MVC is (will be) the proper delivery format.. the Blu-ray players worries about the actual formats supported on the TV. I tend to think that things like 960x1080p side-by-side and interlaced formats are temporary… you want the thing that’s going to work, both with today’s technologies and tomorrows. MVC lets the player decide.

    But yeah… you would kind of imagine that, since Vegas is doing the 3D editing, Sony would consider it a priority (theirs, not mine) to deliver 3D authoring in DVDA. And like all DVDA stuff, totally above the board BD creation. That would demand MVC support, in Vegas or in DVDA.

    I don’t know of any MVC encoder that’s no sold at “Hollywood” prices. Nor any 3D BD authoring solution, with or without integral 3D support (eg, even a 2D authoring program needs tweaks to allow an MVC stream as a valid asset).

    But that’s not a shock. Vegas got HD support long before they offered any real solutions for HD delivery. Of course, that’s easy to not worry about when there’s no standard. The 3D-HD delivery standard was out before Vegas 10. So ok, they didn’t have the resources to roll 3D into DVDA. It would be a very useful thing for Sony to officially set the record straight on 3D vs. non-3D support in DVDA.

    And while I’m not offended by 3D support or anything, this is one of those things that we feared, when The Sonic Foundry was bought by Sony. To their credit, they didn’t do most of the terrible things these mergers usually see.

    However, prior to Sony’s buy-out, Vegas was the absolute top-of-the-line application. There was no compelling reason, other than development resources, to leave any feature out of Vegas. But Sony can sell Blu-Print for crazy Hollywood money. They have an interest in not making DVDA anywhere near as capable.

    And on the flip side, I think 3D was put into Vegas because Sony sees 3D as the Next Big Thing. I’m not sure most Vegas users even had 3D on their radar. And while I never have a problem with any new feature, assuming it doesn’t have an otherwise-bad effect on the program… it’s never that simple Each new feature represents a development cost… some other new feature did not get implemented, so that this one could be. Did I get 3D at the price of edit-time GPU acceleration? No idea … but I know which one is more useful to the most existing Vegas users. In Sony’s defense, though, 3D might be better at making new sales. And we all ultimately benefit, the more people use Vegas.

    -Dave

  • Dave Haynie

    January 27, 2011 at 5:04 am in reply to: Conceptual: Stereo AVCHD on a Red Laser DVD

    Well, there are lots of practical concerns: can you get an MVC bitstream into an AVCHD build (short answer: I’m sure there’s a freeware tool that could do the job with some hacking, if no other simple option presents itself), and would a 3D BD player recognize it as 3D.

    The limitation, otherwise, is going to be bitrate. The AVCHD format supports a maximum of 18Mb/s on DVD… that’s essentially a double-rate DVD. Some players go faster, but you can’t rely on it. So the MVC stream would have to still be 18Mb/s, meaning the main stream would max out at 12Mb/s or so.

    Naturally, a pure side-by-side at 960x1080x2 would work, and transparently to all AVCHD creation software… just the way Panasonic’s consumer 3D camcorders work. You don’t even need a 3D Blu-Ray player, but you have to have a TV that supports SbS, and manually set that mode. Either way, you’re taking a resolution loss.. I would bet the MVC version looks better on most material, even with the lower bitrate.

    -Dave

  • Dave Haynie

    January 25, 2011 at 11:01 pm in reply to: render size

    Watch your “B”s… B = byte, b = bit. You successfully inverted this, twice, in two small paragraphs. Yeah, that’s 765MB (may show as 747MiB on your hard drive.. and it may claim that’s actually MB, but do not fall for that.. a DVD5 contains room for exactly 4,700,000,000 bytes).

    Vegas proper is a professional tool, Pinnacle is a consumer tool. Not that Vegas couldn’t do a little more hand holding without much complaint, but Pinnacle has to, to be a successful consumer tool. Also, with variable bitrate encoding, you don’t know exactly how large the final product will be, only “about”. With constant bitrate encoding, you know precisely, but for DVD, you shouldn’t be doing that.

    -Dave

  • Dave Haynie

    January 25, 2011 at 10:54 pm in reply to: Best Render Settings For Blu-ray

    You’re extrapolating, erroneously. “The Sony AVC CODEC only supports constant bitrate encoding” is a true statement. So is “AVC supports variable bitrate encoding”. Sony’s AVC is intended for Blu-ray, primarily, and so there are no salient comparisons with MPEG-4 Advanced Simple Profile (I assume that’s what you mean by “MPEG-4”.. AVC is just as much “MPEG-4” as ASP), Blu-ray only supports AVC, MPEG-2, and VC-1.

    You can get AVC with variable bitrate encoding in Vegas using the Main Concept AVC encoder. But there are no included Blu-ray presets. Not sure why, but you really do need proper settings to ensure compliance. Could be the Main Concept encoder doesn’t do Blu-ray standard AVC? Never tried it myself. I probably should.. it also supports higher bitrates (up to 20Mb/s) than Sony’s.

    -Dave

  • Well, there’s two things at work here. You have an uncompressed 600GB AVI from something. But I don’t think that was your original video. What you capture on camera is the best it’ll ever get, in some sense. Yes, you can use post-processing magic to fix problems, but you’re paying a price for anything but small tweaks.. could be paid in resolution (de-noising algorithms all damage resolution), could be in color resolution or accuracy. Not a problem, those.. the goal is the best final product, not the most accurate or natural, in nearly every case.

    But you can’t add information. Taking a 25Mb/s HDV video to a gigantic uncompressed video does absolutely nothing for you.. it looks exactly the same. You can stave off the effects of repeated editing, however. If you got to a 4:4:4 or 4:2:2 format directly frmo your camcorder video, particularly something that’s not lossy, or well proven for repeated encodings like Cineform, you can improve the final product. But what you’re doing there is eliminating loss, not adding something you didn’t originally capture.

    The MPEG algorithms use a bunch of cool magic tricks to toss out stuff we don’t care about, and exploit redundancy in video. Most do color subsampling. A full RGB capture has 24-bits for every pixel. But each human eye has about six million color-sensing receptors and 120 million luma sensing receptors. We care about color, but nowhere near as much as we care about luma. So most camcorders record in 4:2:0 or 4:1:1 subsampling… in short, they take every luma sample, but toss out three out of every four color samples.

    Then there’s the MPEG algorithms themselves. If you take a photo and blur it just a little, you may not notice the change, and yet, you have reduced the information content. There’s a mathematical operation, fully reversible and lossless (in pure math, anyway), called a Fourier transform. Any finite sample of pixel data, audio data, etc. can be represented precisely as the map of frequencies being used. MPEG uses a function called a discrete cosine transform to represent every point in a 2 dimensional matrix (eg, a photo or video frame) in terms of frequency.

    One you have a frequency matrix, you can very intelligently filter just the high frequency stuff. That’s the lossy part of MPEG. It’s going to eliminate the parts the eye will not notice as readily… obviously, too much filtering (too much compression), and it starts to fall apart. This is the same thing JPEG and DV do. Regular DV25 is a about a 5:1 compression.

    The other thing that happens is interframe compression. The algorithm breaks up video into “groups of pictures”, or GOPs. In most (but not all) video, each frame is pretty similar to the one before or after it. So in each group, the first frame is called an I-Frame.. just that JPEG-type compression. The remainder of the frames (an MPEG-2 GOP is often 15 frames.. in AVC, it can be hundreds) are not full frames. There are various algorithms that compute just the differences between each frame and the next (and sometimes, the previous as well). This is why MPEG compression is so much smaller, but still looks very much the same.

    -Dave

  • Dave Haynie

    January 25, 2011 at 9:42 pm in reply to: render size

    You control the output size by controlling the bitrate. The DVD Architect MPEG-2 templates default to something pretty close to the maximum DVD rate, around 9Mb/s. 9Mb/s is over 4GB per hour, so you get just over an hour’s worth on a DVD5, depending on the audio format.

    If you just want to know the size, that’s easy enough. Go to the template you’re using (eg, “MPEG-2 DVD Architect NTSC Widescreen” or whatever), and find the bitrate listed, on the Video tab. You should be rendering with variable bitrate for best results… use the average here.

    Ok… now get your calculator. (bitrate) Mb/s * (length of video) s * 1 byte/ 8 bits = (size of video). If your video time is in minutes, multiply by 60 sec / minute.

    You can do a little more advanced programming in DVDA, too. For example, the “generate chapters” function just creates buttons for each marked chapter… there’s nothing terribly magical about these. If you have a bunch of independent clips, and want to create a continuous video with them as-is, you can drop these all onto a submenu in DVD… call that one “Chapters” or “Selections” or whatever menuy buzzword you like.

    Take the first video, copy it to your top-level menu, and make that the “PLAY” button. Next, for each of these assets, make the “End Action” a link to the next one in sequence. When you’re done, you’ll have something pretty similar to having rendered a whole video with chapters. DVD Architect isn’t necessarily brilliant about managing links, though, so add the assets in the order you intend to link them. That seems to ensure they always show up in order on the disc… you don’t want needless seeking between chapters.

    You can actually use this same technique to create transitions between sections in DVDA. Rather than link the video assets directly, make the “contents” page a set of submenus. On each submenu, drop your asset, but make it invisible. Then, put the transition in as the menu content, and set the end action of the menu to start the video asset. You can’t always make this as silky smooth as a fully rendered single MPEG, but it can be pretty decent.

    You can vary the bitrate, for smaller video. That CAN affect output quality, but not always, it depends on the subject matter. Most people want to control time and size, but bitrate is your means of control — the one degree of freedom you have, other than length of video (which, as an artistic decision, should not be used for making technology tweaks). You can find an online bitrate calculator here: https://www.videohelp.com/calc.htm.

    -Dave

  • Dave Haynie

    January 23, 2011 at 5:15 pm in reply to: BluRay needs for Vegas

    You can skip Blu-ray, with an ample supply of 32GB Flash dongles or little HDDs, sometimes, but not always. Given that a BD burner runs $100 and a BD-R disc about $1.50, this is not a valid long-term solution if you’re making HD for mainstream clients. Most people how ask for it will have a BD player.

    But otherwise, yes, HD on other media will work, though most PCs without BD players can’t play a BD compilation, much less a BD ISO. An .mp4 file will play on most PCs these days, including those running Linux and MacOS. If your HD is a full length production, though (which I’ve kind of assumed here.. if it were not, you’d probably just put an .mp4 file on a DVD, if they couldn’t handle Blu-ray), FAT32 is not much of an option. That pretty much means NTFS, which is read-only on Linux and more recent versions of MacOS, but can’t be read at all on most other devices.

    The DuneHD is based on Linux, so it can actually access a full Blu-ray ISO on ext3 or NTFS file systems. But this the exception, not the rule. You need a much higher level of computer expertise to be able to deal with these kind of players, and they’re extremely rare compared to Blu-ray players, at the moment. And of course, today, you can buy 3-4 fairly nice Blu-ray players for the price of the Dune HD (depending on whether you buy “Base” or “Prime”).

    Another option is certainly online, as well, but here in invariably take a quality hit. I have often distributed higher quality MP4 files, and occasionally ISOs, from my own web site to clients. But of course, they have to know what to do with them (you can make it pretty easy for them by putting it up on a web page.. everyone knows how to do a web download, lots of internet users don’t have a clue about how to log into an ftp server). And you need your own site with plenty of storage. Going to YouTube, Vimeo, or one of the others, you compromise on quality (well, Vimeo will keep your original around for awhile, but will they accept a 15-20Mb/s encoded video? YouTube actually will take 20Mb/s .mp4, but they don’t store it).

    I should also point out that, in the fairly early days of DVD, I offered the option of including a DVD player in the package for any wedding shoot (I was doing that kind of work more often, back then). I would certainly do the same for Blu-ray today, if it came up (only shot three weddings last year, and no, it didn’t come up). It’s an easy way to ensure there’s Just No Problem.

    -Dave

  • This is particularly critical if you’re using a modern HD video format on your camcorder, like MPEG-2 or AVC. And the care you need to apply, or the penalties for fast motion, go up as you slow the frame rate: 24p is worse than 30p, 30p is worse than 60p.. 60i is about the same, but not identical, to 30p.

    The issue is how interframe compression works. If you go back to DV, you have intraframe-encoding only… each individual frame is a separate, stand-alone compression. DV is actually just a refinement of Motion JPEG… Motion JPEG was just a (sometimes) standardized way of using individual JPEG photos as a video.

    In MPEG-2 and AVC, you have something just like that: the I-Frame (for “independent”). In both cases, this is similar to a JPEG frame: the image is broken up into blocks, those blocks are run though a discrete cosine transform (a kind of digital fourier transform), resulting in an reversible array of frequency info, not pixel info. The lossy part happens when this is filtered… depending on the degree of compression, the higher frequency information is tossed out of that block. The there’s a lossless compression (Huffmann encoding) of what’s left over.

    Ok, that gives you your first frame. The next frame, however, it based off the first. Usually, each frame will only be a little different than the previous. Each algorithm uses various means to determine motion has occurred (one reason all encoders do not produce equally good results — the job here is well defined, but the means to achieve it is left open), then encode “vectors” to store how the image moved. There’s also a difference.. the difference between that actual next frame and what the motion estimation reconstructs, that has to be stored. This is usually very small.

    When a subject moves fast, this present some challenges to the MPEG algorithms, so variable bitrate encoding can adjust to this by offering more storage for fast moving segments, less for slower moving segments. But when the whole frame moves (eg, you’re panning on a subject, versus a subject running across the visual field of a tripod-mounted camera), there’s a huge difference from frame to frame. The slower your frame rate, the more differences will occur between individual frame. And you’re getting a new I-Frame less often.

    When there’s too much of that “difference” information, the MPEG algorthms kind of fall apart. You see heavy “blocking” in fast moving MPEG… that’s the result of that “difference” information being too large. MPEG blocks occur during that lossy stage. When you toss out the high frequency information in a block, you’re basically blurring things a little, merging multiple colors into one, etc. When you have too much compression, the edges of one block no longer line up with the next, color-wise, and your eye sees the edge of the block.

    The best approach here is to shoot 24p for “cinematic” things.. fixed camera on a tripod, relatively slow motion… and go to 60i or 60p if you can for sports and other fast motion.

    When a DVD or Blu-ray is professionally mastered for a Hollywood release, the encoding engineer has tools not built-in on any camcorder. For one, he’s got time, and a human brain. For fast motion scenes, he can apply a global low-pass filter (eg, blur everything just a little), lowering the overall information in that section of the film, allowing MPEG to encode the scene without visible blocks, because there’s less information to toss out in the lossy part of the encoder.

    And of course, he can boost or cut the bitrate, at least within the limits of the format. AVCHD camcorders all record in variable bitrate, too (HDV can’t.. the tape doesn’t support variable bitrate), but there are limits.

    -Dave

  • Dave Haynie

    January 23, 2011 at 6:08 am in reply to: BluRay needs for Vegas

    USB 2.0 is just dandy for most Blu-ray needs. A USB 2.0 high speed link runs at 480Mb/s. The peak rate on a 1x Blu-ray disc is about 40Mb/s. So USB 2.0 is good enough for up to about a 10x-12x Blu-ray drive, after that, you want USB 3.0 or eSATA (there is some overhead on USB 2.0, or any serial bus, for protocol, so you don’t get the full 480Mb/s for data).

    I mention this primarily because most PCs have USB 2.0 ports. eSATA is much less common. I see USB 2.0 BD-R burners on NewEgg up to.. 12x. Lots of SATA, no boxed eSATA drive. You will pay at least twice as much for the external drive, which is kind of a rip-off, but maybe a safer bet if you’re not comfortable messing around with hardware.

    -Dave

Page 85 of 110

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy