- what are the advantages of PCM over bitsteaming HD audio? Other than the MC features mentioned at the wiki's "Audio Connection Type", there's nothing there to conclude any upside while my AVR is equally equipped and I'm not having problems. Granted, not all are, but it seems to be an inappropriate assumption for JR to believe MC+Ro is all that's needed ...
- Most AVRs allow for checking the audio throughput for knowing what's going on ... is there anything similar with MC16+RO?
- RO came to my installation (build 97) configured as the default, and broke my setup until I disabled it and reconfigured for bitreaming. IMO, RO should still be in beta, let alone not be the default ... which isn't to say it shouldn't eventually become the default ...
- Correct me if I'm wrong, but there should be a single-click option for selecting bitstreaming over PCM. That is, selecting the option to 'bitstream' over 'PCM' should disable RO, should it not? Similarly, to enable 'PCM' should also allow RO(?) Regarding 99 not working, if RO is disabled, it seems that there must be something else that should also be disabled (?)
Bitstreaming works
fine on my HTPC with Red October turned ON (AMD Radeon HD 6870 HDMI out to a Denon AVR, Catalyst 11.3 drivers). They are designed to work together. If turning on Red October breaks bitstreaming on your system, that is a bug that they need to address (one of many right now). They will probably need more information on your specific setup so that they can track down the problem. They are absolutely NOT intended to be mutually exclusive. The "one switch" idea you are looking for is intended to be
Options -> Video -> Audio for Video -> Connection Type. You will likely also need to set the Playback Device in the same section to point explicitly to your audio device, and not "Same as Audio".
Jim admitted that this build was made public "probably too soon". They do have an issue that it is hard to get good reports of what is working and what isn't unless you release it to the wider community. There were still issues reported in the Beta builds with the system, but as of build 97 it did seem to work for most of us with the most common media types (and a variety of different audio setups, both bitstreaming and non-bitstreaming). However, most of us on the Beta Team are fairly sophisticated users, which means there is a somewhat limited range of testable systems (for example, a very high percentage of us are all on Windows 7, for much the same reasons that we are on the Beta Team for MC). It is a bit of a chicken and an egg scenario... But, the
entire point of RO is that it is intended to be on by default to address
these types of concerns.
Lastly, since you asked... The main benefit (as I see it) to decoding to PCM on the PC rather than bitstreaming is that you can do the "VideoClock trick". I might get a few of these details slightly wrong, but the gist is correct... The problem this is designed to solve is "judder". When you are watching a video, if the refresh rate of the monitor doesn't exactly match (or is a clear multiple of) the frame rate of the video, the system cannot actually play the video frames timed correctly. It has to do one of two basic things: drop (or replicate) frames of video occasionally or slightly speed/slow the audio to make up for the slightly inaccurate framerate. When audio playback happens normally on a PC, the "master clock" that everything is slaved to is typically the audio device's clock, because it is historically the most accurate clock in the system, and when you are bitstreaming audio, of course, the PC doesn't actually control the timing of the audio.
In NTSC-land this often isn't a big deal (if you aren't a stickler for perfection), because the refresh rate of our monitors is typically near 60Hz (or a multiple of that, preferably 120Hz), and NTSC video is 29.97 fps, which is pretty close to 30, which divides into 60 just fine. "Film sources" are more troublesome, which is why 120Hz monitors are nice, because 24 goes into 120 cleanly, but there is a fairly decent "pulldown pattern" already established to handle conversion from 24p->60Hz. They've been dealing with this in broadcast television for years and years, after all. The trouble REALLY begins if you are in PAL-land. Those poor people have 50 and 100Hz monitors, and are forced by the dominance of American media companies to often deal with 30/60 content, and if they actually have a 24p source (and not one artificially sped up to 25p), the pulldown pattern for 24p -> 50Hz is VERY ugly. You can't really solve the "big" pulldown problem without repeating frames or running your monitor at a clear multiple of the video framerate (so 24p on a 60Hz monitor is never going to look "right"). But, if you are simply playing a 30p "source" on a 60Hz monitor, or a 24p source on a 24Hz (or 120Hz) monitor, it should look "mostly" right because no pulldown pattern is required.
In reality, it isn't so simple, because your monitor isn't actually 60 or 120Hz, it is something like 59.9765423Hz; and the NTSC frame rate isn't 30, it is 29.97, and "24p" rate is 23.976 really. All of these are "close enough" for most people to not even notice the difference. However, even in NTSC-land playing "30p" video, the difference between 29.97fps and whatever random 59.99625488 refresh rate your monitor happens to be running at, slowly builds up over time. Eventually, the video gets to be "ahead" of the audio by around a full frame. So, the normal "DirectShow method" used by most filters is to occasionally drop frames of video to keep the audio and video in sync.
So, the "other way" to solve this problem is to dynamically scale the speed of the audio playback and guarantee that every frame of video will play for the "same" amount of time on-screen. So, essentially you are "slaving" the playback to the monitor's refresh rate rather than the audio hardware's clock. That's what the "ReClock" filter for DirectShow does, and that's what the "VideoClock" feature of MC does. It smooths out the video by dynamically scaling the audio of a file, on the fly, rather than adding and dropping frames of video. But, to do it's magic, you can't bitstream because then MC can't control the audio playback at all.*
There are some other benefits to decoding to PCM (mainly that you can do DSP-magic on the audio stream in MC, which may be more powerful than what you have in your receiver), but if you have a nice-quality receiver this may be of lesser importance to you.
EDIT: I edited the above a few times trying to make it more clear. I think it is pretty good now.
* Technically, you CAN bitstream even in this scenario, but not in the way that most people mean when they say "bitstreaming". MC has to have access to the raw, decoded PCM data in order to do the VideoClock magic. It can, then, bitstream this result out via HDMI (or SPDIF) but you will not be getting the pristine unaltered source audio streamed, and your receiver won't light up the "DTS-MA" light on its display. Instead of bitstreaming DTS-MA or Dolby TrueHD, it will typically be bitstreaming PCM audio over the HDMI (or maybe re-encoding it to AC3 and bitstreaming that if you use a SPDIF connection).
Author
Topic: Video Problems Go Here (and a status report) (Read 8021 times)