Print

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

[JEEB]

Some general info on what's been more or less put on the table:

• Removal of FFDShow-tryouts
  
  • S/PDIF users will have to look for something else as the capability to encode !(AC3 or DTS) >2ch stuff to AC3. AC3Filter and Reclock mentioned as alternatives.
  • We lose the audio mixer. Generally the Windows mixer should work for this. Nevcairiel has said that he has plans on implementing certain types of mixing in LAV Audio via libswresample or libavresample, as both are now in ffmpeg.
  • Video filters are lost, some people will whine.
• Video and audio decoding left to LAV by default.
  
  • Was already partially in the last release (the H.264 decoder check-box), but now it'll be taking over in a more grandiose way.
• Switch away from MPC-HC's VSFilter to xy-VSFilter (?).
• Switch away from Gabest's lol-old MPEG-2 decoder to a low-merit, MPEG-2-only customized LAV Video (?).
• Rewrite the settings app completely or partially to make it less herpy derpy.
  
  • Separate HKLM/HKCU parts and remove a lot of the fugly things that have stuck since it was first made circa 2005.
  • Working on this (to a lesser or larger extent): Me, Myrsloik, Kovensky, Lord
  • Original idea was to use Inno, in the end it will either end up that -- or Lord just stabs the NSIS code base. Kovensky has also been looking into Qt as making interfaces in it is much less of an effort.

<Insert here a sarcastic remark from Lord on how we'll never get anything done on the last point>

Most of the components' patches are up-to-date (plus upstream projects have merged some things they have deemed useful, thus bringing the amount of patches down from the last release), and regarding the components it's mostly just some settings that could be tweaked. The real problem currently is the need for update in the general "backbone" part of the package.

Also, we welcome people to go around the CCCP wiki, and propose edits (the wiki is badly out-of-date at many places, plenty of stuff to poke at ). I still haven't gotten to setting up a proper anti-spam measure for the wiki, so all registered users will just have to be given separate access to the editing functionality (I swear I'll do something about this). Until the spam problem has been dealt with, write rights will be given out to people who post some useful edits that can be applied on the wiki (I will probably open a separate thread for the wiki edits tomorrow (today) in the morning, to keep this thread related to the changes for the next CCCP release(s)).

[emptyeighty]

Hm.. imo change components one by one, not in all in one release. There are bound to be problems that go unnoticed with changes this big. Makes narrowing a problem down harder if more things changed.

[Mandarinka]

Shouldn't tryouts stay around at least for 1 more round at the slightest, before being completely dumped? I know LAV video has been added in last release already, I think that making it default is fine (especially since it seems that swscale will be stuck with that slightly wrong 10-bit conversion forever). However, to have it as only decoder at the same time isn't exactly conservative to put it diplomatically.

I use grab, OSD (for special purposes naturally), and software scaling. There are probably numerous people who use deband. While I consider postprocessing like deblock/dering to be generally bad, in general the filtering functionality is quite useful - it should at least be enable-able imho (for example through settling ffdshow to process raw video - it would be actually ideal if the setting application was able to do that /idea).
(Edit: oh and the avisynth module is rather useful when you want filtering that isn't really available in video players - derainbowing, ivtc, chromashift come to mind.)
That being said, I can certainly install everything myself instead of relying on CCCP. But I believe it is a valid reason to keep ffdshow

P.S. Last week, I actually ran into some issue in LAV video that would make it crash (EDIT - wait, I think it was actually that LAV Video would introduce a crash in ffdshow somehow) when outputting rgb32 on one PC... I forgot what it was exactly, sadly. But I'll leave it here as an anecdotal evidence that ffdshow might not be deserving to be completely thrown under the bus just yet.

Last but not least, thanks for maintaining/developing this thing.

[zer0]

Perhaps you could keep FFDshow around one last time but not have it be the default (that would be LAV). In the new settings have a switch for using FFDshow instead of LAV? I personally don't mind if you switch to LAV cause I don't think I use anything that requires it but Mandarinka makes a good point.

[gommorah]

I'll throw in a vote to keep FFDShow around, even if it's not the default decoder. I personally use the resize filter in FFDShow for SD content or else the subs are just eye cancer. Unless LAV has gained the ability to resize its video output recently or there's a guide somewhere telling me how to feed LAV output into FFDShow for filtering.

[zer0]

As a side note, is MadVR a viable option for the next release? I haven't tried it out yet but I have seen some positive opinions on it in this forum and other places so was curious.

[Mandarinka]

With MadVR, there is still the problem of having it reliably work out of the box for everyone. It definitely can't be used as a default, because too many GPUs are just insufficient.

[cyberbeing]

If xy-VSFilter is going to be included, I think madVR should at least have a non-default check-box in the CCCP settings application to enable/disable it in MPC-HC if installed. The question of if madVR should be bundled with CCCP w/o internal libav decoder dll, is something I have no opinion on at the moment. It could work either way, I just think it should be detected and have a check-box in the setting application.

[JEEB]

If xy-VSFilter is going to be included, I think madVR should at least have a non-default check-box in the CCCP settings application to enable/disable it in MPC-HC if installed. The question of if madVR should be bundled with CCCP w/o internal libav decoder dll, is something I have no opinion on at the moment. It could work either way, I just think it should be detected and have a check-box in the setting application.

xy-VSFilter will be a replacement for the MPC-HC VSFilter as far as I see it right now, not an alternative. As for MadVR, we already have users go to the View->Options->Playback->Output menu to pick their preferred renderer, and as MadVR still isn't exactly a "works everywhere" kind of thing I'd still stay wary of adding it to the settings app .

If we end up ever making enough automation in there to make it all feasible, sure (although in this case it would mostly be a case of setting some kind of default). We even thought about a renderer tester kind of app during last year, but I'm not exactly seeing it going to happen soon (comparison of outputs to a certain sample rendering, and having the usual fail cases such as mismatched levels etc. around to make the user a nice report and a workable default).

[cyberbeing]

The main dilemma is that a lot of users of xy-VSFilter use or at least try out using madVR, but rather than madVR not being a "works everywhere kind of thing", the problem for CCCP is more that madVR's internal decoders (enabled by default) override CCCP's decoder choices and prevent VSFilter from loading on Win7 w/ MPC-HC. At the very least, you should consider setting LAV Video to "prefer" in MPC-HC external filters, or take other countermeasures to prevent that from happening.

[Lenmaer]

I would ask you to make an updated version of the current CCCP first while waiting for the next final version.
So at least fansub groups release format would be unified again, as some already made the move to xy-vsfilter and others not, and leechers wouldn't be troubled with heavy typesettings and lags.

[Lord]

Hm.. imo change components one by one, not in all in one release. There are bound to be problems that go unnoticed with changes this big. Makes narrowing a problem down harder if more things changed.

That's certainly a concern, but we could just tackle that by leaving the previous release around for a while.

Shouldn't tryouts stay around at least for 1 more round at the slightest, before being completely dumped?

Perhaps you could keep FFDshow around one last time but not have it be the default (that would be LAV).

I'll throw in a vote to keep FFDShow around, even if it's not the default decoder.

It is way too large, bloated, and broken to just include in a disabled state.

In the new settings have a switch for using FFDshow instead of LAV?

Hell no, thank you. I can easily count for you how many would bother to add support for that for just one release. CCCP was never supposed to have more than one component that does the same thing to begin with.

or there's a guide somewhere telling me how to feed LAV output into FFDShow for filtering.

Poke the "Raw video" line under Codecs in the decoder config, or just use the "ffdshow raw video filter" which exists exactly for that purpose.

As a side note, is MadVR a viable option for the next release? I haven't tried it out yet but I have seen some positive opinions on it in this forum and other places so was curious.

It's quite large to add (especially its config app) for the two users or so that would actually benefit from it, otherwise maybe.

[cyberbeing]

It's quite large to add (especially its config app)

LZMA compressed size:

MPC-HC: ~3.3MB
LAV Filters: ~3.1MB
Haali: ~700KB
xy-VSFilter: ~420KB
madVR: ~1.94MB
ffdshow: ~3.8MB

CCCP w/o madVR & ffdshow = ~7.5MB

CCCP w/ madVR, w/o ffdshow = ~9.44MB (around +25% increase)

CCCP w/o madVR, w/ ffdshow = ~11.3MB (around +50% increase)

CCCP w/ madVR & ffdshow = ~13.3MB (around +77% increase)

Even though 1.94MB for madVR isn't significant in this age of broadband, I assume Lord is concerned with how it would increase CCCP's pack size by +25%, especially now that he is removing ffdshow to reduce bloat. 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+.

[zer0]

I understand not having redundant components and seeing as I already check the LAV decoder box in settings for H264 I don't mind if you guys get rid of FFdshow. The madVR thing was more of curiosity on my part (I am in the middle of getting parts for a new desktop so I can't try it out for a little bit but once I am set up I will give it a whirl).

Even though Intel HD Video 4000 seems to be a pretty decent integrated chip, it did only come out like a week ago so not many people will have it available to use. I can understand Lord and Jeeb's concerns with adding MadVR. Not like we can't download it and try it out on our own either. Also, while file size doesn't really bother some of us (praise God I have Fios) there are a lot of people who don't have decent broadband or have caps to deal with it so I can see the rationale behind keeping the pack from getting bloated.

I do however think xy-vsfilter should be included in the next update. I have kept tabs on the threads in this section of the forums and seems like it does help out people with older hardware and perform better than current version. I remember a core 2 quad I had around with an nvidia graphics card sounding like it was about to lift off from every fan kicking up and stuttering on a 1080p bluray rip with subs (if I remember right it was the unlimited blade works movie, terrible by the way.)

As a side note, I would like to say thanks to all you devs that post here and work on CCCP/related projects. Not everyone takes the time to discuss the course for future updates of apps/projects with the users.

[Lord]

I do however think xy-vsfilter should be included in the next update.

That's the plan, as JEEB said above, as long as it doesn't turn out to be too broken during testing.

The main issue with removing tryout is some of the filters that can come in handy working around broken drivers/files/etc. in some cases. The most interesting one is (again as mentioned by JEEB) the mixer, the only one we actually enable by default right now. Resample was useful with those broken matroska AAC muxes that decoded to 96 KHz audio (and made some sound cards/drivers scream), volume is nice with streams that have insanely low volume levels (in some or all of the channels), and the resize filter can help with non-mod4 video and drivers (and sometimes filters, ahem vsfilter) that fail them hard.