Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JustinChase]

So this came up in the Blu Ray thread, but as mentioned I was going off topic, sorry  

I think this is off-topic, but since you keep bringing it up...
{the rest of the quote is in the next post, with reply}
...so—to stay on topic—I'll conclude by saying adding Blu-ray support is almost as bad an idea as compiling a JRiver codec pack.

But is it a bad idea?

From that thread I started off topic when I originally wrote...

I haven't really stayed on top of it, (nor was I ever on top of it) but last I checked MKV's don't currently do chapters and menu's, but I think that the format does allow for it.  I could certainly be mistaken about that and/or it may have changed.

if that is correct, maybe this is an opportunity for MC to stand out.  Getting chapters and menu's and subtitles working well inside MC would be wonderful.  There's only a few options for ripping to MKV's so there can't be too much variety in what would be presented to Media Center.  Taking the known input, into a perhaps semi-custom or known working splitter to known/suggested filters and allowing the full experience of the Blu-Ray Disc from the HTPC, pre or easily configured lossless audio and video that just works would "sell-out on release date" I think.

Is there any legal downside to compiling a J River Media Center codec pack?  There must be some combination of filters and codecs that will work with most of the common formats on most current systems that could be bundled up as a codec pack.  However, with MC as the intended client.  Custom tweaked filters with known input and output chains in mind, specifically designed to work in MC.  I have no idea how hard this would be to implement, but seeing the amazing things happen over the last decade makes me think you can do it.  It seems that it might actually be harder to make all of the options available and getting all that to connect and work well with all the different possible combinations than it would be to just "fix" a system that almost works and just concentrate in keeping that working and updated and improved.

I'm assuming you couldn't just implement them with the MC install to make sure everything installs perfectly, but that would be even better.

Doing that well, and maybe working out something with one or all of the ripping developers to suggest their product if they can present a file with some things the way you need them for this to all work well.  Everyone wins.

Just thinking out loud

I received this answer

Just an FYI, MKV does chapter support just fine now with the latest Haali.  Menus are still not supported, however, and that's a very big ball of yarn to untangle.  Most BD menus are done in BD-J, so, it's not a simple thing of "ripping the menu" and "adding it to an MKV".  At the present time of this writing, you won't find any open source, non-commercial player that supports BD menus.  Yes, I know that support is being worked on by at least 2 groups.  However, it's going to be a long, involved process.

and it looked like a big opportunity for MC to expand its user base, if they could get this working sooner than anyone else, or at least implement the solution quickly if/when someone else does it, with MC as the player (Maybe a free video jukebox for just videos?)

This was in a discussion about the lengthy AACS LA license requirements...

...BTW, did I mention the work necessary to create the video and audio codecs?  Those aren't provided.  As an AACS LA licensee, you get the spec.  You're on your own as to how to implement it.  That's 3 video codecs (already handled so no problem there) and 3 audio codecs.  DTS-HD MA being the most obvious one that would need to be written from scratch.  I think TrueHD could be handled by what's already out there depending on how the license is written.  Otherwise they may be forced to write their own codec for it.  Awesome....

But it also points out that there are 3 video codecs and 3 audio codecs that need to be dealt with, and 5 of them are likely handled.  That's great, but how exactly is that happening?  I don't think CCCP is making that happen by simply installing it after Media Center is installed, with no tweaking or settings needing to be adjusted somewhere.  At least it certainly didn't work that way for me.  Some combination of CCCP and ffdshow, or maybe ffdshow tryouts, and which splitter to use, which one offers chapters, which version, oh wait that only works with MCP if you change this setting to stun and which widget needs to be turned West for DXVA processing; unless you have an nVidia card...  It's all too much for the casual user to bother with.  

For example, Matt commented in a thread about bitstreaming Dolby TrueHD and DTS-HD...

I gave MakeMKV a spin.

It took 40 minutes to make an MKV.  I have the original LG HD-DVD / Bluray combo drive, with a machine that benchmarks around ~2600 with Media Center.

The resulting MKV played without much drama.  CPU usage was 1% with MPC video decoder and 8% with ffdshow video decoder.  Both decoders looked good and provided correct lip-sync.

I do analog audio output to a power amp, so I'm not trying to bitstream.  But ASIO, Room Correction, and other JRiver audio goodness worked fine.  Since this was a DTS Blu-ray, I don't think I'm getting the full quality analog decode.

My system always wants to use Haali as the source filter.  I couldn't get MPC to stick.  But since Haali worked fine, I don't think this is an issue.

The ease of this approach makes we wonder if JRiver should focus solely on playback of Bluray in MKV format, and just work to make it as easy and feature rich as possible.  We would leave it up to users to get the MKV files.  We would worry about playing, tagging, getting metadata, and providing access from the couch.

As you can see, there is some disparity in what works how...

• CPU usage was 1% with MPC video decoder and 8% with ffdshow video decoder
• Since this was a DTS Blu-ray, I don't think I'm getting the full quality analog decode
• My system always wants to use Haali as the source filter.  I couldn't get MPC to stick
• The ease of this approach...

If this is easy... ?

The great news in that was that Matt is in agreement that "... JRiver should focus solely on playback of Bluray in MKV format, and just work to make it as easy and feature rich as possible.  We would leave it up to users to get the MKV files.  We would worry about playing, tagging, getting metadata, and providing access from the couch."

PERFECT!!

MKV seems the most likely choice, and would be a great first step to conquer.  Get the basics worked out, maybe devote some time to research and perhaps tackle DTS-HD MA processing.  Eventually focus on getting menu's to work.  Someone dedicated to this, with access to the inner workings of Media Center should be able to put together a combination of things that provides processing of lossless audio and video with subtitles and chapters and generally faultless playback where possible, but step down as hardware capabilities necessitate.  

How many different places can this content come from?  ISO's, commercial rippers and torrents; I don't know where else.  there can't be that much variety in the input MC is likely to encounter.   from here, MC automatically puts together the "best" known working chain to output the highest quality available to it.

Even when this is accomplished, it's a moving target.  What is the good solution today will be replaced soon enough by a better one.  I don't want to search various forums and threads for information on which codec or filter or settings or combinations handle the playback of the latest media file, whether it's CD or DVD or HD-DVD or Blu Ray or whatever 3D video format comes next, or FLAC or whatever.  I don't want to have to keep track of when chapters start working well, or how to make that work, or when menu's become available in MKV files.  I like all this stuff, but it's a part time job keeping up with it.  Most of us that are trying to keep up with it do so because we like it, but Joe Public will never read Doom9 or AVS Forums or makemkv.com or whatever is current.  They will end up with a hi-def version of a file thru a limited set of circumstances, and just want to hit play and have it work, as good as possible, with little/no setup.

I know Media Center does a great job of playing back pretty much anything, and the customization options are outstanding, but putting together a package that is known to work, and is updated regularly would be a big benefit to users.  I think anyway.

[JustinChase]

{the missing part of the quote above}

I'm not sure if you're thinking of BD ripped to MKV and limited variations of what may be found in the resulting files, but most of us expect our media player to be able to play any video file (within reason).

That's what I'm referring to, and I also expect faultless playback of all my media, but there isn't that much "weird/obscure" stuff that I have that would need to be added to the proposal above.  I certainly don't think everything in the CCCP is needed to playback *most* media that MC will run across.  And anyone having anything that exotic likely knows what needs done to play it back correctly, this isn't necessarily for them, it's for my Mother, who knows how to install programs and follow directions, but doesn't ever want to deal with learning about codecs and filters and playback modes and flushing buffers and renderers and splitters.

That's why CCCP or some reputable codec pack is recommended. It seems those who compile these things put a lot of effort into finding a combinations of codecs that will work together properly in most circumstances. The result has to not just handle various content, but do so with the resources available.

recommended by many users, but there are other recommendations, and I'm not sure if J River oficially recommends CCCP or any other codec pack.  I know they have in various posts, but also ffdshow, and Haali, and Matroska, and I can't remember what else.  and again, a user needs to research to find all this.  These codec packs also need to work with various players, which adds bloat, and required customizations and settings.

What you need to play a particular file may be different from what I need.

Really?  A file needs the right software to playback, but it also needs the right settings to play it back as cleanly and with the least amount of processing possible.  playing a file in MC in your machine will be similar to playing it back in my machine.  Any differences can be dealt with by MC by knowing what hardware you have, which I believe it can get from your system info, or by a setup dialog or wizard.  Then it can compensate for any shortcomings I have in capabilities.  For example, I don't have a sound or video card capable of bitstreaming HD audio, but have digital optical out, MC can set the options to give that output the best possible output available.  It could pick the correct audio stream, based on this info, automatically.  It can only do this if it knows what all the software parts are, and can adjust them.  MC can/should still allow the user to customize if they want, but outta the box, it could be much easier.

So I'm not sure how using MC changes this in any way that isn't already taken care of by the MC configuration (e.g., it can handle audio in a different and better way—and it will do so if asked). So I don't see what it is that MC might do in this area—other than try to make the program easier to use and provide support in what is necessarily a complicated matter.

Using MC takes away the variables required for other players.  Yes, MC allows you to customize the playback options and filters and splitters and so forth, but who really *wants* to bother with that?  some certainly do, and more power to them, but I would much prefer to have those hours of researching and experimenting to spend on other stuff.  True, it's not that often changes need to be made, but still, I'll happily pay $10 more for renewal to not have to deal with all that, and just let MC do as you say, "try to make the program easier to use and provide support"

As I said above, if this can just be hard-coded into Media Center and avoid another install and/or codec pack, fantastic, but I'm guessing that's not gonna happen, so a maintained codec pack it is

[rick.ca]

That's what I'm referring to, and I also expect faultless playback of all my media, but there isn't that much "weird/obscure" stuff that I have that would need to be added to the proposal above.  I certainly don't think everything in the CCCP is needed to playback *most* media that MC will run across.

Neither of us have the technical background to be discussing whether JRiver can do a better job of it than something like CCCP. My comment is based solely on my understanding that the very purpose of CCCP (and other similar codec packs) is to address the need you're talking about. I think your assumption CCCP is bloated with things for handling obscure stuff, and JRiver could do a better job creating something "just for the stuff MC users need" is unfounded. I don't think the requirements of an MC user are any different than the user of any other player that relies on system codecs to play videos. Even if CCCP does include components rarely needed by anyone, I don't see why this should be of any concern.

I'm not sure if J River oficially recommends CCCP or any other codec pack.  I know they have in various posts, but also ffdshow, and Haali, and Matroska, and I can't remember what else.  and again, a user needs to research to find all this.

I don't know why they would "officially" recommend anything, but they regularly suggest users try CCCP when they're having difficulty playing videos. Ffdshow, Haali and Matroska are not codec packs. Versions of ffdshow and Haali are included in CCCP. Matroska is a container. Again, one of the fundamental advantages of using a codec pack is it eliminates a lot of research that would otherwise be required.

These codec packs also need to work with various players, which adds bloat, and required customizations and settings.

I don't think so. Players either use their own codecs, or they use DirectShow. The latter, like MC, therefore need to be configured in how they do that. The codecs themselves have settings (some have many), but this has nothing to do with what player is used. CCCP has settings clearly intended to make it easier to configure the entire codec pack. In other words, most users will only need to consider adjusting the relatively few CCCP settings, and then the whole thing will just work.

Really? A file needs the right software to playback, but it also needs the right settings to play it back as cleanly and with the least amount of processing possible.  playing a file in MC in your machine will be similar to playing it back in my machine.

I don't think so. Not everyone uses CoreAVC. And even if MC could detect that I want to output audio over SPDIF, it doesn't know what the capabilities of the receiver on the other end are, or that I need to use AC3Filter to manage that connection. And that's just one zone. But this is not obscure geeky stuff—it's commonplace. Yet my requirements are completely different from yours, and not something that can be automatically configured using some magic MC codec pack.

The great news in that was that Matt is in agreement that "... JRiver should focus solely on playback of Bluray in MKV format, and just work to make it as easy and feature rich as possible.  We would leave it up to users to get the MKV files.  We would worry about playing, tagging, getting metadata, and providing access from the couch."

My interpretation of Matt's comments was that whatever obstacles or shortcomings currently exist in playing MKV Blu-ray rips could be overcome. He did not say anything about creating a filter for doing so. Also, I may be wrong, but I assume "chapter support" in a player context simply involves reading chapter information saved in the container and using that to control playback. Also, it hasn't been discussed, but Matroska includes a specification for saving meta data in the container. This might also be supported. None of this suggests to me JRiver should or intends to write filters or create codec packs for handling Blu-ray content.

[JimH]

Is there any legal downside to compiling a J River Media Center codec pack?

It's a gray area and one we won't attempt. 

[JustinChase]

I don't have the time or energy to counter every point, so I will summarize.

You are right that neither of us can say whether or not MC could do a better job with a codec pack, but I think you're missing the whole point.

MC doesn't just work right now, not for high quality audio and video.  Something else must be installed for that to happen.  Why does Joe Public have to read forums to find out that J River suggests you install CCCP, or Haali, or anything else?

Even if they do that research, installing CCCP, or any codec pack doesn't just work.  it needs configured.  It needs an updated version of ffdshow to get chapter support.  It might need an updated filter or renderer, and some work well with some players, but not with others.  A solution today may not be the best solution tomorrow.  Why does Joe Public need to follow all the options and go look for updates to get the best playback possible?  I can tell you right now; they won't.

My suggestion is that with access to the inner workings of MC, much/all of this could be resolved, and a "just works" solution could be made available to users of MC, suggested to them by the makers, at the time of purchase or install, and updates could be suggested to them as they are now with the program.

You suggest that just installing CCCP (a codec pack) is an acceptable solution, but that MC developing one specifically for MC is a bad solution.  I just don't follow that logic.

Yes, you have CoreAVC installed, so you process different than I do; but that's 2 options, with or without CoreAVC installed, certainly a manageable difference I would think.  I prefer to have my video card process via DXVA, which adds more complexity, but not that much I would argue.  it isn't hard to determine that my sound card is capable of this, do I want to use it?  yes/no.  the trick is, which codec, filter and renderer will process without issue?  that's where Joe Public has problems.  if MC spent the time to just "figure it out" and released a known working solution, everyone wins, don't they?

You clearly think this is a bad idea, but I fail to understand why.  Because there are options a geek can already figure out, so why bother?  this isn't a valid reason not to do as I suggest; not as far as I'm concerned.

if you think it will take too much time away from development of other stuff; okay, but if it takes the developer of the program too much time to bother with, what about my Mother?  She doesn't stand a chance of getting it working well.

MC has always been a hobbiest program, used mainly by computer geeks.  I think ONE person I have recommended it to has purchased, and everyone else has told me it's just too much for them.  That's a LOT of sales that don't get made.  Making it easier to use would increase sales; no doubt in my mind.

How is MC putting together a known working solution, which makes it easier to use, a bad thing?

[JustinChase]

It's a gray area and one we won't attempt. 

I can certainly appreciate that.  is that also the case for a stand-alone "product", not included with Media Center?  I figured building all this inside MC was not an option, but don't know about a separate program/pack.

if so, this is all for naught, which is too bad.  Joe Public will never figure all this out on their own

[HiFiTubes]

There is a lot of validity to what you are saying. I love to suggest MC to people who mainly seem to be interested in home theater and video.

What about the box MC sells? Is it configured for mkv etc? My in-laws would still have trouble with the Boxee box so the market you speak really does still need some form of hand-holding; if you are the geek of the family...kiss your free time good-bye.

This discussion mirrors the audio setup thread. I really have to make time to video setup because it really does take a bit of attention and experimentation even after things seem to be set up correctly.

[Vocalpoint]

It's a gray area and one we won't attempt.  

How about a huge "ongoing" sticky at the top of the forum (called What We Use) or a definitive guide in the wiki stating the actual preferences/components you (the dev team) use to test in-house? Certainly there must be a standard combination of items that are always set when you guys want to test MKV (or whatever) functionality for a new build?

This would be a much better start than flailing around installing a pile of codec packs to see what sticks. For what it's worth - I finally just bought CoreAVC and my MKV troubles are now over...but there are hundreds of others out there.....

Cheers!

VP

[fitbrit]

I like the sticky idea as a start.

CCCP just doesn't cut it for the latest in video (mkv) files. Shark's codec pack is better, but really just a few codecs/filters are pretty much all you need. I think things may improve in a little while as some of the mkv splitters sort out bugs.

[Matt]

For example, Matt commented in a thread about bitstreaming Dolby TrueHD and DTS-HD...

As you can see, there is some disparity in what works how...

• CPU usage was 1% with MPC video decoder and 8% with ffdshow video decoder
• Since this was a DTS Blu-ray, I don't think I'm getting the full quality analog decode
• My system always wants to use Haali as the source filter.  I couldn't get MPC to stick
• The ease of this approach...

If this is easy... ?

It's easy as in "I can see the light at the end of the tunnel."  For high-end users, it works now.  With a little work on our end, it could work well for most users with little configuration.

Part of the problem is that we're talking about features at the bleeding edge of the industry.  Support for these formats and features just aren't always available in commonly used decoders, splitters, etc. yet.  I believe this will get better with time.

It would help if there was a consensus about the best filters for MKV Blu-ray playback.  This would allow us to auto-preference the best filters.  Suggestions would be welcome on this front.  Haali as the splitter and FFDShow as the audio and video decoders worked well for me.

[fitbrit]

It would help if there was a consensus about the best filters for MKV Blu-ray playback.  This would allow us to auto-preference the best filters.  Suggestions would be welcome on this front.  Haali as the splitter and FFDShow as the audio and video decoders worked well for me.

It may work for you because you don't have mkv files that it fails on, or you have no need to bitstream HD audio formats. This is the problem with MC15's interface of choosing filters based on filetype, rather than codec. As you know MKV files can hold all sorts of stuff. So it doesn't make sense that MC has to try and use the same filters for plain 480p AC3, non DXVA compliant DVD-rip file and one that is DXVA compatible, 1080p DTS-HD MA BluRay rip. Progress made in ffdshow suggests we're almost there, but then the splitters present problems.

Right now, I suspect that the only way to get hardware accelerated  high bit-rate h264 mkv playback, with bitstreaming of DTS-HD MA, and subtitles in MC15, is to use the nVidia gt460 cards with CUDA support (using CoreAVC), MPC's Matroska splitter and ffdshow. This is because subtitles break the requirements for DXVA unless EVR custom presenter is used as a renderer, or MC15 has its own internal subtitle renderer that is DXVA compatible. CUDA acceleration does not have the same requirements of the video chain as DXVA. Hopefully, nVidia will come out with lower power video cards (suited more to HTPC than gaming) that can bitstream HD audio soon.
I say suspect, because I've seen nVidia's CUDA acceleration work very well with CoreAVC in MC15, with no issues with subtitles. I assume that no new issues will be raised by bitstreaming the HD audio codecs as well, which is a new feature of the gt460.
BTW, if the nvidia card does work with the combo above, it should work for all mkv files, as far as I can tell. If Haali and SMM splitters fix a few issues, it could offer us a further choice.

[rick.ca]

How is MC putting together a known working solution, which makes it easier to use, a bad thing?

I knew the point was mute from the beginning (as Jim has now confirmed), but I thought you might appreciate an explanation. There is no one known working solution. So it's not that the idea is bad—it's that it's not feasible and therefore irrelevant. There are positive things JRiver and the user community can do to help, but a JRiver codec pack is a red herring. In that context, it is a bad thing.