Print

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

[cyberbeing]

I'd say another main issue of losing FFDShow is the loss of deblocking/deringing for nearly every codec LAV Video supports (except H.264 & VC1 which have in-loop deblocking).

Mainly an issue for old xvid fansubs and VP6 flash video. The VP6 issue isn't easily solved, but maybe the Xvid license allows distributing xvid.ax only for decoding of mpeg4-asp encodes?

[Mandarinka]

The good news is that Intel's new "HD Graphics 4000" Ivy Bridge integrated GPU is powerful enough to use well with madVR (according to Anandtech).  In another year or so, around when Intel Haswell is released in 2013-2014, we will probably be in a situation where all new computers have a GPU powerful enough for madVR. Though considering the goals of CCCP, Lord is likely correct that it's best to wait a little longer before strongly considering prospect of adding madVR to the pack as long as it remains 2MB+.

HD 4000 will again be present only in the most expensive models of processors (at least for desktops). Even if it weren't, are you seriously suggesting to base the general hardware target around a brand new cpu?
Come on, if there still are cursed existences stuck using socket 939 platforms and the like, just how many more are likely to be there with systems that are not as old, but 1) have IGPs weaker than HD4000/Llano (= prolly 90% of IGPs out there if not more) 2) have directx9 Radeons (no MadVR) 3) have too weak gpus (we all know the shader performance required for reliable function isn't that low). 4) have laptops - the gpu shader usage could increase heat/noise and hamper battery-mode playback a lot, even if there is an adequate gpu; though more often than not, laptops are going to be covered by 1) and 3).

The "hey this could be a problem" list for MadVR beaing set as default is quite long, and that's just stuff I can toss out of my sleeve randomly in the morning...

[cyberbeing]

Even if it weren't, are you seriously suggesting to base the general hardware target around a brand new cpu?

I never said anything of the sort, maybe you should read my post again. What I did say was a good time to consider including madVR in CCCP as a non-default option, would be when all new desktop and laptop computers on the market contain GPUs powerful enough to use with madVR effectively. [Hint: This won't occur for at least another 1-2 years]

Come on, if there still are cursed existences stuck using socket 939 platforms and the like,

What's wrong with Socket 939? I was using a circa 2005 Socket 939 computer with madVR for the past 3 years, all the way up until last month when it decided to die on me. I could also play high bitrate 10-bit 1080p encodes with madVR + xy-VSFilter, without dropped frames, using that same computer.

just how many more are likely to be there with systems that are not as old, but 1) have IGPs weaker than HD4000/Llano (= prolly 90% of IGPs out there if not more) 2) have directx9 Radeons (no MadVR) 3) have too weak gpus (we all know the shader performance required for reliable function isn't that low). 4) have laptops - the gpu shader usage could increase heat/noise and hamper battery-mode playback a lot, even if there is an adequate gpu; though more often than not, laptops are going to be covered by 1) and 3).

And why exactly does this matter? What's to stop such people from continuing to use their renderer of choice? NOTHING. CCCP is never going to force anybody to use madVR, ever. That said, at a certain point such people are going to need to accept downloading an extra 2MB for something completely useless to them.

The "hey this could be a problem" list for MadVR beaing set as default is quite long, and that's just stuff I can toss out of my sleeve randomly in the morning...

Maybe next time you should actually wake up and drink your morning coffee before posting.

[Mandarinka]

Well, but it doesn't seem CCCP is very willing to ship disabled components. And I'd say that ffdshow actually has more merit (see what I posted before) than MadVR. /Its footprint is bigger too, though, plus the "don not want" factor.../

[cyberbeing]

From an xy-VSFilter perspective, I'd actually prefer CCCP only including LAV Video since it doesn't have weird behavior related to stride, colorspace handling, and reconnection like FFDShow does. Users who desire functionality from FFDShow can install it separately, but as soon as they complain to me about FFDshow bugs, I can point them right back at CCCP.

The main benefit of CCCP, is as a simple "just works" codec pack which can be recommend when people are having playback trouble, since usually such people are not knowledgeable enough to know the recommended components to install separately. In such cases it easier to just tell someone, "Install CCCP", and avoid the hassle of troubleshooting a potentially obscure codec problem. Let you not forget that the reason why CCCP even came into existence, was because of a collective decision of fansub groups of the time who were tired of offering playback support.

FFDShow never really fit into this goal very well, considering the extensive testing which CCCP devs and their beta testers need to do, just find a version which could be considered "stable". Now that LAV Video and LAV Audio have become viable options, much of that hassle can be avoided, and any problems found at the last minute have a high chance of being quickly fixed by nevcairiel.

Though it the big picture, if Lord wants to remove FFDShow from CCCP, there is a 90% chance that that's what's going to happen unless the fansub groups who support CCCP vote against it in force. The way I see it, this was never truly up for discussion in the first place. I've yet to see Lord ever change his mind once he decides something, so anybody who really wants FFDShow included has an uphill battle to convince him. Futile effort IMHO, so I'll say out of it.

All I ask is for the next CCCP version to be designed in such a way that if a user installs FFDShow, madVR, or other decoders/splitters separately, they either never override CCCP's defaults, and/or the default configuration continues to be easily recoverable with a simple "Reset All Settings" & "Re-register Filters".

[Lord]

Though it the big picture, if Lord wants to remove FFDShow from CCCP, there is a 90% chance that that's what's going to happen unless the fansub groups who support CCCP vote against it in force. The way I see it, this was never truly up for discussion in the first place. I've yet to see Lord ever change his mind once he decides something, so anybody who really wants FFDShow included has an uphill battle to convince him. Futile effort IMHO, so I'll say out of it.

The question isn't really if we want to remove it (most agree that we do), but whether we can. In fact if you know me that much, you should also know that I'm usually on the "conservative" side and would certainly prefer some better transition.
I just stated my side that I don't want to go and start fixing it (again), unless we really must. Not to mention the related settings app mess.

All I ask is for the next CCCP version to be designed in such a way that if a user installs FFDShow, madVR, or other decoders/splitters separately, they either never override CCCP's defaults, and/or the default configuration continues to be easily recoverable with a simple "Reset All Settings" & "Re-register Filters".

We generally don't want to touch stuff not installed by the CCCP (and especially not without the explicit consent of the user), and it isn't exactly feasible either when the list of possible troublemakers is rather long. The best we could do is adding the decoders (splitters are a different kind of mess) to mpc-hc's external filters.

[cyberbeing]

We generally don't want to touch stuff not installed by the CCCP (and especially not without the explicit consent of the user), and it isn't exactly feasible either when the list of possible troublemakers is rather long. The best we could do is adding the decoders (splitters are a different kind of mess) to mpc-hc's external filters.

If it's not included with CCCP, I suspect a lot of users will still install FFDShow separately for the filters. Not a problem in and of itself, other than once FFDShow is installed on top, the user would basically no longer be using CCCP. I think it would be reasonable to disable all FFDShow Audio & Video decoders enabled by CCCP in LAV Filters when a user does "Reset All Settings" in the CCCP setting application. I'd classify that as "explicit consent" in a CCCP which doesn't include FFDShow. LAV Video would still need to be set to preferred to not run into the MPC-HC specific madVR internal decoder issues either way though. It then becomes a question if you want to offer support to users of media players other than MPC-HC, since FFDShow and its insanely high default merit would override everything else in default directshow graphs.

As far as splitters are concerned, its just as simple matter of "Reset All Settings" recreating any missing registry entries, including Media Type source filter entries, which may have been overwritten since installation of CCCP. I suspect that CCCP already does this though. One change I'd like to see is not messing with the default Windows AVI quartz.dll source filter entry. As far as AVI splitters are concerned, I've never seen an advantage of using anything but the Windows default source filter, which at least in my experience has always been the most stable.

I'm not too sure its even possible to ease a transition away from ffdshow. One possibility may be to bundle lachs0r's SMPlayer2 min_installer to fill the gap a bit, but as a non-directshow player, I'm unsure how well that would work.

[Mandarinka]

I don't think user expects CCCP to fiddle with 3rd party filters, so it shouldn't do that.

[Lord]

I think it would be reasonable to disable all FFDShow Audio & Video decoders enabled by CCCP in LAV Filters when a user does "Reset All Settings" in the CCCP setting application. I'd classify that as "explicit consent" in a CCCP which doesn't include FFDShow.

I certainly wouldn't. At least there is absolutely nothing explicit about it at all, not even a warning as is.

As far as splitters are concerned, its just as simple matter of "Reset All Settings" recreating any missing registry entries, including Media Type source filter entries, which may have been overwritten since installation of CCCP. I suspect that CCCP already does this though.

Those set the source filter, and not currently set for LAV either (due to settings app fun). Not to mention requires admin rights, and can only be set for a specific set of known extensions too.
But anyway the point was that it is just a completely different kind of mess as I said.

One change I'd like to see is not messing with the default Windows AVI quartz.dll source filter entry.

Change? When did we ever mess with it?

As far as AVI splitters are concerned, I've never seen an advantage of using anything but the Windows default source filter, which at least in my experience has always been the most stable.

You've just not encountered enough weird files then (one example is multiple audio/video tracks).

I'm not too sure its even possible to ease a transition away from ffdshow. One possibility may be to bundle lachs0r's SMPlayer2 min_installer to fill the gap a bit, but as a non-directshow player, I'm unsure how well that would work.

My current idea is still just keeping around (and supporting) the previous release too.

[cyberbeing]

I certainly wouldn't. At least there is absolutely nothing explicit about it at all, not even a warning as is.

A warning certainly wouldn't hurt, but I don't see why it's needed. If you feel more user consent is really needed, then why not add a "Disable FFDShow decoders" checkbox to both the CCCP Installer and Setting Application? Afterall, "Reset All Settings" + "Re-register Filters" should be equivalent to restoring CCCP's default playback setup. When other filters or configuration settings are causing problems, it's a useful troubleshooting step for users who aren't tech-savvy enough to detect and solve issues on their own. FFDShow is such a filter which could prevent CCCP from behaving like CCCP.

Imagine the opposite case of someone who has FFDShow installed before installing CCCP. LAV Video and Audio would be installed by CCCP, but never used outside of MPC-HC (assuming ext filters = preferred). To make matters worse, the user may not even be aware that FFDShow is overriding everything. At that point CCCP becomes useless. If there is no guarantee that installing CCCP will result in a reliable playback setup with a good set of decoders and splitters, how can it even be recommended? I honestly don't see how you could remove FFDShow from CCCP, without keeping the setting application aware of FFDShow to avoid conflicts.

Change? When did we ever mess with it?

Those set the source filter, and not currently set for LAV either (due to settings app fun).

If you haven't so far, then that's good, but it's just more of a risk to do it accidentally, now that you've migrated to LAV Splitter. When creating the next CCCP install script, just be aware that the official LAV Filters installer does get a bit overzealous overwriting source filter entries ("HKLM\SOFTWARE\Classes\Media Type" + "HKCR\Media Type"), and you should probably avoid copying its behavior as-is. Certain source filter entries can be useful, but a mass replacement is never usually a great idea. Windows default source filter entries are impossible to recover without a backup of the registry, which can be a bit of a problem after LAV Filters is uninstalled, leaving you with no working source filters whatsoever.

My current idea is still just keeping around (and supporting) the previous release too.

If that's what your thinking, maybe consider merging the single r4172 commit into the old CCCP r3996 build for at least the AC3 channel fix, and release it as Combined-Community-Codec-Pack-2011-11-11-v2.exe or some such. Possibly with a slight modification the defaults as well.

[JEEB]

A warning certainly wouldn't hurt, but I don't see why it's needed. If you feel more user consent is really needed, then why not add a "Disable FFDShow decoders" checkbox to both the CCCP Installer and Setting Application? Afterall, "Reset All Settings" + "Re-register Filters" should be equivalent to restoring CCCP's default playback setup. When other filters or configuration settings are causing problems, it's a useful troubleshooting step for users who aren't tech-savvy enough to detect and solve issues on their own. FFDShow is such a filter which could prevent CCCP from behaving like CCCP.

We already have code in the installer regarding 'badly behaving filters'. While FFDShow-tryouts isn't exactly such, it can indeed push away LAV and friends from being used. On the other hand, Lord is seemingly lately more leaning towards using the 'preferred filters' scheme rather than having CCCP as a 'proper' DirectShow package to have lusers their own setups in general (but have stuff work in MPC-HC).

Anyways, I guess the settings app and the installer code might get something to make FFDShow-tryouts less zealous in DirectShow about its position.

If you haven't so far, then that's good, but it's just more of a risk to do it accidentally, now that you've migrated to LAV Splitter. When creating the next CCCP install script, just be aware that the official LAV Filters installer does get a bit overzealous overwriting source filter entries ("HKLM\SOFTWARE\Classes\Media Type" + "HKCR\Media Type"), and you should probably avoid copying its behavior as-is.

Yes, we're the group who has kept as much of the default Windows source / splitter filters as possible as-is because random stuff likes to fail if we touch it (certain games crashing with !MS MPEG-1 Splitter is just one of the recent examples of this, AVI being another). LAV Filters themselves used to actually do this during registration before (we patched the stuff out), but thankfully that code has since been removed in upstream as well

If that's what your thinking, maybe consider merging the single r4172 commit into the old CCCP r3996 build for at least the AC3 channel fix, and release it as Combined-Community-Codec-Pack-2011-11-11-v2.exe or some such. Possibly with a slight modification the defaults as well.

Yeah, I guess a new in-the-middle build with some installer fixes, newer MPC-HC + FFDShow-tryouts with that patch put in (and possibly newer LAV Filters) could be a quick remedy for some things, but derp. I'm just not sure if Lord wants us to release anything with the old settings app.

[indivent]

Yeah, I guess a new in-the-middle build with some installer fixes, newer MPC-HC + FFDShow-tryouts with that patch put in (and possibly newer LAV Filters) could be a quick remedy for some things, but derp. I'm just not sure if Lord wants us to release anything with the old settings app.

I think the pros of doing this outweigh the cons. As long as it doesn't take too much time from the next release.

[Lord]

Afterall, "Reset All Settings" + "Re-register Filters" should be equivalent to restoring CCCP's default playback setup.

It is, and has always been. And that never included poking off stuff non-CCCP stuff.

When other filters or configuration settings are causing problems, it's a useful troubleshooting step for users who aren't tech-savvy enough to detect and solve issues on their own. FFDShow is such a filter which could prevent CCCP from behaving like CCCP.

As I said before, there is a very long list of other similar troublemakers already, and you can't reliably do much anything about it. We would need a specific tool to look for them and fix as needed, which includes maintaining the database necessary for it.

Imagine the opposite case of someone who has FFDShow installed before installing CCCP. LAV Video and Audio would be installed by CCCP, but never used outside of MPC-HC (assuming ext filters = preferred).

That's pretty much already the case on win7 FYI. And at the very least we should definitely add those to the "badfilters" list of the installer indeed.

If you haven't so far, then that's good, but it's just more of a risk to do it accidentally, now that you've migrated to LAV Splitter.

I'd like to think we're not retarded enough to "accidentally" enable such very obvious troublemakers.
Btw I did test lav splitter previously, before adding it to CCCP. Here's some related IRC log for your entertainment:

<JEEB> well, the only good'ish part is that lavf tends to work well'ish for avi and mpeg-ps
<Lord> not really
<Lord> at all
<Lord> for avi
* Lord points at clock.avi
<Lord> it screwed up much more spectacularly than I expected
<Lord> read: no audio and some nice green video
<Lord> and I only installed his splitter
<Lord> oh wait
<Lord> the color is different with each open
<Lord>
* Lord got blue now
<Lord> then black
<JEEB> lol
<Lord> yay purple
<Lord> ok now it just crashed
<Lord> probably ran out of colors

When creating the next CCCP install script, just be aware that the official LAV Filters installer does get a bit overzealous overwriting source filter entries ("HKLM\SOFTWARE\Classes\Media Type" + "HKCR\Media Type"), and you should probably avoid copying its behavior as-is.

If we weren't, you would already see the result of it with the last CCCP release.

Certain source filter entries can be useful, but a mass replacement is never usually a great idea. Windows default source filter entries are impossible to recover without a backup of the registry, which can be a bit of a problem after LAV Filters is uninstalled, leaving you with no working source filters whatsoever.

It doesn't actually replace much, and just uninstalling (or removing the related extension entries) should bring you back to more or less the previous state IIRC.

If that's what your thinking, maybe consider merging the single r4172 commit into the old CCCP r3996 build for at least the AC3 channel fix, and release it as Combined-Community-Codec-Pack-2011-11-11-v2.exe or some such. Possibly with a slight modification the defaults as well.

Yeah, I guess a new in-the-middle build with some installer fixes, newer MPC-HC + FFDShow-tryouts with that patch put in (and possibly newer LAV Filters) could be a quick remedy for some things, but derp. I'm just not sure if Lord wants us to release anything with the old settings app.

Not really, I'd personally prefer to just leave the old release alone as is and not spend any further time and effort on it. I mean, it's not like a new CCCP release should make the previous one behave any worse than it did before.

But anyway, we don't even know what we will actually have in the next release exactly at all so far. We have plans, but those things like to fall apart spectacularly when confronted with practice (read: actual testing).

[timjinn]

So, anything new happening or are you still hard at work with the settings app?

[JEEB]

So, anything new happening or are you still hard at work with the settings app?

• Settings application rewrite is actually getting some love from Myrsloik (the original creator of the NSIS-based settings application for CCCP).
• Changes for the installer have to be started sometime soon'ish to accomodate the overall bigger changes that will happen for the next release. Also, some imperfections were lately found in the installer, and I guess I should fix those soon'ish.
• Components are pretty much patched-ready until some decisions get made on the new defaults after most other things get done. Feature-wise I guess what's possibly left is the patching and (ab)use of the MPC-HC's update checking functionality to implement a version check for the CCCP.
• Movax is actually continuing work on the CCCP Insurgent troubleshooting application, and now is actually sharing sources. Separate from the actual pack so far, but it's actually nice to see new development for this application, as it is still quite useful -- even if 5 years old already.