SageTV Community

SageTV Community (http://forums.sagetv.com/forums/index.php)
-   SageTV Github Development (http://forums.sagetv.com/forums/forumdisplay.php?f=53)
-   -   VS2017 64Bit Build (http://forums.sagetv.com/forums/showthread.php?t=65147)

bryanzim 10-31-2017 08:36 AM

VS2017 64Bit Build
 
So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

JustFred 10-31-2017 03:21 PM

".. And The Heavens Rejoice .."

Well, at the very least, I'm certainly happy to see this.

Q1: I'm assuming that once they're pulled into the repo, all the .sln and .vcxproj files will be updated for the 64-bit build. Can developers continue to use VS2015, or will VS2017 be required at that point?

Q2: Will it still be possible to build 32-bit binaries? Is this the end of the road for 32-bit and/or XP? Personally, I won't shed any tears for the loss of either of them, but others may feel differently.

tmiranda 10-31-2017 03:33 PM

Quote:

Originally Posted by bryanzim (Post 611676)
So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

My hero :)

I was working on it but there were sooooo many errors and warnings I never made it through them all.

You can use the jar from the linux build.

jusjoken 10-31-2017 07:57 PM

Quote:

Originally Posted by bryanzim (Post 611676)
So I had a little bit of time and wanted to take a stab again and producing a 64 bit version of SageTV. I have a completely compiling source tree except for third_party\SageTV-LPGL\Pushreader. A 64 bit version of this library is needed for successful build of the solution.

I was unable to compile with MinGW for lack of a config.h file in the third_party\ffmpeg folder.

Does anyone have any ideas about this and maybe it should be looked into to update ffmpeg also?

Will also need a 64 bit build of the jar files. I am using the 8.0.1620.1 JDK.

Another developer very interested. I am assuming the installer would also need some work to support both.

Let me know when you are ready to share and i will help out with the installer side... sorry i cannot help with the questions.

k

wayner 11-01-2017 06:07 AM

Quote:

Originally Posted by JustFred (Post 611687)
Q2: Will it still be possible to build 32-bit binaries? Is this the end of the road for 32-bit and/or XP? Personally, I won't shed any tears for the loss of either of them, but others may feel differently.

One reason I can think of for keeping 32 bit is firewire tuning as some people use that and the drivers only work with 32 bit systems in Windows. But that will likely fade over time as fewer cable boxes will support firewire.

SHS 11-01-2017 09:10 AM

Quote:

Originally Posted by wayner (Post 611699)
One reason I can think of for keeping 32 bit is firewire tuning as some people use that and the drivers only work with 32 bit systems in Windows. But that will likely fade over time as fewer cable boxes will support firewire.

Have you try this ? wayner.
https://blogs.msdn.microsoft.com/usb...ewire-package/

btrcp2000 11-01-2017 09:19 AM

I have no skills to help with development, but would be willing to test. I'm trying to move to UNRAID for 64bit, but have had no success getting my r5000 tuners to work with a linux sage server.

Taddeusz 11-01-2017 09:19 AM

Quote:

Originally Posted by SHS (Post 611702)

The problem isn't with FireWire support itself but with the drivers needed for the tuners themselves. Those drivers are proprietary in nature.

SHS 11-01-2017 09:23 AM

Quote:

Originally Posted by Taddeusz (Post 611705)
The problem isn't with FireWire support itself but with the drivers needed for the tuners themselves. Those drivers are proprietary in nature.

So are say it the STB it self then ?.

Taddeusz 11-01-2017 09:36 AM

Quote:

Originally Posted by SHS (Post 611706)
So are say it the STB it self then ?.

Yes, the STB drivers are 32-bit only and I'm unaware of any 64-bit drivers. It apparently uses a standard interface but someone would need to have the knowledge to build a new version of the driver. This is the same interface used to communicate with old SVHS recorders.

SHS 11-01-2017 11:29 AM

Quote:

Originally Posted by Taddeusz (Post 611707)
Yes, the STB drivers are 32-bit only and I'm unaware of any 64-bit drivers. It apparently uses a standard interface but someone would need to have the knowledge to build a new version of the driver. This is the same interface used to communicate with old SVHS recorders.

So there a 2nd driver that ride on top of windows firewire driver ?.

wayner 11-01-2017 11:54 AM

Quote:

Originally Posted by SHS (Post 611711)
So there a 2nd driver that ride on top of windows firewire driver ?.

Yes, there were some drivers that were "hacked" together - I believe it was by a guy named Tim M Moore. If I remember correctly he reverse engineered the ones for a Panasonic D-VHS recorder. These drivers were supposed to work for both video capture and changing channels. I never got the video capture to work with my boxes reliably but the channel changing was rock-solid. They were never officially supported by any company (or person) so it was always kind of a kluge.

But the drivers don't work on 64 bit systems. There has been some discussion here about the issue here and more on the AVS forums. Here is one thread that hasn't been updated in about five years, perhaps there are other threads as well: http://www.avsforum.com/forum/42-hdt...-1394-a-5.html

The best drivers for 32 bit can be found here: https://exdeusweb.github.io/stbfirewire/

Of course, this stuff is very old so there are lots of broken links, etc.

SHS 11-01-2017 01:47 PM

Quote:

Originally Posted by wayner (Post 611713)
Yes, there were some drivers that were "hacked" together - I believe it was by a guy named Tim M Moore. If I remember correctly he reverse engineered the ones for a Panasonic D-VHS recorder. These drivers were supposed to work for both video capture and changing channels. I never got the video capture to work with my boxes reliably but the channel changing was rock-solid. They were never officially supported by any company (or person) so it was always kind of a kluge.

But the drivers don't work on 64 bit systems. There has been some discussion here about the issue here and more on the AVS forums. Here is one thread that hasn't been updated in about five years, perhaps there are other threads as well: http://www.avsforum.com/forum/42-hdt...-1394-a-5.html

The best drivers for 32 bit can be found here: https://exdeusweb.github.io/stbfirewire/

Of course, this stuff is very old so there are lots of broken links, etc.

I see what going on looking at the INF it self in this case look like it build around 9x WDM architect so driver them self could very well be build around same old architect that could explain why there are some compatibility issues with newer OS so with out the original source code there is no hope for you in near future in tell the patent expire and by time there be no telling where SageTV will be at.

bryanzim 11-02-2017 04:31 AM

If this ever were to work then you would be able to build both a 32 bit build and a 64 bit build.

So it looks like PushReader is using a combination of FFMPeg and Mplayer from the 3rd party library. I was able to pull down and compile a new version of FFMpeg; I converted most of the code in PushReader to the newer FFMpeg except for the audio conversion. As I am not a FFMpeg expert this may take some time.

At this point in time it looks as if maybe I want to try to compile the version of mplayer in the third party library and revert push reader since the new mplayer source tree does not contain the audio conversion functions any more either.

So currently at a stumbling block.

btrcp2000 12-12-2017 08:58 AM

Just wondering if you have had any luck with a 64 bit windows setup?

jusjoken 01-19-2018 04:39 PM

Quote:

Originally Posted by bryanzim (Post 611747)
If this ever were to work then you would be able to build both a 32 bit build and a 64 bit build.

So it looks like PushReader is using a combination of FFMPeg and Mplayer from the 3rd party library. I was able to pull down and compile a new version of FFMpeg; I converted most of the code in PushReader to the newer FFMpeg except for the audio conversion. As I am not a FFMpeg expert this may take some time.

At this point in time it looks as if maybe I want to try to compile the version of mplayer in the third party library and revert push reader since the new mplayer source tree does not contain the audio conversion functions any more either.

So currently at a stumbling block.

Any progress?

sdsean 10-12-2018 07:18 PM

Resurrection!!!

So I am a bit surprised that the drivers for firewire tuning don't exist in a 64bit format and even then I feel like that can be resovled with a wrapper. Serial tuning has worked for years on 64bit windows with literally 0 problems (I'm still using it today). beyond that there's still IR tuning and HTTP tuning . . .HTTP tuning has been supported by nearly all STBs be that cable or satellite for the last few years, and IR tuning works on 64 bit already.

What are the other barriers to have a 64bit build on windows? I'd really like to be able to connect more than 2 (maybe 3) HD-300s but more than 2 pretty much always peaks the memory usage beyond 1GB with plugins and what not. . . Yes I could switch to linux, but that's a whole different can of worms and would make it so that i have to create interops between things like playon (which only run on windows). Again as said many times I'm sure there are barriers but to me tuning should be the last problem needing solved. . .

wnjj 10-13-2018 09:02 PM

Thanks for the bump. I, too plan to give this 64-bit thing a whirl. I just now got the 32-bit version to compile OK using the wonderful instructions provided by previous pioneers.

The only wrinkle I ran into was the Windows SDK 6.1 is no longer available for download so I had to make a few changes to get it working on 7.1A.

1. Find a "qedit.h" and add it back to the 7.1A include directory.
2. Added a new include file with a bunch of CSLID's and IID's that are no longer in strmiid.lib for use in FilterGraphTools.cpp.

With those 2 additions, I compiled it ok with SDK7.1A.

Now I'm throwing the switch on 64-bit mode to see what fun ensues. I'm already getting warnings about _USE_32BIT_TIME_T and "long *" versus "LONG_PTR *" which I'll have to work through.

I'm making no promises as this may just be one thing after another but I'm willing to give it a shot.

sdsean 10-13-2018 09:07 PM

Sweetness, let me know what you find and if you think you need and let me know as well I can try and jump in and make edits.

wnjj 10-18-2018 06:03 PM

Update (the following was all done using Visual Studio 2015 and MSYS2/MINGW):

After doing a considerable amount of cleanup inside the VS project files to more easily build 32-bit and 64-bit into separate directories I was able to compile everything in the project except the stream demux filter (same place bryanzim got to). As he stated, it relies upon PushReader which was built in MinGW previously.

Because that filter is only used for video playback, I dumped the files I did have onto a clean machine and tried to fire it up, immediately running into the missing ImageLoader lib...dang. Since I had previously managed to compile the swscale and ImageLoader Windows dlls within MinGW, I next installed a newer MSYS2/MINGW32/MINGW64 setup that supports both 32-bit and 64-bit.

After installing some packages into MSYS2, I was able to build both 32-bit and 64-bit swscale.dll and ImageLoader.dll. I have yet to try but building PushReader should be similar.

Tonight I plan to try running with the ImageLoader dll added and see if I can't at least get a 64-bit server to start up.

The BIG caveat in all of this is that there will likely be 32/64-bit pointer issues that arise as crashes when they finally get used. Now the compilers do warn about them and I fixed a few but so many aren't 'real' issues (like subtracting pointers and storing the result into an 'int').

Still chugging along...

jusjoken 10-18-2018 07:57 PM

This is great news and progress. When you succeed i will need to figure out how to adjust the installer...unless you feel like taking that challenge on as well :D

Thanks for taking this on,

k

sdsean 10-18-2018 08:19 PM

So excited! Let us know if there's any further research or code we can help with!

EnterNoEscape 10-18-2018 08:29 PM

Very cool. It's exciting to see progress on the one thing I thought would never happen for SageTV. :thumb:

wnjj 10-18-2018 08:31 PM

Quote:

Originally Posted by sdsean (Post 617406)
So excited! Let us know if there's any further research or code we can help with!

I'm pretty sure the 7 libraries needed to compile PushReader are:

Code:

faac
faad
xvidcore
x264
avformat
avcodec
avutil

I've gotten faac and faad to compile. Xvidcore has a VS project with it so it can probably be built directly in VS.

I haven't figured out x264 (third_party/codecs/x264) or the 3 "av" libraries (third_party/ffmpeg).


If you can manage to build any of those 4 into 64-bit .a or .lib files, that is the main block right now. Even building them for 32-bit is just as difficult. As it is now, pushreader.lib (which links all 7) is already built and sitting there in the Pushreader dir so it hasn't ever been built for V9.

wnjj 10-18-2018 08:33 PM

If this ffmpeg stuff becomes too difficult, shouldn't you still be able to run a headless server in 64-bit and then connect a 32-bit client to it? In other words is there enough reason to even get all of the video/audio playback filters working in 64-bit?

For that matter, isn't the Sage demux optional? I have to admit I don't fully understand how all of the filter graphs get built and what you don't really need.

jusjoken 10-19-2018 04:08 AM

Quote:

Originally Posted by wnjj (Post 617409)
If this ffmpeg stuff becomes too difficult, shouldn't you still be able to run a headless server in 64-bit and then connect a 32-bit client to it? In other words is there enough reason to even get all of the video/audio playback filters working in 64-bit?

For that matter, isn't the Sage demux optional? I have to admit I don't fully understand how all of the filter graphs get built and what you don't really need.

In my opinion having playback on the server is not required. The 32 bit client and placeshifter would fill that void. The gap we windows folk need is a 64 bit server so we can have numerous clients connected.

k

SteveW 10-19-2018 09:34 AM

Quote:

Originally Posted by jusjoken (Post 617412)
In my opinion having playback on the server is not required. The 32 bit client and placeshifter would fill that void. The gap we windows folk need is a 64 bit server so we can have numerous clients connected.

k


Very much agree. I often do playback on my server when I'm troubleshooting my HD-PVRs and the satellite receivers beside them.


If I can still fire up a Sage Windows client on the same windows server that has the Sage server running on it, that all works for me...

KryptoNyte 10-19-2018 04:06 PM

Quote:

Originally Posted by wnjj (Post 617409)
If this ffmpeg stuff becomes too difficult, shouldn't you still be able to run a headless server in 64-bit and then connect a 32-bit client to it? In other words is there enough reason to even get all of the video/audio playback filters working in 64-bit?

1) Does it affect Placeshifter if the server can't render the video?
2) When configuring the channel lineup on some tuners, the station preview can be helpful, although not necessarily required.

I like the idea that you could run the client on the server machine if a user needed to.

This is very exciting to see the 64 bit part happening!

SHS 10-20-2018 05:06 AM

Quote:

Originally Posted by KryptoNyte (Post 617414)
1) Does it affect Placeshifter if the server can't render the video?
2) When configuring the channel lineup on some tuners, the station preview can be helpful, although not necessarily required.

I like the idea that you could run the client on the server machine if a user needed to.

This is very exciting to see the 64 bit part happening!

That what I was think plus it may also be need for transcoding

wnjj 10-20-2018 11:48 PM

1 Attachment(s)
I agree that it would be nice to get video playback working. I'm just not sure if the Sage demux is required for that.

So to update on my progress, see the attached image. :)

There are still plenty of missing and untested pieces. For example I haven't gotten the Freetype font library complied without missing dependencies, there's an error in the log file about a "bundle for base name" (i18n) and I had to skip over the pixel shader code since it kept returning an error code. I'll keep at this but it's definitely showing some promise!

EDIT: The "bundle for base name" was a typo in my sage.properties that I had hand-edited the paths in. ;) One down, several to go...
EDIT2: It looks like the pixel shader code is missing some compiler...probably because I hand-copied some 64-bit DX9 dll's to my test system. There must be a couple more needed.
EDIT3: Yep. Just needed to install the DX9 runtimes and that fixed the pixel shader issue. I assume the installer has to define dependencies and include 64-bit now?

jusjoken 10-21-2018 04:59 AM

:goodjob: :clap: :jump:

deanm 10-21-2018 05:08 AM

:goodjob::goodjob:

trk2 10-21-2018 06:57 AM

:smokin:

EnterNoEscape 10-21-2018 11:41 AM

:goodjob::thumb:

NetworkGuy 10-21-2018 02:56 PM

:clap::jump::clap::jump:

wnjj 10-22-2018 10:44 AM

I installed 64-bit LAV filters on my test machine and voila, it played an MPEG2 recording (originally from an HDHR source)! :thumb:

This is without the problem child Sage StrmDeMux.ax filter complied/installed.

So who here can explain how all these decoders, renderers, demuxes, splitters, etc. work? I see all kinds of if/else code for selecting filters mostly based upon media type (naturally) plus registry options to disable at least the Sage stream demux. I've read plenty of generic DirectShow stuff talking about filters/graphs generically so I have some idea but I've never really had a good handle on what pieces (dll's/ax's) do what specifically for SageTV. Are all these custom Sage filters less relevant these days with other options like LAV?

If the StrmDeMux.ax filter isn't strictly needed, all that remains is further testing and getting the installer to deal with 64-bit stuff which I've never dealt with.

What I did to get this running by hand was:

Code:

1. Copy the newly-built 64-bit binaries into a new directory.
2. Copied the STVs & JARs folders and existing sage.jar, sage.properties & RemoteClients.properties.defaults from the 32-bit setup.
3. Hand-edited the paths inside sage.properties to point to the new install area.
4. Ran 'regsrv32.exe' from an elevated command prompt on all of the .ax files in the 'common' directory plus STVEVRPrstr.dll in the main directory.
5. Installed the DX9 redistributables to get the 64-bit versions.


So I then tried connecting an HD200 and nothing showed up but when I checked the server, another client window was sitting there open and had me go through the config menus. So it looks like it rendered it locally instead of at the HD200. It may be something I did wrong since it's been 9 years since I configured a server. ;)


There will be other issues as I only tweaked stuff until some things worked. My test video was one OTA MPEG2 file since that's mostly what I deal with. I did play an mp4 from a camera OK but the progress bar never moved so something's up there. I put a ripped DVD into the video directory but it won't show up in Sage either. Not sure why that is. Maybe some missing Sage component is needed to locate those?

MattHelm 10-22-2018 11:52 AM

Quote:

Originally Posted by wnjj (Post 617474)
So who here can explain how all these decoders, renderers, demuxes, splitters, etc. work?

It's magic. Ask Harry! :bang:

wnjj 10-22-2018 01:01 PM

Answering some of my own questions just a bit by looking in the code. It seems that "MpegDeMux" is used for MPEG2-TS/PS formats, a standard MS filter is used for AVI and then all other DirectShow playback goes through "StrmDeMux".

If StrmDeMux is disabled through the registry setting "Directshow/EnableSageTVStreamDemux" = 0, no filter is used for non-MPEG2/AVI formats. In that case I assume DShow builds a playback graph automatically from whatever it finds installed on the system?

jusjoken 10-22-2018 07:06 PM

Have you pm'd Narflex to see if he can explain?

BTW: although time is tight i will take on the installer work as i think its important and i SO appreciate you getting us this far. PM me when you want help with that.

k

wnjj 10-22-2018 07:36 PM

Quote:

Originally Posted by jusjoken (Post 617478)
Have you pm'd Narflex to see if he can explain?

BTW: although time is tight i will take on the installer work as i think its important and i SO appreciate you getting us this far. PM me when you want help with that.

k

I PM'd him. I was kind of hoping he'd drop by but I'm sure he's a busy guy.

That would be great if you can help with the installer. I know nothing about that but have learned quite a bit about what's needed to run in 64-bit mode, the first of which is the 64-bit DX9 runtimes. I'm not even sure how external dependencies are handled. Does the installer include the 32-bit versions of those binaries today? Just a few DLL's or a whole DX9 install-able package? When I downloaded the DX9 runtimes, I ended up with a .zip file full of .cab files (remember those?). Then the DX9 installer program extracted the DLL's needed (and likely many more not needed ones).


All times are GMT -6. The time now is 03:54 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.