NextPVR Forums

For information about this plugin please visit the SoftwareRecorder Wiki Page.

VERY VERY IMPORTANT: If you want to use this plugin for anything but LiveTV in Preview Mode, i.e. LiveTV in timeshift mode, or recording programs, then you will have to install an mpeg encoder library. Check below for the list of encoders that have been known to work. It seems that the default MPEG2 decoders provided by windows have troubles decoding some video streams, therefore it is recommended that you use the video decoder that comes with the encoder to watch your recordings. Please try the ATI Avivo encoder first.

EVEN MORE IMPORTANT: If you can't get your card to work, please make sure that you take all the logs generated during your testing, zip them together and attach them to the message you post in this thread. In the logs hide all the secret answers to your problems, I can't guess what's wrong if I don't have logs.

Encoders know to be working (preferred at the top):
- ATI Avivo Video Conterter - normanr - bit-tech review, digit-life review, gb-pvr forum thread
- ATI MPEG Video Encoder - irony.delerium - These drivers are provided by ATI for use with their TV tuner cards.
- Moonlight MPEG2 Encoder - normanr
- Elecard MPEG2 Encoder - The Mac reports some success
- LEAD MPEG-2 Encoder - nwenos reports success

Cards known to be working:
- ATI 7200 VIVO - unknown chipset - pBS
- ATI AIW 7500 combo - unknown chipset - ivanvector - untested
- ATI TV Wonder - unknown chipset - collindv, DeepSpace1 - DUX review, HardwareCentral review
- ATI TV Wonder Pro - Conexant CX8800-series chipset - irony.delerium - might require btwincap drivers
- ATI Wonder Pro USB 2.0 - Phillips Tuner - Theater 200 Chipset - pBS - no tuner audio
- Avermedia AVerTV 203 - BT878 chipset - convil - tv-cards review
- Avermedia UltraTV PCI 300 - BT878 chipset - Kindred359
- ECS EZ-TV TVP3XP - Philips SAA7134HL chipset - miochza - digit-life review
- Hauppauge WinTV Go - BT878 chipset - madmike269
- LifeView FlyVideo 3000 FM (aka LifeView FlyTV Prime 34) - Philips SAA7134HL chipset - normanr - digit-life review, mittoni review
- MSI built ATI Theater 550Pro - angust63
- MSI TV@Anywhere Plus - unknown chipset - ivanvector - works with 'double record' setting
- Pinnacle PCTV Pro - BT848 chipset, Connexant 878A with Temic 3X7 524 tuner - Klaas, pBS - aardvark review, tv-cards review
- Pinnacle PCTV Rave - BT848 chipset, Connexant 878A with Temic 3X7 035 Tuner - RMJ - tv-cards review (only preview mode confirmed, but seeing as the pro works - this one should too)

It would be appreciated that if you get this to work that you report your configuration so we can add it to the supported list.

MPEG-2 Compressors/Encoders: What this plugin really needs is a free mpeg2 compressor library that can be used to replace the Moonlight one. Unfortunately to make an encoder work with gb-pvr it needs to exist as a module that can be inserted into a DirectShow graph. GraphEdit is a program that can be used to create your own graphs and link up components. As a rule of thumb, IF-AND-ONLY-IF the encoder can be used in GraphEdit (and it takes video and audio of some form, and it also has to output the mpeg stream for further use - and not write it directly to a file), then it can be used in gb-pvr. Encoders/compressors that do not match this description (and hence can not be used by this plugin) include: FFMPEG, FreeEnc, XMPEG, QuEnc, hcenc.

First post:
This is the first pass at the support for LifeView FlyVideo card. It requires a mpeg2 encoder (Moonlight encoder, evaluation version avalible for download from http://www.elecard.com/download/)

At the moment it only captures from the first avalible WDM Video Capture device, and it enforces that fact that the video capture has to be mpeg2 encoded. It should work with other mpeg2 encoders, but I've only tested it with the Moonlight ones.

The attached package includes:
- DShowNet - directshow library for c#
- SoftwareRecorder - plugin that does non-mpeg2 video capture
- RecorderTest - small app that tests any capture plugins.

Second post:
I managed to get config.exe to 'find' the SoftwareRecorder by implementing the GBPVR.Backend.Common.TechnoTrendRecordingSource class (and just making that inherit from SoftwareRecorder.SoftwareRecorder), and dumping the software recorder .dll into plugins/

Getting the GBPVRRecordingService to load it was another story, but a small code injection loads all the plugins into the ApplicationDomain, so that it can access the SoftwareRecorder class.

i.e. I added a call to am.a() from bt.ctor() - what ever these function are before Dotfuscator gets to them. In other words: a call to [the Function in BackendCommon that loads plugins/*.dll] from [the Function called just after "GB-PVR Recording Service starting"]. This does end up loading far more plugins than needed for the recording service (e.g. DVDRipperPlugin bitches about not being able to find config.xml), but it's the easiest if you don't have all the source code.

To get both the config, and GBPVRRecordingService to find DShow.dll: I had to set up .config files that have runtime.assemblyBinding.probing.privatePath's. Dumping DShow.dll into the gbpvr folder instead of plugins doesn't work because the path probings end up being relative.

Of course all of these 'hacks' will dissapear in the next version.

I also had to add code to change the settings for the Moonlight Muxer again. GB-PVR Parser seems to insist that MPEG2 streams are recorded in "Program" and not "Transport" mode.

There is a 3.5 second delay between "DirectShowHelper::playFile" and "Graph running". About 1.5 seconds is taken up by the two "File already in use - probably still recording" messages, but another 2 is taken after the "About to load PreferredDecoder". I'm guessing here that it's not really the decoder loading, but the graph connecting, etc? GraphEdit seem to generate and connect a similar graph much quicker.

To help with slow graph creation I don't destroy the Graph immediatly after stopRecording is called, so that if it's a pure channel change I can just re-tune the tuner and change the filename and re-start the graph. If the graph is left un-used for a second, then I clean it up. This helps, but not dramatically.

Looking forward to version %currentversion%+1

Wow, I'm not a coder and therefore almost all the above post just goes over my head, BUT I've just picked up a FlyVideo 3000 on ebay here in Australia and I really appreciate all your hard work. It will be great when you get this thing really cooking along.

Keep going, it sounds like you're whippin it...

Wow! Can this be made working for other then WDM too?

Best regards!

Would there be any chance of being able to use this system to make PiP possible, it would be a good addition to this most wanted software cards... In other words using a muxer and muxing two MPEG2 streams together to one MPEG2 stream... Is this possible or would this need a new muxer... Ofcorse only one audio stream is used, but switching between main picture and the PiP should be possible... Also would be great to be able to see the channel in PiP if one could use a simple channel list before changing to that channel...

This will be great for people with two cards or later people with one DVB and one PVR/WDM card...

Hope this can be done...

Best regards and keep up the great work!

PiP really needs a backend re-design to make things all work transparently. But I'm guessing that you'd need to find a supporting DirectShow filter to be able to do PiP. I'll keep it in mind while I'm playing.

dito: After some reading I've found that doing PiP is technically really easy.

Technical note: call IVMRFilterConfig::SetNumberOfStreams, to enable the VMR mixer mode - I expect this is already being done, because bitmaps are being blitted onto the video stream for OSD.
Then call IVMRMixerControl::SetOutputRect for each input stream to set it's position in the output window.
You can also use IVMRMixerControl::SetZOrder to set the z-order of each stream.

So yes it's very possible, but no I can't do it very easily, ask sub nicely if he'll start showing us some source code (sub: i'm even willing to think about signing nda's over this - i'd really like to help make gb-pvr an awesome program.)

That approach would only work if you're using VMR. GB-PVR also supports Overlay, XCard, PVR350 and MVP, which would probably make this a non-starter.

Correct, you really shouldn't be using Overlay (VMR's have far cooler transparant OSD's), but you have a good arguement with the XCard, 350 and MVP output sources. As I don't have any (i might have access to the 350/MVP in the future) I can't really comment on those. I'm guessing that a custom DirectShow filter doing the PiP would help there.

Thanks normanr for giving clearity to the subject!

Hope there can be some progress for PiP since it is really cool!

Best regards!