I love WMC and I know exactly what you mean. But this is not another skin like all the others. Besides, a new TV backend is in the works, but it goes without saying that the current one can't compete with WMC.
That's a very tricky approach. I wasn't aware that there exists an HDHR proxy which implements the low-level UDP API. All those I know are just using the (newer but less capable) http API and I thought, I was the only one implementing the UDP API. Well, maybe I still am, because I don't use the provided SiliconDust lib like HDHRProxyIPTV does. I know that getting a handle on the WMC BDA filtergaph building can be difficult, because only some filter connection/selections are driven by DirectShow priorities and others are just hardcoded (internal in quartz.dll, so even manipulating the COM guids doesn't help). The only way/idea I could think of to add support for HEVC would require to intercept the filtergraph at two points: somewhere early and before the demux for modifying it to look liken H264 video stream and later some kind of decoder wrapper which pretends to do H264 but can also change to wrap an HEVC decoder if necessary. But even when it would work somehow - it probably wouldn't be a solid and stable solution..
It's a complex solution, but it works pretty well. I had no idea as well, the HDHRproxy part was Kèvin's idea. On the other hand the first solution that I found before that implies the use of DVBlink and is way simpler to configure for less expert people, and manages the EPG as well, but is a bit less rock solid in channel changes and also in case of interrupted streams for whatever reason, hdhr drivers recover the situation almost always, DVBlink does not (you need to stop and resume manually). Whatever nothing prevents to use the two ways in parallel to compare them and to have a backup solution.
How much does the transcoding to H264 add to channel switching times in both cases? (didn't know that DVBLink can transcode..)
DVBblink can transcode, and NextPVR can transcode as well, but both of them do transcode only for mobile user agent, so i used TVHeadend anyway. Would have been way simpler if the developer of Nextpvr had listened my request to add an option to always transcode (likely it required 10 lines of code given all the infrastructure is already in place), but he stubbornly refused. Whatever just read the pages I linked, we are just duplicating what was already extensively discussed For channel switching if you tune with TVH is almost instantaneous (it is pretty fast), but is not what I use, given I need Windows. I tune with Next PVR then TVH does trascoding, then dvblink OR HDHRproxy to feed WMC, so I have a bit more delay, 1/2 seconds.
Yeah, they even took my green skin for WMC to the next level, the last time I checked there were three variant (one is gray and I like it)
My suspicion is that there exist some invisible interactions between some of the filters, i.e. interactions which are not reflected by PIN connections. I wish I still was an MVP, then I could look it up in the source, but it ended quite a while ago.
WMC is relatively easy to decompile/recompile (i never did that but it's detailed at the beginning of this thread, (say may/aug 2015) this is how it was patched, for kernel policy, tv over rdp connection and so on. Sadly the guy who did this job isn't seen here since many years. I'm not a coder, but I never did that more because I'm scared by the amount of MS tools that are (usually) needed to do the simplest thing. I remember when I wanted to try the treo smarphones in an emulator, the PalmOS version was a 13MB zip, you unpacked it, clicked on the exe and nothing else. On the other hand his WindowsMobile cousin required something like a 60MB download, then visual studio, then the mobile extensions, then.... I ended downloading something like 6GB of stuff v.s. 13MB
I guess you mean the managed code implementation of the eHome components. What I'm referring to are the DirectShow components which are developed in C++/ATL.
Like I said I'm not a coder, but likely patching the program to accept whath lav codecs provides, w/o digging deeper could be viable. Think to the rdp thing, all what was needed was already there, is not like patching the rdp protocol was necessary, it was just matter of removing an artificial block, maybe there is an artificial block for codecs as well, something thought to block something else rather than HEVC that didn't exist 10/15 years ago... Remember that WMC was all about money rather than tech, protect the interest of media companies was the absolute priority.
Ah, understood, I had missed that part. The problem is in the MPEGTS splitter filter. When it doesn't know the stream descriptors and stream ids of HEVC streams, then it cannot even know that those streams are video streams and thus, it cannot provide these as video output pins. This is not something you can "unblock" in some way. It's missing implementation. That's why I said that you could only try to intercept the stream before it hits the splitter and rewrite it in a way that it looks like an H.264 stream, because that's the only way to get a video output from the splitter (and WMC adds and relies on that splitter, so you cannot easily replace it. Even if you would manage to do that, it would probably still not work due to the invisible interactions that I mentioned (which a replacement filter wouldn't provide). And the the stream re-writing (making it look like H.264) is easily said, but actually that's a hell of a job because it's not just like patching a few bits in the stream - you need to replace the stream descriptors which are different and most importantly: are of different length. This replacement can only work when the length of the end result is shorter than the input, because would have to repackage all TS packets otherwise and this is something you don't even need to think about (=insane, error-prone and likely to screw synchronization). For TVnext, we are sinking off the stream before all this happens and we get a full mux with we process manually, so we can support any existing DVB/ATSC/ISDB feature. Interestingly, the BDA reception components are quite up-to-date. They even support special new features of DVB-T2 which were introduced much later than the last WMC release (probably these things were requests by tuner hardware manufacturers). The bottom line from my perspective though, is that this is not just a matter of HEVC. WMC has dead ends in so many directions that it's not worth to invest such effort in HEVC playback. That's why I chose to invest 100 times of that effort for creating something which will really be able to serve as a replacement for WMC (I mean TVnext, not the WMC UI). Of course this will be up to everyone's own judgement - once it will be available.
Well, not my philosophy. I'm typing tight now on a (perfectly usable) turion x2 notebook built before vista, and not because I'm poor or greedy, but because i have fun getting the best of/improving what I have. WMC was released around 2004 and after 19 years I have yet to see a media center SW that is smooth and handy like it. No matter how much features it lacks that many competitors had even before it release (beyond tv had the server/client split like any modern sw, for example) On the other hand practically any SW, that was rewritten from scratch because the old one "wasn't worth to fix" turned in to failures. Say the KDE 6 is still not on par with kde 3.x from 2003 or so, the same is true for gnome 3+. Wayland was "sold" as a quick way to replace X w/o having to fix all the old cruft (after 15 years of development wayland has yet to reach the parity level, but requires beefy machines, while X can work even on 30 years old HW). Vivaldi (and that was a forced choice) took 5 years to re-implement most part of the Opera features, but it takes 20 times the storage space and the ram that Opera needed We can continue for a day, but on the debate fix v.s. new, I'm almost always for the former. That said I hope your effort goes well.
Thanks a lot, and I'll know that in case I'd be able to convince you at least half-way, then it will really be earned...