Enable the use of tuning plugins for non-SageTV network encoders.

[enternoescape]

I believe I was able to find a good location for the plugin to be used if it is defined. I compiled with the changes linked below and was able to use the EXEMultiTuner plugin without any issues. A change to the STV would also be needed to so you can select between, using a local plugin or allow the remote server to tune the channel. I am still working out the STV changes, but I wanted to get this up here in case there are concerns.

https://github.com/enternoescape/sagetv/commit/bfeb009361c6540a75a72fd512458bdb18c37a04

[Narflex]

I'm sort of confused by how this would be used. The way it's currently done is by having the network encoder itself handle the tuning...and if you're using SageTV for that, then you just configure the tuning plugin in the instance of SageTV that's running the network encoder. Can you explain what scenario you'd expect this to be used in?

[enternoescape]

The OpenDCT network encoder has started supporting IPTV devices. The tuning supported in OpenDCT is EXE based for the time being. In this configuration, the network encoder is not another instance of SageTV. The network encoder currently also does not have a GUI, so the easiest way to facilitate this is to allow the use of the use of the tuning plugins in SageTV.

[Narflex]

Interesting...can you point me to a link regarding what IPTV devices they are supporting?

[enternoescape]

I wrote up a small review on one of them in the forums: http://forums.sagetv.com/forums/showthread.php?t=63177

The device I tested can be found here: http://www.aliexpress.com/item/MPEG-4-AVC-H-264-HDMI-Encoder-Replace-HD-Video-Capture-Card/1856597088.html

If you wanted one for yourself, I'd go with the one here (1080p60 encoding): http://www.aliexpress.com/store/product/MPEG-4-AVC-H-264-wifi-HDMI-Video-Encoder-HDMI-Transmitter-live-Broadcast-encoder-wireless-H264/837328_32644182124.html

MythTV has a page dedicated to them: https://www.mythtv.org/wiki/IPTV_Encoders_as_a_Capture_Device

[Narflex]

Oh, OK...now I get it. :) Thanks!

[enternoescape]

There's a very large variety, so I basically created a capture device that will generally work with any http address that links directly to a TS which is one of the many ways to get video from this category of devices. It might be a little while until I have an STV proposal since I really don't mess with that part of SageTV much. :)

[enternoescape]

This wasn't actually that hard to do. Here's a screenshot of what it looks like:

Here's the modified STV: https://github.com/enternoescape/sagetv/blob/master/stvs/SageTV7/SageTV7.xml

Like I said, though, I don't edit in studio much, so I definitely need someone to review this and tell me if I did something bad.

[Narflex]

I don't think you made your changes based off the SageTV7.xml file that is in GitHub...when I do a diff between yours and that one I get a lot more changes than I would have expected in areas that don't even apply to this.

That would be the right place to change the menu that you show in the screenshot; but I'd go with these options:

1. Use external Cable or Satellite receiver to tune the channel controlled by the SageTV Server. (The SageTV Server will do the tuning rather than the Network Encoder)
2. Don't Configure Tuning. (You may still configure infrared or serial tuning control using the SageTV installation that is controlling this Network Encoder)

The 2 options that were already there are essentially the same in their behavior..so I'm not even sure why we had two options in there currently.

I also noticed in your Java code that you cloned doPluginTune from the Windows or Mac capture code...the Linux one does it a little different in IVTCaptureDevice; so be sure to cover that case as well. Also feel free to refactor that code to make it cleaner and consolidated so that the same code isn't in multiple different places. :)

[enternoescape]

I did actually make my changes to that file. When I saved it from studio, I saw some other things in the file that I wasn't expecting and that's partly why I wanted someone else to take a look. I'll start over with a clean file and hopefully have better results.

Thanks for the cross-platform tip. I'll fix that up too. It didn't occur to me that the code I was looking at didn't do anything for Linux.

My thoughts are that the doTunePlugin methods can be merged into CaptureDevice as a few protected static methods for their respective operating systems. That way they are accessible to any capture device that needs them, but they don't get initialized for capture devices that don't even use them. This of course adds some more parameters, but it's actually not that bad.

[enternoescape]

Now it looks like this:

I'm still not sure what happened the first time around, but not fully understanding the file structure, I didn't know if it was normal to have those extra things; I now know it's not. :) The SageTV7.xml I created this time is much cleaner. I also moved the doPluginTune methods over to doPluginTuneWindows, doPluginTuneLinux and doPluginTuneMac static functions. I did a search for the doPluginTune method and changed each location over.

https://github.com/google/sagetv/commit/c2d2a541a97da276dfc5c4593ee776e4b3e6c174

[Narflex]

Feel free to submit a pull request when you have it all ready.

Something else I should mention....have you considered integrating OpenDCT into the SageTV core directly as another set of capture devices through its own CaptureDeviceManager class?

[enternoescape]

Will do.

That is a thought I've had and is partly why I chose the Apache 2.0 license for OpenDCT.

One of the big reasons I have not even attempted it is because Cling UPnP is used to detect the InfiniTV capture devices, in my opinion would add significantly to the heap while it's running; it creates lots of short-lived byte arrays about every minute. I don't like adding that kind of overhead when it's not going to benefit very many users. Other than that, it would likely not take a lot of effort to add the InfiniTV as a normal capture device.

The other thing is that OpenDCT has a pooling concept. This only applies to capture devices that can actually report that they are locked by another computer. So far that's just the HDHomeRun capture devices. It will automatically group the capture devices based on how the device is configured (DCT, QAM, ATSC). The pools can be changed manually if desired, but generally that isn't needed. When SageTV requests any capture device within one of these groups, OpenDCT will iterate over the capture devices in order of priority until it finds one that is not currently locked, then it will lock it. There is also an option to force a device to unlock if they are all locked. OpenDCT maps capture devices on START and BUFFER. It unmaps them on STOP. I guess something like this could be ported into SageTV, but would we want that to cover all capture devices or just have it somehow available as a special option for HDHomeRun devices?

I also ported the majority of the HDHomeRun communication protocol over to Java; I don't know if that's a plus or minus for you. That code has been in use since October of last year and has proven to be very stable.

Something else that it can do is use any available capture device with a CableCARD installed to find the frequency and program for a given channel and then map that to any available ClearQAM capture device. Basically SageTV provides a channel number to be tuned on a ClearQAM device, OpenDCT looks it up on the device with a CableCARD, then tunes the frequency and program in on the ClearQAM device.

The next problem I can think of is how would we add capture devices to SageTV that it can't actually detect? A great example is the IPTV encoder I just added to OpenDCT. Would we just have a permanent entry in the capture devices labeled something like "Manually configure new capture device."?

I'm not really trying to completely bombard you will complications, but I do like the flexibility of being able to update this project at will and I'm not sure just how far you would be willing to let me change how SageTV works. Especially since some of the features might involve significant changes.

Maybe what would make this easier for everyone would be adding the ability to have SageTV load capture devices provided as a plugin?

[Narflex]

Yeah...there's lots of unique stuff relating to OpenDCT it sounds like...and it's already abstracted over a clean interface so we can just leave it the way it is. Not as much to gain by spending a bunch of time integrating all of that.

But if there's other features of the network encoder protocol you wanted that might be useful for you...feel free to bring those up. It is a versioned protocol, so extending it is not a problem.

[enternoescape]

This is probably not the greatest place to ask about this, but it's kind of related.

The streams produced by the IPTV encoder do not remux well into .mpg files; all of the streams are there, but very few players can actually open the files. I believe for similar reasons, the HD-PVR only creates .ts files.

The only way I have found that I can present this device as an HDMI device and not see an extra screen asking for me to select an audio device is to use MMC.MPEG_PURE_CAPTURE_MASK. This returns the quality MPEG2_Transport_Stream as the only selectable encoder quality which actually results in SageTV requesting a Program Stream from the network encoder. Is this intentional or can I propose to change it to request a Transport Stream instead?

[Narflex]

You should also be able to use the flag MMC.MPEG_AV_CAPTURE_MASK and then it won't ask you to select the audio source. This should also then give all the normal MPEG2 Program Stream encoding quality options as well.

Interestingly enough, for network encoders, it doesn't really matter what the quality is set to because it will always do a format detection on the file to determine it's type. Really, the only thing that changes between using MPEG_PURE and MPEG_AV is that one ends up with a .ts file extension and the other ends up with a .mpg file extension (but the contents of the files are identical).

Historically, I always felt .mpg (MPEG2-PS) files were more compatible because the layout of them was much more straightforward than .ts (MPEG2-TS) files. That's why SageTV always converted recordings into .mpg format (except for the HD-PVR). But nowadays, there's much more compatibility for MPEG2-TS playback (such as ExoPlayer on Android, which didn't even have MPEG2-PS support until I added it recently).

[enternoescape]

OpenDCT will actually produce an MPEG2-PS file if SageTV gives the file a .mpg extension. Does SageTV do anything extra on .ts files? I noticed that sometimes the video or audio is missing if an MPEG-TS it muxed into a file with a .mpg extension, but I have never seen this happens when the file extension is .ts.

[Narflex]

The only thing different that comes to mind for .ts files is that thumbnail generation is done slightly different due to FFMPEG issues with parsing some TS files.

Which reminds me...are you using FFMPEG at all for remuxing; or did you end up using the SageTV remuxing code for that? (I was chatting with somebody about that awhile back, I think it might have been you) If audio or video is missing after a remux; then it sounds like a problem with the remuxer itself. :)

[enternoescape]

FFmpeg is being used for remuxing. I have been looking at adding support for the way SageTV remuxes. I can assure you that unless FFmpeg is making things up that all remuxing done by OpenDCT contains at least one video stream and all audio streams available within the same program. I am actually using the libraries of FFmpeg, not ffmpeg.exe. When it creates MPEG-PS files using FFmpeg, sometimes SageTV will only see the video or audio. However, if I make SageTV re-detect the file after it's done recording, suddenly it will see the video and audio. These same files playback anywhere else without these issues. I fixed this recently by forcing a video key frame to be the very first packet when remuxing. When I use MPEG-TS, I have yet to have SageTV be unable to detect the video and all available audio streams correctly.

[Narflex]

Closing this one out since the change has been made.