Raspberry Pi Based Extender

[SageWizdom]

Having seen several discussions about a Raspberry Pi based extender, I wanted to create a place to talk about it. As a conversation starter, I thought I would post the specs for the HD300, the Raspberry Pi 2 ($40) and the new Raspberry Pi Zero ($5).

HD300

• Sigma Designs SMP8654 (500Mhz-600Mhz Arm ??)
• 500-1GB Ram
• 2 USB 2.0 ports
• 1 10/100 Ethernet
• HDMI 1.3
• S/PDIF
• IR Receiver
• Power

RPI 2($40)

• BCM2836 (Quad Core 900Mhz ARMv7)
• 1GB Ram
• 4 USB 2.0 ports
• 1 10/100 Ethernet
• HDMI 1.3 / 1.4
• Power Port
• Free: h.264/AVC , MPEG-4 ASP
• With License : MPEG2 (~$3.75), VC1 (~$2)

RPI Zero($5)

• BCM2835 (1Ghz ARMv11/ARMv6)
• 512GB Ram
• 2 micro USB 2.0 ports
• micro HDMI 1.3 / 1.4
• Free: h.264/AVC , MPEG-4 ASP
• With License : MPEG2 (~$3.75), VC1 (~$2)
• Essentially the same as any of the Raspberry Pi 1 boards

pcDuino3 Nano($15)

• AllWinner A20 SoC, (Dual Core 1GHz ARM Cortex A7)
• 1024GB Ram
• 4GB onboard
• 2-3 USB
• HDMI 1.4 (w/HDCP)
• 10/100/1000 Eth
• Free: h.264/AVC , MPEG-4 ASP
• With License : MPEG2 (~$3.75), VC1 (~$2)
• Essentially the same as any of the Raspberry Pi 1 boards

pcDuino8

• http://store.cutedigi.com/pcduino8-stb-with-enclosure/
• Runs Android 4.4
• AllWinner A20 SoC, (8 Core 2GHz ARM Cortex A7)
• 1024GB Ram
• 8GB onboard
• 2 USB
• HDMI 1.4 (w/HDCP)
• 10/100 Eth
• Ir Receiver and Remote
• wifi (B/G/N?)

I keep thinking it would be cool to be able to build an extender for $5 out of the Raspberry Pi Zero, but looking at the pcDuino8, I'm wondering if it makes more sense to just support/buy/help (how) the android effort. Thoughts?

Given all the work already done to split the code (easier maintenance) I may just say nevermmind to the idea... but it also means I cant really help (not a java guy, sorry)

[stuckless]

When dealing with SageTV you'll have hard to getting away from Java... even for the MiniClient piece. The HD300 uses java as well, but there is "native" portion (some of that code is open source). Similar to Android client, since it's written in Java, but the player code is all C.

I think getting video playback on the PI would be problematic, but certainly solvable if you have the C and Media skills. (Kodi runs on PI, so it's all possible, in theory).

Personally, I'd be more interested in a SageTV Server on PI than a client. (ie, lightweight server, no transcoding)

[Fuzzy]

Originally Posted by stuckless

When dealing with SageTV you'll have hard to getting away from Java... even for the MiniClient piece. The HD300 uses java as well, but there is "native" portion (some of that code is open source). Similar to Android client, since it's written in Java, but the player code is all C.

I think getting video playback on the PI would be problematic, but certainly solvable if you have the C and Media skills. (Kodi runs on PI, so it's all possible, in theory).

Personally, I'd be more interested in a SageTV Server on PI than a client. (ie, lightweight server, no transcoding)

I think the Pi's data IO capabilities would be it's Achilles heel in a server role (100Mbps ethernet, and only USB 2.0). Something like a pogoplug may be more appropriate for server duty, having a gigibit ethernet port, SATA port, and USB-3.0. It even comes with a case! Unfortunately, I think it's only got like 128MB of RAM, making an actual sage server impossible. I wish there was something on the market that hit somewhere in the middle, but I haven't seen it.

If sage had a slightly different architecture, where there was a 'thin server' that could do just the recording, scheduling, and carny, but all UI was handled by full clients only, it would likely work on a small embedded device like that. A Pi² actually would make plenty of sense as a full client, instead of a miniclient, as it'd have the gpu capabilities for accelerated UI rendering and the local RAM to handle caching of images. But yeah, in that arrangement, miniclients and placeshifters would not be possible.

[SageWizdom]

Writing up the original post, I'm not sure if I talked myself into or out of, figuring out how to make it work. I was thinking that while new firmware is out of the question, seeing how the firmware worked, and mimicking it might not be that hard.

Presumably the HD300 was running a basic os (linux or similar), device drivers, maybe some java and the mini client. I was thinking that since the Pi and others already run debian, it might not be to bad making them run an extender.... but I'd rather spend my effort where it is best served. If the android port is really working, and I can just get something like the above box for $40, its probably not worth it. I'll just work on the FFMPEG updates/mplayer updates etc. (something in C that I can actually do, vs Java)

You guys definitely are spending lots of time on this, any thoughts on which needs more help ffmpeg or mplayer and what needs to be done? For either of these, I'd recommend compartmentalizing any sage specific changes and working on making it so the normal baseline with minimal updates does what sage wants (so it can stay current). It also may be worthwhile to see if those projects might consider some sage options as part of their baseline.

[stuckless]

Originally Posted by SageWizdom

Writing up the original post, I'm not sure if I talked myself into or out of, figuring out how to make it work. I was thinking that while new firmware is out of the question, seeing how the firmware worked, and mimicking it might not be that hard.

I see nothing wrong with that, personally. I have a love of writing Android apps (at least trying) and a long time of love of SageTV, so for me, porting the MiniClient to Android was a good fit in terms of my skills and what I love to do, as a hobby. Plus I got to learn a great deal in terms of how the SageTV miniclient works.

Originally Posted by SageWizdom

Presumably the HD300 was running a basic os (linux or similar), device drivers, maybe some java and the mini client. I was thinking that since the Pi and others already run debian, it might not be to bad making them run an extender.... but I'd rather spend my effort where it is best served. If the android port is really working, and I can just get something like the above box for $40, its probably not worth it. I'll just work on the FFMPEG updates/mplayer updates etc. (something in C that I can actually do, vs Java)

You guys definitely are spending lots of time on this, any thoughts on which needs more help ffmpeg or mplayer and what needs to be done? For either of these, I'd recommend compartmentalizing any sage specific changes and working on making it so the normal baseline with minimal updates does what sage wants (so it can stay current). It also may be worthwhile to see if those projects might consider some sage options as part of their baseline.

If you have to skills (and passion) for C, then I'd suggest you start with ffmpeg, bring it up to the latest version of ffmpeg. Jeff and team had to do several changes to the original ffmpeg code to make it work with sagetv, so figuring out those changes, and then applying them to a recent ffmpeg would be great. This is not a small task, and it's somewhat tedious. I've done this already (about 70%) for the mplayer portion (which is really only used on the linux placeshifter).

https://github.com/OpenSageTV/mplayer/tree/master

If you look at that mplayer project, there is a master branch which is an untouched mplayer, and then a sagetv branch which is the changes that I've managed to apply to mplayer.

Something similar needs to be done for the ffmpeg sources.

If no one else does it, I'll likely take a stab at it (someday), but, to be honest, it's not my core skillset.

Originally Posted by Fuzzy

I think the Pi's data IO capabilities would be it's Achilles heel in a server role (100Mbps ethernet, and only USB 2.0). Something like a pogoplug may be more appropriate for server duty, having a gigibit ethernet port, SATA port, and USB-3.0. It even comes with a case! Unfortunately, I think it's only got like 128MB of RAM, making an actual sage server impossible. I wish there was something on the market that hit somewhere in the middle, but I haven't seen it.

If sage had a slightly different architecture, where there was a 'thin server' that could do just the recording, scheduling, and carny, but all UI was handled by full clients only, it would likely work on a small embedded device like that. A Pi² actually would make plenty of sense as a full client, instead of a miniclient, as it'd have the gpu capabilities for accelerated UI rendering and the local RAM to handle caching of images. But yeah, in that arrangement, miniclients and placeshifters would not be possible.

Yeah, when I think of creating a lightweight server, it's really a server that does exactly as you describe. I would then consider extending the Android MiniClient to also be able to run as a full client, where the UI is fully rendered locally on the Android Client instead of on the Server. A full android client, is probably the next project I tackle once the MiniClient is complete (or at least in good shape).

[SageWizdom]

Speaking of the mplayer, there may be a change needed in how SageClient calls mplayer. The no audio issue looks to be a possibly forced use of a specific codec. As I noted in the post linked below, I will try to take a look, but if you have an idea where this is and can point me at it, that would be awesome.

Thanks

http://forums.sagetv.com/forums/show...&postcount=617

[Fuzzy]

Originally Posted by stuckless

I see nothing wrong with that, personally. I have a love of writing Android apps (at least trying) and a long time of love of SageTV, so for me, porting the MiniClient to Android was a good fit in terms of my skills and what I love to do, as a hobby. Plus I got to learn a great deal in terms of how the SageTV miniclient works.



If you have to skills (and passion) for C, then I'd suggest you start with ffmpeg, bring it up to the latest version of ffmpeg. Jeff and team had to do several changes to the original ffmpeg code to make it work with sagetv, so figuring out those changes, and then applying them to a recent ffmpeg would be great. This is not a small task, and it's somewhat tedious. I've done this already (about 70%) for the mplayer portion (which is really only used on the linux placeshifter).

https://github.com/OpenSageTV/mplayer/tree/master

If you look at that mplayer project, there is a master branch which is an untouched mplayer, and then a sagetv branch which is the changes that I've managed to apply to mplayer.

Something similar needs to be done for the ffmpeg sources.

If no one else does it, I'll likely take a stab at it (someday), but, to be honest, it's not my core skillset.



Yeah, when I think of creating a lightweight server, it's really a server that does exactly as you describe. I would then consider extending the Android MiniClient to also be able to run as a full client, where the UI is fully rendered locally on the Android Client instead of on the Server. A full android client, is probably the next project I tackle once the MiniClient is complete (or at least in good shape).

The changes in ffmpeg, as far as I can tell (hopefully Jeff or Qian can back me up on this), are:
- stv:// source. This is a source that pulls the file via Sage's MediaServer protocol (which is a very simple streaming protocol).
- on the fly video bitrate changes, controlled via STDIN (used for real time transcoding for placeshifter - only works with MPEG4 in the current version, should be made to work h.264 in any new version)
- clean exit command via STDIN

I think the only change in mplayer for sagetv was the stv:// source (which since both are a part of avcodec, is just a copy from one project to the other.

The only 'improvements' I can think of that'd need to be made along with the update to the newer version, besides the transcoding changing to h.264, would be creating an stv:// output module to go along with the stv:// input module. This is something that could be used for network encoders to send a stream from just about any source to the sagetv server, while transcoding on the fly, and not having to pipe the stream in and out of a separate process like PrimeNetEncoder has to do currently.

[SageWizdom]

A quick tool shout-out. The tool I use for comparing code (Linux/Mac/Windows) is called Beyond Compare. It has an incredibly well implemented folder comparison feature, that then allows you to drill into the files that are different, and the lines. etc. It can ignore unimportant changes (whitespace) etc.

I'm basically pulling the sage ffmpeg / mplayer code and doing a walk through with the official repos to see / validate the differences. I just thought I'd share in case other folks were trying to do similar.

http://www.scootersoftware.com/

[Fuzzy]

Yeah, that's not tough to do... the issue is finding what version of the ffmpeg repo the sage modded files were sourced from.

[stuckless]

Originally Posted by SageWizdom

A quick tool shout-out. The tool I use for comparing code (Linux/Mac/Windows) is called Beyond Compare. It has an incredibly well implemented folder comparison feature, that then allows you to drill into the files that are different, and the lines. etc. It can ignore unimportant changes (whitespace) etc.

I'm basically pulling the sage ffmpeg / mplayer code and doing a walk through with the official repos to see / validate the differences. I just thought I'd share in case other folks were trying to do similar.

http://www.scootersoftware.com/

I used MELD to do the same thing, for the mplayer that I have modified in the OpenSageTV repo.

The mplayer-sagetv9 has 2 branches as well. The "master" is the original unmodified mplayer, and the "sagetv" branch has the modifications. If you check out both (int different areas, and then run beyond compare, you can then get a decent view of all the changes).

I would then use that dual view and find a change and try to figure out how to make the same change in the newest mplayer sources. It's not entirely easy since a lot of changed between the original sagetv mplayer version and the newest. But, the results of those changes are in the "mplayer" repo on OpenSageTV, where the "mplayer" branch is the unmodified newest, and the "sagetv" branch is the changes that I made for the migration.

So, you'd need to so something similar for ffmpeg, by finding the closest unmodified version of ffmpeg, and then compare that to the sagetv modified version, and then start migrating changes to a fresh new ffmpeg. I would suggest doing these changes in a git enabled repository so that you can track the changes made and commit them, and then later, we can upgrade ffmpeg, by rebasing the modified repo to the latest ffmpeg (which will then replay your changes).

[SageWizdom]

Originally Posted by stuckless

.
So, you'd need to so something similar for ffmpeg, by finding the closest unmodified version of ffmpeg, and then compare that to the sagetv modified version, and then start migrating changes to a fresh new ffmpeg. I would suggest doing these changes in a git enabled repository so that you can track the changes made and commit them, and then later, we can upgrade ffmpeg, by rebasing the modified repo to the latest ffmpeg (which will then replay your changes).

I had to move some servers around and clean up for the holidays, but I'm going to work through the mplayer and ffmpeg paths and see if I can get them rolling. Hopefully I'll be able to find some time in the next few days to play with things.

This is probably behind a v2 of the linux install guide though. I've figured out the firewall commands I needed and I'm going to re-do it having folks use the .deb packages (downloaded for now). As well, I'm going to add in the auto start via init.d (from previous forum posts) and auto PrimeNetEncoder startup. I'm hoping to figure all the bits as command line commands, with the next step either scripting the whole thing, or using some other automated install path.

[wayner]

Originally Posted by stuckless

Personally, I'd be more interested in a SageTV Server on PI than a client. (ie, lightweight server, no transcoding)

Why is this?

I have just bought components for a new Server to run V9 and it is pretty much the most heavyweight server you can get with the latest CPU, Z170 chipset, 16GB of RAM, honkin' fast SSD for the system, etc. My last server gave me a decade or so and I want this one to do the same. I want to make sure it has the capabilities to run Comskip, transcode, etc.

My hope is that in the future we will have Sage available for many platforms, especially mobile platforms like Android and iOS, just like Plex, but I am assuming that this may require transcoding in many instances so you want a server that can handle that.

[stuckless]

Originally Posted by wayner

Why is this?

I have just bought components for a new Server to run V9 and it is pretty much the most heavyweight server you can get with the latest CPU, Z170 chipset, 16GB of RAM, honkin' fast SSD for the system, etc. My last server gave me a decade or so and I want this one to do the same. I want to make sure it has the capabilities to run Comskip, transcode, etc.

My hope is that in the future we will have Sage available for many platforms, especially mobile platforms like Android and iOS, just like Plex, but I am assuming that this may require transcoding in many instances so you want a server that can handle that.

As I said, "personally", because about 2 years ago, I was working on a project where I needed a lightweight media server (ie something that basically served up media, held metadata, etc), running on a low-cost ARM box. The clients were "thick" clients that would talk with the media server for media information and locally cache the data (and media files) on the android device. I ended up building it all from scratch, since sagetv wasn't an option. Today, given the same project, I'd likely try running SageTV server on an ARM box, and use an Android "thick client" for the UI. I don't think that this is the typical use case, but it is of interest to me

[jchiso]

Originally Posted by stuckless

... I don't think that this is the typical use case, but it is of interest to me

I'm in the same camp. I love that I can use Pis to act as Kodi servers. My Sage servers are all pretty weak, but I don't ask them to do much more than capture and save data streams to disks. I've never experimented with add-ons and such. A Pi-based option would be more than adequate for my purposes ...

[wayner]

I just got a few RPi3s to add to my collection of Pi2. I had primarily been using the original Pi and the Pi3 is way, way faster. It would be great to be able to use a Pi as an extender if we can get everything working on ARM hardware.

[SageWizdom]

Originally Posted by wayner

I just got a few RPi3s to add to my collection of Pi2. I had primarily been using the original Pi and the Pi3 is way, way faster. It would be great to be able to use a Pi as an extender if we can get everything working on ARM hardware.

How much is really needed for a placeshifter client. I think that is the real question. Stuckless I think is the expert in that camp right now.

[stuckless]

When I look at the available hardware today, for a placeshifter client, the PI is interesting, but not something that I'd personally tackle.

Getting the UI to work on the PI would be trivial, actually the v9 miniclient jar would probably just work (as long as I included the arm based jogl libraries -- not sure if I strip them out, but if I do, then added them in, is easy).

The challenge on any platform is going to be video. Video is not trivial... even for someone as skilled as Jeff. It'll certainly be easier for someone with his skillset, but still not a quick an easy project.

You might be able to get the current mplayer to recompile for for ARM, but, your miniclient is still only as good as the mplayer on linux today.

For me, Android offers the most benefit. It has a decent Media Player framework, that is getting better, and includes out of the box hardware decoding for mpeg2, h264 and h265. All the challenges that exist today, getting video to work and supporting things like audio passthrough, native output switching, etc, all would still have to be solved in the PI as well. Plus with Android, SageTV running as an App, you get the benefit of easy access to Netflix, YouTube, and just about any other streaming service. The Android platform is far from perfect, but, I think it best MiniClient platform we are going to see.

My understanding is that the PI has a native video player (not sure of all the capabilities), but integrating it with the rest of the MiniClient would be a fair amount of work. (just based on what I know from including 3 video libraries into the Android MiniClient)

All that being said, I do want to get a PI3 (I tried to buy one, but they are sold out), so that I can play with it. It is an interesting platform, and maybe someone will tackle it as a MiniClient platform. I'm not confident it would be better than a $99 Nexus Player, or even a Chromecast.